Hubbry Logo
Diameter (protocol)Diameter (protocol)Main
Open search
Diameter (protocol)
Community hub
Diameter (protocol)
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Diameter (protocol)
Diameter (protocol)
Diameter (protocol)
View on Wikipedia
from Wikipedia

Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

Diameter is an authentication, authorization, and accounting (AAA) 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 (EAP).

Comparison with RADIUS

[edit]

The name is a play on words, derived from the RADIUS protocol, which is the predecessor (a diameter is twice the radius). Diameter is not directly backward compatible but provides an upgrade path for RADIUS. The main features provided by Diameter but lacking in RADIUS are:

  • Support for SCTP
  • Capability negotiation
  • Application layer acknowledgements; Diameter defines failover methods and state machines (RFC 3539)
  • Extensibility; new commands can be defined
  • Aligned on 32 bit boundaries

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 (IPSEC or TLS). 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

[edit]

A Diameter Application is not a software application but is a protocol based on the Diameter base protocol defined in RFC 6733 (obsoletes RFC 3588) and RFC 7075. Each application is defined by an application identifier and can add new command codes and/or new mandatory AVPs (Attribute-Value Pair). Adding a new optional AVP does not require a new application.

Examples of Diameter applications:

  • Diameter Mobile IPv4 Application (MobileIP, RFC 4004)
  • Diameter Network Access Server Application (NASREQ, RFC 7155)(Obsoletes: RFC 4005)
  • Diameter Extensible Authentication Protocol Application (RFC 4072)
  • Diameter Credit-Control Application (DCCA, RFC 8506])(Obsoletes: RFC 4006)
  • Diameter Session Initiation Protocol Application (RFC 4740)
  • Various applications in the 3GPP IP Multimedia Subsystem
Both the HSS and the SLF communicate using the Diameter protocol.

(Generic Bootstrapping Architecture): Bootstrapping Server Function

History

[edit]

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 (AAA) that could overcome the limitations of RADIUS. At the time Diameter was designed, RADIUS was believed to have issues with reliability, scalability, security, and flexibility. RADIUS also did not support large policies which were needed for telephony applications. 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.[1]

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 (3GPP) IP Multimedia Subsystem (IMS). The S6a, S6b, Gx, Gy, Sy, Rx, Cx, Dh, Dx, Rf, Ro, Sh and Zh interfaces are supported by Diameter applications.[2] Through the use of extensions, the protocol was designed to be extensible to support proxies, brokers, strong security, mobile IP, network-access servers (NASREQ), accounting and resource management.

Protocol description

[edit]

The Diameter base protocol is defined by RFC 6733 (Obsoletes: RFC 3588 and RFC 5719) 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, as stated in section 11.4 of RFC 6733.

Packet format

[edit]

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.

Diameter Header
Bit offset  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 version message length
32 R P E T         command code
64 application ID
96 hop-by-hop ID
128 end-to-end ID
160
...		 AVPs
...

Version

[edit]

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

Message length

[edit]

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

Command flags

[edit]

The "R" (Request) bit – If set, the message is a request. If cleared, the message is an answer.

The "P" (Proxiable) bit – If set, the message MAY be proxied, relayed or redirected. If cleared, the message MUST be locally processed.

The "E" (Error) 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" (Potentially re-transmitted message) 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

[edit]

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 (hex 0xFFFFFE and 0xFFFFFF) 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 (base and applications) are:

Command-Name Abbr. Code Application
AA-Request AAR 265 Diameter NAS Application - RFC 7155
AA-Answer AAA 265 Diameter NAS Application - RFC 7155
Diameter-EAP-Request DER 268 Diameter EAP Application - RFC 4072
Diameter-EAP-Answer DEA 268 Diameter EAP Application - RFC 4072
Abort-Session-Request ASR 274 Diameter base
Abort-Session-Answer ASA 274 Diameter base
Accounting-Request ACR 271 Diameter base
Accounting-Answer ACA 271 Diameter base
Credit-Control-Request CCR 272 Diameter Credit-Control Application - RFC 8506 (Obsoletes RFC 4006)
Credit-Control-Answer CCA 272 Diameter Credit-Control Application - RFC 8506 (Obsoletes RFC 4006)
Capabilities-Exchange-Request CER 257 Diameter base
Capabilities-Exchange-Answer CEA 257 Diameter base
Device-Watchdog-Request DWR 280 Diameter base
Device-Watchdog-Answer DWA 280 Diameter base
Disconnect-Peer-Request DPR 282 Diameter base
Disconnect-Peer-Answer DPA 282 Diameter base
Re-Auth-Request RAR 258 Diameter base
Re-Auth-Answer RAA 258 Diameter base
Session-Termination-Request STR 275 Diameter base
Session-Termination-Answer STA 275 Diameter base
User-Authorization-Request UAR 283 Diameter SIP Application - RFC 4740
User-Authorization-Answer UAA 283 Diameter SIP Application - RFC 4740
Server-Assignment-Request SAR 284 Diameter SIP Application - RFC 4740
Server-Assignment-Answer SAA 284 Diameter SIP Application - RFC 4740
Location-Info-Request LIR 285 Diameter SIP Application - RFC 4740
Location-Info-Answer LIA 285 Diameter SIP Application - RFC 4740
Multimedia-Auth-Request MAR 286 Diameter SIP Application - RFC 4740
Multimedia-Auth-Answer MAA 286 Diameter SIP Application - RFC 4740
Registration-Termination-Request RTR 287 Diameter SIP Application - RFC 4740
Registration-Termination-Answer RTA 287 Diameter SIP Application - RFC 4740
Push-Profile-Request PPR 288 Diameter SIP Application - RFC 4740
Push-Profile-Answer PPA 288 Diameter SIP Application - RFC 4740
User-Authorization-Request UAR 300 Diameter base (3GPP) RFC 3589
User-Authorization-Answer UAA 300 Diameter base (3GPP) RFC 3589
Server-Assignment-Request SAR 301 Diameter base (3GPP) RFC 3589
Server-Assignment-Answer SAA 301 Diameter base (3GPP) RFC 3589
Location-Info-Request LIR 302 Diameter base (3GPP) RFC 3589
Location-Info-Answer LIA 302 Diameter base (3GPP) RFC 3589
Multimedia-Auth-Request MAR 303 Diameter base (3GPP) RFC 3589
Multimedia-Auth-Answer MAA 303 Diameter base (3GPP) RFC 3589
Registration-Termination-Request RTR 304 Diameter base (3GPP) RFC 3589
Registration-Termination-Answer RTA 304 Diameter base (3GPP) RFC 3589
Push-Profile-Request PPR 305 Diameter base (3GPP) RFC 3589
Push-Profile-Answer PPA 305 Diameter base (3GPP) RFC 3589
User-Data-Request UDR 306 Diameter base (3GPP) RFC 3589
User-Data-Answer UDA 306 Diameter base (3GPP) RFC 3589
Profile-Update-Request PUR 307 Diameter base (3GPP) RFC 3589
Profile-Update-Answer PUA 307 Diameter base (3GPP) RFC 3589
Subscribe-Notifications-Request SNR 308 Diameter base (3GPP) RFC 3589
Subscribe-Notifications-Answer SNA 308 Diameter base (3GPP) RFC 3589
Push-Notification-Request PNR 309 Diameter base (3GPP) RFC 3589
Push-Notification-Answer PNA 309 Diameter base (3GPP) RFC 3589
Bootstrapping-Info-Request BIR 310 Diameter base (3GPP) RFC 3589
Bootstrapping-Info-Answer BIA 310 Diameter base (3GPP) RFC 3589
Message-Process-Request MPR 311 Diameter base (3GPP) RFC 3589
Message-Process-Answer MPA 311 Diameter base (3GPP) RFC 3589
Update-Location-Request ULR 316 3GPP TS 29.272 [RFC 5516]
Update-Location-Answer ULA 316 3GPP TS 29.272 [RFC 5516]
Cancel-Location-Request CLR 317 3GPP TS 29.272 [RFC 5516]
Cancel-Location-Answer CLA 317 3GPP TS 29.272 [RFC 5516]
Authentication-Information-Request AIR 318 3GPP TS 29.272 [RFC 5516]
Authentication-Information-Answer AIA 318 3GPP TS 29.272 [RFC 5516]
Insert-Subscriber-Data-Request IDR 319 3GPP TS 29.272 [RFC 5516]
Insert-Subscriber-Data-Answer IDA 319 3GPP TS 29.272 [RFC 5516]
Delete-Subscriber-Data-Request DSR 320 3GPP TS 29.272 [RFC 5516]
Delete-Subscriber-Data-Answer DSA 320 3GPP TS 29.272 [RFC 5516]
Purge-UE-Request PER 321 3GPP TS 29.272 [RFC 5516]
Purge-UE-Answer PEA 321 3GPP TS 29.272 [RFC 5516]
Notify-Request NR 323 3GPP TS 29.272 [RFC 5516]
Notify-Answer NA 323 3GPP TS 29.272 [RFC 5516]
Provide-Location-Request PLR 8388620 3GPP-LCS-SLg (Application-ID 16777255)
Provide-Location-Answer PLA 8388620 3GPP-LCS-SLg (Application-ID 16777255)
Routing-Info-Request RIR 8388622 3GPP-LCS-SLh (Application-ID 16777291)
Routing-Info-Answer RIA 8388622 3GPP-LCS-SLh (Application-ID 16777291)
AA-Mobile-Node-Request AMR 260 Diameter Mobile IPv4 - RFC 4004
AA-Mobile-Node-Answer AMA 260 Diameter Mobile IPv4 - RFC 4004
Home-Agent-MIP-Request HAR 262 Diameter Mobile IPv4 - RFC 4004
Home-Agent-MIP-Answer HAA 262 Diameter Mobile IPv4 - RFC 4004
Configuration-Information-Request CIR 8388718 S6t per 3GPP TS 29.336
Configuration-Information-Answer CIA 8388718 S6t per 3GPP TS 29.336
Reporting-Information-Request RIR 8388719 S6t per 3GPP TS 29.336
Reporting-Information-Answer RIA 8388719 S6t per 3GPP TS 29.336
NIDD-Information-Request NIR 8388726 S6t per 3GPP TS 29.336
NIDD-Information-Answer NIA 8388726 S6t per 3GPP TS 29.336

