RFC 5624
Quality of Service Parameters for Usage with Diameter
Quality of Service Parameters for Usage with Diameter 💖
Part 1 of 2 🎀
Okay bestie, this is RFC 5624 ✨. It's a Standards Track doc from the Network Working Group, dated August 2009. The authors are J. Korhonen (Ed.), H. Tschofenig, and E. Davies. Korhonen and Tschofenig are at Nokia Siemens Networks, and Davies is at Folly Consulting. It doesn't obsolete or update any other RFCs, since none are listed in its header 🌸
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. 🙈
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 . . . . . . . . . . . . . . . . . 111. Introduction 🌈
This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within the Diameter protocol [RFC3588]. 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 [RFC3588]. The data types are also taken from [RFC3588].
The traffic model (TMOD) AVPs are containers consisting of four AVPs and provide a way to describe the traffic source. 🧚 Okay, the list is:
- token rate (r)
- bucket depth (b)
- peak traffic rate (p)
- minimum policed unit (m)
- 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 [RFC2210] and in Section 3.6 of [RFC2215]. 📖
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. [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 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 [RFC2475], and the Differentiated Services Field is described in Section 3 of [RFC2474]. Updated terminology can be found in [RFC3260]. Standardized per-hop behavior is, for example, described in [RFC2597] ("Assured Forwarding PHB Group") and in [RFC3246] ("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 RFC2119 [RFC2119]. 🫶
3. QoS Parameter Encoding ✨
3.1. TMOD-1 AVP
The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. 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 [RFC2215]. 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 }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 [RFC3140]. The registries needed for usage with [RFC3140] 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 [RFC3140], 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+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 [RFC2474]. 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 [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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4. Extensibility ✨
okay so this part is literally about making room for the future 🌸 Different orgs and groups love defining their own QoS parameters (they have strong opinions, iykyk 💅), so this doc gives an initial QoS profile with a common set of parameters. Ideally you use these whenever you can, but sometimes you need extra parameters, or you want the same parameters with different semantics. In that case, it's advisable to define a new QoS profile that has new parameters on top of the ones here, or a totally different set. You can also register a specific QoS profile that already has fixed values, so you don't have to fill in blanks at all 🦋
To make new QoS profiles possible, there's an 8-octet registry field, split into a 4-octet vendor field and a 4-octet specifier field 🎀 The vendor field holds an Enterprise Number from [RFC2578], taken from the IANA Enterprise Numbers registry. If the vendor field is 0x00000000 (the reserved value for IANA), then the specifier field MUST be registered with IANA (see Section 5.2). If the vendor field is anything else, the specifier is vendor-specific, and the enterprise in the vendor field is the one in charge of allocating it 💜
5. IANA Considerations 🎀
5.1. AVP Codes
okay so IANA handed out AVP codes from the IANA-controlled namespace registry (the one in Section 11.1.1 of [RFC3588]) for every AVP defined in this doc. Here's the whole lineup 🦋
+------------------------------------------------------------------+
| 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 is a 64-bit field, also split into a 4-octet vendor field and a 4-octet specifier field 💅 The vendor field tells you whether the profile is standards-specified or vendor-specific.
if the vendor field is 0x00000000, the profile is standards-specified, and a registry gets created to keep track of the QoS profile specifier values. The specifier field is the actual QoS profile. What you need to do to request a new value depends on the number:
0 to 511: Standards Action512 to 32767: Specification Required32768 to 4294967295: Reserved
so 0 to 511 needs a Standards Action to add, depreciate, delete, or modify, and 512 to 32767 needs a specification for those same changes 🔥
IANA set up that registry and gave the value zero (0) to the QoS profile defined in this doc ✨
Alternative vendor-specific QoS profiles are also a thing. You identify them with an Enterprise Number from the IANA registry created by [RFC2578] in the vendor field, plus a vendor-specific value in the specifier field. The vendor is responsible for allocating those specifier values 🌈
6. Security Considerations 🙈
okay this one's short but it matters 💀 This document doesn't raise any security concerns, because it only defines QoS parameters and doesn't yet describe how they get exchanged in an Authentication, Authorization, and Accounting (AAA) protocol. Security considerations live in the documents that use this specification, so go check those too, bestie 🫶
7. Acknowledgements 💖
the authors would like to thank the NSIS working group members Cornelia Kappler, Jerry Ash, Attila Bader, and Dave Oran 🧚 They also thank 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.
They'd also 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 on some of the parameters in this documents 🌸
Jerry Ash, Al Morton, Mayutan Arumaithurai, and Xiaoming Fu helped with the semantics of some QSPEC parameters 👑
Last but not least, Dan Romascanu gave a detailed Area Director review, and Scott Bradner did the Transport Area Directorate review. Chris Newman, Adrian Farrel, and Pasi Eronen gave feedback during the IESG review 💜
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements",
RFC 2215, September 1997.
[RFC2474] 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.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
"Per Hop Behavior Identification Codes", RFC 3140,
June 2001.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.8.2. Informative References
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
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
Marker", RFC 2697, September 1999.
[RFC3246] 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.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.Appendix A. ABNF Code Fragment 🧩
the code bits in this appendix come with a license, and here it is word for word 💅
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.and here are the TMOD grammars 🦋
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 }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.comThat's the whole RFC, babe! 🌈✨
📦 where this page comes from
- ietf: rfc5624 2009-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms