From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6735.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc6735.txt (limited to 'doc/rfc/rfc6735.txt') diff --git a/doc/rfc/rfc6735.txt b/doc/rfc/rfc6735.txt new file mode 100644 index 0000000..99c7818 --- /dev/null +++ b/doc/rfc/rfc6735.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) K. Carlberg, Ed. +Request for Comments: 6735 G11 +Category: Standards Track T. Taylor +ISSN: 2070-1721 PT Taylor Consulting + October 2012 + + + Diameter Priority Attribute-Value Pairs + +Abstract + + This document defines Attribute-Value Pair (AVP) containers for + various priority parameters for use with Diameter and the + Authentication, Authorization, and Accounting (AAA) framework. The + parameters themselves are defined in several different protocols that + operate at either the network or application layer. + + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by + the Internet Engineering Steering Group (IESG). Further + information on Internet Standards is available in Section 2 of + RFC 5741. + + Information about the current status of this document, any + errata, and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6735. + +Copyright Notice + + 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 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. + + + + +Carlberg & Taylor Standards Track [Page 1] + +RFC 6735 Resource Priorities AVPs October 2012 + + + 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 document defines a number of Attribute-Value Pairs (AVP) that + can be used within the Diameter protocol [RFC6733] to convey a + specific set of priority parameters. These parameters are specified + in other documents, but are briefly described below. The + corresponding AVPs defined in Section 3 are extensions to those + defined in [RFC5866]. We note that all the priority fields + associated with the AVPs defined in this document are extensible and + allow for additional values beyond what may have already been defined + or registered with IANA. + + Priority influences the distribution of resources and, in turn, the + QoS associated with that resource. 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. + + Another example of how prioritization can be realized is articulated + in Appendix A.3 (the Priority Bypass Model) of [RFC6401]. In this + case, prioritized flows may gain access to resources that are never + shared with non-prioritized flows. + +1.1. Other Priority-Related AVPs + + The 3rd Generation Partnership Project (3GPP) has defined several + Diameter AVPs that support prioritization of sessions. The following + AVPs are intended to be used for priority services (e.g., 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] + + + + +Carlberg & Taylor Standards Track [Page 2] + +RFC 6735 Resource Priorities AVPs October 2012 + + + Both the Reservation-Priority AVP and the Priority-Level AVP can + carry priority levels associated with a session initiated by a user. + We note that these AVPs are defined from the allotment set aside for + 3GPP for Diameter-based interfaces, and they are particularly aimed + at IP Multimedia Subsystem (IMS) deployment environments. The above + AVPs defined by 3GPP are to be viewed as private implementations + operating within a walled garden. In contrast, the priority-related + AVPs defined below in Section 3 are not constrained to IMS + environments. The potential applicability or use-case scenarios that + involve coexistence between the above 3GPP-defined priority-related + AVPs and those defined below in Section 3 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]. + +3. Priority Parameter Encoding + + This section defines a set of AVPs that correlates to priority fields + defined in other protocols. This set of priority-related AVPs 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 [RFC6733]. We note that the following + subsections describe the prioritization field of a given protocol as + well as the structure of the AVP corresponding to that field. + + We stress that neither the priority-related AVPs, nor the Diameter + protocol, perform or realize the QoS for a session or flow of + packets. Rather, these AVPs are part of a mechanism to determine + validation of the priority value. + +3.1. Dual-Priority AVP + + The Dual-Priority AVP (AVP Code 608) 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]. + + In [RFC3181], the Defending-Priority value is set when the + reservation has been admitted by the RSVP protocol. The Preemption- + Priority field (described in [RFC3181]) of a newly requested + reservation is compared with the Defending-Priority value of a + previously admitted flow. The actions taken based upon the result of + this comparison are a function of local policy. + + + + +Carlberg & Taylor Standards Track [Page 3] + +RFC 6735 Resource Priorities AVPs October 2012 + + + 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 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 610) is of type Unsigned16. + 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 611) is of type Unsigned8. The + admission priority associated with an RSVP flow is used to increase + the probability of session establishment for selected RSVP 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 + [RFC6401]. + +3.3. SIP-Resource-Priority AVP + + The SIP-Resource-Priority AVP (AVP Code 612) is a grouped AVP + consisting of two AVPs, the SIP-Resource-Priority-Namespace and the + SIP-Resource-Priority-Value AVP, which are 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 contains a string that identifies a unique + ordered set of priority values as described in [RFC4412]. + + + + + + + +Carlberg & Taylor Standards Track [Page 4] + +RFC 6735 Resource Priorities AVPs October 2012 + + +3.3.2. SIP-Resource-Priority-Value AVP + + The SIP-Resource-Priority-Value AVP (AVP Code 614) is of type + UTF8String. This AVP contains a string (i.e., a namespace entry) + that identifies a member of a set of priority values unique to the + namespace. Examples of namespaces and corresponding sets of priority + values are found in [RFC4412]. + +3.4. Application-Level-Resource-Priority AVP + + The Application-Level-Resource-Priority (ALRP) AVP (AVP Code 615) is + a grouped AVP consisting of two AVPs, the ALRP-Namespace AVP and the + ALRP-Value AVP. + + Application-Level-Resource-Priority ::= < AVP Header: 615 > + { ALRP-Namespace } + { ALRP-Value } + + A description of the semantics of the parameter values can be found + in [RFC4412] and in [RFC6401]. The registry set up by [RFC4412] + provides string values for both the priority namespace and the + priority values associated with that namespace. [RFC6401] modifies + that registry to assign numerical values to both the namespace + identifiers and the priority values within them. Consequently, SIP- + Resource-Priority and Application-Level-Resource-Priority AVPs convey + the same priority semantics, but with differing syntax. In the + former case, an alpha-numeric encoding is used, while the latter case + is constrained to a numeric-only value. + +3.4.1. ALRP-Namespace AVP + + The ALRP-Namespace AVP (AVP Code 616) is of type Unsigned16. This + AVP contains a numerical value identifying 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 + contains the priority value within the ALRP-Namespace, as described + in [RFC6401]. + +4. Examples of Usage + + Usage of the Dual-Priority, Admission-Priority, and Application- + Level-Resource-Priority AVPs can all be illustrated by the same + simple network scenario, although they would not all typically be + used in the same network. The scenario is as follows: + + + + +Carlberg & Taylor Standards Track [Page 5] + +RFC 6735 Resource Priorities AVPs October 2012 + + + A user with special authorization is authenticated by a Network + Access Server (NAS), which acts as a client to a Diameter Server + supporting the user's desired application. Once the user has + authenticated, the Diameter Server provides the NAS with information + on the user's authorized QoS, including instances of the Dual- + Priority, Admission-Priority, and/or Application-Level-Resource- + Priority AVPs. + + Local policy governs the usage of the values conveyed by these AVPs + at the NAS to decide whether the flow associated with the user's + application can be admitted. If the decision is positive, the NAS + forwards the authorized QoS values as objects in RSVP signaling. In + particular, the values in the Dual-Priority AVP would be carried in + the "Signaled Preemption Priority Policy Element" defined in + [RFC3181], and the values contained in the Admission-Priority and + Application-Level-Resource-Priority AVPs would be carried in the + corresponding policy objects defined in [RFC6401]. Each subsequent + node would make its own decision taking account of the authorized QoS + objects including the priority-related objects, again governed by + local policy. The example assumes that the user session terminates + on a host or server in the same administrative domain as the NAS to + avoid complications due to the restricted applicability of [RFC3181] + and [RFC6401]. + + Local policy might for example indicate: + + - 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. + + A scenario for the use of the SIP-Resource-Priority AVP will differ + slightly from the previous one, in that the initial decision point + would typically be a SIP proxy receiving a session initiation request + containing a Resource-Priority header field and deciding whether to + admit the session to the domain. Like the NAS, the SIP proxy would + serve as client to a Diameter Server during the process of user + authentication, and upon successful authentication would receive back + from the Diameter Server AVPs indicating authorized QoS. Among these + might be the SIP-Resource-Priority AVP, the contents of which would + be compared with the contents of the Resource-Priority header field. + Again, local policy would determine which namespaces to accept and + the effect of a given priority level on the admission decision. + + + + +Carlberg & Taylor Standards Track [Page 6] + +RFC 6735 Resource Priorities AVPs October 2012 + + + For the sake of our example, suppose now that the SIP proxy signals + using RSVP to the border router that will be admitting the media + flows associated with the session. (This, of course, makes a few + assumptions on routing and knowledge of that routing at the proxy.) + The SIP proxy can indicate authorized QoS using various objects. In + particular, it can map the values from the Resource-Priority header + field to the corresponding numeric values as defined by [RFC6401] and + send it using the Application-Level Resource Priority Policy Element. + +5. IANA Considerations + +5.1. AVP Codes + + IANA has allocated AVP codes for the following AVPs that are 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 has allocated a new value from the "QoS Profiles" subregistry of + the "Authentication, Authorization, and Accounting (AAA) Parameters" + defined in [RFC5624] for the QoS profile defined in this document. + The name of the profile is "Resource priority parameters" (1). + +6. Security Considerations + + This document describes an extension for conveying quality-of-service + information, and therefore follows the same security considerations + of the Diameter QoS Application [RFC5866]. The values placed in the + AVPs are not changed by this document, nor are they changed in the + Diameter QoS application. We recommend the use of mechanisms to + ensure integrity when exchanging information from one protocol to an + associated DIAMETER AVP. Examples of these integrity mechanisms + + + +Carlberg & Taylor Standards Track [Page 7] + +RFC 6735 Resource Priorities AVPs October 2012 + + + would be use of S/MIME with the SIP Resource Priority Header (RPH), + or an INTEGRITY object within a POLICY_DATA object within the context + of RSVP. The consequences of changing values in the Priority AVPs + may result in an allocation of additional or less resources. + + Changes in integrity-protected values SHOULD NOT be ignored, and + appropriate protocol-specific error messages SHOULD be sent back + upstream. Note that we do not use the term "MUST NOT be ignored" + because the local policy of an administrative domain associated with + other protocols acts as the final arbiter. In addition, some + protocols associated with the AVPs defined in this document may be + deployed within a single administrative domain or "walled garden"; + thus, possible changes in values would reflect policies of that + administrative domain. + + The security considerations of the Diameter protocol itself are + discussed in [RFC6733]. Use of the AVPs defined in this document + MUST take into consideration the security issues and requirements of + the Diameter base protocol. + + The authors also recommend that readers familiarize themselves with + the security considerations of the various protocols listed in the + Normative References. This is because values placed in the AVPs + defined in this document are set/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. + + + + + +Carlberg & Taylor Standards Track [Page 8] + +RFC 6735 Resource Priorities AVPs October 2012 + + + [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 + + + + + + + + + + + + + + + +Carlberg & Taylor Standards Track [Page 9] + +RFC 6735 Resource Priorities AVPs October 2012 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Carlberg & Taylor Standards Track [Page 10] + -- cgit v1.2.3