< draft-wu-pce-traffic-steering-sfc-10.txt		draft-wu-pce-traffic-steering-sfc-11.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: September 7, 2017 M. Boucadair		Expires: September 10, 2017 M. Boucadair
	C. Jacquenet		C. Jacquenet
	Orange		Orange
	J. Tantsura		J. Tantsura
	March 6, 2017		March 9, 2017
	PCEP Extensions for Service Function Chaining (SFC)		PCEP Extensions for Service Function Chaining (SFC)
	draft-wu-pce-traffic-steering-sfc-10		draft-wu-pce-traffic-steering-sfc-11
	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) to dynamically structure service function chains.		Element (PCE) to dynamically structure service function chains.
	Service Function Chaining (SFC) is a technique that is meant to		Service Function Chaining (SFC) is a technique that is meant to
	facilitate the dynamic enforcement of differentiated traffic		facilitate the dynamic enforcement of differentiated traffic
	forwarding policies within a domain. Service function chains are		forwarding policies within a domain. Service function chains are
	composed of an ordered set of elementary Service Functions (such as		composed of an ordered set of elementary Service Functions (such as
	firewalls, load balancers) that need to be invoked according to the		firewalls, load balancers) that need to be invoked according to the
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 September 7, 2017.		This Internet-Draft will expire on September 10, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 37 ¶
	4.2. SFP Withdrawal . . . . . . . . . . . . . . . . . . . . . 6		4.2. SFP Withdrawal . . . . . . . . . . . . . . . . . . . . . 6
	4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . 7		4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . 7
	4.4. SFP State Synchronization . . . . . . . . . . . . . . . . 7		4.4. SFP State Synchronization . . . . . . . . . . . . . . . . 7
	4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . 7		4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . 7
	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 . . . . . . . . . . . . . . . . . . . . . 8		5.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . 8
	5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 8		5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 8
	6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9		6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9
	7. SFP Instantiation Signaling and Forwarding Considerations . . 9		7. SFP Instantiation Signaling and Forwarding Considerations . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	11.1. Normative References . . . . . . . . . . . . . . . . . . 10		11.1. Normative References . . . . . . . . . . . . . . . . . . 10
	11.2. Informative References . . . . . . . . . . . . . . . . . 10		11.2. Informative References . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Service Function Chaining (SFC) enables the creation of composite		Service Function Chaining (SFC) enables the creation of composite
	services that consist of an ordered set of Service Functions (SF)		services that consist of an ordered set of Service Functions (SF)
	that must be applied to packets and/or frames and/or flows selected		that must be applied to packets and/or frames and/or flows selected
	as a result of service-inferred traffic classification as described		as a result of service-inferred traffic classification as described
	in [RFC7665]. A Service Function Path (SFP) is a path along which		in [RFC7665]. A Service Function Path (SFP) is a path along which
	traffic that is bound to a specific service function chain will be		traffic that is bound to a specific service function chain will be
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 36 ¶
	be used as a SF/SFF identification means. This document makes no		be used as a SF/SFF identification means. This document makes no
	change to the PCInitiate message format but extends LSP objects		change to the PCInitiate message format but extends LSP objects
	described in Section 5.2.		described in Section 5.2.
	Editor's note: In case a PCE-Initiated signaling mechanism is used to		Editor's note: In case a PCE-Initiated signaling mechanism is used to
	set up the service function path, does the classifier / PCE-Initiated		set up the service function path, does the classifier / PCE-Initiated
	signaling protocol need to understand whether an IP address is		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		assigned to a SFF or a SF, or the signaling protocol is only used to
	signal IP addresses for SFs?		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.
	4.1. SFP Instantiation		4.1. SFP Instantiation
	The instantiation of a SFP is the same as defined in Section 5.3 of		The instantiation of a SFP is the same as defined in Section 5.3 of
	[I-D.ietf-pce-pce-initiated-lsp]. Rules for processing and error		[I-D.ietf-pce-pce-initiated-lsp]. Rules for processing and error
	codes remain unchanged.		codes remain unchanged.
	4.2. SFP Withdrawal		4.2. SFP Withdrawal
	The withdrawal of an SFP is the same as defined in Section 5.4 of		The withdrawal of an SFP is the same as defined in Section 5.4 of
	[I-D.ietf-pce-pce-initiated-lsp]: the PCE sends an LSP Initiate		[I-D.ietf-pce-pce-initiated-lsp]: the PCE sends an LSP Initiate
	skipping to change at page 8, line 29 ¶		skipping to change at page 8, line 34 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	LSP Object Format		LSP Object Format
	A new flag, called the SFC flag (F-bit), is introduced. The F-bit		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		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.		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 SFPs.		As described in section 4, SFP ID is predetermined and assigned by
	The SFP Identifier TLV is used by the classifier to select the SFP		stateful PCE. The SFP Identifiers TLV MUST be included in the LSP
	along which some traffic will be forwarded, according to the traffic		object for SFPs. The SFP Identifier TLV is used by the classifier to
	classification rules applied by the classifier [RFC7665]. The SFP		select the SFP along which some traffic will be forwarded, according
	Identifier is part of the SFC metadata carried in packets and is used		to the traffic classification rules applied by the classifier
	by the SFF to invoke service functions and identify the next SFF.		[RFC7665]. 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 Figure 4.		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
	skipping to change at page 10, line 33 ¶		skipping to change at page 10, line 49 ¶
	pce-18 (work in progress), December 2016.		pce-18 (work in progress), December 2016.
	[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation		[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
	Element (PCE) Communication Protocol (PCEP)", RFC 5440,		Element (PCE) Communication Protocol (PCEP)", RFC 5440,
	DOI 10.17487/RFC5440, March 2009,		DOI 10.17487/RFC5440, March 2009,
	<http://www.rfc-editor.org/info/rfc5440>.		<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-08 (work in		Model", draft-ietf-pce-pce-initiated-lsp-09 (work in
	progress), March 2017.		progress), March 2017.
	[I-D.ietf-teas-pce-central-control]		[I-D.ietf-teas-pce-central-control]
	Farrel, A., Zhao, Q., Li, Z., and C. Zhou, "An		Farrel, A., Zhao, Q., Li, Z., and C. Zhou, "An
	Architecture for Use of PCE and PCEP in a Network with		Architecture for Use of PCE and PCEP in a Network with
	Central Control", draft-ietf-teas-pce-central-control-01		Central Control", draft-ietf-teas-pce-central-control-01
	(work in progress), December 2016.		(work in progress), December 2016.
	11.2. Informative References		11.2. Informative References
End of changes. 9 change blocks.
	14 lines changed or deleted		21 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/