One document matched: draft-xu-mpls-service-chaining-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-xu-mpls-service-chaining-00"
ipr="trust200902">
<front>
<title abbrev="Service Chaining using MPLS Source Routing">Service
Chaining using MPLS Source Routing</title>
<author fullname="Xiaohu Xu" initials="X.X." surname="Xu">
<organization>Huawei</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>xuxiaohu@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Stewart Bryant" initials="S.B" surname="Bryant">
<organization>Huawei</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>stewart.bryant@gmail.com</email>
<uri/>
</address>
</author>
<author fullname="Hamid Assarpour" initials="H.A" surname="Assarpour">
<organization>Broadcom</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>hamid.assarpour@broadcom.com</email>
<uri/>
</address>
</author>
<author fullname="Himanshu Shah" initials="H.S." surname="Shah">
<organization>Ciena</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>hshah@ciena.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Luis M. Contreras" initials="L.M." surname="Contreras">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Ronda de la Comunicacion, s/n</street>
<street>Sur-3 building, 3rd floor</street>
<city>Madrid,</city>
<code>28050</code>
<country>Spain</country>
</postal>
<email>luismiguel.contrerasmurillo@telefonica.com</email>
<uri>http://people.tid.es/LuisM.Contreras/</uri>
</address>
</author>
<author fullname="Daniel Bernier" initials="D.B." surname="Bernier">
<organization>Bell Canada</organization>
<address>
<postal>
<street/>
</postal>
<email>daniel.bernier@bell.ca</email>
</address>
</author>
<date month="" year="2016"/>
<area>Routing Area</area>
<workgroup>MPLS Working Group</workgroup>
<keyword>Sample</keyword>
<keyword>Draft</keyword>
<abstract>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>When applying a particular Service Function Chain (SFC) <xref
target="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
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 <xref target="RFC7665"/>.</t>
</section>
<section anchor="Teminology" title="Terminology">
<t>This memo makes use of the terms defined in <xref
target="I-D.ietf-spring-segment-routing-mpls"/> and <xref
target="RFC7665"/>.</t>
</section>
<section anchor="Advertising" title="Solution Description">
<t><figure>
<artwork align="center"><![CDATA[ +----------------------------------------------- ----+
| 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]]></artwork>
</figure></t>
<t>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 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).</t>
<section title="Encoding SFP Information by an MPLS Label Stack">
<t><figure>
<artwork align="center"><![CDATA[ +----------------------------------------------- ----+
| 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]]></artwork>
</figure>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 <xref target="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 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) ).</t>
<t>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 <xref
target="I-D.song-sfc-legacy-sf-mapping"/> could be considered.</t>
<t>When the encapsulated packet arrives at SFF2, SFF2 would perform
the similar action to that described above.</t>
<t>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 <xref target="RFC4023"/>,
MPLS-in-UDP tunnel <xref target="RFC7510"/> or MPLS-in-L2TPv3 tunnel
<xref target="RFC4817"/>) would be used instead (for more details
about this special usage, please refer to <xref
target="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 <xref
target="RFC7665"/>.</t>
<t/>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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</t>
<!---->
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t/>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.xu-mpls-spring-islands-connection-over-ip"?>
<?rfc include="reference.I-D.ietf-sfc-nsh"?>
<?rfc include="reference.I-D.ietf-spring-segment-routing-mpls"?>
<?rfc include="reference.I-D.song-sfc-legacy-sf-mapping"?>
<?rfc include="reference.RFC.4023"?>
<?rfc include="reference.RFC.7665"?>
<?rfc include="reference.RFC.4817"?>
<?rfc include="reference.RFC.7510"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:59:16 |