--- 1/draft-ietf-dime-drmp-03.txt 2016-03-10 09:16:05.581211303 -0800 +++ 2/draft-ietf-dime-drmp-04.txt 2016-03-10 09:16:05.617212196 -0800 @@ -1,18 +1,18 @@ Diameter Maintenance and Extensions (DIME) S. Donovan Internet-Draft Oracle -Intended status: Standards Track February 2, 2016 -Expires: August 5, 2016 +Intended status: Standards Track March 10, 2016 +Expires: September 11, 2016 Diameter Routing Message Priority - draft-ietf-dime-drmp-03.txt + draft-ietf-dime-drmp-04.txt 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. @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 5, 2016. + This Internet-Draft will expire on September 11, 2016. 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 @@ -55,36 +55,36 @@ 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. First Responder Related Signaling . . . . . . . . . . . . 5 5.2. Emergency Call Related Signaling . . . . . . . . . . . . 5 5.3. Differentiated Services . . . . . . . . . . . . . . . . . 6 5.4. Application Specific Priorities . . . . . . . . . . . . . 6 6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 - 8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 8 + 8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 9 9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 11 9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 11 9.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 10.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . 13 - 10.2. New registries . . . . . . . . . . . . . . . . . . . . . 13 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 10.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.2. New registries . . . . . . . . . . . . . . . . . . . . . 12 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 13 11.2. Denial of Service Attacks . . . . . . . . . . . . . . . 14 11.3. End-to End-Security Issues . . . . . . . . . . . . . . . 14 - 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 13.2. Informative References . . . . . . . . . . . . . . . . . 15 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The 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. @@ -273,53 +273,64 @@ 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 involve different application command codes. In this scenario it is requests with the same command code that have different implied priorities. One example of this is in the 3GPP application [S6a] where a ULR - request resulting from an MME restoration procedure might be given - a higher priority than a ULR resulting from an initial attach. + request resulting from an MME (Mobility Management Entity) + restoration procedure might be given a higher priority than a ULR + (Update Location Request) 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 handing the request - Agents use the priority information + 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 throttled is implementation dependent and is outside the scope of - this document. 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. + 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. 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 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 @@ -331,21 +342,30 @@ 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 to lower priority transactions. + treatment to 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. 7. Extensibility @@ -361,35 +381,50 @@ Resource Message Priority (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 SHOULD NOT require the Diameter Agents to + 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. The priority information included in the DRMP AVP in request messages applies to both the request message and, by default, answer message associated with the transaction. + While done only in exceptional circumstances, Diameter agents MAY + modify priority information when relaying request and answer + messages. + + 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. + + There might be scenarios where a Diameter endpoint does not + support the DRMP mechanism and agents insert priority information + for that non supporting endpoint. + 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. @@ -428,73 +463,24 @@ 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, PRIORITY_0 MUST be treated as the - highest priority. - - When setting and using priorities, PRIORITY_1 MUST be treated as a - lower priority than PRIORITY_0 and a higher priority than PRIORITY_2. - - When setting and using priorities, PRIORITY_2 MUST be treated as a - lower priority than PRIORITY_1 and a higher priority than PRIORITY_3. - - When setting and using priorities, PRIORITY_3 MUST be treated as a - lower priority than PRIORITY_2 and a higher priority than PRIORITY_4. - - When setting and using priorities, PRIORITY_4 MUST be treated as a - lower priority than PRIORITY_3 and a higher priority than PRIORITY_5. - - When setting and using priorities, PRIORITY_5 MUST be treated as a - lower priority than PRIORITY_4 and a higher priority than PRIORITY_6. - - When setting and using priorities, PRIORITY_6 MUST be treated as a - lower priority than PRIORITY_5 and a higher priority than PRIORITY_7. - - When setting and using priorities, PRIORITY_7 MUST be treated as a - lower priority than PRIORITY_6 and a higher priority than PRIORITY_8. - - When setting and using priorities, PRIORITY_8 MUST be treated as a - lower priority than PRIORITY_7 and a higher priority than PRIORITY_9. - - When setting and using priorities, PRIORITY_9 MUST be treated as a - lower priority than PRIORITY_8 and a higher priority than - PRIORITY_10. - - When setting and using priorities, PRIORITY_10 MUST be treated as a - lower priority than PRIORITY_9 and a higher priority than - PRIORITY_11. - - When setting and using priorities, PRIORITY_11 MUST be treated as a - lower priority than PRIORITY_10 and a higher priority than - PRIORITY_12. - - When setting and using priorities, PRIORITY_12 MUST be treated as a - lower priority than PRIORITY_11 and a higher priority than - PRIORITY_13. - - When setting and using priorities, PRIORITY_13 MUST be treated as a - lower priority than PRIORITY_12 and a higher priority than - PRIORITY_14. - - When setting and using priorities, PRIORITY_14 MUST be treated as a - lower priority than PRIORITY_13 and a higher priority than - PRIORITY_15. + When setting and using priorities, for all integers x,y in [0,15] + treat PRIORITY_ as lower priority than PRIOIRTY_ when y. - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 5226, - DOI 10.17487/RFC5226, May 2008, - . - [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 - [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource - Priority for the Session Initiation Protocol (SIP)", - RFC 4412, DOI 10.17487/RFC4412, February 2006, - . - [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 10.8.0, June 2013.