Multi-purpose Special Purpose Label for Forwarding Actions

Base Special Purpose Labels (bSPLs) , , are a precious commodity; there are only 16 such values, of which 8 have already been allocated. There are currently five requests for bSPLs that the authors are aware of; this document proposes another use case for a bSPL, in all consuming nearly all the remaining values. This document suggests a method whereby a single bSPL can be used for all the purposes currently requested. This leads to perhaps the more valuable long-term contribution of this document: an approach to the definition and use of bSPLs (and SPLs in general) whereby a single value can be used for multiple purposes, and provide a flexible yet efficient means of carrying associated data.

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. Forwarding Actions Indicator In-Stack Data Standard ISD User-Defined ISD In-Stack Data Header Label stack entry Post-Stack Data Special-purpose label Base special-purpose label

This section (to be removed before publication) offers highlights from the draft’s revision history.

This section added. Added a section discussing when data should be put in the LS FAD vs in the PL FAD. Tweaked the bits in the FAI. Added a field “edist”. Elaborated on the use of the H bit and the FAH data. Updated the processing of the LS FAD. Added processing of edist. Updated the FAI example. Updated the Issues section.

Updated Abstract and Introduction to focus on FAI; moved description of use cases to separate section. Added terminology. Changed terminology: LS FAD and PL FAD to ISD and PSD, respectively. Updated text on criteria for putting associated data in ISD. Introduced the terms FAI Block, FFB Block, sISD Block and uISD Block. Introduced an “end of block” bit, s. Updated flag bits; updated processing of ISD. Removed field edist. Updated the section on preventing the FAI from reaching the Top of Stack. Updated the section on Readable Stack Depth

Separated the discussion of the LSE format from the flag definitions. Replaced continuation bits with explicit length fields for easier parsing.

This document proposes the use of a single bSPL to tell routers one or more forwarding actions they should take on a packet, e.g.: to treat a packet according to its flow-aggregate, given its G-FAS; to load balance a packet, given its entropy; whether or not to perform fast reroute on a failure ; whether or not a packet has metadata relevant to intermediate hops along the path; and perhaps other functions in the future. This bSPL is called the “Forwarding Actions Indicator” (FAI). There are other suggestions for this name, including “Network Functions Indicator” and “Network Actions Indicator”. We’ll let WG consensus determine the final choice of name, but for now, we’ll continue to use FAI. The FAI uses the label’s TC bits and TTL field to inform the forwarding plane of the required actions. Each of these actions may have associated data. This data may be carried in the label stack as “In-Stack Data” (ISD) or after the label stack as “Post-Stack Data” (PSD).

The design of the bSPL hinges on two key insights: forwarding engines do not interpret the TC bits or the TTL field for labels that are not at the top of the label stack (ToS); nor do they do so for SPLs. For non-ToS labels, the important bit fields are the label value field (to compute entropy and identify SPLs) and the End of Stack (S) bit (to know when the label stack ends). [If you know of a forwarding engine that looks at other bit fields of labels below the ToS, please contact the authors.] This means that for a bSPL that will never appear at the ToS, the TC bits and the TTL bits can be used to carry additional information. Furthermore, for the ISD, the entire 4-octet label stack entry, the S bit excepted, can be used to carry data. We use this technique to make the FAI bSPL multipurpose, and to make the ISD words compact and efficient.

A pertinent question is when one should put data in the ISD versus in the PSD. One alternative is to put all such data in the PSD. However, this would mean that accessing such information would require finding the End of Stack, and parsing the PSD. For certain types of data, this would be a severe burden on the packet forwarding engine. Examples of such data are the Entropy label (needed for efficient load balancing) and the G-FAS (needed for accurate packet forwarding). Having any of this data in the PSD would hurt forwarding performance. This memo suggests that data that is required for accurate and optimal forwarding should be put in the ISD, and data that is optional from a forwarding point of view should be put in the PSD. Furthermore, each flag bit should have no more than one word of associated ISD. The EG flag can thus have up to 2 words of associated data. By the above criteria, this memo suggests that in-situ OAM data and the Flow ID be carried in the PSD.

