Skip to main content

Diameter Agent Overload and the Peer Overload Report
draft-ietf-dime-agent-overload-05

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8581.
Author Steve Donovan
Last updated 2016-05-19
Replaces draft-donovan-dime-agent-overload
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 8581 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Kathleen Moriarty
Send notices to (None)
draft-ietf-dime-agent-overload-05
Diameter Maintenance and Extensions (DIME)                    S. Donovan
Internet-Draft                                                    Oracle
Intended status: Standards Track                            May 19, 2016
Expires: November 20, 2016

          Diameter Agent Overload and the Peer Overload Report
                 draft-ietf-dime-agent-overload-05.txt

Abstract

   This specification documents an extension to the Diameter Overload
   Indication Conveyance (DOIC) [RFC7683] 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
   provisions of BCP 78 and BCP 79.

   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 November 20, 2016.

Copyright Notice

   Copyright (c) 2016 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

Donovan                 Expires November 20, 2016               [Page 1]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   3
   3.  Peer Report Use Cases . . . . . . . . . . . . . . . . . . . .   4
     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  . . . . . . . . . . . . . . .   8
       5.1.2.  Reporting Node Behavior . . . . . . . . . . . . . . .   9
     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  . . . . . . . . . . . . . . . . .  15
     6.3.  SourceID  . . . . . . . . . . . . . . . . . . . . . . . .  16
     6.4.  Attribute Value Pair flag rules . . . . . . . . . . . . .  16
   7.  IANA  Considerations  . . . . . . . . . . . . . . . . . . . .  16
     7.1.  AVP codes . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.2.  New registries  . . . . . . . . . . . . . . . . . . . . .  16
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

Donovan                 Expires November 20, 2016               [Page 2]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

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.  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 [RFC7683] 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
   Agent might also handle the overload mitigation.  For instance, a
   Diameter Agent might handle Diameter overload mitigation when it
   knows that a Diameter Client does not support the DOIC extension.

   This document extends the base Diameter endpoint overload
   specification to address the case when Diameter Agents become
   overloaded.  Just as is the case with other Diameter nodes --
   Diameter Clients and Diameter Servers -- surges in Diameter traffic
   can cause a Diameter Agent to be asked to handle more Diameter
   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 [RFC7683] and is expected to
   work for other overload abatement algorithms defined in extensions to
   the DOIC solution.

2.  Terminology and Abbreviations

   Diameter Node

      A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733
      Diameter Agent.

   Diameter Endpoint

      An RFC6733 Diameter Client and RFC6733 Diameter Server.

Donovan                 Expires November 20, 2016               [Page 3]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

   Reporting Node

      A DOIC Node that sends and overload report in a Diameter answer
      message.

   Reacting Node

      A DOIC Node that receives and acts on a Diameter overload report.

   DIOC Node

      A Diameter Node that supports the DOIC solution defined in
      [RFC7683].

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 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 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|
                              +-+    +-+    +-+

                                 Figure 1

   A more likely case for the use of agents is illustrated in Figure 2.
   In this case, there are multiple servers behind the single agent.
   The client sends all traffic through the agent and the agent
   determines how to distribute the traffic to the servers based on
   local routing and load distribution policy.

Donovan                 Expires November 20, 2016               [Page 4]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

                                            +-+
                                          --|s|
                              +-+    +-+ /  +-+
                              |c|----|a|-   ...
                              +-+    +-+ \  +-+
                                          --|s|
                                            +-+

                                 Figure 2

   In both of these cases, the occurrence of overload in the single
   agent must by handled by the client in a similar fashion as if the
   client were handling the overload of a directly connected server.
   When the agent becomes overloaded it will insert an overload report
   in answer messages flowing to the client.  This overload report will
   contain a requested reduction in the amount of traffic sent to the
   agent.  The client will apply overload abatement behavior as defined
   in the base Diameter overload specification [RFC7683] or the
   extension draft that defines the indicated overload abatement
   algorithm.  This will result in the throtting of the abated traffic
   that would have been sent to the agent, as there is no alternative
   route, with the appropriate indication given to the service request
   that resulted in the need for the Diameter transaction.

