MPLS Network Actions (MNA) Overview

• MNA is a framework for embedding network actions into the MPLS label stack, using NAS formats to carry opcodes and ancillary data alongside traditional labels.
• It extends MPLS by overcoming limited label space and poor composability, enabling applications like service chaining, in-situ OAM, and fast reroute.
• Recent P4-based implementations demonstrate MNA’s feasibility at high throughput while addressing parser depth, stack management, and compatibility challenges.

Searching arXiv for papers on MPLS Network Actions and related implementations. MPLS Network Actions (MNA) are an IETF effort to provide a generalized way to encode MPLS extensions and per-packet processing instructions directly in the MPLS label stack or after it, rather than consuming a limited special-purpose label space for each new feature. In the framework described by the recent literature, a network action is an operation identified by an opcode and optionally accompanied by ancillary data, and the wire-format abstraction is the Network Action Sub-stack (NAS), a contiguous group of Label Stack Entries (LSEs) inserted below a forwarding label (Ihle et al., 2024). MNA is intended as an augmentation of MPLS label forwarding, not a replacement for it: forwarding labels still determine path selection, while MNA sub-stacks carry programmable per-packet instructions for transit, selected, or egress processing. A central theme in current work is that the architectural flexibility of MNA is coupled to hard data-plane constraints, especially parser depth, stack growth, mutability limits, and coexistence with MNA-incapable nodes; these constraints have become a primary focus of implementation-oriented research (Ihle et al., 21 Jul 2025).

1. Architectural rationale and protocol position

MPLS historically introduced special-purpose labels to trigger special behavior in MPLS nodes, but the available space is limited. In the terminology summarized by recent work, base special-purpose labels use label values $0$–$15$, and the extension label with value $15$ enables extended special-purpose labels, with values $16$–$239$ reserved for extensions (Ihle et al., 2024). This model is limited not only by the small number of directly available special labels, but also by poor composability. The cited overview notes, for example, that the SFC eSPLs defined in RFC 8595 assume no other extension label is present, making combination with other extensions difficult. MNA is presented as the structured answer to that extensibility problem.

The framework is repeatedly compared to IPv6 extension headers. The comparison is architectural rather than syntactic: both mechanisms extend a basic forwarding header format with optional processing instructions and associated data. The literature argues that MNA can be better deployed than IPv6 extension headers because MNA has bounded encoding by design: a NAS is limited to $17$ LSEs, each action may have at most $7$ AD LSEs, there are at most $128$ opcodes, and MPLS is typically deployed intra-domain by a provider (Ihle et al., 2024). This suggests that bounded depth and single-domain control are considered central to MNA’s deployability claim.

The motivating use cases identified in the MPLS working group and repeated in the implementation literature include no further fast reroute (NFFRR), in-situ OAM (IOAM), service function chaining (SFC), alternate-marking method (AMM), and network slicing (Ihle et al., 2024). Other discussion in the stack-management work also refers to ECMP, operations, administration and maintenance (OAM) generally, and NSH-related contexts (Ihle et al., 21 Jul 2025). Taken together, these examples situate MNA as a general extensibility substrate for MPLS rather than a feature tied to a single application domain.

2. Encoding model, NAS structure, and placement semantics

A NAS has minimum size $2$ LSEs and maximum size $17$ LSEs. It begins with a NAS indicator LSE in traditional MPLS format, followed by one mandatory initial opcode LSE, optionally followed by subsequent opcode LSEs and ancillary-data LSEs (Ihle et al., 2024). The overview identifies four NAS LSE formats from the IETF proposal.

Format	Role	Noted payload property
A	NAS indicator LSE	Traditional MPLS structure
B	Initial opcode LSE	Carries NAS-wide control information
C	Subsequent opcode LSE	Provides $15$0 bits of opcode-specific AD
D	AD LSE	Provides $15$1 bits of opcode-specific AD

Format B defines the first network action and also carries NAS-wide control information. Its fields are summarized as Opcode, Data, $15$2, $15$3, $15$4, $15$5, NASL, and NAL. The Data field provides $15$6 bits of opcode-specific ancillary data; NASL is a $15$7-bit Network Action Sub-stack Length; and NAL is a $15$8-bit Network Action Length (Ihle et al., 2024). Since NASL is $15$9 bits wide, a NAS may contain at most $15$0 network-action/AD LSEs after the indicator, and with the indicator this yields the $15$1-LSE maximum. Since NAL is $15$2 bits wide, up to seven Format D LSEs may follow a Format B or Format C LSE.

