Diameter (protocol)


Diameter is an authentication, authorization, and accounting protocol for computer networks. It evolved from the earlier RADIUS protocol. It belongs to the application layer protocols in the internet protocol suite.
Diameter Applications extend the base protocol by adding new commands and/or attributes, such as those for use with the Extensible Authentication Protocol.

Comparison with RADIUS

The name is a play on words, derived from the RADIUS protocol, which is the predecessor. Diameter is not directly backwards compatible but provides an upgrade path for RADIUS. The main features provided by Diameter but lacking in RADIUS are:
Also:
Like RADIUS, it is intended to work in both local and roaming AAA situations.
It uses TCP or SCTP unlike RADIUS which uses UDP.
Unlike RADIUS it includes no encryption, but can be protected by transport level security.
The base size of the AV identifier is 32 bit unlike RADIUS which uses 8 bit as the base AV identifier size.
Like RADIUS, it supports stateless as well as stateful modes.
Like RADIUS, it supports application layer acknowledgment and defines failover.
Diameter is used for many different interfaces defined by the 3GPP standards, with each interface typically defining new commands and attributes.

Applications

A Diameter Application is not a software application but is a protocol based on the Diameter base protocol defined in RFC 6733 and RFC 7075. Each application is defined by an application identifier and can add new command codes and/or new mandatory AVPs. Adding a new optional AVP does not require a new application.
Examples of Diameter applications:
: Bootstrapping Server Function

History

The Diameter protocol was initially developed by Pat R. Calhoun, Glen Zorn, and Ping Pan in 1998 to provide a framework for authentication, authorization and accounting that could overcome the limitations of RADIUS. RADIUS had issues with reliability, scalability, security and flexibility. RADIUS cannot deal effectively with remote access, IP mobility and policy control. The Diameter protocol defines a policy protocol used by clients to perform policy, AAA, and resource control. This allows a single server to handle policies for many services.
Like RADIUS, Diameter provides AAA functionality, but uses TCP and SCTP instead of UDP, therefore delegating detection and handling of communication problems to those protocols. The Diameter protocol is enhanced further by the development of the 3rd Generation Partnership Project IP Multimedia Subsystem. The S6a, S6b, Gx, Gy, Sy, Rx, Cx, Dh, Dx, Rf, Ro, Sh and Zh interfaces are supported by Diameter applications. Through the use of extensions, the protocol was designed to be extensible to support proxies, brokers, strong security, mobile IP, network-access servers, accounting and resource management.

Protocol Description

The Diameter base protocol is defined by RFC 6733 and defines the minimum requirements for an AAA protocol. Diameter Applications can extend the base protocol by adding new commands, attributes, or both. Diameter security is provided by IPsec or TLS. The IANA has assigned TCP and SCTP port number 3868 to Diameter.

Packet Format

The packet consists of a Diameter header and a variable number of Attribute-Value Pairs, or AVPs, for encapsulating information relevant to the Diameter message.

Version

This field indicates the version of the Diameter Base Protocol. As of 2014, the only value supported is 1.

Message Length

The Message Length field indicates the length of the Diameter message in bytes, including the header fields and the padded AVPs.

Flags

The "R" bit – If set, the message is a request. If cleared, the message is an answer.
The "P" bit – If set, the message MAY be proxied, relayed or redirected. If cleared, the message MUST be locally processed.
The "E" bit – If set, the message contains a protocol error, and the message will not conform to the CCF described for this command. Messages with the "E" bit set are commonly referred to as error messages. This bit MUST NOT be set in request messages.
The "T" bit – This flag is set after a link failover procedure, to aid the removal of duplicate requests. It is set when resending requests not yet acknowledged as an indication of a possible duplicate due to a link failure.

Commands

