SPRING Working Group X. Geng Internet-Draft M. Chen Intended status: Standards Track F. Yang Expires: August 26, 2021 Huawei Technologies February 22, 2021 Segment Routing for Redundancy Protection draft-geng-spring-sr-redundancy-protection-01 Abstract Redundancy protection is one of the mechanisms to achieve service protection, following the principle of PREOF (Packet Replication/Elimination/Ordering Function). To empower the Segment Routing with the capability of redundancy protection, two types of Segment including Redundancy Segment and Merging Segment are introduced. The instantiation of Redundancy and Merging Segments can be applied to both segment routing over MPLS (SR-MPLS) and segment routing over IPv6 (SRv6). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 26, 2021. Geng, et al. Expires August 26, 2021 [Page 1] Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021 Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 3. Redundancy Protection in Segment Routing Scenario . . . . . . 4 4. Segment to Support Redundancy Protection . . . . . . . . . . 5 4.1. Redundancy Segment . . . . . . . . . . . . . . . . . . . 5 4.1.1. SR over MPLS . . . . . . . . . . . . . . . . . . . . 5 4.1.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Alternative Option of Redundancy Segment . . . . . . . . 6 4.3. Merging Segment . . . . . . . . . . . . . . . . . . . . . 6 4.3.1. SR over MPLS . . . . . . . . . . . . . . . . . . . . 7 4.3.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Meta Data to Support Redundancy Protection . . . . . . . . . 7 6. Segment Routing Policy to Support Redundancy Protection . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Service protection defined in [RFC8655] is initially required from the use cases in a variety of industries described in [RFC8578]. Together with other two techniques Resource allocation and Explicit routes, it targets to provide the deterministic flow transmission. Meanwhile, with the emerge of Cloud VR, Cloud Game, High-Definition Video applications running in the Internet, SLA (Service Level Agreement) guarantee becomes an important issue which requires new technologies and solutions for network. Geng, et al. Expires August 26, 2021 [Page 2] Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021 Redundancy Protection is one of the mechanisms to achieve service protection, following the principle of PREOF (Packet Replication/ Elimination/Ordering Function) defined in [RFC8655]. Specifically, replicates the packets of flows into two or more copies, transports different copies through different paths in parallel, eliminates and orders the packets at end to provide redundancy protection. Segment Routing (SR) leverages the source routing paradigm. An ingress node steers a packet through an ordered list of instructions, called "segments". A segment can be associated to an arbitrary processing of the packet in the node identified by the segment. This document extends the capabilities in SR paradigm to support the redundancy protection, including the definitions of new Segments and a variation of Segment Routing Policy. The new mechanism applies equally to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). 2. Terminology and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [I-D.ietf-spring-srv6-network-programming] and[RFC2119]. Redundancy Node: the start point of redundancy protection, which is a network device that could implement packet replication. Merging Node: the end point of redundancy protection, which is a network node that could implement packet elimination and ordering (optionally). Redundancy Policy: an extended SR policy which includes more than one active segment lists to support redundancy protection. Flow Identification: information in SR data service to indicate one flow. Sequence Number: information in SR data service to indicate the packet sequence of one flow. Editor's Note: Similar mechanism is defined as "Service Protection" in the [RFC8655]. In this document, we define a new term "Redundancy Protection" to distinguish with other service protection method. Some of the terms are similar as [RFC8655]. Geng, et al. Expires August 26, 2021 [Page 3] Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021 3. Redundancy Protection in Segment Routing Scenario | | |<-------------- SR Domain ------------->| | | | +-----+R3+-----+ | +---+ +-+-+ +-+-+ +---+ -------|R1 |--------|Red| |Mer|--------|R2 |------- +---+ +-+-+ +-+-+ +---+ +-----+R4+-----+ Figure 1: Example Scenario of Redundancy Protection in SR Domain This figure shows an example of redundancy protection used in SR domain. When a flow is sent into SR domain, the process is: 1) R1 receives the traffic flow and encapsulates packets with a list of segments, which is instantiated as a stack of MPLS labels or an ordered list of SRv6 SIDs. The final destination of packets is R2. R1, R2, R3, R4, Red and Mer are SR-capable nodes. 2) When the packet flow arrives in Red node, known as Redundancy Node, one flow is replicated into two copies. Each copy of flow is encapsulated with different newly-defined list of SIDs, and the last SID is always pointed to the SID of Mer node, known as Merging Node. 3) Packet is encapsulated with the information of flow identification and sequence number. Flow identification identifies the specific flow, and sequence number distinguishes the packet sequence of a flow. 4) When the original flow and replicated flow go through different paths till Mer node, the first received packet of the flow is transmitted from Merging Node to R2, and the redundant packets are eliminated. 5) When there is any failures happened in one path, the service continues to deliver through the other path without break. 6) Sometimes, the packet will arrive out of order because of redundancy protection, the function of reordering may be necessary in the Merging Node. In this example, service protection is supported by utilizing two packet flows transmitted over two forwarding paths. For a unidirectional flow, Red node supports replication function, and Mer node supports elimination and ordering functions. Geng, et al. Expires August 26, 2021 [Page 4] Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021 4. Segment to Support Redundancy Protection To achieve the Packet Replication/Elimination/Ordering Function, Redundancy Segment and Merging Segment are introduced. 4.1. Redundancy Segment Redundancy Segment is associated with a Redundancy Policy on redundancy node. Redundancy segment is instantiated with service instructions, indicating the following operations: o Steering the packet into the corresponding redundancy policy o Packet replication and encapsulation based on the redundancy policy, e.g., the number of replication copies o Encapsulate the packet with necessary meta data (e.g., flow identification, sequence number) if it is not included in the original packet 4.1.1. SR over MPLS In the case of SR over MPLS, when the Active Segment is a redundancy segment, a redundancy policy is associated. According to the information of candidate paths in redundancy policy, packets are replicated and a CONTINUE operation is applied. Incoming redundancy segment is swapped with different Adj-SIDs to forward the packet in different paths. 4.1.2. SRv6 In the case of SRv6, a new behavior End.R for redundancy segment is defined. 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: Geng, et al. Expires August 26, 2021 [Page 5] Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021 S01. When an SRH is processed { S02. If (Segments Left>0) { S03. Create two headers IPv6+SRH-1 and IPv6+SRH-2 S04. Insert different policy-instructed segment lists into SRH-1 and SRH-2 S05. Add flow identification and sequence number to SRH-1 and SRH-2 S06. Remove the incoming outer IPv6+SRH header S07. Create a duplication of the incoming packet payload S08. Encapsulate the original packet with IPv6+SRH-1 header S09. Encapsulate the duplicate packet with IPv6+SRH-2 header S10. Set IPv6 SA as the local address of this node S11. Set IPv6 DA of IPv6+SRH-1 to the first segment of SRv6 Policy in SRH-1 segment list S12. Set IPv6 DA of IPv6+SRH-2 to the first segment of SRv6 Policy in SRH-2 segment list S13. } S14. ELSE { S15. Drop the packet S16. } Note that, redundancy node decapsulates the original IPv6 and SRH header, and encapsulates another newly created IPv6 and SRH header to the packet payload. In this case, it would not bring extra header insertion risk to IPv6. 4.2. Alternative Option of Redundancy Segment Redundancy segment can also be a variation of Binding SID (BSID). Different paths between redundancy node and merging node can be encapsulated or inserted by using the End.B6.Encaps and End.B6.Insert behavior of BSID. In this way, headend can have a complete segment list in SRH to indicate the path from R1 to R2 in Figure 1. Take End.B6.Encaps as an example. The behavior of redundancy segment includes replicating packets into different copies, pushing new IPv6 and SRH header to packets, and newly adding or copying the information like flow identification and sequence number from original packet. By using the BSID and End.B6.Encaps behavior, the IPv6 header insertion issue can be avoided too. 4.3. Merging Segment Merging Segment is associated with service instructions, indicates the following operations: o Packet merging and elimination: forward the first received packets and eliminate the redundant packets o Packet ordering(optional): reorder the packets if the packet arrives out of order Geng, et al. Expires August 26, 2021 [Page 6] Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021 4.3.1. SR over MPLS In the case of SR over MPLS, when the Active Segment is a Merging Segment and this packet is not a redundant packet, a CONTINUE operation is applied. Incoming merging segment is swapped with Prefix-SID of destination address. The redundancy of packets is determined by other techniques, and is not within the scope of this document. 4.3.2. SRv6 In the case of SRv6, a new behavior End.M for Merging Segment is defined. 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 Merging SID, N does: S01. When an SRH is processed { S02. If (Segments Left>0) { S03. Acquire the sequence number of received packet and lookup it in a local table S04. If (the sequence number is not existed in table ) { S05. Store the packet and record the sequence number in table S06. Decrement IPv6 Hop Limit by 1 S07. Decrement Segments Left by 1 S08. Update IPv6 DA with Segment List[Segments Left] S09. Submit the packet to the egress IPv6 FIB lookup and transmit S10. } S11. ELSE { S12. Drop the packet S13. } S14. } S15. } 5. Meta Data to Support Redundancy Protection To support the redundancy protection function, Flow Identification and Sequence Number are required. Flow identification identifies the specific flow with target of redundancy protection. Sequence number distinguishes the packets within a flow by specifying the order of packets. The information is carried in the service packets along the different paths to merging node. Merging node removes flow identifier and sequence number once the elimination and ordering is accomplished. Flow identification and sequence number can be defined as MPLS label in SR over MPLS data plane, or is extended in SRH in SRv6 data plane. In case of SRv6, [I-D.geng-6man-redundancy-protection-srh] specifies the options of supporting flow identification and sequence number on SRH extensions. Geng, et al. Expires August 26, 2021 [Page 7] Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021 Note that, the flow identification and sequence number can be added either at the headend of the path, or at the redundancy node. In the former case, the information is managed and assigned from the SDN controller, and carried in the packet along the entire forwarding path in SR domain. In the latter case, redundancy node assigns the values of flow identification and sequence number itself, and this information is only used between redundancy node and merging node. 6. Segment Routing Policy to Support Redundancy Protection Redundancy Policy is a variation of SR Policy, and is identified through the tuple . Redundancy node is specified as IPv4/IPv6 address of the headend, which is able to do packet replication. Merging node is specified as IPv4/IPv6 address of the endpoint, which is able to do packet elimination and ordering (optional). Redundancy ID could be a specified value of "color" define in section 2.1 of [I-D.ietf-spring-segment-routing-policy], which indicates the SR policy as a redundancy policy. Redundancy ID could also be used to distinguish different redundancy policies sharing the same redundancy node and merging node. Redundancy Policy extends SR policy to include more than one ordered lists of segments between redundancy node and merging node to steer the same flow through different paths in SR domain. In Redundancy Policy, Redundancy Segment MUST be specified, and the last segment of each ordered list of segments SHOULD be Merging Segment. 7. IANA Considerations This document requires registration of End.R behavior and End.M behavior in "SRv6 Endpoint Behaviors" sub-registry of "Segment Routing Parameters" registry. 8. Security Considerations TBD 9. Acknowledgements The authors would like to thank Bruno Decraene, Ron Bonica, and James Guichard for their valuable comments. 10. References Geng, et al. Expires August 26, 2021 [Page 8] Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021 10.1. Normative References [I-D.ietf-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "SRv6 Network Programming", draft-ietf-spring-srv6-network-programming-28 (work in progress), December 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 10.2. Informative References [I-D.geng-6man-redundancy-protection-srh] Geng, X., M. Chen, and F. Yang, "SRH Extension for Redundancy Protection", draft-geng-6man-redundancy-protection- srh-00 (work in progress), February 2021. [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", draft- ietf-spring-segment-routing-policy-09 (work in progress), November 2020. [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", RFC 8578, DOI 10.17487/RFC8578, May 2019, . [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . [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, . Authors' Addresses Xuesong Geng Huawei Technologies Beijing China Email: gengxuesong@huawei.com Geng, et al. Expires August 26, 2021 [Page 9] Internet-Draft draft-geng-spring-sr-redundancy-protection February 2021 Mach(Guoyi) Chen Huawei Technologies Beijing China Email: mach.chen@huawei.com Fan Yang Huawei Technologies Beijing China Email: shirley.yangfan@huawei.com Geng, et al. Expires August 26, 2021 [Page 10]