draft-ietf-dime-qos-parameters-08.txt		draft-ietf-dime-qos-parameters-09.txt
	Diameter Maintenance and J. Korhonen, Ed.		Diameter Maintenance and J. Korhonen, Ed.
	Extensions (DIME) H. Tschofenig		Extensions (DIME) H. Tschofenig
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Intended status: Standards Track December 18, 2008		Intended status: Standards Track E. Davies
	Expires: June 21, 2009		Expires: July 26, 2009 Folly Consulting
			January 22, 2009
	Quality of Service Parameters for Usage with Diameter		Quality of Service Parameters for Usage with Diameter
	draft-ietf-dime-qos-parameters-08.txt		draft-ietf-dime-qos-parameters-09.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 33		skipping to change at page 1, line 34
	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 June 21, 2009.		This Internet-Draft will expire on July 26, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2008 IETF Trust and the persons identified as the		Copyright (c) 2009 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.		to this document.
	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 Diameter.		that can be reused for conveying QoS information within Diameter.
	The payloads used to carry these QoS parameters are opaque for the		The defined QoS information includes data traffic parameters for
	AAA client and the AAA server itself and interpreted by the		describing a token bucket filter, bandwidth, defending and preemption
	respective Resource Management Function.		priority, admission priority, application-level resource priority,
			per-hop behavior class, and DiffServ-aware Multiprotocol Label
			Switching (MPLS) traffic engineering.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4		2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
	3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4		3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4
	3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1.1. TMOD-Rate AVP . . . . . . . . . . . . . . . . . . . . 4		3.1.1. TMOD-Rate AVP . . . . . . . . . . . . . . . . . . . . 4
	3.1.2. TMOD-Size AVP . . . . . . . . . . . . . . . . . . . . 4		3.1.2. TMOD-Size AVP . . . . . . . . . . . . . . . . . . . . 4
	3.1.3. Peak-Data-Rate AVP . . . . . . . . . . . . . . . . . . 4		3.1.3. Peak-Data-Rate AVP . . . . . . . . . . . . . . . . . . 4
	3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4		3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4
	3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 5		3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5
	3.3.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 5		3.4. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 5		3.4.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 5
	3.4. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 5		3.4.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 5
	3.5. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.5. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 5
	3.5.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 6		3.6. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.5.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 6		3.6.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 6
	3.6. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 6		3.6.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 6
	3.6.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 6		3.7. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 6
	3.6.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 7		3.7.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 6
	3.6.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 7		3.7.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 7
	3.7. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 7		3.7.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 7
			3.8. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 8
	4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . . 11		8.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	skipping to change at page 5, line 17		skipping to change at page 5, line 17
	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
	[RFC2215]. The TMOD-2 AVP is useful in a DiffServ environment. The		[RFC2215]. The TMOD-2 AVP is useful in a DiffServ environment. The
	coding for the TMOD-2 AVP is as follows:		coding for the TMOD-2 AVP is as follows:
	TMOD-2 ::= < AVP Header: TBD >		TMOD-2 ::= < AVP Header: TBD >
	{ TMOD-Rate }		{ TMOD-Rate }
	{ TMOD-Size }		{ TMOD-Size }
	{ Peak-Data-Rate }		{ Peak-Data-Rate }
	{ Minimum-Policed-Unit }		{ Minimum-Policed-Unit }
	3.3. Priority AVP		3.3. Bandwidth AVP
			The Bandwidth AVP (AVP Code TBD) is of type Float32 and is measured
			in bytes of IP datagrams per second.
			3.4. Priority AVP
	The Priority AVP is a grouped AVP consisting of two AVPs, the		The Priority AVP is a grouped AVP consisting of two AVPs, the
	Preemption-Priority and the Defending-Priority AVP. A description of		Preemption-Priority and the Defending-Priority AVP. A description of
	the semantic can be found in [RFC3181].		the semantic can be found in [RFC3181].
	Priority ::= < AVP Header: TBD >		Priority ::= < AVP Header: TBD >
	{ Preemption-Priority }		{ Preemption-Priority }
	{ Defending-Priority }		{ Defending-Priority }
	3.3.1. Preemption-Priority AVP		3.4.1. Preemption-Priority AVP
	The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and		The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and
	it indicates the priority of the new flow compared with the defending		it indicates the priority of the new flow compared with the defending
	priority of previously admitted flows. Higher values represent		priority of previously admitted flows. Higher values represent
	higher priority.		higher priority.
	3.3.2. Defending-Priority AVP		3.4.2. Defending-Priority AVP
	The Defending-Priority AVP (AVP Code TBD) is of type Unsigned32.		The Defending-Priority AVP (AVP Code TBD) is of type Unsigned32.
	Once a flow is admitted, the preemption priority becomes irrelevant.		Once a flow is admitted, the preemption priority becomes irrelevant.
	Instead, its defending priority is used to compare with the		Instead, its defending priority is used to compare with the
	preemption priority of new flows.		preemption priority of new flows.
	3.4. Admission-Priority AVP		3.5. Admission-Priority AVP
	The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32.		The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32.
	The admission control priority of the flow, in terms of access to		The admission control priority of the flow, in terms of access to
	network bandwidth in order to provide higher probability of call		network bandwidth in order to provide higher probability of call
	completion to selected flows. Higher values represent higher		completion to selected flows. Higher values represent higher
	priority. A given admission priority is encoded in this information		priority. A given admission priority is encoded in this information
	element using the same value as when encoded in the Admission-		element using the same value as when encoded in the Admission-
	Priority AVP defined in Section 3.1 of		Priority AVP defined in Section 3.1 of
	[I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter).		[I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter).
	3.5. ALRP AVP		3.6. ALRP AVP
	The Application-Level Resource Priority (ALRP) AVP is a grouped AVP		The Application-Level Resource Priority (ALRP) AVP is a grouped AVP
	consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP.		consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP.
	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] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for		[RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for
	parameter is as follows:		parameter is as follows:
	ALRP ::= < AVP Header: TBD >		ALRP ::= < AVP Header: TBD >
	{ ALRP-Namespace }		{ ALRP-Namespace }
	{ ALRP-Priority }		{ ALRP-Priority }
	3.5.1. ALRP-Namespace AVP		3.6.1. ALRP-Namespace AVP
	The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32.		The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32.
	3.5.2. ALRP-Priority AVP		3.6.2. ALRP-Priority AVP
	The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32.		The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32.
	[RFC4412] defines a resource priority header and established the		[RFC4412] defines a resource priority header and established the
	initial registry. That registry was later extended by		initial registry. That registry was later extended by
	[I-D.ietf-tsvwg-emergency-rsvp].		[I-D.ietf-tsvwg-emergency-rsvp].
	3.6. PHB-Class AVP		3.7. PHB-Class AVP
	The PHB-Class AVP (AVP Code TBD) is of type Unsigned32.		The PHB-Class AVP (AVP Code TBD) is of type Unsigned32.
	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 registries needed for usage with [RFC3140] already		[RFC3140]. The registries needed for usage with [RFC3140] already
	exist and hence no new registry needs to be created by this document.		exist and hence no new registry needs to be created by this document.
	The encoding requires three cases need to be differentiated. All		The encoding requires three cases need to be differentiated. All
	bits indicated as "reserved" MUST be set to zero (0).		bits indicated as "reserved" MUST be set to zero (0).
	3.6.1. Case 1: Single PHB		3.7.1. Case 1: Single PHB
	As prescribed in [RFC3140], the encoding for a single PHB is the		As prescribed in [RFC3140], the encoding for a single PHB is the
	recommended DSCP value for that PHB, left-justified in the 16 bit		recommended DSCP value for that PHB, left-justified in the 16 bit
	field, with bits 6 through 15 set to zero.		field, with bits 6 through 15 set to zero.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) |		| DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3.6.2. Case 2: Set of PHBs		3.7.2. Case 2: Set of PHBs
	The encoding for a set of PHBs is the numerically smallest of the set		The encoding for a set of PHBs is the numerically smallest of the set
	of encodings for the various PHBs in the set, with bit 14 set to 1.		of encodings for the various PHBs in the set, with bit 14 set to 1.
	(Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with		(Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with
	bit 14 set to 1.)		bit 14 set to 1.)
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) |		| DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3.6.3. Case 3: Experimental or Local Use PHBs		3.7.3. Case 3: Experimental or Local Use PHBs
	PHBs not defined by standards action, i.e., experimental or local use		PHBs not defined by standards action, i.e., experimental or local use
	PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB		PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB
	identification code, assigned by the IANA, is placed left-justified		identification code, assigned by the IANA, is placed left-justified
	in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a		in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a
	single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero.		single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero.
	Bits 12 and 13 are reserved either for expansion of the PHB		Bits 12 and 13 are reserved either for expansion of the PHB
	identification code, or for other use, at some point in the future.		identification code, or for other use, at some point in the future.
	skipping to change at page 7, line 44		skipping to change at page 8, line 5
	[RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that		[RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that
	do not constitute a PHB Scheduling Class can be identified by using		do not constitute a PHB Scheduling Class can be identified by using
	more than one PHBID.		more than one PHBID.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PHD ID CODE |0 0 1 0| (Reserved) |		| PHD ID CODE |0 0 1 0| (Reserved) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3.7. DSTE-Class-Type AVP		3.8. DSTE-Class-Type AVP
	The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A		The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A
	description of the semantic of the parameter values can be found in		description of the semantic of the parameter values can be found in
	[RFC4124].		[RFC4124].
	Currently, the values of alues currently allowed are 1, 2, 3, 4, 5,		Currently, the values of alues currently allowed are 1, 2, 3, 4, 5,
	6, 7. The value of zero (0) is marked as reserved in [RFC4124].		6, 7. The value of zero (0) is marked as reserved in [RFC4124].
	Furthermore, the CLASSTYPE attribute in [RFC4124] is 32 bits in		Furthermore, the CLASSTYPE attribute in [RFC4124] is 32 bits in
	length with 29 bits reserved.		length with 29 bits reserved.
	4. Extensibility		4. Extensibility
	This document is designed with extensibility in mind given that		This document is designed with extensibility in mind given that
	different organizations and groups are used to define their own		different organizations and groups are used to define their own
	Quality of Service parameters. This document provides an initial QoS		Quality of Service parameters. This document provides an initial QoS
	profile with common set of parameters. Ideally, these parameters		profile with common set of parameters. Ideally, these parameters
	should be used whenever possible but there are cases where additional		should be used whenever possible but there are cases where additional
	parameters might be needed, or where the parameters specified in this		parameters might be needed, or where the parameters specified in this
	document are used with a different semantic. In this case it is		document are used with a different semantic. In that case it is
	advisable to define a new QoS profile that may consist of new		advisable to define a new QoS profile that may consist of new
	parameters in addition to parameters defined in this document or an		parameters in addition to parameters defined in this document or an
	entirely different set of parameters.		entirely different set of parameters. Finally, it is also possible
			to register a specific QoS profile that defines a specific set of QoS
			values rather than parameters that need to be filled with values in
			order to be used.
	To enable the definition of new QoS profiles a 8 octet registry is		To enable the definition of new QoS profiles a 8 octet registry is
	defined field that is represented by a 4-octet vendor and 4-octet		defined field that is represented by a 4-octet vendor and 4-octet
	specifier field. The vendor field indicates the type as either		specifier field. The vendor field indicates the type as either
	standards-specified or vendor-specific. If the four octets of the		standards-specified or vendor-specific. If the four octets of the
	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 as Enterprise Numbers defined		and the registry is maintained by IANA as Enterprise Numbers defined
	in [RFC2578], and any other value represents a vendor-specific Object		in [RFC2578], and any other value represents a vendor-specific Object
	Identifier (OID). IANA created registry is split into two value		Identifier (OID). IANA created registry is split into two value
	ranges; one range uses the "Standards Action" and the second range		ranges; one range uses the "Standards Action" and the second range
	skipping to change at page 9, line 15		skipping to change at page 9, line 15
	+------------------------------------------------------------------+		+------------------------------------------------------------------+
	| AVP Section |		| AVP Section |
	|AVP Name Code Defined Data Type |		|AVP Name Code Defined Data Type |
	+------------------------------------------------------------------+		+------------------------------------------------------------------+
	|TMOD-1 TBD 3.1 Grouped |		|TMOD-1 TBD 3.1 Grouped |
	|TMOD-Rate TBD 3.1.1 Float32 |		|TMOD-Rate TBD 3.1.1 Float32 |
	|TMOD-Size TBD 3.1.2 Float32 |		|TMOD-Size TBD 3.1.2 Float32 |
	|Peak-Data-Rate TBD 3.1.3 Float32 |		|Peak-Data-Rate TBD 3.1.3 Float32 |
	|Minimum-Policed-Unit TBD 3.1.4 Unsigned32 |		|Minimum-Policed-Unit TBD 3.1.4 Unsigned32 |
	|TMOD-2 TBD 3.2 Grouped |		|TMOD-2 TBD 3.2 Grouped |
	|Priority TBD 3.3 Grouped |		|Bandwidth TBD 3.3 Float32 |
	|Preemption-Priority TBD 3.3.1 Unsigned32 |		|Priority TBD 3.4 Grouped |
	|Defending-Priority TBD 3.3.2 Unsigned32 |		|Preemption-Priority TBD 3.4.1 Unsigned32 |
	|Admission-Priority TBD 3.4 Unsigned32 |		|Defending-Priority TBD 3.4.2 Unsigned32 |
	|ALRP TBD 3.5 Grouped |		|Admission-Priority TBD 3.5 Unsigned32 |
	|ALRP-Namespace TBD 3.5.1 Unsigned32 |		|ALRP TBD 3.6 Grouped |
	|ALRP-Priority TBD 3.5.2 Unsigned32 |		|ALRP-Namespace TBD 3.6.1 Unsigned32 |
	|PHB-Class TBD 3.6 Unsigned32 |		|ALRP-Priority TBD 3.6.2 Unsigned32 |
	|DSTE-Class-Type TBD 3.7 Unsigned32 |		|PHB-Class TBD 3.7 Unsigned32 |
			|DSTE-Class-Type TBD 3.8 Unsigned32 |
	+------------------------------------------------------------------+		+------------------------------------------------------------------+
	5.2. QoS Profile		5.2. QoS Profile
	IANA is requested to create the following registry.		IANA is requested to create the following registry.
	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
	skipping to change at page 10, line 20		skipping to change at page 10, line 21
	QoS parameters and does not yet describe how they are exchanged in a		QoS parameters and does not yet describe how they are exchanged in a
	AAA protocol. Security considerations are described in documents		AAA protocol. Security considerations are described in documents
	using this specification.		using this specification.
	7. Acknowledgements		7. 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 Mankin, Jon Peterson)		the former Transport Area Directors (Allison Mankin, Jon Peterson)
	for their help. This document re-uses content from the NSIS QSPEC		for their help. The authors of this document are thankful for the
	[I-D.ietf-nsis-qspec] specification.		suggestions and input received from the NSIS QSPEC
			[I-D.ietf-nsis-qspec] authors.
	We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt,		We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt,
	Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James		Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James
	Polk, Martin Stiemerling, and Magnus Westerlund for their help with		Polk, Martin Stiemerling, and Magnus Westerlund for their help with
	resolving problems regarding the Admission Priority and the ALRP		resolving problems regarding the Admission Priority and the ALRP
	parameter.		parameter.
	Elwyn Davies provided a detailed review of the specification. Elwyn		Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu provided
	helped to investigate what QoS mechanisms are deployed in networks		help with the semantic of some QSPEC parameters.
	today. Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu
	provided help with the semantic of some QSPEC parameters.
	We would like to thank Dan Romascanu for his detailed Area Director		We would like to thank Dan Romascanu for his detailed Area Director
	review comments and Scott Bradner for his Transport Area Directorate		review comments and Scott Bradner for his Transport Area Directorate
	review.		review.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-tsvwg-emergency-rsvp]		[I-D.ietf-tsvwg-emergency-rsvp]
	skipping to change at line 533		skipping to change at page 12, line 37
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
			Elwyn Davies
			Folly Consulting
			Soham
			UK
			Phone: +44 7889 488 335
			Email: elwynd@dial.pipex.com
End of changes. 24 change blocks.
	49 lines changed or deleted		61 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/