| Internet-Draft | IGP for Aggregate Header Limit | August 2024 |
| Liu, et al. | Expires 21 February 2025 | [Page] |
This document proposes extensions for IGP to order to advertise the aggregate header limit of a node or a link on a node to for efficient packet processing. Aggregate header limit is the total header size(e.g, in IPv6, it includes the IPv6 header chain as well as any headers that are part of network encapsulation that precedes the innermost transport layer) that a router is able to process at full forwarding rate, for some devices, this limit is related with its buffer size and buffer design.¶
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 21 February 2025.¶
Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In terms of processing packets, a device has various limits. One of the limits is the aggregate header limit. As described in [RFC8883], some hardware devices implement a parsing buffer of a fixed size to process packets. The parsing buffer is expected to contain all the headers that a device needs to examine. If the aggregate length of headers in a packet exceeds the size of the parsing buffer, a device will either discard the packet or defer processing to a software slow path. [RFC8883] defines one code for ICMPv6 Destination Unreachable that is sent by a node that is unable to process the headers of a packet due to the aggregate size of the packet headers exceeding a processing limit.¶
The introduction of IPv6 extension headers, especially SRH, has increased the total packet header chain size greatly. And the possibility of combination of extension headers packets would make total header size even bigger.¶
The headend node can attach data on the packet. For SRv6 IOAM pre-allocated trace, the headend attachs the hop-by-hop options header with the IOAM data fields ahead of SRH as introduced in [RFC9486]. In the case of SR service programming[I-D.ietf-spring-sr-service-programming], the SRH Opaque Metadata TLV and NSH Carrier TLV may be inserted by the headend. For network slicing purpose, the VTN Option in IPv6 Hop-by-Hop option may be carried in the packet [I-D.ietf-6man-enhanced-vpn-vtn-id]. And all the above functions may be used in combination.¶
The intermediate nodes may increase the header size of the packet either. The IPv6 extension headers, as well as their TLVs may be attached by the intermediate destination nodes(e.g SR Segment Endpoint nodes) via inserting or tunneling. For example, for Binding SID, an SR Segment Endpoint nodes with an End.B6.Encaps/End.B6.Encaps.Red [RFC8986] SID instantiated would push a new IPv6 header with its own SRH containing an segment list above the original IPv6 header. And in the case of TI-LFA [I-D.ietf-rtgwg-segment-routing-ti-lfa], the PLR node may push a repair SID list to the original packet.¶
So for efficient packet processing, in many cases it's very important to obtain the aggregate header limit that the downstream nodes are able to process.¶
As per [RFC8883], an ICMPv6 Destination Unreachable error with code for "Headers too long" SHOULD be sent when a node discards a packet because the aggregate length of the headers in the packet exceeds the processing limits of the node.¶
While sending ICMPv6 messages for aggregate header size limit detecting is a solution, in an SR domain, there may be many nodes(either as headend or intermediate nodes) able to increase the total header size, and the SR path can be dynamic, which makes it not easy for these node to obtain the Aggregate Header Limits of the downstream nodes by sending and processing the ICMP messages. For example, node A is the headend of 2 SR policies, each SR policy is consist of 2 candidate paths, and each candidate path includes 2 segment lists, and each segment list contains 8 segments. For simplicity, assuming that there's no sharing nodes, in this case, node A needs to send at least 64 ICMPv6 massages, on message for each node to obtain the size limit of the downstream nodes.¶
Signaling could be another solution. There're already mechanisms like IGP-MSD to advertise certain size limit at per node and per link basis, for both MPLS/SR-MPLS [RFC8491] [RFC8476] and SRv6 [RFC9352], and the MSD signaling mechanism is not SR-specific. With IGP signaling, the headend as well as intermediate nodes, can get aggregate header limits of all the nodes in the domain, which helps when there're a large amount of paths or the paths are dynamic. Session 4 provides some possible implementation usages with the IGP extension.¶
Based on the considerations above, this document proposes extensions for IGP to order to advertise the aggregate header limit of a node or a link on a node for efficient packet processing.¶
The terminology defined in [I-D.ietf-6man-hbh-processing] and [RFC8491] are used in this document¶
MSD: Maximum SID Depth.¶
Forwarding Plane: Routers exchange user data through the forwarding plane. Routers process fields contained in packet headers. However, they do not process information contained in packet payloads.¶
Control Plane: Routers exchange management and routing information. They also exchange routing information with one another. Management and routing information are processed by its recipient. Management and control information can be forwarded by a router that process fields contained in packet headers.¶
Fast Path: A path through a router that is optimized for forwarding packets. The Fast Path might be supported by Application Specific Integrated Circuits (ASICS), Network Processor (NP), or other special purpose hardware. This is the usual processing path within a router taken by the forwarding plane.¶
Slow Path: A path through a router that is capable of general purpose processing and is not optimized for any particular function. This processing path is used for packets that require special processing or differ from assumptions made in Fast Path heuristics or to process router control protocols used by the control plane.¶
Full Forwarding Rate: This is the rate that a router can forward packets without adversely impacting the aggregate forwarding rate. For example, a router could process packets at a rate that allows it to maintain the full speed on its outgoing interfaces, which is sometimes called "wire speed".¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
[RFC8491] and [RFC8476] define the means to advertise node-/link-specific values for MSDs of various types separately for IS-IS and OSPF, and it's not SR specific. This document leverages the MSD advertising mechanism in IGP.¶
A new "IGP MSD-Type value" code is required for aggregate header size and its value field represents the the total header size that a router is able to process at full forwarding rate. The total header size is the size of headers from ethernet header to any headers that are part of network encapsulation that precedes the innermost transport layer.¶
Editor's note: a) Currently the document leverages the existing IGP-MSD sub-TLV for aggregate header limit advertising by defining a new type of MSD for protocol simplicity. But considering that MSDs are now mainly related with the number of SIDs or labels, it can be further discussed whether defining new types of sub-TLVs is necessary. b) The term "full forwarding rate" is used instead of "fast path" following the definition in [I-D.ietf-6man-hbh-processing].¶
With the IGP extension introduced in this document, how to leverage the aggregate header size limit is implementation specific and the details are out of scope of the document. This section provides some possible usages.¶
For the intermediate nodes, the aggregate header limits helps when it needs to increase the size of the packet header(e.g, inserting/encapsulating headers) that the downstream nodes are expected to process in the data plane, if the downstream limits are exceeded, the node MAY choose to not to use the related feature/function and log an error.¶
For the headend node, it MAY calculate the SRv6 paths with the awareness of the aggregate header limits of all the nodes within the IGP domain. Or when the headend needs to attach extra data along the existing paths, e.g, IOAM data in the HBH header, if the aggregate header limit of the nodes along the path are not sufficient to process the headers(e.g, for intermediate endpoints, it's HBH+SRH), the headend node MAY choose to not to use the related feature/function and log an error.¶
For the controller/PCE, it can collect the aggregate header limits advertised by IGP via BGP-LS for path computing and other management purpose, e.g, whether to enable certain function on certain path or not.¶
It should be noticed that, even with the IGP extension introduced in this document, packet being dropped or sent to slow path due to aggregate header limit exceeding can not be completely avoided. As mentioned in [RFC9098], intermediate nodes/systems may need to process Layer 3 / Layer 4 information to make a forwarding decision. If the header-size-increasing nodes or the controller are not aware of the behavior of these intermediate nodes along the path, the packet forwarding may still be impacted due to aggregate header limit exceeding on them. For example, for an SRv6 segment list A-B-C, there's an intermediate node X between B and C, which is not aware of SRH. In many cases, X may just forward the packets as normal IPv6 packets, but if X would perform DPI and node A is not aware of that, node A may encapsulate an packet with larger header chain size than X is able to process, which would have an impact on the packet forwarding.¶
This document requests that IANA allocate a code point from the "IGP MSD-Types" registry in the "Interior Gateway Protocol (IGP) Parameters" namespace for "Aggregate Header Limit", referencing this document.¶
Security considerations as specified by [RFC8491] and [RFC8476]are applicable to this document.¶
The author would like to thank Tom Herbert, Les Ginsberg and Acee Lindem for their comments.¶