idnits 2.17.1 draft-roach-dime-overload-ctrl-00.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 (October 2, 2012) is 4223 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) == Outdated reference: A later version (-13) exists of draft-ietf-dime-overload-reqs-00 ** Downref: Normative reference to an Informational draft: draft-ietf-dime-overload-reqs (ref. 'I-D.ietf-dime-overload-reqs') == Outdated reference: A later version (-15) exists of draft-ietf-soc-overload-control-09 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DIME A. B. Roach 3 Internet-Draft Tekelec 4 Intended status: Standards Track October 2, 2012 5 Expires: April 5, 2013 7 A Mechanism for Diameter Overload Control 8 draft-roach-dime-overload-ctrl-00 10 Abstract 12 When a Diameter server or agent becomes overloaded, it needs to be 13 able to gracefully reduce its load, typically by informing clients to 14 reduce or stop sending traffic for some period of time. Otherwise, 15 it must continue to expend resources parsing and responding to 16 Diameter messages. 18 This document proposes a concrete, application-independent mechanism 19 to address the challenge of communicating load and overload state 20 among Diameter peers, and specifies an algorithm for load abatement 21 to address such overload conditions as they occur. The load 22 abatement algorithm is extensible, allowing for future documents to 23 define additional load abatement approaches. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 5, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Mechanism Properties . . . . . . . . . . . . . . . . . . . 4 61 1.2. Overview of Operation . . . . . . . . . . . . . . . . . . 6 62 1.3. Documentation Conventions . . . . . . . . . . . . . . . . 6 63 2. Overload Scopes . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.1. Scope Descriptions . . . . . . . . . . . . . . . . . . . . 7 65 2.2. Combining Scopes . . . . . . . . . . . . . . . . . . . . . 8 66 3. Diameter Node Behavior . . . . . . . . . . . . . . . . . . . . 9 67 3.1. Connection Establishment Procedures . . . . . . . . . . . 9 68 3.2. Diameter Client and Diameter Server Behavior . . . . . . . 11 69 3.2.1. Sending a Request . . . . . . . . . . . . . . . . . . 11 70 3.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 13 71 3.2.3. Sending an Answer . . . . . . . . . . . . . . . . . . 14 72 3.2.4. Receiving an Answer . . . . . . . . . . . . . . . . . 15 73 3.3. Diameter Agent Behavior . . . . . . . . . . . . . . . . . 15 74 3.3.1. Proxying a Request . . . . . . . . . . . . . . . . . . 15 75 3.3.2. Proxying an Answer . . . . . . . . . . . . . . . . . . 16 76 3.4. Proactive Load and Overload Communication . . . . . . . . 16 77 3.5. Load Processing . . . . . . . . . . . . . . . . . . . . . 16 78 3.5.1. Sending Load Information . . . . . . . . . . . . . . . 17 79 3.5.2. Receiving Load Information . . . . . . . . . . . . . . 18 80 3.6. Session Establishment for Session Groups . . . . . . . . . 19 81 3.6.1. Session Group Concepts . . . . . . . . . . . . . . . . 19 82 3.6.2. Session Group Procedures . . . . . . . . . . . . . . . 21 83 4. Loss-Based Overload Control Algorithm . . . . . . . . . . . . 21 84 4.1. Overload-Metric values for the 'Loss' Algorithm . . . . . 22 85 4.2. Example Implementation . . . . . . . . . . . . . . . . . . 22 86 5. Diameter AVPs for Overload . . . . . . . . . . . . . . . . . . 26 87 5.1. Load-Info AVP . . . . . . . . . . . . . . . . . . . . . . 27 88 5.2. Supported-Scopes AVP . . . . . . . . . . . . . . . . . . . 27 89 5.3. Overload-Algorithm AVP . . . . . . . . . . . . . . . . . . 28 90 5.4. Overload-Info-Scope AVP . . . . . . . . . . . . . . . . . 28 91 5.4.1. Realm Scope . . . . . . . . . . . . . . . . . . . . . 29 92 5.4.2. Application-ID Scope . . . . . . . . . . . . . . . . . 30 93 5.4.3. Host Scope . . . . . . . . . . . . . . . . . . . . . . 30 94 5.4.4. Session Scope . . . . . . . . . . . . . . . . . . . . 30 95 5.4.5. Connection Scope . . . . . . . . . . . . . . . . . . . 30 96 5.4.6. Session Group Scope . . . . . . . . . . . . . . . . . 30 97 5.5. Overload-Metric AVP . . . . . . . . . . . . . . . . . . . 31 98 5.6. Period-Of-Validity AVP . . . . . . . . . . . . . . . . . . 31 99 5.7. Session-Group AVP . . . . . . . . . . . . . . . . . . . . 31 100 5.8. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . . 31 101 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 103 7.1. New Diameter AVPs . . . . . . . . . . . . . . . . . . . . 32 104 7.2. New Diameter Disconnect-Cause . . . . . . . . . . . . . . 32 105 7.3. New Diameter Response Code . . . . . . . . . . . . . . . . 33 106 7.4. New Command Flag . . . . . . . . . . . . . . . . . . . . . 33 107 7.5. Overload Algorithm Registry . . . . . . . . . . . . . . . 33 108 7.6. Overload Scope Registry . . . . . . . . . . . . . . . . . 33 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 110 8.1. Normative References . . . . . . . . . . . . . . . . . . . 34 111 8.2. Informative References . . . . . . . . . . . . . . . . . . 34 112 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 113 Appendix B. Requirements Analysis . . . . . . . . . . . . . . . . 34 114 Appendix C. Extending the Overload Mechanism . . . . . . . . . . 35 115 C.1. New Algorithms . . . . . . . . . . . . . . . . . . . . . . 35 116 C.2. New Scopes . . . . . . . . . . . . . . . . . . . . . . . . 35 117 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 119 1. Introduction 121 When a Diameter [I-D.ietf-dime-rfc3588bis] server or agent becomes 122 overloaded, it needs to be able to gracefully reduce its load, 123 typically by informing clients to reduce or stop sending traffic for 124 some period of time. Otherwise, it must continue to expend resources 125 parsing and responding to Diameter messages. 127 This document defines a mechanism for communicating the load and 128 overload information among Diameter nodes. It also defines a base 129 algorithm for shedding traffic under overload circumstances. The 130 design of the mechanism described in this document allows for the 131 definition of alternate load abatement algorithms as well. 133 The mechanism proposed in this document is heavily influenced by the 134 work performed in the IETF Session Initiation Protocol (SIP) Overload 135 Control Working Group, and draws on the conclusions reached by that 136 working group after extensive network modeling. 138 The solution described in this document is intended to satisfy the 139 requirements described in [I-D.ietf-dime-overload-reqs], with the 140 exception of REQ 35. As discussed in that document, the intention of 141 a Diameter overload mechanism is to handle overload of the actual 142 message processing portions of Diameter servers. This is in contrast 143 to congestion, which is the inability of the underlying switching and 144 routing fabric of the network to carry the volume of traffic at the 145 volume that IP hosts wish to send it. Handling of congestion is 146 relegated to the underlying transport protocol (TCP or SCTP), and 147 will not be discussed. 149 Philosophically, the approach in designing this mechanism is based on 150 the prospect that building a base-level, fully compliant 151 implementation should be a very simple and straightforward exercise. 152 However, the protocol includes many additional features that may be 153 implemented to allow Diameter nodes to apply increasingly 154 sophisticated behaviors. This approach gives implementors the 155 freedom to implement as sophisticated a scheme as they desire, while 156 freeing them from the burden of unnecessary complexity. By doing so, 157 the mechanism allows for the rapid development and deployment of the 158 mechanism followed by a period of steady and gradual improvements as 159 implementations become more capable. 161 1.1. Mechanism Properties 163 The core Diameter overload mechanism described in this document is 164 fundamentally hop-by-hop. The rationale for using a hop-by-hop 165 approach is the same as is described in section 5.1 of [RFC6357]. 166 However, due to the fact that Diameter networks frequently have 167 traffic that is easily grouped into a few well-defined categories, we 168 have added some concepts that allow Diameter agents to push back on 169 subsets of traffic that correspond to certain well-defined and 170 client-visible constructs (such as Destination-Host, Destination- 171 Realm, and Application-ID). These constructs are termed "Scopes" in 172 this document. A more complete discussion of Scopes is found in 173 Section 2. 175 The key information transmitted between Diameter peers is the current 176 server load (to allow for better balancing of traffic, so as to 177 preempt overload in the first place) as well as an indication of 178 overload state and severity (overload information). The actual load 179 and overload information is conveyed as a new compound AVP, added to 180 any Diameter messages that allow for extensibility. As discussed in 181 section 3.2 of [I-D.ietf-dime-rfc3588bis], all CCFs are encouraged to 182 include AVP-level extensibility by inclusion of a "* [ AVP ]" 183 construct in their syntax definition. The document author has 184 conducted an extensive (although admittedly not exhaustive) audit of 185 existing applications, and found none lacking this property. The 186 inclusion of load and overload information in existing messages has 187 the property that the frequency with which information can be 188 exchanged increases as load on the system goes up. 190 For the purpose of grouping the several different parts of load 191 information together, this mechanism makes use of a Grouped AVP, 192 called "Load-Info". The Load-Info AVP may appear one or more times 193 in any extensible command, with the restriction that each instance of 194 the Load-Info AVP must contain different Scopes. 196 Load and overload information can be conveyed during times of inter- 197 node quiescence through the use of DWR/DWA exchanges. These 198 exchanges can also be used to proactively change the overload or load 199 level of a server when no other transaction is ready to be sent. 200 Finally, in the unlikely event that an application is defined that 201 precludes the inclusion of new AVPs in its commands, DWR/DWA 202 exchanges can be sent at any rate acceptable to the server in order 203 to convey load and overload information. 205 In [RFC3588], the DWR and DWA message syntax did not allow for the 206 addition of new AVPs in the DWR and DWA messages. This oversight 207 was fixed in [I-D.ietf-dime-rfc3588bis]. To allow for 208 transmission of load information on quiescent links, 209 implementations of the mechanism described in this document are 210 expected to correctly handle extension AVPs in DWR and DWA 211 messages, even if such implementations have not otherwise been 212 upgraded to support [I-D.ietf-dime-rfc3588bis]. 214 1.2. Overview of Operation 216 During the capabilities exchange phase of connection establishment, 217 peers determine whether the connection will make use of the overload 218 control mechanism; and, if so, which optional behaviors are to be 219 employed. 221 The information sent between adjacent nodes includes two key metrics: 222 Load (which, roughly speaking, provides a linear metric of how busy 223 the node is), and Overload-Metric (which is input to the negotiated 224 load abatement algorithm). 226 Message originators (whether originating a request or an answer) 227 include one or more Load-Info AVPs in messages when they form them. 228 These Load-Info AVPs reflect the originators' own load and overload 229 state. 231 Because information is being used on a hop-by-hop basis, it is 232 exchanged only between adjacent nodes. This means that any Diameter 233 agent that forwards a message (request or answer) is required to 234 remove any information received from the previous hop, and act upon 235 it as necessary. Agents also add their own load and overload 236 information (which may, at implementors' preference, take previous- 237 hop information into account) into a new Load-Info AVP before sending 238 the request or answer along. 240 Because the mechanism requires affirmative indication of support 241 in the capabilities exchange phase of connection establishment, 242 load and overload information will never be sent to intermediaries 243 that do not support the overload mechanism. Therefore, no special 244 provisions need to be made for removal of information at such 245 intermediaries -- it will simply not be sent to them. 247 Message recipients are responsible for reading and acting upon load 248 and overload information that they receive in such messages. 250 1.3. Documentation Conventions 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 254 document are to be interpreted as described in [RFC2119]. 256 2. Overload Scopes 258 In normal operation, a Diameter node may be overloaded for some but 259 not all possible requests. For example, an agent that supports two 260 realms (realm A and realm B in this example) may route traffic to one 261 set of servers for realm A, and another set of servers for realm B. 262 If the realm A servers are overloaded but realm B servers are not, 263 then the agent is effectively overloaded for realm A but not for 264 realm B. 266 Despite the fact that Diameter agents can report on scopes that 267 semantically map to constructs elsewhere in the network, it is 268 important to keep in mind that overload state is still reported on a 269 hop-by-hop basis. In other words, the overload state reported for 270 realm A in the example above represents the aggregate of the agent's 271 overload state along with the overload state being reported by 272 applicable upstream servers (those serving realm A). 274 Even without the use of Diameter agents, similar situations may arise 275 in servers that need to make use of external resources for certain 276 applications but not for others. For example, if a single server is 277 handling two applications, one of which uses an external database 278 while the other does not, it may become overloaded for the 279 application that uses the external database when the database 280 response latency increases. 282 The indication of scopes for overload information (using the 283 Overload-Info-Scope AVP; see Section 5.4) allows a node to indicate a 284 subset of requests to which overload information is to be applied. 285 This document defines seven scopes, five of which are mandatory to 286 implement. The use of the two optional scopes, along with the use of 287 any additional scopes defined in other documents, is negotiated at 288 connection establishment time; see Section 3.1. 290 2.1. Scope Descriptions 292 Destination-Realm: This scope, which is mandatory to implement, 293 pertains to all transactions that have a Destination-Realm AVP 294 matching the indicated value. 296 Application-ID: This scope, which is mandatory to implement, 297 pertains to all transactions that contain an Application-ID 298 field matching the indicated value. 300 Destination-Host: This scope, which is mandatory to implement, 301 pertains to all transactions that have a Destination-Host AVP 302 matching the indicated value. 304 Host: This scope, which is mandatory to implement, pertains to all 305 transactions sent directly to the host matching the indicated 306 value. 308 Connection: This scope, which is mandatory to implement, pertains to 309 all transactions sent on the same TCP connection or SCTP 310 association. This scope has no details indicating which 311 connection or association it applies to; instead, the recipient 312 of an indication of "Connection" scope is to use the connection 313 or association on which the message was received as the 314 indicated connection or association. In other words, any use 315 of Connection scope applies to "this connection." 317 Session-Group: This scope, which is optional to implement, pertains 318 to all transactions in a session that has been assigned to the 319 indicated group. For more information on assigning sessions to 320 groups, see Section 3.6. 322 Session: This scope, which is optional to implement, pertains to all 323 transactions in the indicated session. 325 Some applications do not have long-running sessions containing 326 multiple transactions. For such applications, the use of "Session- 327 Group" and "Session" scopes do not make sense. Such applications 328 will instead make use of the most applicable of the remaining five 329 scopes (plus any negotiated extension scopes) to achieve overload 330 control. 332 OPEN ISSUE: Is there value to including a stream-level scope for 333 SCTP? We haven't been able to come up with a use case for doing so 334 yet, but it wouldn't necessarily be unreasonable. 336 2.2. Combining Scopes 338 To allow for the expression of more complicated scopes than the 339 primitives defined above, multiple Overload-Info-Scope AVPs may be 340 included in a single Load-Info AVP. Semantically, these scopes are 341 included in the following way: 343 o Attributes of the different kinds are logically and-ed together 344 (e.g., if both "Destination-Realm" and "Application-ID" are 345 present, the information applies to requests sent that match both 346 the realm and the application). 348 o Attributes of the same kind are logically or-ed together (e.g., if 349 two "Destination-Realm"s are present, the information applies to 350 requests sent to either realm). 352 o If a transaction falls within more than one scope, the "most 353 overloaded" scope is used for traffic shaping. 355 To prevent the complexity of implementing arbitrary scope combination 356 rules, only the following combinations of scopes are allowed (OPEN 357 ISSUE -- we need to figure out what makes most sense for expressing 358 these combinations. Formal grammar? Prose? A table of some kind? 359 For now, they're expressed as a pseudo-ABNF): 361 o 1*(Destination-Realm) 0*1(Application-ID) 362 o 1*(Application-ID) 0*1(Destination-Realm) 363 o 1*(Destination-Host) 364 o 1*1(Next-Hop) 365 o 1*1(Connection) 366 o 1*(Session-Group) 0*1(Next-Hop | Connection) 367 o 1*(Session) 0*1(Next-Hop | Connection) 369 OPEN ISSUE: Is this the right set of scope combinations? Is there 370 a need for more? Are any of these unnecessary? Ideally, this 371 should be the smallest set of combinations that lets nodes report 372 what they realistically need to report. 374 Any document that creates additional scopes MUST define how they may 375 be combined with all scopes registered with IANA at the time of their 376 publication. 378 3. Diameter Node Behavior 380 The following sections outline the behavior expected of Diameter 381 clients, servers, and agents that implement the overload control 382 mechanism. 384 OPEN ISSUE: SIP Overload Control includes a sequence parameter to 385 ensure that out-of-order messages do not cause the receiver to act on 386 state that is no longer accurate. Is message reordering a concern in 387 Diameter? That is, do we need to include sequence numbers in the 388 messages to ensure that the receiver does not act on stale state 389 information? Because Diameter uses only reliable, in-order 390 transports, it seems that this isn't likely to be an issue. Is there 391 room for a race when multiple connections are in use? 393 3.1. Connection Establishment Procedures 395 Negotiation for support of this mechanism is performed during 396 Diameter capabilities exchange. Optional protocol features and 397 extensions to this mechanism are also negotiated at this time. No 398 provision is provided for renegotiation of mechanism use or 399 extensions during the course of a connection. If peers wish to make 400 changes to the mechanism, they must create a new connection to do so. 402 The connection initiator includes a Load-Info AVP in the CER 403 (Capabilities-Exchange-Request) message that it sends after 404 establishing the connection. This Load-Info AVP MUST contain a 405 Supported-Scopes AVP and an Overload-Algorithm AVP. The Supported- 406 Scopes AVP indicates a comprehensive list of optional scopes 407 supported by the connection initiator. See Section 5.2 for 408 information on the format of the Supported-Scopes AVP. 410 The Load-Info AVP in a CER message also MAY contain one or more 411 Overload-Algorithm AVPs. If present, these AVPs indicate every 412 Overload-Algorithm the connection initiator is willing to support for 413 the connection that is being established. If the connection 414 initiator supports only the "Loss" algorithm, it MAY indicate this 415 fact by omitting the Overload-Algorithm altogether. 417 The Load-Info AVP in a CER message MAY also contain additional AVPs, 418 as defined in other documents, for the purpose of negotiation 419 extensions to the Overload mechanism. 421 The Diameter node that receives a CER message first examines it for 422 the presence of a Load-Info AVP. If no such AVP is present, the node 423 concludes that the overload control mechanism is not supported for 424 this connection, and no further overload-related negotiation is 425 performed. If the received CER contains a Load-Info AVP, the 426 recipient of that message extracts the value of the Supported-Scopes 427 AVP, performs a logical intersection (bit-wise and) between the 428 indicated scopes with its own supported scopes, and stores that 429 information locally in the context of the connection being 430 established. It then examines the Overload-Algorithm AVPs, if 431 present, and selects a single algorithm from that list. If no 432 Overload-Algorithm is indicated, then the base "Loss" algorithm is 433 used for the connection. In either case, the recipient of the CER 434 stores this algorithm in the context of the connection. 436 When a node conformant to this specification sends a Capabilities- 437 Exchange-Answer (CEA) message in answer to a CER that contained a 438 Load-Info AVP, the CEA MUST contain a Load-Info AVP. This Load-Info 439 AVP MUST contain a Supported-Scopes AVP that indicates the scopes to 440 be used for this connection (which is the same set stored in the 441 paragraph above). The CEA also contains zero or one Overload- 442 Algorithm AVPs. If present, this Overload-Algorithm MUST match one 443 of the Overload-Algorithm AVPs sent in the CER, and it indicates the 444 overload control algorithm that will be used for the connection. If 445 the CEA contains no Overload-Algorithm, the connection will use the 446 "Loss" algorithm. 448 When a node receives a CEA message, it examines it for the presence 449 of a Load-Info AVP. If no such AVP is present, the node concludes 450 that the overload mechanism is not supported for this connection. If 451 the received CEA contains a Load-Info AVP, then the recipient 452 extracts the Supported-Scopes information, and stores them locally in 453 the context of the connection being established. It then checks for 454 the presence of an Overload-Algorithm AVP. If present, this AVP 455 indicates the overload control algorithm that will be used for the 456 connection. If absent, then the connection will use the "Loss" 457 algorithm. 459 If a node receives a CEA message that indicates support for a scope 460 that it did not indicate in its CER or which selects an overload 461 control algorithm that it did not advertise in its CER, then it MUST 462 terminate the connection by sending a DPR with a Disconnect-Cause of 463 NEGOTIATION_FAILURE, (128 [actual value TBD]) indicating that the CEA 464 sender has failed to properly follow the negotiation process 465 described above. 467 3.2. Diameter Client and Diameter Server Behavior 469 The following sections describe the behavior that Diameter clients 470 and Diameter servers implement for the overload control mechanism. 471 Behavior at Diameter Agents is described in Section 3.3. 473 To implement overload control, Diameter nodes need to keep track of 474 three important metrics for each of the scopes for which information 475 has been received: the overload metric for the scope, the period of 476 validity for that overload metric, and the load within that scope. 477 Conceptually, these are data records indexed by the scope to which 478 they apply. In the following sections, we refer to these data 479 records with the term "scope entry." Further, when it is necessary 480 to distinguish between those scope entries referring to the load 481 information received from other nodes and those referring to the load 482 information sent to other nodes, we use the term "remote scope entry" 483 to refer to the information received from other nodes, and "local 484 scope entry" to refer to that information that is being maintained to 485 send to other nodes. 487 In order to allow recipients of overload information to perform 488 certain performance optimizations, we also define a new command flag, 489 called 'O'verload. This bit, when set, indicates that the message 490 contains at least one Load-Info AVP with a non-zero Overload-Metric 491 -- in other words, the sending node is overloaded for at least one 492 context. See Section 7.4 for the definition of the 'O'verload bit. 494 3.2.1. Sending a Request 496 This section applies only to those requests sent to peers who 497 negotiated use of the overload control mechanism during capabilities 498 exchange. Requests sent over other connections are handled the same 499 as they would in the absence of the overload control mechanism. 501 Before sending a request, a Diameter node must first determine which 502 scope applies. It does this as follows: first, a next hop host and 503 connection are determined, according to normal Diameter procedures 504 (potentially modified as described in Section 3.5.2). The sending 505 node then searches through its list of remote scope entries (ignoring 506 any whose Period-of-Validity has expired) to determine which ones 507 match the combination of the fields in the current request, the next- 508 hop host, and the selected connection. If none of the matching scope 509 entries are in overload, then the message is handled normally, and no 510 additional processing is required. 512 As an optimization, a sending node MAY choose to track whether any of 513 its peers are in overload, and to skip the preceding step if it knows 514 that no scopes are in overload. 516 If one or more matching scope entries are in overload, then the 517 sending node determines which scope is most overloaded. The sending 518 node then sends, drops, queues, or otherwise modifies handling of the 519 request according to the negotiated overload control algorithm, using 520 the Overload-Metric from the selected scope entry as input to the 521 algorithm. 523 When determining which requests are impacted by the overload control 524 algorithm, request senders MAY take into account the type of message 525 being sent and its contents. For example, messages within an 526 existing session may be prioritized over those that create a new 527 session. The exact rules for such prioritization will likely vary 528 from application to application. The authors expect that 529 specifications that define or specify the use of specific Diameter 530 Applications may choose to formally define a set of rules for such 531 prioritization on a per-Application basis. 533 The foregoing notwithstanding, senders MUST NOT use the content or 534 type of request to exempt that request from overload handling. For 535 example, if a peer requests a 50% decrease in sent traffic using the 536 "Loss" algorithm (see Section 4), but the traffic that the sending 537 node wishes to send consists 65% of traffic that the sender considers 538 critical, then the sender is nonetheless obliged to drop some portion 539 of that critical traffic (e.g., it may elect to drop all non-critical 540 traffic and 23% of the critical traffic, resulting in an overall 50% 541 reduction). 543 The sending node then inserts one or more Load-Info AVPs (see 544 Section 5.1) into the request. If the sender inserts more than one 545 Load-Info AVP, then each Load-Info AVP MUST contain a unique scope, 546 as specified by the Overload-Scope AVP(s) inside the Load-Info AVP. 548 Each Load-Info AVP in the request MUST contain an Overload-Metric 549 (see Section 5.5), indicating whether (and to what degree) the sender 550 is overloaded for the indicated scope. If this metric is not zero, 551 then the Load-Info AVP MUST also contain a Period-Of-Validity AVP 552 (see Section 5.6), indicating the maximum period the recipient should 553 consider the Overload-Metric to be valid. Any message containing a 554 non-zero Overload-Metric also MUST set the 'O'verload bit in the 555 Command Flags field to indicate to the recipient that the message 556 contains an overload indication. See Section 7.4 for the definition 557 of the 'O'verload bit. 559 Each Load-Info AVP MUST also contain a Load AVP, indicating the 560 server's load level within the context of the indicated scope. See 561 Section 3.5.1 for details on generating this load metric. Note that 562 a server's load may frequently be identical for all the scopes for 563 which it sends information. 565 3.2.2. Receiving a Request 567 3.2.2.1. Receiving a Request from a Compliant Peer 569 A node that receives a request from a peer that has negotiated 570 support for the overload control mechanism will extract the Load-Info 571 AVPs from the request and use each of them to update its remote scope 572 entries. First, the node attempts to locate an existing scope entry 573 that corresponds to the Overload-Scope indicated in the Load-Info 574 AVP. If one does not exist, it is created. The scope entry is then 575 populated with the overload metric, period of validity, and load 576 information. The message is then processed as normal. 578 3.2.2.2. Receiving a Request from a Noncompliant Peer 580 An important aspect of the overload control mechanism is that 581 Diameter nodes that do not implement the mechanism cannot have an 582 advantage over those that do. In other words, it is necessary to 583 prevent the situation that a network in overload will cease servicing 584 those transactions from overload-compliant nodes in favor of those 585 sent by those nodes that do not implement the overload control 586 mechanism. To achieve this goal, message recipients need to track 587 the overload control metric on behalf of those sending nodes that do 588 not implement overload, and to reject messages from those nodes that 589 would have been dropped if the sender had implemented the overload 590 mechanism. 592 A node that receives a request from a peer that has not negotiated 593 support for the overload control mechanism searches through its list 594 of local scope entries to determine which ones match the combination 595 of the fields in the received request. (These are the entries that 596 indicate the Overload-Metric that the node would have sent to the 597 peer if the peer had supported the overload mechanism). If none of 598 the matching scope entries are in overload, then the message is sent 599 normally, and no additional processing is required. 601 If one or more matching local scope entries are in overload, then the 602 node determines which scope is most overloaded. The node then 603 executes the "Loss" overload control algorithm (see Section 4) using 604 the overload metric in that most overloaded scope. If the result of 605 running that algorithm determines that a sender who had implemented 606 the overload control mechanism would have dropped the message, then 607 the recipient MUST reply to the request with a 608 DIAMETER_PEER_IN_OVERLOAD response (see Section 7.3). 610 3.2.3. Sending an Answer 612 This section applies only to those answers sent to peers who 613 negotiated use of the overload control mechanism during capabilities 614 exchange. 616 When sending an answer, a Diameter node inserts one or more Load-Info 617 AVPs (see Section 5.1) into the answer. If the sender inserts more 618 than one Load-Info AVP, then each Load-Info AVP MUST contain a unique 619 scope, as specified by the Overload-Scope AVP(s) inside the Load-Info 620 AVP. 622 Each Load-Info AVP in the answer MUST contain an Overload-Metric (see 623 Section 5.5), indicating whether (and to what degree) the server is 624 overloaded for the indicated scope. If this metric is not zero, then 625 the Load-Info AVP MUST also contain a Period-Of-Validity AVP (see 626 Section 5.6), indicating the maximum period the recipient should 627 consider the Overload-Metric to be valid. Any message containing a 628 non-zero Overload-Metric also MUST set the 'O'verload bit in the 629 Command Flags field to indicate to the recipient that the message 630 contains an overload indication. See Section 7.4 for the definition 631 of the 'O'verload bit. 633 Each Load-Info AVP MUST also contain a Load AVP, indicating the 634 server's load level within the context of the indicated scope. See 635 Section 3.5.1 for details on generating this load metric. Note that 636 a server's load may frequently be identical for all the scopes for 637 which it sends information. 639 3.2.4. Receiving an Answer 641 A node that receives a answer from a peer that has negotiated support 642 for the overload control mechanism will extract the Load-Info AVPs 643 from the answer and use each of them to update its remote scope 644 entries. First, the node attempts to locate an existing scope entry 645 that corresponds to the Overload-Scope indicated in the Load-Info 646 AVP. If one does not exist, it is created. The scope entry is then 647 populated with the overload metric, period of validity, and load 648 information. The message is then processed as normal. 650 3.3. Diameter Agent Behavior 652 This section discusses the behavior of a Diameter Agent acting as a 653 Proxy or Relay. Diameter Agents that provide redirect or translation 654 services behave the same as Diameter Servers for the purpose of 655 overload control, and follow the procedures defined in Section 3.2. 657 Whenever sending a request or an answer, Agents MUST include a Load- 658 Info AVP reflecting the a Agent's overload and load information. In 659 formulating this information, the Agent may choose to use only that 660 information relating to its own local resources. However, better 661 network behavior can be achieved if agents incorporate information 662 received from their peers when generating overload information. The 663 exact means for incorporating such information is left to local 664 policy at the agent. 666 For example: consider an agent that distributes sessions and 667 transactions among three Diameter servers, each hosting a different 668 Diameter application. While it would be compliant for the Agent to 669 only report its own overload state (i.e., at "Host" scope), overall 670 network behavior would be improved if it chose to also report 671 overload state for up to three additional scopes (i.e. at 672 "Application-ID" scope), incorporating the Overload information 673 received from each server in these scopes. 675 3.3.1. Proxying a Request 677 Upon receiving a request, a Diameter Proxy or Relay performs the 678 steps detailed in Section 3.2.2. 680 The agent then MUST remove all Load-Info AVPs from the request: Load- 681 Info is never passed through a Proxy or Relay transparently. 683 When the Diameter Agent proxies or relays a request, it follows the 684 process outlined in Section 3.2.1. 686 3.3.2. Proxying an Answer 688 Upon receiving an answer, a Diameter Agent follows the process 689 described in Section 3.2.4 to update its remote scope entries. 691 The Agent then MUST remove all Load-Info AVPs from the answer: Load- 692 Info is never passed through a Proxy or Relay transparently. 694 When the Diameter Agent proxies or relays a response, it follows the 695 process outlined in Section 3.2.3. 697 3.4. Proactive Load and Overload Communication 699 Because not all Diameter links will have constant traffic, it may be 700 occasionally necessary to send overload and/or load information over 701 links that would otherwise be quiescent. To proactively send such 702 information to peers, the Diameter node with information to convey 703 may choose to send a Diameter Watchdog Request (DWR) message to its 704 peers. The procedure described in Section 3.2.1 applies to these 705 requests, which provides the means to send load and overload 706 information. 708 In order to prevent unnecessarily diminished throughput between 709 peers, a Diameter node SHOULD proactively send a DWR to all its peers 710 whenever it leaves an overload state. Similarly, in order to provide 711 peers the proper data for load distribution, nodes SHOULD send DWR 712 messages to a peer if the load information most recently sent to that 713 peer has changed by more than 20% and is more than 5 seconds old. 715 3.5. Load Processing 717 While the remainder of the mechanism described in this document is 718 aimed at handling overload situations once they occur, it is far 719 better for a system if overload can be avoided altogether. In order 720 to facilitate overload avoidance, the overload mechanism includes the 721 ability to convey node load information. 723 Semantically, the Load information sent by a Diameter node indicates 724 the current utilization of its most constrained resource. It is a 725 linear scale from 0 (least loaded) to 65535 (most loaded). 727 It is critical to distinguish between the value conveyed in the Load 728 AVP and the value conveyed in the Overload-Metric AVP. The Load AVP 729 is computed and used independent of the Overload-Algorithm selected 730 for a connection, while the Overload-Metric is meaningful only in the 731 context of the selected algorithm. Most importantly, the Load 732 information never has any impact on the behavior specified in the 733 overload algorithm. If a node reports a Load of 65535, but the 734 Overload-Metric does not indicate any need to apply the selected 735 overload control algorithm, then the sender MUST NOT apply the 736 selected overload control algorithm. Conversely, if a node is 737 reporting an Overload-Metric that requires the recipient to take 738 action to reduce traffic, those actions MUST be taken, even if the 739 node is simultaneously reporting a Load value of 0. 741 3.5.1. Sending Load Information 743 Diameter nodes implementing the overload mechanism described in this 744 document MUST include a Load AVP (inside a Load-Info AVP) in every 745 Diameter message (request and answer) they send over a connection 746 that has been negotiated to use the overload control mechanism. Note 747 that this requirement does not necessitate calculation of the Load 748 metric each time a message is sent; the Load value may be calculated 749 periodically (e.g., every 100 ms), and used for every message sent 750 until it is recalculated. 752 The algorithm for generation of the load metric is a matter of local 753 policy at the Diameter node, and may vary widely based on the 754 internal software architecture of that node. 756 For advanced calculations of Load, anticipated inputs to the 757 computation include CPU utilization, network utilization, processor 758 interrupts, I/O throughput, and internal message queue depths. 760 To free implementors from the potential complexity of determining an 761 optimal calculation for load, we define a very simple, baseline load 762 calculation that MAY be used for the purpose of populating the Load 763 AVP. Implementations using this simplified calculation will use a 764 configured, hard-coded, or Service Level Agreement (SLA)-defined 765 maximum number of transactions per second (TPS) which a node is known 766 to be able to support without issue. These implementations simply 767 report their load as a linear representation of how much of this 768 known capacity is currently in use: 770 Load = MIN(Current_TPS * 65535 / Maximum_TPS, 65535) 772 To prevent rapid fluctuations in the load metric, nodes SHOULD report 773 a rolling average of the calculated load rather than the actual 774 instantaneous load at any given moment. 776 Load information is scoped to the level indicated by the Overload- 777 Info-Scope AVP present in the Load-Info AVP in which the Load AVP 778 appears. 780 3.5.2. Receiving Load Information 782 While sending load information is mandatory, the actual processing of 783 load information at a recipient is completely optional. Ideally, 784 recipients will use the load information as input to a decision 785 regarding which of multiple equivalent servers to use when initiating 786 a new connection. Recipients may choose to update load information 787 on receipt of every message; alternately, they may periodically 788 "sample" messages from a host to determine the load it is currently 789 reporting. 791 3.5.2.1. Example Load Handling 793 This section describes a non-normative example of how recipients can 794 use Load information received from other Diameter nodes. At a high 795 level, the concept is that received load metrics are used to scale 796 the distribution algorithm that the node uses for selection of a 797 server from a group of equivalent servers. 799 Consider a client that uses DNS to resolve a host name into IP 800 addresses. In this example, the client is attempting to reach the 801 server for the realm example.com. It performs a NAPTR query for the 802 "AAA+D2T" record for that domain, and receives a result pointing to 803 the SRV record "_diameter._tcp.example.com". Querying for this SRV 804 record, in turn, results in three entries, with the same priorities: 806 +------------+----------------------+ 807 | SRV Weight | Server Name | 808 +------------+----------------------+ 809 | 20 | server-a.example.com | 810 | 20 | server-b.example.com | 811 | 60 | server-c.example.com | 812 +------------+----------------------+ 814 The client then examines the currently reported loads for each of the 815 three servers. In this example, we are asserting that the reported 816 load metrics are as follows: 818 +-------------+----------------------+ 819 | Load | Server Name | 820 +-------------+----------------------+ 821 | 13107 (20%) | server-a.example.com | 822 | 26214 (60%) | server-b.example.com | 823 | 52428 (80%) | server-c.example.com | 824 +-------------+----------------------+ 826 Based on this load information, the client scales the SRV weights 827 proportional to each server's reported load; the general formula is: 829 new_weight = original_weight * (65535 - load) / 65535 831 The node then calculates a new set of weights for the destination 832 hosts: 834 o server-a: new_weight = 20 * (65535 - 13107) / 65535 = 16 835 o server-b: new_weight = 20 * (65535 - 26214) / 65535 = 12 836 o server-c: new_weight = 60 * (65535 - 52428) / 65535 = 12 838 These three new weights (16, 12, and 12) are then used as input to 839 the random selection process traditionally used when selecting among 840 several SRV records. 842 Note that this example is provided in the context of DNS SRV 843 processing; however, it works equally well in the case that server 844 processing weights are provisioned or made available through an 845 alternate resolution process. 847 3.6. Session Establishment for Session Groups 849 The procedure in this section applies to any Diameter operation that 850 may result in the creation of a new Diameter session. Note that 851 these operations are performed in addition to any normal message 852 processing, and in addition to the operations described in the 853 following sections. 855 3.6.1. Session Group Concepts 857 At the time a session is established, the server and/or the client 858 may choose to assign the newly created session to a Session Group 859 that they can use to refer to the session (and other sessions in the 860 same group) in later overload-related messages. This grouping is 861 intended to be used by servers that have visibility into resources 862 that may be independently overloaded, but which do not correspond to 863 an existing Diameter construct (such as Application, Realm, or 864 Destination Server). 866 One example of a server having visibility into resources that don't 867 have a corresponding Diameter construct is a Diameter Agent servicing 868 a mixed community of users -- say, one authenticated by a "Business" 869 server, and another authenticated by a "Residential" server. The 870 client in this network does not know which group any given session 871 belongs in; the routing of sessions is based on information available 872 only to the agent. 874 +-------------+ +-------------+ 875 | | | | 876 | Server A | | Server B | 877 | (Business) | |(Residential)| 878 | | | | 879 +-------------+ +-------------+ 880 `. ,' 881 `. ,' 882 `. ,' 883 +-----+---+-----+ 884 | | 885 | Agent | 886 | | 887 +---------------+ 888 ^ 889 | 890 +-------+-------+ 891 | | 892 | Client | 893 | | 894 +---------------+ 896 In this case, the Agent may wish to assign sessions to two client- 897 visible Session Groups when the session is established. By doing so, 898 the Agent gains the ability to report Load and Overload metrics to 899 the Client independently for the two classes of users. This can be 900 extremely helpful, for example, in allowing the Agent to ask the 901 Client to throttle traffic for the Residential server when it becomes 902 overload, without impacting sessions pertaining to the Business 903 server. 905 Similar situations can arise even without the presence of Diameter 906 Agents in the network: a server may have a class of sessions that 907 require access to an off-board database (which can, itself, become 908 overloaded), while also servicing a class of sessions that is handled 909 entirely by a local authentication table. The server can use Session 910 Groups to assign these two classes of sessions to different groups, 911 and report overload on the class using the (overloaded) off-board 912 database without impacting the other sessions. 914 In some applications, it is possible to have the session established 915 by one peer (e.g., in the upstream direction), while some subsequent 916 in-session transactions are initiated by the other peer (e.g., in the 917 downstream direction). Because of this possibility, the overload 918 mechanism allows both peers to establish a Session Group at the time 919 the session is set up. The session identifiers are scoped to the 920 node that sends them. In other words, if a server assigns a session 921 to a group called "Residential", this group is not related to a 922 client group (if any) by the same name. For clarity, this document 923 will refer to the session group assigned by the server performing the 924 processing as a "local session group," and the session group assigned 925 by the remote node as a "remote session group." 927 Nodes that send a session-creating request follow normal Diameter 928 procedures, along with the additional behavior described in 929 Section 3.2.1 and Section 3.3.1, as appropriate. Such nodes may also 930 assign the session to a Session Group, as long as the peer to which 931 they are communicating indicated support for the "Session-Group" 932 scope during capabilities exchange. Whether to do so and what group 933 to assign a session to is done according to local policy. To perform 934 such assignment, the node will include a Session-Group AVP (see 935 Section 5.7 in the Load-Info AVP for the session creating request. 936 These nodes also store the assigned name as the session's local 937 session group. 939 3.6.2. Session Group Procedures 941 The procedures in this section only apply on connections for which 942 support for the "Session-Group" scope has been negotiated during 943 capabilities exchange. See Section 3.1. 945 When a node receives a session creating request, it MUST check that 946 request for the presence for a Session-Group AVP in its Load-Info 947 AVP. If one is present, it stores that session group name as the 948 remote session group name for that server. This allows clients to 949 assign the session to a group, allowing it to indicate overload for 950 server-initiated transactions in the resulting session. 952 When a node replies to a session creating request, it can choose to 953 assign the newly-established session to a session group. Whether it 954 chooses to do so is independent of whether the remote node assigned 955 the session to a session group. To perform such an assignment, the 956 node includes a Session-Group AVP in the Load-Info AVP sent in answer 957 to the session-creating request. These nodes also store the assigned 958 name as the session's local session group. 960 Finally, when a node that has sent a session-creating request 961 receives a corresponding answer message, it MUST check that answer 962 for the presence of a Session-Group AVP in its Load-Info AVP. If one 963 is present, it stores that session group name as the remote session 964 group name for that server. 966 4. Loss-Based Overload Control Algorithm 968 This section describes a baseline, mandatory-to-implement overload 969 control algorithm, identified by the indicator "Loss". This 970 algorithm allows a Diameter peer to ask its peers to reduce the 971 number of requests they would ordinarily send by a specified 972 percentage. For example, if a peer requests of another peer that it 973 reduce the traffic it is sending by 10%, then that peer will 974 redirect, reject, or treat as failed, 10% of the traffic that would 975 have otherwise been sent to this Diameter node. 977 4.1. Overload-Metric values for the 'Loss' Algorithm 979 A Diameter node entering the overload state for any of the scopes 980 that it uses with its peers will calculate a value for its Overload 981 Metric, in the range of 0 to 100 (inclusive). This value indicates 982 the percentage traffic reduction the Diameter node wishes its peers 983 to implement. The computation of the exact value for this parameter 984 is left as an implementation choice at the sending node. It is 985 acceptable for implementations to request different levels of traffic 986 reduction to different peers according to local policy at the 987 Diameter node. These Overload Metrics are then communicated to peers 988 using the Overload-Metric AVP in requests and answers sent by this 989 node. 991 Recipients of Overload-Metric AVPs on connections for which the 992 "Loss" algorithm has been specified MUST reduce the number of 993 requests sent in the corresponding scope by that percentage, either 994 by redirecting them to an alternate destination, or by failing the 995 request. For a Diameter Agent, these failures are indicated to the 996 peer who originated the request by sending a 997 DIAMETER_PEER_IN_OVERLOAD response (see Section 7.3). For diameter 998 clients, these failures cause the client to behave as if they 999 received a transient error in response to the request. 1001 It is acceptable, when implementing the "Loss" algorithm, for the 1002 reduction in transactions to make use of a statistical loss function 1003 (e.g., random assignment of transactions into "success" and "failure" 1004 categories based on the indicated percentage). In such a case, the 1005 actual traffic reduction might vary slightly from the percentage 1006 indicated, albeit in an insignificant amount. 1008 4.2. Example Implementation 1010 The exact means a client uses to implement the requirement that it 1011 reduce traffic by a requested percentage is left to the discretion of 1012 the implementor. However, to aid in understanding the nature of such 1013 an implementation, we present an example of a valid implementation in 1014 pseudo-code. 1016 In this example, we consider that the sending node maintains two 1017 classes of request. The first category are considered of lower 1018 priority than the second category. If a reduction in traffic is 1019 required, then these lower priority requests will be dropped before 1020 any of the higher priority requests are dropped. 1022 The sending Diameter node determines the mix of requests falling into 1023 the first category, and those falling into the second category. For 1024 example, 40% of the requests may be in the lower-priority category, 1025 while 60% are in the higher-priority category. 1027 When a node receives an overload indication from one of its peers, it 1028 converts the Overload-Metric value to a value that applies to the 1029 first category of requests. For example, if the Overload-Metric for 1030 the applicable context is "10", and 40% of the requests are in the 1031 lower-priority category, then: 1033 10 / 40 * 100 = 25 1035 Or 25% of the requests in the first category can be dropped, with an 1036 overall reduction in sent traffic of 10%. The sender then drops 25% 1037 of all category 1 requests. This can be done stochastically, by 1038 selecting a random number for each sent packet between 1 to 100 1039 (inclusive), and dropping any packet for which the resulting 1040 percentage is equal to or less than 25. In this set of 1041 circumstances, messages in the second category do not require any 1042 reduction to meet the requirement of 25% traffic reduction. 1044 A reference algorithm is shown below, using pseudo-code. 1046 cat1 := 80.0 // Category 1 --- subject to reduction 1047 cat2 := 100.0 - cat1 // Category 2 --- Under normal operations 1048 // only subject to reduction after category 1 is exhausted. 1049 // Note that the above ratio is simply a reasonable default. 1050 // The actual values will change through periodic sampling 1051 // as the traffic mix changes over time. 1053 while (true) { 1054 // We're modeling message processing as a single work queue 1055 // that contains both incoming and outgoing messages. 1056 msg := get_next_message_from_work_queue() 1058 update_mix(cat1, cat2) // See Note below 1060 switch (msg.type) { 1062 case outbound request: 1063 destination := get_next_hop(msg) 1064 oc_context := get_oc_scope(destination,msg) 1065 if (we are in overload) { 1066 add_overload_avps(msg) 1067 } 1069 if (oc_context == null) { 1070 send_to_network(msg) // Process it normally by sending the 1071 // request to the next hop since this particular 1072 // destination is not subject to overload 1073 } 1074 else { 1075 // Determine if server wants to enter in overload or is in 1076 // overload 1077 in_oc := extract_in_oc(oc_context) 1079 oc_value := extract_oc(oc_context) 1080 oc_validity := extract_oc_validity(oc_context) 1082 if (in_oc == false or oc_validity is not in effect) { 1083 send_to_network(msg) // Process it normally by sending 1084 // the request to the next hop since this particular 1085 // destination is not subject to overload. Optionally, 1086 // clear the oc context for this server (not shown). 1087 } 1088 else { // Begin perform overload control 1089 r := random() 1090 drop_msg := false 1092 if (cat1 >= cat2) { 1093 category := assign_msg_to_category(msg) 1094 pct_to_reduce_cat2 := 0 1095 pct_to_reduce_cat1 := oc_value / cat1 * 100 1096 if (pct_to_reduce_cat1 > 100) { 1097 // Get remaining messages from category 2 1098 pct_to_reduce_cat2 := 100 - pct_to_reduce_cat1 1099 pct_to_reduce_cat1 := 100 1100 } 1102 if (category == cat1) { 1103 if (r <= pct_to_reduce_cat1) { 1104 drop_msg := true 1105 } 1106 } 1107 else { // Message from category 2 1108 if (r <= pct_to_reduce_cat2) { 1109 drop_msg := true 1110 } 1111 } 1112 } 1113 else { // More category 2 messages than category 1; 1114 // indicative of an emergency situation. Since 1115 // there are more category 2 messages, don't 1116 // bother distinguishing between category 1 or 1117 // 2 --- treat them equal (for simplicity). 1118 if (r <= oc_value) 1119 drop_msg := true 1120 } 1122 if (drop_msg == false) { 1123 send_to_network(msg) // Process it normally by 1124 // sending the request to the next hop 1125 } 1126 else { 1127 // Do not send request downstream, handle locally by 1128 // generating response (if a proxy) or treating as 1129 // an error (if a user agent). 1130 } 1131 } // End perform overload control 1132 } 1134 end case // outbound request 1136 case outbound answer: 1137 if (we are in overload) { 1138 add_overload_avps(msg) 1139 } 1140 send_to_network(msg) 1142 end case // outbound answer 1144 case inbound answer: 1145 create_or_update_oc_scope() // For the specific server 1146 // that sent the answer, create or update the oc scope; 1147 // i.e., extract the values of the overload AVPs 1148 // and store them in the proper scopes for later use. 1149 process_msg(msg) 1151 end case // inbound answer 1152 case inbound request: 1153 create_or_update_oc_scope() 1155 if (we are not in overload) { 1156 process_msg(msg) 1157 } 1158 else { // We are in overload 1159 if ( connection supports overload) 1160 process_msg(msg) 1162 } 1163 else { // Sender does not support oc 1164 if (local_policy(msg) says process message) { 1165 process_msg(msg) 1166 } 1167 else { 1168 send_answer(msg, DIAMETER_PEER_IN_OVERLOAD) 1169 } 1170 } 1171 } 1172 end case // inbound request 1173 } 1174 } 1176 A simple way to sample the traffic mix for category 1 and category 2 1177 is to associate a counter with each category of message. 1178 Periodically (every 5-10s), get the value of the counters and 1179 calculate the ratio of category 1 messages to category 2 messages 1180 since the last calculation. 1182 Example: In the last 5 seconds, a total of 500 requests were 1183 scheduled to be sent. Assume that 450 out of 500 were messages 1184 subject to reduction and 50 out of 500 were classified as requests 1185 not subject to reduction. Based on this ratio, cat1 := 90 and cat2 1186 := 10, or a 90/10 mix will be used in overload calculations. 1188 Of course, this scheme can be generalized to include an arbitrary 1189 number of priorities, depending on how many different classes of 1190 messages make sense for the given application. 1192 5. Diameter AVPs for Overload 1194 NOTE: THE AVP NUMBERS IN THIS SECTION ARE USED FOR EXAMPLE PURPOSES 1195 ONLY. THE FINAL AVP CODES TO BE USED WILL BE ASSIGNED BY IANA DURING 1196 THE PUBLICATION PROCESS, WHEN AND IF THIS DOCUMENT IS PUBLISHED AS AN 1197 RFC. 1199 +---------------------+-------+-------+-------------+------+--------+ 1200 | Attribute Name | AVP | Sec. | Data Type | MUST | MUST | 1201 | | Code | Def. | | | NOT | 1202 +---------------------+-------+-------+-------------+------+--------+ 1203 | Load-Info | 1600 | 5.1 | Grouped | | M,V | 1204 | Supported-Scopes | 1601 | 5.2 | Unsigned64 | | M,V | 1205 | Overload-Algorithm | 1602 | 5.3 | Enumerated | | M,V | 1206 | Overload-Info-Scope | 1603 | 5.4 | OctetString | | M,V | 1207 | Overload-Metric | 1604 | 5.5 | Unsigned32 | | M,V | 1208 | Period-Of-Validity | 1605 | 5.6 | Unsigned32 | | M,V | 1209 | Session-Group | 1606 | 5.7 | UTF8String | | M,V | 1210 | Load | 1607 | 5.8 | Unsigned32 | | M,V | 1211 +---------------------+-------+-------+-------------+------+--------+ 1213 5.1. Load-Info AVP 1215 The Load-Info AVP (AVP code 1600) is of type Grouped, and is used as 1216 a top-level container to group together all information pertaining to 1217 load and overload information. Every Load-Info AVP MUST contain one 1218 Overload-Information-Scope AVP, and one Overload-Metric AVP. 1220 The Grouped Data field of the Load-Info AVP has the following CCF 1221 grammar: 1223 < Load-Info > ::= < AVP Header: 1600 > 1224 < Overload-Metric > 1225 * { Overload-Info-Scope } 1226 [ Supported-Scopes ] 1227 * [ Overload-Algorithm ] 1228 [ Period-Of-Validity ] 1229 [ Session-Group ] 1230 [ Load ] 1231 * [ AVP ] 1233 5.2. Supported-Scopes AVP 1235 The Supported-Scopes AVP (AVP code 1601) is of type Uint64, and is 1236 used during capabilities exchange to negotiate the scopes that can be 1237 used for the connection. Nodes that support the mechanism defined in 1238 this document MUST include a Supported-Scopes AVP in all CER 1239 messages. It also MUST appear in any CEA messages sent in answer to 1240 a CER message containing a Load-Info AVP. The Supported-Scopes AVP 1241 MUST NOT appear in any other message types. See Section 5.4 for an 1242 initial list of scopes. 1244 The Supported-Scopes AVP contains a bitmap that indicates the scopes 1245 supported by the client. The five mandatory scopes (Destination- 1246 Realm, Application-ID, Destination-Host, Next-Hop, and Connection) 1247 are not signaled. Within the bitmap, the least significant bit 1248 indicates support for scope 6 (Session-Group), while the next least 1249 significant bit indicates support for scope 7 (Session). In general, 1250 if we consider the bits to be numbered from 0 (LSB) to 63 (MSB), then 1251 any bit n corresponds to the scope type numbered n+6. This scheme 1252 allows for up to 69 total scopes to be supported (including the five 1253 mandatory scopes). More formally, the bitmask used to indicate 1254 support for any specific context is calculated as follows (where the 1255 symbol "<<" indicates a bit shift left): 1257 bitmask = 1 << (n - 6) 1259 For additional clarity, the bitmasks for the two optional scopes 1260 defined in this document are as follows: 1262 +-------+---------+---------------+ 1263 | Scope | Bitmask | Scope | 1264 +-------+---------+---------------+ 1265 | 6 | 0x01 | Session-Group | 1266 | 7 | 0x02 | Session | 1267 +-------+---------+---------------+ 1269 The negotiation process that makes use of the Supported-Scopes AVP is 1270 described in Section 3.1. The Supported-Scopes AVP may be omitted if 1271 no optional scopes are supported. 1273 5.3. Overload-Algorithm AVP 1275 The Overload-Algorithm AVP (AVP code 1602) is of type Enumerated, and 1276 is used to negotiate the algorithm that will be used for load 1277 abatement. The Overload-Algorithm AVP MAY appear in CER and CEA 1278 messages, and MUST NOT appear in any other message types. If absent, 1279 an Overload Algorithm of type 1 (Loss) is indicated. Additional 1280 values can be registered by other documents; see Appendix C.1. 1281 Initial values for the enumeration are as follows: 1283 +------------+----------------+------------+ 1284 | AVP Values | Attribute Name | Reference | 1285 +------------+----------------+------------+ 1286 | 0 | Reserved | - | 1287 | 1 | Loss | [RFC xxxx] | 1288 +------------+----------------+------------+ 1290 5.4. Overload-Info-Scope AVP 1292 The Overload-Info-Scope AVP (AVP code 1603) is of type OctetString, 1293 and is used to indicate to which scope the Overload-Metric applies. 1295 See Section 2 for a definition of the different scope types and a 1296 formal description of how they are applied. Other documents may 1297 define additional scopes; see Appendix C.2 for details. 1299 0 1 2 3 1300 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Scope | | 1303 +-+-+-+-+-+-+-+-+ Details | 1304 | | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 +-------+-------------------+------------+ 1308 | Scope | Attribute Name | Reference | 1309 +-------+-------------------+------------+ 1310 | 0 | Reserved | [RFC xxxx] | 1311 | 1 | Destination-Realm | [RFC xxxx] | 1312 | 2 | Application-ID | [RFC xxxx] | 1313 | 3 | Destination-Host | [RFC xxxx] | 1314 | 4 | Host | [RFC xxxx] | 1315 | 5 | Connection | [RFC xxxx] | 1316 | 6 | Session-Group | [RFC xxxx] | 1317 | 7 | Session | [RFC xxxx] | 1318 +-------+-------------------+------------+ 1320 Each Overload-Info-Scope has a different encoding, according to the 1321 identifier used to designate the corresponding scope. The formats 1322 for the seven scopes defined in this document are given in the 1323 following section. 1325 5.4.1. Realm Scope 1327 0 1 2 3 1328 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | 1 | | 1331 +-+-+-+-+-+-+-+-+ Realm (DiameterIdentity) | 1332 | | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 5.4.2. Application-ID Scope 1337 0 1 2 3 1338 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | 2 | Reserved (set to zeros) | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | Application-ID (Unsigned32) | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 5.4.3. Host Scope 1347 0 1 2 3 1348 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | 3 | | 1351 +-+-+-+-+-+-+-+-+ Host (DiameterIdentity) | 1352 | | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 5.4.4. Session Scope 1357 0 1 2 3 1358 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | 4 | | 1361 +-+-+-+-+-+-+-+-+ Session-ID (UTF8String) | 1362 | | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 5.4.5. Connection Scope 1367 0 1 2 3 1368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | 5 | Reserved (set to zeros) | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 5.4.6. Session Group Scope 1375 0 1 2 3 1376 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | 6 | | 1379 +-+-+-+-+-+-+-+-+ Group Name (UTF8String) | 1380 | | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 5.5. Overload-Metric AVP 1385 The Overload-Metric AVP (AVP code 1604) is of type Unsigned32, and is 1386 used as input to the load mitigation algorithm. Its definition and 1387 interpretation is left up to each individual algorithm, with the 1388 exception that an Overload-Metric of "0" always indicates that the 1389 node is not in overload (that is, no load abatement procedures are in 1390 effect) for the indicated scope. 1392 5.6. Period-Of-Validity AVP 1394 The Period-Of-Validity AVP (AVP code 1605) is of type Unsigned32, and 1395 is used to indicate the length of time, in seconds, the Overload- 1396 Metric is to be considered valid (unless overridden by a subsequent 1397 Overload-Metric in the same scope). It MUST NOT be present if the 1398 Overload-Metric is '0', and MUST be present otherwise. 1400 5.7. Session-Group AVP 1402 The Session-Group AVP (AVP code 1606) is of type UTF8String, and is 1403 used to assign a new session to the session group that it names. The 1404 Session-Group AVP MAY appear once in the answer to a session-creating 1405 request, and MUST NOT appear in any other message types. 1407 5.8. Load AVP 1409 The Load AVP (AVP code 1607) is of type Unsigned32, and is used to 1410 indicate the load level of the scope in which it appears. See 1411 Section 3.5 for additional information. 1413 6. Security Considerations 1415 A key concern for recipients of overload metrics and load information 1416 is whether the peer from which the information has been received is 1417 authorized to speak for the indicated scope. For scopes such as 1418 "Host" and "Connection", such authorization is obvious. For other 1419 scopes, such as "Application-ID" and "Realm", the potential for a 1420 peer to maliciously or accidentally reduce traffic to a third party 1421 is evident. Implementations may choose to ignore indications from 1422 hosts which do not clearly have authority over the indicated scope; 1423 alternately, they may wish to further restrict the scope to apply 1424 only to the host from which the information has been received. 1426 On the other hand, multiple nodes that are under the same 1427 administrative control (or a tightly controlled confederation of 1428 control) may be implicitly trusted to speak for all scopes within 1429 that domain of control. Implementations are encouraged to allow 1430 configuration of inherently trusted servers to which the foregoing 1431 restrictions are not applied. 1433 Open Issue: There are almost certainly other security issues to take 1434 into consideration here. For example, we might need to include 1435 guidance around who gets to see our own load information, and 1436 potentially changing the granularity of information presented based 1437 on trust relationships. 1439 7. IANA Considerations 1441 This document defines new entries in several existing IANA tables. 1442 It also creates two new tables. 1444 7.1. New Diameter AVPs 1446 The following entries are added to the "AVP Codes" table under the 1447 "aaa-parameters" registry. 1449 +----------+---------------------+-----------+ 1450 | AVP Code | Attribute Name | Reference | 1451 +----------+---------------------+-----------+ 1452 | 1600 | Load-Info | RFC xxxx | 1453 | 1601 | Supported-Scopes | RFC xxxx | 1454 | 1602 | Overload-Algorithm | RFC xxxx | 1455 | 1603 | Overload-Info-Scope | RFC xxxx | 1456 | 1604 | Overload-Metric | RFC xxxx | 1457 | 1605 | Period-Of-Validity | RFC xxxx | 1458 | 1606 | Session-Group | RFC xxxx | 1459 | 1607 | Load | RFC xxxx | 1460 +----------+---------------------+-----------+ 1462 7.2. New Diameter Disconnect-Cause 1464 The following entry is added to the "Disconnect-Cause AVP Values 1465 (code 273)" table in the "aaa-parameters" registry: 1467 +------------------------+---------------------+-----------+ 1468 | AVP Values | Attribute Name | Reference | 1469 +------------------------+---------------------+-----------+ 1470 | 128 [actual value TBD] | NEGOTIATION_FAILURE | RFC xxxx | 1471 +------------------------+---------------------+-----------+ 1473 7.3. New Diameter Response Code 1475 The following entry is added to the "Result-Code AVP Values (code 1476 268) - Transient Failures" table in the "aaa-parameters" registry: 1478 +-------------------------+---------------------------+-----------+ 1479 | AVP Values | Attribute Name | Reference | 1480 +-------------------------+---------------------------+-----------+ 1481 | 4128 [actual value TBD] | DIAMETER_PEER_IN_OVERLOAD | RFC xxxx | 1482 +-------------------------+---------------------------+-----------+ 1484 7.4. New Command Flag 1486 The following entry is added to the "Command Flags" table in the 1487 "aaa-parameters" registry: 1489 +-----+------------+-----------+ 1490 | bit | Name | Reference | 1491 +-----+------------+-----------+ 1492 | 4 | 'O'verload | RFC xxxx | 1493 +-----+------------+-----------+ 1495 7.5. Overload Algorithm Registry 1497 This document defines a new table, to be titled "Overload-Algorithm 1498 Values (code 1602)", in the "aaa-parameters" registry. Its initial 1499 values are to be taken from the table in Section 5.3. 1501 New entries in this table follow the IANA policy of "Specification 1502 Required." (Open Issue: The WG should discuss registration policy to 1503 ensure that we think this is the right balance). 1505 7.6. Overload Scope Registry 1507 This document defines a new table, to be titled "Overload-Info-Scope 1508 Values (code 1603)", in the "aaa-parameters" registry. Its initial 1509 values are to be taken from the table in Section 5.4. 1511 New entries in this table follow the IANA policy of "Specification 1512 Required." (Open Issue: The WG should discuss registration policy to 1513 ensure that we think this is the right balance). 1515 8. References 1516 8.1. Normative References 1518 [I-D.ietf-dime-overload-reqs] 1519 McMurry, E. and B. Campbell, "Diameter Overload Control 1520 Requirements", draft-ietf-dime-overload-reqs-00 (work in 1521 progress), September 2012. 1523 [I-D.ietf-dime-rfc3588bis] 1524 Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1525 "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-34 1526 (work in progress), June 2012. 1528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1529 Requirement Levels", BCP 14, RFC 2119, March 1997. 1531 8.2. Informative References 1533 [I-D.ietf-soc-overload-control] 1534 Gurbani, V., Hilt, V., and H. Schulzrinne, "Session 1535 Initiation Protocol (SIP) Overload Control", 1536 draft-ietf-soc-overload-control-09 (work in progress), 1537 July 2012. 1539 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1540 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1542 [RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design 1543 Considerations for Session Initiation Protocol (SIP) 1544 Overload Control", RFC 6357, August 2011. 1546 Appendix A. Acknowledgements 1548 This work was inspired by and borrows heavily from the SIP overload 1549 control mechanism described in [I-D.ietf-soc-overload-control]. The 1550 authors of this document are deeply grateful to the editor and 1551 authors of that work, as well as its many contributors. 1553 Thanks to Ben Campbell and Eric McMurry for significant input to the 1554 initial mechanism design. The author also thanks Martin Dolly, Bob 1555 Wallace, John Gilmore, Matt McCann, Jonathan Palmer, Kedar Karmarkar, 1556 Imtiaz Shaikh, Jouni Korhonen, Uri Baniel, Jianrong Wang, Brian 1557 Freeman, and Eric Noel for early feedback on the mechanism. 1559 Appendix B. Requirements Analysis 1561 This section analyzes the mechanism described in this document 1562 against the set of requirements detailed in 1563 [I-D.ietf-dime-overload-reqs]. 1565 Open Issue: This analysis to be performed after requirements have 1566 been finalized. 1568 Appendix C. Extending the Overload Mechanism 1570 This specification includes two key extension points to allow for new 1571 behaviors to be smoothly added to the mechanism in the future. The 1572 following sections discuss the means by which future documents are 1573 expected to extend the mechanism. 1575 C.1. New Algorithms 1577 In order to provide the ability for different means of traffic 1578 abatement in the future, this specification allows for descriptions 1579 of new traffic reduction algorithms. In general, documents that 1580 define new algorithms need to describe externally-observable node 1581 behavior in sufficient detail as to allow interoperation. 1583 At a minimum, such description needs to include: 1585 1. The name and IANA-registered number for negotiating the algorithm 1586 (see Section 5.3). 1587 2. A clear description of how the Overload-Metric AVP is to be 1588 interpreted, keeping in mind that "0" is reserved to indicate 1589 that no overload condition exists. 1590 3. An example, proof-of-concept description (preferably in pseudo- 1591 code) of how nodes can implement the algorithm. 1593 New algorithms must be capable of working with all applications, not 1594 just a subset of applications. 1596 C.2. New Scopes 1598 Because it is impossible to foresee all the potential constructs that 1599 it might be useful to scope operations to for the purposes of 1600 overload, we allow for the registration of new scopes. 1602 At a minimum, such description needs to include: 1604 1. The name and IANA-registered number for negotiating and 1605 indicating the scope (see Section 5.4). 1606 2. A syntax for the "Details" field of the Overload-Info-Scope AVP, 1607 preferably derived from one of the base Diameter data types. 1609 3. An explicit and unambiguous description of how both parties to 1610 the overload control mechanism can determine which transactions 1611 correspond to the indicated scope. 1612 4. A clear and exhaustive list that extends the one in Section 2.2, 1613 indicating exactly which combinations of scopes are allowed with 1614 the new scope. This list must take into account all of the IANA- 1615 registered scopes at the time of its publication. 1617 It is acceptable for new scopes to be specific to constructs within 1618 one or several applications. In other words, it may be desirable to 1619 define scopes that can be applied to one kind of application while 1620 not making sense for another. Extension documents should be very 1621 clear that such is the case, however, if they choose to do so. 1623 Author's Address 1625 Adam Roach 1626 Tekelec 1627 17210 Campbell Rd. 1628 Suite 250 1629 Dallas, TX 75252 1630 US 1632 Email: adam@nostrum.com