draft-ietf-dime-qos-parameters-11.txt		rfc5624.txt
	Diameter Maintenance and J. Korhonen, Ed.		Network Working Group J. Korhonen, Ed.
	Extensions (DIME) H. Tschofenig		Request for Comments: 5624 H. Tschofenig
	Internet-Draft Nokia Siemens Networks		Category: Standards Track Nokia Siemens Networks
	Intended status: Standards Track E. Davies		E. Davies
	Expires: November 26, 2009 Folly Consulting		Folly Consulting
	May 25, 2009		August 2009
	Quality of Service Parameters for Usage with Diameter		Quality of Service Parameters for Usage with Diameter
	draft-ietf-dime-qos-parameters-11.txt
	Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 26, 2009.
	Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights
	and restrictions with respect 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, a bandwidth parameter, and a per-		describing a token bucket filter, a bandwidth parameter, and a per-
	hop behavior class object.		hop behavior class object.
			Status of This Memo
			This document specifies an Internet standards track protocol for the
			Internet community, and requests discussion and suggestions for
			improvements. Please refer to the current edition of the "Internet
			Official Protocol Standards" (STD 1) for the standardization state
			and status of this protocol. Distribution of this memo is unlimited.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4		2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
	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. Token-Rate AVP . . . . . . . . . . . . . . . . . . . . 4		3.1.1. Token-Rate AVP . . . . . . . . . . . . . . . . . . . . 4
	3.1.2. Bucket-Depth AVP . . . . . . . . . . . . . . . . . . . 4		3.1.2. Bucket-Depth AVP . . . . . . . . . . . . . . . . . . . 4
	3.1.3. Peak-Traffic-Rate AVP . . . . . . . . . . . . . . . . 4		3.1.3. Peak-Traffic-Rate AVP . . . . . . . . . . . . . . . . 4
	3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 5		3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4
	3.1.5. Maximum-Packet-Size AVP . . . . . . . . . . . . . . . 5		3.1.5. Maximum-Packet-Size AVP . . . . . . . . . . . . . . . 4
	3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5		3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5
	3.4. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 5		3.4. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 5
	3.4.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 5		3.4.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 5
	3.4.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 6		3.4.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 5
	3.4.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 6		3.4.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 6
	4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Appendix A. ABNF Code Fragment . . . . . . . . . . . . . . . . . 11
	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 [RFC3588]. The current set of QoS parameters defined in		protocol [RFC3588]. The current set of QoS parameters defined in
	this document are a core subset determined to be useful for a wide		this document are a core subset determined to be useful for a wide
	range of applications. Additional parameters may be defined in		range of applications. Additional parameters may be defined in
	future documents as the need arises and are for future study. The		future documents as the need arises and are for future study. The
	parameters are defined as Diameter encoded Attribute Value Pairs		parameters are defined as Diameter-encoded Attribute Value Pairs
	(AVPs) described using a modified version of the Augmented Backus-		(AVPs), which are described using a modified version of the Augmented
	Naur Form (ABNF), see [RFC3588]. The datatypes are also taken from		Backus-Naur Form (ABNF), see [RFC3588]. The data types are also
	[RFC3588].		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 provide a way to describe the traffic source.
	o token rate (r)		o token rate (r)
	o bucket depth (b)		o bucket depth (b)
	o peak traffic rate (p)		o peak traffic rate (p)
	o minimum policed unit (m)		o minimum policed unit (m)
	o maximum packet size (M)		o maximum packet size (M)
	The encoding of the <TMOD-1> and the <TMOD-2> AVP can be found in		The encoding of the <TMOD-1> and the <TMOD-2> AVPs can be found in
	Section 3.1 and Section 3.2. The semantics of these two AVPs are		Sections 3.1 and 3.2. The semantics of these two AVPs are described
	described in Section 3.1 of [RFC2210] and in Section 3.6 of		in Section 3.1 of [RFC2210] and in Section 3.6 of [RFC2215].
	[RFC2215].
	The <TMOD-2> AVP is, for example, needed by some DiffServ		The <TMOD-2> AVP is, for example, needed by some DiffServ
	applications.		applications.
	It is typically assumed that DiffServ EF traffic is 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].
	Resource reservations might refer to a packet processing with a		It is typically assumed that DiffServ expedited forwarding (EF)
			traffic is 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 assured forwarding
			(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 processor with a
	particular DiffServ per-hop behavior (PHB) (using the <PHB-Class>		particular DiffServ per-hop behavior (PHB) (using the <PHB-Class>
	AVP). A generic description of the DiffServ architecture can be		AVP). A generic description of the DiffServ architecture can be
	found in [RFC2475] and the Differentiated Services Field is described		found in [RFC2475], and the Differentiated Services Field is
	in Section 3 of [RFC2474]. Updated terminology can be found in		described in Section 3 of [RFC2474]. Updated terminology can be
	[RFC3260]. Standardized Per-Hop Behavior is, for example, described		found in [RFC3260]. Standardized per-hop behavior is, for example,
	in [RFC2597] (Assured Forwarding Per-Hop Behavior) and in [RFC3246]		described in [RFC2597] ("Assured Forwarding PHB Group") and in
	(An Expedited Forwarding Per-Hop Behavior).		[RFC3246] ("An Expedited Forwarding PHB").
	The above-mentioned parameters are intended to support basic		The above-mentioned parameters are intended to support basic
	integrated and differentiated services functionality in the network.		integrated and differentiated services functionality in the network.
	Additional parameters can be defined and standardized if required to		Additional parameters can be defined and standardized if required to
	support specific services in future.		support specific services in the 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: 495 >
	{ Token-Rate }		{ Token-Rate }
	{ Bucket-Depth }		{ Bucket-Depth }
	{ Peak-Traffic-Rate }		{ Peak-Traffic-Rate }
	{ Minimum-Policed-Unit }		{ Minimum-Policed-Unit }
	{ Maximum-Packet-Size }		{ Maximum-Packet-Size }
	3.1.1. Token-Rate AVP		3.1.1. Token-Rate AVP
	The Token-Rate AVP (AVP Code TBD) is of type Float32.		The Token-Rate AVP (AVP Code 496) is of type Float32.
	3.1.2. Bucket-Depth AVP		3.1.2. Bucket-Depth AVP
	The Bucket-Depth AVP (AVP Code TBD) is of type Float32.		The Bucket-Depth AVP (AVP Code 497) is of type Float32.
	3.1.3. Peak-Traffic-Rate AVP		3.1.3. Peak-Traffic-Rate AVP
	The Peak-Traffic-Rate AVP (AVP Code TBD) is of type Float32.		The Peak-Traffic-Rate AVP (AVP Code 498) is of type Float32.
	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.		The Minimum-Policed-Unit AVP (AVP Code 499) is of type Unsigned32.
	3.1.5. Maximum-Packet-Size AVP		3.1.5. Maximum-Packet-Size AVP
	The Maximum-Packet-Size AVP (AVP Code TBD) is of type Unsigned32.		The Maximum-Packet-Size AVP (AVP Code 500) 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 semantics of the parameter values can be found
	[RFC2215]. The coding for the TMOD-2 AVP is as follows:		in [RFC2215]. The coding for the TMOD-2 AVP is as follows:
	TMOD-2 ::= < AVP Header: TBD >		TMOD-2 ::= < AVP Header: 501 >
	{ Token-Rate }		{ Token-Rate }
	{ Bucket-Depth }		{ Bucket-Depth }
	{ Peak-Traffic-Rate }		{ Peak-Traffic-Rate }
	{ Minimum-Policed-Unit }		{ Minimum-Policed-Unit }
	{ Maximum-Packet-Size }		{ 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 502) is of type Float32 and is measured
	in octets of IP datagrams per second. The Bandwidth AVP represents a		in octets of IP datagrams per second. The Bandwidth AVP represents a
	simplified description of the following TMOD setting whereby the		simplified description of the following TMOD setting whereby the
	token rate (r) = peak traffic rate (p), the bucket depth (b) = large,		token rate (r) = peak traffic rate (p), the bucket depth (b) = large,
	minimum policed unit (m) = large when only bandwidth has to be		and the minimum policed unit (m) = large when only bandwidth has to
	expressed.		be expressed.
	3.4. 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 503) is of type Unsigned32.
	A description of the semantic of the parameter values can be found in		A description of the semantics of the parameter values can be found
	[RFC3140]. The registries needed for usage with [RFC3140] already		in [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 a new registry is not required for this purpose. The
	The encoding requires three cases need to be differentiated. All		encoding requires that three cases be differentiated. All bits
	bits indicated as "reserved" MUST be set to zero (0).		indicated as "reserved" MUST be set to zero (0).
	3.4.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 Differentiated Services Code Point (DSCP) value for that
	field, with bits 6 through 15 set to zero.		PHB, left-justified in the 16-bit 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.4.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.4.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 may not be defined by standards actions i.e., experimental or
	PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB		local use PHBs as allowed by [RFC2474]. In this case, an arbitrary
	identification code, assigned by the IANA, is placed left-justified		12-bit PHB identification code, assigned by the IANA, is left-
	in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a		justified in the 16-bit field. Bit 15 is set to 1, and bit 14 is
	single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero.		zero for a 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, future use.
	In both cases, when a single PHBID is used to identify a set of PHBs		In both cases, when a single PHBID is used to identify a set of PHBs
	(i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB		(i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB
	Scheduling Class (i.e., use of PHBs from the set MUST NOT cause		Scheduling Class (i.e., use of PHBs from the set MUST NOT cause
	intra-microflow traffic reordering when different PHBs from the set		intra-microflow traffic reordering when different PHBs from the set
	are applied to traffic in the same microflow). The set of AF1x PHBs		are applied to traffic in the same microflow). The set of AF1x PHBs
	[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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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 defining 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 a 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
	parameters might be needed, or where the parameters specified in this		additional parameters might be needed or where the parameters
	document are used with a different semantic. In that case it is		specified in this document are used with different semantics. In
	advisable to define a new QoS profile that may consist of new		that case, it is advisable to define a new QoS profile that may
	parameters in addition to parameters defined in this document or an		consist of new parameters in addition to parameters defined in this
	entirely different set of parameters. Finally, it is also possible		document or an entirely different set of parameters. Finally, it is
	to register a specific QoS profile that defines a specific set of QoS		also possible to register a specific QoS profile that defines a
	values rather than parameters that need to be filled with values in		specific set of QoS values rather than parameters that need to be
	order to be used.		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, an 8-octet registry is
	defined field that is represented by a 4-octet vendor and 4-octet		defined as a field that is represented by 4-octet vendor and 4-octet
	specifier field. The vendor field contains an Enterprise Number as		specifier fields. The vendor field contains an Enterprise Number as
	defined in [RFC2578] taken from the values maintained in the IANA		defined in [RFC2578], taken from the values maintained in the IANA
	Enterprise Numbers registry. If the four octets of the vendor field		Enterprise Numbers registry. If the four octets of the vendor field
	are 0x00000000 (reserved value for IANA), then the value in the		are 0x00000000 (reserved value for IANA), then the value in the
	specifier field MUST be registered with IANA (see Section 5.2). If		specifier field MUST be registered with IANA (see Section 5.2). If
	the vendor field is other than 0x00000000, the value of the specifier		the vendor field is other than 0x00000000, the value of the specifier
	field represents a vendor-specific value, where allocation is the		field represents a vendor-specific value, where allocation is the
	responsibility of the enterprise indicated in the vendor field.		responsibility of the enterprise indicated in the vendor field.
	5. IANA Considerations		5. IANA Considerations
	5.1. AVP Codes		5.1. AVP Codes
	IANA is requested to allocate AVP codes in the IETF IANA controlled		IANA allocated AVP codes in the IANA-controlled namespace registry
	namespace registry specified in Section 11.1.1 of [RFC3588] for the		specified in Section 11.1.1 of [RFC3588] for the following AVPs that
	following AVPs that are defined in this document.		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 495 3.1 Grouped |
	|Token-Rate TBD 3.1.1 Float32 |		|Token-Rate 496 3.1.1 Float32 |
	|Bucket-Depth TBD 3.1.2 Float32 |		|Bucket-Depth 497 3.1.2 Float32 |
	|Peak-Traffic-Rate TBD 3.1.3 Float32 |		|Peak-Traffic-Rate 498 3.1.3 Float32 |
	|Minimum-Policed-Unit TBD 3.1.4 Unsigned32 |		|Minimum-Policed-Unit 499 3.1.4 Unsigned32 |
	|Maximum-Packet-Size TBD 3.1.5 Unsigned32 |		|Maximum-Packet-Size 500 3.1.5 Unsigned32 |
	|TMOD-2 TBD 3.2 Grouped |		|TMOD-2 501 3.2 Grouped |
	|Bandwidth TBD 3.3 Float32 |		|Bandwidth 502 3.3 Float32 |
	|PHB-Class TBD 3.7 Unsigned32 |		|PHB-Class 503 3.4 Unsigned32 |
	+------------------------------------------------------------------+		+------------------------------------------------------------------+
	5.2. QoS Profile		5.2. QoS Profile
	The QoS Profile refers to a 64 bit long field that is represented by		The QoS profile refers to a 64-bit field that is represented by
	a 4-octet vendor and 4-octet specifier field. The vendor field		4-octet vendor and 4-octet specifier fields. 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 a registry will be created to maintain the		is standards-specified and a registry will be created to maintain the
	QoS profile specifier values. The specifier field indicates the		QoS profile specifier values. The specifier field indicates the
	actual QoS profile. Depending on the value requested, the action		actual QoS profile. Depending on the value requested, the action
	needed to request a new value is:		needed to request a new value is:
	0 to 511: Standards Action		0 to 511: Standards Action
	512 to 32767: Specification Required		512 to 32767: Specification Required
	32768 to 4294967295: Reserved
			32768 to 4294967295: Reserved
	Standards action is required to add, depreciate, delete, or modify		Standards action is required to add, depreciate, delete, or modify
	QoS profile values in the range of 0-511 and a specification is		QoS profile values in the range of 0-511, and a specification is
	required to add, depreciate, delete, or modify existing QoS profile		required to add, depreciate, delete, or modify existing QoS profile
	values in the range of 512-32767.		values in the range of 512-32767.
	This document requests IANA to create such a registry and to allocate		IANA created such a registry and allocated the value zero (0) for the
	the value zero (0) for the QoS profile defined in this document.		QoS profile defined in this document.
	Alternative vendor-specific QoS profiles can be created and		Alternative vendor-specific QoS profiles can be created and
	identified with a Enterprise Number taken from the IANA registry		identified with an Enterprise Number taken from the IANA registry
	created by [RFC2578] in the vendor field combined with a vendor-		created by [RFC2578] in the vendor field, combined with a vendor-
	specific value in the specifier field. Allocation of the specifier		specific value in the specifier field. Allocation of the specifier
	values is the responsibility of the vendor.		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 an
	AAA protocol. Security considerations are described in documents		Authentication, Authorization, and Accounting (AAA) protocol.
	using this specification.		Security considerations are described in documents using this
			specification.
	7. Acknowledgements		7. Acknowledgements
	The authors would like to thank the NSIS working group members		The authors would like to thank the NSIS working group members
	Cornelia Kappler, Jerry Ash, Attila Bader, and Dave Oran, the former		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 and Jon Peterson
	for their help.		for their help.
	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 Dolly, Martin Stiemerling, and Magnus Westerlund for		Polk, Martin Dolly, Martin Stiemerling, and Magnus Westerlund for
	their feedback regarding some of the parameters in this documents.		their feedback regarding some of the parameters in this documents.
	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 semantics 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. Chris Newman, Adrian Farrel and Pasi Eronen provided		review. Chris Newman, Adrian Farrel, and Pasi Eronen provided
	feedback during the IESG review.		feedback during the IESG review.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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
	skipping to change at page 10, line 33		skipping to change at page 11, line 5
	Marker", RFC 2697, September 1999.		Marker", RFC 2697, September 1999.
	[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,		[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
	J., Courtney, W., Davari, S., Firoiu, V., and D.		J., Courtney, W., Davari, S., Firoiu, V., and D.
	Stiliadis, "An Expedited Forwarding PHB (Per-Hop		Stiliadis, "An Expedited Forwarding PHB (Per-Hop
	Behavior)", RFC 3246, March 2002.		Behavior)", RFC 3246, March 2002.
	[RFC3260] Grossman, D., "New Terminology and Clarifications for		[RFC3260] Grossman, D., "New Terminology and Clarifications for
	Diffserv", RFC 3260, April 2002.		Diffserv", RFC 3260, April 2002.
			Appendix A. ABNF Code Fragment
			Copyright (c) 2009 IETF Trust and the persons identified as authors
			of the code. All rights reserved.
			Redistribution and use in source and binary forms, with or without
			modification, are permitted provided that the following conditions
			are met:
			o Redistributions of source code must retain the above copyright
			notice, this list of conditions and the following disclaimer.
			o Redistributions in binary form must reproduce the above copyright
			notice, this list of conditions and the following disclaimer in
			the documentation and/or other materials provided with the
			distribution.
			o Neither the name of Internet Society, IETF or IETF Trust, nor the
			names of specific contributors, may be used to endorse or promote
			products derived from this software without specific prior written
			permission.
			THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
			'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
			LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
			A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
			OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
			SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
			LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
			DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
			THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
			(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
			OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
			TMOD-1 ::= < AVP Header: 495 >
			{ Token-Rate }
			{ Bucket-Depth }
			{ Peak-Traffic-Rate }
			{ Minimum-Policed-Unit }
			{ Maximum-Packet-Size }
			TMOD-2 ::= < AVP Header: 501 >
			{ Token-Rate }
			{ Bucket-Depth }
			{ Peak-Traffic-Rate }
			{ Minimum-Policed-Unit }
			{ Maximum-Packet-Size }
	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
	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		Elwyn Davies
	Folly Consulting		Folly Consulting
	Soham		Soham
	UK		UK
	Phone: +44 7889 488 335		Phone: +44 7889 488 335
	Email: elwynd@dial.pipex.com		EMail: elwynd@dial.pipex.com
End of changes. 56 change blocks.
	156 lines changed or deleted		187 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/