draft-ietf-mpls-sfc-05.txt   draft-ietf-mpls-sfc-06.txt 
MPLS Working Group A. Farrel MPLS Working Group A. Farrel
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Intended status: Standards Track S. Bryant Intended status: Standards Track S. Bryant
Expires: August 16, 2019 Huawei Expires: September 8, 2019 Huawei
J. Drake J. Drake
Juniper Networks Juniper Networks
February 12, 2019 March 7, 2019
An MPLS-Based Forwarding Plane for Service Function Chaining An MPLS-Based Forwarding Plane for Service Function Chaining
draft-ietf-mpls-sfc-05 draft-ietf-mpls-sfc-06
Abstract Abstract
Service Function Chaining (SFC) is the process of directing packets This document describes how Service Function Chaining (SFC) can be
through a network so that they can be acted on by an ordered set of achieved in an MPLS network by means of a logical representation of
abstract service functions before being delivered to the intended the Network Service Header (NSH) in an MPLS label stack. That is,
destination. An architecture for SFC is defined in RFC7665. the NSH is not used, but the fields of the NSH are mapped to fields
in the MPLS label stack. It does not deprecate or replace the NSH,
The Network Service Header (NSH) can be inserted into packets to but acknowledges that there may be a need for an interim deployment
steer them along a specific path to realize a Service Function Chain. of SFC functionality in brownfield networks.
Multiprotocol Label Switching (MPLS) is a widely deployed forwarding
technology that uses labels placed in a packet in a label stack to
identify the forwarding actions to be taken at each hop through a
network. Actions may include swapping or popping the labels as well,
as using the labels to determine the next hop for forwarding the
packet. Labels may also be used to establish the context under which
the packet is forwarded.
This document describes how Service Function Chaining can be achieved
in an MPLS network by means of a logical representation of the NSH in
an MPLS label stack. That is, the NSH is not used, but the fields of
the NSH are mapped to fields in the MPLS label stack. It does not
deprecate or replace the NSH, but acknowledges that there may be a
need for an interim deployment of SFC functionality in brownfield
networks.
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 August 16, 2019. This Internet-Draft will expire on September 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 5 4. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 4
4.1. Label Swapping for Logical NSH . . . . . . . . . . . . . 5 4.1. Label Swapping for Logical NSH . . . . . . . . . . . . . 5
4.2. Hierarchical Encapsulation . . . . . . . . . . . . . . . 5 4.2. Hierarchical Encapsulation . . . . . . . . . . . . . . . 5
4.3. Fine Control of Service Function Instances . . . . . . . 6 4.3. Fine Control of Service Function Instances . . . . . . . 5
4.4. Micro Chains and Label Stacking . . . . . . . . . . . . . 6 4.4. Micro Chains and Label Stacking . . . . . . . . . . . . . 5
4.5. SFC and Segment Routing . . . . . . . . . . . . . . . . . 6 4.5. SFC and Segment Routing . . . . . . . . . . . . . . . . . 6
5. Basic Unit of Representation . . . . . . . . . . . . . . . . 6 5. Basic Unit of Representation . . . . . . . . . . . . . . . . 6
6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 8 6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 7
7. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 10 7. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 10
8. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 12 8. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 11
9. A Note on Service Function Capabilities and SFC Proxies . . . 13 9. A Note on Service Function Capabilities and SFC Proxies . . . 13
10. Control Plane Considerations . . . . . . . . . . . . . . . . 13 10. Control Plane Considerations . . . . . . . . . . . . . . . . 13
11. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 14 11. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 14
12. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Indicating Metadata in User Data Packets . . . . . . . . 15 12.1. Indicating Metadata in User Data Packets . . . . . . . . 15
12.2. Inband Programming of Metadata . . . . . . . . . . . . . 17 12.2. Inband Programming of Metadata . . . . . . . . . . . . . 17
13. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 20 13. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 20
14. Implementation Notes . . . . . . . . . . . . . . . . . . . . 24 14. Implementation Notes . . . . . . . . . . . . . . . . . . . . 24
15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
19.1. Normative References . . . . . . . . . . . . . . . . . . 27 19.1. Normative References . . . . . . . . . . . . . . . . . . 28
19.2. Informative References . . . . . . . . . . . . . . . . . 28 19.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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].
skipping to change at page 4, line 9 skipping to change at page 3, line 42
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 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 (the approach defined here does not include
the O-bit defined in [RFC8300] and has some limitations to the use of
metadata as described in Section 12.
Section 4 provides a short overview of several use case scenarios Section 4 provides a short overview of several use case scenarios
that help to explain the relationship between the MPLS label that help to explain the relationship between the MPLS label
operations (swapping, popping, stacking) and the MPLS encoding of the operations (swapping, popping, stacking) and the MPLS encoding of the
logical NSH described in this document). 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 9. in Section 9.
skipping to change at page 6, line 7 skipping to change at page 5, line 39
encoding of the logical NSH, and label stacking as defined in encoding of the logical NSH, and label stacking as defined in
[RFC3031] and described in Section 7. In this model, swapping is [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 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 chain is reached, the final label is popped revealing the label for
another chain. Thus, the primary mode is swapping, but stacking is another chain. Thus, the primary mode is swapping, but stacking is
used to enable the ingress classifier to control concatenation of used to enable the ingress classifier to control concatenation of
service function chains. service function chains.
4.3. Fine Control of Service Function Instances 4.3. Fine Control of Service Function Instances
It may be that a service function chain (as described in Section 4.1 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 allows some leeway in the choice of service function instances along
the chain. However, it may be that a service classifier wishes to the chain. However, it may be that a service classifier wishes to
constrain the choice and this can be achieved using chain constrain the choice and this can be achieved using chain
concatenation so that the first chain ends at the point of choice, concatenation so that the first chain ends at the point of choice,
the next label in the stack indicates the specific service function 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 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. chain. Thus, a mixture of label swapping and stacking is used.
4.4. Micro Chains and Label Stacking 4.4. Micro Chains and Label Stacking
skipping to change at page 6, line 37 skipping to change at page 6, line 20
as described Section 4.5, and the discussion in that section applies as described Section 4.5, and the discussion in that section applies
to this section as well. to this section as well.
4.5. SFC and Segment Routing 4.5. SFC and Segment Routing
Segment Routing (SR) in an MPLS network (known as MPLS-SR) uses a 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 stack of MPLS labels to encode information about the path and network
functions that a packet should traverse. MPLS-SR is achieved by functions that a packet should traverse. MPLS-SR is achieved by
applying control plane and management plane techniques to program the applying control plane and management plane techniques to program the
MPLS forwarding plane, and by imposing labels on packets at the MPLS forwarding plane, and by imposing labels on packets at the
entrance to the MPLS-SR network. entrance to the MPLS-SR network. An implementation proposal for
achieving SFC using MPLS-SR can be found in
The application of SR to SFC was considered in early versions of the [I-D.xuclad-spring-sr-service-programming] and is not discussed
SR architecture [RFC8402] and the MPLS-SR specification further in this document.
[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 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
skipping to change at page 7, line 29 skipping to change at page 7, line 11
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 6) or stack entries are used for MPLS label swapping (see Section 6) or
MPLS label stacking (see Section 7). 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 in this case. They SHOULD be set to
label stack entries when a packet is sent and MUST be ignored on zero in both label stack entries when a packet is sent and MUST be
receipt. ignored on 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. In the SF label stack
SF label stack entry depending on whether the label is the bottom entry it MUST be clear in all cases except when the label is the
of stack. bottom of stack, when it MUST be set.
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 6) set according to its use for MPLS label swapping (see Section 6)
or MPLS label stacking (see Section 7 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
skipping to change at page 9, line 29 skipping to change at page 9, line 10
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 which
which SFF or instance of an SF (an SFI) to deliver the packet. SFF or instance of an SF (an SFI) to deliver the packet to. Under
Under normal circumstances (with the exception of branching and normal circumstances (with the exception of branching and re-
reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the classification - 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 re-classification 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. lookup to forward a packet to the next SFF.
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). re-classification).
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.
7. 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 5 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. The use case carry information about the SFP and SFs to be executed. The use case
scenarios for this approach is introduced in Section 4. scenarios for this approach is introduced in Section 4.
skipping to change at page 10, line 49 skipping to change at page 10, line 31
fields of these label stack entries provided in Section 5 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-specific 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 if so configured and coordinated with the controller that
programs the labels for the SFP.
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 5. TC: The TC fields are as described in Section 5.
S: The S bits are as described in Section 5. S: The S bits are as described in Section 5.
skipping to change at page 12, line 36 skipping to change at page 12, line 21
combination of both techniques. It is also worth noting that 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 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 as described in use of a specific entry on the label stack as described in
Section 4.3. 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 from the context of the incoming interface, and from the SFP
swapping or a {context label, SFI index} label pair for label indicated by the top label whether it is processing an {SPI, SI}
stacking. It then selects the appropriate SFI to which to send the label pair for label swapping or a {context label, SFI index} label
packet. When it receives the packet back from the SFI, it has four pair for label stacking. It then selects the appropriate SFI to
cases to consider. which to send the packet. When it receives the packet back from the
SFI, it has four cases to consider.
o If the current hop requires an {SFP, SI} and the next hop requires o If the current hop requires an {SPI, SI} and the next hop requires
an {SFP, SI}, it selects an instance of the SF to be executed at an {SPI, SI}, it sets the SPI label according to the SFP to be
the next hop, sets the SI label to the SI value of the next hop, traversed, selects an instance of the SF to be executed at the
and tunnels the packet to the SFF for that SFI. next hop, sets the SI label to the SI value of the next hop, 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 {SPI, 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 {SPI, 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.
o If the current hop requires a {context label, SFI label}, it pops o If the current hop requires a {context label, SFI label}, it pops
the {context label, SFI label} from the top of the MPLS label the {context label, SFI label} from the top of the MPLS label
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 {SPI, 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 new top of the MPLS label stack contains a {context
SFI label}, it tunnels the packet to the SFF indicated by the label, SFI label}, it tunnels the packet to the SFF indicated
context label. by the context label.
9. 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.
skipping to change at page 13, line 38 skipping to change at page 13, line 26
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 co-resident 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 12) 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.
10. Control Plane Considerations 10. Control Plane Considerations
skipping to change at page 16, line 4 skipping to change at page 15, line 39
+----------------+ +----------------+
| 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 12.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 are
present zero, one, or more times and are placed at the bottom of the placed at the bottom of the label 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 25, line 17 skipping to change at page 25, line 17
Of course, an actual implementation might make considerable Of course, an actual implementation might make considerable
optimizations on this approach, but this section should provide hints optimizations on this approach, but this section should provide hints
about how MPLS-based SFC might be achieved with relatively small about how MPLS-based SFC might be achieved with relatively small
modifications to deployed MPLS devices. modifications to deployed MPLS devices.
15. Security Considerations 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]. Those documents provide analysis and present a present in [RFC8300]. Those documents provide analysis and present a
set of requirements and recommendations for security, but they do not set of requirements and recommendations for security and the
describe any mechanisms for securing NSH systems. normative security requirements from those documents apply to this
specification. However, it should be noted that those documents do
not describe any mechanisms for securing NSH systems.
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
that labels are swapped or popped correctly. Where an SF is not that labels are swapped or popped correctly. Where an SF is not
encapsulation aware the encapsulation may be stripped by an SFC proxy encapsulation-aware the encapsulation may be stripped by an SFC proxy
such that packet may exist as a native packet (perhaps IP) on the such that packet may exist as a native packet (perhaps IP) on the
path between SFC proxy and SF, however this is an intrinsic part of path between SFC proxy and SF, however this is an intrinsic part of
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.
SFC components are configured and enabled through a management system SFC components are configured and enabled through a management system
or a control plane. This document does not make any assumptions or a control plane. This document does not make any assumptions
about what mechanisms are used. Deployments should, however, be about what mechanisms are used. Deployments should, however, be
aware that vulnerabilities in the management plane or control plane aware that vulnerabilities in the management plane or control plane
of an SFC system imply vulnerabilities in the whole SFC system. of an SFC system imply vulnerabilities in the whole SFC system.
Thus, control plane solutions (such as Thus, control plane solutions (such as
[I-D.ietf-bess-nsh-bgp-control-plane]) and management plane [I-D.ietf-bess-nsh-bgp-control-plane]) and management plane
mechanisms must include security measures that can be enable by mechanisms must include security measures that can be enable by
operators to protect their SFC systems. operators to protect their SFC systems.
An analysis of the security of MPLS systems is provided in [RFC5920]. An analysis of the security of MPLS systems is provided in [RFC5920].
That document notes the MPLS forwarding plane has no built-in That document notes the MPLS forwarding plane has no built-in
security mechanisms. Some proposals to add encryption to the MPLS security mechanisms. Some proposals to add encryption to the MPLS
forwarding plane have been suggested forwarding plane have been suggested
([I-D.ietf-mpls-opportunistic-encrypt]), but no mechanisms have been ([I-D.ietf-mpls-opportunistic-encrypt]), but no mechanisms have been
agreed at the time of publication of this document. That means that agreed at the time of publication of this document. Additionally,
procedures described in this document rely on three basic principles: MPLS does not provide any cryptographic integrity protection on the
MPLS headers. That means that procedures described in this document
rely on three basic principles:
o The MPLS network is often considered to be a closed network such o The MPLS network is often considered to be a closed network such
that insertion, modification, or inspection of packets by an that insertion, modification, or inspection of packets by an
outside party is not possible. This is particularly pertinent in outside party is not possible. MPLS networks are operated with
the SFC context because [RFC7665] notes that "The architecture closed boundaries so that MPLS encapsulated packets are not
described herein is assumed to be applicable to a single network admitted to the network, and MPLS headers are stripped before
administrative domain." packets are forwarded from the network. This is particularly
pertinent in the SFC context because [RFC7665] notes that "The
architecture described herein is assumed to be applicable to a
single network administrative domain." Furthermore, [RFC8300]
states that packets originating outside the SFC-enabled domain
MUST be dropped if they contain an NSH and packets exiting the
SFC-enabled domain MUST be dropped if they contain an NSH. These
constraints apply equally to the use of MPLS to encode a logical
representation of the NSH.
o The underlying transport mechanisms (such as Ethernet) between o The underlying transport mechanisms (such as Ethernet) between
adjacent MPLS nodes may offer security mechanisms that can be used adjacent MPLS nodes may offer security mechanisms that can be used
to defend packets "on the wire". to defend packets "on the wire".
o The SFC-capable devices participating in an SFC system are o The SFC-capable devices participating in an SFC system are
responsible for verifying and protecting packets and their responsible for verifying and protecting payload packets and their
contents as well as providing other security capabilities that contents as well as providing other security capabilities that
might be required in the particular system. might be required in the particular system.
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, this design relies on the component underlying technologies to
addressed) in all the underlying technologies used by this design. address the potential security vulnerabilities, and documents the
No known new security vulnerabilities are introduced by this design, necessary protections (or risk of their absence) above. It does not
but if issues are discovered in the future it is expected that they include any native security mechanisms in-band with the MPLS encoding
will be addressed through modifications to control/management of the NSH functionality.
components of any solution, or through changes to the underlying
technology. Note that configuration elements of this system (such as the
programming of the table of metadata, see Section 12) must also be
adequately secured although such mechanisms are not in scope for this
protocol specification.
No known new security vulnerabilities over the SFC architecture
[RFC7665] and the NSH specification [RFC8300] are introduced by this
design, but if issues are discovered in the future it is expected
that they will be addressed through modifications to control/
management components of any solution, or through changes to the
underlying technology.
16. 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 |
-------+-----------------------------------+-------------- -------+-----------------------------------+--------------
skipping to change at page 27, line 10 skipping to change at page 27, line 31
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, Joel Halpern, Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, Joel Halpern,
and Mach Chen for reviews of this text. Thanks to Russ Mundy for his and Mach Chen for reviews of this text. Thanks to Russ Mundy for his
Security Directorate review and to S Moonesamy for useful Security Directorate review and to S Moonesamy for useful
discussions. discussions. Thanks also to Benjamin Kaduk, Alissa Cooper, Eric
Rescorla, Mirja Kuehlewind, Alvaro Retana, and Martin Vigoureux for
comprehensive reviews during IESG evaluation.
The authors would like to be able to thank the authors of The authors would like to be able to thank the authors of
[I-D.xuclad-spring-sr-service-chaining] and [RFC8402] whose original [I-D.xuclad-spring-sr-service-programming] and [RFC8402] whose
work on service chaining and the identification of services using original work on service chaining and the identification of services
SIDs, and conversation with whom helped clarify the application of using SIDs, and conversation with whom helped clarify the application
MPLS-SR to SFC. of MPLS-SR to SFC.
Particular thanks to Loa Andersson for conversations and advice about Particular thanks to Loa Andersson for conversations and advice about
working group process. working group process.
18. Contributors 18. Contributors
The following people contributed text to this document: The following people contributed text to this document:
Andrew Malis Andrew Malis
Email: agmalis@gmail.com Email: agmalis@gmail.com
19. References 19. References
19.1. Normative References 19.1. Normative References
[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>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[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.,
skipping to change at page 28, line 15 skipping to change at page 28, line 46
[RFC8393] Farrel, A. and J. Drake, "Operating the Network Service [RFC8393] Farrel, A. and J. Drake, "Operating the Network Service
Header (NSH) with Next Protocol "None"", RFC 8393, Header (NSH) with Next Protocol "None"", RFC 8393,
DOI 10.17487/RFC8393, May 2018, DOI 10.17487/RFC8393, May 2018,
<https://www.rfc-editor.org/info/rfc8393>. <https://www.rfc-editor.org/info/rfc8393>.
19.2. Informative References 19.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-05 (work in progress), January 2019. nsh-bgp-control-plane-09 (work in progress), March 2019.
[I-D.ietf-mpls-opportunistic-encrypt] [I-D.ietf-mpls-opportunistic-encrypt]
Farrel, A. and S. Farrell, "Opportunistic Security in MPLS Farrel, A. and S. Farrell, "Opportunistic Security in MPLS
Networks", draft-ietf-mpls-opportunistic-encrypt-03 (work Networks", draft-ietf-mpls-opportunistic-encrypt-03 (work
in progress), March 2017. in progress), March 2017.
[I-D.ietf-spring-segment-routing-mpls] [I-D.xuclad-spring-sr-service-programming]
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-18
(work in progress), December 2018.
[I-D.xuclad-spring-sr-service-chaining]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Segment Routing for Henderickx, W., and S. Salsano, "Service Programming with
Service Chaining", draft-xuclad-spring-sr-service- Segment Routing", draft-xuclad-spring-sr-service-
chaining-01 (work in progress), March 2018. programming-01 (work in progress), October 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 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
 End of changes. 47 change blocks. 
123 lines changed or deleted 124 lines changed or added

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