The format of a label stack that includes an FAI has the structure:

The flags and data associated with the FAI come in three forms: Forwarding Actions Flags and Data; these flags are in the FAI LSE. These are defined in this document. Standard In-Stack Flags and Data; these flags are in the In-Stack Data Header. These MUST be defined in a Standards-track document. User-defined In-Stack Flags and Data; these flags are also in the In-Stack Data Header. These are perforce user-defined and not subject to standardization. The format of the PSD is out of scope for this document.

The format of the FAI LSE is:

The FAI LSE’s label value MUST be the IANA allocated value. The remaining fields are defined as follows: In-Stack Data Header (ISDH) is present (1) or not (0). If set, the PSD contains hop-by-hop information. Every node in the path SHOULD attempt to process the hop-by-hop information, but not at the expense of exceeding the processing time budget, which could cause this (or other) packet(s) to be dropped. If clear, no hop-by-hop data exists in the PSD: either the PSD is empty, or it contains only end-to-end data (to be processed by the egress). Reserved for future use (SHOULD be ignored by receivers). MUST be set if the FAI LSE is the end of stack, and clear otherwise. Each bit in the Flags field represents a forwarding action. Except for the flags defined herein, the semantics of a forwarding action are out of scope for this document. Each flag is allocated from the Forwarding Actions Flag Registry and is assigned an index. Flag indices 0 to 2 correspond to bits 24 to 26 within the FAI LSE. Flags continue into the In-Stack Data Header, if present. This is the total size of the FAI block, i.e., the FAI LSE and all associated data, in four-octet words.

If the I flag is set, the label stack contains an In-Stack Data Header (ISDH) following a FAI LSE. The format of the ISDH is:

The fields in the Forwarding Actions Header are: This is the size of the Standard ISD (sISD) in four-octet words. This is a continuation of the Flags field from the preceeding FAI LSE, i.e., flag indices 3 to 15 correspond to bits 5 to 17 in the ISDH. This is the size of the user-defined ISD (uISD) in four-octet words. MUST be set if the ISDH is the end of stack, and clear otherwise. These correspond to user-defined flags, and are not subject to standardization.

This document defines the following Forwarding Action Flags.

0 None If set, do not perform fast re-route on this traffic.

These are two flags that have joint semantics: 1, 2 0, 1, or 2 ISD LSEs, depending on the values of the flags: No Entropy or G-FAS present ISD 0 contains 16 bits of Entropy in the high order 16 bits and 15 bits of G-FAS in the low order 16 bits (S bit excepted). ISD 0 contains 20 bits of Entropy in the high order 20 bits and 11 bits of G-FAS in the low order 12 bits (S bit excepted). ISD 0 contains the 31-bit Entropy; ISD 1 contains the 31-bit G-FAS. In ISD 0, the S bit MUST be 0; the packet forwarding engine may choose to use the S bit as part of the Entropy, as it doesn’t affect the outcome. In ISD 1, the S bit may be 0 or 1.

Here’s how the Standard ISD is parsed. One must keep track of Ssize to know when the Standard ISD data ends, and the S bit to know when the stack ends. The Standard ISD data appears in the order of the corresponding flags. It is an error if the label stack ends while there are more ISD words to process. Set CL (“current label”) to the FAI label. LL is the last label (End of Stack); PL (“payload”) is the first 4-octet word of the payload. If I is 0, there is no associated ISDH; set Ssize = Usize = 0. Otherwise, note the values of Ssize and Usize; increment CL. Process Forwarding Actions Flags and Data: Process N. CL is unchanged. Process EG: If EG is 00, CL is unchanged. If EG is 01 or 10, increment CL. CL now contains both G-FAS and Entropy. If EG is 11, CL+1 contains Entropy; CL+2 contains G-FAS. Increment CL by 2. If I == 1, process sISD Flags; increment CL by 1 for each (upto Ssize; skip any remaining sISD Flags once Ssize LSEs have been processed). If I == 1, process uISD Flags; increment CL by 1 for each (upto Usize). Note that how the uISD is used is not defined here; this is up to the user. All that is included here is how a forwarding engine can tell the size of uISD.

