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/rfc7944.txt | 1011 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1011 insertions(+) create mode 100644 doc/rfc/rfc7944.txt (limited to 'doc/rfc/rfc7944.txt') diff --git a/doc/rfc/rfc7944.txt b/doc/rfc/rfc7944.txt new file mode 100644 index 0000000..63e0f12 --- /dev/null +++ b/doc/rfc/rfc7944.txt @@ -0,0 +1,1011 @@ + + + + + + +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] + -- cgit v1.2.3