Application-ID

[edit]

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 (CER) and Capabilities-Exchange-Answer (CEA) 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 (CCR) and Credit-Control-Answer (CCA) Command for the Diameter Credit-Control Application is 4.[4]

Application-ID Abbr. Full name Usage
0 Base Diameter Common Messages Diameter protocol association establishment/teardown/maintenance
16777216 Cx/Dx 3GPP Cx/Dx IMS I/S-CSCF to HSS interface
16777217 Sh 3GPP Sh VoIP/IMS SIP Application Server to HSS interface
16777236 Rx 3GPP Rx Policy and charging control
16777238 Gx 3GPP Gx Policy and charging control
16777251 S6a/S6d 3GPP S6a/S6d LTE Roaming signaling
16777252 S13 3GPP 13 Interface between EIR and MME
16777255 SLg 3GPP LCS SLg Location services
16777345 S6t 3GPP S6t Interface between SCEF and HSS

Hop-by-Hop Identifier

[edit]

The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in network byte order) 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

[edit]

The End-to-End Identifier is an unsigned 32-bit integer field (in network byte order) 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)

[edit]
AVP Header
Bit offset  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 AVP code
32 V M P           AVP length
64 vendor ID (optional)
96
...		 data
...

For simplicity, AVP Flag "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-Name Code Data Type
Acct-Interim-Interval 85 Unsigned32
Accounting-Realtime-Required 483 Enumerated
Acct-Multi-Session-Id 50 UTF8String
Accounting-Record-Number 485 Unsigned32
Accounting-Record-Type 480 Enumerated
Accounting-Session-Id 44 OctetString
Accounting-Sub-Session-Id 287 Unsigned64
Acct-Application-Id 259 Unsigned32
Auth-Application-Id 258 Unsigned32
Auth-Request-Type 274 Enumerated
Authorization-Lifetime 291 Unsigned32
Auth-Grace-Period 276 Unsigned32
Auth-Session-State 277 Enumerated
Re-Auth-Request-Type 285 Enumerated
Class 25 OctetString
Destination-Host 293 DiamIdent
Destination-Realm 283 DiamIdent
Disconnect-Cause 273 Enumerated
E2E-Sequence 300 Grouped
Error-Message 281 UTF8String
Error-Reporting-Host 294 DiamIdent
Event-Timestamp 55 Time
Experimental-Result 297 Grouped
Experimental-Result-Code 298 Unsigned32
Failed-AVP 279 Grouped
Firmware-Revision 267 Unsigned32
Host-IP-Address 257 Address
Inband-Security-Id 299 Unsigned32
Multi-Round-Time-Out 272 Unsigned32
Origin-Host 264 DiamIdent
Origin-Realm 296 DiamIdent
Origin-State-Id 278 Unsigned32
Product-Name 269 UTF8String
Proxy-Host 280 DiamIdent
Proxy-Info 284 Grouped
Proxy-State 33 OctetString
Redirect-Host 292 DiamURI
Redirect-Host-Usage 261 Enumerated
Redirect-Max-Cache-Time 262 Unsigned32
Result-Code 268 Unsigned32
Route-Record 282 DiamIdent
Session-Id 263 UTF8String
Session-Timeout 27 Unsigned32
Session-Binding 270 Unsigned32
Session-Server-Failover 271 Enumerated
Supported-Vendor-Id 265 Unsigned32
Termination-Cause 295 Enumerated
User-Name 1 UTF8String
Vendor-Id 266 Unsigned32
Vendor-Specific-Application-Id 260 Grouped

State machines

[edit]

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.

  • Peer State Machine Part 1
    Peer State Machine Part 1
  • Peer State Machine Part 2
    Peer State Machine Part 2

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.

  • Diameter Authorization State Machines (Client)
    Diameter Authorization State Machines (Client)
  • Diameter Authorization State Machines (Server)
    Diameter Authorization State Machines (Server)
  • Diameter Accounting State Machines (Client)
    Diameter Accounting State Machines (Client)
  • Diameter Accounting State Machines (Server)
    Diameter Accounting State Machines (Server)

Message flows

[edit]

The communication between two diameter peers starts with the establishment of a transport connection (TCP or SCTP). The initiator then sends a Capabilities-Exchange-Request (CER) to the other peer, which responds with a Capabilities-Exchange-Answer (CEA). For RFC3588 compliant peers TLS (Transport Layer Security) 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 (DWR) and the other peer must respond with Device-Watchdog-Answer.

Either side may terminate the communication by sending a Disconnect-Peer-Request (DPR) which the other peer must respond to with Disconnect-Peer-Answer. After that the transport connection can be disconnected.

RFCs

[edit]

The Diameter protocol is currently defined in the following IETF RFCs: Obsolete RFCs are indicated with strikethrough text.

# Title Date published Obsoleted by
RFC 3588 Diameter Base Protocol. September 2003 RFC 6733
RFC 3589 Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5. September 2003
RFC 4004 Diameter Mobile IPv4 Application. August 2005
RFC 4005 Diameter Network Access Server Application. August 2005 RFC 7155
RFC 4006 Diameter Credit-Control Application. August 2005 RFC 8506
RFC 4072 Diameter Extensible Authentication Protocol (EAP) Application. August 2005
RFC 4740 Diameter Session Initiation Protocol (SIP) Application. M. November 2006
RFC 5224 Diameter Policy Processing Application. March 2008
RFC 5431 Diameter ITU-T Rw Policy Enforcement Interface Application. March 2009
RFC 5447 Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction. February 2009
RFC 5516 Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). April 2009
RFC 5624 Quality of Service Parameters for Usage with Diameter. August 2009
RFC 5719 Updated IANA Considerations for Diameter Command Code Allocations. January 2010 RFC 6733
RFC 6733 Diameter Base Protocol. October 2012
RFC 6737 The Diameter Capabilities Update Application. October 2012
RFC 7155 Diameter Network Access Server Application. April 2014
RFC 8506 Diameter Credit-Control Application March 2019

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Diameter (protocol)

