idnits 2.17.1 draft-ietf-dime-drmp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 3, 2016) is 2885 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 529 -- Looks like a reference, but probably isn't: '15' on line 529 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions (DIME) S. Donovan 3 Internet-Draft Oracle 4 Intended status: Standards Track June 3, 2016 5 Expires: December 5, 2016 7 Diameter Routing Message Priority 8 draft-ietf-dime-drmp-07.txt 10 Abstract 12 When making routing and resource allocation decisions, Diameter nodes 13 currently have no generic mechanism to determine the relative 14 priority of Diameter messages. This document addresses this by 15 defining a mechanism to allow Diameter endpoints to indicate the 16 relative priority of Diameter transactions. With this information 17 Diameter nodes can factor that priority into routing, resource 18 allocation and overload abatement decisions. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 5, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 57 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 58 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. First Responder Related Signaling . . . . . . . . . . . . 6 61 5.2. Emergency Call Related Signaling . . . . . . . . . . . . 6 62 5.3. Differentiated Services . . . . . . . . . . . . . . . . . 6 63 5.4. Application Specific Priorities . . . . . . . . . . . . . 7 64 6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8 65 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 9 66 8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 10 67 9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 12 68 9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 12 69 9.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 13 70 10. Considerations When Defining Application Priorities . . . . . 13 71 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 11.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . 15 73 11.2. New registries . . . . . . . . . . . . . . . . . . . . . 15 74 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 12.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 15 76 12.2. Denial of Service Attacks . . . . . . . . . . . . . . . 16 77 12.3. End-to End-Security Issues . . . . . . . . . . . . . . . 16 78 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 79 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 14.1. Normative References . . . . . . . . . . . . . . . . . . 17 81 14.2. Informative References . . . . . . . . . . . . . . . . . 17 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 The Diameter Overload Indication Conveyance (DOIC) solution [RFC7683] 87 for Diameter overload control introduces scenarios where Diameter 88 routing decisions made by Diameter nodes can be influenced by the 89 overload state of other Diameter nodes. This includes the scenarios 90 where Diameter endpoints and Diameter agents can throttle requests as 91 a result of the target for the request being overloaded. 93 With currently available mechanisms these Diameter nodes do not have 94 a mechanism to differentiate request message priorities when making 95 these throttling decisions. As such, all requests are treated the 96 same, meaning that all requests have the same probability of being 97 throttled. 99 There are scenarios where treating all requests the same can cause 100 issues. For instance, it might be considered important to reduce the 101 probability of transactions involving first responders being 102 throttled during overload scenarios caused, for example, by a period 103 of heavy signaling resulting from a natural disaster. 105 This document defines a mechanism that allows Diameter nodes to 106 indicate the relative priority of Diameter transactions. With this 107 information other Diameter nodes can factor the relative priority of 108 requests into routing and throttling decisions. 110 1.1. Applicability 112 There are two primary considerations that must be addressed for the 113 mechanism described in this document to work effectively. The first 114 takes into consideration that the Diameter base protocol defined in 115 [RFC6733] is designed to transport multiple Diameter applications 116 and that Diameter nodes can be implemented that support multiple 117 applications. In order for the DRMP mechanism to work, the 118 priorities defined for all messages across all applications used in a 119 Diameter administrative domain must be defined in a consistent and 120 coordinated fashion, taking the default priority into account. See 121 Section 10 for a discussion of some of the considerations that need 122 to be factored into the setting of DRMP priorities used by Diameter 123 applications. 125 Note that this consideration does not apply to Diameter networks 126 where all Diameter nodes only support a single application. 128 Without this cross application priority design taken into 129 consideration it is possible for messages for one application to gain 130 unwarranted preferential treatment over messages for other 131 applications. 133 This mechanism also depends on all of the messages that carry the 134 DRMP AVP are inserted into Diameter messages by trusted nodes within 135 the Diameter administrative domain. As discussed in Section 12, 136 misbehaving nodes have the ability to use the DRMP mechanism to gain 137 unwarranted preferential treatment. 139 When messages cross Diameter administrative boundaries, care should 140 be taken to either strip or modify the DRMP priority values in these 141 messages. If the priority definitions vary between the two Diameter 142 administrative domains then it is possible for messages from a 143 foreign domain to gain unwarranted preferential treatment. 145 2. Terminology and Abbreviations 147 Diversion 149 As defined in [RFC7683]. An overload abatement treatment where 150 the reacting node selects alternate destinations or paths for 151 requests. 153 DOIC 155 Diameter Overload Indication Conveyance. 157 DRMP 159 Diameter Routing Message Priority. 161 Overload Abatement 163 As defined in [RFC7683]. Reaction to receipt of an overload 164 report resulting in a reduction in traffic sent to the reporting 165 node. Abatement actions include diversion and throttling. 167 Priority 169 The relative importance of a Diameter message. A lower priority 170 value implies a higher relative importance of the message. 172 Throttling 174 As defined in [RFC7683]. An abatement treatment that limits the 175 number of requests sent by the DOIC reacting node. Throttling can 176 include a Diameter Client choosing to not send requests, or a 177 Diameter Agent or Server rejecting requests with appropriate error 178 responses. In both cases the result of the throttling is a 179 permanent rejection of the transaction. 181 3. Conventions Used in This Document 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC2119]. 187 RFC 2119 [RFC2119] interpretation does not apply for the above listed 188 words when they are not used in all-caps format. 190 4. Problem Statement 192 With the introduction of overload control mechanisms, Diameter nodes 193 will be required to make decisions regarding which Diameter request 194 messages should be throttled as a result of overloaded Diameter 195 nodes. 197 There is currently no generic mechanism to indicate which request 198 messages should be given preferential treatment when these throttling 199 decisions are made. 201 As a result, all messages are treated equally and, as such, have an 202 equal probability of being throttled. 204 There are a number of scenarios where it is appropriate for an 205 application to mark a request as being of a higher priority than 206 other application requests. These are discussed in the next section. 208 This document defines a mechanism for applications to indicate 209 priority for individual transactions, reducing the probability of 210 those transactions being throttled if there are other lower priority 211 transactions that are eligible for throttling treatment. 213 While the primary usage of DRMP defined priorities is for input to 214 Diameter overload control related throttling decisions, it is also 215 expected that the priority information could also be used for other 216 routing related functionality. This might include giving higher 217 priority transactions preferential treatment when selecting routes. 219 It is also envisioned that DRMP priority information could be used by 220 Diameter endpoints to make resource allocation decisions. For 221 instance, a Diameter Server might choose to use the priority 222 information to treat higher priority requests ahead of lower priority 223 requests. It might also use the priority information to as a reason 224 to fail a request as a result of insufficient resources. 226 Note: There are a number of application specific definitions 227 indicating various views of application level priority for 228 different requests. Using these application specific priority 229 Attribute Value Pairs (AVPs) as input to throttling and other 230 Diameter routing decisions would require Diameter agents to 231 understand all applications and do application specific parsing of 232 all messages in order to determine the priority of individual 233 messages. This is considered an unacceptable level of complexity 234 to put on elements whose primary responsibility is to route 235 Diameter messages. 237 5. Use Cases 239 This section discusses various scenarios where Diameter transactions 240 can benefit from the use of priority information. 242 It is important to note that for priority information to be reliably 243 usable, the Diameter nodes sending and consuming DRMP AVPs must have 244 pre-established trust relationships of the sort described in 245 Section 12. 247 5.1. First Responder Related Signaling 249 Natural disasters can result in a considerable increase in usage of 250 network resources. This can be made worse if the disaster results in 251 a loss of network capacity. 253 The combination of added load and reduced capacity can lead to 254 Diameter nodes becoming overloaded and, as a result, the use of DOIC 255 mechanisms to request a reduction in traffic. This in turn results 256 in requests being throttled in an attempt to control the overload 257 scenario and prevent the overloaded node from failing. 259 There is the need for first responders and other individuals 260 responsible for handling the after effects of the disaster to be 261 assured that they can gain access to the network resources in order 262 to communicate both between themselves and with other network 263 resources. 265 Signaling associated with first responders needs to be given a higher 266 priority to help ensure they can most effectively do their jobs. 268 The United States Wireless Priority Services (WPS) and Government 269 Emergency Telecommunications Service (GETS) are examples of systems 270 designed to address the command and control aspects of these first 271 responder needs. 273 5.2. Emergency Call Related Signaling 275 Similar to the first responder scenario, there is also signaling 276 associated with emergency calls. Given the critical nature of these 277 emergency calls, this signaling should also be given preferential 278 treatment when possible. 280 5.3. Differentiated Services 282 Operators may desire to differentiate network-based services by 283 providing a service level agreement that includes preferential 284 Diameter routing behavior. This might, for example, be modeled as 285 Platinum, Gold and Silver levels of service. 287 In this scenario an operator might offer a Platinum SLA that includes 288 ensuring that all signaling for a customer who purchases the Platinum 289 service being marked as having a higher priority than signaling 290 associated with Gold and Silver customers. 292 5.4. Application Specific Priorities 294 There are scenarios within Diameter applications where it might be 295 appropriate to give a subset of the transactions for the application 296 a higher priority than other transactions for that application. 298 For instance, when there is a series of transactions required for a 299 user to gain access to network services, it might be appropriate to 300 mark transactions that occur later in the series at a higher priority 301 than those that occur early in the series. This would recognize that 302 there was potentially significant work done by the network already 303 that would be lost if those later transactions were throttled. 305 There are also scenarios where an agent cannot easily differentiate a 306 request that starts a session from requests that update or end 307 sessions. In these scenarios it might be appropriate to mark the 308 requests that establish new sessions with a lower priority than 309 updates and session ending requests. This also recognizes that more 310 work has already taken place for established sessions and, as a 311 result, it might be more harmful from a signaling point of view if 312 the session update and session ending requests were to be throttled. 314 There are also scenarios where the priority of requests for 315 individual command codes within an application depends on the context 316 that exists when the request is sent. There isn't always information 317 in the message from which this context can be determined by Diameter 318 nodes other than the node that originates the request. 320 This is similar to the scenario where a series of requests are needed 321 to access a network service. It is different in that the series of 322 requests involve different application command codes. In this 323 scenario requests with the same command code have different implied 324 priorities. 326 One example of this is in the 3GPP application [S6a] where an 327 Update Location Request (ULR) request resulting from an MME 328 (Mobility Management Entity) restoration procedure might be given 329 a higher priority than a ULR (Update Location Request) resulting 330 from an initial attach. 332 6. Theory of Operation 334 This section outlines the envisioned usage of DRMP. 336 The expected behavior depends on the role (request sender, agent or 337 request handler) of the Diameter node handling the request. 339 The following behavior is expected during the flow of a Diameter 340 transaction. 342 1. Request sender - The sender of a request, be it a Diameter Client 343 or a Diameter Server, determines the relative priority of the 344 request and includes that priority information in the request. 345 The method for determining the relative priority is application 346 specific and is outside the scope of this specification. The 347 request sender also saves the priority information with the 348 transaction state. This will be used when handling the answer 349 messages. 351 2. Agents handling the request - Agents use the priority information 352 when making routing decisions. This can include determining 353 which requests to route first, which requests to throttle and 354 where the request is routed. For instance, requests with higher 355 priority might have a lower probability of being throttled. The 356 mechanism for how the agent determines which requests are 357 candidates to be throttled is implementation dependent and is 358 outside the scope of this document. Before forwarding request 359 messages, agents generally do not modify the priority information 360 present in the received request message nor include the priority 361 information when absent in the received request message. 362 However, in some scenarios, agents can modify the priority 363 information, for example, edge agents modifying the priority 364 values set by an adjacent operator. There might be other 365 scenarios where a Diameter endpoint does not support the DRMP 366 mechanism and agents insert the priority information in the 367 request messages for that non supporting endpoint. When 368 forwarding the request messages, the agent also saves the 369 transaction priority in the transaction state, either as locally 370 managed state or using the Proxy-Info mechanism defined in 371 [RFC6733]. This will be used when handling the associated answer 372 message for the transaction. 374 3. Request handler - The handler of the request, be it a Diameter 375 Server or a Diameter Client, can use the priority information to 376 determine how to handle the request. This could include 377 determining the order in which requests are handled and resources 378 that are applied to handling of the request. 380 4. Answer sender - The handler of the request is also the sender of 381 the answer. The answer sender uses the priority information 382 received in the request message when sending the answer. This 383 implies that answers for higher priority transactions are given 384 preferential treatment to lower priority transactions. The 385 answer sender also has the option of including priority 386 information in the answer message. This is done when the answer 387 message needs to have a different priority than the priority 388 carried in the request message. The priority included by the 389 answer sender is application specific. 391 5. Agent handling the answer - By default, agents handling answer 392 messages use the priority information stored with the transaction 393 state to determine the priority of relaying the answer message. 394 However, priority information included in the answer message, 395 when present, is used in place of the stored priority 396 information. The use of priority information implies that 397 answers for higher priority transactions are given preferential 398 treatment to lower priority transactions. When forwarding the 399 answer messages, agents generally do not modify the priority 400 information present in the received answer messages nor include 401 the priority information when absent in the received answer 402 messages. However, in some scenarios, agents can modify the 403 priority information, for example, edge agents modifying the 404 priority values set by an adjacent operator. There might be 405 other scenarios where a Diameter endpoint does not support the 406 DRMP mechanism and agents insert the priority information for 407 that non-supporting endpoint. 409 6. Answer handler - The answer handler uses the same method as the 410 agent to determine the priority of the answer message. By 411 default the handler of the answer message uses the priority saved 412 in the transaction's state. Priority information in the answer 413 message is used when present. The priority is used when 414 allocating resources for processing that occurs after the receipt 415 of the answer message. 417 7. Extensibility 419 This document does not define extensibility mechanisms that are 420 specific to the DRMP mechanism. As a result, any extension that 421 requires new AVPs will be required to use existing Diameter 422 extensibility mechanisms defined in [RFC6733]. 424 8. Normative Behavior 426 This section contains the normative behavior associated with Diameter 427 Resource Message Priority (DRMP). 429 When routing priority information is available, Diameter nodes SHOULD 430 include Diameter routing message priority in the DRMP AVP in all 431 Diameter request messages. 433 Note: The method of determining the priority value included in the 434 request is application specific and is not in the scope of this 435 specification. 437 The priority marking scheme does not require the Diameter Agents to 438 understand application specific AVPs. 440 When available, Diameter nodes SHOULD use routing priority 441 information included in the DRMP AVP when making Diameter overload 442 throttling decisions. 444 Diameter agents MAY use routing priority information included in the 445 DRMP AVP when relaying request and answer messages. This includes 446 the selection of routes and the ordering of messages relayed. 448 Note: The priority information included in the DRMP AVP in request 449 messages applies to both the request message and, by default, 450 answer message associated with the transaction. 452 While done only in exceptional circumstances, Diameter agents MAY 453 modify priority information when relaying request and answer 454 messages. 456 Note: There might be scenarios where a Diameter agent does modify 457 priority information. For instance, an edge agent might need to 458 modify the priority values set by an adjacent operator. 460 While done only in exceptional circumstances, Diameter agents MAY add 461 priority information when relaying request and answer messages. 463 Note: There might be scenarios where a Diameter endpoint does not 464 support the DRMP mechanism and agents insert priority information 465 for that non-supporting endpoint. 467 Diameter endpoints MAY use routing priority information included in 468 the DRMP AVP when making resource allocation decisions for the 469 transaction associated with the request message that contains the 470 DRMP information. 472 Diameter endpoints MAY use routing priority information included in 473 the DRMP AVP when making resource allocation decisions for the 474 transaction associated with the answer messages using the DRMP 475 information associated with the transaction. 477 Diameter endpoints MAY include the DRMP AVP in answer messages. This 478 is done when the priority for the answer message needs to have a 479 different priority than the priority carried in the request message. 481 When determining the priority to apply to answer messages, Diameter 482 nodes SHOULD use the priority indicated in the DRMP AVP carried in 483 the answer message, if it exists. If there is not DRMP AVP in the 484 answer message then the Diameter node SHOULD use the priority 485 indicated in the DRMP AVP of the associated request message. 487 Note: One method to determine what priority to apply to an answer 488 when there is no DRMP AVP in the answer message is to save the 489 priority included in the request message in state associated with 490 the Diameter transaction. Another is to use the Proxy-Info 491 mechanism defined in [RFC6733]. 493 Diameter nodes MUST have a default priority to apply to transactions 494 that do not have an explicit priority set in the DRMP AVP. 496 In order to guaranty consistent handling of messages from nonupgraded 497 Diameter clients, Diameter nodes SHOULD use the PRIORITY_10 priority 498 as this default priority value. 500 PRIORITY_10 is a mid range priority that corresponds to "normal" 501 traffic and thus would be a suitable default for most deployments, 502 while still allowing different Diameter applications to designate 503 other priorities for lower and higher priority traffic. 505 Note: This does not imply that a DRMP AVP is added to the message. 506 Rather, the message is treated the same as a message that has a 507 DRMP AVP with priority value of PRIORITY_10. 509 Diameter nodes MUST support the ability for the default priority to 510 be modified through local configuration interfaces. 512 Note: There are scenarios where operators might want to specify a 513 different default value for transactions that do not have an 514 explicit priority. In this case, the operator defined local 515 policy would override the use of PRIORITY_10 as the default 516 priority. 518 When using DRMP priority information, Diameter nodes MUST use the 519 default priority for transactions that do not have priority specified 520 in a DRMP AVP. 522 Note: This guidance on the handling of messages without a priority 523 does not result in a Diameter agent inserting a DRMP AVP into the 524 message. Rather, it gives guidance on how that specific 525 transaction should be treated when its priority is compared with 526 other requests. When a Diameter agent relays the request it will 527 not insert a DRMP AVP with a priority value of 10. 529 When setting and using priorities, for all integers x,y in [0,15] 530 treat PRIORITY_ as lower priority than PRIOIRTY_ when y. 782 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 783 Ed., "Diameter Base Protocol", RFC 6733, 784 DOI 10.17487/RFC6733, October 2012, 785 . 787 14.2. Informative References 789 [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. 790 Morand, "Diameter Overload Indication Conveyance", 791 RFC 7683, DOI 10.17487/RFC7683, October 2015, 792 . 794 [S6a] 3GPP, "Evolved Packet System (EPS); Mobility Management 795 Entity (MME) and Serving GPRS Support Node (SGSN) related 796 interfaces based on Diameter protocol", 3GPP TS 29.272 797 10.8.0, June 2013. 799 Author's Address 800 Steve Donovan 801 Oracle 802 7460 Warren Parkway 803 Frisco, Texas 75034 804 United States 806 Email: srdonovan@usdonovans.com