idnits 2.17.00 (12 Aug 2021) /tmp/idnits13189/draft-ietf-dime-ovli-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 530 has weird spacing: '...rotocol stan...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Indicates that the reporting node (or realm) does not want to receive any traffic from the reacting node for the application the report concerns. The reacting node MUST not send traffic to the reporting node (or realm) as long as the overload condition changes or expires. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The lack of end-to-end confidentiality protection means that any Diameter agent in the path of an overload report can view the contents of that report. In addition to the requirement to select which peers are trusted to send overload reports, operators MUST be able to select which peers are authorized to receive reports. A node MUST not send an overload report to a peer not authorized to receive it. Furthermore, an agent MUST remove any overload reports that might have been inserted by other nodes before forwarding a Diameter message to a peer that is not authorized to receive overload reports. -- The document date (March 27, 2014) is 2977 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: 'RFC5905' is defined on line 1619, but no explicit reference was found in the text == Unused Reference: 'RFC5729' is defined on line 1642, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-dime-e2e-sec-req has been published as RFC 7966 -- Obsolete informational reference (is this intentional?): RFC 4006 (Obsoleted by RFC 8506) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed. 3 Internet-Draft Broadcom 4 Intended status: Standards Track S. Donovan, Ed. 5 Expires: September 28, 2014 B. Campbell 6 Oracle 7 L. Morand 8 Orange Labs 9 March 27, 2014 11 Diameter Overload Indication Conveyance 12 draft-ietf-dime-ovli-02.txt 14 Abstract 16 This specification documents a Diameter Overload Control (DOC) base 17 solution and the dissemination of the overload report information. 19 Requirements 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 September 28, 2014. 42 Copyright Notice 44 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 61 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Architectural Assumptions . . . . . . . . . . . . . . . . 6 63 3.1.1. Application Classification . . . . . . . . . . . . . 6 64 3.1.2. Application Type Overload Implications . . . . . . . 7 65 3.1.3. Request Transaction Classification . . . . . . . . . 8 66 3.1.4. Request Type Overload Implications . . . . . . . . . 9 67 3.1.5. Diameter Agent Behavior . . . . . . . . . . . . . . . 10 68 3.1.6. Simplified Example Architecture . . . . . . . . . . . 11 69 3.2. Conveyance of the Overload Indication . . . . . . . . . . 12 70 3.2.1. DOIC Capability Discovery . . . . . . . . . . . . . . 12 71 3.3. Overload Condition Indication . . . . . . . . . . . . . . 13 72 4. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 13 73 4.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 13 74 4.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 14 75 4.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 16 77 4.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 16 78 4.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 17 79 4.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 18 80 4.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 19 81 5. Overload Control Operation . . . . . . . . . . . . . . . . . 19 82 5.1. Overload Control Endpoints . . . . . . . . . . . . . . . 19 83 5.2. Piggybacking Principle . . . . . . . . . . . . . . . . . 23 84 5.3. Capability Announcement . . . . . . . . . . . . . . . . . 24 85 5.3.1. Reacting Node Endpoint Considerations . . . . . . . . 24 86 5.3.2. Reporting Node Endpoint Considerations . . . . . . . 24 87 5.3.3. Agent Considerations . . . . . . . . . . . . . . . . 25 88 5.4. Protocol Extensibility . . . . . . . . . . . . . . . . . 25 89 5.5. Overload Report Processing . . . . . . . . . . . . . . . 26 90 5.5.1. Overload Control State . . . . . . . . . . . . . . . 26 91 5.5.2. Reacting Node Considerations . . . . . . . . . . . . 28 92 5.5.3. Reporting Node Considerations . . . . . . . . . . . . 30 93 5.5.4. Agent Considerations . . . . . . . . . . . . . . . . 31 94 6. Transport Considerations . . . . . . . . . . . . . . . . . . 31 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 96 7.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 31 97 7.2. New registries . . . . . . . . . . . . . . . . . . . . . 31 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 99 8.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 32 100 8.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 33 101 8.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 33 102 8.4. End-to End-Security Issues . . . . . . . . . . . . . . . 34 103 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 105 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 106 10.2. Informative References . . . . . . . . . . . . . . . . . 35 107 Appendix A. Issues left for future specifications . . . . . . . 36 108 A.1. Additional traffic abatement algorithms . . . . . . . . . 36 109 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 36 110 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 36 111 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 37 112 B.1. Mix of Destination-Realm routed requests and Destination- 113 Host routed requests . . . . . . . . . . . . . . . . . . 37 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 116 1. Introduction 118 This specification defines a base solution for Diameter Overload 119 Control (DOC). The requirements for the solution are described and 120 discussed in the corresponding design requirements document 121 [RFC7068]. Note that the overload control solution defined in this 122 specification does not address all the requirements listed in 123 [RFC7068]. A number of overload control related features are left 124 for the future specifications. 126 The solution defined in this specification addresses the Diameter 127 overload control between two endpoints (see Section 5.1). 128 Furthermore, the solution is designed to apply to existing and future 129 Diameter applications, requires no changes to the Diameter base 130 protocol [RFC6733] and is deployable in environments where some 131 Diameter nodes do not implement the Diameter overload control 132 solution defined in this specification. 134 2. Terminology and Abbreviations 136 Abatement Algorithm 138 An algorithm requested by reporting nodes and used by reacting 139 nodes to reduce the amount of traffic sent to the reporting node 140 during an occurrence of overload control. 142 Throttling: 144 Throttling is the reduction of the number of requests sent to an 145 entity. Throttling can include a client dropping requests, or an 146 agent rejecting requests with appropriate error responses. 147 Clients and agents can also choose to redirect throttled requests 148 to some other entity or entities capable of handling them. 150 Reporting Node 152 A Diameter node that generates an overload report. (This may or 153 may not be the overloaded node.) 155 Reacting Node 157 A Diameter node that consumes and acts upon a report. Note that 158 "act upon" does not necessarily mean the reacting node applies an 159 abatement algorithm; it might decide to delegate that downstream, 160 in which case it also becomes a "reporting node". 162 Overload Control State (OCS) 164 State describing an occurrence of overload control maintained by 165 reporting and reacting nodes. 167 Overload Report (OLR) 169 A set of AVPs sent by a reporting node indicating the start or 170 continuation of an occurrence of overload control. 172 3. Solution Overview 174 The Diameter Overload Information Conveyance (DOIC) mechanism allows 175 Diameter nodes to request other nodes to perform overload abatement 176 actions, that is, actions to reduce the load offered to the 177 overloaded node or realm. 179 A Diameter node that supports DOIC is known as a "DOIC endpoint". 180 Any Diameter node can act as a DOIC endpoint, including clients, 181 servers, and agents. DOIC endpoints are further divided into 182 "Reporting Nodes" and "Reacting Nodes." A reporting node requests 183 overload abatement by sending an Overload Report (OLR) to one or more 184 reacting nodes. 186 A reacting node consumes OLRs, and performs whatever actions are 187 needed to fulfill the abatement requests included in the OLRs. A 188 Reporting node may report overload on its own behalf, or on behalf of 189 other (typically upstream) nodes. Likewise, a reacting node may 190 perform overload abatement on its own behalf, or on behalf of other 191 (typically downstream) nodes. 193 A node's role as a DOIC endpoint is independent of its Diameter role. 194 For example, Diameter relay and proxy agents may act as DOIC 195 endpoints, even though they are not endpoints in the Diameter sense. 196 Since Diameter enables bi-directional applications, where Diameter 197 servers can send requests towards Diameter clients, a given Diameter 198 node can simultaneously act as a reporting node and reacting node. 200 Likewise, a relay or proxy agent may act as a reacting node from the 201 perspective of upstream nodes, and a reporting node from the 202 perspective of downstream nodes. 204 DOIC endpoints do not generate new messages to carry DOIC related 205 information. Rather, they "piggyback" DOIC information over existing 206 Diameter messages by inserting new AVPs into existing Diameter 207 requests and responses. Nodes indicate support for DOIC, and any 208 needed DOIC parameters by inserting an OC_Supported_Features AVP 209 (Section 4.1) into existing requests and responses. Reporting nodes 210 send OLRs by inserting OC-OLR AVPs. (Section 4.3) 212 A given OLR applies to the Diameter realm and application of the 213 Diameter message that carries it. If a reporting node supports more 214 than one realm and/or application, it reports independently for each 215 combination of realm and application. Similarly, OC-Feature-Vector 216 AVPs apply to the realm and application of the enclosing message. 217 This implies that a node may support DOIC for one application and/or 218 realm, but not another, and may indicate different DOIC parameters 219 for each application and realm for which it supports DOIC. 221 Reacting nodes perform overload abatement according to an agreed-upon 222 abatement algorithm. An abatement algorithm defines the meaning of 223 the parameters of an OLR, and the procedures required for overload 224 abatement. This document specifies a single must-support algorithm, 225 namely the "loss" algorithm [ref?]. Future specifications may 226 introduce new algorithms. 228 Editor's note: The need to restructure the document to contain a 229 section that describes the loss algorithm. This likely means 230 separating the description of the mechanisms for reporting the need 231 for overload control from the description of the loss algorithm. 233 Overload conditions may vary in scope. For example, a single 234 Diameter node may be overloaded, in which case reacting nodes may 235 reasonably attempt to send throttled requests to other destinations 236 or via other agents. On the other hand, an entire Diameter realm may 237 be overloaded, in which case such attempts would do harm. DOIC OLRs 238 have a concept of "report type" (Section 4.6), where the type defines 239 such behaviors. Report types are extensible. This document defines 240 report types for overload of a specific server, and for overload of 241 an entire realm. 243 While a reporting node sends OLRs to "adjacent" reacting nodes, nodes 244 that are "adjacent" for DOIC purposes may not be adjacent from a 245 Diameter, or transport, perspective. For example, one or more 246 Diameter agents that do not support DOIC may exist between a given 247 pair of reporting and reacting nodes, as long as those agents pass 248 unknown AVPs through unmolested. The report types described in this 249 document can safely pass through non-supporting agents. This may not 250 be true for report types defined in future specifications. Documents 251 that introduce new report types MUST describe any limitations on 252 their use across non-supporting agents. 254 3.1. Architectural Assumptions 256 This section describes the high-level architectural and semantic 257 assumptions that underlie the Diameter Overload Control Mechanism. 259 3.1.1. Application Classification 261 The following is a classification of Diameter applications and 262 requests. This discussion is meant to document factors that play 263 into decisions made by the Diameter identity responsible for handling 264 overload reports. 266 Section 8.1 of [RFC6733] defines two state machines that imply two 267 types of applications, session-less and session-based applications. 268 The primary difference between these types of applications is the 269 lifetime of Session-Ids. 271 For session-based applications, the Session-Id is used to tie 272 multiple requests into a single session. 274 In session-less applications, the lifetime of the Session-Id is a 275 single Diameter transaction, i.e. the session is implicitly 276 terminated after a single Diameter transaction and a new Session-Id 277 is generated for each Diameter request. 279 For the purposes of this discussion, session-less applications are 280 further divided into two types of applications: 282 Stateless applications: 284 Requests within a stateless application have no relationship to 285 each other. The 3GPP defined S13 application is an example of a 286 stateless application [S13], --> where only a Diameter command is 287 defined between a client and a server and no state is maintained 288 between two consecutive transactions. 290 Pseudo-session applications: 292 Applications that do not rely on the Session-Id AVP for 293 correlation of application messages related to the same session 294 but use other session-related information in the Diameter requests 295 for this purpose. The 3GPP defined Cx application [Cx] is an 296 example of a pseudo-session application. 298 The Credit-Control application defined in [RFC4006] is an example of 299 a Diameter session-based application. 301 The handling of overload reports must take the type of application 302 into consideration, as discussed in Section 3.1.2. 304 3.1.2. Application Type Overload Implications 306 This section discusses considerations for mitigating overload 307 reported by a Diameter entity. This discussion focuses on the type 308 of application. Section 3.1.3 discusses considerations for handling 309 various request types when the target server is known to be in an 310 overloaded state. 312 These discussions assume that the strategy for mitigating the 313 reported overload is to reduce the overall workload sent to the 314 overloaded entity. The concept of applying overload treatment to 315 requests targeted for an overloaded Diameter entity is inherent to 316 this discussion. The method used to reduce offered load is not 317 specified here but could include routing requests to another Diameter 318 entity known to be able to handle them, or it could mean rejecting 319 certain requests. For a Diameter agent, rejecting requests will 320 usually mean generating appropriate Diameter error responses. For a 321 Diameter client, rejecting requests will depend upon the application. 322 For example, it could mean giving an indication to the entity 323 requesting the Diameter service that the network is busy and to try 324 again later. 326 Stateless applications: 328 By definition there is no relationship between individual requests 329 in a stateless application. As a result, when a request is sent 330 or relayed to an overloaded Diameter entity - either a Diameter 331 Server or a Diameter Agent - the sending or relaying entity can 332 choose to apply the overload treatment to any request targeted for 333 the overloaded entity. 335 Pseudo-session applications: 337 For pseudo-session applications, there is an implied ordering of 338 requests. As a result, decisions about which requests towards an 339 overloaded entity to reject could take the command code of the 340 request into consideration. This generally means that 341 transactions later in the sequence of transactions should be given 342 more favorable treatment than messages earlier in the sequence. 343 This is because more work has already been done by the Diameter 344 network for those transactions that occur later in the sequence. 345 Rejecting them could result in increasing the load on the network 346 as the transactions earlier in the sequence might also need to be 347 repeated. 349 Session-based applications: 351 Overload handling for session-based applications must take into 352 consideration the work load associated with setting up and 353 maintaining a session. As such, the entity sending requests 354 towards an overloaded Diameter entity for a session-based 355 application might tend to reject new session requests prior to 356 rejecting intra-session requests. In addition, session ending 357 requests might be given a lower probability of being rejected as 358 rejecting session ending requests could result in session status 359 being out of sync between the Diameter clients and servers. 360 Application designers that would decide to reject mid-session 361 requests will need to consider whether the rejection invalidates 362 the session and any resulting session clean-up procedures. 364 3.1.3. Request Transaction Classification 366 Independent Request: 368 An independent request is not correlated to any other requests 369 and, as such, the lifetime of the session-id is constrained to an 370 individual transaction. 372 Session-Initiating Request: 374 A session-initiating request is the initial message that 375 establishes a Diameter session. The ACR message defined in 376 [RFC6733] is an example of a session-initiating request. 378 Correlated Session-Initiating Request: 380 There are cases when multiple session-initiated requests must be 381 correlated and managed by the same Diameter server. It is notably 382 the case in the 3GPP PCC architecture [PCC], where multiple 383 apparently independent Diameter application sessions are actually 384 correlated and must be handled by the same Diameter server. 386 Intra-Session Request: 388 An intra session request is a request that uses the same Session- 389 Id than the one used in a previous request. An intra session 390 request generally needs to be delivered to the server that handled 391 the session creating request for the session. The STR message 392 defined in [RFC6733] is an example of an intra-session requests. 394 Pseudo-Session Requests: 396 Pseudo-session requests are independent requests and do not use 397 the same Session-Id but are correlated by other session-related 398 information contained in the request. There exists Diameter 399 applications that define an expected ordering of transactions. 400 This sequencing of independent transactions results in a pseudo 401 session. The AIR, MAR and SAR requests in the 3GPP defined Cx 402 [Cx] application are examples of pseudo-session requests. 404 3.1.4. Request Type Overload Implications 406 The request classes identified in Section 3.1.3 have implications on 407 decisions about which requests should be throttled first. The 408 following list of request treatment regarding throttling is provided 409 as guidelines for application designers when implementing the 410 Diameter overload control mechanism described in this document. The 411 exact behavior regarding throttling is a matter of local policy, 412 unless specifically defined for the application. 414 Independent requests: 416 Independent requests can be given equal treatment when making 417 throttling decisions. 419 Session-initiating requests: 421 Session-initiating requests represent more work than independent 422 or intra-session requests. Moreover, session-initiating requests 423 are typically followed by other session-related requests. As 424 such, as the main objective of the overload control is to reduce 425 the total number of requests sent to the overloaded entity, 426 throttling decisions might favor allowing intra-session requests 427 over session-initiating requests. Individual session-initiating 428 requests can be given equal treatment when making throttling 429 decisions. 431 Correlated session-initiating requests: 433 A Request that results in a new binding, where the binding is used 434 for routing of subsequent session-initiating requests to the same 435 server, represents more work load than other requests. As such, 436 these requests might be throttled more frequently than other 437 request types. 439 Pseudo-session requests: 441 Throttling decisions for pseudo-session requests can take into 442 consideration where individual requests fit into the overall 443 sequence of requests within the pseudo session. Requests that are 444 earlier in the sequence might be throttled more aggressively than 445 requests that occur later in the sequence. 447 Intra-session requests 449 There are two classes of intra-sessions requests. The first class 450 consists of requests that terminate a session. The second one 451 contains the set of requests that are used by the Diameter client 452 and server to maintain the ongoing session state. Session 453 terminating requests should be throttled less aggressively in 454 order to gracefully terminate sessions, allow clean-up of the 455 related resources (e.g. session state) and get rid of the need for 456 other intra-session requests, reducing the session management 457 impact on the overloaded entity. The default handling of other 458 intra-session requests might be to treat them equally when making 459 throttling decisions. There might also be application level 460 considerations whether some request types are favored over others. 462 3.1.5. Diameter Agent Behavior 464 Editor's note: This section needs to be revisited once definition of 465 DOIC endpoints is finalized. 467 In the context of the Diameter Overload Indication Conveyance (DOIC) 468 and reacting to the overload information, the functional behavior of 469 Diameter agents in front of servers, especially Diameter proxies, 470 needs to be common. This is important because agents may actively 471 participate in the handling of an overload conditions. For example, 472 they may make intelligent next hop selection decisions based on 473 overload conditions, or aggregate overload information to be 474 disseminated downstream. Diameter agents may have other deployment 475 related tasks that are not defined in the Diameter base protocol 476 [RFC6733]. These include, among other tasks, topology hiding, or 477 agent acting as a Server Front End (SFE) for a farm of Diameter 478 servers. 480 Since the solution defined in this specification must not break the 481 Diameter base protocol [RFC6733] at any time, great care has to be 482 taken not to assume functionality from the Diameter agents that would 483 break base protocol behavior, or to assume agent functionality beyond 484 the Diameter base protocol. Effectively this means the following 485 from a Diameter agent: 487 o If a Diameter agent presents itself as the "end node", as an agent 488 acting as an topology hiding SFE, the agent is the final 489 destination of requests initiated by Diameter clients, the 490 original source for the corresponding answers and server-initiated 491 requests. As a consequence, the DOIC mechanism MUST NOT leak 492 information of the Diameter nodes behind it. This requirement 493 means that such a Diameter agent acts as a back-to-back-agent for 494 DOIC purposes. How the Diameter agent in this case appears to the 495 Diameter servers in the farm, is specific to the implementation 496 and deployment within the realm the Diameter agent is deployed. 498 o If the Diameter agent does not impersonate the servers behind it, 499 the Diameter dialogue is established between clients and servers 500 and any overload information received by a client would be from 501 the server identified by the Origin-Host identity contained in the 502 Diameter message. 504 3.1.6. Simplified Example Architecture 506 Figure 1 illustrates the simplified architecture for Diameter 507 overload information conveyance. See Section 5.1 for more discussion 508 and details how different Diameter nodes fit into the architecture 509 from the DOIC point of view. 511 Realm X Same or other Realms 512 <--------------------------------------> <----------------------> 514 +--^-----+ : (optional) : 515 |Diameter| : : 516 |Server A|--+ .--. : +---^----+ : .--. 517 +--------+ | _( `. : |Diameter| : _( `. +---^----+ 518 +--( )--:-| Agent |-:--( )--|Diameter| 519 +--------+ | ( ` . ) ) : +-----^--+ : ( ` . ) ) | Client | 520 |Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+ 521 |Server B| : : 522 +---^----+ : : 524 End-to-end Overload Indication 525 1) <-----------------------------------------------> 526 Diameter Application Y 528 Overload Indication A Overload Indication A' 529 2) <----------------------> <----------------------> 530 standard base protocol standard base protocol 532 Figure 1: Simplified architecture choices for overload indication 533 delivery 535 In Figure 1, the Diameter overload indication can be conveyed (1) 536 end-to-end between servers and clients or (2) between servers and 537 Diameter agent inside the realm and then between the Diameter agent 538 and the clients when the Diameter agent acting as back-to-back-agent 539 for DOIC purposes. 541 3.2. Conveyance of the Overload Indication 543 The following sections describe new Diameter AVPs used for sending 544 overload reports, and for declaring support for certain DOIC 545 features. 547 3.2.1. DOIC Capability Discovery 549 Support of DOIC may be specified as part of the functionality 550 supported by a new Diameter application. In this way, support of the 551 considered Diameter application (discovered during capabilities 552 exchange phase as defined in Diameter base protocol [RFC6733]) 553 indicates implicit support of the DOIC mechanism. 555 Editor's Note: This method does not work in general when agents are 556 part of the deployment. 558 When the DOIC mechanism is introduced in existing Diameter 559 applications, a specific capability discovery mechanism is required. 560 The "DOIC capability discovery mechanism" is based on the presence of 561 specific optional AVPs in the Diameter messages, such as the OC- 562 Supported-Features AVP (see Section 4.1). Although the OC-Supported- 563 Features AVP can be used to advertise a certain set of new or 564 existing Diameter overload control capabilities, it is not a 565 versioning solution per se, however, it can be used to achieve the 566 same result. 568 From the Diameter overload control functionality point of view, the 569 "Reacting node" is the requester of the overload report information 570 and the "Reporting node" is the provider of the overload report. The 571 OC-Supported-Features AVP in the request message is always 572 interpreted as an announcement of "DOIC supported capabilities". The 573 OC-Supported-Features AVP in the answer is also interpreted as a 574 report of "DOIC supported capabilities" and at least one of supported 575 capabilities MUST be common with the "Reacting node" (see 576 Section 4.1). 578 3.3. Overload Condition Indication 580 Diameter nodes can request a reduction in offered load by indicating 581 an overload condition in the form of an overload report. The 582 overload report contains information about how much load should be 583 reduced, and may contain other information about the overload 584 condition. This information is conveyed in Diameter Attribute Value 585 Pairs (AVPs). 587 Certain new AVPs may also be used to declare certain DOIC 588 capabilities and extensions. 590 4. Attribute Value Pairs 592 This section describes the encoding and semantics of the Diameter 593 Overload Indication Attribute Value Pairs (AVPs) defined in this 594 document. 596 4.1. OC-Supported-Features AVP 598 The OC-Supported-Features AVP (AVP code TBD1) is type of Grouped and 599 serves for two purposes. First, it announces a node's support for 600 the DOIC in general. Second, it contains the description of the 601 supported DOIC features of the sending node. The OC-Supported- 602 Features AVP MUST be included in every Diameter message a DOIC 603 supporting node sends. 605 OC-Supported-Features ::= < AVP Header: TBD1 > 606 [ OC-Feature-Vector ] 607 * [ AVP ] 609 The OC-Feature-Vector sub-AVP is used to announce the DOIC features 610 supported by the endpoint, in the form of a flag bits field in which 611 each bit announces one feature or capability supported by the node 612 (see Section 4.2). The absence of the OC-Feature-Vector AVP 613 indicates that only the default traffic abatement algorithm described 614 in this specification is supported. 616 A reacting node includes this AVP to indicate its capabilities to a 617 reporting node. For example, the endpoint (reacting node) may 618 indicate which (future defined) traffic abatement algorithms it 619 supports in addition to the default. 621 During the message exchange the overload control endpoints express 622 their common set of supported capabilities. The reacting node 623 includes the OC-Supported-Features AVP that announces what it 624 supports. The reporting node that sends the answer also includes the 625 OC-Supported-Features AVP that describes the capabilities it 626 supports. The set of capabilities advertised by the reporting node 627 depends on local policies. At least one of the announced 628 capabilities MUST match. If there is no single matching capability 629 the reacting node MUST act as if it does not implement DOIC and cease 630 inserting any DOIC related AVPs into any Diameter messages with this 631 specific reacting node. 633 Editor's note: The last sentence conflicts with the last sentence two 634 paragraphs up. In reality, there will always be at least one 635 matching capability as all nodes supporting DOIC must support the 636 loss algorithm. Suggest removing the last sentence. 638 4.2. OC-Feature-Vector AVP 640 The OC-Feature-Vector AVP (AVP code TBD6) is type of Unsigned64 and 641 contains a 64 bit flags field of announced capabilities of an 642 overload control endpoint. The value of zero (0) is reserved. 644 The following capabilities are defined in this document: 646 OLR_DEFAULT_ALGO (0x0000000000000001) 647 When this flag is set by the overload control endpoint it means 648 that the default traffic abatement (loss) algorithm is supported. 650 4.3. OC-OLR AVP 652 The OC-OLR AVP (AVP code TBD2) is type of Grouped and contains the 653 necessary information to convey an overload report. The OC-OLR AVP 654 does not explicitly contain all information needed by the reacting 655 node to decide whether a subsequent request must undergo a throttling 656 process with the received reduction percentage. The value of the OC- 657 Report-Type AVP within the OC-OLR AVP indicates which implicit 658 information is relevant for this decision (see Section 4.6). The 659 application the OC-OLR AVP applies to is the same as the Application- 660 Id found in the Diameter message header. The identity the OC-OLR AVP 661 concerns is determined from the Origin-Host AVP (and Origin-Realm AVP 662 as well) found from the encapsulating Diameter command. The OC-OLR 663 AVP is intended to be sent only by a reporting node. 665 OC-OLR ::= < AVP Header: TBD2 > 666 < OC-Sequence-Number > 667 < OC-Report-Type > 668 [ OC-Reduction-Percentage ] 669 [ OC-Validity-Duration ] 670 * [ AVP ] 672 The OC-Validity-Duration AVP indicates the validity time of the 673 overload report associated with a specific sequence number, measured 674 after reception of the OC-OLR AVP. The validity time MUST NOT be 675 updated after reception of subsequent OC-OLR AVPs with the same 676 sequence number. The default value for the OC-Validity-Duration AVP 677 value is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is 678 not present in the OC-OLR AVP, the default value applies. 680 Note that if a Diameter command were to contain multiple OC-OLR AVPs 681 they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs 682 with unknown values SHOULD be silently discarded and the event SHOULD 683 be logged. 685 Editor's note: Need to specify what happens when two reports of the 686 same type are received. 688 The OC-OLR AVP can be expanded with optional sub-AVPs only if a 689 legacy implementation can safely ignore them without breaking 690 backward compatibility for the given OC-Report-Type AVP value implied 691 report handling semantics. If the new sub-AVPs imply new semantics 692 for the report handling, then a new OC-Report-Type AVP value MUST be 693 defined. 695 4.4. OC-Sequence-Number AVP 697 The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64. 698 Its usage in the context of overload control is described in 699 Section 4.3. 701 From the functionality point of view, the OC-Sequence-Number AVP MUST 702 be used as a non-volatile increasing counter between two overload 703 control endpoints. The sequence number is only required to be unique 704 between two overload control endpoints. Sequence numbers are treated 705 in a uni-directional manner, i.e. two sequence numbers on each 706 direction between two endpoints are not related or correlated. 708 When generating sequence numbers, the new sequence number MUST be 709 greater than any sequence number in an active overload report 710 previously sent by the reporting node. This property MUST hold over 711 a reboot of the reporting node. 713 4.5. OC-Validity-Duration AVP 715 The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 716 and indicates in seconds the validity time of the overload report. 717 The number of seconds is measured after reception of the first OC-OLR 718 AVP with a given value of OC-Sequence-Number AVP. The default value 719 for the OC-Validity-Duration AVP is 5 (i.e., 5 seconds). When the 720 OC-Validity-Duration AVP is not present in the OC-OLR AVP, the 721 default value applies. Validity duration with values above 86400 722 (i.e.; 24 hours) MUST NOT be used. Invalid duration values are 723 treated as if the OC-Validity-Duration AVP were not present and 724 result in the default value being used. 726 A timeout of the overload report has specific concerns that need to 727 be taken into account by the endpoint acting on the earlier received 728 overload report(s). Section 4.7 discusses the impacts of timeout in 729 the scope of the traffic abatement algorithms. 731 When a reporting node has recovered from overload, it SHOULD 732 invalidate any existing overload reports in a timely matter. This 733 can be achieved by sending an updated overload report (meaning the 734 OLR contains a new sequence number) with the OC-Validity-Duration AVP 735 value set to zero ("0"). If the overload report is about to expire 736 naturally, the reporting node MAY choose to simply let it do so. 738 A reacting node MUST invalidate and remove an overload report that 739 expires without an explicit overload report containing an OC- 740 Validity-Duration value set to zero ("0"). 742 4.6. OC-Report-Type AVP 744 The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated. The 745 value of the AVP describes what the overload report concerns. The 746 following values are initially defined: 748 0 A host report. The overload treatment should apply to requests 749 for which all of the following conditions are true: 751 The Destination-Host AVP is present in the request and its value 752 matches the value of the Origin-Host AVP of the received message 753 that contained the OC-OLR AVP. 755 The value of the Destination-Realm AVP in the request matches the 756 value of the Origin-Realm AVP of the received message that 757 contained the OC-OLR AVP. 759 The value of the Application-ID in the Diameter Header of the 760 request matches the value of the Application-ID of the Diameter 761 Header of the received message that contained the OC-OLR AVP. 763 1 A realm report. The overload treatment should apply to requests 764 for which all of the following conditions are true: 766 The Destination-Host AVP is absent in the request. 768 The value of the Destination-Realm AVP in the request matches the 769 value of the Origin-Realm AVP of the received message that 770 contained the OC-OLR AVP. 772 The value of the Application-ID in the Diameter Header of the 773 request matches the value of the Application-ID of the Diameter 774 Header of the received message that contained the OC-OLR AVP. 776 Editor's note: There is still an open issue on the definition of 777 Realm reports and whether what report types should be supported. 778 There is consensus that host reports should be supported. There is 779 discussion on Realm reports and Realm-Routed-Request reports. The 780 above definition applies to Realm-Routed-Request reports where Realm 781 reports are defined to apply to all requests that match the realm, 782 independent of the presence, absence or value of the Destination-Host 783 AVP. 785 The default value of the OC-Report-Type AVP is 0 (i.e. the host 786 report). 788 The OC-Report-Type AVP is envisioned to be useful for situations 789 where a reacting node needs to apply different overload treatments 790 for different "types" of overload. For example, the reacting node(s) 791 might need to throttle differently requests sent to a specific server 792 (identified by the Destination-Host AVP in the request) and requests 793 that can be handled by any server in a realm. The example in 794 Appendix B.1 illustrates this usage. 796 When defining new report type values, the corresponding specification 797 MUST define the semantics of the new report types and how they affect 798 the OC-OLR AVP handling. The specification MUST also reserve a 799 corresponding new feature, see the OC-Supported-Features and OC- 800 Feature-Vector AVPs. 802 4.7. OC-Reduction-Percentage AVP 804 The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 805 and describes the percentage of the traffic that the sender is 806 requested to reduce, compared to what it otherwise would send. The 807 OC-Reduction-Percentage AVP applies to the default (loss) algorithm 808 specified in this specification. However, the AVP can be reused for 809 future abatement algorithms, if its semantics fit into the new 810 algorithm. 812 The value of the Reduction-Percentage AVP is between zero (0) and one 813 hundred (100). Values greater than 100 are ignored. The value of 814 100 means that all traffic is to be throttled, i.e. the reporting 815 node is under a severe load and ceases to process any new messages. 816 The value of 0 means that the reporting node is in a stable state and 817 has no need for the other endpoint to apply any traffic abatement. 818 The default value of the OC-Reduction-Percentage AVP is 0. When the 819 OC-Reduction-Percentage AVP is not present in the overload report, 820 the default value applies. 822 If an overload control endpoint comes out of the 100 percent traffic 823 reduction as a result of the overload report timing out, the 824 following concerns are RECOMMENDED to be applied. The reacting node 825 sending the traffic should be conservative and, for example, first 826 send "probe" messages to learn the overload condition of the 827 overloaded node before converging to any traffic amount/rate decided 828 by the sender. Similar concerns apply in all cases when the overload 829 report times out unless the previous overload report stated 0 percent 830 reduction. 832 Editor's note: Need to add additional guidance to slowly increase the 833 rate of traffic sent to avoid a sudden spike in traffic, as the spike 834 in traffic could result in oscillation of the need for overload 835 control. 837 4.8. Attribute Value Pair flag rules 839 +---------+ 840 |AVP flag | 841 |rules | 842 +----+----+ 843 AVP Section | |MUST| 844 Attribute Name Code Defined Value Type |MUST| NOT| 845 +--------------------------------------------------+----+----+ 846 |OC-Supported-Features TBD1 x.x Grouped | | V | 847 +--------------------------------------------------+----+----+ 848 |OC-OLR TBD2 x.x Grouped | | V | 849 +--------------------------------------------------+----+----+ 850 |OC-Sequence-Number TBD3 x.x Unsigned64 | | V | 851 +--------------------------------------------------+----+----+ 852 |OC-Validity-Duration TBD4 x.x Unsigned32 | | V | 853 +--------------------------------------------------+----+----+ 854 |OC-Report-Type TBD5 x.x Enumerated | | V | 855 +--------------------------------------------------+----+----+ 856 |OC-Reduction | | | 857 | -Percentage TBD8 x.x Unsigned32 | | V | 858 +--------------------------------------------------+----+----+ 859 |OC-Feature-Vector TBD6 x.x Unsigned64 | | V | 860 +--------------------------------------------------+----+----+ 862 As described in the Diameter base protocol [RFC6733], the M-bit 863 setting for a given AVP is relevant to an application and each 864 command within that application that includes the AVP. 866 The Diameter overload control AVPs SHOULD always be sent with the 867 M-bit cleared when used within existing Diameter applications to 868 avoid backward compatibility issues. Otherwise, when reused in newly 869 defined Diameter applications, the DOC related AVPs SHOULD have the 870 M-bit set. 872 5. Overload Control Operation 874 Editor's note: The concept of endpoints requires additional thought 875 and specification. 877 5.1. Overload Control Endpoints 879 The overload control solution can be considered as an overlay on top 880 of an arbitrary Diameter network. The overload control information 881 is exchanged over on a "DOIC association" established between two 882 communication endpoints. The endpoints, namely the "reacting node" 883 and the "reporting node" do not need to be adjacent Diameter peer 884 nodes, nor they need to be the end-to-end Diameter nodes in a typical 885 "client-server" deployment with multiple intermediate Diameter agent 886 nodes in between. The overload control endpoints are the two 887 Diameter nodes that decide to exchange overload control information 888 between each other. How the endpoints are determined is specific to 889 a deployment, a Diameter node role in that deployment and local 890 configuration. 892 The following diagrams illustrate the concept of Diameter Overload 893 End-Points and how they differ from the standard [RFC6733] defined 894 client, server and agent Diameter nodes. The following is the key to 895 the elements in the diagrams: 897 C Diameter client as defined in [RFC6733]. 899 S Diameter server as defined in [RFC6733]. 901 A Diameter agent, in either a relay or proxy mode, as defined in 902 [RFC6733]. 904 DEP Diameter Overload End-Point as defined in this document. In the 905 following figures a DEP may terminate two different DOIC 906 associations being a reporter and reactor at the same time. 908 Diameter Session A Diameter session as defined in [RFC6733]. 910 DOIC Association A DOIC association exists between two Diameter 911 Overload End-Points. One of the end-points is the overload 912 reporter and the other is the overload reactor. 914 Figure 2 illustrates the most basic configuration where a client is 915 connected directly to a server. In this case, the Diameter session 916 and the DOIC association are both between the client and server. 918 +-----+ +-----+ 919 | C | | S | 920 +-----+ +-----+ 921 | DEP | | DEP | 922 +--+--+ +--+--+ 923 | | 924 | | 925 |{Diameter Session}| 926 | | 927 |{DOIC Association}| 928 | | 930 Figure 2: Basic DOIC deployment 932 In Figure 3 there is an agent that is not participating directly in 933 the exchange of overload reports. As a result, the Diameter session 934 and the DOIC association are still established between the client and 935 the server. 937 +-----+ +-----+ +-----+ 938 | C | | A | | S | 939 +-----+ +--+--+ +-----+ 940 | DEP | | | DEP | 941 +--+--+ | +--+--+ 942 | | | 943 | | | 944 |----------{Diameter Session}---------| 945 | | | 946 |----------{DOIC Association}---------| 947 | | | 949 Figure 3: DOIC deployment with non participating agent 951 Figure 4 illustrates the case where the client does not support 952 Diameter overload. In this case, the DOIC association is between the 953 agent and the server. The agent handles the role of the reactor for 954 overload reports generated by the server. 956 +-----+ +-----+ +-----+ 957 | C | | A | | S | 958 +--+--+ +-----+ +-----+ 959 | | DEP | | DEP | 960 | +--+--+ +--+--+ 961 | | | 962 | | | 963 |----------{Diameter Session}---------| 964 | | | 965 | |{DOIC Association}| 966 | | | 968 Figure 4: DOIC deployment with non-DOIC client and DOIC enabled agent 970 In Figure 5 there is a DOIC association between the client and the 971 agent and a second DOIC association between the agent and the server. 972 One use case requiring this configuration is when the agent is 973 serving as a SFE for a set of servers. 975 +-----+ +-----+ +-----+ 976 | C | | A | | S | 977 +-----+ +-----+ +-----+ 978 | DEP | | DEP | | DEP | 979 +--+--+ +--+--+ +--+--+ 980 | | | 981 | | | 982 |----------{Diameter Session}---------| 983 | | | 984 |{DOIC Association}|{DOIC Association}| 985 | | and/or 986 |----------{DOIC Association}---------| 987 | | | 989 Figure 5: A deployment where all nodes support DOIC 991 Figure 6 illustrates a deployment where some clients support Diameter 992 overload control and some do not. In this case the agent must 993 support Diameter overload control for the non supporting client. It 994 might also need to have a DOIC association with the server, as shown 995 here, to handle overload for a server farm and/or for managing Realm 996 overload. 998 +-----+ +-----+ +-----+ +-----+ 999 | C1 | | C2 | | A | | S | 1000 +-----+ +--+--+ +-----+ +-----+ 1001 | DEP | | | DEP | | DEP | 1002 +--+--+ | +--+--+ +--+--+ 1003 | | | | 1004 | | | | 1005 |-------------------{Diameter Session}-------------------| 1006 | | | | 1007 | |--------{Diameter Session}-----------| 1008 | | | | 1009 |---------{DOIC Association}----------|{DOIC Association}| 1010 | | | and/or 1011 |-------------------{DOIC Association}-------------------| 1012 | | | | 1014 Figure 6: A deployment with DOIC and non-DOIC supporting clients 1016 Figure 7 illustrates a deployment where some agents support Diameter 1017 overload control and others do not. 1019 +-----+ +-----+ +-----+ +-----+ 1020 | C | | A | | A | | S | 1021 +-----+ +--+--+ +-----+ +-----+ 1022 | DEP | | | DEP | | DEP | 1023 +--+--+ | +--+--+ +--+--+ 1024 | | | | 1025 | | | | 1026 |-------------------{Diameter Session}-------------------| 1027 | | | | 1028 | | | | 1029 |---------{DOIC Association}----------|{DOIC Association}| 1030 | | | and/or 1031 |-------------------{DOIC Association}-------------------| 1032 | | | | 1034 Figure 7: A deployment with DOIC and non-DOIC supporting agents 1036 5.2. Piggybacking Principle 1038 The overload control AVPs defined in this specification have been 1039 designed to be piggybacked on top of existing application message 1040 exchanges. This is made possible by adding overload control top 1041 level AVPs, the OC-OLR AVP and the OC-Supported-Features AVP as 1042 optional AVPs into existing commands when the corresponding Command 1043 Code Format (CCF) specification allows adding new optional AVPs (see 1044 Section 1.3.4 of [RFC6733]). 1046 When added to existing commands, both OC-Feature-Vector and OC-OLR 1047 AVPs SHOULD have the M-bit flag cleared to avoid backward 1048 compatibility issues. 1050 A new application specification can incorporate the overload control 1051 mechanism specified in this document by making it mandatory to 1052 implement for the application and referencing this specification 1053 normatively. In such a case, the OC-Feature-Vector and OC-OLR AVPs 1054 reused in newly defined Diameter applications SHOULD have the M-bit 1055 flag set. However, it is the responsibility of the Diameter 1056 application designers to define how overload control mechanisms works 1057 on that application. 1059 Note that the overload control solution does not have fixed server 1060 and client roles. The endpoint role is determined based on the 1061 message type: whether the message is a request (i.e. sent by a 1062 "reacting node") or an answer (i.e. send by a "reporting node"). 1063 Therefore, in a typical "client-server" deployment, the "client" MAY 1064 report its overload condition to the "server" for any server 1065 initiated message exchange. An example of such is the server 1066 requesting a re-authentication from a client. 1068 5.3. Capability Announcement 1070 Since the overload control solution relies on the piggybacking 1071 principle for the overload reporting and the overload control 1072 endpoint are not adjacent peers, finding out whether the other 1073 endpoint supports overload control or the common traffic abatement 1074 algorithm to apply for the traffic. The approach defined in this 1075 specification for end-to-end capability announcement relies on the 1076 exchange of the OC-Supported-Features AVPs between the endpoints. 1077 The feature announcement solution also works when carried out on 1078 existing applications. For the newly defined applications the 1079 negotiation can be more exact based on the application specification. 1081 Editor's note: Suggest removing the reference to the feature 1082 announcement solution. 1084 5.3.1. Reacting Node Endpoint Considerations 1086 The basic principle is that the request message initiating endpoint 1087 (i.e. the "reacting node") announces its support for the overload 1088 control mechanism by including in the request message the OC- 1089 Supported-Features AVP with the capabilities it supports and is 1090 willing to use for this Diameter transaction. The lifetime of a 1091 capability announcement is limited to a single transaction. As a 1092 result, the reacting node MUST include the capability announcement in 1093 all request messages. 1095 Once the endpoint that initiated the request message receives an 1096 answer message from the remote endpoint, it can detect from the 1097 received answer message whether the remote endpoint supports the 1098 overload control solution and in a case it does, what features are 1099 supported. The support for the overload control solution is based on 1100 the presence of the OC-Supported-Features AVP in the Diameter answer. 1102 5.3.2. Reporting Node Endpoint Considerations 1104 When a remote endpoint (i.e. a "reporting node") receives a request 1105 message, it can detect whether the request message initiating 1106 endpoint supports the overload control solution based on the presence 1107 of the OC-Supported-Features AVP. For the newly defined applications 1108 the overload control solution support can be part of the application 1109 specification. Based on the content of the OC-Supported-Features AVP 1110 the request message receiving endpoint knows what overload control 1111 functionality the other endpoint supports and then acts accordingly 1112 for the subsequent answer messages it initiates. The reporting node 1113 MUST include the OC-Supported-Features AVP in all response messages 1114 for transactions where the request message included the OC-Supported- 1115 Features AVP. The reporting node MUST announce support of the single 1116 algorithm that the reporting node will request the reacting node to 1117 use to mitigate overload instances. The reporting node MUST NOT 1118 change the selected algorithm during a period of time that it is in 1119 an overload state and, as a result, is sending OC-OLR AVPs in answer 1120 messages. 1122 Note: There will always be at least one algorithm supported by both 1123 the reacting and reporting nodes as all nodes that support DOIC must 1124 support the loss algorithm defined in this document. 1126 The handling of feature bits in the OC-Feature-Vector AVP that are 1127 not associated with overload abatement algorithms MUST be specified 1128 by the extensions that define the features. 1130 The reporting node MUST NOT include the OC-Supported-Features AVP, 1131 OC-OLR AVP or any other overload control AVPs defined in extension 1132 drafts in response messages for transactions where the request 1133 message does not include the OC-Supported-Features AVP. Lack of the 1134 OC-Supported-Features AVP in the request message indicates that the 1135 sender of the request message does not support DOIC. 1137 5.3.3. Agent Considerations 1139 Editor's note -- Need to add this section. 1141 5.4. Protocol Extensibility 1143 The overload control solution can be extended, e.g. with new traffic 1144 abatement algorithms, new report types or other new functionality. 1145 The new features and algorithms MUST be registered with the IANA and 1146 for use with the OC-Supported-Features for announcing the support for 1147 the new features (see Section 7 for the required procedures). 1149 It should be noted that [RFC6733] defined Grouped AVP extension 1150 mechanisms also apply. This allows, for example, defining a new 1151 feature that is mandatory to understand even when piggybacked on an 1152 existing applications. More specifically, the sub-AVPs inside the 1153 OC-OLR AVP MAY have the M-bit set. However, when overload control 1154 AVPs are piggybacked on top of an existing applications, setting 1155 M-bit in sub-AVPs is NOT RECOMMENDED. 1157 5.5. Overload Report Processing 1159 5.5.1. Overload Control State 1161 Both reacting and reporting nodes maintain an overload control state 1162 (OCS) for each endpoint (a host or a realm) they communicate with and 1163 both endpoints have announced support for DOIC. See Sections 4.1 and 1164 5.3 for discussion about how the support for DOIC is determined. 1166 5.5.1.1. Overload Control State for Reacting Nodes 1168 A reacting node maintains the following OCS per supported Diameter 1169 application: 1171 o A host-type Overload Control State for each Destination-Host 1172 towards which it sends host-type requests and 1174 o A realm-type Overload Control State for each Destination-Realm 1175 towards which it sends realm-type requests. 1177 A host-type Overload Control State may be identified by the pair of 1178 Application-Id and Destination-Host. A realm-type Overload Control 1179 State may be identified by the pair of Application-Id and 1180 Destination-Realm. The host-type/realm-type Overload Control State 1181 for a given pair of Application and Destination-Host / Destination- 1182 Realm could include the following information: 1184 o Sequence number (as received in OC-OLR) 1186 o Time of expiry (deviated from validity duration as received in OC- 1187 OLR and time of reception) 1189 o Selected Abatement Algorithm (as received in OC-Supported- 1190 Features) 1192 o Algorithm specific input data (as received within OC-OLR, e.g. 1193 Reduction Percentage for Loss) 1195 5.5.1.2. Overload Control States for Reporting Nodes 1197 A reporting node maintains per supported Diameter application and per 1198 supported (and eventually selected) Abatement Algorithm an Overload 1199 Control State. 1201 An Overload Control State may be identified by the pair of 1202 Application-Id and supported Abatement Algorithm. 1204 The Overload Control State for a given pair of Application and 1205 Abatement Algorithm could include the information: 1207 o Sequence number 1209 o Validity Duration and Expiry Time 1211 o Algorithm specific input data (e.g. Reduction Percentage for Loss) 1213 Overload Control States for reporting nodes containing a validity 1214 duration of 0 sec. should not expire before any previously sent 1215 (stale) OLR has timed out at any reacting node. 1217 5.5.1.3. Maintaining Overload Control State 1219 Reacting nodes create a host-type OCS identified by OCS-Id = (app-id 1220 ,host-id) when receiving an answer message of application app-id 1221 containing an Orig-Host of host-id and a host-type OC-OLR AVP unless 1222 such host-type OCS already exists. 1224 Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id 1225 ,realm-id) when receiving an answer message of application app-id 1226 containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP 1227 unless such realm type OCS already exists. 1229 Reacting nodes delete an OCS when it expires (i.e. when current time 1230 minus reception time is greater than validity duration). 1232 Reacting nodes update the host-type OCS identified by OCS-Id = (app- 1233 id,host-id) when receiving an answer message of application app-id 1234 containing an Orig-Host of host-id and a host-type OC-OLR AVP with a 1235 sequence number higher than the stored sequence number. 1237 Reacting nodes update the realm-type OCS identified by OCS-Id = (app- 1238 id,realm-id) when receiving an answer message of application app-id 1239 containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP with 1240 a sequence number higher than the stored sequence number. 1242 Reacting nodes do not delete an OCS when receiving an answer message 1243 that does not contain an OC-OLR AVP (i.e. absence of OLR means "no 1244 change"). 1246 Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) 1247 when receiving a request of application app-id containing an OC- 1248 Supported-Features AVP indicating support of the Abatement Algorithm 1249 Alg (which the reporting node selects) while being overloaded, unless 1250 such OCS already exists. 1252 Reporting nodes delete an OCS when it expires. 1254 Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) 1255 when they detect the need to modify the requested amount of 1256 application app-id traffic reduction. 1258 5.5.2. Reacting Node Considerations 1260 Once a reacting node receives an OC-OLR AVP from a reporting node, it 1261 applies traffic abatement based on the selected algorithm with the 1262 reporting node and the current overload condition. The reacting node 1263 learns the reporting node supported abatement algorithms directly 1264 from the received answer message containing the OC-Supported-Features 1265 AVP. 1267 The received OC-Supported-Features AVP does not change the existing 1268 overload condition and/or traffic abatement algorithm settings if the 1269 OC-Sequence-Number AVP contains a value that is equal to the 1270 previously received/recorded value. If the OC-Supported-Features AVP 1271 is received for the first time for the reporting node or the OC- 1272 Sequence-Number AVP value is less than the previously received/ 1273 recorded value (and is outside the valid overflow window), then the 1274 sequence number is stale (e.g. an intentional or unintentional 1275 replay) and SHOULD be silently discarded. 1277 As described in Section 4.3, the OC-OLR AVP contains the necessary 1278 information for the overload condition on the reporting node. 1280 From the OC-Report-Type AVP contained in the OC-OLR AVP, the reacting 1281 node learns whether the overload condition report concerns a specific 1282 host (as identified by the Origin-Host AVP of the answer message 1283 containing the OC-OLR AVP) or the entire realm (as identified by the 1284 Origin-Realm AVP of the answer message containing the OC-OLR AVP). 1285 The reacting node learns the Diameter application to which the 1286 overload report applies from the Application-ID of the answer message 1287 containing the OC-OLR AVP. The reacting node MUST use this 1288 information as an input for its traffic abatement algorithm. The 1289 idea is that the reacting node applies different handling of the 1290 traffic abatement, whether sent request messages are targeted to a 1291 specific host (identified by the Diameter-Host AVP in the request) or 1292 to any host in a realm (when only the Destination-Realm AVP is 1293 present in the request). Note that future specifications MAY define 1294 new OC-Report-Type AVP values that imply different handling of the 1295 OC-OLR AVP. For example, in a form of new additional AVPs inside the 1296 Grouped OC-OLR AVP that would define report target in a finer 1297 granularity than just a host. 1299 Editor's note: The above behavior for Realm reports is inconsistent 1300 with the definition of realm reports in section Section 4.6. 1302 In the context of this specification and the default traffic 1303 abatement algorithm, the OC-Reduction-Percentage AVP value MUST be 1304 interpreted in the following way: 1306 value == 0 1308 Indicates that no traffic reduction has been requested. As a 1309 result the overload state, including the sequence number, MUST NOT 1310 be removed and future overload reports of the same type from the 1311 same reporting node must follow the rules for new sequence 1312 numbers. 1314 value == 100 1316 Indicates that the reporting node (or realm) does not want to 1317 receive any traffic from the reacting node for the application the 1318 report concerns. The reacting node MUST not send traffic to the 1319 reporting node (or realm) as long as the overload condition 1320 changes or expires. 1322 0 < value < 100 1324 Indicates that the reporting node urges the reacting node to 1325 reduce its traffic by a given percentage. For example if an OC- 1326 Reduction-Percentage value of 10 has been received, the reacting 1327 node which would otherwise send 100 requests MUST only send 90 1328 requests to the reporting node. How the reacting node achieves 1329 the "true reduction" in transactions leading to the sent request 1330 messages is up to the implementation. The reacting node MAY 1331 simply drop every 10th request from its output queue and let the 1332 generic application logic try to recover from it. 1334 If the OC-OLR AVP is received for the first time, the reacting node 1335 MUST create overload control state associated with the related realm 1336 or a specific host in the realm identified in the message carrying 1337 the OC-OLR AVP, as described in Section 5.5.1. 1339 If the value of the OC-Sequence-Number AVP contained in the received 1340 OC-OLR AVP is equal to or less than the value stored in an existing 1341 overload control state, the received OC-OLR AVP SHOULD be silently 1342 discarded. If the value of the OC-Sequence-Number AVP contained in 1343 the received OC-OLR AVP is greater than the value stored in an 1344 existing overload control state or there is no previously recorded 1345 sequence number, the reacting node MUST update the overload control 1346 state associated with the realm or the specific node in the realm. 1348 When an overload control state is created or updated, the reacting 1349 node MUST apply the traffic abatement requested in the OC-OLR AVP 1350 using the algorithm announced in the OC-Supported-Features AVP 1351 contained in the received answer message along with the OC-OLR AVP. 1353 The validity duration of the overload information contained in the 1354 OC-OLR AVP is either explicitly indicated in the OC-Validity-Duration 1355 AVP or is implicitly equals to the default value (5 seconds) if the 1356 OC-Validity-Duration AVP is absent. The reacting node MUST maintain 1357 the validity duration in the overload control state. Once the 1358 validity duration times out, the reacting node MUST assume the 1359 overload condition reported in a previous OC-OLR AVP has ended. 1361 A value of zero ("0") received in the OC-Validity-Duration in an 1362 updated overload report indicates that the overload condition has 1363 ended and that the overload state is no longer valid. 1365 In the case that the validity duration expires or is explicitly 1366 signaled as being no longer valid the state associated with the 1367 overload report MUST be removed and any abatement associated with the 1368 overload report MUST be ended in a controlled fashion. After 1369 removing the overload state the sequence number MUST NOT be used for 1370 future comparisons of sequence numbers. 1372 5.5.3. Reporting Node Considerations 1374 A reporting node is a Diameter node inserting an OC-OLR AVP in a 1375 Diameter message in order to inform a reacting node about an overload 1376 condition and request Diameter traffic abatement. 1378 The operation on the reporting node is straight forward. The 1379 reporting node learns the capabilities of the reacting node when it 1380 receives the OC-Supported-Features AVP as part of any Diameter 1381 request message. If the reporting node shares at least one common 1382 feature with the reacting node, then the DOIC can be enabled between 1383 these two endpoints. See Section 5.3 for further discussion on the 1384 capability and feature announcement between two endpoints. 1386 When a traffic reduction is required due to an overload condition and 1387 the overload control solution is supported by the sender of the 1388 Diameter request, the reporting node MUST include an OC-Supported- 1389 Features AVP and an OC-OLR AVP in the corresponding Diameter answer. 1390 The OC-OLR AVP contains the required traffic reduction and the OC- 1391 Supported-Features AVP indicates the traffic abatement algorithm to 1392 apply. This algorithm MUST be one of the algorithms advertised by 1393 the request sender. 1395 A reporting node MAY rely on the OC-Validity-Duration AVP values for 1396 the implicit overload control state cleanup on the reacting node. 1397 However, it is RECOMMENDED that the reporting node always explicitly 1398 indicates the end of a overload condition. 1400 The reporting node SHOULD indicate the end of an overload occurrence 1401 by sending a new OLR with OC-Validity-Duration set to a value of zero 1402 ("0"). The reporting node SHOULD insure that all reacting nodes 1403 receive the updated overload report. 1405 5.5.4. Agent Considerations 1407 Editor's note -- Need to add this section. 1409 6. Transport Considerations 1411 In order to reduce overload control introduced additional AVP and 1412 message processing it might be desirable/beneficial to signal whether 1413 the Diameter command carries overload control information that should 1414 be of interest of an overload aware Diameter node. 1416 Should such indication be include is not part of this specification. 1417 It has not either been concluded at what layer such possible 1418 indication should be. Obvious candidates include transport layer 1419 protocols (e.g., SCTP PPID or TCP flags) or Diameter command header 1420 flags. 1422 7. IANA Considerations 1424 7.1. AVP codes 1426 New AVPs defined by this specification are listed in Section 4. All 1427 AVP codes allocated from the 'Authentication, Authorization, and 1428 Accounting (AAA) Parameters' AVP Codes registry. 1430 7.2. New registries 1432 Three new registries are needed under the 'Authentication, 1433 Authorization, and Accounting (AAA) Parameters' registry. 1435 Section 4.2 defines a new "Overload Control Feature Vector" registry 1436 including the initial assignments. New values can be added into the 1437 registry using the Specification Required policy [RFC5226]. See 1438 Section 4.2 for the initial assignment in the registry. 1440 Section 4.6 defines a new "Overload Report Type" registry with its 1441 initial assignments. New types can be added using the Specification 1442 Required policy [RFC5226]. 1444 8. Security Considerations 1446 This mechanism gives Diameter nodes the ability to request that 1447 downstream nodes send fewer Diameter requests. Nodes do this by 1448 exchanging overload reports that directly affect this reduction. 1449 This exchange is potentially subject to multiple methods of attack, 1450 and has the potential to be used as a Denial-of-Service (DoS) attack 1451 vector. 1453 Overload reports may contain information about the topology and 1454 current status of a Diameter network. This information is 1455 potentially sensitive. Network operators may wish to control 1456 disclosure of overload reports to unauthorized parties to avoid its 1457 use for competitive intelligence or to target attacks. 1459 Diameter does not include features to provide end-to-end 1460 authentication, integrity protection, or confidentiality. This may 1461 cause complications when sending overload reports between non- 1462 adjacent nodes. 1464 8.1. Potential Threat Modes 1466 The Diameter protocol involves transactions in the form of requests 1467 and answers exchanged between clients and servers. These clients and 1468 servers may be peers, that is,they may share a direct transport (e.g. 1469 TCP or SCTP) connection, or the messages may traverse one or more 1470 intermediaries, known as Diameter Agents. Diameter nodes use TLS, 1471 DTLS, or IPSec to authenticate peers, and to provide confidentiality 1472 and integrity protection of traffic between peers. Nodes can make 1473 authorization decisions based on the peer identities authenticated at 1474 the transport layer. 1476 When agents are involved, this presents an effectively hop-by-hop 1477 trust model. That is, a Diameter client or server can authorize an 1478 agent for certain actions, but it must trust that agent to make 1479 appropriate authorization decisions about its peers, and so on. 1481 Since confidentiality and integrity protection occurs at the 1482 transport layer. Agents can read, and perhaps modify, any part of a 1483 Diameter message, including an overload report. 1485 There are several ways an attacker might attempt to exploit the 1486 overload control mechanism. An unauthorized third party might inject 1487 an overload report into the network. If this third party is upstream 1488 of an agent, and that agent fails to apply proper authorization 1489 policies, downstream nodes may mistakenly trust the report. This 1490 attack is at least partially mitigated by the assumption that nodes 1491 include overload reports in Diameter answers but not in requests. 1493 This requires an attacker to have knowledge of the original request 1494 in order to construct a response. Therefore, implementations SHOULD 1495 validate that an answer containing an overload report is a properly 1496 constructed response to a pending request prior to acting on the 1497 overload report. 1499 A similar attack involves an otherwise authorized Diameter node that 1500 sends an inappropriate overload report. For example, a server for 1501 the realm "example.com" might send an overload report indicating that 1502 a competitor's realm "example.net" is overloaded. If other nodes act 1503 on the report, they may falsely believe that "example.net" is 1504 overloaded, effectively reducing that realm's capacity. Therefore, 1505 it's critical that nodes validate that an overload report received 1506 from a peer actually falls within that peer's responsibility before 1507 acting on the report or forwarding the report to other peers. For 1508 example, an overload report from an peer that applies to a realm not 1509 handled by that peer is suspect. 1511 An attacker might use the information in an overload report to assist 1512 in certain attacks. For example, an attacker could use information 1513 about current overload conditions to time a DoS attack for maximum 1514 effect, or use subsequent overload reports as a feedback mechanism to 1515 learn the results of a previous or ongoing attack. 1517 8.2. Denial of Service Attacks 1519 Diameter overload reports can cause a node to cease sending some or 1520 all Diameter requests for an extended period. This makes them a 1521 tempting vector for DoS tacks. Furthermore, since Diameter is almost 1522 always used in support of other protocols, a DoS attack on Diameter 1523 is likely to impact those protocols as well. Therefore, Diameter 1524 nodes MUST NOT honor or forward overload reports from unauthorized or 1525 otherwise untrusted sources. 1527 8.3. Non-Compliant Nodes 1529 When a Diameter node sends an overload report, it cannot assume that 1530 all nodes will comply. A non-compliant node might continue to send 1531 requests with no reduction in load. Requirement 28 [RFC7068] 1532 indicates that the overload control solution cannot assume that all 1533 Diameter nodes in a network are necessarily trusted, and that 1534 malicious nodes not be allowed to take advantage of the overload 1535 control mechanism to get more than their fair share of service. 1537 In the absence of an overload control mechanism, Diameter nodes need 1538 to implement strategies to protect themselves from floods of 1539 requests, and to make sure that a disproportionate load from one 1540 source does not prevent other sources from receiving service. For 1541 example, a Diameter server might reject a certain percentage of 1542 requests from sources that exceed certain limits. Overload control 1543 can be thought of as an optimization for such strategies, where 1544 downstream nodes never send the excess requests in the first place. 1545 However, the presence of an overload control mechanism does not 1546 remove the need for these other protection strategies. 1548 8.4. End-to End-Security Issues 1550 The lack of end-to-end security features makes it far more difficult 1551 to establish trust in overload reports that originate from non- 1552 adjacent nodes. Any agents in the message path may insert or modify 1553 overload reports. Nodes must trust that their adjacent peers perform 1554 proper checks on overload reports from their peers, and so on, 1555 creating a transitive-trust requirement extending for potentially 1556 long chains of nodes. Network operators must determine if this 1557 transitive trust requirement is acceptable for their deployments. 1558 Nodes supporting Diameter overload control MUST give operators the 1559 ability to select which peers are trusted to deliver overload 1560 reports, and whether they are trusted to forward overload reports 1561 from non-adjacent nodes. 1563 The lack of end-to-end confidentiality protection means that any 1564 Diameter agent in the path of an overload report can view the 1565 contents of that report. In addition to the requirement to select 1566 which peers are trusted to send overload reports, operators MUST be 1567 able to select which peers are authorized to receive reports. A node 1568 MUST not send an overload report to a peer not authorized to receive 1569 it. Furthermore, an agent MUST remove any overload reports that 1570 might have been inserted by other nodes before forwarding a Diameter 1571 message to a peer that is not authorized to receive overload reports. 1573 At the time of this writing, the DIME working group is studying 1574 requirements for adding end-to-end security 1575 [I-D.ietf-dime-e2e-sec-req] features to Diameter. These features, 1576 when they become available, might make it easier to establish trust 1577 in non-adjacent nodes for overload control purposes. Readers should 1578 be reminded, however, that the overload control mechanism encourages 1579 Diameter agents to modify AVPs in, or insert additional AVPs into, 1580 existing messages that are originated by other nodes. If end-to-end 1581 security is enabled, there is a risk that such modification could 1582 violate integrity protection. The details of using any future 1583 Diameter end-to-end security mechanism with overload control will 1584 require careful consideration, and are beyond the scope of this 1585 document. 1587 9. Contributors 1589 The following people contributed substantial ideas, feedback, and 1590 discussion to this document: 1592 o Eric McMurry 1594 o Hannes Tschofenig 1596 o Ulrich Wiehe 1598 o Jean-Jacques Trottin 1600 o Maria Cruz Bartolome 1602 o Martin Dolly 1604 o Nirav Salot 1606 o Susan Shishufeng 1608 10. References 1610 10.1. Normative References 1612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1613 Requirement Levels", BCP 14, RFC 2119, March 1997. 1615 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1616 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1617 May 2008. 1619 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1620 Time Protocol Version 4: Protocol and Algorithms 1621 Specification", RFC 5905, June 2010. 1623 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1624 "Diameter Base Protocol", RFC 6733, October 2012. 1626 10.2. Informative References 1628 [Cx] 3GPP, , "ETSI TS 129 229 V11.4.0", August 2013. 1630 [I-D.ietf-dime-e2e-sec-req] 1631 Tschofenig, H., Korhonen, J., Zorn, G., and K. Pillay, 1632 "Diameter AVP Level Security: Scenarios and Requirements", 1633 draft-ietf-dime-e2e-sec-req-00 (work in progress), 1634 September 2013. 1636 [PCC] 3GPP, , "ETSI TS 123 203 V11.12.0", December 2013. 1638 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 1639 Loughney, "Diameter Credit-Control Application", RFC 4006, 1640 August 2005. 1642 [RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, 1643 "Clarifications on the Routing of Diameter Requests Based 1644 on the Username and the Realm", RFC 5729, December 2009. 1646 [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control 1647 Requirements", RFC 7068, November 2013. 1649 [S13] 3GPP, , "ETSI TS 129 272 V11.9.0", December 2012. 1651 Appendix A. Issues left for future specifications 1653 The base solution for the overload control does not cover all 1654 possible use cases. A number of solution aspects were intentionally 1655 left for future specification and protocol work. 1657 A.1. Additional traffic abatement algorithms 1659 This specification describes only means for a simple loss based 1660 algorithm. Future algorithms can be added using the designed 1661 solution extension mechanism. The new algorithms need to be 1662 registered with IANA. See Sections 4.1 and 7 for the required IANA 1663 steps. 1665 A.2. Agent Overload 1667 This specification focuses on Diameter end-point (server or client) 1668 overload. A separate extension will be required to outline the 1669 handling the case of agent overload. 1671 A.3. DIAMETER_TOO_BUSY clarifications 1673 The current [RFC6733] behavior in a case of DIAMETER_TOO_BUSY is 1674 somewhat under specified. For example, there is no information how 1675 long the specific Diameter node is willing to be unavailable. A 1676 specification updating [RFC6733] should clarify the handling of 1677 DIAMETER_TOO_BUSY from the error answer initiating Diameter node 1678 point of view and from the original request initiating Diameter node 1679 point of view. Further, the inclusion of possible additional 1680 information providing AVPs should be discussed and possible be 1681 recommended to be used. 1683 Appendix B. Examples 1685 B.1. Mix of Destination-Realm routed requests and Destination-Host 1686 routed requests 1688 Diameter allows a client to optionally select the destination server 1689 of a request, even if there are agents between the client and the 1690 server. The client does this using the Destination-Host AVP. In 1691 cases where the client does not care if a specific server receives 1692 the request, it can omit Destination-Host and route the request using 1693 the Destination-Realm and Application Id, effectively letting an 1694 agent select the server. 1696 Clients commonly send mixtures of Destination-Host and Destination- 1697 Realm routed requests. For example, in an application that uses user 1698 sessions, a client typically won't care which server handles a 1699 session-initiating requests. But once the session is initiated, the 1700 client will send all subsequent requests in that session to the same 1701 server. Therefore it would send the initial request with no 1702 Destination-Host AVP. If it receives a successful answer, the client 1703 would copy the Origin-Host value from the answer message into a 1704 Destination-Host AVP in each subsequent request in the session. 1706 An agent has very limited options in applying overload abatement to 1707 requests that contain Destination-Host AVPs. It typically cannot 1708 route the request to a different server than the one identified in 1709 Destination-Host. It's only remaining options are to throttle such 1710 requests locally, or to send an overload report back towards the 1711 client so the client can throttle the requests. The second choice is 1712 usually more efficient, since it prevents any throttled requests from 1713 being sent in the first place, and removes the agent's need to send 1714 errors back to the client for each dropped request. 1716 On the other hand, an agent has much more leeway to apply overload 1717 abatement for requests that do not contain Destination-Host AVPs. If 1718 the agent has multiple servers in its peer table for the given realm 1719 and application, it can route such requests to other, less overloaded 1720 servers. 1722 If the overload severity increases, the agent may reach a point where 1723 there is not sufficient capacity across all servers to handle even 1724 realm-routed requests. In this case, the realm itself can be 1725 considered overloaded. The agent may need the client to throttle 1726 realm-routed requests in addition to Destination-Host routed 1727 requests. The overload severity may be different for each server, 1728 and the severity for the realm at is likely to be different than for 1729 any specific server. Therefore, an agent may need to forward, or 1730 originate, multiple overload reports with differing ReportType and 1731 Reduction-Percentage values. 1733 Figure 8 illustrates such a mixed-routing scenario. In this example, 1734 the servers S1, S2, and S3 handle requests for the realm "realm". 1735 Any of the three can handle requests that are not part of a user 1736 session (i.e. routed by Destination-Realm). But once a session is 1737 established, all requests in that session must go to the same server. 1739 Client Agent S1 S2 S3 1740 | | | | | 1741 |(1) Request (DR:realm) | | 1742 |-------->| | | | 1743 | | | | | 1744 | | | | | 1745 | |Agent selects S1 | | 1746 | | | | | 1747 | | | | | 1748 | | | | | 1749 | |(2) Request (DR:realm) | 1750 | |-------->| | | 1751 | | | | | 1752 | | | | | 1753 | | |S1 overloaded, returns OLR 1754 | | | | | 1755 | | | | | 1756 | | | | | 1757 | |(3) Answer (OR:realm,OH:S1,OLR:RT=DH) 1758 | |<--------| | | 1759 | | | | | 1760 | | | | | 1761 | |sees OLR,routes DR traffic to S2&S3 1762 | | | | | 1763 | | | | | 1764 | | | | | 1765 |(4) Answer (OR:realm,OH:S1, OLR:RT=DH) | 1766 |<--------| | | | 1767 | | | | | 1768 | | | | | 1769 |Client throttles requests with DH:S1 | 1770 | | | | | 1771 | | | | | 1772 | | | | | 1773 |(5) Request (DR:realm) | | 1774 |-------->| | | | 1775 | | | | | 1776 | | | | | 1777 | |Agent selects S2 | | 1778 | | | | | 1779 | | | | | 1780 | | | | | 1781 | |(6) Request (DR:realm) | 1782 | |------------------>| | 1783 | | | | | 1784 | | | | | 1785 | | | |S2 is overloaded... 1786 | | | | | 1787 | | | | | 1788 | | | | | 1789 | |(7) Answer (OH:S2, OLR:RT=DH)| 1790 | |<------------------| | 1791 | | | | | 1792 | | | | | 1793 | |Agent sees OLR, realm now overloaded 1794 | | | | | 1795 | | | | | 1796 | | | | | 1797 |(8) Answer (OR:realm,OH:S2, OLR:RT=DH, OLR: RT=R) 1798 |<--------| | | | 1799 | | | | | 1800 | | | | | 1801 |Client throttles DH:S1, DH:S2, and DR:realm 1802 | | | | | 1803 | | | | | 1804 | | | | | 1805 | | | | | 1806 | | | | | 1808 Figure 8: Mix of Destination-Host and Destination-Realm Routed 1809 Requests 1811 1. The client sends a request with no Destination-Host AVP (that is, 1812 a Destination-Realm routed request.) 1814 2. The agent follows local policy to select a server from its peer 1815 table. In this case, the agent selects S2 and forwards the 1816 request. 1818 3. S1 is overloaded. It sends a answer indicating success, but also 1819 includes an overload report. Since the overload report only 1820 applies to S1, the ReportType is "Destination-Host". 1822 4. The agent sees the overload report, and records that S1 is 1823 overloaded by the value in the Reduction-Percentage AVP. It 1824 begins diverting the indicated percentage of realm-routed traffic 1825 from S1 to S2 and S3. Since it can't divert Destination-Host 1826 routed traffic, it forwards the overload report to the client. 1827 This effectively delegates the throttling of traffic with 1828 Destination-Host:S1 to the client. 1830 5. The client sends another Destination-Realm routed request. 1832 6. The agent selects S2, and forwards the request. 1834 7. It turns out that S2 is also overloaded, perhaps due to all that 1835 traffic it took over for S1. S2 returns an successful answer 1836 containing an overload report. Since this report only applies to 1837 S2, the ReportType is "Destination-Host". 1839 8. The agent sees that S2 is also overloaded by the value in 1840 Reduction-Percentage. This value is probably different than the 1841 value from S1's report. The agent diverts the remaining traffic 1842 to S3 as best as it can, but it calculates that the remaining 1843 capacity across all three servers is no longer sufficient to 1844 handle all of the realm-routed traffic. This means the realm 1845 itself is overloaded. The realm's overload percentage is most 1846 likely different than that for either S1 or S2. The agent 1847 forward's S2's report back to the client in the Diameter answer. 1848 Additionally, the agent generates a new report for the realm of 1849 "realm", and inserts that report into the answer. The client 1850 throttles requests with Destination-Host:S1 at one rate, requests 1851 with Destination-Host:S2 at another rate, and requests with no 1852 Destination-Host AVP at yet a third rate. (Since S3 has not 1853 indicated overload, the client does not throttle requests with 1854 Destination-Host:S3.) 1856 Authors' Addresses 1858 Jouni Korhonen (editor) 1859 Broadcom 1860 Porkkalankatu 24 1861 Helsinki FIN-00180 1862 Finland 1864 Email: jouni.nospam@gmail.com 1865 Steve Donovan (editor) 1866 Oracle 1867 7460 Warren Parkway 1868 Frisco, Texas 75034 1869 United States 1871 Email: srdonovan@usdonovans.com 1873 Ben Campbell 1874 Oracle 1875 7460 Warren Parkway 1876 Frisco, Texas 75034 1877 United States 1879 Email: ben@nostrum.com 1881 Lionel Morand 1882 Orange Labs 1883 38/40 rue du General Leclerc 1884 Issy-Les-Moulineaux Cedex 9 92794 1885 France 1887 Phone: +33145296257 1888 Email: lionel.morand@orange.com