| MPLS Working Group | A. Farrel |
| Internet-Draft | Juniper Networks |
| Intended status: Standards Track | S. Bryant |
| Expires: August 5, 2018 | Huawei |
| J. Drake | |
| Juniper Networks | |
| February 1, 2018 |
An MPLS-Based Forwarding Plane for Service Function Chaining
draft-farrel-mpls-sfc-03
Service 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 to identify the forwarding actions to be taken at each hop through a network. Segment Routing is a mechanism that provides a source routing paradigm for steering packets in an MPLS network.
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 5, 2018.
Copyright (c) 2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Service 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].
When applying a particular Service Function Chain to the traffic selected by a service classifier, the traffic needs to be steered through an ordered set of Service Functions (SFs) in the network. This ordered set of SFs is termed a Service Function Path (SFP), and the traffic is passed between Service Function Forwarders (SFFs) that are responsible for delivering the packets to the SFs and for forwarding them onward to the next SFF.
In order to steer the selected traffic between SFFs and to the correct SFs the service classifier needs to attach information to each packet. This information indicates the SFP on which the packet is being forwarded and hence the SFs to which it must be delivered. The information also indicates the progress the packet has already made along the SFP.
The Network Service Header (NSH) [RFC8300] has been defined to carry the necessary information for Service Function Chaining in packets. The NSH can be inserted into packets and contains various information including a Service Path Indicator (SPI), a Service Index (SI), and a Time To Live (TTL) counter.
Multiprotocol Label Switching (MPLS) [RFC3031] is a widely deployed forwarding technology that uses labels to identify the forwarding actions to be taken at each hop through a network. In many cases, MPLS will be used as a tunneling technology to carry packets through networks between SFFs.
Segment Routing [RFC7855] defines a source routing paradigm for use in packet switched networks. The application of Segment Routing in MPLS networks is described in [I-D.ietf-spring-segment-routing-mpls] and is known as MPLS-SR.
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. This approach is applicable to both classical MPLS forwarding (where labels are looked up at each hop, and swapped for the next hop [RFC3031]) and MPLS Segment Routing (where labels are looked up at each hop, and popped to reveal the next label to action [I-D.ietf-spring-segment-routing-mpls]). The mechanisms described in this document are a compromise between the full function that can be achieved using the NSH, and the benefits of reusing the existing MPLS forwarding paradigms.
It is assumed that the reader is fully familiar with the terms and concepts introduced in [RFC7665] and [RFC8300].
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.
While [RFC8300] defines the NSH that can be used in a number of environments, this document provides a mechanism to handle situations in which the NSH is not ubiquitously deployed. In this case it is possible to use an alternative data plane representation of the SPI/SI by carrying the identical semantics in MPLS labels.
In order to correctly select the mechanism by which SFC information is encoded and carried between SFFs, it may be necessary to configure the capabilities and choices either within the whole Service Function Overlay Network, or on a hop by hop basis. It is a requirement that both ends of a tunnel over the underlay network (i.e., a pair of SFFs adjacent in the SFC) know that the tunnel is used for SFC and know what form of NSH representation is used. A control plane signalling approach to achieve these objectives is provided using BGP in [I-D.ietf-bess-nsh-bgp-control-plane].
Note that the encoding of the SFC information is independent of the choice of tunneling technology used between SFFs. Thus, an MPLS representation of the logical NSH (as defined in this document) may be used even if the tunnel between a pair of SFFs is not an MPLS tunnel. Conversely, MPLS tunnels may be used to carry other encodings of the logical NSH (specifically, the NSH itself).
When an MPLS label stack is used to carry a logical NSH, a basic unit of representation is used. This unit comprises two MPLS labels as shown below. The unit may be present one or more times in the label stack as explained in subsequent sections.
In order to convey the same information as is present in the NSH, two MPLS label stack entries are used. One carries a label to provide context within the SFC scope (the SFC Context Label), and the other carries a label to show which service function is to be actioned (the SF Label). This two-label unit is shown in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFC Context Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Basic Unit of MPLS Label Stack for SFC
The fields of these two label stack entries are encoded as follows:
The sections that follow show how this basic unit of MPLS label stack may be used for SFC in the MPLS label swapping case and in the MPLS-SR case. For simplicity, these sections do not describe the use of metadata: that is covered separately in Section 10.
This section describes how the basic unit of MPLS label stack for SFC introduced in Section 4 is used when MPLS label swapping is in use. As can be seen from Figure 2, the top of the label stack comprises the labels necessary to deliver the packet over the MPLS tunnel between SFFs. Any MPLS encapsulation may be used (i.e., MPLS, MPLS in UDP, MPLS in GRE, and MPLS in VXLAN or GPE), thus the tunnel technology does not need to be MPLS, but that is shown here for simplicity.
An entropy label ([RFC6790]) may also be present as described in Section 9
Under these labels (or other encapsulation) comes a single instance of the basic unit of MPLS label stack for SFC. In addition to the interpretation of the fields of these label stack entries provided in Section 4 the following meanings are applied:
---------------
~ Tunnel Labels ~
+---------------+
~ Optional ~
~ Entropy Label ~
+---------------+ - - -
| SPI Label |
+---------------+ Basic unit of MPLS label stack for SFC
| SI Label |
+---------------+ - - -
| |
~ Payload ~
| |
---------------
Figure 2: The MPLS SFC Label Stack
The following processing rules apply to the Label fields:
The following processing rules apply to the TTL field of the SF label stack entry, and are derived from section 2.2 of [RFC8300]:
This section describes how the basic unit of MPLS label stack for SFC introduced in Section 4 is used when in an MPLS-SR network. As can be seen Figure 3, the top of the label stack comprises the labels necessary to deliver the packet over the MPLS tunnel between SFFs. Any MPLS encapsulation may be used and the tunnel technology does not need to be MPLS or MPLS-SR, but MPLS-SR is shown here for simplicity.
An entropy label ([RFC6790]) may also be present as described in Section 9
Under these labels (or other encapsulation) comes one of more instances of the basic unit of MPLS label stack for SFC. In addition to the interpretation of the fields of these label stack entries provided in Section 4 the following meanings are applied:
-------------------
~ MPLS-SR Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
~ ~
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
| |
~ Payload ~
| |
-------------------
Figure 3: The MPLS SFC Label Stack for Segment Routing
The following processing rules apply to the Label fields:
The previous sections describe homogeneous networks where SFC forwarding is either all label swapping or all label popping. But it is also possible that different parts of the network utilize swapping or popping for different purposes.
When an SFF receives a packet containing an MPLS label stack, it checks whether it is processing an {SFP, SI} label pair for label swapping or a {context label, SFI index} label pair for MPLS-SR. It then selects the appropriate SFI to which to send the packet. When it receives the packet back from the SFI, it has four cases to consider.
In order that a packet may be forwarded along an SFP several functional elements must be executed.
Various approaches may be taken. These include a fully centralized model where SFFs report to a central controller the SFIs that they support, the central controller computes the SFP and programs the Classifiers, and (if the label swapping approach is taken) the central controller installs forwarding state in the SFFs that lie on the SFP.
Alternatively, a dynamic control plane may be used such as that described in [I-D.ietf-bess-nsh-bgp-control-plane]. In this case the SFFs use the control plane to advertise the SFIs that they support, a central controller computes the SFP and programs the Classifiers, and (if the label swapping approach is taken) the central controller uses the control plane to advertise the SFPs so that SFFs that lie on the SFP can install the necessary forwarding state.
Entropy is used in ECMP situations to ensure that packets from the same flow travel down the same path, thus avoiding jitter or re-ordering issues within a flow.
Entropy is often determined by hashing on specific fields in a packet header such as the "five-tuple" in the IP and transport headers. However, when an MPLS label stack is present, the depth of the stack could be too large for some processors to correctly determine the entropy hash. This problem is addressed by the inclusion of an Entropy Label as described in [RFC6790].
When entropy is desired for packets as they are carried in MPLS tunnels over the underlay network, it is RECOMMENDED that an Entropy Label is included in the label stack immediately after the tunnel labels and before the SFC labels as shown in Figure 2 and Figure 3.
If an Entropy Label is present in a packet received by an SR-capabale node (at the end of a tunnel across the underlay network), it is RECOMMENDED that the value of that label is preserved and used in an Entropy Label inserted in the label stack when the packet is forwarded (on the next tunnel) to the next SFF.
If an Entropy Label is present in an MPLS payload, it is RECOMMENDED that the initial Classifier use that value in an Entropy Label inserted in the label stack when the packet is forwarded (on the first tunnel) to the first SFF. In this case it is not necessary to remove the Entropy Label from the payload.
Metadata is defined in [RFC7665] as providing "the ability to exchange context information between classifiers and SFs, and among SFs." [RFC8300] defines how this context information can be directly encoded in fields that form part of the NSH encapsulation.
The next two sections describe how metadata is associated with user data packets, and how metadata may is exchanged between SFC nodes in the network, when using an MPLS encoding of the logical representation of the NSH.
Metadata is achieved in the MPLS realization of the logical NSH by the use of an SFC Metadata Label which uses the Extended Special Purpose Label construct [RFC7274]. Thus, three label stack entries are present as shown in Figure 4:
----------------
| Extension = 15 |
+----------------+
| MLI |
+----------------+
| Metadata Label |
---------------
Figure 4: The MPLS SFC Metadata Label
The Metadata Label value is an index into a table of metadata that is programmed into the network using in-band or out-of-band mechanisms. Out-of-band mechanisms potentially include management plane and control plane solutions (such as [I-D.ietf-bess-nsh-bgp-control-plane]), but are out of scope for this document. The in-band mechanism is described in Section 10.2
The SFC Metadata Label (as a set of three labels as indicated in Figure 4) may be present zero, one, or more times in an MPLS SFC packet. For MPLS label swapping, the SFC Metadata Labels are placed immediately after the basic unit of MPLS label stack for SFC as shown in Figure 5. For MPLS-SR, the SFC Metadata Labels can be present zero, one, or more times and are placed at the bottom of the label stack as shown in Figure 6.
----------------
~ Tunnel Labels ~
+----------------+
~ Optional ~
~ Entropy Label ~
+----------------+
| SPI Label |
+----------------+
| SI Label |
+----------------+
| Extension = 15 |
+----------------+
| MLI |
+----------------+
| Metadata Label |
+----------------+
~ Other ~
| Metadata |
~ Label Triples ~
+----------------+
| |
~ Payload ~
| |
----------------
Figure 5: The MPLS SFC Label Stack for Label Swapping with Metadata Label
-------------------
~ MPLS-SR Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
~ ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| Extension = 15 |
+-------------------+
| MLI |
+-------------------+
| Metadata Label |
+-------------------+
~ Other ~
| Metadata |
~ Label Triples ~
+-------------------+
| |
~ Payload ~
| |
-------------------
Figure 6: The MPLS SFC Label Stack for MPLS-SR with Metadata Label
A mechanism for sending metadata associated with an SFP without a payload packet is described in [I-D.farrel-sfc-convent]. The same approach can be used in an MPLS network where the NSH is logically represented by an MPLS label stack.
The packet header is formed exactly as previously described in this document so that the packet will follow the SFP through the SFC network. However, instead of payload data, metadata is included after the bottom of the MPLS label stack. An Extended Special Purpose Label is used to indicate that the metadata is present. Thus, three label stack entries are present:
The SFC Metadata Present Label, if present, is placed immediately after the last basic unit of MPLS label stack for SFC. The resultant label stacks are shown in Figure 7 for the MPLS label swapping case and Figure 8 for the MPLS-SR case.
---------------
~ Tunnel Labels ~
+---------------+
~ Optional ~
~ Entropy Label ~
+---------------+
| SPI Label |
+---------------+
| SI Label |
+---------------+
| Extension = 15|
+---------------+
| MPI |
+---------------+
| Metadata Label|
+---------------+
| |
~ Metadata ~
| |
---------------
Figure 7: The MPLS SFC Label Stack Carrying Metadata
-------------------
~ MPLS-SR Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
~ ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| Extension = 15 |
+-------------------+
| MPI |
+-------------------+
| Metadata Label |
+-------------------+
| |
~ Metadata ~
| |
-------------------
Figure 8: The MPLS SFC Label Stack for MPLS-SR Carrying Metadata
In both cases the metadata is formatted as a TLV as shown in Figure 9.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Metadata Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Metadata ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The Metadata TLV
The fields of this TLV are interpreted as follows:
Consider the simplistic MPLS SFC overlay network shown in Figure 10. A packet is classified for an SFP that will see it pass through two Service Functions, SFa and SFb, that are accessed through Service Function Forwarders SFFa and SFFb respectively. The packet is ultimately delivered to destination, D.
Let us assume that the SFP is computed and assigned the SPI of 239. The forwarding details of the SFP are distributed (perhaps using the mechanisms of [I-D.ietf-bess-nsh-bgp-control-plane]) so that the SFFs are programmed with the necessary forwarding instructions.
The packet progresses as follows:
Further labels may be imposed to tunnel the packet from the Classifier to SFFa.
Further labels may be imposed to tunnel the packet from the SFFa to SFFb.
+---------------------------------------------------+
| MPLS SFC Network |
| |
| +---------+ +---------+ |
| | SFa | | SFb | |
| +----+----+ +----+----+ |
| ^ | | ^ | | |
| (b)| | |(c) (e)| | |(f) |
| (a) | | V (d) | | V (g) |
+----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
|Classifier+------+ SFFa +-------+ SFFb +------+ D |
+----------+ +---------+ +---------+ +-------+
| |
+---------------------------------------------------+
Figure 10: Service Function Chaining in an MPLS Network
Alternatively, consider the MPLS SFC overlay network shown in Figure 11. A packet is classified for an SFP that will see it pass through two Service Functions, SFx and SFy, that are accessed through Service Function Forwarders SFFx and SFFy respectively. The packet is ultimately delivered to destination, D.
Let us assume that the SFP is computed and assigned the SPI of 239. However, the forwarding state for the SFP is not distributed and installed in the network. Instead it will be attached to the individual packets using MPLS-SR.
The packet progresses as follows:
Further labels may be imposed to tunnel the packet from the Classifier to SFFx.
Further labels may be imposed to tunnel the packet from the SFFx to SFFy.
+---------------------------------------------------+
| MPLS-SR SFC Network |
| |
| +---------+ +---------+ |
| | SFx | | SFy | |
| +----+----+ +----+----+ |
| ^ | | ^ | | |
| (2)| | |(3) (5)| | |(6) |
| (1) | | V (4) | | V (7) |
+----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
|Classifier+------+ SFFx +-------+ SFFy +------+ D |
+----------+ +---------+ +---------+ +-------+
| |
+---------------------------------------------------+
Figure 11: Service Function Chaining in an MPLS-SR Network
Discussion of the security properties of SFC networks can be found in [RFC7665]. Further security discussion for the NSH and its use is present in [RFC8300].
It is fundamental to the SFC design that the classifier is a trusted resource which determines the processing that the packet will be subject to, including for example the firewall. It is also fundamental to the Segment Routing design that packets are routed through the network using the path specified by the node imposing the SIDs. Where an SF is not encapsulation aware the packet may exist as an IP packet, however this is an intrinsic part of the SFC design which needs to define how a packet is protected in that environment. Where a tunnel is used to link two non-MPLS domains, the tunnel design needs to specify how it is secured. Thus the security vulnerabilities are addressed in the underlying technologies used by this design, which itself does not introduce any new security vulnerabilities.
This document requests IANA to make allocations from the "Extended Special-Purpose MPLS Label Values" subregistry of the "Special-Purpose Multiprotocol Label Switching (MPLS) Label Values" registry as follows:
Value | Description |
-------+-----------------------------------+--------------
TBD1 | Metadata Label Indicator (MLI) | [This.I-D]
TBD2 | Metadata Present Indicator (MPI) | [This.I-D]
This document derives ideas and text from [I-D.ietf-bess-nsh-bgp-control-plane].
The authors are grateful to all those who contributed to the discussions that led to this work: Loa Andersson, Andrew G. Malis, Alexander Vainshtein, Joel M. Halpern, Tony Przygienda, Stuart Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided helpful review comments.
| [I-D.ietf-spring-segment-routing-mpls] | Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing with MPLS data plane", Internet-Draft draft-ietf-spring-segment-routing-mpls-11, October 2017. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7274] | Kompella, K., Andersson, L. and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [RFC8300] | Quinn, P., Elzur, U. and C. Pignataro, "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018. |