The document shepherd is Lionel Morand. The responsible Area Director is Stephen Farrell.
This document defines a mechanism that allows Diameter nodes to indicate the relative priority of Diameter transactions. With this information other Diameter nodes can factor the relative priority of requests into routing and throttling decisions. This mechanism is a solution to address throttling requirement introduced in Diameter overload control solution [RFC7068][RFC7683].
Intended status: Standards Track
2. Review and Consensus
The document starts by introducing the problematic to solve and describes various scenarios where the use of Diameter message priority can be useful before describing the Diameter priority mechanism.
The mechanism defined in this document is fairly simple. It consists in defining a new AVP, DRMP AVP, that can be included in Diameter requests and answers to indicate the priority of the command. 16 values are defined (from 0 to 15), Priority 0 being the highest priority. This priority value is used by Diameter nodes to determine the relative priority of the message. How to set the priority in the messages and how to use the priority information when making routing decisions or throttling is outside the scope of this document. It can be defined per application or can be implementation dependent.
The proposed solution has not been implemented yet, as vendors are waiting for IANA AVP code value assignment before implementing. However, no issues are expected with implementation. Moreover, the solution defined in this document have been already introduced in standard specifications defined by 3GPP. It is therefore understood that the vendors implementing 3GPP specifications will implement this mechanism.
The document received a large support for adoption when initiated and it has been reviewed multiple times, with detailed comments and corrections. The version -03 addresses the last comments received after the WGLC process. There is a strong WG consensus on the content of this document, with a broad range of people, including key experts.
3. Security Considerations
The Security considerations section highlights the lack of e2e protection in Diameter. It is therefore assumed that the mechanism is used in a trusted environment.
4. IANA considerations
The IANA considerations section is consistent with the body of the document. All protocol extensions are associated
with appropriate reservations for IANA.
5. Intellectual Property
The author and contributor have confirmed conformance with IETF IPR rules (RFCs 3979, 4879, 3669, and 5378). There are no IPR disclosures on the document.
6. ID Nits
There are two IDnits that can be handled with a rev of the document when publishing the document;
== Unused Reference: 'RFC5226' is defined on line 680, but no explicit
reference was found in the text
== Unused Reference: 'RFC4412' is defined on line 692, but no explicit
reference was found in the text
7. Other points
The RFC 6735 defines the Diameter Priority AVPs that convey over Diameter a specific set of priority parameters that can be part of the user profile information retrieved by a AAA client from the AAA server.
These priority parameters are used to act on the user session managed by the Diameter client (e.g. access sessions or SIP sessions). There are not used to indicate relative priority of messages in the Diameter-based signaling networks. The RFC 6735 is therefore not linked to this new document.