rfc9789.original   rfc9789.txt 
MPLS Working Group L. Andersson Internet Engineering Task Force (IETF) L. Andersson
Internet-Draft Huawei Technologies Request for Comments: 9789 Huawei Technologies
Intended status: Informational S. Bryant Category: Informational S. Bryant
Expires: 30 June 2025 University of Surrey 5GIC ISSN: 2070-1721 University of Surrey 5GIC
M. Bocci M. Bocci
Nokia Nokia
T. Li T. Li
Juniper Networks Juniper Networks
27 December 2024 July 2025
MPLS Network Actions (MNA) Framework MPLS Network Actions (MNAs) Framework
draft-ietf-mpls-mna-fwk-15
Abstract Abstract
This document describes an architectural framework for the MPLS This document describes an architectural framework for MPLS Network
Network Actions (MNA) technologies. MNA technologies are used to Action (MNA) technologies. MNA technologies are used to indicate
indicate actions that impact the forwarding or other processing (such actions that impact the forwarding or other processing (such as
as monitoring) of the packet along the Label Switched Path (LSP) of monitoring) of the packet along the Label Switched Path (LSP) of the
the packet and to transfer any additional data needed for these packet and to transfer any additional data needed for these actions.
actions.
The document provides the foundation for the development of a common This document provides the foundation for the development of a common
set of network actions and information elements supporting additional set of network actions and information elements supporting additional
operational models and capabilities of MPLS networks. operational models and capabilities of MPLS networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 30 June 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9789.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Normative Definitions
1.2.1. Normative Definitions . . . . . . . . . . . . . . . . 4 1.3. Abbreviations
1.2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . 4 2. Structure
2. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Scopes
2.1. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Partial Processing
2.2. Partial Processing . . . . . . . . . . . . . . . . . . . 8 2.3. Signaling
2.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1. Readable Label Depth
2.3.1. Readable Label Depth . . . . . . . . . . . . . . . . 9 2.4. State
2.4. State . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Encoding
3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. The MNA Label
3.1. The MNA Label . . . . . . . . . . . . . . . . . . . . . . 11 3.1.1. Existing Base SPL
3.1.1. Existing Base SPL . . . . . . . . . . . . . . . . . . 11 3.1.2. New Base SPL
3.1.2. New Base SPL . . . . . . . . . . . . . . . . . . . . 11 3.1.3. New Extended SPL
3.1.3. New Extended SPL . . . . . . . . . . . . . . . . . . 11 3.1.4. User-Defined Label
3.1.4. User-Defined Label . . . . . . . . . . . . . . . . . 12 3.2. TC and TTL
3.2. TC and TTL . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.1. TC and TTL Retained
3.2.1. TC and TTL retained . . . . . . . . . . . . . . . . . 12 3.2.2. TC and TTL Repurposed
3.2.2. TC and TTL Repurposed . . . . . . . . . . . . . . . . 12 3.3. Length of the NAS
3.3. Length of the NAS . . . . . . . . . . . . . . . . . . . . 13 3.3.1. Last/Continuation Bits
3.3.1. Last/Continuation Bits . . . . . . . . . . . . . . . 13 3.3.2. Length Field
3.3.2. Length Field . . . . . . . . . . . . . . . . . . . . 13 3.4. Encoding of Scopes
3.4. Encoding of Scopes . . . . . . . . . . . . . . . . . . . 14 3.5. Encoding a Network Action
3.5. Encoding a Network Action . . . . . . . . . . . . . . . . 14 3.5.1. Bit Catalogs
3.5.1. Bit Catalogs . . . . . . . . . . . . . . . . . . . . 14 3.5.2. Operation Codes
3.5.2. Operation Codes . . . . . . . . . . . . . . . . . . . 15 3.6. Encoding of Post-Stack Data
3.6. Encoding of Post-Stack Data . . . . . . . . . . . . . . . 15 3.6.1. First Nibble Considerations
3.6.1. First Nibble Considerations . . . . . . . . . . . . . 15 4. Semantics
4. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Definition of a Network Action
5. Definition of a Network Action . . . . . . . . . . . . . . . 16 6. Management Considerations
6. Management Considerations . . . . . . . . . . . . . . . . . . 17 7. Security Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. References
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 Acknowledgements
10.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This document describes an architectural framework for the MPLS This document describes an architectural framework for MPLS Network
Network Actions (MNA) technologies. MNA technologies are used to Action (MNA) technologies. MNA technologies are used to indicate
indicate actions for Label Switched Paths (LSPs) and/or MPLS packets actions for Label Switched Paths (LSPs) and/or MPLS packets and to
and to transfer data needed for these actions. transfer data needed for these actions.
The document provides the foundation for the development of a common This document provides the foundation for the development of a common
set of network actions and information elements supporting additional set of network actions and information elements supporting additional
operational models and capabilities of MPLS networks. MNA solutions operational models and capabilities of MPLS networks. MNA solutions
derived from this framework are intended to address the requirements derived from this framework are intended to address the requirements
found in [RFC9613]. In addition, MNA may support actions that found in [RFC9613]. In addition, MNA may support actions that
overlap existing MPLS functionality. This may be beneficial for overlap existing MPLS functionality. This may be beneficial for
numerous reasons, such as making it more efficient to combine numerous reasons, such as making it more efficient to combine
existing functionality and new functions in the same MPLS packet. existing functionality and new functions in the same MPLS packet.
MPLS forwarding actions are instructions to MPLS routers to apply MPLS forwarding actions are instructions to MPLS routers to apply
additional actions when forwarding a packet. These might include additional actions when forwarding a packet. These might include
load-balancing a packet given its entropy, whether or not to perform load-balancing a packet given its entropy, indicating whether or not
fast-reroute on a failure, and whether or not a packet has metadata to perform Fast Reroute on a failure, and indicating whether or not a
relevant to the forwarding actions along the path. packet has metadata relevant to the forwarding actions along the
path.
This document generalizes the concept of MPLS "forwarding actions" This document generalizes the concept of MPLS "forwarding actions" to
into "network actions" to include any action that an MPLS router is "network actions" that include any action that an MPLS router is
requested to take on the packet. That includes any MPLS forwarding requested to take on the packet. Network actions include any MPLS
action, but may include other operations (such as security functions, forwarding actions but may also include other operations (such as
OAM procedures, etc.) that are not directly related to forwarding of security functions, Operations, Administration, and Maintenance (OAM)
the packet. MPLS network actions are always triggered by an MNA procedures, etc.) that are not directly related to forwarding of the
packet but may have implications for subsequent traffic, including packet. MPLS network actions are always triggered by an MNA packet
non-MNA packets, as discussed in Section 2.4. but may have implications for subsequent traffic, including non-MNA
packets, as discussed in Section 2.4.
MNA technologies may redefine the semantics of the Label, Traffic MNA technologies may redefine the semantics of the Label, Traffic
Class (TC), and Time to Live (TTL) fields in an MPLS Label Stack Class (TC), and Time to Live (TTL) fields in an MPLS Label Stack
Entry (LSE) within a Network Action Sub-Stack (NAS). Entry (LSE) within a Network Action Sub-Stack (NAS).
1.1. Requirement Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. These words may also appear in this capitals, as shown here.
document in lower case as plain English words, absent their normative
meanings.
Although this is an Informational document, these conventions are Although this is an Informational document, these conventions are
applied to achieve clarity in the requirements that are presented. applied to achieve clarity in the requirements that are presented.
1.2. Terminology 1.2. Normative Definitions
1.2.1. Normative Definitions
This document adopts the definitions of the following terms and This document adopts the definitions of the following terms and
abbreviations from [RFC9613] as normative: "Network Action", "Network abbreviations from [RFC9613] as normative: "Network Action", "Network
Action Indication (NAI)", "Ancillary Data (AD)", and "Scope". Action Indicator (NAI)", "Ancillary Data (AD)", and "Scope".
In addition, this document also defines the following terms: In addition, this document defines the following terms:
* Network Action Sub-Stack (NAS): A set of related, contiguous LSEs Network Action Sub-Stack (NAS): A set of related, contiguous LSEs in
in the MPLS label stack for carrying information related to the MPLS label stack for carrying information related to network
network actions. The Label, TC, and TTL values in the LSEs in the actions. The Label, TC, and TTL values in the LSEs in the NAS may
NAS may be redefined, but the meaning of the S bit is unchanged. be redefined, but the meaning of the S bit is unchanged.
* Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS,
contains a special label that indicates the start of the NAS. which contains a special-purpose label that indicates the start of
the NAS.
1.2.2. Abbreviations 1.3. Abbreviations
+==============+=====================+=====================+ +==============+=====================+===========================+
| Abbreviation | Meaning | Reference | | Abbreviation | Meaning | Reference |
+==============+=====================+=====================+ +==============+=====================+===========================+
| AD | Ancillary Data | [RFC9613] | | AD | Ancillary Data | [RFC9613] |
+--------------+---------------------+---------------------+ +--------------+---------------------+---------------------------+
| BIER | Bit Index Explicit | [RFC8279] | | BIER | Bit Index Explicit | [RFC8279] |
| | Replication | | | | Replication | |
+--------------+---------------------+---------------------+ +--------------+---------------------+---------------------------+
| BoS | Bottom of Stack | [RFC6790] | | BoS | Bottom of Stack | [RFC6790] |
+--------------+---------------------+---------------------+ +--------------+---------------------+---------------------------+
| bSPL | Base Special | [RFC9017] | | bSPL | Base Special- | [RFC9017] |
| | Purpose Label | | | | Purpose Label | |
+--------------+---------------------+---------------------+ +--------------+---------------------+---------------------------+
| ECMP | Equal Cost | [RFC9522] | | ECMP | Equal-Cost | [RFC9522] |
| | Multipath | | | | Multipath | |
+--------------+---------------------+---------------------+ +--------------+---------------------+---------------------------+
| EL | Entropy Label | [RFC6790] | | EL | Entropy Label | [RFC6790] |
+--------------+---------------------+---------------------+ +--------------+---------------------+---------------------------+
| ERLD | Entropy Readable | [RFC8662] | | ERLD | Entropy Readable | [RFC8662] |
| | Label Depth | | | | Label Depth | |
+--------------+---------------------+---------------------+ +--------------+---------------------+---------------------------+
| eSPL | Extended Special | [RFC9017] | | eSPL | Extended Special- | [RFC9017] |
| | Purpose Label | | | | Purpose Label | |
+--------------+---------------------+---------------------+ +--------------+---------------------+---------------------------+
| HBH | Hop by hop | In the MNA context, | | HbH | Hop by Hop | In the MNA context, this |
| | | this document. | | | | document. |
+--------------+---------------------+---------------------+ +--------------+---------------------+---------------------------+
| I2E | Ingress to Egress | In the MNA context, | | I2E | Ingress to Egress | In the MNA context, this |
| | | this document. | | | | document. |
+--------------+---------------------+---------------------+ +--------------+---------------------+---------------------------+
| IGP | Interior Gateway | | | IGP | Interior Gateway | |
| | Protocol | | | | Protocol | |
+--------------+---------------------+---------------------+ +--------------+---------------------+---------------------------+
| ISD | In-stack data | [RFC9613] | | ISD | In-Stack Data | [RFC9613] |
+--------------+---------------------+---------------------+ +--------------+---------------------+---------------------------+
| LSE | Label Stack Entry | [RFC3032] | | LSE | Label Stack Entry | [RFC3032] |
+--------------+---------------------+---------------------+ +--------------+---------------------+---------------------------+
| MNA | MPLS Network | [RFC9613] | | LSP | Label Switched Path | |
| | Actions | | +--------------+---------------------+---------------------------+
+--------------+---------------------+---------------------+ | MNA | MPLS Network Action | [RFC9613] |
| MSD | Maximum SID Depth | [RFC8491] | +--------------+---------------------+---------------------------+
+--------------+---------------------+---------------------+ | MSD | Maximum SID Depth | [RFC8491] |
| NAI | Network Action | [RFC9613] | +--------------+---------------------+---------------------------+
| | Indicator | | | NAI | Network Action | [RFC9613] |
+--------------+---------------------+---------------------+ | | Indicator | |
| NAS | Network Action Sub- | This document | +--------------+---------------------+---------------------------+
| | Stack | | | NAS | Network Action Sub- | This document |
+--------------+---------------------+---------------------+ | | Stack | |
| NSI | Network Action Sub- | This document | +--------------+---------------------+---------------------------+
| | Stack Indicator | | | NSI | Network Action Sub- | This document |
+--------------+---------------------+---------------------+ | | Stack Indicator | |
| PSD | Post-stack data | [RFC9613] and | +--------------+---------------------+---------------------------+
| | | Section 3.6 | | PSD | Post-Stack Data | [RFC9613] and Section 3.6 |
+--------------+---------------------+---------------------+ | | | of this document |
| RLD | Readable Label | This document | +--------------+---------------------+---------------------------+
| | Depth | | | RLD | Readable Label | This document |
+--------------+---------------------+---------------------+ | | Depth | |
| SID | Segment Identifier | [RFC8402] | +--------------+---------------------+---------------------------+
+--------------+---------------------+---------------------+ | SID | Segment Identifier | [RFC8402] |
| SPL | Special Purpose | [RFC9017] | +--------------+---------------------+---------------------------+
| | Label | | | SPL | Special-Purpose | [RFC9017] |
+--------------+---------------------+---------------------+ | | Label | |
+--------------+---------------------+---------------------------+
| TC | Traffic Class | |
+--------------+---------------------+---------------------------+
| TTL | Time to Live | |
+--------------+---------------------+---------------------------+
Table 1: Abbreviations Table 1: Abbreviations
2. Structure 2. Structure
An MNA solution specifies one or more network actions to apply to an An MNA solution specifies one or more network actions to apply to an
MPLS packet. These network actions and their ancillary data may be MPLS packet. These network actions and their ancillary data may be
carried in sub-stacks within the MPLS label stack and/or post-stack carried in sub-stacks within the MPLS label stack and/or post-stack
data. A solution must specify where in the label stack the network data. A solution must specify where the network action sub-stacks
actions sub-stacks occur, if and how frequently they should be occur in the label stack, if and how frequently they should be
replicated within the label stack, and how the network action sub- replicated within the label stack, and how the network action sub-
stack and post-stack data are encoded. stack and post-stack data are encoded.
It seems highly likely that some ancillary data will be needed at It seems highly likely that some ancillary data will be needed at
many points along an LSP. Replication of ancillary data throughout many points along an LSP. Replication of ancillary data throughout
the label stack would be highly inefficient, as would a full rewrite the label stack would be highly inefficient, as would a full rewrite
of the label stack at each hop, so MNA allows encoding of network of the label stack at each hop; thus, MNA allows encoding of network
actions and ancillary data deeper in the label stack, requiring actions and ancillary data deeper in the label stack, requiring
implementations to look past the first LSE. Processing of the label implementations to look past the first LSE. Processing of the label
stack past the top of stack LSE was first introduced with the Entropy stack past the top-of-stack LSE was first introduced with the Entropy
Label [RFC6790]. Label (EL) [RFC6790].
A network action sub-stack contains: A network action sub-stack contains:
* Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS * Network Action Sub-Stack Indicator (NSI): The first LSE in the
contains a special purpose label, called the MNA label, which is NAS, which contains a special-purpose label, called the MNA label,
used to indicate the start of a network action sub-stack. that is used to indicate the start of a network action sub-stack.
* Network Action Indicators (NAI): Optionally, a set of indicators * Network Action Indicators (NAIs): Optionally, a set of indicators
that describes the set of network actions. If the set of that describes the set of network actions. If the set of
indicators is not in the sub-stack, a solution could encode them indicators is not in the sub-stack, a solution could encode them
in post-stack data. A network action is said to be present if in post-stack data. A network action is said to be present if
there is an indicator in the packet that invokes the action. there is an indicator in the packet that invokes the action.
* In-Stack Data (ISD): A set of zero or more LSEs that carry * In-Stack Data (ISD): A set of zero or more LSEs that carry
ancillary data for the network actions that are present. Network ancillary data for the network actions that are present. Network
action indicators are not considered ancillary data. action indicators are not considered ancillary data.
Each network action present in the network action sub-stack may have Each network action present in the network action sub-stack may have
skipping to change at page 7, line 24 skipping to change at line 299
| Network Action Sub-Stack |0| | | Network Action Sub-Stack |0| |
~ ~ ~ ~
| Network Action Sub-Stack continued |0| | | Network Action Sub-Stack continued |0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |0| TTL | | Label | TC |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |1| TTL | | Label | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload | | Payload |
Figure 1: A label stack with an embedded Network Action Sub-Stack Figure 1: A Label Stack with an Embedded Network Action Sub-Stack
Certain network actions may also specify that data is carried after Certain network actions may also specify that data is carried after
the label stack. This is called post-stack data. The encoding of the label stack. This is called post-stack data. The encoding of
the post-stack data, if any, for a network action must be specified the post-stack data, if any, for a network action must be specified
in the document that defines the network action. If multiple network in the document that defines the network action. If multiple network
actions are present and have post-stack data, the ordering of their actions are present and have post-stack data, the ordering of their
post-stack data corresponds to the ordering of the network action post-stack data corresponds to the ordering of the network action
indicators. indicators.
As an example, post-stack data might appear as a label stack followed As an example, a packet containing post-stack data might contain a
by post-stack data, followed by the payload: label stack followed by post-stack data, followed by the payload:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |0| TTL | | Label | TC |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |1| TTL | | Label | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Post-stack data | | Post-Stack Data |
~ ~ ~ ~
| Post-stack data continued | | Post-Stack Data continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload | | Payload |
Figure 2: A label stack followed by post-stack data Figure 2: A Label Stack Followed by Post-Stack Data
A solution must specify the order for network actions to be applied A solution must specify the order for network actions to be applied
to the packet for the actions to have consistent semantics. Since to the packet for the actions to have consistent semantics. Since
there are many possible orderings, especially with bit catalogs there are many possible orderings, especially with bit catalogs
(Section 3.5.1), the solution must provide an unambiguous (Section 3.5.1), the solution must provide an unambiguous
specification. The precise semantics of an action are dependent on specification. The precise semantics of an action are dependent on
the contents of the packet, including any ancillary data, and the the contents of the packet, including any ancillary data, and the
state of the router. state of the router.
This document assumes that the MPLS WG will select not more than one This document assumes that the MPLS WG will select a single solution
solution for the encoding of ISD and not more than one solution for for the encoding of ISD and not more than one solution for the
the encoding of PSD. encoding of PSD.
2.1. Scopes 2.1. Scopes
A network action may need to be processed by every node along the A network action may need to be processed by every node along the
path, or some subset of the nodes along its path. Some of the scopes path or some subset of the nodes along its path. Some of the scopes
that an action may have are: that an action may have are:
* Hop-by-hop (HBH): Every node along the path will perform the * Hop by Hop (HbH): Every node along the path will perform the
action. action.
* Ingress-to-Egress (I2E): Only the last node on the path will * Ingress to Egress (I2E): Only the last node on the path will
perform the action. perform the action.
* Select: Only specific nodes along the path will perform the * Select: Only specific nodes along the path will perform the
action. action.
If a solution supports the select scope, it must describe how it If a solution supports the select scope, it must describe how it
specifies the set of nodes to perform the actions. specifies the set of nodes to perform the actions.
This framework does not place any constraints on the scope of, or the This framework does not place any constraints on the scope of, or the
ancillary data for, a network action. Any network action may appear ancillary data for, a network action. Any network action may appear
in any scope or combination of scopes, may have no ancillary data, in any scope or combination of scopes, may have no ancillary data,
and may require in-stack data, and/or post-stack data. Some and may require in-stack data and/or post-stack data. Some
combinations may be sub-optimal, but this framework does not restrict combinations may be suboptimal, but this framework does not restrict
the combinations in an MNA solution. A specific MNA solution may the combinations in an MNA solution. A specific MNA solution may
define such constraints. define such constraints.
2.2. Partial Processing 2.2. Partial Processing
As described in [RFC3031], legacy devices that do not recognize the As described in [RFC3031], legacy devices that do not recognize the
MNA label will discard the packet if the top label is the MNA label. MNA label will discard the packet if the top label is the MNA label.
Devices that do recognize the MNA label might not implement all of Devices that do recognize the MNA label might not implement all of
the network actions that are present. A solution must specify how the network actions that are present. A solution must specify how
skipping to change at page 9, line 14 skipping to change at line 383
One alternative is that an implementation should stop processing One alternative is that an implementation should stop processing
network actions when it encounters an unrecognized network action. network actions when it encounters an unrecognized network action.
Subsequent present network actions would not be applied. The result Subsequent present network actions would not be applied. The result
is dependent on the solution's order of operations. is dependent on the solution's order of operations.
Another alternative is that an implementation should drop any packet Another alternative is that an implementation should drop any packet
that contains any unrecognized present network actions. that contains any unrecognized present network actions.
A third alternative is that an implementation should perform all A third alternative is that an implementation should perform all
recognized present network actions, but ignore all unrecognized recognized present network actions but ignore all unrecognized
present network actions. present network actions.
Other alternatives may also be possible. The solution should specify Other alternatives may also be possible. The solution should specify
the alternative adopted. the alternative adopted.
In some solutions, an indication may be provided in the packet or in In some solutions, an indication may be provided in the packet or in
the action as to how the forwarder should proceed if it does not the action as to how the forwarder should proceed if it does not
recognize the action. Where an action needs to be processed at every recognize the action. Where an action needs to be processed at every
hop, it is recommended that care be taken not to construct an LSP hop, it is recommended that care be taken not to construct an LSP
that traverses nodes that do not support that action. It is that traverses nodes that do not support that action. It is
recognised that in some circumstances it may not be possible to recognized that, in some circumstances, it may not be possible to
construct an LSP that avoids such nodes, such as when a network is construct an LSP that avoids such nodes, such as when a network is
re-converging following a failure or when IPFRR [RFC5714] is taking reconverging following a failure or when IP Fast Reroute (IPFRR)
place. [RFC5714] is taking place.
2.3. Signaling 2.3. Signaling
A node that wishes to make use of MNA and apply network actions to a A node that wishes to make use of MNA and apply network actions to a
packet must understand the nodes that the packet will transit, packet must understand the nodes that the packet will transit,
whether or not the nodes support MNA, and the network actions that whether or not the nodes support MNA, and the network actions that
are to be invoked. These capabilities are presumed to be signaled by are to be invoked. These capabilities are presumed to be signaled by
protocols that are out-of-scope for this document and are presumed to protocols that are out of scope for this document and are presumed to
have per-network action granularity. If a solution requires have per-network-action granularity. If a solution requires
alternate signaling, it must specify that explicitly. alternate signaling, it must specify that explicitly.
2.3.1. Readable Label Depth 2.3.1. Readable Label Depth
Readable Label Depth (RLD) is defined as the number of LSEs, starting Readable Label Depth (RLD) is defined as the number of LSEs, starting
from the top of the stack, that a router can read in an incoming MPLS from the top of the stack, that a router can read in an incoming MPLS
packet with no performance impact. [RFC8662] introduced Entropy packet with no performance impact. [RFC8662] introduced Entropy
Readable Label Depth (ERLD). Readable Label Depth is the same Readable Label Depth (ERLD). Readable Label Depth is the same
concept, but generalized and not specifically associated with the concept, but it is generalized and not specifically associated with
Entropy Label (EL) or MNA. the Entropy Label (EL) or MNA.
ERLD is not redundant with RLD because ERLD specifically specifies a ERLD is not redundant with RLD because ERLD specifies a value of zero
value of zero if a system does not support the Entropy Label. Since if a system does not support the Entropy Label. Since a system could
a system could reasonably support MNA or other MPLS functions and reasonably support MNA or other MPLS functions and needs to advertise
needs to advertise an RLD value but not support the Entropy Label, an RLD value but not support the Entropy Label, another advertised
another advertised value is required. value is required.
A node that pushes an NAS onto the label stack is responsible for A node that pushes a NAS onto the label stack is responsible for
ensuring that all nodes that are expected to process the NAS will ensuring that all nodes that are expected to process the NAS will
have the entire NAS within their RLD. A node SHOULD use signaling have the entire NAS within their RLD. A node SHOULD use signaling
(e.g., [RFC9088], [RFC9089]) to determine this. An exception might (e.g., the signaling described in [RFC9088] and [RFC9089]) to
be, for example, when the node has out-of-band knowledge that all determine this. An exception might be, for example, when the node
nodes along the path do not have RLD limitations and thus could avoid has out-of-band knowledge that all nodes along the path do not have
the unnecessary overhead of using signaling. RLD limitations and thus could avoid the unnecessary overhead of
using signaling.
Per [RFC8662], a node that does not support EL will advertise a value Per [RFC8662], a node that does not support EL will advertise a value
of zero for its ERLD, so advertising ERLD alone does not suffice in of zero for its ERLD, so advertising ERLD alone does not suffice in
all cases. A node MAY advertise both ERLD and RLD and SHOULD do so all cases. A node MAY advertise both ERLD and RLD, and it SHOULD do
if its ERLD and RLD values are different. Again, if a node has out- so if its ERLD and RLD values are different. Again, if a node has
of-band knowledge that all nodes do not have RLD limitations, then out-of-band knowledge that all nodes do not have RLD limitations,
signaling can be avoided. If a node's ERLD and RLD values are the then signaling can be avoided. If a node's ERLD and RLD values are
same, it MAY only advertise ERLD for efficiency reasons. If a node the same, it MAY only advertise ERLD for efficiency reasons. If a
supports MNA but does not support EL, then it SHOULD advertise RLD node supports MNA but does not support EL, then it SHOULD advertise
unless it has out-of-band knowledge that no nodes in the domain have RLD unless it has out-of-band knowledge that no nodes in the domain
RLD restrictions. have RLD restrictions.
RLD is advertised by an IGP MSD-Type value of (TBA) and MAY be RLD is advertised by an IGP MSD-Type value of 3 and MAY be advertised
advertised as a Node Maximum Segment Identifier (SID) Depth (MSD), as a Node MSD, Link MSD, or both.
Link MSD, or both.
An MNA node MUST use the RLD determined by selecting the first An MNA node MUST use the RLD determined by selecting the first
advertised non-zero value from: advertised non-zero value from the following:
* The RLD advertised for the link. * The RLD advertised for the link
* The RLD advertised for the node. * The RLD advertised for the node
* The non-zero ERLD for the node. * The non-zero ERLD for the node
A node's RLD is a function of its hardware capabilities and is not A node's RLD is a function of its hardware capabilities and is not
expected to depend on the specifics of the MNA solution. expected to depend on the specifics of the MNA solution.
2.4. State 2.4. State
A network action can affect the state stored in the network. This A network action can affect the state stored in the network. This
implies that a packet may affect how subsequent packets are handled. implies that a packet may affect how subsequent packets are handled.
In particular, one packet may affect subsequent packets in the same In particular, one packet may affect subsequent packets in the same
LSP. LSP.
3. Encoding 3. Encoding
Several possible ways to encode NAIs have been proposed. This Several possible ways to encode NAIs have been proposed. This
section summarizes the proposals and some considerations for the section summarizes the proposals and some considerations for the
various alternatives. various alternatives.
When network actions are carried in the MPLS label stack, then When network actions are carried in the MPLS label stack, then
regardless of their type, they are represented by a set of LSEs regardless of their type, they are represented by a set of LSEs
termed a network action sub-stack (NAS). An NAS consists of a termed a Network Action Sub-Stack (NAS). A NAS consists of a
special label, optionally followed by LSEs that specify which network special-purpose label, optionally followed by LSEs that specify which
actions are to be performed on the packet and the in-stack ancillary network actions are to be performed on the packet and the in-stack
data for each indicated network action. Different network actions ancillary data for each indicated network action. Different network
may be placed together in one NAS or may be carried in different sub- actions may be placed together in one NAS or may be carried in
stacks. different sub-stacks.
[RFC9613] requires that a solution not add unnecessary LSEs to the [RFC9613] requires that a solution not add unnecessary LSEs to the
sub-stack (Section 3.1, requirement 9). Accordingly, solutions sub-stack (see requirement 9 in Section 3.1 of [RFC9613]).
should also make efficient use of the bits within the sub-stack Accordingly, solutions should also make efficient use of the bits
(except the S-bit), as inefficient use of the bits could result in within the sub-stack (except the S-bit), as inefficient use of the
the addition of unnecessary LSEs. bits could result in the addition of unnecessary LSEs.
3.1. The MNA Label 3.1. The MNA Label
The first LSE in a network action sub-stack contains a special label The first LSE in a network action sub-stack contains a special-
that indicates a network action sub-stack. A solution has several purpose label that indicates a network action sub-stack. A solution
choices for this special label. has several choices for this special-purpose label.
3.1.1. Existing Base SPL 3.1.1. Existing Base SPL
A solution may reuse an existing Base SPL (bSPL). If it elects to do A solution may reuse an existing Base SPL (bSPL). If it elects to do
so, it must explain how the usage is backward compatible, including so, it must explain how the usage is backward compatible, including
in the case where there is ISD. in the case where there is ISD.
If an existing inactive bSPL is selected that will not be backward If an existing inactive bSPL is selected that will not be backward
compatible, then it must first be retired per [RFC7274] and then compatible, then it must first be retired per [RFC7274] and then
reallocated. reallocated.
skipping to change at page 12, line 18 skipping to change at line 525
indicates the network action sub-stack. This creates management indicates the network action sub-stack. This creates management
overhead for the network operator to coordinate the use of this label overhead for the network operator to coordinate the use of this label
across all nodes on the path using management or signaling protocols. across all nodes on the path using management or signaling protocols.
The user-defined label could be network-wide or LSP-specific. If a The user-defined label could be network-wide or LSP-specific. If a
solution elects to use a user-defined label, the solution should solution elects to use a user-defined label, the solution should
justify this overhead. justify this overhead.
3.2. TC and TTL 3.2. TC and TTL
In the first LSE of the network action sub-stack, only the 20 bits of In the first LSE of the network action sub-stack, only the 20 bits of
Label Value and the Bottom of Stack bit are used by NSI; the TC field the Label value and the Bottom of Stack bit are used by the NSI; the
(3 bits) and the TTL (8 bits) are not used. This could leave 11 bits TC field (3 bits) and the TTL (8 bits) are not used. This could
that could be used for MNA purposes. leave 11 bits that could be used for MNA purposes.
3.2.1. TC and TTL retained 3.2.1. TC and TTL Retained
If the solution elects to retain the TC and TTL fields, then the If the solution elects to retain the TC and TTL fields, then the
first LSE of the network action sub-stack would appear as described first LSE of the network action sub-stack would appear as described
in [RFC3032]: in [RFC3032]:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL | | Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label value, 20 bits
TC: Traffic Class, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time To Live
Figure 3: A Label Stack Entry Figure 3: A Label Stack Entry with TC and TTL Retained
Label: Label value, 20 bits
TC: Traffic Class, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time To Live, 8 bits
Further LSEs would be needed to encode NAIs. If a solution elects to Further LSEs would be needed to encode NAIs. If a solution elects to
retain these fields, it must address the requirement for the minimal retain the TC and TTL fields, it must address the requirement for the
number of LSEs. minimal number of LSEs.
3.2.2. TC and TTL Repurposed 3.2.2. TC and TTL Repurposed
If the solution elects to reuse the TC and TTL fields, then the first If the solution elects to reuse the TC and TTL fields, then the first
LSE of the network action sub-stack would appear as: LSE of the network action sub-stack would appear as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |x x x|S|x x x x x x x x| | Label |x x x|S|x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label value, 20 bits
x: Bit available for use in solution definition Figure 4: A Label Stack Entry with TC and TTL Repurposed
S: Bottom of Stack, 1 bit
Label: Label value, 20 bits
x: Bit available for use in solution definition
S: Bottom of Stack, 1 bit
The solution may use more LSEs to contain NAIs. If a solution elects The solution may use more LSEs to contain NAIs. If a solution elects
to use more LSEs it must address the requirement for the minimal to use more LSEs, it must address the requirement for the minimal
number of LSEs. number of LSEs.
3.3. Length of the NAS 3.3. Length of the NAS
A solution must have a mechanism (such as an indication of the length A solution must have a mechanism (such as an indication of the length
of the NAS) to enable an implementation to find the end of the NAS. of the NAS) to enable an implementation to find the end of the NAS.
This must be easily processed even by implementations that do not This must be easily processed even by implementations that do not
understand the full contents of the NAS. Two options are described understand the full contents of the NAS. Two options are described
below, other solutions may be possible. below; other solutions may be possible.
3.3.1. Last/Continuation Bits 3.3.1. Last/Continuation Bits
A solution may use a bit per LSE to indicate whether the NAS A solution may use a bit per LSE to indicate whether or not the NAS
continues into the next LSE or not. The bit may indicate continues into the next LSE. The bit may indicate continuation by
continuation by being set or by being clear. The overhead of this being set or by being clear. The overhead of this approach is one
approach is one bit per LSE and has the advantage that it can bit per LSE and has the advantage that it can effectively encode an
effectively encode an arbitrarily sized NAS. This approach is arbitrarily sized NAS. This approach is efficient if the NAS is
efficient if the NAS is small. small.
3.3.2. Length Field 3.3.2. Length Field
A solution may opt to have a fixed size length field at a fixed A solution may opt to have a fixed-size Length field at a fixed
location within the NAS. The fixed size of the length field may not location within the NAS. The fixed size of the Length field may not
be large enough to support all possible NAS contents. This approach be large enough to support all possible NAS contents. This approach
may be more efficient if the NAS is longer but not longer than can be may be more efficient if the NAS is long, but not longer than can be
described by the length field. described by the Length field.
Advice from one hardware designer recommends a length field as this One hardware designer recommends a Length field as this minimizes
minimizes branching in the logic. branching in the logic.
3.4. Encoding of Scopes 3.4. Encoding of Scopes
A solution may choose to explicitly encode the scope of each action A solution may choose to explicitly encode the scope of each action
contained in a network action sub-stack. For example, a NAS might contained in a network action sub-stack. For example, a NAS might
contain Action A (HBH), Action B (HBH), and Action C (HBH). A contain Action A (HbH), Action B (HbH), and Action C (HbH). A
solution may alternately choose to have the scope encoded implicitly, solution may alternately choose to have the scope encoded implicitly,
based on the actions present in the network action sub-stack. For based on the actions present in the network action sub-stack. For
example, a NAS might contain HBH scope actions: A, B, C. This choice example, a NAS might contain the following actions with HbH scope: A,
may have performance implications as an implementation might have to B, and C. This choice may have performance implications as an
parse the network actions that are present in a network action sub- implementation might have to parse the network actions that are
stack only to discover that there are no actions for it to perform. present in a network action sub-stack only to discover that there are
no actions for it to perform.
For example, suppose that an NAS is embedded in a label stack at a For example, suppose that a NAS is embedded in a label stack at a
depth of 6 LSEs and that the NAS contains 3 actions, each with Select depth of six LSEs and the NAS contains three actions, each with
scope. These actions are not applicable at the current node and Select scope. These actions are not applicable at the current node
should be ignored. If the scope is encoded explicitly with each and should be ignored. If the scope is encoded explicitly with each
action, then an implementation must parse each action. However, if action, then an implementation must parse each action. However, if
the scope is encoded as part of the NAS, then an implementation need the scope is encoded as part of the NAS, then an implementation only
only parse the start of the NAS and need not parse individual needs to parse the start of the NAS and not individual actions.
actions.
Solutions need to consider the order of scoped NAIs and their Solutions need to consider the order of scoped NAIs and their
associated AD within individual sub-stacks and the order of per-scope associated AD within individual sub-stacks and the order of per-scope
sub-stacks so that network actions and the AD can be most readily sub-stacks, so that network actions and the AD can be readily found
found and need not be processed by nodes that are not required to and not be processed by nodes that are not required to handle those
handle those actions. actions.
3.5. Encoding a Network Action 3.5. Encoding a Network Action
Two options for encoding NAIs are described below, other solutions Two options for encoding NAIs are described below; other solutions
may be possible. Any solution should allow the encoding of an may be possible. Any solution should allow the encoding of an
arbitrary number of NAIs. arbitrary number of NAIs.
3.5.1. Bit Catalogs 3.5.1. Bit Catalogs
A solution may opt to encode the set of network actions as a list of A solution may opt to encode the set of network actions as a list of
bits, sometimes known as a catalog. The solution must provide a bits, sometimes known as a catalog. The solution must provide a
mechanism to determine how many LSEs are devoted to the catalog when mechanism to determine how many LSEs are devoted to the catalog when
the NAIs are carried in-stack. A set bit in the catalog would the NAIs are carried in-stack. A set bit in the catalog would
indicate that the corresponding network action is present. indicate that the corresponding network action is present.
Catalogs are efficient if the number of present network actions is Catalogs are efficient if the number of present network actions is
relatively high and if the size of the necessary catalog is small. relatively high and if the size of the necessary catalog is small.
For example, if the first 16 actions are all present, a catalog can For example, if the first 16 actions are all present, a catalog can
encode this in 16 bits. However, if the number of possible actions encode this in 16 bits. However, if the number of possible actions
is large, then a catalog can become inefficient. Selecting only one is large, then a catalog can become inefficient. Selecting only one
action that is the 256th action would require a catalog of 256 bits, action that is the 256th action would require a catalog of 256 bits,
which would require more than one LSE when the NAIs are carried in- which would require more than one LSE when the NAIs are carried in-
stack. stack.
A solution may include a bit remapping mechanism so that a given A solution may include a bit-remapping mechanism so that a given
domain may optimize for its commonly used actions. domain may optimize for its commonly used actions.
3.5.2. Operation Codes 3.5.2. Operation Codes
A solution may opt to encode the set of present network actions as a A solution may opt to encode the set of present network actions as a
list of operation codes (opcodes). Each opcode is a fixed number of list of operation codes (opcodes). Each opcode is a fixed number of
bits. The size of the opcode bounds the number of network actions bits. The size of the opcode bounds the number of network actions
that the solution can support. that the solution can support.
Opcodes are efficient if there are only one or two active network Opcodes are efficient if there are only one or two active network
actions. For example, if an opcode is 8 bits, then two active actions. For example, if an opcode is 8 bits, then two active
network actions could be encoded in 16 bits. However, if 16 actions network actions could be encoded in 16 bits. However, if 16 actions
are required, then opcodes would consume 128 bits. Opcodes are are required, then opcodes would consume 128 bits. Opcodes are
efficient at encoding a large number of possible actions. If only efficient at encoding a large number of possible actions. If only
the 256th action is to be selected, that still requires 8 bits. the 256th action is to be selected, that still requires 8 bits.
3.6. Encoding of Post-Stack Data 3.6. Encoding of Post-Stack Data
A solution may carry some NAI and AD as PSD. For ease of parsing, A solution may carry NAI and AD as PSD. For ease of parsing, all AD
all AD should be co-located with its NAI. should be co-located with its NAI.
If there are multiple instances of post-stack data, they should occur If there are multiple instances of post-stack data, they should occur
in the same order as their relevant network action sub-stacks and in the same order as their relevant network action sub-stacks and
then in the same order as their relevant network actions occur within then in the same order as their relevant network actions occur within
the network action sub-stacks. the network action sub-stacks.
3.6.1. First Nibble Considerations 3.6.1. First Nibble Considerations
The first nibble after the label stack has been used to convey The first nibble after the label stack has been used to convey
information in certain cases [RFC4385]. A consolidated view of first information in certain cases [RFC4385]. A consolidated view of the
nibble uses is provided in [I-D.ietf-mpls-1stnibble]. uses of the first nibble is provided in [RFC9790].
For example, in [RFC4928] this nibble is investigated to find out if For example, in [RFC4928], this nibble is investigated to find out if
it has the value "4" or "6". If it is not, it is assumed that the it has the value "4" or "6". If it does not, it is assumed that the
packet payload is not IPv4 or IPv6, and Equal Cost Multipath (ECMP) packet payload is not IPv4 or IPv6, and Equal-Cost Multipath (ECMP)
is not performed. is not performed.
It should be noted that this is an inexact method. For example, an It should be noted that this is an inexact method. For example, an
Ethernet Pseudowire without a control word might have "4" or "6" in Ethernet pseudowire without a control word might have "4" or "6" in
the first nibble and thus will be ECMP'ed. the first nibble and thus will be subject to ECMP forwarding.
Nevertheless, the method is implemented and deployed, it is used Nevertheless, the method is implemented and deployed; it is used
today and will be for the foreseeable future. today and will be for the foreseeable future.
The use of the first nibble for Bit Index Explicit Replication (BIER) The use of the first nibble for Bit Index Explicit Replication (BIER)
is specified in [RFC8296]. BIER sets the first nibble to 5. The is specified in [RFC8296]. BIER sets the first nibble to 5. The
same is true for a BIER payload as for any use of the first nibble: same is true for a BIER payload as for any use of the first nibble:
it is not possible to conclude that the payload is BIER even if the it is not possible to conclude that the payload is BIER even if the
first nibble is set to 5 because an Ethernet pseudowire without a first nibble is set to 5 because an Ethernet pseudowire without a
control word might begin with a 5. However, the BIER approach meets control word might begin with a 5. However, the BIER approach meets
the design goal of [RFC8296] to determine that the payload is IPv4, the design goal of [RFC8296] to determine that the payload is IPv4,
IPv6 or with the header of a pseudowire packet with a control word, IPv6, or a packet with a header that includes a pseudowire control
rather than being a payload belonging to a BIER or some other type of word.
packet.
[RFC4385] allocates 0b0000 for the pseudowire control word and 0b0001 [RFC4385] allocates 0b0000 for the pseudowire control word and 0b0001
as the control word for the pseudowire Associated Channel Header as the control word for the pseudowire Associated Channel Header
(ACH). (ACH).
A PSD solution should specify the contents of the first nibble, the A PSD solution should specify the contents of the first nibble, the
actions to be taken for the value, and the interaction with post- actions to be taken for the value, and the interaction with post-
stack data used concurrently by other MPLS applications. stack data used concurrently by other MPLS applications.
4. Semantics 4. Semantics
For MNA to be consistent across implementations and predictable in For MNA to be consistent across implementations and predictable in
operational environments, its semantics need to be entirely operational environments, its semantics need to be entirely
predictable. An MNA solution MUST specify a deterministic order for predictable. An MNA solution MUST specify a deterministic order for
processing each of the Network Actions in a packet. Each network processing each of the network actions in a packet. Each network
action must specify how it interacts with all other previously action must specify how it interacts with all other previously
defined network actions. Private network actions are network actions defined network actions. Private network actions are network actions
that are not publicly documented. Private network actions MUST be that are not publicly documented. Private network actions MUST be
included in the ordering of network actions, but the interactions of included in the ordering of network actions, but the interactions of
private actions with other actions are outside of the scope of this private actions with other actions are outside of the scope of this
document. document.
5. Definition of a Network Action 5. Definition of a Network Action
Network actions should be defined in a document that must contain: A document defining a network action must contain the following:
* Name: The name of the network action.
* Network Action Indicator: The bit position or opcode that Name: The name of the network action.
indicates that the network action is active.
* Scope: The document should specify which nodes should perform the Network Action Indicator: The bit position or opcode that indicates
network action as described in Section 2.1. that the network action is active.
* State: The document should specify if the network action can Scope: Description of which nodes should perform the network action
modify state in the network, and if so, the state that may be as described in Section 2.1.
modified and its side effects.
* Required/Optional: The document should specify whether a node is State: Indication of whether the network action can modify state in
required to perform the network action. the network and, if so, the state that may be modified and its
side effects.
* In-Stack Data: The number of LSEs of in-stack data, if any, and Required/Optional: Indication of whether a node is required to
its encoding. If this is of a variable length, then the solution perform the network action.
must specify how an implementation can determine this length
without implementing the network action.
* Post-Stack Data: The encoding of post-stack data, if any. If this In-Stack Data: The number of LSEs of in-stack data, if any, and the
is of a variable length, then the solution must specify how an encoding of the in-stack data. If the in-stack data is of a
implementation can determine this length without implementing the variable length, then the solution must specify how an
implementation can determine the length without implementing the
network action. network action.
Post-Stack Data: The encoding of post-stack data, if any. If the
post-stack data is of a variable length, then the solution must
specify how an implementation can determine the length without
implementing the network action.
A solution should create an IANA registry for network actions. A solution should create an IANA registry for network actions.
6. Management Considerations 6. Management Considerations
Network operators will need to be cognizant of which network actions Network operators will need to be cognizant of which network actions
are supported by which nodes and will need to ensure that this is are supported by which nodes and will need to ensure that this is
signaled. Some solutions may require network-wide configuration to signaled. Some solutions may require network-wide configuration to
synchronize the use of the labels that indicate the start of an NAS. synchronize the use of the labels that indicate the start of a NAS.
Solution documents must make clear what management considerations Solution documents must clearly state what management considerations
apply to the solutions they are describing. Solutions documents must apply to the solutions they are describing. Solution documents must
describe mechanisms for performing network diagnostics in the describe mechanisms for performing network diagnostics in the
presence of MNAs. presence of MNAs.
7. Security Considerations 7. Security Considerations
An analysis of the security of MPLS systems is provided in [RFC5920], An analysis of the security of MPLS systems is provided in [RFC5920],
which also notes that the MPLS forwarding plane has no built-in which also notes that the MPLS forwarding plane has no built-in
security mechanisms. security mechanisms.
Central to the security of MPLS networks is operational security of Central to the security of MPLS networks is operational security of
the network; something that operators of MPLS networks are well the network, something that operators of MPLS networks are well
versed in. The deployment of link-level security (e.g., [MACsec]) versed in. The deployment of link-level security (e.g., [MACsec])
prevents link traffic observation covertly acquiring the label stack prevents link traffic observation covertly acquiring the label stack
for an attack. This is particularly important in the case of a for an attack. This is particularly important in the case of a
network deploying MNA, because the MNA information may be sensitive. network deploying MNA, because the MNA information may be sensitive.
Thus the confidentiality and authentication achieved through the use Thus, the confidentiality and authentication achieved through the use
of link-level security is particularly advantageous. of link-level security is particularly advantageous.
Some additional proposals to add encryption to the MPLS forwarding Some additional proposals to add encryption to the MPLS forwarding
plane have been suggested [I-D.ietf-mpls-opportunistic-encrypt], but plane have been suggested [MPLS-OPP-SEC], but no mechanisms have been
no mechanisms have been agreed upon at the time of publication of agreed upon at the time of publication of this document.
this document. [I-D.ietf-mpls-opportunistic-encrypt] offers hop-by- [MPLS-OPP-SEC] offers hop-by-hop security that encrypts the label
hop security that encrypts the label stack and is functionally stack and is functionally equivalent to that provided by [MACsec].
equivalent to that provided by [MACsec]. Alternatively, it also Alternatively, it also offers end-to-end encryption of the MPLS
offers end-to-end encryption of the MPLS payload with no payload with no cryptographic integrity protection of the MPLS label
cryptographic integrity protection of the MPLS label stack. stack.
Particular care would be needed when introducing any end-to-end Particular care is needed when introducing any end-to-end security
security mechanism to allow an in-stack MNA solution that needed to mechanism to allow an in-stack MNA solution that needs to employ on-
employ on-path modification of the MNA data, or where post-stack MNA path modification of the MNA data or where post-stack MNA data needs
data needed to be examined on-path. to be examined on-path.
A cornerstone of MPLS security is to protect the network from A cornerstone of MPLS security is to protect the network from
processing MPLS labels originated outside the network. processing MPLS labels that originated outside the network.
Operators have considerable experience in excluding MPLS-encoded Operators have considerable experience in excluding MPLS-encoded
packets at the network boundaries for example, by excluding all MPLS packets at the network boundaries, for example, by excluding all MPLS
packets and all packets that are revealed to be carrying an MPLS packets and all packets that are revealed to be carrying an MPLS
packet as the payload of IP tunnels. Where such packets are accepted packet as the payload of IP tunnels. Where such packets are accepted
into an MPLS network from an untrusted third party, non-MPLS packets into an MPLS network from an untrusted third party, non-MPLS packets
are immediately encapsulated in an MPLS label stack specified by the are immediately encapsulated in an MPLS label stack specified by the
MPLS network operator and MPLS packets have additional label stack MPLS network operator, and MPLS packets have additional label stack
entries imported as specified by the MPLS network operator. Thus, it entries imported as specified by the MPLS network operator. Thus, it
is difficult for an attacker to pass an MPLS-encoded packet into a is difficult for an attacker to pass an MPLS-encoded packet into a
network or to present any instructions to the network forwarding network or to present any instructions to the network forwarding
system. system.
Within a single well-managed domain, an adjacent domain may be Within a single well-managed domain, an adjacent domain may be
considered to be trusted provided that it is sufficiently shielded considered to be trusted provided that it is sufficiently shielded
from third-party traffic ingress and third-party traffic observation. from third-party traffic ingress and third-party traffic observation.
In such a situation, no new security vulnerabilities are introduced In such a situation, no new security vulnerabilities are introduced
by MNA. by MNA.
In some inter-domain applications (including carrier's carrier) where In some inter-domain applications (including carrier's carrier) where
a first network's MPLS traffic is encapsulated directly over a second a first network's MPLS traffic is encapsulated directly over a second
MPLS network by simply pushing additional MPLS LSEs, the contents of MPLS network by simply pushing additional MPLS LSEs, the contents of
the first network's payload and label stack may be visible to the the first network's payload and label stack may be visible to the
forwarders in the second network. Historically this has been benign, forwarders in the second network. Historically, this has been benign
and indeed useful for ECMP. However, if the first network's traffic and indeed useful for ECMP. However, if the first network's traffic
has MNA information this may be exposed to MNA-capable forwarders has MNA information, this may be exposed to MNA-capable forwarders
causing unpredictable behavior or modification of the customer MPLS and cause unpredictable behavior or modification of the customer MPLS
label stack or MPLS payload. This is an increased vulnerability label stack or MPLS payload. This is an increased vulnerability
introduced by MNA that SHOULD be addressed in any MNA solution. introduced by MNA that SHOULD be addressed in any MNA solution.
Several mitigations are available to an operator: Several mitigations are available to an operator:
a) Reject all incoming packets containing MNA information that do not a. Reject all incoming packets containing MNA information that do
come from a trusted network. Note that it may be acceptable to not come from a trusted network. Note that it may be acceptable
accept and process MNA information from a trusted network. to accept and process MNA information from a trusted network.
b) Fully encapsulate the inbound packet in a new additional MPLS b. Fully encapsulate the inbound packet in a new additional MPLS
label stack such that the forwarder finds a Bottom of Stack (BoS) bit label stack such that the forwarder finds a Bottom of Stack (BoS)
imposed by the carrier network and only finds MNA information added bit imposed by the carrier network and only finds MNA information
by the carrier network. added by the carrier network.
A mitigation that we reject as unsafe is having the ingress LSR push A mitigation that we reject as unsafe is having the ingress Label
sufficient additional labels such that any MNA information received Switching Router (LSR) push sufficient additional labels such that
in packets entering the network from a third-party network is made any MNA information received in packets entering the network from a
inaccessible due to it being below the RLD. This is unsafe in the third-party network is made inaccessible due to it being below the
presence of an overly conservative RLD value which can result in the RLD. This is unsafe in the presence of an overly conservative RLD
third-party MNA information becoming visible to and acted on by an value and can result in the third-party MNA information becoming
MNA forwarder in the carrier network. visible to and acted on by an MNA forwarder in the carrier network.
8. IANA Considerations 8. IANA Considerations
This document requests that IANA allocate a code point from the "IGP IANA has allocated the following code point in the "IGP MSD-Types"
MSD-Types" registry [MSD] in the "Interior Gateway Protocol (IGP) registry [MSD] within the "Interior Gateway Protocol (IGP)
Parameters" namespace for "Readable Label Depth", referencing this Parameters" registry group:
document. The "Data-Plane" value for this entry should be "MPLS".
9. Acknowledgements
This document is the result of work started in MPLS Open Design Team, +=======+======================+============+===========+
with participation by the MPLS, PALS, and DETNET working groups. | Value | Name | Data Plane | Reference |
+=======+======================+============+===========+
| 3 | Readable Label Depth | MPLS | RFC 9789 |
+-------+----------------------+------------+-----------+
The authors would like to thank Adrian Farrel for his contributions Table 2: New IGP MSD-Type
and to John Drake, Toerless Eckert, and Jie Dong for their comments.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
skipping to change at page 20, line 38 skipping to change at line 911
[RFC9017] Andersson, L., Kompella, K., and A. Farrel, "Special- [RFC9017] Andersson, L., Kompella, K., and A. Farrel, "Special-
Purpose Label Terminology", RFC 9017, Purpose Label Terminology", RFC 9017,
DOI 10.17487/RFC9017, April 2021, DOI 10.17487/RFC9017, April 2021,
<https://www.rfc-editor.org/info/rfc9017>. <https://www.rfc-editor.org/info/rfc9017>.
[RFC9613] Bocci, M., Ed., Bryant, S., and J. Drake, "Requirements [RFC9613] Bocci, M., Ed., Bryant, S., and J. Drake, "Requirements
for Solutions that Support MPLS Network Actions (MNAs)", for Solutions that Support MPLS Network Actions (MNAs)",
RFC 9613, DOI 10.17487/RFC9613, August 2024, RFC 9613, DOI 10.17487/RFC9613, August 2024,
<https://www.rfc-editor.org/info/rfc9613>. <https://www.rfc-editor.org/info/rfc9613>.
10.2. Informative References 9.2. Informative References
[I-D.ietf-mpls-opportunistic-encrypt] [MACsec] IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security", IEEE Std
802.1AE-2018, DOI 10.1109/ieeestd.2018.8585421, 26
December 2018,
<https://ieeexplore.ieee.org/document/8585421>.
[MPLS-OPP-SEC]
Farrel, A. and S. Farrell, "Opportunistic Security in MPLS Farrel, A. and S. Farrell, "Opportunistic Security in MPLS
Networks", Work in Progress, Internet-Draft, draft-ietf- Networks", Work in Progress, Internet-Draft, draft-ietf-
mpls-opportunistic-encrypt-03, 28 March 2017, mpls-opportunistic-encrypt-03, 28 March 2017,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls- <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
opportunistic-encrypt-03>. opportunistic-encrypt-03>.
[I-D.ietf-mpls-1stnibble] [MSD] IANA, "IGP MSD-Types",
Kompella, K., Bryant, S., Bocci, M., Mirsky, G., <https://www.iana.org/assignments/igp-parameters/>.
Andersson, L., and J. Dong, "IANA Registry and Processing
Recommendations for the First Nibble Following a Label
Stack", Work in Progress, Internet-Draft, draft-ietf-mpls-
1stnibble-13, 5 December 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
1stnibble-13>.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128, Cost Multipath Treatment in MPLS Networks", BCP 128,
RFC 4928, DOI 10.17487/RFC4928, June 2007, RFC 4928, DOI 10.17487/RFC4928, June 2007,
<https://www.rfc-editor.org/info/rfc4928>. <https://www.rfc-editor.org/info/rfc4928>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010, RFC 5714, DOI 10.17487/RFC5714, January 2010,
<https://www.rfc-editor.org/info/rfc5714>. <https://www.rfc-editor.org/info/rfc5714>.
skipping to change at page 22, line 27 skipping to change at line 987
[RFC9089] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., [RFC9089] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
and M. Bocci, "Signaling Entropy Label Capability and and M. Bocci, "Signaling Entropy Label Capability and
Entropy Readable Label Depth Using OSPF", RFC 9089, Entropy Readable Label Depth Using OSPF", RFC 9089,
DOI 10.17487/RFC9089, August 2021, DOI 10.17487/RFC9089, August 2021,
<https://www.rfc-editor.org/info/rfc9089>. <https://www.rfc-editor.org/info/rfc9089>.
[RFC9522] Farrel, A., Ed., "Overview and Principles of Internet [RFC9522] Farrel, A., Ed., "Overview and Principles of Internet
Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522,
January 2024, <https://www.rfc-editor.org/info/rfc9522>. January 2024, <https://www.rfc-editor.org/info/rfc9522>.
[MACsec] IEEE Computer Society, "IEEE 802.1AE Media Access Control [RFC9790] Kompella, K., Bryant, S., Bocci, M., Mirsky, G., Ed.,
(MAC) Security", August 2006. Andersson, L., and J. Dong, "IANA Registry and Processing
Recommendations for the First Nibble Following a Label
Stack", RFC 9790, DOI 10.17487/RFC9790, July 2025,
<https://www.rfc-editor.org/info/rfc9790>.
[MSD] "IGP MSD-Types", December 2024, Acknowledgements
<https://www.iana.org/assignments/igp-parameters/igp-
parameters.xhtml#igp-msd-types>. This document is the result of work started in MPLS Open Design Team,
with participation by the MPLS, PALS, and DETNET Working Groups.
The authors would like to thank Adrian Farrel for his contributions.
The authors would also like to thank John Drake, Toerless Eckert, and
Jie Dong for their comments.
Authors' Addresses Authors' Addresses
Loa Andersson Loa Andersson
Huawei Technologies Huawei Technologies
Email: loa@pi.nu Email: loa@pi.nu
Stewart Bryant Stewart Bryant
University of Surrey 5GIC University of Surrey 5GIC
Email: sb@stewartbryant.com Email: sb@stewartbryant.com
 End of changes. 114 change blocks. 
378 lines changed or deleted 390 lines changed or added

This html diff was produced by rfcdiff 1.48.