Diameter Maintenance and                                J. Korhonen, Ed.
Extensions (DIME)                                            TeliaSonera
Internet-Draft                                          H. Tschofenig
Internet-Draft                                    Nokia Siemens Networks
Intended status: Standards Track                  Nokia Siemens Networks                       December 18, 2008
Expires: May 5, June 21, 2009                                    November 1, 2008

         Quality of Service Parameters for Usage with the AAA Framework
                 draft-ietf-dime-qos-parameters-07.txt Diameter
                 draft-ietf-dime-qos-parameters-08.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 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 May 5, June 21, 2009.

Copyright Notice

   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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  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 RADIUS and 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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  3  4
   3.  QoS Parameter Overview . . Encoding . . . . . . . . . . . . . . . . . . . .  3  4
     3.1.  Traffic Model Parameter  . . . . . . . . . . . .  TMOD-1 AVP . . . . .  3
     3.2.  Constraints Parameters . . . . . . . . . . . . . . . . . .  3
     3.3.  Traffic Handling Directives .  4
       3.1.1.  TMOD-Rate AVP  . . . . . . . . . . . . . .  5
     3.4.  Traffic Classifiers . . . . . .  4
       3.1.2.  TMOD-Size AVP  . . . . . . . . . . . . .  5
   4.  Parameter Encoding . . . . . . .  4
       3.1.3.  Peak-Data-Rate AVP . . . . . . . . . . . . . . .  5
     4.1.  Parameter Header . . .  4
       3.1.4.  Minimum-Policed-Unit AVP . . . . . . . . . . . . . . .  4
     3.2.  TMOD-2 AVP . . .  5
     4.2.  TMOD-1 Parameter . . . . . . . . . . . . . . . . . . . . .  5
     4.3.  TMOD-2 Parameter . . . . . . . . . . . . . . . .
     3.3.  Priority AVP . . . . .  6
     4.4.  Path Latency Parameter . . . . . . . . . . . . . . . . . .  7
     4.5.  Path Jitter Parameter  5
       3.3.1.  Preemption-Priority AVP  . . . . . . . . . . . . . . .  5
       3.3.2.  Defending-Priority AVP . . .  7
     4.6.  Path PLR Parameter . . . . . . . . . . . . .  5
     3.4.  Admission-Priority AVP . . . . . . .  8
     4.7.  Path PER Parameter . . . . . . . . . . .  5
     3.5.  ALRP AVP . . . . . . . . .  8
     4.8.  Slack Term Parameter . . . . . . . . . . . . . . . .  6
       3.5.1.  ALRP-Namespace AVP . . .  8
     4.9.  Preemption Priority amp; Defending Priority Parameters . .  9
     4.10. Admission Priority Parameter . . . . . . . . . . . . .  6
       3.5.2.  ALRP-Priority AVP  . .  9
     4.11. Application-Level Resource Priority (ALRP) Parameter . . . 10
     4.12. Excess Treatment Parameter . . . . . . . . . . . . .  6
     3.6.  PHB-Class AVP  . . . 11
     4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 12
       4.13.1.  6
       3.6.1.  Case 1: Single PHB . . . . . . . . . . . . . . . . . 12
       4.13.2. .  6
       3.6.2.  Case 2: Set of PHBs  . . . . . . . . . . . . . . . . . 12
       4.13.3.  7
       3.6.3.  Case 3: Experimental or Local Use PHBs . . . . . . . 13
     4.14. DSTE Class Type Parameter .  7
     3.7.  DSTE-Class-Type AVP  . . . . . . . . . . . . . . . 13
     4.15. Y.1541 QoS Class Parameter . . . .  7
   4.  Extensibility  . . . . . . . . . . . . 14
   5.  Extensibility . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . 14
   6.  IANA Considerations . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . 15
     6.1.  QoS Profile . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . 15
     6.2.  Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 15
     6.3.  Excess Treatment Parameter . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  Acknowledgements . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1. 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2. 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 18 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20 12

1.  Introduction

   This document defines a number of Quality of Service (QoS) parameters
   that can be reused for conveying QoS information within RADIUS and
   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.

2.  Terminology and Abbreviations

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Diameter
   protocol.

   This document are to be interpreted as described in RFC2119 [RFC2119].

3.  Parameter Overview

