idnits 2.17.1 draft-geng-spring-sr-redundancy-protection-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 10, 2021) is 1081 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: 'I-D.ietf-spring-sr-service-programming' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'RFC8578' is defined on line 454, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-11 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-04 Summary: 0 errors (**), 0 flaws (~~), 5 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, Ed. 5 Expires: November 11, 2021 Huawei Technologies 6 P. Camarillo 7 Cisco Systems, Inc. 8 G. Mishra 9 Verizon Inc. 10 May 10, 2021 12 Segment Routing for Redundancy Protection 13 draft-geng-spring-sr-redundancy-protection-03 15 Abstract 17 Redundancy protection provides a mechanism to achieve the high 18 reliability of the service transmission in network. This document 19 extends the capabilities in SR paradigm to support the redundancy 20 protection in a DetNet environment, including the definitions of new 21 Segments and a variation of Segment Routing Policy. The new 22 mechanism applies equally to both Segment Routing with MPLS data 23 plane (SR-MPLS) and Segment Routing with IPv6 data plane (SRv6). 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in . 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 11, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 2.2. Terminology and Conventions . . . . . . . . . . . . . . . 3 69 3. Redundancy Protection in Segment Routing Scenario . . . . . . 4 70 4. Segment to Support Redundancy Protection . . . . . . . . . . 5 71 4.1. Redundancy Segment . . . . . . . . . . . . . . . . . . . 5 72 4.1.1. SR over MPLS . . . . . . . . . . . . . . . . . . . . 5 73 4.1.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.2. Merging Segment . . . . . . . . . . . . . . . . . . . . . 7 75 4.2.1. SR over MPLS . . . . . . . . . . . . . . . . . . . . 7 76 4.2.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 7 77 5. Meta Data to Support Redundancy Protection . . . . . . . . . 8 78 6. Segment Routing Policy to Support Redundancy Protection . . . 8 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 10.2. Informative References . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 Redundancy Protection provides a mechanism to achieve the high 90 reliability of the service transmission in network. Specifically, 91 packets of flows are replicated into two or more copies, which are 92 transported through different paths in parallel. When copies of 93 packets are merged at network node, the redundant packets are 94 eliminated to guarantee one copy of the flow is successfully 95 transmitted. 97 Redundancy protection targets to the services especially requires 98 ultra reliable transmission, for example 5G URLLC services including 99 Cloud VR/Game, remote surgery, harbor crane lifting, and differential 100 protection in electrical utilities etc. Redundancy protection can 101 also be used as Packet Replication and Elimination Function for 102 Deterministic Networking defined in [RFC8655]. At last, it also 103 bring values to the existing services in legacy network, for example 104 IPTV service and financial private line in fixed broadband network, 105 as well as the video service in data center interconnect. 107 Segment Routing (SR) leverages the source routing paradigm. An 108 ingress node steers a packet through an ordered list of instructions, 109 called "segments". A segment can be associated to an arbitrary 110 processing of the packet in the node identified by the segment. 112 This document extends the capabilities in SR paradigm to support the 113 redundancy protection in a DetNet environment, including the 114 definitions of new Segments and a variation of Segment Routing 115 Policy. The new mechanism applies equally to both Segment Routing 116 with MPLS data plane (SR-MPLS) [RFC8660] and Segment Routing with 117 IPv6 data plane (SRv6) [RFC8986]. 119 2. Terminology 121 2.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 2.2. Terminology and Conventions 131 This document uses the terminology defined in [RFC8402] [RFC8964], 132 and it also introduces the following new terms: 134 Redundancy Node: the start point of redundancy protection, which is a 135 network device that could implement packet replication. 137 Merging Node: the end point of redundancy protection, which is a 138 network node that could implement packet elimination. 140 Redundancy Policy: an extended SR policy which includes more than one 141 active segment lists to support redundancy protection. 143 Flow Identification: information in the SR packet to indicate one 144 flow. 146 Sequence Number: information in the SR packet to indicate the packet 147 sequence of one flow. 149 Editor's Note: Similar mechanism is defined as "Service Protection" 150 in the [RFC8655]. In this document, we define a new term "Redundancy 151 Protection" to distinguish with other service protection method. 152 Some of the terms are similar as [RFC8655]. 154 3. Redundancy Protection in Segment Routing Scenario 156 | | 157 |<------------- SRv6 Domain ------------->| 158 | | 159 | +---+ | 160 | +-----+R3 +-----+ | 161 | | +---+ | | 162 +-+-+ +-+-+ +-+-+ +-+-+ 163 -------+R1 +--------+Red| |Mer+--------+R2 +------- 164 +---+ +-+-+ +-+-+ +---+ 165 | +---+ | 166 +-----+R4 +-----+ 167 +---+ 169 Figure 1: Example Scenario of Redundancy Protection in SRv6 Domain 171 This figure shows an example of redundancy protection used in SRv6 172 domain. R1, R2, R3, R4, Red and Mer are SR-capable nodes. When a 173 flow is sent into SRv6 domain, the process is: 175 1) R1 receives the traffic flow and encapsulates packets with a list 176 of segments destined to R2, which is instantiated as an ordered list 177 of SRv6 SIDs. 179 2) When the packet flow arrives in Red node, known as Redundancy 180 Node, each packet is replicated into two or more copies. Each copy 181 of the packet is encapsulated with a new segment list, which 182 represents different forwarding paths (e.g., Disjoint Paths). The 183 last SID in the segment list is always a SID instantiated on the 184 Merging node (Mer) . 186 3) At the same time, the Flow Identification and Sequence Number are 187 added to each of the replicas. Flow identification identifies the 188 specific flow, and sequence number distinguishes the packet sequence 189 of a flow. 191 4) The multiple replicas go through different paths until the Mer 192 node. The first received packet of the flow is transmitted from 193 Merging Node to R2, and the redundant packets are eliminated. 195 5) When there is any failures or packet loss in one path, the service 196 continues undisrupted through the other path without break. 198 6) Sometimes, the packet will arrive out of order because of 199 redundancy protection, the function of reordering may be also 200 necessary on Merging Node. In such case the Merging node may include 201 a reordering function. This is implementation specific and out of 202 the scope of this document. 204 In this example, service protection is supported by utilizing two 205 packet flows transmitted over two forwarding paths. It is noted that 206 there is no limitation of the number of replicas. For a 207 unidirectional flow, Red node supports replication function, and Mer 208 node supports elimination function. Reordering function MAY be 209 required in combination of elimination function on merging node. To 210 minimize the jitter caused by random packet loss, the disjoint paths 211 are recommended to have similar path forwarding delay. 213 4. Segment to Support Redundancy Protection 215 To achieve the packet replication and elimination functions, 216 Redundancy Segment and Merging Segment, as well as the SR over MPLS 217 forwarding behavior and SRv6 Endpoint Behavior are introduced. 219 4.1. Redundancy Segment 221 Redundancy Segment is a variation of Binding SID, and associated with 222 a Redundancy Policy on the redundancy node. Redundancy segment is 223 associated with service instructions, indicating the following 224 operations: 226 o Steering the packet into the corresponding redundancy policy 228 o Flow identification and sequence number encapsulation in packets 230 o Packet replication and segment encapsulation based on the 231 information of redundancy policy, e.g., the number of replication 232 copies, a segment or an ordered list of segments with a 233 topological instruction 235 4.1.1. SR over MPLS 237 In the case of SR over MPLS, IETF Deterministic Networking working 238 group has defined Packet Replication/Elimination/Ordering Functions 239 in DetNet MPLS data plane [RFC8964]. The support of redundancy 240 protection in SR over MPLS data plane keeps consistent with the PRF 241 and REF functions defined in DetNet MPLS data plane. 243 In SR over MPLS, Redundancy Segment acts as DetNet S-Label to 244 explicitly identify the replication function on redundancy node. 245 Redundancy segment is allocated from redundancy node, and is 246 provisioned to the ingress node of SR domain by the controller plane 247 via PCEP, BGP, or NetConf protocols. 249 When the Active Segment is a Redundancy Segment, a NEXT operation is 250 performed and a redundancy policy is associated. Via redundancy 251 policy, flow identification is assigned to redundancy node and acts 252 as the elimination serivce label (S-Label). Sequence number is 253 generated and encapsulated in DetNet Control Word (d-CW). The 254 packets of a flow is replicated to multiple replicas, and 255 encapsulated with a new MPLS label stack including the d-CW, S-Label 256 and forwarding sub-layer LSPs, determined by the candidate paths of 257 redundancy policy. 259 4.1.2. SRv6 261 In the case of SRv6, a new behavior End.R for Redundancy Segment is 262 defined. An instance of a redundancy SID is associated with a 263 redundancy policy B and a source address A. In the following 264 description, End.R behavior is specified in the encapsulation mode. 265 The End.R behavior in the insertion mode is for further study. 267 When an SRv6-capable node (N) receives an IPv6 packet whose 268 destination address matches a local IPv6 address instantiated as an 269 SRv6 SID (S), and S is a Redundancy SID, N does: 271 S01.When an SRH is processed { 272 S02. If (Segments Left == 0) { 273 S03. Remove the IPv6 header 274 S04 } 275 S05. If (Segments Left>0) { 276 S06. Decrement IPv6 Hop Limit by 1 277 S07. Decrement Segments Left by 1 278 S08. Update IPv6 DA with Segment List[Segments Left] 279 S09. } 280 S10. Add flow identification and sequence number to packet 281 S11. Duplicate the packets (as many replicas as active SID lists in B) 282 S12. Push the new IPv6 headers to each replica. The IPv6 header 283 contains an SRH with a different SID List 284 S13. Set the outer IPv6 SA to A 285 S14. Set the outer IPv6 DA to the first SID of new SRH SL 286 S15. Set the outer Payload Length, Traffic Class, Flow Label, 287 Hop Limit and Next-Header fields 288 S16. Submit the packet to the egress IPv6 FIB lookup 289 for transmission to the new destination 290 S17.} 291 4.2. Merging Segment 293 Merging Segment is associated with service instructions, indicates 294 the following operations: 296 o Packet merging and elimination: forward the first received packets 297 and eliminate the redundant packets 299 In order to eliminate the redundant packet of a flow, merging node 300 utilizes sequence number to evaluate the redundant status of a 301 packet. Note that implementation specific mechanism could be applied 302 to control the amount of state monitored on sequence number, so that 303 system memory usage can be limited at a reasonable level. 305 As merging node needs to maintain the state of flows, a centralized 306 controller should have a knowledge of merging nodes capability, and 307 never provision the redundancy policy to redundancy node when the 308 computation result goes beyond the flow recovery capability of 309 merging node. The capability advertisement of merging node will be 310 specified separately elsewhere, which is not within the scope of this 311 document. 313 4.2.1. SR over MPLS 315 In the case of SR over MPLS, being consistent with [RFC8964], Merging 316 Segment always stays at last of MPLS label stack as DetNet S-Label. 317 When the Active Segment is a Merging Segment, a NEXT operation is 318 performed. The packet is identified to a particular flow according 319 to the service label. Sequence number encapsulated in DetNet control 320 word is used to determine whether the packet is redundant. 322 4.2.2. SRv6 324 In the case of SRv6, a new behavior End.M for Merging Segment is 325 defined. 327 When an SRv6-capable node (N) receives an IPv6 packet whose 328 destination address matches a local IPv6 address instantiated as an 329 SRv6 SID (S), and S is a Merging SID, N does: 331 S01. When an SRH is processed { 332 S02. If (Segments Left==0) { 333 S03. Acquire the sequence number of received packet and look it up 334 S04. If (state of this sequence number == 0) { 335 S05. Set the state of this sequence number to 1 336 S06. Remove the outer IPv6+SRH header 337 S07. Decrement IPv6 Hop Limit by 1 in inner SRH 338 S08. Decrement Segments Left by 1 in inner SRH 339 S09. Update IPv6 DA with Segment List[Segments Left] in inner SRH 340 S10. Submit the packet to the egress IPv6 FIB lookup and transmit 341 S11. } 342 S12. ELSE { 343 S13. Drop the packet 344 S14. } 345 S15. } 346 S16. } 348 5. Meta Data to Support Redundancy Protection 350 To support the redundancy protection function, Flow Identification 351 and Sequence Number are required. Flow identification identifies the 352 specific flow with target of redundancy protection. Sequence number 353 distinguishes the packets within a flow by specifying the order of 354 packets. Thus, the encapsulation of flow identification and sequence 355 number is required in both SR over MPLS and SRv6 data plane. 357 In SR over MPLS, being consistent with [RFC8964], flow identification 358 is identified by either redundancy service or merging service, and is 359 encapsulated as the DetNet service label. Note that, the DetNet 360 service label can be different and swapped in the packet 361 transmission. Sequence number is encapsulated in DetNet Control Word 362 (d-CW). 364 In SRv6, flow identification and sequence number is added at the 365 redundancy node and carried in the packets along the different paths 366 to merging node. Merging node removes flow identifier and sequence 367 number once the elimination and ordering (optional) is accomplished. 369 6. Segment Routing Policy to Support Redundancy Protection 371 Redundancy Policy is a variation of SR Policy, and is identified 372 through the tuple . 373 Redundancy node is specified as IPv4/IPv6 address of the headend, 374 which is able to do packet replication. Merging node is specified as 375 IPv4/IPv6 address of the endpoint, which is able to do packet 376 elimination. Redundancy ID could be a specified value of "color" 377 define in section 2.1 of [I-D.ietf-spring-segment-routing-policy], 378 which indicates the SR policy as a redundancy policy. Redundancy ID 379 could also be used to distinguish different redundancy policies 380 sharing the same redundancy node and merging node. 382 Redundancy Policy extends SR policy to include more than one ordered 383 lists of segments between redundancy node and merging node, and all 384 the ordered lists of segments are used at the same time to steer the 385 copies of flow into different paths. In redundancy policy, 386 Redundancy Segment MUST be specified, and the last segment of each 387 ordered list of segments MUST be Merging Segment. 389 7. IANA Considerations 391 This document requires registration of End.R behavior and End.M 392 behavior in "SRv6 Endpoint Behaviors" sub-registry of "Segment 393 Routing Parameters" registry. 395 8. Security Considerations 397 TBD 399 9. Acknowledgements 401 The authors would like to thank Bruno Decraene, Ron Bonica, and James 402 Guichard for their valuable comments. 404 10. References 406 10.1. Normative References 408 [I-D.ietf-spring-segment-routing-policy] 409 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 410 P. Mattes, "Segment Routing Policy Architecture", draft- 411 ietf-spring-segment-routing-policy-11 (work in progress), 412 April 2021. 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, 416 DOI 10.17487/RFC2119, March 1997, 417 . 419 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 420 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 421 May 2017, . 423 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 424 Decraene, B., Litkowski, S., and R. Shakir, "Segment 425 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 426 July 2018, . 428 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 429 Decraene, B., Litkowski, S., and R. Shakir, "Segment 430 Routing with the MPLS Data Plane", RFC 8660, 431 DOI 10.17487/RFC8660, December 2019, 432 . 434 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, 435 S., and J. Korhonen, "Deterministic Networking (DetNet) 436 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 437 2021, . 439 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 440 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 441 (SRv6) Network Programming", RFC 8986, 442 DOI 10.17487/RFC8986, February 2021, 443 . 445 10.2. Informative References 447 [I-D.ietf-spring-sr-service-programming] 448 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 449 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 450 S. Salsano, "Service Programming with Segment Routing", 451 draft-ietf-spring-sr-service-programming-04 (work in 452 progress), March 2021. 454 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 455 RFC 8578, DOI 10.17487/RFC8578, May 2019, 456 . 458 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 459 "Deterministic Networking Architecture", RFC 8655, 460 DOI 10.17487/RFC8655, October 2019, 461 . 463 Authors' Addresses 465 Xuesong Geng 466 Huawei Technologies 467 China 469 Email: gengxuesong@huawei.com 470 Mach(Guoyi) Chen 471 Huawei Technologies 472 China 474 Email: mach.chen@huawei.com 476 Fan Yang 477 Huawei Technologies 478 China 480 Email: shirley.yangfan@huawei.com 482 Pablo Camarillo Garvia 483 Cisco Systems, Inc. 484 Spain 486 Email: pcamaril@cisco.com 488 Gyan Mishra 489 Verizon Inc. 491 Email: gyan.s.mishra@verizon.com