| TOC |
|
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 June 21, 2009.
Copyright (c) 2008 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.
This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter.
The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function.
1.
Introduction
2.
Terminology and Abbreviations
3.
QoS Parameter Encoding
3.1.
TMOD-1 AVP
3.1.1.
TMOD-Rate AVP
3.1.2.
TMOD-Size AVP
3.1.3.
Peak-Data-Rate AVP
3.1.4.
Minimum-Policed-Unit AVP
3.2.
TMOD-2 AVP
3.3.
Priority AVP
3.3.1.
Preemption-Priority AVP
3.3.2.
Defending-Priority AVP
3.4.
Admission-Priority AVP
3.5.
ALRP AVP
3.5.1.
ALRP-Namespace AVP
3.5.2.
ALRP-Priority AVP
3.6.
PHB-Class AVP
3.6.1.
Case 1: Single PHB
3.6.2.
Case 2: Set of PHBs
3.6.3.
Case 3: Experimental or Local Use PHBs
3.7.
DSTE-Class-Type AVP
4.
Extensibility
5.
IANA Considerations
6.
Security Considerations
7.
Acknowledgements
8.
References
8.1.
Normative References
8.2.
Informative References
§
Authors' Addresses
| TOC |
This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within the Diameter protocol.
This document defines an initial QoS profile containing a set of QoS AVPs.
The traffic model (TMOD) AVPs are containers consisting of four AVPs and is a way to describe the traffic source.
The encoding of <TMOD-1> and <TMOD-2> can be found in Section 3.1 (TMOD-1 AVP) and Section 3.2 (TMOD-2 AVP) and the semantic is described in [RFC2210] (Wroclawski, J., “The Use of RSVP with IETF Integrated Services,” September 1997.) and in [RFC2215] (Shenker, S. and J. Wroclawski, “General Characterization Parameters for Integrated Service Network Elements,” September 1997.). <TMOD-2> is, for example, needed by some DiffServ applications. I t 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.).
The <Preemption-Priority> AVP refers to the priority of a new flow compared with the <Defending-Priority> AVP of previously admitted flows. Once a flow is admitted, the preemption priority becomes irrelevant. The <Defending-Priority> AVP is used to compare with the preemption priority of new flows. For any specific flow, its preemption priority is always less than or equal to the defending priority.
The <Admission-Priority> AVP and <ALRP> AVP provide an essential way to differentiate flows for emergency services, ETS, E911, etc., and assign them a higher admission priority than normal priority flows and best-effort priority flows.
Resource reservations might refer to a packet processing with a particular DiffServ per-hop behavior (PHB) [RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.) (using the <PHB-Class> AVP) or to a particular QoS class, e.g., a DiffServ-aware MPLS traffic engineering (DSTE) class type, as described in [RFC3564] (Le Faucheur, F. and W. Lai, “Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering,” July 2003.) and in [RFC4124] (Le Faucheur, F., “Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering,” June 2005.), using the <DSTE-Class-Type> AVP.
| TOC |
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 |
| TOC |
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 >
{ TMOD-Rate }
{ TMOD-Size }
{ Peak-Data-Rate }
{ Minimum-Policed-Unit }
| TOC |
The TMOD-Rate AVP (AVP Code TBD) is of type Float32 and contains the rate (r).
| TOC |
The TMOD-Size AVP (AVP Code TBD) is of type Float32 and contains the bucket size (b).
| TOC |
The Peak-Data-Rate AVP (AVP Code TBD) is of type Float32 and contains the peak rate (p).
| TOC |
The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32 and contains the minimum policed unit (m).
| TOC |
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 TMOD-2 AVP is useful in a DiffServ environment. The coding for the TMOD-2 AVP is as follows:
TMOD-2 ::= < AVP Header: TBD >
{ TMOD-Rate }
{ TMOD-Size }
{ Peak-Data-Rate }
{ Minimum-Policed-Unit }
| TOC |
The Priority AVP is a grouped AVP consisting of two AVPs, the Preemption-Priority and the Defending-Priority AVP. A description of the semantic can be found in [RFC3181] (Herzog, S., “Signaled Preemption Priority Policy Element,” October 2001.).
Priority ::= < AVP Header: TBD >
{ Preemption-Priority }
{ Defending-Priority }
| TOC |
The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and it indicates the priority of the new flow compared with the defending priority of previously admitted flows. Higher values represent higher priority.
| TOC |
The Defending-Priority AVP (AVP Code TBD) is of type Unsigned32. Once a flow is admitted, the preemption priority becomes irrelevant. Instead, its defending priority is used to compare with the preemption priority of new flows.
| TOC |
The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32.
The admission control priority of the flow, in terms of access to network bandwidth in order to provide higher probability of call completion to selected flows. Higher values represent higher priority. A given admission priority is encoded in this information element using the same value as when encoded in the Admission-Priority AVP defined in Section 3.1 of [I‑D.ietf‑tsvwg‑emergency‑rsvp] (Faucheur, F., Polk, J., and K. Carlberg, “Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority,” March 2010.) (Admission Priority parameter).
| TOC |
The Application-Level Resource Priority (ALRP) AVP is a grouped AVP consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP.
A description of the semantic of the parameter values can be found in [RFC4412] (Schulzrinne, H. and J. Polk, “Communications Resource Priority for the Session Initiation Protocol (SIP),” February 2006.) and in [I‑D.ietf‑tsvwg‑emergency‑rsvp] (Faucheur, F., Polk, J., and K. Carlberg, “Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority,” March 2010.). The coding for parameter is as follows:
ALRP ::= < AVP Header: TBD >
{ ALRP-Namespace }
{ ALRP-Priority }
| TOC |
The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32.
| TOC |
The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32.
[RFC4412] (Schulzrinne, H. and J. Polk, “Communications Resource Priority for the Session Initiation Protocol (SIP),” February 2006.) defines a resource priority header and established the initial registry. That registry was later extended by [I‑D.ietf‑tsvwg‑emergency‑rsvp] (Faucheur, F., Polk, J., and K. Carlberg, “Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority,” March 2010.).
| TOC |
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 |
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 |
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 |
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 |
The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A description of the semantic of the parameter values can be found in [RFC4124] (Le Faucheur, F., “Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering,” June 2005.).
Currently, the values of alues currently allowed are 1, 2, 3, 4, 5, 6, 7. The value of zero (0) is marked as reserved in [RFC4124] (Le Faucheur, F., “Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering,” June 2005.). Furthermore, the CLASSTYPE attribute in [RFC4124] (Le Faucheur, F., “Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering,” June 2005.) is 32 bits in length with 29 bits reserved.
| TOC |
This document is designed with extensibility in mind given that different organizations and groups are used to define 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 this 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.
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 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 the registry is maintained by IANA as Enterprise Numbers defined in [RFC2578] (McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Structure of Management Information Version 2 (SMIv2),” April 1999.), and any other value represents a vendor-specific Object Identifier (OID). IANA created registry is split into two value ranges; one range uses the "Standards Action" and the second range uses "Specification Required" allocation policy. The latter range is meant to be used by organizations outside the IETF.
| TOC |
| TOC |
IANA is requested to allocate AVP codes for the following AVPs that are defined in this document.
+------------------------------------------------------------------+ | AVP Section | |AVP Name Code Defined Data Type | +------------------------------------------------------------------+ |TMOD-1 TBD 3.1 Grouped | |TMOD-Rate TBD 3.1.1 Float32 | |TMOD-Size TBD 3.1.2 Float32 | |Peak-Data-Rate TBD 3.1.3 Float32 | |Minimum-Policed-Unit TBD 3.1.4 Unsigned32 | |TMOD-2 TBD 3.2 Grouped | |Priority TBD 3.3 Grouped | |Preemption-Priority TBD 3.3.1 Unsigned32 | |Defending-Priority TBD 3.3.2 Unsigned32 | |Admission-Priority TBD 3.4 Unsigned32 | |ALRP TBD 3.5 Grouped | |ALRP-Namespace TBD 3.5.1 Unsigned32 | |ALRP-Priority TBD 3.5.2 Unsigned32 | |PHB-Class TBD 3.6 Unsigned32 | |DSTE-Class-Type TBD 3.7 Unsigned32 | +------------------------------------------------------------------+
| TOC |
IANA is requested to create the following registry.
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 the registry is maintained by IANA, and any other value represents a vendor-specific Object Identifier (OID).
The specifier field indicates the actual QoS profile. The vendor field 0x00000000 is reserved to indicate that the values in the specifier field are maintained by IANA. This document requests IANA to create such a registry and to allocate the value zero (0) for the QoS profile defined in this document.
For any other vendor field, the specifier field is maintained by the vendor.
For the IANA maintained QoS profiles the following allocation policy is defined:
0 to 511: Standards Action
512 to 4095: Specification Required
Standards action is required to depreciate, delete, or modify existing QoS profile values in the range of 0-511 and a specification is required to depreciate, delete, or modify existing QoS profile values in the range of 512-4095.
| TOC |
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 |
The authors would like to thank the NSIS QSPEC [I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.) authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the NSIS working group chairs (John Loughney and Martin Stiemerling) and the former Transport Area Directors (Allison Mankin, Jon Peterson) for their help. This document re-uses content from the NSIS QSPEC [I‑D.ietf‑nsis‑qspec] (Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” January 2010.) specification.
We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt, Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James Polk, Martin Stiemerling, and Magnus Westerlund for their help with resolving problems regarding the Admission Priority and the ALRP parameter.
Elwyn Davies provided a detailed review of the specification. Elwyn helped to investigate what QoS mechanisms are deployed in networks today. 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.
| TOC |
| TOC |
| TOC |
| [I-D.ietf-nsis-qspec] | Bader, A., Kappler, C., and D. Oran, “QoS NSLP QSPEC Template,” draft-ietf-nsis-qspec-24 (work in progress), January 2010 (TXT). |
| [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). |
| [RFC2697] | Heinanen, J. and R. Guerin, “A Single Rate Three Color Marker,” RFC 2697, September 1999 (TXT). |
| [RFC3290] | Bernet, Y., Blake, S., Grossman, D., and A. Smith, “An Informal Management Model for Diffserv Routers,” RFC 3290, May 2002 (TXT). |
| [RFC3564] | Le Faucheur, F. and W. Lai, “Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering,” RFC 3564, July 2003 (TXT). |
| [RFC5226] | Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT). |
| TOC |
| 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 |