loops J. Wang Internet-Draft S. Nie Intended status: Informational B. Lei Expires: September 10, 2020 China Telecom C. Bormann Universitaet Bremen TZI March 09, 2020 Embedding LOOPS in SRv6 draft-wang-loops-srv6-binding-00 Abstract LOOPS (Local Optimizations on Path Segments) aims to provide local in-network loss recovery. It can be used with tunneling protocols to efficiently recover lost packets on a single segment of an end-to-end path instead of leaving recovery to the end-to-end protocol, traversing the entire path. Segment Routing (SR) leverages the source routing mechanisms and steers the packets through an policy instantiated as an ordered list of instructions called segments. LOOPS can be embedded in an SR segment to improve the packet recovery. draft-welzl-loops-gen-info defines the generic information model, without binding that to any specific protocols, to be carried between LOOPS ingress and egress nodes, which can be SR segment endpoints. This document specifies the concrete mechanisms to embed LOOPS in SRv6 segment. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 10, 2020. Wang, et al. Expires September 10, 2020 [Page 1] Internet-Draft LOOPS in SRv6 March 2020 Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. LOOPS TLV in SRv6 . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Flags and Flag Based Data . . . . . . . . . . . . . . . . 5 4. Embedding LOOPS in SRv6 . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction LOOPS (Local Optimizations on Path Segments) aims to provide local in-network loss recovery. [I-D.li-tsvwg-loops-problem-opportunities] shows an overview on the problems that LOOPS could address and some use cases where LOOPS can be employed to improve the performance. When an end-to-end path contains one or more LOOPS segments, packet loss recovery can be performed over such a segment. Such in-network recovery is faster than the end-to-end packet recovery in most cases, especially when the LOOPS enabled segment is a small part of the entire path in terms of latency, or when it occasionally suffers microburst losses. In addition, with the increasing deployment of encrypted transport layer like QUIC, the traditional performance enhancing proxies (PEPs, [RFC3135]) are no longer applicable. LOOPS enabled on a network segment can work with no dependency on transport layer or higher information. Thus it can improve performance over a path with segments of varying quality. Wang, et al. Expires September 10, 2020 [Page 2] Internet-Draft LOOPS in SRv6 March 2020 [I-D.welzl-loops-gen-info] illustrates the generic information to be carried over a LOOPS segment. Such information is used for packet loss detection, packet retransmission (if required), segment congestion indication to end-to-end congestion control loop, etc. In typical cases where the segment is tunnel based, this information is embedded in the tunnel encapsulation. [I-D.welzl-loops-gen-info] does not exhaustively describe how each protocol specifically carries LOOPS information and what are the encapsulations. [I-D.bormann-loops-geneve-binding] is an example for a binding of LOOPS to a specific encapsulation, in this case Geneve. Similarly, the present document is a binding of LOOPS to SRv6. Segment Routing (SR) [RFC8402] uses source routing techniques to deliver the data through a pre-defined path and/or functions. It can be used to select a traffic path, for instance a lower latency one. SRv6 (SR over IPv6) runs on a best effort IPv6 network, and its segments suffer from different levels of packet loss. An SR segment can naturally be a LOOPS segment to perform in-network packet loss recovery. There are some typical scenarios that we could use LOOPS to enhance SRv6 data transmission. For example, most mobile payment services have critical requirements of the latency and packet loss over the Internet. The pre-defined SRv6 path could be the shortest one on average, with some occasional packet loss. Such occasional packet loss does not always trigger the selection of a better path as change of a path normally can not be executed in real time. Hence LOOPS can be used to recover the packet loss over SRv6 segments to guarantee such critical services. The ingress endpoint identifies the key services which require LOOPS enablement and the traffic flows through the pre-defined SIDs (segment IDs). There are different ways to identify such services, for instance, using the destination IP address and port. In SR context, it could also be coupled to some special SID when an SRv6 ingress node applies its path selection policy. In-network recovery then can be performed between the endpoints of a SR segment, to be more specific between two SIDs. This document describes how to embed LOOPS in SRv6 data packets. 2. Terminology This document makes use of the terminology defined in [I-D.welzl-loops-gen-info]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in Wang, et al. Expires September 10, 2020 [Page 3] Internet-Draft LOOPS in SRv6 March 2020 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. LOOPS TLV in SRv6 SRv6 [I-D.ietf-6man-segment-routing-header] defines meta-data in TLV format for segment processing. SRv6 segment endpoints are LOOPS ingress and egress. In the rest of this document, the term "segment" is used interchangeably both for the LOOPS segment and the SRv6 segment. A new TLV called LOOPS is defined in this document. Figure 1 shows its format. Alignment requirement: 4n 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Flag Based Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: SRv6 LOOPS TLV where: o Type: to be assigned by IANA (suggested value 128). The value should be at least 128 as LOOPS TLV data may change en route to the packet's final destination. Its highest-order bit of Type must be 1. o Length: The length of the variable length data in bytes. The maximum total length of this TLV is (8 + 127) = 135 bytes. o Flags: 16 bits, as described in Section 3.1. Some of the flags indicate the presence of additional data in the field of Flag Based Data. o Flag Based Data: This field consists of one or multiple optional data blocks whose presence is indicated by the corresponding flag bits. Please see Section 3.1 for details. Wang, et al. Expires September 10, 2020 [Page 4] Internet-Draft LOOPS in SRv6 March 2020 3.1. Flags and Flag Based Data Flags are defined in Figure 2. Some flags have additional data blocks in Flags Based Data field. Those additional data blocks are placed in order of flags. Figure 2 shows the format and definition of flags defined. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|I|R|D|S|T|E|A|R| |B| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Flags in SRv6 LOOPS TLV o M: Mode flag. * 0: Retransmission mode. In this mode, the LOOPS TLV format and operations follow this document. * 1: FEC mode. o I: Initial Packet Sequence Number (PSN) flag. It is set by the LOOPS ingress to notify the egress about using a new initial PSN. o R: Initial PSN Received flag; echo of I flag provided by the LOOPS egress. o D: ACK Desired flag. It is set by the LOOPS ingress if it wants the egress to generate an acknowledgement immediately upon receiving a particular packet. o S: PSN flag. When set, it indicates a PSN data block is carried in Flag Based Data field. It must be set when a packet payload is present. It must not be set if the packet is a pure LOOPS ACK packet, i.e. when no payload is included in the packet. o T: Timestamp flag. When set, it indicates a Timestamp data block is carried in the Flag Based Data field. o E: Echoed Timestamp flag. When set, it indicates an Echoed Timestamp data block is carried in the Flag Based Data field. o A: ACK number flag. When set, it indicates the presence of a Block 1 ACK information block. o R: Reception time flag: May only be set if A is set. Indicates that an absolute reception time is given (Format TBD). Wang, et al. Expires September 10, 2020 [Page 5] Internet-Draft LOOPS in SRv6 March 2020 Finally, a single flag bit is defined that causes the addition of a variable-length block (therefore this flag is put as the least significant bit of Flags): o B: Block 2 flag. When set, it indicates the presence of a Block 2 ACK information block, with the following format: TBD (((We borrowed most text about encapsulation from draft-bormann- loops-geneve-binding. 1. M flag for Mode is put in flags field which is different from Geneve encap. 2. Further discussion about a minimum and unified set of loops format is required since it turns out most encap format are the same for Geneve and SRv6. ))) 4. Embedding LOOPS in SRv6 LOOPS can be enabled on any segment in SRv6 deployment. For instance, a SID list may enable LOOPS on any segments independently. If segment S2 is subject to higher packet loss, LOOPS is enabled on S2 without impact on S1 and S3. Figure 3 shows packets sent from S to D in an SRv6 domain via SID list and LOOPS is enabled between R1 and R2. The configuration needs to make sure both R1 and R2 can support LOOPS TLV. Wang, et al. Expires September 10, 2020 [Page 6] Internet-Draft LOOPS in SRv6 March 2020 Format (SA,DA): (src address, dst address) (S3, S2, S1; SL):(SID list; Segments Left) SID:S1 SID:S2 SID:S3 +----+ +----+ lossy link +----+ +----+ +---+ | S |---| R1 |--------------| R2 |------| R3 |------| D | +----+ +----+ +----+ +----+ +---+ | | |<----------------->| | LOOPS enabled | (S, S1) (D,S3,S2,S1;3) ------------> (S, S2) (D,S3,S2,S1;2) + LOOPS TLV --------------> (S, S3) (D,S3,S2,S1;1) (S2,S1) --------------> (S1;0) (S, D) + LOOPS TLV (D,S3,S2,S1;0) <--------------- -------------> Figure 3: Segment enabled LOOPS in SRv6 LOOPS TLV should be parsed and removed by the destined SRv6 SID. That is to say LOOPS is enabled on a segment independently. In the forward path, a LOOPS TLV is added by SR segment endpoint R1 and sent to SID S2. When R2 receives the packet with SRH and LOOPS TLV present, it should get the previous segment SID which is S1 as shown in Figure 3 from field Segment List[Segment Left + 1] where Segment Left is field value in the received SRH. When the value of Segment Left is equal to the value of Last Entry in SRH, the previous segment SID is set to the value of the source IPv6 address in IP header. Reduced SRH (section 4.1.1 in [I-D.ietf-6man-segment-routing-header]) does not contain the first segment of the related SR policy in Segment List, the first segment is the one already in the DA of the IPv6 header. Hence when reduced SRH is used, if the value of Segment Left is equal to the value of (Last Entry + 1) in SRH, the previous Wang, et al. Expires September 10, 2020 [Page 7] Internet-Draft LOOPS in SRv6 March 2020 segment SID is set to the value of the source IPv6 address. A special case that needs to be taken care of is when LOOPS is enabled on the second segment with reduced SRH. As the SID of the first segment is not present in the field of Segment List, there is no direct way to set the right value of previous segment SID (which is SID of the first segment) when the second segment receives the LOOPS enabled packet. Hence it is suggested not to use reduced SRH when LOOPS is in use or the configurations need to ensure that LOOPS is not enabled on the second segment when reduced SRH is in use. Any generated feedback such as ACKs should be sent as reverse channel information back to previous segment SID. The LOOPS reverse channel information needs to be sent from SID S2 to SID S1 in figure 3. Such information can be piggybacked in data packets in the reverse direction. When piggyback is not possible, a pure LOOPS ACK needs to be sent back. In this case, the reverse information packet has SRH with LOOPS TLV but has no real payload. The field of Next Header in SRH for pure LOOPS ACK should be set to 59 (No Next Header) [RFC8200]. When the sender and receiver are outside the SRv6 domain, the SR ingress (which could be R1 in Figure 3) will encapsulate the packet received in an outer header with an SRH. LOOPS can be enabled on the segment indicated by the outer header. 5. Security Considerations The security considerations of [I-D.welzl-loops-gen-info] and [I-D.ietf-6man-segment-routing-header] apply. 6. IANA Considerations IANA is requested to assign a code point value for LOOPS TLV from Segment Routing Header TLVs Registry. Assigned Value Description ------------ -------------------------------------------- 128 LOOPS (Local Optimizations on Path Segments) 7. References 7.1. Normative References [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, . Wang, et al. Expires September 10, 2020 [Page 8] Internet-Draft LOOPS in SRv6 March 2020 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [I-D.li-tsvwg-loops-problem-opportunities] Yizhou, L., Zhou, X., Boucadair, M., and J. Wang, "LOOPS (Localized Optimizations on Path Segments) Problem Statement and Opportunities for Network-Assisted Performance Enhancement", draft-li-tsvwg-loops-problem- opportunities-04 (work in progress), January 2020. [I-D.welzl-loops-gen-info] Welzl, M. and C. Bormann, "LOOPS Generic Information Set", draft-welzl-loops-gen-info-02 (work in progress), November 2019. [I-D.ietf-6man-segment-routing-header] Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-26 (work in progress), October 2019. [I-D.bormann-loops-geneve-binding] Bormann, C., "Embedding LOOPS in Geneve", draft-bormann- loops-geneve-binding-00 (work in progress), November 2019. Acknowledgements The authors would like to thank Yizhou Li for her help on LOOPS generic information. Wang, et al. Expires September 10, 2020 [Page 9] Internet-Draft LOOPS in SRv6 March 2020 Authors' Addresses Jianglong Wang China Telecom Email: wangjl50@chinatelecom.cn Shizhong Nie China Telecom Email: nieshzh@chinatelecom.cn Bo Lei China Telecom Email: leibo@chinatelecom.cn Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Wang, et al. Expires September 10, 2020 [Page 10]