idnits 2.17.1 draft-geng-spring-sr-redundancy-protection-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 30 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 22, 2021) is 1151 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8754' is defined on line 373, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group X. Geng 3 Internet-Draft M. Chen 4 Intended status: Standards Track F. Yang 5 Expires: August 26, 2021 Huawei Technologies 6 February 22, 2021 8 Segment Routing for Redundancy Protection 9 draft-geng-spring-sr-redundancy-protection-02 11 Abstract 13 Redundancy protection is one of the mechanisms to achieve service 14 protection, following the principle of PREOF (Packet 15 Replication/Elimination/Ordering Function). To empower the Segment 16 Routing with the capability of redundancy protection, two types of 17 Segment including Redundancy Segment and Merging Segment are 18 introduced. The instantiation of Redundancy and Merging Segments can 19 be applied to both segment routing over MPLS (SR-MPLS) and segment 20 routing over IPv6 (SRv6). 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in . 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 26, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 64 3. Redundancy Protection in Segment Routing Scenario . . . . . . 4 65 4. Segment to Support Redundancy Protection . . . . . . . . . . 5 66 4.1. Redundancy Segment . . . . . . . . . . . . . . . . . . . 5 67 4.1.1. SR over MPLS . . . . . . . . . . . . . . . . . . . . 5 68 4.1.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.2. Merging Segment . . . . . . . . . . . . . . . . . . . . . 6 70 4.2.1. SR over MPLS . . . . . . . . . . . . . . . . . . . . 6 71 4.2.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Meta Data to Support Redundancy Protection . . . . . . . . . 7 73 6. Segment Routing Policy to Support Redundancy Protection . . . 7 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 10.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 Service protection defined in [RFC8655] is initially required from 85 the use cases in a variety of industries described in [RFC8578]. 86 Together with other two techniques Resource allocation and Explicit 87 routes, it targets to provide the deterministic flow transmission. 88 Meanwhile, with the emerge of Cloud VR, Cloud Game, High-Definition 89 Video applications running in the Internet, SLA (Service Level 90 Agreement) guarantee becomes an important issue which requires new 91 technologies and solutions for network. 93 Redundancy Protection is one of the mechanisms to achieve service 94 protection, following the principle of PREOF (Packet Replication/ 95 Elimination/Ordering Function) defined in [RFC8655]. Specifically, 96 replicates the packets of flows into two or more copies, transports 97 different copies through different paths in parallel, eliminates and 98 orders the packets at end to provide redundancy protection. 100 Segment Routing (SR) leverages the source routing paradigm. An 101 ingress node steers a packet through an ordered list of instructions, 102 called "segments". A segment can be associated to an arbitrary 103 processing of the packet in the node identified by the segment. 105 This document extends the capabilities in SR paradigm to support the 106 redundancy protection, including the definitions of new Segments and 107 a variation of Segment Routing Policy. The new mechanism applies 108 equally to both segment routing with MPLS data plane (SR-MPLS) and 109 segment routing with IPv6 data plane (SRv6). 111 2. Terminology and Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in 116 [I-D.ietf-spring-srv6-network-programming] and[RFC2119]. 118 Redundancy Node: the start point of redundancy protection, which is a 119 network device that could implement packet replication. 121 Merging Node: the end point of redundancy protection, which is a 122 network node that could implement packet elimination and ordering 123 (optionally). 125 Redundancy Policy: an extended SR policy which includes more than one 126 active segment lists to support redundancy protection. 128 Flow Identification: information in SR data service to indicate one 129 flow. 131 Sequence Number: information in SR data service to indicate the 132 packet sequence of one flow. 134 Editor's Note: Similar mechanism is defined as "Service Protection" 135 in the [RFC8655]. In this document, we define a new term "Redundancy 136 Protection" to distinguish with other service protection method. 137 Some of the terms are similar as [RFC8655]. 139 3. Redundancy Protection in Segment Routing Scenario 141 | | 142 |<-------------- SR Domain ------------->| 143 | | 144 | +-----+R3+-----+ | 145 +---+ +-+-+ +-+-+ +---+ 146 -------|R1 |--------|Red| |Mer|--------|R2 |------- 147 +---+ +-+-+ +-+-+ +---+ 148 +-----+R4+-----+ 150 Figure 1: Example Scenario of Redundancy Protection in SR Domain 152 This figure shows an example of redundancy protection used in SR 153 domain. When a flow is sent into SR domain, the process is: 155 1) R1 receives the traffic flow and encapsulates packets with a list 156 of segments destined to R2, which is instantiated as a stack of MPLS 157 labels or an ordered list of SRv6 SIDs. R1, R2, R3, R4, Red and Mer 158 are SR-capable nodes. 160 2) R1 encapsulates the flow identification and sequence number to the 161 packets. Flow identification identifies the specific flow, and 162 sequence number distinguishes the packet sequence of a flow. 164 3) When the packet flow arrives in Red node, known as Redundancy 165 Node, one flow is replicated into two copies. Each copy of flow is 166 encapsulated with different newly-defined list of SIDs, and the last 167 SID is always pointed to the SID of Mer node, known as Merging Node. 169 4) When the original flow and replicated flow go through different 170 paths till Mer node, the first received packet of the flow is 171 transmitted from Merging Node to R2, and the redundant packets are 172 eliminated. 174 5) When there is any failures happened in one path, the service 175 continues to deliver through the other path without break. 177 6) Sometimes, the packet will arrive out of order because of 178 redundancy protection, the function of reordering may be necessary in 179 the Merging Node. 181 In this example, service protection is supported by utilizing two 182 packet flows transmitted over two forwarding paths. For a 183 unidirectional flow, Red node supports replication function, and Mer 184 node supports elimination and ordering functions. 186 4. Segment to Support Redundancy Protection 188 To achieve the Packet Replication/Elimination/Ordering Function, 189 Redundancy Segment and Merging Segment are introduced. 191 4.1. Redundancy Segment 193 Redundancy Segment is a variation of Binding SID, and associated with 194 a Redundancy Policy on redundancy node. Redundancy segment is 195 associated with service instructions, indicating the following 196 operations: 198 o Steering the packet into the corresponding redundancy policy 200 o Packet replication and encapsulation based on the redundancy 201 policy, e.g., the number of replication copies 203 4.1.1. SR over MPLS 205 In the case of SR over MPLS, when the Active Segment is a Redundancy 206 Segment, a redundancy policy is associated. According to the 207 information of candidate paths in redundancy policy, packets are 208 replicated, and the Incoming redundancy segment is swapped with 209 different stacks of MPLS labels to forward the packet in different 210 paths. 212 4.1.2. SRv6 214 In the case of SRv6, a new behavior End.R for Redundancy Segment is 215 defined. In the following description, End.R behavior is specified 216 in the encapsulation mode. The End.R behavior in the insertion mode 217 is for further study. 219 When an SRv6-capable node (N) receives an IPv6 packet whose 220 destination address matches a local IPv6 address instantiated as an 221 SRv6 SID (S), and S is a Redundancy SID, N does: 223 S01. When an SRH is processed { 224 S02. If (Segments Left>0) { 225 S03. Decrement IPv6 Hop Limit by 1 226 S04. Decrement Segments Left by 1 227 S05. Update IPv6 DA with Segment List[Segments Left] 228 S06. Create two new IPv6 headers with SRH-1 and SRH-2 respectively 229 S07. Insert different policy-instructed segment lists into SRH-1 and SRH-2 230 S08. Create a duplication of the incoming packet 231 S09. Encapsulate the original packet with the new IPv6+SRH-1 header 232 S10. Encapsulate the duplicate packet with the new IPv6+SRH-2 header 233 S11. Set IPv6 SA as the local address of this node 234 S12. Set IPv6 DA of IPv6+SRH-1 to the first segment of SRH-1 SL 235 S13. Set IPv6 DA of IPv6+SRH-2 to the first segment of SRH-2 SL 236 S14. Copy flow identification and sequence number from current SRH to SRH-1 237 S15. Copy flow identification and sequence number from current SRH to SRH-2 238 S16. Set the outer Payload Length, Traffic Class, Flow Label,Hop Limit and Next-Header fields 239 S17. Submit the packet to the egress IPv6 FIB lookup and transmit 240 S18. } 241 S19. ELSE { 242 S20. Drop the packet 243 S21. } 244 S22. } 246 4.2. Merging Segment 248 Merging Segment is associated with service instructions, indicates 249 the following operations: 251 o Packet merging and elimination: forward the first received packets 252 and eliminate the redundant packets 254 o Packet ordering(optional): reorder the packets if the packet 255 arrives out of order 257 4.2.1. SR over MPLS 259 In the case of SR over MPLS, when the Active Segment is a Merging 260 Segment and this packet is not a redundant packet, a CONTINUE 261 operation is applied. Incoming merging segment is swapped with next 262 segment. 264 4.2.2. SRv6 266 In the case of SRv6, a new behavior End.M for Merging Segment is 267 defined. 269 When an SRv6-capable node (N) receives an IPv6 packet whose 270 destination address matches a local IPv6 address instantiated as an 271 SRv6 SID (S), and S is a Merging SID, N does: 273 S01. When an SRH is processed { 274 S02. If (Segments Left==0) { 275 S03. Acquire the sequence number of received packet and lookup it in a local table 276 S04. If (the sequence number is not existed in table ) { 277 S05. Store the packet and record the sequence number in table 278 S06. Remove the outer IPv6+SRH header 279 S07. Decrement IPv6 Hop Limit by 1 in inner SRH 280 S08. Decrement Segments Left by 1 in inner SRH 281 S09. Update IPv6 DA with Segment List[Segments Left] in inner SRH 282 S10. Submit the packet to the egress IPv6 FIB lookup and transmit 283 S11. } 284 S12. ELSE { 285 S13. Drop the packet 286 S14. } 287 S15. } 288 S16. } 290 5. Meta Data to Support Redundancy Protection 292 To support the redundancy protection function, Flow Identification 293 and Sequence Number are required. Flow identification identifies the 294 specific flow with target of redundancy protection. Sequence number 295 distinguishes the packets within a flow by specifying the order of 296 packets. The flow identification and sequence number is RECOMMENDED 297 to be added at the ingress of SR domain, and MUST be added before the 298 redundancy node. The flow identification and sequence number is 299 carried in the service packets along the different paths to merging 300 node. Merging node removes flow identifier and sequence number once 301 the elimination and ordering is accomplished. Thus, an encapsulation 302 of flow identification and sequence number is required to be defined 303 in both SR over MPLS and SRv6 data plane. 305 6. Segment Routing Policy to Support Redundancy Protection 307 Redundancy Policy is a variation of SR Policy, and is identified 308 through the tuple . 309 Redundancy node is specified as IPv4/IPv6 address of the headend, 310 which is able to do packet replication. Merging node is specified as 311 IPv4/IPv6 address of the endpoint, which is able to do packet 312 elimination and ordering (optional). Redundancy ID could be a 313 specified value of "color" define in section 2.1 of 314 [I-D.ietf-spring-segment-routing-policy], which indicates the SR 315 policy as a redundancy policy. Redundancy ID could also be used to 316 distinguish different redundancy policies sharing the same redundancy 317 node and merging node. 319 Redundancy Policy extends SR policy to include more than one ordered 320 lists of segments between redundancy node and merging node, and all 321 the ordered lists of segments are used at the same time to steer the 322 copies of flow into different paths. In redundancy policy, 323 Redundancy Segment MUST be specified, and the last segment of each 324 ordered list of segments MUST be Merging Segment. 326 7. IANA Considerations 328 This document requires registration of End.R behavior and End.M 329 behavior in "SRv6 Endpoint Behaviors" sub-registry of "Segment 330 Routing Parameters" registry. 332 8. Security Considerations 334 TBD 336 9. Acknowledgements 338 The authors would like to thank Bruno Decraene, Ron Bonica, and James 339 Guichard for their valuable comments. 341 10. References 343 10.1. Normative References 345 [I-D.ietf-spring-srv6-network-programming] 346 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 347 Matsushima, S., and Z. Li, "SRv6 Network Programming", 348 draft-ietf-spring-srv6-network-programming-28 (work in 349 progress), December 2020. 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, 353 DOI 10.17487/RFC2119, March 1997, 354 . 356 10.2. Informative References 358 [I-D.ietf-spring-segment-routing-policy] 359 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 360 P. Mattes, "Segment Routing Policy Architecture", draft- 361 ietf-spring-segment-routing-policy-09 (work in progress), 362 November 2020. 364 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 365 RFC 8578, DOI 10.17487/RFC8578, May 2019, 366 . 368 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 369 "Deterministic Networking Architecture", RFC 8655, 370 DOI 10.17487/RFC8655, October 2019, 371 . 373 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 374 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 375 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 376 . 378 Authors' Addresses 380 Xuesong Geng 381 Huawei Technologies 382 Beijing 383 China 385 Email: gengxuesong@huawei.com 387 Mach(Guoyi) Chen 388 Huawei Technologies 389 Beijing 390 China 392 Email: mach.chen@huawei.com 394 Fan Yang 395 Huawei Technologies 396 Beijing 397 China 399 Email: shirley.yangfan@huawei.com