]> Nokia

matthew.bocci@nokia.com

University of Surrey 5GIC

sb@stewartbryant.com

Juniper Networks

jdrake@juniper.com

MPLS Working Group This document specifies requirements for MPLS network actions which affect the forwarding or other processing of MPLS packets. These requirements are derived from a number of proposals for additions to the MPLS label stack to allow forwarding or other processing decisions to be made, either by a transit or terminating LSR (i.e. the LER).

Introduction There is significant interest in developing the MPLS data plane to address the requirements of new use cases , which require a general mechanism, termed MPLS network actions, for enhanced forwarding or other processing of MPLS packets. It is intended that this mechanism will be conformant to the greatest extent possible with the existing MPLS architecture as specified by, among other documents, , , and . This document specifies the requirements for MPLS network actions, as well as the encoding and use of the ancillary data.

Terminology

• Network Action: An operation to be performed on a packet or as a consequence of a packet being processed by a router. A network action may affect router state, packet forwarding, or it may affect the packet in some other way.
• Network Action Indication (NAI): An indication in the packet that a certain network action is to be performed.
• Ancillary Data (AD): Data in an MPLS packet associated with a given Network Action that may be used as input to the processing of the Network Action or results from the processing of the Network Action.
• In-Stack Data: Ancillary data carried within the MPLS label stack.
• Post-Stack Data: Ancillary data carried in a packet between the bottom of the MPLS label stack and the first octet of the user payload. This document does not prescribe whether post-stack data precedes or follows any other protocol structure such as a control word or associated channel header (ACH).
• Scope: The set of nodes that should perform a given action.

Background The MPLS architecture is specified in and provides a mechanism for forwarding packets through a network without requiring any analysis of the 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 packet is assigned to a forwarding equivalence class (FEC). MPLS uses switching based on a label pushed on the packet to achieve efficient forwarding and traffic engineering of flows associated with the FEC. While originally used for IP traffic, MPLS has been extended to support point-to-point, point-to-multipoint and multipoint-to-multipoint layer 2 and layer 3 services. An overview of the development of MPLS is provided in . A number of applications have emerged which require LSRs to make forwarding or other processing decisions based on inspection of the network layer header, or some other ancillary information in the protocol stack encapsulated deeper in the packet. An early example of this was generation of a hash of the payload header to be used for load balancing over Equal Cost Multipath (ECMP) or Link Aggregation Group (LAG) next hops. This is based on an assumption that the network layer protocol is IP. MPLS was extended to avoid the need for LSRs to perform this operation if load balancing was needed based on the payload and instead use only the MPLS label stack, using the Entropy Label / Entropy Label Indicator which are inserted at the LER. Other applications where the intermediate LSRs may need to inspect and process a packet on an LSP include OAM, which can make use of mechanisms such the Router Alert Label or the Generic Associated Channel Label (GAL) to indicate that an intercepted packet should be processed locally. See for detailed list of such applications. There have been a number of new proposals for how network actions and associated ancillary data is to be carried in MPLS and how its presence is indicated to the LSR or egress LER, for example In-situ OAM and Service Function Chaining (SFC) . A summary of these proposals is contained in , and an overview of use cases is provided in . discusses some of the issues with these proposals (note that this document draws on the requirements and issues without endorsing a specific solution from ): New use cases therefore require the definition of extensions to the MPLS architecture and label stack operations that can be used across these use cases in order to minimise implementation complexity and promote interoperability and extensibility.

Requirements Language 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 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.

MPLS Network Action Requirements This document specifies requirements of MPLS Network Action (MNA) Indicators (NAIs), and the associated Ancillary Data, as well as the alert mechanism (the MPLS Network Action Sub-Stack Indicator) to indicate to an LSR or LER that NAIs are present in a 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 purpose of this document is to identify the toolkit and any new protocol work that is required. This new protocol work MUST be based on the existing MPLS architecture.

General Requirements

1. MPLS combines extensibility, flexibility and efficiency by using control plane context combined with a simple data plane mechanism to allow the network to make forwarding decisions about a packet. Any solution MUST maintain these properties of MPLS.
2. Any MNA solutions to these requirements MUST NOT restrict the generality of MPLS architecture , and .
3. If extensions to the MPLS data plane are required, they MUST NOT be inconsistent with the MPLS architecture , and .
4. MNA solutions meeting the requirements set out in this document MUST be able to coexist with and MUST NOT obsolete existing MPLS mechanisms.
5. Subject to the constraints in these requirements a solution MAY carry MNA information in-stack, post-stack or both in-stack and post-stack.
6. The design of any MNA solution SHOULD be such that an LSR is able to efficiently parse the label stack.
7. Any MNA solution specification MUST discuss the ECMP consequences of the design.
8. Consistent with MPLS best practise, MNA solutions MUST NOT increase the size of the MPLS label stack more than is necessary.
9. MNA 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.
10. The design of any MNA solution MUST NOT expose confidential information to the LSRs.
11. Any MNA solution specification MUST document any changes to the existing MPLS data plane security model that it introduces.
12. An MNA solution MUST allow NAI-carrying and non-NAI-carrying packets to coexist on the same LSP.

Requirements on the MPLS Network Action Sub-Stack Indicator

1. An MNA solution MUST define how a node determines whether Network Action Indicators (NAIs) are present in the packet.
2. If NAIs are required, an MNA solution MUST specify where they are to be placed in the packet i.e. in-stack or post-stack.
3. An MNA solution MUST respect the principle that Special Purpose Labels are the mechanism of last resort and therefore must minimise the number of new SPLs that are allocated.

Requirements on Network Action Indicators

1. Insertion, parsing, processing and disposition of NAIs SHOULD make use of existing MPLS data plane operations.
2. An NAI MUST NOT be delivered to a node that is not capable of processing the indicated network action in a way that is acceptable to the imposing LER.
3. An MNA solution MUST enable a node inserting or modifying NAIs to determine if the far-end LER can accept and process a packet containing a given NAI.
4. The NAI design MUST support scoping of network actions.
5. A given NAI specification MUST specify if the scope is end-to-end, hop-by-hop, or directed at one or more selected nodes.
6. If an MNA solution allows more than one scope, it MUST provide a mechanism to specify the precedence of the scopes.
7. An MNA solution SHOULD support NAIs for both P2P and P2MP paths, but any specific NAI MAY only be supported for one or the other.
8. An MNA solution defining data plane mechanisms for NAIs MUST be consistent across different control plane protocol types.
9. An MNA solution MUST allow the in-use control / management planes to determine the ability of downstream LSRs/LERs to accept/process a given NAI.
10. An MNA solution SHOULD allow indicators for multiple network actions in the same packet.
11. An MNA solution MUST support the processing of a subset of the NAIs on a packet.
12. NAIs SHOULD only be inserted at LERs, and MAY be processed at LSRs and LERs.
13. If a network action needs to insert an NAI with in-stack ancillary data at an LSR on an LSP, then the new network action indicator and any required ancillary data MUST be pushed onto the MPLS label stack.
14. If a network action needs to insert an NAI with below stack ancillary data at an LSR on an LSP, then the MNA solution specification MUST specify how this is achieved in all circumstances and MUST be consistent with {RFC3031}.
15. MPLS network action specifications MUST specify if in-stack or post-stack ancillary data can be rewritten by an LSR.
16. An MPLS network action specification MUST specify whether ancillary data is required and whether it is in-stack and/or post-stack.
17. Network action indicators MUST be allocated through the IANA process specified in the MNA solution specification.
18. Is it RECOMENDED that an MPLS network action specification supports network actions for private use .
19. A node removing an NAI MUST NOT leave the MPLS label stack in such a way that downstream nodes are unable to determine the presence of ancillary data remaining in the packet.

Requirements on Ancillary Data

