Diameter Peer Nodes

A Peer Node can represent either a Diameter Node or a RADIUS Node. When representing a Diameter Node, a Peer Node is an external Diameter client, server, or agent with which the application establishes direct transport connections. Qhwn representing a RADIUS Node, a Peer Node may be a single system or a cluster of systems and might have one or more transport connections.

You can perform these tasks on an Active System OAM (SOAM).

A Transaction ID is a unique end-to-end transaction ID created by DRL for each unique transaction received from an ingress Peer Node. This value is created when Peer Node routing commences and is stored in the Pending Transaction Record (PTR) for the lifetime of this end-to-end transaction. Its value does not change when the Request message is rerouted. You can apply transaction configuration sets that allow independent grouping of transaction configuration rules for varying use case needs.

If a Route List to route a Request message via a PRT search cannot be located and the message is not addressed to a Peer Node (via the Destination-Host AVP), an attempt is made to perform Implicit Realm Routing. Using the Destination-Realm AVP and Application-Id in the Request message, a matching entry in the system-wide Realm Route Table is sought. This identifies a Route List to use for routing the message. If a match is found, the Route List assigned to the (Realm, Application-Id) is used for routing the message. If a match is not found, transaction routing is abandoned.

Diameter Request messages can only be forwarded to Peer Nodes that support the Application to which the message is addressed (identified by the Application-ID field in the message). The List of Common Application IDs is acquired for elements that contain that connection (for example, Peer Nodes, Route Groups, and Route Lists). When a Connection is no longer a candidate for routing Request messages, the List of Common Application IDs for each Route List, Route Group, and Peer Node which contain this Connection are updated to reflect the potential loss of Application IDs supported by that Connection.

After it is configured, a Peer Node can be:

• Assigned to connections for use in Diameter routing
• Assigned to Route Groups that manage the distribution of traffic to and among Peer Nodes

On the Diameter > Configuration > Peer Nodes page, you can perform the following actions:

• Filter the list of Peer Nodes to display only the desired Peer Nodes.
• Sort the list by a column in ascending or descending order by clicking the column heading (except IP Addresses). The default order is by Peer Node Name in ascending ASCII order.
• Click an entry that is shown in blue in a column to open the Diameter > Configuration > <component> [Filtered] page and display that entry only.
• Click Insert.

  On the Diameter > Configuration > Peer Nodes [Insert] page, you can add a new Peer Node.

  The Diameter > Configuration > Peer Nodes [Insert] does not open if the maximum number of Peer Nodes per Network Element (16000) already exists in the system.

• Select a Peer Node in the list and click Edit.

  On the Diameter > Configuration > Peer Notes [Edit] page, you can edit the selected Peer Node.

• Select a Peer Node in the list and click Delete. You can delete the selected Peer Node.

Redirect Notification Processing and Message Redirection

An egress Peer Node, acting as a Redirect Agent, can send an answer with a redirect notification. The result code in the answer can indicate either diameter redirect or diameter realm redirect. Upon receiving the redirect notification, the configuration dictates how to reroute the request (Redirected Request). If redirect notification is enabled, the redirected request can be started from ART or PRT.

Redirect notifications are processed as follows:

• Redirect notifications with no Redirect-Host-Usage AVP are processed.
• Redirect notifications with Redirect-Host-Usage equal to do not cache are processed.
• Redirect notifications with Redirect-Host-Usage not equal to do not cache are forwarded to the downstream peer.

The following original transaction attributes are carried with the redirected transaction:

• Copy of the original Request message received
• Connection ID associated with the ingress Request message
• Information about whether the transaction was initiated by a Peer Node or an application
• Routing information received from the application
• The number of times the Request message has been forwarded/rerouted and the Redirected Peer List
• The Message Copy related flag, route list ID, or config set ID
• TTR Event