idnits 2.17.1 draft-ietf-dime-agent-overload-11.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. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 22, 2017) is 2592 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-dime-doic-rate-control-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions (DIME) S. Donovan 3 Internet-Draft Oracle 4 Updates: RFC7683 (if approved) March 22, 2017 5 Intended status: Standards Track 6 Expires: September 23, 2017 8 Diameter Agent Overload and the Peer Overload Report 9 draft-ietf-dime-agent-overload-11.txt 11 Abstract 13 This specification documents an extension to RFC 7683 (Diameter 14 Overload Indication Conveyance (DOIC)) base solution. The extension 15 defines the Peer overload report type. The initial use case for the 16 Peer report is the handling of occurrences of overload of a Diameter 17 agent. 19 Requirements 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 23, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 61 3. Peer Report Use Cases . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 4 63 3.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 5 64 3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 6 65 3.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 7 66 3.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 8 67 3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 8 68 4. Interaction Between Host/Realm and Peer Overload Reports . . 8 69 5. Peer Report Behavior . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Capability Announcement . . . . . . . . . . . . . . . . . 9 71 5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 9 72 5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 9 73 5.2. Peer Overload Report Handling . . . . . . . . . . . . . . 10 74 5.2.1. Overload Control State . . . . . . . . . . . . . . . 10 75 5.2.2. Reporting Node Maintenance of Peer Report OCS . . . . 11 76 5.2.3. Reacting Node Maintenance of Peer Report OCS . . . . 11 77 5.2.4. Peer-Report Reporting Node Behavior . . . . . . . . . 12 78 5.2.5. Peer-Report Reacting Node Behavior . . . . . . . . . 13 79 6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14 80 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14 81 6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 14 82 6.1.2. OC-Peer-Algo AVP . . . . . . . . . . . . . . . . . . 14 83 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15 84 6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15 85 6.3. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15 86 6.4. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 16 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 88 7.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 16 89 7.2. New Registries . . . . . . . . . . . . . . . . . . . . . 16 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 10.1. Informative References . . . . . . . . . . . . . . . . . 17 94 10.2. Normative References . . . . . . . . . . . . . . . . . . 17 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 97 1. Introduction 99 This specification documents an extension to the Diameter Overload 100 Indication Conveyance (DOIC) [RFC7683] base solution. The extension 101 defines the Peer overload report type. The initial use case for the 102 Peer report is the handling of occurrences of overload of a Diameter 103 agent. 105 This document defines the behavior of Diameter nodes when Diameter 106 agents enter an overload condition and send an overload report 107 requesting a reduction of traffic. It also defines new overload 108 report type, the Peer overload report type, that is used for handling 109 of agent overload conditions. The Peer overload report type is 110 defined in a generic fashion so that it can also be used for other 111 Diameter overload scenarios. 113 The base Diameter overload specification [RFC7683] addresses the 114 handling of overload when a Diameter endpoint (a Diameter Client or 115 Diameter Server as defined in [RFC6733]) becomes overloaded. 117 In the base specification, the goal is to handle abatement of the 118 overload occurrence as close to the source of the Diameter traffic as 119 feasible. When possible this is done at the originator of the 120 traffic, generally referred to as a Diameter Client. A Diameter 121 Agent might also handle the overload mitigation. For instance, a 122 Diameter Agent might handle Diameter overload mitigation when it 123 knows that a Diameter Client does not support the DOIC extension. 125 This document extends the base Diameter endpoint overload 126 specification to address the case when Diameter Agents become 127 overloaded. Just as is the case with other Diameter nodes -- 128 Diameter Clients and Diameter Servers -- surges in Diameter traffic 129 can cause a Diameter Agent to be asked to handle more Diameter 130 traffic than it was configured to handle. For a more detailed 131 discussion of what can cause the overload of Diameter nodes, refer to 132 the Diameter Overload Requirements [RFC7068]. 134 This document defines a new overload report type to communicate 135 occurrences of agent overload. This report type works for the "Loss" 136 overload mitigation algorithm defined in [RFC7683] and is expected to 137 work for other overload abatement algorithms defined in extensions to 138 the DOIC solution. 140 2. Terminology and Abbreviations 142 AVP 144 Attribute Value Pair 146 Diameter Node 148 A [RFC7683] Diameter Client, an [RFC7683] Diameter Server, and 149 [RFC7683] Diameter Agent. 151 Diameter Endpoint 153 An [RFC7683] Diameter Client and [RFC7683] Diameter Server. 155 Diameter Agent 157 An [RFC7683] Diameter Agent. 159 Reporting Node 161 A DOIC Node that sends an overload report in a Diameter answer 162 message. 164 Reacting Node 166 A DOIC Node that receives and acts on a DOIC overload report. 168 DOIC Node 170 A Diameter Node that supports the DOIC solution defined in 171 [RFC7683]. 173 3. Peer Report Use Cases 175 This section outlines representative use cases for the peer report 176 used to communicate agent overload. 178 There are two primary classes of use cases currently identified, 179 those involving the overload of agents and those involving overload 180 of Diameter endpoints. In both cases the goal is to use an overload 181 algorithm that controls traffic sent towards peers. 183 3.1. Diameter Agent Overload Use Cases 185 The peer report needs to support the following use cases. 187 In the figures in this section, elements labeled "c" are Diameter 188 Clients, elements labeled "a" are Diameter Agents and elements 189 labeled "s" are Diameter Servers. 191 3.1.1. Single Agent 193 This use case is illustrated in Figure 1. In this case, the client 194 sends all traffic through the single agent. If there is a failure in 195 the agent then the client is unable to send Diameter traffic toward 196 the server. 198 +-+ +-+ +-+ 199 |c|----|a|----|s| 200 +-+ +-+ +-+ 202 Figure 1 204 A more likely case for the use of agents is illustrated in Figure 2. 205 In this case, there are multiple servers behind the single agent. 206 The client sends all traffic through the agent and the agent 207 determines how to distribute the traffic to the servers based on 208 local routing and load distribution policy. 210 +-+ 211 --|s| 212 +-+ +-+ / +-+ 213 |c|----|a|- ... 214 +-+ +-+ \ +-+ 215 --|s| 216 +-+ 218 Figure 2 220 In both of these cases, the occurrence of overload in the single 221 agent must by handled by the client in a similar fashion as if the 222 client were handling the overload of a directly connected server. 223 When the agent becomes overloaded it will insert an overload report 224 in answer messages flowing to the client. This overload report will 225 contain a requested reduction in the amount of traffic sent to the 226 agent. The client will apply overload abatement behavior as defined 227 in the base Diameter overload specification [RFC7683] or the 228 extension draft that defines the indicated overload abatement 229 algorithm. This will result in the throttling of the abated traffic 230 that would have been sent to the agent, as there is no alternative 231 route. The client sends an appropriate error response to the 232 originator of the request. 234 3.1.2. Redundant Agents 236 Figure 3 and Figure 4 illustrate a second, and more likely, type of 237 deployment scenario involving agents. In both of these cases, the 238 client has Diameter connections to two agents. 240 Figure 3 illustrates a client that has a primary connection to one of 241 the agents (agent a1) and a secondary connection to the other agent 242 (agent a2). In this scenario, under normal circumstances, the client 243 will use the primary connection for all traffic. The secondary 244 connection is used when there is a failure scenario of some sort. 246 +--+ +-+ 247 --|a1|---|s| 248 +-+ / +--+\ /+-+ 249 |c|- x 250 +-+ . +--+/ \+-+ 251 ..|a2|---|s| 252 +--+ +-+ 254 Figure 3 256 The second case, in Figure 4, illustrates the case where the 257 connections to the agents are both actively used. In this case, the 258 client will have local distribution policy to determine the traffic 259 sent through each client. 261 +--+ +-+ 262 --|a1|---|s| 263 +-+ / +--+\ /+-+ 264 |c|- x 265 +-+ \ +--+/ \+-+ 266 --|a2|---|s| 267 +--+ +-+ 269 Figure 4 271 In the case where one of the agents in the above scenarios become 272 overloaded, the client should reduce the amount of traffic sent to 273 the overloaded agent by the amount requested. This traffic should 274 instead be routed through the non-overloaded agent. For example, 275 assume that the overloaded agent requests a reduction of 10 percent. 276 The client should send 10 percent of the traffic that would have been 277 routed to the overloaded agent through the non-overloaded agent. 279 When the client has an active and a standby connection to the two 280 agents then an alternative strategy for responding to an overload 281 report from an agent is to change the standby connection to active. 282 This will result in all traffic being routed through the new active 283 connection. 285 In the case where both agents are reporting overload, the client may 286 need to start decreasing the total traffic sent to the agents. This 287 would be done in a similar fashion as discussed in Section 3.1.1 The 288 amount of traffic depends on the combined reduction requested by the 289 two agents. 291 3.1.3. Agent Chains 293 There are also deployment scenarios where there can be multiple 294 Diameter Agents between Diameter Clients and Diameter Servers. An 295 example of this type of deployment includes when there are Diameter 296 agents between administrative domains. 298 Figure 5 illustrates one such network deployment case. Note that 299 while this figure shows a maximum of two agents being involved in a 300 Diameter transaction, it is possible that more than two agents could 301 be in the path of a transaction. 303 +---+ +---+ +-+ 304 --|a11|-----|a21|---|s| 305 +-+ / +---+ \ / +---+\ /+-+ 306 |c|- x x 307 +-+ \ +---+ / \ +---+/ \+-+ 308 --|a12|-----|a22|---|s| 309 +---+ +---+ +-+ 311 Figure 5 313 Handling of overload of one or both of agents a11 or a12 in this case 314 is equivalent to that discussed in Section 3.1.2. 316 Overload of agents a21 and a22 must be handled by the previous hop 317 agents. As such, agents a11 and a12 must handle the overload 318 mitigation logic when receiving an agent overload report from agents 319 a21 and a22. 321 The handling of peer overload reports is similar to that discussed in 322 Section 3.1.2. If the overload can be addressed using diversion then 323 this approach should be taken. 325 If both of the agents have requested a reduction in traffic then the 326 previous hop agent must start throttling the appropriate number of 327 transactions. When throttling requests, an agent uses the same error 328 responses as defined in the base DOIC specification [RFC7683]. 330 3.2. Diameter Endpoint Use Cases 332 This section outlines use cases for the peer overload report 333 involving Diameter Clients and Diameter Servers. 335 3.2.1. Hop-by-hop Abatement Algorithms 337 It is envisioned that abatement algorithms will be defined that will 338 support the option for Diameter Endpoints to send peer reports. For 339 instance, it is envisioned that one usage scenario for the rate 340 algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked 341 on by the DIME working group as this document is being written, will 342 involve abatement being done on a hop-by-hop basis. 344 This rate deployment scenario would involve Diameter Endpoints 345 generating peer reports and selecting the rate algorithm for 346 abatement of overload conditions. 348 4. Interaction Between Host/Realm and Peer Overload Reports 350 It is possible that both an agent and an end-point in the path of a 351 transaction are overloaded at the same time. When this occurs, 352 Diameter entities need to handle both overload reports. In this 353 scenario the reacting node should first handle the throttling of the 354 overloaded host or realm. Any messages that survive throttling due 355 to host or realm reports should then go through abatement for the 356 peer overload report. In this scenario, when doing abatement on the 357 PEER report, the reacting node SHOULD take into consideration the 358 number of messages already throttled by the handling of the HOST/ 359 REALM report abatement. 361 Note: The goal is to avoid traffic oscillations that might result 362 from throttling of messages for both the HOST/REALM overload 363 reports and the PEER overload reports. This is especially a 364 concern if both reports indicate the LOSS abatement algorithm. 366 5. Peer Report Behavior 368 This section defines the normative behavior associated with the Peer 369 Report extension to the DOIC solution. 371 5.1. Capability Announcement 373 5.1.1. Reacting Node Behavior 375 When sending a Diameter request a DOIC Node that supports the 376 OC_PEER_REPORT (as defined in Section 6.1.1) feature MUST include in 377 the OC-Supported-Features AVP an OC-Feature-Vector AVP with the 378 OC_PEER_REPORT bit set. 380 When sending a request a DOIC Node that supports the OC_PEER_REPORT 381 feature MUST include a SourceID AVP in the OC-Supported-Features AVP 382 with its own DiameterIdentity. 384 When a Diameter Agent relays a request that includes a SourceID AVP 385 in the OC-Supported-Features AVP, if the Diameter Agent supports the 386 OC_PEER_REPORT feature then it MUST remove the received SourceID AVP 387 and replace it with a SourceID AVP containing its own 388 DiameterIdentity. 390 5.1.2. Reporting Node Behavior 392 When receiving a request a DOIC Node that supports the OC_PEER_REPORT 393 feature MUST update transaction state with an indication of whether 394 or not the peer from which the request was received supports the 395 OC_PEER_REPORT feature. 397 Note: The transaction state is used when the DOIC Node is acting 398 as a peer-report reporting node and needs send OC-OLR reports of 399 type peer in answer messages. The peer overload reports are only 400 included in answer messages being sent to peers that support the 401 OC_PEER_REPORT feature. 403 The peer supports the OC_PEER_REPORT feature if the received request 404 contains an OC-Supported-Features AVP with the OC-Feature-Vector with 405 the OC_PEER_REPORT feature bit set and with a SourceID AVP with a 406 value that matches the DiameterIdentity of the peer from which the 407 request was received. 409 When an agent relays an answer message, a reporting node that 410 supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from 411 the OC-Supported-Features AVP. 413 When sending an answer message, a reporting node that supports the 414 OC_PEER_REPORT feature MUST determine if the peer to which the answer 415 is to be sent supports the OC_PEER_REPORT feature. 417 If the peer supports the OC_PEER_REPORT feature then the reporting 418 node MUST indicate support for the feature in the OC-Supported- 419 Features AVP. 421 If the peer supports the OC_PEER_REPORT feature then the reporting 422 node MUST insert the SourceID AVP in the OC-Supported-Features AVP in 423 the answer message. 425 If the peer supports the OC_PEER_REPORT feature then the reporting 426 node MUST insert the OC-Peer-Algo AVP in the OC-Supported-Features 427 AVP. The OC-Peer-Algo AVP MUST indicate the overload abatement 428 algorithm that the reporting node wants the reacting nodes to use 429 should the reporting node send a peer overload report as a result of 430 becoming overloaded. 432 5.2. Peer Overload Report Handling 434 This section defines the behavior for the handling of overload 435 reports of type peer. 437 5.2.1. Overload Control State 439 This section describes the Overload Control State (OCS) that might be 440 maintained by both the peer-report reporting node and the peer-report 441 reacting node. 443 This is an extension of the OCS handling defined in [RFC7683]. 445 5.2.1.1. Reporting Node Peer Report OCS 447 A DOIC Node that supports the OC_PEER_REPORT feature SHOULD maintain 448 Reporting Node OCS, as defined in [RFC7683] and extended here. 450 If different abatement specific contents are sent to each peer then 451 the reporting node MUST maintain a separate reporting node peer 452 report OCS entry per peer to which a peer overload report is sent. 454 Note: The rate overload abatement algorithm allows for different 455 rates to be sent to each peer. 457 5.2.1.2. Reacting Node Peer Report OCS 459 In addition to OCS maintained as defined in [RFC7683], a reacting 460 node that supports the OC_PEER_REPORT feature maintains the following 461 OCS per supported Diameter application: 463 A peer-type OCS entry for each peer to which it sends requests. 465 A peer-type OCS entry is identified by the pair of Application-ID and 466 the peer's DiameterIdentity. 468 The peer-type OCS entry include the following information (the actual 469 information stored is an implementation decision): 471 Sequence number (as received in the OC-OLR AVP). 473 Time of expiry (derived from OC-Validity-Duration AVP received in 474 the OC-OLR AVP and time of reception of the message carrying OC- 475 OLR AVP). 477 Selected abatement algorithm (as received in the OC-Supported- 478 Features AVP). 480 Input data that is abatement algorithm specific (as received in 481 the OC-OLR AVP -- for example, OC-Reduction-Percentage for the 482 loss abatement algorithm). 484 5.2.2. Reporting Node Maintenance of Peer Report OCS 486 All rules for managing the reporting node OCS entries defined in 487 [RFC7683] apply to the peer report. 489 5.2.3. Reacting Node Maintenance of Peer Report OCS 491 When a reacting node receives an OC-OLR AVP with a report type of 492 peer it MUST determine if the report was generated by the Diameter 493 peer from which the report was received. 495 If a reacting node receives an OC-OLR AVP of type peer and the 496 SourceID matches the DiameterIdentity of the Diameter peer from which 497 the response message was received then the report was generated by a 498 Diameter peer. 500 If a reacting node receives an OC-OLR AVP of type peer and the 501 SourceID does not match the DiameterIdentity of the Diameter peer 502 from which the response message was received then the reacting node 503 MUST ignore the overload report. 505 Note: Under normal circumstances, a Diameter node will not add a 506 peer report when sending to a peer that does not support this 507 extension. This requirement is to handle the case where peer 508 reports are erroneously or maliciously inserted into response 509 messages. 511 If the peer report was received from a Diameter peer then the 512 reacting node MUST determine if it is for an existing or new overload 513 condition. 515 The peer report is for an existing overload condition if the reacting 516 node has an OCS that matches the received peer report. For a peer 517 report, this means it matches the Application-ID and the peer's 518 DiameterIdentity in an existing OCS entry. 520 If the peer report is for an existing overload condition then it MUST 521 determine if the peer report is a retransmission or an update to the 522 existing OLR. 524 If the sequence number for the received peer report is greater than 525 the sequence number stored in the matching OCS entry then the 526 reacting node MUST update the matching OCS entry. 528 If the sequence number for the received peer report is less than or 529 equal to the sequence number in the matching OCS entry then the 530 reacting node MUST silently ignore the received peer report. The 531 matching OCS MUST NOT be updated in this case. 533 If the received peer report is for a new overload condition then the 534 reacting node MUST generate a new OCS entry for the overload 535 condition. 537 For a peer report this means it creates an OCS entry with a 538 DiameterIdentity from the SourceID AVP in the received OC-OLR AVP. 540 If the received peer report contains a validity duration of zero 541 ("0") then the reacting node MUST update the OCS entry as being 542 expired. 544 The reacting node does not delete an OCS when receiving an answer 545 message that does not contain an OC-OLR AVP (i.e. absence of OLR 546 means "no change"). 548 The reacting node sets the abatement algorithm based on the OC-Peer- 549 Algo AVP in the received OC-Supported-Features AVP. 551 5.2.4. Peer-Report Reporting Node Behavior 553 When there is an existing reporting node peer report OCS entry, the 554 reporting node MUST include an OC-OLR AVP with a report type of peer 555 using the contents of the reporting node peer report OCS entry in all 556 answer messages sent by the reporting node to peers that support the 557 OC_PEER_REPORT feature. 559 The reporting node determines if a peer supports the 560 OC_PEER_REPORT feature based on the indication recorded in the 561 reporting node's transaction state. 563 The reporting node MUST include its DiameterIdentity in the SourceID 564 AVP in the OC-OLR AVP. This is used by DOIC Nodes that support the 565 OC_PEER_REPORT feature to determine if the report was received from a 566 Diameter peer. 568 The reporting agent must follow all other overload reporting node 569 behaviors outlined in the DOIC specification. 571 5.2.5. Peer-Report Reacting Node Behavior 573 A reacting node supporting this extension MUST support the receipt of 574 multiple overload reports in a single message. The message might 575 include a host overload report, a realm overload report and/or a peer 576 overload report. 578 When a reacting node sends a request it MUST determine if that 579 request matches an active OCS. 581 In all cases, if the reacting node is an agent then it MUST strip the 582 Peer Report OC-OLR AVP from the message. 584 If the request matches an active OCS then the reacting node MUST 585 apply abatement treatment to the request. The abatement treatment 586 applied depends on the abatement algorithm indicated in the OCS. 588 For peer overload reports, the preferred abatement treatment is 589 diversion. As such, the reacting node SHOULD attempt to divert 590 requests identified as needing abatement to other peers. 592 If there is not sufficient capacity to divert abated traffic then the 593 reacting node MUST throttle the necessary requests to fit within the 594 available capacity of the peers able to handle the requests. 596 If the abatement treatment results in throttling of the request and 597 if the reacting node is an agent then the agent MUST send an 598 appropriate error response as defined in [RFC7683]. 600 In the case that the OCS entry validity duration expires or has a 601 validity duration of zero ("0"), meaning that if the reporting node 602 has explicitly signaled the end of the overload condition then 603 abatement associated with the OCS entry MUST be ended in a controlled 604 fashion. 606 6. Peer Report AVPs 608 6.1. OC-Supported-Features AVP 610 This extension adds a new feature to the OC-Feature-Vector AVP. This 611 feature indication shows support for handling of peer overload 612 reports. Peer overload reports are used by agents to indicate the 613 need for overload abatement handling by the agent's peer. 615 A supporting node must also include the SourceID AVP in the OC- 616 Supported-Features capability AVP. 618 This AVP contains the DiameterIdentity of the node that supports the 619 OC_PEER_REPORT feature. This AVP is used to determine if support for 620 the peer overload report is in an adjacent node. The value of this 621 AVP should be the same Diameter identity used as part of the Diameter 622 Capabilities Exchange procedure defined in [RFC7683]. 624 This extension also adds the OC-Peer-Algo AVP to the OC-Supported- 625 Features AVP. This AVP is used by a reporting node to indicate the 626 abatement algorithm it will use for peer overload reports. 628 OC-Supported-Features ::= < AVP Header: 621 > 629 [ OC-Feature-Vector ] 630 [ SourceID ] 631 [ OC-Peer-Algo] 632 * [ AVP ] 634 6.1.1. OC-Feature-Vector AVP 636 The peer report feature defines a new feature bit for the OC-Feature- 637 Vector AVP. 639 OC_PEER_REPORT (0x0000000000000010) 641 When this flag is set by a DOIC Node it indicates that the DOIC 642 Node supports the peer overload report type. 644 6.1.2. OC-Peer-Algo AVP 646 The OC-Peer-Algo AVP (AVP code TBD1) is of type Unsigned64 and 647 contains a 64 bit flags field of announced capabilities of a DOIC 648 Node. The value of zero (0) is reserved. 650 Feature bits defined for the OC-Feature-Vector AVP and associated 651 with overload abatement algorithms are reused for this AVP. 653 6.2. OC-OLR AVP 655 This extension makes no changes to the OC_Sequence_Number or 656 OC_Validity_Duration AVPs in the OC-OLR AVP. These AVPs are also be 657 used in peer overload reports. 659 The OC_PEER_REPORT feature extends the base Diameter overload 660 specification by defining a new overload report type of "peer". See 661 section [7.6] in [RFC7683] for a description of the OC-Report-Type 662 AVP. 664 The overload report MUST also include the Diameter identity of the 665 agent that generated the report. This is necessary to handle the 666 case where there is a non supporting agent between the reporting node 667 and the reacting node. Without the indication of the agent that 668 generated the overload report, the reacting node could erroneously 669 assume that the report applied to the non-supporting node. This 670 could, in turn, result in unnecessary traffic being either diverted 671 or throttled. 673 The SourceID AVP is used in the OC-OLR AVP to carry this 674 DiameterIdentity. 676 OC-OLR ::= < AVP Header: 623 > 677 < OC-Sequence-Number > 678 < OC-Report-Type > 679 [ OC-Reduction-Percentage ] 680 [ OC-Validity-Duration ] 681 [ SourceID ] 682 * [ AVP ] 684 6.2.1. OC-Report-Type AVP 686 The following new report type is defined for the OC-Report-Type AVP. 688 PEER_REPORT 2 The overload treatment should apply to all requests 689 bound for the peer identified in the overload report. If the peer 690 identified in the overload report is not a peer to the reacting 691 endpoint then the overload report should be stripped and not acted 692 upon. 694 6.3. SourceID AVP 696 The SourceID AVP (AVP code TBD2) is of type DiameterIdentity and is 697 inserted by a Diameter node to indicate the source of the AVP in 698 which it is a part. 700 In the case of peer reports, the SourceID AVP indicates the node that 701 supports this feature (in the OC-Supported-Features AVP) or the node 702 that generates an overload with a report type of peer (in the OC-OLR 703 AVP). 705 It contains the DiameterIdentity of the inserting node. This is used 706 by other Diameter nodes to determine the node that inserted the 707 enclosing AVP that contains the SourceID AVP. 709 6.4. Attribute Value Pair Flag Rules 711 +---------+ 712 |AVP flag | 713 |rules | 714 +----+----+ 715 AVP Section | |MUST| 716 Attribute Name Code Defined Value Type |MUST| NOT| 717 +--------------------------------------------------------+----+----+ 718 |OC-Peer-Algo TBD1 6.1.2 Unsigned64 | | V | 719 |SourceID TBD2 6.3 DiameterIdentity | | V | 720 +--------------------------------------------------------+----+----+ 722 7. IANA Considerations 724 7.1. AVP Codes 726 New AVPs defined by this specification are listed in Section 6.4. 727 All AVP codes are allocated from the 'Authentication, Authorization, 728 and Accounting (AAA) Parameters' AVP Codes registry. 730 One new OC-Report-Type AVP value is defined in Section 6.2.1 732 7.2. New Registries 734 There are no new IANA registries introduced by this document. 736 The values used for the OC-Peer-Algo AVP are the subset of the "OC- 737 Feature-Vector AVP Values (code 622)" registry. Only the values in 738 that registry that apply to overload abatement algorithms apply to 739 the OC-Peer-Algo AVP. 741 8. Security Considerations 743 Agent overload is an extension to the base Diameter overload 744 mechanism. As such, all of the security considerations outlined in 745 [RFC7683] apply to the agent overload scenarios. 747 It is possible that the malicious insertion of an agent overload 748 report could have a bigger impact on a Diameter network as agents can 749 be concentration points in a Diameter network. Where an end-point 750 report would impact the traffic sent to a single Diameter server, for 751 example, a peer report could throttle all traffic to the Diameter 752 network. 754 This impact is amplified in an agent that sits at the edge of a 755 Diameter network that serves as the entry point from all other 756 Diameter networks. 758 The impacts of this attack, as well as the mitigation strategies, are 759 the same as outlined in [RFC7683]. 761 9. Acknowledgements 763 Adam Roach and Eric McMurry for the work done in defining a 764 comprehensive Diameter overload solution in draft-roach-dime- 765 overload-ctrl-03.txt. 767 Ben Campbell for his insights and review of early versions of this 768 document. 770 10. References 772 10.1. Informative References 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, 776 DOI 10.17487/RFC2119, March 1997, 777 . 779 [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control 780 Requirements", RFC 7068, DOI 10.17487/RFC7068, November 781 2013, . 783 10.2. Normative References 785 [I-D.ietf-dime-doic-rate-control] 786 Donovan, S. and E. Noel, "Diameter Overload Rate Control", 787 draft-ietf-dime-doic-rate-control-03 (work in progress), 788 March 2016. 790 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 791 Ed., "Diameter Base Protocol", RFC 6733, 792 DOI 10.17487/RFC6733, October 2012, 793 . 795 [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. 796 Morand, "Diameter Overload Indication Conveyance", 797 RFC 7683, DOI 10.17487/RFC7683, October 2015, 798 . 800 Author's Address 802 Steve Donovan 803 Oracle 804 7460 Warren Parkway, Suite 300 805 Frisco, Texas 75034 806 United States 808 Email: srdonovan@usdonovans.com