GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5624

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 <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].

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5624.txt · Last modified: 2009/08/20 23:58 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki