One document matched: draft-xu-spring-sfc-use-case-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-spring-sfc-use-case-02"
ipr="trust200902">
<front>
<title abbrev="SFC Use Case for SPRING">Service Function Chaining Use Case
for 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="2014"/>
<abstract>
<t>This document describes a particular use case for SPRING where the
Segment Routing mechanism is leveraged to realize the service path layer
functionality of the Service Function Chaining (i.e, steering traffic
through the service function path).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>When applying a particular Service Function Chaining (SFC) <xref
target="I-D.quinn-sfc-arch"/> to the traffic selected by the service
classifier, the traffic need to be steered through an ordered set of
service nodes in the network. This ordered set of service nodes
indicates the service function path which is actually the instantiation
of the above SFC in the network. Furthermore, additional information
about the traffic (a.k.a. metadata) which is helpful for enabling
value-added services may need to be carried across those service nodes
within the SFC instantiation. As mentioned in <xref
target="I-D.rijsman-sfc-metadata-considerations"/> "...it is important
to make a distinction between fields which are used at the service path
layer to identify the Service Path Segment, and additional fields which
carry metadata which is imposed and interpreted at the service function
layer. Combining both types of fields into a single header should
probably be avoided from a layering point of view. "</t>
<t>Segment Routing (SR) <xref
target="I-D.filsfils-spring-segment-routing"/> is a source routing
paradigm which can be used to steer traffic through an ordered set of
routers. SR can be applied to the MPLS data plane <xref
target="I-D.gredler-spring-mpls"/> <xref
target="I-D.filsfils-spring-segment-routing-mpls"/>and the IPv6 data
plane <xref target="I-D.previdi-6man-segment-routing-header"/>.</t>
<t>This document describes a particular use case for SPRING where the SR
mechanism is leveraged to realize the service path layer functionality
of the SFC (i.e, steering traffic through the service function
path).</t>
<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.filsfils-spring-segment-routing"/> and <xref
target="I-D.quinn-sfc-arch"/>.</t>
</section>
<section anchor="Advertising" title="SFC Use Case">
<t><figure>
<artwork align="center"><![CDATA[ +----------------------------------------------- ----+
| SR Netowrks |
| +---------+ +---------+ |
| | +-----+ | | +-----+ | |
| (1) | | SF1 | | (2) | | SF2 | | (3) |
+----+-----+ ---> | +-----+ | ----> | +-----+ | ---> +---+---+
|Classifier+------+ SN1 +-------+ SN2 +-------+ D |
+----------+ +---------+ +---------+ +---+---+
| |
+----------------------------------------------------+
Figure 1: Service Function Chaining in SR Networks]]></artwork>
</figure>As shown in Figure 1, assume SN1 and SN2 are two SR-capable
nodes meanwhile they are service nodes which offer service function SF1
and SF2 respectively. In addition, they have allocated and advertised
segment IDs (SID) for the service functions they are offering. For
example, SN1 allocates and advertises an SID, i.e., SID(SF1) for service
function SF1 while SN2 allocates and advertises an SID, i.e., SID(SF2)
for service function SF2. These SIDs which are used to indicate service
functions are referred to as Service Function SIDs. In addition, assume
the node SIDs for SN1 and SN2 are SID(SN1) and SID(SN2)
respectively.</t>
<t>How to steer a packet through a service fucntion path in both MPLS-SR
and IPv6-SR cases is illustrated in the following two sub-sections
respectively.</t>
<section title="SFC in MPLS-SR Case">
<t>In the MPLS-SR case, those service function SIDs as mentioned above
would be interpreted as local MPLS labels. Meanwhile, to simplify the
illustrationIn in this document, those node SIDs as mentioned above
would be interpreted as MPLS global labels.</t>
<t>Now assume a given packet destined for destination D is required to
go through a service function chain {SF1, SF2} before reaching its
final destination D. The service classifier therefore would attach a
segment list {SID(SN1), SID(SF1), SID(SN2), SID(SF2)} to the packet.
This segment list is actually represented by a MPLS label stack. In
addition, the service classifier could optionally impose metadata on
the packet through the Network Service Header (NSH) <xref
target="I-D.quinn-sfc-nsh"/>. 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 2 since there are two service nodes within the service
function path. How to impose the NSH on a MPLS packet is outside the
scope of this document. When the encapsulated packet arrives at SN1,
SN1 would know which service function should be performed according to
SID (SF1). If a NSH is carried in that packet, SN1 could further
consume the metadata contained in the NSH and meanwhile decrease the
service index value within the NSH by one. When the encapsualted
packet arrives at SN2, SN2 would do the similar action as what has
been done by SN1. Furthermore, since SN2 is the last service node
within the service function path, SN2 MUST strip the NSH (if it has
been imposed) before sending the packet to D.</t>
</section>
<section title="SFC in IPv6-SR Case">
<t>In the IPv6-SR case, those service function SIDs as mentioned above
would be interpreted as IPv6 link-local addresses while those node
SIDs as mentioned above would be interpreted as IPv6 global unicast
addresses.</t>
<t>Now assume a given IPv6 packet destined for destination D is
required to go through a service function chain {SF1, SF2} before
reaching its final destination D. The service classifier therefore
would attach a SR header containing a segment list {SID(SF1),
SID(SN2),SID(SF2),SID(D)} to the IPv6 packet. This segment list is
actually represented by an ordered list of IPv6 addresses. The IPv6
destination address is filled with SID(SN1). In addition, the service
classifier could optionally impose metadata on the above IPv6 packet
through the NSH and meanwhile carry the original IPv6 source address
in the Original Source Address field of the packet. When the above
IPv6 packet arrives at SN1, SN1 would know which service function
should be performed according to SID (SF1). If a NSH is carried in
that packet, SN1 could further consume the metadata contained in the
NSH and meanwhile decrease the service index value within the NSH by
one. When the packet arrives at SN2, SN2 would do the similar action
as what has been done by SN1. Furthermore, since SN2 is the second
last node in the segment list, SN2 should strip the SR header and
meanwhile fill in the IPv6 source address with the Original Source
Address (if available) before sending the packet towards D. Besides,
since SN2 is the last service node within the service path, SN2 MUST
strip the NSH (if it has been imposed) before sending the packet to
D.</t>
</section>
</section>
<!---->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBD.</t>
<!---->
</section>
<section anchor="IANA" title="IANA Considerations">
<t>TBD.</t>
<!---->
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not introduce any new security risk.</t>
<!---->
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
<?rfc include="reference.I-D.rijsman-sfc-metadata-considerations"?>
<?rfc include="reference.I-D.quinn-sfc-arch"?>
<?rfc include="reference.I-D.previdi-6man-segment-routing-header"?>
<?rfc include="reference.I-D.gredler-spring-mpls"?>
<?rfc include="reference.I-D.filsfils-spring-segment-routing-mpls"?>
<?rfc include="reference.I-D.quinn-sfc-nsh"?>
<!---->
</references>
<references title="Informative References">
<!---->
<?rfc include="reference.I-D.filsfils-spring-segment-routing"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:30:23 |