One document matched: draft-wu-pce-traffic-steering-sfc-08.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-wu-pce-traffic-steering-sfc-08"
ipr="trust200902" obsoletes="" submissionType="IETF" updates=""
xml:lang="en">
<front>
<title abbrev="PCEP for SFC">PCEP Extensions for Service Function Chaining
(SFC)</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>bill.wu@huawei.com</email>
</address>
</author>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody">
<organization>Huawei</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization>
<address>
<postal>
<street>Rennes 35000</street>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
<organization>Orange</organization>
<address>
<postal>
<street>Rennes</street>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
<organization>Ericsson</organization>
<address>
<postal>
<street>300 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<email>Jeff.Tantsura@ericsson.com</email>
</address>
</author>
<date year="2016" />
<area>Routing Area</area>
<workgroup>PCE Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>PCE</keyword>
<abstract>
<t>This document provides an overview of the usage of Path Computation
Element (PCE) to dynamically structure service function chains. Service
Function Chaining (SFC) is a technique that is meant to facilitate the
dynamic enforcement of differentiated traffic forwarding policies within
a domain. Service function chains are composed of an ordered set of
elementary Service Functions (such as firewalls, load balancers) that
need to be invoked according to the design of a given service.
Corresponding traffic is thus forwarded along a Service Function Path
(SFP) that can be computed by means of PCE.</t>
<t>This document specifies extensions to the Path Computation Element
Protocol (PCEP) that allow a stateful PCE to compute and instantiate
Service Function Paths.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Service Function Chaining (SFC) enables the creation of composite
services that consist of an ordered set of Service Functions (SF) that
must be applied to packets and/or frames and/or flows selected as a
result of service-inferred traffic classification as described in <xref
target="RFC7665"></xref>. A Service Function Path (SFP) is a path along
which traffic that is bound to a specific service function chain will be
forwarded. Packets typically follow a Service Function Path from a
classifier through the Service Functions (SF) that need to be invoked
according to the SFC instructions. Forwarding decisions are made by
Service Function Forwarders (SFF) according to such instructions.</t>
<t><xref target="RFC5440"></xref> describes the Path Computation Element
Protocol (PCEP) as the protocol used by a Path Computation Client (PCC)
and a Path Control Element (PCE) to exchange information, thereby
enabling the computation of Multiprotocol Label Switching (MPLS) for
Traffic Engineering Label Switched Path (TE LSP), in particular.</t>
<t><xref target="I-D.ietf-pce-stateful-pce"></xref> specifies extensions
to PCEP to enable a stateful control of MPLS TE LSPs. <xref
target="I-D.ietf-pce-pce-initiated-lsp"></xref> provides the extensions
needed for stateful PCE-initiated LSP instantiation.</t>
<t>This document specifies PCEP extensions that allow a stateful PCE to
compute and instantiate traffic-engineered Service Function Paths
(SFP).</t>
</section>
<section title="Conventions used in this document">
<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">RFC2119</xref>.</t>
<t>This document makes use of these acronyms:</t>
<t><list style="hanging">
<t hangText="PCC:">Path Computation Client.</t>
<t hangText="PCE:">Path Computation Element.</t>
<t hangText="PCEP:">Path Computation Element Protocol.</t>
<t hangText="PDP:">Policy Decision Point.</t>
<t hangText="SF:">Service Function.</t>
<t hangText="SFC:">Service Function Chain.</t>
<t hangText="SFP:">Service Function Path.</t>
<t hangText="RSP:">Rendered Service Path.</t>
<t hangText="SFF:">Service Function Forwarder.</t>
<t hangText="UNI:">User-Network Interface.</t>
</list></t>
</section>
<section title="Service Function Paths and PCE">
<t>Service function chains are constructed as a sequence of SFs, where a
SF can be virtualized or embedded in a physical network element. One or
several SFs may be supported by the same physical network element. A SFC
creates an abstracted view of a service and specifies the set of
required SFs as well as the order in which they must be executed.</t>
<t>When an SFC is created, it is necessary to select the specific
instances of SFs that will be used. A service function path for that SFC
will then be established (notion of rendered service path) or can be
precomputed, based upon the sequence of SFs that need to be invoked by
the corresponding traffic, i.e., the traffic that is bound to the
corresponding SFC. Note that a SF instance can be serviced by one or
multiple SFFs. One or multiple SF instances can be serviced by one SFF.
Thus, the instantiation of an SFC results in the establishment of a
Service Function Path, either in a hop-by-hop fashion, or by means of
traffic-engineering capabilities. In the latter case, the SFP is
precomputed, i.e., an SFP is an instantiation of the defined SFC as
described in <xref target="RFC7665"></xref>.</t>
<t>The computation, the selection, and the establishment of a
traffic-engineered SFP can rely upon a set of (service-specific)
policies (forwarding and routing, QoS, security, etc., or a combination
thereof). Stateful PCE with appropriate SFC-aware PCEP extensions can be
used to compute traffic-engineered SFPs.</t>
<figure align="left" alt="" anchor="SEC_FIG1" height=""
suppress-title="false" title="PCE-based SFP instantiation"
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[ SFC Control Element
+------------------------+
| stateful PCE |
| +-------+ +-------+ |
| |Policy | | TE-DB | |
| +-------+ +-------+ |
+----------| +-------------+ |
|SFP | |LSP-DB/SFP-DB| |
|Instan- | +-------------+ |
|tiation +------------------------+
| +-----+ +-----+ +-----+
| |SF-1 | |SF-2 | |SF-3 |
| | | | | | |
| +---+-+ +-+---+ +--+--+
| | | |
| ++-----++ +----+--+
V | | | |
+-----+ Signaling | | Signaling | | Signaling
| SFC |----------->| SFF-1 | --------->| SFF-2 |----------->
Classifier | | | |
| | | | | |
+-----+ +-------+ +-------+ ]]></artwork>
</figure>
<t>The SFC Control Element <xref
target="I-D.ietf-sfc-control-plane"></xref> is responsible for defining
service instructions to bind a flow to a service function chain and
forward such flow along the corresponding SFP. It is also responsible
for defining the appropriate policies (traffic classification,
forwarding and routing, etc.) that will be enforced by SFC Classifiers
and SFF Nodes as described in <xref target="RFC7665"></xref>. The SFC
Control Element can be seen as a Policy Decision Point (PDP, <xref
target="RFC5394"></xref>). Such PDP can then operate a stateful PCE to
compute, select and establish Service Function Paths. The PCE may be
co-located with the SFC Control element or enabled in an external
entity.</t>
</section>
<section title="Overview of PCEP Operation in SFC-Enabled Networks">
<t>A PCEP speaker indicates its ability to support PCE-computed SFP
paths during the PCEP Initialization phase via a mechanism described in
<xref target="SEC_CA"></xref>. A PCE may initiate SFPs only for PCCs
that advertised this capability; a PCC follows the procedures described
in this document only for sessions where the PCE advertised this
capability.</t>
<t>As per Section 5.1 of <xref
target="I-D.ietf-pce-pce-initiated-lsp"></xref>, the PCE sends a Path
Computation LSP Initiate Request (PCInitiate) message to the PCC to
instantiate or delete a LSP. The Explicit Route Object (ERO) is used to
encode either a full sequence of SF instances or a specific sequence of
SFFs and SFs to establish an SFP. If the said SFFs and SFs are
identified with an IP address, the IP sub-object can be used as a SF/SFF
identification means. This document makes no change to the PCInitiate
message format but extends LSP objects described in <xref
target="SEC_LSP"></xref>.</t>
<t>Editor's note: In case a PCE-Initiated signaling mechanism is used to
set up the service function path, then does the classifier /
PCE-Initiated signaling protocol need to understand if the IP address is
for SFF or SF or the signaling protocol is only used to signal IP
addresses for SFs?</t>
<section anchor="SEC_INST" title="SFP Instantiation" toc="default">
<t>The instantiation of a SFP is the same as defined in Section 5.3 of
<xref target="I-D.ietf-pce-pce-initiated-lsp"></xref>. Rules for
processing and error codes remain unchanged.</t>
</section>
<section title="SFP Withdrawal" toc="default">
<t>The withdrawal of an SFP is the same as defined in Section 5.4 of
<xref target="I-D.ietf-pce-pce-initiated-lsp"></xref>: the PCE sends
an LSP Initiate Message with an LSP object carrying the PLSP-ID of the
SFP and the SFP Identifier to be removed, as well as an SRP object
with the R flag set (LSP-REMOVE as per Section 5.2 of <xref
target="I-D.ietf-pce-pce-initiated-lsp"></xref>). Rules for processing
and error codes remain unchanged.</t>
</section>
<section title="SFP Delegation and Cleanup" toc="default">
<t>SFP delegation and cleanup operations are similar to those defined
in Section 6 of <xref target="I-D.ietf-pce-pce-initiated-lsp"></xref>.
Rules for processing and error codes remain unchanged.</t>
</section>
<section title="SFP State Synchronization" toc="default">
<t>State Synchronization operations described in Section 5.4 of <xref
target="I-D.ietf-pce-stateful-pce"></xref> can be applied to SFP state
maintenance as well.</t>
</section>
<section title="SFP Update and Report" toc="default">
<t>A PCE can send an SFP Update request to a PCC to update one or more
attributes of an SFP and to re-signal the SFP with the updated
attributes. A PCC can send an SFP state report to a PCE, and which
contains the SFP State information. The mechanism is described in
<xref target="I-D.ietf-pce-stateful-pce"></xref> and can be applied to
SFPs as well.</t>
</section>
</section>
<section title="Object Formats">
<section anchor="SEC_CA" title="The OPEN Object">
<t>The optional TLV shown in <xref target="SEC_FIG2"></xref> is
defined for use in the OPEN Object to indicate the PCEP speaker's
Service Function Chaining capability.</t>
<t>The SFC-PCE-CAPABILITY TLV is an optional TLV to be carried in the
OPEN Object to advertise the SFC capability during the PCEP
session.</t>
<figure align="left" alt="" anchor="SEC_FIG2" height=""
suppress-title="true" title="SFC-PCE-CAPABILITY TLV Format"
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The code point for the TLV type is to be defined by IANA (see <xref
target="iana"></xref>). The TLV length is 4 octets.</t>
<t>As per <xref target="I-D.ietf-pce-stateful-pce"></xref>, a PCEP
speaker advertises the capability of instantiating PCE-initiated LSPs
via the Stateful PCE Capability TLV (LSP-INSTANTIATION-CAPABILITY bit)
carried in an Open message. The inclusion of the SFC-PCE-CAPABILITY
TLV in an OPEN object indicates that the sender is SFC-capable. Both
mechanisms indicate the SFP instantiation capability of the PCEP
speaker.</t>
</section>
<section anchor="SEC_LSP" title="The LSP Object">
<t>The LSP object is defined in <xref
target="I-D.ietf-pce-pce-initiated-lsp"></xref> and included here for
reference (<xref target="SEC_FIG3"></xref>).</t>
<figure align="left" alt="" anchor="SEC_FIG3" height=""
suppress-title="true" title="LSP Object Format" width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID | Flags |F|C| O|A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>A new flag, called the SFC flag (F-bit), is introduced. The F-bit
set to "1" indicates that this LSP is actually an SFP. The C flag will
also be set to indicate it was created via a PCInitiate message.</t>
<section title="SFP Identifiers TLV">
<t>The SFP Identifiers TLV MUST be included in the LSP object for
SFPs. The SFP Identifier TLV is used by the classifier to select the
SFP along which some traffic will be forwarded, according to the
traffic classification rules applied by the classifier <xref
target="RFC7665"></xref>. The SFP Identifier is part of the SFC
metadata carried in packets and is used by the SFF to invoke service
functions and identify the next SFF.</t>
<t>The format of the SFP Identifier TLV is shown in <xref
target="sfpid"></xref>.<figure anchor="sfpid">
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Path ID (SPI): 24 bits
Service Index (SI): 8 bits]]></artwork>
</figure></t>
<t>SPI: identifies a service path. The same ID is used by the
participating nodes for path setup/selection. An administrator can
use the SPI for reporting and troubleshooting packets along a
specific path. SPI along with PLSP-ID is used by PCEP to identify
the Service Path. <vspace blankLines="1" />SI: provides location
within the service path.</t>
</section>
</section>
</section>
<section title="Backward Compatibility">
<t>The SFP instantiation capability defined as a PCEP extension and
documented in this draft MUST NOT be used if PCCs or the PCE did not
advertise their stateful SFP instantiation capability,<xref
target="SEC_CA"> </xref>. If this is not the case and stateful
operations on SFPs are attempted, then a PCErr message with error-type
19 (Invalid Operation) and error-value TBD needs to be generated.</t>
<t>[Editor's note: more information on exact error value is needed]</t>
</section>
<section title="SFP Signaling and Forwarding Considerations">
<t>The SFP instantiation mechanism described in this document is not
tightly coupled to any SFP signaling mechanism. For example, Generic SFC
Encapsulation <xref target="I-D.ietf-sfc-nsh"></xref> can be used
together with the mechanism described in this document to enable SFP
forwarding. SR-based approach <xref
target="I-D.ietf-pce-segment-routing"></xref> can also use the mechanism
described here and does not need any other specific protocol
extensions.</t>
</section>
<section title="Security Considerations">
<t>The security considerations described in <xref
target="RFC5440"></xref> and <xref
target="I-D.ietf-pce-pce-initiated-lsp"></xref> are applicable to this
specification. This document does not raise any additional security
issue.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t> IANA is requested to allocate a new code point in the PCEP TLV Type
Indicators registry, as follows:<figure>
<artwork><![CDATA[ Value Meaning Reference
------- ---------------------------- --------------
TBD SFC-PCE-CAPABILITY This document]]></artwork>
</figure></t>
<t></t>
</section>
<section title="Acknowledgements">
<t>Many thanks to Ron Parker, Hao Wang, Dave Dolson, Jing Huang, and
Joel M. Halpern for the discussion in formulating the content for the
document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.I-D.ietf-pce-stateful-pce"?>
<?rfc include="reference.RFC.5440" ?>
<?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2753" ?>
<?rfc include='reference.RFC.7665'?>
<?rfc include="reference.RFC.5394" ?>
<?rfc include="reference.I-D.ietf-sfc-control-plane"?>
<?rfc include="reference.I-D.ietf-pce-segment-routing"?>
<?rfc include="reference.I-D.ietf-sfc-nsh"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:42:42 |