One document matched: draft-wu-pce-traffic-steering-sfc-07.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-07"
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="Jacquenet">
<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 year="2015"/>
<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>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 the 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.ietf-sfc-architecture"/> and referred to
as Service Function Chain (SFC). A 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) and
Service Function Forwarders (SFF).</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"/> specifies extensions to
PCEP to enable stateful control of MPLS TE LSPs. <xref
target="I-D.ietf-pce-pce-initiated-lsp"/> 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="SFF:">Service Forwarder Function.</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 a SF can be a virtual instance or be embedded in a physical
network element, and one or more 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 instantiated into the network it is necessary to
select the specific instances of SFs that will be used, and to create
the service function path for that SFC using SF network locators. Thus,
the instantiation of a SFC results in the establishment of a Service
Function Path, either a la hop-by-hop through the ordered sequence of SF
functions, or in a pre-computed, traffic-engineered fashion. In other
words, an SFP is the instantiation of the defined SFC as described in
<xref target="I-D.ietf-sfc-architecture"/>.</t>
<t>The selection of SFP can be based on a set of policy attributes
(forwarding and routing, QoS, security, etc., or a combination thereof),
ranging from simple to more elaborate selection criteria and the use of
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"/> specifies a
set of extensions to PCEP to enable stateful control of TE LSPs. <xref
target="I-D.ietf-pce-pce-initiated-lsp"/> 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="PCE based SFP instantiation"
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve">
+------------------------+
| stateful PCE |
| +-------+ +-------+ |
| |Policy | | TE-DB | | +-------+
| +-------+ +-------+ | | SFC |
+----------| +-------------+ |<---|control|
|SFP | |LSP-DB/SFP-DB| | | plane |
|Instan- | +-------------+ | +-------+
|tiation +------------------------+
| +-----+ +-----+ +-----+
| |SF-1 | |SF-2 | |SF-3 |
| | | | | | |
| +---+-+ +-+---+ +--+--+
| | | |
| ++-----++ +----+--+
V | | | |
+-----+ Signaling | | Signaling | | Signaling
| SF |----------->| SFF-1 | --------->| SFF-2 |----------->
Classifier | | | |
|Node | | | | |
+-----+ +-------+ +-------+
</artwork>
</figure>
<t>SFC Control plane components are responsible for maintaining SFC
Policy Tables and enforcing appropriate policies in SF Classifier and
SFF Nodes as described in <xref
target="I-D.ietf-sfc-architecture"/><xref
target="I-D.ww-sfc-control-plane"/>. The SFC Control plane component can
be seen as a policy Decision point (PDP,<xref target="RFC5394"/>). Such
PDP can then operates a stateful PCE and its instantiation mechanism to
compute and instantiate Service Function Paths (SFP). The PCE maybe
co-located with the SFC Control plane component 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 provisioned
dynamic SFP paths during the PCEP Initialization phase via a mechanism
described in <xref target="SEC_CA"/>. A PCE can initiate SFPs only for
PCCs that advertised this capability and a PCC will follow the
procedures described in this document only on 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) can be used
to encode either a sequence of SF functions or a combination of SFs and
SFFs to establish a SFP. If the said SFFs and SFs can be 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-Note: In case a PCE-Initiated Signaling mechanism is used to
setup the service function path, then does the classifier /
PCE-Initiated signaling protocol needs to understand if the IP address
is for SFF or SF or the signaling protocol is only used to signal IP
address for SFs? </t>
<section anchor="SEC_INST" title="SFP Instantiation" toc="default">
<t>The Instantiation operation of a SFP is the same as defined in
section 5.3<xref target="I-D.ietf-pce-pce-initiated-lsp"/>. Rules of
processing and error codes remain unchanged.</t>
</section>
<section title="SFP Withdrawal" toc="default">
<t>The withdrawal operation of a 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 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"/>).
Rules of 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
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"/>can be applied for 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 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 Service function Chaining
capability.</t>
<t>The SFC-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN
Object to advertise the SFC capability during the PCEP session. The
format of the SFC-PCE-CAPABILITY TLV is shown in the following<xref
target="SEC_FIG2"/> :</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. The TLV
length is 4 octets.</t>
<t>The value is TBD.</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)
conveyed 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 (F) flag, is introduced. The F Flag 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
Service Function Paths (SFP). The SFP Identifier TLV is used by the
classifier to enable SFP selection for the traffic,i.e.,direct
traffic to specific SFP[I-D.ietf-sfc-architecture]. The SFP
Identifier carried in the SFC encapsulation can be further used by
SFF to select service functions and next SFF,e.g., enable a packet
that repeatedly arrives at the same SFF to get the correct services
provided each time it arrives, and to go to the correct next SFF
each time it arrives.</t>
<t>The format of SFP Identifier TLV is shown in the following
figure.<figure>
<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>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 in 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 PCEP protocol extensions described
in this document MUST NOT be used if PCCs or the PCE did not advertise
its SFP instantiation stateful 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="SFP signaling and forwarding consideration">
<t>The SFP instantiation mechanism described in this document is not
tightly coupled to any SFP signaling mechanism. For example,SR-based
approach [I-D.ietf-pce-segment-routing] can utilize the mechanism
described here and does not need any other specific protocol extensions.
Generic SFC Encapsulation [I-D.quinn-sfc-nsh] can also be used together
with the mechanism described here to enable SFP forwarding.</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. No additional security measure is required.</t>
</section>
<section title="IANA Considerations">
<t>TBD</t>
</section>
<section title="Acknowledgements">
<t>Many thanks to Ron Parker, Hao Wang,Dave Dolson,Jing Huang,Joel M.
Halpern for the discussion in formulating the content for the draft.</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.5394.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.I-D.ietf-sfc-architecture"?>
<?rfc include="reference.I-D.ww-sfc-control-plane"?>
<?rfc include="reference.I-D.ietf-pce-segment-routing"?>
<?rfc include="reference.I-D.quinn-sfc-nsh"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:42:43 |