A request is sent towards its final destination using a combination of the Destination-Realm and Destination-Host AVPs. There are three specification-mandated combinations of these AVPs.
Of these three addressing methods, only the realm addressing requires additional configuration to select a routing algorithm that will be used by Diameter RAs. Routing and failover behaviour specific to this addressing mode is described in following sections:
General outgoing request routing
Requests addressed to a specific Diameter peer (both Destination-Host and Destination-Realm defined) are routed to that specific peer. Routing of realm-addressed requests requires additional configuration and includes route selection made by the RA, for the first request in a session. Subsequent requests in the same session are directed to the same peer. If the previously selected peer fails, session failover may take place; and the session might continue with requests directed to another peer in the same realm.
The configuration and general behaviour of Diameter RAs for outgoing request routing is based on the user-provided realm table.
The realm table may specify multiple realms and a default route:
<realm-table>
<realm>
<realm-name>opencloud</realm-name>
<application-route>
...
</application-route>
</realm>
<default-route>
...
</default-route>
</realm-table>Default Route
When routing the first outgoing request in a Diameter session, the realm table is searched for a realm definition matching the request`s Destination-Realm AVP value. If a matching realm is not found, then the default route is used.
If the default route is defined, it must contain one or more peer references:
<default-route>
<peer-ref>
<hostname>diameterserver1</hostname>
<metric>1</metric>
</peer-ref>
<peer-ref>
<hostname>diameterserver2</hostname>
<metric>2</metric>
</peer-ref>
</default-route>If there is only a single peer reference defined, or only a single peer is currently reachable (a network connection is established), the request is routed to that peer. Whenever there are multiple peers configured and reachable, a specific request routing algorithm is invoked to select among available peers.
Realm
When routing the first outgoing request in a Diameter session, and the realm table contains configuration for a realm matching the request`s Destination-Realm AVP value, that configuration is used as input to the user-selected routing algorithm.
The realm must contain at least one application route with one or more peer references:
<realm>
<realm-name>opencloud</realm-name>
<application-route>
<application>
<application-id>4</application-id>
<vendor-id>0</vendor-id> <!-- optional, default is zero -->
</application>
<action>LOCAL</action>
<transport-failover>ALWAYS</transport-failover>
<peer-ref>
<hostname>diameterserver1</hostname>
<metric>1</metric>
</peer-ref>
<peer-ref>
<hostname>diameterserver2</hostname>
<metric>2</metric>
</peer-ref>
</application-route>
</realm>The application route to use is selected based on the Vendor-Specific-Application-Id, Auth-Application-Id, or Acct-Application-Id AVP value in the request. If a matching application route is not found, then the default route is used. If there is only a single peer reference defined, or only a single peer is currently reachable (a network connection is established), the request is routed to that peer. Whenever there are multiple peers configured and reachable, a specific request routing algorithm is invoked to select among available peers.
Transport failover of Diameter sessions
This section describes Diameter RA behaviour when a connected peer fails.
When routing the first request on a new Diameter session, a failed peer is treated the same as if it was never connected. Diameter RAs provide an additional realm table configuration element, transport-failover, to select the expected RA behaviour when routing subsequent requests on a Diameter session. If a request could be routed to multiple peers (for example, if multiple peer-refs are specified for application-route or default-route) and the selected peer fails, then the transport-failover element value defines whether the request is sent to a different peer or a failure is reported to SBB.
The following values are supported by the transport-failover configuration element:
| Value | What it specifies | ||
|---|---|---|---|
BEFORE_FIRST_SEND |
Select the next peer only when: the request is the first request in a session; and a failure occurred before the message was put on the wire. (this is the default value) |
||
RETRANSMIT_ONLY_FIRST |
In addition to |
||
ALWAYS |
As well as the
|
Outgoing request routing algorithms
This version of the Diameter RAs supports two routing algorithms: METRIC and WEIGHT. Configuration syntax within the realm table is the same for both routing algorithms and is based on the metric value defined for the peer reference. The difference between them is how the metric value is interpreted:
-
METRIC— The metric value represents a "cost" of the route to the peer. The peer with the lowest cost (lowest metric value) is selected whenever reachable. If the metric of all peer references is equal, routing is done in a round-robin fashion. Peers with the same metric value are ordered based on the configuration order (the peer reference specified first is preferred to a peer reference specified later). -
WEIGHT— The metric value assigns a performance weight to each peer. Peers with a higher weight value receive a larger percentage of requests. The metric values of all peers in the route are summarized: the percentage of requests directed to a peer is equal to the peer’s metric value divided by the sum of metric values of all peers in the route. For example, for a route with three peers: peer A metric 10, peer B metric 15, and peer C metric 25, the percentage of initial requests that will be directed to each peer is: peer A 20%, peer B 30%, peer C 50%. When the metrics of all peer references are equal, the behaviour is equivalent to a round-robin algorithm.
Selection between routing algorithms is made using the RequestRouter attribute of the Diameter Configuration Profile.
