Diameter Routing Profile (3.0)
The Diameter Routing profile enables you to define the Peer Table and the Realm Routing Table properties for the Diameter Stack agent. You can also enable throttling, which allows you to prevent more than the specified number of UDRs per second to be forwarded. The throttling functionality uses the token bucket algorithm. The Diameter Routing profile is loaded when you start a workflow that depends on it. Changes to the profile become effective when you restart the workflow. It is also possible to make changes effective while a workflow is running. For more information about this, see the section below, To Dynamically Update the Diameter Routing Profile. To define a Diameter Routing profile, click on the New Configuration button in the upper left part of the A Diameter Stack agent that uses the Diameter Routing profile maintains transport connections with all the hosts that are defined in the Peer table list. Connections and handshakes of hosts that are not in this list are rejected with the appropriate protocol errors. Note that Hostname The hostname (case sensitive) or IP address of a Diameter Identity For example: ggsn01.vendor.com Note! The content of the Origin-Host AVP in the answer commands from the specified peer should be identical to this value. If the values do not match, the MIM values published by the Diameter Stack agent that contain counters are not updated correctly. This may occur, for instance, if you have specified a hostname in this text box but the Origin-Host AVP contains an IP address. It is recommended that you consistently use either IP addresses or hostnames when configuring the Diameter profiles and agents. Port The port to connect to when initiating transport connections with a peer. For example: 3868. Protocol The transport protocol to use when initiating a peer connection. The following settings are available: When TCP/TLS is selected, the Diameter Stack requires a secure connection from this host. You configure this feature by setting the Keystore Path and the Keystore Password in the Diameter Stack agent. For further information, see the section, Advanced tab, in Diameter Stack Agent Configuration(3.0). Note! SCTP must be installed on every EC host that uses the SCTP protocol. For installation instructions, see your operating system documentation. If throttling has been enabled for the peer, this field will show the configured threshold for when transmissions of request UDRs should be throttled. Throttled UDRs will be routed back into the workflow. For example: 1.000 (which means a maximum of 1.000 UDRs/second will be transmitted). Note! Throttling will determine if and how the workflow will limit the number of requests and UDRs sent out from the workflow. For information regarding how to configure the Diameter agent to reject incoming requests or UDRs to the workflow, see the section, Diameter Too Busy in . When unknown peers try to connect to the Diameter Stack, you can configure how such connection attempts are to be handled. You can choose from three options from the drop box: In the Diameter Routing Profile , click on the Add button beneath the Peer Table . Enter the host name and port for the host in the Hostname and Port fields. Select protocol in the Protocol drop-down-list. If you want to enable throttling for the peer, select the Enable Throttling check box, and then enter the maximum number of request UDRs per second you want the Diameter Stack agent to transmit to the peer in the Throughput Threshold (UDR/s) field. Note! Ensure that you handle the throttled UDRs in your APL code in the workflow in order to not loose any UDRs. Click on the Add button and the host will be added in the Peer Table , and then click on the Close button to close the dialog when you are finished adding hosts. Realm-based routing is performed when the Destination-Host AVP is not set in a Diameter message. All realm-based routing is performed based on lookups in the Realm Routing Table. When the lookup matches more than one set of keys, the first result from the lookup will be used for routing. For this reason, the order of the rows in the Realm Routing Table must be considered. You can control the order of the rows by using the arrow buttons. Clicking on the table columns to change the displayed sort order does not have any effect on the actual order of the rows in the Realm Routing Table. Diameter requests are routed to peers in the realms in accordance with the selected Realm Routing Strategy. The following settings are available: The table below contains examples of how Diameter requests are routed to the peers of a realm, with the Round Robin strategy, depending on the peer connection state: Peer 1 Status Diameter requests are not routed to peers that are specified in the Select this check box when you want to use DNS queries (dynamic peer discovery) to find peer hosts in realms. The queried peer host information is buffered by the Diameter Stack agent according to the TTL (time to live) parameter in the DNS records. When the TTL has expired, the agent will attempt to refresh the information. If the refresh fails, the buffered information will be deleted. When Enable Dynamic Peer Discovery is selected, DNS queries are performed at: Note! To make changes to this setting effective, you must restart the workflow(s). If the DNS service is unavailable (server available but service down) when starting the workflow(s), the system log entry will indicate errors in realm lookups. In order to resume lookups in DNS, you need to dynamically update the routing table in the Diameter Stack agent when the DNS is available again. For information about how to dynamically update the routing table, see the section below, To Dynamically Update the Diameter routing profile. For information about how to select DNS servers, see the section below, DNS Tab. Realm The realm name (case sensitive) . Realm is used as primary key in the routing table lookup. If left empty, all the destination realms are valid for this route. For example: address.com. Applications The applications that this route serves. This entry is a used as a secondary key field in the routing table lookup. If left empty all the applications are valid for this route. For example: 3,4. Hostnames A list of all the peer hosts in the realm. The hostnames must be selected from the Peer Table. When Node Discovery is set to Dynamic, you should leave this field empty. The method of finding the peer hosts in the realm: Note! Entries in the Realm Routing Table that have the Dynamic setting are ignored (not matched), unless Enable Dynamic Peer Discovery is selected. When a DNS server resolves a realm to peer hosts, it may return fully-qualified DNS domain names with a dot at the end. These trailing dots are removed by the Diameter Stack agent. Enter the realm name in the Realm text box. If the realm serves specific applications, click on the Add button beneath the Applications list box and specify the Application Id. Repeat this step for each application. You should only perform this step if Peer Discovery is set to Static and the peer hosts are to be specified in the Realm Routing Table. Click on the Add button beneath the Hostname list box and select a host from the drop-down list. Repeat this step for each host in the realm. If you specified the peer hosts of the realm in the previous step, select Static from Peer Discovery. If you want to use dynamic peer discovery instead, select Dynamic from this drop-down list. Click on the Add button and the realm will be added in the Realm Routing Table, and then click on the Close button to close the dialog when you are finished adding realms. You can use the DNS tab to configure the DNS settings used for looking up peer hosts of realms. For information about how configure your DNS for dynamic peer discovery, see the Diameter Base Protocol (RFC 6733). Note! To make changes to this tab effective, you must restart the workflow(s). Avoid configuring the same peer host in both DNS and the Peer Table, this may cause duplicate instances of Diameter peers. The host- and realm names in the Diameter Stack agent are case sensitive. Retry Interval Time (ms) Enter the time (in milliseconds) that Diameter Stack agent must wait before retrying a failed DNS connection. If the DNS Servers list is empty, the Diameter Stack agent will use the file You can refresh the routing table of a Diameter Stack agent while a workflow is running. When the agent refreshes the routing table, it reads the updated Peer Table, Realm Routing Table and Realm Routing Strategy from the selected Diameter Routing Profile. The routing table can be refreshed from the Workflow Monitor or from the Command Line Tool. In the Workflow Monitor, double-click the Diameter Stack agent to open the Workflow Status Agent configuration. Run the following commands: Example - Update Routing Table Example - Reset Round Robin Selection You can use the Diameter Stack MIM value Realm Routing Table to read the realm routing table of a Diameter Stack Agent from APL. The MIM value is of the map<string,map<string, list<string>>> type and is defined as a global MIM context type. The string values in the outer map contain the realm names (primary key). The string values of the inner map contain the applications (secondary key). The lists in the map contain the hostnames of the peers in the realm. The string values in the outer map contain the realm names (primary key). The string values of the inner map contain the applications (secondary key). The lists in the map contain the hostnames of the peers in the realm. Asterisks (*) are used in the strings to denote unspecified realm name or unspecified applications. The values in the inner and outer maps are sorted exactly as the Realm Routing Table of the selected Diameter routing profile. Example Realm Routing Table MIM Assume that the following realm routing table is defined for a Diameter Stack agent: Realm The following APL code can be used to read the table: Note! The spaces between the angle brackets in the example above are required. If missing, the APL will fail to compile. Example debug output: For more information about MIM values published by the Diameter Stack agent, see Diameter Stack Agent Input/Output Data and MIM(3.0).Routing Tab
Peer Table
Item Description Throughput Threshold On Connection from Unknown Peer To Add a Host
Realm Routing Table
Item Description Realm Routing Strategy Peer 2 Status Peer 3 Status Route Distribution OKAY
OKAY
OKAY
Peer 1, Peer 2, or Peer 3
OKAY
OKAY
SUSPECT
Peer 1 or Peer 2
REOPEN
SUSPECT
OKAY
Peer 3
DOWN
DOWN
SUSPECT
Peer 3
DOWN
REOPEN
DOWN
Peer 2
DOWN
DOWN
DOWN
None
ExcludePeers
field of a RequestCycle
UDR. For more information about the RequestCycle
UDR, see the section, RequestCycleUDR in The Diameter Base Protocol(3.0).Enable Dynamic Peer Discovery Node Discovery To Add a Realm
DNS Tab
Max Number Of Retries Enter the maximum number of times that Diameter Stack agent should retry to connect to the servers in the DNS Servers list before it gives up. When the agent has attempted to connect to all servers (after an initial failed attempt), it counts as retry. DNS Servers Enter the hostname or IP address of the DNS servers that can be queried. The topmost available server will be used. /etc/resolv.conf
on the Execution Context host to select the DNS server. For information about how to configure resolv.conf, see your operating system documentation. To Dynamically Update the Diameter Routing Profile
The setting Enable Dynamic Peer Discovery in the Routing tab and the settings in the DNS tab are not read from the Diameter Routing table at refresh. To make changes to these settings effective, you must restart the workflow(s).
In the Command tab, select the Update Routing Table button to refresh the routing table.Command Line Tool
mzcli wfcommand <workflow name> <Diameter Stack agent name>
mzcli wfcommand Default.my_workflow Stack1
When Round Robin is the selected Realm Routing Strategy, you can reset the selection cycle by running the following command:mzcli wfcommand <workflow name> <Diameter Stack agent name> clearstrategystate
mzcli wfcommand Default.my_workflow Stack1 clearstrategystate
To Read the Realm Routing Table in APL
Aplications Peers dr
peer1, peer2
100,200 peer3, peer4 peer5, peer6 initialize {
//Note the space between the angle brackets!
map<string, map<string, list<string> > > realmTable = (map<string, map<string, list<string> > >) mimGet("Stack1", "Realm Routing Table");
//Check the size of the table
if (mapSize(realmTable) != 2)
abort("Realm table incorrect size");
//Check that realms are included
if (mapKeys(realmTable) != listCreate(string, "dr", "*"))
abort("Wrong realms");
//Get the inner map for realm name "dr"
map<string, list<string> > drMap = mapGet(realmTable, "dr");
//Get the inner map for realm name "*" (unspecified realm)
map<string, list<string> > starMap = mapGet(realmTable, "*");
//Any Application Id
debug(mapGet(drMap, "*"));
//Application Id 100
debug(mapGet(starMap, "100"));
//Any Application Id
debug(mapGet(starMap, "*"));
}
12:11:40: [peer1, peer2]
12:11:40: [peer3, peer4]
12:11:40: [peer5, peer6]