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/ |