idnits 2.17.00 (12 Aug 2021) /tmp/idnits59831/draft-wang-loops-srv6-binding-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 09, 2020) is 796 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-li-tsvwg-loops-problem-opportunities-04 == Outdated reference: A later version (-04) exists of draft-welzl-loops-gen-info-02 == Outdated reference: draft-ietf-6man-segment-routing-header has been published as RFC 8754 == Outdated reference: A later version (-01) exists of draft-bormann-loops-geneve-binding-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 loops J. Wang 3 Internet-Draft S. Nie 4 Intended status: Informational B. Lei 5 Expires: September 10, 2020 China Telecom 6 C. Bormann 7 Universitaet Bremen TZI 8 March 09, 2020 10 Embedding LOOPS in SRv6 11 draft-wang-loops-srv6-binding-00 13 Abstract 15 LOOPS (Local Optimizations on Path Segments) aims to provide local 16 in-network loss recovery. It can be used with tunneling protocols to 17 efficiently recover lost packets on a single segment of an end-to-end 18 path instead of leaving recovery to the end-to-end protocol, 19 traversing the entire path. 21 Segment Routing (SR) leverages the source routing mechanisms and 22 steers the packets through an policy instantiated as an ordered list 23 of instructions called segments. LOOPS can be embedded in an SR 24 segment to improve the packet recovery. draft-welzl-loops-gen-info 25 defines the generic information model, without binding that to any 26 specific protocols, to be carried between LOOPS ingress and egress 27 nodes, which can be SR segment endpoints. This document specifies 28 the concrete mechanisms to embed LOOPS in SRv6 segment. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 10, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. LOOPS TLV in SRv6 . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Flags and Flag Based Data . . . . . . . . . . . . . . . . 5 68 4. Embedding LOOPS in SRv6 . . . . . . . . . . . . . . . . . . . 6 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 7.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 LOOPS (Local Optimizations on Path Segments) aims to provide local 80 in-network loss recovery. [I-D.li-tsvwg-loops-problem-opportunities] 81 shows an overview on the problems that LOOPS could address and some 82 use cases where LOOPS can be employed to improve the performance. 83 When an end-to-end path contains one or more LOOPS segments, packet 84 loss recovery can be performed over such a segment. Such in-network 85 recovery is faster than the end-to-end packet recovery in most cases, 86 especially when the LOOPS enabled segment is a small part of the 87 entire path in terms of latency, or when it occasionally suffers 88 microburst losses. In addition, with the increasing deployment of 89 encrypted transport layer like QUIC, the traditional performance 90 enhancing proxies (PEPs, [RFC3135]) are no longer applicable. LOOPS 91 enabled on a network segment can work with no dependency on transport 92 layer or higher information. Thus it can improve performance over a 93 path with segments of varying quality. 95 [I-D.welzl-loops-gen-info] illustrates the generic information to be 96 carried over a LOOPS segment. Such information is used for packet 97 loss detection, packet retransmission (if required), segment 98 congestion indication to end-to-end congestion control loop, etc. In 99 typical cases where the segment is tunnel based, this information is 100 embedded in the tunnel encapsulation. [I-D.welzl-loops-gen-info] 101 does not exhaustively describe how each protocol specifically carries 102 LOOPS information and what are the encapsulations. 103 [I-D.bormann-loops-geneve-binding] is an example for a binding of 104 LOOPS to a specific encapsulation, in this case Geneve. Similarly, 105 the present document is a binding of LOOPS to SRv6. 107 Segment Routing (SR) [RFC8402] uses source routing techniques to 108 deliver the data through a pre-defined path and/or functions. It can 109 be used to select a traffic path, for instance a lower latency one. 110 SRv6 (SR over IPv6) runs on a best effort IPv6 network, and its 111 segments suffer from different levels of packet loss. An SR segment 112 can naturally be a LOOPS segment to perform in-network packet loss 113 recovery. 115 There are some typical scenarios that we could use LOOPS to enhance 116 SRv6 data transmission. For example, most mobile payment services 117 have critical requirements of the latency and packet loss over the 118 Internet. The pre-defined SRv6 path could be the shortest one on 119 average, with some occasional packet loss. Such occasional packet 120 loss does not always trigger the selection of a better path as change 121 of a path normally can not be executed in real time. Hence LOOPS can 122 be used to recover the packet loss over SRv6 segments to guarantee 123 such critical services. The ingress endpoint identifies the key 124 services which require LOOPS enablement and the traffic flows through 125 the pre-defined SIDs (segment IDs). There are different ways to 126 identify such services, for instance, using the destination IP 127 address and port. In SR context, it could also be coupled to some 128 special SID when an SRv6 ingress node applies its path selection 129 policy. In-network recovery then can be performed between the 130 endpoints of a SR segment, to be more specific between two SIDs. 132 This document describes how to embed LOOPS in SRv6 data packets. 134 2. Terminology 136 This document makes use of the terminology defined in 137 [I-D.welzl-loops-gen-info]. 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in 142 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 3. LOOPS TLV in SRv6 147 SRv6 [I-D.ietf-6man-segment-routing-header] defines meta-data in TLV 148 format for segment processing. SRv6 segment endpoints are LOOPS 149 ingress and egress. In the rest of this document, the term "segment" 150 is used interchangeably both for the LOOPS segment and the SRv6 151 segment. 153 A new TLV called LOOPS is defined in this document. Figure 1 shows 154 its format. 156 Alignment requirement: 4n 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Type | Length | Flags | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | | 164 ~ Flag Based Data ~ 165 | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Figure 1: SRv6 LOOPS TLV 170 where: 172 o Type: to be assigned by IANA (suggested value 128). The value 173 should be at least 128 as LOOPS TLV data may change en route to 174 the packet's final destination. Its highest-order bit of Type 175 must be 1. 177 o Length: The length of the variable length data in bytes. The 178 maximum total length of this TLV is (8 + 127) = 135 bytes. 180 o Flags: 16 bits, as described in Section 3.1. Some of the flags 181 indicate the presence of additional data in the field of Flag 182 Based Data. 184 o Flag Based Data: This field consists of one or multiple optional 185 data blocks whose presence is indicated by the corresponding flag 186 bits. Please see Section 3.1 for details. 188 3.1. Flags and Flag Based Data 190 Flags are defined in Figure 2. Some flags have additional data 191 blocks in Flags Based Data field. Those additional data blocks are 192 placed in order of flags. Figure 2 shows the format and definition 193 of flags defined. 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 |M|I|R|D|S|T|E|A|R| |B| 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 2: Flags in SRv6 LOOPS TLV 201 o M: Mode flag. 203 * 0: Retransmission mode. In this mode, the LOOPS TLV format and 204 operations follow this document. 206 * 1: FEC mode. 208 o I: Initial Packet Sequence Number (PSN) flag. It is set by the 209 LOOPS ingress to notify the egress about using a new initial PSN. 211 o R: Initial PSN Received flag; echo of I flag provided by the LOOPS 212 egress. 214 o D: ACK Desired flag. It is set by the LOOPS ingress if it wants 215 the egress to generate an acknowledgement immediately upon 216 receiving a particular packet. 218 o S: PSN flag. When set, it indicates a PSN data block is carried 219 in Flag Based Data field. It must be set when a packet payload is 220 present. It must not be set if the packet is a pure LOOPS ACK 221 packet, i.e. when no payload is included in the packet. 223 o T: Timestamp flag. When set, it indicates a Timestamp data block 224 is carried in the Flag Based Data field. 226 o E: Echoed Timestamp flag. When set, it indicates an Echoed 227 Timestamp data block is carried in the Flag Based Data field. 229 o A: ACK number flag. When set, it indicates the presence of a 230 Block 1 ACK information block. 232 o R: Reception time flag: May only be set if A is set. Indicates 233 that an absolute reception time is given (Format TBD). 235 Finally, a single flag bit is defined that causes the addition of a 236 variable-length block (therefore this flag is put as the least 237 significant bit of Flags): 239 o B: Block 2 flag. When set, it indicates the presence of a Block 2 240 ACK information block, with the following format: TBD 242 (((We borrowed most text about encapsulation from draft-bormann- 243 loops-geneve-binding. 1. M flag for Mode is put in flags field 244 which is different from Geneve encap. 2. Further discussion about a 245 minimum and unified set of loops format is required since it turns 246 out most encap format are the same for Geneve and SRv6. ))) 248 4. Embedding LOOPS in SRv6 250 LOOPS can be enabled on any segment in SRv6 deployment. For 251 instance, a SID list may enable LOOPS on any segments 252 independently. If segment S2 is subject to higher packet loss, LOOPS 253 is enabled on S2 without impact on S1 and S3. 255 Figure 3 shows packets sent from S to D in an SRv6 domain via SID 256 list and LOOPS is enabled between R1 and R2. The 257 configuration needs to make sure both R1 and R2 can support LOOPS 258 TLV. 260 Format 261 (SA,DA): (src address, dst address) 262 (S3, S2, S1; SL):(SID list; Segments Left) 264 SID:S1 SID:S2 SID:S3 265 +----+ +----+ lossy link +----+ +----+ +---+ 266 | S |---| R1 |--------------| R2 |------| R3 |------| D | 267 +----+ +----+ +----+ +----+ +---+ 268 | | 269 |<----------------->| 270 | LOOPS enabled | 272 (S, S1) 273 (D,S3,S2,S1;3) 274 ------------> 275 (S, S2) 276 (D,S3,S2,S1;2) 277 + LOOPS TLV 278 --------------> (S, S3) 279 (D,S3,S2,S1;1) 280 (S2,S1) --------------> 281 (S1;0) (S, D) 282 + LOOPS TLV (D,S3,S2,S1;0) 283 <--------------- -------------> 285 Figure 3: Segment enabled LOOPS in SRv6 287 LOOPS TLV should be parsed and removed by the destined SRv6 SID. 288 That is to say LOOPS is enabled on a segment independently. 290 In the forward path, a LOOPS TLV is added by SR segment endpoint R1 291 and sent to SID S2. When R2 receives the packet with SRH and LOOPS 292 TLV present, it should get the previous segment SID which is S1 as 293 shown in Figure 3 from field Segment List[Segment Left + 1] where 294 Segment Left is field value in the received SRH. When the value of 295 Segment Left is equal to the value of Last Entry in SRH, the previous 296 segment SID is set to the value of the source IPv6 address in IP 297 header. 299 Reduced SRH (section 4.1.1 in [I-D.ietf-6man-segment-routing-header]) 300 does not contain the first segment of the related SR policy in 301 Segment List, the first segment is the one already in the DA of the 302 IPv6 header. Hence when reduced SRH is used, if the value of Segment 303 Left is equal to the value of (Last Entry + 1) in SRH, the previous 304 segment SID is set to the value of the source IPv6 address. A 305 special case that needs to be taken care of is when LOOPS is enabled 306 on the second segment with reduced SRH. As the SID of the first 307 segment is not present in the field of Segment List, there is no 308 direct way to set the right value of previous segment SID (which is 309 SID of the first segment) when the second segment receives the LOOPS 310 enabled packet. Hence it is suggested not to use reduced SRH when 311 LOOPS is in use or the configurations need to ensure that LOOPS is 312 not enabled on the second segment when reduced SRH is in use. 314 Any generated feedback such as ACKs should be sent as reverse channel 315 information back to previous segment SID. The LOOPS reverse channel 316 information needs to be sent from SID S2 to SID S1 in figure 3. Such 317 information can be piggybacked in data packets in the reverse 318 direction. When piggyback is not possible, a pure LOOPS ACK needs to 319 be sent back. In this case, the reverse information packet has SRH 320 with LOOPS TLV but has no real payload. The field of Next Header in 321 SRH for pure LOOPS ACK should be set to 59 (No Next Header) 322 [RFC8200]. 324 When the sender and receiver are outside the SRv6 domain, the SR 325 ingress (which could be R1 in Figure 3) will encapsulate the packet 326 received in an outer header with an SRH. LOOPS can be enabled on the 327 segment indicated by the outer header. 329 5. Security Considerations 331 The security considerations of [I-D.welzl-loops-gen-info] and 332 [I-D.ietf-6man-segment-routing-header] apply. 334 6. IANA Considerations 336 IANA is requested to assign a code point value for LOOPS TLV from 337 Segment Routing Header TLVs Registry. 339 Assigned Value Description 340 ------------ -------------------------------------------- 341 128 LOOPS (Local Optimizations on Path Segments) 343 7. References 345 7.1. Normative References 347 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 348 Shelby, "Performance Enhancing Proxies Intended to 349 Mitigate Link-Related Degradations", RFC 3135, 350 DOI 10.17487/RFC3135, June 2001, 351 . 353 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 354 (IPv6) Specification", STD 86, RFC 8200, 355 DOI 10.17487/RFC8200, July 2017, 356 . 358 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 359 Decraene, B., Litkowski, S., and R. Shakir, "Segment 360 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 361 July 2018, . 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 369 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 370 May 2017, . 372 7.2. Informative References 374 [I-D.li-tsvwg-loops-problem-opportunities] 375 Yizhou, L., Zhou, X., Boucadair, M., and J. Wang, "LOOPS 376 (Localized Optimizations on Path Segments) Problem 377 Statement and Opportunities for Network-Assisted 378 Performance Enhancement", draft-li-tsvwg-loops-problem- 379 opportunities-04 (work in progress), January 2020. 381 [I-D.welzl-loops-gen-info] 382 Welzl, M. and C. Bormann, "LOOPS Generic Information Set", 383 draft-welzl-loops-gen-info-02 (work in progress), November 384 2019. 386 [I-D.ietf-6man-segment-routing-header] 387 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 388 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 389 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 390 progress), October 2019. 392 [I-D.bormann-loops-geneve-binding] 393 Bormann, C., "Embedding LOOPS in Geneve", draft-bormann- 394 loops-geneve-binding-00 (work in progress), November 2019. 396 Acknowledgements 398 The authors would like to thank Yizhou Li for her help on LOOPS 399 generic information. 401 Authors' Addresses 403 Jianglong Wang 404 China Telecom 406 Email: wangjl50@chinatelecom.cn 408 Shizhong Nie 409 China Telecom 411 Email: nieshzh@chinatelecom.cn 413 Bo Lei 414 China Telecom 416 Email: leibo@chinatelecom.cn 418 Carsten Bormann 419 Universitaet Bremen TZI 420 Postfach 330440 421 Bremen D-28359 422 Germany 424 Phone: +49-421-218-63921 425 Email: cabo@tzi.org