| Internet-Draft | Aggregate Header Limit | February 2024 |
| Liu & Liu | Expires 31 August 2024 | [Page] |
Aggregate header limit(AHL) is the total header size 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 document describes the problems for path calculation and function enablement without the awareness of AHL in SRv6, and the considerations for AHL collection are also included.¶
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 31 August 2024.¶
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.¶
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] proposes the concept "aggregate header limit" to describe this size limit. 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.¶
The introduction of IPv6 extension headers, especially SRH, and some advanced features/functions have increased the total packet header chain size greatly, which may cause inefficient packet processing due to aggregate header limit exceeding.¶
This document describes the problems for path calculation and function enablement without the awareness of AHL, and provides some usecases with AHL, the considerations for AHL collection are also included.¶
The terminology defined in [I-D.ietf-6man-hbh-processing] and [RFC8491] are used in this document¶
MSD: Maximum SID Depth.¶
AHL: Aggregate header limit. It the total header sizethat a router is able to process at full forwarding rate(e.g, at fast path).¶
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.¶
The introduction of IPv6 extension headers, especially SRH, and some further features/functions have increased the total packet header chain size greatly. Following are some possible scenarios that would greatly increase the difficulty of efficient packet processing from the aspects of total header size increasing.¶
Most of the functions mentioned above are not mutually-exclusive, the possibility of combination of extension headers/TLVs would make total header size even bigger. Normally, there're different models/versions of network devices(i.e, switches, routers) from multiple vendors in an operator's network, different devices may have different aggregate header limits and different behaviors after aggregate header limit exceeding. As more and more functions mentioned above are superimposed in the operator's network, packet dropping or rate limiting due to AHL exceeding is a potential risk, which makes it difficult to management the network.¶
Path calculation, whether by the controller or the headend, without the awareness of AHL of the nodes in the network and the prediction on which features would be enabled along the path, may result in a path with nodes with lower AHLs than required. If the controller is aware of aforesaid information, e.g, when calculation certain path for SR Policy, and the controller knows that and per-hop IOAM and network slicing would be enabled for this SR Policy, the controller would leave out the space for HBH header with options for IOAM and VTN-ID and to ensure that the packet header size wouldn't exceed the AHLs of the intermediate segment endpoints along the list.¶
The situation is similar for packet encapsulation triggered by function enablement, whether on the headend or the intermediate nodes, packets may be encapsulated with larger header size than the downstream nodes able to process. If AHL information of the nodes/path can be obtained in advance, when the node needs to attach extra data along the existing path, and the aggregate header limit of the downstream nodes along the path are not sufficient to process the headers, the node may choose to not to use the related function and log an error.¶
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. Base on this definition, obtaining the minimum AHL along the path can be achieved by sending detection messages of certain size and receiving the ICMPv6 error messages.¶
This may work when the network is small, with not many static paths. But there may be some problems in the following scenarios:¶
Signaling could be another option. Considering that there're already mechanisms like IGP-MSD [RFC8491][RFC8476] to advertise certain size limit at per node and per link basis. The mechanism for advertising AHL is similar with IGP-MSD. In the inter-domain scenario, the BGP signaling may helps as well.¶
For the controller, it can get the AHLs of the nodes in the network via BGP-LS, YANG or other south-north mechanisms.¶
The details of signaling mechanism is out of the scope of the document and would be discussed in separated documents.¶
This document makes no request of IANA.¶
TBA¶