TOC 
Diameter Maintenance andJ. Korhonen, Ed.
Extensions (DIME)H. Tschofenig
Internet-DraftNokia Siemens Networks
Intended status: Standards TrackE. Davies
Expires: September 10, 2009Folly Consulting
 March 09, 2009


Quality of Service Parameters for Usage with Diameter
draft-ietf-dime-qos-parameters-10.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.

Internet-Drafts are draft documents valid for a maximum of six months 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 September 10, 2009.

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.

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.



Table of Contents

1.  Introduction
2.  Terminology and Abbreviations
3.  QoS Parameter Encoding
    3.1.  TMOD-1 AVP
        3.1.1.  Token-Rate AVP
        3.1.2.  Bucket-Depth AVP
        3.1.3.  Peak-Traffic-Rate AVP
        3.1.4.  Minimum-Policed-Unit AVP
        3.1.5.  Maximum-Packet-Size AVP
    3.2.  TMOD-2 AVP
    3.3.  Bandwidth AVP
    3.4.  PHB-Class AVP
        3.4.1.  Case 1: Single PHB
        3.4.2.  Case 2: Set of PHBs
        3.4.3.  Case 3: Experimental or Local Use PHBs
4.  Extensibility
5.  IANA Considerations
6.  Security Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses




 TOC 

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] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.). It defines an initial QoS profile containing a set of Diameter encoded Attribute Value Pairs (AVPs) described using a modified version of the Augmented Backus-Naur Form (ABNF), see [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.). The datatypes are also taken from [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.).

The traffic model (TMOD) AVPs are containers consisting of four AVPs and is a way to describe the traffic source.

The encoding of the <TMOD-1> and the <TMOD-2> AVP can be found in Section 3.1 (TMOD-1 AVP) and Section 3.2 (TMOD-2 AVP). The semantics of these two AVPs are described in Section 3.1 of [RFC2210] (Wroclawski, J., “The Use of RSVP with IETF Integrated Services,” September 1997.) and in Section 3.6 of [RFC2215] (Shenker, S. and J. Wroclawski, “General Characterization Parameters for Integrated Service Network Elements,” September 1997.).

The <TMOD-2> AVP is, for example, needed by some DiffServ applications.

It is typically assumed that DiffServ 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 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] (Heinanen, J. and R. Guerin, “A Single Rate Three Color Marker,” September 1999.) 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] (Heinanen, J. and R. Guerin, “A Single Rate Three Color Marker,” September 1999.) 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] (Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, “Assured Forwarding PHB Group,” June 1999.).

Resource reservations might refer to a packet processing 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] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.) and the Differentiated Services Field is described in Section 3 of [RFC2474] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.). Updated terminology can be found in [RFC3260] (Grossman, D., “New Terminology and Clarifications for Diffserv,” April 2002.). Standardized Per-Hop Behavior is, for example, described in [RFC2597] (Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, “Assured Forwarding PHB Group,” June 1999.) (Assured Forwarding Per-Hop Behavior) and in [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),” March 2002.) (An Expedited Forwarding Per-Hop Behavior).

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



 TOC 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

3.  QoS Parameter Encoding



 TOC 

3.1.  TMOD-1 AVP

The TMOD-1 AVP is obtained from [RFC2210] (Wroclawski, J., “The Use of RSVP with IETF Integrated Services,” September 1997.) and [RFC2215] (Shenker, S. and J. Wroclawski, “General Characterization Parameters for Integrated Service Network Elements,” September 1997.). The structure of the AVP is as follows:

  TMOD-1  ::= < AVP Header: TBD >
              { Token-Rate }
              { Bucket-Depth }
              { Peak-Traffic-Rate }
              { Minimum-Policed-Unit }
              { Maximum-Packet-Size }



 TOC 

3.1.1.  Token-Rate AVP

The Token-Rate AVP (AVP Code TBD) is of type Float32.



 TOC 

3.1.2.  Bucket-Depth AVP

The Bucket-Depth AVP (AVP Code TBD) is of type Float32.



 TOC 

3.1.3.  Peak-Traffic-Rate AVP

The Peak-Traffic-Rate AVP (AVP Code TBD) is of type Float32.



 TOC 

3.1.4.  Minimum-Policed-Unit AVP

The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32.



 TOC 

3.1.5.  Maximum-Packet-Size AVP

