RFC 6735

Diameter Priority Attribute-Value Pairs

📅 published October 2012, from ietf

Diameter Priority Attribute-Value Pairs (RFC 6735) 💖

Okay bestie, first the tea ☕ This is RFC 6735, titled Diameter Priority Attribute-Value Pairs. It's an Internet Standards Track doc from October 2012, with ISSN 2070-1721. The authors are K. Carlberg, Ed. (G11) and T. Taylor (PT Taylor Consulting) 🎀 The title block doesn't list anything it obsoletes or updates, so it's a fresh start ✨

Abstract 🌸

This doc defines Attribute-Value Pair (AVP) containers for a bunch of priority parameters, for use with Diameter and the Authentication, Authorization, and Accounting (AAA) framework. The actual parameters are defined in several other protocols, and those protocols work at either the network or the application layer 🦋

Status of This Memo 📜

This is an Internet Standards Track document, so it's official-official 💅

It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 🧚

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6735 🔗

Copyright (c) 2012 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 read these carefully, because 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 they are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 🫶

1. Introduction ✨

This doc defines a bunch of Attribute-Value Pairs (AVPs) that can be used inside the Diameter protocol [RFC6733] to carry a specific set of priority parameters 💜 Those parameters are specified in other documents, but I'll give you the quick version below. The matching AVPs in Section 3 are extensions of the ones defined in [RFC5866]. Also, all the priority fields tied to the AVPs in this doc are extensible, so they can take extra values beyond what's already been defined or registered with IANA. Future-proof, no cap 🔥

So, priority basically decides how resources get shared, and that affects the QoS for that resource. The influence can be probabilistic, somewhere between (but not including) 0% and 100%. Or it can be a guarantee that you either get the resource or don't 🍓

Another way prioritization can work is laid out in Appendix A.3 (the Priority Bypass Model) of [RFC6401]. Here, prioritized flows can get access to resources that are never shared with non-prioritized flows. Main character energy 👑

The 3rd Generation Partnership Project (3GPP) has defined several Diameter AVPs that support prioritization of sessions. The following AVPs are meant for priority services, like Multimedia Priority Service 🎀

   -  Reservation-Priority AVP as defined in [ETSI]
   -  MPS-Identifier AVP as defined in [3GPPa]
   -  Priority-Level AVP (as part of the Allocation Retention
      Priority AVP) as defined in [3GPPb]
   -  Session-Priority AVP as defined in [3GPPc] and [3GPPd]

Okay so both the Reservation-Priority AVP and the Priority-Level AVP can carry priority levels for a session that a user starts 🌸 These AVPs come from the block set aside for 3GPP on Diameter-based interfaces, and they're really aimed at IP Multimedia Subsystem (IMS) deployments 🦋 The 3GPP AVPs above are meant to be seen as private implementations living inside a walled garden 🌷 The priority AVPs defined below in Section 3 are not limited to IMS environments, though. Whether the 3GPP ones and the Section 3 ones can coexist, and in what use cases, is for further study 🔍

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 RFC 2119 [RFC2119]. These are the official requirement words, so they're doing the heavy lifting 💀

3. Priority Parameter Encoding 🧁

This section defines a set of AVPs that line up with priority fields defined in other protocols. This group of priority-related AVPs is for use with the Diameter QoS application [RFC5866], and it continues the list of AVPs defined in [RFC5624]. The syntax notation is the one from [RFC6733]. Each subsection below describes the prioritization field of a given protocol, plus the structure of the AVP that matches that field 💖

Now listen, this is important ⚠️ Neither the priority-related AVPs nor the Diameter protocol actually perform or deliver the QoS for a session or flow of packets. Instead, these AVPs are part of a mechanism for checking the validity of the priority value 🫶

3.1. Dual-Priority AVP 🔥

The Dual-Priority AVP (AVP Code 608) is a grouped AVP made of two AVPs, the Preemption-Priority and the Defending-Priority AVP. They come from the matching priority fields in the "Signaled Preemption Priority Policy Element" [RFC3181] of RSVP [RFC2205] 🌈

In [RFC3181], the Defending-Priority value gets set once the reservation has been admitted by the RSVP protocol. When a newly requested reservation comes in, its Preemption-Priority field (described in [RFC3181]) gets compared with the Defending-Priority value of a flow that was already admitted. What happens after that comparison depends on local policy 👑

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

3.1.1. Preemption-Priority AVP 🦋

The Preemption-Priority AVP (AVP Code 609) is of type Unsigned16. Higher values mean higher priority. The value 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 610) is of type Unsigned16. Higher values mean higher priority. The value 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 611) is of type Unsigned8. The admission priority tied to an RSVP flow is used to increase the probability of session establishment for selected RSVP flows. Higher values mean higher priority. A given admission priority is encoded here using the same value it would have in the admission-priority parameter defined in Section 5.1 of [RFC6401] 🍓

