--- 1/draft-ietf-dime-qos-parameters-08.txt 2009-01-22 22:12:05.000000000 +0100 +++ 2/draft-ietf-dime-qos-parameters-09.txt 2009-01-22 22:12:05.000000000 +0100 @@ -1,19 +1,20 @@ Diameter Maintenance and J. Korhonen, Ed. Extensions (DIME) H. Tschofenig Internet-Draft Nokia Siemens Networks -Intended status: Standards Track December 18, 2008 -Expires: June 21, 2009 +Intended status: Standards Track E. Davies +Expires: July 26, 2009 Folly Consulting + January 22, 2009 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 This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -22,66 +23,69 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 21, 2009. + This Internet-Draft will expire on July 26, 2009. 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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter. - The payloads used to carry these QoS parameters are opaque for the - AAA client and the AAA server itself and interpreted by the - respective Resource Management Function. + The defined QoS information includes data traffic parameters for + describing a token bucket filter, bandwidth, defending and preemption + priority, admission priority, application-level resource priority, + per-hop behavior class, and DiffServ-aware Multiprotocol Label + Switching (MPLS) traffic engineering. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4 3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. TMOD-Rate AVP . . . . . . . . . . . . . . . . . . . . 4 3.1.2. TMOD-Size AVP . . . . . . . . . . . . . . . . . . . . 4 3.1.3. Peak-Data-Rate AVP . . . . . . . . . . . . . . . . . . 4 3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4 3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.3. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.3.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 5 - 3.3.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 5 - 3.4. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 5 - 3.5. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.5.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 6 - 3.5.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 6 - 3.6. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 6 - 3.6.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 6 - 3.6.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 7 - 3.6.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 7 - 3.7. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 7 + 3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5 + 3.4. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.4.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 5 + 3.4.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 5 + 3.5. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 5 + 3.6. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.6.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 6 + 3.6.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 6 + 3.7. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 6 + 3.7.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 6 + 3.7.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 7 + 3.7.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 7 + 3.8. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 8 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 @@ -184,117 +188,122 @@ 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 coding for the TMOD-2 AVP is as follows: TMOD-2 ::= < AVP Header: TBD > { TMOD-Rate } { TMOD-Size } { Peak-Data-Rate } { 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 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.3.1. Preemption-Priority AVP +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.3.2. Defending-Priority AVP +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.4. Admission-Priority AVP +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.5. ALRP AVP +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.5.1. ALRP-Namespace AVP +3.6.1. ALRP-Namespace AVP 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. [RFC4412] defines a resource priority header and established the initial registry. That registry was later extended by [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. A description of the semantic of the parameter values can be found in [RFC3140]. The registries needed for usage with [RFC3140] already exist and hence no new registry needs to be created by this document. The encoding requires three cases need to be differentiated. All 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 recommended DSCP value for that PHB, left-justified in the 16 bit field, with bits 6 through 15 set to zero. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 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 bit 14 set to 1.) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 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 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 identification code, or for other use, at some point in the future. @@ -306,43 +315,46 @@ [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 more than one PHBID. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 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 This document is designed with extensibility in mind given that different organizations and groups are used to define their own Quality of Service parameters. This document provides an initial QoS profile with common set of parameters. Ideally, these parameters should be used whenever possible but there are cases where additional 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 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 defined field that is represented by a 4-octet vendor and 4-octet specifier field. The vendor field 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 as Enterprise Numbers defined in [RFC2578], and any other value represents a vendor-specific Object Identifier (OID). IANA created registry is split into two value ranges; one range uses the "Standards Action" and the second range @@ -359,29 +371,30 @@ +------------------------------------------------------------------+ | AVP Section | |AVP Name Code Defined Data Type | +------------------------------------------------------------------+ |TMOD-1 TBD 3.1 Grouped | |TMOD-Rate TBD 3.1.1 Float32 | |TMOD-Size TBD 3.1.2 Float32 | |Peak-Data-Rate TBD 3.1.3 Float32 | |Minimum-Policed-Unit TBD 3.1.4 Unsigned32 | |TMOD-2 TBD 3.2 Grouped | - |Priority TBD 3.3 Grouped | - |Preemption-Priority TBD 3.3.1 Unsigned32 | - |Defending-Priority TBD 3.3.2 Unsigned32 | - |Admission-Priority TBD 3.4 Unsigned32 | - |ALRP TBD 3.5 Grouped | - |ALRP-Namespace TBD 3.5.1 Unsigned32 | - |ALRP-Priority TBD 3.5.2 Unsigned32 | - |PHB-Class TBD 3.6 Unsigned32 | - |DSTE-Class-Type TBD 3.7 Unsigned32 | + |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 | + |DSTE-Class-Type TBD 3.8 Unsigned32 | +------------------------------------------------------------------+ 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 a 4-octet vendor and 4-octet specifier field. The vendor field indicates the type as either standards-specified or vendor-specific. If the four octets of the vendor field are 0x00000000, then the value @@ -413,33 +426,32 @@ QoS parameters and does not yet describe how they are exchanged in a AAA protocol. Security considerations are described in documents using this specification. 7. Acknowledgements The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the NSIS working group chairs (John Loughney and Martin Stiemerling) and the former Transport Area Directors (Allison Mankin, Jon Peterson) - for their help. This document re-uses content from the NSIS QSPEC - [I-D.ietf-nsis-qspec] specification. + for their help. The authors of this document are thankful for the + 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, Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James Polk, Martin Stiemerling, and Magnus Westerlund for their help with resolving problems regarding the Admission Priority and the ALRP parameter. - Elwyn Davies provided a detailed review of the specification. Elwyn - helped to investigate what QoS mechanisms are deployed in networks - today. Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu - provided help with the semantic of some QSPEC parameters. + 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 review comments and Scott Bradner for his Transport Area Directorate review. 8. References 8.1. Normative References [I-D.ietf-tsvwg-emergency-rsvp] @@ -523,10 +535,18 @@ Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at + + Elwyn Davies + Folly Consulting + Soham + UK + + Phone: +44 7889 488 335 + Email: elwynd@dial.pipex.com