[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-korhonen-dime-qos-parameters) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 5624

Diameter Maintenance and                                J. Korhonen, Ed.
Extensions (DIME)                                            TeliaSonera
Internet-Draft                                             H. Tschofenig
Intended status: Standards Track                  Nokia Siemens Networks
Expires: November 27, 2008                                  May 26, 2008


     Quality of Service Parameters for Usage with the AAA Framework
                 draft-ietf-dime-qos-parameters-05.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 is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 November 27, 2008.

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.







Korhonen & Tschofenig   Expires November 27, 2008               [Page 1]


Internet-Draft               QoS Parameters                     May 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Traffic Model Parameter  . . . . . . . . . . . . . . . . .  4
     1.2.  Constraints Parameters . . . . . . . . . . . . . . . . . .  4
     1.3.  Traffic Handling Directives  . . . . . . . . . . . . . . .  5
     1.4.  Traffic Classes  . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  6
   3.  AVP Definition . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  TMOD-Rate-1 AVP  . . . . . . . . . . . . . . . . . . .  6
       3.1.2.  TMOD-Size-1 AVP  . . . . . . . . . . . . . . . . . . .  6
       3.1.3.  Peak-Data-Rate-1 AVP . . . . . . . . . . . . . . . . .  6
       3.1.4.  Minimum-Policed-Unit-1 AVP . . . . . . . . . . . . . .  6
     3.2.  TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.2.1.  TMOD-Rate-2 AVP  . . . . . . . . . . . . . . . . . . .  7
       3.2.2.  TMOD-Size-2 AVP  . . . . . . . . . . . . . . . . . . .  7
       3.2.3.  Peak-Data-Rate-2 AVP . . . . . . . . . . . . . . . . .  7
       3.2.4.  Minimum-Policed-Unit-2 AVP . . . . . . . . . . . . . .  7
     3.3.  Path-Latency AVP . . . . . . . . . . . . . . . . . . . . .  7
     3.4.  Path-Jitter AVP  . . . . . . . . . . . . . . . . . . . . .  8
       3.4.1.  Path-Jitter-STAT1 AVP  . . . . . . . . . . . . . . . .  8
       3.4.2.  Path-Jitter-STAT2 AVP  . . . . . . . . . . . . . . . .  8
       3.4.3.  Path-Jitter-STAT3 AVP  . . . . . . . . . . . . . . . .  8
       3.4.4.  Path-Jitter-STAT4 AVP  . . . . . . . . . . . . . . . .  8
     3.5.  Path-PLR AVP . . . . . . . . . . . . . . . . . . . . . . .  8
     3.6.  Path-PER AVP . . . . . . . . . . . . . . . . . . . . . . .  9
     3.7.  Slack-Term AVP . . . . . . . . . . . . . . . . . . . . . .  9
     3.8.  Priority AVP . . . . . . . . . . . . . . . . . . . . . . .  9
       3.8.1.  Preemption-Priority AVP  . . . . . . . . . . . . . . .  9
       3.8.2.  Defending-Priority AVP . . . . . . . . . . . . . . . .  9
     3.9.  Admission-Priority AVP . . . . . . . . . . . . . . . . . .  9
     3.10. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 10
       3.10.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 10
       3.10.2. ALRP-Priority AVP  . . . . . . . . . . . . . . . . . . 10
     3.11. Excess-Treatment AVP . . . . . . . . . . . . . . . . . . . 10
       3.11.1. Excess-Treatment-Value AVP . . . . . . . . . . . . . . 11
       3.11.2. Remark-Value AVP . . . . . . . . . . . . . . . . . . . 11
       3.11.3. PHB-Class AVP  . . . . . . . . . . . . . . . . . . . . 12
       3.11.4. DSTE-Class-Type AVP  . . . . . . . . . . . . . . . . . 13
       3.11.5. Y.1541-QoS-Class AVP . . . . . . . . . . . . . . . . . 13
   4.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
     5.1.  QoS Profile  . . . . . . . . . . . . . . . . . . . . . . . 15
     5.2.  AVP Allocations  . . . . . . . . . . . . . . . . . . . . . 16
     5.3.  Excess-Treatment AVP . . . . . . . . . . . . . . . . . . . 16
     5.4.  DSTE-Class-Type AVP  . . . . . . . . . . . . . . . . . . . 16
     5.5.  Y.1541-QoS-Class AVP . . . . . . . . . . . . . . . . . . . 16



Korhonen & Tschofenig   Expires November 27, 2008               [Page 2]


Internet-Draft               QoS Parameters                     May 2008


   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20












































Korhonen & Tschofenig   Expires November 27, 2008               [Page 3]


Internet-Draft               QoS Parameters                     May 2008


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 subsequent section give an overview of the parameters defined by
   this document.

1.1.  Traffic Model Parameter

   The Traffic Model (TMOD) parameter is a container consisting of four
   sub-parameters:
   o  rate (r)
   o  bucket size (b)
   o  peak rate (p)
   o  minimum policed unit (m)

   The TMOD parameter is a mathematically complete way to describe the
   traffic source.  If, for example, TMOD is set to specify bandwidth
   only, then set r = peak rate = p, b = large, m = large.  As another
   example if TMOD is set for TCP traffic, then set r = average rate, b
   = large, p = large.

1.2.  Constraints Parameters

   <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QoS
   parameters describing the desired path latency, path jitter and path
   bit 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 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 a minimum path latency
   for use with services which provide estimates or bounds on additional
   path delay [RFC2212].

   The <Path Jitter> parameter refers to the accumulated jitter of the
   packet forwarding process associated with each QoS aware node along
   the path, where the jitter is defined to be the nominal jitter added
   by each such node.  IP packet jitter, or delay variation, is defined
   in Section 3.4 of RFC 3393 [RFC3393], (Type-P-One-way-ipdv), and
   where the selection function includes the packet with minimum delay
   such that the distribution is equivalent to 2-point delay variation
   in [Y.1540].  The suggested evaluation interval is 1 minute.  This



Korhonen & Tschofenig   Expires November 27, 2008               [Page 4]


Internet-Draft               QoS Parameters                     May 2008


   jitter results from packet processing limitations, and includes any
   variable queuing delay which may be present.  The purpose of this
   parameter 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 the
   scope of this document.

   The <Path PLR> parameter refers to the accumulated packet loss rate
   (PLR) of the packet forwarding process associated with each QoS aware
   node along the path where the PLR is defined to be the PLR added by
   each such node.

   The <Path PER> parameter refers to the accumulated packet error rate
   (PER) of the packet forwarding process associated with each QoS aware
   node, where the PER 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 to the
   defending priority. <Admission Priority> and <RPH Priority> 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.

1.3.  Traffic Handling Directives

   The <Excess Treatment< parameter describes how a QoS aware node will
   process excess traffic, that is, out-of-profile traffic.  Excess
   traffic MAY be dropped, shaped and/or remarked.

1.4.  Traffic Classes

   Resource reservations might refer to a packet processing with a
   particular DiffServ per-hop behavior (PHB) [RFC2475] or to a
   particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS
   traffic engineering (DSTE) class type [RFC3564], [RFC4124].







Korhonen & Tschofenig   Expires November 27, 2008               [Page 5]


Internet-Draft               QoS Parameters                     May 2008


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.  AVP Definition

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-1 }
                                   { TMOD-Size-1 }
                                   { Peak-Data-Rate-1 }
                                   { Minimum-Policed-Unit-1 }

3.1.1.  TMOD-Rate-1 AVP

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

3.1.2.  TMOD-Size-1 AVP

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

3.1.3.  Peak-Data-Rate-1 AVP

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

3.1.4.  Minimum-Policed-Unit-1 AVP

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

   The values r, b, and p are represented as IEEE floating point values
   and 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.





Korhonen & Tschofenig   Expires November 27, 2008               [Page 6]


Internet-Draft               QoS Parameters                     May 2008


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-2 }
                                   { TMOD-Size-2 }
                                   { Peak-Data-Rate-2 }
                                   { Minimum-Policed-Unit-2 }

3.2.1.  TMOD-Rate-2 AVP

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

3.2.2.  TMOD-Size-2 AVP

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