1. 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.
2. MNA solutions MUST take care to limit the quantity of in-stack ancillary data to the minimum amount required.
3. A common preamble for ancillary data MUST be defined so that a node receiving the ancillary data can determine whether to process, ignore, skip over or discard it according to network or local policies.
4. A standardised container MUST be defined for in-stack ancillary data based on the MPLS LSE.
5. Any MNA solution specification MUST describe whether it can coexist with existing post-stack data mechanisms e.g. control words and G-ACH, and if so how this coexistence operates.
6. An MNA solution MUST allow an LER inserting ancillary data to determine that each node that needs to process the ancillary data can read the required distance into the packet at that node, for example .
7. In order to prevent unnecessary scanning of the packet, care needs to be taken in the location of any post stack ancillary data, for example it SHOULD be located as close to the bottom of the label stack as possible.
8. Ancillary data MAY be associated with control or maintenance information for traffic carried by an LSP, and/or it MAY be associated with the user traffic itself.
9. For scoped 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.
10. MNA solution specifications MUST specify if the ancillary data needs to be processed as a part of the immediate forwarding operation and whether packet mis-ordering is allowed to occur as a result of the time taken to process the ancillary data. Ed. We think this applies to both NAs and ancillary data and should be generalised.
11. A solution MUST be provided to verify the authenticity of ancillary data processed to LSRs .
12. The design of the ancillary data MUST NOT expose confidential information to the LSRs.
13. A mechanism MUST exist to notify an egress LER of the presence of ancillary data so that it can dispose of it appropriately.
14. An egress LER MUST NOT forward a packet with ancillary data to a node that is not expecting the ancillary data to be present.
15. The size of the ancillary data carried post-stack end-to-end in a packet is a matter for agreement between the ingress and egress PEs, and is not part of these requirements.

IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC.

Security Considerations The mechanisms required by this document introduce new security considerations to MPLS. Individual solution specifications meeting these requirements MUST address any security considerations.

Acknowledgements The authors gratefully acknowledge the contributions from Greg Mirsky, Yingzhen Qu, Haoyu Song, Tarek Saad, Loa Andersson, Tony Li, Adrian Farrel, Jie Dong and 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.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References University of Surrey There has been significant recent interest in developing MPLS to address new needs. This memo collects together various documents that together describe the key aspects of the MPLS architecture together with the development proposals that the author is aware of. The purpose of this document is to bring everyone up to speed on the rational for the existing design and to alert them to the new proposals. Futurewei Technologies Huawei Technologies Bronze Dragon Consulting Juniper Networks Cisco Systems Motivated by the need to support multiple in-network services and functions in an MPLS network (a.k.a. MPLS Network Actions (MNA)), this document describes a generic and extensible method to encapsulate MNA instructions as well as possible ancillary data in an MPLS packet. All the post-stack MNAs are encapsulated in a structure called Post-stack Action Header (PAH). A PAH is composed of a common header plus a chain of extension headers; each extension header is a container for an MNA. The encapsulation method allows chaining multiple post-stack extension headers and provides the means to enable fast access to them as well as the original upper layer headers. This document confines to the solution of PAH encoding and leaves the specification of PAH indicator to the overall MNA solution. We show how PAH can be used to support several new MNAs as a generic post-stack mechanism. Cisco Systems, Inc. Futurewei Technologies Futurewei Technologies Ericsson This document presents a number of use cases that have a common need for encoding network action indicators and associated ancillary data inside MPLS packets. There has been significant recent interest in extending the MPLS data plane to carry such indicators and ancillary data to address a number of use cases that are described in this document. The use cases described in this document are not an exhaustive set, but rather the ones that are actively discussed by members of the IETF MPLS, PALS and DETNET working groups participating in the MPLS Open Design Team. Cisco Systems, Inc. Cisco Systems, Inc. Cisco Systems, Inc. Cisco Systems, Inc. Comcast Comcast In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the data packet while the packet traverses a path between two nodes in the network. This document defines how IOAM data fields are transported with MPLS data plane encapsulation using new Generic Associated Channel (G-ACh). This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK] This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK] RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". [STANDARDS-TRACK] This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism. Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK] This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Multiprotocol Label Switching (MPLS) has defined a mechanism to load-balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load-balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities using IS-IS and Border Gateway Protocol - Link State (BGP-LS). Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols.