4.3.1 AVPs to Route Request Messages

The Diameter request message routing relies on both the destination realm and the Application‐Id. While reaching the final destination, the destination host, if present, is used to forward the message to the correct peer node.

4.3.1.4 User‐Name AVP

Unlike RADIUS [3], Diameter does not rely on the User‐Name AVP for request routing purposes. However, a Diameter node may use the User‐Name value to determine the destination realm. The User‐Name AVP is of type UTF8String and contains the subscriber username in a format of Network Access Identifier (NAI) [4,5], which is constructed like an email address. The NAI allows decoration, that is, one can embed a source route in a form of realms into the NAI user‐name portion. See Figure 4.1 for examples of NAI decoration. RFC 5729 [2] updates the Diameter base protocol to explicitly support source routing based on NAI decoration. However, deployment experience has shown that NAI decoration is not a scalable and maintainable solution in larger multi‐vendor and multi‐operator deployments. Populating and maintaining client devices with exact AAA routing information is burdensome, and repairing breakage due to stale source routes is slow since client devices, rather than the routing infrastructure, need to be updated with new routes. Realm‐level redirections [6] or a dynamic DNS‐based discovery [7,8] may be used to circumvent stale realms in the routing network, but there is not much deployment experience using these techniques in the case of source routing of messages.

4.3.2 Routing AVPs

Diameter end‐to‐end communication relies on a number of routing AVPs. Unlike what the category name suggests, these AVPs are not used for the request routing or forwarding, but to record the used route and the state information of the traversed agents.

Note that even relay agents process the routing AVPs. Both relay and proxy agents append the Route‐Record AVP to the request. The AVP contains the DiameterIdentity of the agent. Another point to stress here is that the Route‐Record AVPs are intended to be included only in the request message, whereas the received Proxy‐Info AVPs are echoed in the answer message in the same order from the corresponding request message.

Routing AVPs serve three main purposes:

1. 1. Relay and proxy agents inspect the array of Route‐Record AVPs in the request message in order to detect routing loops.
2. 2. The receiver of the request message can carry out path authorization by verifying that the request message traversed through realms and nodes that are supposed to be on the path. Note the lack of cryptographic origin authentication of the inserted Route‐Record AVPs – it is trivial to spoof or modify the routing AVPs if some intermediate wishes to do. This “feature” is commonly used, for example to realize topology hiding.
3. 3. The Proxy‐Info AVPs serve the purpose of recording and remembering the transaction state of the traversed stateless agents.

      Proxy-Info ::= < AVP Header: 284 >             { Proxy-Host }             { Proxy-State }            * [ AVP ]  

4.4.1 Detecting Duplicated Messages

The End‐to‐End Identifier is used for detecting duplicated messages. The End‐to‐End Identifier is a 32‐bit integer placed in the Diameter message header by the request message originator and is locally unique to the Diameter node that created it. RFC 6733 recommends creating the End‐to‐End Identifier out of two parts: placing the low‐order bits of the current time into the upper 12 bits of the 32‐bit value and using a random value for the lower 20 bits. RFC 6733 does not define “current time”. If “current time” is based on Network Time Protocol (NTP), then the lower 12 bits are parts of the “fraction of second” in any of the NTP on‐wire formats [9]. The End‐to‐End Identifier must remain unique to its creator for at least 4 minutes, even across reboots.

Intermediate Diameter agents (relays, redirects, proxies) are not allowed to modify the value. In the answer direction, the value of the End‐to‐End Identifier is copied to the answer message.

In addition to using a combination of the End‐to‐End Identifier and the Origin‐Host AVP to detect duplicated messages, the message receiver can look for the T flag in the request command flag field. The message originator may set the T flag if it is retrying messages after a transport failure or after a reboot. The 4‐minute minimum value for the End‐to‐End Identifier uniqueness hints to the Diameter server that it should be prepared to “remember” received requests for that period of time. The same also applies for the request originator regarding answer messages.

If a server receives a duplicate Diameter request message, it should reply with the same answer. This requirement does not concern transport‐level identifiers and parameters such as the Hop‐by‐Hop Identifier and routing AVPs (see Section 4.3.1 ). Furthermore, the reception of the duplicate message should not cause any state transition changes in the peer state machine.

4.4.2 Error Codes

