Compressed SRv6 Segment List Encoding in SRH

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 9 January 2022.¶

Copyright Notice

Copyright (c) 2021 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

The Segment Routing architecture is defined in [RFC8402].¶

SRv6 Network Programming [RFC8986] defines a framework to build a network program with topological and service segments carried in a Segment Routing header (SRH) [RFC8754].¶

This document adds new flavors to the SR endpoint behaviors defined in Section 4 of [RFC8986]. These flavors enable a compressed encoding of the SRv6 Segment-List in the SRH and therefore address the requirements described in [I-D.srcompdt-spring-compression-requirement].¶

The flavors defined in this document leverage the SRH data plane without any change and do not require any SRv6 control plane change.¶

2. Terminology

This document leverages the terms defined in [RFC8402], [RFC8754] and [RFC8986]. The reader is assumed to be familiar with this terminology.¶

This document introduces the following new terms:¶

• Compressed-SID (C-SID): A C-SID is a short encoding of a SID in SRv6 packet that does not include the SID block bits (locator block).¶
• Compressed-SID container (C-SID container): An entry of the SRH Segment-List field (128 bits) that contains a sequence of C-SIDs.¶
• Compressed-SID sequence (C-SID sequence): A group of one or more C-SID containers in a segment list that share the same SRv6 SID block.¶
• Uncompressed SID sequence: A group of one or more uncompressed SIDs in a segment list.¶
• Compressed Segment List encoding: A segment list encoding that reduces the packet header length thanks to one or more C-SID sequences. A compressed Segment List encoding may also contain any number of uncompressed SID sequences.¶

3. Basic Concepts

In an SRv6 domain, the SIDs are allocated from a particular IPv6 prefix: the SRv6 SID block. Therefore, all SRv6 SIDs instantiated from the same SRv6 SID block share the same most significant bits. These common bits are named Locator-Block in [RFC8986]. Furthermore, when the combined length of the SRv6 SID Locator, Function and Argument is smaller than 128 bits, the trailing bits are set to zero.¶

When a sequence of consecutive SIDs in a Segment List shares a common Locator-Block, a compressed SRv6 Segment-List encoding can optimize the packet header length by avoiding the repetition of the Locator-Block and trailing bits with each individual SID.¶

The compressed Segment List encoding is fully compliant with the specifications in [RFC8402], [RFC8754] and [RFC8986]. Efficient encoding is achieved by combining a compressed Segment List encoding logic on the SR policy headend with new flavors of the base SRv6 endpoint behaviors that decode this compressed encoding. No SRv6 SRH data plane change nor control plane extension is required.¶

A Segment List can be encoded in the packet header using any combination of compressed and uncompressed sequences. The C-SID sequences leverage the flavors defined in this document, while the uncompressed sequences use behaviors and flavors defined in other documents, such as [RFC8986]. An SR Policy headend constructs and compresses the SID-list depending on the capabilities of each SR endpoint node that the packet should traverse, as well as its own compression capabilities.¶

It is expected that compressed encoding flavors be available on devices with limited packet manipulation capabilities, such as legacy ASICs.¶

The compressed Segment List encoding supports any SRv6 SID Block allocation. While other options are supported and may provide higher efficiency, each routing domain can be allocated a /48 prefix from a global IPv6 block (see Section 6.2).¶

4. SR Endpoint Flavors

This section defines several options to achieve compressed Segment List encoding, in the form of two new flavors for the END, END.X and END.T behaviors of [RFC8986]. These flavors could also be combined with behaviors defined in other documents.¶

The compressed encoding can be achieved by leveraging any of these SR endpoint flavors. The NEXT-C-SID flavor and the REPLACE-C-SID flavor expose the same high-level behavior in their use of the SID argument to determine the next segment to be processed, but they have different low-level characteristics that can make one more or less efficient that the other for a particular SRv6 deployment. The NEXT-and-REPLACE-C-SID flavor is the combination of the NEXT-C-SID flavor and the REPLACE-C-SID flavor. It provides the best efficiency in terms of encapsulation size at the cost of increased complexity.¶

It is recommended for ease of operation that a single compressed encoding flavor be used in a given SRv6 domain. However, in a multi-domain deployment, different flavors can be used in different domains.¶