3.2.3.  Peak-Data-Rate-2 AVP

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

3.2.4.  Minimum-Policed-Unit-2 AVP

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

   The values r, b, and p are represented as IEEE floating point values
   and 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.

3.3.  Path-Latency AVP

   The semantic of the parameter values can be found in [RFC2210] and
   [RFC2215].  The Path-Latency AVP (AVP Code TBD) is of type Integer32.

   The composition rule for the path latency 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



Korhonen & Tschofenig   Expires November 27, 2008               [Page 7]


Internet-Draft               QoS Parameters                     May 2008


   resolution less than one microsecond MUST set unused digits to zero.
   The total latency added across all QoS aware nodes along the path can
   range as high as (2**32)-2.

3.4.  Path-Jitter AVP

   The coding for the Path-Jitter AVP is as follows:

                       Path-Jitter  ::= < AVP Header: TBD >
                                        { Path-Jitter-STAT1 }
                                        { Path-Jitter-STAT2 }
                                        { Path-Jitter-STAT3 }
                                        { Path-Jitter-STAT4 }

3.4.1.  Path-Jitter-STAT1 AVP

   The Path-Jitter-STAT1 AVP (AVP Code TBD) is of type Integer32 and
   contains the variance.

3.4.2.  Path-Jitter-STAT2 AVP

   The Path-Jitter-STAT2 AVP (AVP Code TBD) is of type Integer32 and
   contains the 99.9%-ile.

3.4.3.  Path-Jitter-STAT3 AVP

   The Path-Jitter-STAT3 AVP (AVP Code TBD) is of type Integer32 and
   contains the minimum latency.

3.4.4.  Path-Jitter-STAT4 AVP

   The Path-Jitter-STAT4 AVP (AVP Code TBD) is of type Integer32 and is
   reserved for future use.

   The Path-Jitter AVP 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.

3.5.  Path-PLR AVP

   The Path-PLR AVP (AVP Code TBD) is of type Float32 and contains the
   path packet loss ratio.  The PLRs are reported in units of 10^-11.  A
   system with resolution less than one microsecond MUST set unused
   digits to zero.  The total PLR added across all QoS aware nodes can
   range as high as 10^-1.





Korhonen & Tschofenig   Expires November 27, 2008               [Page 8]


Internet-Draft               QoS Parameters                     May 2008


3.6.  Path-PER AVP

   The Path-PER AVP (AVP Code TBD) is of type Float32 and contains the
   path packet error ratio.  The PERs are reported in units of 10^-11.
   A system with resolution less than one microsecond MUST set unused
   digits to zero.  The total PER added across all QoS aware nodes can
   range as high as 10^-1.

3.7.  Slack-Term AVP

   The Slack-Term AVP (AVP Code TBD) is of type Integer32 and its
   semantic can be found in [RFC2212] and [RFC2215].  The Slack-Term AVP
   contains values measured in microseconds and its value can range from
   0 to (2**32)-1 microseconds.

3.8.  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.8.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.8.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.9.  Admission-Priority AVP

   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



Korhonen & Tschofenig   Expires November 27, 2008               [Page 9]


Internet-Draft               QoS Parameters                     May 2008


   element using the same value as when encoded in the Admission-
   Priority AVP 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 AVP, 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.

3.10.  ALRP AVP

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


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

3.10.1.  ALRP-Namespace AVP

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

3.10.2.  ALRP-Priority AVP

   The Path-Jitter-STAT4 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.11.  Excess-Treatment AVP

   The Excess-Treatment AVP is a grouped AVP consisting of two AVPs, the
   Treatment and the Remark-Value AVP.

   The coding for the Excess-Treatment AVP is as follows:


                       Excess-Treatment  ::= < AVP Header: TBD >
                                             { Excess-Treatment-Value }
                                             [ Remark-Value ]





Korhonen & Tschofenig   Expires November 27, 2008              [Page 10]


Internet-Draft               QoS Parameters                     May 2008


3.11.1.  Excess-Treatment-Value AVP

   The Excess-Treatment-Value AVP (AVP Code TBD) is of type Enumerated
   and indicates how a QoS aware node should process out-of-profile
   traffic.  The following values are currently defined:


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

   The default 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 it finds suitable.

   When the treatment is set to 'drop', all marked traffic MUST be
   dropped by a QoS aware node.

   When the treatment is set to 'shape', it is expected that QoS
   parameters conveyed as part of QoS-Desired are used to reshape the
   traffic (for example a TMOD parameter indicated as QoS desired).
   When the shaping causes unbounded queue growth at the shaper traffic
   can be dropped.

   When the treatment is set to 'remark', the excess treatment parameter
   MUST carry the remark value.  For example, packets may be remarked to
   drop remarked to pertain to a particular QoS class.  In the latter
   case, remarking relates to a DiffServ-type model, where packets
   arrive marked as belonging to a certain QoS class, and when they are
   identified as excess, they should then be remarked to a different QoS
   Class.  The Remark-Value AVP carries the information used for re-
   marking.

   If 'no metering or policing is permitted' is indicated, the QoS aware
   node should accept the treatment set by the sender with special care
   so that excess traffic should not cause a problem.  To request the
   Null Meter [RFC3290] is especially strong, and should be used with
   caution.

3.11.2.  Remark-Value AVP

   The Remark-Value AVP (AVP Code TBD) is of type Unsigned32 and
   contains the DSCP value the excess traffic should be remarked to.







Korhonen & Tschofenig   Expires November 27, 2008              [Page 11]


Internet-Draft               QoS Parameters                     May 2008


3.11.3.  PHB-Class AVP

   The PHB-Class AVP (AVP Code TBD) is of type OctetString and is two
   octets long.  A description of the semantic of the parameter values
   can be found in [RFC3140].  The coding for the values 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | DSCP      |0 0 0 0 0 0 0 0 0 0|            (Reserved)         |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   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.

   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
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | DSCP      |0 0 0 0 0 0 0 0 X 0|
      +---+---+---+---+---+---+---+---+

   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.


       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      PHD ID CODE      |0 0 X 0|
      +---+---+---+---+---+---+---+---+

   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



Korhonen & Tschofenig   Expires November 27, 2008              [Page 12]


Internet-Draft               QoS Parameters                     May 2008


   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.

   The registries needed to use [RFC3140] already exist.  Hence, no new
   registry needs to be created for this purpose.

3.11.4.  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 0, 1, 2, 3, 4,
   5, 6, 7.

3.11.5.  Y.1541-QoS-Class AVP

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

   Currently, the allowed values of the Y.1541 QoS class are 0, 1, 2, 3,
   4, 5, 6, 7.

   Class 0:

      Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <=
      10^-3.  Real-time, highly interactive applications, sensitive to
      jitter.  Application examples include VoIP, Video Teleconference.

   Class 1:

      Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <=
      10^-3.  Real-time, interactive applications, sensitive to jitter.
      Application examples include VoIP, Video Teleconference.

   Class 2:

      Mean delay <= 100 ms, delay variation unspecified, loss ratio <=
      10^-3.  Highly interactive transaction data.  Application examples
      include signaling.







Korhonen & Tschofenig   Expires November 27, 2008              [Page 13]


Internet-Draft               QoS Parameters                     May 2008


   Class 3:

      Mean delay <= 400 ms, delay variation unspecified, loss ratio <=
      10^-3.  Interactive transaction data.  Application examples
      include signaling.

   Class 4:

      Mean delay <= 1 sec, delay variation unspecified, loss ratio <=
      10^-3.  Low Loss Only applications.  Application examples include
      short transactions, bulk data, video streaming.

   Class 5:

      Mean delay unspecified, delay variation unspecified, loss ratio
      unspecified.  Unspecified applications.  Application examples
      include traditional applications of default IP networks.

   Class 6:

      Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <=
      10^-5.  Applications that are highly sensitive to loss, such as
      television transport, high-capacity TCP transfers, and TDM circuit
      emulation.

   Class 7:

      Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <=
      10^-5.  Applications that are highly sensitive to loss, such as
      television transport, high-capacity TCP transfers, and TDM circuit
      emulation.


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



Korhonen & Tschofenig   Expires November 27, 2008              [Page 14]


