| RFC 9613 | MNA Requirements | July 2024 |
| Bocci, et al. | Informational | [Page] |
This document specifies requirements for the development of MPLS Network Actions (MNAs) that affect the forwarding or other processing of MPLS packets. These requirements are informed by a number of proposals for additions to the MPLS information in the labeled packet to allow such actions to be performed, either by a transit or terminating Label Switching Router (i.e., the Label Edge Router - LER).¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the 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.¶
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/rfc9613.¶
Copyright (c) 2024 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.¶
There is significant interest in developing the MPLS data plane to address the requirements of new use cases [MNA-USECASES]. This requires a general mechanism, termed MPLS Network Actions (MNAs), to allow the network to make a forwarding or processing decision based on information other than the top label and Traffic Class (TC) bits, and to also make use of the Network Action Indicator and ancillary data (MNA information). These use cases require the definition of extensions to the MPLS architecture and label-stack operations that can be used across these use cases in order to minimize implementation complexity and promote interoperability and extensibility. These protocol extensions need to conform with the existing MPLS architecture as specified by [RFC3031], [RFC3032], and [RFC6790].¶
Note that the MPLS architecture specified in [RFC3031] describes a mechanism for forwarding MPLS packets through a network without requiring any analysis of the MPLS packet payload's network layer header by intermediate nodes (Label Switching Routers - LSRs). Formally, inspection may only occur at network ingress (the Label Edge Router - LER) where the MPLS packet is assigned to a Forwarding Equivalence Class (FEC).¶
This document specifies the requirements for solutions that encode MNAs and ancillary data that may be needed to proces those actions. These requirements are informed by a number of proposals to allow additions to the MPLS information in the labeled packet so that such actions can be performed, either by a transit or terminating LSR. It is anticipated that these will result in two types of solution specifications:¶
The term 'solutions', in isolation, refers to both MNA and Network Action solutions. The requirements constrain the MNA solution design to enable interoperability between implementations.¶
Data in an MPLS packet associated with a given network action that may be used as input to process the network action or may result from processing the network action.¶
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.¶
Although this document is not a protocol specification, this convention is adopted for clarity of description of requirements.¶
This document specifies requirements on MPLS Network Actions and the technology to support them in MPLS, such as NAIs, the associated AD, and the alert mechanism to indicate to an LSR that NAIs are present in an MPLS packet.¶
The requirements are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which indicators for network actions and associated ancillary data are constructed. It does not specify the detailed actions and processing of any network actions or ancillary data by an LSR or LER.¶
The size of the ancillary data carried post-stack end to end in an MPLS packet is a matter for agreement between the ingress and egress provider edges (PEs), and is not part of these requirements. Since in-stack ancillary data and per-hop post-stack data need to be parsed and processed by transit LSRs along the Label Switched Path (LSP), requirements on the size of such ancillary data are documented in the following sections.¶
Any solutions MUST maintain the properties of extensibility, flexibility, and efficiency inherent in the split between the control plane context and simple data plane used in MPLS and SHOULD describe how this is achieved.¶
Any solutions to these requirements MUST be based on and MUST NOT restrict the generality of the MPLS architecture [RFC3031] [RFC3032] [RFC5331].¶
If extensions to the MPLS data plane are required, they MUST NOT be inconsistent with the MPLS architecture [RFC3031], [RFC3032] and [RFC5331].¶
Solutions meeting the requirements set out in this document MUST be able to coexist with existing MPLS mechanisms.¶
Subject to the constraints in these requirements, a Network Action solution MAY carry MNA information in-stack, post-stack, or both in-stack and post-stack.¶
Solutions MUST NOT require an implementation to support in-stack ancillary data, unless the implementation chooses to support a network action that uses in-stack ancillary data.¶
Solutions MUST NOT require an implementation to support post-stack ancillary data, unless the implementation chooses to support a network action that uses post-stack ancillary data.¶
The design of any MNA solution MUST minimize the amount of processing required to parse the label stack at an LSR.¶
Solutions MUST minimize any additions to the size of the MPLS label stack.¶
Solutions that increase the size of the MPLS label stack in a way that is not controlled by the ingress LER MUST discuss the consequences.¶
Solution specifications MUST discuss the ECMP consequences of the design.¶
A Network Action solution MUST NOT expose information to the LSRs that is not already exposed to the LER.¶
The design of any network action MUST NOT expose any information that a user of any service using the LSP considers confidential [RFC6973] [RFC3552].¶
Solution specifications MUST document any new security considerations that they introduce.¶
An MNA solution MUST allow MPLS packets carrying NAI and ancillary data (where it exists) to coexist with MPLS packets that do not carry this information on the same LSP.¶
It is RECOMMENDED that an MNA solution support network actions for Private Use (see Section 4.1 of [RFC8126]).¶
Network action solutions MUST specify if the network action needs to be processed as a part of the immediate forwarding operation and whether MPLS packet misordering is allowed to occur as a result of the time taken to process the network action.¶
If a Network Action solution allows more than one scope for a network action, it MUST provide a mechanism to specify the precedence of the scopes or any combination of the scopes.¶
If a network action requires an NAI with in-stack ancillary data that needs to be imposed at an LSR on an LSP, then the Network Action solution MUST specify how this is achieved in all circumstances.¶
If a network action requires an NAI with post-stack ancillary data to be imposed at an LSR on an LSP, then the Network Action solution MUST specify how this is achieved in all circumstances.¶
Insertion, parsing, processing, and disposition of NAIs SHOULD make use of existing MPLS data plane operations.¶
Without constraining the mechanism, an MNA solution MUST enable a node inserting or modifying NAIs to determine if the target of the NAI, or any other LSR that may expose the NAI, can accept and process an MPLS packet containing the NAI.¶
An NAI MUST NOT be imposed for delivery to a node unless it is known that the node supports processing the NAI.¶
The NAI design MUST support setting the scope of network actions.¶
A given network action solution MUST specify which scope or scopes are applicable to the associated NAI.¶
An MNA solution SHOULD support NAIs for both Point-to-Point (P2P) and Point-to-Multipoint (P2MP) paths, but the network action specification MAY limit a specific NAI to only one of these path types if there is a clear reason to do so.¶
An MNA solution defining data plane mechanisms for NAIs MUST be consistent across different control plane protocols.¶
An MNA solution MUST allow the deployed MPLS control and management planes to determine the ability of downstream LSRs to accept and/or process a given NAI.¶
An MNA solution MUST allow indicators for multiple network actions in the same MPLS packet.¶
An MNA solution MUST NOT require an implementation to process all NAIs present in an MPLS packet.¶
NAIs MUST only be inserted at LSRs that push a label onto the stack, but they can be processed by LSRs along the path of the LSP. Two examples of LSRs that push a label onto the stack are head-end LSRs and points of local repair (PLRs).¶
If a network action requires in-stack ancillary data, the NAI that indicates this network action MUST be present in the label stack.¶
All NAIs MUST be encoded in a manner consistent with [RFC3031].¶
If there is post-stack ancillary data for an NAI that is present in the label stack, it MUST be possible to infer the presence of the ancillary data without having to parse below the bottom of the label stack.¶
Any processing that removes an NAI from the label stack MUST also remove all associated ancillary data from the MPLS packet unless the ancillary data is required by any remaining NAIs.¶
MNA solutions MUST request that IANA create registries and make allocations from those registries for NAIs as necessary to ensure unambiguous identification of standardized network actions. An MNA solution MAY request that IANA reserve a range of a registry for Private Use.¶
A Network Action solution MUST state where the NAIs are to be placed in the MPLS packet, that is whether they are placed in-stack or post-stack.¶
Network action solutions MUST specify whether ancillary data is required to fulfill the action and whether it is in-stack and/or post-stack.¶
Network action solutions MUST specify if in-stack or post-stack ancillary data that is already present in the MPLS packet MAY be rewritten by an LSR.¶
Solutions for in-stack ancillary data MUST be able to coexist with and MUST NOT obsolete existing MPLS mechanisms. Such solutions MUST be described in a Standards Track RFC.¶
Network Action solutions MUST take care to limit the quantity of in-stack ancillary data to the minimum amount required.¶
A Network Action solution SHOULD NOT use post-stack ancillary data unless the size of that ancillary data could prevent the coexistence of the network action with other in-use MPLS network functions if it were inserted into the label stack.¶
The structure of the NAI and any associated ancillary data MUST enable skipping of unknown NAIs and any associated AD.¶
Any MNA solution MUST describe whether it can coexist with existing post-stack data mechanisms (e.g., control words and the Generic Associated Channel Header), and if so how coexistence operates.¶
An MNA solution MUST allow an LER that inserts ancillary data to determine whether each node that needs to process the ancillary data can read the required distance into the MPLS packet at that node (compare with the mechanism in [RFC9088]).¶
For scoped in-stack or post-stack ancillary data, any MNA solution MUST allow an LER inserting NAIs whose network actions make use of that ancillary data to determine if the NAI and ancillary data will be processed by LSRs within the scope along the path. Such a solution may need to determine if LSRs along the path can process a specific type of AD implied by the NAI at the depth in the stack that it will be presented to the LSR.¶
A mechanism MUST exist to notify an egress LER of the presence of ancillary data so that it can dispose of it appropriately.¶
In-stack ancillary data MUST only be inserted in conjunction with an operation conforming with [RFC3031].¶
Post-stack ancillary data MUST only be inserted in conjunction with an operation conforming with [RFC3031].¶
Processing of ancillary data below a swapped label MAY include rewriting the ancillary data.¶
A Network Action solution that needs to change the size of the ancillary data MUST analyze the implications on MPLS packet forwarding and specify how these are addressed.¶
Not more than one Standards Track solution SHOULD be defined for encoding in-stack ancillary data.¶
Not more than one Standards Track solution SHOULD be defined for encoding post-stack ancillary data.¶
This document has no IANA actions.¶
Solutions designed according to the requirements in this document may introduce new security considerations to MPLS, whose forwarding plane on its own does not provide any built-in security mechanisms [RFC5920].¶
In particular, such solutions may embed information derived from the MPLS payload in the MPLS headers. This may expose data that a user of the MPLS-based service might otherwise assume is opaque to the MPLS network. Furthermore, an LSR may insert information into the labeled packet such that the forwarding behavior is no longer purely a function of the top label or another label with forwarding context. Instead, the forwarding behavior may be the result of a more complex heuristic. This creates an implicit trust relationship between the LSR whose forwarding behavior is being changed and the upstream LSR inserting the data causing that change.¶
Several requirements above address some of these considerations. The MNA framework [MNA-FRAMEWORK] also provides security considerations resulting from any extensions to the MPLS architecture, and these SHOULD be taken together with the security considerations herein.¶
Individual solution specifications meeting the requirements in this document MUST address any security considerations introduced by the MNA design.¶
The authors gratefully acknowledge the contributions from Joel Halpern, Greg Mirsky, Yingzhen Qu, Haoyu Song, Tarek Saad, Loa Andersson, Tony Li, Adrian Farrel, Jie Dong, Bruno Decraene, and participants in the MPLS Working Group who have provided comments.¶
The authors also gratefully acknowledge the input of the members of the MPLS Open Design Team.¶