Diameter protocol tutorial | Messages, AVPs, and comparison with Radius

---

Diameter protocol stack:

As an application layer protocol in the OSI model, in the protocol stack, it comes over SCTP/TCP transport layer.

A basic example of a call flow:

The following example shows the message flow for a Diameter credit-control application. Before sending any credit control request, the client sets up an SCTP association with the remote server by doing an SCTP four-way handshake. After that, there is an exchange of CER/CEA. We are describing the CRE/CEA in the capability negotiation section.

Diameter Vs Radius – A detailed comparison:

• Radius uses UDP, which is not a reliable protocol, while Diameter uses TCP or SCTP.

  When UDP sends a message to the destination, there is no connection setup and no acknowledgment from the peer for the message. If a message is lost, the sender UDP will not take any action for the lost message. While in SCTP, there is a connection setup before sending any message to the peer. The receiver acknowledges the message. If the message is lost, the sender SCTP retransmits the same message again. SCTP does continuous monitoring of link status by sending heartbeat and reeving Heatbeat ACK at regular intervals.

  If the Link is not active or goes down, the SCTP user (e.g, diameter application), gets a communication lost indication.
• Server Initiated Messages In Radius protocol, server-initiated messages are optional, while this is mandatory in diameter. There are situations when a server detects that a session is not in use or inactive for a long time. The server will not keep waiting all the time for any event from the client. It can verify by sending a message if a client is active or not by doing ReAuth. In 3GPP there is a Gx interface. Gx provides capabilities for data throttling for a device. For data access, the Gx server receives the Auth request and server responses with the Auth Answer with Qos Values for an IMSI. If QoS on the server changes, the server can initiate a ReAuth request with a new QoS to apply new values immediately

  . Else server has to wait for the next Auth Request from the client.

• Capability Negotiations,

  Before starting any communication both diameter peers do capability negotiations. This makes both nodes communicate with each other without any mismatch. Capability Exchange Request (CER) and Capability Exchange Answer (CEA) messages provide capability handling.  This enables each other to know the protocol version, supported applications, etc.
• Diameter provides fail-over handling This is at two layers one at the SCTP level, it is possible because of the multi-homing feature of SCTP. The other is the diameter level, diameter uses a watchdog message to monitor the health of the peer host. If the watchdog fails, the peer is marked inactive, and messages are sent to another peer.
• Error Reporting Radius drops messages silently if there is an error. While diameter reports an error to the client.  There are two types of errors in the Diameter protocol. Application-level errors are permanent errors, the server responds with an error in ResultCode AVP.  Protocol level error is because of the wrong message according to the protocol, e.g missing a mandatory AVP. Following is the list of error codes:
• (1xxx), 1xxx is an integer value, that starts with 1, this is to inform the client from the server that, a request does not have sufficient action to complete, more action is required to complete.
• (2xxx), starts with a digit 2, this set of codes is for success.
• (3xxx), starts with 3, this set of error codes is for protocol level failures.
• (4xxx), starts with 4, this set of error codes is for transit failure, these are temporary failures.
• (5xxx), starts with 5, this set of error codes is for permanent failure.

Compatibility with Radius:

It is important for a new system to be compatible with an older or a legacy system. The new specification has backward compatibility with RADIUS. Diameter AVPs with values 1 to 255 are reserved for radius and 0 to 255 command codes are reserved for Radius.

The specification provides a translation node for the conversation of protocol messages.

Base Diameter protocol Functionalities:

• The delivery of AVPs in a protocol message. An AVP is a basic unit to carries a parameter. To make AAA work, the client application sends parameters (user, pass, etc.) to the server, the placeholder for these values is called AVP.
• Capability Negotiation.
• Support for the addition of new AVPs.
• Handling of sessions.

Diameter Network,   Nodes (Relay Agent, Proxy, and Redirect):

Diameter base protocol defines the network nodes to support a big network based on diameter protocol. As diameter supports roaming, there are nodes in the roaming network those need to talk to servers or nodes in-home network.

