One document matched: draft-wu-pce-traffic-steering-sfc-02.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-02"
ipr="trust200902" obsoletes="" submissionType="IETF" updates=""
xml:lang="en">
<front>
<title abbrev="PCEP for SFC">PCEP Extensions for traffic steering support
in Service Function Chaining</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>sunseawq@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>France Telecom </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="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street>Rennes 35000</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 month="February" year="2014" />
<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) with Service Function Chaining (SFC); which is described
as the definition and instantiation of an ordered set of such service
functions (such as firewalls, load balancers), and the subsequent
"steering" of traffic flows through those service functions.</t>
<t>Further this document specifies extensions to the Path Computation
Element Protocol (PCEP) that allow a stateful PCE to compute and
instantiate Service Function Paths (SFP).</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Service chaining enables creation of composite services that consist
of an ordered set of Service Functions (SF) that must be applied to
packets and/or frames selected as a result of classification as
described in <xref target="I-D.boucadair-sfc-framework"></xref><xref
target="I-D.quinn-sfc-arch"></xref> and referred to as Service Function
Chain (SFC). Service Function Path (SFP) is the instantiation of a SFC
in the network. Packets follow a Service Function Path from a classifier
through the requisite Service Functions (SF).</t>
<t><xref target="RFC5440"></xref> describes the Path Computation Element
Protocol (PCEP) as the communication between a Path Computation Client
(PCC) and a Path Control Element (PCE), or between PCE and PCE, enabling
computation of Multiprotocol Label Switching (MPLS) for Traffic
Engineering Label Switched Path (TE LSP).</t>
<t><xref target="I-D.ietf-pce-stateful-pce"></xref> specifies extensions
to PCEP to enable stateful control of MPLS TE LSPs. <xref
target="I-D.ietf-pce-pce-initiated-lsp"></xref> provides the fundamental
extensions needed for stateful PCE-initiated LSP instantiation.</t>
<t>This document specifies extensions to the PCEP that allow a stateful
PCE to compute and instantiate 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>The following terminologies are used in this document:</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="UNI:">User-Network Interface.</t>
</list></t>
</section>
<section title="Service Function Paths and PCE">
<t>Services are constructed as a sequence of SFs that represent an SFC,
where SF can be a virtual instance or be embedded in a physical network
element, and one or more SFs may be deployed within the same physical
network element. 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 instantiated into the network it is necessary to
select the specific instances of SFs that will be used, and to create
the service topology for that SFC using SF's network locator. Thus,
instantiation of the SFC results in the creation of a Service Function
Path (SFP) and is used for forwarding packets through the SFC. In other
words, an SFP is the instantiation of the defined SFC as described in
details in <xref target="I-D.boucadair-sfc-framework"></xref><xref
target="I-D.quinn-sfc-arch"></xref>.</t>
<t>The selection of SFP can be based on a range of policy attributes,
ranging from simple to more elaborate criteria and stateful PCE with
extensions to PCEP are one such way to achieve this.</t>
<t>Stateful pce <xref target="I-D.ietf-pce-stateful-pce"></xref>
specifies a set of extensions to PCEP to enable stateful control of TE
LSPs. <xref target="I-D.ietf-pce-pce-initiated-lsp"></xref> provides the
fundamental motivations and extensions needed for stateful PCE-initiated
LSP instantiation. This document specifies extensions that allow a
stateful PCE to compute and instantiate Service Function Paths (SFP) via
PCEP.</t>
<figure align="left" alt="" anchor="SEC_FIG1" height=""
suppress-title="false" title="SFP instantiation vis PCE"
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
+---------------------------------+
|+------+ +------+ PDP |
|| | | | |
|| | | | |
||PCE | |Policy| |
|*------+ +------+ |
*---------------------------------+
/
/
/ SFP
/ Instan-
/ tiation
/ SF Node1 SF Node2
/ +-------+ +-------+
V | | | |
+-----+ Signaling |+-----+| Signaling |+-----+| Signaling +-----+
|SF-In|----------->||SF-1 || --------->||SF-2 ||----------->|SF-E |
|gress| || || || || |gress|
+-----+ |+-----+| |+-----+| +-----+
+-------+ +-------+
</artwork>
</figure>
<t>A Policy Decision Point (PDP) <xref target="RFC2753"></xref> is the
central entity which is responsible for maintaining SFC Policy Tables
and enforcing appropriate policies in SF Nodes described in detail in
<xref target="I-D.boucadair-sfc-framework"></xref>. A PDP may further
use stateful PCE and its instantiation mechanism to compute and
instantiate Service Function Paths (SFP). The PCE maybe co-located with
the PDP or 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 initiated dynamic
SFP during the PCEP Initialization Phase via mechanism described in
<xref target="SEC_CA"></xref>.</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. This document makes no change to the
PCInitiate message format but extends LSP objects described in <xref
target="SEC_LSP"></xref>.</t>
<section anchor="SEC_INST" title="SFP Instantiation" toc="default">
<t>The Instantiation operation of SFP is same as defined in section
5.3 of <xref target="I-D.ietf-pce-pce-initiated-lsp"></xref>. Rules of
processing and error codes remains unchanged.</t>
</section>
<section title="SFP Deletion" toc="default">
<t>The deletion operation of SFP is same as defined in section 5.4 of
<xref target="I-D.ietf-pce-pce-initiated-lsp"></xref> by sending an
LSP Initiate Message with an LSP object carrying the PLSP-ID of the
SFP to be removed and 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 of processing
and error codes remains unchanged.</t>
</section>
<section title="SFP Delegation and Cleanup" toc="default">
<t>SFP delegation and cleanup operations are same as defined in
section 6 of <xref target="I-D.ietf-pce-pce-initiated-lsp"></xref>.
Rules of processing and error codes remains 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> and can be applied for SFPs
as well.</t>
</section>
<section title="SFP Update and Report" toc="default">
<t>PCE can make an SFP Update requests to a PCC to update one or more
attributes of an SFP and to re-signal the SFP with updated attributes.
PCC can make an SFP state report to a PCE to send SFP state. The
mechanism are described in <xref
target="I-D.ietf-pce-stateful-pce"></xref> and can be applied for SFPs
as well.</t>
</section>
</section>
<section title="Object Formats">
<section anchor="SEC_CA" title="The OPEN Object">
<t>This document defines a new optional TLV for use in the OPEN Object
to indicate the PCEP speaker's capability for Service function
Chaining.</t>
<t>The SFC-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN
Object to advertise the SFC capability on the PCEP session. The format
of the SFC-PCE-CAPABILITY TLV is shown in the following figure:</t>
<figure align="left" alt="" anchor="SEC_FIG2" height=""
suppress-title="true" title="" 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. The TLV
length is 4 octets.</t>
<t>The value is TBD.</t>
<t>As per <xref target="I-D.ietf-pce-stateful-pce"></xref>, PCEP
speaker advertises capability for instantiation of PCE-initiated LSPs
via Stateful PCE Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) in
open message. The inclusion of SFC-PCE-CAPABILITY TLV in an OPEN
object indicates that the sender is SFC capable. These mechanism when
used together indicates the instantiation capability for SFP by 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
easy reference.</t>
<figure align="left" alt="" anchor="SEC_FIG3" height=""
suppress-title="true" title="" 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, the SFC (F) flag is introduced. The F Flag set to 1 to
indicate that this 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
Service Function Paths (SFP).</t>
<t>The format and operations are TBD.</t>
</section>
</section>
</section>
<section title="Backward Compatibility">
<t>The PCEP protocol extensions described in this document for PCEP
speaker with instantiation capability for SFPs MUST NOT be used if PCC
or PCE has not advertised its stateful capability with Instantiation and
SFC capability as per <xref target="SEC_CA"></xref>. If this is not the
case and Stateful operations on SFPs are attempted, then a PCErr with
error-type 19 (Invalid Operation) and error-value TBD needs to be
generated.</t>
<t>[Editor Note: more information on exact error value is needed]</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. No additional security measure is required.</t>
</section>
<section title="IANA Considerations">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.I-D.ietf-pce-stateful-pce"?>
<?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2753.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.I-D.quinn-sfc-arch"?>
<?rfc include="reference.I-D.boucadair-sfc-framework"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:44:23 |