SRH TLV Processing Programming

Segment routing (SR) 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. When segment routing is deployed on the IPv6 data plane, it is called SRv6 . For support of SR, a new routing header called Segment Routing Header (SRH), containing a list of segments, optional TLVs and other information, has been defined in . Currently, when TLVs are carried in an SRH, they are ignored by the nodes by default, unless there are some local policies on nodes to enable the SRH TLV processing . When a node is configured to process a TLV, it needs to examine all the SRH TLVs for processing a single TLV (TLVs except HMAC in SRH MAY appear in any order), which is inefficient. Furthermore, in order to deploy a new service, network operators need to configure multiple nodes along the path to support SRH TLVs processing, which is complicated. Also, it is not easy to dynamically adjustment the local policy for meeting dynamic service requirements. However, SRv6 does not have the compability to program the rules of SRH TLVs processing on the ingress node currently. In summary, network operator are not able to program the SRH TLV processing rules on the ingress node to process specific TLVs on specific segment endpoint nodes for some packets dynamically. This document proposes a mechanism to program the SRH TLVs processing rules explicitly and dynamically on the ingress node. In this mechanism, there is no need to configure nodal local policy to support SRH TLV processing. It can be used for the following use cases: Service Function Chaining (SFC): In SFC, SRH TLVs like Firewall related TLVs may only be processed on some specific nodes instead of all the nodes along the path. Smart In-situ OAM (IOAM): In IOAM, the IOAM metadata will be collected by all the nodes along the path. However, in the most cases, only the metadatda on some nodes are important for OAM, while the others are redundant or irrelevant. For example, congestion may occur only on some nodes, not all nodes. In addition, congestion may occur on link A at the last moment and may occur on link B at the next moment. To implement smarter and more efficient IOAM, the scope of IOAM metadata collection needs to be dynamically adjusted (without modifying the segment list) based on the result of IOAM measurement to reduce unnecessary IOAM information collection.

This document makes use of the terms defined in , and the reader is assumed to be familiar with that terminology. This document introduces the following terms: TPI: TLV Processing Indicator

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 BCP 14 when, and only when, they appear in all capitals, as shown here.

This document defines a new flavor in SRv6 to indicate the SRv6 endpoint node to process SRH TLVs. Also, this document defines an SRH TLV processing rule TLV in SRH to describe how to process the TLV on SRv6 endpoint nodes.

Currently, SRv6 endpoint nodes will ignore the SRH TLV if there is no local policy to enable processing. When receives an SRv6 packet, in order to explicitly indicate to process SRH TLVs, a TLV Processing Indicator (TPI) Flavor is defined in this document. By default, the node should ignore the SRH TLV. With TPI flavor, SRH TLV processing can be triggered by TPI flavor SID without local configuration. When a TPI flavor SID is processed at an SRv6 node, the node MUST process the SRH TLVs. Otherwise, the SRH TLVs SHOULD be ignored by default or processed based on the local policies as per .

