Readable Label Depth (RLD) in MPLS

• Readable Label Depth (RLD) is a constraint on the number of MPLS label stack entries a node can inspect at line rate, directly tied to hardware parser resources.
• The MNA framework inflates RLD requirements by mandating pre-reservation for maximum-sized NAS entries, linking protocol semantics to physical parser budgets.
• The HBH preservation mechanism reorders label stacks to keep critical network actions at shallow depths, reducing in-between parsing overhead and enhancing performance.

Searching arXiv for the specified paper and closely related work on MPLS Network Actions and readable label depth. Readable Label Depth (RLD) is a depth constraint on structured label representations, most explicitly defined in the context of MPLS Network Actions (MNA) as “the number of Label Stack Entries (LSEs) a node can read without performance impact and [which] results from the available hardware resources.” In that setting, RLD links protocol semantics to parser budgets, ASIC pipeline width, and line-rate feasibility: an MNA-capable node can only process network actions that lie within its readable portion of the MPLS stack (Ihle et al., 21 Jul 2025). A broader, interpretive use of the term appears in work on logarithmic-depth multi-label trees, where the practically relevant depth is the number of decisions needed to reach a label prediction; that paper does not define RLD explicitly, but it motivates a depth-as-readability perspective in which shallow, balanced hierarchies reduce the amount of structure that must be traversed before a label becomes actionable (Majzoubi et al., 2019).

1. Definition, physical basis, and protocol context

In MPLS, the label stack is a sequence of LSEs, each 4 bytes, parsed from the top of stack downward. RLD is the bounded number of such entries that a router can inspect at line rate without performance impact. The bound is determined by physical resources such as parsing memory, TCAM or ASIC pipeline budget, header-vector width, extraction buses, and pre-allocated header arrays in P4 or ASIC implementations. If a forwarding label or a Network Action Sub-stack (NAS) lies deeper than the RLD, the node cannot see or process it at line rate (Ihle et al., 21 Jul 2025).

Within the MNA framework, network actions are encoded as in-stack data (ISD) LSEs arranged into a NAS. MNA also supports Post-Stack Data (PSD), but the paper under discussion focuses on ISD. A NAS is minimally 2 LSEs and maximally 17 LSEs long, and multiple NAS instances can appear in a single stack with different scopes. A select-scoped NAS is processed by one specific node only, is placed below that node’s forwarding label, and must be popped after processing. A hop-by-hop (HBH)-scoped NAS is intended to be processed by every node on the path and should not be removed by intermediate nodes. The MNA drafts conceptually place HBH NAS at the bottom of stack so that it becomes visible as labels are popped, but the paper shows that this idealization collides with realistic RLD limits when stacks become large (Ihle et al., 21 Jul 2025).

The operational significance is that RLD is not an abstract parser preference but a hard deployment constraint. Each node advertises its RLD to the ingress using routing protocols such as IS-IS or OSPF, allowing the ingress to avoid constructing stacks that exceed downstream readability. This makes RLD a first-class capability parameter in MNA-capable networks (Ihle et al., 21 Jul 2025).

2. Why MNA inflates RLD requirements

The paper identifies the source of high RLD demand in the protocol structure of MNA rather than in any specific implementation. A node that supports both select-scoped and HBH-scoped NAS must reserve parsing resources for a maximum-sized select NAS, a maximum-sized HBH NAS, and the forwarding label at the top of the stack. Because the HBH NAS may be located below unrelated entries, the node must also parse an intervening “in-between stack” of labels and NAS entries that are irrelevant to the current hop but still consume readability budget (Ihle et al., 21 Jul 2025).

The quantitative relation is given by:

$$\begin{aligned} \text{maxLSEs}^{btwn}_{stack} = RLD &- \text{maxLSEs}^{select}_{NAS} \ &\quad - \text{maxLSEs}^{HBH}_{NAS} - 1. \end{aligned}$$

Here, $\text{maxLSEs}^{select}_{NAS} = 17$, $\text{maxLSEs}^{HBH}_{NAS} = 17$, and the $-1$ accounts for the top-of-stack forwarding label. With $RLD = 51$, the paper gives $$\text{maxLSEs}^{btwn}_{stack} = 51 - 17 - 17 - 1 = 16$$ LSEs. In other words, 34 LSEs are pre-committed to the two maximum-sized NAS, one LSE to the current forwarding label, and only 16 LSEs remain for everything between the current label and the HBH NAS (Ihle et al., 21 Jul 2025).

This decomposition exposes the structural source of the problem. The node must provision for potentially large, semantically irrelevant depth simply because the HBH NAS does not have a fixed shallow position. The paper states this directly: “The need for resource allocation of an in-between stack originates from the protocol design of the MNA framework and is not specific to the implementation.” A common misconception is therefore that large RLD is merely an artifact of a P4 realization or a particular ASIC target; the paper argues that the inflation arises from how MNA places and scopes in-stack actions (Ihle et al., 21 Jul 2025).

3. Hardware model and implementation-level manifestation

