idnits 2.17.1 draft-donovan-dime-drmp-01.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 (May 26, 2015) is 3257 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) == Unused Reference: 'RFC5226' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC4412' is defined on line 488, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ietf-dime-ovli-08 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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 May 26, 2015 5 Expires: November 27, 2015 7 Diameter Routing Message Priority 8 draft-donovan-dime-drmp-01.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 defines a mechanism to 15 allow Diameter endpoints to indicate the relative priority of 16 Diameter transactions. With this information Diameter nodes can 17 factor that priority into routing, resource allocation and overload 18 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 November 27, 2015. 37 Copyright Notice 39 Copyright (c) 2015 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 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 56 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 57 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. First Responder Related Signaling . . . . . . . . . . . . 5 60 5.2. Emergency Call Related Signaling . . . . . . . . . . . . 5 61 5.3. Differentiated Services . . . . . . . . . . . . . . . . . 5 62 5.4. Application Specific Priorities . . . . . . . . . . . . . 6 63 6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7 64 7. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 8 65 8. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 9 66 8.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 9 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 9.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 10 70 9.2. New registries . . . . . . . . . . . . . . . . . . . . . 10 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 12.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Appendix A. Design Considerations and Questions . . . . . . . . 11 77 A.1. Relationship with SIP Resource Priority . . . . . . . . . 11 78 A.2. Priority Encoding Method . . . . . . . . . . . . . . . . 12 79 A.3. Base Protocol versus Application Extension . . . . . . . 12 80 A.4. Scope of Priority Setting . . . . . . . . . . . . . . . . 12 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 The DOIC solution [I-D.ietf-dime-ovli] for Diameter overload control 86 introduces scenarios where Diameter routing decisions made by 87 Diameter nodes can be influenced by the overload state of other 88 Diameter nodes. This includes the scenarios where Diameter endpoints 89 and Diameter agents can throttle requests as a result of the target 90 for the request being overloaded. 92 With currently available mechanisms these Diameter nodes do not have 93 a clean mechanism to differentiate request message priorities when 94 making these throttling decisions. As such, all requests are treated 95 the same meaning that all requests have the same probability of being 96 throttled. 98 There are scenarios where treating all requests the same can cause 99 issues. For instance it might be considered important to reduce the 100 probability of transactions involving first responders during a 101 period of heavy signaling resulting from a natural disaster being 102 throttled during overload scenarios. 104 This document defines a mechanism that allows Diameter nodes to 105 indicate the relative priority of Diameter transactions. With this 106 information other Diameter nodes can factor the relative priority of 107 requests into routing and throttling decisions. 109 2. Terminology and Abbreviations 111 Diversion 113 As defined in [I-D.ietf-dime-ovli]. An overload abatement 114 treatment where the reacting node selects alternate destinations 115 or paths for requests. 117 DOIC 119 Diameter Overload Indication Conveyance. 121 DRMP 123 Diameter Routing Message Priority. 125 Overload Abatement 127 As defined in [I-D.ietf-dime-ovli]. Reaction to receipt of an 128 overload report resulting in a reduction in traffic sent to the 129 reporting node. Abatement actions include diversion and 130 throttling. 132 Priority 134 The relative importance of a Diameter message. A higher priority 135 value implies a higher relative importance of the message. 137 Throttling 139 As defined in [I-D.ietf-dime-ovli]. An abatement treatment that 140 limits the number of requests sent by the DIOC reacting node. 141 Throttling can include a Diameter Client choosing to not send 142 requests, or a Diameter Agent or Server rejecting requests with 143 appropriate error responses. In both cases the result of the 144 throttling is a permanent rejection of the transaction. 146 3. Conventions Used in This Document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 RFC 2119 [RFC2119] interpretation does not apply for the above listed 153 words when they are not used in all-caps format. 155 4. Problem Statement 157 With the introduction of overload control mechanisms, Diameter nodes 158 will be required to make decisions regarding which Diameter request 159 messages should be throttled as a result of overloaded Diameter 160 nodes. 162 There is currently no generic mechanism to indicate which request 163 messages should be given preferential treatment when these throttling 164 decisions are made. 166 As a result, all messages are treated equally and, as such, have an 167 equal probability of being throttled. 169 There are a number of scenarios where it is appropriate for an 170 application to mark a request as being of a higher priority than 171 other application requests. These are discussed in the next section. 173 This document defines a mechanism for applications to indicate 174 priority for individual transactions, reducing the probability of 175 those transactions being throttled if there are other lower priority 176 transactions that are eligible for throttling treatment. 178 While the primary usage of DRMP defined priorities is for input to 179 Diameter overload control related throttling decisions, it is also 180 expected that the priority information could also be used for other 181 routing related functionality. This might include giving higher 182 priority transactions preferential treatment when selecting routes. 184 It is also envisioned that DRMP priority information could be used by 185 Diameter endpoints to make resource allocation decisions. For 186 instance, a Diameter Server might choose to use the priority 187 information to treat higher priority requests ahead of lower priority 188 requests. 190 Note: There are a number of application specific definitions 191 indicating various views of application level priority for 192 different requests. Using these application specific priority 193 AVPs as input to throttling and other Diameter routing decisions 194 would require Diameter agents to understand all applications and 195 do application specific parsing of all messages in order to 196 determine the priority of individual messages. This is considered 197 an unacceptable level of complexity to put on elements whose 198 primary responsibility is to route Diameter messages. 200 5. Use Cases 202 This section discussed various scenarios where Diameter transactions 203 can benefit from the use of priority information. 205 5.1. First Responder Related Signaling 207 Natural disasters can result in a considerable increase in usage of 208 network resources. This can be made worse if the disaster results in 209 a loss of network capacity. 211 The combination of added load and reduced capacity can lead to 212 Diameter nodes becoming overloaded and, as a result, the use of DOIC 213 mechanisms to request a reduction in traffic. This in turn results 214 in requests being throttled in an attempt to control the overload 215 scenario and prevent the overloaded node from failing. 217 There is the need for first responders and other individuals 218 responsible for handling the after effects of the disaster to be 219 assured that they can gain access to the network resources in order 220 to communicate both between themselves and with other network 221 resources. 223 Signaling associated with first responders needs to be given a higher 224 priority to help ensure they can most effectively do their job. 226 The United States Wireless Priority Services (WPS) and Government 227 Emergency Telecommunications Service (GETS) are examples of systems 228 designed to address these first responder needs. 230 5.2. Emergency Call Related Signaling 232 Similar to the first responder scenario, there is also signaling 233 associated with emergency calls. Given the critical nature of these 234 emergency calls, this signaling should also be given preferential 235 treatment when possible. 237 5.3. Differentiated Services 239 Operators may desire to differentiate network-based services by 240 providing a service level agreement that includes preferential 241 Diameter routing behavior. This might, for example, be modeled as 242 Platinum, Gold and Silver levels of service. 244 In this scenario an operator might offer a Platinum SLA the includes 245 ensuring that all signaling for a customer who purchases the Platinum 246 service being marked as having a higher priority than signaling 247 associated with Gold and Silver customers. 249 5.4. Application Specific Priorities 251 There are scenarios within Diameter applications where it might be 252 appropriate to give a subset of the transactions for the application 253 a higher priority than other transactions for that application. 255 For instance, when there is a series of transactions required for a 256 user to gain access to network services, it might be appropriate to 257 mark transactions that occur later in the series at a higher priority 258 than those that occur early in the series. This would recognize that 259 there was potentially significant work done by the network already 260 that would be lost if those later transactions were throttled. 262 There are also scenarios where an agent cannot easily differentiate a 263 request that starts a session from requests that update or end 264 sessions. In these scenarios it might be appropriate to mark the 265 requests that establish new sessions with a lower priority than 266 updates and session ending requests. This also recognizes that more 267 work has already taken place for established sessions and, as a 268 result, it might be more harmful if the session update and session 269 ending requests were to be throttled. 271 There are also scenarios where the priority of requests for 272 individual command codes within an application depends on the context 273 that exists when the request is sent. There isn't always information 274 in the message from which this context can be determined by Diameter 275 nodes other than the node that originates the request. 277 This is similar to the scenario where a series of requests are needed 278 to access a network service. It is different in that the series of 279 requests involve different application command-codes. In this 280 scenario it is requests with the same command-code that have 281 different implied priorities. 283 One example of this is in the 3GPP application [S6a] where a ULR 284 request resulting from an MME restoration procedure might be given 285 a higher priority than a ULR resulting from an initial attach. 287 6. Theory of Operation 289 This section outlines the envisioned usage of DRMP. 291 The expected behavior depends on the role (request sender, agent or 292 request handler) of the Diameter node handling the request. 294 The following behavior is expected during the flow of a Diameter 295 transaction. 297 1. Request sender - The sender of a request, be it a Diameter Client 298 or a Diameter Server, determines the relative priority of the 299 request and includes that priority information in the request. 300 The method for determining the relative priority is application 301 specific and is outside the scope of this specification. The 302 request sender also saves the priority information with the 303 transaction state. This will be used when handling the answer 304 messages. 306 2. Agents handing the request - Agents use the priority information 307 when making routing decisions. This can include determining 308 which requests to route first, which requests to throttle and 309 where the request is routed. For instance, requests with higher 310 priority might have a lower probability of being throttled. The 311 mechanism for how the agent determines which requests are 312 throttled is implementation dependent and is outside the scope of 313 this document. The agent also records the transaction priority 314 in the transaction state. This will be used when handling the 315 associated answer message for the transaction. 317 3. Request handler - The handler of the request, be it a Diameter 318 Server or a Diameter Client, can use the priority information to 319 determine how to handle the request. This could include 320 determining the order in which requests are handled and resources 321 that are applied to handling of the request. 323 4. Answer sender - The handler of the request is also the sender of 324 the answer. The answer sender uses the priority information 325 received in the request message when sending the answer. This 326 implies that answers for higher priority transactions are given 327 preferential treatment to lower priority transactions. 329 5. Agent handling the answer - Agents handling answer messages use 330 the priority information stored with the transaction state to 331 determine the priority of relaying the answer message. This 332 implies that answers for higher priority transactions are given 333 preferential treatment to lower priority transactions. 335 6. Answer handler - The handler of the answer message uses the 336 priority of the transaction when allocating resources for 337 processing that occurs after the receipt of the answer message. 339 7. Normative Behavior 341 This section contains the normative behavior associated with Diameter 342 Resource Message Priority (DRMP). 344 When routing priority information is availble, Diameter nodes SHOULD 345 include Diameter routing message priority in all Diameter request 346 messages. 348 Note: The method of determining the priority value included in the 349 request is application specific and is not in the scope of this 350 specification. 352 The priority marking scheme SHOULD NOT require the Diameter Agents to 353 understand application specific AVPs. 355 When routing priority information is availble, Diameter nodes SHOULD 356 use DRMP information when making Diameter overload related throttling 357 decisions. 359 Diameter agents MAY use DRMP information when relaying messages. 360 This includes the selection of routes and the ordering of messages 361 relayed. 363 The priority information included applies to both the request 364 message and answer message associated with the transaction. As 365 such it is used in the processing of both types of messages. 367 Diameter endpoints MAY use DRMP information when making resource 368 allocation decisions for the transaction associated with the request 369 message that contains the DRMP information. 371 Diameter endpoints MAY use DRMP information when making resource 372 allocation decisions for the transaction associated with the answer 373 messages using the DRMP information associated with the transaction. 375 When there is a mix of transactions specifying priority in request 376 messages and transactions that do not have the priority specified, 377 transactions that do not have a specified priority SHOULD be treated 378 as having the PRIORITY_0 priority. 380 When setting and using priorities, PRIORITY_0 MUST be treated as the 381 lowest priority. 383 When setting and using priorities, PRIORITY_1 MUST be treated as a 384 higher priority than PRIORITY_0 and a lower priority than PRIORITY_2. 386 When setting and using priorities, PRIORITY_2 MUST be treated as a 387 higher priority than PRIORITY_1 and a lower priority than PRIORITY_3. 389 When setting and using priorities, PRIORITY_3 MUST be treated as a 390 higher priority than PRIORITY_2 and a lower priority than PRIORITY_4. 392 When setting and using priorities, PRIORITY_4 MUST be the highest 393 priority. 395 Editor's note: It is likely that there are other considerations 396 for setting and using priorities. For instance, it might be good 397 to use priority 1 to indicate elevated priority for strictly 398 protocol reasons (e.g.; the S6a use case). Priorities 3, 4 and 5 399 would then be used for non protocol reasons. 401 8. Attribute Value Pairs 403 This section describes the encoding and semantics of the Diameter 404 Overload Indication Attribute Value Pairs (AVPs) defined in this 405 document. 407 8.1. DRMP AVP 409 The DRMP (AVP code TBD1) is of type Enumerated. The value of the AVP 410 indicates the routing message priority for the transaction. The 411 following values are initially defined: 413 PRIORITY_0 0 Priority 0 is the lowest priority. 415 PRIORITY_1 1 Priority 1 is the second lowest priority. 417 PRIORITY_2 2 Priority 2 is the middle priority. 419 PRIORITY_3 3 Priority 3 is the second higest priority. 421 PRIORITY_4 4 Priority 4 is the higest priority. 423 8.2. Attribute Value Pair flag rules 424 +---------+ 425 |AVP flag | 426 |rules | 427 +----+----+ 428 AVP Section | |MUST| 429 Attribute Name Code Defined Value Type |MUST| NOT| 430 +--------------------------------------------------+----+----+ 431 |DRMP TBD1 8.1 Grouped | | V | 432 +--------------------------------------------------+----+----+ 434 9. IANA Considerations 436 9.1. AVP codes 438 New AVPs defined by this specification are listed in Section 8. All 439 AVP codes are allocated from the 'Authentication, Authorization, and 440 Accounting (AAA) Parameters' AVP Codes registry. 442 9.2. New registries 444 There are no new IANA registries introduced by this document. 446 Editor's Note: The current assumption is that there is no need to 447 extend the number of priorities beyond the five defined in this 448 specification. This assumption needs to be verified. If there is 449 the need for extensability then a new IANA registry would be 450 required. This new registry would be established as part of the 451 standardization effort associated with the definition of new 452 priority values. 454 10. Security Considerations 456 The DRMP could be used to get better access to services. This could 457 result in one segment of a Diameter network limiting service to 458 another segment of a Diameter network. 460 11. Contributors 462 The following people contributed substantial ideas, feedback, and 463 discussion to this document: 465 o Janet P. Gunn 467 12. References 469 12.1. Normative References 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997. 474 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 475 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 476 May 2008. 478 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 479 "Diameter Base Protocol", RFC 6733, October 2012. 481 12.2. Informative References 483 [I-D.ietf-dime-ovli] 484 Korhonen, J., Donovan, S., Campbell, B., and L. Morand, 485 "Diameter Overload Indication Conveyance", draft-ietf- 486 dime-ovli-08 (work in progress), February 2015. 488 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 489 Priority for the Session Initiation Protocol (SIP)", RFC 490 4412, February 2006. 492 [S6a] 3GPP, "Evolved Packet System (EPS); Mobility Management 493 Entity (MME) and Serving GPRS Support Node (SGSN) related 494 interfaces based on Diameter protocol", 3GPP TS 29.272 495 10.8.0, June 2013. 497 Appendix A. Design Considerations and Questions 499 This section contains a list of questions that will influence the 500 design of the DRMP mechanism. It is expected that this section will 501 be removed once the DRMP mechanism is defined. 503 A.1. Relationship with SIP Resource Priority 505 Question 1: Is there value with aligning the Diameter Routing Message 506 Priority design with the SIP Resource Priority [RFC4412]work? 508 Current thoughts: SIP Resource Priority is considered to be 509 addressing a superset of the requirements that DRMP addresses. The 510 concensus seems to be that there is no need for multiple name spaces 511 with DRMP. 513 Question 2: If so, is there value in reusing the existing SIP 514 Resource Priority name spaces and request handling strategies? 515 Current thoughts: Given that the direction for DRMP is to have a 516 single set of priority values, DRMP will not reuse name spaces. 518 A.2. Priority Encoding Method 520 Question 3: Is there a preference for handling DRMP by introducing 521 AVPs or by using existing bits in the Diameter Command Flags field? 523 Current thoughts: The advantage of using bits in the Command Flags 524 field is that it would reduce parsing overhead for elements that need 525 access to the routing priority information. The question is whether 526 this optimization in parsing overhead is worth the expense of using 527 the reserved bits. 529 There are four bits remaining in the Command Flags header. If this 530 approach is taken then the expectation would be that three of the 531 bits would be used, allowing for eight priority levels. 533 This approach has questionable utility if multiple namespaces are to 534 be used as the namespace identity would still require an AVP. Once 535 the requirement for parsing the namespace AVP is introduced the 536 incremental savings from utilizing the Command Flags would be 537 minimal. 539 The current direction is to use AVPs to communicate priority. This 540 gives the ability to extend the DRMP mechanism if additional 541 functionality, such as name spaces, is determined to be required. 543 A.3. Base Protocol versus Application Extension 545 Question 4: Should DRMP be base protocol behavior or should Diameter 546 applications be required to explicitly incorporate DRMP behavior? 548 The direction is to make the behavior generic across all 549 applications. 551 A.4. Scope of Priority Setting 553 Question 5: Which of the following does the DRMP priority apply to: 555 Messages - meaning that a separate priority can be set for request 556 messages and answer messages? 558 Transactions - meaning that the priority set in the request 559 message also applies to the answer messages? 561 Request messages - meaning that answer message priority always has 562 an implied higher priority than all request messages? 564 Current thoughts: The consensus is to have the DRMP priority apply to 565 transactions. 567 Author's Address 569 Steve Donovan 570 Oracle 571 7460 Warren Parkway 572 Frisco, Texas 75034 573 United States 575 Email: srdonovan@usdonovans.com