Diameter protocol tutorial | Messages, AVPs and comparison with Radius
Diameter protocol stack:
A basic example of a call flow:
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, 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 immediately apply new values. Else server has to wait for the next Auth Request from the client.
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 watchdog fails, the peer is marked inactive, and messages are sent to another peer.
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 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, 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 are for success.
- (3xxx), starts with 3, this set of error codes are for protocol level failures.
- (4xxx), starts with 4, this set of error codes are for transit failure, these are temporary failures.
- (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 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 carry a parameter. 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 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 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:
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.
- 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
Diameter AVP :
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 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, String.
This type of AVP has more grouped or grouped and basic diameter AVPs.