draft-ietf-mpls-sfc-06.txt   draft-ietf-mpls-sfc-07.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: September 8, 2019 Huawei Expires: September 8, 2019 Huawei
J. Drake J. Drake
Juniper Networks Juniper Networks
March 7, 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-06 draft-ietf-mpls-sfc-07
Abstract Abstract
This document describes how Service Function Chaining (SFC) can be This document describes how Service Function Chaining (SFC) can be
achieved in an MPLS network by means of a logical representation of achieved in an MPLS network by means of a logical representation of
the Network Service Header (NSH) in an MPLS label stack. That is, the Network Service Header (NSH) in an MPLS label stack. That is,
the NSH is not used, but the fields of the NSH are mapped to fields 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, 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 but acknowledges that there may be a need for an interim deployment
of SFC functionality in brownfield networks. of SFC functionality in brownfield networks.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
5. Basic Unit of Representation . . . . . . . . . . . . . . . . 6 5. Basic Unit of Representation . . . . . . . . . . . . . . . . 6
6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 7 6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 7
7. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 10 7. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 10
8. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 12.2.1. Loss of Inband Metadata . . . . . . . . . . . . . . 20
13. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 21
14. Implementation Notes . . . . . . . . . . . . . . . . . . . . 24 14. Implementation Notes . . . . . . . . . . . . . . . . . . . . 24
15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
19.1. Normative References . . . . . . . . . . . . . . . . . . 28 19.1. Normative References . . . . . . . . . . . . . . . . . . 28
19.2. Informative References . . . . . . . . . . . . . . . . . 28 19.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 7, line 45 skipping to change at page 7, line 45
The use case scenario for this approach is introduced in Section 4.1. 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 11 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 5 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
skipping to change at page 10, line 17 skipping to change at page 10, line 17
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.
As can be seen in Figure 3, the top of the label stack comprises the 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 labels necessary to deliver the packet over the MPLS tunnel between
SFFs. Any MPLS encapsulation may be used. 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 11 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 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
skipping to change at page 10, line 46 skipping to change at page 10, line 46
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.
TTL: The TTL fields in the SFC Context label stack entry SF label TTL: The TTL fields in the SFC Context label stack entry and in the
stack entry SHOULD be set to 1 as stated in Section 5, but MAY be SF label stack entry SHOULD be set to 1 as stated in Section 5,
set to larger values if the label indicated a forwarding operation but MAY be set to larger values if the label indicated a
towards the node that hosts the SF. forwarding operation towards the node that hosts the SF.
------------------- -------------------
~ Tunnel Labels ~ ~ Tunnel Labels ~
+-------------------+ +-------------------+
~ Optional ~ ~ Optional ~
~ Entropy Label ~ ~ Entropy Label ~
+-------------------+ - - - +-------------------+ - - -
| SFC Context Label | | SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC +-------------------+ Basic unit of MPLS label stack for SFC
| SF Label | | SF Label |
skipping to change at page 20, line 22 skipping to change at page 20, line 22
Figure 9: The Metadata TLV Figure 9: The Metadata TLV
The fields of this TLV are interpreted as follows: The fields of this TLV are interpreted as follows:
Length: The length of the metadata carried in the Metadata field in Length: The length of the metadata carried in the Metadata field in
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] and encoded with the most significant bit
first.
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.2.1. Loss of Inband Metadata
Note that inband exchange of metadata is vulnerable to packet loss.
This is both a risk arising from network faults and an attack
vulnerability.
If packets that arrive at an SFF use an MLI that does not have an
entry in the metadata table, an alarm can be raised and the packet
can be discarded or processed without the metadata according to local
configuration. This provides some long-term mitigation, but is not
an ideal solution.
Further mitigation to loss of metadata packets can be achieved by
retransmitting them at a configurable interval. This is a relatively
cheap, but only partial solution because there may still be a window
during which the metadata has not been received.
The concern of lost metadata may be particularly important when the
metadata applicable to a specific MPI is being changed. This could
result in out-of-date metadata being applied to a packet. If this is
a concern, it is RECOMMENDED that a new MPI is used to install a new
entry in the metadata table, and the packets in the flow should be
marked with the equivalent new MLI.
Finally, if an application that requires metadata is sensitive to
this potential loss or attack, it SHOULD NOT use inband metadata
distribution, but SHOULD rely on control plane or management plane
mechanisms because these approaches can use a more sophisticated
protocol that includes confirmation of delivery, and can perform
verification or inspection of entries in the metadata table.
13. Worked Examples 13. Worked Examples
This section reverts to the simplified descriptions of networks that This section reverts to the simplified descriptions of networks that
rely wholly on label swapping or label stacking. As described in rely wholly on label swapping or label stacking. As described in
Section 4, actual deployment scenarios may depend on the use of both Section 4, actual deployment scenarios may depend on the use of both
mechanisms and utilize a mixed mode as described in Section 8. 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
skipping to change at page 25, line 22 skipping to change at page 25, line 46
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 and the set of requirements and recommendations for security and the
normative security requirements from those documents apply to this normative security requirements from those documents apply to this
specification. However, it should be noted that those documents do specification. However, it should be noted that those documents do
not describe any mechanisms for securing NSH systems. 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 fully
resource which determines the processing that the packet will be trusted element. That is, the classification decision process is not
subject to, including for example the firewall. It is also visible to the other elements and its output is treated as accurate.
fundamental to the MPLS design that packets are routed through the As such, the classifier has responsibility for determining the
network using the path specified by the node imposing the labels, and processing that the packet will be subject to, including, for
that labels are swapped or popped correctly. Where an SF is not example, firewall functions. It is also fundamental to the MPLS
encapsulation-aware the encapsulation may be stripped by an SFC proxy design that packets are routed through the network using the path
such that packet may exist as a native packet (perhaps IP) on the specified by the node imposing the labels, and that labels are
path between SFC proxy and SF, however this is an intrinsic part of swapped or popped correctly. Where an SF is not encapsulation-aware
the SFC design which needs to define how a packet is protected in the encapsulation may be stripped by an SFC proxy such that packet
that environment. may exist as a native packet (perhaps IP) on the 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 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.
 End of changes. 10 change blocks. 
23 lines changed or deleted 58 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/