The hardware analysis is based on a P4 implementation targeting the Intel Tofino 2 switching ASIC. In that model, parser-visible MPLS structures are represented as header stacks that must be sized a priori. The implementation therefore allocates distinct arrays for a select-scoped NAS, an HBH-scoped NAS, and the in-between stack. Under the assumed platform with $RLD = 51$, the allocated capacity corresponds to 17 LSEs for the select NAS, 17 LSEs for the HBH NAS, 1 LSE for the top forwarding label, and 16 LSEs for the in-between stack (Ihle et al., 21 Jul 2025).

Two consequences follow immediately. First, RLD is a hard cap on total parseable header-array capacity. Second, because maximum NAS sizes are fixed by the MNA drafts, support for ordinary forwarding labels and additional network-action placement becomes constrained unless RLD is already quite large. The ingress may even need to insert copies of the HBH NAS at multiple positions so that each downstream node encounters at least one copy within its RLD, which further increases stack size and intensifies RLD pressure (Ihle et al., 21 Jul 2025).

This implementation analysis is significant because it grounds the protocol discussion in concrete parser economics. The bottleneck is not only the total stack size in bytes, but also the need to pre-reserve parser state for worst-case NAS lengths plus variable intervening depth. The paper therefore connects RLD to a broader design principle: protocol structures that require deep parsing of irrelevant stack entries are intrinsically costly on high-speed programmable forwarding hardware (Ihle et al., 21 Jul 2025).

4. HBH preservation and the stack management network action

The central mechanism proposed to reduce RLD is the HBH preservation mechanism, enabled by a novel stack management network action. Its purpose is to eliminate the need for an in-between stack by keeping the HBH-scoped NAS at a fixed shallow position. Specifically, at any MNA-capable node, the HBH NAS is kept directly below the top-of-stack forwarding label. When the current top label is popped, the node moves a forwarding label from below the HBH NAS to the top of stack. The HBH NAS is therefore never exposed at the top and remains available for subsequent nodes (Ihle et al., 21 Jul 2025).

The significance of this reordering is immediate: the HBH NAS is always at known small depth, directly under the current forwarding label, and no scan through an unknown number of LSEs is required. As a result, the in-between stack array is no longer required for HBH processing. The paper realizes this behavior through the stack management network action, which instructs a node to move the next $n$ forwarding labels from below the NAS to the top of stack whenever the node pops its current top forwarding label. If the forwarding label is not popped, no action is taken (Ihle et al., 21 Jul 2025).

The action is parameterized by scope. In an HBH-scoped NAS, the parameter is $n_{HBH}$; in a select-scoped NAS, it is $n_{Select}$. When both are processed at the same node, the total number of labels moved upward is

$\text{maxLSEs}^{select}_{NAS} = 17$0

Each stack management action consumes one LSE inside a NAS. The paper illustrates this with a path containing nodes $\text{maxLSEs}^{select}_{NAS} = 17$1, where $\text{maxLSEs}^{select}_{NAS} = 17$2 and $\text{maxLSEs}^{select}_{NAS} = 17$3 are MNA-incapable. The ingress installs an HBH-scoped NAS with $\text{maxLSEs}^{select}_{NAS} = 17$4 for HBH preservation and a select-scoped NAS for $\text{maxLSEs}^{select}_{NAS} = 17$5 with $\text{maxLSEs}^{select}_{NAS} = 17$6 so that, at $\text{maxLSEs}^{select}_{NAS} = 17$7, three forwarding labels are moved upward in total. The select-scoped NAS is then popped, while the HBH NAS remains just below the top label and survives transit across legacy nodes (Ihle et al., 21 Jul 2025).

The mechanism changes the placement problem from “how deeply must a node parse to find the HBH NAS?” to “how many labels might a node need to bring upward at once?” That shift is what enables the reduction in required RLD (Ihle et al., 21 Jul 2025).

5. Integration with legacy nodes, revised RLD bounds, and packet-level effects

The paper explicitly addresses coexistence with MNA-incapable MPLS nodes and with MNA-capable nodes of limited hardware capability. Without additional handling, a legacy node that pops its forwarding label may expose the MNA indicator at the top of stack and then fail to process it, causing subsequent nodes to treat it as an invalid label and potentially drop the packet. Because each node’s MNA capability is signaled to the ingress, the ingress can encode stack management parameters so that the node preceding a legacy region moves enough labels upward in advance. The legacy nodes then see only ordinary MPLS labels on top and never expose the NAS themselves. This permits incremental deployment without requiring transit nodes to maintain per-neighbor capability logic; the control is carried in the NAS constructed by the ingress (Ihle et al., 21 Jul 2025).

The reduction in RLD is summarized by a new lower bound:

“The required minimum RLD using the HBH preservation mechanism is $\text{maxLSEs}^{select}_{NAS} = 17$8 LSEs where $\text{maxLSEs}^{select}_{NAS} = 17$9. Two maximum-sized NAS with 17 LSEs each, one label for forwarding, and at least one label after the NAS are contained in the RLD. The parameter $\text{maxLSEs}^{HBH}_{NAS} = 17$0 corresponds to the number of LSEs that needs to be brought to the top at once, e.g., the maximum number of consecutive MNA-incapable nodes in a network.”

