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/