SRv6 for Redundancy Protection

Redundancy Protection is a generalized protection mechanism to achieve high reliability for services provided in a Segment Routing (SR) network. Specifically, packets of flows are replicated at a replication network node into two or more copies, which are transported via different protection paths in parallel. At the elimination network node, the multiple copies are received, redundant packets are eliminated, and only a single copy of the packet is forwarded. This mechanism is commonly referred to as "Live-Live" as data traffic is forwarded on the protection paths simultaneously and therefore it provides a packet-level protection. In case of redundancy protection, there is no need to perform switchover between primary and backup paths as data packets are sent simultaneously on multiple protection paths. Connectivity is provided until at least one protection path remains operational. One new SRv6 Segment Endpoint Behavior, the associated Headend Encapsulation Behaviors and the associated Redundancy Policy are introduced to support the redundancy protection functions (i.e., replication, and elimination) on specific network nodes by leveraging SRv6 Network Programming capabilities. Depending on the Service Level Objective of a service and the network characteristics (topology, link/node availability, Bit Error Rate of links, etc.) redundancy protection can be used alone or together with other protection mechanisms like TI-LFA. Detailed design rules of redundancy protection (e.g., location of replication and elimination functions, number of used protection paths, routes of protection paths) are scenario-specific and outside the scope of this document. Redundancy protection provides ultra-reliable protection to many services, for example DetNet flows, Cloud VR/Game, IPTV service and other types of video service, high-value private-line services.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

SR: Segment Routing SRv6: Segment Routing over IPv6 SID: Segment Identifier RSID: Redundancy SID R-node: Redundancy node participating in the service protection. Replication node: R-node doing replication. A network element that replicates incoming packets for parallel delivery. Elimination node: R-node doing elimination. A network element that eliminates duplicates to forward a single copy. Redundancy Policy: A policy associated with an RSID, that contains entries for redundancy protected flows and how these flows are served by local redundancy functions. RedInst: Redundancy instance, that provides the flow-specific redundancy function on an R-node. FID: Flow Identifier SeqNum: Sequence Number Member flow: One part of the protected flow between the R-nodes.

Redundancy nodes (R-nodes) are interconnected by SRv6 tunnels used to encapsulate the protected flow. Flow-specific redundancy actions on a redundancy node are triggered by the Redundancy SID (RSID) and the actions are defined by the Redundancy Policy. The Redundancy Policy contains entries for each flow for which the R-node provides redundancy protection. The replicated flow parts between the R-nodes are referred to as member flows. There are two basic types of redundancy actions applied on the protected flow: (1) replication, and (2) elimination. A flow has one or more actions defined in its Redundancy Policy entry. The actions are executed by the flow related redundancy instance (RedInst), that maintains flow-specific state (e.g., action type, action order, ingress/egress member flow-specific parameters, identifiers).