3.1.2.  Redundant Agents

   Figure 3 and Figure 4 illustrate a second, and more likely, type of
   deployment scenario involving agents.  In both of these cases, the
   client has Diameter connections to two agents.

   Figure 3 illustrates a client that has a primary connection to one of
   the agents (agent a1) and a secondary connection to the other agent
   (agent a2).  In this scenario, under normal circumstances, the client
   will use the primary connection for all traffic.  The secondary
   connection is used when there is a failure scenario of some sort.

                                     +--+   +-+
                                   --|a1|---|s|
                              +-+ /  +--+\ /+-+
                              |c|-        x
                              +-+ .  +--+/ \+-+
                                   ..|a2|---|s|
                                     +--+   +-+

                                 Figure 3

Donovan                 Expires November 20, 2016               [Page 5]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

   The second case, in Figure 4, illustrates the case where the
   connections to the agents are both actively used.  In this case, the
   client will have local distribution policy to determine the
   percentage of the traffic sent through each client.

                                     +--+   +-+
                                   --|a1|---|s|
                              +-+ /  +--+\ /+-+
                              |c|-        x
                              +-+ \  +--+/ \+-+
                                   --|a2|---|s|
                                     +--+   +-+

                                 Figure 4

   In the case where one of the agents in the above scenarios become
   overloaded, the client should reduce the amount of traffic sent to
   the overloaded agent by the amount requested.  This traffic should
   instead be routed through the non-overloaded agent.  For example,
   assume that the overloaded agent requests a reduction of 10 percent.
   The client should send 10 percent of the traffic that would have been
   routed to the overloaded agent through the non-overloaded agent.

   When the client has an active and a standby connection to the two
   agents then an alternative strategy for responding to an overload
   report from an agent is to change to standby connection to active and
   route all traffic through the new active connection.

   In the case where both agents are reporting overload, the client may
   need to start decreasing the total traffic sent to the agents.  This
   would be done in a similar fashion as discussed in section 3.1.  The
   amount of traffic depends on the combined reduction requested by the
   two agents.

3.1.3.  Agent Chains

   There are also deployment scenarios where there can be multiple
   Diameter Agents between Diameter Clients and Diameter Servers.
   Examples of this type of deployment include when there are edge
   agents between Diameter networks.  Another example of this type of
   deployment is when there are multiple sets of servers, each
   supporting a subset of the Diameter traffic.

   Figure 5 illustrates one such network deployment case.  Note that
   while this figure shows a maximum of two agents being involved in a
   Diameter transaction, it is possible that more than two agents could
   be in the path of a transaction.

Donovan                 Expires November 20, 2016               [Page 6]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

                                +---+     +---+   +-+
                              --|a11|-----|a21|---|s|
                         +-+ /  +---+ \ / +---+\ /+-+
                         |c|-          x        x
                         +-+ \  +---+ / \ +---+/ \+-+
                              --|a12|-----|a22|---|s|
                                +---+     +---+   +-+

                                 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.

   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 [RFC7683].

3.2.  Diameter Endpoint Use Cases

   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 document is being 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.

Donovan                 Expires November 20, 2016               [Page 7]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

4.  Interaction Between Host/Realm and Peer Overload Reports

   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 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.

5.1.  Capability Announcement

5.1.1.  Reacting Node Behavior

   When sending a Diameter request a DOIC node that supports the
   OC_PEER_REPORT feature MUST include an OC-Supported-Features AVP with
   an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.

      Note: The sender of a request can be a Diameter Client or Diameter
      Server that originates the Diamter request or a Diameter Agent
      that relays the request.

   Support for the OC_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 OC_PEER_REPORT
   feature MUST include a SourceID AVP in the OC-Supported-Features AVP
   with its own DiameterIdentity.

      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
      OC_PEER_REPORT feature.

   When relaying a request that includes a SourceID AVP in the OC-
   Supported-Features AVP, a DOIC node that supuports the OC_PEER_REPORT
   feature must remove the received SourceID AVP and replace it with a
   SourceID AVP containing its own Diameter identity.

Donovan                 Expires November 20, 2016               [Page 8]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

