2.6.1 Peer Routing Table
A peer route table is a set of prioritized peer routing rules that define routing to peer nodes based on message content. Peer routing rules are prioritized lists of user-configured rules that define where to route a message to upstream peer nodes. Routing is based on message content matching a peer routing rule’s conditions. There are six peer routing rule parameters:
- Destination-Realm
- Destination-Host
- Application-ID
- Command-Code
- Origin-Realm
- Origin-Host
When a diameter message matches the condition of peer routing rules then the action specified for the rule occurs. If you choose to route the diameter message to a peer node, the message is sent to a peer node in the selected route list based on the route group priority and peer node configured capacity settings. If you choose to send an answer, then the message is not routed and the specified diameter answer code is returned to the sender.
Peer routing rules are assigned a priority in relation to other peer routing rules. A message is handled based on the highest priority routing rule that it matches. The lower the number a peer routing rule is assigned the higher priority it has. (1 is the highest priority and 1000 is the lowest priority.)
If a message does not match any of the peer routing rules and the destination-host parameter contains a Fully Qualified Domain Name (FQDN) matching a peer node, then the message is directly routed to that peer node if it has an available connection. If there is not an available connection, the message is routed using the alternate implicit route configured for the peer node.
PRT Partitioning
Routing rules can be prioritized (1 – 1000) for cases where an inbound Diameter request may match multiple user-defined routing rules. The DSR supports up to 500 PRTs on the DSR. Any one of the PRTs can be optionally associated with either the (ingress) peer or Ingress Peer Node selected Transaction Configuration Group or Default Transaction Configuration Group. A local application can also specify the PRT that needs to be used for routing a request. Each of these PRTs have no more than 1000 rules and the total number of rules across all PRTs cannot exceed 50,000. A system wide PRT is also present by default and is used if a PRT has not been assigned.
The PRT can be associated with the ingress peer node which can be useful to separate routing tables for example for LTE domain, IMS domain, or routing partners.
Rule Action defines the action to perform when a routing rule is invoked. Actions supported are:
- Route to Peer - use Route List Table.
- Send Answer Response - an Answer response is sent with a configurable Result-Code and no further message processing occurs.
- Abandon With No Answer - discard the message and no Answer is sent to the originating Peer Node.
Forward to Peer Route Table - forward the message to the specified Peer Route Table.
The table below is used to determine the PRT instance to be used:
Table 2-5 PRT Precedence
| PRT Used | PRT specified by local app (if supported) | PRT associated with Ingress Peer Node Selected Transaction Configuration Group | PRT associated with an Ingress Peer | PRT associated with Default Transaction Configuration Group | Default PRT |
|---|---|---|---|---|---|
| Default PRT | No | No | No | No | Yes |
| Default Transaction Configuration Group PRT | No | No | No | Yes | Yes |
| Peer PRT | No | No | Yes | Don’t Care | Yes |
| PRT associated with Ingress Peer Node Selected Transaction Configuration Group | No | Yes | Don’t Care | Don’t Care | Yes |
| Local App PRT | Yes | Don’t Care | Don’t Care | Yes | Yes |