idnits 2.17.1 draft-ietf-dime-agent-overload-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 -- The document date (December 17, 2014) is 3390 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) == Missing Reference: 'DOIC' is mentioned on line 520, but not defined == Unused Reference: 'RFC5226' is defined on line 802, but no explicit reference was found in the text -- No information found for draft-ietf-dime-ovli - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-dime-ovli' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 7068 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions (DIME) S. Donovan 3 Internet-Draft Oracle 4 Intended status: Standards Track December 17, 2014 5 Expires: June 20, 2015 7 Diameter Agent Overload 8 draft-ietf-dime-agent-overload-00.txt 10 Abstract 12 This specification documents an extension to the Diameter Overload 13 Control (DOC) base solution. The extension addresses the handling of 14 occurrances of overload of a Diameter agent. 16 Requirements 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 20, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 58 3. Peer Report Use Cases . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 4 60 3.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 5 61 3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 6 62 3.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 7 63 3.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 8 64 3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 8 65 4. Interaction Between Host/Realm and Peer Overload Reports . . 8 66 5. Peer Report Behavior . . . . . . . . . . . . . . . . . . . . 8 67 5.1. Capability Announcement . . . . . . . . . . . . . . . . . 9 68 5.2. Peer Report Overload Report Handling . . . . . . . . . . 10 69 5.2.1. Overload Control State . . . . . . . . . . . . . . . 10 70 5.2.2. Reporting Node Maintenace of Peer Report OCS . . . . 11 71 5.2.3. Reacting Node Maintenace of Peer Report OCS . . . . . 12 72 5.2.4. Peer Report Reporting Node Behavior . . . . . . . . . 13 73 5.2.5. Peer Report Reacting Node Behavior . . . . . . . . . 13 74 6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14 75 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14 76 6.1.1. OC-Feature-Vector . . . . . . . . . . . . . . . . . . 15 77 6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 15 78 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15 79 6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 16 80 6.3. OC-SourceID . . . . . . . . . . . . . . . . . . . . . . . 16 81 6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 16 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 85 10. Normative References . . . . . . . . . . . . . . . . . . . . 17 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 This document defines the behavior of Diameter nodes when Diameter 91 agents enter an overload condition and send an overload report 92 requesting a reduction of traffic. 94 The base Diameter overload specification [I-D.ietf-dime-ovli] 95 addresses the handling of overload when a Diameter endpoint (a 96 Diameter Client or Diameter Server as defined in [RFC6733]) becomes 97 overloaded. 99 In the base specification, the goal is to handle abatement of the 100 overload occurrance as close to the source of the Diameter traffic as 101 is feasible. When possible this is done at the originator of the 102 traffic, generally referred to as a Diameter Client. A Diameter 103 Agent might also handle the overload mitigation. For instance, a 104 Diameter Agent might handle Diameter overload mitigation when it 105 knows that a Diameter Client does not support the DOIC extension. 107 This document extends the base Diameter endpoint overload 108 specification to address the case when Diameter Agents become 109 overloaded. Just as is the case with other Diameter nodes -- 110 Diameter Clients and Diameter Servers -- surges in Diameter traffic 111 can cause a Diameter Agent to be asked to handle more Diameter 112 traffic than it was configured to handle. For a more detailed 113 discussion of what can cause the overload of Diameter nodes, refer to 114 the Diameter Overload Requirements [RFC7068]. 116 This document defines a new overload report type to communicate 117 occurrances of agent overlaod. This report type works for the "Loss" 118 overload mitigation algorithm defined in [I-D.ietf-dime-ovli] and is 119 expected to work for other overload abatement algorithms defined in 120 extensions to the DOIC solution. 122 The handling of endpoint overload and agent overload is very similar. 123 The primary differences are the following: 125 o Endpoint overload is handled as close to the originator of the 126 traffic as possible. 128 o Agent overload is handled by the previous hop Diameter Node. 130 o Endpoint overload mitigation deals with traffic targeted for a 131 single Diameter application. As such, it is assumed that an 132 overload report impacts just the application implied by the 133 message carrying the overload report. 135 o Agent overload deals with all traffic targeted for an agent, 136 independent of the application. As such, a single agent overload 137 report can impact multiple applications. 139 Editor's Note: Open Issue - Does a peer report apply to the 140 implicitly communicated application-id in the same way as host and 141 realm reports do or does it apply to all applications handled by the 142 peer? Do we need the ability for to support both cases? 143 Open Issue - To support the ability of an agent to select a different 144 abatement algorithm than endpoints, we probably need to extend the 145 OC-Supported-Features AVP to include an OC-Abatement-Algorithm AVP. 146 This is currently shown to be in the OC-OLR AVP but needs to be moved 147 as this information is needed prior to receiving the OC-OLR. It 148 probably needs to be changed to OC-Peer-Abatement-Algorithm. 150 2. Terminology and Abbreviations 152 Editors note - These definitions need to be made consistent with the 153 base Diameter overload specification defined in [I-D.ietf-dime-ovli]. 155 Diameter Node 157 A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733 158 agent. 160 Diameter Endpoint 162 An RFC6733 Diameter Client and RFC6733 Server. 164 Reporting Node 166 A DOIC Node that sends and overload report in Diameter answer 167 message. 169 Reacting Node 171 A DOIC Node that receives and acts on a Diameter overload report. 173 DIOC Node 175 A Diameter Node that supports the DOIC solution defined in 176 [I-D.ietf-dime-ovli]. 178 3. Peer Report Use Cases 180 This section outlines representative use cases for the peer report. 182 There are two primary classes of use cases, those involving the 183 overload of agents and those involving overload of Diameter endpoints 184 (Diameter Clients and Diameter Servers). 186 3.1. Diameter Agent Overload Use Cases 188 The agent overload extension must support following use cases. 190 3.1.1. Single Agent 192 This use case is illustrated in Figure 1. In this case, the client 193 sends all traffic through the single agent. If there is a failure in 194 the agent then the client is unable to send Diameter traffic toward 195 the server. 197 +-+ +-+ +-+ 198 |c|----|a|----|s| 199 +-+ +-+ +-+ 201 Figure 1 203 A more likely case for the use of agents is illustrated in Figure 2. 204 In this case, there are multiple servers behind the single agent. 205 The client sends all traffic through the agent and the agent 206 determines how to distribute the traffic to the servers based on 207 local routing and load distribution policy. 209 +-+ 210 --|s| 211 +-+ +-+ / +-+ 212 |c|----|a|- ... 213 +-+ +-+ \ +-+ 214 --|s| 215 +-+ 217 Figure 2 219 In both of these cases, the occurrence of overload in the single 220 agent must by handled by the client in a similar fashion as if the 221 client were handling the overload of a directly connected server. 222 When the agent becomes overloaded it will insert an overload report 223 in answer messages flowing to the client. This overload report will 224 contain a requested reduction in the amount of traffic sent to the 225 agent. The client will apply overload abatement behavior as defined 226 in the base Diameter overload specification [I-D.ietf-dime-ovli] or 227 the extension draft that defines the indicated overoad abatement 228 algorithm. This will result in the abated traffic that would have 229 been sent to the agent being dropped, as there is no alternative 230 route, with the appropriate indication given to the service request 231 that resulted in the need for the Diameter transaction. 233 Editor's note: Need to address case where the agent requests a 234 different abatement algorithm than requested by a host or realm 235 reporting node. 237 3.1.2. Redundant Agents 239 Figure 3 and Figure 4 illustrate a second, and more likely,type of 240 deployment scenario involving agents. In both of these cases, the 241 client has Diameter connections to two agents. 243 Figure 3 illustrates a client that has a primary connection to one of 244 the agents (agent a1) and a secondary connection to the other agent 245 (agent a2). In this scenario, under normal circumstances, the client 246 will use the primary connection for all traffic. The secondary 247 connection is used when there is a failure scenario of some sort. 249 +--+ +-+ 250 --|a1|---|s| 251 +-+ / +--+\ /+-+ 252 |c|- x 253 +-+ . +--+/ \+-+ 254 ..|a2|---|s| 255 +--+ +-+ 257 Figure 3 259 The second case, in Figure 4, illustrates the case where the 260 connections to the agents are both actively used. In this case, the 261 client will have local distribution policy to determine the 262 percentage of the traffic sent through each client. 264 +--+ +-+ 265 --|a1|---|s| 266 +-+ / +--+\ /+-+ 267 |c|- x 268 +-+ \ +--+/ \+-+ 269 --|a2|---|s| 270 +--+ +-+ 272 Figure 4 274 In the case where one of the agents in the above scenarios become 275 overloaded, the client should reduce the amount of traffic sent to 276 the overloaded agent by the amount requested. This traffic should 277 instead be routed through the non-overloaded agent. For example, 278 assume that the overloaded agent requests a reduction of 10 percent. 279 The client should send 10 percent of the traffic that would have been 280 routed to the overloaded agent through the non-overloaded agent. 282 When the client has an active and a standby connection to the two 283 agents then an alternative strategy for responding to an overload 284 report from an agent is to change to standby connection to active and 285 route all traffic through the new active connection. 287 In the case where both agents are reporting overload, the client may 288 need to start decreasing the total traffic sent to the agents. This 289 would be done in a similar fashion as discussed in section 3.1. The 290 amount of traffic depends on the combined reduction requested by the 291 two agents. 293 3.1.3. Agent Chains 295 There are also deployment scenarios where there can be multiple 296 Diameter Agents between Diameter Clients and Diameter Servers. 297 Examples of this type of deployment include when there are edge 298 agents between Diameter networks. Another example of this type of 299 deployment is when there are multiple sets of servers, each 300 supporting a subset of the Diameter traffic. 302 Figure 5 illustrates one such network deployment case. Note that 303 while this figure shows a maximum of two agents being involved in a 304 Diameter transaction, it is possible that more than two agents could 305 be in the path of a transaction. 307 +---+ +---+ +-+ 308 --|a11|-----|a21|---|s| 309 +-+ / +---+ \ / +---+\ /+-+ 310 |c|- x x 311 +-+ \ +---+ / \ +---+/ \+-+ 312 --|a12|-----|a22|---|s| 313 +---+ +---+ +-+ 315 Figure 5 317 Handling of overload of one or both of agents a11 or a12 in this case 318 is equivalent to that discussed in section 2.2. 320 Overload of agents a21 and a22 must be handled by the previous hop 321 agents. As such, agents a11 and a12 must handle the overload 322 mitigation logic when receiving an agent overload report from agents 323 a21 and a22. 325 Editor's note: Probably need to elaborate the reasoning behind the 326 need for the agent overload report being handled by the previous hop 327 agent. 329 The handling of the overload reports is similar to that discussed in 330 section 2.2. If the overload can be addressed using diversion then 331 this approach should be taken. 333 If both of the agents have requested a reduction in traffic then the 334 previous hop agent must start throttling the appropriate percentage 335 of transactions. When throttling requests, the agent must use the 336 same error responses as defined in the base DOIC specification 337 [I-D.ietf-dime-ovli]. 339 3.2. Diameter Endpoint Use Cases 341 This section outlines use cases for the peer report feature involving 342 Diameter Clients and Diameter Servers. 344 3.2.1. Hop-by-hop Abatement Algorithms 346 It is envisioned that abatement algorithms will be defined that will 347 support the option for Diameter Endpoints to send peer reports. For 348 instance, it is envisioned that one usage scenario for the rate 349 algorithm, which is being worked on by the DIME working group as this 350 is written, will involve abatement being done on a hop-by-hop basis. 352 This rate deployment scenario would involve Diameter Endpoints 353 generating peer reports and selecting the rate algorithm for 354 abatement of overload conditions. 356 4. Interaction Between Host/Realm and Peer Overload Reports 358 It is possible that both an agent and a server in the path of a 359 transaction are overloaded at the same time. When this occurs, 360 Diameter entities will need to handle both overload reports. When 361 this occurs the reacting node should first handle the throttling of 362 the overloaded host or realm. Any messages that survive throttling 363 due to host or realm reports should then go through abatement for the 364 peer overload report. 366 Editor's note: Do we need to prevent double throttling of requests 367 or is that a local implementation consideration? 369 5. Peer Report Behavior 371 This section defines the normative behavior associated with the Peer 372 Report extension to the DOIC solution. 374 5.1. Capability Announcement 376 Editor's Note: Issue - how does an agent indicate the selected 377 abatement algorithm? It cannot use the OC-Feature-Vector in the OC- 378 Supported-Features AVP as that applies to host and realm report 379 types. Need a new AVP in the OC-Supported-Features AVP. 381 When sending a Diameter request a DOIC node that supports the Peer 382 Report feature MUST include an OC-Supported-Features AVP with an OC- 383 Feature-Vector AVP with the OLR_PEER_REPORT bit set. 385 The sender of a request can be a Diameter Client or Diameter 386 Server that originates the Diamter request or a Diameter Agent 387 that relays the request. 389 Support for the peer report feature does not impact the logic for 390 setting of other feature bits in the OC-Feature-Vector AVP. 392 When sending a request a DOIC node that supports the Peer Report 393 feature MUST include an OC-SourceID AVP in the OC-Supported-Features 394 AVP with its own DiameterID. 396 This allows the next DOIC node in the path of the request to 397 determine if the indication of support came from a Diameter peer 398 or if the request traversed a node that does not support the peer 399 feature. 401 When receiving a request a DOIC node that supports the Peer Report 402 feature MUST update transaction state with an indication of whether 403 or not the peer from which the request was received supports the Peer 404 Report feature. 406 The transaction state is used when the DOIC node is acting as a 407 peer report reporting node and needs to insert OC-OLR reports of 408 type peer into answer messages. The OLR should only be included 409 in answer messages being sent to peers that support the peer 410 report feature. 412 The following are indications that the peer does not support the Peer 413 Reports feature: 415 The request does not contain an OC-Supported-Features AVP. 417 The received request contains an OC-Supported-Features AVP with no 418 a OC-Feature-Vector. 420 The received request contains an OC-Supported-Features AVP with a 421 OC-Feature-Vector with the OLR_PEER_REPORT feature bit cleared. 423 The received request contains an OC-Supported-Features AVP with a 424 OC-Feature-Vector with the OLR_PEER_REPORT feature bit set but 425 with an OC-SourceID AVP with a DiameterID that does not match the 426 DiameterID of the peer from which the request was received. 428 The peer supports the Peer Reports feature if the received request 429 contains an OC-Supported-Features AVP with the OC-Feature-Vector with 430 the OLR_PEER_REPORT feature bit set and with an OC-SourceID AVP with 431 a Diameter ID that matches the DiameterID of the peer from which the 432 request was received. 434 When receiving a request a DOIC node that supports the Peer Report 435 feature MUST remove any received OC-SourceID AVP from the OC- 436 Supported-Features AVP. This is done to prevent the OC-SourceID AVP 437 from being included in a relayed message through a node that supports 438 the Peer Report feature. 440 Editor's Note: Need to add behavior for handling of answer messages 441 to define how the OC-Supported-Features AVP that will be included in 442 a relayed answer message is constructed. This includes logic on 443 whether or not the peer report feature bit is set and whether or not 444 the OC-Peer-Algo AVP is included in the OC-Supported-Features AVP. 446 5.2. Peer Report Overload Report Handling 448 This section defines the behavior for the handling of overload 449 reports of type peer. 451 5.2.1. Overload Control State 453 This section describes the Overload Control State (OCS) that might be 454 maintained by both the peer report reporting node and the peer report 455 reacting node. 457 5.2.1.1. Reporting Node Peer Report OCS 459 A DOIC Node that supports the Peer Report feature SHOULD maintain 460 Reporting Node Peer Report OCS. This is used to record overload 461 events and build overload reports at the reporting node. 463 If different abatement specific contents are sent to each peer then 464 the reporting node MUST maintain a separate peer node peer report OCS 465 entry per peer to which a peer overload report is sent. 467 The rate overload abatement algorithm allows for different rates 468 to be sent to each peer. 470 The Reporting Node Peer Report OCS entry MAY include the following 471 information (the actual information stored is an implementation 472 decision): 474 o Sequence number 476 o Validity Duration 478 o Expiration Time 480 o Abatement Algorithm 482 o Algorithm specific input data (for example, the Reduction 483 Percentage for the Loss Abatement Algorithm) 485 5.2.1.2. Reacting Node Peer Report OCS 487 A DOIC node that supports the Peer Report feature SHOULD maintain 488 Reacting Node Peer Report OCS for each peer with which it 489 communicates. This is used to record overload reports received from 490 peer nodes. 492 A Reacting Node Peer Report OCS entry is identified by the DiameterID 493 of the peer as communicated during the RFC6733 defined Capability 494 Exchange procedure 496 The Reacting Node Peer Report OCS entry MAY include the following 497 information (the actual information stored is an implementation 498 decision): 500 o Sequence number 502 o Expiration Time 504 o Abatement Algorithm 506 o Algorithm specific input data (for example, the Reduction 507 Percentage for the Loss Abatement Algorithm) 509 5.2.2. Reporting Node Maintenace of Peer Report OCS 511 A reporting node SHOULD create a new Reporting Node Peer Report OCS 512 entry Section 5.2.1.1 in an overload condition and sending a peer 513 overload report to a peer for the first time. 515 If the reporting node knows that there are no reacting nodes 516 supporting the Peer Report feature then the reporting node can 517 choose to not create OCS entries. 519 All rules for managing the reporting node OCS enteries defined in 520 [DOIC] apply to the peer report. 522 5.2.3. Reacting Node Maintenace of Peer Report OCS 524 When a reacting node receives an OC-OLR AVP with an a report type of 525 peer it MUST determine if the report was generated by the Diameter 526 peer from which the report was received. 528 If the DiameterID in the SourceID contained in the OLR matches the 529 DiameterID of the peer from which the request was received then the 530 report was received from a Diameter peer. 532 If a reacting node receives an OC-OLR AVP of type peer and the OC- 533 SourceID does not match the ID of the Diameter peer from which the 534 request was received then the reacting node MUST strip the OC-OLR AVP 535 from the message and not use it to update reacting node peer report 536 OCS entries. 538 If the Peer Report OLR was received from a Diameter peer then the 539 reacting node MUST determine if it is for an existing or new overload 540 condition. 542 The OLR is for an existing overload condition if the reacting node 543 has an OCS that matches the received OLR. 545 For a peer report-type this means the DiameterID received in the 546 SourceID AVP matches the DiameterID of an existing peer report OLR. 548 If the OLR is for an existing overload condition then it MUST 549 determine if the OLR is a retransmission or an update to the existing 550 OLR. 552 If the sequence number for the received OLR is greater than the 553 sequence number stored in the matching OCS entry then the reacting 554 node MUST update the matching OCS entry. 556 If the sequence number for the received OLR is less than or equal to 557 the sequence number in the matching OCS entry then the reacting node 558 MUST silently ignore the received OLR. The matching OCS MUST NOT be 559 updated in this case. 561 If the received OLR is for a new overload condition then the reacting 562 node MUST generate a new OCS entry for the overload condition. 564 Editor's note: The above four paragraphs are copied form the DOIC 565 specification. Is it possible to include this behavior by 566 refrence or do we need to include all of these statements in this 567 specification as well. 569 For a peer report this means it creates an OCS entry with an 570 DiameterID from the SourceID AVP in the received OC-OLR AVP. 572 If the received OLR contains a validity duration of zero ("0") then 573 the reacting node MUST update the OCS entry as being expired. 575 The reacting node does not delete an OCS when receiving an answer 576 message that does not contain an OC-OLR AVP (i.e. absence of OLR 577 means "no change"). 579 The reacting node sets the abatement algorithm based on the OC-Peer- 580 Algo AVP in the received OC-Supported-Features AVP. 582 5.2.4. Peer Report Reporting Node Behavior 584 When there is an existing peer report reporting node OCS entry, the 585 reporting node MUST include an OC-OLR AVP with a report type of peer 586 using the contents of the peer report reporting node OCS entry in all 587 answer messages sent by the reporting node to peers that support the 588 peer report feature. 590 The reporting node determines if a peer supports the peer report 591 feature based on the indication recorded in the reporting nodes 592 transaction state. 594 The reporting node MUST include its DiameterID in the OC-SourceID AVP 595 in the OC-OLR AVP. This is used by DOIC nodes that support the peer 596 report feature to determine if the report was received from a 597 Diameter peer. 599 The reporting agent must follow all other overload reporting node 600 behaviors outlined in the DOIC specification. This includes sending 601 a report with a reduction percentage of zero when the need for a 602 reduction has ended. It also includes sending a new overload report, 603 with a new sequence number, to refresh the abatement duration. 605 5.2.5. Peer Report Reacting Node Behavior 607 A reacting node supporting this extension MUST support the receipt of 608 multiple overload reports in a single message. The message might 609 inlude a host overload report, a realm overload report and a peer 610 overload report. 612 When a reacting node sends a request it MUST determine if that 613 request matches an active OCS. 615 If the request matches and active OCS then the reacting node MUST 616 apply abatement treatment on the request. The abatement treatment 617 applied depends on the abatement algorithm stored in the OCS. 619 For peer overload reports, the preferred abatement treatment is 620 diversion. As such, the reacting node SHOULD attempt to divert 621 requests identified as needing abatement to other peers. 623 If a host-routed request, as defined in the DOIC specification, is 624 selected for abatement and the request must be routed to the DOIC 625 node that generated the peer overload report -- meaning that the 626 request is a host-routed request as defined in the DOIC specification 627 -- then the reacting node MUST throttle the request. 629 This would result from an overloaded Diameter endpoint (Diameter 630 Server or Diameter Client) sending a peer overload report and the 631 request contains a Destination-Host AVP with a DiameterID that 632 matches the DiameterID in the SourceID AVP received in the peer 633 overload report. 635 If there is not sufficient capacity to divert abated traffic then the 636 reacting node MUST throttle the necessary requests to fit within the 637 available capacity of the peers able to handle the requests. 639 If the abatement treatment results in throttling of the request and 640 if the reacting node is an agent then the agent MUST send an 641 appropriate error as defined in the DOIC specification. 643 In the case that the OCS entry validity duration expires or has a 644 validity duration of zero ("0"), meaning that it the reporting node 645 has explicitly signaled the end of the overload condition then 646 abatement associated with the overload abatement MUST be ended in a 647 controlled fashion. 649 6. Peer Report AVPs 651 6.1. OC-Supported-Features AVP 653 This extension adds a new feature to the OC-Feature-Vector AVP. This 654 feature indication shows support for handling of peer overload 655 reports. Peer overload reports are used by agents to indicate the 656 need for overload abatement handling by the agents peer. 658 A supporting node must also include the OC-SourceID AVP in the OC- 659 Supported-Features capability AVP. 661 This AVP contains the Diameter Identity of the node that supports the 662 OLR_PEER_REPORT feature. This AVP is used to determine if support 663 for the peer overload report is in an adjectent node. The value of 664 this AVP should be the same Diameter identity used as part of the 665 CER/CEA base Diameter capabilities exchange. 667 OC-Supported-Features ::= < AVP Header: TBD1 > 668 [ OC-Feature-Vector ] 669 [ OC-SourceID ] 670 [ OC-Peer-Algo] 671 * [ AVP ] 673 6.1.1. OC-Feature-Vector 675 The peer report feature defines a new feature bit is added for the 676 OC-Feature-Vector AVP. 678 OLR_PEER_REPORT (0x0000000000000010) 680 When this flag is set by a DOIC node it indicates that the DOIC 681 node supports the peer overload report type. 683 6.1.2. OC-Peer-Algo 685 The OC-Peer-Algo AVP (AVP code TBD6) is of type Unsigned64 and 686 contains a 64 bit flags field of announced capabilities of a DOIC 687 node. The value of zero (0) is reserved. 689 Feature bits defined for the OC-Feature-Vector AVP and associated 690 with overload abatement algorithms are reused in for this AVP. This 691 include the following value defined in the DOIC specification. 693 Editor's node: This is to avoid the need for an additional IANA 694 registry. 696 6.2. OC-OLR AVP 698 This extension makes no changes to the SequenceNumber or 699 ValidityDuration AVPs in the OC-OLR AVP. These AVPs are also be used 700 in peer overload reports. 702 The peer report feature extends the base Diameter overload 703 specification by defining a new overload report type of "peer". See 704 section [4.5] in [I-D.ietf-dime-ovli] for a description of the 705 overload report type AVP. 707 The overload report must also include the Diameter identity of the 708 agent that generated the report. This is necessary to handle the 709 case where there is a non supporting agent between the reporting node 710 and the reacting node. Without the indication of the agent that 711 generated the overload request, the reacting node could erroneously 712 assume that the report applied to the non supporting node. This 713 could, in turn, result in unnecessary traffic being either 714 redistributed or throttled. 716 The OC-SourceID AVP is used in the OC-OLR AVP to carry this 717 DiameterID. 719 OC-OLR ::= < AVP Header: TBD2 > 720 < OC-Sequence-Number > 721 < OC-Report-Type > 722 [ OC-Reduction-Percentage ] 723 [ OC-Validity-Duration ] 724 [ OC-Source-ID ] 725 * [ AVP ] 727 6.2.1. OC-Report-Type AVP 729 The following new report type is defined for the OC-Report-Type AVP. 731 2 Peer. The overload treatment should apply to all requests bound 732 for the peer identified in the overload report. If the peer 733 identified in the overload report is not a peer to the reacting 734 endpoint then the overload report should be stripped and not acted 735 upon. 737 This extension uses the OC-SourceID AVP for this purpose. 739 6.3. OC-SourceID 741 The SourceID AVP (AVP code TBD) is of type DiameterIdentity and is 742 inserted by the DOIC node that either indicates support for this 743 feature (in the OC-Supported-Features AVP) or that generates an OC- 744 OLR AVP with a report type of peer. 746 It contains the Diameter Identity of the inserting node. This is 747 used by other DOIC nodes to determine if the a peer indicated 748 indicated support this feature or inserted the peer report 750 6.4. Attribute Value Pair flag rules 751 +---------+ 752 |AVP flag | 753 |rules | 754 +----+----+ 755 AVP Section | |MUST| 756 Attribute Name Code Defined Value Type |MUST| NOT| 757 +--------------------------------------------------------+----+----+ 758 |OC-SourceID TBD1 x.x Unsigned64 | | V | 759 |OC-Peer-Algo TBD1 x.x Unsigned64 | | V | 760 +--------------------------------------------------------+----+----+ 762 7. IANA Considerations 764 Editors note: This section will be completed once the base overload 765 document has finished the definition of extension IANA requirements. 767 8. Security Considerations 769 Agent overload is an extension to the based Diameter overload 770 mechanism. As such, all of the security considerations outlined in 771 [I-D.ietf-dime-ovli] apply to the agent overload scenarios. 773 It is possible that the malicious insertion of an agent overload 774 report could have a bigger impact on a Diameter network as agents can 775 be concentration points in a Diameter network. Where an end-point 776 report would impact the traffic sent to a single Diameter server, for 777 example, a peer report could throttle all traffic to the Diameter 778 network. 780 This impact is amplified in an agent that sits at the edge of a 781 Diameter network that serves as the entry point from all other 782 Diameter networks. 784 9. Acknowledgements 786 Adam Roach and Eric McMurry for the work done in defining a 787 comprehensive Diameter overload solution in draft-roach-dime- 788 overload-ctrl-03.txt. 790 Ben Campbell for his insights and review of early versions of this 791 document. 793 10. Normative References 795 [I-D.ietf-dime-ovli] 796 Korhonen, J., "Diameter Overload Indication Conveyance", 797 October 2013. 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, March 1997. 802 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 803 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 804 May 2008. 806 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 807 "Diameter Base Protocol", RFC 6733, October 2012. 809 [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control 810 Requirements", RFC 7068, November 2013. 812 Author's Address 814 Steve Donovan 815 Oracle 816 7460 Warren Parkway, Suite 300 817 Frisco, Texas 75034 818 United States 820 Email: srdonovan@usdonovans.com