SRv6 for Redundancy Protection

2.1. Requirements Language

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.2. Terminology and Conventions

SR: Segment Routing¶

SRv6: Segment Routing over IPv6¶

SID: Segment Identifier¶

BSID: Binding SID¶

RSID: Redundancy SID¶

R-node: Redundancy node participating in the service protection.¶

Rep node: R-node doing replication. A network element that replicates incoming packets for parallel delivery.¶

Elm node: R-node doing elimination. A network element that eliminates duplicates to forward a single copy.¶

RedInst: Redundancy instance, flow-specific redundancy function on the R-node.¶

FID: Flow Identification¶

SeqNum: Sequence Number¶

3.1. Redundancy Node Concept

Redundancy 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 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 flow related redundancy instance (RedInst) has flow specific states (e.g., action type, action order, ingress/egress member flow specific parameters, identifiers).¶

3.2. RSID and Meta Data to Support Redundancy Protection

To support the redundancy protection function, flow identification (FID) and sequence number (SeqNum) information are added to the member flow packets in the RSID. They are used at downstream R-nodes when their redundancy actions are executed.¶

FID identifies one specific member flow on an R-Node and has local significance. Allocation methods and signalling of FID values are out of scope in 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 controller and R-nodes. FID MUST be included in the RSID.¶

SeqNum distinguishes the packets within a flow by specifying the order of packets. Unlike the FID, which remains constant for all packet in a given member flow, the SeqNum changes with each packet. SeqNum MUST be included in the RSID.¶

The explicit format of Redundancy SID (RSID) is network addressing design specific. Redundancy specific parameters are encoded as follows:¶

• LOC: specifies the redundancy node (same allocation rule applies as for any SRv6-enabled node).¶

• FUNCT: a single value represents the redundancy function of a redundancy node.¶

• ARG: Contains the FID and the SeqNum parameters.¶

RSID MUST support containing a FID of 20 bits.¶

RSID MUST support containing a SeqNum of 16 bits.¶

The ARG part of the RSID MUST contain first the FID immediatelly followed by the SeqNum. Remaining LSB of the ARG part MUST be filled with zeros.¶

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 maximal size SeqNum field (28-bit) defined for DetNet flows in [RFC8964].¶

Note: if Function=RSID, Arg=0 is also a meaningful value and does not refer to the lack of arguments. It is meaning that the packet belongs to a flow having FID=0 and its SeqNum=0.¶

Note2: 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) or by excluding those bits from ECMP hashing.¶

3.3. Redundancy Policy

A Redundancy SID (RSID) MUST have a related Redundancy Policy. The Redundancy Policy MUST contain entries for each member flow for which the R-node provides redundancy protection. An entry MUST contain the flow specific actions and their parameters.¶

The following summarizes the information that is needed in the Redundancy Policy entries:¶

• Ingress member flow(s) identification information (e.g., FID).¶

• Redundancy action parameters (e.g., Action type, RedInst, SeqNum length, Algorithm, Action pipeline).¶

• 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 the last R-nodes needs additional information:¶

• Ingress flow matching information on the first R-node (e.g., 5-tuple of the served flow).¶

• Egress forwarding information on the last R-node (e.g., which VRF/VSI to use for forwarding).¶

Various options for ingress flow matching are defined for example in [RFC8939]. They can be used on the first R-node.¶

Using SR Policy desribed in [RFC9256] for the definition of an egress member flow redundancy path is out of scope here and left for further study.¶

3.4. Redundancy Protection Scenario Example

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

           |                                              |
           |<--------------- SRv6 Domain ---------------->|
           |                                              |
           |                    +-----+                   |
           |              +-----+  R3 +-----+             |
           |              |     +-----+     |             |
        +-----+        +--+--+           +--+--+       +-----+
 -------+  R1 +--------+ Rep |           | Elm +-------+  R2 +-------
        +-----+        +--+--+           +--+--+       +-----+
                          |     +-----+     |
                          +-----+  R4 +-----+
                                +-----+

Figure 1: Example topology¶

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 Rep node (an R-node configured for replication), each packet is replicated into two copies.¶

2.2) Meta data information including flow identification (FID) and sequence number (SeqNum) are added to the copies. FID is used to identify the specific flow (and the related RedInst) on the downstream R-node, and SeqNum distinguishes the packet sequence within a flow.¶

2.3) Each copy of the packet is encapsulated with a new path specific segment list, which represents different forwarding paths towards the downstream R-node. One copy is forwarded over R3 and the other over R4. The path is provisioned for example by a controller.¶

3) The multiple replicas go through different paths until they reach the next R-node i.e., the Elm node in this example. The Elm node is configured with an elimination action for the flow. The first received copy of each packet is forwarded, and the redundant packets are eliminated. Furthermore, the redundancy policy entry of the flow specifies that the non-eliminated packets are forwarded without the meta data 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.¶

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 to 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 [RFC9550].¶

Note: the jitter caused by random packet loss can be minimized, if the protection paths have similar path forwarding delay.¶

4.1. Redundancy Segment Endpoint Behavior

This section describes the Redundancy specific behaviors that can be associated with a SID.¶

+-------------+-------------------------------------------------------+
| End.R       | Endpoint with decapsulation and Redundancy Processing |
+-------------+-------------------------------------------------------+

Redundancy Segment is the identifier of packets on which service protection needs to be executed on the redundancy node. It has associated Redundancy Policy(s), instantiation of which provides service protection action(s). The use of Redundancy Segment triggers the Redundancy Policy instantiation on the redundancy node.¶

Redundancy Segment is associated with service instructions, indicating the following operations:¶

• Steers the packet into the corresponding redundancy instance.¶

• Encapsulates flow identification and sequence number in SRv6 packets.¶

• Packet replication/elimination and segment encapsulation/decapsulation based on the information of the flow-specific redundancy policy entry, e.g., the number of replication copies, an ordered list of segments with a topological instruction.¶

In this document, a new behavior End.R for Redundancy Segment is defined. An instance of a redundancy SID is associated with a redundancy policy B and a source address A. In the following description, End.R behavior is specified with the encapsulation mode.¶

For redundancy protection processing, two arguments are needed:¶

1. Flow-ID (FID): defines which flow the packet belongs to (what is used to determine which Redundancy instance has to be used on a node).¶

2. Sequence Number (SeqNum): defines the sequencing information, it is created at the first Redundancy node and used by replication and elimination functionalities.¶

Note: DetNet has defined a service protection for the DetNet service sub-layer [RFC8655]. The packet replication and elimination service protection method was defined for DetNet MPLS data plane using 20 bits for FID and the following SeqNum sizes: 0/16/28 bits [RFC8964].¶

In order to eliminate the redundant packets of a flow, the elimination node utilizes sequence number to evaluate the redundant status of a packet. The mechanism used for elimination is implementation-specific and outside the scope of this document.¶

R-nodes are interconnected by SRv6 tunnels used to encapsulate the protected flow and they hold flow states regarding the served traffic flow(s). From the segment routing architecture perspective [RFC8402] R-nodes are ingresss 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.¶

As elimination node needs to maintain the state of served flows, a centralized controller MUST have a knowledge of elimination nodes capability. It MUST NOT provision the redundancy policy to a redundancy node when the computation result goes beyond the flow recovery capability of the elimination node. The capability advertisement is outside the scope of this document.¶

The Redundancy SID (RSID) MUST be the last segment in an SR Policy and it is associated with the Redundancy functionality.¶

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:¶

S01. When an SRH is processed {
S02.  If (Segments Left != 0) {
S03.   Send an ICMP Parameter Problem message to the Source Address
            with Code 0 (Erroneous header field encountered),
            and Pointer set to the Segments Left field,
            interrupt packet processing and discard the packet
S04.  }
S05.  Proceed to process the next header in the packet
S06. }

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

