draft-ietf-dime-qos-parameters-08.txt | draft-ietf-dime-qos-parameters-09.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 December 18, 2008 | Intended status: Standards Track E. Davies | |||
Expires: June 21, 2009 | Expires: July 26, 2009 Folly Consulting | |||
January 22, 2009 | ||||
Quality of Service Parameters for Usage with Diameter | Quality of Service Parameters for Usage with Diameter | |||
draft-ietf-dime-qos-parameters-08.txt | draft-ietf-dime-qos-parameters-09.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 33 | 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 June 21, 2009. | This Internet-Draft will expire on July 26, 2009. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2008 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 | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights 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 payloads used to carry these QoS parameters are opaque for the | The defined QoS information includes data traffic parameters for | |||
AAA client and the AAA server itself and interpreted by the | describing a token bucket filter, bandwidth, defending and preemption | |||
respective Resource Management Function. | priority, admission priority, application-level resource priority, | |||
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. TMOD-Rate AVP . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1.2. TMOD-Size AVP . . . . . . . . . . . . . . . . . . . . 4 | 3.1.2. TMOD-Size AVP . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1.3. Peak-Data-Rate AVP . . . . . . . . . . . . . . . . . . 4 | 3.1.3. Peak-Data-Rate AVP . . . . . . . . . . . . . . . . . . 4 | |||
3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4 | 3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4 | |||
3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.3. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.3.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 5 | 3.4. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.3.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 5 | 3.4.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 5 | |||
3.4. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 5 | 3.4.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 5 | |||
3.5. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3.5. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 5 | |||
3.5.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 6 | 3.6. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.5.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 6 | 3.6.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 6 | |||
3.6. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 6 | 3.6.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 6 | |||
3.6.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 6 | 3.7. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.6.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 7 | 3.7.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 6 | |||
3.6.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 7 | 3.7.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 7 | |||
3.7. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 7 | 3.7.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 7 | |||
3.8. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 8 | ||||
4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 | 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
1. Introduction | 1. Introduction | |||
skipping to change at page 5, line 17 | skipping to change at page 5, line 17 | |||
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 TMOD-2 AVP is useful in a DiffServ environment. 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 } | { TMOD-Rate } | |||
{ TMOD-Size } | { TMOD-Size } | |||
{ Peak-Data-Rate } | { Peak-Data-Rate } | |||
{ Minimum-Policed-Unit } | { Minimum-Policed-Unit } | |||
3.3. Priority AVP | 3.3. Bandwidth AVP | |||
The Bandwidth AVP (AVP Code TBD) is of type Float32 and is measured | ||||
in bytes of IP datagrams per second. | ||||
3.4. Priority AVP | ||||
The Priority AVP is a grouped AVP consisting of two AVPs, the | The Priority AVP is a grouped AVP consisting of two AVPs, the | |||
Preemption-Priority and the Defending-Priority AVP. A description of | Preemption-Priority and the Defending-Priority AVP. A description of | |||
the semantic can be found in [RFC3181]. | the semantic can be found in [RFC3181]. | |||
Priority ::= < AVP Header: TBD > | Priority ::= < AVP Header: TBD > | |||
{ Preemption-Priority } | { Preemption-Priority } | |||
{ Defending-Priority } | { Defending-Priority } | |||
3.3.1. Preemption-Priority AVP | 3.4.1. Preemption-Priority AVP | |||
The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and | The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and | |||
it indicates the priority of the new flow compared with the defending | it indicates the priority of the new flow compared with the defending | |||
priority of previously admitted flows. Higher values represent | priority of previously admitted flows. Higher values represent | |||
higher priority. | higher priority. | |||
3.3.2. Defending-Priority AVP | 3.4.2. Defending-Priority AVP | |||
The Defending-Priority AVP (AVP Code TBD) is of type Unsigned32. | The Defending-Priority AVP (AVP Code TBD) is of type Unsigned32. | |||
Once a flow is admitted, the preemption priority becomes irrelevant. | Once a flow is admitted, the preemption priority becomes irrelevant. | |||
Instead, its defending priority is used to compare with the | Instead, its defending priority is used to compare with the | |||
preemption priority of new flows. | preemption priority of new flows. | |||
3.4. Admission-Priority AVP | 3.5. Admission-Priority AVP | |||
The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. | The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. | |||
The admission control priority of the flow, in terms of access to | The admission control priority of the flow, in terms of access to | |||
network bandwidth in order to provide higher probability of call | network bandwidth in order to provide higher probability of call | |||
completion to selected flows. Higher values represent higher | completion to selected flows. Higher values represent higher | |||
priority. A given admission priority is encoded in this information | priority. A given admission priority is encoded in this information | |||
element using the same value as when encoded in the Admission- | element using the same value as when encoded in the Admission- | |||
Priority AVP defined in Section 3.1 of | Priority AVP defined in Section 3.1 of | |||
[I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter). | [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter). | |||
3.5. ALRP AVP | 3.6. ALRP AVP | |||
The Application-Level Resource Priority (ALRP) AVP is a grouped AVP | The Application-Level Resource Priority (ALRP) AVP is a grouped AVP | |||
consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority 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 | 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 | [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for | |||
parameter is as follows: | parameter is as follows: | |||
ALRP ::= < AVP Header: TBD > | ALRP ::= < AVP Header: TBD > | |||
{ ALRP-Namespace } | { ALRP-Namespace } | |||
{ ALRP-Priority } | { ALRP-Priority } | |||
3.5.1. ALRP-Namespace AVP | 3.6.1. ALRP-Namespace AVP | |||
The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. | The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. | |||
3.5.2. ALRP-Priority AVP | 3.6.2. ALRP-Priority AVP | |||
The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32. | The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32. | |||
[RFC4412] defines a resource priority header and established the | [RFC4412] defines a resource priority header and established the | |||
initial registry. That registry was later extended by | initial registry. That registry was later extended by | |||
[I-D.ietf-tsvwg-emergency-rsvp]. | [I-D.ietf-tsvwg-emergency-rsvp]. | |||
3.6. PHB-Class AVP | 3.7. 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.6.1. Case 1: Single PHB | 3.7.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.6.2. Case 2: Set of PHBs | 3.7.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.6.3. Case 3: Experimental or Local Use PHBs | 3.7.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 7, line 44 | skipping to change at page 8, line 5 | |||
[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.7. DSTE-Class-Type AVP | 3.8. DSTE-Class-Type AVP | |||
The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A | 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 | description of the semantic of the parameter values can be found in | |||
[RFC4124]. | [RFC4124]. | |||
Currently, the values of alues currently allowed are 1, 2, 3, 4, 5, | 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]. | 6, 7. The value of zero (0) is marked as reserved in [RFC4124]. | |||
Furthermore, the CLASSTYPE attribute in [RFC4124] is 32 bits in | Furthermore, the CLASSTYPE attribute in [RFC4124] is 32 bits in | |||
length with 29 bits reserved. | 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 define 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 this 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. | entirely different set of parameters. Finally, it is also possible | |||
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 | ||||
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 indicates the type as either | |||
standards-specified or vendor-specific. If the four octets of the | standards-specified or vendor-specific. If the four octets of the | |||
vendor field are 0x00000000, then the value is standards-specified | vendor field are 0x00000000, then the value is standards-specified | |||
and the registry is maintained by IANA as Enterprise Numbers defined | and the registry is maintained by IANA as Enterprise Numbers defined | |||
in [RFC2578], and any other value represents a vendor-specific Object | in [RFC2578], and any other value represents a vendor-specific Object | |||
Identifier (OID). IANA created registry is split into two value | Identifier (OID). IANA created registry is split into two value | |||
ranges; one range uses the "Standards Action" and the second range | ranges; one range uses the "Standards Action" and the second range | |||
skipping to change at page 9, line 15 | skipping to change at page 9, line 15 | |||
+------------------------------------------------------------------+ | +------------------------------------------------------------------+ | |||
| 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 | | |TMOD-Rate TBD 3.1.1 Float32 | | |||
|TMOD-Size TBD 3.1.2 Float32 | | |TMOD-Size TBD 3.1.2 Float32 | | |||
|Peak-Data-Rate TBD 3.1.3 Float32 | | |Peak-Data-Rate TBD 3.1.3 Float32 | | |||
|Minimum-Policed-Unit TBD 3.1.4 Unsigned32 | | |Minimum-Policed-Unit TBD 3.1.4 Unsigned32 | | |||
|TMOD-2 TBD 3.2 Grouped | | |TMOD-2 TBD 3.2 Grouped | | |||
|Priority TBD 3.3 Grouped | | |Bandwidth TBD 3.3 Float32 | | |||
|Preemption-Priority TBD 3.3.1 Unsigned32 | | |Priority TBD 3.4 Grouped | | |||
|Defending-Priority TBD 3.3.2 Unsigned32 | | |Preemption-Priority TBD 3.4.1 Unsigned32 | | |||
|Admission-Priority TBD 3.4 Unsigned32 | | |Defending-Priority TBD 3.4.2 Unsigned32 | | |||
|ALRP TBD 3.5 Grouped | | |Admission-Priority TBD 3.5 Unsigned32 | | |||
|ALRP-Namespace TBD 3.5.1 Unsigned32 | | |ALRP TBD 3.6 Grouped | | |||
|ALRP-Priority TBD 3.5.2 Unsigned32 | | |ALRP-Namespace TBD 3.6.1 Unsigned32 | | |||
|PHB-Class TBD 3.6 Unsigned32 | | |ALRP-Priority TBD 3.6.2 Unsigned32 | | |||
|DSTE-Class-Type 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. | 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 | If the four octets of the vendor field are 0x00000000, then the value | |||
skipping to change at page 10, line 20 | skipping to change at page 10, line 21 | |||
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 QSPEC [I-D.ietf-nsis-qspec] | |||
authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the | authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the | |||
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. This document re-uses content from the NSIS QSPEC | for their help. The authors of this document are thankful for the | |||
[I-D.ietf-nsis-qspec] specification. | 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 Stiemerling, and Magnus Westerlund for their help with | |||
resolving problems regarding the Admission Priority and the ALRP | resolving problems regarding the Admission Priority and the ALRP | |||
parameter. | parameter. | |||
Elwyn Davies provided a detailed review of the specification. Elwyn | Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu provided | |||
helped to investigate what QoS mechanisms are deployed in networks | help with the semantic of some QSPEC parameters. | |||
today. Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu | ||||
provided 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. | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[I-D.ietf-tsvwg-emergency-rsvp] | [I-D.ietf-tsvwg-emergency-rsvp] | |||
skipping to change at line 533 | skipping to change at page 12, line 37 | |||
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 | ||||
Folly Consulting | ||||
Soham | ||||
UK | ||||
Phone: +44 7889 488 335 | ||||
Email: elwynd@dial.pipex.com | ||||
End of changes. 24 change blocks. | ||||
49 lines changed or deleted | 61 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/ |