One document matched: draft-xu-sfc-using-mpls-spring-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-xu-sfc-using-mpls-spring-02"
ipr="trust200902">
<front>
<title abbrev="">Service Function Chaining Using MPLS-SPRING</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="Zhenbin Li" initials="Z.L." surname="Li">
<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>lizhenbin@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</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>
<!--
-->
<date day="" month="" year="2015"/>
<abstract>
<t>Source Packet Routing in Networking (SPRING) WG specifies a special
source routing mechanism. Such source routing mechanism can be leveraged
to realize the service path layer functionality of the service function
chaining (i.e, steering traffic through a particular service function
path) by encoding the service function path or the service function
chain information as the explicit path information. This document
describes how to leverage the MPLS-based source routing mechanism as
developed by the SPRING WG to realize the service path layer
functionality of the service function chaining.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>When applying a particular Service Function Chain (SFC) <xref
target="I-D.ietf-sfc-architecture"/> 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. To steer the selected traffic through an ordered list of
SFs in the network, the traffic need to be attached by the service
classifier with the information about the SFP (i.e., specifying exactly
which Service Function Forwarders (SFFs) and which SFs are to be visited
by traffic), the SFC, or the partially specified SFP which is in between
the former two extremes. Source Packet Routing in Networking (SPRING) WG
specifies a special source routing mechanism which can be used to steer
traffic through an ordered set of routers (i.e., an explicit path). Such
source routing mechanism 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, the SFC or the partially specified
SFP information as the explicit path information contained in packets.
The source routing mechanism specified by the SPRING WG can be applied
to the MPLS data plane <xref
target="I-D.ietf-spring-segment-routing-mpls"/>. This document describes
how to leverage the MPLS-based 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="I-D.ietf-sfc-architecture"/>.</t>
<section 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>
</section>
</section>
<section anchor="Teminology" title="Terminology">
<t>This memo makes use of the terms defined in <xref
target="I-D.ietf-spring-segment-routing"/> and <xref
target="I-D.ietf-sfc-architecture"/>.</t>
</section>
<section anchor="Advertising" title="Solution Description">
<t><figure>
<artwork align="center"><![CDATA[ +----------------------------------------------- ----+
| SPRING Netowrks |
| +---------+ +---------+ |
| | SF1 | | SF2 | |
| +----+----+ +----+----+ |
| | | |
| (1) | (2) | (3) |
+----+-----+ ---> +----+----+ ----> +----+----+ ---> +---+---+
|Classifier+------+ SFF1 +-------+ SFF2 +-------+ D |
+----------+ +---------+ +---------+ +---+---+
| |
+----------------------------------------------------+
Figure 1: Service Function Chaining in SPRING Networks]]></artwork>
</figure></t>
<t>As shown in Figure 1, assume SFF1 and SFF2 are two MPLS-SPRING-
capable nodes. They are also Service Function Forwarders (SFF) to which
two SFs (i.e., SF1 and SF2) are attached respectively. In addition, they
have allocated and advertised Segment IDs (SID) for their locally
attached SFs. In the MPLS-SPRING context, SIDs are intercepted as MPLS
labels. For example, SFF1 allocates and advertises an 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 by an MPLS label
stack, those SF SIDs as mentioned above would be interpreted as local
MPLS labels. In contrast, to encode the SFC information by an MPLS label
stack, those SF SIDs MUST be interpreted as domain-wide unique MPLS
labels, which means a big difference from the current usage of the MPLS
labels. The reason why local MPLS labels are not applicable is that all
of the labels in the stack would have to be swapped by the current SFF
before forwarding the packet to the next SFF if local labels are used.
In addition, assume node SIDs for SFF1 and SFF2 are SID(SFF1) and
SID(SFF2) respectively. To simplify the illustration in this document,
those node SIDs would be interpreted as domain-wide unique MPLS labels
as well. 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 and
3.2 describe approaches of leveraging the MPLS- based source routing
mechanisms to realize the service path functionality of the service
function chaining (i.e., by encoding the SFP information within an MPLS
label stack or by encoding the SFC information within an MPLS label
stack) respectively. Since the encoding of the partially specified SFP
is just a simple combination of the encoding of the SFP and the encoding
of the SFC, this document would not describe how to encode the partially
specified SFP anymore.</t>
<section title="Encoding SFP Information by an MPLS Label Stack">
<t>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
actually represented by a MPLS label stack. When the encapsulated
packet arrives at SFF1, SFF1 would know which SF should be performed
according to the current top label (i.e., SID (SF1)) of the received
MPLS packet. Before sending the packet to SF1, the whole MPLS label
stack (i.e., SID(SFF2)->SID(SF2)) MUST be stripped. After receiving
the packet returned from SF1, SFF1 would reimpose the MPLS label stack
which had been stripped before to the packet and then send it to SFF2
according to the current top label (i.e., SID (SFF2) ). Note that
popping and reimposing a label stack means a difference from the
current MPLS forwarding behavior. Details of the above special MPLS
forwarding behavior would be discribed in a later version of this
document. When the encapsulated packet arrives at SFF2, SFF2 would do
the similar action as what has been done by SFF1. 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="I-D.ietf-sfc-architecture"/>.</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-L2TPv3 tunnel <xref target="RFC4817"/> or MPLS-in-UDP tunnel
<xref target="I-D.ietf-mpls-in-udp"/>) could be used instead (For more
details about this special usage, please refer to <xref
target="I-D.xu-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="I-D.ietf-sfc-architecture"/>.</t>
<t>In addition, the service classifier could further impose metadata
on the MPLS packet through the Network Service Header (NSH) <xref
target="I-D.quinn-sfc-nsh"/> (As for how to contain the NSH within a
MPLS packet, please see Section 3.3). Here the Service Path field
wihin the NSH would not be used for the path selection purpose anymore
and therefore it MUST be set to a particular value to indicate such
particular usage. In addition, the service index value within the NSH
is set to a value indicating the total number of SFs within the
service function path. The service index SHOULD be decreased by one on
each SF or SF-proxy on behalf of the corresponding legacy SF. When the
service index become zero, the NSH MUST be removed from the packet by
the SF or SF-proxy on behalf of the corresponding legacy SF. </t>
</section>
<section title="Encoding SFC Information by an MPLS Label Stack">
<t>Since the selected packet needs to travel through an SFC (i.e.,
SF1->SF2), the service classifier would attach a segment list
(i.e., SID(SF1)->SID(SF2)) which indicates that SFC to the packet.
This segment list is actually represented by a MPLS label stack. Since
it's known to the service classifier that SFF1 is attached with an
instance of SF1, the service classifier would therefore send the MPLS
encapsulated packet through either an MPLS LSP tunnel or an IP-based
tunnel towards SFF1. When the MPLS encapsulated packet arrives at
SFF1, SFF1 would know which SF should be performed according to the
current top label (i.e., SID (SF1)). Before sending the packet to SF1,
the whole MPLS label stack (i.e., SID(SF2)}) MUST be stripped. Upon
receiving the packet returned from SF1, SFF1 would re-impose the MPLS
label stack which had been stripped before to the packet, and then
send it to SFF2 through either an MPLS LSP tunnel or an IP-based
tunnel towards SFF2 since it's known to SFF1 that SFF2 is attached
with an instance of SF2. When the encapsulated packet arrives at SFF2,
SFF2 would do the similar action as what has been done by SFF1. Since
the transport (i.e., the underlay) could be IPv4, IPv6 or even MPLS
networks, the above approach of encoding the SFC information by an
MPLS label stack is fully transport-independent which is one of the
major requirements for the SFC encapsulation <xref
target="I-D.ietf-sfc-architecture"/>.</t>
<t>In addition, the service classifier could further impose metadata
on the MPLS packet through the Network Service Header (NSH) <xref
target="I-D.quinn-sfc-nsh"/>. The procedures of imposing, consumming
and stripping the NSH is the same as that being mentioned in Section
3.1.</t>
<t/>
</section>
<section title="How to Contain Metadata within an MPLS Packet">
<t>Since the MPLS encapsulation has no explicit protocol identifier
field to indicate the protocol type of the MPLS payload, how to
indicate the presence of metadata (i.e., the NSH which is only used as
a metadata containner) in MPLS packets is a potential issue. There are
two possible ways to address the above issue: 1) SFFs allocate two
different labels for a given SF, one indicates the presence of NSH
while the other indicates the absence of NSH; 2) Add an protocol
identifier field at the bottom of the MPLS label stack to indicate the
presence or absence of the NSH (For more details about the protocol
identifier field in the MPLS packet, see <xref
target="I-D.xu-mpls-payload-protocol-identifier"/> ). The former
approach has no change to the current MPLS architecture but it would
require more than one label binding for a given SF. The latter
approach only requires a single label binding for a given SF but it
would require a little change to the current MPLS architecture. Which
approach would be chosen depends on the rough consensus of the IETF
community.</t>
</section>
</section>
<!---->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Loa Andersson and Andrew G. Malis for
their valuable comments and suggestions on the draft. The authors would
like to thank Adrian Farrel, Stewart Bryant, Carlos Pignataro, Huub van
Helvoort, Alexander Vainshtein, Joel M. Halpern, Loa Andersson and
Andrew G. Malis for their valuable comments and suggestions on how to
indicate the presence of metadata within an MPLS packet.</t>
<!---->
</section>
<section anchor="IANA" title="IANA Considerations">
<t>TBD.</t>
<!---->
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
<!---->
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
<?rfc include="reference.I-D.ietf-spring-segment-routing-mpls"?>
<?rfc include="reference.I-D.ietf-sfc-architecture"?>
<!---->
</references>
<references title="Informative References">
<!---->
<?rfc include="reference.I-D.ietf-spring-segment-routing"?>
<?rfc include="reference.I-D.xu-spring-islands-connection-over-ip"?>
<?rfc include="reference.I-D.xu-mpls-payload-protocol-identifier"?>
<?rfc include="reference.I-D.quinn-sfc-nsh"?>
<?rfc include="reference.RFC.4023"?>
<?rfc include="reference.RFC.4817"?>
<?rfc include="reference.I-D.ietf-mpls-in-udp"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:03:53 |