3.1.  Traffic Model Parameter defines an initial QoS profile containing a set of QoS
   AVPs.

   The Traffic Model traffic model (TMOD) parameter is a container AVPs are containers consisting of four
   sub-parameters: AVPs
   and is a way to describe the traffic source.

   o  rate (r)
   o  bucket size (b)
   o  peak rate (p)
   o  minimum policed unit (m)

   All four sub-parameters MUST

   The encoding of <TMOD-1> and <TMOD-2> can be included found in Section 3.1 and
   Section 3.2 and the TMOD parameter.  The
   TMOD parameter semantic is a mathematically complete way to describe the
   traffic source.  If, described in [RFC2210] and in
   [RFC2215]. <TMOD-2> is, for example, TMOD needed by some DiffServ
   applications.  I t is set to specify bandwidth
   only, then set r = peak typically assumed that DiffServ EF traffic is
   shaped at the ingress by a single rate = p, b = large, m = large.  As another
   example if token bucket.  Therefore, a
   single TMOD parameter is set sufficient to signal DiffServ EF traffic.
   However, for TCP traffic, then set r = average rate, b
   = large, p = large.

3.2.  Constraints Parameters

   <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QoS DiffServ AF traffic two sets of token bucket parameters describing
   are needed, one token bucket for the desired path latency, path jitter average traffic and path
   error rate respectively.

   The <Path Latency> parameter refers to the accumulated latency of the
   packet forwarding process associated with each QoS aware node along
   the path, where the latency is defined to be one token
   bucket for the mean packet delay
   added by each such node.  This delay results from speed-of-light
   propagation delay, from packet processing limitations, or both.  The
   mean delay reflects the variable queuing delay that may be present.

   The purpose of this parameter is to provide burst traffic.  [RFC2697] defines a minimum path latency
   for use with services Single Rate Three
   Color Marker (srTCM), which provide estimates or bounds on additional
   path delay [RFC2212].

   The procedures for collecting path latency information are outside
   the scope of this document.

   The <Path Jitter> parameter refers meters a traffic stream and marks its
   packets according to the accumulated jitter of the
   packet forwarding process associated with each QoS aware node along
   the path, where the jitter is defined three traffic parameters, Committed Information
   Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS),
   to be the nominal jitter added
   by each such node.  IP packet jitter, either green, yellow, or delay variation, red.  A packet is defined
   in Section 3.4 of RFC 3393 [RFC3393], (Type-P-One-way-ipdv), and
   where marked green if it
   does not exceed the selection function includes CBS, yellow if it does exceed the packet with minimum delay
   such CBS, but not
   the EBS, and red otherwise.  [RFC2697] defines specific procedures
   using two token buckets that run at the distribution is equivalent same rate.  Therefore, two
   TMOD AVPs are sufficient to 2-point delay variation
   in [Y.1540].  The suggested evaluation interval is 1 minute.  This
   jitter results from packet processing limitations, and includes any
   variable queuing delay which may be present.  The purpose distinguish among three levels of this
   parameter drop
   precedence.  An example is to provide a nominal path jitter for use with services
   that provide estimates or bounds on additional path delay [RFC2212].

   The procedures for collecting path jitter information are outside also described in the
   scope appendix of this document.
   [RFC2597].

   The <Path PLR> parameter <Preemption-Priority> AVP refers to the accumulated packet loss rate
   (PLR) priority of the packet forwarding process associated a new flow
   compared with each QoS aware
   node along the path where the path PLR <Defending-Priority> AVP of previously admitted
   flows.  Once a flow is defined to be admitted, the PLR added
   by each such node. preemption priority becomes
   irrelevant.  The <Path PER> parameter refers <Defending-Priority> AVP is used to the accumulated packet error rate
   (PER) of the packet forwarding process associated compare with each QoS aware
   node, where the path PER
   preemption priority of new flows.  For any specific flow, its
   preemption priority is defined to be the PER added by each such
   node.

   The <Slack Term> parameter refers to the difference between desired
   delay and delay obtained by using bandwidth reservation, and which is
   used to reduce the resource reservation for a flow [RFC2212].

   The <Preemption Priority> parameter refers to the priority of the new
   flow compared with the <Defending Priority> of previously admitted
   flows.  Once a flow is admitted, the preemption priority becomes
   irrelevant.  The <Defending Priority> parameter is used to compare
   with the preemption priority of new flows.  For any specific flow,
   its preemption priority MUST always be less than or equal always less than or equal to the defending
   priority. <Admission Priority>

   The <Admission-Priority> AVP and <RPH Priority> <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.

3.3.  Traffic Handling Directives

   The <Excess Treatment> parameter describes how a QoS aware node will
   process excess traffic, that is, out-of-profile traffic.  Dopping,
   shaping or remarking are possible actions.

3.4.  Traffic Classifiers

   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., Y.1541 QoS class or a DiffServ-aware MPLS
   traffic engineering (DSTE) class type [RFC3564], [RFC4124].

4.  Parameter Encoding

4.1.  Parameter Header

   Each QoS parameter is encoded type, as described in TLV format.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |M|r|r|r|     Parameter ID      |r|r|r|r|         Length        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    M Flag: When set indicates the subsequent parameter MUST be
            interpreted. If the M flag is set [RFC3564] and
   in [RFC4124], using the parameter is not
            understood then it leads to an error. If the M flag is not
            set <DSTE-Class-Type> AVP.

2.  Terminology and then not understood then it can be ignored. Abbreviations

   The r bits key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are reserved.

    Parameter ID: Assigned to each individual QoS parameter

    Length: Indicates the length of the subsequent data be interpreted as described in 32-bit words.

4.2.  TMOD-1 RFC2119 [RFC2119].

3.  QoS Parameter

   <TMOD-1> = <r> <b> <p> <m> [RFC2210] , [RFC2215] Encoding

3.1.  TMOD-1 AVP

   The above notation means that the 4 <TMOD-1> sub-parameters must be
   carried in the <TMOD-1> parameter. TMOD-1 AVP is obtained from [RFC2210] and [RFC2215].  The coding for
   structure of the <TMOD-1>
   parameter AVP is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           1           |r|r|r|r|          4            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  TMOD Rate-1 [r] (32-bit IEEE floating point number)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  TMOD Size-1 [b] (32-bit IEEE floating point number)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Peak Data Rate-1 [p] (32-bit IEEE floating point number)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Minimum Policed Unit-1 [m] (32-bit unsigned integer)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The <TMOD> parameters are represented by three floating point numbers
   in single-precision IEEE floating point format followed by one 32-bit
   integer in network byte order.  The first floating point value

                       TMOD-1  ::= < AVP Header: TBD >
                                   { TMOD-Rate }
                                   { TMOD-Size }
                                   { Peak-Data-Rate }
                                   { Minimum-Policed-Unit }

3.1.1.  TMOD-Rate AVP

   The TMOD-Rate AVP (AVP Code TBD) is of type Float32 and contains the
   rate (r), the second floating point value (r).

3.1.2.  TMOD-Size AVP

   The TMOD-Size AVP (AVP Code TBD) is of type Float32 and contains the
   bucket size (b), the
   third floating point (b).

3.1.3.  Peak-Data-Rate AVP

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

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

   When r, b, and p terms are represented as IEEE floating point values,
   the sign bit MUST be zero (all values MUST be non-negative).
   Exponents less than 127 (i.e., 0) are prohibited.  Exponents greater
   than 162 (i.e., positive 35) are discouraged, except for specifying a
   peak rate of infinity.  Infinity is represented with an exponent of
   all ones (255) and a sign bit and mantissa of all zeroes.

4.3.

3.2.  TMOD-2 Parameter AVP

   A description of the semantic of the parameter values can be found in
   [RFC2215].  The <TMOD-2> parameter may be needed TMOD-2 AVP is useful in a DiffServ environment.  The
   coding for the <TMOD-2> parameter TMOD-2 AVP is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           2           |r|r|r|r|          4            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  TMOD Rate-2 [r] (32-bit IEEE floating point number)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  TMOD Size-2 [b] (32-bit IEEE floating point number)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Peak Data Rate-2 [p] (32-bit IEEE floating point number)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Minimum Policed Unit-2 [m] (32-bit unsigned integer)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   When r, b, and p terms are represented as IEEE floating point values,
   the sign bit MUST be zero (all values MUST be non-negative).

   Exponents less than 127 (i.e., 0) are prohibited.  Exponents greater
   than 162 (i.e., positive 35) are discouraged, except for specifying a
   peak rate of infinity.  Infinity

                       TMOD-2  ::= < AVP Header: TBD >
                                   { TMOD-Rate }
                                   { TMOD-Size }
                                   { Peak-Data-Rate }
                                   { Minimum-Policed-Unit }

3.3.  Priority AVP

   The Priority AVP is represented with an exponent of
   all ones (255) and a sign bit and mantissa grouped AVP consisting of all zeroes.

4.4.  Path Latency Parameter two AVPs, the
   Preemption-Priority and the Defending-Priority AVP.  A description of
   the semantic of the parameter values can be found in
   [RFC2210],[RFC2215].  The coding for the <Path Latency> parameter [RFC3181].

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

3.3.1.  Preemption-Priority AVP

   The Preemption-Priority AVP (AVP Code TBD) is
   as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           3           |r|r|r|r|          1            |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      |                Path Latency (32-bit integer)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Path Latency is a single 32-bit integer in network byte order.
   The composition rule for the <Path Latency> parameter is summation
   with a clamp of (2**32 - 1) on the maximum value.  The latencies are
   average values reported in units of one microsecond.  A system with
   resolution less than one microsecond MUST set unused digits to zero.

4.5.  Path Jitter Parameter

   The coding for the <Path Jitter> parameter is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           4           |r|r|r|r|          4            |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      |          Path Jitter STAT1(variance) (32-bit integer)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Path Jitter STAT2(99.9%-ile) (32-bit integer)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Path Jitter STAT3(minimum Latency) (32-bit integer)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Path Jitter STAT4(Reserved)        (32-bit integer)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   The Path Jitter is a set of four 32-bit integers in network byte
   order.  The Path Jitter parameter is the combination of four
   statistics describing the Jitter distribution with a clamp of (2**32
   - 1) on the maximum of each value.  The jitter STATs are reported in
   units of one microsecond.

4.6.  Path PLR Parameter

   The coding for the <Path PLR> parameter is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           5           |r|r|r|r|          1            |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      |             Path Packet Loss Ratio (32-bit floating point)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Path PLR is a single 32-bit single precision IEEE floating point
   number in network byte order.  The PLRs are reported in units of
   10^-11.  A system with resolution less than one microsecond MUST set
   unused digits to zero.

4.7.  Path PER Parameter

   The coding for the <Path PER> parameter is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           6           |r|r|r|r|          1            |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      |             Path Packet Error Ratio (32-bit floating point)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Path PER is a single 32-bit single precision IEEE floating point
   number in network byte order.  The PERs are reported in units of
   10^-11.  A system with resolution less than one microsecond MUST set
   unused digits to zero.

4.8.  Slack Term Parameter

   A description of the semantic of the parameter values can be found in
   [RFC2212], [RFC2215].  The coding for the <Slack Term> parameter is
   as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           7           |r|r|r|r|          1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Slack Term [S]  (32-bit integer)                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Slack Term parameter S is a 32-bit integer value in network byte
   order and is measured in microseconds.  S is represented as a 32-bit
   integer.

4.9.  Preemption Priority amp; Defending Priority Parameters

   A description of the semantic of the parameter values can be found in
   [RFC3181].

   The coding for the <Preemption Priority> & <Defending Priority> sub-
   parameters is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           8           |r|r|r|r|          1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Preemption Priority        |      Defending Priority       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Preemption Priority: The priority of the new flow compared with the
   defending priority of previously admitted flows.  Higher values
   represent higher priority.

   Defending Priority: 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.

   As specified in [RFC3181], <Preemption Priority> & <Defending
   Priority> are 16-bit integer values.  They are represented in network
   byte order.

4.10.  Admission Priority Parameter

   The coding for the <Admission Priority> parameter is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           9           |r|r|r|r|          1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Admis.Priority|                  (Reserved)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The 'Admis.Priority' field is a 8 bit unsigned integer in network
   byte order.

   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 parameter defined in Section 6.2.9 of [I-D.ietf-nsis-qspec],
   or in the Admission Priority parameter defined in Section 3.1 of
   [I-D.ietf-tsvwg-emergency-rsvp].  In other words, a given value
   inside the Admission Priority information element defined in the
   present document, inside the [I-D.ietf-nsis-qspec] Admission Priority
   parameter or inside the [I-D.ietf-tsvwg-emergency-rsvp] Admission
   Priority parameter, refers to the same Admission Priority.

4.11.  Application-Level Resource Priority (ALRP) Parameter

   A description of the semantic of the parameter values can be found in
   [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp].  The coding for
   parameter is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           10          |r|r|r|r|          1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       ALRP Namespace          | (Reserved)    | ALRP Priority |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The ALRP Namespace field is a 16 bits long unsigned integer in
   network byte order and the ALRP Priority field is an 8 bit long
   unsigned integer in network byte order containing the specific
   priority value.

   [RFC4412] defines a resource priority header and established the
   initial registry; the encoding of the values in that registry was
   later extended by [I-D.ietf-tsvwg-emergency-rsvp].

4.12.  Excess Treatment Parameter

   The coding for the <Excess Treatment> parameter is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           11          |r|r|r|r|          1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Excess Trtmnt | Remark Value  |         Reserved              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Excess Treatment (8 bit unsigned integer value in network byte
   order): Indicates how the QoS aware node should process out-of-
   profile traffic, that is, traffic not covered by the <Traffic>
   parameter.  Allowed values are as follows:

      0: drop
      1: shape
      2: remark
      3: no metering or policing is permitted

   Further values can be registered as described in Section 6.3.

   The default excess treatment in case that none is specified is that
   there are no guarantees to excess traffic, i.e., a QoS aware node can
   do what of type Unsigned32 and
   it finds suitable.

   When excess treatment indicates the priority of the new flow compared with the defending
   priority of previously admitted flows.  Higher values represent
   higher priority.

3.3.2.  Defending-Priority AVP

   The Defending-Priority AVP (AVP Code TBD) is set to 'drop', all marked traffic MUST be
   dropped by of type Unsigned32.
   Once a QoS aware node.

   When excess treatment is set to 'shape', it flow is expected that admitted, the QoS
   Desired object carries a TMOD parameter.  Excess traffic preemption priority becomes irrelevant.
   Instead, its defending priority is used to be
   shaped to this TMOD.  When the shaping causes unbounded queue growth
   at compare with the shaper traffic can be dropped.

   When excess treatment
   preemption priority of new flows.

3.4.  Admission-Priority AVP

   The Admission-Priority AVP (AVP Code TBD) is set to 'remark', the excess treatment
   parameter MUST carry of type Unsigned32.

   The admission control priority of the remark value.  For example, packets may be
   remarked flow, in terms of access to drop remarked
   network bandwidth in order to pertain provide higher probability of call
   completion to a particular QoS class.  In selected flows.  Higher values represent higher
   priority.  A given admission priority is encoded in this information
   element using the latter case, remarking relates to a DiffServ-type model, where
   packets arrive marked same value as belonging to a certain QoS class, and when
   they are identified as excess, they should then be remarked to a
   different QoS Class.

   If 'no metering or policing is permitted' encoded in the Admission-
   Priority AVP defined in Section 3.1 of
   [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter).

3.5.  ALRP AVP

   The Application-Level Resource Priority (ALRP) AVP is signaled, a grouped AVP
   consisting of two AVPs, the QoS aware
   node should accept ALRP-Namespace and the excess treatment parameter set by ALRP-Priority AVP.

   A description of the sender
   with special care so that excess traffic should not cause a problem.
   To request semantic of the Null Meter [RFC3290] is especially strong, and should parameter values can be used with caution. found in
   [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp].  The Remark Value coding for
   parameter is as follows:

                       ALRP  ::= < AVP Header: TBD >
                                 { ALRP-Namespace }
                                 { ALRP-Priority }

3.5.1.  ALRP-Namespace AVP

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

3.5.2.  ALRP-Priority AVP

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

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

3.6.  PHB-Class AVP

   The PHB-Class AVP (AVP Code TBD) is an 8 bit unsigned integer value in network byte
   order.

4.13.  PHB Class Parameter 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 coding for the <PHB Class> parameter is as follows and encoding requires three
   different cases need to be differentiated.  The header format is
   shown in the subsequent figure below and is used by all three cases
   defined in the subsequent sub-sections.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           12          |r|r|r|r|          1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.13.1.  All
   bits indicated as "reserved" MUST be set to zero (0).

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

4.13.2.
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

4.13.3.
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

4.14.  DSTE Class Type Parameter

   A description of the semantic of the parameter values can be found in
   [RFC4124].  The coding for the <DSTE Class Type> parameter is as
   follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           13          |r|r|r|r|          1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |DSTE Cls. Type |                (Reserved)                     |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   DSTE Class Type: Indicates the DSTE class type.  Values currently
   allowed are 0, 1, 2, 3, 4, 5, 6, 7.  A value of 255 (all 1's) means
   that the <DSTE Class Type> parameter is not used.

4.15.  Y.1541 QoS Class Parameter

   A description of the semantic of the parameter values can be found in
   [Y.1541].  The coding for the <Y.1541 QoS Class> parameter is as
   follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|r|r|r|           14          |r|r|r|r|          1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Y.1541 QoS Cls.| 0|            (Reserved)         |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   Y.1541 QoS Class: Indicates
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.7.  DSTE-Class-Type AVP

   The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32.  A
   description of the Y.1541 QoS Class.  Values semantic of the parameter values can be found in
   [RFC4124].

   Currently, the values of alues currently allowed are 0, 1, 2, 3, 4, 5,
   6, 7.  A  The value of 255 (all 1's) means
   that zero (0) is marked as reserved in [RFC4124].
   Furthermore, the <Y.1541 QoS Class> parameter CLASSTYPE attribute in [RFC4124] is not used.

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

6.

5.  IANA Considerations

   This section defines the registries and initial codepoint
   assignments, in accordance with BCP 26 RFC 5226 [RFC5226].  It also
   defines the procedural requirements to be followed by IANA in
   allocating new codepoints.

5.1.  AVP Codes

   IANA is requested to create allocate AVP codes for the following registries listed AVPs that
   are defined in the
   subsections below.

6.1. 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  |
   +------------------------------------------------------------------+

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 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:
      1
      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.

6.2.  Parameter ID

   The Parameter ID refers to a 12 bit long field.

   The following values are allocated by this specification.

                  (0): <TMOD-1>
                  (1): <TMOD-2>
                  (2): <Path Latency>
                  (3): <Path Jitter>
                  (4): <Path PLR>
                  (5): <Path PER>
                  (6): <Slack Term>
                  (7): <Preemption Priority> & <Defending Priority>
                  (8): <Admission Priority>
                  (9): <ALRP>
                  (10): <Excess Treatment>
                  (11): <PHB Class>
                  (12): <DSTE Class Type>
                  (13): <Y.1541 QoS Class>

   The allocation policies for further values are as follows:
      14-127: Standards Action
      128-255: Private/Experimental Use
      255-4095: Specification Required

   A standards track document is required to depreciate, delete, or
   modify existing Parameter IDs.

6.3.  Excess Treatment Parameter

   The Excess Treatment parameter refers to an 8 bit long field.

   The following values are allocated by this specification:
      Excess Treatment Value 0: drop
      Excess Treatment Value 1: shape
      Excess Treatment Value 2: remark
      Excess Treatment Value3: no metering or policing is permitted
      Excess Treatment Values 4-63: Standards Action
      Excess Treatment Value 64-255: Reserved

   The 8 bit Remark Value allocation policies are as follows:
      0-63: Specification Required
      64-127: Private/Experimental Use
      128-255: Reserved

   The ALRP Namespace and ALRP Priority field inside the ALRP Parameter
   take their values from the registry created by [RFC4412] and extended
   with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions are
   required by IANA by this specification.

7.

6.  Security Considerations

   This document does not raise any security concerns as it only defines
   QoS parameters.

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

   We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt,
   Francois Le Faucheur, John Loughney, Martin
   Stiemerling, Dave Oran, An Nguyen, Ken Carlberg, Dave Oran, James
   Polk, Lars
   Eggert, 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.

9. comments and Scott Bradner for his Transport Area Directorate
   review.

8.  References

9.1.

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.

   [RFC2212]  Shenker, S., Partridge, C., and R. Guerin, "Specification
              of Guaranteed Quality of Service", RFC 2212,
              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.

   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              November 2002.

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

   [RFC4412]  Schulzrinne, H. and J. Polk, "Communications Resource
              Priority for the Session Initiation Protocol (SIP)",
              RFC 4412, February 2006.

   [Y.1541]   "ITU-T Recommendation Y.1541, Network Performance
              Objectives for IP-Based Services",  , 2006.

9.2.

8.2.  Informative References

   [I-D.ietf-nsis-qspec]
              Ash, G.,
              Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC
              Template", draft-ietf-nsis-qspec-20 draft-ietf-nsis-qspec-21 (work in progress), April
              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.

   [RFC2697]  Heinanen, J. and R. Guerin, "A Single Rate Three Color
              Marker", RFC 2697, September 1999.

   [RFC3290]  Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
              Informal Management Model for Diffserv Routers", RFC 3290,
              May 2002.

   [RFC3564]  Le Faucheur, F. and W. Lai, "Requirements for Support of
              Differentiated Services-aware MPLS Traffic Engineering",
              RFC 3564, July 2003.

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

   [Y.1540]   "ITU-T Recommendation Y.1540, Internet Protocol Data
              Communication Service - IP Packet Transfer and
              Availability Performance Parameters",  , December 2002.

Authors' Addresses

   Jouni Korhonen (editor)
   TeliaSonera
   Teollisuuskatu 13
   Sonera  FIN-00051
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Email: jouni.korhonen@teliasonera.com 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

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.