The Diameter base protocol has a number of result codes that can be returned as a result of errors during the request message routing/forwarding. All routing and forwarding errors are categorized as protocol errors and fall into the 3xxx class of the status codes. As a reminder, protocol errors use a specific “answer‐message” Command Code Format (CCF) instead of the normal answer message for the request. The “E” error bit is also set in the “answer‐message” command header. The protocol errors are handled on a hop‐by‐hop basis, which means that intermediate Diameter nodes may react to the received answer message. The intermediate node reacting to the error may try to resolve the issue that caused the error before forwarding the “answer‐message” back to the downstream Diameter node.

• DIAMETER_REALM_NOT_SERVED

  (Status code 3003) Used when the realm of the request message is not recognized. This could be due to a lack of the desired realm in the routing table and the lack of a default route, or due to the requested realm being malformed.

• DIAMETER_UNABLE_TO_DELIVER

  (Status code 3002) Used in two situations:

  • There is no Diameter node (either a server or an intermediate agent) in the destination realm that can support the desired application to which the request message belongs.
  • The request message lacks the Destination‐Realm AVP but has the Destination‐Host AVP and the request should be routed. This case is covered in Section 4.3.
• DIAMETER_LOOP_DETECTED

  (Status code 3005) Used in situations where a Diameter node (typically an intermediate agent) notices that it has received a request message it had already forwarded. This implies that the Diameter network has a routing loop somewhere or that the DNS infrastructure has misconfigured zone files.

  The Diameter node finds a loop by inspecting the routing AVPs in the received request message (discussed further in Section 4.3.2). In the case of routing loops, it makes little sense to attempt to re‐route the request message, rather the Diameter node that detected the loop should raise an event to the network administration for further inspection and just return the answer message to the downstream node.

• DIAMETER_REDIRECT_INDICATION

  (Status code 3006) This status code is not a result of a routing error. It is used only in conjunction with redirect agents to redirect the request message and possibly subsequent request messages to a different Diameter node. The response is meant for the adjacent node, which should not forward it on. Recent updates (RFC 7075 [6]) to redirecting behavior added the ability to redirect a whole realm. A new status code was added for this purpose: DIAMETER_REALM_REDIRECT_INDICATION (status code 3011). However, this functionality works only for newly defined applications. Note that although not an error, the “E” bit is still set in the answer message.

• DIAMETER_APPLICATION_UNSUPPORTED

  (Status code 3007) Used in a situation where a Diameter request message reaches a Diameter agent that has no entry for the desired application in its routing table and thus the node cannot route/forward the request message.

4.5.1 Relaying and Proxying Answer Messages

If the answer message arrives at an agent node, the node restores the original value of the Diameter header's Hop‐by‐Hop Identifier field and proxies or relays the answer message. If the last Proxy‐Info AVP in the answer message is targeted to the local Diameter server, the node removes the Proxy‐Info AVP before it forwards the answer message.

If the answer message contains a Result‐Code AVP that indicates failure, the agent or proxy must not modify the Result‐Code AVP, even if the node detected additional, local errors. If the Result‐Code AVP indicates success, but the node wants to indicate an error, it can provide the appropriate error in the Result‐Code AVP in the message destined towards the request message originator but must also include the Error‐Reporting‐Host AVP. The node must also send an STR on behalf of the request message originator towards the Diameter server.

4.7.1 Inter‐Connection Approaches

One of growing and expected to be huge Diameter inter‐connection networks is the IPX network [10] serving cellular operators, and not just 3rd Generation Partnership Project (3GPP)‐based cellular operators. 3GPP made a far‐reaching decision to migrate all Signaling System 7 (SS7) based signaling interfaces with Diameter for the Evolved Packet System (EPS) in 3GPP Release 8. Eventually every Long‐Term Evolution (LTE) enabled cellular operator has to use Diameter, not only to connect with their roaming partners, but also in their internal network.

GSM Association (GSMA) has been defining how inter‐operator roaming works in practice. For EPS and LTE, GSMA produced the LTE Roaming Guidelines [11], which also detail the envisioned and recommended Diameter inter‐operator network architecture. Figure 4.3 illustrates the “reference” inter‐operator Diameter‐based inter‐connection network architecture.

The basic architectural approach is straightforward. Operators have relay agents, i.e., Diameter edge agents (DEA), on their network edges. These relay agents are then connected to internal agents, e.g., 3GPP specific Diameter routing agent (DRA) proxies or “vanilla” Diameter proxies with application‐specific treatment of Diameter messages. Finally, the proxy agents are connected to the Diameter clients and servers. The connectivity within the operator's realm does not need to be a full mesh. However, for failover purposes, the peer connections within an operator realm are nearly a full mesh.

