< draft-wu-pce-traffic-steering-sfc-07.txt		draft-wu-pce-traffic-steering-sfc-08.txt >
	PCE Working Group Q. Wu		PCE Working Group Q. Wu
	Internet-Draft D. Dhody		Internet-Draft D. Dhody
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: January 1, 2016 M. Boucadair		Expires: September 8, 2016 M. Boucadair
	C. Jacquenet		C. Jacquenet
	France Telecom		Orange
	J. Tantsura		J. Tantsura
	Ericsson		Ericsson
	June 30, 2015		March 7, 2016
	PCEP Extensions for traffic steering support in Service Function		PCEP Extensions for Service Function Chaining (SFC)
	Chaining		draft-wu-pce-traffic-steering-sfc-08
	draft-wu-pce-traffic-steering-sfc-07
	Abstract		Abstract
	This document provides an overview of the usage of Path Computation		This document provides an overview of the usage of Path Computation
	Element (PCE) with Service Function Chaining (SFC); which is		Element (PCE) to dynamically structure service function chains.
	described as the definition and instantiation of an ordered set of		Service Function Chaining (SFC) is a technique that is meant to
	such service functions (such as firewalls, load balancers), and the		facilitate the dynamic enforcement of differentiated traffic
	subsequent "steering" of traffic flows through those service		forwarding policies within a domain. Service function chains are
	functions.		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		This document specifies extensions to the Path Computation Element
	Protocol (PCEP) that allow a stateful PCE to compute and instantiate		Protocol (PCEP) that allow a stateful PCE to compute and instantiate
	Service Function Paths (SFP).		Service Function Paths.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 1, 2016.		This Internet-Draft will expire on September 8, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions used in this document . . . . . . . . . . . . . . 3		2. Conventions used in this document . . . . . . . . . . . . . . 3
	3. Service Function Paths and PCE . . . . . . . . . . . . . . . 3		3. Service Function Paths and PCE . . . . . . . . . . . . . . . 4
	4. Overview of PCEP Operation in SFC-enabled Networks . . . . . 5		4. Overview of PCEP Operation in SFC-Enabled Networks . . . . . 5
	4.1. SFP Instantiation . . . . . . . . . . . . . . . . . . . . 6		4.1. SFP Instantiation . . . . . . . . . . . . . . . . . . . . 6
	4.2. SFP Withdrawal . . . . . . . . . . . . . . . . . . . . . 6		4.2. SFP Withdrawal . . . . . . . . . . . . . . . . . . . . . 6
	4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . 6		4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . 6
	4.4. SFP State Synchronization . . . . . . . . . . . . . . . . 6		4.4. SFP State Synchronization . . . . . . . . . . . . . . . . 6
	4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . 6		4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . 6
	5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7		5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7		5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7
	5.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . 7		5.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . 7
	5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 8		5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 8
	6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9		6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9
	7. SFP signaling and forwarding consideration . . . . . . . . . 9		7. SFP Signaling and Forwarding Considerations . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	11.1. Normative References . . . . . . . . . . . . . . . . . . 9		11.1. Normative References . . . . . . . . . . . . . . . . . . 10
	11.2. Informative References . . . . . . . . . . . . . . . . . 10		11.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Service chaining enables the creation of composite services that		Service Function Chaining (SFC) enables the creation of composite
	consist of an ordered set of Service Functions (SF) that must be		services that consist of an ordered set of Service Functions (SF)
	applied to packets and/or frames selected as a result of		that must be applied to packets and/or frames and/or flows selected
	classification as described in [I-D.ietf-sfc-architecture] and		as a result of service-inferred traffic classification as described
	referred to as Service Function Chain (SFC). A Service Function Path		in [RFC7665]. A Service Function Path (SFP) is a path along which
	(SFP) is the instantiation of a SFC in the network. Packets follow a		traffic that is bound to a specific service function chain will be
	Service Function Path from a classifier through the requisite Service		forwarded. Packets typically follow a Service Function Path from a
	Functions (SF) and Service Function Forwarders (SFF).		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.
	[RFC5440] describes the Path Computation Element Protocol (PCEP) as		[RFC5440] describes the Path Computation Element Protocol (PCEP) as
	the communication between a Path Computation Client (PCC) and a Path		the protocol used by a Path Computation Client (PCC) and a Path
	Control Element (PCE), or between PCE and PCE, enabling computation		Control Element (PCE) to exchange information, thereby enabling the
	of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label		computation of Multiprotocol Label Switching (MPLS) for Traffic
	Switched Path (TE LSP).		Engineering Label Switched Path (TE LSP), in particular.
	[I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable		[I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable a
	stateful control of MPLS TE LSPs. [I-D.ietf-pce-pce-initiated-lsp]		stateful control of MPLS TE LSPs. [I-D.ietf-pce-pce-initiated-lsp]
	provides the fundamental extensions needed for stateful PCE-initiated		provides the extensions needed for stateful PCE-initiated LSP
	LSP instantiation.		instantiation.
	This document specifies extensions to the PCEP that allow a stateful		This document specifies PCEP extensions that allow a stateful PCE to
	PCE to compute and instantiate Service Function Paths (SFP).		compute and instantiate traffic-engineered Service Function Paths
			(SFP).
	2. Conventions used in this document		2. Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119 [RFC2119].		document are to be interpreted as described in RFC2119 [RFC2119].
	The following terminologies are used in this document:		This document makes use of these acronyms:
	PCC: Path Computation Client.		PCC: Path Computation Client.
	PCE: Path Computation Element.		PCE: Path Computation Element.
	PCEP: Path Computation Element Protocol.		PCEP: Path Computation Element Protocol.
	PDP: Policy Decision Point.		PDP: Policy Decision Point.
	SF: Service Function.		SF: Service Function.
	SFC: Service Function Chain.		SFC: Service Function Chain.
	SFP: Service Function Path.		SFP: Service Function Path.
	SFF: Service Forwarder Function.		RSP: Rendered Service Path.
			SFF: Service Function Forwarder.
	UNI: User-Network Interface.		UNI: User-Network Interface.
	3. Service Function Paths and PCE		3. Service Function Paths and PCE
	Services are constructed as a sequence of SFs that represent an SFC,		Service function chains are constructed as a sequence of SFs, where a
	where a SF can be a virtual instance or be embedded in a physical		SF can be virtualized or embedded in a physical network element. One
	network element, and one or more SFs may be supported by the same		or several SFs may be supported by the same physical network element.
	physical network element. A SFC creates an abstracted view of a		A SFC creates an abstracted view of a service and specifies the set
	service and specifies the set of required SFs as well as the order in		of required SFs as well as the order in which they must be executed.
	which they must be executed.
	When an SFC is instantiated into the network it is necessary to		When an SFC is created, it is necessary to select the specific
	select the specific instances of SFs that will be used, and to create		instances of SFs that will be used. A service function path for that
	the service function path for that SFC using SF network locators.		SFC will then be established (notion of rendered service path) or can
	Thus, the instantiation of a SFC results in the establishment of a		be precomputed, based upon the sequence of SFs that need to be
	Service Function Path, either a la hop-by-hop through the ordered		invoked by the corresponding traffic, i.e., the traffic that is bound
	sequence of SF functions, or in a pre-computed, traffic-engineered		to the corresponding SFC. Note that a SF instance can be serviced by
	fashion. In other words, an SFP is the instantiation of the defined		one or multiple SFFs. One or multiple SF instances can be serviced
	SFC as described in [I-D.ietf-sfc-architecture].		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 [RFC7665].
	The selection of SFP can be based on a set of policy attributes		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		(forwarding and routing, QoS, security, etc., or a combination
	thereof), ranging from simple to more elaborate selection criteria		thereof). Stateful PCE with appropriate SFC-aware PCEP extensions
	and the use of stateful PCE with extensions to PCEP are one such way		can be used to compute traffic-engineered SFPs.
	to achieve this.
	Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of
	extensions to PCEP to enable stateful control of TE LSPs.
	[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.
			SFC Control Element
	+------------------------+		+------------------------+
	| stateful PCE |		| stateful PCE |
	| +-------+ +-------+ |		| +-------+ +-------+ |
	| |Policy | | TE-DB | | +-------+		| |Policy | | TE-DB | |
	| +-------+ +-------+ | | SFC |		| +-------+ +-------+ |
	+----------| +-------------+ |<---|control|		+----------| +-------------+ |
	|SFP | |LSP-DB/SFP-DB| | | plane |		|SFP | |LSP-DB/SFP-DB| |
	|Instan- | +-------------+ | +-------+		|Instan- | +-------------+ |
	|tiation +------------------------+		|tiation +------------------------+
	| +-----+ +-----+ +-----+		| +-----+ +-----+ +-----+
	| |SF-1 | |SF-2 | |SF-3 |		| |SF-1 | |SF-2 | |SF-3 |
	| | | | | | |		| | | | | | |
	| +---+-+ +-+---+ +--+--+		| +---+-+ +-+---+ +--+--+
	| | | |		| | | |
	| ++-----++ +----+--+		| ++-----++ +----+--+
	V | | | |		V | | | |
	+-----+ Signaling | | Signaling | | Signaling		+-----+ Signaling | | Signaling | | Signaling
	| SF |----------->| SFF-1 | --------->| SFF-2 |----------->		| SFC |----------->| SFF-1 | --------->| SFF-2 |----------->
	Classifier | | | |		Classifier | | | |
	|Node | | | | |		| | | | | |
	+-----+ +-------+ +-------+		+-----+ +-------+ +-------+
	Figure 1: PCE based SFP instantiation		Figure 1: PCE-based SFP instantiation
	SFC Control plane components are responsible for maintaining SFC		The SFC Control Element [I-D.ietf-sfc-control-plane] is responsible
	Policy Tables and enforcing appropriate policies in SF Classifier and		for defining service instructions to bind a flow to a service
	SFF Nodes as described in		function chain and forward such flow along the corresponding SFP. It
	[I-D.ietf-sfc-architecture][I-D.ww-sfc-control-plane]. The SFC		is also responsible for defining the appropriate policies (traffic
	Control plane component can be seen as a policy Decision point		classification, forwarding and routing, etc.) that will be enforced
	(PDP,[RFC5394]). Such PDP can then operates a stateful PCE and its		by SFC Classifiers and SFF Nodes as described in [RFC7665]. The SFC
	instantiation mechanism to compute and instantiate Service Function		Control Element can be seen as a Policy Decision Point (PDP,
	Paths (SFP). The PCE maybe co-located with the SFC Control plane		[RFC5394]). Such PDP can then operate a stateful PCE to compute,
	component or an external entity.		select and establish Service Function Paths. The PCE may be co-
			located with the SFC Control element or enabled in an external
			entity.
	4. Overview of PCEP Operation in SFC-enabled Networks		4. Overview of PCEP Operation in SFC-Enabled Networks
	A PCEP speaker indicates its ability to support PCE provisioned		A PCEP speaker indicates its ability to support PCE-computed SFP
	dynamic SFP paths during the PCEP Initialization phase via a		paths during the PCEP Initialization phase via a mechanism described
	mechanism described in Section 5.1. A PCE can initiate SFPs only for		in Section 5.1. A PCE may initiate SFPs only for PCCs that
	PCCs that advertised this capability and a PCC will follow the		advertised this capability; a PCC follows the procedures described in
	procedures described in this document only on sessions where the PCE		this document only for sessions where the PCE advertised this
	advertised this capability.		capability.
	As per section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends		As per Section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends
	a Path Computation LSP Initiate Request (PCInitiate) message to the		a Path Computation LSP Initiate Request (PCInitiate) message to the
	PCC to instantiate or delete a LSP. The Explicit Route Object (ERO)		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		is used to encode either a full sequence of SF instances or a
	combination of SFs and SFFs to establish a SFP. If the said SFFs and		specific sequence of SFFs and SFs to establish an SFP. If the said
	SFs can be identified with an IP address, the IP sub-object can be		SFFs and SFs are identified with an IP address, the IP sub-object can
	used as a SF/SFF identification means. This document makes no change		be used as a SF/SFF identification means. This document makes no
	to the PCInitiate message format but extends LSP objects described in		change to the PCInitiate message format but extends LSP objects
	Section 5.2.		described in Section 5.2.
	Editor-Note: In case a PCE-Initiated Signaling mechanism is used to		Editor's note: In case a PCE-Initiated signaling mechanism is used to
	setup the service function path, then does the classifier / PCE-		set up the service function path, then does the classifier / PCE-
	Initiated signaling protocol needs to understand if the IP address is		Initiated signaling protocol need to understand if the IP address is
	for SFF or SF or the signaling protocol is only used to signal IP		for SFF or SF or the signaling protocol is only used to signal IP
	address for SFs?		addresses for SFs?
	4.1. SFP Instantiation		4.1. SFP Instantiation
	The Instantiation operation of a SFP is the same as defined in		The instantiation of a SFP is the same as defined in Section 5.3 of
	section 5.3[I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and		[I-D.ietf-pce-pce-initiated-lsp]. Rules for processing and error
	error codes remain unchanged.		codes remain unchanged.
	4.2. SFP Withdrawal		4.2. SFP Withdrawal
	The withdrawal operation of a SFP is the same as defined in section		The withdrawal of an SFP is the same as defined in Section 5.4 of
	5.4 of [I-D.ietf-pce-pce-initiated-lsp] : the PCE sends an LSP		[I-D.ietf-pce-pce-initiated-lsp]: the PCE sends an LSP Initiate
	Initiate Message with an LSP object carrying the PLSP-ID of the SFP		Message with an LSP object carrying the PLSP-ID of the SFP and the
	to be removed and an SRP object with the R flag set (LSP-REMOVE as		SFP Identifier to be removed, as well as an SRP object with the R
	per section 5.2 of [I-D.ietf-pce-pce-initiated-lsp]). Rules of		flag set (LSP-REMOVE as per Section 5.2 of
	processing and error codes remain unchanged.		[I-D.ietf-pce-pce-initiated-lsp]). Rules for processing and error
			codes remain unchanged.
	4.3. SFP Delegation and Cleanup		4.3. SFP Delegation and Cleanup
	SFP delegation and cleanup operations are similar to those defined in		SFP delegation and cleanup operations are similar to those defined in
	section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing		Section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules for processing
	and error codes remains unchanged.		and error codes remain unchanged.
	4.4. SFP State Synchronization		4.4. SFP State Synchronization
	State Synchronization operations described in Section 5.4 of		State Synchronization operations described in Section 5.4 of
	[I-D.ietf-pce-stateful-pce]can be applied for SFP state maintenance		[I-D.ietf-pce-stateful-pce] can be applied to SFP state maintenance
	as well.		as well.
	4.5. SFP Update and Report		4.5. SFP Update and Report
	A PCE can send an SFP Update request to a PCC to update one or more		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 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		attributes. A PCC can send an SFP state report to a PCE, and which
	contains the SFP State information. The mechanism is described in		contains the SFP State information. The mechanism is described in
	[I-D.ietf-pce-stateful-pce] and can be applied for SFPs as well.		[I-D.ietf-pce-stateful-pce] and can be applied to SFPs as well.
	5. Object Formats		5. Object Formats
	5.1. The OPEN Object		5.1. The OPEN Object
	This document defines a new optional TLV for use in the OPEN Object		The optional TLV shown in Figure 2 is defined for use in the OPEN
	to indicate the PCEP speaker's Service function Chaining capability.		Object to indicate the PCEP speaker's Service Function Chaining
			capability.
	The SFC-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN		The SFC-PCE-CAPABILITY TLV is an optional TLV to be carried in the
	Object to advertise the SFC capability during the PCEP session. The		OPEN Object to advertise the SFC capability during the PCEP session.
	format of the SFC-PCE-CAPABILITY TLV is shown in the
	followingFigure 2 :
	0 1 2 3		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		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 |		| Type=TBD | length=4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Flags |		| Reserved | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	SFC-PCE-CAPABILITY TLV Format		SFC-PCE-CAPABILITY TLV Format
	The code point for the TLV type is to be defined by IANA. The TLV		The code point for the TLV type is to be defined by IANA (see
	length is 4 octets.		Section 9). The TLV length is 4 octets.
	The value is TBD.
	As per [I-D.ietf-pce-stateful-pce], a PCEP speaker advertises the		As per [I-D.ietf-pce-stateful-pce], a PCEP speaker advertises the
	capability of instantiating PCE-initiated LSPs via the Stateful PCE		capability of instantiating PCE-initiated LSPs via the Stateful PCE
	Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) conveyed in an Open		Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) carried in an Open
	message. The inclusion of the SFC-PCE-CAPABILITY TLV 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		object indicates that the sender is SFC-capable. Both mechanisms
	indicate the SFP instantiation capability of the PCEP speaker.		indicate the SFP instantiation capability of the PCEP speaker.
	5.2. The LSP Object		5.2. The LSP Object
	The LSP object is defined in [I-D.ietf-pce-pce-initiated-lsp] and		The LSP object is defined in [I-D.ietf-pce-pce-initiated-lsp] and
	included here for reference (Figure 3).		included here for reference (Figure 3).
	0 1 2 3		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		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|		| PLSP-ID | Flags |F|C| O|A|R|S|D|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// TLVs //		// TLVs //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	LSP Object Format		LSP Object Format
	A new flag, called the SFC (F) flag, is introduced. The F Flag set		A new flag, called the SFC flag (F-bit), is introduced. The F-bit
	to 1 indicates that this LSP is actually an SFP. The C flag will		set to "1" indicates that this LSP is actually an SFP. The C flag
	also be set to indicate it was created via a PCInitiate message.		will also be set to indicate it was created via a PCInitiate message.
	5.2.1. SFP Identifiers TLV		5.2.1. SFP Identifiers TLV
	The SFP Identifiers TLV MUST be included in the LSP object for		The SFP Identifiers TLV MUST be included in the LSP object for SFPs.
	Service Function Paths (SFP). The SFP Identifier TLV is used by the		The SFP Identifier TLV is used by the classifier to select the SFP
	classifier to enable SFP selection for the traffic,i.e.,direct		along which some traffic will be forwarded, according to the traffic
	traffic to specific SFP[I-D.ietf-sfc-architecture]. The SFP		classification rules applied by the classifier [RFC7665]. The SFP
	Identifier carried in the SFC encapsulation can be further used by		Identifier is part of the SFC metadata carried in packets and is used
	SFF to select service functions and next SFF,e.g., enable a packet		by the SFF to invoke service functions and identify the next SFF.
	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.
	The format of SFP Identifier TLV is shown in the following figure.		The format of the SFP Identifier TLV is shown in Figure 4.
	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		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 | Service Index |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Service path ID (SPI): 24 bits		Service Path ID (SPI): 24 bits
	Service index (SI): 8 bits		Service Index (SI): 8 bits
			Figure 4
	SPI: identifies a service path. The same ID is used by the		SPI: identifies a service path. The same ID is used by the
	participating nodes for path setup/selection. An administrator can		participating nodes for path setup/selection. An administrator can
	use the SPI for reporting and troubleshooting packets along a		use the SPI for reporting and troubleshooting packets along a
	specific path. SPI along with PLSP-ID is used in PCEP to identify		specific path. SPI along with PLSP-ID is used by PCEP to identify
	the Service Path.		the Service Path.
	SI: provides location within the service path.		SI: provides location within the service path.
	6. Backward Compatibility		6. Backward Compatibility
	The SFP instantiation capability PCEP protocol extensions described		The SFP instantiation capability defined as a PCEP extension and
	in this document MUST NOT be used if PCCs or the PCE did not		documented in this draft MUST NOT be used if PCCs or the PCE did not
	advertise its SFP instantiation stateful capability, as per		advertise their stateful SFP instantiation capability,Section 5.1.
	Section 5.1. If this is not the case and stateful operations on SFPs		If this is not the case and stateful operations on SFPs are
	are attempted, then a PCErr with error-type 19 (Invalid Operation)		attempted, then a PCErr message with error-type 19 (Invalid
	and error-value TBD needs to be generated.		Operation) and error-value TBD needs to be generated.
	[Editor Note: more information on exact error value is needed]		[Editor's note: more information on exact error value is needed]
	7. SFP signaling and forwarding consideration		7. SFP Signaling and Forwarding Considerations
	The SFP instantiation mechanism described in this document is not		The SFP instantiation mechanism described in this document is not
	tightly coupled to any SFP signaling mechanism. For example,SR-based		tightly coupled to any SFP signaling mechanism. For example, Generic
	approach [I-D.ietf-pce-segment-routing] can utilize the mechanism		SFC Encapsulation [I-D.ietf-sfc-nsh] can be used together with the
	described here and does not need any other specific protocol		mechanism described in this document to enable SFP forwarding. SR-
	extensions. Generic SFC Encapsulation [I-D.quinn-sfc-nsh] can also		based approach [I-D.ietf-pce-segment-routing] can also use the
	be used together with the mechanism described here to enable SFP		mechanism described here and does not need any other specific
	forwarding.		protocol extensions.
	8. Security Considerations		8. Security Considerations
	The security considerations described in [RFC5440] and		The security considerations described in [RFC5440] and
	[I-D.ietf-pce-pce-initiated-lsp] are applicable to this		[I-D.ietf-pce-pce-initiated-lsp] are applicable to this
	specification. No additional security measure is required.		specification. This document does not raise any additional security
			issue.
	9. IANA Considerations		9. IANA Considerations
	TBD		IANA is requested to allocate a new code point in the PCEP TLV Type
			Indicators registry, as follows:
			Value Meaning Reference
			------- ---------------------------- --------------
			TBD SFC-PCE-CAPABILITY This document
	10. Acknowledgements		10. Acknowledgements
	Many thanks to Ron Parker, Hao Wang,Dave Dolson,Jing Huang,Joel M.		Many thanks to Ron Parker, Hao Wang, Dave Dolson, Jing Huang, and
	Halpern for the discussion in formulating the content for the draft.		Joel M. Halpern for the discussion in formulating the content for
			the document.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[I-D.ietf-pce-stateful-pce]		[I-D.ietf-pce-stateful-pce]
	Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP		Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
	Extensions for Stateful PCE", draft-ietf-pce-stateful-		Extensions for Stateful PCE", draft-ietf-pce-stateful-
	pce-11 (work in progress), April 2015.		pce-13 (work in progress), December 2015.
			[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
			Element (PCE) Communication Protocol (PCEP)", RFC 5440,
			DOI 10.17487/RFC5440, March 2009,
			<http://www.rfc-editor.org/info/rfc5440>.
	[I-D.ietf-pce-pce-initiated-lsp]		[I-D.ietf-pce-pce-initiated-lsp]
	Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP		Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
	Extensions for PCE-initiated LSP Setup in a Stateful PCE		Extensions for PCE-initiated LSP Setup in a Stateful PCE
	Model", draft-ietf-pce-pce-initiated-lsp-04 (work in		Model", draft-ietf-pce-pce-initiated-lsp-05 (work in
	progress), April 2015.		progress), October 2015.
	11.2. Informative References		11.2. Informative References
	[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework		[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
	for Policy-based Admission Control", RFC 2753, January		for Policy-based Admission Control", RFC 2753,
	2000.		DOI 10.17487/RFC2753, January 2000,
			<http://www.rfc-editor.org/info/rfc2753>.
			[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
			Chaining (SFC) Architecture", RFC 7665,
			DOI 10.17487/RFC7665, October 2015,
			<http://www.rfc-editor.org/info/rfc7665>.
	[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,		[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
	"Policy-Enabled Path Computation Framework", RFC 5394,		"Policy-Enabled Path Computation Framework", RFC 5394,
	December 2008.		DOI 10.17487/RFC5394, December 2008,
			<http://www.rfc-editor.org/info/rfc5394>.
	[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
	(PCE) Communication Protocol (PCEP)", RFC 5440, March
	2009.
	[I-D.ietf-sfc-architecture]
	Halpern, J. and C. Pignataro, "Service Function Chaining
	(SFC) Architecture", draft-ietf-sfc-architecture-09 (work
	in progress), June 2015.
	[I-D.ww-sfc-control-plane]		[I-D.ietf-sfc-control-plane]
	Li, H., Wu, Q., Boucadair, M., Jacquenet, C., Haeffner,		Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C.,
	W., Lee, S., Parker, R., Dunbar, L., Malis, A., Halpern,		Haeffner, W., Lee, S., Parker, R., Dunbar, L., Malis, A.,
	J., Reddy, T., and P. Patil, "Service Function Chaining		Halpern, J., Reddy, T., and P. Patil, "Service Function
	(SFC) Control Plane Components & Requirements", draft-ww-		Chaining (SFC) Control Plane Components & Requirements",
	sfc-control-plane-06 (work in progress), June 2015.		draft-ietf-sfc-control-plane-03 (work in progress),
			January 2016.
	[I-D.ietf-pce-segment-routing]		[I-D.ietf-pce-segment-routing]
	Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,		Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
	Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,		Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,
	"PCEP Extensions for Segment Routing", draft-ietf-pce-		"PCEP Extensions for Segment Routing", draft-ietf-pce-
	segment-routing-05 (work in progress), May 2015.		segment-routing-06 (work in progress), August 2015.
	[I-D.quinn-sfc-nsh]		[I-D.ietf-sfc-nsh]
	Quinn, P., Guichard, J., Surendra, S., Smith, M.,		Quinn, P. and U. Elzur, "Network Service Header", draft-
	Henderickx, W., Nadeau, T., Agarwal, P., Manur, R.,		ietf-sfc-nsh-02 (work in progress), January 2016.
	Chauhan, A., Halpern, J., Majee, S., Elzur, U., Melman,
	D., Garg, P., McConnell, B., Wright, C., and K. Kevin,
	"Network Service Header", draft-quinn-sfc-nsh-07 (work in
	progress), February 2015.
	Authors' Addresses		Authors' Addresses
	Qin Wu		Qin Wu
	Huawei		Huawei
	101 Software Avenue, Yuhua District		101 Software Avenue, Yuhua District
	Nanjing, Jiangsu 210012		Nanjing, Jiangsu 210012
	China		China
	EMail: sunseawq@huawei.com		EMail: bill.wu@huawei.com
	Dhruv Dhody		Dhruv Dhody
	Huawei		Huawei
	Leela Palace		Leela Palace
	Bangalore, Karnataka 560008		Bangalore, Karnataka 560008
	INDIA		INDIA
	EMail: dhruv.ietf@gmail.com		EMail: dhruv.ietf@gmail.com
	Mohamed Boucadair		Mohamed Boucadair
	France Telecom		Orange
	Rennes 35000		Rennes 35000
	France		France
	EMail: mohamed.boucadair@orange.com		EMail: mohamed.boucadair@orange.com
	Christian Jacquenet		Christian Jacquenet
	France Telecom		Orange
	Rennes 35000		Rennes
	France		France
	EMail: christian.jacquenet@orange.com		EMail: christian.jacquenet@orange.com
	Jeff Tantsura		Jeff Tantsura
	Ericsson		Ericsson
	300 Holger Way		300 Holger Way
	San Jose, CA 95134		San Jose, CA 95134
	US		US
	EMail: Jeff.Tantsura@ericsson.com		EMail: Jeff.Tantsura@ericsson.com
End of changes. 68 change blocks.
	191 lines changed or deleted		202 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/