To support the redundancy protection function, flow identifier (FID) and sequence number (SeqNum) information are added to the member flow packets in the RSID as arguments. They are used at downstream R-nodes when their redundancy actions are executed: Flow Identifier (FID): defines which flow the packet belongs to. It is used to determine via the Redundancy Policy which redundancy instance (RedInst) has to be used on a node. Sequence Number (SeqNum): defines the sequencing information, it is created at the first redundancy node, and used by the replication and elimination functionalities. FID identifies one specific member flow on an R-node and has local significance. The FID value is allocated by the receiving R-node, therefore an upstream R-node must place the downstream R-node's FID in the RSID. Allocation methods and signalling of FID values are outside the scope of this document. They can be allocated for example, by a centralized controller or can be allocated and advertised by the R-node. BGP, PCEP or NETCONF protocols can facilitate the advertisement and distribution of flow identification information among controllers and R-nodes. FID MUST be included in the RSID as an argument. The local FID identifies an ingress member flow, and the Redundancy Policy points to the related serving RedInst. Member flows of an original flow may have different FIDs at different R-nodes. In case of elimination there are multiple incoming FIDs for the member flows and they are associated with the same elimination instance (RedInst). SeqNum distinguishes the packets within a flow by specifying the order of packets. All replicas of an original packet carry the same SeqNum. Unlike the FID, which remains constant for all packets in a given member flow, the SeqNum changes with each packet. SeqNum MUST be included in the RSID as an argument. The SeqNumber is an unsigned value and the SeqNum space is a circular one with no restriction on the initial value. The SeqNum MUST be incremented by one for each new packet of the original flow. The values can wrap, and it is important to note that zero (0) is a valid SeqNum value. For example, when the SeqNum size is 16 bits, the sequence will contain: 65535, 0, 1, where zero (0) is an ordinary sequence number. The SeqNum length MUST be provisioned on a per original flow basis via configuration in the Redundancy Policy, and MUST be consistent on all related R-nodes. SeqNum is generated at the first R-node along the path and subsequent R-nodes preserve the original SeqNum. The algorithm(s) used by RedInst is out of scope. Impact of various network events like restart of an R-node are algorithm-specific and also not covered here. The exact format of Redundancy SID (RSID) is network addressing design specific. Redundancy-specific parameters are encoded as follows: LOC: specifies the R-node (same allocation rule applies as for any SRv6-enabled node). FUNC: a single value represents the redundancy function of an R-node. ARG: contains the FID and the SeqNum parameters. The minimum number of bits needed for FID and SeqNum are dependent on the network scenario and the characteristics of the served flows. As the size of these parameters directly impacts scalability, this document list values an implementation MUST support. Other parameter sizes MAY be supported if it fits within the selected network addressing design. RSID MUST support containing a FID of 20 bits. RSID MUST support containing a SeqNum of 16 bits and 28 bits. The ARG part of the RSID MUST contain first the FID immediately followed by the SeqNum. Remaining least-significant bits of the ARG part MUST be filled with zeros. A packet does not carry any indication of the SeqNum length. The SeqNum length is inferred entirely from the locally configured Redundancy Policy. All member flows associated with a RedInst MUST use the same SeqNum length. The remaining zero-filled bits are merely padding. Figure 1 shows an example of the RSID with a 20-bit FID and 16-bit SeqNum in the argument.

A Redundancy Policy SHOULD check and reject configuration with unsupported or inconsistent SeqNum lengths. For example, if a network uses /80 for LOC+FUNC, then the remaining 48 bits are enough to carry a 20-bit FID and a maximum-size SeqNum field (28-bit) defined for DetNet flows in . Note: if Function=RSID, Arg=0 is also a meaningful value and does not refer to the lack of arguments. It means that the packet belongs to a flow having FID=0 and its SeqNum=0. Note 2.: Encoding the FID and SeqNum as arguments of the SID implies that when the RSID is in the IPv6 DA, the DA changes on a per-packet basis for the redundancy protected flow, and it may alter the ECMP hashing. This can be avoided for example, by using additional node-specific SIDs before the RSID (e.g., End).

A Redundancy SID MUST have a related Redundancy Policy. The Redundancy Policy MUST contain entries for each member flow for which the R-node provides redundancy protection using the given RSID. Each entry of the Redundancy Policy MUST contain the flow-specific actions and their parameters. The following summarizes the minimum set of information that is needed in the Redundancy Policy entries: Ingress member flow(s) identification information (e.g., FID). Redundancy action-specific parameters (e.g., RedInst identifier, Action pipeline, Action type, SeqNum length, Algorithm). Egress member flow(s) identification information (e.g., RSID+FID used by the downstream R-node). Egress member flow(s) redundancy path parameters (e.g., ordered list of segments associated with a member flow). The first and last R-nodes need additional information elements: Ingress flow matching information on the first R-node (e.g., 5-tuple of the served original flow). Egress forwarding information on the last R-node (e.g., which VRF/VSI to use for forwarding). Flow matching options are defined, for example, in . They can be used for ingress flow matching on the first R-node. The use of an SR Policy, as described in , to define an egress member-flow protection path is outside the scope of this document.

