MPLS Transport Encapsulation For The SFC NSHHuawei Technologiesagmalis@gmail.comHuawei Technologiesstewart.bryant@gmail.comEricssonjoel.halpern@ericsson.comNokiawim.henderickx@nokia.comMPLS Working GroupThis document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet original packet/frame. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and to select one of multiple SFFs in the destination MPLS node.As discussed in , a number of transport encapsulations for the Service Function Chaining (SFC) Network Service Header (NSH) already exist, such as Ethernet, UDP, GRE, and others.This document describes an MPLS transport encapsulation for the NSH and how to use a Service Function Forwarder (SFF) Label to indicate the presence of the NSH in the MPLS packet payload. This allows SFC packets using the NSH to be forwarded between SFFs in an MPLS transport network, where MPLS is used to interconnect the network nodes that contain one or more SFFs. The label is also used to select between multiple SFFs in the destination MPLS node.This encapsulation is equivalent from an SFC perspective to other transport encapsulations of packets using the NSH. This can be illustrated by adding an additional line to the example of a next-hop SPI/SI-to-network overlay network locator mapping in Table 1 of :SFF Labels are similar to other service labels at the bottom of an MPLS label stack that denote the contents of the MPLS payload being other than a normally routed IP packet, such as a layer 2 pseudowire, an IP packet that is routed in a VPN context with a private address, or an Ethernet virtual private wire service.This informational document follows well-established MPLS procedures and does not require any actions by IANA or any new protocol extensions.Note that using the MPLS label stack as a replacement for the SFC NSH, covering use cases that do not require per-packet metadata, is described elsewhere .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.The encapsulation is a standard MPLS label stack with an SFF Label at the bottom of the stack, followed by a NSH as defined by and the NSH original packet/frame.Much like a pseudowire label, an SFF Label MUST be allocated by the downstream receiver of the NSH from its per-platform label space, since the meaning of the label is identical independent of which incoming interface it is received .If a receiving node supports more than one SFF (i.e., more than one SFC forwarding instance), then the SFF Label can be used to select the proper SFF, by having the receiving node advertise more than one SFF Label to its upstream sending nodes as appropriate.The method used by the downstream receiving node to advertise SFF Labels to the upstream sending node is out of scope of this document. That said, a number of methods are possible, such as via a protocol exchange, or via a controller that manages both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc. One such BGP-based method has already been defined, and is documented in .
This does not constrain the further definition of other such advertisement methods in the future.While the SFF label will usually be at the bottom of the label stack, there may be cases where there are additional label stack entries beneath it. For example, when an Associated Channel Header (ACH) is carried that applies to the SFF, a Generic Associated Channel Label (GAL) will be in the label stack below the SFF. Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) may be carried below the SFF in the label stack. This is identical to the situation with VPN labels.This document does not define a use for the Traffic Class (TC) field (formerly known as the Experimental Use (EXP) bits ) in the SFF Label.When one SFF wishes to send an SFC packet with a NSH to another SFF over an MPLS transport network, a label stack needs to be constructed by the MPLS node that contains the sending SFF in order to transport the packet to the destination MPLS node that contains the receiving SFF. The label stack is constructed as follows:Push zero or more labels that are interpreted by the destination MPLS node on to the packet, such as the Generic Associated Channel label (see ). The TTL For these labels is set according to the relevant standards that define these labels.Push the SFF Label to identify the desired SFF in the receiving MPLS node. The TTL For this MPLS label MUST be set to one to avoid mis-forwarding.Push zero or more additional labels such that (a) the resulting label stack will cause the packet to be transported to the destination MPLS node, and (b) when the packet arrives at the destination node, either: the SFF Label will be at the top of the label stack (this is typically the case when penultimate hop popping is used at the penultimate node, or the source and destination nodes are direct neighbors), oras a part of normal MPLS processing, the SFF Label becomes the top label in the stack before the packet is forwarded to another node and before the packet is dispatched to a higher layer.The TTL for these labels is set by configuration, or set to the defaults for normal MPLS operation in the network.The destination MPLS node performs a lookup on the SFF label to retrieve the next-hop context between the SFF and SF, e.g. to retrieve the destination MAC address in the case where native Ethernet encapsulation is used between SFF and SF. How the next-hop context is populated is out of the scope of this document.The receiving SFF SHOULD check that the received SFF label has a TTL of 1 upon receipt. Any other values indicate a likely error condition and SHOULD result in discarding the packet.The receiving MPLS node then pops the SFF Label (and any labels beneath it) so that the destination SFF receives the SFC packet with the NSH is at the top of the packet.As discussed in and , there are ECMP considerations for payloads carried by MPLS.Many existing routers use deep packet inspection to examine the payload of an MPLS packet, and if the first nibble of the payload is equal to 0x4 or 0x6, these routers (sometimes incorrectly, as discussed in ) assume that the payload is IPv4 or IPv6
respectively, and as a result, perform ECMP load balancing based on (presumed) information present in IP/TCP/UDP payload headers or in a combination of MPLS label stack and (presumed) IP/TCP/UDP payload headers in the packet.For SFC, ECMP may or may not be desirable. To prevent ECMP when it is not desired, the NSH Base Header was carefully constructed so that the NSH could not look like IPv4 or IPv6 based on its first nibble. See Section 2.2 of for further details.If ECMP is desired when SFC is used with an MPLS transport network, there are two possible options, Entropy and Flow-Aware Transport labels. A recommendation between these options, and their proper placement in the label stack, is for future study.OAM at the SFC Layer is handled by SFC-defined mechanisms . However, OAM may be required at the MPLS transport layer. If so, then standard MPLS-layer OAM mechanisms may be used at the transport label layer (the labels above the SFF label).This document does not request any actions from IANA.Editorial note to RFC Editor: This section may be removed at your discretion.This document describes a method for transporting SFC packets using the NSH over an MPLS transport network. It follows well-established MPLS procedures in widespread operational use and does not define any new protocol elements or allocate any new code points, and is no more or less secure than carrying any other protocol over MPLS. To the MPLS network, the NSH and its contents is simply an opaque payload.Discussion of the security properties of SFC networks can be found in . Further security discussion regarding the NSH is contained in . references a number of transport encapsulations of the NSH, including Ethernet, GRE, UDP, and others. This document simply defines one additional transport encapsulation. The NSH was specially constructed to be agnostic to its transport encapsulation. As as result, in general this additional encapsulation is no more or less secure than carrying the NSH in any other encapsulation.However, it can be argued that carrying the NSH over MPLS is more secure than using other encapsulations, as it is extremely difficult, due to the MPLS architecture, for an attempted attacker to inject unexpected MPLS packets into a network, as MPLS networks do not by design accept MPLS packets from external interfaces, and an attacker would need knowledge of the specific labels allocated by control and/or management plane protocols. Thus, an attacker attempting to spoof MPLS-encapsulated NSH packets would require insider knowledge of the network’s control and management planes and a way to inject packets into internal interfaces. This is compared to, for example, NSH over UDP over IP, which could be injected into any external interface in a network that was not properly configured to filter out such packets at the ingress.The authors would like to thank Jim Guichard, Eric Rosen, Med Boucadair, Sasha Vainshtein, Jeff Tantsura, Anoop Ghanwani, John Drake, Loa Andersson, Carlos Pignataro, and Christian Hopps for their reviews and comments.Key words for use in RFCs to Indicate Requirement LevelsIn 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.Multiprotocol Label Switching ArchitectureThis document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]MPLS Label Stack EncodingThis 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]Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" FieldThe early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field.To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK]Service Function Chaining (SFC) ArchitectureThis 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.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Network Service Header (NSH)This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining (SFC) encapsulation required to support the SFC architecture (defined in RFC 7665).BGP Control Plane for NSH SFCThis document describes the use of BGP as a control plane for networks that support Service Function Chaining (SFC). The document introduces a new BGP address family called the SFC AFI/SAFI with two route types. One route type is originated by a node to advertise that it hosts a particular instance of a specified service function. This route type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other route type is used by a Controller to advertise the paths of "chains" of service functions, and to give a unique designator to each such path so that they can be used in conjunction with the Network Service Header. This document adopts the SFC architecture described in RFC 7665.An MPLS-Based Forwarding Plane for Service Function ChainingService Function Chaining (SFC) is the process of directing packets through a network so that they can be acted on by an ordered set of abstract service functions before being delivered to the intended destination. An architecture for SFC is defined in RFC7665. The Network Service Header (NSH) can be inserted into packets to steer them along a specific path to realize a Service Function Chain. Multiprotocol Label Switching (MPLS) is a widely deployed forwarding technology that uses labels placed in a packet in a label stack to identify the forwarding actions to be taken at each hop through a network. Actions may include swapping or popping the labels as well, as using the labels to determine the next hop for forwarding the packet. Labels may also be used to establish the context under which the packet is forwarded. This document describes how Service Function Chaining can be achieved in an MPLS network by means of a logical representation of the NSH in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. It does not deprecate or replace the NSH, but acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks.Avoiding Equal Cost Multipath Treatment in MPLS NetworksThis document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.MPLS Generic Associated ChannelThis 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.Flow-Aware Transport of Pseudowires over an MPLS Packet Switched NetworkWhere the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal Cost Multiple Paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs.This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. [STANDARDS-TRACK]The Use of Entropy Labels in MPLS ForwardingLoad 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]MPLS Forwarding Compliance and Performance RequirementsThis document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers.