]> Compressed SRv6 Segment List Encoding in SRH China Mobile
China chengweiqiang@chinamobile.com
Cisco Systems, Inc.
Belgium cf@cisco.com
Huawei Technologies
China lizhenbin@huawei.com
Alibaba
USA d.cai@alibaba-inc.com
Bell Canada
Canada daniel.voyer@bell.ca
Cisco Systems, Inc.
France fclad@cisco.com
Broadcom
Israel shay.zadok@broadcom.com
Futurewei Technologies Ltd.
USA james.n.guichard@futurewei.com
ZTE Corporation
China liu.aihua@zte.com.cn
General SPRING Internet-Draft This document defines a compressed SRv6 Segment List Encoding in the SRH. This solution does not require any SRH data plane change nor any SRv6 control plane change. This solution leverages the SRv6 Network Programming model.
The Segment Routing architecture is defined in . SRv6 Network Programming defines a framework to build a network program with topological and service segments carried in a Segment Routing header (SRH) . This document adds new flavors to the SR endpoint behaviors defined in . These flavors enable a compressed encoding of the SRv6 Segment-List in the SRH and therefore address the requirements described in . The flavors defined in this document leverage the SRH data plane without any change and do not require any SRv6 control plane change.
This document leverages the terms defined in , and . 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.
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 . 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 , and . 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 . 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 ).
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 . 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.
A SID instantiated with the NEXT-C-SID flavor takes an argument that carries the remaining C-SIDs in the current C-SID container. The length A of the argument is equal to 128-B-NF and should be a multiple of NF.
<--------- NF ----------> <-- A ---> ]]>
Pseudo-code:
Note: DA.Argument identifies the bits [(B+NF)..(B+NF+A-1)] in the Destination Address of the IPv6 header. The NEXT-C-SID flavor has been previously documented in under the name "SHIFT" flavor. In that context, a C-SID and a C-SID-sequence are respectively named a Micro-Segment (uSID) and a Micro-Program.
A SID instantiated with the REPLACE-C-SID flavor takes an argument, which is used to determine the index of the next C-SID in the appropriate container. All SIDs that are part of a C-SID sequence using the REPLACE-C-SID flavor have the same C-SID length NF. The length A of the argument should be at least ceil(log_2(128/NF)).
<--------- NF ----------> <-- A ---> ]]>
Pseudo-code:
Notes: DA.Argument identifies the bits [(B+NF)..(B+NF+A-1)] in the Destination Address of the IPv6 header. Segment List[Segments Left][DA.Argument] identifies the bits [DA.Argument*NF..(DA.Argument+1)*NF-1] in the SRH Segment List entry at index Segments Left. The REPLACE-C-SID flavor has been previously documented in under the name "COC(Continue of Compression)" flavor. In that context, a C-SID and a C-SID-sequence are respectively named a G-SID and G-SRv6 compression sub-path.
A SID instantiated with the NEXT-and-REPLACE-C-SID flavor takes a two-parts argument comprising, Arg.Next and Arg.Index, and encoded in the SID in this order. The length A_I of Arg.Index is equal to ceil(log_2(128/NF)). The length A_N of Arg.Next is equal to 128-B-NF-A_I and must be a multiple of NF. The total SID argument length A is the sum of A_I and A_N. The NEXT-and-REPLACE-C-SID flavor also leverages an additional variable, C_DA, that is equal to (1 + (A_N/NF)) and represents the number of C-SID's that can be encoded in the IPv6 Destination Address. All SIDs that are part of a C-SID sequence using the NEXT-and-REPLACE-C-SID flavor must have the same C-SID length NF. Furthermore, this NF must be a divisor of 128.
<--------- NF ----------> <- A_N --> <-- A_I --> ]]>
Pseudo-code:
= 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+F+A_N-1] of the Destination Address of the IPv6 header to zero. 14. Set DA.Arg.Index to 0. 15. } ]]>
Notes: DA.Arg.Next identifies the bits [(B+NF)..(B+NF+A_N-1)] in the Destination Address of the IPv6 header. DA.Arg.Index identifies the bits [(B+NF+A_N)..(B+NF+A_N+A_I-1)] in the Destination Address of the IPv6 header. Segment List[Segments Left][DA.Arg.Index] identifies the bits [DA.Arg.Index*NF..(DA.Arg.Index+1)*NF-1] in the SRH Segment List entry at index Segments Left.
GIB: The set of IDs available for global C-SID allocation. LIB: The set of IDs available for local C-SID allocation.
A C-SID from the GIB. A Global C-SID typically identifies a shortest-path to a node in the SRv6 domain. An IP route is advertised by the parent node to each of its global C-SID's, under the associated C-SID block. The parent node executes a variant of the END behavior. A node can have multiple global C-SID's under the same C-SID blocks (e.g. one per IGP flexible algorithm). Multiple nodes may share the same global C-SID (anycast).
A C-SID from the LIB. A local C-SID may identify a cross-connect to a direct neighbor over a specific interface or a VPN context. No IP route is advertised by a parent node for its local C-SID's. If N1 and N2 are two different physical nodes of the SRv6 domain and I is a local C-SID value, then N1 and N2 may bind two different behaviors to I. The concept of LIB is applicable to SRv6 and specifically to its NEXT-C-SID and REPLACE-C-SID flavors. The shorter the SID/C-SID, the more benefit the LIB brings. The allocation of C-SID's from the GIB and LIB depends on the C-SID length (see ).
The NEXT-C-SID flavor allows to place multiple C-SID's in the DA to mix C-SID's of different sizes in the DA/any container to process multiple C-SID's at once (with one single FIB lookup) For these reasons, the NEXT-C-SID flavor benefits from a lower C-SID length granularity and 16 bits is recommended. The REPLACE-C-SID flavor does not allow to place multiple C-SID's in the DA to mix C-SID's of different sizes in the DA/any container to process multiple C-SID's at once (with one single FIB lookup) For these reasons, the REPLACE-C-SID flavor must "replace" more bits when updating the DA. A longer C-SID length is needed, and 32 bits is recommended. Note: Appendix A describes the problems that arise if REPLACE-C-SID is used with 16-bit C-SID length In summary: NEXT-C-SID: 16-bit C-SID length REPLACE-C-SID: 32-bit C-SID length
The compressed Segment List encoding supports any SRv6 SID Block allocation either from GUA or LUA space. The recommended SRv6 SID block sizes for the NEXT-C-SID flavor are 16, 32 or 48 bits. The smaller the block, the higher the compression efficiency. The recommended SRv6 SID block size for the REPLACE-C-SID flavor can be 48, 56, 64, 72 or 80 bits, depending on the needs of the operator.
The previous block and C-SID length recommendations, call for the following GIB/LIB usage: NEXT-C-SID: GIB: END.NEXT-C-SID LIB: END.X.NEXT-C-SID, END.DX.NEXT-C-SID, END.DT.NEXT-C-SID LIB: END.DX.NEXT-C-SID for large-scale PW support REPLACE-C-SID: GIB: END.REPLACE-C-SID, END.X.REPLACE-C-SID, END.DX.REPLACE-C-SID, END.DT.REPLACE-C-SID LIB: END.DX.REPLACE-C-SID for large-scale PW support
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.
This document does not require any control plane modification.
Illustrations will be provided in a separate document.
TBD
TBD
&RFC8402; &RFC8754; &I-D.ietf-spring-srv6-network-programming; &I-D.filsfils-spring-net-pgm-extension-srv6-usid; &I-D.cheng-spring-shorter-srv6-sid-requirement; Generalized SRv6 Network Programming for SRv6 Compression
In this section, we show the problems that would arise if REPLACE-C-SID is used with C-SID length of 16bits. The use of 16-bit C-SIDs requires to allocate END.X.REPLACE-C-SID, END.DT.REPLACE-C-SID and END.DX.REPLACE-C-SID SIDs from the LIB. In the case of an END.REPLACE-C-SID SID followed by an END.X.REPLACE-C-SID SID instantiated on the same node, this would require to: Lookup the END.REPLACE-C-SID SID in the DA Replace active C-SID with the next one in SRH Lookup the END.X.REPLACE-C-SID SID in the DA Replace active C-SID with the next one in SRH Forward the packet via X-connect In the case of an END.REPLACE-C-SID SID following by an END.DT.REPLACE-C-SID SID instantiated on the same node, this would require to: Lookup the END.REPLACE-C-SID SID in the DA Replace active C-SID with the next one in SRH Lookup the END.DT.REPLACE-C-SID SID in the DA Decapsulate the packet Lookup the inner DA in the appropriate table Forward the packet This double or triple lookup is a major inefficiency if one would want to deploy the REPLACE-C-SID flavor with 16-bit C-SIDs. It really mandates the use of 32-bit C-SIDs, such that END.X.REPLACE-C-SID, END.DT.REPLACE-C-SID and END.DX.REPLACE-C-SID SIDs can be allocated from the GIB and it is not required to prefix them with an END.REPLACE-C-SID SID.