Stack Management Network Action in MPLS

• Stack Management Network Action is a mechanism that reorganizes MPLS label stacks to always place the HBH-scoped NAS immediately below the top forwarding label, ensuring reliable in-band action execution.
• It reduces the required parser depth by confining label processing to 35+n LSEs, thereby mitigating hardware constraints and optimizing forwarding performance.
• The design supports mixed-capability networks by enabling selective promotion of forwarding labels to traverse legacy nodes while maintaining ECMP consistency and minimal header overhead.

The Stack Management Network Action is a network action introduced for MPLS Network Actions (MNA) to enable the HBH preservation mechanism: routers restructure the MPLS label stack during forwarding so that hop-by-hop (HBH)-scoped MNA information remains immediately below the current top-of-stack forwarding label. Its purpose is to reduce the readable label depth (RLD) required by MNA-capable nodes, while preserving HBH processing semantics and allowing deployment in paths that include nodes with limited hardware capabilities (Ihle et al., 21 Jul 2025).

1. Position within the MPLS Network Actions framework

MNA extends MPLS forwarding with a generalized encoding for packet-carried processing instructions. In the framework considered here, network actions are carried as in-stack data (ISD) inside the MPLS label stack, grouped into a Network Action Sub-stack (NAS) that reuses the encoding space of MPLS Label Stack Entries (LSEs). A NAS can be as small as 2 LSEs and as large as 17 LSEs, and multiple NAS blocks may appear in one MPLS stack (Ihle et al., 21 Jul 2025).

Two scopes are central to the stack-management problem. A select-scoped NAS is processed only by one designated node; it sits below the forwarding label of its target node and is processed when that label is popped, after which the NAS itself is popped. An HBH-scoped NAS must be processed by every node along a path and therefore must be preserved across forwarding operations. The Stack Management Network Action exists specifically to preserve that HBH-scoped NAS without forcing deep stack parsing at every hop (Ihle et al., 21 Jul 2025).

The relevant hardware constraint is RLD, defined as the maximum number of MPLS LSEs a node can read without performance degradation. MNA matters because its action-carrying LSEs must fall within this readable window to be parsed and executed at line rate. Related MNA implementation work describes the same broader problem as one of header-stacking constraints produced by hardware parser limits and the bounded but potentially large number of action-bearing LSEs in ISD-based MNA (Ihle et al., 2024).

2. The deployment obstacle: deep parsing of irrelevant stack regions

The paper’s diagnosis is that the large RLD requirement in MNA is not only a consequence of NAS size; it is also a consequence of where HBH-scoped information sits in the stack. In the baseline organization, a transit node may need to parse through forwarding labels for downstream hops and select-scoped NAS blocks intended for other routers before reaching the HBH NAS. The paper terms this irrelevant region the in-between stack (Ihle et al., 21 Jul 2025).

The hardware analysis is expressed as:

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

The final “$-1$” accounts for the top-of-stack forwarding label. With the values used in the prior implementation, $RLD = 51$ and $$\text{maxLSEs}^{select}_{NAS} = \text{maxLSEs}^{HBH}_{NAS} = 17$$, yielding:

$$\text{maxLSEs}^{btwn}_{stack} = 51 - 17 - 17 - 1 = 16.$$

So even with an RLD of 51 LSEs, only 16 LSEs remain for all labels between the current top label and the HBH NAS. The paper explicitly treats this as the core obstacle: the current MNA stack structure forces each node to parse an in-between region that is irrelevant to that node (Ihle et al., 21 Jul 2025).

A common misconception is that MNA’s parser-depth problem follows unavoidably from the fact that a NAS can be large. The paper rejects that interpretation. Its central claim is narrower and more structural: the pressure on RLD is substantially driven by the need to search downward for HBH information that is not kept near the top of the stack (Ihle et al., 21 Jul 2025).

3. HBH preservation and the semantics of the Stack Management Network Action

The proposed solution is to restructure the stack during forwarding so that the HBH-scoped NAS is always immediately below the current top-of-stack forwarding label. When a node pops the top forwarding label, it also moves one or more forwarding labels from below the HBH NAS to the top of the stack. The HBH NAS is thereby preserved, but never exposed as the top label (Ihle et al., 21 Jul 2025).

This behavior is driven by the Stack Management Network Action, encoded as a network action inside a NAS. Its parameter is $n$, the number of forwarding labels that must be moved from below the NAS to the top of the stack:

$n = n_{HBH} + n_{Select}.$

The paper distinguishes the two components as follows:

Component	Scope	Role
$n_{HBH}$	HBH-scoped NAS	Preserves the HBH NAS for the next MNA-capable hop
$n_{Select}$	select-scoped NAS	Skips one or more succeeding MNA-incapable nodes

In the normal case, the ingress inserts the Stack Management Network Action in the HBH-scoped NAS with $n_{HBH}=1$, because after one forwarding label is popped, exactly one next forwarding label must be promoted above the HBH NAS to keep that NAS hidden but immediately accessible at the next MNA-capable node (Ihle et al., 21 Jul 2025).

The forwarding behavior can be restated compactly. At an MNA-capable transit node, the router parses the top forwarding label and the HBH-scoped NAS immediately beneath it. If the forwarding operation does not pop the current top label, no stack restructuring is needed. If the top forwarding label is popped, the node computes $-1$0, removes the top label, promotes the next $-1$1 forwarding labels from below the relevant NAS block or blocks, pops any select-scoped NAS exposed for that node, and preserves the HBH-scoped NAS below the newly promoted forwarding label or labels (Ihle et al., 21 Jul 2025).

4. Integration of legacy nodes and mixed-capability paths

