< draft-ietf-mpls-sfc-00.txt   draft-ietf-mpls-sfc-01.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 29, 2018 Huawei Expires: November 16, 2018 Huawei
J. Drake J. Drake
Juniper Networks Juniper Networks
March 28, 2018 May 15, 2018
An MPLS-Based Forwarding Plane for Service Function Chaining An MPLS-Based Forwarding Plane for Service Function Chaining
draft-ietf-mpls-sfc-00 draft-ietf-mpls-sfc-01
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.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 29, 2018. This Internet-Draft will expire on November 16, 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 5
5. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 6 4.1. Label Swapping for Logical NSH . . . . . . . . . . . . . 5
6. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 8 4.2. Hierarchical Encapsulation . . . . . . . . . . . . . . . 5
7. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 10 4.3. Fine Control of Service Function Instances . . . . . . . 5
8. A Note on Service Function Capabilities and SFC Proxies . . . 11 4.4. Micro Chains and Label Stacking . . . . . . . . . . . . . 6
9. Control Plane Considerations . . . . . . . . . . . . . . . . 11 4.5. SFC and Segment Routing . . . . . . . . . . . . . . . . . 6
10. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 12 5. Basic Unit of Representation . . . . . . . . . . . . . . . . 6
11. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 7
11.1. Indicating Metadata in User Data Packets . . . . . . . . 13 7. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 10
11.2. Inband Programming of Metadata . . . . . . . . . . . . . 15 8. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 12
12. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 18 9. A Note on Service Function Capabilities and SFC Proxies . . . 13
13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Control Plane Considerations . . . . . . . . . . . . . . . . 13
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 14
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 12. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 15
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12.1. Indicating Metadata in User Data Packets . . . . . . . . 15
16.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.2. Inband Programming of Metadata . . . . . . . . . . . . . 17
16.2. Informative References . . . . . . . . . . . . . . . . . 24 13. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 14. Implementation Notes . . . . . . . . . . . . . . . . . . . . 24
15. Security Considerations . . . . . . . . . . . . . . . . . . . 25
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
18.1. Normative References . . . . . . . . . . . . . . . . . . 26
18.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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
selected by a service classifier, the traffic needs to be steered selected by a service classifier, the traffic needs to be steered
skipping to change at page 4, line 5 skipping to change at page 4, line 8
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 all forms of 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
or popped [RFC3031]). It does not deprecate or replace the NSH, but or popped [RFC3031]). It does not deprecate or replace the NSH, but
acknowledges that there may be a need for an interim deployment of acknowledges that there may be a need for an interim deployment of
SFC functionality in brownfield networks. The mechanisms described SFC functionality in brownfield networks. The mechanisms described
in this document are a compromise between the full function that can in this document are a compromise between the full function that can
be achieved using the NSH, and the benefits of reusing the existing be achieved using the NSH, and the benefits of reusing the existing
MPLS forwarding paradigms. MPLS forwarding paradigms.
Section 4 provides a short overview of several use case scenarios
that help to explain the relationship between the MPLS label
operations (swapping, popping, stacking) and the MPLS encoding of the
logical NSH described in this document).
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 Note that one of the features of the SFC architecture described in
[RFC7665] is the "SFC proxy" that exists to include legacy SFs that [RFC7665] is the "SFC proxy" that exists to include legacy SFs that
are not able to process NSH-encapsulated packets. This issue is are not able to process NSH-encapsulated packets. This issue is
equally applicable to the use of MPLS-encapsulated packets that equally applicable to the use of MPLS-encapsulated packets that
encode a logical representation of an NSH. It is discussed further encode a logical representation of an NSH. It is discussed further
in Section 8. in Section 9.
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 4, line 48 skipping to change at page 5, line 8
approach to achieve these objectives is provided using BGP in approach to achieve these objectives is provided using BGP in
[I-D.ietf-bess-nsh-bgp-control-plane]. [I-D.ietf-bess-nsh-bgp-control-plane].
Note that the encoding of the SFC information is independent of the Note that the encoding of the SFC information is independent of the
choice of tunneling technology used between SFFs. Thus, an MPLS choice of tunneling technology used between SFFs. Thus, an MPLS
representation of the logical NSH (as defined in this document) may 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 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 tunnel. Conversely, MPLS tunnels may be used to carry other
encodings of the logical NSH (specifically, the NSH itself). encodings of the logical NSH (specifically, the NSH itself).
4. Basic Unit of Representation 4. Use Case Scenarios
There are five scenarios that can be considered for the use of an
MPLS encoding in support of SFC. These are set out in the following
sub-sections.
4.1. Label Swapping for Logical NSH
The primary use case for SFC is described in [RFC7665] and delivered
using the NSH which, as described in [RFC8300], uses an encapsulation
with a position indicator that is modified at each SFC hop along the
chain to indicate the next hop.
The label swapping use case scenario effectively replaces the NSH
with an MPLS encapsulation as described in Section 6. The MPLS
labels encode the same information as the NSH to form a logical NSH.
The labels are modified (swapped per [RFC3031]) at each SFC hop along
the chain to indicate the next hop. The processing and forwarding
state for a chain (i.e., the actions to take on a received label) are
programmed in to the network using a control plane or management
plane.
4.2. Hierarchical Encapsulation
[I-D.ietf-sfc-hierarchical] describes an architecture for
hierarchical encapsulation using the NSH. It facilitates
partitioning of SFC domains for administrative reasons, and allows
concatenation of service function chains under the control of a
service classifier.
The same function can be achieved in an MPLS network using an MPLS
encoding of the logical NSH, and label stacking as defined in
[RFC3031] and described in Section 7. In this model, swapping is
used per Section 4.1 to navigate one chain, and when the end of the
chain is reached, the final label is popped revealing the label for
another chain. Thus, the primary mode is swapping, but stacking is
used to enable the ingress classifier to control concatenation of
service function chains.
4.3. Fine Control of Service Function Instances
It may be that a service function chain (as described in Section 4.1
allows some leeway in the choice of service function instances along
the chain. However, it may be that a service classifier wishes to
constrain the choice and this can be achieved using chain
concatenation so that the first chain ends at the point of choice,
the next label in the stack indicates the specific service function
instance to be executed, and the next label in the stack starts a new
chain. Thus, a mixture of label swapping and stacking is used.
4.4. Micro Chains and Label Stacking
The scenario in Section 4.2 may be extended to its logical extreme by
making each concatenated chain as short as it can be: one service
function. Each label in the stack indicates the next service
function to be executed, and the network is programmed through the
control plane or management plane to know how to route to the next
(i.e., first) hop in each chain just as it would be to support the
scenarios in Section 4.1 and Section 4.2.
4.5. SFC and Segment Routing
Segment Routing (SR) in an MPLS network (known as MPLS-SR) uses a
stack of MPLS labels to encode information about the path and network
functions that a packet should traverse. MPLS-SR is achieved by
applying control plane and management plane techniques to program the
MPLS forwarding plane, and by imposing labels on packets at the
entrance to the MPLS-SR network.
The application of SR to SFC was considered in early versions of the
SR architecture [I-D.ietf-spring-segment-routing] and the MPLS-SR
specification [I-D.ietf-spring-segment-routing-mpls], but has since
been moved out of those documents. An implementation proposal for
achieving SFC using MPLS-SR can be found in
[I-D.xuclad-spring-sr-service-chaining] and is not discussed further
in this document.
5. Basic Unit of Representation
When an MPLS label stack is used to carry a logical NSH, a basic unit 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 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 shown below. The unit may be present one or more times in the label
stack as explained in subsequent sections. stack as explained in subsequent sections.
In order to convey the same information as is present in the NSH, two 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 MPLS label stack entries are used. One carries a label to provide
context within the SFC scope (the SFC Context Label), and the other 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 carries a label to show which service function is to be actioned (the
skipping to change at page 5, line 28 skipping to change at page 7, line 20
| 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 label swapping (see Section 5) or stack entries are used for MPLS label swapping (see Section 6) or
MPLS label stacking (see Section 6). MPLS label stacking (see Section 7).
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 label swapping (see Section 5) set according to its use for MPLS label swapping (see Section 6)
or MPLS label stacking (see Section 6 and is used to mitigate or MPLS label stacking (see Section 7 and is used to mitigate
packet loops. 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
label stacking. For simplicity, these sections do not describe the label stacking. For simplicity, these sections do not describe the
use of metadata: that is covered separately in Section 11. use of metadata: that is covered separately in Section 12.
5. MPLS Label Swapping 6. 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 5 is used when MPLS label swapping is in use.
The use case scenario for this approach is introduced in Section 4.1.
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
simplicity. 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 11
Under these labels (or other encapsulation) comes a single instance Under these labels (or other encapsulation) comes a single instance
of the basic unit of MPLS label stack for SFC. In addition to the 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 interpretation of the fields of these label stack entries provided in
Section 4 the following meanings are applied: Section 5 the following meanings are applied:
SPI Label: The Label field of the SFC Context label stack entry SPI Label: The Label field of the SFC Context label stack entry
contains the value of the SPI encoded as a 20 bit integer. The contains the value of the SPI encoded as a 20 bit integer. The
semantics of the SPI is exactly as defined in [RFC8300]. Note semantics of the SPI is exactly as defined in [RFC8300]. Note
that an SPI as defined by [RFC8300] can be encoded in 3 octets that an SPI as defined by [RFC8300] can be encoded in 3 octets
(i.e., 24 bits), but that the Label field allows for only 20 bits (i.e., 24 bits), but that the Label field allows for only 20 bits
and reserves the values 0 though 15 as 'special purpose' labels and reserves the values 0 though 15 as 'special purpose' labels
[RFC7274]. Thus, a system using MPLS representation of the [RFC7274]. Thus, 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. less than 16.
SI Label: The Label field of the SF label stack entry contains the SI Label: The Label field of the SF label stack entry contains the
value of the SI exactly as defined in [RFC8300]. Since the SI value of the SI exactly as defined in [RFC8300]. Since the SI
requires only 8 bits, and to avoid overlap with the 'special requires only 8 bits, and to avoid overlap with the 'special
purpose' label range of 0 through 15 [RFC7274], the SI is carried purpose' label range of 0 through 15 [RFC7274], the SI is carried
in the top (most significant) 8 bits of the Label field with the in the top (most significant) 8 bits of the Label field with the
low order 12 bits set to zero. low order 12 bits set to zero.
TC: The TC fields are as described in Section 4. TC: The TC fields are as described in Section 5.
S: The S bits are as described in Section 4. S: The S bits are as described in Section 5.
TTL: The TTL field in the SPI label stack entry SHOULD be set to 1 TTL: The TTL field in the SPI label stack entry SHOULD be set to 1
as stated in Section 4. The TTL in SF label stack entry is as stated in Section 5. The TTL in SF label stack entry is
decremented once for each forwarding hop in the SFP, i.e., for decremented once for each forwarding hop in the SFP, i.e., for
each SFF transited, and so mirrors the TTL field in the NSH. each SFF transited, and so mirrors the TTL field in the NSH.
--------------- ---------------
~ Tunnel Labels ~ ~ Tunnel Labels ~
+---------------+ +---------------+
~ Optional ~ ~ Optional ~
~ Entropy Label ~ ~ Entropy Label ~
+---------------+ - - - +---------------+ - - -
| SPI Label | | SPI Label |
skipping to change at page 7, line 24 skipping to change at page 9, line 24
+---------------+ - - - +---------------+ - - -
| | | |
~ Payload ~ ~ Payload ~
| | | |
--------------- ---------------
Figure 2: The MPLS SFC Label Stack Figure 2: The MPLS SFC Label Stack
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 sets the SPI o When a classifier inserts a packet onto an SFP it sets the SPI
Label to indicate the identity of the SFP, and sets the SI Label Label to indicate the identity of the SFP, and sets the SI Label
to indicate the first SF in the path. to indicate the first SF in the path.
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
SPI Label to identify the SFP and the SI Label to determine to SPI Label to identify the SFP and the SI Label to determine to
which SFF or instance of an SF (an SFI) to deliver the packet. which SFF or instance of an SF (an SFI) to deliver the packet.
Under normal circumstances (with the exception of branching and Under normal circumstances (with the exception of branching and
reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the
SPI Label value is preserved on all packets. The SI Label value SPI Label value is preserved on all packets. The SI Label value
is modified by SFFs and through reclassification to indicate the is modified by SFFs and through reclassification to indicate the
next hop along the SFP. next hop along the SFP.
The following processing rules apply to the TTL field of the SF label The following processing rules apply to the TTL field of the SF label
stack entry, and are derived from section 2.2 of [RFC8300]: stack entry, and are derived from section 2.2 of [RFC8300]:
o When a Classifier places a packet onto an SFP it MUST set the TTL o When a classifier places a packet onto an SFP it MUST set the TTL
to a value between 1 and 255. It SHOULD set this according to the to a value between 1 and 255. It SHOULD set this according to the
expected length of the SFP (i.e., the number of SFs on the SFP), expected length of the SFP (i.e., the number of SFs on the SFP),
but it MAY set it to a larger value according to local but it MAY set it to a larger value according to local
configuration. The maximum TTL value supported in an NSH is 63, configuration. The maximum TTL value supported in an NSH is 63,
and so the practical limit here may also be 63. and so the practical limit here may also be 63.
o When an SFF receives a packet from any component of the SFC system o When an SFF receives a packet from any component of the SFC system
(Classifier, SFI, or another SFF) it MUST discard any packets with (classifier, SFI, or another SFF) it MUST discard any packets with
TTL set to zero. It SHOULD log such occurrences, but MUST apply TTL set to zero. It SHOULD log such occurrences, but MUST apply
rate limiting to any such logs. rate limiting to any such logs.
o An SFF MUST decrement the TTL by one each time it performs a o An SFF MUST decrement the TTL by one each time it performs a
forwarding lookup. forwarding lookup.
o If an SFF decrements the TTL to zero it MUST NOT send the packet, o If an SFF decrements the TTL to zero it MUST NOT send the packet,
and MUST discard the packet. It SHOULD log such occurrences, but and MUST discard the packet. It SHOULD log such occurrences, but
MUST apply rate limiting to any such logs. MUST apply rate limiting to any such logs.
o SFIs MUST ignore the TTL, but MUST mirror it back to the SFF o SFIs MUST ignore the TTL, but MUST mirror it back to the SFF
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 Label Stacking 7. 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 MPLS label stacking is used to introduced in Section 5 is used when MPLS label stacking is used to
carry information about the SFP and SFs to be executed. As can be carry information about the SFP and SFs to be executed. The use case
seen in Figure 3, the top of the label stack comprises the labels scenarios for this approach is introduced in Section 4.
necessary to deliver the packet over the MPLS tunnel between SFFs.
Any MPLS encapsulation may be used. 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. Any MPLS encapsulation may be used.
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 11
Under these labels comes one of more instances of the basic unit of Under these labels comes one of more instances of the basic unit of
MPLS label stack for SFC. In addition to the interpretation of the MPLS label stack for SFC. In addition to the interpretation of the
fields of these label stack entries provided in Section 4 the fields of these label stack entries provided in Section 5 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 how to interpret the context-speific semantics such as indicating how to interpret the
skipping to change at page 9, line 4 skipping to change at page 11, line 7
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 how to interpret the context-speific semantics such as indicating how to interpret the
SF Label or how to forward the packet to the node that offers the SF Label or how to forward the packet to the node that offers the
SF. 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 5.
S: The S bits are as described in Section 4. S: The S bits are as described in Section 5.
TTL: The TTL fields in the SFC Context label stack entry SF label TTL: The TTL fields in the SFC Context label stack entry SF label
stack entry SHOULD be set to 1 as stated in Section 4, but MAY be stack entry SHOULD be set to 1 as stated in Section 5, but MAY be
set to larger values if the label indicated a forwarding operation set to larger values if the label indicated a forwarding operation
towards the node that hosts the SF. towards the node that hosts the SF.
------------------- -------------------
~ Tunnel Labels ~ ~ Tunnel Labels ~
+-------------------+ +-------------------+
~ Optional ~ ~ Optional ~
~ Entropy Label ~ ~ Entropy Label ~
+-------------------+ - - - +-------------------+ - - -
| SFC Context Label | | SFC Context Label |
skipping to change at page 9, line 47 skipping to change at page 11, line 49
+-------------------+ - - - +-------------------+ - - -
| | | |
~ Payload ~ ~ Payload ~
| | | |
------------------- -------------------
Figure 3: The MPLS SFC Label Stack for Label Stacking 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 8. 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 forwarding is either all label swapping or all label popping
(stacking). But it is also possible that different parts of the (stacking). This simplification helps to clarify the explanation of
network utilize swapping or popping. It is also worth noting that a the mechanisms.
Classifier may be content to use an SFP as installed in the network
However, as described in Section 4.2, some uses cases may use label
swapping and stacking at the same time. Furthermore, it is also
possible that different parts of the network utilize swapping or
popping such that an end-to-end service chain has to utilize a
combination of both techniques. 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 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 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 SFIs can be made (perhaps for load balancing) and where, in this
instance, the Classifier wishes to exert control over that choice by instance, the classifier wishes to exert control over that choice by
use of a specific entry on the label stack. use of a specific entry on the label stack as described in
Section 4.3.
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 label swapping or a {context label, SFI index} label pair for label
stacking. It then selects the appropriate SFI to which to send the stacking. It then selects the appropriate SFI to which to send the
packet. When it receives the packet back from the SFI, it has four packet. When it receives the packet back from the SFI, it has four
cases to 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
skipping to change at page 11, line 9 skipping to change at page 13, line 17
stack. stack.
* If the new top of the MPLS label stack contains an {SFP, SI} * If the new top of the MPLS label stack contains an {SFP, SI}
label pair, it selects an SFI to use at the next hop, and label pair, it selects an SFI to use at the next hop, and
tunnels the packet to SFF for that SFI. tunnels the packet to SFF for that SFI.
* If the top of the MPLS label stack contains a {context label, * If the top of the MPLS label stack contains a {context label,
SFI label}, it tunnels the packet to the SFF indicated by the SFI label}, it tunnels the packet to the SFF indicated by the
context label. context label.
8. A Note on Service Function Capabilities and SFC Proxies 9. A Note on Service Function Capabilities and SFC Proxies
The concept of an "SFC Proxy" is introduced in [RFC7665]. An SFC The concept of an "SFC proxy" is introduced in [RFC7665]. An SFC
Proxy is logically located between an SFF and an SFI that is not proxy is logically located between an SFF and an SFI that is not
"SFC-aware". Such SFIs are not capable of handling the SFC "SFC-aware". Such SFIs are not capable of handling the SFC
encapsulation (whether that be NSH or MPLS) and need the encapsulation (whether that be NSH or MPLS) and need the
encapsulation stripped from the packets they are to process. In many encapsulation stripped from the packets they are to process. In many
cases, legacy SFIs that were once deployed as "bumps in the wire" fit cases, legacy SFIs that were once deployed as "bumps in the wire" fit
into this category until they have been upgraded to be SFC-aware. into this category until they have been upgraded to be SFC-aware.
The job of an SFC Proxy is to remove and then reimpose SFC The job of an SFC proxy is to remove and then reimpose SFC
encapsulation so that the SFF is able to process as though it was encapsulation so that the SFF is able to process as though it was
communication with an SFC-aware SFI, and so that the SFI is unaware communication with an SFC-aware SFI, and so that the SFI is unaware
of the SFC encapsulation. In this regard, the job of an SFC Proxy is of the SFC encapsulation. In this regard, the job of an SFC proxy is
no different when NSH encapsulation is used and when MPLS no different when NSH encapsulation is used and when MPLS
encapsulation is used as described in this document, although (of encapsulation is used as described in this document, although (of
course) it is different encapsulation bytes that must be removed and course) it is different encapsulation bytes that must be removed and
reimposed. reimposed.
It should be noted that the SFC Proxy is a logical function. It It should be noted that the SFC proxy is a logical function. It
could be implemented as a separate physical component on the path could be implemented as a separate physical component on the path
from the SFF to SFI, but it could be coresident with the SFF or it from the SFF to SFI, but it could be coresident with the SFF or it
could be a component of the SFI. This is purely an implementation could be a component of the SFI. This is purely an implementation
choice. choice.
Note also that the delivery of metadata (see Section 11) requires Note also that the delivery of metadata (see Section 12) requires
specific processing if an SFC Proxy is in use. This is also no specific processing if an SFC proxy is in use. This is also no
different when NSH or the MPLS encoding defined in this document is different when NSH or the MPLS encoding defined in this document is
in use, and how it is handled will depend on how (or if) each non- in use, and how it is handled will depend on how (or if) each non-
SFC-aware SFI can receive metadata. SFC-aware SFI can receive metadata.
9. Control Plane Considerations 10. Control Plane Considerations
In order that a packet may be forwarded along an SFP several In order that a packet may be forwarded along an SFP several
functional elements must be executed. functional elements must be executed.
o Discovery/advertisement of SFIs. o Discovery/advertisement of SFIs.
o Computation of SFP. o Computation of SFP.
o Programming of Classifiers. o Programming of classifiers.
o Advertisement of forwarding instructions. o Advertisement of forwarding instructions.
Various approaches may be taken. These include a fully centralized Various approaches may be taken. These include a fully centralized
model where SFFs report to a central controller the SFIs that they model where SFFs report to a central controller the SFIs that they
support, the central controller computes the SFP and programs the support, the central controller computes the SFP and programs the
Classifiers, and (if the label swapping approach is taken) the classifiers, and (if the label swapping approach is taken) the
central controller installs forwarding state in the SFFs that lie on central controller installs forwarding state in the SFFs that lie on
the SFP. the SFP.
Alternatively, a dynamic control plane may be used such as that 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 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 SFFs use the control plane to advertise the SFIs that they support, a
central controller computes the SFP and programs the Classifiers, and central controller computes the SFP and programs the classifiers, and
(if the label swapping approach is taken) the central controller uses (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 the control plane to advertise the SFPs so that SFFs that lie on the
SFP can install the necessary forwarding state. SFP can install the necessary forwarding state.
10. Use of the Entropy Label 11. Use of the Entropy Label
Entropy is used in ECMP situations to ensure that packets from the Entropy is used in ECMP situations to ensure that packets from the
same flow travel down the same path, thus avoiding jitter or re- same flow travel down the same path, thus avoiding jitter or re-
ordering issues within a flow. ordering issues within a flow.
Entropy is often determined by hashing on specific fields in a packet Entropy is often determined by hashing on specific fields in a packet
header such as the "five-tuple" in the IP and transport headers. 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 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 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 12. 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 be 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 [RFC8393] for definitions of
definitions of these terms), but "per-packet" metadata (where the these terms), but "per-packet" metadata (where the metadata must be
metadata must be carried on each packet because it differs from one carried on each packet because it differs from one packet to the next
packet to the next even on the same flow or SFP) is only supported even on the same flow or SFP) is only supported using the NSH and not
using the NSH and not using the mechanisms defined in this document. using the mechanisms defined in this document.
11.1. Indicating Metadata in User Data Packets 12.1. Indicating Metadata in User Data Packets
Metadata is achieved in the MPLS realization of the logical NSH by Metadata is achieved in the MPLS realization of the logical NSH by
the use of an SFC Metadata Label which uses the Extended Special the use of an SFC Metadata Label which uses the Extended Special
Purpose Label construct [RFC7274]. Thus, three label stack entries Purpose Label construct [RFC7274]. Thus, three label stack entries
are present as shown in Figure 4: are present as shown in Figure 4:
o The Extension Label (value 15) o The Extension Label (value 15)
o An extended special purpose label called the Metadata Label o An extended special purpose label called the Metadata Label
Indicator (MLI) (value TBD1 by IANA) Indicator (MLI) (value TBD1 by IANA)
skipping to change at page 13, line 41 skipping to change at page 16, line 4
+----------------+ +----------------+
| MLI | | MLI |
+----------------+ +----------------+
| Metadata Label | | Metadata Label |
--------------- ---------------
Figure 4: The MPLS SFC Metadata Label Figure 4: The MPLS SFC Metadata Label
The Metadata Label value is an index into a table of metadata that is 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. 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 12.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 label stacking, the SFC Metadata Labels can be in Figure 5. For MPLS label stacking, the SFC Metadata Labels can be
present zero, one, or more times and are placed at the bottom of the present zero, one, or more times and are placed at the bottom of the
label stack as shown in Figure 6. label stack as shown in Figure 6.
---------------- ----------------
skipping to change at page 15, line 39 skipping to change at page 17, line 39
~ Label Triples ~ ~ Label Triples ~
+-------------------+ +-------------------+
| | | |
~ Payload ~ ~ Payload ~
| | | |
------------------- -------------------
Figure 6: The MPLS SFC Label Stack for Label Stacking with Metadata Figure 6: The MPLS SFC Label Stack for Label Stacking with Metadata
Label Label
11.2. Inband Programming of Metadata 12.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 [RFC8393]. The same approach can be
approach can be used in an MPLS network where the NSH is logically used in an MPLS network where the NSH is logically represented by an
represented by an MPLS label stack. 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
network. However, instead of payload data, metadata is included network. However, instead of payload data, metadata is included
after the bottom of the MPLS label stack. An Extended Special after the bottom of the MPLS label stack. An Extended Special
Purpose Label is used to indicate that the metadata is present. Purpose Label is used to indicate that the metadata is present.
Thus, three label stack entries are present: Thus, three label stack entries are present:
o The Extension Label (value 15) o The Extension Label (value 15)
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 12.
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 label stacking case. and Figure 8 for the MPLS label stacking case.
--------------- ---------------
~ Tunnel Labels ~ ~ Tunnel Labels ~
+---------------+ +---------------+
~ Optional ~ ~ Optional ~
skipping to change at page 18, line 28 skipping to change at page 20, line 28
octets not including any padding. octets not including any padding.
Metadata Type: The type of the metadata present. Values for this Metadata Type: The type of the metadata present. Values for this
field are taken from the "MD Types" registry maintained by IANA field are taken from the "MD Types" registry maintained by IANA
and defined in [RFC8300]. and defined in [RFC8300].
Metadata: The actual metadata formatted as described in whatever Metadata: The actual metadata formatted as described in whatever
document defines the metadata. This field is end-padded with zero document defines the metadata. This field is end-padded with zero
to three octets of zeroes to take it up to a four octet boundary. to three octets of zeroes to take it up to a four octet boundary.
12. Worked Examples 13. Worked Examples
This section reverts to the simplified descriptions of networks that
rely wholly on label swapping or label stacking. As described in
Section 4, actual deployment scenarios may depend on the use of both
mechanisms and utilize a mixed mode as described in Section 8.
Consider the simplistic MPLS SFC overlay network shown in Figure 10. 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 A packet is classified for an SFP that will see it pass through two
Service Functions, SFa and SFb, that are accessed through Service Service Functions, SFa and SFb, that are accessed through Service
Function Forwarders SFFa and SFFb respectively. The packet is Function Forwarders SFFa and SFFb respectively. The packet is
ultimately delivered to destination, D. 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.
The forwarding details of the SFP are distributed (perhaps using the 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 mechanisms of [I-D.ietf-bess-nsh-bgp-control-plane]) so that the SFFs
are programmed with the necessary forwarding instructions. are programmed with the necessary forwarding instructions.
The packet progresses as follows: The packet progresses as follows:
a. The Classifier assigns the packet to the SFP and imposes two a. The classifier assigns the packet to the SFP and imposes two
label stack entries comprising a single basic unit of MPLS SFC label stack entries comprising a single basic unit of MPLS SFC
representation: representation:
* The higher label stack entry contains a label carrying the SPI * The higher label stack entry contains a label carrying the SPI
value of 239. value of 239.
* The lower label stack entry contains a label carrying the SI * The lower label stack entry contains a label carrying the SI
value of 255. value of 255.
Further labels may be imposed to tunnel the packet from the Further labels may be imposed to tunnel the packet from the
Classifier to SFFa. classifier to SFFa.
b. When the packet arrives at SFFa it strips any labels associated b. When the packet arrives at SFFa it strips any labels associated
with the tunnel that runs from the Classifier to SFFa. SFFa with the tunnel that runs from the classifier to SFFa. SFFa
examines the top labels and matches the SPI/SI to identify that examines the top labels and matches the SPI/SI to identify that
the packet should be forwarded to SFa. The packet is forwarded the packet should be forwarded to SFa. The packet is forwarded
to SFa unmodified. to SFa unmodified.
c. SFa performs its designated function and returns the packet to c. SFa performs its designated function and returns the packet to
SFFa. SFFa.
d. SFFa modifies the SI in the lower label stack entry (to 254) and d. SFFa modifies the SI in the lower label stack entry (to 254) and
uses the SPI/SI to look up the forwarding instructions. It sends uses the SPI/SI to look up the forwarding instructions. It sends
the packet with two label stack entries: the packet with two label stack entries:
skipping to change at page 20, line 35 skipping to change at page 22, line 35
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 the MPLS label stack. 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
SFC context. SFC context.
+ The lower label stack entry contains a label carrying the + The lower label stack entry contains a label carrying the
SF indicator for SFx. SF indicator for SFx.
skipping to change at page 21, line 9 skipping to change at page 23, line 9
* The lower basic unit comprises two label stack entries as * The lower 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
SFC context. SFC context.
+ The lower label stack entry contains a label carrying the + The lower label stack entry contains a label carrying the
SF indicator for SFy. SF indicator for SFy.
Further labels may be imposed to tunnel the packet from the Further labels may be imposed to tunnel the packet from the
Classifier to SFFx. classifier to SFFx.
2. When the packet arrives at SFFx it strips any labels associated 2. When the packet arrives at SFFx it strips any labels associated
with the tunnel from the Classifier. SFFx examines the top with the tunnel from the classifier. SFFx examines the top
labels and matches the context/SF values to identify that the labels and matches the context/SF values to identify that the
packet should be forwarded to SFx. The packet is forwarded to packet should be forwarded to SFx. The packet is forwarded to
SFx unmodified. SFx unmodified.
3. SFx performs its designated function and returns the packet to 3. SFx performs its designated function and returns the packet to
SFFx. SFFx.
4. SFFx strips the top basic unit of MPLS SFC representation 4. SFFx strips the top basic unit of MPLS SFC representation
revealing the next basic unit. It then uses the revealed revealing the next basic unit. It then uses the revealed
context/SF values to determine how to route the packet to the context/SF values to determine how to route the packet to the
skipping to change at page 22, line 22 skipping to change at page 24, line 22
| (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 Using MPLS Label Stacking Figure 11: Service Function Chaining Using MPLS Label Stacking
13. Security Considerations 14. Implementation Notes
It is not the job of an IETF specification to describe the internals
of an implementation except where that directly impacts upon the bits
on the wire that change the likelihood of interoperability, or where
the availability of configuration or security options directly affect
the utility of an implementation.
However, in view of the objective of this document to acknowledge
that there may be a need for an interim deployment of SFC
functionality in brownfield MPLS networks, this section provides some
observations about how an SFF might utilize MPLS features that are
available in existing routers. This section is not intended to be
definitive or technically complete, but is indicative.
Consider the mechanism used to indicate to which Virtual Routing and
Forwarding (VRF) an incoming MPLS packet should be routed in a Layer
3 Virtual Private Network (L3VPN) [RFC4364]. In this case, the top
MPLS label is an indicator of the VRF that is to be used to route the
payload.
A similar approach can be taken with the label swapping SFC technique
described in Section 6 such that the SFC Context Label identifies a
routing table specific to the SFP. The SF Label can be looked up in
the context of this routing table to determine to which SF to direct
the packet, and how to forward it to the next SFF.
Advanced features (such as metadata) are not inspected by SFFs. The
packets are passed to SFIs that are MPLS-SFC-aware or to SFC proxies,
and those components are responsible for handling all metadata
issues.
Of course, an actual implementation might make considerable
optimizations on this approach, but this section should provide hints
about how MPLS-based SFC might be achieved with relatively small
modifications to deployed MPLS devices.
15. 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 MPLS design that packets are routed through the fundamental to the MPLS design that packets are routed through the
network using the path specified by the node imposing the labels, and network using the path specified by the node imposing the labels, and
skipping to change at page 22, line 47 skipping to change at page 25, line 37
the SFC design which needs to define how a packet is protected in the SFC design which needs to define how a packet is protected in
that environment. that environment.
Additionally, where a tunnel is used to link two non-MPLS domains, Additionally, where a tunnel is used to link two non-MPLS domains,
the tunnel design needs to specify how the tunnel is secured. the tunnel design needs to specify how the tunnel is secured.
Thus the security vulnerabilities are addressed (or should be Thus the security vulnerabilities are addressed (or should be
addressed) in all the underlying technologies used by this design, addressed) in all the underlying technologies used by this design,
which itself does not introduce any new security vulnerabilities. which itself does not introduce any new security vulnerabilities.
14. IANA Considerations 16. 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 |
-------+-----------------------------------+-------------- -------+-----------------------------------+--------------
TBD1 | Metadata Label Indicator (MLI) | [This.I-D] TBD1 | Metadata Label Indicator (MLI) | [This.I-D]
TBD2 | Metadata Present Indicator (MPI) | [This.I-D] TBD2 | Metadata Present Indicator (MPI) | [This.I-D]
15. Acknowledgements 17. Acknowledgements
This document derives ideas and text from This document derives ideas and text from
[I-D.ietf-bess-nsh-bgp-control-plane]. [I-D.ietf-bess-nsh-bgp-control-plane].
The authors are grateful to all those who contributed to the The authors are grateful to all those who contributed to the
discussions that led to this work: Loa Andersson, Andrew G. Malis, discussions that led to this work: Loa Andersson, Andrew G. Malis,
Alexander Vainshtein, Joel M. Halpern, Tony Przygienda, Stuart Alexander Vainshtein, Joel M. Halpern, Tony Przygienda, Stuart
Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided
helpful review comments. helpful review comments.
Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, and Mach Chen Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, Joel Halpern,
for reviews of this text. and Mach Chen for reviews of this text.
16. References The authors would like to be able to thank the authors of
[I-D.xuclad-spring-sr-service-chaining] and
[I-D.ietf-spring-segment-routing] whose original work on service
chaining and the identification of services using SIDs, and
conversation with whom helped clarify the application of MPLS-SR to
SFC.
16.1. Normative References Particular thanks to Loa Andersson for conversations and advice about
working group process.
[I-D.farrel-sfc-convent] 18. References
Farrel, A. and J. Drake, "Operating the Network Service
Header (NSH) with Next Protocol "None"", draft-farrel-sfc- 18.1. Normative References
convent-06 (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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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 [RFC8393] Farrel, A. and J. Drake, "Operating the Network Service
Header (NSH) with Next Protocol "None"", RFC 8393,
DOI 10.17487/RFC8393, May 2018,
<https://www.rfc-editor.org/info/rfc8393>.
18.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-03 (work in progress), March 2018. nsh-bgp-control-plane-03 (work in progress), March 2018.
[I-D.ietf-sfc-hierarchical]
Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
"Hierarchical Service Function Chaining (hSFC)", draft-
ietf-sfc-hierarchical-08 (work in progress), April 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.
[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-13
(work in progress), April 2018.
[I-D.xuclad-spring-sr-service-chaining]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Segment Routing for
Service Chaining", draft-xuclad-spring-sr-service-
chaining-01 (work in progress), March 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>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[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>.
 End of changes. 71 change blocks. 
105 lines changed or deleted 285 lines changed or added

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