5.1.2.  Reporting Node Behavior

   When receiving a request a DOIC node that supports the OC_PEER_REPORT
   feature MUST update transaction state with an indication of whether
   or not the peer from which the request was received supports the
   OC_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 OC_PEER_REPORT feature.

   The following are indications that the peer does not support the
   OC_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
      OC-Feature-Vector with the OC_PEER_REPORT feature bit cleared.

      The received request contains an OC-Supported-Features AVP with a
      OC-Feature-Vector with the OC_PEER_REPORT feature bit set but with
      a SourceID AVP with a DiameterIdentity that does not match the
      DiameterIdentity of the peer from which the request was received.

   The peer supports the OC_PEER_REPORT feature if the received request
   contains an OC-Supported-Features AVP with the OC-Feature-Vector with
   the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
   Diameter ID that matches the DiameterIdentity of the peer from which
   the request was received.

   When relaying an answer message, a reporting node that supports the
   OC_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
   OC_PEER_REPORT feature MUST determine if the peer to which the answer
   is to be sent supports the OC_PEER_REPORT feature.

   If the peer supports the OC_PEER_REPORT feature then the reporting
   node MUST indicate support for the feature in the Supported-Features
   AVP.

Donovan                 Expires November 20, 2016               [Page 9]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

   If the peer supports the OC_PEER_REPORT feature then the reporting
   node MUST insert the SourceID AVP in the OC-Supported-Features AVP in
   the answer message.

   If the peer supports the OC_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 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
   maintained by both the peer report reporting node and the peer report
   reacting node.

5.2.1.1.  Reporting Node Peer Report OCS

   A DOIC Node that supports the OC_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.

      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

   o  Abatement Algorithm

Donovan                 Expires November 20, 2016              [Page 10]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

   o  Algorithm specific input data (for example, the Reduction
      Percentage for the Loss Abatement Algorithm)

5.2.1.2.  Reacting Node Peer Report OCS

   A DOIC node that supports the OC_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
   DiameterIdentity of the peer as communicated during the RFC6733
   defined Capability 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

   o  Algorithm specific input data (for example, the Reduction
      Percentage for the Loss Abatement Algorithm)

5.2.2.  Reporting Node Maintenance of Peer Report OCS

   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 OC_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
   [RFC7683] 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 a report type of
   peer it MUST determine if the report was generated by the Diameter
   peer from which the report was received.

Donovan                 Expires November 20, 2016              [Page 11]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

   If the DiameterID in the SourceID contained in the OLR matches the
   DiameterIdentity 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
   SourceID does not match the ID of the Diameter peer from which the
   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 DiameterIdentity received in the SourceID AVP matches
   the DiameterIdentity 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.

   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").

Donovan                 Expires November 20, 2016              [Page 12]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

   The reacting node sets the abatement algorithm based on the OC-Peer-
   Algo AVP in the received OC-Supported-Features AVP.

5.2.4.  Peer Report Reporting Node Behavior

   When there is an existing reporting node peer report OCS entry, the
   reporting node MUST include an OC-OLR AVP with a report type of peer
   using the contents of the reporting node peer report OCS entry in all
   answer messages sent by the reporting node to peers that support the
   OC_PEER_REPORT feature.

      The reporting node determines if a peer supports the
      OC_PEER_REPORT feature based on the indication recorded in the
      reporting nodes transaction state.

   The reporting node MUST include its DiameterIdentity in the SourceID
   AVP in the OC-OLR AVP.  This is used by DOIC nodes that support the
   OC_PEER_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/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 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 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 [RFC7683].

Donovan                 Expires November 20, 2016              [Page 13]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

   In the case that the OCS entry validity duration expires or has a
   validity duration of zero ("0"), meaning that it the reporting node
   has explicitly signaled the end of the overload condition then
   abatement associated with the overload abatement MUST be ended in a
   controlled fashion.

6.  Peer Report AVPs

6.1.  OC-Supported-Features AVP

   This extension adds a new feature to the OC-Feature-Vector AVP.  This
   feature indication shows support for handling of peer overload
   reports.  Peer overload reports are used by agents to indicate the
   need for overload abatement handling by the agents peer.

   A supporting node must also include the SourceID AVP in the OC-
   Supported-Features capability AVP.

   This AVP contains the Diameter Identity of the node that supports the
   OC_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 ]
                              [ 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.

   OC_PEER_REPORT (0x0000000000000010)

      When this flag is set by a DOIC node it indicates that the DOIC
      node supports the peer overload report type.

Donovan                 Expires November 20, 2016              [Page 14]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

6.1.2.  OC-Peer-Algo

   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.

6.2.  OC-OLR AVP

   This extension makes no changes to the SequenceNumber or
   ValidityDuration AVPs in the OC-OLR AVP.  These AVPs are also be used
   in peer overload reports.

   The OC_PEER_REPORT feature extends the base Diameter overload
   specification by defining a new overload report type of "peer".  See
   section [7.6] in [RFC7683] for a description of the OC-Report-Type
   AVP.

   The overload report must also include the Diameter identity of the
   agent that generated the report.  This is necessary to handle the
   case where there is a non supporting agent between the reporting node
   and the reacting node.  Without the indication of the agent that
   generated the overload request, the reacting node could erroneously
   assume that the report applied to the non supporting node.  This
   could, in turn, result in unnecessary traffic being either
   redistributed or throttled.

   The SourceID AVP is used in the OC-OLR AVP to carry this
   DiameterIdentity.

      OC-OLR ::= < AVP Header: TBD2 >
                 < OC-Sequence-Number >
                 < OC-Report-Type >
                 [ OC-Reduction-Percentage ]
                 [ OC-Validity-Duration ]
                 [ SourceID ]
               * [ AVP ]

6.2.1.  OC-Report-Type AVP

   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

Donovan                 Expires November 20, 2016              [Page 15]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

      endpoint then the overload report should be stripped and not acted
      upon.

6.3.  SourceID

   The SourceID AVP (AVP code TBD2) is of type DiameterIdentity and is
   inserted by a Diameter node to indicate the source of the AVP in
   which it is a part.

   In the case of peer reports, the SourceID AVP indicates the node that
   support for this feature (in the OC-Supported-Features AVP) or the
   node that generates an overload with a report type of peer (in the
   OC-OLR AVP).

   It contains the DiameterIdentity of the inserting node.  This is used
   by other Diameter nodes to determine the node that inserted the
   enclosing AVP that contains the SourceID AVP.

6.4.  Attribute Value Pair flag rules

                                                             +---------+
                                                             |AVP flag |
                                                             |rules    |
                                                             +----+----+
                             AVP   Section                   |    |MUST|
     Attribute Name          Code  Defined Value Type        |MUST| NOT|
    +--------------------------------------------------------+----+----+
    |SourceID                TBD1    x.x   DiameterIdentity  |    | V  |
    |OC-Peer-Algo            TBD2    x.x   Unsigned64        |    | V  |
    +--------------------------------------------------------+----+----+

7.  IANA Considerations

7.1.  AVP codes

   New AVPs defined by this specification are listed in Section 6.  All
   AVP codes are allocated from the 'Authentication, Authorization, and
   Accounting (AAA) Parameters' AVP Codes registry.

7.2.  New registries

   There are no new IANA registries introduced by this document.

   The values used for the OC-Peer-Algo AVP are the subset of the "OC-
   Feature-Vector AVP Values (code 622)" registry.  Only the values in

Donovan                 Expires November 20, 2016              [Page 16]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

   that registry that apply to overload abatement algorithms apply to
   the OC-Peer-Algo AVP.

8.  Security Considerations

   Agent overload is an extension to the base Diameter overload
   mechanism.  As such, all of the security considerations outlined in
   [RFC7683] 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.

   This impact is amplified in an agent that sits at the edge of a
   Diameter network that serves as the entry point from all other
   Diameter networks.

9.  Acknowledgements

   Adam Roach and Eric McMurry for the work done in defining a
   comprehensive Diameter overload solution in draft-roach-dime-
   overload-ctrl-03.txt.

   Ben Campbell for his insights and review of early versions of this
   document.

10.  Normative References

   [I-D.ietf-dime-doic-rate-control]
              Donovan, S. and E. Noel, "Diameter Overload Rate Control",
              draft-ietf-dime-doic-rate-control-01 (work in progress),
              March 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

Donovan                 Expires November 20, 2016              [Page 17]
Internet-Draft   Diameter Agent Overload and Peer Report        May 2016

   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733,
              DOI 10.17487/RFC6733, October 2012,
              <http://www.rfc-editor.org/info/rfc6733>.

   [RFC7068]  McMurry, E. and B. Campbell, "Diameter Overload Control
              Requirements", RFC 7068, DOI 10.17487/RFC7068, November
              2013, <http://www.rfc-editor.org/info/rfc7068>.

   [RFC7683]  Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
              Morand, "Diameter Overload Indication Conveyance",
              RFC 7683, DOI 10.17487/RFC7683, October 2015,
              <http://www.rfc-editor.org/info/rfc7683>.

Author's Address

   Steve Donovan
   Oracle
   7460 Warren Parkway, Suite 300
   Frisco, Texas  75034
   United States

   Email: srdonovan@usdonovans.com

Donovan                 Expires November 20, 2016              [Page 18]