doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

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]
+