The framework supports two data placement models. In-stack data (ISD) carries actions and their data as repurposed MPLS LSEs within the label stack itself, while post-stack data (PSD) places ancillary data after the bottom-of-stack (Ihle et al., 2024). The implementation papers focus on ISD. The overview explains that ISD keeps all control information in the MPLS stack, enabling packet processing without requiring parsing beyond bottom-of-stack, but also inherits MPLS compatibility constraints, especially restrictions on mutability. PSD is not implemented in the cited work, but is described as important for telemetry-heavy or state-accumulating applications such as IOAM passport mode because all bits in PSD can be mutable (Ihle et al., 2024).

Backward compatibility strongly shapes the encoding rules. The literature states that a NAS must never appear at top of stack because MNA-incapable nodes may exist on path. Therefore, any node that pops the forwarding label immediately above a NAS and would expose that NAS to top-of-stack must also pop the NAS (Ihle et al., 2024). The overview also notes that a Format D AD LSE must have its most significant bit set to $15$3 so that the first $15$4 bits cannot fall into the bSPL/eSPL ranges $15$5–$15$6, and opcode values must be non-zero for similar reasons. These are not merely syntactic details; they are compatibility constraints imposed by how legacy MPLS nodes interpret label fields.

3. Scope model, readable label depth, and parser-resource constraints

The scope model is central to MNA. The initial opcode LSE carries an IHS field defining the processing scope of the entire NAS. The current literature distinguishes select scope, hop-by-hop (HBH) scope, and ingress-to-egress (I2E) scope (Ihle et al., 2024). A select-scoped NAS is processed by exactly one specific node, namely the node that pops the forwarding label immediately above that NAS; in SR-MPLS this NAS sits below the active segment and is popped after processing. An I2E-scoped NAS is processed only by the egress LER, typically at the bottom of the MPLS stack. An HBH-scoped NAS is processed by every node along the path.

The HBH case leads directly to the Readable Label Depth (RLD) concept. RLD is defined as the depth of LSEs a node can parse without performance impact, and recent work characterizes it as a physical hardware limit caused by finite parser and memory resources (Ihle et al., 21 Jul 2025). Since HBH actions may sit deeper in the stack than some routers can inspect, routers are expected to signal RLD through routing protocols such as IS-IS or OSPF (Ihle et al., 2024). The ingress LER must then place copies of an HBH-scoped NAS at positions such that each node can find one copy within its RLD (Ihle et al., 2024).

The practical consequence is substantial stack pressure. At an LSR there can be one select-scoped and one HBH-scoped NAS; at an egress LER there can additionally be one I2E-scoped NAS. Since each NAS may have up to $15$7 LSEs, an LSR may need to accommodate up to $15$8 LSEs of network actions, and an LER up to $15$9 LSEs (Ihle et al., 2024). The P4-MNA implementation allocates parsing resources for a maximum of $16$0 LSEs, which the overview states directly results from available Tofino 2 resources. Those $16$1 LSEs are partitioned into

• $16$2,
• $16$3,
• $16$4,

with

$16$5

One of those $16$6 remaining entries is needed for the top-of-stack forwarding label, leaving only $16$7 LSEs between the select-scoped NAS and the deeper HBH-scoped NAS (Ihle et al., 2024).

The later stack-management paper isolates the protocol-design reason for this pressure. In the baseline MNA organization, the HBH-scoped NAS may sit deep in the stack below an “in-between stack” of LSEs that are not relevant to the current node, including forwarding labels for later hops and select-scoped NASes meant for other nodes (Ihle et al., 21 Jul 2025). The exact baseline budget is expressed as

$16$8

With $16$9, $239$0, and the extra $239$1 for the top-of-stack forwarding label, a node that supports both maximum-sized NAS types has already reserved $239$2 LSEs for the two NAS arrays before accounting for labels above the HBH NAS (Ihle et al., 21 Jul 2025). This is the precise hardware-driven deployment obstacle addressed by subsequent work.

4. Data-plane realization and demonstrated use cases

The first hardware implementation described in the current literature is P4-MNA, targeting the Intel Tofino 2 programmable switching ASIC and using ISD only (Ihle et al., 2024). The data plane is written in P4 and the control plane in Rust. Tofino 2 provides line-rate processing at $239$3 Gb/s per port, and the implementation is designed to preserve that rate. The parser, ingress pipeline, and deparser follow the standard P4/TNA structure (Ihle et al., 2024).

Parser heterogeneity is the main challenge. Because P4 parsers are finite-state machines with limited state and transition resources, and header stacks in P4 require fixed pre-allocation and homogeneous header types, the implementation parses all Format D AD LSEs using the Format C header structure. After the mandatory Format A and Format B, the parser treats the remainder of the NAS as a stack of Format C-like entries, using NASL to know how many to extract. The semantic distinction between opcode LSEs and AD LSEs is then restored in ingress control by using NAL and per-entry metadata (Ihle et al., 2024). When a match-action table matches a network action at position $239$4, the action accesses LSEs $239$5, treats the current one as opcode and the following ones as AD, and marks those entries as already processed.