Figure 2 shows an example of redundancy protection used in an SRv6 domain.

| | | | +-----+ | | +-----+ R3 +-----+ | | | +-----+ | | +-----+ +--+--+ +--+--+ +-----+ -------+ R1 +--------+ Rep | | Elm +-------+ R2 +------- +-----+ +--+--+ +--+--+ +-----+ | +-----+ | +-----+ R4 +-----+ +-----+ ]]> R1, R2, R3, R4, Rep and Elm are SR-capable nodes. Rep and Elm are redundancy nodes (R-node). When a flow is sent into the SRv6 domain, the process is: 1) R1 receives the traffic flow and encapsulates packets with a list of segments destined to R2, which is instantiated as an ordered list of SRv6 SIDs. 2-1) When the packet flow arrives at the Rep node (an R-node configured for replication), each packet is replicated into two copies. 2-2) Metadata information including flow identifier (FID) and sequence number (SeqNum) are added to the copies. (FID is used to identify the specific flow on the downstream R-node, and SeqNum distinguishes the packet sequence within a flow.) 2-3) Each copy of the packet is encapsulated using the RSID of the downstream R-node and a new path-specific segment list, which represents different forwarding paths towards the downstream R-node. One encapsulated copy is forwarded over R3 and the other over R4. The path is provisioned for example, by a controller. 3) The multiple encapsulated replicas go through different paths until they reach the next R-node, i.e., the Elm node in this example. 4-1) The Elm node decapsulates the packets and it is configured with an elimination action for the flow. The first received copy of each packet is forwarded, and the redundant packets are eliminated. 4-2) Furthermore, the redundancy policy entry of the flow specifies that the non-eliminated packets are forwarded, without additional encapsulation and added metadata, to the R2 node. When there is any failure or packet loss in one path, the service transmission continues through the other path non-disruptively. No interaction is needed between the R-nodes. In general, replicas are preferred to be sent over disjoint paths. The mechanism can operate over non-disjoint paths, although the resulting protection may be reduced. The type of disjointness (e.g., using link-, node-, or SRLG-disjoint paths) is use-case and network scenario-specific. Sometimes, out-of-order packets may occur since service packets are recovered from different forwarding paths. In this case, the Elm node or other network nodes downstream of the Elm node may include a reordering function to guarantee in-order delivery of packets. Reordering is implementation-specific and out of the scope of this document. Note: a possible reordering function is described in . Note 2.: the jitter caused by random packet loss can be minimized, if the protection paths have similar forwarding delay.

To achieve Redundancy Protection in an SRv6 network, the following packet processing rules are defined regarding the Redundancy SID: (i) End.R, (ii) H.Encaps.R, (iii) H.Encaps.R.Red, (iv) H.Encaps.R.L2, and (v) H.Encaps.R.L2.Red. Note that, the algorithm used by the redundancy functionality is not within the scope of this document. For example, provides algorithms used for reliability.

This section describes the redundancy-specific behaviors that can be associated with a SID.

Redundancy Segment is the identifier of packets on which service protection needs to be executed on the redundancy node. It has an associated Redundancy Policy, defining the flow-specific instance executing the service protection action(s). The use of Redundancy Segment triggers via the redundancy functionality of the R-node. R-nodes are interconnected by SRv6 tunnels used to encapsulate the protected flow and they hold flow state regarding the served traffic flow. From the segment routing architecture perspective , R-nodes are ingress node for the served member flows. Flow-specific states are present only on R-nodes. Nodes between the R-nodes do not have flow-specific states. The Redundancy SID MUST be the final segment in an SR Policy (i.e., Segment List[0]) and it is associated with the redundancy functionality. A Redundancy Segment is associated with service instructions, indicating the following operations: Decapsulates the received SRv6 packet and extracts the flow identifier and sequence number from it. Steers the packet (and its extracted metadata) via the Redundancy Policy into the corresponding redundancy instance (RedInst). The RedInst is selected by the flow-specific redundancy policy entry and it executes the related redundancy processing (like packet replication/elimination, egress member flow encapsulation). Packets with an unknown FID or failed redundancy instance (e.g., incomplete configuration, resource exhaustion, unsupported SeqNum length) MUST be droped. Because an R-node needs to maintain the state of served flows, the management or control-plane entity provisioning the policy MUST have knowledge of replication/elimination node's capabilities (e.g., maximum number of flows, maxmimum packet rate, buffering capacity, supported algorithms, computation capacity). It MUST NOT provision the redundancy policy to a redundancy node when the computation result goes beyond the capability of the node. The capability advertisement is outside the scope of this document. When an SRv6-capable node (N) receives an IPv6 packet whose destination address matches a local IPv6 address instantiated as an SRv6 SID (S), and S is a Redundancy SID, N does:

When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.R SID, N does the following:

Upper-Layer Header processing of End.R SID in Step06 is the same as that defined in Section 4.1.1 of .

This section describes a set of SRv6 Redundancy Policy Headend behaviors.

When a node "N" receives a packet P=(A, B) identified as a flow for redundancy, and B is neither a local address nor a SID of "N". Node "N" executes the flow-related redundancy function, resulting in one or more member flows (P1=(A, B), P2=(A, B), ...) with related parameters ([FID1, SeqNum], [FID2, SeqNum], ...). Note: The number of resulting member flows depends on the configuration of the flow related function. For example, in the case of elimination there is only one egress member flow. Node "N" is configured with an IPv6 address "T" (e.g., assigned to its loopback). Node "N" steers the egress packet P1 into an SRv6 Policy with a Source Address T and a segment list SP1=<S11, S12, S13>, where S13 is a Redundancy SID (LOC+FUNC) with 0 as ARG. The H.Encaps.R encapsulation behavior for one member flow is defined as follows (SA: source address, DA: destination address): The Next Header field of the SRH MUST be set to 4 or 41 depending on the encapsulated packet (IPv4 or IPv6 respectively). After the H.Encaps.R behavior, P1 and P2, if P2 exists, look like: (T, S11) (S13, S12, S11; SL=2) (A, B), note: S13.ARG=FID1,SeqNum (T, S21) (S23, S22, S21; SL=2) (A, B), note: S23.ARG=FID2,SeqNum The member flow packet is encapsulated unmodified (with the exception of the IPv4 TTL or IPv6 Hop Limit that is decremented). The push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there is no need to use any flag, tag, or TLV. In such cases the outer destination address is the Redundancy SID and the Next Header field of the IPv6 packet is set to 4 (IPv4 payload) or 41 (IPv6 payload).

The H.Encaps.R.Red behavior is an optimization of the H.Encaps.R behavior. H.Encaps.R.Red reduces the length of the SRH by excluding the first SID in the SRH of the pushed IPv6 header. The first SID is only placed in the Destination Address field of the pushed IPv6 header. After the H.Encaps.R.Red behavior, P1, and P2 respectively look like: (T, S11) (S13, S12; SL=2) (A, B), note: S13.ARG=FID1, SeqNum (T, S21) (S23, S22; SL=2) (A, B), note: S23.ARG=FID2, SeqNum

The H.Encaps.R.L2 behavior encapsulates a received Ethernet frame and its attached VLAN header, if present, in an IPv6 packet with an SRH. The Ethernet frame becomes the payload of the new IPv6 packet. The H.Encaps.R.L2 encapsulation behavior is similar to H.Encaps.R but sets an Ethernet-specific outer Next Header and lacks the TTL- or Hop-Limit-related action. H.Encaps.R.L2 is defined as follows: The Next Header field of the SRH MUST be set to 143. The push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there is no need to use any flag, tag, or TLV. In such cases the outer destination address is the Redundancy SID and the Next Header field of the IPv6 packet is set to 143 (Ethernet payload). The encapsulating node MUST remove the preamble (if any) and frame check sequence (FCS) from the Ethernet frame upon encapsulation, and the decapsulating node MUST regenerate, as required, the preamble and FCS before forwarding the Ethernet frame.

