Skip to main content

6.1. Diameter Request Routing Overview

6.1. Diameter Request Routing Overview​

A request is sent towards its final destination using one of the following three combinations of the Destination-Realm and Destination-Host AVPs:

  • A request that is not able to be proxied (such as a CER) MUST NOT contain either Destination-Realm or Destination-Host AVPs.

  • A request that needs to be sent to a home server serving a specific realm, but not to a specific server (such as the first request of a series of round trips), MUST contain a Destination-Realm AVP but MUST NOT contain a Destination-Host AVP. For Diameter clients, the value of the Destination-Realm AVP MAY be extracted from the User-Name AVP, or other methods.

  • Otherwise, a request that needs to be sent to a specific home server among those serving a given realm MUST contain both the Destination-Realm and Destination-Host AVPs.

The Destination-Host AVP is used as described above when the destination of the request is fixed, which includes:

  • Authentication requests that span multiple round trips.

  • A Diameter message that uses a security mechanism that makes use of a pre-established session key shared between the source and the final destination of the message.

  • Server-initiated messages that MUST be received by a specific Diameter client (e.g., access device), such as the Abort-Session-Request message, which is used to request that a particular user's session be terminated.

Note that an agent can only forward a request to a host described in the Destination-Host AVP if the host in question is included in its peer table (see Section 2.6). Otherwise, the request is routed based on the Destination-Realm only (see Section 6.1.6).

When a message is received, the message is processed in the following order:

  • If the message is destined for the local host, the procedures listed in Section 6.1.4 are followed.

  • If the message is intended for a Diameter peer with whom the local host is able to directly communicate, the procedures listed in Section 6.1.5 are followed. This is known as "Request Forwarding".

  • The procedure listed in Section 6.1.6 is followed, which is known as "Request Routing".

  • If none of the above are successful, an answer is returned with the Result-Code set to DIAMETER_UNABLE_TO_DELIVER, with the 'E' bit set.

For routing of Diameter messages to work within an administrative domain, all Diameter nodes within the realm MUST be peers.

The overview contained in this section (6.1) is intended to provide general guidelines to Diameter developers. Implementations are free to use different methods than the ones described here as long as they conform to the requirements specified in Sections 6.1.1 through 6.1.9. See Section 7 for more details on error handling.

Last updated on