View on Grokipedia
from Grokipedia
The Diameter protocol is an , , and (AAA) framework designed for applications such as network access or IP mobility, providing a peer-to-peer mechanism to exchange AAA information between network elements. It evolved as a successor to the protocol to address limitations in scalability, security, and reliability for modern telecommunications environments, including support for roaming and large-scale deployments. Standardized by the (IETF) in RFC 6733 (published October 2012), which obsoletes earlier specifications like RFC 3588, Diameter uses extensible Attribute-Value Pairs (AVPs) for data encoding and operates over reliable transports such as TCP or SCTP on port 3868. Diameter's architecture supports a distributed model with nodes functioning as clients, servers, or agents (including relays, proxies, redirects, and translators) to route messages across realms, enabling efficient handling of AAA requests in hierarchical or federated networks. Key features include capabilities negotiation via the Capabilities-Exchange-Request/Answer (CER/CEA) messages, fail-over and load-balancing mechanisms, and accounting support for event-based or session-based records with guaranteed delivery. is mandated through transport-layer protections like TLS over TCP (port 5868) or DTLS over SCTP, ensuring end-to-end confidentiality, integrity, and peer authentication without relying on inband mechanisms. In , Diameter is integral to 3GPP-defined interfaces, such as Cx and Dx for (IMS) authentication and authorization, facilitating seamless integration in 4G/LTE and networks for policy control and charging. The protocol's extensibility allows for application-specific extensions, identified by unique Application-IDs, supporting diverse uses from mobile data to session initiation in SIP environments. Overall, Diameter's design emphasizes robustness for high-traffic scenarios, with IANA-managed registries for command codes, AVPs, and result codes to ensure across implementations.

Background

Definition and Purpose

The Diameter protocol is an , , and (AAA) framework designed for computer networks, providing extensible messaging to support applications such as network access or IP mobility in both local and roaming situations. It serves as a base protocol that enables reliable and scalable AAA services, particularly in distributed environments like IP-based telecommunications networks. At its core, Diameter aims to facilitate secure and efficient exchange of AAA data, incorporating mechanisms for reliable transport, , and to handle high-volume, distributed operations. It operates over TCP or SCTP to ensure ordered delivery of messages, enhancing dependability in communications. These features make it suitable for environments requiring robust handling of requests, decisions, and accounting records across network elements. Diameter offers high-level benefits including improved reliability over its predecessor , support for proxy and agents to enable flexible routing of AAA requests, and extensibility through the definition of new applications and commands. This design allows it to adapt to evolving access technologies while maintaining a peer-to-peer model for direct interactions between nodes.

Evolution from RADIUS

The Remote Authentication Dial-In User Service () protocol, defined in RFC 2865, served as the foundational AAA framework for network access but exhibited several limitations that hindered its scalability and reliability in modern environments. Primarily, operates over UDP, which lacks inherent retransmission mechanisms, leading to potential and inconsistent reliability across implementations. Additionally, it provides no standardized procedures, resulting in behavior that varies by vendor, and offers limited confined to response packet authentication without per-packet confidentiality or protections. also lacks explicit support for agent roles such as proxies or relays, making proxying in large networks challenging, and its server-initiated messages are optional, impeding features like session termination. Furthermore, extensibility is constrained by its fixed attribute format without mandatory/non-mandatory flags or robust error reporting, and peer discovery requires manual configuration, increasing administrative overhead. Diameter was developed as a successor to to overcome these shortcomings, introducing a more robust and extensible design while maintaining conceptual alignment with AAA functions. A key advancement is the shift to reliable transport protocols like TCP or SCTP, which provide built-in retransmission and ordered delivery to mitigate UDP's unreliability. Diameter incorporates universal transmission security through TLS over TCP or DTLS over SCTP, ensuring both confidentiality and integrity for all packets, far surpassing RADIUS's limited protections. It defines explicit roles for agents—including relays, proxies, redirects, and translation agents—with standardized behaviors to facilitate proxying and routing in large-scale networks. Server-initiated messages are mandatory, enabling proactive features such as disconnects, and capabilities exchange during peer association allows negotiation of supported features, addressing RADIUS's absence of such mechanisms. is supported through defined algorithms, state machines, and the T flag for duplicate detection, ensuring consistent recovery from failures. In terms of protocol structure, Diameter employs Attribute-Value Pairs (AVPs) for data encoding, offering greater flexibility than RADIUS's rigid attribute format; AVPs support diverse data types (e.g., OctetString, Integer32), grouped constructs, and flags to indicate mandatory or optional status, enhancing extensibility. in Diameter relies on command codes within messages, combined with application IDs and peer routing tables, providing more precise and scalable directionality compared to RADIUS's simpler code-based approach. Vendor-specific extensions are enabled through dedicated namespaces for AVPs and codes, allowing customization without protocol conflicts, and dynamic peer discovery via DNS SRV and NAPTR reduces configuration burdens. reporting is improved with dedicated result codes and informative messages, supporting better diagnostics than RADIUS's limited options. While Diameter represents a significant evolution, it includes provisions for backward compatibility with RADIUS through translation gateways that map attributes to AVPs—reusing codes 1 through 255 for legacy RADIUS attributes without a Vendor-Id—and supports hybrid environments where Diameter proxies interface with RADIUS servers. However, Diameter is not intended as a direct , as its architecture and enhanced features necessitate targeted migrations in AAA infrastructures.

Historical Development

The Diameter protocol originated in the late 1990s as part of the (IETF) efforts to develop a more robust , , and (AAA) framework capable of supporting emerging mobile and IP-based networks, addressing limitations in the existing protocol such as scalability and security for next-generation services. Initial development began with early Internet-Drafts authored by Pat R. Calhoun and collaborators, including drafts on Diameter's proxy architecture in August 1998 and integration with (SIP) in November 1998, marking the protocol's foundational work within the IETF AAA Working Group (AAATWG). Key milestones in standardization followed rapidly in the early 2000s. The first comprehensive drafts for the base protocol emerged between 1998 and 2000 under the IETF's AAATWG, culminating in the publication of RFC 3588 in September 2003, which defined the core Diameter base protocol for AAA applications in network access and IP mobility. This specification was later obsoleted by RFC 6733 in October 2012, which provided clarifications on security mechanisms, transport protocols like SCTP, and other refinements without altering the fundamental architecture. The development was significantly influenced by the (3GPP), particularly for the (IMS) in mobile networks, where joint IETF-3GPP design teams addressed AAA requirements for PDP context support and SIP integration starting around 2001. Adoption of Diameter accelerated in the 2010s with the rollout of /LTE networks, where it became the standard for AAA signaling in evolved packet cores, enabling efficient subscriber management and policy control at scale. By the mid-2010s, widespread deployment in LTE infrastructures solidified its role, transitioning from in many telecom environments. As of 2025, Diameter maintains ongoing relevance in signaling for core network functions like authentication and session management, supporting the coexistence of and ecosystems. No major revisions to the base protocol have occurred since RFC 6733, but the ecosystem has expanded through new RFCs defining extensions for applications such as credit-control (RFC 8506, 2018) and overload rate control (RFC 8582, 2019), adapting to emerging telecom demands.

Applications

Core Functions in AAA

The Diameter protocol provides a robust framework for , , and (AAA) operations, enabling secure and scalable management of network access and resource usage. As an evolution from the protocol, Diameter addresses limitations in handling complex, high-volume AAA scenarios by introducing enhanced reliability, security, and extensibility features. These core functions operate conceptually through exchanges, where clients and servers collaborate to verify identities, allocate permissions, and track consumption without relying on centralized hierarchies. Authentication in Diameter verifies the identity of users or devices by facilitating the exchange of credentials and challenges between clients and servers. This process often involves multi-round interactions, where an initial request prompts the server to issue a challenge, and subsequent responses confirm the provided credentials against stored profiles. Such mechanisms ensure that only legitimate entities gain entry, supporting diverse methods like passwords, tokens, or certificates in a unified protocol structure. Following successful , determines and grants specific access rights and session parameters to the user. The server evaluates policies to assign resources, such as bandwidth limits or service levels, and communicates these in response messages, often including details on session duration and . This step ensures that authenticated users receive tailored permissions aligned with administrative rules, preventing unauthorized overreach. Accounting captures and records usage for billing, auditing, or purposes, typically through sequenced records of session activity. It employs start records to initiate tracking, stop records to conclude sessions, and interim updates to report ongoing consumption at defined intervals, allowing for accurate aggregation of metrics like or connection time. Diameter's supports real-time in high- environments, such as mobile networks, by mandating timely delivery of records within policy-defined windows to enable immediate processing and decision-making. These AAA functions integrate seamlessly via request-answer message pairs that maintain session continuity throughout the lifecycle. A client initiates a request encapsulating or details, receives an answer with outcomes and parameters, and follows with updates, all correlated through unique session identifiers for end-to-end traceability. This paired exchange model ensures atomicity and reliability, combining , , and into cohesive sessions that adapt to dynamic network demands.

Deployments in Networks

Diameter is deployed in network access servers (NAS) to provide authentication, authorization, and accounting (AAA) services for various access technologies, including Wi-Fi, DSL, and VPN connections. In DSL environments, it supports framed access protocols like PPP over ADSL, using AVPs such as Framed-IP-Address to assign subscriber resources during authentication. For VPNs, Diameter facilitates compulsory tunneling via dedicated AVPs like Tunnel-Type and Tunnel-Client-Endpoint, enabling secure remote access integration with AAA servers. Wi-Fi authentication leverages NAS-Port-Type specifications for IEEE 802.11, allowing seamless user verification in wireless hotspots. In mobile and IP networks, Diameter plays a central role in policy control and charging, particularly in LTE architectures through interactions with the Policy and Charging Rules Function (PCRF), and in through the Policy Control Function (PCF). It enables real-time policy decisions for data sessions, such as bandwidth allocation and QoS enforcement, via interfaces like Gx between the Packet Data Network Gateway (P-GW) and PCRF in LTE. In IP-based core networks, Diameter handles subscriber authentication and , supporting the Evolved Packet System (EPS) for seamless mobility. As of 2025, Diameter remains a key AAA protocol in mobile networks, underpinning the majority of global traffic for authentication and billing in LTE deployments and for legacy interworking and in , where HTTP/2-based Service-Based Interfaces (SBIs) are adopted for many new core functions. For VoIP and (IMS) deployments, Diameter supports session initiation and border control by integrating AAA with (SIP) signaling. It authorizes multimedia sessions through interfaces like Cx to the Home Subscriber Server (HSS) for user profile retrieval and Gq to PCRF for policy enforcement at the Proxy-Call Session Control Function (P-CSCF). Session Border Controllers (SBCs) use Diameter for accounting and border security, ensuring compliant media flows across IMS domains while preventing unauthorized access. The signaling market is projected to exceed USD 1.2 billion as of 2025, driven by adoption. In specifically, while SBIs handle many policy tasks, Diameter authorizes network slicing in interworking scenarios by enforcing slice-specific policies through PCF functions, enabling like low-latency slices for IoT or enhanced . Diameter is used in interfaces such as N27 (equivalent to S6a) for and interworking. Large-scale Diameter deployments face scalability challenges, including signaling congestion from high message volumes in networks, which can degrade performance during peak loads. These are addressed through load balancing mechanisms in Diameter Routing Agents () and Signaling Controllers (DSCs), which distribute traffic across server pools using Layer 7 message inspection for efficient resource utilization and .

Extensions for Specific Domains

The Diameter protocol's extensibility is achieved through the definition of new applications that reuse the base protocol's core mechanisms while introducing unique Application Identifiers (AppIDs) assigned by the (IANA), along with domain-specific command codes and Attribute-Value Pairs (AVPs). This allows vendors and standards bodies to tailor the protocol for specialized use cases without altering its foundational architecture or transport reliability features. As of 2025, 141 such AppIDs have been assigned, enabling more than 20 distinct applications across various domains, with many allocated to for telecommunications-specific adaptations. In mobile networks, has developed key extensions for the (IMS), particularly through the Cx and Dx interfaces, which facilitate , , and management between the Serving-CSCF (S-CSCF) and the Home Subscriber Server (HSS). The Cx interface supports procedures like user registration and location updates using Diameter commands such as User-Authorization-Request (UAR), while Dx extends this for scenarios by relaying queries across visited networks. For and charging control, the Gx interface between the Policy and Charging Enforcement Function (PCEF) and Policy and Charging Rules Function (PCRF) enables dynamic provisioning of charging rules and quality-of-service (QoS) policies, using commands like Credit-Control-Request (CCR) and Credit-Control-Answer (CCA). Similarly, the Rx interface connects the Application Function (AF) to the PCRF, allowing applications to request decisions for media flows, such as bandwidth allocation for VoLTE sessions, through AVPs like Media-Component-Description. These extensions are integral to deployments in LTE and IMS environments, where they handle session setup and resource allocation in real-time, and continue in for IMS and interworking. The , specified in RFC 4006, provides a framework for real-time prepaid charging across diverse services like network access and IP mobility, using event- and session-based charging models with granular credit unit management. It introduces specific AVPs such as Granted-Service-Unit and Used-Service-Unit to track consumption, enabling operators to authorize and deduct credits dynamically during service delivery. For network access servers (), the NASREQ application defined in RFC 4005 supports , , and (AAA) functions, including service-specific authorizations via commands like Service-Specific-Authorization-Request. Complementing this, the () application in RFC 4072 transports EAP payloads between and backend servers, allowing flexible support for methods like EAP-TLS or EAP-SIM without protocol modifications.

Protocol Architecture

Overall Design Principles

The Diameter protocol is designed as a robust successor to , addressing limitations in scalability, security, and extensibility for modern , , and (AAA) applications such as network access and IP mobility. Its architecture emphasizes a modular base protocol that supports pluggable applications through mechanisms like Application IDs, allowing new commands, Attribute-Value Pairs (AVPs), and values to be defined without altering the core framework. This extensibility is further enhanced by vendor-specific AVPs identified via the Vendor-ID, enabling proprietary extensions while maintaining interoperability. Reliability is a cornerstone of Diameter's design, achieved through mandatory failover support, where messages can be forwarded to alternate peers upon failure, and session recovery using unique identifiers like the Session-Id AVP, Hop-by-Hop Sequence Numbers, and End-to-End Identifiers. The protocol mandates operation over reliable transports such as TCP or SCTP, complemented by application-layer acknowledgments, Device-Watchdog messages for peer monitoring, and congestion control via the Tc timer (set to 30 seconds) and Result-Code AVPs like DIAMETER_TOO_BUSY to handle overload. Accounting records are retransmitted as needed to ensure completeness during disruptions. Security is integrated at the transport level, requiring connections between peers to use TLS over TCP or DTLS over SCTP, with IPsec as an optional alternative for protection against eavesdropping and tampering. Mutual authentication is enforced during peer establishment, either through TLS/DTLS certificates or Capabilities-Exchange-Request/Answer (CER/CEA) messages, ensuring only authorized nodes participate in Diameter exchanges. Scalability is facilitated by dynamic peer discovery using DNS NAPTR and SRV records, eliminating the need for static configurations in large deployments. Diameter employs a realm-based model to manage administrative domains globally, where messages are routed via the Destination-Realm AVP against a of realm names, supporting efficient forwarding based on the realm portion of Network Access Identifiers (NAIs) and Application IDs while preventing loops with the Route-Record AVP. This model, along with redirection via the Redirect-Host AVP, enables seamless operation across dynamic without centralized coordination.

Peer-to-Peer Model

The Diameter protocol employs a peer-to-peer model, enabling flexible interactions among nodes where any participant can initiate requests or provide responses, in contrast to the strict client-server architecture of its predecessor, RADIUS. This design supports diverse network topologies and allows nodes to dynamically assume different roles based on context, facilitating scalable and decentralized AAA (Authentication, Authorization, and Accounting) operations. Diameter defines several distinct node roles to manage message origination, processing, and routing within this peer-to-peer framework:
  • Clients act as initiators, typically edge devices such as Network Access Servers (NAS) or Foreign Agents, that generate AAA requests on behalf of users or services.
  • Servers process these requests, performing user authentication, authorization, and accounting functions for a specific realm.
  • Relays forward messages between peers without modifying content or maintaining session state, relying solely on routing-related Attribute-Value Pairs (AVPs) to determine paths.
  • Proxies route messages while potentially modifying them, enforcing policies, and preserving session state to support advanced mediation.
  • Redirects respond to requests by providing alternative peer identities or host details, such as through the Redirect-Host-Usage AVP, without relaying the messages themselves.
Peer relationships are established through the exchange of Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA) messages upon connection initiation, allowing nodes to negotiate supported applications, mechanisms, and other capabilities. The CER message, with command code 257 and the 'R' (request) bit set, prompts the peer to reply with a CEA, which clears the 'R' bit and includes details like supported vendor IDs and AVP formats. This ensures mutual compatibility before proceeding to AAA exchanges, with both messages mandatory for all peer connections. To locate and connect with peers, Diameter utilizes Diameter URIs for node identification, formatted as schemes like "aaa://host.example.com;transport=tcp" to specify protocols and parameters. Dynamic discovery leverages DNS SRV records, queried via names such as "_diameter._tcp.realm" to resolve host addresses and ports, enabling automatic peer location without static configuration. This mechanism supports and load distribution in multi-peer environments.