Relay Agents:

Relay Agents forward messages from source to destination without inspecting the message.   Routes a message based on the destination realm in the message.  A relay agent is important for routing a large number of diameter peers in an area to the peers in a remote area. No state is maintained.

Proxy Agents:

Proxy Agents route the message based on the destination realm. The message is inspected, and policy control may be enforced.  The state is maintained.

Redirect Agents :

These nodes have centralized routing information. This is like a DNS server, when clients want to send the request to the server and don’t know the target address, then send requests to the redirect agent. After a successful response from the redirect node, the client and server communicate with each other directly.

Diameter Message Format :

A diameter message has a header and a list of AVPs. The diameter message has the following parameters:

Version: This is a one-byte field. This specifies the version number of the diameter protocol. Currently, only the version number is 1.

Message Length: This is three bytes field. Represents the total message length, which is the diameter header and all AVPs.

Flags : This is 8 bits in length, every bit represents information about the message.

bit 0 is Request bit, if this bit is set then message is a request else it is a response message.
bit 1 is Proxiable bit, if this bit is set message should not processes locally. The diameter should send this to next hope.
bit 2 is Error bit, if this bit is set , message have protocol errors.
bit 3 is Re-transmitted Message,  if this bit is set message is retransmitted. 
This is because a client did not receive a response for a previously sent request. To avoid duplicate processing this bit is set.
bit 4 to 7 are reserved.

Command Code: It is a three bytes parameter. This represents the diameter Request or Response command based on the Request bit set in Flags.  Each message should carry a command according to the application id, to make correct message processing on a peer. Following is a list of command codes provided by the base diameter protocol

•  Capability Exchange Request (CER) /Capability Exchange Answer (CEA) – 257 
• Device Watch Dog Request (DWR) / Device Watch Dog Answer (DWA) – 280
• Disconnect Peer Request (DPR) /Disconnect Peer Answer (DPA) – 282
• ReAuth Request (RAR) /ReAuth Answer (RAA)  – 258
• Session Abort Request (SAR)/Session Abort Answer (SAA)- 274
• Session Termination Request (STR)/Session Termination Answer (STA) – 275
• Accounting-Request(ACR)/Accounting Answer(ACA)  271

 Application Id: It is 4 bytes in length and an integer value. This carries the numeric id used by the application. The application can be basic Accounting, Authorization, or Vendor-specific application.

Hope By Hope Identifier: Four bytes in length.  A peer uses these values to match a response with the request. If a peer gets the response with the unknown value of the hop-by-hop identifier, the peer drops the response.  The value is assigned locally is in increasing order. If a peer reboots the value should be unique after a reboot too.  

End to End Identifier: Four bytes in length. To check the duplicate of a diameter message. The server should send the same value in the Diameter Answer message.

Diameter AVP :

Diameter AVP is a basic placeholder for user data or information. The user data can be for Authentication, Authorization, or Accounting. For example,  If a mobile device wants to get credit to access data, Credit Control Request includes IMSI, in use name AVP, and  Request amount of data in requested octets.

AVP Header:

Each AVP has a header and other information along with AVP data.  Following is the description of all AVP header fields.

AVP Code – The first four bytes are for AVP code. An AVP code is an integer value.

AVP Flags – The next byte (8 bits ) are AVP flags. The bit from 1 to 5 is reserver.

The 6 bit is for protection, if this bit is set, the data in an AVP is encrypted from end to end.

The 7th bit represents if the AVP is mandatory or not, if this bit is set, then all diameter agents should support this AVP.

The 8th bit is used for Vendor-specific, if this bit is set, a vendor id will be added in the AVP.  For example, 3GPP is one of the vendors.

AVP length – The next three bytes are the total AVP length.

Vendor-Id –  If the vendor id bit will be set there will be a four bytes vendor ID.

Basic Diameter AVP :

These AVP contains basic data types. Basic data types are Integer, Boolean, and String.

Grouped AVP:

This type of AVP has more grouped or grouped and basic diameter AVPs.