All three flavors leverage the following variables:¶

• Variable B is the Locator Block length of the SID.¶
• Variable NF is the sum of the Locator Node and the Function lengths of the SID. It is also referred to as C-SID length.¶
• Variable A is the Argument length of the SID.¶

+----------------------------------------------------+
| Locator-Block | Locator-Node | Function | Argument |
+----------------------------------------------------+
 <----- B -----> <--------- NF ----------> <-- A --->

 1.   If (DA.Argument != 0) {
 2.     Copy DA.Argument into the bits [B..(B+A-1)] of the
          Destination Address of the IPv6 header.
 3.     Set the bits [(B+A)..127] of the Destination Address
          of the IPv6 header to zero.
 4.   } Else {
 5.     Decrement Segments Left by 1.
 6.     Copy Segment List[Segments Left] from the SRH to the
          Destination Address of the IPv6 header.
 7.   }

+----------------------------------------------------+
| Locator-Block | Locator-Node | Function | Argument |
+----------------------------------------------------+
 <----- B -----> <--------- NF ----------> <-- A --->

 1.   If (DA.Argument != 0) {
 2.     Decrement DA.Argument by 1.
 3.   } Else {
 4.     Decrement Segments Left by 1.
 5.     Set DA.Argument to (128/NF - 1).
 6.   }
 7.   Copy Segment List[Segments Left][DA.Argument] into the bits
        [B..B+NF-1] of the Destination Address of the IPv6 header.

+----------------------------------------------------------------+
| Locator-Block | Locator-Node | Function | Arg.Next | Arg.Index |
+----------------------------------------------------------------+
 <----- B -----> <--------- NF ----------> <- A_N --> <-- A_I -->

 1.   If (DA.Arg.Next != 0) {
 2.     Copy DA.Arg.Next into the bits [B..(B+A_N-1)] of the
          Destination Address of the IPv6 header.
 3.     Set the bits [(B+A_N)..(B+NF+A_N-1)] of the Destination Address
          of the IPv6 header to zero.
 4.   } Else If (DA.Arg.Index >= C_DA) {
 5.     Decrement DA.Arg.Index by C_DA.
 6.     Copy C_DA*NF bits from Segment List[Segments Left][DA.Arg.Index]
          into the bits [B..B+C_DA*NF-1] of the Destination Address of
          the IPv6 header.
 7.   } Else If (Segments Left != 0) {
 8.     Decrement Segments Left by 1.
 9.     Set DA.Arg.Index to ((DA.Arg.Index - C_DA) % (128/NF)).
10.     Copy C_DA*NF bits from Segment List[Segments Left][DA.Arg.Index]
          into the bits [B..B+C_DA*NF-1] of the Destination Address of
          the IPv6 header.
11.   } Else {
12.     Copy DA.Arg.Index*NF bits from Segment List[0][0] into the bits
          [B..B+DA.Arg.Index*NF-1] of the Destination Address of the
          IPv6 header.
13.     Set the bits [B+DA.Arg.Index*NF..B+NF+A_N-1] of the Destination
          Address of the IPv6 header to zero.
14.     Set DA.Arg.Index to 0.
15.   }

5. GIB, LIB, global C-SID and local C-SID

GIB: The set of IDs available for global C-SID allocation.¶

LIB: The set of IDs available for local C-SID allocation.¶

6. C-SID and Block Length

7. Efficient SID-list Encoding

The compressed SID-list encoding logic is a local behavior of the SR Policy headend node and hence out of the scope of this document.¶

8. Inter Routing Domains with the End.XPS behavior

The End.XPS behavior described in this section is OPTIONAL.¶

Some SRv6 traffic may need to cross multiple routing domains, such as different Autonomous Systems (ASes) or different routing areas. Different routing domains may use different addressing schema and SRv6 SID blocks.¶

This section defines an optional solution and SID behavior allowing for the use of different SRv6 SID blocks between routing domains.¶

The solution requires a new SID behavior, called "Endpoint with cross-connect to an array of layer-3 adjacencies and SRv6 Prefix Swap" (End.XPS for short) allowing for this transition of SRv6 SID block between two routing domains.¶

