idnits 2.17.00 (12 Aug 2021) /tmp/idnits12922/draft-ietf-dime-ovli-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 : ---------------------------------------------------------------------------- ** 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 584 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: 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 (November 22, 2013) is 3102 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-dime-e2e-sec-req has been published as RFC 7966 == Outdated reference: draft-ietf-dime-overload-reqs has been published as RFC 7068 -- Obsolete informational reference (is this intentional?): RFC 4006 (Obsoleted by RFC 8506) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions J. Korhonen, Ed. 3 (DIME) Broadcom 4 Internet-Draft S. Donovan 5 Intended status: Standards Track B. Campbell 6 Expires: May 26, 2014 Oracle 7 November 22, 2013 9 Diameter Overload Indication Conveyance 10 draft-ietf-dime-ovli-00.txt 12 Abstract 14 This specification documents a Diameter Overload Control (DOC) base 15 solution and the dissemination of the overload report information. 17 Requirements 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 26, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 59 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Architectural Assumptions . . . . . . . . . . . . . . . . 6 61 3.1.1. Application Classification . . . . . . . . . . . . . . 7 62 3.1.2. Application Type Overload Implications . . . . . . . . 8 63 3.1.3. Request Transaction Classification . . . . . . . . . . 9 64 3.1.4. Request Type Overload Implications . . . . . . . . . . 10 65 3.1.5. Diameter Deployment Scenarios . . . . . . . . . . . . 11 66 3.1.6. Diameter Agent Behaviour . . . . . . . . . . . . . . . 12 67 3.1.7. Simplified Example Architecture . . . . . . . . . . . 13 68 3.2. Conveyance of the Overload Indication . . . . . . . . . . 14 69 3.2.1. Negotiation and Versioning . . . . . . . . . . . . . . 14 70 3.2.2. Transmission of the Attribute Value Pairs . . . . . . 14 71 3.3. Overload Condition Indication . . . . . . . . . . . . . . 15 72 4. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 15 73 4.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 15 74 4.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.3. TimeStamp AVP . . . . . . . . . . . . . . . . . . . . . . 17 76 4.4. ValidityDuration AVP . . . . . . . . . . . . . . . . . . . 17 77 4.5. ReportType AVP . . . . . . . . . . . . . . . . . . . . . . 17 78 4.6. Reduction-Percentage AVP . . . . . . . . . . . . . . . . . 18 79 4.7. Attribute Value Pair flag rules . . . . . . . . . . . . . 19 80 5. Overload Control Operation . . . . . . . . . . . . . . . . . . 19 81 5.1. Overload Control Endpoints . . . . . . . . . . . . . . . . 19 82 5.2. Piggybacking Principle . . . . . . . . . . . . . . . . . . 23 83 5.3. Capability Announcement . . . . . . . . . . . . . . . . . 23 84 5.3.1. Request Message Initiator Endpoint Considerations . . 24 85 5.3.2. Answer Message Initiating Endpoint Considerations . . 24 86 5.4. Protocol Extensibility . . . . . . . . . . . . . . . . . . 25 87 5.5. Overload Report Processing . . . . . . . . . . . . . . . . 25 88 5.5.1. Sender Endpoint Considerations . . . . . . . . . . . . 25 89 5.5.2. Receiver Endpoint Considerations . . . . . . . . . . . 25 90 6. Transport Considerations . . . . . . . . . . . . . . . . . . . 25 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 92 7.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 26 93 7.2. New registries . . . . . . . . . . . . . . . . . . . . . . 26 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 95 8.1. Potential Threat Modes . . . . . . . . . . . . . . . . . . 27 96 8.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 28 97 8.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 28 98 8.4. End-to End-Security Issues . . . . . . . . . . . . . . . . 28 99 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 103 11.2. Informative References . . . . . . . . . . . . . . . . . . 31 104 Appendix A. Issues left for future specifications . . . . . . . . 31 105 A.1. Additional traffic abatement algorithms . . . . . . . . . 31 106 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . . 31 107 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . . 31 108 Appendix B. Conformance to Requirements . . . . . . . . . . . . . 32 109 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 41 110 C.1. 3GPP S6a interface overload indication . . . . . . . . . . 41 111 C.2. 3GPP PCC interfaces overload indication . . . . . . . . . 41 112 C.3. Mix of Destination-Realm routed requests and 113 Destination-Host reouted requests . . . . . . . . . . . . 41 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 116 1. Introduction 118 This specification defines a base solution for the Diameter Overload 119 Control (DOC). The requirements for the solution are described and 120 discussed in the corresponding design requirements document 121 [I-D.ietf-dime-overload-reqs]. Note that the overload control 122 solution defined in this specification does not address all the 123 requirements listed in [I-D.ietf-dime-overload-reqs]. A number of 124 overload control related features are left for the future 125 specifications. See Appendix A for more detailed discussion on 126 those. 128 The solution defined in this specification addresses the Diameter 129 overload control between two endpoints (see Section 5.1). 130 Furthermore, the solution is designed to apply to existing and future 131 Diameter applications, requires no changes to the Diameter base 132 protocol [RFC6733] and is deployable in environments where some 133 Diameter nodes do not implement the Diameter overload control 134 solution defined in this specification. 136 2. Terminology and Abbreviations 138 Server Farm 140 A set of Diameter servers that can handle any request for a given 141 set of Diameter applications. While these servers support the 142 same set of applications, they do not necessarily all have the 143 same capacity. An individual server farm might also support a 144 subset of the users for a Diameter Realm. 146 [OpenIssue: Is a server farm assumed to support a single realm? 147 That is, does it support a set of applications in a single realm?] 149 Server Front End 151 A Server Front End (SFE) is a role that can be performed by a 152 Diameter agent -- either a relay or a proxy -- that sits between 153 Diameter clients and a Server Farm. An SFE can perform various 154 functions for the server farm it sits in front of. This includes 155 some or all of the following functions: 157 * Diameter Routing 159 * Diameter layer load balancing 161 * Load Management 162 * Overload Management 164 * Topology Hiding 166 * Server Farm Identity Management 168 [OpenIssue: We used the concept of a server farm and SFE for 169 internal discussions. Do we still need those concepts to explain 170 the mechanism? It doesn't seem like we use them much.] 172 Diameter Routing: 174 Diameter Routing determines the destination of Diameter messages 175 addressed to either a Diameter Realm and Application in general, 176 or to a specific server using Destination-Host. This function is 177 defined in [RFC6733]. Application level routing specifications 178 that expand on [RFC6733] also exist. 180 Diameter-layer Load Balancing: 182 Diameter layer load balancing allows Diameter requests to be 183 distributed across the set of servers. Definition of this 184 function is outside the scope of this document. 186 Load Management: 188 This functionality ensures that the consolidated load state for 189 the server farm is collected, and processed. The exact algorithm 190 for computing the load at the SFE is implementation specific but 191 enough semantic of the conveyed load information needs to be 192 specified so that deterministic behavior can be ensured. 194 Overload Management: 196 The SFE is the entity that understands the consolidated overload 197 state for the server farm. Just as it is outside the scope of 198 this document to specify how a Diameter server calculates its 199 overload state, it is also outside the scope of this document to 200 specify how an SFE calculates the overload state for the set of 201 servers. This document describes how the SFE communicates 202 Overload information to Diameter Clients. 204 Topology Hiding: 206 Topology Hiding is loosely defined as ensuring that no Diameter 207 topology information about the server farm can be discovered from 208 Diameter messages sent outside a predefined boundary (typically an 209 administrative domain). This includes obfuscating identifiers and 210 address information of Diameter entities in the server farm. It 211 can also include hiding the number of various Diameter entities in 212 the server farm. Identifying information can occur in many 213 Diameter Attribute-Value Pairs (AVPs), including Origin-Host, 214 Destination-Host, Route-Record, Proxy-Info, Session-ID and other 215 AVPs. 217 Server Farm Identity Management: 219 Server Farm Identity Management (SFIM) is a mechanism that can be 220 used by the SFE to present a single Diameter identity that can be 221 used by clients to send Diameter requests to the server farm. 222 This requires that the SFE modifies Origin-Host information in 223 answers coming from servers in the server farm. An agent that 224 performs SFIM appears as a server from the client's perspective. 226 Throttling: 228 Throttling is the reduction of the number of requests sent to an 229 entity. Throttling can include a client dropping requests, or an 230 agent rejecting requests with appropriate error responses. 231 Clients and agents can also choose to redirect throttled requests 232 to some other entity or entities capable of handling them. 234 Reporting Node 236 A Diameter node that generates an overload report. (This may or 237 may not be the actually overloaded node.) 239 Reacting Node 241 A Diameter node that consumes and acts upon a report. Note that 242 "act upon" does not necessarily mean the reacting node applies an 243 abatement algorithm; it might decide to delegate that downstream, 244 in which case it also becomes a "reporting node". 246 OLR Oveload Report. 248 3. Solution Overview 250 3.1. Architectural Assumptions 252 This section describes the high-level architectural and semantic 253 assumptions that underly the Diameter Overload Control Mechanism. 255 3.1.1. Application Classification 257 The following is a classification of Diameter applications and 258 requests. This discussion is meant to document factors that play 259 into decisions made by the Diameter identity responsible for handling 260 overload reports. 262 Section 8.1 of [RFC6733] defines two state machines that imply two 263 types of applications, session-less and session-based. The primary 264 differentiator between these types of applications is the lifetime of 265 Session-IDs. 267 For session-based applications, the session-id is used to tie 268 multiple requests into a single session. 270 In session-less applications, the lifetime of the session-id is a 271 single Diameter transaction. 273 The 3GPP-defined S6a application is an example of a session-less 274 application. The following, copied from section 7.1.4 of 29.272, 275 explicitly states that sessions are implicitly terminated and that 276 the server does not maintain session state: 278 "Between the MME and the HSS and between the SGSN and the HSS and 279 between the MME and the EIR, Diameter sessions shall be implicitly 280 terminated. An implicitly terminated session is one for which the 281 server does not maintain state information. The client shall not 282 send any re-authorization or session termination requests to the 283 server. 285 The Diameter base protocol includes the Auth-Session-State AVP as 286 the mechanism for the implementation of implicitly terminated 287 sessions. 289 The client (server) shall include in its requests (responses) the 290 Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), 291 as described in [RFC6733]. As a consequence, the server shall not 292 maintain any state information about this session and the client 293 shall not send any session termination request. Neither the 294 Authorization-Lifetime AVP nor the Session-Timeout AVP shall be 295 present in requests or responses." 297 For the purposes of this discussion, session-less applications are 298 further divided into two types of applications: 300 Stateless applications: Requests within a stateless application have 301 no relationship to each other. The 3GPP defined S13 application 302 is an example of a stateless application. 304 Pseudo-session applications: While this class of application does 305 not use the Diameter Session-ID AVP to correlate requests, there 306 is an implied ordering of transactions defined by the application. 307 The 3GPP defined Cx application [reference] is an example of a 308 pseudo-session application. 310 [OpenIssue: Do we assume that all requests in a pseudo-session 311 typically need to go to the same server?] 313 The accounting application defined in [RFC6733] and the Credit- 314 Control application defined in [RFC4006] are examples of Diameter 315 session-based applications. 317 The handling of overload reports must take the type of application 318 into consideration, as discussed in Section 3.1.2. 320 3.1.2. Application Type Overload Implications 322 This section discusses considerations for mitigating overload 323 reported by a Diameter entity. This discussion focuses on the type 324 of application. Section 3.1.3 discusses considerations for handling 325 various request types when the target server is known to be in an 326 overloaded state. Section 3.1.5 discusses considerations for 327 handling overload conditions based on the network deployment 328 scenario. 330 These discussions assume that the strategy for mitigating the 331 reported overload is to reduce the overall workload sent to the 332 overloaded entity. The concept of applying overload treatment to 333 requests targeted for an overloaded Diameter entity is inherent to 334 this discussion. The method used to reduce offered load is not 335 specified here but could include routing requests to another Diameter 336 entity known to be able to handle them, or it could mean rejecting 337 certain requests. For a Diameter agent, rejecting requests will 338 usually mean generating appropriate Diameter error responses. For a 339 Diameter client, rejecting requests will depend upon the application. 340 For example, it could mean giving an indication to the entity 341 requesting the Diameter service that the network is busy and to try 342 again later. 344 Stateless applications: By definition there is no relationship 345 between individual requests in a stateless application. As a 346 result, when a request is sent or relayed to an overloaded 347 Diameter entity - either a Diameter Server or a Diameter Agent - 348 the sending or relaying entity can choose to apply the overload 349 treatment to any request targeted for the overloaded entity. 351 Pseudo-stateful applications: Pseudo stateful applications are also 352 stateless applications in that there is no session Diameter state 353 maintained between transactions. There is, however, an implied 354 ordering of requests. As a result, decisions about which 355 transactions to reject as a result of an overloaded entity could 356 take the command-code of the request into consideration. This 357 generally means that transactions later in the sequence of 358 transactions should be given more favorable treatment than 359 messages earlier in the sequence. This is because more work has 360 already been done by the Diameter network for those transactions 361 that occur later in the sequence. Rejecting them could result in 362 increasing the load on the network as the transactions earlier in 363 the sequence might also need to be repeated. 365 Stateful applications: Overload handling for stateful applications 366 must take into consideration the work associated with setting up 367 an maintaining a session. As such, the entity handling overload 368 of a Diameter entity for a stateful application might tend to 369 reject new session requests before rejecting intra-session 370 requests. In addition, session ending requests might be given a 371 lower priority of being rejected as rejecting session ending 372 requests could result in session status being out of sync between 373 the Diameter clients and servers. Nodes that reject mid-session 374 requests will need to consider whether the rejection invalidates 375 the session, and any session clean-up that may be required. 377 3.1.3. Request Transaction Classification 379 Independent Request: An independent request is not a part of a 380 Diameter session and, as such, the lifetime of the session-id is 381 constrained to an individual transaction. 383 Session-Initiating Request: A session-initiating request is the 384 initial message that establishes a Diameter session. The ACR 385 message defined in [RFC6733] is an example of a session-initiating 386 request. 388 Correlated Session-Initiating Request: There are cases, most notably 389 in the 3GPP PCC architecture, where multiple Diameter sessions are 390 correlated and must be handled by the same Diameter server. This 391 is a special case of a Session-Initiating Request. Gx CCR-I 392 requests and Rx AAR messages are examples of correlated session- 393 initiating requests. 395 [OpenIssue: The previous paragraph needs references.] 397 Intra-Session Request: An intra session request is a request that 398 uses a session-id for an already established request. An intra 399 session request generally needs to be delivered to the server that 400 handled the session creating request for the session. The STR 401 message defined in [RFC6733] is an example of an intra-session 402 requests. CCR-U and CCR-T requests defined in [RFC4006] are 403 further examples of intra-session requests. 405 Pseudo-Session Requests: Pseudo session requests are independent 406 requests and, as such, the request transactions are not tied 407 together using the Diameter session-id. There exist Diameter 408 applications that define an expected ordering of transactions. 409 This sequencing of independent transactions results in a pseudo 410 session. The AIR, MAR and SAR requests in the 3GPP defined Cx 411 application are examples of pseudo-session requests. 413 3.1.4. Request Type Overload Implications 415 The request classes identified in Section 3.1.3 have implications on 416 decisions about which requests should be throttled first. 418 Independent requests: Independent requests can be given equal 419 treatment when making throttling decisions. 421 Session-creating requests: Session-creating requests represent more 422 work than independent or intra-session requests. As such, 423 throttling decisions might favor intra-session requests over 424 session-creating requests. Individual session-creating requests 425 can be given equal treatment when making throttling decisions. 427 Correlated session-creating requests: A Request that results in a 428 new binding, where the binding is used for routing of subsequent 429 session-creating requests, represents more work than other 430 requests. As such, these requests might be throttled more 431 frequently than other request types. 433 Pseudo-session requests: Throttling decisions for pseudo-session 434 requests can take where individual requests fit into the overall 435 sequence of requests within the pseudo session. Requests that are 436 earlier in the sequence might be throttled more aggressively than 437 requests that occur later in the sequence. 439 Intra-session requests There are two classes of intra-sessions 440 requests. The first is a request that ends a session. The second 441 is a request that is used to convey session related state between 442 the Diameter client and server. Session ending request should be 443 throttled less aggressively in order to keep session state 444 consistent between the client and server, and possibly reduce the 445 sessions impact on the overloaded entity. The default handling of 446 other intra-session requests might be to treat them equally when 447 making throttling decisions. There might also be application 448 level considerations whether some request types are favored over 449 others. 451 3.1.5. Diameter Deployment Scenarios 453 This section discusses various Diameter network deployment scenarios 454 and the implications of those deployment models on handling of 455 overload reports. 457 The scenarios vary based on the following: 459 o The presence or absence of Diameter agents 461 o Which Diameter entities support the DOC extension 463 o The amount of the network topology understood by Diameter clients 465 o The complexity of the Diameter server deployment for a Diameter 466 application 468 o Number of Diameter applications supported by Diameter clients and 469 Diameter servers 471 Without consideration for which elements support the DOC extension, 472 the following is a representative list of deployment scenarios: 474 o Client --- Server 476 o Client --- Multiple equivalent servers 478 o Client --- Agent --- Multiple equivalent servers 480 o Client --- Agent [ --- Agent ] --- Partitioned server 482 o Client --- Edge Agent [ --- Edge Agent] --- { Multiple Equivalent 483 Servers | Partitioned Servers } 485 o Client --- Session Correlating Agent --- Multiple Equivalent 486 Servers 488 [OpenIssue: Do the "multiple equivalent servers" cases change for 489 session-stateful applications? Do we need to distinguish equivalence 490 for session-initiation requests vs intra-session requests?] 492 The following is a list of representative DOC deployment scenarios: 494 o Direct connection between a DOC client and a DOC server 496 o DOC client --- non-DOC agent --- DOC server 498 o DOC client --- DOC agent --- DOC server 500 o Non-DOC client --- DOC agent --- DOC server 502 o Non-DOC client --- DOC agent --- Mix of DOC and non-DOC servers 504 o DOC client --- agent --- Partitioned/Segmented DOC server 506 o DOC client --- agent --- agent --- Partitioned/Segmented DOC 507 server 509 o DOC client --- edge agent --- edge agent --- DOC server 511 [OpenIssue: In the last 3 list entries, are the agents DOC or non- 512 DOC?] 514 3.1.6. Diameter Agent Behaviour 516 In the context of the Diameter Overload Indication Conveyance (DOIC) 517 and reacting to the overload information, the functional behaviour of 518 Diameter agents in front of servers, especially Diameter proxies, 519 needs to be common. This is important because agents may actively 520 participate in the handling of an overload conditions. For example, 521 they may make intelligent next hop selection decisions based on 522 overload conditions, or aggregate overload information to be 523 disseminated downstream. Diameter agents may have other deployment 524 related tasks that are not defined in the Diameter base protocol 525 [RFC6733]. These include, among other tasks, topology hiding, and 526 acting as a server front end for a server farm of real Diameter 527 servers. 529 Since the solution defined in this specification must not break the 530 Diameter base protocol [RFC6733] at any time, great care has to be 531 taken not to assume functionality from the Diameter agents that would 532 break base protocol behavior, or to assume agent functionality beyond 533 the Diameter base protocol. Effectively this means the following 534 from a Diameter agent: 536 o If a Diameter agent presents itself as the "end node", perhaps 537 acting as an topology hiding SFE, the DOC mechanism MUST NOT leak 538 information of the Diameter nodes behind it. From the Diameter 539 client point of view the final destination to its requests and the 540 original source for the answers MUST be the Diameter agent. This 541 requirement means that such a Diameter agent acts as a back-to- 542 back-agent for DOC purposes. How the agent in this case appears 543 to the Diameter nodes it is representing (i.e. the real Diameter 544 servers), is an implementation and a deployment specific within 545 the realm the Diameter agent is deployed. 547 o This requirement also implies that if the Diameter agent does not 548 impersonate the servers behind it, the Diameter dialogue is 549 established between clients and servers and any overload 550 information received by a client would be from a given server 551 identified by the Origin-Host identity. 553 [OpenIssue: We've discussed multiple situations where an agent might 554 insert an OLR. I don't think we mean to force them to always perform 555 topology hiding or SFIM in order to do so. We cannot assume that an 556 OLR is always "from" or "about" the Origin-Host. Also, the section 557 seems to assume that topology hiding agents act as b2b overload 558 agents, but non-topology hiding agents never do. It don't think 559 that's the right abstraction. It's possible that topology-hiding 560 agents must do this, but I don't think we can preclude non-topology 561 hiding agents from also doing it, at least some of the time.] 563 3.1.7. Simplified Example Architecture 565 Figure 1 illustrates the simplified architecture for Diameter 566 overload control. See Section 5.1 for more discussion and details 567 how different Diameter nodes fit into the architecture from the DOIC 568 point of view. 570 Realm X Other Realms 571 <--------------------------------------> <----------------------> 573 +--^-----+ : (optional) : 574 |Diameter| : : 575 |Server A|--+ .--. : +---^----+ : .--. 576 +--------+ | _( `. : |Diameter| : _( `. +---^----+ 577 +--( )--:-| Agent |-:--( )--|Diameter| 578 +--------+ | ( ` . ) ) : +-----^--+ : ( ` . ) ) | Client | 579 |Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+ 580 |Server B| : : 581 +---^----+ : : 582 Overload Indication A Overload Indication A' 583 1) <----------------------> <----------------------> 584 standard base protocol standard base protocol 586 End-to-end Overload Indication 587 2) <-----------------------------------------------> 588 standard base protocol 590 Figure 1: Simplified architecture choices for overload indication 591 delivery 593 3.2. Conveyance of the Overload Indication 595 The following features describe new Diameter AVPs used for sending 596 overload reports, and for declaring support for certain DOC features. 598 3.2.1. Negotiation and Versioning 600 Since the Diameter overload control mechanism is also designed to 601 work over existing application (i.e., the piggybacking principle), a 602 proper negotiation is hard to accomplish. The "capability 603 negotiation" is based on the existense of specific non-mandatory APV, 604 such as the OC-Feature-Vector AVP (see Section 4.1. Although the OC- 605 Feature-Vector AVP can be used to advertise a certain set of new or 606 existing Diameter overload control capabilities, it is not a 607 versioning solution per se, however, it can be used to achieve the 608 same result. 610 3.2.2. Transmission of the Attribute Value Pairs 612 The Diameter overload control APVs SHOULD always be sent as an 613 optional AVPs. This requirement stems from the fact that 614 piggybacking overload control information on top of existing 615 application cannot really use AVPs with the M-bit set. However, 616 there are certain exceptions as explained in Section 5.4. 618 From the Diameter overload control functionality point of view, the 619 "Reacting node" is always the requester of the overload report 620 information and the "Reporting node" is the provider of the overload 621 report. The overload report or the capability information in the 622 request message is always interpreted as an announcement of a 623 "capability". The overload report and the capability information in 624 the answer is always interpreted as a report of supported commond 625 functionality and as a status report of an overload condition (of a 626 node). 628 3.3. Overload Condition Indication 630 Diameter nodes can request a reduction in offered load by indicating 631 an overload condition in the form of an overload report. The 632 overload report contains information about how much load should be 633 reduced, and may contain other information about the overload 634 condition. This information is encoded in Diameter Attribute Value 635 Pairs (AVPs). 637 Certain new AVPs may also be used to declare certain DOIC 638 capabilities and extensions. 640 4. Attribute Value Pairs 642 This section describes the encoding and semantics of Overload 643 Indication Attribute Value Pairs (AVPs). 645 4.1. OC-Feature-Vector AVP 647 The OC-Feature-Vector AVP (AVP code TBD1) is type of Unsigned64 and 648 contains a 64 bit flags field of announced capabilities of an 649 overload control endpoint. Sending or receiving the OC-Feature- 650 Vector AVP with the value 0 indicates that the endpoint only support 651 the capabilities defined in this specification. 653 An overload control endpoint (a reacting node) includes this AVP to 654 indicate its capabilities to the other overload control endpoint (the 655 reporting node). For example, the endpoint (reacting node) may 656 indicate which (future defined) traffic abatement algorithms it 657 supports in addition to the default. 659 During the message exchange the overload control endpoints express 660 their common set of supported capabilities. The endpoint sending a 661 request (the reacting node) includes the OC-Feature-Vector AVP with 662 those flags set that correspond what it supports. The endpoint that 663 sends the answer (the reporting node) also includes the OC-Feature- 664 Vector AVP with flags set to describe the capabilities it both 665 supports and agrees with the request sender (e.g., based on the local 666 policy and/or configuration). The answer sending endpoint (the 667 reporting node) does not need to advertise those capabilities it is 668 not going to use with the request sending endpoint (the reacting 669 node). 671 This specification does not define any additional capability flag. 672 The implicity capability (all flags set to zero) indicates the 673 support for this specification only. 675 4.2. OC-OLR AVP 677 The OC-OLR AVP (AVP code TBD2) is type of Grouped and contains the 678 necessary information to convey an overload report. OC-OLR may also 679 be used to convey additional information about an extension that is 680 declared in the OC-Feature-Vector AVP. 682 The OC-OLR AVP does not contain explicit information to which 683 application it applies to and who inserted the AVP or whom the 684 specific OC-OLR AVP concerns to. Both these information is 685 implicitly learned from the encapsulating Diameter message/command. 686 The application the OC-OLR AVP applies to is the same as the 687 Application-Id found in the Diameter message header. The identity 688 the OC-OLR AVP concerns is determined from the Origin-Host AVP found 689 from the encapsulating Diameter command. 691 OC-OLR ::= < AVP Header: TBD2 > 692 < TimeStamp > 693 [ Reduction-Percentage ] 694 [ ValidityDuration ] 695 [ ReportType ] 696 * [ AVP ] 698 The TimeStamp AVP indicates when the original OC-OLR AVP with the 699 current content was created. It is possible to replay the same OC- 700 OLR AVP multiple times between the overload endpoints, however, when 701 the OC-OLR AVP content changes or the other information sending 702 endpoint wants the receiving endpoint to update its overload control 703 information, then the TimeStamp AVP MUST contain a new value. 705 [OpenIssue: Is this necessarily a timestamp, or is it just a sequence 706 number that can be implemented as a timestamp? Is this timestamp 707 used to calculate expiration time? (propose no.). We should also 708 consider whether either a timestamp or sequence number is needed for 709 protection against replay attacks.] 711 4.3. TimeStamp AVP 713 The TimeStamp AVP (AVP code TBD3) is type of Time. Its usage in the 714 context of the overload control is described in Section 4.2. From 715 the functionality point of view, the TimeStamp AVP is merely used as 716 a non-volatile increasing counter between two overload control 717 endpoints. 719 4.4. ValidityDuration AVP 721 The ValidityDuration AVP (AVP code TBD4) is type of Unsigned32 and 722 describes the number of seconds the OC-OLR AVP and its content is 723 valid since the creation of the OC-OLR AVP (as indicated by the 724 TimeStamp AVP). 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.6 discusses the impacts of timeout in 729 the scope of the traffic abatement algorithms. 731 As a general guidance for implementations it is RECOMMENDED never to 732 let any overload report to timeout. Rather, an overload endpoint 733 should explicitly signal, e.g. the end of overload condition. This 734 leaves no need for the other overload endpoint to reason or guess the 735 condition the other endpoint is at. 737 4.5. ReportType AVP 739 The ReportType AVP (AVP code TBD5) is type of Enumerated. The value 740 of the AVP describes what the overload report concerns. The 741 following values are initially defined: 743 0 Reserved. 745 1 Destination-Host report. The overload treatment should apply to 746 requests that the sender knows will reach the overloaded server. 747 For example, requests with a Destination-Host AVP indicating the 748 server. 750 2 Realm (aggregated) report. The overload treatment should apply to 751 all requests bound for the overloaded realm. 753 The ReportType AVP is envisioned to be useful for situations where a 754 reacting node needs to apply different overload treatments for 755 different "types" of overload. For example, the reacting node(s) 756 might need to throttle requests that are targeted to a specific 757 server by the presence of a Destination-Host AVP than for requests 758 that can be handled by any server in a realm. The example in 759 Appendix C.3 illustrates this usage. 761 [OpenIssue: There is an ongoing discussion about whether the 762 ReportType AVP is the right way to solve that issue, and whether it's 763 needed at all.] 765 4.6. Reduction-Percentage AVP 767 The Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 768 and describes the percentage of the traffic that the sender is 769 requested to reduce, compared to what it otherwise would have sent. 771 The value of the Reduction-Percentage AVP is between zero (0) and one 772 hundred (100). Values greater than 100 are interpreted as 100. The 773 value of 100 means that no traffic is expected, i.e. the sender of 774 the information is under a severe load and ceases to process any new 775 messages. The value of 0 means that the sender of the information is 776 in a stable state and has no requests to the other endpoint to apply 777 any traffic abatement. 779 [Open Issue: We should consider an algorithm independent way to end 780 an overload condition. Perhaps setting the validitytime to zero? 781 Counter comment; since the abatement is based on a specific 782 algorithm, it is natural to indicate that from the abatement 783 algorithm point of view status quo has been reached.] 785 If an overload control endpoint comes out of the 100 percent traffic 786 reduction as a result of the overload report timing out, the 787 following concerns are RECOMMENDED to be applied. The endpoint 788 sending the traffic should be conservative and, for example, first 789 send few "probe" messages to learn the overload condition of the 790 other endpoint before converging to any traffic amount/rate decided 791 by the sender. Similar concerns actually apply in all cases when the 792 overload report times out unless the previous overload report stated 793 0 percent reduction. 795 [Open Issue: It is still open whether we need an AVP to indicate the 796 exact used traffic abatement algorithm. Currently it assumed that 797 the reacting node is able to figure out what to do based on the 798 Reducttion-Percentage AVP and possible other embedded information 799 inside the OC-OLR AVP.] 801 4.7. Attribute Value Pair flag rules 803 +---------+ 804 |AVP flag | 805 |rules | 806 +----+----+ 807 AVP Section | |MUST| 808 Attribute Name Code Defined Value Type |MUST| NOT| 809 +--------------------------------------------------+----+----+ 810 |OC-Feature-Vector TBD1 x.x Unsigned64 | | V | 811 +--------------------------------------------------+----+----+ 812 |OC-OLR TBD2 x.x Grouped | | V | 813 +--------------------------------------------------+----+----+ 814 |TimeStamp TBD3 x.x Time | | V | 815 +--------------------------------------------------+----+----+ 816 |ValidityPeriod TBD4 x.x Unsigned32 | | V | 817 +--------------------------------------------------+----+----+ 818 |ReportType TBD5 x.x Enumerated | | V | 819 +--------------------------------------------------+----+----+ 820 |Reduction | | | 821 | -Percentage TBD8 x.x Unsigned32 | | V | 822 +--------------------------------------------------+----+----+ 824 5. Overload Control Operation 826 5.1. Overload Control Endpoints 828 The overload control solution can be considered as an overlay on top 829 of an arbitrary Diameter network. The overload control information 830 is exchanged over on a "DOIC association" between two communicatin 831 endpoints. The endpoints, namely the "reacting node" and the 832 "reporting node" do not need to be adjacent Diameter peer nodes, nor 833 they need to be the end-to-end Diameter nodes in a typical "client- 834 server" deployment with multiple intermediate Diameter agent nodes in 835 between. The overload control endpoint are the two Diameter nodes 836 that decide to exchange overload control information between each 837 other. How the endpoints are determined is specific to a deployment, 838 a Diameter node role in that deployment and local configuration. 840 The following diagrams illustrate the concept of Diameter Overload 841 End-Points and how they differ from the standard [RFC6733] defined 842 client, server and agent Diameter nodes. The following is the key to 843 the elements in the diagrams: 845 C Diameter client as defined in [RFC6733]. 847 S Diameter server as defined in [RFC6733]. 849 A Diameter agent, in either a relay or proxy mode, as defined in 850 [RFC6733]. 852 DEP Diameter Overload End-Point as defined in this document. In the 853 following figures a DEP may terminate two different DOIC 854 associations being a reporter and reactor at the same time. 856 Diameter Session A Diameter session as defined in [RFC6733]. 858 DOIC Association A DOIC association exists between two Diameter 859 Overload End-Points. One of the end-points is the overload 860 reporter and the other is the overload reactor. 862 Figure 2 illustrates the most basic configuration where a client is 863 connected directly to a server. In this case, the session and 864 association are both between the client and server. 866 +-----+ +-----+ 867 | C | | S | 868 +-----+ +-----+ 869 | DEP | | DEP | 870 +--+--+ +--+--+ 871 | | 872 | | 873 |{Diameter Session}| 874 | | 875 |{DOIC Association}| 876 | | 878 Figure 2: Basic DOIC deployment 880 In Figure 3 there is an agent that is not participating directly in 881 the exchange of overload reports. As a result, the DOIC association 882 is still between the client and the server. 884 +-----+ +-----+ +-----+ 885 | C | | A | | S | 886 +-----+ +--+--+ +-----+ 887 | DEP | | | DEP | 888 +--+--+ | +--+--+ 889 | | | 890 | | | 891 |----------{Diameter Session}---------| 892 | | | 893 |----------{DOIC Association}---------| 894 | | | 896 Figure 3: DOIC deployment with non participating agent 898 Figure 4 illustrates the case where the client does not support 899 Diameter overload. In this case, the DOIC association is between the 900 agent and the server. The agent handles the role of the reactor for 901 overload reports generated by the server. 903 +-----+ +-----+ +-----+ 904 | C | | A | | S | 905 +--+--+ +-----+ +-----+ 906 | | DEP | | DEP | 907 | +--+--+ +--+--+ 908 | | | 909 | | | 910 |----------{Diameter Session}---------| 911 | | | 912 | |{DOIC Association}| 913 | | | 915 Figure 4: DOIC deployment with non-DOIC client and DOIC enabled agent 917 In Figure 5 there is a DOIC association between the client and the 918 agent and a second DOIC association between the agent and the server. 919 One use case requiring this configuration is when the agent is 920 serving as a SFE/SFIM for a set of servers. 922 +-----+ +-----+ +-----+ 923 | C | | A | | S | 924 +-----+ +-----+ +-----+ 925 | DEP | | DEP | | DEP | 926 +--+--+ +--+--+ +--+--+ 927 | | | 928 | | | 929 |----------{Diameter Session}---------| 930 | | | 931 |{DOIC Association}|{DOIC Association}| 932 | | | 934 Figure 5: A deployment where all nodes support DOIC 936 Figure 6 illustrates a deployment where some clients support Diameter 937 overload control and some do not. In this case the agent must 938 support Diameter overload control for the non supporting client. It 939 might also need to have a DOIC association with the server, as shown 940 here, to handle overload for a server farm and/or for managing Realm 941 overload. 943 +-----+ +-----+ +-----+ +-----+ 944 | C1 | | C2 | | A | | S | 945 +-----+ +--+--+ +-----+ +-----+ 946 | DEP | | | DEP | | DEP | 947 +--+--+ | +--+--+ +--+--+ 948 | | | | 949 | | | | 950 |-------------------{Diameter Session}-------------------| 951 | | | | 952 | |--------{Diameter Session}-----------| 953 | | | | 954 |---------{DOIC Association}----------|{DOIC Association}| 955 | | | | 957 Figure 6: A deployment with DOIC and non-DOIC supporting clients 959 Figure 7 illustrates a deployment where some agents support Diameter 960 overload control and others do not. 962 +-----+ +-----+ +-----+ +-----+ 963 | C | | A | | A | | S | 964 +-----+ +--+--+ +-----+ +-----+ 965 | DEP | | | DEP | | DEP | 966 +--+--+ | +--+--+ +--+--+ 967 | | | | 968 | | | | 969 |-------------------{Diameter Session}-------------------| 970 | | | | 971 | | | | 972 |---------{DOIC Association}----------|{DOIC Association}| 973 | | | | 975 Figure 7: A deployment with DOIC and non-DOIC supporting agents 977 5.2. Piggybacking Principle 979 The overload control solution defined AVPs are essentially 980 piggybacked on top of existing application message exchanges. This 981 is made possible by adding overload control top level AVPs, the OC- 982 OLR AVP and the OC-Feature-Vector AVP into existing commands (this 983 has an assumption that the application CCF allows adding new AVPs 984 into the Diameter messages. 986 In a case of newly defined Diameter applications, it is RECOMMENDED 987 to add and defined how overload control mechanisms works on that 988 application. using OC-Feature-Vector and OC-OLR AVPs in a non- 989 mandatory manner is intended only existing applications. 991 Note that the overload control solution does not have fixed server 992 and client roles. The endpoint role is determined based on the sent 993 message type: whether the message is a request (i.e. sent by a 994 "reacting node") or an answer (i.e. send by a "reporting node"). 995 Therefore, in a typical "client-server" deployment, the "client" MAY 996 report its overload condition to the "server" for any server 997 initiated message exchange. An example of such is the server 998 requesting a re-authentication from a client. 1000 5.3. Capability Announcement 1002 Since the overload control solution relies on the piggybacking 1003 principle for the overload reporting and the overload control 1004 endpoint are likely not adjacent peers, finding out whether the other 1005 endpoint supports the overload control or what is the common traffic 1006 abatement algorithm to apply for the traffic. The approach defined 1007 in this specification for the end-to-end capability capability 1008 announcement relies on the exchange of the OC-Feature-Vector between 1009 the endpoints. The feature announcement solution also works when 1010 carried out on existing applications. For the newly defined 1011 application the negotiation can be more exact based on the 1012 application specification. The announced set of capabilities MUST 1013 NOT change during the life time of the Diameter session (or 1014 transaction in a case of non-session maintaining applications). 1016 5.3.1. Request Message Initiator Endpoint Considerations 1018 The basic principle is that the request message initiating endpoint 1019 (i.e. the "reacting node") announces its support for the overload 1020 control mechanism by including in the request message the OC-Feature- 1021 Vector AVP with those capability flag bits set that it supports and 1022 is willing to use for this Diameter session (or transaction in a case 1023 of a non-session state maintaining applications). In a case of 1024 session maintaining applications the request message initiating 1025 endpoint does not need to do the capability announcement more than 1026 once for the lifetime of the Diameter session. In a case of non- 1027 session maintaining applications, it is RECOMMENDED that the request 1028 message initiating endpoint includes the capability announcement into 1029 every request regardless it has had prior message exchanges with the 1030 give remote endpoint. 1032 [OpenIssue: We need to think about the lifetime of a capabilities 1033 declaration. It's probably not the same as for a session. We have 1034 had proposals that the feature vector needs to go into every request 1035 sent by an OC node. For peer to peer cases, this can be associated 1036 with connection lifetime, but it's more complex for non-adjacent OC 1037 support.] 1039 Once the endpoint that initiated the request message receives an 1040 answer message from the remote endpoint, it can detect from the 1041 received answer message whether the remote endpoint supports the 1042 overload control solution and in a case it does, what features are 1043 supported. The support for the overload control solution is based on 1044 the presence of the OC-Feature-Vector AVP in the Diameter answer for 1045 existing application. For the newly defined applications the support 1046 for the overload control MAY already be part of the application 1047 specification. Based on capability knowledge the request message 1048 initiating endpoint can select the preferred common traffic abatement 1049 algorithm and act accordingly for the subsequent message exchanges. 1051 5.3.2. Answer Message Initiating Endpoint Considerations 1053 When a remote endpoint (i.e. a "reporting node") receives a request 1054 message in can detect whether the request message initiating endpoint 1055 has support for the overload control solution based on the presence 1056 of the OC-Feature-Vector AVP. For the newly defined applications the 1057 overload control solution support can be part of the application 1058 specification. Based on the content of the OC-Feature-Vector AVP the 1059 request message receiving endpoint knows what overload control 1060 functionality the other endpoint supports and then act accordingly 1061 for the subsequent answer messages it initiates. It is RECOMMENDED 1062 that the answer message initiating endpoint selects one common 1063 traffic abatement algorithm even if it would support multiple. The 1064 answer message initiating endpoint MUST NOT include any overload 1065 control solution defined AVPs into its answer messages if the request 1066 message initiating endpoint has not indicated support at the 1067 beginning of the the created session (or transaction in a case of 1068 non-session state maintaining applications). 1070 5.4. Protocol Extensibility 1072 The overload control solution can be extended, e.g. with new traffic 1073 abatement algorithms or new functionality. The new features and 1074 algorithms MUST be registered with the IANA and for the ppossible use 1075 with the OC-Feature-Vector for announcing the support for the new 1076 features (see Section 7 for the required procedures). 1078 It should be noted that [RFC6733] defined Grouped AVP extension 1079 mechanisms also apply. This allows, for example, defining a new 1080 feature that is mandatory to understand even when piggybacked on an 1081 existing applications. More specifically, the sub-AVPs inside the 1082 OC-OLR AVP MAY have the M-bit set. However, when overload control 1083 AVPs are piggybacked on top of an existing applications, setting 1084 M-bit in sub-AVPs is NOT RECOMMENDED. 1086 5.5. Overload Report Processing 1088 5.5.1. Sender Endpoint Considerations 1090 5.5.2. Receiver Endpoint Considerations 1092 [OpenIssue: did we now agree that e.g. a server can refrain sending 1093 OLR in answers based on some magical algorithm? (Note: We seem to 1094 have consensus that a server MAY repeat OLRs in subsequent messages, 1095 but is not required to do so, based on local policy.)] 1097 6. Transport Considerations 1099 In order to reduce overload control introduced additional AVP and 1100 message processing it might be desirable/beneficial to signal whether 1101 the Diameter command carries overload control information that should 1102 be of interest of an overload aware Diameter node. 1104 Should such indication be include is not part of this specification. 1105 It has not either been concluded at what layer such possible 1106 indication should be. Obvious candidates include transport layer 1107 protocols (e.g., SCTP PPID or TCP flags) or Diameter command header 1108 flags. 1110 7. IANA Considerations 1112 7.1. AVP codes 1114 New AVPs defined by this specification are listed in Section 4. All 1115 AVP codes allocated from the 'Authentication, Authorization, and 1116 Accounting (AAA) Parameters' AVP Codes registry. 1118 7.2. New registries 1120 Three new registries are needed under the 'Authentication, 1121 Authorization, and Accounting (AAA) Parameters' registry. 1123 Section 4.1 defines a new "Overload Control Feature Vector" registry 1124 including the initial assignments. New values can be added into the 1125 registry using the Specification Required policy [RFC5226]. 1127 Section 4.5 defines a new "Overload Report Type" registry with its 1128 initial assignments. New types can be added using the Specification 1129 Required policy [RFC5226]. 1131 8. Security Considerations 1133 This mechanism gives Diameter nodes the ability to request that 1134 downstream nodes send fewer Diameter requests. Nodes do this by 1135 exchanging overload reports that directly affect this reduction. 1136 This exchange is potentially subject to multiple methods of attack, 1137 and has the potential to be used as a Denial-of-Service (DoS) attack 1138 vector. 1140 Overload reports may contain information about the topology and 1141 current status of a Diameter network. This information is 1142 potentially sensitive. Network operators may wish to control 1143 disclosure of overload reports to unauthorized parties to avoid its 1144 use for competitive intelligence or to target attacks. 1146 Diameter does not include features to provide end-to-end 1147 authentication, integrity protection, or confidentiality. This may 1148 cause complications when sending overload reports between non- 1149 adjacent nodes. 1151 8.1. Potential Threat Modes 1153 The Diameter protocol involves transactions in the form of requests 1154 and answers exchanged between clients and servers. These clients and 1155 servers may be peers, that is,they may share a direct transport (e.g. 1156 TCP or SCTP) connection, or the messages may traverse one or more 1157 intermediaries, known as Diameter Agents. Diameter nodes use TLS, 1158 DTLS, or IPSec to authenticate peers, and to provide confidentiality 1159 and integrity protection of traffic between peers. Nodes can make 1160 authorization decisions based on the peer identities authenticated at 1161 the transport layer. 1163 When agents are involved, this presents an effectively hop-by-hop 1164 trust model. That is, a Diameter client or server can authorize an 1165 agent for certain actions, but it must trust that agent to make 1166 appropriate authorization decisions about its peers, and so on. 1168 Since confidentiality and integrity protection occurs at the 1169 transport layer. Agents can read, and perhaps modify, any part of a 1170 Diameter message, including an overload report. 1172 There are several ways an attacker might attempt to exploit the 1173 overload control mechanism. An unauthorized third party might inject 1174 an overload report into the network. If this third party is upstream 1175 of an agent, and that agent fails to apply proper authorization 1176 policies, downstream nodes may mistakenly trust the report. This 1177 attack is at least partially mitigated by the assumption that nodes 1178 include overload reports in Diameter answers but not in requests. 1179 This requires an attacker to have knowledge of the original request 1180 in order to construct a response. Therefore, implementations SHOULD 1181 validate that an answer containing an overload report is a properly 1182 constructed response to a pending request prior to acting on the 1183 overload report. 1185 A similar attack involves an otherwise authorized Diameter node that 1186 sends an inappropriate overload report. For example, a server for 1187 the realm "example.com" might send an overload report indicating that 1188 a competitor's realm "example.net" is overloaded. If other nodes act 1189 on the report, they may falsely believe that "example.net" is 1190 overloaded, effectively reducing that realm's capacity. Therefore, 1191 it's critical that nodes validate that an overload report received 1192 from a peer actually falls within that peer's responsibility before 1193 acting on the report or forwarding the report to other peers. For 1194 example, an overload report from an peer that applies to a realm not 1195 handled by that peer is suspect. 1197 An attacker might use the information in an overload report to assist 1198 in certain attacks. For example, an attacker could use information 1199 about current overload conditions to time a DoS attack for maximum 1200 effect, or use subsequent overload reports as a feedback mechanism to 1201 learn the results of a previous or ongoing attack. 1203 8.2. Denial of Service Attacks 1205 Diameter overload reports can cause a node to cease sending some or 1206 all Diameter requests for an extended period. This makes them a 1207 tempting vector for DoS tacks. Furthermore, since Diameter is almost 1208 always used in support of other protocols, a DoS attack on Diameter 1209 is likely to impact those protocols as well. Therefore, Diameter 1210 nodes MUST NOT honor or forward overload reports from unauthorized or 1211 otherwise untrusted sources. 1213 8.3. Non-Compliant Nodes 1215 When a Diameter node sends an overload report, it cannot assume that 1216 all nodes will comply. A non-compliant node might continue to send 1217 requests with no reduction in load. Requirement 28 1218 [I-D.ietf-dime-overload-reqs] indicates that the overload control 1219 solution cannot assume that all Diameter nodes in a network are 1220 necessarily trusted, and that malicious nodes not be allowed to take 1221 advantage of the overload control mechanism to get more than their 1222 fair share of service. 1224 In the absence of an overload control mechanism, Diameter nodes need 1225 to implement strategies to protect themselves from floods of 1226 requests, and to make sure that a disproportionate load from one 1227 source does not prevent other sources from receiving service. For 1228 example, a Diameter server might reject a certain percentage of 1229 requests from sources that exceed certain limits. Overload control 1230 can be thought of as an optimization for such strategies, where 1231 downstream nodes never send the excess requests in the first place. 1232 However, the presence of an overload control mechanism does not 1233 remove the need for these other protection strategies. 1235 8.4. End-to End-Security Issues 1237 The lack of end-to-end security features makes it far more difficult 1238 to establish trust in overload reports that originate from non- 1239 adjacent nodes. Any agents in the message path may insert or modify 1240 overload reports. Nodes must trust that their adjacent peers perform 1241 proper checks on overload reports from their peers, and so on, 1242 creating a transitive-trust requirement extending for potentially 1243 long chains of nodes. Network operators must determine if this 1244 transitive trust requirement is acceptable for their deployments. 1245 Nodes supporting Diameter overload control MUST give operators the 1246 ability to select which peers are trusted to deliver overload 1247 reports, and whether they are trusted to forward overload reports 1248 from non-adjacent nodes. 1250 [OpenIssue: This requires that a responding node be able to tell a 1251 peer-generated OLR from one generated by a non-adjacent node. One 1252 way of doing this would be to include the identity of the node that 1253 generated the report as part of the OLR] 1255 [OpenIssue: Do we need further language about what rules an agent 1256 should apply before forwarding an OLR?] 1258 The lack of end-to-end protection creates a tension between two 1259 requirements from the overload control requirements document. 1260 [I-D.ietf-dime-overload-reqs] Requirement 34 requires the ability 1261 to send overload reports across intermediaries (i.e. agents) that 1262 do not support overload control mechanism. Requirement 27 forbids 1263 the mechanism from adding new vulnerabilities or increasing the 1264 severity of existing ones. A non-supporting agent will most 1265 likely forward overload reports without inspecting them or 1266 applying any sort of validation or authorization. This makes the 1267 transitive trust issue considerably more of a problem. Without 1268 the ability to authenticate and integrity protect overload reports 1269 across a non-supporting agent, the mechanism cannot comply with 1270 both requirements. 1272 [OpenIssue: What do we want to do about this? Req27 is a 1273 normative MUST, while Req34 is "merely" a SHOULD. This would seem 1274 to imply that 27 has to take precedent. Can we say that overload 1275 reports MUST NOT be sent to and/or accepted from non-supporting 1276 agents until such time we can use end-to-end security?] 1278 The lack of end-to-end confidentiality protection means that any 1279 Diameter agent in the path of an overload report can view the 1280 contents of that report. In addition to the requirement to select 1281 which peers are trusted to send overload reports, operators MUST be 1282 able to select which peers are authorized to receive reports. A node 1283 MUST not send an overload report to a peer not authorized to receive 1284 it. Furthermore, an agent MUST remove any overload reports that 1285 might have been inserted by other nodes before forwarding a Diameter 1286 message to a peer that is not authorized to receive overload reports. 1288 At the time of this writing, the DIME working group is studying 1289 requirements for adding end-to-end security 1290 [I-D.ietf-dime-e2e-sec-req] features to Diameter. These features, 1291 when they become available, might make it easier to establish 1292 trust in non-adjacent nodes for overload control purposes. 1293 Readers should be reminded, however, that the overload control 1294 mechanism encourages Diameter agents to modify AVPs in, or insert 1295 additional AVPs into, existing messages that are originated by 1296 other nodes. If end-to-end security is enabled, there is a risk 1297 that such modification could violate integrity protection. The 1298 details of using any future Diameter end-to-end security mechanism 1299 with overload control will require careful consideration, and are 1300 beyond the scope of this document. 1302 9. Contributors 1304 The following people contributed substantial ideas, feedback, and 1305 discussion to this document: 1307 o Eric McMurry 1309 o Hannes Tschofenig 1311 o Ulrich Wiehe 1313 o Jean-Jacques Trottin 1315 o Lionel Morand 1317 o Maria Cruz Bartolome 1319 o Martin Dolly 1321 o Nirav Salot 1323 o Susan Shishufeng 1325 10. Acknowledgements 1327 ... 1329 11. References 1331 11.1. Normative References 1333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1334 Requirement Levels", BCP 14, RFC 2119, March 1997. 1336 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1337 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1338 May 2008. 1340 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1341 "Diameter Base Protocol", RFC 6733, October 2012. 1343 11.2. Informative References 1345 [I-D.ietf-dime-e2e-sec-req] 1346 Tschofenig, H., Korhonen, J., Zorn, G., and K. Pillay, 1347 "Diameter AVP Level Security: Scenarios and Requirements", 1348 draft-ietf-dime-e2e-sec-req-00 (work in progress), 1349 September 2013. 1351 [I-D.ietf-dime-overload-reqs] 1352 McMurry, E. and B. Campbell, "Diameter Overload Control 1353 Requirements", draft-ietf-dime-overload-reqs-13 (work in 1354 progress), September 2013. 1356 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 1357 Loughney, "Diameter Credit-Control Application", RFC 4006, 1358 August 2005. 1360 Appendix A. Issues left for future specifications 1362 The base solution for the overload control does not cover all 1363 possible use cases. A number of solution aspects were intentionally 1364 left for future specification and protocol work. 1366 A.1. Additional traffic abatement algorithms 1368 This specification describes only means for a simple loss based 1369 algorithm. Future algorithms can be added using the designed 1370 solution extension mechanism. The new algorithms need to be 1371 registered with IANA. See Sections 4.1 and 7 for the required IANA 1372 steps. 1374 A.2. Agent Overload 1376 This specification focuses on Diameter end-point (server or client) 1377 overload. A separate extension will be required to outline the 1378 handling the case of agent overload. 1380 A.3. DIAMETER_TOO_BUSY clarifications 1382 The current [RFC6733] behaviour in a case of DIAMETER_TOO_BUSY is 1383 somewhat underspecified. For example, there is no information how 1384 long the specific Diameter node is willing to be unavailable. A 1385 specification updating [RFC6733] should clarify the handling of 1386 DIAMETER_TOO_BUSY from the error answer initiating Diameter node 1387 point of view and from the original request initiating Diameter node 1388 point of view. Further, the inclusion of possible additional 1389 information providing APVs should be discussed and possible be 1390 recommended to be used. 1392 Appendix B. Conformance to Requirements 1394 The following section analyses, which Diameter Overload Control 1395 requirements [I-D.ietf-dime-overload-reqs] are met by this 1396 specification. 1398 Key: 1400 S - Supported 1402 P - Partial 1404 N - Not supported 1406 +------+----+-------------------------------------------------------+ 1407 | Rqmt | S/ | Notes | 1408 | # | P/ | | 1409 | | N | | 1410 +------+----+-------------------------------------------------------+ 1411 | REQ | P | The DOIC solution only addresses overload | 1412 | 1 | | information. Load information is left as future | 1413 | | | work. In addition, the DOIC solution does not | 1414 | | | address agent overload scenarios. | 1415 | | | - | 1416 | REQ | P | The DOIC solution supports overload reports that | 1417 | 2 | | implicitly indicate the application impacted by the | 1418 | | | report. The DOIC solution does not support reporting | 1419 | | | load information. The DOIC solution is thought to | 1420 | | | support graceful behavior. Allowing an application | 1421 | | | specific capabilities negotiation mechanism violates | 1422 | | | application-independence. Suggested different | 1423 | | | wording: The DOIC solution supports overload reports | 1424 | | | that are applicable to any Diameter application. The | 1425 | | | DOIC solution does not support reporting load | 1426 | | | information. The DOIC solution allows to support | 1427 | | | graceful behavior; this will be enhanced when the | 1428 | | | Load information will be defined. Comment: Can we | 1429 | | | removed the words "is thought"? | 1430 | | | - | 1431 | REQ | S | The DOIC solution is thought to address this | 1432 | 3 | | requirement. Comment: Can we removed the words "is | 1433 | | | thought"? | 1434 | | | - | 1435 | REQ | P | The DOIC solution does allow for both both a Diameter | 1436 | 4 | | server and a Diameter client to send overload | 1437 | | | reports. The DOIC solution only addresses Diameter | 1438 | | | end-point (server and client) overload. Agent | 1439 | | | overload is being addressed in a separate draft. | 1440 | | | - | 1441 | REQ | S | The DOIC solution does not depend on how the | 1442 | 5 | | end-points are discovered. Comment: it might be | 1443 | | | worth working through at least one use case showing | 1444 | | | DNS based dynamic peer discovery to make sure we | 1445 | | | haven't missed anything. | 1446 | | | - | 1447 | REQ | ? | Need to update text as some configuation is required. | 1448 | 6 | | Need to determin if the current discussion on | 1449 | | | overload application id increases the amount of | 1450 | | | configuration which would change this to a N. | 1451 | | | - | 1452 | REQ | S | The DOIC solution supports the loss algorithm, which | 1453 | 7 | | is expected to address this requirement. There is | 1454 | | | concern about the ability to address oscillations. | 1455 | | | Wording is included for how a reacting node starts to | 1456 | | | increase traffic after an overload report expires to | 1457 | | | address this concern. Suggested different wording: | 1458 | | | The DOIC solution supports a baseline mechanism | 1459 | | | relying on traffic reduction percentage that is a | 1460 | | | loss algorithm, which allows to address this | 1461 | | | requirement. Oscillations are avoided or quite | 1462 | | | minimized by sending successive OLR reports with the | 1463 | | | values to converge to the optimal traffic or to | 1464 | | | smoothly come back to normal traffic conditions when | 1465 | | | overload decreases and ends. | 1466 | | | - | 1467 | REQ | ? | The DOIC solution supports a timestamp which is meant | 1468 | 8 | | to serve as a report version indication to address | 1469 | | | this requirement. Comment: The use of the timestamp | 1470 | | | is under discussion. | 1471 | | | - | 1472 | REQ | ? | The DOIC solution uses a piggybacking strategy for | 1473 | 9 | | carrying overload reports, which scales lineraly with | 1474 | | | the amount of traffic. As such, the first part of | 1475 | | | the requirement is addressed. The DOIC solution does | 1476 | | | not support a mechanism for sending overload reports | 1477 | | | over a quiescent transport connections or, more | 1478 | | | generally, to Diameter nodes that are not producing | 1479 | | | traffic. Suggested different wording: The DOIC | 1480 | | | solution uses a piggybacking strategy for carrying | 1481 | | | overload reports. As such, the first part of the | 1482 | | | requirement is addressed. For a connection that has | 1483 | | | become quiescent due to OLRs with a 100% traffic | 1484 | | | reduction, the validity timer allows to handle this | 1485 | | | case. Other cases of quiescent connections are | 1486 | | | outside the scope of Diameter overload (e.g. their | 1487 | | | handling may be done through the watch dog of the | 1488 | | | Diameter base protocol). | 1489 | | | - | 1490 | REQ | S | The DOIC solution supports two methods for managing | 1491 | 10 | | the length of an overload condition. First, all | 1492 | | | overload reports must contain a duration indication, | 1493 | | | after which the node reacting to the report can | 1494 | | | consider the overload condition as ended. Secondly, | 1495 | | | the solution supports the method for the node | 1496 | | | originating the overload report to explicitly | 1497 | | | communicate that the condition has ended. This | 1498 | | | latter mechanism depends on traffic to be sent from | 1499 | | | the reacting node and, as such, can not be depended | 1500 | | | upon in all circumstances. | 1501 | | | - | 1502 | REQ | ? | The DOIC solution works well for small network | 1503 | 11 | | configurations and for network configurations with a | 1504 | | | single Diameter agent hop. More analysis is required | 1505 | | | to determine how well the DOIC solution handles very | 1506 | | | large Diameter network with partitioned or segmented | 1507 | | | server farms requiring multiple hops through Diameter | 1508 | | | agents. | 1509 | | | - | 1510 | REQ | P | The DOIC solution focuses on Diameter end-point | 1511 | 12 | | overload and meets this requirement for those | 1512 | | | Diameter nodes. The DOIC solution does not address | 1513 | | | Diameter Agent overload and does not meet this | 1514 | | | requirement for those Diameter nodes. | 1515 | | | - | 1516 | REQ | ? | The DOIC solution requires including of the overload | 1517 | 13 | | report in all answer messages in some situations. It | 1518 | | | is not agreed, however, that this constitutes | 1519 | | | substantial work. This can also be mitigated by the | 1520 | | | sender of the overload report keeping state to record | 1521 | | | who has received overload reports. It is left to | 1522 | | | implementation decisions as to which approach is | 1523 | | | taken -- send in all messages or send once with a | 1524 | | | record of who has received the report. Another way | 1525 | | | is to let the request sender (reacting node) insert | 1526 | | | information in the request to say whether a | 1527 | | | throttling is actually performed. The reporting node | 1528 | | | then can base its decision on information received in | 1529 | | | the request; no need for keeping state to record who | 1530 | | | has received overload reports. The DOIC solution | 1531 | | | also requires capabilities negotiation in every | 1532 | | | request and response message, which increases the | 1533 | | | baseline work required for any node supporting the | 1534 | | | DOIC solution. Suggested additional text: It does | 1535 | | | not, however, require that the information be | 1536 | | | recalculated or updated with each message. The | 1537 | | | update frequency is up to the implementation, and | 1538 | | | each implementation can make decisions on balancing | 1539 | | | the update of overload information along with its | 1540 | | | other priorities. It is expected that using a | 1541 | | | periodically updated OLR report added to all messages | 1542 | | | sent to overload control endpoints will not add | 1543 | | | substantial additional work. Piggyback base | 1544 | | | transport also does not require composition, sending, | 1545 | | | or parsing of new Diameter messages for the purpose | 1546 | | | of conveying overload control information. There is | 1547 | | | still discussion on the substantial additional work | 1548 | | | due to have OLR in each answer message. | 1549 | | | - | 1550 | REQ | S | The DOIC solution uses the piggybacking method to | 1551 | 14 | | deliver overload report, which scales lineraly with | 1552 | | | the amount of traffic. This allows for immediate | 1553 | | | feedback to any node generating traffic toward | 1554 | | | another overloaded node. | 1555 | | | - | 1556 | REQ | S | The DOIC solution does not interfere with transport | 1557 | 15 | | protocols. | 1558 | | | - | 1559 | REQ | ? | The DOIC solution allows for a mixed network of | 1560 | 16 | | supporting and non supporting Diameter end-points. | 1561 | | | It isn't clear how realm overload is handled in a | 1562 | | | network with agents that do not support the DOIC | 1563 | | | solution. Suggested additional wording: Evaluation | 1564 | | | of Realm overload may require a DA supporting DOIC, | 1565 | | | if the realm overload is not evaluated by the client. | 1566 | | | Realm overload handling is still under discussion. | 1567 | | | - | 1568 | REQ | ? | Suggested wording: The DOIC solution addresses this | 1569 | 17 | | requirement through the loss algorithm (DOIC baseline | 1570 | | | mechanism) with the following possibilities. A DA | 1571 | | | supporting DOIC can act on behalf of clients not | 1572 | | | supporting DOIC. A reporting node is also aware of | 1573 | | | the nodes not supporting the DOIC as there is no | 1574 | | | advertisement of the DOIC support. It may then apply | 1575 | | | a particular throttling of the requests coming from | 1576 | | | these non supporting DOIC clients. | 1577 | | | - | 1578 | REQ | ? | It isn't clear yet that if this requirement is | 1579 | 18 | | addressed. There has been a proposal to mark | 1580 | | | messages that survived overload throttling as one | 1581 | | | method for an overloaded node to address fairness but | 1582 | | | this proposal is not yet part of the solution. It is | 1583 | | | also possible that the overloaded node could use | 1584 | | | state gathered as part of the capability | 1585 | | | advertisement mechanism to know if the sending node | 1586 | | | supports the DOIC solution and if not, to apply a | 1587 | | | particular throttling of the requests coming from | 1588 | | | these non supporting DOIC clients. | 1589 | | | - | 1590 | REQ | S | The DOIC solution supports the ability for the | 1591 | 19 | | overloaded node and the reacting node to be in | 1592 | | | different administrative domains. | 1593 | | | - | 1594 | REQ | ? | This mechanism is still under discussion. Comment 1: | 1595 | 20 | | I think this is a "S". OLRs are clearly | 1596 | | | distinguishable from any error code. The fact that | 1597 | | | an agent would need to send errors if it throttles is | 1598 | | | not an overload indication per se. It needs to do | 1599 | | | that even without DoC. OTOH, if we apply some DOC | 1600 | | | related fix to TOO_BUSY, we probably need a new code. | 1601 | | | Comment 2: New AVPs conveys overload control | 1602 | | | information, and this is transported on existing | 1603 | | | answer messages, so distinguishable from Diameter | 1604 | | | errors. | 1605 | | | - | 1606 | REQ | S | The inability for a node to send overload reports | 1607 | 21 | | will result in equivalent through put to a network | 1608 | | | that does not support the DOIC solution. | 1609 | | | - | 1610 | REQ | S | The DOIC solution gives this node generating the | 1611 | 22 | | overload report the ability to control the amount of | 1612 | | | throttling done by the reacting node using the | 1613 | | | reduction percentage parameter in the overload | 1614 | | | report. | 1615 | | | - | 1616 | REQ | ? | Initial text: The DOIC mechanism supports two | 1617 | 23 | | abatement strategies by reacting nodes, routing to an | 1618 | | | alternative node or dropping traffic. The routing to | 1619 | | | an alternative node will be enhanced when the Load | 1620 | | | extension is defined. Comment: This is a N. There's | 1621 | | | no good way to determine which nodes are likely to | 1622 | | | have sufficient capacity without some sort of load | 1623 | | | metric for non-overloaded nodes. | 1624 | | | - | 1625 | REQ | N | The DOIC solution does not address delivering load | 1626 | 24 | | information. | 1627 | | | - | 1628 | REQ | S | The DOIC solution contains some guideance. | 1629 | 25 | | | 1630 | | | - | 1631 | REQ | S | The DOIC solution does not constrain a nodes ability | 1632 | 26 | | to determine which requests are trottled. | 1633 | | | - | 1634 | REQ | ? | Initial text: The DOIC solution does add a new line | 1635 | 27 | | of attack in the ability for a malicious entity to | 1636 | | | insert overload reports that would reduce or | 1637 | | | eliminate traffic. This, however, is no worse than | 1638 | | | an attacker that would assert erroneous error | 1639 | | | responses such as a TOO BUSY response. It is | 1640 | | | recognized that the end-to-end security solution | 1641 | | | currently being worked on by the DIME working group | 1642 | | | is needed to close these types of vulurabilities. | 1643 | | | Comment: Sending a malicious OLR with a type of | 1644 | | | "realm" will have considerably more impact than a | 1645 | | | TOO_BUSY. Personally, I don't think we can achieve | 1646 | | | this requirement without either being hop-by-hop or | 1647 | | | requiring e2e security. We probably need further | 1648 | | | analysis of the security implications of the | 1649 | | | capabilities negotiation as well. Suggested | 1650 | | | additional verbage: An OLR only relates to the | 1651 | | | traffic between a reporting node and a reacting node | 1652 | | | and can effectively block the traffic from a client | 1653 | | | which would be an important impact. Nevertheless | 1654 | | | OLRs are regularly sent in all answers, so a | 1655 | | | malicious OLR will have a short transient effect, as | 1656 | | | quickly overridden by a new OLR. To have a | 1657 | | | significant impact would require a continuous flow of | 1658 | | | answers with malicious OLRs. There is the exception | 1659 | | | of the OLR with a value of 100% reduction traffic | 1660 | | | which has a higher vulnerability and the use of which | 1661 | | | should be avoided when possible. In addition such | 1662 | | | malicious OLRs must be in answers, which means the | 1663 | | | capability to insert the malicious OLR in an existing | 1664 | | | answer rather than to create an answer which is much | 1665 | | | less easy than to create a request. To have a | 1666 | | | network wide applicability would request to generate | 1667 | | | malicious OLRs messages towards all reacting nodes. | 1668 | | | It can be considered that the baseline mechanism | 1669 | | | offer a relevant level of security. Further analysis | 1670 | | | with a security expertise would be beneficial. | 1671 | | | - | 1672 | REQ | ? | See REQ 18 and REQ 27. Suggested additional verbage: | 1673 | 28 | | Guidance may be provided for detection of non | 1674 | | | compliant/abnormal use of OLRs, not only by endpoints | 1675 | | | but also by intermediate DA that can be aware of | 1676 | | | OLRs, an example being edge DAs with external | 1677 | | | networks. Further analysis with a security expertise | 1678 | | | would be beneficial. | 1679 | | | - | 1680 | REQ | ? | This requirement is not explicitly addressed by the | 1681 | 29 | | DOIC solution. There is nothing in the DOIC solution | 1682 | | | that would prevent the goals of this requirement from | 1683 | | | being achieved. Non-adjacent DOIC without e2e | 1684 | | | security could be an issue here. | 1685 | | | - | 1686 | REQ | ? | It isn't clear how a solution would interfere. | 1687 | 30 | | Suggested wording: A node can have methods on how to | 1688 | | | protect from overload from nodes non supporting DOIC. | 1689 | | | The DOIC mechanism used with DOIC supporting nodes | 1690 | | | will not interfere with the appliance of these | 1691 | | | methods. There is the remark that the use of these | 1692 | | | methods may impact the global overload of the node | 1693 | | | and the evaluation of the traffic reduction that the | 1694 | | | reporting node will send in OLRs. If a node has | 1695 | | | methods to protect against denial of service attacks, | 1696 | | | the use of DOIC will not interfere with them. A | 1697 | | | denial of service attack concerning the DOIC itself | 1698 | | | is addressed in REQ 27. | 1699 | | | - | 1700 | REQ | ? | Initial text with an S: The DOIC solution addresses | 1701 | 31 | | node and realm directly. The application to which a | 1702 | | | report applies is implicitly determined based on the | 1703 | | | application level message carrying the report. Note | 1704 | | | that there is no way with DOIC for an overloaded node | 1705 | | | to communicate multiple nodes, realms or applications | 1706 | | | in a single overload report. So the inverse of this | 1707 | | | requirement is not supported. Comment: The inverse | 1708 | | | is also not _required_ :-) But I think we are "P" | 1709 | | | here, in that we don't support "node" per se. we do | 1710 | | | support "server." "Node" includes agents. (I also | 1711 | | | interpreted this to mean that each granularity needed | 1712 | | | to be supported independently--that is, a potential | 1713 | | | to say "all traffic to a realm" or "all traffic to a | 1714 | | | host" independently of application.) | 1715 | | | - | 1716 | REQ | ? | Initial text with an S: The DOIC solution supports | 1717 | 32 | | extensibility of both the information communicated | 1718 | | | and in the definition of new overload abatement | 1719 | | | algorithms. Comment 1: Recent discussions have made | 1720 | | | this a ?. It can be changed to S/N/P once these | 1721 | | | discussions come to a conclusion and new text is | 1722 | | | added to the draft. Comment 2: Suggested wording - | 1723 | | | The DOIC solution supports extensibility of both the | 1724 | | | information communicated and in the definition of new | 1725 | | | overload abatement algorithms or strategies. It | 1726 | | | should be noted that, according to the applications | 1727 | | | or to reacting node implementations, many algorithms | 1728 | | | may be applied on top of the DOIC baseline solution | 1729 | | | (without contradicting it), e.g. regarding which type | 1730 | | | of request to throttle, prioritized messages | 1731 | | | handling, mapping of the reduction % to an internal | 1732 | | | algorithm (eg 1 message out of ten etc..) but such | 1733 | | | algorithms are out of scope of DOIC. | 1734 | | | - | 1735 | REQ | ? | Initial text with P: The DOIC solution currently | 1736 | 33 | | defines the loss algorithm as the default algorithm. | 1737 | | | It does not specify it as mandatory to implement. | 1738 | | | Comment 1: Then I think that's a "n". The MTI part | 1739 | | | is the crux of the requirement. Comment 2: Suggested | 1740 | | | wording: In the DOIC baseline solution, the reacting | 1741 | | | node has to apply the received Reduction-Percentage, | 1742 | | | and for achieving this, the reacting node can do | 1743 | | | requests rerouting (when it is possible) or | 1744 | | | drop/reject requests. This DOIC baseline solution is | 1745 | | | a loss algorithm and DOIC should not require further | 1746 | | | specification. The answer to REQ32 indicates the | 1747 | | | possibility to add other algorithms on top of the | 1748 | | | DOIC baseline solution. The DOIC solution currently | 1749 | | | defines this loss algorithm as the default algorithm. | 1750 | | | It is still under discussion to make it as mandatory | 1751 | | | to implement. | 1752 | | | - | 1753 | REQ | P | The ability to communicate overload reports between | 1754 | 34 | | supporting Diameter nodes does not require agents to | 1755 | | | support the DOIC solution. Load information exchange | 1756 | | | is not currently defined. | 1757 +------+----+-------------------------------------------------------+ 1759 Table 1 1761 Appendix C. Examples 1763 C.1. 3GPP S6a interface overload indication 1765 [TBD: Would cover S6a MME-HSS communication with several topology 1766 choices (such as with or without DRA, and with "generic" agents).] 1768 C.2. 3GPP PCC interfaces overload indication 1770 [TBD: Would cover Gx/Rx and maybe S9..] 1772 C.3. Mix of Destination-Realm routed requests and Destination-Host 1773 reouted requests 1775 [TBD: Add example showing the use of Destination-Host type OLRs and 1776 Realm type OLRs.] 1778 Authors' Addresses 1780 Jouni Korhonen (editor) 1781 Broadcom 1782 Porkkalankatu 24 1783 Helsinki FIN-00180 1784 Finland 1786 Email: jouni.nospam@gmail.com 1788 Steve Donovan 1789 Oracle 1790 17210 Campbell Road 1791 Dallas, Texas 75254 1792 United States 1794 Email: srdonovan@usdonovans.com 1796 Ben Campbell 1797 Oracle 1798 17210 Campbell Road 1799 Dallas, Texas 75254 1800 United States 1802 Email: ben@nostrum.com