idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- 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 (15 February 2022) is 773 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) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-16 Summary: 0 errors (**), 0 flaws (~~), 2 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: 19 August 2022 Huawei Technologies 6 P. Camarillo 7 Cisco Systems, Inc. 8 G. Mishra 9 Verizon Inc. 10 15 February 2022 12 SRv6 for Redundancy Protection 13 draft-ietf-spring-sr-redundancy-protection-01 15 Abstract 17 Redundancy Protection is a generalized protection mechanism to 18 achieve the high reliability of service transmission in Segment 19 Routing network. The mechanism inherits the "Live-Live" methodology, 20 targeting to enhance the functionalities of Segment Routing over 21 IPv6. Inspired by DetNet Packet Replication and Packet Elimination 22 functions, two new Segments are introduced to provide replication and 23 elimination functions on specific network nodes by leveraging SRv6 24 Segment programming capabilities. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in . 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 19 August 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised 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.2. Merging Segment . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . 9 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 10.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 Redundancy Protection is a generalized protection mechanism to 86 achieve the high reliability of service transmission in Segment 87 Routing network. Specifically, packets of flows are replicated at a 88 network node into two or more copies, which are transported via 89 different and disjoint paths in parallel. When copies of packets are 90 received and merged at one network node, the redundant packets are 91 determined and further eliminated to guarantee only one copy of 92 packets is transmitted. The mechanism inherits the "Live-Live" 93 methodology, targeting to enhance the functionalities of Segment 94 Routing over IPv6 [RFC8986]. Inspired by DetNet [RFC8655] Packet 95 Replication and Packet Elimination Functions, two new Segments are 96 introduced to provide the replication and elimination functions on 97 specific network nodes by leveraging SRv6 Segment programming 98 capabilities. As it is unnecessary to perform switchover of 99 recieving packets between different paths, redundancy protection can 100 facilitate to achieve zero packet loss target when failure on either 101 path happens. 103 Redundancy protection provides ultra reliable protection to many 104 services, for example Cloud VR/Game, IPTV service and other type of 105 video services, high value private line service etc. In this 106 document, redundancy protection is applied to point-to-point service. 107 The mechanism for point-to-multipoint service stays out of the scope 108 of this document. 110 Segment Routing (SR) leverages the source routing paradigm. An 111 ingress node steers a packet through an ordered list of instructions, 112 called "segments". A segment can be associated to an arbitrary 113 processing of the packet in the node identified by the segment. 115 This document extends the Segment Routing capabilities to support the 116 redundancy protection in an SRv6 environment, including the 117 definitions of two new Segments, meta data encapsulation, and a 118 variation of Segment Routing Policy. 120 2. Terminology 122 2.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 2.2. Terminology and Conventions 132 SR: Segment Routing 134 URLLC: Ultra-Reliable Low-Latency Communication 136 VR: Virtual Reality 138 Red node: Redundancy node 140 Mer node: Merging node 142 FID: Flow IDentification 143 SN: Sequence Number 145 3. Redundancy Protection in Segment Routing Scenario 147 | | 148 |<--------------- SRv6 Domain ---------------->| 149 | | 150 | +-----+ | 151 | +-----+ R3 +-----+ | 152 | | +-----+ | | 153 +-----+ +--+--+ +--+--+ +-----+ 154 -------+ R1 +--------+ Red | | Mer +-------+ R2 +------- 155 +-----+ +--+--+ +--+--+ +-----+ 156 | +-----+ | 157 +------+ R4 +-----+ 158 +-----+ 160 Figure 1: Example Scenario of Redundancy Protection in SRv6 Domain 162 This figure shows an example of redundancy protection used in SRv6 163 domain. R1, R2, R3, R4, Red and Mer are SR-capable nodes. When a 164 flow is sent into SRv6 domain, the process is: 166 1) R1 receives the traffic flow and encapsulates packets with a list 167 of segments destined to R2, which is instantiated as an ordered list 168 of SRv6 SIDs. 170 2) When the packet flow arrives at Red node, known as Redundancy 171 node, each packet is replicated into two or more copies. Each copy 172 of the packet is encapsulated with a new segment list, which 173 represents different disjoint forwarding paths. 175 3) Meta data information such as flow identification (FID) and 176 sequence number (SN) is used to facilitate the packet elimination on 177 Merging node (Mer). Flow identification identifies the specific 178 flow, and sequence number distinguishes the packet sequence of a 179 flow. Meta data is either carried in the packet before it arrives at 180 redundancy node, or added to each of the replicas at redundancy node. 182 4) The multiple replicas go through different paths until the Mer 183 node, known as Merging node. The first received copy of each flow 184 packet is transmitted from Merging node to R2, and the redundant 185 packets are eliminated. 187 5) When there is any failures or packet loss in one path, the service 188 transmission continues through the other path non-disruptively. 190 6) Sometimes, out-of-order packets may occur since service packets 191 are recovered from different forwarding paths. In this case, the 192 merging node or other network nodes behind merging node is desired to 193 include a reordering function, which is implementation specific and 194 out of the scope of this document. 196 In this example, service protection is supported by utilizing two 197 packet flows transmitted over two forwarding paths. It is noted that 198 there is no limitation of the number of replicas. For a 199 unidirectional flow, Red node supports replication function, and Mer 200 node supports elimination function. Reordering function MAY be 201 required in combination of elimination function on merging node. To 202 minimize the jitter caused by random packet loss, the disjoint paths 203 are recommended to have similar path forwarding delay. 205 4. Segment to Support Redundancy Protection 207 To achieve the packet replication and elimination functions, 208 Redundancy Segment and Merging Segment, as well as the related SRv6 209 Endpoint Behavior are introduced. 211 4.1. Redundancy Segment 213 Redundancy Segment is the identifier of packets which need to be 214 replicated on redundancy node. It is a variation of Binding SID 215 (BSID) to associate with a Redundancy Policy, instantiation of which 216 provides segment lists of different disjoint paths. Similar to the 217 relationship between BSID and SR Policy 218 [I-D.ietf-spring-segment-routing-policy], the use of Redundancy 219 Segment would trigger the Redundancy Policy instantiation on 220 redundancy node. 222 Redundancy Segment is associated with service instructions, 223 indicating the following operations: 225 * Steers the packet into the corresponding redundancy policy 227 * Encapsulates flow identification and sequence number in packets if 228 the two information is not carried in packets 230 * Packet replication and segment encapsulation based on the 231 information of redundancy policy, e.g., the number of replication 232 copies, an ordered list of segments with a topological instruction 234 In the case of SRv6, a new behavior End.R for Redundancy Segment is 235 defined. An instance of a redundancy SID is associated with a 236 redundancy policy B and a source address A. In the following 237 description, End.R behavior is specified in the encapsulation mode. 238 The End.R behavior in the insertion mode is for further study. 240 When an SRv6-capable node (N) receives an IPv6 packet whose 241 destination address matches a local IPv6 address instantiated as an 242 SRv6 SID (S), and S is a Redundancy SID, N does: 244 S01. When an SRH is processed { 245 S02. If (Segments Left>0) { 246 S03. Decrement IPv6 Hop Limit by 1 247 S04. Decrement Segments Left by 1 248 S05. Update IPv6 DA with Segment List[Segments Left] 249 S06. Add flow identification and sequence number if indicated* 250 S07. Duplicate the packets (as number of active SID lists in B) 251 S08. Push the new IPv6 headers to each replica. The IPv6 header 252 contains an SRH with the SID list in B 253 S09. Set the outer IPv6 SA to A 254 S10. Set the outer IPv6 DA to the first SID of new SRH SL 255 S11. Set the outer Payload Length, Traffic Class, Flow Label, 256 Hop Limit and Next-Header fields 257 S12. Submit the packet to the egress IPv6 FIB lookup 258 for transmission to the new destination 259 S13. } 260 S14. } 261 * Adding flow identification and sequence number is an optional behavior 262 for Redundancy Segment. The instruction execution is determined and 263 explicitly indicated by SR policy or Segment itself. 265 4.2. Merging Segment 267 Merging Segment is associated with service instructions, indicates 268 the following operations: 270 * Packet merging and elimination: forward the first received packets 271 and eliminate the redundant packets 273 In order to eliminate the redundant packet of a flow, merging node 274 utilizes sequence number to evaluate the redundant status of a 275 packet. Note that implementation specific mechanism could be applied 276 to control the amount of state monitored on sequence number, so that 277 system memory usage can be limited at a reasonable level. 279 As merging node needs to maintain the state of flows, a centralized 280 controller should have a knowledge of merging nodes capability, and 281 never provision the redundancy policy to redundancy node when the 282 computation result goes beyond the flow recovery capability of 283 merging node. The capability advertisement of merging node will be 284 specified separately elsewhere, which is not within the scope of this 285 document. 287 In the case of SRv6, a new behavior End.M for Merging Segment is 288 defined. 290 When an SRv6-capable node (N) receives an IPv6 packet whose 291 destination address matches a local IPv6 address instantiated as an 292 SRv6 SID (S), and S is a Merging SID, N does: 294 S01. When an SRH is processed { 295 S02. If (Segments Left> or ==0) { 296 S03. Acquire the sequence number of received packet and 297 look it up in table 298 S04. If (this sequence number does not exist in the table) { 299 S05. Store this sequence number in table 300 S06. Remove the outer IPv6+SRH header 301 S07. Decrement IPv6 Hop Limit by 1 in inner SRH 302 S08. Decrement Segments Left by 1 in inner SRH 303 S09. Update IPv6 DA with Segment List[Segments Left] in inner SRH 304 S10. Submit the packet to the egress IPv6 FIB lookup and transmit 305 S11. } 306 S12. ELSE { 307 S13. Drop the packet 308 S14. } 309 S15. } 310 S16. } 312 5. Meta Data to Support Redundancy Protection 314 To support the redundancy protection function, flow identification 315 and sequence number are added in the packet and further used at 316 merging node when the merging function is executed. Flow 317 identification identifies one specific flow of redundancy protection, 318 and is usually allocated from centralized controller to SR ingress 319 node or redundancy node in SR network. Note that flow identification 320 can also be allocated and advertised by merging node. BGP, PCEP or 321 Netconf protocols can facilitate the advertisement and distribution 322 of flow identification among controller, redundancy node and merging 323 node. Sequence number distinguishes the packets within a flow by 324 specifying the order of packets. Not like the uniqueness of flow 325 identification to one specific flow, sequence number keeps changing 326 to each packet within a flow. It is RECOMMENDED to add the sequence 327 number in forwarding plane as performance and scalability is 328 required. 330 Figure 4 suggests an encapsulation of flow identification and 331 sequence number in Segment Routing Header (SRH)[RFC8754] when 332 redundancy protection is used in SRv6 network. 334 0 1 2 3 335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Last Entry | Flags | Tag (Sequence Number) | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 ~ Merging Segment (Locator+Function+Arg:Flow ID) ~ 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 ~ ... ~ 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 ~ Segment List[n] (128 bits) ~ 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 4 Encapsulation of Flow Identification and Sequence Number 350 Since the flow identification is only used at merging node to 351 identify the specific flow of redundancy protection, it is 352 RECOMMENDED to be encapsulated in the Arguments of Merging Segment in 353 SRH. The length of flow identification is not limited, however in 354 practice it is suggested to be 16 bits. 356 All the duplicates of the same packet need to be tagged for 357 deduplication at the merging node. For this purpose, we will use a 358 sequence number. It is RECOMMENDED to encode the seq number in the 359 Tag field of the SRH, with a length of 16bits. 361 6. Segment Routing Policy to Support Redundancy Protection 363 Redundancy Policy is a variation of SR Policy to conduct the replicas 364 to multiple disjoint paths for redundancy protection. It extends SR 365 policy [I-D.ietf-spring-segment-routing-policy] to include more than 366 one active and parallel ordered lists of segments between redundancy 367 node and merging node, and all the ordered lists of segments are used 368 at the same time to steer each copy of flow into different disjoint 369 paths. 371 7. IANA Considerations 373 This document requires registration of End.R behavior and End.M 374 behavior in "SRv6 Endpoint Behaviors" sub-registry of "Segment 375 Routing Parameters" registry. 377 8. Security Considerations 379 TBD 381 9. Acknowledgements 383 The authors would like to thank Bruno Decraene, Ron Bonica, James 384 Guichard, Jeffrey Zhang, Balazs Varga for their valuable comments and 385 discussions. 387 10. References 389 10.1. Normative References 391 [I-D.ietf-spring-segment-routing-policy] 392 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 393 P. Mattes, "Segment Routing Policy Architecture", Work in 394 Progress, Internet-Draft, draft-ietf-spring-segment- 395 routing-policy-16, 28 January 2022, 396 . 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, 401 DOI 10.17487/RFC2119, March 1997, 402 . 404 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 405 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 406 May 2017, . 408 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 409 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 410 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 411 . 413 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 414 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 415 (SRv6) Network Programming", RFC 8986, 416 DOI 10.17487/RFC8986, February 2021, 417 . 419 10.2. Informative References 421 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 422 "Deterministic Networking Architecture", RFC 8655, 423 DOI 10.17487/RFC8655, October 2019, 424 . 426 Authors' Addresses 428 Xuesong Geng 429 Huawei Technologies 430 China 432 Email: gengxuesong@huawei.com 434 Mach(Guoyi) Chen 435 Huawei Technologies 436 China 438 Email: mach.chen@huawei.com 440 Fan Yang 441 Huawei Technologies 442 China 444 Email: shirley.yangfan@huawei.com 446 Pablo Camarillo Garvia 447 Cisco Systems, Inc. 448 Spain 450 Email: pcamaril@cisco.com 452 Gyan Mishra 453 Verizon Inc. 455 Email: gyan.s.mishra@verizon.com