PCEP Extensions for traffic
steering support in Service Function ChainingHuawei101 Software Avenue, Yuhua DistrictNanjingJiangsu210012Chinasunseawq@huawei.comHuaweiLeela PalaceBangaloreKarnataka560008INDIAdhruv.ietf@gmail.com
Routing Area
PCE Working GroupRFCRequest for CommentsI-DInternet-DraftPCEThis 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.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).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 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). 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). specifies extensions
to PCEP to enable stateful control of MPLS TE LSPs.
provides the
fundamental extensions needed for stateful PCE-initiated LSP
instantiation.This document specifies extensions to the PCEP that allow a stateful PCE to
compute and instantiate Service Function Paths (SFP).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 RFC2119.The following terminologies are used in this document:Path Computation Client.Path Computation Element.Path Computation Element Protocol.Policy Decision Point.Service Function.Service Function Chain.Service Function Path.User-Network Interface.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.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 .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.Stateful pce specifies a set of
extensions to PCEP to enable stateful control of TE LSPs.
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.A Policy Decision Point (PDP) is the central
entity which is responsible for maintaining SFC Policy Tables and
enforcing appropriate policies in SF Nodes described in detail in
. 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.A PCEP speaker indicates its ability to support PCE initiated dynamic
SFP during the PCEP Initialization Phase via mechanism described
in .As per section 5.1 of
, 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 .The Instantiation operation of SFP is same as defined in section 5.3 of
. Rules of processing and
error codes remains unchanged.The deletion operation of SFP is same as defined in section 5.4 of
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 ). Rules of processing and
error codes remains unchanged.SFP delegation and cleanup operations are same as defined in section 6 of
. Rules of processing and
error codes remains unchanged.State Synchronization operations described in Section 5.4 of
and can be applied
for SFPs as well.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
and can be applied
for SFPs as well.This document defines a new optional TLV for use in the OPEN Object
to indicate the PCEP speaker's capability for Service function Chaining.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:The code point for the TLV type is to be defined by IANA. The TLV
length is 4 octets.The value is TBD.As per ,
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.The LSP object is defined in and included
here for easy reference.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.The SFP Identifiers TLV MUST be included in the LSP object for Service Function Paths (SFP).The format and operations are TBD.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
. 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.[Editor Note: more information on exact error value is needed]The security considerations described in and
are applicable to this specification.
No additional security measure is required.TBD