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

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

Status of this Memo

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

   Internet-Drafts are working documents  of  the  Internet  Engineering
   Task  Force  (IETF),  its  areas,  and its working groups.  (IETF).   Note  that  other  groups  may also distribute
   working documents as Internet-Drafts.  The list of current  Internet-
   Drafts.
   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."

   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.

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)  that
   can  be  used  within  the  Diameter  protocol  [RFC3588] to convey a
   specific set of priority parameters.  The parameters  themselves  are
   specified in other documents, but are described briefly below.

   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  [draft.rsvp-
   priority-extension]. [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  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 3.1 5.1 of
   [I-D.ietf-tsvwg-emergency-rsvp]. [I-D.ietf-
   tsvwg-emergency-rsvp].

3.3. SIP-RPH AVP

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

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

3.3.1.  SIP-Namespace AVP

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

3.3.2 SIP-Value SIP-RPH-Value AVP

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

3.4.  App-Level-Resource-Priority AVP

   The  App-Level-Resource-Priority  (ALRP)  AVP  is   a   grouped   AVP
   consisting  of two AVPs, the ALRP-Namespace AVP and the ALRP-Priority
   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  and  App-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  ::= < AVP Header: TBD >
                                     { ALRP-Namespace }
                                     { ALRP-Priority }

3.3.1.

3.4.1.  ALRP-Namespace AVP

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

3.3.2.

3.4.2.  ALRP-Priority 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                                TBD  3.3       Grouped     |
    |SIP-Namespace                          TBD  3.3.1     UTF8String  |
    |SIP-Value                              TBD  3.3.2     UTF8String  |
    |App-Level-Resource-Priority            TBD  3.4       Grouped     |
    |ALRP-Namespace                         TBD  3.4.1     Unsigned32  |
    |ALRP-Priority                          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.  Examples

             +--------+              +--------+
             |Diameter|              |  SIP   |
             | server |              | server |
             +--------+              +--------+
                 |                       |
                 |                       |
                 |                       |
          1. SIP INVITE w/ RPH           |
          ------------------------------>|
                 | 2. MAR w/ SIP-RPH AVP |
                 |<----------------------|
                 | 3. MAA.               |
                 |---------------------->| 8. SIP INVITE
                 |                       |---------------->
                 |                       | 9. SIP 200 (OK)
                10. SIP 200 (OK)         |<----------------
          <------------------------------|
                 |                       |

6.  Security Considerations

     TBD

7.

6.  Acknowledgements

   We  would  like  to  thank  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.

8.

7.  References

8.1.

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.

8.2.

   [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