Network action execution is performed in ingress via match-action tables. Since a NAS can carry up to $239$6 network actions, the pipeline instantiates $239$7 match-action tables per NAS, each responsible for one LSE position. Each table matches on opcode, NAL, and a metadata bit indicating whether the LSE was already processed (Ihle et al., 2024). Since only one NAS of up to $239$8 actions can be fully processed in one ingress pass, packets with multiple NASes require resubmit rather than recirculation. The implementation uses resubmit because, as the paper states, resubmit does not consume additional link bandwidth and is cheaper on Tofino.

The scalability numbers reported are concrete. The IETF encoding supports $239$9 opcodes; with $17$0 through $17$1 AD LSEs, one match-action table must cover $17$2 opcode/NAL combinations; and each network action match-action table in P4-MNA has $17$3 entries (Ihle et al., 2024). The implementation supports processing $17$4 LSEs containing up to $17$5 network actions per node at $17$6 Gb/s, where the $17$7 figure comes from two fully sized NASes per LSR, each carrying up to $17$8 network actions.

Two implemented use cases are emphasized. For AMM, packets are marked in alternating color batches to estimate packet loss and delay between points. The implemented example places AMM in an HBH-scoped NAS so every LSR performs measurement. The evaluation uses packet batches of about $17$9 million packets before alternating color, with three logical LSRs configured to drop packets probabilistically before MNA processing: $7$0, $7$1, and $7$2 (Ihle et al., 2024). The calculated loss rates with AMM are reported as $7$3, $7$4, and $7$5, reproducing the configured loss probabilities essentially exactly. For network slicing, the paper states that MNA can encode the NRP selector as a network action and can additionally carry scheduling-related data, linking MNA to IETF network slices and network resource partitions (Ihle et al., 2024).

A recurrent misconception is that implementation feasibility alone resolves deployability. The overview does not make that claim. It concludes that MNA, specifically its ISD realization, is feasible on modern programmable switching ASICs at production rates, but also emphasizes parser depth, stack growth, and mutability restrictions as the largest deployment caveats (Ihle et al., 2024).

5. Stack management, HBH preservation, and mixed-capability networks

The stack-management work addresses a specific obstacle: the amount of MPLS label stack that routers must be able to parse at line rate when HBH MNA data sits behind labels irrelevant to the current node (Ihle et al., 21 Jul 2025). Its main contribution is not a new MNA architecture from scratch, but a forwarding procedure and a new network action that make the existing MNA model more deployable on real hardware, especially when some nodes have limited parsing depth or are not MNA-capable at all.

The proposed mechanism is called the HBH preservation mechanism. Instead of leaving the HBH NAS deep in the stack and forcing each node to search for it, the mechanism keeps the HBH NAS immediately below the top forwarding label at each hop (Ihle et al., 21 Jul 2025). Whenever a node pops the top forwarding label, it also moves one or more forwarding labels from below the NAS to above it, so the HBH NAS remains buried under a forwarding label and is never exposed to top of stack at intermediate MNA-capable nodes. The paper’s claim is that this eliminates the need for the “in-between stack” from the perspective of each MNA-capable node.

This mechanism is enabled by a new stack management network action. It instructs a node to move the next $7$6 forwarding labels from below a NAS to the top of the stack if the current top forwarding label is popped (Ihle et al., 21 Jul 2025). The paper defines two parameters:

• $7$7, carried in an HBH-scoped NAS,
• $7$8, carried in a select-scoped NAS,

with

$7$9

The interpretation given is that $128$0 is used for ordinary HBH preservation, while $128$1 is used to skip over a run of MNA-incapable nodes for compatibility (Ihle et al., 21 Jul 2025).

The mixed-capability case is central. The stack-management paper effectively works with three classes: MNA-capable nodes, MNA-incapable nodes, and hardware-limited MNA nodes (Ihle et al., 21 Jul 2025). The interoperability problem is explicit: if the HBH NAS is preserved near the top for MNA-capable processing, a following MNA-incapable node may pop the top forwarding label and expose the NAS at top of stack, where the legacy node cannot process it; the next legacy node then sees an invalid top label and may drop the packet. The compatibility procedure therefore relies on ingress knowing path capabilities via signaling such as IS-IS or OSPF and precomputing where stack restructuring must “jump over” legacy nodes (Ihle et al., 21 Jul 2025).

The illustrative example uses four routers: $128$2 MNA-capable, $128$3 and $128$4 MNA-incapable, and $128$5 MNA-capable. With forwarding labels $128$6, an HBH NAS, and a select-scoped NAS for $128$7, ingress creates a conceptual stack

$128$8

