RFC 8595
An MPLS-Based Forwarding Plane for Service Function Chaining
Pages: 32
Proposed Standard
Proposed Standard
Part 2 of 2 – Pages 22 to 32
13. Worked Examples
This section reverts to the simplified descriptions of networks that rely wholly on label swapping or label stacking. As described in Section 4, actual deployment scenarios may depend on the use of both mechanisms and utilize a mixed mode as described in Section 8. Consider the simplistic MPLS SFC overlay network shown in Figure 10. A packet is classified for an SFP that will see it pass through two SFs (SFa and SFb) that are accessed through two SFFs (SFFa and SFFb, respectively). The packet is ultimately delivered to the destination, D. +---------------------------------------------------+ | MPLS SFC Network | | | | +---------+ +---------+ | | | SFa | | SFb | | | +----+----+ +----+----+ | | ^ | | ^ | | | | (2)| | |(3) (5)| | |(6) | | (1) | | V (4) | | V (7) | +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ |Classifier+------+ SFFa +-------+ SFFb +------+ D | +----------+ +---------+ +---------+ +-------+ | | +---------------------------------------------------+ Figure 10: Service Function Chaining in an MPLS Network Let us assume that the SFP is computed and assigned an SPI value of 239. The forwarding details of the SFP are distributed (perhaps using the mechanisms of [BGP-NSH-SFC]) so that the SFFs are programmed with the necessary forwarding instructions. The packet progresses as follows: 1. The classifier assigns the packet to the SFP and imposes two label stack entries comprising a single basic unit of MPLS SFC representation: * The higher label stack entry contains a label carrying the SPI value of 239. * The lower label stack entry contains a label carrying the SI value of 255.
Further labels may be imposed to tunnel the packet from the
classifier to SFFa.
2. When the packet arrives at SFFa, SFFa strips any labels
associated with the tunnel that runs from the classifier to SFFa.
SFFa examines the top labels and matches the SPI/SI to identify
that the packet should be forwarded to SFa. The packet is
forwarded to SFa unmodified.
3. SFa performs its designated function and returns the packet
to SFFa.
4. SFFa modifies the SI in the lower label stack entry (to 254) and
uses the SPI/SI to look up the forwarding instructions. It sends
the packet with two label stack entries:
* The higher label stack entry contains a label carrying the SPI
value of 239.
* The lower label stack entry contains a label carrying the SI
value of 254.
Further labels may be imposed to tunnel the packet from SFFa
to SFFb.
5. When the packet arrives at SFFb, SFFb strips any labels
associated with the tunnel from SFFa. SFFb examines the top
labels and matches the SPI/SI to identify that the packet should
be forwarded to SFb. The packet is forwarded to SFb unmodified.
6. SFb performs its designated function and returns the packet
to SFFb.
7. SFFb modifies the SI in the lower label stack entry (to 253) and
uses the SPI/SI to look up the forwarding instructions. It
determines that it is the last SFF in the SFP, so it strips the
two SFC Label stack entries and forwards the payload toward D
using the payload protocol.
Alternatively, consider the MPLS SFC overlay network shown in Figure 11. A packet is classified for an SFP that will see it pass through two SFs (SFx and SFy) that are accessed through two SFFs (SFFx and SFFy, respectively). The packet is ultimately delivered to the destination, D. +---------------------------------------------------+ | MPLS SFC Network | | | | +---------+ +---------+ | | | SFx | | SFy | | | +----+----+ +----+----+ | | ^ | | ^ | | | | (2)| | |(3) (5)| | |(6) | | (1) | | V (4) | | V (7) | +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ |Classifier+------+ SFFx +-------+ SFFy +------+ D | +----------+ +---------+ +---------+ +-------+ | | +---------------------------------------------------+ Figure 11: Service Function Chaining Using MPLS Label Stacking Let us assume that the SFP is computed and assigned an SPI value of 239. However, the forwarding state for the SFP is not distributed and installed in the network. Instead, it will be attached to the individual packets using the MPLS label stack. The packet progresses as follows: 1. The classifier assigns the packet to the SFP and imposes two basic units of MPLS SFC representation to describe the full SFP: * The top basic unit comprises two label stack entries as follows: + The higher label stack entry contains a label carrying the SFC context. + The lower label stack entry contains a label carrying the SF indicator for SFx.
* The lower basic unit comprises two label stack entries as
follows:
+ The higher label stack entry contains a label carrying the
SFC context.
+ The lower label stack entry contains a label carrying the
SF indicator for SFy.
Further labels may be imposed to tunnel the packet from the
classifier to SFFx.
2. When the packet arrives at SFFx, SFFx strips any labels
associated with the tunnel from the classifier. SFFx examines
the top labels and matches the context/SF values to identify that
the packet should be forwarded to SFx. The packet is forwarded
to SFx unmodified.
3. SFx performs its designated function and returns the packet
to SFFx.
4. SFFx strips the top basic unit of MPLS SFC representation,
revealing the next basic unit. It then uses the revealed
context/SF values to determine how to route the packet to the
next SFF, SFFy. It sends the packet with just one basic unit of
MPLS SFC representation comprising two label stack entries:
* The higher label stack entry contains a label carrying the SFC
context.
* The lower label stack entry contains a label carrying the SF
indicator for SFy.
Further labels may be imposed to tunnel the packet from SFFx
to SFFy.
5. When the packet arrives at SFFy, SFFy strips any labels
associated with the tunnel from SFFx. SFFy examines the top
labels and matches the context/SF values to identify that the
packet should be forwarded to SFy. The packet is forwarded to
SFy unmodified.
6. SFy performs its designated function and returns the packet
to SFFy.
7. SFFy strips the top basic unit of MPLS SFC representation,
revealing the payload packet. It forwards the payload toward D
using the payload protocol.
14. Implementation Notes
It is not the job of an IETF specification to describe the internals of an implementation, except where that directly impacts upon the bits on the wire that change the likelihood of interoperability or where the availability of configuration or security options directly affects the utility of an implementation. However, in view of the objective of this document to acknowledge that there may be a need for an interim deployment of SFC functionality in brownfield MPLS networks, this section provides some observations about how an SFF might utilize MPLS features that are available in existing routers. This section is not intended to be definitive or technically complete; rather, it is indicative. Consider the mechanism used to indicate to which Virtual Routing and Forwarding (VRF) system an incoming MPLS packet should be routed in a Layer 3 Virtual Private Network (L3VPN) [RFC4364]. In this case, the top MPLS label is an indicator of the VRF system that is to be used to route the payload. A similar approach can be taken with the label-swapping SFC technique described in Section 6 such that the SFC Context Label identifies a routing table specific to the SFP. The SF Label can be looked up in the context of this routing table to determine to which SF to direct the packet and how to forward it to the next SFF. Advanced features (such as metadata) are not inspected by SFFs. The packets are passed to SFIs that are MPLS-SFC aware or to SFC proxies, and those components are responsible for handling all metadata issues. Of course, an actual implementation might make considerable optimizations on this approach, but this section should provide hints about how MPLS-based SFC might be achieved with relatively small modifications to deployed MPLS devices.15. Security Considerations
Discussion of the security properties of SFC networks can be found in [RFC7665]. Further security discussion for the NSH and its use is provided in [RFC8300]. Those documents provide analysis and present a set of requirements and recommendations for security, and the 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 fully trusted element. That is, the classification decision process is not visible to the other elements, and its output is treated as accurate. As such, the classifier has responsibility for determining the processing that the packet will be subject to, including, for example, firewall functions. It is also fundamental to the MPLS design that packets are routed through the network using the path specified by the node imposing the labels and that the labels are swapped or popped correctly. Where an SF is not encapsulation aware, the encapsulation may be stripped by an SFC proxy such that a packet may exist as a native packet (perhaps IP) on the path between the SFC proxy and the 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 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 [BGP-NSH-SFC]) and management- plane mechanisms must include security measures that can be enabled by operators to protect their SFC systems. An analysis of the security of MPLS systems is provided in [RFC5920], which also notes that the MPLS forwarding plane has no built-in security mechanisms. Some proposals to add encryption to the MPLS forwarding plane have been suggested [MPLS-Opp-Sec], but no mechanisms have been agreed upon at the time of publication of this document. Additionally, 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 that insertion, modification, or inspection of packets by an outside party is not possible. MPLS networks are operated with closed boundaries so that MPLS-encapsulated packets are not admitted to the network, and MPLS headers are stripped before 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
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 payload 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,
the tunnel design needs to specify how the tunnel is secured.
Thus, this design relies on the component underlying technologies to
address the potential security vulnerabilities, and it documents the
necessary protections (or risk of their absence) above. It does not
include any native security mechanisms in-band with the MPLS encoding
of the NSH functionality.
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
IANA has made allocations from the "Extended Special-Purpose MPLS
Label Values" subregistry of the "Special-Purpose Multiprotocol Label
Switching (MPLS) Label Values" registry as follows:
Value | Description | Reference
-------+-----------------------------------+--------------
16 | Metadata Label Indicator (MLI) | RFC 8595
17 | Metadata Present Indicator (MPI) | RFC 8595
17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <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 and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014, <https://www.rfc-editor.org/info/rfc7274>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>. [RFC8393] Farrel, A. and J. Drake, "Operating the Network Service Header (NSH) with Next Protocol "None"", RFC 8393, DOI 10.17487/RFC8393, May 2018, <https://www.rfc-editor.org/info/rfc8393>.
17.2. Informative References
[BGP-NSH-SFC] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for NSH SFC", Work in Progress, draft-ietf-bess-nsh-bgp-control-plane-11, May 2019. [MPLS-Opp-Sec] Farrel, A. and S. Farrell, "Opportunistic Security in MPLS Networks", Work in Progress, draft-ietf-mpls-opportunistic-encrypt-03, March 2017. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>. [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>. [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <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>. [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, "Hierarchical Service Function Chaining (hSFC)", RFC 8459, DOI 10.17487/RFC8459, September 2018, <https://www.rfc-editor.org/info/rfc8459>. [SR-Srv-Prog] Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Service Programming with Segment Routing", Work in Progress, draft-xuclad-spring-sr-service-programming-02, April 2019.
Acknowledgements
This document derives ideas and text from [BGP-NSH-SFC]. The authors are grateful to all those who contributed to the discussions that led to that work: Loa Andersson, Andrew G. Malis, Alexander (Sasha) Vainshtein, Joel Halpern, Tony Przygienda, Stuart Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided helpful review comments. Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, Joel Halpern, and Mach Chen for reviews of this text. Thanks to Russ Mundy for his Security Directorate review and to S Moonesamy for useful 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 [SR-Srv-Prog] and [RFC8402] whose original work on service chaining and the identification of services using Segment Identifiers (SIDs), and conversation with whom, helped clarify the application of SR-MPLS to SFC. Particular thanks to Loa Andersson for conversations and advice about working group process.Contributors
The following individual contributed text to this document: Andrew G. Malis Email: agmalis@gmail.com
Authors' Addresses
Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Stewart Bryant Futurewei Email: stewart.bryant@gmail.com John Drake Juniper Networks Email: jdrake@juniper.net