Traffix-pedia: Diameter for Techies

Traffix-pedia: Diameter Protocol for Techies

The Diameter protocol was derived from the Remote Authentication Dial-In User Service (RADIUS) protocol with many improvements in different aspects. Although initially defined by IETF; Diameter was embraced by many standard bodies such as the 3GPP and ETSI standard bodies and adopted as the foundation for all Authentication, Authorization, and Accounting (AAA) functionalities in their defined next-generation networks.

With the emergence of new technologies and applications , the requirements for Authentication and Authorization have greatly increased, and access control mechanisms became more complex than ever. The existing RADIUS protocol was insufficient to cope with these new AAA requirements. In NGN, IP-Multimedia Sub-systems (IMS) and later in Long Term Evolution (LTE) based networks the AAA realm have grown to encompass new needs in its borders, such as policy control, dynamic rules, QoS, bandwidth allocation and new charging requirements. All these new requirements coupled with demanding Real-Time transaction essentials derived from the introduction of new advanced multimedia services are handled using the Diameter protocol.

Therefore Diameter protocol was adopted to meet those new requirements and has become fundamental cornerstone in the building and success of 4G networks such as LTE.

Diameter Nodes and Agents

In LTE Diameter is used for the signaling across all core network elements and is crucial to billing, traffic and subscriber management, subscriber authentication, roaming, and mobility management. Diameter is designed as a Peer to Peer protocol, and every host who implements the Diameter protocol can act as a client, server or agent depending on network deployment. So the term Diameter node is used to refer to a Diameter client, a Diameter server, or a Diameter agent. The node called Diameter agent is clearly defined in the Diameter base protocol specification (RFC 3588).

Diameter agents can perform numerous tasks such as load balancing, centralizing request dispatching, and value-based pre-processing of messages.

Diameter agents must maintain transaction state for failover purposes. Upon forwarding request, its Hop by Hop identifier is saved and replaced with new identifier value. When matching response arrives Hop by Hop identifier is restored to the value before the switch. When the matching answer arrives request state is released.

Diameter agents might be Stateless (only maintains transaction state) or Stateful (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 either until it is notified otherwise or by expiration) Maintaining state by Diameter agents can be useful in some scenarios, like protocol translation (e.g. RADIUS to Diameter), limiting resources authorized to a particular user or per user or transaction auditing.

IETF Diameter specifications clearly define four kinds of Diameter agents:

1. Diameter Relay Agents

Diameter Relay agents are used to forward messages to the appropriate hosts, depending on the information contained in the message, for instance destination realm. Routing decisions are performed using of list of supported realms and known peers. This is known as the Realm Routing Table. Relay agents may be used to combine requests from multiple Network Access Servers (NAS) from one region. It allows creating NAS without knowledge of the exact network configuration they should contain. Moreover Relay agents simplify Diameter server configuration, which would change every time NAS would be added, deleted or modified, simplifying network management and reducing required configuration alternations.

The Relay agent is advantageous because it can combine requests from different realms or regions to a specific realm, which eliminates the required configurations of NAS for every Diameter server change.

2. Diameter Proxy Agents

Diameter Proxy agents just like Relay agents route Diameter messages using the Diameter Routing Table, but unlike a Relay agent, a Proxy agent can modify the message content and, therefore, provide value-added services, enforce rules and policy on different messages, or perform administrative tasks for a specific realm.

Because of this Proxy agents are required to maintain state of their downlink peers (e.g. access devices). Proxy agents can enforce rules, control resource usage and provide admission control and provisioning.

Proxy agents need to maintain information on session and transaction state.

3. Diameter Redirect Agents

Diameter Redirect agents act as a centralized configuration repository for other Diameter nodes. When Redirect agent receives a Diameter message, it checks its routing table, and returns a response message along with redirection information to its original sender. This ability is very useful for other Diameter nodes because they won’t need to keep a list of routing entries locally and can look up a Redirect agent when needed.

Redirect agents don’t maintain session nor transaction state.

4. Translation Agents

Diameter Translation agents convert messages from one AAA protocol to another. The Translation agent is extremely important when migrating to Diameter or interconnecting different domain using different AAA protocols. The Translation agent could provide the backward compatibility for a smooth network migration. For example possible protocol translations are Diameter to RADIUS or Diameter to LDAP or WebsServices. 

Translation agents must be session Stateful and must maintain transaction state.