At $128$9, $2$0 is popped, the select-scoped NAS for $2$1 is processed and popped, the HBH NAS is processed, and stack management computes

$2$2

The node then moves the next three forwarding labels from below the NAS to the top, producing conceptually

$2$3

Routers $2$4 and $2$5 then simply pop or forward using $2$6 and $2$7 and never expose the HBH NAS at top, while $2$8 can again process the HBH NAS and apply the preservation rule with $2$9 (Ihle et al., 21 Jul 2025).

Architecturally, this proposal is additive rather than disruptive. It does not redefine the whole MNA encoding model; it adds a new network action type carried in the existing NAS structure, preserves select- and HBH-scope semantics, and changes forwarding procedures so that HBH NASes remain reachable with smaller RLD (Ihle et al., 21 Jul 2025).

6. Overhead, mutability, ECMP, and open issues

The current literature is technically optimistic about feasibility but conservative about constraints. In the stack-management proposal, the required minimum RLD with HBH preservation becomes

$17$0

where $17$1 (Ihle et al., 21 Jul 2025). The paper explains this as $17$2 LSEs for a maximum select NAS, $17$3 for a maximum HBH NAS, $17$4 forwarding label, and at least $17$5 label after the NAS, plus any extra labels needed to skip MNA-incapable nodes. It states that $17$6 LSEs is the absolute minimum to support maximum-sized NASes in MNA and $17$7 LSEs is the minimum with the proposed preservation mechanism in operation. This does not remove parser-depth concerns altogether; it removes the need to reserve parser budget for a variable in-between stack (Ihle et al., 21 Jul 2025).

Packet overhead is quantified in both papers. For AMM, a NAS adds at least $17$8 bytes: $17$9 bytes for the Format A NAS indicator, $15$00 bytes for a Format B LSE, and $15$01 bytes for the AMM network action LSE (Ihle et al., 2024). If copies are needed for HBH placement within downstream nodes’ RLD, each extra copy adds another $15$02 bytes. The stack-management mechanism adds overhead in the form of extra MNA action encoding: $15$03 LSE ($15$04 bytes) in the HBH-scoped NAS when HBH preservation is used and potentially $15$05 additional LSE ($15$06 bytes) in a select-scoped NAS when backward-compatibility skipping is needed (Ihle et al., 21 Jul 2025). The later paper describes this overhead as negligible. A plausible implication is that stack management is partly motivated by reducing the need for repeated HBH NAS copies, not merely by parser simplification.

Throughput impact depends on packet size. For packets including Ethernet plus ten forwarding MPLS labels, the AMM evaluation reports that at $15$07-byte frames one NAS reduces admissible input throughput from $15$08 to $15$09 Gb/s and two NASes reduce it to $15$10 Gb/s; at $15$11-byte frames one NAS reduces it only to about $15$12 Gb/s and two NASes to about $15$13 Gb/s (Ihle et al., 2024). The penalty is therefore much more severe for small packets and scales linearly with the number of inserted NASes.

Mutability is a distinct constraint in ISD. For backward compatibility with ECMP and legacy MPLS hashing behavior, only the last eight bits of an LSE may be mutable; the first $15$14 bits must remain unchanged because many implementations hash them for load balancing (Ihle et al., 2024). The overview states that in ISD only $15$15 bits are mutable in Format C and $15$16 bits are mutable in Format D. Its maximum-mutable-bits example yields a NAS with $15$17 data bits total but only $15$18 mutable bits, so only about $15$19 of the NAS can carry mutable data (Ihle et al., 2024). This is why PSD is presented as the likely long-term answer for telemetry-heavy uses.

ECMP effects are discussed explicitly in the stack-management paper. Reordering MPLS labels can affect ECMP because implementations may hash over MPLS labels. The paper’s conclusion is conditional: if the HBH preservation mechanism is applied consistently to all packets, the hash value seen at a given point is consistent across packets, so load balancing behavior does not change across packets of the same traffic class or flow; therefore, there is no impact on load balancing if the mechanism is applied consistently (Ihle et al., 21 Jul 2025). This addresses a potential misconception that any label reordering necessarily destabilizes ECMP.

Open issues remain. The overview proposes treating supported NAS sizes as node capabilities and signaling them in the network in addition to RLD, specifically by advertising $15$20 and $15$21 so ingress LERs can tailor stacks to downstream hardware (Ihle et al., 2024). The stack-management paper points to publication or standardization of the stack management network action as an IETF draft, detailed performance evaluation, exploration of mixed ISD and PSD implementations, and practical standardization of capability signaling and operational procedures (Ihle et al., 21 Jul 2025). The research trajectory therefore suggests continuity rather than closure: the core encoding model is stable enough to implement, but deployability depends on increasingly precise treatment of parser depth, signaling, and stack restructuring semantics.