MPLS Working Group X. Xu
Internet-Draft S. Bryant
Intended status: Standards Track Huawei
Expires: April 16, 2017 H. Assarpour
Broadcom
H. Shah
Ciena
L. Contreras
Telefonica I+D
D. Bernier
Bell Canada
October 13, 2016
Service Chaining using MPLS Source Routing
draft-xu-mpls-service-chaining-00
Abstract
Source Packet Routing in Networking (SPRING) WG is developing an MPLS
source routing mechanism. This MPLS source routing mechanism can be
leveraged to realize the service path layer functionality of the
service function chaining (i.e., steering the selected traffic
through a particular service function path) by encoding the service
function path information as an MPLS label stack. This document
describes how to use the MPLS source routing mechanism as developed
by the SPRING WG to realize the service path layer functionality of
service function chaining.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Xu, et al. Expires April 16, 2017 [Page 1]
Internet-Draft Service Chaining using MPLS Source Routing October 2016
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 16, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Description . . . . . . . . . . . . . . . . . . . . 3
3.1. Encoding SFP Information by an MPLS Label Stack . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
When applying a particular Service Function Chain (SFC) [RFC7665] to
the traffic selected by a service classifier, the traffic need to be
steered through an ordered set of Service Functions (SF) in the
network. This ordered set of SFs in the network indicates the
Service Function Path (SFP) associated with the above SFC. In order
to steer the selected traffic through the required ordered list of
SFs, the service classifier needs to attach information to the packet
specifying which Service Function Forwarders (SFFs) and which SFs are
to be visited by the selected traffic. The Source Packet Routing in
Networking (SPRING) WG is developing an MPLS source routing mechanism
which can be used to steer traffic through an ordered set of routers
(i.e., an explicit path) and instruct nodes on that path to execute
Xu, et al. Expires April 16, 2017 [Page 2]
Internet-Draft Service Chaining using MPLS Source Routing October 2016
specific operations on the packet. This MPLS source routing
mechanism thus can be leveraged to realize the service path layer
functionality of the SFC (i.e., steering traffic through a particular
SFP) by encoding the SFP information as a label stack. This document
describes how to use the MPLS source routing mechanisms to realize
the service path layer functionality of the service function
chaining. Note that this approach is aligned with the Transport
Derived SFF mode as described in Section 4.3.1 of [RFC7665].
2. Terminology
This memo makes use of the terms defined in
[I-D.ietf-spring-segment-routing-mpls] and [RFC7665].
3. Solution Description
+----------------------------------------------- ----+
| MPLS SPRING Networks |
| +---------+ +---------+ |
| | SF1 | | SF2 | |
| +----+----+ +----+----+ |
| ^ | |(3) ^ | |(6) |
| (1) (2)| | V (4) (5)| | V (7) |
+----+-----+ ---> +----+----+ ----> +----+----+ ---> +---+---+
|Classifier+------+ SFF1 +-------+ SFF2 +-------+ D |
+----------+ +---------+ +---------+ +---+---+
| |
+----------------------------------------------------+
Figure 1: Service Function Chaining in MPLS-SPRING Networks
As shown in Figure 1, SFF1 and SFF2 are two MPLS-SPRING-capable
nodes. They are also SFFs, each with one SF attached. In addition,
they have allocated and advertised Segment IDs (SID) for their
locally attached SFs. In the MPLS-SPRING context, SIDs are encoded
as MPLS labels. For example, SFF1 allocates and advertises a SID
(i.e., SID(SF1)) for SF1 while SFF2 allocates and advertises an SID (
i.e., SID(SF2)) for SF2. These SIDs, which are used to indicate SFs
are referred to as SF SIDs. To encode the SFP information as an MPLS
label stack, those SF SIDs as mentioned above would be interpreted as
local MPLS labels. More specifically, local MPLS labels are
allocated from SFFs' (e.g., SFF1 in Figure 1) label spaces to
identify their attached SFs (e.g., SF1 in Figure 1), whilst the SFFs
are identified by either nodal SIDs or adjacency SIDs depending on
how strictly the network path needs to be specified. In addition,
assume node SIDs for SFF1 and SFF2 are SID(SFF1) and SID(SFF2)
respectively. Now assume a given traffic flow destined for
destination D is selected by the service classifier to go through a
particular SFC (i.e., SF1-> SF2) before reaching its final
Xu, et al. Expires April 16, 2017 [Page 3]
Internet-Draft Service Chaining using MPLS Source Routing October 2016
destination D. Section 3.1 describes how to use the MPLS-based
source routing mechanism to realize the service path functionality of
the service function chaining (i.e., by encoding the SFP information
within an MPLS label stack).
3.1. Encoding SFP Information by an MPLS Label Stack
+----------------------------------------------- ----+
| MPLS SPRING Networks |
| +---------+ +---------+ |
| | SF1 | | SF2 | |
| +----+----+ +----+----+ |
| +---------+ | | +---------+ |
| |SID(SFF2)| | | |Pkt to D | |
| +---------+ | | +---------+ |
| |SID(SF2) | | | |
| +---------+ | ^ | | |
| |Pkt to D | ^ | | | | | |
| +---------+ | | | (5)| | |(6) |
| (2)| | |(3) | | V |
| (1) | | V (4) | (7) |
+----+-----+ ---> +----+----+ ----> +----+----+ ---> +---+---+
|Classifier+------+ SFF1 +-------+ SFF2 +-------+ D |
+----------+ +---------+ +---------+ +---+---+
| +---------+ +---------+ +---------+ |
| |SID(SFF1)| |SID(SFF2)| |Pkt to D | |
| +---------+ +---------+ +---------+ |
| |SID(SF1) | |SID(SF2) | |
| +---------+ +---------+ |
| |SID(SFF2)| |Pkt to D | |
| +---------+ +---------+ |
| |SID(SF2) | |
| +---------+ |
| |Pkt to D | |
| +---------+ |
+----------------------------------------------------+
Figure 2: Packet Walk in MPLS Source Routing based SFC
As shown in Figure 2, since the selected packet needs to travel
through an SFC (i.e., SF1->SF2), the service classifier would attach
a segment list of (i.e., SID(SFF1)->SID(SF1)->SID(SFF2)-> SID(SF2))
which indicates the corresponding SFP to the packet. This segment
list is represented by an MPLS label stack. To some extent, the MPLS
label stack here could be looked as a specific implementation of the
SFC encapsulation used for containing the SFP information [RFC7665].
When the encapsulated packet arrives at SFF1, SFF1 would know which
SF should be performed according to the top label (i.e., SID (SF1))
of the received MPLS packet. We first consider the case where SF1 is
Xu, et al. Expires April 16, 2017 [Page 4]
Internet-Draft Service Chaining using MPLS Source Routing October 2016
an encapsulation aware SF, i.e., it understands how to process a
packet with a pre-pended MPLS label stack. In this case the packet
would be sent to SF1 by SFF1 with the label stack SID(SFF2)->
SID(SF2). SF1 would perform the required service function on the
received MPLS packet where the payload is constrained to be an IP
packet, and the SF needs to process both IPv4 and IPv6 packets (note
that the SF would use the first nibble of the MPLS payload to
identify the payload type). After the MPLS packet is returned from
SF1, SFF1 would send it to SFF2 according to the top label (i.e., SID
(SFF2) ).
If SF1 is a legacy SF, i.e. one that is unable to process the MPLS
label stack, the remaining MPLS label stack (i.e.,
SID(SFF2)->SID(SF2)) MUST be saved and stripped from the packet
before sending the packet to SF1. When the packet is returned from
SF1, SFF1 would re-impose the MPLS label stack which had been
previously stripped and then send the packet to SFF2 according to the
current top label (i.e., SID (SFF2) ). As for how to associate the
corresponding MPLS label stack with the packets returned from legacy
SFs, those mechanisms as described in
[I-D.song-sfc-legacy-sf-mapping] could be considered.
When the encapsulated packet arrives at SFF2, SFF2 would perform the
similar action to that described above.
If there is no MPLS LSP towards the next node segment (i.e., the next
SFF identified by the current top label), the corresponding IP-based
tunnel (e.g., MPLS-in-IP/GRE tunnel [RFC4023], MPLS-in-UDP tunnel
[RFC7510] or MPLS-in-L2TPv3 tunnel [RFC4817]) would be used instead
(for more details about this special usage, please refer to
[I-D.xu-mpls-spring-islands-connection-over-ip]). Since the
transport (i.e., the underlay) could be IPv4, IPv6 or even MPLS
networks, the above approach of encoding the SFP information by an
MPLS label stack is fully transport-independent which is one of the
major requirements for the SFC encapsulation [RFC7665].
4. Acknowledgements
The authors would like to thank Loa Andersson, Andrew G. Malis,
Adrian Farrel, Alexander Vainshtein and Joel M. Halpern for their
valuable comments and suggestions on the document
5. IANA Considerations
This document makes no request of IANA.
Xu, et al. Expires April 16, 2017 [Page 5]
Internet-Draft Service Chaining using MPLS Source Routing October 2016
6. Security Considerations
It is fundamental to the SFC design that the classifier is a trusted
resource which determines the processing that the packet will be
subject to, including for example the firewall. It is also
fundamental to the SPRING design that packets are routed through the
network using the path specified by the node imposing the SIDs.
Where an SF is not encapsulation aware the packet may exist as an IP
packet, however this is an intrinsic part of the SFC design which
needs to define how a packet is protected in that environment. Where
a tunnel is used to link two non-MPLS domains, the tunnel design
needs to specify how it is secured. Thus the secutity
vulnerabilities are addressed in the underlying technologies used by
this design, which itself does not introduce any new security
vulnerabilities.
7. References
7.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,
<http://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-10 (work in progress), September 2016.
[I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R.,
jefftant@gmail.com, j., and E. Crabbe, "Segment Routing
with MPLS data plane", draft-ietf-spring-segment-routing-
mpls-05 (work in progress), July 2016.
[I-D.song-sfc-legacy-sf-mapping]
Song, H., You, J., Yong, L., Jiang, Y., Dunbar, L.,
Bouthors, N., and D. Dolson, "SFC Header Mapping for
Legacy SF", draft-song-sfc-legacy-sf-mapping-08 (work in
progress), September 2016.
Xu, et al. Expires April 16, 2017 [Page 6]
Internet-Draft Service Chaining using MPLS Source Routing October 2016
[I-D.xu-mpls-spring-islands-connection-over-ip]
Xu, X., Raszuk, R., Chunduri, U., Contreras, L., and L.
Jalil, "Connecting MPLS-SPRING Islands over IP Networks",
draft-xu-mpls-spring-islands-connection-over-ip-00 (work
in progress), October 2016.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<http://www.rfc-editor.org/info/rfc4023>.
[RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and
J. Young, "Encapsulation of MPLS over Layer 2 Tunneling
Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March
2007, <http://www.rfc-editor.org/info/rfc4817>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<http://www.rfc-editor.org/info/rfc7510>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
Authors' Addresses
Xiaohu Xu
Huawei
Email: xuxiaohu@huawei.com
Stewart Bryant
Huawei
Email: stewart.bryant@gmail.com
Hamid Assarpour
Broadcom
Email: hamid.assarpour@broadcom.com
Xu, et al. Expires April 16, 2017 [Page 7]
Internet-Draft Service Chaining using MPLS Source Routing October 2016
Himanshu Shah
Ciena
Email: hshah@ciena.com
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid, 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://people.tid.es/LuisM.Contreras/
Daniel Bernier
Bell Canada
Email: daniel.bernier@bell.ca
Xu, et al. Expires April 16, 2017 [Page 8]