Each command Request/Answer pair is assigned a command code. Whether it is the request or answer is identified via the ’R’ bit in the Command Flags field of the header.
The values 0-255 are reserved for RADIUS backward compatibility.
The values 256-16777213 are for permanent, standard commands allocated by IANA.
The values 16777214 and 16777215 are reserved for experimental and testing purposes.
A Command Code is used to determine the action that is to be taken for a particular message. Some common Diameter commands defined in the protocol are:
Command-NameAbbr.CodeApplication
AA-RequestAAR265Diameter NAS Application - RFC 7155
AA-AnswerAAA265Diameter NAS Application - RFC 7155
Diameter-EAP-RequestDER268Diameter EAP Application - RFC 4072
Diameter-EAP-AnswerDEA268Diameter EAP Application - RFC 4072
Abort-Session-RequestASR274Diameter base
Abort-Session-AnswerASA274Diameter base
Accounting-RequestACR271Diameter base
Accounting-AnswerACA271Diameter base
Credit-Control-RequestCCR272Diameter Credit-Control Application - RFC 8506
Credit-Control-AnswerCCA272Diameter Credit-Control Application - RFC 8506
Capabilities-Exchange-RequestCER257Diameter base
Capabilities-Exchange-AnswerCEA257Diameter base
Device-Watchdog-RequestDWR280Diameter base
Device-Watchdog-AnswerDWA280Diameter base
Disconnect-Peer-RequestDPR282Diameter base
Disconnect-Peer-AnswerDPA282Diameter base
Re-Auth-RequestRAR258Diameter base
Re-Auth-AnswerRAA258Diameter base
Session-Termination-RequestSTR275Diameter base
Session-Termination-AnswerSTA275Diameter base
User-Authorization-RequestUAR283Diameter SIP Application - RFC 4740
User-Authorization-AnswerUAA283Diameter SIP Application - RFC 4740
Server-Assignment-RequestSAR284Diameter SIP Application - RFC 4740
Server-Assignment-AnswerSAA284Diameter SIP Application - RFC 4740
Location-Info-RequestLIR285Diameter SIP Application - RFC 4740
Location-Info-AnswerLIA285Diameter SIP Application - RFC 4740
Multimedia-Auth-RequestMAR286Diameter SIP Application - RFC 4740
Multimedia-Auth-AnswerMAA286Diameter SIP Application - RFC 4740
Registration-Termination-RequestRTR287Diameter SIP Application - RFC 4740
Registration-Termination-AnswerRTA287Diameter SIP Application - RFC 4740
Push-Profile-RequestPPR288Diameter SIP Application - RFC 4740
Push-Profile-AnswerPPA288Diameter SIP Application - RFC 4740
User-Authorization-RequestUAR300Diameter base RFC 3589
User-Authorization-AnswerUAA300Diameter base RFC 3589
Server-Assignment-RequestSAR301Diameter base RFC 3589
Server-Assignment-AnswerSAA301Diameter base RFC 3589
Location-Info-RequestLIR302Diameter base RFC 3589
Location-Info-AnswerLIA302Diameter base RFC 3589
Multimedia-Auth-RequestMAR303Diameter base RFC 3589
Multimedia-Auth-AnswerMAA303Diameter base RFC 3589
Registration-Termination-RequestRTR304Diameter base RFC 3589
Registration-Termination-AnswerRTA304Diameter base RFC 3589
Push-Profile-RequestPPR305Diameter base RFC 3589
Push-Profile-AnswerPPA305Diameter base RFC 3589
User-Data-RequestUDR306Diameter base RFC 3589
User-Data-AnswerUDA306Diameter base RFC 3589
Profile-Update-RequestPUR307Diameter base RFC 3589
Profile-Update-AnswerPUA307Diameter base RFC 3589
Subscribe-Notifications-RequestSNR308Diameter base RFC 3589
Subscribe-Notifications-AnswerSNA308Diameter base RFC 3589
Push-Notification-RequestPNR309Diameter base RFC 3589
Push-Notification-AnswerPNA309Diameter base RFC 3589
Bootstrapping-Info-RequestBIR310Diameter base RFC 3589
Bootstrapping-Info-AnswerBIA310Diameter base RFC 3589
Message-Process-RequestMPR311Diameter base RFC 3589
Message-Process-AnswerMPA311Diameter base RFC 3589
Update-Location-RequestULR3163GPP TS 29.272
Update-Location-AnswerULA3163GPP TS 29.272
Cancel-Location-RequestCLR3173GPP TS 29.272
Cancel-Location-AnswerCLA3173GPP TS 29.272
Authentication-Information-RequestAIR3183GPP TS 29.272
Authentication-Information-AnswerAIA3183GPP TS 29.272
Insert-Subscriber-Data-RequestIDR3193GPP TS 29.272
Insert-Subscriber-Data-AnswerIDA3193GPP TS 29.272
Delete-Subscriber-Data-RequestDSR3203GPP TS 29.272
Delete-Subscriber-Data-AnswerDSA3203GPP TS 29.272
Purge-UE-RequestPER3213GPP TS 29.272
Purge-UE-AnswerPEA3213GPP TS 29.272
Notify-RequestNR3233GPP TS 29.272
Notify-AnswerNA3233GPP TS 29.272
Provide-Location-RequestPLR83886203GPP-LCS-SLg
Provide-Location-AnswerPLA83886203GPP-LCS-SLg
Routing-Info-RequestRIR83886223GPP-LCS-SLh
Routing-Info-AnswerRIA83886223GPP-LCS-SLh
AA-Mobile-Node-RequestAMR260Diameter Mobile IPv4 - RFC 4004
AA-Mobile-Node-AnswerAMA260Diameter Mobile IPv4 - RFC 4004
Home-Agent-MIP-RequestHAR262Diameter Mobile IPv4 - RFC 4004
Home-Agent-MIP-AnswerHAA262Diameter Mobile IPv4 - RFC 4004
Configuration-Information-RequestCIR8388718S6t per 3GPP TS 29.336
Configuration-Information-AnswerCIA8388718S6t per 3GPP TS 29.336
Reporting-Information-RequestRIR8388719S6t per 3GPP TS 29.336
Reporting-Information-AnswerRIA8388719S6t per 3GPP TS 29.336
NIDD-Information-RequestNIR8388726S6t per 3GPP TS 29.336
NIDD-Information-AnswerNIA8388726S6t per 3GPP TS 29.336

