RADIUS versus Diameter

Because the Diameter protocol was developed as a fundamental improvement to RADIUS, there are some similarities and significant differences between the two protocols. The protocols have similarities such as transaction requests/responses, Response messages must always be sent along the same path as the Request message, as well as messages comprised of header and set of tag-length-value attributes. Several of the RADIUS attributes have Diameter equivalents in order to support interworking between Diameter and RADIUS networks as shown in Table 2-1.

Table 2-1 Major Differences between Diameter and RADIUS

Diameter	RADIUS
Application IDs	No Application IDs.
Capabilities exchange procedure	Does not exist. Messages supported on a connection are determined through static configuration.
End-to-End Transaction IDs	No End-to-End Transaction IDs.
32-bit Hop-by-Hop ID	8-bit Hop-by-Hop ID (called an Identifier in RADIUS)
Duplicate transactions received by a node from any path can be detected (using the T-bit, Session-ID, End-to-End ID)	A RADIUS Server is able detect that a received Request is a duplicate of a previously received Request message if the Request message have the same Source IP address, Source Port Number and RADIUS header Identifier values.
Answer contains error code	Transaction responses do not universally contain an error code. When a transaction failure is detected, the most common practice is to discard the Request rather than sending a Response.
Ability to send Congestion response	No ability to indicate congestion. DSR features that are based on the congestion response such as Remote Busy are difficult to support.
Nodes are assigned a FQDN which can be used to address a transaction to a specific Node.	RADIUS transactions can only be addressed to a RADIUS node called a NAS. Transactions sent to a RADIUS authentication or accounting server contain no destination address.
Request messages always contain a universal address (FQDN) of the node that initiated the transaction.	Only transactions initiated by an access node referred to as a NAS must contain an originating node address. However, a NAS can have up to three different address types which are not guaranteed to be unique across networks.
Requests always contain an origin and destination Realm.	Realms are not a fundamental capability of RADIUS. The User-Name attribute may contain a Realm.
Universal Watchdog procedure used for detecting peer node failures must be supported by all Diameter nodes.	RADIUS procedures exist for monitoring a path between RADIUS Peer Nodes (such as Status-Server) but are not mandatory. This RADIUS procedure is not considered a true "watchdog" procedure.
All transactions contain a Session-ID which has the originating node's FQDN making Session-IDs unique across multiple networks.	Not all transactions contain a Session-ID equivalent and there is no guarantee that it is unique across networks.
Command Code identical in Request and Answer	Command Code (Code in RADIUS) is different in Request and Answer (Response in RADIUS).
Transaction path recording and message loop detection (via Route-Record)	Does not exist.
Mandatory/non-mandatory flag for message attributes.	Not supported.

RADIUS and Diameter Command Codes and AVP Codes are defined to prevent overlap/ambiguities. RADIUS Command and AVP codes values are in the range of 1-255, while Diameter values are 256 or more.