In addition to clients and servers, the Diameter protocol introduces relay, proxy, redirect, and translation agents, each of which is
defined in Section 1.2. Diameter agents are useful for several reasons:
o They can distribute administration of systems to a configurable grouping, including the maintenance of security associations.
o They can be used for concentration of requests from a number of co-located or distributed NAS equipment sets to a set of like user
groups.
o They can do value-added processing to the requests or responses.
o They can be used for load balancing.
o A complex network will have multiple authentication sources, they can sort requests and forward towards the correct target.
The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes. Transaction state
implies that upon forwarding a request, its Hop-by-Hop Identifier is saved; the field is replaced with a locally unique identifier, which
is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the
answer. A stateless agent is one that only maintains transaction state.
The Proxy-Info AVP allows stateless agents to add local state to a Diameter request, with the guarantee that the same state will be
present in the answer. However, the protocol's failover procedures require that agents maintain a copy of pending requests.
A stateful agent is one that maintains session state information by keeping track of all authorized active sessions. Each authorized
session is bound to a particular service, and its state is considered active until either the agent is notified otherwise or the session
expires. Each authorized session has an expiration, which is communicated by Diameter servers via the Session-Timeout AVP.
Maintaining session state may be useful in certain applications, such as:
o Protocol translation (e.g., RADIUS <-> Diameter)
o Limiting resources authorized to a particular user
o Per-user or per-transaction auditing
A Diameter agent MAY act in a stateful manner for some requests and be stateless for others. A Diameter implementation MAY act as one
type of agent for some requests and as another type of agent for others.
Relay Agents
Relay agents are Diameter agents that accept requests and route messages to other Diameter nodes based on information found in the
messages (e.g., the value of the Destination-Realm AVP Section 6.6). This routing decision is performed using a list of supported realms
and known peers. This is known as the routing table, as is defined further in Section 2.7.
Relays may, for example, be used to aggregate requests from multiple Network Access Servers (NASes) within a common geographical area
(Point of Presence, POP). The use of relays is advantageous since it eliminates the need for NASes to be configured with the necessary
security information they would otherwise require to communicate with Diameter servers in other realms. Likewise, this reduces the
configuration load on Diameter servers that would otherwise be necessary when NASes are added, changed, or deleted.
Relays modify Diameter messages by inserting and removing routing information, but they do not modify any other portion of a message.
Relays SHOULD NOT maintain session state but MUST maintain transaction state.
+------+ ---------> +------+ ---------> +------+
| | 1. Request | | 2. Request | |
| NAS | | DRL | | HMS |
| | 4. Answer | | 3. Answer | |
+------+ <--------- +------+ <--------- +------+
example.net example.net example.com
Figure 2: Relaying of Diameter messages
The example provided in Figure 2 depicts a request issued from a NAS, which is an access device, for the user bob@example.com. Prior to
issuing the request, the NAS performs a Diameter route lookup, using "example.com" as the key, and determines that the message is to be
relayed to a DRL, which is a Diameter relay. The DRL performs the same route lookup as the NAS, and relays the message to the HMS,
which is example.com's home server. The HMS identifies that the request can be locally supported (via the realm), processes the
authentication and/or authorization request, and replies with an answer, which is routed back to the NAS using saved transaction
state.
Since relays do not perform any application-level processing, they provide relaying services for all Diameter applications; therefore,
they MUST advertise the Relay Application Id.
Proxy Agents
Similar to relays, proxy agents route Diameter messages using the Diameter routing table. However, they differ since they modify
messages to implement policy enforcement. This requires that proxies maintain the state of their downstream peers (e.g., access devices)
to enforce resource usage, provide admission control, and provide provisioning.
Proxies may, for example, be used in call control centers or access ISPs that provide outsourced connections; they can monitor the number
and type of ports in use and make allocation and admission decisions according to their configuration.
Since enforcing policies requires an understanding of the service being provided, proxies MUST only advertise the Diameter applications
they support.
Redirect Agents
Redirect agents are useful in scenarios where the Diameter routing configuration needs to be centralized. An example is a redirect
agent that provides services to all members of a consortium, but does not wish to be burdened with relaying all messages between realms.
This scenario is advantageous since it does not require that the consortium provide routing updates to its members when changes are
made to a member's infrastructure.
Since redirect agents do not relay messages, and only return an answer with the information necessary for Diameter agents to
communicate directly, they do not modify messages. Since redirect agents do not receive answer messages, they cannot maintain session
state.
The example provided in Figure 3 depicts a request issued from the access device, NAS, for the user bob@example.com. The message is
forwarded by the NAS to its relay, DRL, which does not have a routing entry in its Diameter routing table for example.com. The DRL has a
default route configured to DRD, which is a redirect agent that returns a redirect notification to DRL, as well as the HMS' contact
information. Upon receipt of the redirect notification, the DRL establishes a transport connection with the HMS, if one doesn't
already exist, and forwards the request to it.
+------+
| |
| DRD |
| |
+------+
^ |
2. Request | | 3. Redirection
| | Notification
| v
+------+ ---------> +------+ ---------> +------+
| | 1. Request | | 4. Request | |
| NAS | | DRL | | HMS |
| | 6. Answer | | 5. Answer | |
+------+ <--------- +------+ <--------- +------+
example.net example.net example.com
Figure 3: Redirecting a Diameter Message
Since redirect agents do not perform any application-level processing, they provide relaying services for all Diameter
applications; therefore, they MUST advertise the Relay Application ID.
Translation Agents
A translation agent is a device that provides translation between two protocols (e.g., RADIUS<->Diameter, TACACS+<->Diameter). Translation
agents are likely to be used as aggregation servers to communicate with a Diameter infrastructure, while allowing for the embedded
systems to be migrated at a slower pace.
Given that the Diameter protocol introduces the concept of long-lived authorized sessions, translation agents MUST be session stateful and
MUST maintain transaction state.
Translation of messages can only occur if the agent recognizes the application of a particular request; therefore, translation agents
MUST only advertise their locally supported applications.
+------+ ---------> +------+ ---------> +------+
| | RADIUS Request | | Diameter Request | |
| NAS | | TLA | | HMS |
| | RADIUS Answer | | Diameter Answer | |
+------+ <--------- +------+ <--------- +------+
example.net example.net example.com
Figure 4: Translation of RADIUS to Diameter
RFC : 6733
