draft-ietf-mpls-sfc-01.txt   draft-ietf-mpls-sfc-02.txt 
MPLS Working Group A. Farrel MPLS Working Group A. Farrel
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track S. Bryant Intended status: Standards Track S. Bryant
Expires: November 16, 2018 Huawei Expires: February 6, 2019 Huawei
J. Drake J. Drake
Juniper Networks Juniper Networks
May 15, 2018 August 5, 2018
An MPLS-Based Forwarding Plane for Service Function Chaining An MPLS-Based Forwarding Plane for Service Function Chaining
draft-ietf-mpls-sfc-01 draft-ietf-mpls-sfc-02
Abstract Abstract
Service Function Chaining (SFC) is the process of directing packets Service Function Chaining (SFC) is the process of directing packets
through a network so that they can be acted on by an ordered set of through a network so that they can be acted on by an ordered set of
abstract service functions before being delivered to the intended abstract service functions before being delivered to the intended
destination. An architecture for SFC is defined in RFC7665. destination. An architecture for SFC is defined in RFC7665.
The Network Service Header (NSH) can be inserted into packets to The Network Service Header (NSH) can be inserted into packets to
steer them along a specific path to realize a Service Function Chain. steer them along a specific path to realize a Service Function Chain.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 16, 2018. This Internet-Draft will expire on February 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . . . . . . . . 25
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
18.1. Normative References . . . . . . . . . . . . . . . . . . 26 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
18.2. Informative References . . . . . . . . . . . . . . . . . 27 19.1. Normative References . . . . . . . . . . . . . . . . . . 26
19.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Service Function Chaining (SFC) is the process of directing packets Service Function Chaining (SFC) is the process of directing packets
through a network so that they can be acted on by an ordered set of through a network so that they can be acted on by an ordered set of
abstract service functions before being delivered to the intended abstract service functions before being delivered to the intended
destination. An architecture for SFC is defined in [RFC7665]. destination. An architecture for SFC is defined in [RFC7665].
When applying a particular Service Function Chain to the traffic When applying a particular Service Function Chain to the traffic
skipping to change at page 6, line 20 skipping to change at page 6, line 26
4.4. Micro Chains and Label Stacking 4.4. Micro Chains and Label Stacking
The scenario in Section 4.2 may be extended to its logical extreme by The scenario in Section 4.2 may be extended to its logical extreme by
making each concatenated chain as short as it can be: one service making each concatenated chain as short as it can be: one service
function. Each label in the stack indicates the next service function. Each label in the stack indicates the next service
function to be executed, and the network is programmed through the function to be executed, and the network is programmed through the
control plane or management plane to know how to route to the next control plane or management plane to know how to route to the next
(i.e., first) hop in each chain just as it would be to support the (i.e., first) hop in each chain just as it would be to support the
scenarios in Section 4.1 and Section 4.2. scenarios in Section 4.1 and Section 4.2.
This scenario is functionally identical to the use of MPLS-SR for SFC
as described Section 4.5, and the discussion in that section applies
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.
The application of SR to SFC was considered in early versions of the The application of SR to SFC was considered in early versions of the
SR architecture [I-D.ietf-spring-segment-routing] and the MPLS-SR SR architecture [RFC8402] and the MPLS-SR specification
specification [I-D.ietf-spring-segment-routing-mpls], but has since [I-D.ietf-spring-segment-routing-mpls], but has since been moved out
been moved out of those documents. An implementation proposal for of those documents. An implementation proposal for achieving SFC
achieving SFC using MPLS-SR can be found in using MPLS-SR can be found in [I-D.xuclad-spring-sr-service-chaining]
[I-D.xuclad-spring-sr-service-chaining] and is not discussed further and is not discussed further in this document.
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 15, line 17 skipping to change at page 15, line 17
Metadata is defined in [RFC7665] as providing "the ability to Metadata is defined in [RFC7665] as providing "the ability to
exchange context information between classifiers and SFs, and among exchange context information between classifiers and SFs, and among
SFs." [RFC8300] defines how this context information can be directly SFs." [RFC8300] defines how this context information can be directly
encoded in fields that form part of the NSH encapsulation. encoded in fields that form part of the NSH encapsulation.
The next two sections describe how metadata is associated with user The next two sections describe how metadata is associated with user
data packets, and how metadata may be exchanged between SFC nodes in data packets, and how metadata may be exchanged between SFC nodes in
the network, when using an MPLS encoding of the logical the network, when using an MPLS encoding of the logical
representation of the NSH. representation of the NSH.
It should be noted that the MPLS encoding is slightly less functional It should be noted that the MPLS encoding is less functional than the
than the direct use of the NSH. Both methods support metadata that direct use of the NSH. Both methods support metadata that is "per-
is "per-SFP" or "per-packet-flow" (see [RFC8393] for definitions of SFP" or "per-packet-flow" (see [RFC8393] for definitions of these
these terms), but "per-packet" metadata (where the metadata must be terms), but "per-packet" metadata (where the metadata must be carried
carried on each packet because it differs from one packet to the next on each packet because it differs from one packet to the next even on
even on the same flow or SFP) is only supported using the NSH and not the same flow or SFP) is only supported using the NSH and not using
using the mechanisms defined in this document. the mechanisms defined in this document.
12.1. Indicating Metadata in User Data Packets 12.1. Indicating Metadata in User Data Packets
Metadata is achieved in the MPLS realization of the logical NSH by Metadata is achieved in the MPLS realization of the logical NSH by
the use of an SFC Metadata Label which uses the Extended Special the use of an SFC Metadata Label which uses the Extended Special
Purpose Label construct [RFC7274]. Thus, three label stack entries Purpose Label construct [RFC7274]. Thus, three label stack entries
are present as shown in Figure 4: are present as shown in Figure 4:
o The Extension Label (value 15) o The Extension Label (value 15)
skipping to change at page 26, line 20 skipping to change at page 26, line 20
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.
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 [I-D.xuclad-spring-sr-service-chaining] and [RFC8402] whose original
[I-D.ietf-spring-segment-routing] whose original work on service work on service chaining and the identification of services using
chaining and the identification of services using SIDs, and SIDs, and conversation with whom helped clarify the application of
conversation with whom helped clarify the application of MPLS-SR to MPLS-SR to SFC.
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. References 18. Contributors
18.1. Normative References The following people contributed text to this document:
Andrew Malis
Email: agmalis@gmail.com
19. 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>.
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating
and Retiring Special-Purpose MPLS Labels", RFC 7274, and Retiring Special-Purpose MPLS Labels", RFC 7274,
DOI 10.17487/RFC7274, June 2014, DOI 10.17487/RFC7274, June 2014,
<https://www.rfc-editor.org/info/rfc7274>. <https://www.rfc-editor.org/info/rfc7274>.
skipping to change at page 27, line 10 skipping to change at page 27, line 19
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
[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>.
18.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-03 (work in progress), March 2018. nsh-bgp-control-plane-04 (work in progress), July 2018.
[I-D.ietf-sfc-hierarchical] [I-D.ietf-sfc-hierarchical]
Dolson, D., Homma, S., Lopez, D., and M. Boucadair, Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
"Hierarchical Service Function Chaining (hSFC)", draft- "Hierarchical Service Function Chaining (hSFC)", draft-
ietf-sfc-hierarchical-08 (work in progress), April 2018. ietf-sfc-hierarchical-11 (work in progress), June 2018.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[I-D.ietf-spring-segment-routing-mpls] [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-13 data plane", draft-ietf-spring-segment-routing-mpls-14
(work in progress), April 2018. (work in progress), June 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,
skipping to change at page 28, line 15 skipping to change at page 28, line 15
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
Authors' Addresses Authors' Addresses
Adrian Farrel Adrian Farrel
Juniper Networks Juniper Networks
Email: afarrel@juniper.net Email: afarrel@juniper.net
Stewart Bryant Stewart Bryant
Huawei Huawei
 End of changes. 18 change blocks. 
40 lines changed or deleted 49 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/