| Internet-Draft | MNA NRP Selector | May 2026 |
| Li, et al. | Expires 2 November 2026 | [Page] |
An IETF Network Slice service provides connectivity coupled with a set of network resource commitments and is expressed in terms of one or more connectivity constructs. A Network Resource Partition (NRP) is a collection of resources identified in the underlay network to support IETF Network Slice services. A Slice-Flow Aggregate refers to the set of traffic streams from one or more connectivity constructs belonging to one or more IETF Network Slices that are mapped to a specific NRP and provide the same forwarding treatment. The packets associated with a Slice-Flow Aggregate may carry markings in the packet's network layer header to identify this association and each is referred to as NRP Selector. The NRP Selector is used to map the packet to the associated NRP and provides the corresponding forwarding treatment to the packet.¶
MPLS Network Actions (MNA) technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions. This document specifies options for using MPLS Network Actions (MNAs) to carry the NRP Selector in MPLS packets.¶
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 2 November 2026.¶
Copyright (c) 2026 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.¶
An IETF Network Slice [RFC9543] service provides connectivity coupled with a set of specific commitments of network resources between a number of endpoints over a shared underlay network. The IETF Network Slice service is expressed in terms of one or more connectivity constructs. A Network Resource Partition (NRP) ([RFC9543], Section 7) is a collection of resources identified in the underlay network to support IETF Network Slice services (or any other services that need logical network structures with required characteristics to be created). An NRP Policy is a policy construct that enables instantiation of mechanisms in support of service specific control and data plane behaviors on select topological elements associated with the NRP. This is also discussed in [I-D.ietf-teas-ns-ip-mpls].¶
A Slice-Flow Aggregate refers to the set of traffic streams from one or more connectivity constructs belonging to one or more IETF Network Slices that are mapped to a specific NRP and are provided the same forwarding treatment. The NRP policy dictates the identification of the flow aggregate that the packet belongs to and the corresponding forwarding treatment that needs to be applied to the packet. The packets associated with a Slice-Flow Aggregate may carry markings in the packet's network layer header to identify this association and each is referred to as NRP Selector (NRPS). [I-D.ietf-teas-ns-ip-mpls] discusses a few options for carrying the NRP Selector in MPLS packets, including overloading the semantics of forwarding/service labels and using a dedicated identifier field.¶
[RFC9789] specifies an architectural framework for the MPLS Network Actions (MNA) technologies. MNA technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions. The MNA architecture can facilitate carrying the dedicated identifier based NRP Selector in the MPLS label stack. This document discusses a few options for using MPLS network actions to carry the NRP Selector. These encodings are compliant with the MNA header encoding formats defined in [I-D.ietf-mpls-mna-hdr].¶
The reader is expected to be familiar with the terminology specified in [RFC9789] and MNA header encoding formats defined in [I-D.ietf-mpls-mna-hdr].¶
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. These words may also appear in this document in lower case as plain English words, absent their normative meanings.¶
The MNA Label Stack Entries (LSEs) in the following subsections use the format and fields defined in [I-D.ietf-mpls-mna-hdr], Section 4, with no change to their meanings. Only the Ancillary Data is modified to carry the NRPS Selector as described in each of the subsections.¶
The format of the 13-bit NRP Selector (NRPS13) Action (when encoded in the second label stack entry in the Network Action Sub-Stack) is:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode=TBA1 | NRPS |R|IHS|S| NASL |U| NAL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This complies with MNA LSE Format B ([I-D.ietf-mpls-mna-hdr], Section 4.2). The fields are:¶
Opcode: The MNA Opcode (TBA1). See [I-D.ietf-mpls-mna-hdr], Section 5.1.¶
NRPS: Network Resource Partition Selector. If this is the top-most NRPS in the label stack, the packet carrying the NRPS13 action is to be given the forwarding treatment specified by the associated NRP policy. See [I-D.ietf-teas-ns-ip-mpls], Section 5.1.1.¶
R: Reserved. See [I-D.ietf-mpls-mna-hdr], Section 4.2.¶
IHS: The Scope of the NAS. See [I-D.ietf-mpls-mna-hdr], Section 5.3.¶
NASL: The Network Action Sub-Stack Length (NASL). See [I-D.ietf-mpls-mna-hdr], Section 4.2.¶
U: Unknown Network Action Handling. See [I-D.ietf-mpls-mna-hdr], Section 5.4.¶
NAL: Network Action Length. See [I-D.ietf-mpls-mna-hdr], Section 4.2.¶
Each Network Action is required to specify the following by [I-D.ietf-mpls-mna-hdr]:¶
Format: LSE Format B¶
Scope: The NRPS13 Action is valid in all scopes.¶
Ancillary Data: The NRPS13 Action carries 13 bits of ancillary data. The NRPS is encoded in 13 bits.¶
Processing: If this is the top-most NRPS in the label stack, the packet carrying the NRPS13 action is to be given the forwarding treatment specified by the associated NRP policy.¶
Interactions: None¶
The format of the 20-bit NRP Selector (NRPS20) Action is:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode=TBA2 | NRPS |S| NRPS |U| NAL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This complies with MNA LSE Format C ([I-D.ietf-mpls-mna-hdr], Section 4.3). The fields are:¶
Opcode: The MNA Opcode (TBA2). See [I-D.ietf-mpls-mna-hdr], Section 5.1.¶
NRPS: Network Resource Partition Selector. This field is intentionally split across the S bit. If this is the top-most NRPS in the label stack, the packet carrying the NRPS20 action is to be given the forwarding treatment specified by the associated NRP policy. See [I-D.ietf-mpls-mna-hdr], Section 4.3 and [I-D.ietf-teas-ns-ip-mpls], Section 5.1.1.¶
U: Unknown Network Action Handling. See [I-D.ietf-mpls-mna-hdr], Section 5.4.¶
NAL: Network Action Length. See [I-D.ietf-mpls-mna-hdr], Section 4.3.¶
Each Network Action is required to specify the following by [I-D.ietf-mpls-mna-hdr]:¶
Format: LSE Format C¶
Scope: The NRPS20 Action is valid in all scopes.¶
Ancillary Data: The NRPS20 Action carries 20 bits of ancillary data. The NRPS is encoded in the 20 bits.¶
Processing: If this is the top-most NRPS in the label stack, the packet carrying the NRPS20 action is to be given the forwarding treatment specified by the associated NRP policy.¶
Interactions: None¶
The format of the 20-bit Entropy and NRP Selector (ENRPS20) Action is:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode=TBA3 | Entropy | NRPS |S| NRPS |U| NAL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This complies with MNA LSE Format C ([I-D.ietf-mpls-mna-hdr], Section 4.3). The fields are:¶
Opcode: The MNA Opcode (TBA3). See [I-D.ietf-mpls-mna-hdr], Section 5.1.¶
Entropy: A 12-bit Entropy Value. The Entropy Value has semantics consistent with the Entropy Label [RFC6790]. While the RFC 6790 Entropy Label has some restrictions to avoid collisions with the reserved label space (0-15) [RFC3032], those restrictions are not necessary for the Entropy Value and do not apply. The selection of the Opcode ensures that this cannot be mistaken for a reserved label.¶
NRPS: Network Resource Partition Selector. This field is intentionally split across the S bit. If this is the top-most NRPS in the label stack, the packet carrying the ENRPS20 action is to be given the forwarding treatment specified by the associated NRP policy. See [I-D.ietf-mpls-mna-hdr], Section 4.3 and [I-D.ietf-teas-ns-ip-mpls], Section 5.1.1.¶
U: Unknown Network Action Handling. See [I-D.ietf-mpls-mna-hdr], Section 5.4.¶
NAL: Network Action Length. See [I-D.ietf-mpls-mna-hdr], Section 4.3.¶
Each Network Action is required to specify the following by [I-D.ietf-mpls-mna-hdr]:¶
Format: LSE Format C¶
Scope: The ENRPS20 Action is valid in all scopes.¶
Ancillary Data: The ENRPS20 Action carries 20 bits of ancillary data. The most significant 12 bits of ancillary data is the Entropy Value. The least significant 8 bits of ancillary data is the NRPS.¶
Processing: The Entropy Value has semantics consistent with the Entropy Label [RFC6790]. While the RFC 6790 Entropy Label has some restrictions to avoid collisions with the reserved label space (0-15) [RFC3032], those restrictions are not necessary for the Entropy Value and do not apply. The selection of the Opcode ensures that this cannot be mistaken for a reserved label. If this is the top-most NRPS in the label stack, the packet carrying the ENRPS20 action is to be given the forwarding treatment specified by the associated NRP policy.¶
Interactions: None¶
Multiple NRPS Actions MAY be encoded in a single packet. An implementation MUST use only the top-most NRPS Action to determine the packet's forwarding treatment. An implementation that finds a subsequent opcode of any of the three NRPS Actions in the label stack MUST ignore it. The specific scenarios where multiple NRPS Actions are present in the label stack are outside the scope of this document.¶
An NRP-capable node SHOULD drop a packet by default if the encoded NRPS cannot be mapped to a known NRP. This requirement MAY be overridden by an operator-specified policy, the specification of which is outside the scope of this document.¶
MNA In-stack operational considerations are discussed in [I-D.ietf-mpls-mna-hdr], Section 13.¶
The choice of the number of bits to encode an NRP Selector is a network-wide deployment decision. This decision may be constrained by implementations.¶
The choice of which Action to use when the NRP Selector could fit in multiple Actions is open, but it is RECOMMENDED to use NRPS13 where possible unless Entropy is also to be carried and it is possible to use ENRPS20.¶
This document requests that IANA allocate a codepoint (TBA1) from the "Network Action Opcodes" registry in the "MPLS Network Actions" group [NAO] for the 13-bit NRP Selector Action. The allocation should reference this document with the description "20-bit Entropy and NRP Selector".¶
This document requests that IANA allocate a codepoint (TBA2) from the "Network Action Opcodes" registry in the "MPLS Network Actions" group [NAO] for the 20-bit NRP Selector Action. The allocation should reference this document with the description "20-bit NRP Selector".¶
This document requests that IANA allocate a codepoint (TBA3) from the "Network Action Opcodes" registry in the "MPLS Network Actions" group [NAO] for the 20-bit Entropy and NRP Selector Action. The allocation should reference this document with the description "20-bit Entropy and NRP Selector".¶
The forwarding plane is insecure. If an adversary can affect the forwarding plane, then they can inject data, remove data, corrupt data, or modify data. MNA additionally allows an adversary to make packets perform arbitrary network actions.¶
Link-level security mechanisms can help mitigate some on-link attacks, but does nothing to preclude hostile nodes.¶
Further security considerations can be found in [I-D.ietf-mpls-mna-hdr], Section 12 and [RFC9789], Section 7.¶
The following individuals contributed to this document:¶
Colby Barth Juniper Networks Email: cbarth@juniper.net Srihari R. Sangli Juniper Networks Email: ssangli@juniper.net Chandra Ramachandran Juniper Networks Email: csekar@juniper.net Kireeti Kompella Juniper Networks Email: kireeti@juniper.net¶