Transport and Routing

The Diameter protocol employs reliable transport protocols to ensure message delivery across networks, primarily using Transmission Control Protocol (TCP) as the default option or for enhanced reliability. TCP provides connection-oriented, reliable delivery suitable for most deployments, while SCTP offers advantages such as multi-homing, which allows a single endpoint to use multiple IP addresses for redundancy and , and ordered delivery to maintain message sequence without on multiple . Both protocols operate on the standard 3868 for non-secure connections, as specified in the base protocol. Routing in Diameter is facilitated through a combination of Attribute-Value Pairs (AVPs) that identify origins and destinations, enabling efficient message forwarding in architectures. The Origin-Host and Origin-Realm AVPs specify the sending node's identity and administrative domain, respectively, while Destination-Host and Destination-Realm AVPs direct messages to the intended recipient or . For cross-realm scenarios, proxy chains are employed, where intermediate proxy agents relay messages, recording the path via Route-Record AVPs and maintaining state with Proxy-Info AVPs to support decisions and potential retransmissions. This mechanism allows Diameter to scale across interconnected realms without requiring direct peer connections everywhere. To manage congestion and connection health, Diameter incorporates watchdog mechanisms using Device-Watchdog-Request (DWR) and Device-Watchdog-Answer (DWA) messages, which peers exchange periodically to verify liveness and detect failures proactively. Elective termination is handled through Disconnect-Peer-Request (DPR) and Disconnect-Peer-Answer (DPA) messages, enabling graceful shutdowns in response to overload or administrative needs, thus preventing resource exhaustion. The protocol supports both IPv4 and addressing natively over these transports. Routing loops are avoided by checking the Route-Record AVPs; if the Origin-Host of the message is already present in the list, the message is rejected with Result-Code DIAMETER_LOOP_DETECTED (3005).

Message Structure

Header Composition

The Diameter message header is a fixed-length structure consisting of 20 octets that precedes the variable-length payload in every Diameter message. This header provides essential metadata for , , and processing, ensuring interoperability across Diameter nodes. It is transmitted over reliable transport protocols such as TCP or SCTP, where the header's fixed size facilitates initial message boundary detection. The header comprises seven fields: Version, , Command Flags, Command-Code, Application-ID, Hop-by-Hop Identifier, and End-to-End Identifier. The Version field occupies the first octet and is always set to 1, indicating compliance with the Diameter base protocol version defined in RFC 6733; this value ensures and allows future versions to be distinguished if needed. Following this, the field spans three octets and specifies the total length of the Diameter in bytes, encompassing the 20-octet header and all subsequent Attribute-Value Pairs (AVPs) padded to a 4-octet boundary. This length must be a multiple of 4 and at least 20 bytes; values that are non-zero but invalid (e.g., not a multiple of 4 or exceeding transport limits) trigger protocol errors, such as the DIAMETER_INVALID_MESSAGE_LENGTH result code (5015), potentially leading to discard or connection closure. All multi-octet fields, including , use network byte order (big-endian) for consistent interpretation across heterogeneous systems. The Command Flags field, a single octet, contains four defined bit flags that control message semantics and handling, with the remaining four bits reserved and set to zero. Bit 0 (Request, R) is set to 1 for request messages initiating an operation and 0 for answer messages responding to requests; it must not be set in answers. Bit 1 (Proxiable, P) indicates (when 1) that the message may be relayed, proxied, or redirected by intermediate nodes, or (when 0) that it requires local processing only at the destination. Bit 2 (, E) is set to 1 to signal a protocol-level in the message and 0 otherwise; it must not be set in requests. Bit 3 (Potentially retransmitted, T) is set to 1 if the message might be a duplicate due to retransmission and 0 for initial transmissions; it must not be set in answers or error responses. Receivers ignore any non-zero values in the reserved bits, but setting them may result in the DIAMETER_INVALID_HDR_BITS (3008). The Command-Code field occupies three octets and uniquely identifies the operation or command being invoked, such as capabilities exchange or accounting requests. The Application-ID field is a 32-bit unsigned that specifies the Diameter application to which the message applies, with value 0 indicating the base protocol and other values identifying specific applications or vendors. The Hop-by-Hop Identifier and End-to-End Identifier are 32-bit unsigned integers used for correlating requests and answers, as detailed in the Sequence Identifiers subsection.
FieldOctetsDescription
Version1Protocol version (always 1).
Message Length3Total message length in bytes (header + padded AVPs), multiple of 4.
Command Flags1Bit flags: R (request/answer), P (proxiable), E (error), T (retransmitted).
Command-Code3Unique command identifier.
Application-ID4Identifies the Diameter application (0 for base protocol).
Hop-by-Hop Identifier4Matches requests/answers within a hop.
End-to-End Identifier4Uniquely identifies the entire transaction end-to-end.

Command Codes and Flags

The Command-Code field in a Diameter message header is a 24-bit unsigned that identifies the specific command being invoked, enabling up to 16,777,216 unique commands to support extensibility across base and application-specific uses. This field is positioned immediately after the message length and flags in the header, allowing peers to quickly determine the message type for processing. Command codes are assigned and managed by the (IANA) through its Diameter Command Codes registry, with values from 0 to 255 reserved for backward compatibility. Values from 256 to 8,388,607 are allocated via IETF Review for the Diameter base protocol, standards-track, and other IETF applications; higher values up to 16,777,215 are for vendor-defined commands via procedures, requiring documentation of the command's purpose and AVP usage. In the base protocol, request and answer messages for a given command share the same code, distinguished instead by the Request bit in the flags field. The following table lists key base protocol command codes, illustrating their use in core Diameter functions:
Command CodeCommand NamePurpose
257Capabilities-Exchange-Request/Answer (CER/CEA)Negotiate capabilities and parameters during peer connection establishment.
258Re-Auth-Request/Answer (RAR/RAA)Trigger re-authentication or re-authorization of an existing session.
280Device-Watchdog-Request/Answer (DWR/DWA)Monitor the liveness of a peer connection.
282Disconnect-Peer-Request/Answer (DPR/DPA)Gracefully terminate a peer connection.
For application-specific extensions, an example is code 271, used for Accounting-Request/Answer (ACR/ACA) messages in accounting applications to record usage data such as session events or . These codes enable Diameter's , where applications like or policy control define their own commands while adhering to base protocol rules. The Command Flags field, comprising the four most significant bits of the second header octet, modifies the interpretation and handling of the message associated with the Command-Code. The remaining four bits are reserved and must be set to zero. These flags provide essential metadata for routing, error indication, and reliability without altering the core command semantics. The flags are defined as follows:
  • R (Request) bit: Set to 1 for request messages to indicate initiation of a transaction; cleared to 0 for answer messages, signaling completion or response. This bit is mandatory for all base commands and must align with the command's expected direction.
  • P (Proxiable) bit: Set to 1 if the message may be proxied, relayed, or redirected by intermediaries; cleared to 0 for direct delivery only. This supports Diameter's distributed architecture in multi-hop scenarios.
  • E (Error) bit: Set to 1 in answer messages reporting protocol-level errors, such as invalid AVPs or routing failures; never set in requests. When set, the message carries a Result-Code AVP detailing the error.
  • T (Potentially re-transmitted) bit: Set to 1 for messages that may represent retransmissions of unacknowledged requests or duplicates from peer table entries; cleared to 0 otherwise. This aids in duplicate detection and handling during network disruptions.
These flags ensure robust message processing, with violations treated as protocol errors that trigger appropriate answer messages.

Sequence Identifiers

