When the Ribbon DSC receives a message at a node, it examines its routing tables (if any) to determine rules for routing the message. If the initial routing table or any next table indicates "dsc_default", then default routing is performed.

Diameter Answer messages are always sent back to the connection on which the corresponding Diameter Request was received. If there is no corresponding Diameter Request (as determined by Hop-by-Hop ID “hh-id”), the Answer message is considered unexpected and is discarded.

DSC Default Routing attempts to route Diameter Request messages to the next hop using dynamic information about the Realm and Application IDs of the Adjacent Diameter Nodes (ADNs, with supplementary information from the Realm Routing table and from any provisioned Server Pool object).

The candidates for the next hop route for a Diameter Request message when using dsc_default routing depends on whether or not the Request message contains a Destination-Host AVP.

Note

In the following description,

  • the term target realm refers to the realm in the Destination-Realm AVP of the Request message that is being routed.
  • the term local realm refers to the realm of the DSC Node that is routing the request.

During dsc_default routing of a Diameter Request message that does not contain a Destination-Host AVP, candidates for the next hop are considered in the following order:

  • Adjacent Diameter Nodes (ADNs) in the target realm that advertise support for the specific Application ID.  If the target realm is the local realm and a server pool exists for this message (matching Application ID), the candidate nodes must also be in the appropriate server pool partition (non-servers send realm-routed requests to servers).

  • Adjacent Diameter Relays (ADRs) in the target realm

  • ADRs from realms configured in the Realm Routing table as viable adjacent realms, with lowest cost preferred (but not if their cost is INCOMING_ONLY)

  • ADRs in the local realm

During dsc_default routing of a Diameter Request message that does contain a Destination-Host AVP, candidates for the next hop are considered in the following order:

  • the destination host, if it is adjacent

    Note

    If the destination-host is adjacent and available but fails to advertise the appropriate capabilities, then the message is returned immediately with Result-Code DIAMETER_UNABLE_TO_DELIVER.

  • ADRs in the target realm

  • ADRs from realms configured in the Realm Routing table as viable adjacent realms, with lowest cost preferred (but not if their cost is INCOMING_ONLY)

  • ADRs in the local realm

Specifically, the preceding considerations mean that ADRs in the target realm are always considered as a higher priority than entries in the Realm Routing Table.

Additionally, a Request message is never relayed to the same ADN from which the Request was received (loop).  A Request message is never sent to an ADN that is identified in a Route-Record AVP (predictive loop avoidance).

For default routing examples, see Configuring Server Pools, Examples 3 and 4.

  • No labels