Diameter is an authentication, authorization, and accounting protocol for computer networks.

It
evolved from and replaces the much less capable RADIUS protocol that preceded it.
Diameter Applications extend the base protocol by adding new commands and/or attributes, such
as those for use of 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 backwards compatible but provides an
upgrade path for RADIUS. The main features provided by Diameter but lacking in RADIUS are:

Reliable transport protocols (TCP or SCTP, not UDP)

o The IETF is in the process of standardizing TCP Transport for RADIUS

Network or transport layer security (IPsec or TLS)

o The IETF is in the process of standardizing Transport Layer Security for RADIUS

Transition support for RADIUS, although Diameter is not fully compatible with RADIUS

Larger address space for attribute-value pairs (AVPs) and identifiers (32 bits instead of 8
bits)

Clientserver protocol, with exception of supporting some server-initiated messages as

well

Both stateful and stateless models can be used

Dynamic discovery of peers (using DNS SRV and NAPTR)

Capability negotiation

Supports application layer acknowledgements, defines failover methods and state

machines (RFC 3539)

Error notification

Better roaming support

More easily extended; new commands and attributes can be defined

Aligned on 32-bit boundaries

Basic support for user-sessions and accounting

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). 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:

Diameter Mobile IPv4 Application (MobileIP, RFC 4004)

Diameter Network Access Server Application (NASREQ, RFC 4005)

Diameter Extensible Authentication Protocol Application (RFC 4072)

