Add support for TLV objects in the Segment Routing Header

[zeeshanlakhani]

Background

TLV (Type Length Value) entries contain optional information that may be used by the node identified in the destination address packet. We currently support all components of the Segment Routing Header except for TLV entries. TLVs are particularly useful for HMAC (The keyed Hashed Message Authentication Code) verification/security. PAD-support (related to alignment) is necessary to the implementation.

---

From the RFC:

A TLV provides meta-data for segment processing. The only TLVs defined in this document are the HMAC and PAD TLVs. While processing the SID defined, all TLVs are ignored unless local configuration indicates otherwise. Thus, TLV and HMAC support is optional for any implementation, however, an implementation adding or parsing TLVs MUST support PAD TLVs. Other documents may define additional TLVs and processing rules for them.

TLVs are present when the Hdr Ext Len is greater than (Last Entry+1)*2.

While processing TLVs at a segment endpoint, TLVs MUST be fully contained within the SRH as determined by the Hdr Ext Len. Detection of TLVs exceeding the boundary of the SRH Hdr Ext Len results in an ICMP Parameter Problem, Code 0, message to the Source Address, pointing to the Hdr Ext Len field of the SRH, and the packet being discarded.

An implementation MAY limit the number and/or length of TLVs it processes based on local configuration. It MAY:

• Limit the number of consecutive Pad1 (Section 2.1.1.1) options to1. If padding of more than one byte is required, then PadN should be used.
• Limit the length in PadN to 5.
• Limit the maximum number of non-Pad TLVs to be processed.
• Limit the maximum length of all TLVs to be processed.

The implementation MAY stop processing additional TLVs in the SRH when these configured limits are exceeded.