The H.Encaps.R.L2.Red behavior is an optimization of the H.Encaps.R.L2 behavior. H.Encaps.R.L2.Red reduces the length of the SRH by excluding the first SID in the SRH of the pushed IPv6 header. The first SID is only placed in the Destination Address field of the pushed IPv6 header. The push of the SRH MAY be omitted when the SRv6 Policy only contains one segment and there is no need to use any flag, tag, or TLV. The encapsulating node MUST remove the preamble (if any) and frame check sequence (FCS) from the Ethernet frame upon encapsulation, and the decapsulating node MUST regenerate, as required, the preamble and FCS before forwarding the Ethernet frame.

A node supporting this document SHOULD implement a pair of traffic counters (one for packets and one for bytes) per local RSID entry, for traffic that matched that RSID and was processed successfully (i.e., packets that generate ICMP Error Messages or are dropped are not counted). The retrieval of these counters from MIB, NETCONF/YANG, or any other data structure is outside the scope of this document. Counters and logging of redundancy istances are algorythm and implementation-specific and are outside the scope of this document.

IANA maintains the "SRv6 Endpoint Behaviors" sub-registry of the "Segment Routing" registry. IANA is requested to make one new assignment from the First Come First Served portion of the registry as follows:

Note to the RFC Editor: this section is to be removed before publication. This section records the status of known implementations of the Redundancy Protection defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942. The description of implementations in this section is intended to assist the IETF in its decision-making processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". Known implementations: The organization responsible for the implementation: open-source project by Ericsson. Link to the implementation: https://github.com/EricssonResearch/xdpfrer. Brief general description: this software is an experimental implementation of the algorithms and functions defined in IEEE 802.1CB standard, and the SRv6 Redundancy SID. It is able to replicate packets over redundant network paths to protect against network failures. The implemented functions are called replication (generates copies and sends them over different paths) and elimination (accepts the first copy and drops the duplicates). The implementation's level of maturity: prototype. Coverage: RSID and Redundancy Policy are fully implemented. Flow identification on the ingress node is limited to IPv6 Flow Label. Maximum SID Depth (MSD) is 6. Version compatibility: v08 Licensing: BSD 2-Clause "Simplified" License, see https://github.com/EricssonResearch/xdpfrer/blob/main/LICENSE Implementation experience: detailed description at implementation link. Contact information: Ferenc Fejes ferenc.fejes at ericsson.com Date: 2026-07-10.

This section addresses the operational and management aspects of SRv6 Redundancy Protection, covering deployment, configuration, monitoring, and maintenance guidance. It is targeted for operators managing this functionality to effectively integrate the capability into their networks while maintaining security, performance, and consistency. This is a non-exhaustive list of operational considerations.

Redundancy protection MUST operate with reasonable defaults: Redundancy Protection function: R-nodes default to ordinary IPv6 processing (i.e., without any redundancy protection actions on packets) until explicitly configured with an RSID and the related Redundancy Policy. FID Field Size: Default to 20 bits as specified in Section 3.2. SeqNum Field Size: Default to 16 bits as specified in Section 3.2., and supporting 28 bits for advanced scenarios. Application: Redundancy policies are not applied until explicitly provisioned by a management entity or control plane, preventing unintended replication or elimination of traffic. Operators need to be able to verify that configured defaults match actual running configurations for troubleshooting and consistency assurance.

Redundancy Protection needs to be integrated incrementally into existing SRv6 networks: Coexistence: R-nodes need to support both Redundancy Endpoint behavior (End.R) and existing SRv6 behaviors. Traffic not served by the redundancy protection function needs to be unaffected. Staged Deployment: Operators ought to deploy to a subset of nodes or flows before network-wide adoption. Configuration Rollback: Operators need to have the ability to disable redundancy policies on R-nodes without disrupting other services, enabling rapid rollback if issues arise during deployment.

