Diameter protocol :

What is Diameter protocol:

Diameter protocol is an application layer protocol that uses the services of the IP networks via TCP or SCTP. It provides support for Authentication, Authorization, and Accounting or AAA. Earlier to Diameter, the radius was the protocol that was providing AAA. Diameter base protocol defined in RFC 6733 earlier it was in RFC 3588.  The telecom networks, 3G, LTE, 4G, and IMS are using the diameter protocol for AAA. In new deployment for LTE or 4G, all using diameter signaling. 3GPP is defining new applications or interfaces for supporting roaming and charging over an IP network using diameter. E.g In 4G a new node MME is added, in 3G this was MSC/VLR. The VLR was using SS7/Sigtran protocol with HLR in-home network. in 4G the MME is using Diameter protocol with HSS in-home network. It is a flexible protocol new, applications can be added over the base protocol. The base version provides a framework, for message format, AVP format, connection setup, diameter addressing, error codes, etc.

Diameter protocol stack:

As an application layer protocol in the OSI model. Diameter uses TCP or SCTP for network transport services.
In Following Example, the diameter is running a Diameter credit-control application. Before sending any credit control request diameter client setup  SCTP association to the remote server by doing a four-way handshake and diameter protocol stack exchanges CER and CEA.
Diameter protocol call flow over SCTP
Diameter protocol call flow.

Diameter Vs Radius:

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

    When UDP sends the message to the destination, no connection setup and no acknowledgment from the peer node. If a message is lost, the sender will never come to know. 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 retransmits the same message again.  SCTP do continuations monitoring of link status by sending heartbeat and reeving Heatbeat ACK at regular interval. If Link is not active,  SCTP user (e.g diameter application), gets 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 server changes, the server can initiate ReAuth request with new QoS to immediately apply new values. 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 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 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 error in diameter protocol. Application-level error, these are permanent errors, the server responds with error in ResultCodeAVP.  Protocol level error is because of the wrong message according to the protocol, e.g missing a mandatory AVP.

    Base protocol provides following types of diameter result code,
  • Informational (1xxx), 1xxx is an integer value, 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.
  • Informational (2xxx), starts with 2, this set of error codes are for success.
  • Informational (3xxx), starts with 3, this set of error codes are for protocol level failures.
  • Informational (4xxx), starts with 4, this set of error codes are for transit failure, these are temporary failures.
  • Informational (5xxx), starts with 5, this set of error codes are for permanent failure.

Compatibility with Radius:

It is important for a new system to be compatible with older or a legacy system. Diameter 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. Diameter specification provides a translation node for the conversation of protocol messages.

Base Diameter protocol Functionalities:

  • Delivery of AVPs, an AVP carries parameters. To make AAA work the client application sends parameters (user, pass, etc.) to the server, the place holder 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 servers or nodes in-home network.

Relay Agents:

Relay Agents forwards 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 for a large number of diameter peers in an area to the peers in a remote area. No state is maintained.

Proxy Agents:

Proxy Agents routes 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 doesn’t know the target address, then sends 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:

Diameter Message
Diameter Protocol Message
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 three 3 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 retranmitted. This is beacause 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 Request bit set in Flags.  Each message should carry command according to the application id, to make correct message processing on a peer. Following is a list of command codes provided by 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 an integer value. This carries the numeric id used by the application. The application can be basic Accounting, Authorization or a 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 assigned locally 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 place holder 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, it 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 protected, if this bit is set, the data in an AVP is encrypted from end to end.

The 7th bit is for mandatory, if this bit is set, then all diameter agents should support this AVP.

The 8th bit is 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 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, String.

Grouped AVP:

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

 

1 thought on “Diameter Protocol”

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top