Diameter Maintenance and                                J. Korhonen, Ed.
Extensions (DIME)                                          H. Tschofenig
Internet-Draft                                    Nokia Siemens Networks
Intended status: Standards Track                               E. Davies
Expires: July 26, September 10, 2009                             Folly Consulting
                                                        January 22,
                                                           March 9, 2009

         Quality of Service Parameters for Usage with Diameter
                 draft-ietf-dime-qos-parameters-09.txt
                 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 July 26, 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. 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, bandwidth, defending a bandwidth parameter, and preemption
   priority, admission priority, application-level resource priority,
   per-hop a per-
   hop behavior class, and DiffServ-aware Multiprotocol Label
   Switching (MPLS) traffic engineering. class object.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  4
   3.  QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . .  4
     3.1.  TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . .  4
       3.1.1.  TMOD-Rate  Token-Rate AVP . . . . . . . . . . . . . . . . . . . .  4
       3.1.2.  TMOD-Size  Bucket-Depth AVP . . . . . . . . . . . . . . . . . . . .  4
       3.1.3.  Peak-Data-Rate  Peak-Traffic-Rate AVP  . . . . . . . . . . . . . . . . . .  4
       3.1.4.  Minimum-Policed-Unit AVP . . . . . . . . . . . . . . .  4
     3.2.  TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Bandwidth
       3.1.5.  Maximum-Packet-Size AVP  . . . . . . . . . . . . . . . . . . . . . .  5
     3.4.  Priority
     3.2.  TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . .  5
       3.4.1.  Preemption-Priority AVP  . . . . . . . . . . . . . . .  5
       3.4.2.  Defending-Priority
     3.3.  Bandwidth AVP  . . . . . . . . . . . . . . . .  5
     3.5.  Admission-Priority AVP . . . . . . . . . . . . . . . . . .  5
     3.6.  ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . .  6
       3.6.1.  ALRP-Namespace AVP . . . . . . . . . . . . . . . . . .  6
       3.6.2.  ALRP-Priority AVP  . . . . . . . . . . . . . . . . . .  6
     3.7.
     3.4.  PHB-Class AVP  . . . . . . . . . . . . . . . . . . . . . .  6
       3.7.1.  5
       3.4.1.  Case 1: Single PHB . . . . . . . . . . . . . . . . . .  6
       3.7.2.  5
       3.4.2.  Case 2: Set of PHBs  . . . . . . . . . . . . . . . . .  7
       3.7.3.  6
       3.4.3.  Case 3: Experimental or Local Use PHBs . . . . . . . .  7
     3.8.  DSTE-Class-Type AVP  . . . . . . . . . . . . . . . . . . .  8  6
   4.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . .  8  6
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10  8
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 10

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.

   This document
   protocol [RFC3588].  It defines an initial QoS profile containing a
   set of QoS
   AVPs. Diameter encoded Attribute Value Pairs (AVPs) described using
   a modified version of the Augmented Backus-Naur Form (ABNF), see
   [RFC3588].  The datatypes are also taken from [RFC3588].

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

   o  token rate (r)
   o  bucket size depth (b)
   o  peak traffic rate (p)
   o  minimum policed unit (m)
   o  maximum packet size (M)

   The encoding of the <TMOD-1> and the <TMOD-2> AVP can be found in
   Section 3.1 and Section 3.2 and the semantic is 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 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] 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].

   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

   Resource reservations might refer to a packet processing with a
   particular DiffServ per-hop behavior (PHB) [RFC2475] (using the <PHB-
   Class> AVP) or to a particular QoS class, e.g., a DiffServ-aware MPLS
   traffic engineering (DSTE) class type, as <PHB-Class>
   AVP).  A generic description of the DiffServ architecture can be
   found in [RFC2475] and the Differentiated Services Field is described
   in [RFC3564] Section 3 of [RFC2474].  Updated terminology can be found in
   [RFC3260].  Standardized Per-Hop Behavior is, for example, described
   in [RFC2597] (Assured Forwarding Per-Hop Behavior) and in [RFC3246]
   (An Expedited Forwarding Per-Hop Behavior).

   The above-mentioned parameters are intended to support basic
   integrated and differentiated services functionality in [RFC4124], using the <DSTE-Class-Type> AVP. network.
   Additional parameters can be defined and standardized if required to
   support specific services in 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: TBD >
                 { TMOD-Rate Token-Rate }
                 { TMOD-Size Bucket-Depth }
                 { Peak-Data-Rate Peak-Traffic-Rate }
                 { Minimum-Policed-Unit }
                 { Maximum-Packet-Size }

3.1.1.  TMOD-Rate  Token-Rate AVP

   The TMOD-Rate Token-Rate AVP (AVP Code TBD) is of type Float32 and contains the
   rate (r). Float32.

3.1.2.  TMOD-Size  Bucket-Depth AVP

   The TMOD-Size Bucket-Depth AVP (AVP Code TBD) is of type Float32 and contains the
   bucket size (b). Float32.

3.1.3.  Peak-Data-Rate  Peak-Traffic-Rate AVP

   The Peak-Data-Rate Peak-Traffic-Rate AVP (AVP Code TBD) is of type Float32 and contains
   the peak rate (p). Float32.

3.1.4.  Minimum-Policed-Unit AVP

   The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32 and
   contains the minimum policed unit (m).

3.2.  TMOD-2 AVP

   A description of the semantic of the parameter values can be found in
   [RFC2215].  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 }

3.3.  Bandwidth AVP

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

3.4.  Priority AVP

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

                       Priority  ::= < AVP Header: TBD >
                                     { Preemption-Priority }
                                     { Defending-Priority }

3.4.1.  Preemption-Priority AVP

   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.

3.4.2.  Defending-Priority AVP

   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.

3.5.  Admission-Priority

3.1.5.  Maximum-Packet-Size AVP

   The Admission-Priority Maximum-Packet-Size 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] (Admission Priority parameter).

3.6.  ALRP AVP

   The Application-Level Resource Priority (ALRP) AVP is a grouped

3.2.  TMOD-2 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] and in [I-D.ietf-tsvwg-emergency-rsvp].
   [RFC2215].  The coding for
   parameter the TMOD-2 AVP is as follows:

                       ALRP

     TMOD-2  ::= < AVP Header: TBD >
                 { ALRP-Namespace Token-Rate }
                 { ALRP-Priority Bucket-Depth }

3.6.1.  ALRP-Namespace AVP

   The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32.

3.6.2.  ALRP-Priority
                 { Peak-Traffic-Rate }
                 { Minimum-Policed-Unit }
                 { Maximum-Packet-Size }

3.3.  Bandwidth AVP

   The ALRP-Priority Bandwidth AVP (AVP Code TBD) is of type Unsigned32.

   [RFC4412] defines a resource priority header Float32 and established the
   initial registry.  That registry was later extended by
   [I-D.ietf-tsvwg-emergency-rsvp].

3.7. is measured
   in octets of IP datagrams per second.

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].  The registries needed for usage with [RFC3140] 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).

3.7.1.

3.4.1.  Case 1: Single PHB

   As prescribed in [RFC3140], 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)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.7.2.

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

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

3.8.  DSTE-Class-Type AVP

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

   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].
   Furthermore, the CLASSTYPE attribute in [RFC4124] is 32 bits in
   length with 29 bits reserved.

4.  Extensibility

   This document is designed with extensibility in mind given that
   different organizations and groups are used to define 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 indicates the type contains an Enterprise Number as either
   standards-specified or vendor-specific.
   defined in [RFC2578] taken from the values maintained in the IANA
   Enterprise Numbers registry.  If the four octets of the vendor field
   are 0x00000000, 0x00000000 (reserved value for IANA), then the value is standards-specified
   and in the registry is maintained by
   specifier field MUST be registered with IANA as Enterprise Numbers defined
   in [RFC2578], and any (see Section 5.2).  If
   the vendor field is other than 0x00000000, the value of the specifier
   field represents a vendor-specific Object
   Identifier (OID).  IANA created registry value, where allocation is split into two value
   ranges; one range uses the "Standards Action" and
   responsibility of the second range
   uses "Specification Required" allocation policy.  The latter range is
   meant to be used by organizations outside enterprise indicated in the IETF. vendor field.

