draft-ietf-dime-qos-parameters-09.txt | draft-ietf-dime-qos-parameters-10.txt | |||
---|---|---|---|---|
Diameter Maintenance and J. Korhonen, Ed. | Diameter Maintenance and J. Korhonen, Ed. | |||
Extensions (DIME) H. Tschofenig | Extensions (DIME) H. Tschofenig | |||
Internet-Draft Nokia Siemens Networks | Internet-Draft Nokia Siemens Networks | |||
Intended status: Standards Track E. Davies | Intended status: Standards Track E. Davies | |||
Expires: July 26, 2009 Folly Consulting | Expires: September 10, 2009 Folly Consulting | |||
January 22, 2009 | March 9, 2009 | |||
Quality of Service Parameters for Usage with Diameter | Quality of Service Parameters for Usage with Diameter | |||
draft-ietf-dime-qos-parameters-09.txt | draft-ietf-dime-qos-parameters-10.txt | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 1, line 34 | skipping to change at page 1, line 34 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on July 26, 2009. | This Internet-Draft will expire on September 10, 2009. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents in effect on the date of | |||
(http://trustee.ietf.org/license-info) in effect on the date of | publication of this document (http://trustee.ietf.org/license-info). | |||
publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. | |||
to this document. | ||||
Abstract | Abstract | |||
This document defines a number of Quality of Service (QoS) parameters | This document defines a number of Quality of Service (QoS) parameters | |||
that can be reused for conveying QoS information within Diameter. | that can be reused for conveying QoS information within Diameter. | |||
The defined QoS information includes data traffic parameters for | The defined QoS information includes data traffic parameters for | |||
describing a token bucket filter, bandwidth, defending and preemption | describing a token bucket filter, a bandwidth parameter, and a per- | |||
priority, admission priority, application-level resource priority, | hop behavior class object. | |||
per-hop behavior class, and DiffServ-aware Multiprotocol Label | ||||
Switching (MPLS) traffic engineering. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 | 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 | |||
3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4 | 3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1.1. TMOD-Rate AVP . . . . . . . . . . . . . . . . . . . . 4 | 3.1.1. Token-Rate AVP . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1.2. TMOD-Size AVP . . . . . . . . . . . . . . . . . . . . 4 | 3.1.2. Bucket-Depth AVP . . . . . . . . . . . . . . . . . . . 4 | |||
3.1.3. Peak-Data-Rate AVP . . . . . . . . . . . . . . . . . . 4 | 3.1.3. Peak-Traffic-Rate AVP . . . . . . . . . . . . . . . . 4 | |||
3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4 | 3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4 | |||
3.1.5. Maximum-Packet-Size AVP . . . . . . . . . . . . . . . 5 | ||||
3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5 | 3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.4. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.4. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.4.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 5 | 3.4.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 5 | |||
3.4.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 5 | 3.4.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 6 | |||
3.5. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 5 | 3.4.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 6 | |||
3.6. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.6.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 6 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.6.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 6 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
3.7. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 6 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.7.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 6 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.7.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 7 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 | |||
3.7.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 7 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 | |||
3.8. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 8 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 | ||||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | ||||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | ||||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | ||||
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
1. Introduction | 1. Introduction | |||
This document defines a number of Quality of Service (QoS) parameters | This document defines a number of Quality of Service (QoS) parameters | |||
that can be reused for conveying QoS information within the Diameter | that can be reused for conveying QoS information within the Diameter | |||
protocol. | protocol [RFC3588]. It defines an initial QoS profile containing a | |||
set of Diameter encoded Attribute Value Pairs (AVPs) described using | ||||
This document defines an initial QoS profile containing a set of QoS | a modified version of the Augmented Backus-Naur Form (ABNF), see | |||
AVPs. | [RFC3588]. The datatypes are also taken from [RFC3588]. | |||
The traffic model (TMOD) AVPs are containers consisting of four AVPs | The traffic model (TMOD) AVPs are containers consisting of four AVPs | |||
and is a way to describe the traffic source. | and is a way to describe the traffic source. | |||
o rate (r) | o token rate (r) | |||
o bucket size (b) | o bucket depth (b) | |||
o peak rate (p) | o peak traffic rate (p) | |||
o minimum policed unit (m) | o minimum policed unit (m) | |||
o maximum packet size (M) | ||||
The encoding of <TMOD-1> and <TMOD-2> can be found in Section 3.1 and | The encoding of the <TMOD-1> and the <TMOD-2> AVP can be found in | |||
Section 3.2 and the semantic is described in [RFC2210] and in | Section 3.1 and Section 3.2. The semantics of these two AVPs are | |||
[RFC2215]. <TMOD-2> is, for example, needed by some DiffServ | described in Section 3.1 of [RFC2210] and in Section 3.6 of | |||
applications. It is typically assumed that DiffServ EF traffic is | [RFC2215]. | |||
shaped at the ingress by a single rate token bucket. Therefore, a | ||||
single TMOD parameter is sufficient to signal DiffServ EF traffic. | ||||
However, for DiffServ AF traffic two sets of token bucket parameters | ||||
are needed, one token bucket for the average traffic and one token | ||||
bucket for the burst traffic. [RFC2697] defines a Single Rate Three | ||||
Color Marker (srTCM), which meters a traffic stream and marks its | ||||
packets according to three traffic parameters, Committed Information | ||||
Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), | ||||
to be either green, yellow, or red. A packet is marked green if it | ||||
does not exceed the CBS, yellow if it does exceed the CBS, but not | ||||
the EBS, and red otherwise. [RFC2697] defines specific procedures | ||||
using two token buckets that run at the same rate. Therefore, two | ||||
TMOD AVPs are sufficient to distinguish among three levels of drop | ||||
precedence. An example is also described in the appendix of | ||||
[RFC2597]. | ||||
The <Preemption-Priority> AVP refers to the priority of a new flow | ||||
compared with the <Defending-Priority> AVP of previously admitted | ||||
flows. Once a flow is admitted, the preemption priority becomes | ||||
irrelevant. The <Defending-Priority> AVP is used to compare with the | ||||
preemption priority of new flows. For any specific flow, its | ||||
preemption priority is always less than or equal to the defending | ||||
priority. | ||||
The <Admission-Priority> AVP and <ALRP> AVP provide an essential way | The <TMOD-2> AVP is, for example, needed by some DiffServ | |||
to differentiate flows for emergency services, ETS, E911, etc., and | applications. | |||
assign them a higher admission priority than normal priority flows | It is typically assumed that DiffServ EF traffic is shaped at the | |||
and best-effort priority flows. | ingress by a single rate token bucket. Therefore, a single TMOD | |||
parameter is sufficient to signal DiffServ EF traffic. However, | ||||
for DiffServ AF traffic two sets of token bucket parameters are | ||||
needed, one token bucket for the average traffic and one token | ||||
bucket for the burst traffic. [RFC2697] defines a Single Rate | ||||
Three Color Marker (srTCM), which meters a traffic stream and | ||||
marks its packets according to three traffic parameters, Committed | ||||
Information Rate (CIR), Committed Burst Size (CBS), and Excess | ||||
Burst Size (EBS), to be either green, yellow, or red. A packet is | ||||
marked green if it does not exceed the CBS, yellow if it does | ||||
exceed the CBS, but not the EBS, and red otherwise. [RFC2697] | ||||
defines specific procedures using two token buckets that run at | ||||
the same rate. Therefore, two TMOD AVPs are sufficient to | ||||
distinguish among three levels of drop precedence. An example is | ||||
also described in the appendix of [RFC2597]. | ||||
Resource reservations might refer to a packet processing with a | Resource reservations might refer to a packet processing with a | |||
particular DiffServ per-hop behavior (PHB) [RFC2475] (using the <PHB- | particular DiffServ per-hop behavior (PHB) (using the <PHB-Class> | |||
Class> AVP) or to a particular QoS class, e.g., a DiffServ-aware MPLS | AVP). A generic description of the DiffServ architecture can be | |||
traffic engineering (DSTE) class type, as described in [RFC3564] and | found in [RFC2475] and the Differentiated Services Field is described | |||
in [RFC4124], using the <DSTE-Class-Type> AVP. | in Section 3 of [RFC2474]. Updated terminology can be found in | |||
[RFC3260]. Standardized Per-Hop Behavior is, for example, described | ||||
in [RFC2597] (Assured Forwarding Per-Hop Behavior) and in [RFC3246] | ||||
(An Expedited Forwarding Per-Hop Behavior). | ||||
The above-mentioned parameters are intended to support basic | ||||
integrated and differentiated services functionality in the network. | ||||
Additional parameters can be defined and standardized if required to | ||||
support specific services in future. | ||||
2. Terminology and Abbreviations | 2. Terminology and Abbreviations | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC2119 [RFC2119]. | document are to be interpreted as described in RFC2119 [RFC2119]. | |||
3. QoS Parameter Encoding | 3. QoS Parameter Encoding | |||
3.1. TMOD-1 AVP | 3.1. TMOD-1 AVP | |||
The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The | The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The | |||
structure of the AVP is as follows: | structure of the AVP is as follows: | |||
TMOD-1 ::= < AVP Header: TBD > | TMOD-1 ::= < AVP Header: TBD > | |||
{ TMOD-Rate } | { Token-Rate } | |||
{ TMOD-Size } | { Bucket-Depth } | |||
{ Peak-Data-Rate } | { Peak-Traffic-Rate } | |||
{ Minimum-Policed-Unit } | { Minimum-Policed-Unit } | |||
{ Maximum-Packet-Size } | ||||
3.1.1. TMOD-Rate AVP | 3.1.1. Token-Rate AVP | |||
The TMOD-Rate AVP (AVP Code TBD) is of type Float32 and contains the | The Token-Rate AVP (AVP Code TBD) is of type Float32. | |||
rate (r). | ||||
3.1.2. TMOD-Size AVP | 3.1.2. Bucket-Depth AVP | |||
The TMOD-Size AVP (AVP Code TBD) is of type Float32 and contains the | The Bucket-Depth AVP (AVP Code TBD) is of type Float32. | |||
bucket size (b). | ||||
3.1.3. Peak-Data-Rate AVP | 3.1.3. Peak-Traffic-Rate AVP | |||
The Peak-Data-Rate AVP (AVP Code TBD) is of type Float32 and contains | The Peak-Traffic-Rate AVP (AVP Code TBD) is of type Float32. | |||
the peak rate (p). | ||||
3.1.4. Minimum-Policed-Unit AVP | 3.1.4. Minimum-Policed-Unit AVP | |||
The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32 and | The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32. | |||
contains the minimum policed unit (m). | ||||
3.1.5. Maximum-Packet-Size AVP | ||||
The Maximum-Packet-Size AVP (AVP Code TBD) is of type Unsigned32. | ||||
3.2. TMOD-2 AVP | 3.2. TMOD-2 AVP | |||
A description of the semantic of the parameter values can be found in | A description of the semantic of the parameter values can be found in | |||
[RFC2215]. The TMOD-2 AVP is useful in a DiffServ environment. The | [RFC2215]. The coding for the TMOD-2 AVP is as follows: | |||
coding for the TMOD-2 AVP is as follows: | ||||
TMOD-2 ::= < AVP Header: TBD > | TMOD-2 ::= < AVP Header: TBD > | |||
{ TMOD-Rate } | { Token-Rate } | |||
{ TMOD-Size } | { Bucket-Depth } | |||
{ Peak-Data-Rate } | { Peak-Traffic-Rate } | |||
{ Minimum-Policed-Unit } | { Minimum-Policed-Unit } | |||
{ Maximum-Packet-Size } | ||||
3.3. Bandwidth AVP | 3.3. Bandwidth AVP | |||
The Bandwidth AVP (AVP Code TBD) is of type Float32 and is measured | The Bandwidth AVP (AVP Code TBD) is of type Float32 and is measured | |||
in bytes of IP datagrams per second. | in octets of IP datagrams per second. | |||
3.4. Priority AVP | ||||
The Priority AVP is a grouped AVP consisting of two AVPs, the | ||||
Preemption-Priority and the Defending-Priority AVP. A description of | ||||
the semantic can be found in [RFC3181]. | ||||
Priority ::= < AVP Header: TBD > | ||||
{ Preemption-Priority } | ||||
{ Defending-Priority } | ||||
3.4.1. Preemption-Priority AVP | ||||
The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and | ||||
it indicates the priority of the new flow compared with the defending | ||||
priority of previously admitted flows. Higher values represent | ||||
higher priority. | ||||
3.4.2. Defending-Priority AVP | ||||
The Defending-Priority AVP (AVP Code TBD) is of type Unsigned32. | ||||
Once a flow is admitted, the preemption priority becomes irrelevant. | ||||
Instead, its defending priority is used to compare with the | ||||
preemption priority of new flows. | ||||
3.5. Admission-Priority AVP | ||||
The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. | ||||
The admission control priority of the flow, in terms of access to | ||||
network bandwidth in order to provide higher probability of call | ||||
completion to selected flows. Higher values represent higher | ||||
priority. A given admission priority is encoded in this information | ||||
element using the same value as when encoded in the Admission- | ||||
Priority AVP defined in Section 3.1 of | ||||
[I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter). | ||||
3.6. ALRP AVP | ||||
The Application-Level Resource Priority (ALRP) AVP is a grouped AVP | ||||
consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP. | ||||
A description of the semantic of the parameter values can be found in | ||||
[RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for | ||||
parameter is as follows: | ||||
ALRP ::= < AVP Header: TBD > | ||||
{ ALRP-Namespace } | ||||
{ ALRP-Priority } | ||||
3.6.1. ALRP-Namespace AVP | ||||
The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. | ||||
3.6.2. ALRP-Priority AVP | ||||
The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32. | ||||
[RFC4412] defines a resource priority header and established the | ||||
initial registry. That registry was later extended by | ||||
[I-D.ietf-tsvwg-emergency-rsvp]. | ||||
3.7. PHB-Class AVP | 3.4. PHB-Class AVP | |||
The PHB-Class AVP (AVP Code TBD) is of type Unsigned32. | The PHB-Class AVP (AVP Code TBD) is of type Unsigned32. | |||
A description of the semantic of the parameter values can be found in | A description of the semantic of the parameter values can be found in | |||
[RFC3140]. The registries needed for usage with [RFC3140] already | [RFC3140]. The registries needed for usage with [RFC3140] already | |||
exist and hence no new registry needs to be created by this document. | exist and hence no new registry needs to be created by this document. | |||
The encoding requires three cases need to be differentiated. All | The encoding requires three cases need to be differentiated. All | |||
bits indicated as "reserved" MUST be set to zero (0). | bits indicated as "reserved" MUST be set to zero (0). | |||
3.7.1. Case 1: Single PHB | 3.4.1. Case 1: Single PHB | |||
As prescribed in [RFC3140], the encoding for a single PHB is the | As prescribed in [RFC3140], the encoding for a single PHB is the | |||
recommended DSCP value for that PHB, left-justified in the 16 bit | recommended DSCP value for that PHB, left-justified in the 16 bit | |||
field, with bits 6 through 15 set to zero. | field, with bits 6 through 15 set to zero. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | | | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
3.7.2. Case 2: Set of PHBs | 3.4.2. Case 2: Set of PHBs | |||
The encoding for a set of PHBs is the numerically smallest of the set | The encoding for a set of PHBs is the numerically smallest of the set | |||
of encodings for the various PHBs in the set, with bit 14 set to 1. | of encodings for the various PHBs in the set, with bit 14 set to 1. | |||
(Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with | (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with | |||
bit 14 set to 1.) | bit 14 set to 1.) | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) | | | DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
3.7.3. Case 3: Experimental or Local Use PHBs | 3.4.3. Case 3: Experimental or Local Use PHBs | |||
PHBs not defined by standards action, i.e., experimental or local use | PHBs not defined by standards action, i.e., experimental or local use | |||
PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB | PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB | |||
identification code, assigned by the IANA, is placed left-justified | identification code, assigned by the IANA, is placed left-justified | |||
in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a | in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a | |||
single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. | single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. | |||
Bits 12 and 13 are reserved either for expansion of the PHB | Bits 12 and 13 are reserved either for expansion of the PHB | |||
identification code, or for other use, at some point in the future. | identification code, or for other use, at some point in the future. | |||
skipping to change at page 8, line 5 | skipping to change at page 6, line 44 | |||
[RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that | [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that | |||
do not constitute a PHB Scheduling Class can be identified by using | do not constitute a PHB Scheduling Class can be identified by using | |||
more than one PHBID. | more than one PHBID. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| PHD ID CODE |0 0 1 0| (Reserved) | | | PHD ID CODE |0 0 1 0| (Reserved) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
3.8. DSTE-Class-Type AVP | ||||
The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A | ||||
description of the semantic of the parameter values can be found in | ||||
[RFC4124]. | ||||
Currently, the values of alues currently allowed are 1, 2, 3, 4, 5, | ||||
6, 7. The value of zero (0) is marked as reserved in [RFC4124]. | ||||
Furthermore, the CLASSTYPE attribute in [RFC4124] is 32 bits in | ||||
length with 29 bits reserved. | ||||
4. Extensibility | 4. Extensibility | |||
This document is designed with extensibility in mind given that | This document is designed with extensibility in mind given that | |||
different organizations and groups are used to define their own | different organizations and groups are used to defining their own | |||
Quality of Service parameters. This document provides an initial QoS | Quality of Service parameters. This document provides an initial QoS | |||
profile with common set of parameters. Ideally, these parameters | profile with common set of parameters. Ideally, these parameters | |||
should be used whenever possible but there are cases where additional | should be used whenever possible but there are cases where additional | |||
parameters might be needed, or where the parameters specified in this | parameters might be needed, or where the parameters specified in this | |||
document are used with a different semantic. In that case it is | document are used with a different semantic. In that case it is | |||
advisable to define a new QoS profile that may consist of new | advisable to define a new QoS profile that may consist of new | |||
parameters in addition to parameters defined in this document or an | parameters in addition to parameters defined in this document or an | |||
entirely different set of parameters. Finally, it is also possible | entirely different set of parameters. Finally, it is also possible | |||
to register a specific QoS profile that defines a specific set of QoS | to register a specific QoS profile that defines a specific set of QoS | |||
values rather than parameters that need to be filled with values in | values rather than parameters that need to be filled with values in | |||
order to be used. | order to be used. | |||
To enable the definition of new QoS profiles a 8 octet registry is | To enable the definition of new QoS profiles a 8 octet registry is | |||
defined field that is represented by a 4-octet vendor and 4-octet | defined field that is represented by a 4-octet vendor and 4-octet | |||
specifier field. The vendor field indicates the type as either | specifier field. The vendor field contains an Enterprise Number as | |||
standards-specified or vendor-specific. If the four octets of the | defined in [RFC2578] taken from the values maintained in the IANA | |||
vendor field are 0x00000000, then the value is standards-specified | Enterprise Numbers registry. If the four octets of the vendor field | |||
and the registry is maintained by IANA as Enterprise Numbers defined | are 0x00000000 (reserved value for IANA), then the value in the | |||
in [RFC2578], and any other value represents a vendor-specific Object | specifier field MUST be registered with IANA (see Section 5.2). If | |||
Identifier (OID). IANA created registry is split into two value | the vendor field is other than 0x00000000, the value of the specifier | |||
ranges; one range uses the "Standards Action" and the second range | field represents a vendor-specific value, where allocation is the | |||
uses "Specification Required" allocation policy. The latter range is | responsibility of the enterprise indicated in the vendor field. | |||
meant to be used by organizations outside the IETF. | ||||
5. IANA Considerations | 5. IANA Considerations | |||
5.1. AVP Codes | 5.1. AVP Codes | |||
IANA is requested to allocate AVP codes for the following AVPs that | IANA is requested to allocate AVP codes in the IETF IANA controlled | |||
are defined in this document. | namespace registry specified in Section 11.1.1 of [RFC3588] for the | |||
following AVPs that are defined in this document. | ||||
+------------------------------------------------------------------+ | +------------------------------------------------------------------+ | |||
| AVP Section | | | AVP Section | | |||
|AVP Name Code Defined Data Type | | |AVP Name Code Defined Data Type | | |||
+------------------------------------------------------------------+ | +------------------------------------------------------------------+ | |||
|TMOD-1 TBD 3.1 Grouped | | |TMOD-1 TBD 3.1 Grouped | | |||
|TMOD-Rate TBD 3.1.1 Float32 | | |Token-Rate TBD 3.1.1 Float32 | | |||
|TMOD-Size TBD 3.1.2 Float32 | | |Bucket-Depth TBD 3.1.2 Float32 | | |||
|Peak-Data-Rate TBD 3.1.3 Float32 | | |Peak-Traffic-Rate TBD 3.1.3 Float32 | | |||
|Minimum-Policed-Unit TBD 3.1.4 Unsigned32 | | |Minimum-Policed-Unit TBD 3.1.4 Unsigned32 | | |||
|Maximum-Packet-Size TBD 3.1.5 Unsigned32 | | ||||
|TMOD-2 TBD 3.2 Grouped | | |TMOD-2 TBD 3.2 Grouped | | |||
|Bandwidth TBD 3.3 Float32 | | |Bandwidth TBD 3.3 Float32 | | |||
|Priority TBD 3.4 Grouped | | ||||
|Preemption-Priority TBD 3.4.1 Unsigned32 | | ||||
|Defending-Priority TBD 3.4.2 Unsigned32 | | ||||
|Admission-Priority TBD 3.5 Unsigned32 | | ||||
|ALRP TBD 3.6 Grouped | | ||||
|ALRP-Namespace TBD 3.6.1 Unsigned32 | | ||||
|ALRP-Priority TBD 3.6.2 Unsigned32 | | ||||
|PHB-Class TBD 3.7 Unsigned32 | | |PHB-Class TBD 3.7 Unsigned32 | | |||
|DSTE-Class-Type TBD 3.8 Unsigned32 | | ||||
+------------------------------------------------------------------+ | +------------------------------------------------------------------+ | |||
5.2. QoS Profile | 5.2. QoS Profile | |||
IANA is requested to create the following registry. | ||||
The QoS Profile refers to a 64 bit long field that is represented by | The QoS Profile refers to a 64 bit long field that is represented by | |||
a 4-octet vendor and 4-octet specifier field. The vendor field | a 4-octet vendor and 4-octet specifier field. The vendor field | |||
indicates the type as either standards-specified or vendor-specific. | indicates the type as either standards-specified or vendor-specific. | |||
If the four octets of the vendor field are 0x00000000, then the value | ||||
is standards-specified and the registry is maintained by IANA, and | ||||
any other value represents a vendor-specific Object Identifier (OID). | ||||
The specifier field indicates the actual QoS profile. The vendor | If the four octets of the vendor field are 0x00000000, then the value | |||
field 0x00000000 is reserved to indicate that the values in the | is standards-specified and a registry will be created to maintain the | |||
specifier field are maintained by IANA. This document requests IANA | QoS profile specifier values. The specifier field indicates the | |||
to create such a registry and to allocate the value zero (0) for the | actual QoS profile. Depending on the value requested, the action | |||
QoS profile defined in this document. | needed to request a new value is: | |||
0 to 511: Standards Action | ||||
512 to 32767: Specification Required | ||||
32768 to 4294967295: Reserved | ||||
For any other vendor field, the specifier field is maintained by the | Standards action is required to add, depreciate, delete, or modify | |||
vendor. | QoS profile values in the range of 0-511 and a specification is | |||
required to add, depreciate, delete, or modify existing QoS profile | ||||
values in the range of 512-32767. | ||||
For the IANA maintained QoS profiles the following allocation policy | This document requests IANA to create such a registry and to allocate | |||
is defined: | the value zero (0) for the QoS profile defined in this document. | |||
0 to 511: Standards Action | ||||
512 to 4095: Specification Required | ||||
Standards action is required to depreciate, delete, or modify | Alternative vendor-specific QoS profiles can be created and | |||
existing QoS profile values in the range of 0-511 and a specification | identified with a Enterprise Number taken from the IANA registry | |||
is required to depreciate, delete, or modify existing QoS profile | created by [RFC2578] in the vendor field combined with a vendor- | |||
values in the range of 512-4095. | specific value in the specifier field. Allocation of the specifier | |||
values is the responsibility of the vendor. | ||||
6. Security Considerations | 6. Security Considerations | |||
This document does not raise any security concerns as it only defines | This document does not raise any security concerns as it only defines | |||
QoS parameters and does not yet describe how they are exchanged in a | QoS parameters and does not yet describe how they are exchanged in a | |||
AAA protocol. Security considerations are described in documents | AAA protocol. Security considerations are described in documents | |||
using this specification. | using this specification. | |||
7. Acknowledgements | 7. Acknowledgements | |||
The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] | The authors would like to thank the NSIS working group members | |||
authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the | Cornelia Kappler, Jerry Ash, Attila Bader, and Dave Oran, the former | |||
NSIS working group chairs (John Loughney and Martin Stiemerling) and | NSIS working group chairs (John Loughney and Martin Stiemerling) and | |||
the former Transport Area Directors (Allison Mankin, Jon Peterson) | the former Transport Area Directors (Allison Mankin, Jon Peterson) | |||
for their help. The authors of this document are thankful for the | for their help. | |||
suggestions and input received from the NSIS QSPEC | ||||
[I-D.ietf-nsis-qspec] authors. | ||||
We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt, | We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt, | |||
Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James | Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James | |||
Polk, Martin Stiemerling, and Magnus Westerlund for their help with | Polk, Martin Dolly, Martin Stiemerling, and Magnus Westerlund for | |||
resolving problems regarding the Admission Priority and the ALRP | their feedback regarding some of the parameters in this documents. | |||
parameter. | ||||
Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu provided | Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu provided | |||
help with the semantic of some QSPEC parameters. | help with the semantic of some QSPEC parameters. | |||
We would like to thank Dan Romascanu for his detailed Area Director | We would like to thank Dan Romascanu for his detailed Area Director | |||
review comments and Scott Bradner for his Transport Area Directorate | review comments and Scott Bradner for his Transport Area Directorate | |||
review. | review. Chris Newman and Pasi Eronen provided feedback during the | |||
IESG review. | ||||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[I-D.ietf-tsvwg-emergency-rsvp] | ||||
Faucheur, F., Polk, J., and K. Carlberg, "Resource | ||||
ReSerVation Protovol (RSVP) Extensions for Emergency | ||||
Services", draft-ietf-tsvwg-emergency-rsvp-09 (work in | ||||
progress), October 2008. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated | [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated | |||
Services", RFC 2210, September 1997. | Services", RFC 2210, September 1997. | |||
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization | [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization | |||
Parameters for Integrated Service Network Elements", | Parameters for Integrated Service Network Elements", | |||
RFC 2215, September 1997. | RFC 2215, September 1997. | |||
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |||
"Definition of the Differentiated Services Field (DS | "Definition of the Differentiated Services Field (DS | |||
Field) in the IPv4 and IPv6 Headers", RFC 2474, | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |||
December 1998. | December 1998. | |||
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. | [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. | |||
Schoenwaelder, Ed., "Structure of Management Information | Schoenwaelder, Ed., "Structure of Management Information | |||
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. | Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. | |||
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, | ||||
"Assured Forwarding PHB Group", RFC 2597, June 1999. | ||||
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, | [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, | |||
"Per Hop Behavior Identification Codes", RFC 3140, | "Per Hop Behavior Identification Codes", RFC 3140, | |||
June 2001. | June 2001. | |||
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", | [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. | |||
RFC 3181, October 2001. | Arkko, "Diameter Base Protocol", RFC 3588, September 2003. | |||
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of | ||||
Diffserv-aware MPLS Traffic Engineering", RFC 4124, | ||||
June 2005. | ||||
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource | ||||
Priority for the Session Initiation Protocol (SIP)", | ||||
RFC 4412, February 2006. | ||||
8.2. Informative References | 8.2. Informative References | |||
[I-D.ietf-nsis-qspec] | ||||
Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC | ||||
Template", draft-ietf-nsis-qspec-21 (work in progress), | ||||
November 2008. | ||||
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | |||
and W. Weiss, "An Architecture for Differentiated | and W. Weiss, "An Architecture for Differentiated | |||
Services", RFC 2475, December 1998. | Services", RFC 2475, December 1998. | |||
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, | ||||
"Assured Forwarding PHB Group", RFC 2597, June 1999. | ||||
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color | [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color | |||
Marker", RFC 2697, September 1999. | Marker", RFC 2697, September 1999. | |||
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An | [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, | |||
Informal Management Model for Diffserv Routers", RFC 3290, | J., Courtney, W., Davari, S., Firoiu, V., and D. | |||
May 2002. | Stiliadis, "An Expedited Forwarding PHB (Per-Hop | |||
Behavior)", RFC 3246, March 2002. | ||||
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of | ||||
Differentiated Services-aware MPLS Traffic Engineering", | ||||
RFC 3564, July 2003. | ||||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC3260] Grossman, D., "New Terminology and Clarifications for | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | Diffserv", RFC 3260, April 2002. | |||
May 2008. | ||||
Authors' Addresses | Authors' Addresses | |||
Jouni Korhonen (editor) | Jouni Korhonen (editor) | |||
Nokia Siemens Networks | Nokia Siemens Networks | |||
Linnoitustie 6 | Linnoitustie 6 | |||
Espoo 02600 | Espoo 02600 | |||
Finland | Finland | |||
Email: jouni.korhonen@nsn.com | Email: jouni.korhonen@nsn.com | |||
End of changes. 56 change blocks. | ||||
260 lines changed or deleted | 146 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |