Diameter Maintenance and                                K. Carlberg, Ed.
Extensions (DIME)                                                    G11
Internet-Draft                                                 T. Taylor
Intended status: Standards Track                     Huawei Technologies
                                                           June 11,
                                                           July 8, 2010

                Diameter Priority Attribute Value Pairs
                  draft-ietf-dime-priority-avps-01.txt
                  draft-ietf-dime-priority-avps-02.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents  of  the  Internet  Engineering
   Task  Force  (IETF).   Note  that  other  groups  may also distribute
   working documents as Internet-Drafts.  The list of current  Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

Copyright Notice

   Copyright (c) 2010 IETF Trust  and  the  persons  identified  as  the
   document authors.  All rights reserved.

   This document is subject  to  BCP  78  and  the  IETF  Trust's  Legal
   Provisions  Relating  to  IETF  Documents  in  effect  on the date of
   publication of this document  (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect  to  this  document.   Code  Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust  Legal  Provisions  and  are
   provided without warranty as described in the Simplified BSD License.

   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.  Code Components extracted from this document must
   include Simplified BSD License text as described in  Section  4.e  of
   the  Trust  Legal  Provisions  and  are  provided without warranty as
   described in the Simplified BSD License.

Abstract

   This document  defines  Attribute-Value  Pair  (AVP)  containers  for
   various  priority  parameters  for  use  with  Diameter  and  the AAA
   framework.   The  parameters  themselves  are  defined   in   several
   different protocols that operate at either the network or application
   layer.

1.  Introduction

   This document defines a number of Attribute-Value  Pairs  (AVPs)  (AVP)  that
   can  be  used  within  the  Diameter  protocol  [RFC3588] to convey a
   specific set of priority parameters.  The  These parameters  themselves are  specified
   in   other   documents,   but   are described  briefly  described  below.   The
   corresponding AVPs defined in Section 3 are an extension to to  those
   defined in [RFC5866].

   Priority influences the distribution of  resources.   This  influence
   may  be  probabilistic,  ranging  between  (but not including) 0% and
   100%, or it may be in the form of a guarantee to  either  receive  or
   not receive the resource.

   The influence attributed to prioritization may also affect  QoS,  but
   it  is not to be confused with QoS.  As an example, if packets of two
   or  more  flows  are  contending  for  the  same  shared   resources,
   prioritization  helps  determine  which packet receives the resource.
   However, this allocation of resource does not correlate  directly  to
   any  specific delay or loss bounds that have been associated with the
   packet.

   Another example of how prioritization can be realized is  articulated
   in  Appendix  A.3  (the  priority  by-pass model) of [I-D.ietf-tsvwg-
   emergency-rsvp].  In this case, prioritized flows may gain access  to
   resources that are never shared with non-prioritized flows.

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.  Priority Parameter Encoding

   This section defines a set of priority AVPs.  This  set  is  for  use
   with   the  DIAMETER  QoS  application  [RFC5866]  and  represents  a
   continuation of the list of AVPs defined in  [RFC5624].   The  syntax
   notation used is that of [RFC3588].

   3.1.  Dual-Priority AVP

   The Dual-Priority AVP is a grouped AVP consisting of  two  AVPs;  the
   Preemption-Priority  and  the Defending-Priority AVP.  These AVPs are
   derived from the  corresponding  priority  fields  specified  in  the
   Signaled   Preemption  Priority  Policy  Element  [RFC3181]  of  RSVP
   [RFC2205].  The Defending-Priority is set when  the  reservation  has
   been   admitted.    The  Preemption-Priority  of  a  newly  requested
   reservation is compared with the Defending Priority of  a  previously
   admitted  flow.   The  actions  taken  based  upon the result of this
   comparison are a function of local policy.

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

3.1.1.  Preemption-Priority AVP

   The Preemption-Priority AVP (AVP Code TBD)  is  of  type  Unsigned32.
   Higher  values  represent higher priority.  The value encoded in this
   AVP is the same as  the  preemption  priority  value  that  would  be
   encoded in the signaled preemption priority policy element.

3.1.2.  Defending-Priority AVP

   The Defending-Priority AVP (AVP Code  TBD)  is  of  type  Unsigned32.
   Higher  values  represent higher priority.  The value encoded in this
   AVP is the same as the defending priority value that would be encoded
   in the signaled preemption priority policy element.

3.2.  Admission-Priority AVP

   The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32.  The
   admission priority of the flow is used to increase the probability of
   session establishment for 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 5.1 of [I-D.ietf-
   tsvwg-emergency-rsvp].

3.3. SIP-RPH SIP-Resource-Priority AVP

   The SIP-RPH SIP-Resource-Priority AVP is a  grouped  AVP  consisting  of  two
   AVPs,   the  SIP-
   RPH-Namespace  SIP-Resource-Priority-Namespace  and  the SIP-RPH-Value  SIP-Resource-
   Priority-Value AVP, which are derived from the corresponding optional
   header  fields  in  [rfc4412].   The  SIP-RPH-
   Namespace  SIP-Resource-Priority-Namespace
   identifies a particular ordered set of  priority  values.   The SIP-RPH-Value  SIP-
   Resource-Priority-Value  identifies  a specific priority value within
   the set identified by the SIP-RPH-Namespace.

     SIP-RPH SIP-Resource-Priority-Namespace.

     SIP-Resource-Priority ::= < AVP Header: TBD >
                     { SIP-RPH-Namespace SIP-Resource-Priority-Namespace }
                     { SIP-RPH-Value SIP-Resource-Priority-Value }

3.3.1.  SIP-Namespace AVP

   The SIP-RPH-Namespace SIP-Resource-Priority-Namespace AVP (AVP Code  TBD)  is  of  type
   UTF8String.

3.3.2 SIP-RPH-Value SIP-Resource-Priority-Value AVP

   The SIP-RPH-Value  SIP-Resource-Priority-Value  AVP  (AVP  Code  TBD)  is  of  type
   UTF8String.

3.4.  App-Level-Resource-Priority  Application-Level-Resource-Priority AVP

   The  App-Level-Resource-Priority Application-Level-Resource-Priority (ALRP) AVP is a  grouped  AVP
   consisting  of  two  AVPs,  the ALRP-Namespace AVP and the ALRP-Priority ALRP-Value
   AVP.

   A description of the semantics of the parameter values can  be  found
   in  [RFC4412]  and  in [I-D.ietf-tsvwg-emergency-rsvp].  The registry
   set up by [RFC4412] provided string  values  for  both  the  priority
   namespace  and  the  priority  values associated with that namespace.
   [I-D.ietf-tsvwg-emergency-rsvp]  modifies  that  registry  to  assign
   numerical  values  to both the namespace identifiers and the priority
   values   within   them.   Consequently,  SIP-RPH   SIP-Resource-Priority   and  App-Level-Resource-
   Priority
   Application-Level-Resource-Priority  AVPs  convey  the  same priority
   semantics, but with differing syntax. The coding for parameters is as
   follows:

   Eventhough [RFC4412] and [I-D.ietf-tsvwg-emergency-rsvp] refer to the
   same  information  (ie, namespace and value), the actual encodings of
   each are defined in different forms.  In the former case,  an  alpha-
   numeric  encoding  is  used  while  the  latter  is  constrained to a
   numeric-only value.  This difference  is  reflected  in  the  in  the
   defined structures of Section 3.3 and 3.4 of this document.

     App-Level-Resource-Priority

     Application-Level-Resource-Priority  ::= < AVP Header: TBD >
                                     { ALRP-Namespace }
                                     { ALRP-Priority ALRP-Value }

3.4.1.  ALRP-Namespace AVP

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

3.4.2.  ALRP-Priority  ALRP-Value AVP

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

4.  IANA Considerations

4.1.  AVP Codes

   IANA is requested to allocate AVP codes for the following  AVPs  that
   are defined in this document.

    +------------------------------------------------------------------+
    |                                       AVP  Section               |
    |AVP Name                               Code Defined   Data Type   |
    +------------------------------------------------------------------+
    |Dual-Priority                          TBD  3.1       Grouped     |
    |Preemption-Priority                    TBD  3.1.1     Unsigned32  |
    |Defending-Priority                     TBD  3.1.2     Unsigned32  |
    |Admission-Priority                     TBD  3.2       Unsigned32  |
    |SIP-RPH
    |SIP-Resource-Priority                  TBD  3.3       Grouped     |
    |SIP-Namespace                          TBD  3.3.1     UTF8String  |
    |SIP-Value                              TBD  3.3.2     UTF8String  |
    |App-Level-Resource-Priority
    |Application-Level-Resource-Priority    TBD  3.4       Grouped     |
    |ALRP-Namespace                         TBD  3.4.1     Unsigned32  |
    |ALRP-Priority
    |ALRP-Value                             TBD  3.4.2     Unsigned32  |
    +------------------------------------------------------------------+

4.2.  QoS Profile

   IANA is requested to allocate a new value  from  the  Authentication,
   Authorization,  and  Accounting (AAA) Parameters/QoS Profile registry
   defined in [RFC5624] for the QoS profile defined  in  this  document.
   The  name  of  the  profile  is  "Resource  priority parameters". The
   reference is [RFCXXXX] (this document).

5.  Security Considerations

     TBD

   This document describes  the  extension  of  Diameter  for  conveying
   Quality  of  Service information.  The security considerations of the
   Diameter protocol itself have been discussed in RFC  3588  [RFC3588].
   Use of the AVPs defined in this document MUST take into consideration
   the security issues and requirements of the Diameter base protocol.

6.  Acknowledgements

   We would like to thank Lionel Morand, Janet Gunn, Piers O'Hanlon  for
   the  commenst on the draft, and Lars Eggert, Jan Engelhardt, Francois
   LeFaucheur, John Loughney, An Nguyen, Dave Oran, James  Polk,  Martin
   Stiemerling,  and  Magnus  Westerlund  for  their help with resolving
   problems regarding the Admission Priority and the ALRP parameter.
   Additionally, we would like to thank Martin Dolly  and  Viqar  Shaikh
   for  their  feedback  on  previous discussion related to the topic of
   prioritization.

7.  References

7.1.  Normative References

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

   [RFC5624] Korhonen, J., Tschofenig, H., and E. Davies, "Quality of
            Service Parameters for Usage with Diameter", RFC 5624,
            Aug 2009.

   [RFC5866] Sun, D., et. al., "Diameter Quality-of-Service
             Application", RFC 5866, May 2010.

7.2.  Informative References

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

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

Authors' Addresses

   Ken Carlberg (editor)          Tom Taylor
   G11                            Huawei Technologies
   1601 Clarendon Dr              1852 Lorraine Ave
   Arlington, VA 22209            Ottawa
   United States                  Canada

   Email: carlberg@g11.org.uk     Email: tom111.taylor@bell.net