Internet Engineering Task Force (IETF) S. Donovan Request for Comments: 7944 Oracle Category: Standards Track August 2016 ISSN: 2070-1721 Diameter Routing Message Priority Abstract When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information, Diameter nodes can factor that priority into routing, resource allocation, and overload abatement decisions. 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 7841. 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/rfc7944. Copyright Notice Copyright (c) 2016 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. Donovan Standards Track [Page 1] RFC 7944 DOIC August 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. First-Responder-Related Signaling . . . . . . . . . . . . 6 5.2. Emergency-Call-Related Signaling . . . . . . . . . . . . 6 5.3. Differentiated Services . . . . . . . . . . . . . . . . . 7 5.4. Application-Specific Priorities . . . . . . . . . . . . . 7 6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 10 9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 12 9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 13 10. Considerations When Defining Application Priorities . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . 15 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 12.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 15 12.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . 16 12.3. End-to-End Security Issues . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . 17 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The Diameter Overload Indication Conveyance (DOIC) solution [RFC7683] for Diameter overload control introduces scenarios where Diameter routing decisions made by Diameter nodes can be influenced by the overload state of other Diameter nodes. This includes the scenarios where Diameter endpoints and Diameter Agents can throttle requests as a result of the target for the request being overloaded. With currently available mechanisms, these Diameter nodes do not have a mechanism to differentiate request message priorities when making these throttling decisions. As such, all requests are treated the same, meaning that all requests have the same probability of being throttled. Donovan Standards Track [Page 2] RFC 7944 DOIC August 2016 There are scenarios where treating all requests the same can cause issues. For instance, it might be considered important to reduce the probability of transactions involving first responders being throttled during overload scenarios caused, for example, by a period of heavy signaling resulting from a natural disaster. 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. 1.1. Applicability There are two primary considerations that must be addressed for the mechanism described in this document to work effectively. The first takes into consideration the fact that the Diameter base protocol defined in [RFC6733] is designed to transport multiple Diameter applications and that Diameter nodes can be implemented that support multiple applications. In order for the Diameter Routing Message Priority (DRMP) mechanism to work, the priorities defined for all messages across all applications used in a Diameter administrative domain must be defined in a consistent and coordinated fashion, taking the default priority into account. See Section 10 for a discussion of some of the considerations that need to be factored into the setting of DRMPs used by Diameter applications. Note that this consideration does not apply to Diameter networks where all Diameter nodes only support a single application. Without this cross application priority design taken into consideration, it is possible for messages for one application to gain unwarranted preferential treatment over messages for other applications. This mechanism also depends on all of the messages that carry the DRMP Attribute Value Pair (AVP) that are inserted into Diameter messages by trusted nodes within the Diameter administrative domain. As discussed in Section 12, misbehaving nodes have the ability to use the DRMP mechanism to gain unwarranted preferential treatment. When messages cross Diameter administrative boundaries, care should be taken to either strip or modify the DRMP values in these messages. If the priority definitions vary between the two Diameter administrative domains, then it is possible for messages from a foreign domain to gain unwarranted preferential treatment. Donovan Standards Track [Page 3] RFC 7944 DOIC August 2016 2. Terminology and Abbreviations Diversion As defined in [RFC7683]. An overload abatement treatment where the reacting node selects alternate destinations or paths for requests. DOIC Diameter Overload Indication Conveyance. DRMP Diameter Routing Message Priority. Overload Abatement As defined in [RFC7683]. Reaction to receipt of an overload report resulting in a reduction in traffic sent to the reporting node. Abatement actions include diversion and throttling. Priority The relative importance of a Diameter message. A lower-priority value implies a higher relative importance of the message. Throttling As defined in [RFC7683]. An abatement treatment that limits the number of requests sent by the DOIC reacting node. Throttling can include a Diameter Client choosing to not send requests or a Diameter Agent or Server rejecting requests with appropriate error responses. In both cases, the result of the throttling is a permanent rejection of the transaction. 3. Conventions Used in This Document 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]. The interpretation from RFC 2119 does not apply for the above listed words when they are not used in all caps. Donovan Standards Track [Page 4] RFC 7944 DOIC August 2016 4. Problem Statement With the introduction of overload control mechanisms, Diameter nodes will be required to make decisions regarding which Diameter request messages should be throttled as a result of overloaded Diameter nodes. There is currently no generic mechanism to indicate which request messages should be given preferential treatment when these throttling decisions are made. As a result, all messages are treated equally and, as such, have an equal probability of being throttled. There are a number of scenarios where it is appropriate for an application to mark a request as being of a higher priority than other application requests. These are discussed in the next section. This document defines a mechanism for applications to indicate priority for individual transactions, reducing the probability of those transactions being throttled if there are other lower-priority transactions that are eligible for throttling treatment. While the primary usage of DRMP-defined priorities is for input to throttling decisions related to Diameter overload control, it is also expected that the priority information could also be used for other routing-related functionality. This might include giving higher- priority transactions preferential treatment when selecting routes. It is also envisioned that DRMP information could be used by Diameter endpoints to make resource allocation decisions. For instance, a Diameter Server might choose to use the priority information to treat higher-priority requests ahead of lower-priority requests. It might also use the priority information as a reason to fail a request as a result of insufficient resources. Note: There are a number of application-specific definitions indicating various views of application-level priority for different requests. Using these application-specific priority AVPs as input to throttling and other Diameter routing decisions would require Diameter Agents to understand all applications and do application-specific parsing of all messages in order to determine the priority of individual messages. This is considered an unacceptable level of complexity to put on elements whose primary responsibility is to route Diameter messages. Donovan Standards Track [Page 5] RFC 7944 DOIC August 2016 5. Use Cases This section discusses various scenarios where Diameter transactions can benefit from the use of priority information. It is important to note that for priority information to be reliably usable, the Diameter nodes sending and consuming DRMP AVPs must have pre-established trust relationships of the sort described in Section 12. 5.1. First-Responder-Related Signaling Natural disasters can result in a considerable increase in usage of network resources. This can be made worse if the disaster results in a loss of network capacity. The combination of added load and reduced capacity can lead to Diameter nodes becoming overloaded and, as a result, the use of DOIC mechanisms to request a reduction in traffic. In turn, this results in requests being throttled in an attempt to control the overload scenario and prevent the overloaded node from failing. There is the need for first responders and other individuals responsible for handling the after effects of the disaster to be assured that they can gain access to the network resources in order to communicate both between themselves and with other network resources. Signaling associated with first responders needs to be given a higher priority to help ensure they can most effectively do their jobs. The United States Wireless Priority Services (WPS) and Government Emergency Telecommunications Service (GETS) are examples of systems designed to address the command and control aspects of these first responder needs. 5.2. Emergency-Call-Related Signaling Similar to the first responder scenario, there is also signaling associated with emergency calls. Given the critical nature of these emergency calls, this signaling should also be given preferential treatment when possible. Donovan Standards Track [Page 6] RFC 7944 DOIC August 2016 5.3. Differentiated Services Operators may desire to differentiate network-based services by providing a service level agreement (SLA) that includes preferential Diameter routing behavior. This might, for example, be modeled as Platinum, Gold, and Silver levels of service. In this scenario, an operator might offer a Platinum SLA that includes ensuring that all signaling for a customer who purchases the Platinum service is being marked as having a higher priority than signaling associated with Gold and Silver customers. 5.4. Application-Specific Priorities There are scenarios within Diameter applications where it might be appropriate to give a subset of the transactions for the application a higher priority than other transactions for that application. For instance, when there is a series of transactions required for a user to gain access to network services, it might be appropriate to mark transactions that occur later in the series at a higher priority than those that occur early in the series. This would recognize that there was potentially significant work done by the network already that would be lost if those later transactions were throttled. There are also scenarios where an agent cannot easily differentiate a request that starts a session from requests that update or end sessions. In these scenarios, it might be appropriate to mark the requests that establish new sessions with a lower priority than updates and session ending requests. This also recognizes that more work has already taken place for established sessions, and as a result, it might be more harmful from a signaling point of view if the session update and session ending requests were to be throttled. There are also scenarios where the priority of requests for individual command codes within an application depends on the context that exists when the request is sent. There isn't always information in the message from which this context can be determined by Diameter nodes other than the node that originates the request. This is similar to the scenario where a series of requests are needed to access a network service. It is different in that the series of requests involves different application command codes. In this scenario, requests with the same command code have different implied priorities. Donovan Standards Track [Page 7] RFC 7944 DOIC August 2016 One example of this is in the 3GPP application [S6a] where an Update Location Request (ULR) resulting from a Mobility Management Entity (MME) restoration procedure might be given a higher priority than a ULR resulting from an initial attach. 6. Theory of Operation This section outlines the envisioned usage of DRMP. The expected behavior depends on the role (request sender, agent, or request handler) of the Diameter node handling the request. The following behavior is expected during the flow of a Diameter transaction. 1. Request sender -- The sender of a request, be it a Diameter Client or a Diameter Server, determines the relative priority of the request and includes that priority information in the request. The method for determining the relative priority is application specific and is outside the scope of this specification. The request sender also saves the priority information with the transaction state. This will be used when handling the answer messages. 2. Agents handling the request -- Agents use the priority information when making routing decisions. This can include determining which requests to route first, which requests to throttle, and where the request is routed. For instance, requests with higher priority might have a lower probability of being throttled. The mechanism for how the agent determines which requests are candidates to be throttled is implementation dependent and is outside the scope of this document. Before forwarding request messages, agents generally do not modify the priority information present in the received request message nor include the priority information when absent in the received request message. However, in some scenarios, agents can modify the priority information, for example, edge agents modifying the priority values set by an adjacent operator. There might be other scenarios where a Diameter endpoint does not support the DRMP mechanism, and agents insert the priority information in the request messages for that non-supporting endpoint. When forwarding the request messages, the agent also saves the transaction priority in the transaction state either as locally managed state or using the Proxy-Info mechanism defined in [RFC6733]. This will be used when handling the associated answer message for the transaction. Donovan Standards Track [Page 8] RFC 7944 DOIC August 2016 3. Request handler -- The handler of the request, be it a Diameter Server or a Diameter Client, can use the priority information to determine how to handle the request. This could include determining the order in which requests are handled and resources that are applied to the handling of the request. 4. Answer sender -- The handler of the request is also the sender of the answer. The answer sender uses the priority information received in the request message when sending the answer. This implies that answers for higher-priority transactions are given preferential treatment over lower-priority transactions. The answer sender also has the option of including priority information in the answer message. This is done when the answer message needs to have a different priority than the priority carried in the request message. The priority included by the answer sender is application specific. 5. Agent handling the answer -- By default, agents handling answer messages use the priority information stored with the transaction state to determine the priority of relaying the answer message. However, priority information included in the answer message, when present, is used in place of the stored priority information. The use of priority information implies that answers for higher-priority transactions are given preferential treatment over lower-priority transactions. When forwarding the answer messages, agents generally do not modify the priority information present in the received answer messages nor include the priority information when absent in the received answer messages. However, in some scenarios, agents can modify the priority information, for example, edge agents modifying the priority values set by an adjacent operator. There might be other scenarios where a Diameter endpoint does not support the DRMP mechanism, and agents insert the priority information for that non-supporting endpoint. 6. Answer handler -- The answer handler uses the same method as the agent to determine the priority of the answer message. By default, the handler of the answer message uses the priority saved in the transaction's state. Priority information in the answer message is used when present. The priority is used when allocating resources for processing that occurs after the receipt of the answer message. Donovan Standards Track [Page 9] RFC 7944 DOIC August 2016 7. Extensibility This document does not define extensibility mechanisms that are specific to the DRMP mechanism. As a result, any extension that requires new AVPs will be required to use existing Diameter extensibility mechanisms defined in [RFC6733]. 8. Normative Behavior This section contains the normative behavior associated with DRMP. When routing priority information is available, Diameter nodes SHOULD include Diameter routing message priority in the DRMP AVP in all Diameter request messages. Note: The method of determining the priority value included in the request is application specific and is not in the scope of this specification. The priority marking scheme does not require the Diameter Agents to understand application-specific AVPs. When available, Diameter nodes SHOULD use routing priority information included in the DRMP AVP when making Diameter overload throttling decisions. Diameter Agents MAY use routing priority information included in the DRMP AVP when relaying request and answer messages. This includes the selection of routes and the ordering of messages relayed. Note: The priority information included in the DRMP AVP in request messages applies to both the request message and, by default, the answer message associated with the transaction. While done only in exceptional circumstances, Diameter Agents MAY modify priority information when relaying request and answer messages. Note: There might be scenarios where a Diameter Agent does modify priority information. For instance, an edge agent might need to modify the priority values set by an adjacent operator. While done only in exceptional circumstances, Diameter Agents MAY add priority information when relaying request and answer messages. Note: There might be scenarios where a Diameter endpoint does not support the DRMP mechanism, and agents insert priority information for that non-supporting endpoint. Donovan Standards Track [Page 10] RFC 7944 DOIC August 2016 Diameter endpoints MAY use routing priority information included in the DRMP AVP when making resource allocation decisions for the transaction associated with the request message that contains the DRMP information. Diameter endpoints MAY use routing priority information included in the DRMP AVP when making resource allocation decisions for the transaction associated with the answer messages using the DRMP information associated with the transaction. Diameter endpoints MAY include the DRMP AVP in answer messages. This is done when the priority for the answer message needs to have a different priority than the priority carried in the request message. When determining the priority to apply to answer messages, Diameter nodes SHOULD use the priority indicated in the DRMP AVP carried in the answer message, if it exists. If there is not DRMP AVP in the answer message, then the Diameter node SHOULD use the priority indicated in the DRMP AVP of the associated request message. Note: One method to determine what priority to apply to an answer when there is no DRMP AVP in the answer message is to save the priority included in the request message in the state associated with the Diameter transaction. Another is to use the Proxy-Info mechanism defined in [RFC6733]. Diameter nodes MUST have a default priority to apply to transactions that do not have an explicit priority set in the DRMP AVP. In order to guarantee consistent handling of messages from non- upgraded Diameter Clients, Diameter nodes SHOULD use the PRIORITY_10 priority as this default priority value. PRIORITY_10 is a midrange priority that corresponds to "normal" traffic and thus would be a suitable default for most deployments, while still allowing different Diameter applications to designate other priorities for lower- and higher-priority traffic. Note: This does not imply that a DRMP AVP is added to the message. Rather, the message is treated the same as a message that has a DRMP AVP with a priority value of PRIORITY_10. Diameter nodes MUST support the ability for the default priority to be modified through local configuration interfaces. Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator-defined local Donovan Standards Track [Page 11] RFC 7944 DOIC August 2016 policy would override the use of PRIORITY_10 as the default priority. When using DRMP information, Diameter nodes MUST use the default priority for transactions that do not have priority specified in a DRMP AVP. Note: This guidance on the handling of messages without a priority does not result in a Diameter Agent inserting a DRMP AVP into the message. Rather, it gives guidance on how that specific transaction should be treated when its priority is compared with other requests. When a Diameter Agent relays the request, it will not insert a DRMP AVP with a priority value of 10. When setting and using priorities, for all integers x,y in [0,15], treat PRIORITY_ as lower priority than PRIORITY_ when y. [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, . 13.2. Informative References [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. Morand, "Diameter Overload Indication Conveyance", RFC 7683, DOI 10.17487/RFC7683, October 2015, . [S6a] 3GPP, "Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol", 3GPP TS 29.272, 14.0.0, June 2016, . Donovan Standards Track [Page 17] RFC 7944 DOIC August 2016 Contributors The following person contributed substantial ideas, feedback, and discussion to this document: o Janet P. Gunn Author's Address Steve Donovan Oracle 7460 Warren Parkway Frisco, Texas 75034 United States of America Email: srdonovan@usdonovans.com Donovan Standards Track [Page 18]