The RFC Archive
 The RFC Archive   RFC 5624   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 5624

Quality of Service Parameters for Usage with Diameter

Last modified on Friday, August 21st, 2009

Permanent link to RFC 5624
Search GitHub Wiki for RFC 5624
Show other RFCs mentioning RFC 5624







Network Working Group                                   J. Korhonen, Ed.
Request for Comments: 5624                                 H. Tschofenig
Category: Standards Track                       Nokia Siemens Networks
                                                               E. Davies
                                                        Folly Consulting
                                                             August 2009


         Quality of Service Parameters for Usage with Diameter

 Abstract

   This document defines a number of Quality of Service (QoS) parameters
   that can be reused for conveying QoS information within Diameter.

   The defined QoS information includes data traffic parameters for
   describing a token bucket filter, a bandwidth parameter, and a per-
   hop behavior class object.

 Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

 Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.














Korhonen, et al.            Standards Track                  PAGE 1 top


RFC 5624 QoS Parameters August 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4 3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Token-Rate AVP . . . . . . . . . . . . . . . . . . . . 4 3.1.2. Bucket-Depth AVP . . . . . . . . . . . . . . . . . . . 4 3.1.3. Peak-Traffic-Rate AVP . . . . . . . . . . . . . . . . 4 3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4 3.1.5. Maximum-Packet-Size AVP . . . . . . . . . . . . . . . 4 3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5 3.4. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 5 3.4.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 5 3.4.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 5 3.4.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 6 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. ABNF Code Fragment . . . . . . . . . . . . . . . . . 11 1. Introduction This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within the Diameter protocol [RFC 3588]. The current set of QoS parameters defined in this document are a core subset determined to be useful for a wide range of applications. Additional parameters may be defined in future documents as the need arises and are for future study. The parameters are defined as Diameter-encoded Attribute Value Pairs (AVPs), which are described using a modified version of the Augmented Backus-Naur Form (ABNF), see [RFC 3588]. The data types are also taken from [RFC 3588]. The traffic model (TMOD) AVPs are containers consisting of four AVPs and provide a way to describe the traffic source. o token rate (r) o bucket depth (b) o peak traffic rate (p) Korhonen, et al. Standards Track PAGE 2 top

RFC 5624 QoS Parameters August 2009 o minimum policed unit (m) o maximum packet size (M) The encoding of the <TMOD-1> and the <TMOD-2> AVPs can be found in Sections 3.1 and 3.2. The semantics of these two AVPs are described in Section 3.1 of [RFC 2210] and in Section 3.6 of [RFC 2215]. The <TMOD-2> AVP is, for example, needed by some DiffServ applications. It is typically assumed that DiffServ expedited forwarding (EF) traffic is shaped at the ingress by a single-rate token bucket. Therefore, a single TMOD parameter is sufficient to signal DiffServ EF traffic. However, for DiffServ assured forwarding (AF) traffic, two sets of token bucket parameters are needed: one token bucket for the average traffic and one token bucket for the burst traffic. [RFC 2697] 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. [RFC 2697] 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 [RFC 2597]. Resource reservations might refer to a packet processor with a particular DiffServ per-hop behavior (PHB) (using the <PHB-Class> AVP). A generic description of the DiffServ architecture can be found in [RFC 2475], and the Differentiated Services Field is described in Section 3 of [RFC 2474]. Updated terminology can be found in [RFC 3260]. Standardized per-hop behavior is, for example, described in [RFC 2597] ("Assured Forwarding PHB Group") and in [RFC 3246] ("An Expedited Forwarding PHB"). 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 the future. 2. Terminology and Abbreviations The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. Korhonen, et al. Standards Track PAGE 3 top

RFC 5624 QoS Parameters August 2009 3. QoS Parameter Encoding 3.1. TMOD-1 AVP The TMOD-1 AVP is obtained from [RFC 2210] and [RFC 2215]. The structure of the AVP is as follows: TMOD-1 ::= < AVP Header: 495 > { Token-Rate } { Bucket-Depth } { Peak-Traffic-Rate } { Minimum-Policed-Unit } { Maximum-Packet-Size } 3.1.1. Token-Rate AVP The Token-Rate AVP (AVP Code 496) is of type Float32. 3.1.2. Bucket-Depth AVP The Bucket-Depth AVP (AVP Code 497) is of type Float32. 3.1.3. Peak-Traffic-Rate AVP The Peak-Traffic-Rate AVP (AVP Code 498) is of type Float32. 3.1.4. Minimum-Policed-Unit AVP The Minimum-Policed-Unit AVP (AVP Code 499) is of type Unsigned32. 3.1.5. Maximum-Packet-Size AVP The Maximum-Packet-Size AVP (AVP Code 500) is of type Unsigned32. 3.2. TMOD-2 AVP A description of the semantics of the parameter values can be found in [RFC 2215]. The coding for the TMOD-2 AVP is as follows: TMOD-2 ::= < AVP Header: 501 > { Token-Rate } { Bucket-Depth } { Peak-Traffic-Rate } { Minimum-Policed-Unit } { Maximum-Packet-Size } Korhonen, et al. Standards Track PAGE 4 top

RFC 5624 QoS Parameters August 2009 3.3. Bandwidth AVP The Bandwidth AVP (AVP Code 502) is of type Float32 and is measured in octets of IP datagrams per second. The Bandwidth AVP represents a simplified description of the following TMOD setting whereby the token rate (r) = peak traffic rate (p), the bucket depth (b) = large, and the minimum policed unit (m) = large when only bandwidth has to be expressed. 3.4. PHB-Class AVP The PHB-Class AVP (AVP Code 503) is of type Unsigned32. A description of the semantics of the parameter values can be found in [RFC 3140]. The registries needed for usage with [RFC 3140] already exist and hence a new registry is not required for this purpose. The encoding requires that three cases be differentiated. All bits indicated as "reserved" MUST be set to zero (0). 3.4.1. Case 1: Single PHB As prescribed in [RFC 3140], the encoding for a single PHB is the recommended Differentiated Services Code Point (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.4.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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Korhonen, et al. Standards Track PAGE 5 top

RFC 5624 QoS Parameters August 2009 3.4.3. Case 3: Experimental or Local Use PHBs PHBs may not be defined by standards actions i.e., experimental or local use PHBs as allowed by [RFC 2474]. In this case, an arbitrary 12-bit PHB identification code, assigned by the IANA, is 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, future use. In both cases, when a single PHBID is used to identify a set of PHBs (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB Scheduling Class (i.e., use of PHBs from the set MUST NOT cause intra-microflow traffic reordering when different PHBs from the set are applied to traffic in the same microflow). The set of AF1x PHBs [RFC 2597] 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. Extensibility This document is designed with extensibility in mind, given that different organizations and groups are used to defining their own Quality of Service parameters. This document provides an initial QoS profile with a 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 different semantics. 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. 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, an 8-octet registry is defined as a field that is represented by 4-octet vendor and 4-octet specifier fields. The vendor field contains an Enterprise Number as defined in [RFC 2578], taken from the values maintained in the IANA Enterprise Numbers registry. If the four octets of the vendor field Korhonen, et al. Standards Track PAGE 6 top

RFC 5624 QoS Parameters August 2009 are 0x00000000 (reserved value for IANA), then the value in the specifier field MUST be registered with IANA (see Section 5.2). If the vendor field is other than 0x00000000, the value of the specifier field represents a vendor-specific value, where allocation is the responsibility of the enterprise indicated in the vendor field. 5. IANA Considerations 5.1. AVP Codes IANA allocated AVP codes in the IANA-controlled namespace registry specified in Section 11.1.1 of [RFC 3588] for the following AVPs that are defined in this document. +------------------------------------------------------------------+ | AVP Section | |AVP Name Code Defined Data Type | +------------------------------------------------------------------+ |TMOD-1 495 3.1 Grouped | |Token-Rate 496 3.1.1 Float32 | |Bucket-Depth 497 3.1.2 Float32 | |Peak-Traffic-Rate 498 3.1.3 Float32 | |Minimum-Policed-Unit 499 3.1.4 Unsigned32 | |Maximum-Packet-Size 500 3.1.5 Unsigned32 | |TMOD-2 501 3.2 Grouped | |Bandwidth 502 3.3 Float32 | |PHB-Class 503 3.4 Unsigned32 | +------------------------------------------------------------------+ 5.2. QoS Profile The QoS profile refers to a 64-bit field that is represented by 4-octet vendor and 4-octet specifier fields. 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 a registry will be created to maintain the QoS profile specifier values. The specifier field indicates the actual QoS profile. Depending on the value requested, the action needed to request a new value is: 0 to 511: Standards Action 512 to 32767: Specification Required 32768 to 4294967295: Reserved Korhonen, et al. Standards Track PAGE 7 top

RFC 5624 QoS Parameters August 2009 Standards action is required to add, depreciate, delete, or modify 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. IANA created such a registry and allocated the value zero (0) for the QoS profile defined in this document. Alternative vendor-specific QoS profiles can be created and identified with an Enterprise Number taken from the IANA registry created by [RFC 2578] in the vendor field, combined with a vendor- specific value in the specifier field. Allocation of the specifier values is the responsibility of the vendor. 6. Security Considerations This document does not raise any security concerns as it only defines QoS parameters and does not yet describe how they are exchanged in an Authentication, Authorization, and Accounting (AAA) protocol. Security considerations are described in documents using this specification. 7. Acknowledgements The authors would like to thank the NSIS working group members Cornelia Kappler, Jerry Ash, Attila Bader, and Dave Oran; the former NSIS working group chairs John Loughney and Martin Stiemerling; and the former Transport Area Directors Allison Mankin and Jon Peterson for their help. We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt, Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James Polk, Martin Dolly, Martin Stiemerling, and Magnus Westerlund for their feedback regarding some of the parameters in this documents. Jerry Ash, Al Morton, Mayutan Arumaithurai, and Xiaoming Fu provided help with the semantics 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. Chris Newman, Adrian Farrel, and Pasi Eronen provided feedback during the IESG review. Korhonen, et al. Standards Track PAGE 8 top

RFC 5624 QoS Parameters August 2009 8. References 8.1. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC 2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997. [RFC 2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC 2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC 3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001. [RFC 3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 8.2. Informative References [RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC 2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC 2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999. [RFC 3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. Korhonen, et al. Standards Track PAGE 9 top

RFC 5624 QoS Parameters August 2009 [RFC 3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. Korhonen, et al. Standards Track PAGE 10 top

RFC 5624 QoS Parameters August 2009 Appendix A. ABNF Code Fragment Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. TMOD-1 ::= < AVP Header: 495 > { Token-Rate } { Bucket-Depth } { Peak-Traffic-Rate } { Minimum-Policed-Unit } { Maximum-Packet-Size } TMOD-2 ::= < AVP Header: 501 > { Token-Rate } { Bucket-Depth } { Peak-Traffic-Rate } { Minimum-Policed-Unit } { Maximum-Packet-Size } Korhonen, et al. Standards Track PAGE 11 top

RFC 5624 QoS Parameters August 2009 Authors' Addresses Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland EMail: jouni.korhonen@nsn.com 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 Korhonen, et al. Standards Track PAGE 12 top

Quality of Service Parameters for Usage with Diameter RFC TOTAL SIZE: 23326 bytes PUBLICATION DATE: Friday, August 21st, 2009 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 5624: The IETF Trust, Friday, August 21st, 2009
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement