One document matched: draft-wu-pce-traffic-steering-sfc-09.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-09"
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/>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>US</country>
</postal>
<email>jefftant.ietf@gmail.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"/>. 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"/> 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"/> specifies extensions to
PCEP to enable a stateful control of MPLS TE LSPs. <xref
target="I-D.ietf-pce-pce-initiated-lsp"/> 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"/>.</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"> SFC Control Plane
+------------------------+
|PCE based Controller |
I2 | +-------++-------+ |
+------------- |Policy || TE-DB | |
| I1 | +-------++-------+ <----+
| +----------| +-------------+ | |
| |SFP | |LSP-DB/SFP-DB| | |I2
| |Instan- | +-------------+ | |
| |tiation +-----------^------------+ |policy-provisioning
| |PCEP | |information/
| |Signaling I2 | |Carried by NETCONF,
| | | |BGP, for example
| | | |
| | | |
| | +------V+ +----+--+
V V | | | |
+-----+ Forwarding| | Forwarding| | Forwarding
| SFC |----------->| SFF-1 | --------->| SFF-2 |----------->
Classifier | | | |
| | | | | |
+-----+ ++-----++ +-----+-+
| | |
+--+--+ ++----+ +--+--+
|SF-1 | |SF-2 | |SF-3 |
| | | | | |
+--+--+ +---+-+ +--+--+
|I2 |I2 |I2
V V V</artwork>
</figure>
<t>In Figure 1, the PCE-based Controller [I-D.ietf-teas-pce-central-
control] in the SFC Control plane is responsible for computing the path
for a given service function chain. This PCE-based controller can
operate as a stateful PCE ([I-D.draft_ietf-stateful-pce]) that will
provide a classifier (a headend from a PCE standpoint) with the
PCEP-formatted information to instantiate a given SFP. As a consequence,
the PCE-based controller derives the set of policy-provisioning
information (namely SFP configuration information and traffic
classification rules) that will be provided to the various elements
(Classifier, SFF) involved in the establishment of the SFP. </t>
<t>By doing so, SFC Classifier can bind a flow to a service function
chain and forward such flow along the corresponding SFP. The SFC Control
Plane [I-D.ietf-sfc-control-plane] is also responsible for defining the
appropriate policies (traffic classification, forwarding and routing,
etc.) that will be enforced by SFC Classifiers,SFF Nodes and SF Nodes,
as described in [RFC7665]. From that standpoint, the SFC Control Plane
embeds a Policy Decision Point that is responsible for defining the SFC
policies. SFC policies will be provided by the PDP and enforced by SFC
components like classifiers and SFFs by means of policy-provision
information. A protocol like NETCONF, BGP can be used to carry such
policy-provisioning information. </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"/>. 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"/>, 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"/>.</t>
<t>Editor's note: In case a PCE-Initiated signaling mechanism is used to
set up the service function path, does the classifier / PCE-Initiated
signaling protocol need to understand whether an IP address is assigned
to a SFF or a 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"/>. 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"/>: 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"/>). 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"/>. 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"/> 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"/> 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"/> 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">
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"/>). The TLV length is 4 octets.</t>
<t>As per <xref target="I-D.ietf-pce-stateful-pce"/>, 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"/> and included here for
reference (<xref target="SEC_FIG3"/>).</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">
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"/>. 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"/>.<figure anchor="sfpid">
<artwork> 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 Instantiation Signaling and Forwarding Considerations">
<t>The PCE-initiated SFP instantiation signaling described in this
document does not assume any specific mechanism to exchange SFP
information(e.g.,path identification information,metadata<xref
target="I-D.ietf-sfc-nsh"/>) and establish SFP in the data plane
throughout a SFC domain. For example, such mechanism can rely upon the
use of the SFC Encapsulation defined in <xref
target="I-D.ietf-sfc-nsh"/>. Likewise, <xref
target="I-D.ietf-teas-pce-central-control"/> can use the signaling
mechanism described in this draft to enforce SFC-inferred traffic
engineering policies and provide load balancing between service function
nodes. The approach that relies upon the Segment Routing technique <xref
target="I-D.ietf-pce-segment-routing"/> can also take advantage of the
signaling mechanism described in this document to support Service Path
instantiation, which does not require any additional specific extension
to the Segment Routing machinery.</t>
</section>
<section title="Security Considerations">
<t>The security considerations described in <xref target="RFC5440"/> and
<xref target="I-D.ietf-pce-pce-initiated-lsp"/> 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> Value Meaning Reference
------- ---------------------------- --------------
TBD SFC-PCE-CAPABILITY This document</artwork>
</figure></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 about 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"?>
<?rfc include="reference.I-D.ietf-teas-pce-central-control"?>
</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:47:03 |