S01. If (Upper-Layer header type ==
       ( 4(IPv4) OR 41(IPv6) OR 143(Ethernet) )
           {
S02.   Extract the ARG part of the SID
S03.   Remove the outer IPv6 header with all its extension headers
S04.   Forward the exposed payload, type and the ARG part to the
       Redundancy functionality
S05. } Else {
S06.    Process the Upper Layer Header
S07. }

Upper Layer Header processing of End.R SID is same as defined in Section 4.1.1 of [RFC8986].¶

7.1. Installation and Initial Setup

Redundancy Protection should operate with reasonable defaults:¶

• Redundancy Protection function: R-nodes should default to pass-through mode 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., supporting more bits for advanced scenarios.¶

• Application: Redundancy policies should not be applied until explicitly provisioned by a management entity or control plane, preventing unintended replication or elimination of traffic.¶

Operators must be able to verify that configured defaults match actual running configurations for troubleshooting and consistency assurance.¶

7.2. Migration Path and Deployment

Redundancy Protection integrates incrementally into existing SRv6 networks:¶

• Coexistence: R-nodes support both Redundancy Endpoint behavior (End.R) and existing SRv6 behaviors. Traffic not served by the Redundancy Protection function is unaffected.¶

• Staged Deployment: Operators may deploy to a subset of nodes or flows before network-wide adoption.¶

• Configuration Rollback: Operators should have the ability to disable redundancy policies on R-nodes without disrupting other services, enabling rapid rollback if issues arise during deployment.¶

7.3. Protocol Dependencies and Network Impact

Dependencies: All R-nodes must support SRv6. Accurate time synchronization (i.e., NTP) is recommended. External systems (PCE, SDN controllers) are expected to compute (disjoint) protection paths.¶

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 must ensure flow count does not exceed R-node capacity.¶

• ECMP and Load Balancing Impact: Per-packet ARG changes in RSID may alter ECMP hashing. The impact can be mitigated by excluding ARG bits from hash computation or using node-specific SID(s) before RSID.¶

• Fast Reroute (FRR): Redundancy Protection can coexist with other protection mechanisms. Operators should carefully consider the interaction to avoid unnecessary resource usage.¶

Traffic Pattern Changes: Using Redundancy Protection assumes sufficient path diversity. Monitoring should account for expected duplication patterns to avoid false security alarms.¶

7.4. Security Operations

Security operation related to redundancy proection functionality are:¶

• Indicators of Compromise: Security operators must account for simultaneous traffic on multiple paths. Sequence number analysis can detect replay attacks or anomalies. Implemented algorithms on R-nodes should provide counters to allow such an analysis.¶

• Logging: Replication/Elimination events, policy changes, and error conditions must be logged with timestamps for audit trails.¶

• Management Access Control: Use strong authentication, encrypted transport (TLS), and role-based access control (RBAC) for all management interfaces.¶

7.5. Verifying Correct Operation

Operators should verify redundancy protection through several mechanisms:¶

• Redundancy Policy Status: Query active redundancy policy entries and served flows on each R-node is needed.¶

• 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 e.g., for troubleshooting.¶

7.6. Management Information and Data Models

The following manageable entities are described: Redundancy Node (R-node), Redundancy SID (RSID), Redundancy Policy, and Redundancy Instance (having per-flow state).¶

Standardized Technologies used for Redundancy Protection:¶

• YANG-based Management: Recommended for configuration and state via NETCONF [RFC6241] or RESTCONF [RFC8040]. This needs further work.¶

• Syslog: For operational events and error logging [RFC5424].¶

• IPFIX: For flow-level statistics export [RFC7011].¶

YANG Data Model: A Device Model should distinguish between configuration data (policies, flow criteria), operational state (active flows, sequence numbers), and statistics (counters, performance metrics). The model must enforce valid SeqNum sizes and FID ranges and express relationships between policies, flows, and member flows.¶

7.7. Fault and Configuration Management

Fault Management:¶

• Monitor liveness via CFM tools and/or detecting packet arrival on protection paths.¶

• Track replication/elimination rates and sequence number gaps to identify path failures.¶

• Count malformed RSIDs to detect configuration errors.¶

• Generate alerts when approaching flow capacity limits.¶

Configuration Management:¶

• 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.¶

7.8. Performance and Accounting Management

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.¶

7.9. Tooling Considerations

Operators should 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 should focus only on functions existing tools cannot provide (e.g., specialized path computation and validation).¶

8.1. Packet Duplication

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 merging nodes. The amplification can also magnify denial-of-service attacks if unauthorized traffic reaches replication nodes. Amplification can also achieved by the attacker by blocking the elimination.¶

The use of redundancy protection should be restricted to a trusted SR domain with controlled flows, i.e., rate-limiting and flow admission control at the ingress is employed. Redundancy protection should be provisioned via authenticated and authorized controllers (e.g., PCEP with TLS).¶

8.2. Sequence Number Spoofing

The Elm 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 also can 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 algorithm used by the elimination instance, however algorithm are out of scope in this document.¶

8.3. Information Disclosure

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

8.4. State Exhaustion at Redundancy Node

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. Impact of resource exhaustion is dependent on the implemented method, however algorithms of elimination are out of scope of this document.¶

12.1. Normative References

[I-D.ietf-spring-srv6-security]

Buraglio, N., Mizrahi, T., tongtian124, Contreras, L. M., and F. Gont, "Segment Routing IPv6 Security Considerations", Work in Progress, Internet-Draft, draft-ietf-spring-srv6-security-15, 24 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-security-15>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8402]

Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8655]

Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.

[RFC8754]

Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.

[RFC8939]

Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, <https://www.rfc-editor.org/info/rfc8939>.

[RFC8964]

Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, "Deterministic Networking (DetNet) Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 2021, <https://www.rfc-editor.org/info/rfc8964>.

[RFC8986]

Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.

12.2. Informative References

[IEEE8021CB]

IEEE, "IEEE Standard for Local and metropolitan area networks--Frame Replication and Elimination for Reliability", IEEE 802.1CB-2017, DOI 10.1109/IEEESTD.2017.8091139, October 2017, <https://standards.ieee.org/standard/802_1CB-2017.html>.

[RFC5424]

Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <https://www.rfc-editor.org/info/rfc5424>.

[RFC6241]

Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC7011]

Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.

[RFC8040]

Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC9256]

Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.

[RFC9550]

Varga, B., Ed., Farkas, J., Kehrer, S., and T. Heer, "Deterministic Networking (DetNet): Packet Ordering Function", RFC 9550, DOI 10.17487/RFC9550, March 2024, <https://www.rfc-editor.org/info/rfc9550>.