Application-ID

Application-ID is used to identify for which Diameter application the message is applicable. The application can be an authentication application, an accounting application, or a vendor-specific application.
Diameter agents conforming to a certain Diameter extension publicize its support by including a specific value of in the Auth-Application-Id Attribute of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command.
The value of the Application-ID field in the header is the same as any relevant Application-Id AVPs contained in the message. For instance, the value of the Application-ID and of the Auth-Application-Id Attribute in the Credit-Control-Request and Credit-Control-Answer Command for the Diameter Credit-Control Application is 4.
Application-IDAbbr.Full nameUsage
0BaseDiameter Common MessagesDiameter protocol association establishment/teardown/maintenance
16777216Cx/Dx3GPP Cx/DxIMS I/S-CSCF to HSS interface
16777217Sh3GPP ShVoIP/IMS SIP Application Server to HSS interface
16777236Rx3GPP RxPolicy and charging control
16777251S6a/S6d3GPP S6a/S6dLTE Roaming signaling
16777252S133GPP 13Interface between EIR and MME
16777255SLg3GPP LCS SLgLocation services
16777345S6t3GPP S6tInterface between SCEF and HSS

Hop-by-Hop Identifier

The Hop-by-Hop Identifier is an unsigned 32-bit integer field that is used to match the requests with their answers as the same value in the request is used in the response.
The Diameter protocol requires that relaying and proxying agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, its Hop-by-Hop Identifier is saved; the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request’s state is released upon receipt of the answer. Received answers that do not match a known Hop-by-Hop Identifier are ignored by the Diameter agent.
In case of redirecting agents, the Hop-by-Hop Identifier is maintained in the header as the Diameter agent responds with an answer message.

End-to-End Identifier

The End-to-End Identifier is an unsigned 32-bit integer field that is used to detect duplicate messages along with the combination of the Origin-Host AVP.
When creating a request, the End-to-End Identifier is set to a locally unique value. The End-to-End Identifier is not modified by Diameter agents of any kind, and the same value in the corresponding request is used in the answer.

Attribute-Value Pairs (AVP)