Dependencies: All R-nodes MUST support SRv6. In many scenarios external systems (PCE, SDN controllers) are expected to compute protection paths, however they are not mandatory. Resource Consumption: Bandwidth: Redundancy protection duplicates traffic (i.e., 100% overhead per additional protection path). R-node Processing: Replication and elimination consume CPU and memory. Operators need to ensure, that flow counts do not exceed R-node capacity. ECMP and Load Balancing Impact: Per-packet ARG changes in RSID can alter ECMP hashing. Therefore, operators are required to verify the hashing behavior of every relevant forwarding node and mitigate the impact if needed e.g., by using node-specific SID(s) before RSID. Fast Reroute (FRR): Redundancy protection can coexist with other protection mechanisms. Operators are advised to carefully consider the interaction to avoid unnecessary resource usage. Traffic Pattern Changes: Using redundancy protection assumes sufficient path diversity. Monitoring needs to account for expected duplication patterns to avoid false security alarms.

Security operations related to the redundancy-protection function include: Indicators of Compromise: Security operators need to account for simultaneous traffic on multiple paths. Sequence number analysis can detect replay attacks or anomalies. Implemented algorithms on R-nodes need to provide counters to support such analysis. Logging: replication/elimination events, policy changes, and error conditions need to be logged with timestamps for audit trails. Management Access Control: needs to use strong authentication, encrypted transport (TLS), and role-based access control (RBAC) for all management interfaces.

Operators intend to verify redundancy protection through several mechanisms: Redundancy Policy Status: each R-node supports active query of redundancy policy entries and served flows. Replication/Elimination Counters: monitor the number of duplicate packets on a per-flow basis. Path Verification: confirm traffic follows intended protection paths via SRH inspection. Connectivity Tests: end-to-end connectivity testing for a served flow is needed, for example, for troubleshooting.

The following manageable entities are described in this document: Redundancy Node (R-node), Redundancy SID (RSID), Redundancy Policy, and Redundancy Instance (having per-flow state). Standardized technologies can be used for management of Redundancy Protection: YANG-based Management: Recommended for configuration and state via NETCONF or RESTCONF . Syslog: For operational events and error logging . IPFIX: For flow-level statistics export . YANG model is outside the scope of this document.

Fault Management needs to provide: Monitor liveness via Connectivity Fault Management tools. Detect packet arrival on protection paths. Track packet-replication rate, duplicate-elimination rate, and sequence number gaps to identify path failures. Count malformed RSIDs to detect configuration errors. Generate alerts when approaching flow capacity limits. Configuration Management needs to provide: Allow operators to define, modify, and delete redundancy policies. Support atomic multi-device configuration transactions. Enable configuration consistency verification across R-nodes. Persist configurations across device restarts.

The following tools are expected: Protocol Monitoring: Track replication rate, elimination rate, out-of-order delivery rate, and packet loss via sequence number discontinuities. Device Monitoring: Monitor CPU utilization, memory consumption, and forwarding performance impact on R-nodes. Network Monitoring: Monitor link utilization on protection paths and path efficiency relative to direct routes. Service Monitoring: Measure flow-level metrics (throughput, latency, jitter) against SLA targets. Accounting: Collect usage statistics (protected flows, replicated bandwidth) for capacity planning, cost allocation, and trend analysis.

Operators need to first assess whether existing management systems (NETCONF clients, syslog aggregators, monitoring platforms) can be adapted to support redundancy protection before developing new tools. New tooling development needs to focus only on functions existing tools cannot provide (e.g., specialized path computation and validation).

Detailed security considerations for segment routing are cataloged in , , and . General security considerations on SRv6 are described in . The introduction of Redundancy Segments in Segment Routing networks introduces new vectors for security threats that needs to be carefully mitigated.