In the Diameter protocol, sequence identifiers play a crucial role in ensuring reliable exchange by facilitating the of requests and responses, detecting duplicates, and maintaining transaction across multi-hop paths. The protocol employs two primary 32-bit unsigned fields in its message header: the Hop-by-Hop Identifier and the End-to-End Identifier. These fields, positioned immediately after the Command Code and Application-ID in the header, enable nodes to track messages without relying on external state, supporting robust operation in distributed , , and (AAA) environments. The Hop-by-Hop Identifier is generated by each Diameter node to uniquely match a request with its corresponding answer within a single hop, ensuring that responses are properly associated even in the presence of transport failures or retransmissions. It is initialized to a random value at the start of a connection and incremented monotonically for each subsequent message sent over that peer connection, remaining locally unique across reboots where feasible to avoid collisions. This identifier is preserved and restored by or proxy agents during message forwarding, allowing them to maintain pending transaction queues and detect unmatched responses. Upon establishing a new connection to the same peer—such as after a or reconnection—the Hop-by-Hop Identifier sequence is reset, starting fresh to align with the new session. Complementing this, the End-to-End Identifier is set by the originating node for each request and remains unchanged throughout the entire transaction path, providing a session-wide unique tag that spans multiple hops. Designed to be locally unique for at least four minutes (even across node reboots), it is typically constructed by combining a in the high-order bits with a random value in the lower bits, ensuring low probability of duplication within a . Receivers use this identifier in conjunction with the Origin-Host AVP to identify and discard duplicate messages, preventing redundant that could arise from retransmissions or anomalies. Like the Hop-by-Hop Identifier, it is reset upon new peer connections but is primarily managed at the transaction level rather than per hop. Together, these identifiers enforce at-most-once delivery semantics, where messages are processed no more than once per transaction, and contribute to loop prevention by enabling nodes to track message alongside the Route-Record AVP—though the identifiers themselves focus on correlation and deduplication rather than explicit routing loops. This design minimizes state overhead while providing essential safeguards for Diameter's model, particularly in high-availability scenarios involving and load balancing.

Attribute-Value Pairs (AVPs)

Attribute-Value Pairs (AVPs) serve as the primary mechanism for carrying extensible data within Diameter messages, enabling the transport of , , , and other protocol-specific information between peers. Following the fixed Diameter message header, one or more AVPs form the variable-length , allowing for flexible encoding of parameters required by the base protocol and its applications. This supports the protocol's extensibility, where new AVPs can be defined without altering the core message format. The structure of an AVP consists of a header and a data field. The header includes a 32-bit AVP Code, which is assigned by IANA to uniquely identify the attribute; an 8-bit AVP Flags field; and a 24-bit AVP Length field indicating the total length of the AVP in octets, including the header and data. If the Vendor-Specific flag is set, a 32-bit Vendor-ID follows the flags. The data field is variable-length and type-specific, padded with zeros to align on 4-octet boundaries to ensure efficient processing. All multi-octet fields, including the AVP Code, Length, and data (where applicable), are encoded in network byte order. Grouped AVPs, a special type, allow nesting of other AVPs within the data field to represent complex structures logically. AVP data types are defined to handle diverse information, categorized into basic types such as (32-bit signed ), Unsigned64 (64-bit unsigned ), UTF8String (UTF-8 encoded string), and OctetString (arbitrary octet sequence), as well as derived types like DiameterIdentity (a realm-qualified ) and Enumerated ( values with defined meanings). These types ensure precise representation of protocol elements, with grouped types facilitating hierarchical organization. The AVP Flags field uses specific bits to guide receiver behavior: the Mandatory (M) bit (bit 1) requires the AVP to be recognized and processed, triggering an error (e.g., DIAMETER_AVP_UNSUPPORTED) if unknown; the Vendor-Specific (V) bit (bit 0) indicates vendor-defined extensions; bits 2-7 are reserved and must be set to 0. The remaining bits are reserved and ignored. Over 200 standard AVPs have been defined across IETF specifications, with the base protocol alone specifying 47 core ones for essential functions like session management and error reporting. The mandatory flag enforces critical processing, while non-mandatory unknown AVPs can be safely ignored, promoting .
Flag BitNameDescription
0V (Vendor-Specific)If set, includes a Vendor-ID; denotes vendor-specific AVP.
1M (Mandatory)If set, receiver must understand and process; unknown triggers .
2-7ReservedMust be 0; receiver ignores.

Operational Behavior

State Machines

The Diameter base protocol defines finite state machines to manage peer connections, user sessions, and recovery procedures, ensuring reliable and ordered interactions between nodes. These state machines are essential for maintaining the protocol's nature and handling dynamic network conditions. The base protocol mandates three primary state machines: the peer state machine for connection management, the session state machine for user , and the session state machine for resource tracking, with procedures integrated into the peer and state machines.

Peer State Machine

The peer state machine governs the lifecycle of connections between Diameter nodes, starting from initiation to graceful termination. It operates independently of transport protocols but triggers actions based on events like incoming messages or timeouts. Stable states include Closed (no active connection), I-Open (initiator open), and R-Open (responder open), with intermediate states facilitating transitions. Key states and transitions are outlined below:
StateDescriptionTransitions and Triggers
ClosedNo connection exists; initial or post-termination state.To Wait-Conn-Ack via connection initiation event.
Wait-Conn-AckLocal node attempts to establish a connection as originator; awaiting acknowledgment of outgoing connection request.To Wait-I-CEA via received connection acknowledgment, then send CER.
Wait-I-CEAAwaiting Capabilities-Exchange-Answer (CEA) after sending Capabilities-Exchange-Request (CER).To I-Open via successful CEA processing.
Open (I-Open/R-Open)Connection established and capabilities exchanged; normal operational state.To Closed via DPR/DPA for graceful shutdown or watchdog failure.
Transitions rely on capability exchange via CER and CEA messages to negotiate features and roles, ensuring compatibility before entering the Open state. Device-Watchdog-Request (DWR) and Device-Watchdog-Answer (DWA) messages maintain liveness in the Open state by periodic heartbeats, with failure to respond triggering a transition to Closed and potential . Electability during connection setup allows peers to dynamically determine roles (e.g., primary or secondary initiator) by comparing Origin-Host values in CER messages, with the lexicographically lower value winning and retaining the connection; this prevents loops in multi-peer scenarios. Recovery emphasizes graceful closure using Disconnect-Peer-Request (DPR) and Disconnect-Peer-Answer (DPA) to terminate sessions cleanly, preserving message ordering and minimizing .

Session State Machines

Session state machines handle per-user interactions, tracking and independently of peer connections. They use identifiers like Session-Id for authorization and Acct-Session-Id for accounting to correlate events across nodes. These machines support both stateful (full session tracking) and stateless (no persistent state) modes, depending on the Diameter application. The authorization session state machine maintains user sessions through states such as (pre-session), Open (active authorization), and Disconnected (termination pending). It manages timeouts via Authorization-Lifetime to enforce session duration and Auth-Grace-Period for graceful re-authentication extensions, preventing abrupt expirations. Re-authentication is initiated server-side using Re-Auth-Request (RAR) and Re-Auth-Answer (RAA) messages, allowing dynamic updates without session disruption; the machine transitions based on Re-Auth-Request-Type AVP values like AUTHORIZE_ONLY or TERMINATE. Client and server variants differ in state persistence, with stateful modes required for applications needing full lifecycle tracking. The session state machine similarly uses , Open, and Disconnected states to record resource usage, supporting record types like START_RECORD (session initiation), INTERIM_RECORD (periodic updates), and STOP_RECORD (termination). It handles timeouts through Acct-Interim-Interval for interim reporting, ensuring continuous tracking even during network interruptions; upon recovery, sessions resume from the last known state using Origin-State-Id for synchronization. This machine is crucial for billing and auditing, with stateful operation optional but recommended for reliable aggregation across peers in scenarios such as real-time required accounting.

Message Processing Flows