3.3. SIP-Resource-Priority AVP 📞

The SIP-Resource-Priority AVP (AVP Code 612) is a grouped AVP made of two AVPs, the SIP-Resource-Priority-Namespace and the SIP-Resource-Priority-Value AVP. They're derived from the corresponding optional header fields in [RFC4412] 🎀

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

3.3.1. SIP-Resource-Priority-Namespace AVP 🏷️

The SIP-Resource-Priority-Namespace AVP (AVP Code 613) is of type UTF8String. This AVP holds a string that identifies a unique ordered set of priority values, as described in [RFC4412] 🌸

3.3.2. SIP-Resource-Priority-Value AVP 🫧

The SIP-Resource-Priority-Value AVP (AVP Code 614) is of type UTF8String. This AVP holds a string (basically a namespace entry) that identifies one member of a set of priority values unique to the namespace. You can find examples of namespaces and their sets of priority values in [RFC4412] 🧚

3.4. Application-Level-Resource-Priority AVP 🌟

The Application-Level-Resource-Priority (ALRP) AVP (AVP Code 615) is a grouped AVP made of two AVPs, the ALRP-Namespace AVP and the ALRP-Value AVP 💅

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

You can find a description of what the parameter values mean in [RFC4412] and in [RFC6401]. The registry set up by [RFC4412] gives string values for both the priority namespace and the priority values inside that namespace. [RFC6401] modifies that registry so that it assigns numerical values to both the namespace identifiers and the priority values within them. So the SIP-Resource-Priority and Application-Level-Resource-Priority AVPs carry the same priority semantics, just with different syntax 🤓 In the first case you get an alpha-numeric encoding, and in the second case it's limited to numeric-only values 🔢

3.4.1. ALRP-Namespace AVP 🌈

The ALRP-Namespace AVP (AVP Code 616) is of type Unsigned16. This AVP holds a numerical value that identifies the namespace of the application-level resource priority, as described in [RFC6401] 💜

3.4.2. ALRP-Value AVP 💖

The ALRP-Value AVP (AVP Code 617) is of type Unsigned8. This AVP holds the priority value within the ALRP-Namespace, as described in [RFC6401] ✨

4. Examples of Usage 🎀

okay bestie, the Dual-Priority, Admission-Priority, and Application-Level-Resource-Priority AVPs can all be shown off with the same simple network scenario 💅. they wouldn't all typically live in the same network though 🙈

so here's the vibe: a user with special authorization logs in through a Network Access Server (NAS), and the NAS acts as a client to a Diameter Server that supports the app the user wants. once the user is authenticated, the Diameter Server gives the NAS info about the user's authorized QoS, including instances of the Dual-Priority, Admission-Priority, and/or Application-Level-Resource-Priority AVPs ✨

local policy decides how the values in these AVPs get used at the NAS, which is how it figures out whether the flow for the user's app can be admitted 🫶 if the answer is yes, the NAS forwards the authorized QoS values as objects in RSVP signaling. the values in the Dual-Priority AVP get carried in the "Signaled Preemption Priority Policy Element" defined in [RFC3181], and the values in the Admission-Priority and Application-Level-Resource-Priority AVPs get carried in the matching policy objects defined in [RFC6401]. every node after that makes its own call, looking at the authorized QoS objects (priority stuff included) and, again, following local policy 🔥. the example assumes the user session ends on a host or server in the same administrative domain as the NAS, so we dodge the complications from the limited applicability of [RFC3181] and [RFC6401] 💖

local policy might for example decide:

  • which value to take if both Admission-Priority and Application-Level-Resource-Priority are present;
  • which namespace or namespaces are recognized for use in Application-Level-Resource-Priority;
  • which resources are subject to preemption if the values in Dual-Priority are high enough to allow it.

now the SIP-Resource-Priority AVP scenario is a little different 🦋 the first decision point is usually a SIP proxy that gets a session initiation request containing a Resource-Priority header field, and it decides whether to admit the session to the domain. just like the NAS, the SIP proxy acts as a client to a Diameter Server during user authentication, and once authentication succeeds it gets AVPs back from the Diameter Server that indicate authorized QoS 🌸 one of those might be the SIP-Resource-Priority AVP, and its contents get compared with the contents of the Resource-Priority header field. once again, local policy decides which namespaces to accept and what effect a given priority level has on the admission decision 👑

so let's say the SIP proxy now signals using RSVP to the border router that's going to admit the media flows for the session. (this totally makes a few assumptions about routing, and about the proxy knowing that routing 🙈) the SIP proxy can indicate authorized QoS using various objects. specifically, it can map the values from the Resource-Priority header field to the matching numeric values defined by [RFC6401] and send them using the Application-Level Resource Priority Policy Element 🧚

