draft-farrel-mpls-sfc-04.txt   draft-farrel-mpls-sfc-05.txt 
MPLS Working Group A. Farrel MPLS Working Group A. Farrel
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track S. Bryant Intended status: Standards Track S. Bryant
Expires: September 3, 2018 Huawei Expires: September 23, 2018 Huawei
J. Drake J. Drake
Juniper Networks Juniper Networks
March 2, 2018 March 22, 2018
An MPLS-Based Forwarding Plane for Service Function Chaining An MPLS-Based Forwarding Plane for Service Function Chaining
draft-farrel-mpls-sfc-04 draft-farrel-mpls-sfc-05
Abstract Abstract
Service Function Chaining (SFC) is the process of directing packets 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 through a network so that they can be acted on by an ordered set of
abstract service functions before being delivered to the intended abstract service functions before being delivered to the intended
destination. An architecture for SFC is defined in RFC7665. destination. An architecture for SFC is defined in RFC7665.
The Network Service Header (NSH) can be inserted into packets to The Network Service Header (NSH) can be inserted into packets to
steer them along a specific path to realize a Service Function Chain. steer them along a specific path to realize a Service Function Chain.
Multiprotocol Label Switching (MPLS) is a widely deployed forwarding Multiprotocol Label Switching (MPLS) is a widely deployed forwarding
technology that uses labels to identify the forwarding actions to be technology that uses labels placed in a packet in a label stack to
taken at each hop through a network. Segment Routing is a mechanism identify the forwarding actions to be taken at each hop through a
that provides a source routing paradigm for steering packets in an network. Actions may include swapping or popping the labels as well,
MPLS network. 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 This document describes how Service Function Chaining can be achieved
in an MPLS network by means of a logical representation of the NSH in in an MPLS network by means of a logical representation of the NSH in
an MPLS label stack. an 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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2018. This Internet-Draft will expire on September 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Choice of Data Plane SPI/SI Representation . . . . . . . . . 4 3. Choice of Data Plane SPI/SI Representation . . . . . . . . . 4
4. Basic Unit of Representation . . . . . . . . . . . . . . . . 4 4. Basic Unit of Representation . . . . . . . . . . . . . . . . 4
5. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 5 5. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 6
6. MPLS Segment Routing . . . . . . . . . . . . . . . . . . . . 8 6. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 8
7. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 10 7. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 10
8. A Note on Service Function Capabilities and SFC Proxies . . . 11 8. A Note on Service Function Capabilities and SFC Proxies . . . 11
9. Control Plane Considerations . . . . . . . . . . . . . . . . 11 9. Control Plane Considerations . . . . . . . . . . . . . . . . 11
10. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 12 10. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 12
11. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Indicating Metadata in User Data Packets . . . . . . . . 13 11.1. Indicating Metadata in User Data Packets . . . . . . . . 13
11.2. Inband Programming of Metadata . . . . . . . . . . . . . 15 11.2. Inband Programming of Metadata . . . . . . . . . . . . . 15
12. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 18 12. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 18
13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
16.1. Normative References . . . . . . . . . . . . . . . . . . 23 16.1. Normative References . . . . . . . . . . . . . . . . . . 23
16.2. Informative References . . . . . . . . . . . . . . . . . 23 16.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Service Function Chaining (SFC) is the process of directing packets 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 through a network so that they can be acted on by an ordered set of
abstract service functions before being delivered to the intended abstract service functions before being delivered to the intended
destination. An architecture for SFC is defined in [RFC7665]. destination. An architecture for SFC is defined in [RFC7665].
When applying a particular Service Function Chain to the traffic When applying a particular Service Function Chain to the traffic
skipping to change at page 3, line 24 skipping to change at page 3, line 34
The information also indicates the progress the packet has already The information also indicates the progress the packet has already
made along the SFP. made along the SFP.
The Network Service Header (NSH) [RFC8300] has been defined to carry The Network Service Header (NSH) [RFC8300] has been defined to carry
the necessary information for Service Function Chaining in packets. the necessary information for Service Function Chaining in packets.
The NSH can be inserted into packets and contains various information The NSH can be inserted into packets and contains various information
including a Service Path Indicator (SPI), a Service Index (SI), and a including a Service Path Indicator (SPI), a Service Index (SI), and a
Time To Live (TTL) counter. Time To Live (TTL) counter.
Multiprotocol Label Switching (MPLS) [RFC3031] is a widely deployed Multiprotocol Label Switching (MPLS) [RFC3031] is a widely deployed
forwarding technology that uses labels to identify the forwarding forwarding technology that uses labels placed in a packet in a label
actions to be taken at each hop through a network. In many cases, stack to identify the forwarding actions to be taken at each hop
MPLS will be used as a tunneling technology to carry packets through 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. In many cases, MPLS
will be used as a tunneling technology to carry packets through
networks between SFFs. 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 This document describes how Service Function Chaining can be achieved
in an MPLS network by means of a logical representation of the NSH in 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 an MPLS label stack. This approach is applicable to all forms of
MPLS forwarding (where labels are looked up at each hop, and swapped MPLS forwarding (where labels are looked up at each hop, and swapped
for the next hop [RFC3031]) and MPLS Segment Routing (where labels or popped [RFC3031]). It does not deprecate or replace the NSH, but
are looked up at each hop, and popped to reveal the next label to acknowledges that there may be a need for an interim deployment of
action [I-D.ietf-spring-segment-routing-mpls]). The mechanisms SFC functionality in brownfield networks. The mechanisms described
described in this document are a compromise between the full function in this document are a compromise between the full function that can
that can be achieved using the NSH, and the benefits of reusing the be achieved using the NSH, and the benefits of reusing the existing
existing MPLS forwarding paradigms. MPLS forwarding paradigms.
It is assumed that the reader is fully familiar with the terms and It is assumed that the reader is fully familiar with the terms and
concepts introduced in [RFC7665] and [RFC8300]. concepts introduced in [RFC7665] and [RFC8300].
Note that one of the features of the SFC architecture described in
[RFC7665] is the "SFC proxy" that exists to include legacy SFs that
are not able to process NSH-encapsulated packets. This issue is
equally applicable to the use of MPLS-encapsulated packets that
encode a logical representation of an NSH. It is discussed further
in Section 8.
2. Requirements Language 2. 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 BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Choice of Data Plane SPI/SI Representation 3. Choice of Data Plane SPI/SI Representation
skipping to change at page 5, line 20 skipping to change at page 5, line 28
| SF Label | TC |S| TTL | | SF Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Basic Unit of MPLS Label Stack for SFC Figure 1: The Basic Unit of MPLS Label Stack for SFC
The fields of these two label stack entries are encoded as follows: The fields of these two label stack entries are encoded as follows:
Label: The Label fields contain the values of the SFC Context Label Label: The Label fields contain the values of the SFC Context Label
and the SF Label encoded as 20 bit integers. The precise and the SF Label encoded as 20 bit integers. The precise
semantics of these label fields are dependent on whether the label semantics of these label fields are dependent on whether the label
stack entries are used for MPLS swapping (see Section 5) or MPLS- stack entries are used for MPLS label swapping (see Section 5) or
SR (see Section 6). MPLS label stacking (see Section 6).
TC: The TC bits have no meaning. They SHOULD be set to zero in both TC: The TC bits have no meaning. They SHOULD be set to zero in both
label stack entries when a packet is sent and MUST be ignored on label stack entries when a packet is sent and MUST be ignored on
receipt. receipt.
S: The bottom of stack bit has its usual meaning in MPLS. It MUST be S: The bottom of stack bit has its usual meaning in MPLS. It MUST be
clear in the SFC Context label stack entry and MAY be set in the clear in the SFC Context label stack entry and MAY be set in the
SF label stack entry depending on whether the label is the bottom SF label stack entry depending on whether the label is the bottom
of stack. of stack.
TTL: The TTL field in the SFC Context label stack entry SHOULD be TTL: The TTL field in the SFC Context label stack entry SHOULD be
set to 1. The TTL in SF label stack entry (called the SF TTL) is set to 1. The TTL in SF label stack entry (called the SF TTL) is
set according to its use for MPLS swapping (see Section 5) or set according to its use for MPLS label swapping (see Section 5)
MPLS-SR (see Section 6 and is used to mitigate packet loops. or MPLS label stacking (see Section 6 and is used to mitigate
packet loops.
The sections that follow show how this basic unit of MPLS label stack 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- 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 label stacking. For simplicity, these sections do not describe the
metadata: that is covered separately in Section 11. use of metadata: that is covered separately in Section 11.
5. MPLS Label Swapping 5. MPLS Label Swapping
This section describes how the basic unit of MPLS label stack for SFC 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. 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 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 the labels necessary to deliver the packet over the MPLS tunnel
between SFFs. Any MPLS encapsulation may be used (i.e., MPLS, MPLS 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 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 technology does not need to be MPLS, but that is shown here for
skipping to change at page 8, line 23 skipping to change at page 8, line 23
unmodified along with the SI (which may have been changed by local unmodified along with the SI (which may have been changed by local
reclassification). reclassification).
o If a Classifier along the SFP makes any change to the intended o If a Classifier along the SFP makes any change to the intended
path of the packet including for looping, jumping, or branching path of the packet including for looping, jumping, or branching
(see [I-D.ietf-bess-nsh-bgp-control-plane] it MUST NOT change the (see [I-D.ietf-bess-nsh-bgp-control-plane] it MUST NOT change the
SI TTL of the packet. In particular, each component of the SFC SI TTL of the packet. In particular, each component of the SFC
system MUST NOT increase the SI TTL value otherwise loops may go system MUST NOT increase the SI TTL value otherwise loops may go
undetected. undetected.
6. MPLS Segment Routing 6. MPLS Label Stacking
This section describes how the basic unit of MPLS label stack for SFC 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 introduced in Section 4 is used when MPLS label stacking is used to
be seen Figure 3, the top of the label stack comprises the labels carry information about the SFP and SFs to be executed. As can be
seen in Figure 3, the top of the label stack comprises the labels
necessary to deliver the packet over the MPLS tunnel between SFFs. necessary to deliver the packet over the MPLS tunnel between SFFs.
Any MPLS encapsulation may be used and the tunnel technology does not Any MPLS encapsulation may be used.
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 An entropy label ([RFC6790]) may also be present as described in
Section 10 Section 10
Under these labels (or other encapsulation) comes one of more Under these labels comes one of more instances of the basic unit of
instances of the basic unit of MPLS label stack for SFC. In addition MPLS label stack for SFC. In addition to the interpretation of the
to the interpretation of the fields of these label stack entries fields of these label stack entries provided in Section 4 the
provided in Section 4 the following meanings are applied: following meanings are applied:
SFC Context Label: The Label field of the SFC Context label stack SFC Context Label: The Label field of the SFC Context label stack
entry contains a label that delivers SFC context. This label may entry contains a label that delivers SFC context. This label may
be used to indicate the SPI encoded as a 20 bit integer using the be used to indicate the SPI encoded as a 20 bit integer using the
semantics of the SPI is exactly as defined in [RFC8300] and noting semantics of the SPI is exactly as defined in [RFC8300] and noting
that in this case a system using MPLS representation of the that in this case a system using MPLS representation of the
logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or
less than 16. This label may also be used to convey other SFC less than 16. This label may also be used to convey other SFC
context-speific semantics such as indicating, perhaps with a node context-speific semantics such as indicating how to interpret the
SID (see [I-D.ietf-spring-segment-routing]), how to interpret the SF Label or how to forward the packet to the node that offers the
SF Label. SF.
SF Label: The Label field of the SF label stack entry contains a SF Label: The Label field of the SF label stack entry contains a
value that identifies the next SFI to be actioned for the packet. value that identifies the next SFI to be actioned for the packet.
This label may be scoped globally or within the context of the This label may be scoped globally or within the context of the
preceding SFC Context Label and comes from the range 16 ... 2^20 - preceding SFC Context Label and comes from the range 16 ... 2^20 -
1. 1.
TC: The TC fields are as described in Section 4. TC: The TC fields are as described in Section 4.
S: The S bits are as described in Section 4. S: The S bits are as described in Section 4.
TTL: The TTL field in the SFC Context label stack entry SHOULD be TTL: The TTL fields in the SFC Context label stack entry SF label
set to 1 as stated in Section 4. The TTL in SF label stack entry stack entry SHOULD be set to 1 as stated in Section 4, but MAY be
is set according to the norms for MPLS-SR. set to larger values if the label indicated a forwarding operation
towards the node that hosts the SF.
------------------- -------------------
~ MPLS-SR Labels ~ ~ Tunnel Labels ~
+-------------------+ +-------------------+
~ Optional ~ ~ Optional ~
~ Entropy Label ~ ~ Entropy Label ~
+-------------------+ - - - +-------------------+ - - -
| SFC Context Label | | SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC +-------------------+ Basic unit of MPLS label stack for SFC
| SF Label | | SF Label |
+-------------------+ - - - +-------------------+ - - -
| SFC Context Label | | SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC +-------------------+ Basic unit of MPLS label stack for SFC
skipping to change at page 9, line 42 skipping to change at page 9, line 43
+-------------------+ - - - +-------------------+ - - -
| SFC Context Label | | SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC +-------------------+ Basic unit of MPLS label stack for SFC
| SF Label | | SF Label |
+-------------------+ - - - +-------------------+ - - -
| | | |
~ Payload ~ ~ Payload ~
| | | |
------------------- -------------------
Figure 3: The MPLS SFC Label Stack for Segment Routing Figure 3: The MPLS SFC Label Stack for Label Stacking
The following processing rules apply to the Label fields: The following processing rules apply to the Label fields:
o When a Classifier inserts a packet onto an SFP it adds a stack o When a Classifier inserts a packet onto an SFP it adds a stack
comprising one or more instances of the basic unit of MPLS label comprising one or more instances of the basic unit of MPLS label
stack for SFC. Taken together, this stack defines the SFs to be stack for SFC. Taken together, this stack defines the SFs to be
actioned and so defines the SFP that the packet will traverse. actioned and so defines the SFP that the packet will traverse.
o When a component of the SFC system processes a packet it uses the o When a component of the SFC system processes a packet it uses the
top basic unit of label stack for SFC to determine to which SFI to top basic unit of label stack for SFC to determine to which SFI to
next deliver the packet. When an SFF receives a packet it next deliver the packet. When an SFF receives a packet it
examines the top basic unit of MPLS label stack for SFC to examines the top basic unit of MPLS label stack for SFC to
determine where to send the packet next. If the next recipient is determine where to send the packet next. If the next recipient is
a local SFI, the SFC strips the basic unit of MPLS label stack for a local SFI, the SFC strips the basic unit of MPLS label stack for
SFC before forwarding the packet. SFC before forwarding the packet.
7. Mixed Mode Forwarding 7. Mixed Mode Forwarding
The previous sections describe homogeneous networks where SFC The previous sections describe homogeneous networks where SFC
forwarding is either all label swapping or all label popping. But it forwarding is either all label swapping or all label popping
is also possible that different parts of the network utilize swapping (stacking). But it is also possible that different parts of the
or popping for different purposes. network utilize swapping or popping. It is also worth noting that a
Classifier may be content to use an SFP as installed in the network
by a control plane or management plane and so would use label
swapping, but that there may be a point in the SFP where a choice of
SFIs can be made (perhaps for load balancing) and where, in this
instance, the Classifier wishes to exert control over that choice by
use of a specific entry on the label stack.
When an SFF receives a packet containing an MPLS label stack, it When an SFF receives a packet containing an MPLS label stack, it
checks whether it is processing an {SFP, SI} label pair for label 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 swapping or a {context label, SFI index} label pair for label
then selects the appropriate SFI to which to send the packet. When stacking. It then selects the appropriate SFI to which to send the
it receives the packet back from the SFI, it has four cases to packet. When it receives the packet back from the SFI, it has four
consider. cases to consider.
o If the current hop requires an {SFP, SI} and the next hop requires o If the current hop requires an {SFP, SI} and the next hop requires
an {SFP, SI}, it sets the SI label to the SI value of the current an {SFP, SI}, it sets the SI label to the SI value of the current
hop, selects an instance of the SF to be executed at the next hop, hop, selects an instance of the SF to be executed at the next hop,
and tunnels the packet to the SFF for that SFI. and tunnels the packet to the SFF for that SFI.
o If the current hop requires an {SFP, SI} and the next hop requires o If the current hop requires an {SFP, SI} and the next hop requires
a {context label, SFI label}, it pops the {SFP, SI} from the top a {context label, SFI label}, it pops the {SFP, SI} from the top
of the MPLS label stack and tunnels the packet to the SFF of the MPLS label stack and tunnels the packet to the SFF
indicated by the context label. indicated by the context label.
skipping to change at page 12, line 33 skipping to change at page 12, line 38
However, when an MPLS label stack is present, the depth of the stack However, when an MPLS label stack is present, the depth of the stack
could be too large for some processors to correctly determine the could be too large for some processors to correctly determine the
entropy hash. This problem is addressed by the inclusion of an entropy hash. This problem is addressed by the inclusion of an
Entropy Label as described in [RFC6790]. Entropy Label as described in [RFC6790].
When entropy is desired for packets as they are carried in MPLS When entropy is desired for packets as they are carried in MPLS
tunnels over the underlay network, it is RECOMMENDED that an Entropy tunnels over the underlay network, it is RECOMMENDED that an Entropy
Label is included in the label stack immediately after the tunnel 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. 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 If an Entropy Label is present in an MPLS payload, it is RECOMMENDED
that the initial Classifier use that value in an Entropy Label that the initial Classifier use that value in an Entropy Label
inserted in the label stack when the packet is forwarded (on the 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 first tunnel) to the first SFF. In this case it is not necessary to
remove the Entropy Label from the payload. remove the Entropy Label from the payload.
11. Metadata 11. Metadata
Metadata is defined in [RFC7665] as providing "the ability to Metadata is defined in [RFC7665] as providing "the ability to
exchange context information between classifiers and SFs, and among exchange context information between classifiers and SFs, and among
SFs." [RFC8300] defines how this context information can be directly SFs." [RFC8300] defines how this context information can be directly
encoded in fields that form part of the NSH encapsulation. encoded in fields that form part of the NSH encapsulation.
The next two sections describe how metadata is associated with user The next two sections describe how metadata is associated with user
data packets, and how metadata may is exchanged between SFC nodes in data packets, and how metadata may be exchanged between SFC nodes in
the network, when using an MPLS encoding of the logical the network, when using an MPLS encoding of the logical
representation of the NSH. representation of the NSH.
It should be noted that the MPLS encoding is slightly less functional It should be noted that the MPLS encoding is slightly less functional
than the direct use of the NSH. Both methods support metadata that than the direct use of the NSH. Both methods support metadata that
is "per-SFP" or "per-packet-flow" (see [I-D.farrel-sfc-convent] for is "per-SFP" or "per-packet-flow" (see [I-D.farrel-sfc-convent] for
definitions of these terms), but "per-packet" metadata (where the definitions of these terms), but "per-packet" metadata (where the
metadata must be carried on each packet because it differs from one metadata must be carried on each packet because it differs from one
packet to the next even on the same flow or SFP) is only supported packet to the next even on the same flow or SFP) is only supported
using the NSH and not using the mechanisms defined in this document. using the NSH and not using the mechanisms defined in this document.
skipping to change at page 14, line 6 skipping to change at page 14, line 4
programmed into the network using in-band or out-of-band mechanisms. programmed into the network using in-band or out-of-band mechanisms.
Out-of-band mechanisms potentially include management plane and Out-of-band mechanisms potentially include management plane and
control plane solutions (such as control plane solutions (such as
[I-D.ietf-bess-nsh-bgp-control-plane]), but are out of scope for this [I-D.ietf-bess-nsh-bgp-control-plane]), but are out of scope for this
document. The in-band mechanism is described in Section 11.2 document. The in-band mechanism is described in Section 11.2
The SFC Metadata Label (as a set of three labels as indicated in 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 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 packet. For MPLS label swapping, the SFC Metadata Labels are placed
immediately after the basic unit of MPLS label stack for SFC as shown 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 in Figure 5. For MPLS label stacking, the SFC Metadata Labels can be
zero, one, or more times and are placed at the bottom of the label present zero, one, or more times and are placed at the bottom of the
stack as shown in Figure 6. label stack as shown in Figure 6.
---------------- ----------------
~ Tunnel Labels ~ ~ Tunnel Labels ~
+----------------+ +----------------+
~ Optional ~ ~ Optional ~
~ Entropy Label ~ ~ Entropy Label ~
+----------------+ +----------------+
| SPI Label | | SPI Label |
+----------------+ +----------------+
| SI Label | | SI Label |
skipping to change at page 15, line 6 skipping to change at page 15, line 6
+----------------+ +----------------+
| | | |
~ Payload ~ ~ Payload ~
| | | |
---------------- ----------------
Figure 5: The MPLS SFC Label Stack for Label Swapping with Metadata Figure 5: The MPLS SFC Label Stack for Label Swapping with Metadata
Label Label
------------------- -------------------
~ MPLS-SR Labels ~ ~ Tunnel Labels ~
+-------------------+ +-------------------+
~ Optional ~ ~ Optional ~
~ Entropy Label ~ ~ Entropy Label ~
+-------------------+ +-------------------+
| SFC Context Label | | SFC Context Label |
+-------------------+ +-------------------+
| SF Label | | SF Label |
+-------------------+ +-------------------+
~ ~ ~ ~
+-------------------+ +-------------------+
skipping to change at page 15, line 36 skipping to change at page 15, line 36
+-------------------+ +-------------------+
~ Other ~ ~ Other ~
| Metadata | | Metadata |
~ Label Triples ~ ~ Label Triples ~
+-------------------+ +-------------------+
| | | |
~ Payload ~ ~ Payload ~
| | | |
------------------- -------------------
Figure 6: The MPLS SFC Label Stack for MPLS-SR with Metadata Label Figure 6: The MPLS SFC Label Stack for Label Stacking with Metadata
Label
11.2. Inband Programming of Metadata 11.2. Inband Programming of Metadata
A mechanism for sending metadata associated with an SFP without a A mechanism for sending metadata associated with an SFP without a
payload packet is described in [I-D.farrel-sfc-convent]. The same 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 approach can be used in an MPLS network where the NSH is logically
represented by an MPLS label stack. represented by an MPLS label stack.
The packet header is formed exactly as previously described in this The packet header is formed exactly as previously described in this
document so that the packet will follow the SFP through the SFC document so that the packet will follow the SFP through the SFC
skipping to change at page 16, line 17 skipping to change at page 16, line 17
o An extended special purpose label called the Metadata Present o An extended special purpose label called the Metadata Present
Indicator (MPI) (value TBD2 by IANA) Indicator (MPI) (value TBD2 by IANA)
o The Metadata Label (ML) that is associated with this metadata on o The Metadata Label (ML) that is associated with this metadata on
this SFP and can be used to indicate the use of the metadata as this SFP and can be used to indicate the use of the metadata as
described in Section 11. described in Section 11.
The SFC Metadata Present Label, if present, is placed immediately The SFC Metadata Present Label, if present, is placed immediately
after the last basic unit of MPLS label stack for SFC. The resultant 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 label stacks are shown in Figure 7 for the MPLS label swapping case
and Figure 8 for the MPLS-SR case. and Figure 8 for the MPLS label stacking case.
--------------- ---------------
~ Tunnel Labels ~ ~ Tunnel Labels ~
+---------------+ +---------------+
~ Optional ~ ~ Optional ~
~ Entropy Label ~ ~ Entropy Label ~
+---------------+ +---------------+
| SPI Label | | SPI Label |
+---------------+ +---------------+
| SI Label | | SI Label |
skipping to change at page 16, line 40 skipping to change at page 16, line 40
+---------------+ +---------------+
| MPI | | MPI |
+---------------+ +---------------+
| Metadata Label| | Metadata Label|
+---------------+ +---------------+
| | | |
~ Metadata ~ ~ Metadata ~
| | | |
--------------- ---------------
Figure 7: The MPLS SFC Label Stack Carrying Metadata Figure 7: The MPLS SFC Label Stack for Label Swapping Carrying
Metadata
------------------- -------------------
~ MPLS-SR Labels ~ ~ Tunnel Labels ~
+-------------------+ +-------------------+
~ Optional ~ ~ Optional ~
~ Entropy Label ~ ~ Entropy Label ~
+-------------------+ +-------------------+
| SFC Context Label | | SFC Context Label |
+-------------------+ +-------------------+
| SF Label | | SF Label |
+-------------------+ +-------------------+
| SFC Context Label | | SFC Context Label |
+-------------------+ +-------------------+
skipping to change at page 17, line 36 skipping to change at page 17, line 36
+-------------------+ +-------------------+
| MPI | | MPI |
+-------------------+ +-------------------+
| Metadata Label | | Metadata Label |
+-------------------+ +-------------------+
| | | |
~ Metadata ~ ~ Metadata ~
| | | |
------------------- -------------------
Figure 8: The MPLS SFC Label Stack for MPLS-SR Carrying Metadata Figure 8: The MPLS SFC Label Stack for Label Stacking Carrying
Metadata
In both cases the metadata is formatted as a TLV as shown in In both cases the metadata is formatted as a TLV as shown in
Figure 9. Figure 9.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Metadata Type | | Length | Metadata Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Metadata ~ ~ Metadata ~
skipping to change at page 20, line 14 skipping to change at page 20, line 31
Alternatively, consider the MPLS SFC overlay network shown in Alternatively, consider the MPLS SFC overlay network shown in
Figure 11. A packet is classified for an SFP that will see it pass 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 through two Service Functions, SFx and SFy, that are accessed through
Service Function Forwarders SFFx and SFFy respectively. The packet Service Function Forwarders SFFx and SFFy respectively. The packet
is ultimately delivered to destination, D. is ultimately delivered to destination, D.
Let us assume that the SFP is computed and assigned the SPI of 239. 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 However, the forwarding state for the SFP is not distributed and
installed in the network. Instead it will be attached to the installed in the network. Instead it will be attached to the
individual packets using MPLS-SR. individual packets using the MPLS label stack.
The packet progresses as follows: The packet progresses as follows:
1. The Classifier assigns the packet to the SFP and imposes two 1. The Classifier assigns the packet to the SFP and imposes two
basic units of MPLS SFC representation to describe the full SFP: basic units of MPLS SFC representation to describe the full SFP:
* The top basic unit comprises two label stack entries as * The top basic unit comprises two label stack entries as
follows: follows:
+ The higher label stack entry contains a label carrying the + The higher label stack entry contains a label carrying the
skipping to change at page 21, line 30 skipping to change at page 22, line 6
be forwarded to SFy. The packet is forwarded to SFy unmodified. be forwarded to SFy. The packet is forwarded to SFy unmodified.
6. SFy performs its designated function and returns the packet to 6. SFy performs its designated function and returns the packet to
SFFy. SFFy.
7. SFFy strips the top basic unit of MPLS SFC representation 7. SFFy strips the top basic unit of MPLS SFC representation
revealing the payload packet. It forwards the payload toward D revealing the payload packet. It forwards the payload toward D
using the payload protocol. using the payload protocol.
+---------------------------------------------------+ +---------------------------------------------------+
| MPLS-SR SFC Network | | MPLS SFC Network |
| | | |
| +---------+ +---------+ | | +---------+ +---------+ |
| | SFx | | SFy | | | | SFx | | SFy | |
| +----+----+ +----+----+ | | +----+----+ +----+----+ |
| ^ | | ^ | | | | ^ | | ^ | | |
| (2)| | |(3) (5)| | |(6) | | (2)| | |(3) (5)| | |(6) |
| (1) | | V (4) | | V (7) | | (1) | | V (4) | | V (7) |
+----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
|Classifier+------+ SFFx +-------+ SFFy +------+ D | |Classifier+------+ SFFx +-------+ SFFy +------+ D |
+----------+ +---------+ +---------+ +-------+ +----------+ +---------+ +---------+ +-------+
| | | |
+---------------------------------------------------+ +---------------------------------------------------+
Figure 11: Service Function Chaining in an MPLS-SR Network Figure 11: Service Function Chaining Using MPLS Label Stacking
13. Security Considerations 13. Security Considerations
Discussion of the security properties of SFC networks can be found in Discussion of the security properties of SFC networks can be found in
[RFC7665]. Further security discussion for the NSH and its use is [RFC7665]. Further security discussion for the NSH and its use is
present in [RFC8300]. present in [RFC8300].
It is fundamental to the SFC design that the classifier is a trusted It is fundamental to the SFC design that the classifier is a trusted
resource which determines the processing that the packet will be resource which determines the processing that the packet will be
subject to, including for example the firewall. It is also subject to, including for example the firewall. It is also
fundamental to the Segment Routing design that packets are routed fundamental to the MPLS design that packets are routed through the
through the network using the path specified by the node imposing the network using the path specified by the node imposing the labels, and
SIDs. Where an SF is not encapsulation aware the packet may exist as that labels are swapped or popped correctly. Where an SF is not
an IP packet, however this is an intrinsic part of the SFC design encapsulation aware the encapsulation may be stripped by an SFC proxy
which needs to define how a packet is protected in that environment. such that packet may exist as a native packet (perhaps IP) on the
Where a tunnel is used to link two non-MPLS domains, the tunnel path between SFC proxy and SF, however this is an intrinsic part of
design needs to specify how it is secured. Thus the security the SFC design which needs to define how a packet is protected in
vulnerabilities are addressed in the underlying technologies used by that environment.
this design, which itself does not introduce any new security
vulnerabilities. Additionally, where a tunnel is used to link two non-MPLS domains,
the tunnel design needs to specify how the tunnel is secured.
Thus the security vulnerabilities are addressed (or should be
addressed) in all the underlying technologies used by this design,
which itself does not introduce any new security vulnerabilities.
14. IANA Considerations 14. IANA Considerations
This document requests IANA to make allocations from the "Extended This document requests IANA to make allocations from the "Extended
Special-Purpose MPLS Label Values" subregistry of the "Special- Special-Purpose MPLS Label Values" subregistry of the "Special-
Purpose Multiprotocol Label Switching (MPLS) Label Values" registry Purpose Multiprotocol Label Switching (MPLS) Label Values" registry
as follows: as follows:
Value | Description | Value | Description |
-------+-----------------------------------+-------------- -------+-----------------------------------+--------------
skipping to change at page 23, line 14 skipping to change at page 23, line 35
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.farrel-sfc-convent] [I-D.farrel-sfc-convent]
Farrel, A. and J. Drake, "Operating the Network Service Farrel, A. and J. Drake, "Operating the Network Service
Header (NSH) with Next Protocol "None"", draft-farrel-sfc- Header (NSH) with Next Protocol "None"", draft-farrel-sfc-
convent-06 (work in progress), February 2018. convent-06 (work in progress), February 2018.
[I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-12
(work in progress), February 2018.
[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>.
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating
and Retiring Special-Purpose MPLS Labels", RFC 7274, and Retiring Special-Purpose MPLS Labels", RFC 7274,
DOI 10.17487/RFC7274, June 2014, DOI 10.17487/RFC7274, June 2014,
<https://www.rfc-editor.org/info/rfc7274>. <https://www.rfc-editor.org/info/rfc7274>.
skipping to change at page 23, line 44 skipping to change at page 24, line 15
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
16.2. Informative References 16.2. Informative References
[I-D.ietf-bess-nsh-bgp-control-plane] [I-D.ietf-bess-nsh-bgp-control-plane]
Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess-
nsh-bgp-control-plane-02 (work in progress), October 2017. nsh-bgp-control-plane-03 (work in progress), March 2018.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[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>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012, RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>. <https://www.rfc-editor.org/info/rfc6790>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <https://www.rfc-editor.org/info/rfc7855>.
Authors' Addresses Authors' Addresses
Adrian Farrel Adrian Farrel
Juniper Networks Juniper Networks
Email: afarrel@juniper.net Email: afarrel@juniper.net
Stewart Bryant Stewart Bryant
Huawei Huawei
 End of changes. 44 change blocks. 
108 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/