Diameter message processing flows define the sequence of request and answer exchanges between peers to establish connections, authenticate users, authorize services, and record accounting data. These flows operate within the peer-to-peer model, leveraging transport layers like SCTP or TCP for reliable delivery, and are triggered by state machines that manage peer relationships. The capabilities exchange flow initiates peer connections by negotiating supported features. A Diameter client sends a Capabilities-Exchange-Request (CER) message, identified by Command Code 257 with the 'R' bit set in the header flags, containing mandatory AVPs such as Origin-Host, Origin-Realm, Host-IP-Address, Vendor-Id, and Product-Name, along with optional AVPs like Supported-Vendor-Id, Auth-Application-Id, and Acct-Application-Id to advertise supported vendors and applications. The responding server replies with a Capabilities-Exchange-Answer (CEA) message, mirroring the CER's structure but including a Result-Code AVP (e.g., 2001 for DIAMETER_SUCCESS) to confirm compatibility, and may include Error-Message or Failed-AVP if discrepancies arise. This exchange ensures peers agree on vendor-specific AVPs and application identifiers before proceeding to application-level interactions, without involving proxying or redirection. For authentication, authorization, and accounting (AAA) operations, the flow begins with an application-specific request, such as an request, sent from a client to a server via the Destination-Realm AVP for realm-based and optionally Destination-Host for direct targeting. The server processes the request and responds with an answer message containing a Result-Code AVP indicating outcomes, such as 2001 for success or values in the 3000 series for protocol errors. In proxying scenarios, agents forward the request unchanged except for non-routing AVPs, while proxy agents may insert Route-Record and Proxy-Info AVPs to track the path and add policy enforcement, replacing the Hop-by-Hop Identifier to maintain transaction integrity. The answer traverses the reverse path, restoring original identifiers, enabling multi-hop support for distributed AAA services. Accounting flows use Accounting-Request (ACR) and Accounting-Answer (ACA) messages, both with Command Code 271, to record session events in sequences that support real-time or . An ACR with Accounting-Record-Type AVP set to 1 (START) initiates a session, including Acct-Session-Id and optionally Acct-Multi-Session-Id for grouped sessions; the server acknowledges with an ACA containing Result-Code 2001. Interim updates follow at intervals specified by Acct-Interim-Interval AVP (e.g., every 600 seconds), using Accounting-Record-Type 3, with Accounting-Record-Number AVP ensuring sequence integrity. The sequence concludes with an ACR of type 4 (STOP), capturing final usage data, confirmed by ACA. These flows inherently support asynchronous operations, allowing peers to process independently without blocking, as managed by state machines in states like PendingS or PendingI. Retransmissions ensure reliability using the Hop-by-Hop Identifier in the header to match requests and answers, with the set on retransmitted messages; duplicates are detected via the End-to-End Identifier combined with Origin-Host AVP. Upon transport failure, pending are queued and forwarded to alternate peers with the , preventing loss in scenarios.

Error Handling

The Diameter protocol employs a structured approach to error handling, utilizing result codes in answer messages to indicate the outcome of request processing. These codes are categorized into success, protocol errors, transient failures, and permanent failures, as defined in RFC 6733 and aligned with 3GPP specifications, enabling peers to distinguish between recoverable and irrecoverable conditions. Success is denoted by codes in the 2000-2999 range, with 2001 (DIAMETER_SUCCESS) signaling normal completion without errors. Protocol errors (3000-3999), which are transient and handled hop-by-hop (often with the 'E' bit set), may allow rerouting, such as 3002 (DIAMETER_UNABLE_TO_DELIVER) for routing failures where no upstream server supports the application or route exists. Transient failures (4000-4999) permit retries on the same peer, for example 4001 (DIAMETER_AUTHENTICATION_REJECTED). Permanent errors, indicating non-recoverable issues, use the 5000-5999 range, like 5001 (DIAMETER_AVP_UNSUPPORTED) when an unrecognized AVP is encountered. This classification supports appropriate recovery actions, with 3xxx codes potentially prompting rerouting, 4xxx retries on the same peer, and 5xxx halting further attempts. Error messages are conveyed through specific flags and AVPs in Diameter answers, differentiating protocol-level issues from application-specific ones. The 'E' flag in the message header is set for protocol errors, such as invalid message formatting or routing problems, requiring hop-by-hop resolution; it remains unset for application errors, like authentication rejections, which are handled end-to-end. Accompanying the result code, the Error-Message AVP (code 281) provides a human-readable string describing the error for diagnostic purposes. Additionally, the Failed-AVP (code 279) encapsulates the offending AVP to aid , while the Error-Reporting-Host AVP (code 294) identifies the originating peer. Asynchronous error notifications occur via server-initiated messages, such as Abort-Session-Request or Session-Termination-Request, incorporating these AVPs to inform clients of session-related failures without pending transactions. Recovery from errors emphasizes reliability through retransmission and redundancy mechanisms. The transport layer, using TCP or SCTP, manages retransmissions with a default Tc timer of 30 seconds; upon timeout or transient errors like DIAMETER_TOO_BUSY (indicating overload), clients may resend requests. For peer unavailability, failover to alternate servers is supported by maintaining transaction state and the 'T' (potentially re-transmittable) flag in requests, allowing agents to reroute pending messages upon detecting transport failures or codes like 3002. Failback re-establishes connections to recovered peers, ensuring continuity in peer-to-peer communications. These procedures minimize disruptions in AAA operations while correlating errors using end-to-end and hop-by-hop identifiers for traceability.
CategoryResult-Code RangeExample Code and MeaningRecovery Implication
Success2000-29992001 (DIAMETER_SUCCESS): Normal completionNone required
Protocol Errors (Transient)3000-39993002 (DIAMETER_UNABLE_TO_DELIVER): No routeReroute or to alternate peer
Transient Failures4000-49994001 (DIAMETER_AUTHENTICATION_REJECTED): Authentication rejectedRetry on same peer
Permanent Errors5000-59995001 (DIAMETER_AVP_UNSUPPORTED): Invalid AVPCease attempts; log for diagnostics

Standards

Base Protocol Specifications

The base protocol specifications for the Diameter protocol are defined through key (RFC) documents published by the (IETF), establishing the foundational framework for , , and (AAA) operations. These specifications outline the core message structure, transport mechanisms, and peer-to-peer interactions required for Diameter implementations. RFC 6733, titled "Diameter Base Protocol" and published in October 2012 as a Proposed Standard, serves as the primary current specification, obsoleting RFC 3588 and providing comprehensive details on the protocol header, Attribute-Value Pairs (AVPs), and state machines. It introduces enhancements such as support for Stream Control Transmission Protocol (SCTP) as a transport option and clarifications on security considerations, including improved handling of Transport Layer Security (TLS). As of November 2025, RFC 6733 remains the active base protocol without further obsoletions. Earlier foundational documents include RFC 3588, "Diameter Base Protocol" from September 2003 (also Proposed Standard), which formed the initial core specification but was superseded by RFC 6733 due to errata and updates. Complementing this, RFC 3539, "Authentication, Authorization and Accounting (AAA) Transport Profile" from June 2003 (Proposed Standard), addresses transport-related issues for AAA protocols, including , such as reliability and congestion control. The following table summarizes the core RFCs for the Diameter base protocol specifications:
RFC NumberTitlePublication DateStatus
6733 Base ProtocolOctober 2012Proposed Standard
3588 Base ProtocolSeptember 2003Obsoleted (by RFC 6733)
3539, and (AAA) Transport ProfileJune 2003Proposed Standard

Application and Extension RFCs

The Diameter protocol extends its base framework through specialized applications and extensions, each defined in dedicated RFCs to support domain-specific use cases such as network access, , and session initiation. These applications are identified by a unique 32-bit Application-ID field in the Diameter message header, with the (IANA) maintaining the official registry of assigned values. While the base protocol provides the foundational and mechanisms, these RFCs define command codes, attribute-value pairs (AVPs), and procedures tailored to particular , , and (AAA) scenarios. Key Diameter applications and extensions have been standardized primarily through the IETF's Diameter Maintenance and Extensions (DIME) working group, with some alignment to specifications for domains like (IMS). The DIME WG was concluded in March 2024 after publishing several enhancements. For instance, RFC 4005 specifies the NASREQ application for AAA interactions with network access servers, while RFC 4072 enables the transport of (EAP) messages over Diameter. In contexts, RFC 4740 defines the Cx interface application for SIP-based and in IMS, though much of the detailed IMS implementation relies on Technical Specifications (TS). Similarly, RFC 5779 outlines Diameter support for Proxy Mobile IPv6 (PMIPv6), facilitating AAA between mobile access gateways and servers. More recent extensions include RFC 8583 for Diameter load information conveyance (May 2019) and RFC 9390 for Diameter group signaling (April 2023). The following table summarizes selected seminal RFCs for Diameter applications and extensions:
RFC NumberTitlePublication DateApplication Focus
4005Diameter Network Access Server ApplicationAugust 2005AAA for network access servers (NASREQ)
4072Diameter Extensible Authentication Protocol (EAP) ApplicationAugust 2005EAP payload transport for authentication
4740Diameter Session Initiation Protocol (SIP) ApplicationAugust 2007SIP/IMS Cx interface for user authentication and service authorization
5779Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter ServerFebruary 2010AAA support for PMIPv6 mobility management
8583Diameter Load Information ConveyanceMay 2019Conveyance of load information between Diameter nodes
9390Diameter Group SignalingApril 2023Support for group-based signaling in Diameter
7423Diameter Applications Design GuidelinesJanuary 2015Best practices for developing and extending Diameter applications
As of November 2025, RFC 7423 remains a key guidance document for Diameter application design, with standardization efforts concluding with the DIME WG's closure in 2024.

