draft-ietf-dime-qos-parameters-09.txt		draft-ietf-dime-qos-parameters-10.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 E. Davies		Intended status: Standards Track E. Davies
	Expires: July 26, 2009 Folly Consulting		Expires: September 10, 2009 Folly Consulting
	January 22, 2009		March 9, 2009
	Quality of Service Parameters for Usage with Diameter		Quality of Service Parameters for Usage with Diameter
	draft-ietf-dime-qos-parameters-09.txt		draft-ietf-dime-qos-parameters-10.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 34		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 July 26, 2009.		This Internet-Draft will expire on September 10, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 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 in effect on the date of
	(http://trustee.ietf.org/license-info) in effect on the date of		publication of this document (http://trustee.ietf.org/license-info).
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		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 defined QoS information includes data traffic parameters for		The defined QoS information includes data traffic parameters for
	describing a token bucket filter, bandwidth, defending and preemption		describing a token bucket filter, a bandwidth parameter, and a per-
	priority, admission priority, application-level resource priority,		hop behavior class object.
	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. Token-Rate AVP . . . . . . . . . . . . . . . . . . . . 4
	3.1.2. TMOD-Size AVP . . . . . . . . . . . . . . . . . . . . 4		3.1.2. Bucket-Depth AVP . . . . . . . . . . . . . . . . . . . 4
	3.1.3. Peak-Data-Rate AVP . . . . . . . . . . . . . . . . . . 4		3.1.3. Peak-Traffic-Rate AVP . . . . . . . . . . . . . . . . 4
	3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4		3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4
			3.1.5. Maximum-Packet-Size AVP . . . . . . . . . . . . . . . 5
	3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5		3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5
	3.4. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 5		3.4. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 5
	3.4.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 5		3.4.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 5
	3.4.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 5		3.4.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 6
	3.5. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 5		3.4.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 6
	3.6. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.6.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	3.6.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	3.7. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	3.7.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.7.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	3.7.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . . 9
	3.8. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	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 the Diameter		that can be reused for conveying QoS information within the Diameter
	protocol.		protocol [RFC3588]. It defines an initial QoS profile containing a
			set of Diameter encoded Attribute Value Pairs (AVPs) described using
	This document defines an initial QoS profile containing a set of QoS		a modified version of the Augmented Backus-Naur Form (ABNF), see
	AVPs.		[RFC3588]. The datatypes are also taken from [RFC3588].
	The traffic model (TMOD) AVPs are containers consisting of four AVPs		The traffic model (TMOD) AVPs are containers consisting of four AVPs
	and is a way to describe the traffic source.		and is a way to describe the traffic source.
	o rate (r)		o token rate (r)
	o bucket size (b)		o bucket depth (b)
	o peak rate (p)		o peak traffic rate (p)
	o minimum policed unit (m)		o minimum policed unit (m)
			o maximum packet size (M)
	The encoding of <TMOD-1> and <TMOD-2> can be found in Section 3.1 and		The encoding of the <TMOD-1> and the <TMOD-2> AVP can be found in
	Section 3.2 and the semantic is described in [RFC2210] and in		Section 3.1 and Section 3.2. The semantics of these two AVPs are
	[RFC2215]. <TMOD-2> is, for example, needed by some DiffServ		described in Section 3.1 of [RFC2210] and in Section 3.6 of
	applications. It is typically assumed that DiffServ EF traffic is		[RFC2215].
	shaped at the ingress by a single rate token bucket. Therefore, a
	single TMOD parameter is sufficient to signal DiffServ EF traffic.
	However, for DiffServ AF traffic two sets of token bucket parameters
	are needed, one token bucket for the average traffic and one token
	bucket for the burst traffic. [RFC2697] defines a Single Rate Three
	Color Marker (srTCM), which meters a traffic stream and marks its
	packets according to three traffic parameters, Committed Information
	Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS),
	to be either green, yellow, or red. A packet is marked green if it
	does not exceed the CBS, yellow if it does exceed the CBS, but not
	the EBS, and red otherwise. [RFC2697] defines specific procedures
	using two token buckets that run at the same rate. Therefore, two
	TMOD AVPs are sufficient to distinguish among three levels of drop
	precedence. An example is also described in the appendix of
	[RFC2597].
	The <Preemption-Priority> AVP refers to the priority of a new flow
	compared with the <Defending-Priority> AVP of previously admitted
	flows. Once a flow is admitted, the preemption priority becomes
	irrelevant. The <Defending-Priority> AVP is used to compare with the
	preemption priority of new flows. For any specific flow, its
	preemption priority is always less than or equal to the defending
	priority.
	The <Admission-Priority> AVP and <ALRP> AVP provide an essential way		The <TMOD-2> AVP is, for example, needed by some DiffServ
	to differentiate flows for emergency services, ETS, E911, etc., and		applications.
	assign them a higher admission priority than normal priority flows		It is typically assumed that DiffServ EF traffic is shaped at the
	and best-effort priority flows.		ingress by a single rate token bucket. Therefore, a single TMOD
			parameter is sufficient to signal DiffServ EF traffic. However,
			for DiffServ AF traffic two sets of token bucket parameters are
			needed, one token bucket for the average traffic and one token
			bucket for the burst traffic. [RFC2697] defines a Single Rate
			Three Color Marker (srTCM), which meters a traffic stream and
			marks its packets according to three traffic parameters, Committed
			Information Rate (CIR), Committed Burst Size (CBS), and Excess
			Burst Size (EBS), to be either green, yellow, or red. A packet is
			marked green if it does not exceed the CBS, yellow if it does
			exceed the CBS, but not the EBS, and red otherwise. [RFC2697]
			defines specific procedures using two token buckets that run at
			the same rate. Therefore, two TMOD AVPs are sufficient to
			distinguish among three levels of drop precedence. An example is
			also described in the appendix of [RFC2597].
	Resource reservations might refer to a packet processing with a		Resource reservations might refer to a packet processing with a
	particular DiffServ per-hop behavior (PHB) [RFC2475] (using the <PHB-		particular DiffServ per-hop behavior (PHB) (using the <PHB-Class>
	Class> AVP) or to a particular QoS class, e.g., a DiffServ-aware MPLS		AVP). A generic description of the DiffServ architecture can be
	traffic engineering (DSTE) class type, as described in [RFC3564] and		found in [RFC2475] and the Differentiated Services Field is described
	in [RFC4124], using the <DSTE-Class-Type> AVP.		in Section 3 of [RFC2474]. Updated terminology can be found in
			[RFC3260]. Standardized Per-Hop Behavior is, for example, described
			in [RFC2597] (Assured Forwarding Per-Hop Behavior) and in [RFC3246]
			(An Expedited Forwarding Per-Hop Behavior).
			The above-mentioned parameters are intended to support basic
			integrated and differentiated services functionality in the network.
			Additional parameters can be defined and standardized if required to
			support specific services in future.
	2. Terminology and Abbreviations		2. Terminology and Abbreviations
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119 [RFC2119].		document are to be interpreted as described in RFC2119 [RFC2119].
	3. QoS Parameter Encoding		3. QoS Parameter Encoding
	3.1. TMOD-1 AVP		3.1. TMOD-1 AVP
	The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The		The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The
	structure of the AVP is as follows:		structure of the AVP is as follows:
	TMOD-1 ::= < AVP Header: TBD >		TMOD-1 ::= < AVP Header: TBD >
	{ TMOD-Rate }		{ Token-Rate }
	{ TMOD-Size }		{ Bucket-Depth }
	{ Peak-Data-Rate }		{ Peak-Traffic-Rate }
	{ Minimum-Policed-Unit }		{ Minimum-Policed-Unit }
			{ Maximum-Packet-Size }
	3.1.1. TMOD-Rate AVP		3.1.1. Token-Rate AVP
	The TMOD-Rate AVP (AVP Code TBD) is of type Float32 and contains the		The Token-Rate AVP (AVP Code TBD) is of type Float32.
	rate (r).
	3.1.2. TMOD-Size AVP		3.1.2. Bucket-Depth AVP
	The TMOD-Size AVP (AVP Code TBD) is of type Float32 and contains the		The Bucket-Depth AVP (AVP Code TBD) is of type Float32.
	bucket size (b).
	3.1.3. Peak-Data-Rate AVP		3.1.3. Peak-Traffic-Rate AVP
	The Peak-Data-Rate AVP (AVP Code TBD) is of type Float32 and contains		The Peak-Traffic-Rate AVP (AVP Code TBD) is of type Float32.
	the peak rate (p).
	3.1.4. Minimum-Policed-Unit AVP		3.1.4. Minimum-Policed-Unit AVP
	The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32 and		The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32.
	contains the minimum policed unit (m).
			3.1.5. Maximum-Packet-Size AVP
			The Maximum-Packet-Size AVP (AVP Code TBD) is of type Unsigned32.
	3.2. TMOD-2 AVP		3.2. TMOD-2 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
	[RFC2215]. The TMOD-2 AVP is useful in a DiffServ environment. The		[RFC2215]. 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 }		{ Token-Rate }
	{ TMOD-Size }		{ Bucket-Depth }
	{ Peak-Data-Rate }		{ Peak-Traffic-Rate }
	{ Minimum-Policed-Unit }		{ Minimum-Policed-Unit }
			{ Maximum-Packet-Size }
	3.3. Bandwidth AVP		3.3. Bandwidth AVP
	The Bandwidth AVP (AVP Code TBD) is of type Float32 and is measured		The Bandwidth AVP (AVP Code TBD) is of type Float32 and is measured
	in bytes of IP datagrams per second.		in octets of IP datagrams per second.
	3.4. Priority AVP
	The Priority AVP is a grouped AVP consisting of two AVPs, the
	Preemption-Priority and the Defending-Priority AVP. A description of
	the semantic can be found in [RFC3181].
	Priority ::= < AVP Header: TBD >
	{ Preemption-Priority }
	{ Defending-Priority }
	3.4.1. Preemption-Priority AVP
	The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and
	it indicates the priority of the new flow compared with the defending
	priority of previously admitted flows. Higher values represent
	higher priority.
	3.4.2. Defending-Priority AVP
	The Defending-Priority AVP (AVP Code TBD) is of type Unsigned32.
	Once a flow is admitted, the preemption priority becomes irrelevant.
	Instead, its defending priority is used to compare with the
	preemption priority of new flows.
	3.5. Admission-Priority AVP
	The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32.
	The admission control priority of the flow, in terms of access to
	network bandwidth in order to provide higher probability of call
	completion to selected flows. Higher values represent higher
	priority. A given admission priority is encoded in this information
	element using the same value as when encoded in the Admission-
	Priority AVP defined in Section 3.1 of
	[I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter).
	3.6. ALRP AVP
	The Application-Level Resource Priority (ALRP) AVP is a grouped 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
	[RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for
	parameter is as follows:
	ALRP ::= < AVP Header: TBD >
	{ ALRP-Namespace }
	{ ALRP-Priority }
	3.6.1. ALRP-Namespace AVP
	The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32.
	3.6.2. ALRP-Priority AVP
	The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32.
	[RFC4412] defines a resource priority header and established the
	initial registry. That registry was later extended by
	[I-D.ietf-tsvwg-emergency-rsvp].
	3.7. PHB-Class AVP		3.4. 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.7.1. Case 1: Single PHB		3.4.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.7.2. Case 2: Set of PHBs		3.4.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.7.3. Case 3: Experimental or Local Use PHBs		3.4.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 8, line 5		skipping to change at page 6, line 44
	[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.8. DSTE-Class-Type AVP
	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
	[RFC4124].
	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].
	Furthermore, the CLASSTYPE attribute in [RFC4124] is 32 bits in
	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 defining 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 that 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. Finally, it is also possible		entirely different set of parameters. Finally, it is also possible
	to register a specific QoS profile that defines a specific set of QoS		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		values rather than parameters that need to be filled with values in
	order to be used.		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 contains an Enterprise Number as
	standards-specified or vendor-specific. If the four octets of the		defined in [RFC2578] taken from the values maintained in the IANA
	vendor field are 0x00000000, then the value is standards-specified		Enterprise Numbers registry. If the four octets of the vendor field
	and the registry is maintained by IANA as Enterprise Numbers defined		are 0x00000000 (reserved value for IANA), then the value in the
	in [RFC2578], and any other value represents a vendor-specific Object		specifier field MUST be registered with IANA (see Section 5.2). If
	Identifier (OID). IANA created registry is split into two value		the vendor field is other than 0x00000000, the value of the specifier
	ranges; one range uses the "Standards Action" and the second range		field represents a vendor-specific value, where allocation is the
	uses "Specification Required" allocation policy. The latter range is		responsibility of the enterprise indicated in the vendor field.
	meant to be used by organizations outside the IETF.
	5. IANA Considerations		5. IANA Considerations
	5.1. AVP Codes		5.1. AVP Codes
	IANA is requested to allocate AVP codes for the following AVPs that		IANA is requested to allocate AVP codes in the IETF IANA controlled
	are defined in this document.		namespace registry specified in Section 11.1.1 of [RFC3588] for the
			following AVPs that are defined in this document.
	+------------------------------------------------------------------+		+------------------------------------------------------------------+
	| 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 |		|Token-Rate TBD 3.1.1 Float32 |
	|TMOD-Size TBD 3.1.2 Float32 |		|Bucket-Depth TBD 3.1.2 Float32 |
	|Peak-Data-Rate TBD 3.1.3 Float32 |		|Peak-Traffic-Rate TBD 3.1.3 Float32 |
	|Minimum-Policed-Unit TBD 3.1.4 Unsigned32 |		|Minimum-Policed-Unit TBD 3.1.4 Unsigned32 |
			|Maximum-Packet-Size TBD 3.1.5 Unsigned32 |
	|TMOD-2 TBD 3.2 Grouped |		|TMOD-2 TBD 3.2 Grouped |
	|Bandwidth TBD 3.3 Float32 |		|Bandwidth TBD 3.3 Float32 |
	|Priority TBD 3.4 Grouped |
	|Preemption-Priority TBD 3.4.1 Unsigned32 |
	|Defending-Priority TBD 3.4.2 Unsigned32 |
	|Admission-Priority TBD 3.5 Unsigned32 |
	|ALRP TBD 3.6 Grouped |
	|ALRP-Namespace TBD 3.6.1 Unsigned32 |
	|ALRP-Priority TBD 3.6.2 Unsigned32 |
	|PHB-Class 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.
	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
	is standards-specified and the registry is maintained by IANA, and
	any other value represents a vendor-specific Object Identifier (OID).
	The specifier field indicates the actual QoS profile. The vendor		If the four octets of the vendor field are 0x00000000, then the value
	field 0x00000000 is reserved to indicate that the values in the		is standards-specified and a registry will be created to maintain the
	specifier field are maintained by IANA. This document requests IANA		QoS profile specifier values. The specifier field indicates the
	to create such a registry and to allocate the value zero (0) for the		actual QoS profile. Depending on the value requested, the action
	QoS profile defined in this document.		needed to request a new value is:
			0 to 511: Standards Action
			512 to 32767: Specification Required
			32768 to 4294967295: Reserved
	For any other vendor field, the specifier field is maintained by the		Standards action is required to add, depreciate, delete, or modify
	vendor.		QoS profile values in the range of 0-511 and a specification is
			required to add, depreciate, delete, or modify existing QoS profile
			values in the range of 512-32767.
	For the IANA maintained QoS profiles the following allocation policy		This document requests IANA to create such a registry and to allocate
	is defined:		the value zero (0) for the QoS profile defined in this document.
	0 to 511: Standards Action
	512 to 4095: Specification Required
	Standards action is required to depreciate, delete, or modify		Alternative vendor-specific QoS profiles can be created and
	existing QoS profile values in the range of 0-511 and a specification		identified with a Enterprise Number taken from the IANA registry
	is required to depreciate, delete, or modify existing QoS profile		created by [RFC2578] in the vendor field combined with a vendor-
	values in the range of 512-4095.		specific value in the specifier field. Allocation of the specifier
			values is the responsibility of the vendor.
	6. Security Considerations		6. 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 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 working group members
	authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the		Cornelia Kappler, Jerry Ash, Attila Bader, and Dave Oran, the former
	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. The authors of this document are thankful for the		for their help.
	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 Dolly, Martin Stiemerling, and Magnus Westerlund for
	resolving problems regarding the Admission Priority and the ALRP		their feedback regarding some of the parameters in this documents.
	parameter.
	Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu provided		Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu provided
	help with the semantic of some QSPEC parameters.		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. Chris Newman and Pasi Eronen provided feedback during the
			IESG review.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-tsvwg-emergency-rsvp]
	Faucheur, F., Polk, J., and K. Carlberg, "Resource
	ReSerVation Protovol (RSVP) Extensions for Emergency
	Services", draft-ietf-tsvwg-emergency-rsvp-09 (work in
	progress), October 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.
	[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization		[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization
	Parameters for Integrated Service Network Elements",		Parameters for Integrated Service Network Elements",
	RFC 2215, September 1997.		RFC 2215, September 1997.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	"Definition of the Differentiated Services Field (DS		"Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		Field) in the IPv4 and IPv6 Headers", RFC 2474,
	December 1998.		December 1998.
	[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.		[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
	Schoenwaelder, Ed., "Structure of Management Information		Schoenwaelder, Ed., "Structure of Management Information
	Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.		Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
	[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
	"Assured Forwarding PHB Group", RFC 2597, June 1999.
	[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,		[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
	"Per Hop Behavior Identification Codes", RFC 3140,		"Per Hop Behavior Identification Codes", RFC 3140,
	June 2001.		June 2001.
	[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",		[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
	RFC 3181, October 2001.		Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
	[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
	Diffserv-aware MPLS Traffic Engineering", RFC 4124,
	June 2005.
	[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
	Priority for the Session Initiation Protocol (SIP)",
	RFC 4412, February 2006.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-nsis-qspec]
	Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC
	Template", draft-ietf-nsis-qspec-21 (work in progress),
	November 2008.
	[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,		[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
	and W. Weiss, "An Architecture for Differentiated		and W. Weiss, "An Architecture for Differentiated
	Services", RFC 2475, December 1998.		Services", RFC 2475, December 1998.
			[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
			"Assured Forwarding PHB Group", RFC 2597, June 1999.
	[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color		[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
	Marker", RFC 2697, September 1999.		Marker", RFC 2697, September 1999.
	[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An		[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
	Informal Management Model for Diffserv Routers", RFC 3290,		J., Courtney, W., Davari, S., Firoiu, V., and D.
	May 2002.		Stiliadis, "An Expedited Forwarding PHB (Per-Hop
			Behavior)", RFC 3246, March 2002.
	[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of
	Differentiated Services-aware MPLS Traffic Engineering",
	RFC 3564, July 2003.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC3260] Grossman, D., "New Terminology and Clarifications for
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		Diffserv", RFC 3260, April 2002.
	May 2008.
	Authors' Addresses		Authors' Addresses
	Jouni Korhonen (editor)		Jouni Korhonen (editor)
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Email: jouni.korhonen@nsn.com		Email: jouni.korhonen@nsn.com
End of changes. 56 change blocks.
	260 lines changed or deleted		146 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/