--- 1/draft-ietf-dime-agent-overload-02.txt 2015-10-14 09:15:03.690830314 -0700 +++ 2/draft-ietf-dime-agent-overload-03.txt 2015-10-14 09:15:03.726831185 -0700 @@ -1,25 +1,26 @@ Diameter Maintenance and Extensions (DIME) S. Donovan Internet-Draft Oracle -Intended status: Standards Track August 31, 2015 -Expires: March 3, 2016 +Intended status: Standards Track October 14, 2015 +Expires: April 16, 2016 - Diameter Agent Overload - draft-ietf-dime-agent-overload-02.txt + Diameter Agent Overload and the Peer Overload Report + draft-ietf-dime-agent-overload-03.txt Abstract This specification documents an extension to the Diameter Overload - Indication Conveyance (DOIC) base solution. The extension addresses - the handling of occurrences of overload of a Diameter agent, or more - generally, a Diameter peer. + Indication Conveyance (DOIC) base solution. The extension defines + the Peer overload report type. The initial use case for the Peer + report is the handling of occurrences of overload of a Diameter + agent. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -28,78 +29,82 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 3, 2016. + This Internet-Draft will expire on April 16, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 + 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 3. Peer Report Use Cases . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 5 - 3.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 5 - 3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 6 - 3.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 7 - 3.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 8 - 3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 8 + 3.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 4 + 3.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 4 + 3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 5 + 3.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 6 + 3.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 7 + 3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 7 4. Interaction Between Host/Realm and Peer Overload Reports . . 8 5. Peer Report Behavior . . . . . . . . . . . . . . . . . . . . 8 5.1. Capability Announcement . . . . . . . . . . . . . . . . . 8 - 5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 9 + 5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 8 5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 9 - 5.2. Peer Report Overload Report Handling . . . . . . . . . . 11 - 5.2.1. Overload Control State . . . . . . . . . . . . . . . 11 - 5.2.2. Reporting Node Maintenance of Peer Report OCS . . . . 12 - 5.2.3. Reacting Node Maintenance of Peer Report OCS . . . . 12 - 5.2.4. Peer Report Reporting Node Behavior . . . . . . . . . 14 - 5.2.5. Peer Report Reacting Node Behavior . . . . . . . . . 14 - 6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 15 - 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 15 - 6.1.1. OC-Feature-Vector . . . . . . . . . . . . . . . . . . 15 - 6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 16 - 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 17 - 6.3. OC-SourceID . . . . . . . . . . . . . . . . . . . . . . . 17 - 6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 17 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 - 10. Normative References . . . . . . . . . . . . . . . . . . . . 18 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.2. Peer Report Overload Report Handling . . . . . . . . . . 10 + 5.2.1. Overload Control State . . . . . . . . . . . . . . . 10 + 5.2.2. Reporting Node Maintenance of Peer Report OCS . . . . 11 + 5.2.3. Reacting Node Maintenance of Peer Report OCS . . . . 11 + 5.2.4. Peer Report Reporting Node Behavior . . . . . . . . . 13 + 5.2.5. Peer Report Reacting Node Behavior . . . . . . . . . 13 + 6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14 + 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14 + 6.1.1. OC-Feature-Vector . . . . . . . . . . . . . . . . . . 14 + 6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 15 + 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15 + 6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 16 + 6.3. OC-SourceID . . . . . . . . . . . . . . . . . . . . . . . 16 + 6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 16 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 + 10. Normative References . . . . . . . . . . . . . . . . . . . . 17 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction This document defines the behavior of Diameter nodes when Diameter agents enter an overload condition and send an overload report - requesting a reduction of traffic. + requesting a reduction of traffic. It also defines new overload + report type, the Peer overload report type, that is used for handling + of agent overload conditions. The Peer overload report type is + defined in a generic fashion so that it can also be used for other + Diameter overload scenaios. The base Diameter overload specification [I-D.ietf-dime-ovli] addresses the handling of overload when a Diameter endpoint (a Diameter Client or Diameter Server as defined in [RFC6733]) becomes overloaded. In the base specification, the goal is to handle abatement of the overload occurrence as close to the source of the Diameter traffic as is feasible. When possible this is done at the originator of the traffic, generally referred to as a Diameter Client. A Diameter @@ -115,49 +120,20 @@ traffic than it was configured to handle. For a more detailed discussion of what can cause the overload of Diameter nodes, refer to the Diameter Overload Requirements [RFC7068]. This document defines a new overload report type to communicate occurrences of agent overload. This report type works for the "Loss" overload mitigation algorithm defined in [I-D.ietf-dime-ovli] and is expected to work for other overload abatement algorithms defined in extensions to the DOIC solution. - The handling of endpoint overload and agent overload is very similar. - The primary differences are the following: - - o Endpoint overload is handled as close to the originator of the - traffic as possible. - - o Agent overload is handled by the previous hop Diameter Node. - - o Endpoint overload mitigation deals with traffic targeted for a - single Diameter application. As such, it is assumed that an - overload report impacts just the application implied by the - message carrying the overload report. - - o Agent overload deals with all traffic targeted for an agent, - independent of the application. As such, a single agent overload - report can impact multiple applications. - - Editor's Note: Open Issue - Does a peer report apply to the - implicitly communicated application-id in the same way as host and - realm reports do or does it apply to all applications handled by the - peer? Do we need the ability for to support both cases? - - Open Issue - To support the ability of an agent to select a different - abatement algorithm than endpoints, we probably need to extend the - OC-Supported-Features AVP to include an OC-Abatement-Algorithm AVP. - This is currently shown to be in the OC-OLR AVP but needs to be moved - as this information is needed prior to receiving the OC-OLR. It - probably needs to be changed to OC-Peer-Abatement-Algorithm. - 2. Terminology and Abbreviations Editors note - These definitions need to be made consistent with the base Diameter overload specification defined in [I-D.ietf-dime-ovli]. Diameter Node A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733 Diameter Agent. @@ -177,27 +152,29 @@ DIOC Node A Diameter Node that supports the DOIC solution defined in [I-D.ietf-dime-ovli]. 3. Peer Report Use Cases This section outlines representative use cases for the peer report used to communicate agent overload. - There are two primary classes of use cases, those involving the - overload of agents and those involving overload of Diameter endpoints - (Diameter Clients and Diameter Servers). + There are two primary classes of use cases currently identified, + those involving the overload of agents and those involving overload + of Diameter endpoints (Diameter Clients and Diameter Servers) that + wish to use an overload algorithm suited controlling traffic sent + from a peer. 3.1. Diameter Agent Overload Use Cases - The agent overload extension must support the following use cases. + The peer report needs to support the following use cases. 3.1.1. Single Agent This use case is illustrated in Figure 1. In this case, the client sends all traffic through the single agent. If there is a failure in the agent then the client is unable to send Diameter traffic toward the server. +-+ +-+ +-+ |c|----|a|----|s| @@ -316,57 +293,53 @@ Figure 5 Handling of overload of one or both of agents a11 or a12 in this case is equivalent to that discussed in section 2.2. Overload of agents a21 and a22 must be handled by the previous hop agents. As such, agents a11 and a12 must handle the overload mitigation logic when receiving an agent overload report from agents a21 and a22. - Editor's note: Probably need to elaborate the reasoning behind the - need for the agent overload report being handled by the previous hop - agent. - The handling of peer overload reports is similar to that discussed in section 2.2. If the overload can be addressed using diversion then this approach should be taken. If both of the agents have requested a reduction in traffic then the previous hop agent must start throttling the appropriate number of transactions. When throttling requests, an agent uses the same error responses as defined in the base DOIC specification [I-D.ietf-dime-ovli]. 3.2. Diameter Endpoint Use Cases - This section outlines use cases for the peer report feature involving - Diameter Clients and Diameter Servers. + This section outlines use cases for the peer overload report + involving Diameter Clients and Diameter Servers. 3.2.1. Hop-by-hop Abatement Algorithms It is envisioned that abatement algorithms will be defined that will support the option for Diameter Endpoints to send peer reports. For instance, it is envisioned that one usage scenario for the rate algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked on by the DIME working group as this is written, will involve abatement being done on a hop-by-hop basis. This rate deployment scenario would involve Diameter Endpoints generating peer reports and selecting the rate algorithm for abatement of overload conditions. 4. Interaction Between Host/Realm and Peer Overload Reports - It is possible that both an agent and a server in the path of a + It is possible that both an agent and an end-point in the path of a transaction are overloaded at the same time. When this occurs, - Diameter entities will need to handle both overload reports. In this + Diameter entities need to handle both overload reports. In this scenario the reacting node should first handle the throttling of the overloaded host or realm. Any messages that survive throttling due to host or realm reports should then go through abatement for the peer overload report. 5. Peer Report Behavior This section defines the normative behavior associated with the Peer Report extension to the DOIC solution. @@ -387,38 +360,42 @@ Server that originates the Diamter request or a Diameter Agent that relays the request. Support for the peer report feature does not impact the logic for setting of other feature bits in the OC-Feature-Vector AVP. When sending a request a DOIC node that supports the Peer Report feature MUST include an OC-SourceID AVP in the OC-Supported-Features AVP with its own DiameterID. - Note: This allows the next DOIC node in the path of the request to + Note: This allows the DOIC nodes in the path of the request to determine if the indication of support came from a Diameter peer or if the request traversed a node that does not support the peer feature. + When relaying a request that includes an OC-SourceID AVP in the OC- + Supported-Features AVP, a DOIC node that supuports the Peer Report + feature must remove the received OC-SourceID AVP and replace it with + an OC-SourceID AVP containing its own Diameter identity. + 5.1.2. Reporting Node Behavior When receiving a request a DOIC node that supports the Peer Report feature MUST update transaction state with an indication of whether or not the peer from which the request was received supports the Peer Report feature. - Note" The transaction state is used when the DOIC node is acting - as a peer-report reporting node and needs to insert OC-Supported- - Feature AVP indicating support for the OLR_PEER_REPORT feature and - OC-OLR reports of type PEER_REPORT into answer messages. These - AVP OLR are only included in answer messages being sent to peers - that support the OLR_PEER_REPORT feature. + Note: The transaction state is used when the DOIC node is acting + as a peer-report reporting node and needs send OC-OLR reports of + type PEER_REPORT in answer messages. The peer overload reports + are only included in answer messages being sent to peers that + support the OLR_PEER_REPORT feature. The following are indications that the peer does not support the OLR_PEER_REPORT feature: The request does not contain an OC-Supported-Features AVP. The received request contains an OC-Supported-Features AVP with no OC-Feature-Vector. The received request contains an OC-Supported-Features AVP with a @@ -428,51 +405,41 @@ OC-Feature-Vector with the OLR_PEER_REPORT feature bit set but with an OC-SourceID AVP with a DiameterID that does not match the DiameterID of the peer from which the request was received. The peer supports the OLR_PEER_REPORT feature if the received request contains an OC-Supported-Features AVP with the OC-Feature-Vector with the OLR_PEER_REPORT feature bit set and with an OC-SourceID AVP with a Diameter ID that matches the DiameterID of the peer from which the request was received. - When receiving a request a DOIC node that supports the Peer Report - feature MUST remove any received OC-SourceID AVP from the OC- - Supported-Features AVP. This is done to prevent the OC-SourceID AVP - from being included in a relayed message through a node that supports - the Peer Report feature. - - Note: If the DOIC node relays the message then it will insert an - OC-SourceID AVP with its own DiameterID in the OC-Supported- - Features AVP in the relayed message. - - When sending an answer message, a reporting node that supports the + When relaying an answer message, a reporting node that supports the OLR_PEER_REPORT feature MUST strip any SourceID AVP from the OC- Supported-Features AVP. When sending an answer message, a reporting node that supports the OLR_PEER_REPORT feature MUST determine if the peer to which the answer is to be sent supports the OLR_PEER_REPORT feature. If the peer supports the OLR_PEER_REPORT feature then the reporting node MUST indicate support for the feature in the Supported-Features AVP. If the peer supports the OLR_PEER_REPORT feature then the reporting node MUST insert the OC-SourceID AVP in the OC-Supported-Features AVP in the answer message. If the peer supports the OLR_PEER_REPORT feature then the reporting node MUST insert the OC-Peer-Algo AVP in the OC-Supported-Features AVP. The OC-Peer-Algo AVP MUST indicate the overload abatement - algorithm that the reporting node wants reacting nodes to use should - the reporting node send a peer overload report as a result of + algorithm that the reporting node wants the reacting nodes to use + should the reporting node send a peer overload report as a result of becoming overloaded. 5.2. Peer Report Overload Report Handling This section defines the behavior for the handling of overload reports of type peer. 5.2.1. Overload Control State This section describes the Overload Control State (OCS) that might be @@ -482,22 +449,22 @@ 5.2.1.1. Reporting Node Peer Report OCS A DOIC Node that supports the Peer Report feature SHOULD maintain Reporting Node Peer Report OCS. This is used to record overload events and build overload reports at the reporting node. If different abatement specific contents are sent to each peer then the reporting node MUST maintain a separate peer node peer report OCS entry per peer to which a peer overload report is sent. - The rate overload abatement algorithm allows for different rates - to be sent to each peer. + Note: The rate overload abatement algorithm allows for different + rates to be sent to each peer. The Reporting Node Peer Report OCS entry MAY include the following information (the actual information stored is an implementation decision): o Sequence number o Validity Duration o Expiration Time @@ -509,21 +475,21 @@ 5.2.1.2. Reacting Node Peer Report OCS A DOIC node that supports the Peer Report feature SHOULD maintain Reacting Node Peer Report OCS for each peer with which it communicates. This is used to record overload reports received from peer nodes. A Reacting Node Peer Report OCS entry is identified by the DiameterID of the peer as communicated during the RFC6733 defined Capability - Exchange procedure + Exchange procedure. The Reacting Node Peer Report OCS entry MAY include the following information (the actual information stored is an implementation decision): o Sequence number o Expiration Time o Abatement Algorithm @@ -535,69 +501,65 @@ A reporting node SHOULD create a new Reporting Node Peer Report OCS entry Section 5.2.1.1 in an overload condition and sending a peer overload report to a peer for the first time. If the reporting node knows that there are no reacting nodes supporting the Peer Report feature then the reporting node can choose to not create OCS entries. All rules for managing the reporting node OCS entries defined in - [DOIC] apply to the peer report. + [I-D.ietf-dime-ovli] apply to the peer report. 5.2.3. Reacting Node Maintenance of Peer Report OCS - When a reacting node receives an OC-OLR AVP with an a report type of + When a reacting node receives an OC-OLR AVP with a report type of peer it MUST determine if the report was generated by the Diameter peer from which the report was received. If the DiameterID in the SourceID contained in the OLR matches the DiameterID of the peer from which the request was received then the report was received from a Diameter peer. If a reacting node receives an OC-OLR AVP of type peer and the OC- SourceID does not match the ID of the Diameter peer from which the - request was received then the reacting node MUST strip the OC-OLR AVP - from the message and not use it to update reacting node peer report - OCS entries. + request was received then the reacting node MUST ignore the overload + report. + + In all cases, if the reacting node is a relay then it MUST strip the + OC-OLR AVP from the message. If the Peer Report OLR was received from a Diameter peer then the reacting node MUST determine if it is for an existing or new overload condition. The OLR is for an existing overload condition if the reacting node - has an OCS that matches the received OLR. - - For a peer report-type this means the DiameterID received in the - SourceID AVP matches the DiameterID of an existing peer report OLR. + has an OCS that matches the received OLR. For a peer report-type + this means the DiameterID received in the SourceID AVP matches the + DiameterID of an existing peer report OLR. If the OLR is for an existing overload condition then it MUST determine if the OLR is a retransmission or an update to the existing OLR. If the sequence number for the received OLR is greater than the sequence number stored in the matching OCS entry then the reacting node MUST update the matching OCS entry. If the sequence number for the received OLR is less than or equal to the sequence number in the matching OCS entry then the reacting node MUST silently ignore the received OLR. The matching OCS MUST NOT be updated in this case. If the received OLR is for a new overload condition then the reacting node MUST generate a new OCS entry for the overload condition. - Editor's note: The above four paragraphs are copied form the DOIC - specification. Is it possible to include this behavior by - reference or do we need to include all of these statements in this - specification as well. - For a peer report this means it creates an OCS entry with an DiameterID from the SourceID AVP in the received OC-OLR AVP. If the received OLR contains a validity duration of zero ("0") then the reacting node MUST update the OCS entry as being expired. The reacting node does not delete an OCS when receiving an answer message that does not contain an OC-OLR AVP (i.e. absence of OLR means "no change"). @@ -621,46 +583,34 @@ report feature to determine if the report was received from a Diameter peer. The reporting agent must follow all other overload reporting node behaviors outlined in the DOIC specification. 5.2.5. Peer Report Reacting Node Behavior A reacting node supporting this extension MUST support the receipt of multiple overload reports in a single message. The message might - include a host overload report, a realm overload report and a peer + include a host overload report, a realm overload report and/or a peer overload report. When a reacting node sends a request it MUST determine if that request matches an active OCS. If the request matches and active OCS then the reacting node MUST apply abatement treatment on the request. The abatement treatment - applied depends on the abatement algorithm stored in the OCS. + applied depends on the abatement algorithm indicated in the OCS. For peer overload reports, the preferred abatement treatment is diversion. As such, the reacting node SHOULD attempt to divert requests identified as needing abatement to other peers. - If a host-routed request, as defined in [I-D.ietf-dime-ovli], is - selected for abatement and the request must be routed to the DOIC - node that generated the peer overload report -- meaning that the - request is a host-routed request as defined in the DOIC specification - -- then the reacting node MUST throttle the request. - - This would result from an overloaded Diameter endpoint (Diameter - Server or Diameter Client) sending a peer overload report and the - request contains a Destination-Host AVP with a DiameterID that - matches the DiameterID in the SourceID AVP received in the peer - overload report. - If there is not sufficient capacity to divert abated traffic then the reacting node MUST throttle the necessary requests to fit within the available capacity of the peers able to handle the requests. If the abatement treatment results in throttling of the request and if the reacting node is an agent then the agent MUST send an appropriate error as defined in [I-D.ietf-dime-ovli]. In the case that the OCS entry validity duration expires or has a validity duration of zero ("0"), meaning that it the reporting node @@ -679,20 +629,24 @@ A supporting node must also include the OC-SourceID AVP in the OC- Supported-Features capability AVP. This AVP contains the Diameter Identity of the node that supports the OLR_PEER_REPORT feature. This AVP is used to determine if support for the peer overload report is in an adjacent node. The value of this AVP should be the same Diameter identity used as part of the CER/CEA base Diameter capabilities exchange. + This extension also adds the OC-Peer-Algo AVP to the OC-Supported- + Features AVP. This AVP is used by a reporting node to indicate the + abatement algorithm it will use for peer overload reports. + OC-Supported-Features ::= < AVP Header: TBD1 > [ OC-Feature-Vector ] [ OC-SourceID ] [ OC-Peer-Algo] * [ AVP ] 6.1.1. OC-Feature-Vector The peer report feature defines a new feature bit is added for the OC-Feature-Vector AVP. @@ -691,26 +645,27 @@ [ OC-SourceID ] [ OC-Peer-Algo] * [ AVP ] 6.1.1. OC-Feature-Vector The peer report feature defines a new feature bit is added for the OC-Feature-Vector AVP. OLR_PEER_REPORT (0x0000000000000010) + When this flag is set by a DOIC node it indicates that the DOIC node supports the peer overload report type. 6.1.2. OC-Peer-Algo - The OC-Peer-Algo AVP (AVP code TBD6) is of type Unsigned64 and + The OC-Peer-Algo AVP (AVP code TBD1) is of type Unsigned64 and contains a 64 bit flags field of announced capabilities of a DOIC node. The value of zero (0) is reserved. Feature bits defined for the OC-Feature-Vector AVP and associated with overload abatement algorithms are reused in for this AVP. Editor's node: This is to avoid the need for an additional IANA registry. 6.2. OC-OLR AVP @@ -749,50 +704,50 @@ The following new report type is defined for the OC-Report-Type AVP. PEER_REPORT 2 The overload treatment should apply to all requests bound for the peer identified in the overload report. If the peer identified in the overload report is not a peer to the reacting endpoint then the overload report should be stripped and not acted upon. 6.3. OC-SourceID - The SourceID AVP (AVP code TBD) is of type DiameterIdentity and is + The SourceID AVP (AVP code TBD2) is of type DiameterIdentity and is inserted by the DOIC node that either indicates support for this feature (in the OC-Supported-Features AVP) or that generates an OC- OLR AVP with a report type of peer. It contains the Diameter Identity of the inserting node. This is used by other DOIC nodes to determine if the a peer indicated support this feature or inserted the peer report. 6.4. Attribute Value Pair flag rules +---------+ |AVP flag | |rules | +----+----+ AVP Section | |MUST| Attribute Name Code Defined Value Type |MUST| NOT| +--------------------------------------------------------+----+----+ |OC-SourceID TBD1 x.x Unsigned64 | | V | - |OC-Peer-Algo TBD1 x.x Unsigned64 | | V | + |OC-Peer-Algo TBD2 x.x Unsigned64 | | V | +--------------------------------------------------------+----+----+ 7. IANA Considerations Editors note: This section will be completed once the base overload document has finished the definition of extension IANA requirements. 8. Security Considerations - Agent overload is an extension to the based Diameter overload + Agent overload is an extension to the base Diameter overload mechanism. As such, all of the security considerations outlined in [I-D.ietf-dime-ovli] apply to the agent overload scenarios. It is possible that the malicious insertion of an agent overload report could have a bigger impact on a Diameter network as agents can be concentration points in a Diameter network. Where an end-point report would impact the traffic sent to a single Diameter server, for example, a peer report could throttle all traffic to the Diameter network.