The real payload starts after the PSD.

This section captures issues to be resolved, in this memo and others. As the issues are fixed, they should be removed from here; ideally, this section should be empty before publication.

As was said earlier, the FAI MUST NOT be at the top of stack, since its TC and TTL bits have been repurposed. There are two ways to prevent this. If an LSR X pops a label and the next label is the FAI, X MUST pop Tsize LSEs to remove the FAI LSE and associated data. This implies that the LSR MUST be able to recognize the FAI LSE and at least parse the Tsize field. This can be used in conjunction with . In case it is desired to preserve the FAI+FAD until the egress, X should push an explicit NULL (label value 0 or 2) onto the stack above the FAI, with the correct TC and TTL values. Other options may be pursued; however, we believe this is an adequate resolution.

For LSRs which cannot parse the entire label stack, or would prefer not to unless needed, it is possible to repeat the FAI at “readable stack depth” (rsd). Say the rsd is 10 LSEs, and the FAI block contains 3 LSEs. Then, the FAI block can be repeated every 7 labels, allowing all forwarding engines in the path to process it. When a forwarding label is popped and the FAI block exposed, it is deleted in its entirety, since the same (or potentially different) FAI block is again within the rsd. Other options were considered in , Section 10, and are discussed briefly in .

Currently, CW, … The format of the PSD, whether or not a Control Word is present, and handling of the first nibble, is outside the scope of this document. The FAI will not contain details about the contents of the PSD, besides the single flag on whether or not the PSD contains information relevant to (most) intermediate hops. It is assumed that another memo will document the format of the PSD, and that that memo will provide a means of parsing the PSD (e.g., a TLV structure) and thus determining its contents. The PSD memo should also comment on the impact of processing the PSD on forwarding performance, especially in the case of hop-by-hop info.

Network slicing is an important ongoing effort both for network design, as well as for standardization, in particular at the IETF . A key issue is identifying which slice a packet belongs to, by means of a “slice selector” carried in the packet header. describes several such methods for MPLS networks, of which the Global Identifier for Flow-Aggregate Selector (G-FAS) is one of the more practical solutions. This document shows how to realize the G-FAS using a base special purpose label (bSPL). In MPLS networks, a G-FAS is a data plane construct identifying packets belonging to a slice aggregate (the set of packets that belong to the slice). The G-FAS dictates forwarding actions for the slice aggregate: QoS behavior and next hop selection. The purpose of the G-FAS is detailed in . To embed a G-FAS in a label stack, one must preface it with a bSPL identifying it as such. For reasons that will become apparent, this bSPL is called the Forwarding Actions Indicator (FAI).

Many thanks to Colby Barth, Chandra Ramachandran and Srihari Sangli for their contributions to this draft.

We’d like to acknowledge the helpful discussions with Swamy SRK and folks from the Broadcom team on the impacts to existing and future forwarding engines.

If this draft is deemed useful and adopted as a WG document, the authors request the allocation of a bSPL for the FAI. We suggest the early allocation of label 8 for this.

A new registry is needed for the allocation of the Forwarding Action flags. This registry should be called the “Forwarding Action Flags Registry” within the “Multiprotocol Label Switching Architecture (MPLS)” protocol registry. The policy for allocating new flags is Standards Action. Each flag MUST have a name, a brief description and the length of the associated ISD. IANA should allocate an index for each flag, starting with zero. The initial contents of the registry should contain: Name Indices Reference No Further Fast Re-Route 0 This document Entropy and Slice information 1, 2 This document

A malicious or compromised LSR can insert the FAI and associated data into a label stack, preventing (for example) FRR from occurring. If so, protection will not kick in for failures that could have been protected, and there will be unnecessary packet loss. Similarly, inserting or removing a Fragmentation Header means that a packet’s contents cannot be accurately reconstructed. Inserting or changing a G-FAS means that the packet will be misclassified, perhaps leaving or entering a high-value slice and causing damage.