PCEP Extensions for Service Function Chaining
(SFC)Huawei101 Software Avenue, Yuhua DistrictNanjingJiangsu210012Chinabill.wu@huawei.comHuaweiLeela PalaceBangaloreKarnataka560008INDIAdhruv.ietf@gmail.comOrangeRennes 35000Francemohamed.boucadair@orange.comOrangeRennesFrancechristian.jacquenet@orange.com2330 Central ExpresswaySanta ClaraCA95050USjefftant.ietf@gmail.com
Routing Area
PCE Working GroupRFCRequest for CommentsI-DInternet-DraftPCEThis 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.This document specifies extensions to the Path Computation Element
Protocol (PCEP) that allow a stateful PCE to compute and instantiate
Service Function Paths.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 . 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. 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. specifies extensions to
PCEP to enable a stateful control of MPLS TE LSPs. provides the extensions needed
for stateful PCE-initiated LSP instantiation.This document specifies PCEP extensions that allow a stateful PCE to
compute and instantiate traffic-engineered 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.This document makes use of these acronyms:Path Computation Client.Path Computation Element.Path Computation Element Protocol.Policy Decision Point.Service Function.Service Function Chain.Service Function Path.Rendered Service Path.Service Function Forwarder.User-Network Interface.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.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 .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.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.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.A PCEP speaker indicates its ability to support PCE-computed SFP
paths during the PCEP Initialization phase via a mechanism described in
. 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.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. 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 .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?To prevent multiple classifiers assign the same SFP ID to one Service
Function Path(SFP ID assignment conflict),in this document, we assume
SFP ID can be predetermined and assigned by stateful PCE when stateful
PCE can be used to compute traffic-engineered SFPs.The instantiation of a SFP is the same as defined in Section 5.3 of
. Rules for processing
and error codes remain unchanged.The withdrawal of an SFP is the same as defined in Section 5.4 of
: 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 ). Rules for processing and
error codes remain unchanged.SFP delegation and cleanup operations are similar to those defined
in Section 6 of . Rules
for processing and error codes remain unchanged.State Synchronization operations described in Section 5.4 of can be applied to SFP state
maintenance as well.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
and can be applied to SFPs
as well.The optional TLV shown in is defined for
use in the OPEN Object to indicate the PCEP speaker's Service Function
Chaining capability.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.The code point for the TLV type is to be defined by IANA (see ). The TLV length is 4 octets.As per , 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.The LSP object is defined in and included here for
reference ().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.As described in section 4, SFP ID is predetermined and assigned
by stateful PCE. 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 . 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.The format of the SFP Identifier TLV is shown in .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. SI: provides location
within the service path.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,. 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.[Editor's note: more information on exact error value is needed]The PCE-initiated SFP instantiation signaling described in this
document is exchanged between PCE server and SFC Classifier and does not
assume any specific mechanism to exchange SFP information(e.g.,path
identification information,metadata )
between SFFs or between SFF and SF, or between the controller and SFF
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 to exchange SFP information
between SFFs or rely upon the use of BGP Control plane defined in to exchange SFP
information between the Controller and SFF.Likewise, 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 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.The security considerations described in and
are applicable to this
specification. This document does not raise any additional security
issue.IANA is requested to allocate a new code point in the PCEP TLV Type
Indicators registry, as follows:Many thanks to Ron Parker, Hao Wang, Dave Dolson, Jing Huang, and
Joel M. Halpern for the discussion about the content for the
document.