< draft-minei-diffserv-te-multi-class-01.txt		draft-minei-diffserv-te-multi-class-02.txt >
	Network Working Group Ina Minei		Network Working Group Ina Minei
	Internet Draft Der-Hwa Gan		Internet Draft Der-Hwa Gan
	Expiration Date: January 2006 Kireeti Kompella		Expiration Date: December 2006 Kireeti Kompella
	Category: Informational Juniper Networks		Category: Informational Juniper Networks
	Xiaoming Li		Xiaoming Li
	China Unicom		China Unicom
	July 2005		June 2006
	Extensions for Differentiated Services-aware Traffic Engineered LSPs		Extensions for Differentiated Services-aware Traffic Engineered LSPs
	draft-minei-diffserv-te-multi-class-01.txt		draft-minei-diffserv-te-multi-class-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	skipping to change at page 2, line 28 ¶		skipping to change at page 2, line 28 ¶
	4.2 RSVP signaling ........................................ 6		4.2 RSVP signaling ........................................ 6
	4.3 RSVP error processing ................................. 7		4.3 RSVP error processing ................................. 7
	5 The extended-MAM bandwidth constraints model .......... 8		5 The extended-MAM bandwidth constraints model .......... 8
	6 IGP extensions ........................................ 8		6 IGP extensions ........................................ 8
	7 Migration issues ...................................... 8		7 Migration issues ...................................... 8
	8 Security considerations ............................... 9		8 Security considerations ............................... 9
	9 Intellectual Property Statement ....................... 9		9 Intellectual Property Statement ....................... 9
	10 Acknowledgments ....................................... 9		10 Acknowledgments ....................................... 9
	11 References ............................................ 9		11 References ............................................ 9
	11.1 Normative References .................................. 10		11.1 Normative References .................................. 10
	11.2 Informative References ................................ 10		12 Authors' Addresses .................................... 10
	12 Authors' Addresses .................................... 11
	Full Copyright Statement .............................. 11		Full Copyright Statement .............................. 11
	1. Definitions		1. Definitions
	For readability a number of definitions from [RFC3564] are repeated		For readability a number of definitions from [RFC3564] are repeated
	here:		here:
	Traffic Trunk: an aggregation of traffic flows of the same class		Traffic Trunk: an aggregation of traffic flows of the same class
	[i.e. which are to be treated equivalently from the DS-TE perspec-		[i.e. which are to be treated equivalently from the DS-TE perspec-
	tive] which are placed inside a Label Switched Path.		tive] which are placed inside a Label Switched Path.
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	TE-Class: A pair of:		TE-Class: A pair of:
	1. a Class-Type		1. a Class-Type
	2. a preemption priority allowed for that Class-Type. This means		2. a preemption priority allowed for that Class-Type. This means
	that an LSP transporting a Traffic Trunk from that Class-Type		that an LSP transporting a Traffic Trunk from that Class-Type
	can use that preemption priority as the set-up priority, as the		can use that preemption priority as the set-up priority, as the
	holding priority or both.		holding priority or both.
	2. Introduction		2. Introduction
	[DSTE-PROTO] defines the protocol extensions for setting up diffserv-		[RFC4124] defines the protocol extensions for setting up diffserv-
	aware traffic engineered LSPs. An LSP set up according to [DSTE-		aware traffic engineered LSPs. An LSP set up according to [RFC4124]
	PROTO] carries traffic from a single diffserv class and is set up		carries traffic from a single diffserv class and is set up along a
	along a path that satisfies the bandwidth constraints specified for		path that satisfies the bandwidth constraints specified for this
	this class. In this case, a single Class-Type is configured per LSP.		class. In this case, a single Class-Type is configured per LSP. In
	In the rest of this document such an LSP is called single-class diff-		the rest of this document such an LSP is called single-class diff-
	serv-TE LSP. Note that from a diffserv point of view, a single-class		serv-TE LSP. Note that from a diffserv point of view, a single-class
	LSP can be either an L-LSP or an E-LSP (as defined in [RFC3270]).		LSP can be either an L-LSP or an E-LSP (as defined in [RFC3270]).
	In some scenarios it is required to allow traffic with different		In some scenarios it is required to allow traffic with different
	diffserv behaviors to be mapped to the same LSP and to traffic engi-		diffserv behaviors to be mapped to the same LSP and to traffic engi-
	neer the LSP according to the bandwidth constraints for each one of		neer the LSP according to the bandwidth constraints for each one of
	these classes. In this case, multiple Class-Types are configured per		these classes. In this case, multiple Class-Types are configured per
	LSP. In the rest of the document such an LSP is called a multi-class		LSP. In the rest of the document such an LSP is called a multi-class
	diffserv-TE LSP. From a diffserv point of view, a multi-class LSP is		diffserv-TE LSP. From a diffserv point of view, a multi-class LSP is
	always an E-LSP.		always an E-LSP.
	skipping to change at page 4, line 44 ¶		skipping to change at page 4, line 44 ¶
	3. Setup and holding preemption priorities		3. Setup and holding preemption priorities
	As per existing TE, multi-class LSPs can be configured with a setup		As per existing TE, multi-class LSPs can be configured with a setup
	and holding priority, each with a value between 0 and 7. The combi-		and holding priority, each with a value between 0 and 7. The combi-
	nation of the setup priority and each of the Class-Types for which		nation of the setup priority and each of the Class-Types for which
	the multi-class LSP is set up and of the hold priority and each of		the multi-class LSP is set up and of the hold priority and each of
	the Class-Types for which the multi-class LSP is set up, MUST be such		the Class-Types for which the multi-class LSP is set up, MUST be such
	that together they form one of the (up to) 8 TE-Classes configured in		that together they form one of the (up to) 8 TE-Classes configured in
	the TE-Class Mapping. This requirement is similar to the requirement		the TE-Class Mapping. This requirement is similar to the requirement
	spelled out in [DSTE-PROTO] regarding the combination of priority and		spelled out in [RFC4124] regarding the combination of priority and
	class-type for single-class LSPs.		class-type for single-class LSPs.
	4. Setting up multi-class RSVP-signaled LSPs		4. Setting up multi-class RSVP-signaled LSPs
	4.1. The extended classtype object		4.1. The extended classtype object
	To request LSP setup along a path with bandwidth constraints from		To request LSP setup along a path with bandwidth constraints from
	more than one Class-Type, a new object is defined, the extended-		more than one Class-Type, a new object is defined, the extended-
	classtype-object. This object has a class_num that ensures that a		classtype-object. This object has a class_num that ensures that a
	node that doesn't recognize it will reject it and return an "Unknown		node that doesn't recognize it will reject it and return an "Unknown
	Object Num" error. According to the guidelines in [PROC], the values		Object Num" error. According to the guidelines in [RFC3936], the val-
	used are class_num 124 and "class class_type" 1.		ues used are class_num 124 and "class class_type" 1.
	The contents are a set of subobjects, each encoded as a TLV.		The contents are a set of subobjects, each encoded as a TLV.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Subobjects |		| Subobjects |
	. ... .		. ... .
	. ... .		. ... .
	. ... .		. ... .
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 4 ¶
	Type : 8 bits		Type : 8 bits
	The type of the contents of the subobject. Currently defined		The type of the contents of the subobject. Currently defined
	value is		value is
	1 - bandwidth		1 - bandwidth
	MBZ: 3 bits		MBZ: 3 bits
	This field is reserved. It must be set to zero on transmission		This field is reserved. It must be set to zero on transmission
	and must be ignored on receipt.		and must be ignored on receipt.
	CT : 3 bits		CT : 3 bits
	Indicates the Class-Type. Values currently allowed are 0, 1, 2, ...		Indicates the Class-Type. Values currently allowed are 0, 1,
	, 7. Note that this is different from the definition given in		2, ... , 7. Note that this is different from the definition
	[DSTE-PROTO] where the value 0 is not allowed.		given in [RFC4124] where the value 0 is not allowed.
	BW requested : 32 bits		BW requested : 32 bits
	Indicates the number of bytes (not bits) per second that need to be		Indicates the number of bytes (not bits) per second that need
	reserved for the CT indicated.		to be reserved for the CT indicated.
	4.2. RSVP signaling		4.2. RSVP signaling
	The extended-classtype object is signaled in the PATH message, and		The extended-classtype object is signaled in the PATH message, and
	saved in the PSB at every hop. The extended-classtype object MUST NOT		saved in the PSB at every hop. The extended-classtype object MUST NOT
	be included in a RESV message.		be included in a RESV message.
	The format of the Path message is as follows:		The format of the Path message is as follows:
	<Path Message> ::= <Common Header> [ <INTEGRITY> ]		<Path Message> ::= <Common Header> [ <INTEGRITY> ]
	skipping to change at page 7, line 44 ¶		skipping to change at page 7, line 44 ¶
	ity, return 'CT and setup priority do not form a configured TE-class'		ity, return 'CT and setup priority do not form a configured TE-class'
	The error checking ensures that multi-class LSPs get established only		The error checking ensures that multi-class LSPs get established only
	through LSRs that support multi-class diffserv-te LSPs and have con-		through LSRs that support multi-class diffserv-te LSPs and have con-
	sistent TE-mappings with the ingress.		sistent TE-mappings with the ingress.
	Errors related to the processing of the extended-classtype-object are		Errors related to the processing of the extended-classtype-object are
	reported using the vendor-specific Error-Code "extended-classtype-		reported using the vendor-specific Error-Code "extended-classtype-
	error" 252. The first four octets following the Error Value are 2636		error" 252. The first four octets following the Error Value are 2636
	- the vendor's SMI enterprise code in network octet order (as		- the vendor's SMI enterprise code in network octet order (as
	required by [PROC])		required by [RFC3936])
	The error values are the same as defined in [DSTE-PROTO] for the		The error values are the same as defined in [RFC4124] for the
	classtype object. The values 3, 6, 7 are not used with multi-class-		classtype object. The values 3, 6, 7 are not used with multi-class-
	LSPs.		LSPs.
	5. The extended-MAM bandwidth constraints model		5. The extended-MAM bandwidth constraints model
	A new BC model-id is defined, the extended-mam bandwidth model, with		A new BC model-id is defined, the extended-mam bandwidth model, with
	value 254. The extended-mam model has the same behavior as the MAM		value 254. The extended-mam model has the same behavior as the MAM
	model [DSTE-MAM].		model [RFC4125].
	6. IGP extensions		6. IGP extensions
	[DSTE-PROTO] defines the bandwidth-constraint (BC) sub-tlv. The BC		[RFC4124] defines the bandwidth-constraint (BC) sub-tlv. The BC sub-
	sub-tlv includes the bandwidth model and a list of bandwidth-con-		tlv includes the bandwidth model and a list of bandwidth-constraints.
	straints. In [DSTE-PROTO], the semantic of the "Unreserved Bandwidth"		In [RFC4124], the semantic of the "Unreserved Bandwidth" sub-TLV is
	sub-TLV is changed such that the eight bandwidth values advertised		changed such that the eight bandwidth values advertised correspond to
	correspond to the unreserved bandwidth for each of the TE-Class		the unreserved bandwidth for each of the TE-Class (instead of for
	(instead of for each preemption priority as per existing TE). This		each preemption priority as per existing TE). This approach has two
	approach has two drawbacks:		drawbacks:
	o It creates a flag day in the network with regards to the existing		o It creates a flag day in the network with regards to the existing
	TE LSPs set up without any diffserv properties, as explained in		TE LSPs set up without any diffserv properties, as explained in
	[DSTE-PROTO].		[RFC4124].
	o It requires that LSPs from CT0 be set up at priorities such that		o It requires that LSPs from CT0 be set up at priorities such that
	the combination of (CT0, priority) is one of the configured TE-		the combination of (CT0, priority) is one of the configured TE-
	classes. Thus, the priorities asssigned to pre-existing CT0 LSPs		classes. Thus, the priorities asssigned to pre-existing CT0 LSPs
	use up some of the TE-classes.		use up some of the TE-classes.
	In the method documented here, when the bandwidth-model is extended-		In the method documented here, when the bandwidth-model is extended-
	mam, the semantic of the "Unreserved Bandwidth" sub-TLV is the same		mam, the semantic of the "Unreserved Bandwidth" sub-TLV is the same
	as in existing TE and the bandwidth available per TE-class is adver-		as in existing TE and the bandwidth available per TE-class is adver-
	tised in the BC sub-tlv. This approach achieves the following:		tised in the BC sub-tlv. This approach achieves the following:
	o There is no interference between the diffserv-aware LSPs and the		o There is no interference between the diffserv-aware LSPs and the
	plain TE LSPs		plain TE LSPs
	o There are no migration issues when deploying this feature in a		o There are no migration issues when deploying this feature in a
	network where TE LSPs are deployed.		network where TE LSPs are deployed.
	o A total of 16 TE-classes are effectively created.		o A total of 16 TE-classes are effectively created.
	7. Migration issues		7. Migration issues
	Since the semantics of the "Unreserved Bandwidth" sub-TLV are main-		Since the semantics of the "Unreserved Bandwidth" sub-TLV are main-
	tained unchanged, there are no migration issues when deploying multi-		tained unchanged, there are no migration issues when deploying multi-
	class LSPs in a network where traffic engineering is already in use.		class LSPs in a network where traffic engineering is already in use.
	Single-class and multi-class LSPs cannot co-exist in the same net-		Single-class and multi-class LSPs cannot co-exist in the same net-
	work. When both the multi-class and the single-class functionality		work. When both the multi-class and the single-class functionality
	is required, the semantics of single-class LSPs can be provided by		is required, the semantics of single-class LSPs can be provided by
	the multi-class LSPs.		the multi-class LSPs.
	8. Security considerations		8. Security considerations
	The same security considerations apply as for single-class diffserv-		The same security considerations apply as for single-class diffserv-
	TE LSPs [DSTE-PROTO].		TE LSPs [RFC4124].
	9. Intellectual Property Statement		9. Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	skipping to change at page 10, line 6 ¶		skipping to change at page 10, line 6 ¶
	10. Acknowledgments		10. Acknowledgments
	This work is the outcome of discussions with Arthi Ayyangar and Chai-		This work is the outcome of discussions with Arthi Ayyangar and Chai-
	tanya Kodeboyina. The authors would like to thank them for their		tanya Kodeboyina. The authors would like to thank them for their
	suggestions and insight. The authors would like to thank Yakov		suggestions and insight. The authors would like to thank Yakov
	Rekhter and Peter Busschbach for their review.		Rekhter and Peter Busschbach for their review.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC1700] Reynolds, J., Postel, J., "Assigned numbers", RFC 1700.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119.		Requirement Levels", RFC 2119.
	[RFC2475] Blake et al., "An Architecture for Differentiated Ser-
	vices", RFC2475.
	[RFC2702] Awduche et al., "Requirements for Traffic Engineering Over
	MPLS", RFC2702.
	[RFC3031] Rosen et al., "Multiprotocol Label Switching Architecture",
	RFC3031.
	[RFC3270] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270.		[RFC3270] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270.
	[RFC3630] Katz et al., "Traffic Engineering (TE) Extensions to OSPF		[RFC3564] Le Faucheur et al, "Requirements for support of Diff-Serv-
	Version 2", RFC3630.		aware MPLS Traffic Engineering", RFC3564.
	[RFC3784] Smit, Li, "IS-IS extensions for Traffic Engineering",
	RFC3784.
	[DSTE-MAM] Le Faucheur, Lai, "Maximum Allocation Bandwidth Con-
	straints Model for DS-TE", draft-ietf-tewg-diff-te-mam-02.txt, work
	in progress.
	[DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of
	Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-
	proto-07.txt, work in progress.
	[DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv-
	aware MPLS Traffic Engineering, RFC3564.
	11.2. Informative References		[RFC3936] Kompella, K., Lang, J., "Procedures for Modifying the
			Resource reSerVation Protocol (RSVP)", RFC3936.
	[DSTE-RDM] Le Faucheur et al., "Russian Dolls Bandwidth Constraints		[RFC4125] Le Faucheur, Lai, "Maximum Allocation Bandwidth Constraints
	Model for DS-TE", draft-ietf-tewg-diff-te-russian-04.txt, work in		Model for DS-TE", RFC4125.
	progress.
	[REROUTE] Pan et. al., "Fast Reroute Extensions to RSVP-TE for LSP		[RFC4124] Le Faucheur et al, "Protocol extensions for support of
	Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt, work in		Diff-Serv-aware MPLS Traffic Engineering", RFC4124.
	progress.
	12. Authors' Addresses		12. Authors' Addresses
	Ina Minei		Ina Minei
	Juniper Networks		Juniper Networks
	1194 N.Mathilda Ave		1194 N.Mathilda Ave
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	e-mail: ina@juniper.net		e-mail: ina@juniper.net
	Der-Hwa Gan		Der-Hwa Gan
	skipping to change at page 11, line 33 ¶		skipping to change at page 11, line 7 ¶
	e-mail: kireeti@juniper.net		e-mail: kireeti@juniper.net
	Xiaoming Li		Xiaoming Li
	China United Telecommunications Corporation		China United Telecommunications Corporation
	No.133A, Xidan North Street,		No.133A, Xidan North Street,
	Xicheng District, Beijing 100032, China		Xicheng District, Beijing 100032, China
	email: lixm@chinaunicom.com.cn		email: lixm@chinaunicom.com.cn
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Additional copyright notices are not permitted in IETF Documents		Additional copyright notices are not permitted in IETF Documents
	except in the case where such document is the product of a joint		except in the case where such document is the product of a joint
	development effort between the IETF and another standards development		development effort between the IETF and another standards development
	organization or the document is a republication of the work of		organization or the document is a republication of the work of
	another standards organization. Such exceptions must be approved on		another standards organization. Such exceptions must be approved on
	an individual basis by the IAB.		an individual basis by the IAB.
End of changes. 23 change blocks.
	67 lines changed or deleted		40 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/