The Maximum-Packet-Size AVP (AVP Code TBD) is of type Unsigned32.



 TOC 

3.2.  TMOD-2 AVP

A description of the semantic of the parameter values can be found in [RFC2215] (Shenker, S. and J. Wroclawski, “General Characterization Parameters for Integrated Service Network Elements,” September 1997.). The coding for the TMOD-2 AVP is as follows:

  TMOD-2  ::= < AVP Header: TBD >
              { Token-Rate }
              { Bucket-Depth }
              { Peak-Traffic-Rate }
              { Minimum-Policed-Unit }
              { Maximum-Packet-Size }



 TOC 

3.3.  Bandwidth AVP

The Bandwidth AVP (AVP Code TBD) is of type Float32 and is measured in octets of IP datagrams per second.



 TOC 

3.4.  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] (Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, “Per Hop Behavior Identification Codes,” June 2001.). The registries needed for usage with [RFC3140] (Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, “Per Hop Behavior Identification Codes,” June 2001.) 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).



 TOC 

3.4.1.  Case 1: Single PHB

As prescribed in [RFC3140] (Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, “Per Hop Behavior Identification Codes,” June 2001.), 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)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

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)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

3.4.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] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.). 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.

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] (Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, “Assured Forwarding PHB Group,” June 1999.) 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)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

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 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 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 a 8 octet registry is defined field that is represented by a 4-octet vendor and 4-octet specifier field. The vendor field contains an Enterprise Number as defined in [RFC2578] (McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Structure of Management Information Version 2 (SMIv2),” April 1999.) taken from the values maintained in the IANA Enterprise Numbers registry. If the four octets of the vendor field 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.



 TOC 

5.  IANA Considerations



 TOC 

5.1.  AVP Codes

IANA is requested to allocate AVP codes in the IETF IANA controlled namespace registry specified in Section 11.1.1 of [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) for the following AVPs that are defined in this document.

+------------------------------------------------------------------+
|                                       AVP  Section               |
|AVP Name                               Code Defined   Data Type   |
+------------------------------------------------------------------+
|TMOD-1                                 TBD  3.1       Grouped     |
|Token-Rate                             TBD  3.1.1     Float32     |
|Bucket-Depth                           TBD  3.1.2     Float32     |
|Peak-Traffic-Rate                      TBD  3.1.3     Float32     |
|Minimum-Policed-Unit                   TBD  3.1.4     Unsigned32  |
|Maximum-Packet-Size                    TBD  3.1.5     Unsigned32  |
|TMOD-2                                 TBD  3.2       Grouped     |
|Bandwidth                              TBD  3.3       Float32     |
|PHB-Class                              TBD  3.7       Unsigned32  |
+------------------------------------------------------------------+



 TOC 

5.2.  QoS Profile

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

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.

This document requests IANA to create such a registry and to allocate the value zero (0) for the QoS profile defined in this document.

Alternative vendor-specific QoS profiles can be created and identified with a Enterprise Number taken from the IANA registry created by [RFC2578] (McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Structure of Management Information Version 2 (SMIv2),” April 1999.) 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.



 TOC 

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 a AAA protocol. Security considerations are described in documents using this specification.



 TOC 

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, 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 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. Chris Newman and Pasi Eronen provided feedback during the IESG review.



 TOC 

8.  References



 TOC 

8.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2210] Wroclawski, J., “The Use of RSVP with IETF Integrated Services,” RFC 2210, September 1997 (TXT, HTML, XML).
[RFC2215] Shenker, S. and J. Wroclawski, “General Characterization Parameters for Integrated Service Network Elements,” RFC 2215, September 1997 (TXT, HTML, XML).
[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 (TXT, HTML, XML).
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Structure of Management Information Version 2 (SMIv2),” STD 58, RFC 2578, April 1999 (TXT).
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, “Per Hop Behavior Identification Codes,” RFC 3140, June 2001 (TXT).
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” RFC 3588, September 2003 (TXT).


 TOC 

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 (TXT, HTML, XML).
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, “Assured Forwarding PHB Group,” RFC 2597, June 1999 (TXT).
[RFC2697] Heinanen, J. and R. Guerin, “A Single Rate Three Color Marker,” RFC 2697, September 1999 (TXT).
[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 (TXT).
[RFC3260] Grossman, D., “New Terminology and Clarifications for Diffserv,” RFC 3260, April 2002 (TXT).


 TOC 

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