Internet-Draft               QoS Parameters                     May 2008


   specifier field.  A QoS profile groups together a bunch of QoS
   parameters for usage in a specific environment.  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).
   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.


5.  IANA Considerations

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

   IANA is requested to create the following registries listed in the
   subsections below.

5.1.  QoS Profile

   The QoS Profile refers to a 64 bit long field that is represented by
   a 4-octet vendor and 4-octet specifier field.  The vendor field
   indicates the type as either standards-specified or vendor-specific.
   If the four octets of the vendor field are 0x00000000, then the value
   is standards-specified and 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 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



Korhonen & Tschofenig   Expires November 27, 2008              [Page 15]


Internet-Draft               QoS Parameters                     May 2008


   values in the range of 512-4095.

5.2.  AVP Allocations

   This specification assigns the values TBD1 to TBD2 from the AVP Code
   namespace defined in [RFC3588].  See Section 3 for the assignment of
   the namespace in this specification.

5.3.  Excess-Treatment AVP

   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 Value 3: no metering or policing is permitted
      Excess Treatment Values 4-63: Standards Action
      Excess Treatment Value 64-2^32-1: Reserved

5.4.  DSTE-Class-Type AVP

   The following values are allocated by this specification:
      DSTE Class Type Value 0: DSTE Class Type 0
      DSTE Class Type Value 1: DSTE Class Type 1
      DSTE Class Type Value 2: DSTE Class Type 2
      DSTE Class Type Value 3: DSTE Class Type 3
      DSTE Class Type Value 4: DSTE Class Type 4
      DSTE Class Type Value 5: DSTE Class Type 5
      DSTE Class Type Value 6: DSTE Class Type 6
      DSTE Class Type Value 7: DSTE Class Type 7
      DSTE Class Type Values 8-63: Standards Action
      DSTE Class Type Values 64-2^32-1: Reserved

5.5.  Y.1541-QoS-Class AVP

   The following values are allocated by this specification:
      Y.1541 QoS Class Value 0: Y.1541 QoS Class 0
      Y.1541 QoS Class Value 1: Y.1541 QoS Class 1
      Y.1541 QoS Class Value 2: Y.1541 QoS Class 2
      Y.1541 QoS Class Value 3: Y.1541 QoS Class 3
      Y.1541 QoS Class Value 4: Y.1541 QoS Class 4
      Y.1541 QoS Class Value 5: Y.1541 QoS Class 5
      Y.1541 QoS Class Value 6: Y.1541 QoS Class 6
      Y.1541 QoS Class Value 7: Y.1541 QoS Class 7
      Y.1541 QoS Class Values 8-63: Standards Action
      Y.1541 QoS Class Values 64-2^32-1: Reserved

   The values in the ALRP-Namespace and ALRP-Priority AV{ inside the
   ALRP AVP take their values from the registry created by [RFC4412] and



Korhonen & Tschofenig   Expires November 27, 2008              [Page 16]


Internet-Draft               QoS Parameters                     May 2008


   extended with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions
   are required by IANA by this specification.


6.  Security Considerations

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


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.

   We would like to thank Francois Le Faucheur, John Loughney, Martin
   Stiemerling, Dave Oran, An Nguyen, Ken Carlberg, James Polk, Lars
   Eggert, and Magnus Westerlund for their help with resolving problems
   regarding the Admission Priority and the ALRP parameter.


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-08 (work in
              progress), May 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.




Korhonen & Tschofenig   Expires November 27, 2008              [Page 17]


Internet-Draft               QoS Parameters                     May 2008


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

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

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [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]   "Network Performance Objectives for IP-Based Services",  ,
              2006.

   [Y.1571]   "Admission Control Priority Levels in Next Generation
              Networks",  , July 2006.

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 (work in
              progress), April 2008.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

   [RFC3290]  Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An



Korhonen & Tschofenig   Expires November 27, 2008              [Page 18]


Internet-Draft               QoS Parameters                     May 2008


              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]   "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
   Finland

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















Korhonen & Tschofenig   Expires November 27, 2008              [Page 19]


Internet-Draft               QoS Parameters                     May 2008


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.











Korhonen & Tschofenig   Expires November 27, 2008              [Page 20]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/