Re: [Dime] DOIC Overview of Operation

[Maria Cruz Bartolome <[e-mail]>]

Hello,

One more comment below for clarification.
It is fine to continue with then on .02 though.
Cheers


   The Diameter Overload Information Conveyance (DOIC) mechanism allows

   Diameter nodes to request other nodes to perform overload abatement

   actions, that is, actions to reduce the load offered to the

   overloaded node.



   A Diameter node that supports DOIC is known as a "DOIC endpoint".

   Any Diameter node can act as a DOIC endpoint, including clients,

   servers, and agents.  DOIC endpoints are further divided into

   "Reporting Nodes" and "Reacting Nodes."  A reporting node requests

   overload abatement by sending an Overload Report (OLR) to one or more

   reacting nodes.



   A reacting node consumes OLRs, and performs whatever actions are

   needed to fulfill the requests.  A Reporting node may report overload

   on its own behalf, or on behalf of other (typically upstream) nodes.

   Likewise, a reacting node may perform overload abatement on its own

   behalf, or on behalf of other (typically downstream) nodes.



   A node's role as a DOIC endpoint is independent of its Diameter role.

   For example, Diameter relay and proxy agents may act as DOIC

   endpoints, even though they are not endpoints in the Diameter sense.

   Since Diameter enables bi-directional applications, where Diameter

   servers can send requests towards Diameter clients, a given Diameter

   node can simultaneously act as a reporting node and reacting node.



   Likewise, an relay or proxy agent may act as a reacting node from the

   perspective of upstream nodes, and a reporting node from the

   perspective of downstream nodes.



   DOIC endpoints do not generate new messages to carry DOIC related

   information.  Rather, they "piggyback" DOIC information over existing

   Diameter messages by inserting new AVPs into existing Diameter

   requests and responses.  Nodes indicate support for DOIC, and any

   needed DOIC parameters by inserting an OC_Supported_Features AVP

   (Section 4.1) into existing requests and responses.  Reporting nodes

   send OLRs by inserting OC-OLR AVPs.  (Section 4.3)



   A given OLR applies to the Diameter realm and application of the

   Diameter message that carries it.  If a reporting node supports more

   than one realm and/or application, it reports independently for each

   combination of realm and application.  Similarly, OC-Feature-Vector

   AVPs apply to the realm and application of the enclosing message.

   This implies that a node may support DOIC for one application and/or

   realm, but not another, and may indicate different DOIC parameters

   for each application and realm for which it supports DOIC.



   Reacting nodes perform overload abatement according to an agreed-upon

   abatement algorithm.  An abatement algorithm defines the meaning of

   the parameters of an OLR, and the procedures required for overload

   abatement.  This document specifies a single must-support algorithm,

   namely the "loss" algorithm [ref?].  Future specifications may

   introduce new algorithms.



   Overload conditions may vary in scope.  For example, a single

   Diameter node may be overloaded, in which case reacting nodes may

   reasonably attempt to send throttled requests to other destinations

   or via other agents.  On the other hand, an entire Diameter realm may

   be overloaded, in which case such attempts would do harm.  DOIC OLRs

   have a concept of "report type" (Section 4.6), where the type defines

   such behaviors.  Report types are extensible.  This document defines

   report types for overload of a specific server, and for overload of

   an entire realm.



   While a reporting node sends OLRs to "adjacent" reacting nodes, nodes

   that are "adjacent" for DOIC purposes may not be adjacent from a

   Diameter, or transport, perspective.

[MCruz] Using the term "adjacent" is kind of misleading, even if you later explained precisely that.

Above paragraph could be replaced by "Reacting and reporting nodes are not necessarily adjacent nodes"



For example, one or more

   Diameter agents that do not support DOIC may exist between a given

   pair of reporting and reacting nodes, as long as those agents pass

   unknown AVPs through unmolested.  The report types described in this

   document can safely pass through non-supporting agents.  This may not

   be true for report types defined in future specifications.  Documents

   that introduce new report types MUST describe any limitations on

   their use across non-supporting agents.