Backward compatibility is a central part of the action’s design. Without special handling, the HBH preservation mechanism would fail when an MNA-incapable node is encountered. If an MNA-capable node were to promote only one forwarding label above the HBH NAS and the next hop were legacy MPLS, that legacy router might pop the forwarding label and expose the HBH NAS at top of stack, but could neither process nor remove it. A following legacy router would then see an invalid top label value—the MNA indicator—and drop the packet (Ihle et al., 21 Jul 2025).

The Stack Management Network Action solves this by letting ingress encode a skip over legacy segments. If the path contains a run of MNA-incapable nodes, ingress inserts a select-scoped NAS targeted to the last MNA-capable node before that run, and that select-scoped NAS carries $-1$2, equal to the number of forwarding labels that must be promoted in one step so that the HBH NAS remains buried beneath enough ordinary forwarding labels while the packet traverses the legacy segment (Ihle et al., 21 Jul 2025).

This design places a strong role on ingress. The ingress router computes the MPLS stack, inserts the HBH-scoped NAS and any necessary select-scoped NAS blocks, and sets the Stack Management Network Action parameters based on path knowledge and node capabilities. The paper assumes that ingress knows each node’s MNA capability and RLD via signaling, for example using IS-IS or OSPF extensions, consistent with the MNA framework (Ihle et al., 21 Jul 2025).

The mechanism is therefore deployable in mixed-capability networks, but with an important limitation: the HBH preservation mechanism does not work on legacy MPLS hardware that can only perform conventional push, pop, and swap operations. Such nodes cannot execute the stack management action themselves; they can only be bypassed by prior reshaping at an MNA-capable predecessor (Ihle et al., 21 Jul 2025).

5. Hardware effects, packet overhead, and implementation

The most important quantitative effect is the reduction in required parser depth. Under the proposed organization, because the HBH-scoped NAS is always directly below the top forwarding label, the minimum required RLD becomes:

$-1$3

The paper explains this bound as 17 LSEs for a maximum-sized select-scoped NAS, 17 LSEs for a maximum-sized HBH-scoped NAS, 1 forwarding label at top of stack, and at least $-1$4 additional forwarding labels that may need to be pulled up at once. In the ordinary case $-1$5, so the practical minimum is 36 LSEs. The paper also states that 35 LSEs is the absolute protocol-imposed minimum for supporting two maximum-sized NAS blocks plus one forwarding label, even before accounting for the need to pull up at least one next label (Ihle et al., 21 Jul 2025).

The proposal has another consequence: it eliminates the need to duplicate HBH NAS copies at different depths. In the baseline design, if a bottom-placed HBH NAS would fall outside some node’s RLD, ingress must insert copies of the HBH-scoped NAS so each node can process the first reachable copy. Under the proposed scheme, a single HBH NAS is kept close to the top of the stack and remains within every MNA-capable node’s RLD (Ihle et al., 21 Jul 2025).

The packet-format overhead is small. When an HBH-scoped NAS is present, the Stack Management Network Action adds one LSE, that is 4 bytes, to encode the action in that HBH NAS. If backward compatibility is needed, another 4-byte LSE may be added in a select-scoped NAS. The paper notes that parser arrays are allocated for maximum NAS sizes regardless of which actions are present in a given packet, so the action does not increase hardware array sizing beyond the general NAS budget; it slightly increases per-packet header size (Ihle et al., 21 Jul 2025).

The paper also addresses ECMP. Reorganizing labels during forwarding could in principle change the subset of labels used by ECMP hashing, but the argument given is that if the HBH preservation mechanism is applied consistently to all packets, the resulting stack layout at each hop is consistent as well, so the hash value does not vary across packets in a way that perturbs load balancing (Ihle et al., 21 Jul 2025).

Feasibility is demonstrated by a P4-based implementation on the Intel Tofino 2 switching ASIC. The implementation operates at $-1$6 per port and was verified on a network scenario matching the paper’s mixed-capability example. The result is presented as a proof of realizability on programmable hardware; a detailed performance evaluation is explicitly left for future work (Ihle et al., 21 Jul 2025).

6. Significance, limitations, and relation to broader MNA deployment

The Stack Management Network Action reframes stack restructuring itself as an in-band network action. Its principal significance is architectural: it shows that the large RLD requirement in MPLS MNA is not merely an unavoidable result of adding extensibility to MPLS, but is substantially a consequence of stack placement and the need to parse labels irrelevant to the current hop (Ihle et al., 21 Jul 2025).

This has several direct implications. First, it reduces parser complexity by keeping HBH information in a predictable near-top location. Second, it makes MNA more deployable on nodes with constrained parser resources. Third, it supports mixed-capability paths by allowing ingress to precompute how many labels must be promoted to traverse legacy segments safely. Fourth, the elimination of in-between parsing frees parser budget for other extensions; the paper explicitly notes this as attractive for future support for post-stack data (PSD) (Ihle et al., 21 Jul 2025).

The limitations are equally explicit. The mechanism requires programmable forwarding behavior beyond traditional MPLS label operations; ingress must know path node capabilities and plan the stack accordingly; each stack management action adds a small per-packet header cost; and when long runs of MNA-incapable nodes must be skipped, the parameter $-1$7 grows, increasing the minimum required RLD $-1$8 (Ihle et al., 21 Jul 2025).

Broader MNA implementation work reinforces this interpretation. A separate technological overview and P4 implementation paper identifies the same class of hardware-driven header-stacking constraints and argues that implementation can become infeasible for hardware that can parse only a few MPLS headers, motivating explicit capability signaling in the network (Ihle et al., 2024). Within that broader context, the Stack Management Network Action is best understood as a targeted protocol mechanism that converts HBH preservation from a parser-depth problem into a controlled forwarding operation.