When an SRv6 endpoint node receives an SRv6 packet with SRH TLVs, it will process all the TLVs within the SRH, but actually only some TLVs should be processed at this node while most of the TLVs SHOULD be skipped. For example, SRH "S-class" and "D-class" TLVs are processed at Firewall node only and they SHOULD NOT be processed at other nodes along the path. In order to enhance the performance of SRH TLV processing, this section defines TLV processing Indicator (TPI) TLV to describe how to process the SRH TLVs. If the TPI TLV appears in SRH, it MUST be the first TLV for better processing efficiency. Only one TPI TLV is allowed in SRH. If multiple TPI TLVs are included, only the first TLV will be processed and the rest will be ignored. If Its format is shown below. [Editor's notes] This part may be moved to 6man draft in the future since this is an IPv6 dataplane extension.

Type: type of TPI TLV, TBA. The TLV MUST be ignored if the node does not have the capability to process the TPI TLV. Length: Length of the TPI TLV. Bitmap Length: The length of Bitmap in a TLV Processing Indicator (TPI) entry, in byte. For instance, if there are 6 TLVs (exclude TPI TLV) within the SRH, the length of Bitmap is 1 bytes. If there are 12 TLVs within the SRH (exclude TPI TLV), the length of Bitmap is 2 Bytes. TPI Left: Index of the active TPI entry in the TPI TLV. TLV Processing Indicator: A TLV Processing Indicator indicates how to process the SRH TLVs at a specific node associated with the SID in SRH[TPI.SL]. An TPI TLV can include multiple TPI entries to specify the processing rules on multiple nodes. The length of a TPI entry is variable depends on the length of the bitmap. Segment Left: Segment Left (SL) is the key of a TPI entry, which indicates the node associated with SID in SRH[TPI.SL] needs to process the SRH TLVs according to the TPI entry. When a node processes the TPI TLV, it examines the TPI entry located at TPI-List[TPI Left]. If the value of SRH.SL is equivalent with TPI-List[TPI Left].SL, the node MUST process the SRH TLVs based on the TPI entry, and decrement TPI Left by 1 if TPI Left is greater than 0. If the value of SRH.SL is not equivalent, the processing of the SRH TLVs is skipped. Bitmap: The bitmap indicates which SRH TLVs are needed to be processed on the node associated with SRH[TPI.SL]. Setting the nth bit means the (n+2)th SRH TLV is required to be processed, since the first TLV in SRH MUST be the TPI TLV and the index of the bitmap begins with 0. For instance, If the second TLV (the First TLV after the TPI TLV) in the SRH is needed to be processed on the node, the first bit (bit 0) in the bitmap is set. If the second TLV and the sixth TLV are needed to be processed, the bit 0 and bit 4 are set in the bitmap. Multiple TPI Entries are encoded after the first 32 bits in TPI TLV following the descending order of SL in TPI entries. [Editor's notes: The TPI TLV MUST be the first TLV in SRH, therefore, the HMAC TLV should be the second one, this may require to update ].

In order to easy understanding, this section describes a simple example. The topology is shown in Figure 3. For instance, an SRv6 packet is forwarded from node 1 to node 6. Therefore, <SID2, SID3, SID4, SID5, SID6> is encoded in the SRH. According to the sevice requirements, the SID3 and SID6 are TPI flavor SID, which indicate the nodes to process SRH TLVs. 4 TLVs are encoded in the SRH, TLV 1 and TLV2 will be processed at node 3, while the TLV3 and TLV 4 will be processed at node 6. Other nodes are not required to process any SRH TLVs of this packet. In the SRH TLV fields, a TPI TLV and the other 4 TLVs are encoded, and the TPI TLV is the first TLV. The value of bitmap length field is 1 since there are only 4 TLVs (TPI TLV is excluded) in the SRH. Two TPI entries are encoded after the first 32 bits in TPI TLV. The length of each TPI entry is 2 bytes, 1 byte for SL and 1 byte for the bitmap. The first TPI entry (TPI-List[0]) describes the SRH TLV processing rules on node 6, and its SL is 0. The bit 2 and bit 3 are set in its bitmap to indicate to process the TLV3 and TLV 4. The last TPI entry (TPI List[1]) describes the SRH TLV processing rules on node 3, and its SL is 3. The bit 0 and bit 1 are set in its bitmap to indicate to process the TLV1 and TLV 2.

The TPI Left is initiated as 1 at node 1, and the encoding of TPI TLV in the case is shown below.

<- Last TPI Entry -> Figure 4. Instantiation of TPI TLV at node 1 ]]> When the packet is received at node 2, the SRH TLVs are skipped by default. When the packet is received at node 3, the SRH TLVs are processed because the SID3 is a TPI floavor SID allocated by node 3. When the node 3 processes SRH TLVs, the first TLV to be processed is the TPI TLV. Node 3 compares the TPI-List[TPI Left].SL and SRH.SL, if they are equivalent, the node 3 processes the TLV 1 and TLV 2 according to the bitmap and updates the TPI Left to be 0. When the packet is received at node 4, the SRH TLVs are skipped by default. When the packet is received at node 5, the SRH TLVs are skipped by default. When the packet is received at node 6, the SRH TLVs are processed because the SID6 is a TPI floavor SID allocated by node 6. When the node 6 processes SRH TLVs, the first TLV to be processed is the TPI TLV. Node 6 compares the TPI-List[TPI Left].SL and SRH.SL, if they are equivalent, the node 6 processes the TLV 3 and TLV 4 according to the bitmap. The TPI Left will not be updated because it is 0 already.

TBD