Forwarding and routing of the application level (NASREQ/Gx/Gy) messages in Diameter depends on the message type (requests or answers). Requests messages are forwarded or routed based on destination hosts and realms. Forwarding and routing of request messages is based on the Diameter hosts and realms and is dependent on the two tables maintained in each node between the source and destination:
A peer table contains a list of active peers (adjacent Diameter nodes). The peers in the peer table are populated though configuration and are not learned dynamically. The peer table contains only the peer name (no realms).
A realm-based routing table contains mapping of realms and applications to peers. A realm-based routing table is in the SR OS created per Diameter node. Realms in the routing table are learned dynamically from peers from the origin-realm AVP in Capability Exchange Answer (CEA) messages and cannot be statically configured.
The selection of a peer to which a request message is sent can be a two step process. First, if the request message contains the destination-host AVP, the peer table is checked to find out if there is a matching peer available. If so (the destination is directly connected), the request message is forwarded to it, without further checking the routing table for the next hop (this is called forwarding phase). If the matching host is not present in the peer table (the destination is not directly connected), or the destination-host AVP is not present in the request message (in other words, CCR-I), then the diameter routing table is checked for the matching realm. This is referred to as routing phase. Each routable request message must contain the destination realm AVP and the destination realm is a mandatory configuration parameter in an SR node for a Diameter application. However, on the application level, a Gx and Gy session can also learn the destination realm from received application messages. In this case, the learned value overwrites the configured value.
If the Diameter realm table does not contain an entry for the destination realm and the application, the request message is forwarded to the default peer, if one is configured. There can be only one default peer per Diameter node. Unlike a realm routing entry in the realm table, the default peer is application (NASREQ, Gx, Gy) unaware, and it is used as a route of last resort, regardless whether the selected path leads to a server supporting this application.
If the default peer is not configured, messages destined for a realm that is not known in the realm routing table, are dropped.
Application level answer messages do not rely on the routing or forwarding table. They are forwarded in reverse direction of the matching requests in the transactional cache of each traversed Diameter node and the Hop-by-Hop AVP. The Hop-by-Hop AVP is set to a locally unique value by each Diameter node that forwards request messages. This AVP is then used to match request and answer messages in the reverse direction. This allows a Diameter response to follow the same route as the corresponding Diameter request.