From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5624.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc5624.txt (limited to 'doc/rfc/rfc5624.txt') diff --git a/doc/rfc/rfc5624.txt b/doc/rfc/rfc5624.txt new file mode 100644 index 0000000..d4a42e1 --- /dev/null +++ b/doc/rfc/rfc5624.txt @@ -0,0 +1,675 @@ + + + + + + +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] + +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 [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. + + o token rate (r) + + o bucket depth (b) + + o peak traffic rate (p) + + + + +Korhonen, et al. Standards Track [Page 2] + +RFC 5624 QoS Parameters August 2009 + + + o minimum policed unit (m) + + o maximum packet size (M) + + The encoding of the and the 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 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 + 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]. + + + +Korhonen, et al. Standards Track [Page 3] + +RFC 5624 QoS Parameters August 2009 + + +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 } + + + + + + +Korhonen, et al. Standards Track [Page 4] + +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 [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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Korhonen, et al. Standards Track [Page 5] + +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 [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 + + 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 [RFC2578], 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] + +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 [RFC3588] 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] + +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 [RFC2578] 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] + +RFC 5624 QoS Parameters August 2009 + + +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. + + + + + +Korhonen, et al. Standards Track [Page 9] + +RFC 5624 QoS Parameters August 2009 + + + [RFC3260] Grossman, D., "New Terminology and Clarifications for + Diffserv", RFC 3260, April 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Korhonen, et al. Standards Track [Page 10] + +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] + +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] + -- cgit v1.2.3