Diameter Overview

Diameter protocol is a corner stone of all-IP telco networks. There are two main signalling protocols in IMS. Session Initiation Protocol (SIP) and right, the Diameter.

The main purpose of the SIP protocol is to establish a real-time multimedia session. This session goes end-to-end between the phones (or other devices) of the originator and recipient.

Internally – within the operator’s network – during the session establishment, we have to trigger many network functions. That can be because of the authentication of users, charging, allocation of resources, application of services, etc. 3GPP mandates for this purpose the Diameter protocol. The Diameter is used by both ePC and IMS for requesting/triggering additional information. These requests are sent in a form of transactions. During one IMS session setup or one IMS registration procedure we have to perform several Diameter transactions.

Diameter triggering during VoLTE session setup

 

Before we can jump in 3GPP networks we should firstly describe the Diameter protocol itself. Firstly we should point out that in contrast to SIP, the Diameter has two logical layers.  A so-called base protocol and Applications part. The base protocol does implement functions related to reliable transport, routing and session management. The diameter Applications determine the service logic.

Diameter base protocol and Applications

Diameter Base Protocol

Diameter base protocol is a peer-to-peer protocol defined in RFC 6733, which provides the following facilities:

• Session routing, relaying, proxying, and redirecting through a diameter server hierarchy
• Session management, Capabilities negotiation
• Error notification
• Ability to exchange messages and deliver Attribute-Value Pairs (AVPs)
• Extensibility through addition of new applications, commands, and AVPs

The Diameter base protocol satisfies the minimum requirements for a AAA (authentication, authorization and accounting) protocol, as specified by RFC2989.

In a nutshell, Diameter is easy to implement (based on AVP syntax) and flexible as it allows vendors to create new applications via addition of a new Command Code or an Application Id (RFC 7423, RFC5516). On the other hand the protocol is quite robust, relies on TCP or SCTP (the preferred choice) on the transport layer, supports loadsharing and primary/secondary links. Diameter is also secure enough for usage in the telco environment.

Diameter Communication

Although the protocol is from the service level point of view peer-to-peer, diameter has three different types of network nodes: clients, servers and agents. Clients are network elements that support Diameter client applications as well as the base protocol. They are usually the network elements triggering the service. A Diameter agent provides either relay, proxy, redirect or translation services. A Diameter server handles the authentication, accounting or authorization requests for a particular domain, or realm.

Diameter components

Diameter session consists of message exchanges, where always one peer firstly sends a Request and the other responds with an Answer.

Diameter Request/Answer

 

Diameter Message Format

As mentioned, diameter messages have a very straightforward structure, which allows extensions of application part.

Diameter message structure

Command Code

Every diameter exchange – a Request/Response pair has its own code. E.g. Server-Assignment-Request/Server-Assignment-Answer pair has the Command Code 301 Server-Assignment. The request or answer is identified via the ’R’ bit in the Command Flags field of the header. The values 256-16777213 are for permanent, standard commands allocated by IANA. The list of commands is available at http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

The Command Code defines what action should be taken by a diameter peer and what particular AVPs should be in the message.

Application ID

The Application ID determines the service logic, that means message flow and the way how to interpret the data. One Command Code can be used by more applications (e.g. Multimedia-Auth 303 is used by 3GPP Cx and by 3GPP SWx). Diameter agents typically implement only a few application ids (for example S-CSCF implements only Cx, Rf applications).

The list of Application IDs is again available at http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

Application IDs along with the Command Codes are very useful during the trace analysis.

Diameter trace

Attribute-Value Pairs (AVPs)

Instead of headers in SIP, we use AVPs to carry the application data in Diameter. This approach is developer-friendly, which means it is easy to write protocol decoders/encoders. It is also easy to analyse the data in Wireshark. Just remember that the AVPs can be nested.

Multimedia-Auth-Answer – nested AVPs

Basic Message Flow

The diameter session between two peers starts by the establishment of a transport connection (over SCTP or TCP). For higher security TLS or IPSec can be used.

The connection between diameter peers is established using their valid DiameterIdentity. An initiator have to know the peer’s DiameterIdentity.

The initiator sends a Capabilities-Exchange-Request (CER) to its peer. The other side responds with a Capabilities-Exchange-Answer (CEA). The session is identified by the Session-ID AVP.

Now peers can exchange other diameter messages. In case of an idle link a Device-Watchdog-Request (DWR) is sent and the other peer must respond with Device-Watchdog-Answer.

Either side can close the session by sending a Disconnect-Peer-Request (DPR) which is responded by Disconnect-Peer-Answer (DPA). (The DPR/DPA can be left-out in case the Auth-Session-State is set to NO_STATE_MAINTAINED.)

Diameter Session

 

---

For those who want to learn more

Duplicates Detection

Multiple identical requests or answers be received by diameter network elements because of network issues, restart of application and failover situation. The End-to-End Identifier field in the Diameter header along with the Origin-Host AVP identifies the duplicate messages.

The End-to-End Identifier is inserted by senders of a request as a unique identifier on each message. As per RFC 6733 it remains locally unique for a period of at least 4 minutes, even across reboots.

T(Potentially retransmitted message) is a flag set after a link failover procedure, to help with the removal of duplicate requests. The flag is set in request messages only.

What is Online Charging duplicate?
For Online Charging is the duplicity check is based on the unique combination of the Session-Id and CC-Request-Number AVP pairs. For more details see the TS 32.299.

How to detect duplicates (on OCS)?
The detection of a duplicate request (on OCS) is required. The Diameter server is responsible for duplicate detection and it can choose whether or not to make use of the T flag. However it is recommend in order to optimize duplicate detection. As we want to speed up and simplify as much as possible the duplicate detection, the all-against-all record checking should be avoided and just those records marked as potential duplicates need to be checked against other received requests (in real-time ). To be able to detect duplicates received out of order (meaning the original message arrives later than the resubmitted message with the T flag on), the Diameter server should use backward and forward time windows when performing duplicate checking for the T-flag-marked requests.
 
Reasonable window size would be <-4 mins, +4 mins>, as outside this range the end-to-end identifier might not be unique. Meaning if we receive a message with T flag on, we have to keep it for 4 minutes (in case the original message arrives later).
 
How to handle duplicates?
Duplicate requests should trigger the same answer to be sent, and they not allowed to change any state that was set when the original request. Duplicate answer messages that are to be locally consumed should be silently discarded.

If a duplicate is detected for CC-Request-Type on OCS
INIT – New session is not created (as it was already created).
UPDATE – No action required (state for a particular subscriber is already modified).
TERMINATE – The session is to be deleted with the end of the time window (already marked as to-be-deleted).   

---

Connection Management

Each Diameter node should always establish connection with at least two peers per realm, the primary and secondary peers. In case there are more primary (or secondary) peers connected, we loadballance the traffic.

Diameter links

Note, that one peer can be a primary for a given realm and acting as a secondary for another.

Diameter Network Architecture

Thanks to the massive growth of the 4G networks, the full-mesh architecture as displayed above is no longer an option. The central control of the diameter traffic is critical. More and more important (think about IoT) is a dynamic reconfiguration of resources, congestion management and dynamic routing. Last but not least as diameter traffic can go across more networks (operators) we want to apply topology hiding and other security measures. This is a task for so-called Diameter Signalling Controller (DSC).

The DSC consists of a Diameter Routing Agent (DRA) to route traffic in the core network and a Diameter Edge Agent (DEA) that manages activity at the edge of the network. An operator may have one agent from one vendor and the other from another one. Mostly, however, DSC is an integrated solution that includes DRA, DEA and other embedded functionalities (e.g. interworking functions, intelligent routing, SLF, etc).

VoLTE with Diameter Signalling Controller (DSC)

A diameter network consists of Clients, Servers and Diameter agents. The Diameter protocol in RFC 6733 further specifies relay, proxy, redirect, and translation agents:

• Relay Agent (DRL) – routes messages based on their headers as Destination-Realm or Destination-Host AVPs. Routing decisions are performed using a routing table. The routing table contains a list of supported realms and known peers. The relay agents are usually transparent, a Relay Agent may modify Diameter messages only by inserting and/or removing routing information but may not modify any other content of a message. Therefore DRL doesn’t need to understand the applications part.

Diameter Relay Agent

• Proxy Agent – also routes Diameter messages using the routing table. In contrast to DRL, a proxy agent may modify messages in order to implement policy decisions, provide admission control, and provisioning. That also means that the Proxy agent must understand the service logic.
• Redirect Agent (DRD) – unlike the proxy and relay agents, a redirect agent returns a special type of answer message to the peer that sent the request. This answer contains routing information that allows the peer to resend the request directly to the right destination server. The redirect agent is then out of the routing path; a redirect agent does not relay requests. Since redirect agents do not relay messages, they do not modify messages.
  

  Diameter Redirect Agent (DRD)

• Translation Agent (TLA)  – translates between two protocols, such as RADIUS and Diameter, which can be useful for a migration from RADIUS to Diameter migration.

For us in telco the 3GPP defines in the 29.213 the following network elements:

• Diameter Edge Agent (DAE) – performs routing of signaling messages between operators’ networks and improves network security by collecting and presenting security-related information for signaling from roaming partners.

Diameter Edge Agent

• Diameter Routing Agent (DRA) –  a network function that ensures that all Diameter sessions established over the Gx, S9, Gxx, Rx and Sd reference points for a certain IP-CAN session reach the same PCRF when multiple (separately addressable) PCRFs are present in a Diameter realm. The DRA provides routing of signaling messages for policy control and charging, load distribution and session anchoring.

 

Diameter Routing Agent (DRA)

 

I know it was a long reading and we are still not finished. The key message of this post is that the Diameter is an important protocol in VoLTE networks, it is easy to learn and work with. The DSC is a critical component of each 4G network, which simplifies the network architecture and configuration and allows Network-to-Network communication. Except the RFCs and 3GPP specs there are plenty of very good materials available on the Internet (e.g. Diameter Protocol Explained). And maybe some other time, we’ll continue and take a closer look at some Diameter details.

Related posts:

• IMS from 10.000 feet
• VoLTE Policy Control Summary
• Sh Interface – What Is It Good for?
• User Data Convergence – HSS-FE
• Rainy-day Scenarios – S-CSCF Restoration