5. IANA Considerations 🌈

5.1. AVP Codes

okay so IANA has allocated AVP codes for the following AVPs defined in this document 💜

 +------------------------------------------------------------------+
 |                                       AVP  Section               |
 |AVP Name                               Code Defined   Data Type   |
 +------------------------------------------------------------------+
 |Dual-Priority                          608  3.1       Grouped     |
 |Preemption-Priority                    609  3.1.1     Unsigned16  |
 |Defending-Priority                     610  3.1.2     Unsigned16  |
 |Admission-Priority                     611  3.2       Unsigned8   |
 |SIP-Resource-Priority                  612  3.3       Grouped     |
 |SIP-Resource-Priority-Namespace        613  3.3.1     UTF8String  |
 |SIP-Resource-Priority-Value            614  3.3.2     UTF8String  |
 |Application-Level-Resource-Priority    615  3.4       Grouped     |
 |ALRP-Namespace                         616  3.4.1     Unsigned32  |
 |ALRP-Value                             617  3.4.2     Unsigned32  |
 +------------------------------------------------------------------+

5.2. QoS Profile

IANA also allocated a brand new value from the "QoS Profiles" subregistry of the "Authentication, Authorization, and Accounting (AAA) Parameters" registry, which is defined in [RFC5624], for the QoS profile in this document 🎀 the profile's name is "Resource priority parameters" (1).

6. Security Considerations 🔐

okay this section is serious, so read it with your whole chest 😭 this document describes an extension for conveying quality-of-service information, so it follows the same security considerations as the Diameter QoS Application in [RFC5866]. the values placed in the AVPs aren't changed by this document, and they aren't changed in the Diameter QoS application either 💀 we recommend using mechanisms that ensure integrity when exchanging information from one protocol to an associated DIAMETER AVP. examples of those integrity mechanisms are using S/MIME with the SIP Resource Priority Header (RPH), or an INTEGRITY object inside a POLICY_DATA object in the context of RSVP. changing the values in the Priority AVPs can end up allocating more or fewer resources, and that's the whole danger zone ⚠️

changes in integrity-protected values SHOULD NOT be ignored, and appropriate protocol-specific error messages SHOULD be sent back upstream.

note that we don't use the term "MUST NOT be ignored" here, because the local policy of an administrative domain associated with other protocols is the final arbiter 👑 also, some protocols associated with the AVPs in this document may be deployed inside a single administrative domain, or a "walled garden" 🌸 so any changes in values would reflect that domain's policies.

the security considerations of the Diameter protocol itself are discussed in [RFC6733]. using the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter base protocol, so no skipping that 🫶

the authors also recommend that readers get familiar with the security considerations of the various protocols listed in the Normative References, because the values placed in the AVPs defined here are set or changed by other protocols 🧚

7. Acknowledgements 💖

we would like to thank Lionel Morand, Janet Gunn, Piers O'Hanlon, Lars Eggert, Jan Engelhardt, Francois LeFaucheur, John Loughney, An Nguyen, Dave Oran, James Polk, Martin Stiemerling, Magnus Westerlund, David Harrington, Robert Sparks, and Dan Romascanu for their review and/or comments on previous draft versions of this document 🥹✨

8. References 📚

8.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
  • [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
  • [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
  • [RFC5624] Korhonen, J., Ed., Tschofenig, H., and E. Davies, "Quality of Service Parameters for Usage with Diameter", RFC 5624, August 2009.
  • [RFC5866] Sun, D., Ed., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, Ed., "Diameter Quality-of-Service Application", RFC 5866, May 2010.
  • [RFC6401] Le Faucheur, F., Polk, J., and K. Carlberg, "RSVP Extensions for Admission Priority", RFC 6401, October 2011.
  • [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, October 2012.

8.2. Informative References

  • [3GPPa] "TS 29.214: Policy and charging control over Rx reference point", 3GPP, March, 2011
  • [3GPPb] "TS 29.212: Policy and charging control over Gx reference point", 3GPP, October, 2010
  • [3GPPc] "TS 29.229: Cx and Dx interfaces based on the Diameter protocol; Protocol details", 3GPP, September, 2010
  • [3GPPd] "TS 29.329: Sh interface based on the Diameter protocol; Protocol details", 3GPP, September, 2010
  • [ETSI] "TS 183 017: Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control", ETSI

Authors' Addresses 🦋

Ken Carlberg (editor) G11 1601 Clarendon Dr Arlington, VA 22209 United States

EMail: carlberg@g11.org.uk

Tom Taylor PT Taylor Consulting 1852 Lorraine Ave Ottawa Canada

EMail: tom.taylor.stds@gmail.com

📦 where this page comes from