idnits 2.17.1 draft-geng-spring-sr-redundancy-protection-01.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 8 instances of too long lines in the document, the longest one being 25 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 1156 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 401, 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-01 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. Alternative Option of Redundancy Segment . . . . . . . . 6 70 4.3. Merging Segment . . . . . . . . . . . . . . . . . . . . . 6 71 4.3.1. SR over MPLS . . . . . . . . . . . . . . . . . . . . 7 72 4.3.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5. Meta Data to Support Redundancy Protection . . . . . . . . . 7 74 6. Segment Routing Policy to Support Redundancy Protection . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 10.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 Service protection defined in [RFC8655] is initially required from 86 the use cases in a variety of industries described in [RFC8578]. 87 Together with other two techniques Resource allocation and Explicit 88 routes, it targets to provide the deterministic flow transmission. 89 Meanwhile, with the emerge of Cloud VR, Cloud Game, High-Definition 90 Video applications running in the Internet, SLA (Service Level 91 Agreement) guarantee becomes an important issue which requires new 92 technologies and solutions for network. 94 Redundancy Protection is one of the mechanisms to achieve service 95 protection, following the principle of PREOF (Packet Replication/ 96 Elimination/Ordering Function) defined in [RFC8655]. Specifically, 97 replicates the packets of flows into two or more copies, transports 98 different copies through different paths in parallel, eliminates and 99 orders the packets at end to provide redundancy protection. 101 Segment Routing (SR) leverages the source routing paradigm. An 102 ingress node steers a packet through an ordered list of instructions, 103 called "segments". A segment can be associated to an arbitrary 104 processing of the packet in the node identified by the segment. 106 This document extends the capabilities in SR paradigm to support the 107 redundancy protection, including the definitions of new Segments and 108 a variation of Segment Routing Policy. The new mechanism applies 109 equally to both segment routing with MPLS data plane (SR-MPLS) and 110 segment routing with IPv6 data plane (SRv6). 112 2. Terminology and Conventions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in 117 [I-D.ietf-spring-srv6-network-programming] and[RFC2119]. 119 Redundancy Node: the start point of redundancy protection, which is a 120 network device that could implement packet replication. 122 Merging Node: the end point of redundancy protection, which is a 123 network node that could implement packet elimination and ordering 124 (optionally). 126 Redundancy Policy: an extended SR policy which includes more than one 127 active segment lists to support redundancy protection. 129 Flow Identification: information in SR data service to indicate one 130 flow. 132 Sequence Number: information in SR data service to indicate the 133 packet sequence of one flow. 135 Editor's Note: Similar mechanism is defined as "Service Protection" 136 in the [RFC8655]. In this document, we define a new term "Redundancy 137 Protection" to distinguish with other service protection method. 138 Some of the terms are similar as [RFC8655]. 140 3. Redundancy Protection in Segment Routing Scenario 142 | | 143 |<-------------- SR Domain ------------->| 144 | | 145 | +-----+R3+-----+ | 146 +---+ +-+-+ +-+-+ +---+ 147 -------|R1 |--------|Red| |Mer|--------|R2 |------- 148 +---+ +-+-+ +-+-+ +---+ 149 +-----+R4+-----+ 151 Figure 1: Example Scenario of Redundancy Protection in SR Domain 153 This figure shows an example of redundancy protection used in SR 154 domain. When a flow is sent into SR domain, the process is: 156 1) R1 receives the traffic flow and encapsulates packets with a list 157 of segments, which is instantiated as a stack of MPLS labels or an 158 ordered list of SRv6 SIDs. The final destination of packets is R2. 159 R1, R2, R3, R4, Red and Mer are SR-capable nodes. 161 2) When the packet flow arrives in Red node, known as Redundancy 162 Node, one flow is replicated into two copies. Each copy of flow is 163 encapsulated with different newly-defined list of SIDs, and the last 164 SID is always pointed to the SID of Mer node, known as Merging Node. 166 3) Packet is encapsulated with the information of flow identification 167 and sequence number. Flow identification identifies the specific 168 flow, and sequence number distinguishes the packet sequence of a 169 flow. 171 4) When the original flow and replicated flow go through different 172 paths till Mer node, the first received packet of the flow is 173 transmitted from Merging Node to R2, and the redundant packets are 174 eliminated. 176 5) When there is any failures happened in one path, the service 177 continues to deliver through the other path without break. 179 6) Sometimes, the packet will arrive out of order because of 180 redundancy protection, the function of reordering may be necessary in 181 the Merging Node. 183 In this example, service protection is supported by utilizing two 184 packet flows transmitted over two forwarding paths. For a 185 unidirectional flow, Red node supports replication function, and Mer 186 node supports elimination and ordering functions. 188 4. Segment to Support Redundancy Protection 190 To achieve the Packet Replication/Elimination/Ordering Function, 191 Redundancy Segment and Merging Segment are introduced. 193 4.1. Redundancy Segment 195 Redundancy Segment is associated with a Redundancy Policy on 196 redundancy node. Redundancy segment is instantiated with service 197 instructions, indicating the following operations: 199 o Steering the packet into the corresponding redundancy policy 201 o Packet replication and encapsulation based on the redundancy 202 policy, e.g., the number of replication copies 204 o Encapsulate the packet with necessary meta data (e.g., flow 205 identification, sequence number) if it is not included in the 206 original packet 208 4.1.1. SR over MPLS 210 In the case of SR over MPLS, when the Active Segment is a redundancy 211 segment, a redundancy policy is associated. According to the 212 information of candidate paths in redundancy policy, packets are 213 replicated and a CONTINUE operation is applied. Incoming redundancy 214 segment is swapped with different Adj-SIDs to forward the packet in 215 different paths. 217 4.1.2. SRv6 219 In the case of SRv6, a new behavior End.R for redundancy segment is 220 defined. 222 When an SRv6-capable node (N) receives an IPv6 packet whose 223 destination address matches a local IPv6 address instantiated as an 224 SRv6 SID (S), and S is a Redundancy SID, N does: 226 S01. When an SRH is processed { 227 S02. If (Segments Left>0) { 228 S03. Create two headers IPv6+SRH-1 and IPv6+SRH-2 229 S04. Insert different policy-instructed segment lists into SRH-1 and SRH-2 230 S05. Add flow identification and sequence number to SRH-1 and SRH-2 231 S06. Remove the incoming outer IPv6+SRH header 232 S07. Create a duplication of the incoming packet payload 233 S08. Encapsulate the original packet with IPv6+SRH-1 header 234 S09. Encapsulate the duplicate packet with IPv6+SRH-2 header 235 S10. Set IPv6 SA as the local address of this node 236 S11. Set IPv6 DA of IPv6+SRH-1 to the first segment of SRv6 Policy in SRH-1 segment list 237 S12. Set IPv6 DA of IPv6+SRH-2 to the first segment of SRv6 Policy in SRH-2 segment list 238 S13. } 239 S14. ELSE { 240 S15. Drop the packet 241 S16. } 243 Note that, redundancy node decapsulates the original IPv6 and SRH 244 header, and encapsulates another newly created IPv6 and SRH header to 245 the packet payload. In this case, it would not bring extra header 246 insertion risk to IPv6. 248 4.2. Alternative Option of Redundancy Segment 250 Redundancy segment can also be a variation of Binding SID (BSID). 251 Different paths between redundancy node and merging node can be 252 encapsulated or inserted by using the End.B6.Encaps and End.B6.Insert 253 behavior of BSID. In this way, headend can have a complete segment 254 list in SRH to indicate the path from R1 to R2 in Figure 1. Take 255 End.B6.Encaps as an example. The behavior of redundancy segment 256 includes replicating packets into different copies, pushing new IPv6 257 and SRH header to packets, and newly adding or copying the 258 information like flow identification and sequence number from 259 original packet. By using the BSID and End.B6.Encaps behavior, the 260 IPv6 header insertion issue can be avoided too. 262 4.3. Merging Segment 264 Merging Segment is associated with service instructions, indicates 265 the following operations: 267 o Packet merging and elimination: forward the first received packets 268 and eliminate the redundant packets 270 o Packet ordering(optional): reorder the packets if the packet 271 arrives out of order 273 4.3.1. SR over MPLS 275 In the case of SR over MPLS, when the Active Segment is a Merging 276 Segment and this packet is not a redundant packet, a CONTINUE 277 operation is applied. Incoming merging segment is swapped with 278 Prefix-SID of destination address. The redundancy of packets is 279 determined by other techniques, and is not within the scope of this 280 document. 282 4.3.2. SRv6 284 In the case of SRv6, a new behavior End.M for Merging Segment is 285 defined. 287 When an SRv6-capable node (N) receives an IPv6 packet whose 288 destination address matches a local IPv6 address instantiated as an 289 SRv6 SID (S), and S is a Merging SID, N does: 291 S01. When an SRH is processed { 292 S02. If (Segments Left>0) { 293 S03. Acquire the sequence number of received packet and lookup it in a local table 294 S04. If (the sequence number is not existed in table ) { 295 S05. Store the packet and record the sequence number in table 296 S06. Decrement IPv6 Hop Limit by 1 297 S07. Decrement Segments Left by 1 298 S08. Update IPv6 DA with Segment List[Segments Left] 299 S09. Submit the packet to the egress IPv6 FIB lookup and transmit 300 S10. } 301 S11. ELSE { 302 S12. Drop the packet 303 S13. } 304 S14. } 305 S15. } 307 5. Meta Data to Support Redundancy Protection 309 To support the redundancy protection function, Flow Identification 310 and Sequence Number are required. Flow identification identifies the 311 specific flow with target of redundancy protection. Sequence number 312 distinguishes the packets within a flow by specifying the order of 313 packets. The information is carried in the service packets along the 314 different paths to merging node. Merging node removes flow 315 identifier and sequence number once the elimination and ordering is 316 accomplished. Flow identification and sequence number can be defined 317 as MPLS label in SR over MPLS data plane, or is extended in SRH in 318 SRv6 data plane. In case of SRv6, 319 [I-D.geng-6man-redundancy-protection-srh] specifies the options of 320 supporting flow identification and sequence number on SRH extensions. 322 Note that, the flow identification and sequence number can be added 323 either at the headend of the path, or at the redundancy node. In the 324 former case, the information is managed and assigned from the SDN 325 controller, and carried in the packet along the entire forwarding 326 path in SR domain. In the latter case, redundancy node assigns the 327 values of flow identification and sequence number itself, and this 328 information is only used between redundancy node and merging node. 330 6. Segment Routing Policy to Support Redundancy Protection 332 Redundancy Policy is a variation of SR Policy, and is identified 333 through the tuple . 334 Redundancy node is specified as IPv4/IPv6 address of the headend, 335 which is able to do packet replication. Merging node is specified as 336 IPv4/IPv6 address of the endpoint, which is able to do packet 337 elimination and ordering (optional). Redundancy ID could be a 338 specified value of "color" define in section 2.1 of 339 [I-D.ietf-spring-segment-routing-policy], which indicates the SR 340 policy as a redundancy policy. Redundancy ID could also be used to 341 distinguish different redundancy policies sharing the same redundancy 342 node and merging node. 344 Redundancy Policy extends SR policy to include more than one ordered 345 lists of segments between redundancy node and merging node to steer 346 the same flow through different paths in SR domain. In Redundancy 347 Policy, Redundancy Segment MUST be specified, and the last segment of 348 each ordered list of segments SHOULD be Merging Segment. 350 7. IANA Considerations 352 This document requires registration of End.R behavior and End.M 353 behavior in "SRv6 Endpoint Behaviors" sub-registry of "Segment 354 Routing Parameters" registry. 356 8. Security Considerations 358 TBD 360 9. Acknowledgements 362 The authors would like to thank Bruno Decraene, Ron Bonica, and James 363 Guichard for their valuable comments. 365 10. References 366 10.1. Normative References 368 [I-D.ietf-spring-srv6-network-programming] 369 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 370 Matsushima, S., and Z. Li, "SRv6 Network Programming", 371 draft-ietf-spring-srv6-network-programming-28 (work in 372 progress), December 2020. 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, 376 DOI 10.17487/RFC2119, March 1997, 377 . 379 10.2. Informative References 381 [I-D.geng-6man-redundancy-protection-srh] 382 Geng, X., M. Chen, and F. Yang, "SRH Extension for Redundancy 383 Protection", draft-geng-6man-redundancy-protection- 384 srh-00 (work in progress), February 2021. 386 [I-D.ietf-spring-segment-routing-policy] 387 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 388 P. Mattes, "Segment Routing Policy Architecture", draft- 389 ietf-spring-segment-routing-policy-09 (work in progress), 390 November 2020. 392 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 393 RFC 8578, DOI 10.17487/RFC8578, May 2019, 394 . 396 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 397 "Deterministic Networking Architecture", RFC 8655, 398 DOI 10.17487/RFC8655, October 2019, 399 . 401 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 402 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 403 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 404 . 406 Authors' Addresses 408 Xuesong Geng 409 Huawei Technologies 410 Beijing 411 China 413 Email: gengxuesong@huawei.com 414 Mach(Guoyi) Chen 415 Huawei Technologies 416 Beijing 417 China 419 Email: mach.chen@huawei.com 421 Fan Yang 422 Huawei Technologies 423 Beijing 424 China 426 Email: shirley.yangfan@huawei.com