SPRING Working Group | Yao. Liu |
Internet-Draft | Shaofu. Peng |
Intended status: Standards Track | ZTE Corporation |
Expires: December 30, 2020 | June 28, 2020 |
SRv6 Compressed Path Recover Method
draft-pl-spring-compr-path-recover-00
This document describes a path information recovery method for compressed SRv6 segment lists.
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 December 30, 2020.
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.
Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node by inserting an ordered list of instructions, called segments.Segment Routing can be deployed on the MPLS data plane by encoding 32-bits SIDs in MPLS label stack [RFC8660]. It can also be deployed on the IPv6 data plane by encoding a list of 128-bits SRv6 SIDs in IPv6 Segment Routing Extension Header (SRH)[RFC8754].
Several proposals are introduced to reduce the overhead for both the traffic volume and the network processor in SRv6. The main ideas of them are basically to use a shorter ID associated with the complete 128 bit SID. The SRH does not carry complete path information after compression, however, the transit and egress nodes may need to know the complete SID information along the path in some scenarios such as OAM.
This document describes a path information recovery method for compressed SRv6 segment lists.
Several proposals are introduced to reduce the overhead for both the traffic volume and the network processor in SRv6. The main ideas of them are basically to use a shorter ID associated with the complete 128 bit SID. The method to establish such association could be mapping,stitching, shifting, or translation.
Existing compression schemes use the 128 bit space as the carrier of compressing SIDs. In the compressed SRH, the meaning of a 128 bit segment may be:
a) an uncompressed SID
b) a unified prefix, followed by several short SIDs, and possibly existing end marker or padding, which is generally set to value 0
c) short SIDs of the same type and length, possibly followed by end marker or padding, which is generally set to value 0
So after receiving the SRv6 packets, the node or application cannot obtain the complete path information according to segment list in SRH any more.
This document defines an SRH TLV called Segment List Recover TLV, where,
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 | List ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List Recover Info (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Segment List Recover TLV
List ID: 16 bits, identification of a complete path with local significance.
List Recover Info: variable length. It provides auxiliary information to recover the complete path information from the segment list in the received SRH.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | Index | Range | BL | ST | count | Basic Compressed Description Unit +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - ~ ... ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: List Recover Info detailed structure
List Recover Info contains one or more Basic Compressed Description Unit, where:
Index: 8-bit index, number of 128 bit unit remaining from the current carrier, which is a bit like segments left([RFC8200], Section 4.4).
Index refers to the start of (consecutive) carrier(s) that contains the compression information. If a segment list contains both compressed carrier and complete SID, the index will skip the complete SID.
Range: 8 bit.It indicates the number of consecutive 128-bit carrier in the same format, starting from the carrier directed by the index.
In this way, if multiple consecutive carriers use the same format, only one Basic Compressed Description Unit needs to be carried.
When range is set to 1, it indicates that the basic unit carries informational of only one 128 bit carrier.
BL: It indicates the prefix length. When set to 0, it means that the 128 bit carrier does not carry prefix information but only contains short SIDs.
ST:short SID type, 4 bits with following values:
0001: 32-bits SID
0010: 16-bits SID
Existing proposals mainly focus on the 16-bits and 32-bits short SIDs, other values may be defined in the future.
count: 4 bits.It indicates the number of short SIDs in the 128 bit carrier.
When the headend of the SR policy sends the SRv6 packet, it can contain the TLV used to describe the above compression details in the SRH.Upon receiving the above SRv6 packets, the transit node or egress node can perform segment list restoration according to the TLV carried in the SRH.
The restored SID list information can be used as an important reference for constructing the reverse path, or used for displaying to the user or for other OAM purposes.
This document provides two path restoration options:
a) The node locally maintains the mapping between the list ID and the path information. Upon receiving the packet, the node identifies the path corresponding to the SRH according to the list ID carried in the SRH TLV. List Recover Info is not needed in this case.
b) According to the information carried in the list recover info, combined with the segment list in the SRH, the node recovers the complete path information.
It should be noticed that option b can't be used in reduced SRH.
This section describes how to restore a complete path utilizing a Segment List Recover TLV.
The current chapter focuses on option B combined with some representative schemes. Option A will be discussed in the later version.
[I-D.filsfils-spring-net-pgm-extension-srv6-usid] extends SRv6 Network Programming with a new type of SRv6 SID behavior.
A uSID carrier is a 128 bit SRv6 SID of format <uSID-Block><Active-uSID><Next-uSID>...<Last-uSID><End-of-Carrier>...<End-of-Carrier>.
So the segment list may be encoded as figure 3 after compression.
It is consist of six 128-bit units. SID-1 is an uncompressed 128-bit SID and is the first segment to be processed in the segment list.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | Block(64) | uSIDA(32) | uSIDB(32) | index=0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | Block(64) | uSIDA(32) | uSIDB(32) | index=1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | Block(32) | uSID7(32) | uSID8(32) | uSID9(32) | index=2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | Block(32) | uSID4(32) | uSID5(32) | uSID6(32) | index=3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | Block(32) | uSID1(32) | uSID2(32) | uSID3(32) | index=4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | SID-1(128 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Figure 3: segment list encoding example A
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 | List ID=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | Index=4 | Range=3 | BL=32 |ST=0001|count=3| Basic Compressed Description Unit 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | Index=1 | Range=2 | BL=64 |ST=0001|count=2| Basic Compressed Description Unit 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Figure 4: Segment List Recover TLV encoding example A
Figure 4 shows the corresponding Segment List Recover TLV encoding of the compressed segment list.
Basic Compressed Description Unit 1 has following components, where,
Index=4: It indicates that the compression information starting from the 128-bit unit with index 4 is described in this Basic Compressed Description Unit.
Range=3: It indicates that there are 3 128-bit unit of the same structure described in this Basic Compressed Description Unit
BL=32: It indicates that the block length is 32 bit.
ST=0001: It indicates that the length of each short SID is 32 bit.
count=3: It indicates that this carrier contains 3 short SIDs.
The meaning of Basic Compressed Description Unit2 is similar, so it will not be explained in details.
The compression method of stitching is to extract the public prefix information in the SIDs, the remaining part is short SID and stored in SRH. The prefix and short SID are spliced into a complete 128-bit address.
[I-D.decraene-spring-srv6-vlsid] and [I-D.li-spring-compressed-srv6-np] use the stitching method. Stitching is also one of the compression modes supported by [I-D.mirsky-6man-unified-id-sr].
Figure 5 shows a possible SRH encoding in stitching method.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | uncompressed SID(128 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | uSID1(32) | uSID2(32) | uSID3(32) | uSID4(32) | index=1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | uSID1(32) | uSID2(32) | uSID3(32) | uSID4(32) | index=2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | Block(96) | uSID1(32) | index=3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Figure 5: segment list encoding example B
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 | List ID=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | Index=3 | Range=1 | BL=96 |ST=0001|count=1| Basic Compressed Description Unit 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - | Index=2 | Range=2 | BL=0 |ST=0001|count=4| Basic Compressed Description Unit 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Figure 6: Segment List Recover TLV encoding example B
When restoring the path, the node will save the prefix used in the current carrier, and stich the prefix, each short SID and possible padding into a complete 128-bit address. If BL in the next Basic Compressed Description Unit is not 0, it indicates that there's a new prefix, and the node will replace the previous prefix with the new prefix, and continue the processing. If BL is 0 as in unit 2 showed in figure 6, the previous prefix will still be used.
SRH may also be used carry short SIDs without any prefix information. In this case, when the node recovers segment list, it may obtain the prefix from the source IP of the IPv6 header.
In the mapping method, the short SID is no longer part of the complete 128-bit address, unlike shifting or stitching.
Stitching is supported in [I-D.mirsky-6man-unified-id-sr].
For the compression proposal using the mapping mode, option A can be used to restore the segment list.
The node need to maintains the mapping between the list ID and the path information. Upon receiving the packet, the node identifies the path corresponding to the SRH according to the list ID carried in the SRH TLV. The list ID can be assigned by a centralized controller or by a node locally.
This will be further discussed in a future version of this document.
The security requirements and mechanisms described in [RFC8402] and [RFC8754] also apply to this document.This document does not introduce any new security vulnerabilities.
TBD
[I-D.decraene-spring-srv6-vlsid] | Decraene, B., Raszuk, R., Li, Z. and C. Li, "SRv6 vSID: Network Programming extension for variable length SIDs", Internet-Draft draft-decraene-spring-srv6-vlsid-03, March 2020. |
[I-D.li-spring-compressed-srv6-np] | Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., Guichard, J., Cong, L. and S. Peng, "Compressed SRv6 Network Programming", Internet-Draft draft-li-spring-compressed-srv6-np-02, February 2020. |