draft-ietf-dime-qos-parameters-01.txt		draft-ietf-dime-qos-parameters-02.txt
	Diameter Maintenance and J. Korhonen, Ed.		Diameter Maintenance and J. Korhonen, Ed.
	Extensions (DIME) TeliaSonera		Extensions (DIME) TeliaSonera
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Intended status: Standards Track Nokia Siemens Networks		Intended status: Standards Track Nokia Siemens Networks
	Expires: April 1, 2008 September 29, 2007		Expires: August 28, 2008 February 25, 2008
	Quality of Service Parameters for Usage with the AAA Framework		Quality of Service Parameters for Usage with the AAA Framework
	draft-ietf-dime-qos-parameters-01.txt		draft-ietf-dime-qos-parameters-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		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 1, 2008.		This Internet-Draft will expire on August 28, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document defines a number of Quality of Service (QoS) parameters		This document defines a number of Quality of Service (QoS) parameters
	that can be reused for conveying QoS information within RADIUS and		that can be reused for conveying QoS information within RADIUS and
	Diameter.		Diameter.
	The payloads used to carry these QoS parameters are opaque for the		The payloads used to carry these QoS parameters are opaque for the
	AAA client and the AAA server itself and interpreted by the		AAA client and the AAA server itself and interpreted by the
	respective Resource Management Function.		respective Resource Management Function.
	skipping to change at page 2, line 25		skipping to change at page 2, line 25
	4.1. Parameter Header . . . . . . . . . . . . . . . . . . . . . 5		4.1. Parameter Header . . . . . . . . . . . . . . . . . . . . . 5
	4.2. TMOD-1 Parameter . . . . . . . . . . . . . . . . . . . . . 5		4.2. TMOD-1 Parameter . . . . . . . . . . . . . . . . . . . . . 5
	4.3. TMOD-2 Parameter . . . . . . . . . . . . . . . . . . . . . 6		4.3. TMOD-2 Parameter . . . . . . . . . . . . . . . . . . . . . 6
	4.4. Path Latency Parameter . . . . . . . . . . . . . . . . . . 7		4.4. Path Latency Parameter . . . . . . . . . . . . . . . . . . 7
	4.5. Path Jitter Parameter . . . . . . . . . . . . . . . . . . 7		4.5. Path Jitter Parameter . . . . . . . . . . . . . . . . . . 7
	4.6. Path PLR Parameter . . . . . . . . . . . . . . . . . . . . 8		4.6. Path PLR Parameter . . . . . . . . . . . . . . . . . . . . 8
	4.7. Path PER Parameter . . . . . . . . . . . . . . . . . . . . 8		4.7. Path PER Parameter . . . . . . . . . . . . . . . . . . . . 8
	4.8. Slack Term Parameter . . . . . . . . . . . . . . . . . . . 9		4.8. Slack Term Parameter . . . . . . . . . . . . . . . . . . . 9
	4.9. Preemption Priority amp; Defending Priority Parameters . . 9		4.9. Preemption Priority amp; Defending Priority Parameters . . 9
	4.10. Admission Priority Parameter . . . . . . . . . . . . . . . 10		4.10. Admission Priority Parameter . . . . . . . . . . . . . . . 10
	4.11. RPH Priority Parameter . . . . . . . . . . . . . . . . . . 10		4.11. Application-Level Resource Priority (ALRP) Parameter . . . 10
	4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 12		4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 11
	4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 13		4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 12
	4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 14		4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 13
	4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 14		4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 13
	5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 16		5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 17		6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 16
	6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 17		6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 16
			6.3. Admission Priority Parameter . . . . . . . . . . . . . . . 17
			6.4. Excess Treatment Parameter . . . . . . . . . . . . . . . . 17
			6.5. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 18
			6.6. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 18		9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	9.2. Informative References . . . . . . . . . . . . . . . . . . 20		9.2. Informative References . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	Intellectual Property and Copyright Statements . . . . . . . . . . 21		Intellectual Property and Copyright Statements . . . . . . . . . . 22
	1. Introduction		1. Introduction
	This document defines a number of Quality of Service (QoS) parameters		This document defines a number of Quality of Service (QoS) parameters
	that can be reused for conveying QoS information within RADIUS and		that can be reused for conveying QoS information within RADIUS and
	Diameter.		Diameter.
	The payloads used to carry these QoS parameters are opaque for the		The payloads used to carry these QoS parameters are opaque for the
	AAA client and the AAA server itself and interpreted by the		AAA client and the AAA server itself and interpreted by the
	respective Resource Management Function.		respective Resource Management Function.
	skipping to change at page 9, line 19		skipping to change at page 9, line 19
	follows:		follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|M|r|r|r| 7 |r|r|r|r| 1 |		|M|r|r|r| 7 |r|r|r|r| 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Slack Term [S] (32-bit integer) |		| Slack Term [S] (32-bit integer) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Slack Term parameter S is nonnegative and is measured in		The Slack Term parameter S is a 32-bit integer value in network byte
	microseconds. S is represented as a 32-bit integer. Its value can		order and is measured in microseconds. S is represented as a 32-bit
	range from 0 to (2**32)-1 microseconds.		integer. Its value can range from 0 to (2**32)-1 microseconds.
	4.9. Preemption Priority amp; Defending Priority Parameters		4.9. Preemption Priority amp; Defending Priority Parameters
	A description of the semantic of the parameter values can be found in		A description of the semantic of the parameter values can be found in
	[RFC3181].		[RFC3181].
	The coding for the <Preemption Priority> & <Defending Priority> sub-		The coding for the <Preemption Priority> & <Defending Priority> sub-
	parameters is as follows:		parameters is as follows:
	0 1 2 3		0 1 2 3
	skipping to change at page 9, line 48		skipping to change at page 9, line 48
	Preemption Priority: The priority of the new flow compared with the		Preemption Priority: The priority of the new flow compared with the
	defending priority of previously admitted flows. Higher values		defending priority of previously admitted flows. Higher values
	represent higher priority.		represent higher priority.
	Defending Priority: Once a flow is admitted, the preemption priority		Defending Priority: Once a flow is admitted, the preemption priority
	becomes irrelevant. Instead, its defending priority is used to		becomes irrelevant. Instead, its defending priority is used to
	compare with the preemption priority of new flows.		compare with the preemption priority of new flows.
	As specified in [RFC3181], <Preemption Priority> & <Defending		As specified in [RFC3181], <Preemption Priority> & <Defending
	Priority> are 16-bit integer values.		Priority> are 16-bit integer values. They are represented in network
			byte order.
	4.10. Admission Priority Parameter		4.10. Admission Priority Parameter
	A description of the semantic of the parameter values can be found in		A description of the semantic of the parameter values can be found in
	[Y.1571]. The coding for the <Admission Priority> parameter is as		[Y.1571]. The coding for the <Admission Priority> parameter is as
	follows:		follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|M|r|r|r| 9 |r|r|r|r| 1 |		|M|r|r|r| 9 |r|r|r|r| 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Admis.Priority| (Reserved) |		| Admis.Priority| (Reserved) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			The 'Admis.Priority' field is a 8 bit unsigned integer in network
			byte order.
	High priority flows, normal priority flows, and best-effort priority		High priority flows, normal priority flows, and best-effort priority
	flows can have access to resources depending on their admission		flows can have access to resources depending on their admission
	priority value as follows:		priority value as follows:
	Admission Priority:		Admission Priority:
	0 - best-effort priority flow		0 - best-effort priority flow
	1 - normal priority flow		1 - normal priority flow
	2 - high priority flow		2 - high priority flow
	255 - not used		255 - not used
	A reservation without an <Admission Priority> parameter (i.e., set to		A reservation without an <Admission Priority> parameter (i.e., set to
	255) MUST be treated as a reservation with an <Admission Priority> =		255) MUST be treated as a reservation with an <Admission Priority> =
	1.		1.
	4.11. RPH Priority Parameter		4.11. Application-Level Resource Priority (ALRP) Parameter
	A description of the semantic of the parameter values can be found in		A description of the semantic of the parameter values can be found in
	[RFC4412]. The coding for the <RPH Priority> parameter is as		[RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for
	follows:		parameter is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|M|r|r|r| 10 |r|r|r|r| 1 |		|M|r|r|r| 10 |r|r|r|r| 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RPH Namespace | RPH Priority | (Reserved) |		| ALRP Namespace | ALRP Priority | (Reserved) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			The ALRP Namespace field is a 16 bits long unsigned integer in
			network byte order and the ALRP Priority field is an 8 bit long
			unsigned integer in network byte order containing the specific
			priority value.
	[RFC4412] defines a resource priority header (RPH) with parameters		[RFC4412] defines a resource priority header and established the
	"RPH Namespace" and "RPH Priority" combination, and if populated is		initial registry; that registry was later extended by
	applicable only to flows with high admission priority, as follows:		[I-D.ietf-tsvwg-emergency-rsvp].
	RPH Namespace:
	0 - dsn
	1 - drsn
	2 - q735
	3 - ets
	4 - wps
	255 - not used
	Each namespace has a finite list of relative priority-values. Each
	is listed here in the order of lowest priority to highest priority.
	RPH Priority:
	4 - q735.4
	3 - q735.3
	2 - q735.2
	1 - q735.1
	0 - q735.0
	4 - ets.4
	3 - ets.3
	2 - ets.2
	1 - ets.1
	0 - ets.0
	4 - wps.4
	3 - wps.3
	2 - wps.2
	1 - wps.1
	0 - wps.0
	For the 4 priority parameters, the following cases are permissible
	(procedures specified in references):
	1 parameter: <Admission Priority> [Y.1571]
	2 parameters: <Admission Priority>, <RPH Priority> [RFC4412]
	2 parameters: <Preemption Priority>, <Defending Priority> [RFC3181]
	3 parameters: <Preemption Priority>, <Defending Priority>,
	<Admission Priority> [3GPP-1, 3GPP-2, 3GPP-3]
	4 parameters: <Preemption Priority>, <Defending Priority>,
	<Admission Priority>, <RPH Priority> [3GPP-1, 3GPP-2,
	3GPP-3]
	It is permissible to have <Admission Priority> without <RPH
	Priority>, but not permissible to have <RPH Priority> without
	<Admission Priority> (alternatively <RPH Priority> is ignored in
	instances without <Admission Priority>).
	4.12. Excess Treatment Parameter		4.12. Excess Treatment Parameter
	The coding for the <Excess Treatment> parameter is as follows:		The coding for the <Excess Treatment> parameter is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|M|r|r|r| 11 |r|r|r|r| 1 |		|M|r|r|r| 11 |r|r|r|r| 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Excess Trtmnt | Remark Value | Reserved |		| Excess Trtmnt | Remark Value | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Excess Treatment: Indicates how the QoS aware node should process		Excess Treatment (8 bit unsigned integer value in network byte
	out-of-profile traffic, that is, traffic not covered by the <Traffic>		order): Indicates how the QoS aware node should process out-of-
			profile traffic, that is, traffic not covered by the <Traffic>
	parameter. Allowed values are as follows:		parameter. Allowed values are as follows:
	0: drop		0: drop
	1: shape		1: shape
	2: remark		2: remark
	3: no metering or policing is permitted		3: no metering or policing is permitted
	The default excess treatment in case that none is specified is that		The default excess treatment in case that none is specified is that
	there are no guarantees to excess traffic, i.e., a QoS aware node can		there are no guarantees to excess traffic, i.e., a QoS aware node can
	do what it finds suitable.		do what it finds suitable.
	skipping to change at page 13, line 11		skipping to change at page 12, line 15
	packets arrive marked as belonging to a certain QoS class, and when		packets arrive marked as belonging to a certain QoS class, and when
	they are identified as excess, they should then be remarked to a		they are identified as excess, they should then be remarked to a
	different QoS Class.		different QoS Class.
	If 'no metering or policing is permitted' is signaled, the QoS aware		If 'no metering or policing is permitted' is signaled, the QoS aware
	node should accept the excess treatment parameter set by the sender		node should accept the excess treatment parameter set by the sender
	with special care so that excess traffic should not cause a problem.		with special care so that excess traffic should not cause a problem.
	To request the Null Meter [RFC3290] is especially strong, and should		To request the Null Meter [RFC3290] is especially strong, and should
	be used with caution.		be used with caution.
			The Remark Value is an 8 bit unsigned integer value in network byte
			order.
	4.13. PHB Class Parameter		4.13. PHB Class Parameter
	A description of the semantic of the parameter values can be found in		A description of the semantic of the parameter values can be found in
	[RFC3140]. The coding for the <PHB Class> parameter is as follows:		[RFC3140]. The coding for the <PHB Class> parameter is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|M|r|r|r| 12 |r|r|r|r| 1 |		|M|r|r|r| 12 |r|r|r|r| 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 16, line 39		skipping to change at page 15, line 46
	vendor field are 0x00000000, then the value is standards-specified		vendor field are 0x00000000, then the value is standards-specified
	and the registry is maintained by IANA, and any other value		and the registry is maintained by IANA, and any other value
	represents a vendor-specific Object Identifier (OID). IANA created		represents a vendor-specific Object Identifier (OID). IANA created
	registry is split into two value ranges; one range uses the		registry is split into two value ranges; one range uses the
	"Standards Action" and the second range uses "Specification Required"		"Standards Action" and the second range uses "Specification Required"
	allocation policy. The latter range is meant to be used by		allocation policy. The latter range is meant to be used by
	organizations outside the IETF.		organizations outside the IETF.
	6. IANA Considerations		6. IANA Considerations
	This document reuses the namespace created in [I-D.ietf-nsis-qspec]		This section defines the registries and initial codepoint
	for		assignments, in accordance with BCP 26 RFC 2434 [RFC2434]. It also
	1. Admission Priority Parameter		defines the procedural requirements to be followed by IANA in
	2. RPH Namespace Parameter		allocating new codepoints.
	3. RPH Priority Parameter
	4. Excess Treatment Parameter
	5. DSTE Class Type Parameter
	6. Y.1541 QoS Class Parameter
	IANA is requested to create the following registries: QoS Profile (32		IANA is requested to create the following registries listed in the
	bits), and Parameter ID (12 bits)		subsections below.
	6.1. QoS Profile		6.1. QoS Profile
	The QoS Profile refers to a 64 bit long field that is represented by		The QoS Profile refers to a 64 bit long field that is represented by
	a 4-octet vendor and 4-octet specifier field. The vendor field		a 4-octet vendor and 4-octet specifier field. The vendor field
	indicates the type as either standards-specified or vendor-specific.		indicates the type as either standards-specified or vendor-specific.
	If the four octets of the vendor field are 0x00000000, then the value		If the four octets of the vendor field are 0x00000000, then the value
	is standards-specified and the registry is maintained by IANA, and		is standards-specified and the registry is maintained by IANA, and
	any other value represents a vendor-specific Object Identifier (OID).		any other value represents a vendor-specific Object Identifier (OID).
	skipping to change at page 18, line 14		skipping to change at page 17, line 14
	(0): <TMOD-1>		(0): <TMOD-1>
	(1): <TMOD-2>		(1): <TMOD-2>
	(2): <Path Latency>		(2): <Path Latency>
	(3): <Path Jitter>		(3): <Path Jitter>
	(4): <Path PLR>		(4): <Path PLR>
	(5): <Path PER>		(5): <Path PER>
	(6): <Slack Term>		(6): <Slack Term>
	(7): <Preemption Priority> & <Defending Priority>		(7): <Preemption Priority> & <Defending Priority>
	(8): <Admission Priority>		(8): <Admission Priority>
	(9): <RPH Priority>		(9): <ALRP>
	(10): <Excess Treatment>		(10): <Excess Treatment>
	(11): <PHB Class>		(11): <PHB Class>
	(12): <DSTE Class Type>		(12): <DSTE Class Type>
	(13): <Y.1541 QoS Class>		(13): <Y.1541 QoS Class>
	The allocation policies for further values are as follows:		The allocation policies for further values are as follows:
	14-127: Standards Action		14-127: Standards Action
	128-255: Private/Experimental Use		128-255: Private/Experimental Use
	255-4095: Specification Required		255-4095: Specification Required
	A standards track document is required to depreciate, delete, or		A standards track document is required to depreciate, delete, or
	modify existing Parameter IDs.		modify existing Parameter IDs.
			6.3. Admission Priority Parameter
			The Admission Priority parameter refers to a 8 bit long field.
			The following values are allocated by this specification:
			Admission Priority 0: best-effort priority flow
			Admission Priority 1: normal priority flow
			Admission Priority 2: high priority flow
			Admission Priority 3-63: Standards Action
			Admission Priority 64-255: Reserved
			6.4. Excess Treatment Parameter
			The Excess Treatment parameter refers to an 8 bit long field.
			The following values are allocated by this specification:
			Excess Treatment Value 0: drop
			Excess Treatment Value 1: shape
			Excess Treatment Value 2: remark
			Excess Treatment Value3: no metering or policing is permitted
			Excess Treatment Values 4-63: Standards Action
			Excess Treatment Value 64-255: Reserved
			The 8 bit Remark Value allocation policies are as follows:
			0-63: Specification Required
			64-127: Private/Experimental Use
			128-255: Reserved
			6.5. DSTE Class Type Parameter
			The DSTE Class Type parameter refers to an 8 bit long field.
			The following values are allocated by this specification:
			DSTE Class Type Value 0: DSTE Class Type 0
			DSTE Class Type Value 1: DSTE Class Type 1
			DSTE Class Type Value 2: DSTE Class Type 2
			DSTE Class Type Value 3: DSTE Class Type 3
			DSTE Class Type Value 4: DSTE Class Type 4
			DSTE Class Type Value 5: DSTE Class Type 5
			DSTE Class Type Value 6: DSTE Class Type 6
			DSTE Class Type Value 7: DSTE Class Type 7
			DSTE Class Type Values 8-63: Standards Action
			DSTE Class Type Values 64-255: Reserved
			6.6. Y.1541 QoS Class Parameter
			The Y.1541 QoS Class parameter refers to an 8 bit long field.
			The following values are allocated by this specification:
			Y.1541 QoS Class Value 0: Y.1541 QoS Class 0
			Y.1541 QoS Class Value 1: Y.1541 QoS Class 1
			Y.1541 QoS Class Value 2: Y.1541 QoS Class 2
			Y.1541 QoS Class Value 3: Y.1541 QoS Class 3
			Y.1541 QoS Class Value 4: Y.1541 QoS Class 4
			Y.1541 QoS Class Value 5: Y.1541 QoS Class 5
			Y.1541 QoS Class Value 6: Y.1541 QoS Class 6
			Y.1541 QoS Class Value 7: Y.1541 QoS Class 7
			Y.1541 QoS Class Values 8-63: Standards Action
			Y.1541 QoS Class Values 64-255: Reserved
			The ALRP Namespace and ALRP Priority field inside the ALRP Parameter
			take their values from the registry created by [RFC4412] and extended
			with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions are
			required by IANA by this specification.
	7. Security Considerations		7. Security Considerations
	This document does not raise any security concerns as it only defines		This document does not raise any security concerns as it only defines
	QoS parameters.		QoS parameters.
	8. Acknowledgements		8. Acknowledgements
	The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec]		The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec]
	authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the		authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the
	NSIS working group chairs (John Loughney and Martin Stiemerling) and		NSIS working group chairs (John Loughney and Martin Stiemerling) and
	the former Transport Area Directors (Allison Manking, Jon Peterson)		the former Transport Area Directors (Allison Mankin, Jon Peterson)
	for their help.		for their help.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
			[I-D.ietf-tsvwg-emergency-rsvp]
			Faucheur, F., "Resource ReSerVation Protovol (RSVP)
			Extensions for Emergency Services",
			draft-ietf-tsvwg-emergency-rsvp-05 (work in progress),
			January 2008.
	[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, March 1997.
	[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated		[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
	Services", RFC 2210, September 1997.		Services", RFC 2210, September 1997.
	[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification		[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
	of Guaranteed Quality of Service", RFC 2212,		of Guaranteed Quality of Service", RFC 2212,
	September 1997.		September 1997.
	skipping to change at page 20, line 9		skipping to change at page 20, line 31
	Diffserv-aware MPLS Traffic Engineering", RFC 4124,		Diffserv-aware MPLS Traffic Engineering", RFC 4124,
	June 2005.		June 2005.
	[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource		[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
	Priority for the Session Initiation Protocol (SIP)",		Priority for the Session Initiation Protocol (SIP)",
	RFC 4412, February 2006.		RFC 4412, February 2006.
	[Y.1541] "Network Performance Objectives for IP-Based Services", ,		[Y.1541] "Network Performance Objectives for IP-Based Services", ,
	2006.		2006.
			[Y.1571] "Admission Control Priority Levels in Next Generation
			Networks", , July 2006.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-nsis-qspec]		[I-D.ietf-nsis-qspec]
	Ash, J., "QoS NSLP QSPEC Template",		Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP
	draft-ietf-nsis-qspec-17 (work in progress), July 2007.		QSPEC Template", draft-ietf-nsis-qspec-18 (work in
			progress), October 2007.
			[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 2434,
			October 1998.
	[Y.1540] "Internet Protocol Data Communication Service - IP Packet		[Y.1540] "Internet Protocol Data Communication Service - IP Packet
	Transfer and Availability Performance Parameters", ,		Transfer and Availability Performance Parameters", ,
	December 2002.		December 2002.
	Authors' Addresses		Authors' Addresses
	Jouni Korhonen (editor)		Jouni Korhonen (editor)
	TeliaSonera		TeliaSonera
	Teollisuuskatu 13		Teollisuuskatu 13
	skipping to change at page 21, line 7		skipping to change at page 22, line 7
	Nokia Siemens Networks		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
	Germany		Germany
	Email: Hannes.Tschofenig@nsn.com		Email: Hannes.Tschofenig@nsn.com
	URI: http://www.tschofenig.com		URI: http://www.tschofenig.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 29 change blocks.
	96 lines changed or deleted		137 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/