draft-ietf-mpls-sfc-04.txt   draft-ietf-mpls-sfc-05.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: May 24, 2019 Huawei Expires: August 16, 2019 Huawei
J. Drake J. Drake
Juniper Networks Juniper Networks
November 20, 2018 February 12, 2019
An MPLS-Based Forwarding Plane for Service Function Chaining An MPLS-Based Forwarding Plane for Service Function Chaining
draft-ietf-mpls-sfc-04 draft-ietf-mpls-sfc-05
Abstract Abstract
Service Function Chaining (SFC) is the process of directing packets Service Function Chaining (SFC) is the process of directing packets
through a network so that they can be acted on by an ordered set of through a network so that they can be acted on by an ordered set of
abstract service functions before being delivered to the intended abstract service functions before being delivered to the intended
destination. An architecture for SFC is defined in RFC7665. destination. An architecture for SFC is defined in RFC7665.
The Network Service Header (NSH) can be inserted into packets to The Network Service Header (NSH) can be inserted into packets to
steer them along a specific path to realize a Service Function Chain. steer them along a specific path to realize a Service Function Chain.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Multiprotocol Label Switching (MPLS) is a widely deployed forwarding Multiprotocol Label Switching (MPLS) is a widely deployed forwarding
technology that uses labels placed in a packet in a label stack to 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 identify the forwarding actions to be taken at each hop through a
network. Actions may include swapping or popping the labels as well, network. Actions may include swapping or popping the labels as well,
as using the labels to determine the next hop for forwarding the as using the labels to determine the next hop for forwarding the
packet. Labels may also be used to establish the context under which packet. Labels may also be used to establish the context under which
the packet is forwarded. the packet is forwarded.
This document describes how Service Function Chaining can be achieved This document describes how Service Function Chaining can be achieved
in an MPLS network by means of a logical representation of the NSH in in an MPLS network by means of a logical representation of the NSH in
an MPLS label stack. It does not deprecate or replace the NSH, but an MPLS label stack. That is, the NSH is not used, but the fields of
acknowledges that there may be a need for an interim deployment of the NSH are mapped to fields in the MPLS label stack. It does not
SFC functionality in brownfield networks. 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 May 24, 2019. This Internet-Draft will expire on August 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 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. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 5 4. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . 5 4.3. Fine Control of Service Function Instances . . . . . . . 6
4.4. Micro Chains and Label Stacking . . . . . . . . . . . . . 6 4.4. Micro Chains and Label Stacking . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . 7 6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 8
7. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 10 7. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 10
8. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 12 8. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . 25 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
19.1. Normative References . . . . . . . . . . . . . . . . . . 26 19.1. Normative References . . . . . . . . . . . . . . . . . . 27
19.2. Informative References . . . . . . . . . . . . . . . . . 27 19.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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].
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 12, line 43 skipping to change at page 12, line 43
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 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 selects an instance of the SF to be executed at
hop, selects an instance of the SF to be executed at the next hop, the next hop, sets the SI label to the SI value of the next hop,
and tunnels the packet to the SFF for that SFI. and tunnels the packet to the SFF for that SFI.
o If the current hop requires an {SFP, SI} and the next hop requires o If the current hop requires an {SFP, SI} and the next hop requires
a {context label, SFI label}, it pops the {SFP, SI} from the top a {context label, SFI label}, it pops the {SFP, SI} from the top
of the MPLS label stack and tunnels the packet to the SFF of the MPLS label stack and tunnels the packet to the SFF
indicated by the context label. indicated by the context label.
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.
skipping to change at page 25, line 16 skipping to change at page 25, line 16
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]. present in [RFC8300]. Those documents provide analysis and present a
set of requirements and recommendations for security, but they 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
or a control plane. This document does not make any assumptions
about what mechanisms are used. Deployments should, however, be
aware that vulnerabilities in the management plane or control plane
of an SFC system imply vulnerabilities in the whole SFC system.
Thus, control plane solutions (such as
[I-D.ietf-bess-nsh-bgp-control-plane]) and management plane
mechanisms must include security measures that can be enable by
operators to protect their SFC systems.
An analysis of the security of MPLS systems is provided in [RFC5920].
That document notes the MPLS forwarding plane has no built-in
security mechanisms. Some proposals to add encryption to the MPLS
forwarding plane have been suggested
([I-D.ietf-mpls-opportunistic-encrypt]), but no mechanisms have been
agreed at the time of publication of this document. 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
that insertion, modification, or inspection of packets by an
outside party is not possible. 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."
o The underlying transport mechanisms (such as Ethernet) between
adjacent MPLS nodes may offer security mechanisms that can be used
to defend packets "on the wire".
o The SFC-capable devices participating in an SFC system are
responsible for verifying and protecting packets and their
contents as well as providing other security capabilities that
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, 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. No known new security vulnerabilities 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 26, line 17 skipping to change at page 27, line 8
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, Joel Halpern, Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, Joel Halpern,
and Mach Chen for reviews of this text. and Mach Chen for reviews of this text. Thanks to Russ Mundy for his
Security Directorate review and to S Moonesamy for useful
discussions.
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-chaining] and [RFC8402] whose original
work on service chaining and the identification of services using work on service chaining and the identification of services using
SIDs, and conversation with whom helped clarify the application of SIDs, and conversation with whom helped clarify the application of
MPLS-SR to SFC. 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.
skipping to change at page 27, line 24 skipping to change at page 28, line 15
[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-04 (work in progress), July 2018. nsh-bgp-control-plane-05 (work in progress), January 2019.
[I-D.ietf-mpls-opportunistic-encrypt]
Farrel, A. and S. Farrell, "Opportunistic Security in MPLS
Networks", draft-ietf-mpls-opportunistic-encrypt-03 (work
in progress), March 2017.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-15 data plane", draft-ietf-spring-segment-routing-mpls-18
(work in progress), October 2018. (work in progress), December 2018.
[I-D.xuclad-spring-sr-service-chaining] [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, "Segment Routing for
Service Chaining", draft-xuclad-spring-sr-service- Service Chaining", draft-xuclad-spring-sr-service-
chaining-01 (work in progress), March 2018. 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 [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
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[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. 18 change blocks. 
26 lines changed or deleted 79 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/