One document matched: draft-wu-pce-traffic-steering-sfc-00.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-00"
ipr="trust200902" obsoletes="" updates="" submissionType="IETF" 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 initials="D" surname="Dhody" fullname="Dhruv 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>
<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.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"/> 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.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="" height="" suppress-title="false"
title="SFP instantiation vis PCE" width="" anchor="SEC_FIG1">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"> <![CDATA[
+---------------------------------+
|+------+ +------+ PDP |
|| | | | |
|| | | | |
||PCE | |Policy| |
|*------+ +------+ |
*---------------------------------+
/
/
/ SFP
/ Instan-
/ tiation
/
/
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"/> 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"/>.</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"/>.</t>
<section title="SFP Instantiation" toc="default" anchor="SEC_INST">
<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 title="The OPEN Object" anchor="SEC_CA">
<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="" height="" suppress-title="true"
title="" width="" anchor="SEC_FIG2">
<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 title="The LSP Object" anchor="SEC_LSP">
<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="" height="" suppress-title="true"
title="" width="" anchor="SEC_FIG3">
<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"/>. 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"/> 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:47:12 |