The constant 35 LSEs is the absolute minimum implied by the MNA drafts themselves: 17 LSEs for a select NAS, 17 LSEs for an HBH NAS, and 1 forwarding label. The mechanism does not remove this inherent cost; it removes the additional cost of provisioning for an arbitrary in-between stack (Ihle et al., 21 Jul 2025).

The packet-level side effects are limited but explicit. Each stack management action adds one LSE, or 4 bytes. A packet carrying an HBH-scoped NAS therefore incurs one extra LSE for the HBH stack management action, and a packet that also needs backward compatibility across legacy regions may incur an additional one-LSE action in a select-scoped NAS. The paper characterizes this overhead as negligible relative to MPLS encapsulation and notes that hardware array allocation is dominated by the maximum 17-LSE NAS size rather than by the specific set of actions present (Ihle et al., 21 Jul 2025).

A further operational concern is ECMP. Reorganizing the MPLS stack changes label positions and could, in principle, alter hash inputs. The paper’s position is that if the HBH preservation mechanism is applied coherently and consistently to all packets, the resulting stack structure is deterministic and ECMP load balancing is not disturbed in practice (Ihle et al., 21 Jul 2025).

6. Feasibility on programmable hardware and broader interpretations of depth

The proposed mechanism is implemented in P4 on Intel Tofino 2 by extending a prior P4-based MNA implementation. The data plane inspects the MPLS header stack and, when the top forwarding label is popped, performs the label reordering mandated by the stack management parameters. The implementation operates at 400 Gb/s per port at line rate. This establishes that RLD-aware HBH preservation is not merely a control-plane construction but can be realized on current high-speed programmable ASICs. Legacy MPLS hardware that supports only push, pop, and swap cannot itself execute stack management, but it can be safely traversed when adjacent MNA-capable nodes are programmed to skip it (Ihle et al., 21 Jul 2025).

A broader, cross-domain interpretation of RLD can be inferred from logarithmic-depth multi-label decision trees. In LdSM, the tree depth is of size $\text{maxLSEs}^{HBH}_{NAS} = 17$1 for an $\text{maxLSEs}^{HBH}_{NAS} = 17$2-ary tree, and prediction complexity per example is $\text{maxLSEs}^{HBH}_{NAS} = 17$3. The paper does not define Readable Label Depth explicitly, but it argues that logarithmic-depth traversal keeps paths short and efficient; empirical deepest tree depths fall between roughly $\text{maxLSEs}^{HBH}_{NAS} = 17$4 and $\text{maxLSEs}^{HBH}_{NAS} = 17$5 or $\text{maxLSEs}^{HBH}_{NAS} = 17$6 on multiple datasets, and increasing tree size beyond moderate depth yields less than 3% gain in precision or nDCG (Majzoubi et al., 2019).

This suggests a useful abstraction: in both MPLS MNA and extreme multi-label trees, “readability” is constrained by how much structured label state must be inspected before the relevant semantics become available. In MPLS, the constraint is physical parser depth. In logarithmic-depth label trees, the analogous constraint is decision depth. The common principle is that predictable shallow placement—or, in tree terms, balanced logarithmic depth—reduces the amount of irrelevant structure that must be traversed before useful processing can occur (Majzoubi et al., 2019).

7. Conceptual significance and relation to adjacent work

The paper’s broader claim is that RLD must be treated as a first-class design constraint in MPLS extension work. Protocols that assume arbitrarily large readable depth are misaligned with parser realities. The HBH preservation mechanism therefore serves as a specific demonstration of a more general design rule: key semantic structures should remain at predictable shallow positions, and in-stack metadata can be used not only to encode application logic such as slicing or in-situ OAM, but also to coordinate stack structure itself (Ihle et al., 21 Jul 2025).

The authors also distinguish their contribution from prior work on reducing MPLS stack size through improved path-label encoding. Those approaches reduce the number of forwarding labels, but they do not address the additional RLD burden created by MNA’s NAS structure. The contribution here is narrower and more structural: it targets the readability cost of network-action placement rather than forwarding-label compression (Ihle et al., 21 Jul 2025).

A final misconception addressed by the paper concerns the source of the minimum bound. The value $\text{maxLSEs}^{HBH}_{NAS} = 17$7 is not evidence that the proposed mechanism remains parser-intensive by design choice; rather, 35 LSEs is described as an absolute minimum dictated by the MNA drafts themselves, while the additional $\text{maxLSEs}^{HBH}_{NAS} = 17$8 captures only the largest number of labels that may need to be moved upward at once, such as when traversing a maximal run of consecutive MNA-incapable nodes. The mechanism therefore reduces avoidable RLD overhead but does not repeal the intrinsic worst-case NAS size specified by MNA (Ihle et al., 21 Jul 2025).