Redundancy protection intentionally replicates packets across multiple paths. Without proper admission control or policy enforcement, an attacker could exploit this mechanism to amplify traffic, overwhelming downstream links or elimination nodes. The amplification can also magnify denial-of-service attacks if unauthorized traffic reaches replication nodes. Amplification can also be achieved by the attacker by by-passing the elimination. The use of redundancy protection needs to be restricted to a trusted SR domain with controlled flows, where rate-limiting and flow admission control is employed at the ingress nodes. Redundancy protection needs to be provisioned via authenticated and authorized controllers.

The elimination node relies on sequence numbers to de-duplicate packets. An attacker that can inject or manipulate these sequence numbers could cause legitimate packets to be dropped or reordered. Replay attacks can also affect the operation of redundancy protection. For example, a rogue node, either the headend or a transit node, can cause pathological reordering, intentionally delay packets, or duplicate packets to arrive much later. The impact of such attacks is dependent on the applied algorithm; however, algorithms are outside the scope of this document.

Redundancy protection could involve topology-specific path selections that reveal operational characteristics of the network (e.g., availability of disjoint paths). Statements of on leaking explicit routing information through the boundaries of the administered domain apply for redundancy protection as well.

Redundancy nodes with elimination functionality need to maintain state (e.g., sequence windows, buffering) for each redundancy protected flow. An attacker might attempt to create many such flows to exhaust memory or processing capacity. By limiting the number of concurrent redundancy flows, the R-node can protect its resources. The impact of resource exhaustion is dependent on the implemented method, however elimination algorithms are out of scope of this document.

Contributors Huawei

China shirley.yangfan@huawei.com

Ericsson

Hungary ferenc.fejes@ericsson.com

The authors would like to thank Bruno Decraene, Alvaro Retana, Andy Smith, Ron Bonica, James Guichard, Jeffrey Zhang, and Adrian Farrel for their valuable comments and discussions.

This appendix shows how the described End.R mechanisms can be used in an SRv6 network.