References

  1. https://datatracker.ietf.org/doc/html/rfc6733
  2. https://datatracker.ietf.org/doc/html/rfc2989
  3. https://datatracker.ietf.org/doc/html/rfc6733#section-1.1
  4. https://datatracker.ietf.org/doc/html/rfc6733#section-5
  5. https://datatracker.ietf.org/doc/html/rfc6733#section-1
  6. https://datatracker.ietf.org/doc/html/rfc6733#section-2.1
  7. https://datatracker.ietf.org/doc/html/rfc6733#section-2.8
  8. https://datatracker.ietf.org/doc/html/rfc6733#section-9.4
  9. https://datatracker.ietf.org/doc/html/rfc6733#section-4.1
  10. https://datatracker.ietf.org/doc/html/rfc6733#section-1.3
  11. https://datatracker.ietf.org/doc/html/rfc6733#section-5.2
  12. https://datatracker.ietf.org/doc/html/draft-pan-diameter-sip-01
  13. https://datatracker.ietf.org/doc/rfc3588/
  14. https://datatracker.ietf.org/doc/rfc6733/
  15. https://www.3gpp.org/ftp/tsg_t/tsg_t/TSGT_12/docs/PDFs/TP-010146.pdf
  16. https://www.private-lte.net/diameter-protocol-in-4g-lte/
  17. https://titaniumplatform.com/news-insights/diameter-protocol
  18. https://datatracker.ietf.org/doc/rfc8582/
  19. https://datatracker.ietf.org/doc/html/rfc6733#section-6.1
  20. https://datatracker.ietf.org/doc/html/rfc6733#section-7.1.1
  21. https://datatracker.ietf.org/doc/html/rfc6733#section-9
  22. https://datatracker.ietf.org/doc/html/rfc6733#section-8
  23. https://datatracker.ietf.org/doc/html/rfc6733#section-8.11
  24. https://datatracker.ietf.org/doc/html/rfc6733#section-9.5
  25. https://datatracker.ietf.org/doc/html/rfc6733#section-1.2
  26. https://datatracker.ietf.org/doc/html/rfc6733#section-6
  27. https://datatracker.ietf.org/doc/html/rfc6733#section-2
  28. https://www.rfc-editor.org/rfc/rfc4005.html
  29. https://ribboncommunications.com/company/get-help/glossary/diameter-protocol
  30. https://www.f5.com/glossary/diameter-protocol
  31. https://www.revesoft.com/blog/telecom/diameter-protocol/
  32. https://www.3gpp.org/technologies/5g-system-overview
  33. https://www.futuremarketinsights.com/reports/diameter-signaling-market
  34. https://www.linkedin.com/pulse/beyond-radius-deep-dive-diameter-unsung-hero-4g-5g-networks-cidade-loyif
  35. https://cibersafety.com/en/diameter-protocol-architecture-agents-balancing-security/
  36. https://www.3gpp.org/ftp/Specs/archive/29_series/29.561/
  37. https://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#diameter-application-ids
  38. https://www.3gpp.org/dynareport/29229.htm
  39. https://www.3gpp.org/dynareport/29212.htm
  40. https://www.3gpp.org/dynareport/29214.htm
  41. https://datatracker.ietf.org/doc/html/rfc4006
  42. https://datatracker.ietf.org/doc/html/rfc6733#section-1.3.4
  43. https://datatracker.ietf.org/doc/html/rfc6733#section-2.2
  44. https://datatracker.ietf.org/doc/html/rfc6733#section-13.1
  45. https://datatracker.ietf.org/doc/html/rfc6733#section-12
  46. https://datatracker.ietf.org/doc/html/rfc6733#section-2.7
  47. https://datatracker.ietf.org/doc/html/rfc6733#section-6.1.6
  48. https://datatracker.ietf.org/doc/html/rfc6733#section-2.8.1
  49. https://datatracker.ietf.org/doc/html/rfc6733#section-2.8.2
  50. https://datatracker.ietf.org/doc/html/rfc6733#section-2.8.3
  51. https://datatracker.ietf.org/doc/html/rfc6733#section-5.3
  52. https://datatracker.ietf.org/doc/html/rfc6733#section-3.1
  53. https://datatracker.ietf.org/doc/html/rfc6733#appendix-B
  54. https://datatracker.ietf.org/doc/html/rfc6733#section-2.1.1
  55. https://datatracker.ietf.org/doc/html/rfc6733#section-11.4
  56. https://datatracker.ietf.org/doc/html/rfc6733#section-6.3
  57. https://datatracker.ietf.org/doc/html/rfc6733#section-6.4
  58. https://datatracker.ietf.org/doc/html/rfc6733#section-6.5
  59. https://datatracker.ietf.org/doc/html/rfc6733#section-6.6
  60. https://datatracker.ietf.org/doc/html/rfc6733#section-6.7
  61. https://datatracker.ietf.org/doc/html/rfc6733#section-5.5
  62. https://datatracker.ietf.org/doc/html/rfc6733#section-5.4
  63. https://datatracker.ietf.org/doc/html/rfc6733#section-13
  64. https://datatracker.ietf.org/doc/html/rfc6733#section-3
  65. https://datatracker.ietf.org/doc/html/rfc6733#section-6.2
  66. https://datatracker.ietf.org/doc/html/rfc6733#section-3.2
  67. https://datatracker.ietf.org/doc/html/rfc6733#section-7.2
  68. https://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#diameter-command-codes
  69. https://datatracker.ietf.org/doc/html/rfc6733#section-11.2.1
  70. https://datatracker.ietf.org/doc/html/rfc6733#section-5.6
  71. https://datatracker.ietf.org/doc/html/rfc6733#section-9.7
  72. https://datatracker.ietf.org/doc/html/rfc6733#section-11.2
  73. https://datatracker.ietf.org/doc/html/rfc6733#section-7
  74. https://datatracker.ietf.org/doc/html/rfc6733#section-6.1.9
  75. https://datatracker.ietf.org/doc/html/rfc6733#section-6.1.3
  76. https://www.rfc-editor.org/rfc/rfc6733.html
  77. https://www.rfc-editor.org/rfc/rfc6733.html#section-4.1
  78. https://www.rfc-editor.org/rfc/rfc6733.html#section-4.2
  79. https://www.rfc-editor.org/rfc/rfc6733.html#section-4.4
  80. https://www.rfc-editor.org/rfc/rfc6733.html#section-7
  81. https://datatracker.ietf.org/doc/html/rfc6733#section-5.5.4
  82. https://datatracker.ietf.org/doc/html/rfc6733#section-5.6.4
  83. https://datatracker.ietf.org/doc/html/rfc6733#section-8.1
  84. https://datatracker.ietf.org/doc/html/rfc6733#section-8.3
  85. https://datatracker.ietf.org/doc/html/rfc6733#section-8.10
  86. https://datatracker.ietf.org/doc/html/rfc6733#section-8.12
  87. https://datatracker.ietf.org/doc/html/rfc6733#section-8.13
  88. https://datatracker.ietf.org/doc/html/rfc6733#section-8.2
  89. https://datatracker.ietf.org/doc/html/rfc6733#section-9.8
  90. https://datatracker.ietf.org/doc/html/rfc6733#section-8.6
  91. https://datatracker.ietf.org/doc/html/rfc6733#section-5.3.6
  92. https://datatracker.ietf.org/doc/html/rfc6733#section-6.1.1
  93. https://datatracker.ietf.org/doc/html/rfc6733#section-6.7.1
  94. https://datatracker.ietf.org/doc/html/rfc6733#section-9.8.2
  95. https://datatracker.ietf.org/doc/html/rfc6733#section-7.1.2
  96. https://datatracker.ietf.org/doc/html/rfc6733#section-7.1.3
  97. https://datatracker.ietf.org/doc/html/rfc6733#section-7.1.5
  98. https://datatracker.ietf.org/doc/html/rfc6733#section-8.4
  99. https://datatracker.ietf.org/doc/html/rfc3539
  100. https://datatracker.ietf.org/doc/html/rfc4072
  101. https://datatracker.ietf.org/doc/html/rfc8583
  102. https://datatracker.ietf.org/doc/html/rfc9390
  103. https://datatracker.ietf.org/doc/html/rfc7423
Add your contribution
Related Hubs
User Avatar
No comments yet.