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.
DOIC is comprised of two routing capabilities:
- Static ETR Throttling
- Peer Node Reported Congestion
DOIC is comprised of two primary procedures using two Diameter Grouped AVPs:
- 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
Static ETR Throttling allows you to limit the rate of transactions (Request messages only) that are forwarded to a particular Peer Node, which are addressed to a particular Diameter Application ID. For each (Peer Node, Application ID) ordered pair that you want to throttle, define a Traffic Throttle Point (TTP) and assign it a Maximum ETR value. All of the information required for Peer Node/Application ETR throttling is stored in a Traffic Throttle Point (TTP). If a Peer Node supports multiple Application IDs, you must create a separate TTP for each Application for which you want to enable ETR throttling. When you enable the TTP for service, the routing application begins to measure the rate of transactions that are routed to the Peer Node and Application ID (this includes transactions such as priority override and NGN-PS that might be exempt from diversion). This is referred to as the Offered Traffic Rate (
OTR). Divertable OTRs are the transaction rates offered to a TTP that are candidates for diversion. NGN-PS and priority override transaction are exempt from TTP ETR throttling diversion. When the TTP OTR begins to exceed its user-defined Maximum ETR, the routing application routes the excess transactions alternately using all of the existing routing mechanisms.
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).
Traffic reduction percentages for a Peer Node and Application are used during routing in the following ways:
- 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.
When you enable a TTG, the routing application does not select a Route Group from a Route List when the following criteria are met:
- 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.
The DCA procedure is invoked only when a Request message is being forwarded to a Peer Node for which DOIC has been enabled for the application ID to which the message is addressed. The decision for determining whether an OC-Supported-Features AVP should be appended occurs after the routing application has selected a Connection for forwarding the Request. If the Peer Node associated with the selected Connection has an active TTP associated with the Application ID in the Request message, then:
- 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.
A TTP is considered active, if for a transaction being forwarded to a Connection, the following criteria are met:
- 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
Each time the routing server receives an Answer message that can be associated with a
PTR, it checks if a TTP has been stored in the PTR. If not, then the routing server ignores any DOIC AVPs in the message. If a TTP is stored in the PTR, then it searches for DOIC AVPs in the Answer response if the following criteria are met:
- 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.
If a validation failure occurs with any AVP within the OC-OLR, the entire OLR is discarded. If the OLR is valid, it is handled based upon the type of request as follows:
- 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
Next Generation Network Priority Service (NGN-PS) allows National Security/Emergency Preparedness (
NS/EP) users (service users) to make priority calls/sessions using the public networks. When the NGN-PS feature is enabled on a DSR Node, DSR examines the content of ingress messages received from Diameter Peer Nodes to determine if they qualify for priority treatment based upon a set of rules. See
Diameter System Options elements. If priority treatment is required, the message is assigned a priority of 4 and becomes inviolable, which means that it becomes exempt from discard and bypasses all DSR ingress and egress congestion throttling controls. The following exemptions are provided to inviolable message from DOIC throttling constraints:
- 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.