-------| | Link6 +->--| N3 |----->-------| E5 |--->--+ | +----+ Link4 +----+ | | Link1 | | +---+ +----+ | +----+ +---+ |src|--->---| R1 | +->-+ | E6 |--->---|dst| +---+ +----+ | +----+ +---+ | Link2 | Link7 | | +----+ +----+ | +->--| n4 |--->-----| R2 |----->----+ +----+ Link5 +----+ Link8 n: non-SRv6 IPv6 node N: SRv6-capable node R: Node with Replication Function E: Node with Elimination Function ]]> Note: The IPv6 notations in this appendix are not syntactically valid. Letters such as 'K', 'L', 'P', 'U', 'X', 'src', 'dst', and 'arg' are not hexadecimal IPv6 components, but used for better human readability and refer to symbolic placeholders. In the reference topology: Nodes N3, R1, R2, E5 and E6 are SRv6-capable nodes. Nodes R1, R2, E5 and E6 are Redundancy nodes. Node n4 is an IPv6 node that is not SRv6-capable. Node j has an IPv6 loopback address 2001:db8:L:j::/128. A SID at node j with locator block 2001:db8:K::/48 and function U is represented by 2001:db8:K:j:U::. 2001:db8:K:j:P:: is explicitly allocated as the End.R SID at node j. For example, 2001:db8:K:2:P:: represents End.R at node R2. 2001:db8:K:j:Xim:: is explicitly allocated as the End.X SID at node j towards neighboring node i via the m-th link between nodes i and j. For example, 2001:db8:K:3:X51:: represents End.X at node N3 towards node E5 via Link3 (the first link between nodes N3 and E5). Similarly, 2001:db8:K:3:X52:: represents the End.X at node N3 towards node E5 via Link4 (the second link between nodes N3 and E5). If the src node sends a packet to the dst node for which per-packet redundancy is configured, then the nodes with Redundancy functions provide the required replication or elimination functions. For instance, in the example in : Node src sends a UDP packet as follows: (2001:db8:src::1, 2001:db8:dst::1, NH = UDP)(UDP payload). Node R1, which is an SRv6-capable Redundancy node, identifies the flow to which the packet belongs. As replication is defined by the Redundancy Policy for the given flow, R1 performs the replication action and intends to send the packet to the next R-nodes (E5 and R2). These nodes are reachable via SRv6, so R1 performs H.Encaps.R(.Red) on the replicas with a path-specific SRH. The argument part of the End.R SID contains the FID and the SeqNum. Specifically, one replica is sent on Link1 towards E5 as: (2001:db8:L:1::, 2001:db8:K:3:X51::) (2001:db8:K:5:P:arg::, 2001:db8:K:3:X51::, SL=1, NH = IPv6) (2001:db8:src::1, 2001:db8:dst::1, NH = UDP)(UDP payload). The other replica is sent on Link2 towards R2 as: (2001:db8:L:1::, 2001:db8:K:2:P:arg::, NH = IPv6) (2001:db8:src::1, 2001:db8:dst::1, NH = UDP)(UDP payload). Node N3, which is an SRv6-capable node, performs the standard SRH processing. Specifically, it executes the End.X behavior indicated by the 2001:db8:K:3:X51:: SID and forwards the packet on Link3 to node E5. Node n4, which is a non-SRv6-capable node, performs the standard IPv6 processing. Specifically, it forwards the UDP packet based on DA 2001:db8:K:2:P:arg:: in the IPv6 header towards node R2. Node R2, which is an SRv6-capable Redundancy node, identifies the packet as targeted to the local Redundancy function. R2 performs the decapsulation and forwards the exposed payload and the ARG part to the redundancy functionality. The redundancy function identifies the flow to which the packet belongs. As replication is defined by the Redundancy Policy for the given flow, R2 performs the replication action and intends to send the packet to the next redundancy nodes (E5 and E6). These nodes are reachable via SRv6, so R2 performs H.Encaps.R.Red on the replicas and no a path-specific SRH is needed. The argument part of the End.R SID contains the FID and the SeqNum. Specifically, one replica is sent on Link7 towards E5 as: (2001:db8:L:2::, 2001:db8:K:5:P:arg::, NH = IPv6) (2001:db8:src::1, 2001:db8:dst::1, NH = UDP)(UDP payload). The other replica is sent on Link8 towards E6 as: (2001:db8:L:2::, 2001:db8:K:6:P:arg::, NH = IPv6) (2001:db8:src::1, 2001:db8:dst::1, NH = UDP)(UDP payload). Node E5, which is an SRv6-capable Redundancy node, identifies the packets as targeted to the local redundancy function. E5 performs the decapsulation and forwards the payload and the ARG part to the redundancy functionality. The redundancy function identifies the flow to which the packet belongs. As elimination is defined by the Redundancy Policy for the given flow, the elimination action is performed on the packets received over Link3 and Link7. E5 intends to send the packet to the next redundancy node (E6), which is reachable via SRv6, so E5 performs H.Encaps.R.Red and no a path-specific SRH is needed. The argument part of the End.R SID contains the FID and the SeqNum. Specifically, the replica received first is sent on Link6 towards E6 as: (2001:db8:L:5::, 2001:db8:K:6:P:arg::, NH = IPv6) (2001:db8:src::1, 2001:db8:dst::1, NH = UDP)(UDP payload). Node E6, which is an SRv6-capable redundancy node, identifies the packets as targeted to the local redundancy function. It performs the decapsulation and forwards the payload and the ARG part to the redundancy functionality. The redundancy function identifies the flow to which the packet belongs. As elimination is defined by the Redundancy Policy for the given flow, the elimination action is performed on the packets received over Link6 and Link8. E6 is the last redundancy node, so after the redundancy function it sends the UDP packet towards the destination. Specifically, the replica received first is sent towards the destination as: (2001:db8:src::1, 2001:db8:dst::1, NH = UDP)(UDP payload). The example topology shown in is constructed to show the usage of RSID. Note that any of the links can be replaced with an SRv6 network segment. The principles described above are applicable to more complex network topologies as well.