For simplicity, "V" bit Means Vendor Specific; "M" bit means Mandatory; "P" bit means Protected.
The "V" bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header. When set the AVP Code belongs to the specific vendor code address space.
The "M" bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the "M" bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the message must be rejected. Diameter Relay and redirect agents must not reject messages with unrecognized AVPs.
The "P" bit indicates the need for encryption for end-to-end security.
Attribute-NameCodeData Type
Acct-Interim-Interval85Unsigned32
Accounting-Realtime-Required483Enumerated
Acct-Multi-Session-Id50UTF8String
Accounting-Record-Number485Unsigned32
Accounting-Record-Type480Enumerated
Accounting-Session-Id44OctetString
Accounting-Sub-Session-Id287Unsigned64
Acct-Application-Id259Unsigned32
Auth-Application-Id258Unsigned32
Auth-Request-Type274Enumerated
Authorization-Lifetime291Unsigned32
Auth-Grace-Period276Unsigned32
Auth-Session-State277Enumerated
Re-Auth-Request-Type285Enumerated
Class25OctetString
Destination-Host293DiamIdent
Destination-Realm283DiamIdent
Disconnect-Cause273Enumerated
E2E-Sequence300Grouped
Error-Message281UTF8String
Error-Reporting-Host294DiamIdent
Event-Timestamp55Time
Experimental-Result297Grouped
Experimental-Result-Code298Unsigned32
Failed-AVP279Grouped
Firmware-Revision267Unsigned32
Host-IP-Address257Address
Inband-Security-Id299Unsigned32
Multi-Round-Time-Out272Unsigned32
Origin-Host264DiamIdent
Origin-Realm296DiamIdent
Origin-State-Id278Unsigned32
Product-Name269UTF8String
Proxy-Host280DiamIdent
Proxy-Info284Grouped
Proxy-State33OctetString
Redirect-Host292DiamURI
Redirect-Host-Usage261Enumerated
Redirect-Max-Cache-Time262Unsigned32
Result-Code268Unsigned32
Route-Record282DiamIdent
Session-Id263UTF8String
Session-Timeout27Unsigned32
Session-Binding270Unsigned32
Session-Server-Failover271Enumerated
Supported-Vendor-Id265Unsigned32
Termination-Cause295Enumerated
User-Name1UTF8String
Vendor-Id266Unsigned32
Vendor-Specific-Application-Id260Grouped

State machines

The RFC 3588 defines a core state machine for maintaining connections between peers and processing messages. This is part of the basic protocol functionality and all stacks should support it and as such abstract from the connectivity related operations.
Additionally, application specific state machines can be introduced either later or at a higher abstraction layer. The RFC 3588 defines an authorization and an accounting state machine.

Message flows

The communication between two diameter peers starts with the establishment of a transport connection. The initiator then sends a Capabilities-Exchange-Request to the other peer, which responds with a Capabilities-Exchange-Answer. For RFC3588 compliant peers TLS may optionally be negotiated. For RFC6733 compliant peers TLS negotiation may optionally happen before the CER/CEA.
The connection is then ready for exchanging application messages.
If no messages have been exchanged for some time either side may send a Device-Watchdog-Request and the other peer must respond with Device-Watchdog-Answer.
Either side may terminate the communication by sending a Disconnect-Peer-Request which the other peer must respond to with Disconnect-Peer-Answer. After that the transport connection can be disconnected.

RFCs

The Diameter protocol is currently defined in the following IETF RFCs: Obsolete RFCs are indicated with strikethrough text.
#TitleDate publishedRelated articleObsoleted byNotes
RFC 3588Diameter Base Protocol.September 2003RFC 6733
RFC 3589Diameter Command Codes for Third Generation Partnership Project Release 5.September 2003
RFC 4004Diameter Mobile IPv4 Application.August 2005
RFC 4005Diameter Network Access Server Application.August 2005RFC 7155
RFC 4006Diameter Credit-Control Application.August 2005Diameter Credit-Control ApplicationRFC 8506
RFC 4072Diameter Extensible Authentication Protocol Application.August 2005
RFC 4740Diameter Session Initiation Protocol Application. M.November 2006
RFC 5224Diameter Policy Processing Application.March 2008
RFC 5431Diameter ITU-T Rw Policy Enforcement Interface Application.March 2009
RFC 5447Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction.February 2009
RFC 5516Diameter Command Code Registration for the Third Generation Partnership Project Evolved Packet System.April 2009-
RFC 5624Quality of Service Parameters for Usage with Diameter.August 2009
RFC 5719Updated IANA Considerations for Diameter Command Code Allocations.January 2010RFC 6733
RFC 6733Diameter Base Protocol.October 2012
RFC 6737The Diameter Capabilities Update Application.October 2012
RFC 7155Diameter Network Access Server Application.April 2014
RFC 8506Diameter Credit-Control Application.March 2019