End.XPS is a variant of End.X, performing both "End.X Layer-3 Cross-Connect" and the translation of the SRv6 SID block between the two routing domains.¶

The processing takes as an additional parameter the prefix B2/m corresponding the SRv6 SID block in the second domain. This parameter is a property of the (received) SID and is given as a result of the lookup on the IPv6 destination address which identifies the SRv6 SID and its properties.¶

The End.XPS behavior is compatible with the NEXT-C-SID, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID flavors described in this document.¶

When a router R receives a packet whose IPv6 DA matches a local End.XPS SID with the NEXT-C-SID flavor, that is associated with a set J of one or more Layer-3 adjacencies and the SRv6 SID block B2/m of the neighbor routing domain, R processes the packet as follows.¶

 1.   If (DA.Argument != 0) {
 2.     Write B2 into the most significant bits of the Destination
          Address of the IPv6 header.
 3.     Write DA.Argument into the bits [m..(m+A-1)] of the
          Destination Address of the IPv6 header.
 4.     Set the bits [(m+A)..127] of the Destination Address
          of the IPv6 header to zero.
 5.   } Else {
 6.     Decrement Segments Left by 1.
 7.     Copy Segment List[Segments Left] from the SRH to the
          Destination Address of the IPv6 header.
 8.   }
 9.   Submit the packet to the IPv6 module for transmission to the
        new destination via a member of J.

When a router R receives a packet whose IPv6 DA matches a local End.XPS SID with the REPLACE-C-SID flavor, that is associated with a set J of one or more Layer-3 adjacencies and the SRv6 SID block B2/m of the neighbor routing domain, R processes the packet as follows.¶

 1.   If (DA.Argument != 0) {
 2.     Decrement DA.Argument by 1.
 3.   } Else {
 4.     Decrement Segments Left by 1.
 5.     Set DA.Argument to (128/NF - 1).
 6.   }
 7.   Write B2 into the most significant bits of the Destination
        Address of the IPv6 header.
 8.   Write Segment List[Segments Left][DA.Argument] into the bits
        [m..m+NF-1] of the Destination Address of the IPv6 header.
 9.   Write DA.Argument into the bits [m+NF..m+NF+A-1] of the
        Destination Address of the IPv6 header.
10.   Set the bits [(m+NF+A)..127] of the Destination Address
        of the IPv6 header to zero.
11.   Submit the packet to the IPv6 module for transmission to the
        new destination via a member of J.

Note: the way the SRv6 SID Block B2 of the next routing domain is known is out of scope of this document. As examples, it could be learnt via configuration, or using a signaling protocol either with the peer domain or with a central controller (e.g. PCE).¶

When End.XPS SID behavior is used, the restriction on the C-SID length for the REPLACE-C-SID and the NEXT-and-REPLACE-C-SID flavors is relaxed and becomes: all SID the are part of a C-SID sequence within a domain MUST have the same SID length NF.¶

9. Control Plane

This document does not require any control plane modification.¶

10. Illustrations

Illustrations will be provided in a separate document.¶

11. Interoperability Status

In November 2020, China Mobile successfully validated multiple interoperable implementations of the NEXT-C-SID and REPLACE-C-SID flavors defined in this document.¶

This testing covered two different implementations of the SRv6 endpoint flavors defined in this document:¶

• Hardware implementation in Cisco ASR 9000 running IOS XR¶
• Software implementation in Cisco IOS XRv9000 virtual appliance¶
• Hardware implementation in Huawei NE40E and NE5000E running VRP¶

The interoperability was validated for the following scenario:¶

• Packet forwarding through a traffic engineering segment list combining, in the same SRH ([RFC8754]), SRv6 SIDs bound to an endpoint behavior with the NEXT-C-SID flavor and SRv6 SIDs bound to an endpoint behavior with the REPLACE-C-SID flavor.¶

Further interoperability testing is ongoing and will be reported in this document as the work progresses.¶

12. Security Considerations

TBD¶

13. Acknowledgements

The authors would like to thank Kamran Raza, Xing Jiang, YuanChao Su, Han Li and Yisong Liu.¶

Authors' Addresses