Diameter Credit-Control Application (DCCA, 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. 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.[1]
Like RADIUS, Diameter provides AAA functionality, but it is using TCP and SCTP instead of
UDP, therefore logic for detection of communication problems is not included in the Diameter
protocol itself. The Diameter protocol is enhanced further by the development of the 3rd
Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS). The Cx, Dh, Dx, Rf,
Ro, and Sh 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 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[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
32

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

version

message length

command code

64

application ID

96

hop-by-hop ID

128

end-to-end ID

160
...

AVPs
...

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 ABNF 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 is assigned a command code, which is used for both Requests and Answers.
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.

Some common Diameter commands are:

Command-Name

Abbr.

Code

AA-Request

AAR

265

AA-Answer

AAA

265

Diameter-EAP-Request

DER

268

Diameter-EAP-Answer

DEA

268

Abort-Session-Request

ASR

274

Abort-Session-Answer

ASA

274

Accounting-Request

ACR

271

Accounting-Answer

ACA

271

Credit-Control-Request

CCR

272

Credit-Control-Answer

CCA

272

Capabilities-Exchange-Request

CER

257

Capabilities-Exchange-Answer

CEA

257

Device-Watchdog-Request

DWR

280

Device-Watchdog-Answer

DWA

280

Disconnect-Peer-Request

DPR

282

Disconnect-Peer-Answer

DPA

282

Re-Auth-Request

RAR

258

Re-Auth-Answer

RAA

258

Session-Termination-Request

STR

275

Session-Termination-Answer

STA

275

User-Authorization-Request

UAR

300

User-Authorization-Answer

UAA

300

Server-Assignment-Request

SAR

301

Server-Assignment-Answer

SAA

301

Command-Name

Abbr.

Code

Location-Info-Request

LIR

302

Location-Info-Answer

LIA

302

Multimedia-Auth-Request

MAR

303

Multimedia-Auth-Answer

MAA

303

Registration-Termination-Request

RTR

304

Registration-Termination-Answer

RTA

304

Push-Profile-Request

PPR

305

Push-Profile-Answer

PPA

305

User-Data-Request

UDR

306

User-Data-Answer

UDA

306

Profile-Update-Request

PUR

307

Profile-Update-Answer

PUA

307

Subscribe-Notifications-Request

SNR

308

Subscribe-Notifications-Answer

SNA

308

Push-Notification-Request

PNR

309

Push-Notification-Answer

PNA

309

Bootstrapping-Info-Request

BIR

310

Bootstrapping-Info-Answer

BIA

310

Message-Process-Request

MPR

311

Message-Process-Answer

MPA

311

Update-Location-Request

ULR

316

Update-Location-Answer

ULA

316

Authentication-Information-Request

AIR

318

Authentication-Information-Answer

AIA

318

Notify-Request

NR

323

Notify-Answer

NA

323

Command-Name

Abbr.

Code

This section requires expansion. (December 2009)

Attribute-Value Pairs (AVP)[edit]
AVP Header
Bit
offset

0
32

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

AVP code
V

AVP length

64

vendor ID (optional)

96
...

data
...

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-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

UTF8String

Vendor-Id

266

Unsigned32

Vendor-Specific-Application-Id

260

Grouped

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-WatchdogRequest (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.

Diameter Credit-Control Application, is a networking protocol for Diameter application used

to implement real-time credit-control for a variety of end user services.
It is an IETF standard defined in RFC 4006.
Purpose[edit]

The purpose of the diameter credit control application is to provide a framework for real-time
charging, primarily meant for the communication between gateways/control-points and the backend account/balance systems (typically an Online Charging System).
The application specifies methods for:

Quota management (Reserve, Reauthorize, Abandon)

Simple Debit/Credit

Balance checks

Price inquiries

The diameter credit control application does not specify which type units are bought/used and
which items are charged. This is left to the service context that have to be specified separately, as
is some of the semantics.
Examples of units used/bought:

Time

Upload/Download bytes

SMS (Text Messages)

Examples of items charged:

Money

Points

Units (e.g. if the balance is kept in the same units as what is being used)

Diameter credit control also specifies how to handle the fairly complex issue of multiple unit
types used/charged against a single user balance. For instance, a user may pay for both online
time and download bytes but has only a single account balance.

Session-based charging[edit]

A session-based credit control process uses several interrogations which may include first,
intermediate and last interrogation. During interrogation money is reserved from the user
account. Session-based charging is typically used for scenarios where the charged units are
continuously consumed, e.g. charging for bytes upload/download.
Event-based charging[edit]

An event-based credit control process uses events as charging mechanism. Event-based charging
is typically used when units are not continuously consumed, e.g. a user sending an MMS.
Command Codes[edit]

In order to support Credit Control via Diameter, there are two Diameter messages, the CCR
(Credit Control Request) and the CCA (Credit Control Answer). Command Code for CCR/CCA
is 272, as defined in RFC 4006
For quota management the client sends CCR to the server requesting units and reporting
consumption. The server grants units and charges the user. For simple debit/credit the client
sends a CCR asking the server to credit/debit the user's account. For price inquiries the client ask
the server what the price for a unit is, and the server responds with the price.
Message flows[edit]

The message flows are in general driven by the control-point asking for units and the server
granting them. The message may also be generated by other diameter applications, such as
NASREQ (RFC4005) for sessions that are time/usage-limited.
The following diagram shows a simplified message flow for a session using quota grants.

The client starts by requesting 10 units from the server. The server verifies that the
user/subscriber has enough balance for it. In this example the server grants the client all the units
it requested. if the subscriber had insufficient balance it could have granted less units or rejected
it completely.
When or before the subscriber session has used the granted units the client sends an update to the
server telling it how many units have been used and how many it would like granted this time.
The client is allowed to request units before the previous grant is completely used, in order to
avoid suspending the subscriber session while talking to the server. In this example the client
sends the request when 7 units of the 10 previously granted units have been used; and ask for 10
more units, which the server grants. The server can use the used-units count for debiting the
subscriber balance (granting units does not indicate that they will be used. The Used-Units AVP
contains the actual usage). It is also possible for the server to tell the client how long the grant is
valid, in which case the client is expected to send an update when the grant timer expires.
There can be many update messages during a session.
Finally, the subscriber has ended the session, and the client sends a termination message to the
server containing the last Used-Units. The server can use the termination message to clear any
related reservations made in the back-end balance management system. If the subscriber did not
terminate the session himself but instead depleted his balance then the server would have
responded earlier with reject to an update message, possibly telling the client/control-point to
redirect traffic (this normally only makes sense for HTTP/WAP traffic).
AVP matrix[edit]
AVPs for new command codes[edit]

The new Command codes, CCA and CCR, may require some AVPs as indicated below. Bold
AVPs are new to DCCA.
Command Code
Attribute Name

CCR

CCA

Acct-Multi-Session-Id

0-1

0-1

Auth-Application-Id

CC-Correlation-Id

0-1

CC-Session-Failover

0-1

CC-Request-Number

CC-Request-Type

CC-Sub-Session-Id

0-1

0-1

Check-Balance-Result

0-1

Cost-Information

0-1

Credit-Control-Failure-Handling

0-1

Destination-Host

0-1

Destination-Realm

Direct-Debiting-Failure-Handling

0-1

Event-Timestamp

0-1

0-1

Failed-AVP

0+

Final-Unit-Indication

0-1

Granted-Service-Unit

0-1

Multiple-Services-Credit-Control

0+

0+

Multiple-Services-Indicator

0-1

Origin-Host

Origin-Realm

Origin-State-Id

0-1

0-1

Proxy-Info

0+

0+

Redirect-Host

0+

Redirect-Host-Usage

0-1

Redirect-Max-Cache-Time

0-1

Requested-Action

0-1

Requested-Service-Unit

0-1

Route-Record

0+

0+

Result-Code

Service-Context-Id

Service-Identifier

0-1

Service-Parameter-Info

0+

Session-Id

Subscription-Id

0+

Termination-Cause

0-1

User-Equipment-Info

0-1

Used-Service-Unit

0+

User-Name

0-1

0-1

Validity-Time

0-1

New AVPs for base protocol command codes[edit]

Command Code
Attribute Name

RAR

RAA

CC-Sub-Session-Id

0-1

0-1

G-S-U-Pool-Identifier

0-1

0-1

Service-Identifier

0-1

0-1

Rating-Group

0-1

0-1

The table uses the following symbols:

0 The AVP MUST NOT be present in the message

0+ Zero or more instances of the AVP MAY be present in the message

0-1 Zero or one instance of the AVP MAY be present in the message. It is
considered an error if there is more than one instance of the AVP

1 One instance of the AVP MUST be present in the message

1+ At least one instance of the AVP MUST be present in the message