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/