Diameter Overload Indication Conveyance (DOIC)
DOIC allows Diameter servers to send overload reports requesting that diameter clients reduce the traffic that they are sending to the server. It also allows for Diameter Agents to act as a proxy for either clients by reducing traffic as requested by the servers, or as a proxy for the servers by requesting that traffic be reduced by the clients. DOIC s main purpose is to act as a proxy for the clients on the routing server and reduce traffic based on information from the servers.
- Static ETR Throttling
- Peer Node Reported Congestion
- Capability Announcement Procedure
- DSR as a DOIC Reacting Node advertises its supported DOIC capabilities by inserting a OC-Supported-Features Grouped AVP in each forwarded Request message sent to a DOIC Reporting Node. The DOIC Reporting Node sends an OC-Supported-Features AVP in Answer responses indicating which abatement algorithm it wants to support.
- Overload Reporting Procedure
- The DOIC Reporting Node can request a reduction in traffic addressed to a given application for that Reporting node by inserting one or more Applications associated with a Node/FQDN by inserting a DOIC Overload Report (OC-OLR) Grouped AVP in Answer responses to a Request containing a OC-Supported-Features AVP.
Static ETR Throttling
Note:
A TTP's OTR measurements include all transactions which are associated with an active TTP, which includes both override priority and NGN-PS transactions that might be exempt from diversion.Traffic diversion is prioritized based upon the Discard Policy assigned to the DA-MPs. Using the Discard Policy and message priority and color OTRs measurements, the TTP Rate Shaper algorithm determines whether a Request message associated with the TTP must be diverted. TTP rate shaping is applied after a Peer Node or Connection is selected from a Route Group (or after a Peer Node is selected by Implicit Routing).
Peer Node Reported Congestion
Routing supports the ability to modify the rate of transactions forwarded to a Peer Node based on the OLRs it receives in Answer responses from the Peer Node. The information received in a OLR is stored in a TTP and applied as modifications to the Target ETR. An OLR is enforced until it expires or is cancelled by the Peer Node, at which time the routing application abates the requested traffic reduction percentage to 0 (at a gradual rate determined by a user-configurable TTP attribute).
- You can assign a Maximum Loss Percentage Threshold to a TTP. When this occurs, the routing application does not select a Peer Node or Connection from a Route Group (or select a Peer Node for Implicit Routing) if the TTP's Current Loss Percentage exceeds this threshold.
- When a traffic reduction request is received for a TTP, the routing application updates the TTP Target ETR, which is used for ETR Throttling. ETR Throttling is applied after a Peer Node or Connection is selected from a Route Group (or a Peer Node is selected by Implicit Routing).
- When a message is diverted using a TTP ETR Throttling, the transaction is marked as Diverted in the transaction PTR. When a transaction is marked as Diverted, any subsequent Peer Nodes or Connections are excluded from being a candidate for routing (or re-routing) the diverted transaction if it has a TTP with a non-zero Current Loss Percentage.
- You can allow higher priority transactions to bypass routing constraints via the TTP Override Message Priority Threshold attribute. This attribute is used in the following circumstances:
- After a transaction has been categorized as Diverted, a Request is allowed to be routed to a congested TTP if its priority is great than or equal to the TTP's Override Message Priority Threshold attribute.
- After a Peer Node or Connection is selected from a Route Group (or a Peer Node is selected by Implicit Routing), it bypasses a TTP ETR Throttling if all of the following criteria are met:
- An active TTP exists for the selected Peer Node/Connection and the Application ID addressed by the transaction
- You have assigned a value to the TTP's Override Message Priority Threshold attribute
- The Request message's priority is greater or equal to the TTP Override Message Priority Threshold attribute
- The TTP's OTR is less than or equal to the TTP Maximum ETR
Note:
A TTP's OTR measurements include all transactions which are associated with an active TTP, which includes both override priority and NGN-PS transactions might be exempt from diversion.
Traffic reduction requests from Peer Nodes within a Route Group can be aggregated and used for making decisions about whether Route Groups within a Route List are viable candidates for routing a transaction. Traffic reduction loss values for a group of Connection or Peer Nodes are aggregated by the Traffic Throttle Group (TTG) to which you assign a set of TTPs. The local TTG traffic reduction information is also distributed to other Nodes within the network to assist them in making decisions about sending traffic they cannot handle to the affected Node.
When a TTG is created and enabled for service, the routing application begins to maintain an aggregated Current Loss Percentage for the TTG based upon the Maximum ETR assigned to each TTP and the Current Loss Percentage for each TTP. A TTG can be assigned to a Route Group within a Route List along with a maximum loss threshold.
- TTG is assigned to the Route Group within the Route List
- TTG admin state is Enabled
- TTG Current Loss Percentage exceeds the Maximum Loss Percentage Threshold value assigned to the Route Group within the Route List
DOIC Capabilities Announcement (DCA)
The DOIC solution supports the ability for Diameter nodes to determine if other nodes in the path of a request support the DOIC solution. The DOIC Capabilities Announcement (DCA) procedure allows a DOIC Reacting Node to indicate which DOIC capabilities it supports to a DOIC Reporting Node which, in turn, responds with which capabilities it wants to use.
- Append an OC-Supported-Features AVP to the forwarded Request message containing the list of Abatement Algorithms assigned to the TTP by user configuration.
- Save the TTP in the PTR.
- TTP exists for the Peer Node to which the Request is to be forwarded and the Application-Id in the Request header, AND
- TTP's Dynamic Throttling Admin State is set to Enabled
- TTP's Operational Status is NOT set to Inactive
- TTP is still active (it may have changed between the time the Request was sent and the Answer was received)
- Diameter Node which initiated the Answer (identified by the Origin-Host AVP) is the same node associated with the TTP
If any of these validations fail, then the routing server ignores any DOIC AVPs in the message.
DOIC Overload Reports (OLR)
A DOIC Reporting Node notifies a Reacting Node of a new or change to a previously reported traffic overload condition by piggy-backing one or more OC-OLR AVPs in the Answer response to a DCA procedure. If multiple OC-OLR are found, the routing application only processes the first two OC-OLR found from the top of the Answer message and ignores the balance. It is possible in the DOIC specification to receive two OLR in the same Answer message, the only restriction is that they must have different values for the OC-Report-Type AVP.
OLR AVP Validation and Processing
The OC-OLR is a Grouped AVP. AVPs can be grouped and embedded in the OC-OLR, and they can be validated via the routing application. Optionally, you can define the amount of time (in seconds) that the OLR is enforced. You can also (optionally) define the percentage of the traffic reduction that is requested.
- New overload report
- Update to an existing overload report
- Cancellation of an existing overload report
New OLR
The routing application considers an OLR to be a new request when the TTP Validity Duration stored in the local TTP RT-DB is set to 0. The routing application could be in an overload recovery state for the previously received OLR. When this occurs, the recovery procedure is abandoned by stopping the DOIC Overload Recover timer. The new OLR is then processed.
Cancel an Existing OLR
A Peer Node can cancel an active overload state by setting the OC-Reduction-Percentage to 0 or by setting the OC-Validity-Duration AVP to 0 seconds. Cancellation only applies if the routing application is processing an OLR (TTP's Validity Duration greater than 0). A cancellation is ignored if overload recovery is in progress (Operational Reason is Peer Overload Recovery). If a cancellation is received while the TTP is in Peer Overload, the routing application processes the request.
Modify an Existing OLR
An upstream Peer Node can update an in-progress overload condition. An update request must contain a Sequence Number larger than the previously one sent. The routing application treats an OLR as an update to an existing overload condition if the validation criteria are met.
DOIC Information Sharing within a Node
Traffic reduction requests from an upstream Peer Node can be sent to any DA-MP. This information must be shared with all DA-MPs within the Node so that it can be applied when routing transactions to the congested entity. When a routing application instance on a DA-MP receives a DOIC OLR that modifies a TTP, the updated TTP information is forwarded to all of its peer routing application instances within the Node via a DOIC-OLR stack event.
Overload Recovery and Abatement
When an OLR received from a Peer Node expires or is cancelled, the routing application must restore the traffic rate for the TTP to its maximum capacity. Rather than abruptly reducing the TTP's Current Loss Percent to 0, the routing application reduces the Current Loss Percent based upon a user-defined loss restoral rate defined by the TTP attribute Abatement Recovery Rate.
DOIC and NGN-PS Interaction
- Inviolable Request messages from a Route Group-TTG's Maximum Loss Percent Threshold constraint are exempt.
- Inviolable Request messages from a Peer Node-TTP's Maximum Loss Percent Threshold constraint are exempt.
- Any TTP ETR message throttling constraints for inviolable Request messages are bypassed.
Note:
NGN-PS transactions are never diverted by ETR throttling; therefore, any existing diameter routing layer routing rules associated with DOIC-diverted transactions do not apply.