Internet DRAFT - draft-wang-loops-srv6-binding


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


   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

   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
   ( 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.  []
   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

   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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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

   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


   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

   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 <S1, S2, S3> 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 <S1, S2, S3> and LOOPS is enabled between R1 and R2.  The
   configuration needs to make sure both R1 and R2 can support LOOPS

Wang, et al.           Expires September 10, 2020               [Page 6]
Internet-Draft                LOOPS in SRv6                   March 2020

    (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)
                   (S, S2)
                    + LOOPS TLV
                   --------------> (S, S3)
                       (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

   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)

   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

              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.

              Welzl, M. and C. Bormann, "LOOPS Generic Information Set",
              draft-welzl-loops-gen-info-02 (work in progress), November

              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.

              Bormann, C., "Embedding LOOPS in Geneve", draft-bormann-
              loops-geneve-binding-00 (work in progress), November 2019.


   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


   Shizhong Nie
   China Telecom


   Bo Lei
   China Telecom


   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359

   Phone: +49-421-218-63921

Wang, et al.           Expires September 10, 2020              [Page 10]