5.  IANA Considerations

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] 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
   |Token-Rate                             TBD  3.1.1     Float32     |
   |TMOD-Size
   |Bucket-Depth                           TBD  3.1.2     Float32     |
   |Peak-Data-Rate
   |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     |
   |Priority                               TBD  3.4       Grouped     |
   |Preemption-Priority                    TBD  3.4.1     Unsigned32  |
   |Defending-Priority                     TBD  3.4.2     Unsigned32  |
   |Admission-Priority                     TBD  3.5       Unsigned32  |
   |ALRP                                   TBD  3.6       Grouped     |
   |ALRP-Namespace                         TBD  3.6.1     Unsigned32  |
   |ALRP-Priority                          TBD  3.6.2     Unsigned32  |
   |PHB-Class                              TBD  3.7       Unsigned32  |
   |DSTE-Class-Type                        TBD  3.8       Unsigned32  |
   +------------------------------------------------------------------+

5.2.  QoS Profile

   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 the value
   is standards-specified and a registry and will be created to allocate the value zero (0) for maintain the
   QoS profile defined in this document.

   For any other vendor field, the specifier values.  The specifier field is maintained by the
   vendor.

   For indicates the IANA maintained
   actual QoS profiles profile.  Depending on the following allocation policy
   is defined: value requested, the action
   needed to request a new value is:
      0 to 511: Standards Action
      512 to 4095: 32767: Specification Required
      32768 to 4294967295: Reserved

   Standards action is required to add, depreciate, delete, or modify
   existing
   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-4095. 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] 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 a
   AAA protocol.  Security considerations are described in documents
   using this specification.

7.  Acknowledgements

   The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec]
   authors (Cornelia working group members
   Cornelia Kappler, Jerry Ash, Attila Bader, and Dave Oran), 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.  The authors of this document are thankful for the
   suggestions and input received from the NSIS QSPEC
   [I-D.ietf-nsis-qspec] authors.

   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 help with
   resolving problems feedback regarding some of the Admission Priority and the ALRP
   parameter. 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.

8.  References

8.1.  Normative References

   [I-D.ietf-tsvwg-emergency-rsvp]
              Faucheur, F., Polk, J., and K. Carlberg, "Resource
              ReSerVation Protovol (RSVP) Extensions for Emergency
              Services", draft-ietf-tsvwg-emergency-rsvp-09 (work in
              progress), October 2008.

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

   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
              "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [RFC3140]  Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
              "Per Hop Behavior Identification Codes", RFC 3140,
              June 2001.

   [RFC3181]  Herzog, S., "Signaled Preemption Priority Policy Element",
              RFC 3181, October 2001.

   [RFC4124]  Le Faucheur, F., "Protocol Extensions for Support of
              Diffserv-aware MPLS Traffic Engineering", RFC 4124,
              June 2005.

   [RFC4412]  Schulzrinne, H.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Polk, "Communications Resource
              Priority for the Session Initiation Protocol (SIP)",
              Arkko, "Diameter Base Protocol", RFC 4412, February 2006. 3588, September 2003.

8.2.  Informative References

   [I-D.ietf-nsis-qspec]
              Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC
              Template", draft-ietf-nsis-qspec-21 (work in progress),
              November 2008.

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

   [RFC3290]  Bernet, Y., Blake,

   [RFC3246]  Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
              J., Courtney, W., Davari, S., Grossman, D., Firoiu, V., and A. Smith, D.
              Stiliadis, "An
              Informal Management Model for Diffserv Routers", Expedited Forwarding PHB (Per-Hop
              Behavior)", RFC 3290,
              May 3246, March 2002.

   [RFC3564]  Le Faucheur, F.

   [RFC3260]  Grossman, D., "New Terminology and W. Lai, "Requirements for Support of
              Differentiated Services-aware MPLS Traffic Engineering",
              RFC 3564, July 2003.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines Clarifications for Writing an
              IANA Considerations Section in RFCs", BCP 26,
              Diffserv", RFC 5226,
              May 2008. 3260, April 2002.

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