Realms Overview

A realm is an internet domain whose Fully-Qualified Domain Names (FQDNs) typically all share a domain designation. For example, example.com could be a Realm name, and the addressable hosts in the Realm would have names like host1.example.com, host2.subdomain1.example.com, and so on.

In the diameter signaling space, an operator creates a realm name, then assigns FQDNs to all of the computers that transact diameter traffic. The number of computers in the Diameter Realm depends on the number and type of diameter services the operator intends to support, as well as the expected volume of diameter traffic. Typically, load-sharing and redundancy are major factors governing the internal organization of a Diameter Realm.

The dynamic discovery of remote hosts is always undertaken within a single realm. Many realms can be discovered dynamically, but the discovery of one realm is a process independent of that for all other realms that are to be discovered.

Configuring Routing Information

Diameter signaling routers establish connections to Diameter Peers and route Diameter traffic to those Peers only after all of the necessary routing configuration changes are manually entered into the DSR. Specific configuration changes are user-initiated, either through the GUI or by importing configuration changes by way of Bulk Import/Export (BIE).See the Bulk Import and Export information in Diameter Common User's Guide. These configuration changes are static changes because once entered; they remain in place until you take action to modify or delete them.

DPD implies dynamic configuration changes. Instead of user-specified routing configuration changes, the diameter signaling router learns about remote hosts and dynamically makes the necessary routing configuration changes. The information discovered about remote hosts residing in any Diameter Realm has a defined lifetime, a Time To Live (TTL). Therefore, realm-specific routing configuration made dynamically to a diameter signaling router also has a defined lifetime, and under certain circumstances, this dynamic routing configuration is automatically destroyed, and the Realm can be re-discovered; all of this occurs without user interaction. Dynamic describes these diameter signaling router-initiated routing configuration changes that are created and destroyed over time.

You should understand the difference between static and dynamic configuration with respect to DPD.

• Static configuration is necessary to set up and execute DPD
• Dynamic configuration results from a Diameter Realm having been successfully discovered

DPD setup and execution requires static configuration. The name of the Realm to be discovered, the DNS server(s) that are used to get information about that Realm, and the necessary additional discovery attributes are all statically configured by a user to establish the input parameters governing the discovery of a particular Diameter Realm. Assuming the discovery algorithm is successful, at least one Peer Node and the Connection(s), CEX Configuration Set(s), Route Group(s), and Route List(s) required to properly route Diameter traffic to the Peer Node(s) are dynamically added to the routing configuration.

Creating Discoverable Realms

Any Diameter Realm that is to be discovered must first be made discoverable by a DNS administrator who has knowledge of the hosts within the Realm and the services they provide. The Realm's DNS administrator must set up a DNS zone file that contains all of the information about the Realm that the administrator wants to make public. The DNS zone file resides on any of the Realm's DNS servers that are expected to be queried about Realm services.

The routing application discovers the Realm by sending questions (DNS requests) to the Realm's DNS server or servers. Depending on the answers, the routing application dynamically updates the configuration. These answers are in the form of DNS Resource Records (RRs).

DPD relies on three DNS Resource Record types to obtain the information needed to dynamically configure a Realm. The three types are, in the hierarchical order in which they are requested:

• Name Authority Pointer (NAPTR) Record - is a general-purpose DNS record that has uses beyond Diameter
• Service Locator (SRV) Record - is another general-purpose DNS record that is used well beyond Diameter signaling
• Address (A or AAAA) Record - is a DNS containing an IP address that can be used to reach the host

Diameter Application IDs

Diameter Application IDs play a major role in the discovery of remote hosts. Diameter messages contain information specific to a particular telecommunications signaling function, and these are identified by Application ID. Nodes within a Diameter network are often set up to address certain signaling functions, but not others. So the Diameter Application ID(s) that are supported by a remote host are an important characteristic of that remote host. When configuring a Realm for discovery, you can specify up to ten Application IDs.

Supported Protocols

Realm discovery depends on information from remote hosts within the Realm. The routing application must discover what protocols can be used while communication with the host. Also important is the list of locally-supported protocols, which are protocols that are supported by the routing application, and thus could use when communicating with a remote host.

The full set of transport protocols that can be used when establishing Diameter connections is:

• TCP
• SCTP
• TLS
• DTLS

DNS Discovery

Realm discovery has two phases:

• DNS information for the Realm is retrieved and processed
  • A NAPTR record is selected
  • A single Diameter S-NAPTR record is selected for attempted resolution
  • If a Realm's DNS information does not include any NAPTR records, the DSR may still be able to learn something useful about the realm through the direct SRV query fallback mechanism.
• The routing application adds the needed configuration objects, based on the prioritized list of remote hosts, to enable proper routing of Diameter traffic to the remote hosts in the Realm. This only occurs after the routing application concludes that sufficient DNS information exists to route Diameter traffic to at least one remote host within the Realm. Converting discovered DNS information into a routing configuration can be a complex undertaking, and it depends entirely on the discovered remote hosts, how many IP addresses each host exposes, the protocol(s) each host supports, and the Application ID(s) each host supports. See Discovery Attributes, Diameter Route Lists, and Diameter Route Groups.

Realm Expiration

DNS is designed such that every piece of DNS information has a defined lifetime. After this time duration passes, the information is considered expired. In many cases, a particular piece of DNS information might not change at all over very long periods of time, but in some cases, the information can change, and users of that information are responsible for retrieving and acting on the updated values.

There are potentially dozens of individual DNS resource records that are processed when discovering a Realm, and each of those RRs has its own TTL value. The routing application distills those TTLs down to a single Realm Expiration date/time by taking the nearest-term TTL value from all of the DNS RRs it processes during the Realm's discovery. From the routing application perspective, a Realm expires after enough time passes that the first relevant DNS record expires. After one piece of information becomes old, the entire Realm's discovered data is considered old. You can set or suppress the pending expiration alarms.

DPD implements a couple of user-configurable pending expiration alarms, in order to notify users that a Realm is approaching is expiration. The user configures each of these two alarms. The Realm Expiration Minor Alarm Set Time, in hours, indicates how many hours before Realm expiration a minor alarm should be raised. This value can be as large as 168 hours (one week) before Realm expiration. The Realm Expiration Major Alarm Set Time, also in hours, indicates how many hours before Realm expiration a major alarm should be raised. This value can be as large as 167 hours, and must always be at least one hour shorter than the Minor Alarm Set Time, if the Minor Alarm Set Time exists.