The connectivity between operators (and different realms) is realized using one or a maximum of two intermediate IPX roaming network providers. These IPX providers offer the transit of Diameter signaling traffic. The IPX provider may also deploy a number of intermediate agents, IPX proxies, for instance for value‐added services. The IPX proxies can be relay agents only providing request routing services, or they can also be application‐aware proxies doing application‐level handling and/or manipulation of the transit traffic. Obviously, just deploying relay agents makes it easier to roll out new Diameter applications, since there is no need to upgrade intermediate agents in the IPX network for the new application support.

One of the obvious value‐added services that IPX providers could offer is taking the burden of managing roaming partner connectivity relations and routing information on behalf on the customer operator. In this case, the customer operator only needs to do the following with its preferred IPX provider:

1. 1. Inform the IPX provider with whom and which realms it has a roaming relationship.
2. 2. Inform the IPX provider of any policies for filtering, Diameter level firewalling, correcting known anomalies in implementations, etc.
3. 3. Route all traffic that goes outside its own realm(s) to the IPX provider's IPX proxy.
4. 4. Receive all traffic coming through the IPX provider's IPX proxies.

The above model simplifies greatly the operator's own Diameter routing bookkeeping and policy‐based Diameter message processing at the network edges. The GSMA LTE Roaming Guidelines [11] also recommend using dynamic node discovery [ 7, 2] at the network edges or within IPX. The dynamic discovery eases the management of the next‐hop peer discovery. Section 4.7.2 discusses the pros and cons of the dynamic node discovery in detail.

4.7.2 Dynamic Diameter Node Discovery

The Diameter routing infrastructure may form a complex topology due to the large number of roaming partners involved. The number of partners often exceeds hundreds of companies. The number of peers is therefore even larger, at least double the size, due to the recommendation of maintaining redundant peer connections for improved reliability. As a result, the routing tables for Diameter nodes in such a topology contain a large number of entries.

It is also common for each “foreign realm” to have a dedicated policy for handling and processing of request messages. In large Diameter networks even the internal realm topology can be complex. This results in a vast number of entries in the peer table, and, depending on the internal realm structure, also results in multiple sub‐realm entries in the routing table. As an example, a realm example.com may have a sub‐realm sub.example.com. All these contribute to the complexity and administrative overhead of the Diameter node operations and management. For scalability and managability reasons operators avoid storing comprehensive connectivity information to all internal as well as external nodes in each Diameter node. Default route entries and dynamic Diameter node discovery are useful tools to ease the deployment of large Diameter networks.

Similarly to the management of the DNS infrastructure in many enterprise networks, the internal and external views of the networks are kept separate. There is no need for realm‐external nodes to learn the realm‐internal topology or even Diameter node DiameterIdentities. It is also typically in the network administrators' interest to operate specific ingress into and egress points out of the network for security purposes. It's also not useful for a realm‐internal node to dynamically discover realm‐external nodes since direct peer connections outside realm are not allowed. Obviously the realm‐internal DNS view could be configured so that all realm‐internal DNS‐based dynamic discovery attempts always resolve to the specific agents within the realm.

Therefore, in a typical large Diameter network deployment, the realm edge agents, which can be proxies or relays, are likely the ones initiating the discovery and also being populated into the public DNS to be discovered by realm‐external nodes.

Example deployment architectures are illustrated below. In each architecture it is assumed that the Diameter client inside the originating realm has only a static route to the realm's edge agent. All traffic that exits the client's home realm is directed to the edge agents. Similarly, all traffic coming into the realm always goes through the edge agents. Direct connectivity between realm internal Diameter nodes is rarely if ever allowed in production networks. The reasons are the same as with the IP networking in general: better network control, manageability, and security.

4.7.2.1 Alternative 1

In Figure 4.4, the realm foo.example.com edge agent discovers the realm inter‐connection network's edge agent when it tries to discover the “server B” Diameter node in the realm bar.example.com. Here, the realm bar.example.com DNS administration delegates the publishing of the edge agent DNS information to the inter‐connection network provider.

4.7.2.2 Alternative 2

In Figure 4.5, the realm foo.example.com edge agent discovers the realm bar.example.com edge agent when it tries to discover the “server B” Diameter node in the realm bar.example.com. Here, the realm bar.example.com DNS administration publishes the edge agent DNS information in its own public DNS.

4.7.2.3 Alternative 3

In Figure 4.6, the realm foo.example.com edge agent only has a static “default” route to the inter‐connection network's edge agent. The inter‐connection network agent dynamically discovers the realm bar.example.com edge agent on behalf of the realm foo.example.com edge agent. Here, the realm foo.example.com has an agreement that the inter‐connection network handles its realm‐routing management, and that the bar.example.com DNS administration delegates the publishing of the edge agent DNS information in its own public DNS.

4.8.1 Overload Reports

The OC‐OLR AVP contains a set of fixed, mandatory sub‐AVPs that are the same for all current and future abatement algorithms of the OLR. The optional sub‐AVPs change depending on the supported and used abatement algorithms. Figure 4.9 illustrates the OC‐OLR grouped AVP with sub‐AVPs that are present with the default (must implement) loss abatement algorithm. The fixed AVPs are the OC‐Sequence‐Number and the OC‐Report‐Type AVPs. The OC‐Sequence‐Number AVP carries a monotonically increasing sequence number that DOIC partners (namely the reacting node) use to detect whether or not the contents of the OLR actually update the maintained overload control state (OCS) (covered in Section 4.8.2). The OC‐Report‐Type AVP informs the reacting node whether or not the contents of the OLR concern a specific node (the value of OC‐Report‐Type is HOST_REPORT) or an entire realm (the value of OC‐Report‐Type is REALM_REPORT).

The loss abatement algorithm is specified by the OC‐Reduction‐Percentage and the OC‐Validity‐Duration AVPs. The former indicates the percentage of the traffic that the reacting node is requested to reduce, compared to what it otherwise would send. The values between 0 and 100 are valid. The value 100 means that the reporting node will not process any received messages, and the value 0 means the overload condition is over (somewhat similar meaning as setting the OC‐Validity‐Duration to zero although the explicit ending of the overload condition should be signaled using the OC‐Validity‐Duration AVP). The OC‐Validity‐Duration AVP indicates how long the recently received OLR information is valid. The default value is 30 seconds with a maximum of 86,400 seconds. The value of zero (0) indicates the overload condition concerning this OCS state is over.

4.8.2 Overload Control State

Both reacting and reporting nodes maintain Overload Control State (OCS) for their active overload conditions. At the reacting node the active overload condition is determined from the received OC‐OLR sub‐AVP OC‐Validity‐Period with a non‐zero value. At the reporting node the OCS state is created and maintained for DOIC partners when the overload condition is active.

The OCS states are indexed somewhat differently on the reacting and reporting nodes. A reacting node maintains an OCS entry for each Diameter Application‐Id + DiameterIdentity tuple (Table 4.1). The DiameterIdentity is either a host from the Origin‐Host AVP of the OLR (the OC‐Report‐Type AVP value is HOST_REPORT) or a realm from the Origin‐Realm AVP of the OLR (the OC‐Report‐Type AVP value is REALM_REPORT).

A reporting node maintains an OCS entry for each Diameter Application‐Id + DOIC partner DiameterIdentity + supported abatement algorithm + report type tuple (Table 4.2). The DiameterIdentity is always a host (from the Origin‐Host AVP) of the request message that contained the OC‐Supported‐Features.

The complete information stored in an OCS state entry is an implementation decision. The original goal of the DOIC design was to maintain state only for overload conditions and respective “DOIC partners”. However, it quickly turned out that this was not a realistic goal since the OCS ended up populated with sequence numbers and timers. The sequence numbers are used to check whether newly received OC‐OLR AVPs and timers are used. Still, the maintained state is rather trivial.

4.8.3 Overload Abatement Considerations

Diameter did not have a mechanism to prioritize arbitrary messages over each other in a standardized and a generic manner until Diameter Routing Message Priority (DRMP) [16] was specified. Among several use cases enumerated in RFC 7944, the prioritization of messages when DOIC‐originated overload abatement takes place is a prominent one. The DRMP instructs the Diameter nodes, for example, to make an educated throttling decision between different Diameter messages or a resource allocation.

The DRMP uses a single DRMP AVP in a Diameter message to indicate the relative priority of the message compared to other messages seen by a Diameter node. There are 16 priorities. It is important that priorities are assigned and managed in a coordinated manner within an administrative domain and even between domains/realms. Otherwise, the priorities can be mishandled or misinterpreted, or there could be too many messages with the same priority to realize any benefit of prioritization among messages.