About Load Shedding Overload Control for Diameter

Load shedding is used to reduce latency and to keep an MRA server stable and reliable in overload situations. When enabled, certain requests are rejected by an MRA server when it becomes too heavily loaded to process them. You can access Load Shedding Configuration controls from the MRA and MPE Advanced Configuration pages where you can configure rules for rejecting messages during overload conditions. Multiple congestion levels are defined which can be configured to accept, reject or drop selected messages at each level.

An MRA attempts to successfully process a message whenever possible in one of the following ways:

Local Diversion
Selects a new MPE server in the MPE pool to handle a new connection for a subscriber who is bound to a busyMPE server.
Remote Diversion
Selects an MRA server to handle a new connection for a subscriber who is bound to a busy MPE server. That MRA server creates a binding for the subscriber pointing to one of the MPE servers in the MPE pool.

Note: If any MRA, or MPE servers are unavailable during backup MRA implementation the Remote Diversion function does not work and the error message DIAMETER_TOO_BUSY message occurs. See Policy Management Troubleshooting Reference for more information.

Both MPE and MRA servers handle message overload by utilizing congestion (busyness) levels. An MRA server utilizes two congestion levels (Level 1 and 2) while an MPE server utilizes four congestion levels (Levels 1-4). At each level you can create rules to match the message types that are received. In addition, you can configure a default action that is taken if none of the rules configured for the level match a message. For example, for Level 1, the default Level Action is Accept, which means to bypass load shedding rules. (For more information on actions, see step 8 in Configuring Load Shedding for an MRA Device.)

Note: When Local or Remote Diversion is not possible, the default result code is DIAMETER_TOO_BUSY. The NO_CAPACITY result code indicates an MRA server has a binding, but the MPE server it points to is currently overloaded, and the MRA server cannot perform local diversion to handle the request. The default result code is configurable.

An MRA server proactively rejects all messages destined for an overloaded MPE at all congestion levels. For example, if an MPE is configured to reject CCR-U messages at Level 2, the MRA server rejects the CCR-U message with DIAMETER_UNABLE_TO_COMPLY instead of forwarding it to an MPE server.

An MRA server subscribes to its pool of MPE servers for load notifications by issuing an LSR message after connection is established. It also subscribes to MPE servers in the backup MRA pool and to all other MRA servers in its association. MRA servers communicate their status using Load Notification (LNR) messages that include a Diversion-Status AVP to indicate whether that MRA server is available.

The Diversion-Status AVP indicates whether an MRA is available for diverting traffic to its MPE servers (Remote Diversion). The diversion status is set to DIVERTABLE if none of the MPE servers in an MPE pool are overloaded. The status is set to NOT_DIVERTABLE if at least one MPE server in the MPE pool is overloaded.

When you configure the admission rules for an MRA server to reject messages on behalf of an overloaded MPE server, there can still be times when the MPE server responds to a message with DIAMETER_TOO_BUSY. In these cases, before forwarding the answer message, the MRA server runs the original request through the MPE admission rules and updates the result code in the message with the result code found in the rules.