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) The IETF is in the process of standardizing TCP Transport for RADIUS Network or transport layer security (IPsec or TLS) 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 accountingApplications[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 SubsystemBoth the HSS and the SLF communicate using the Diameter protocol.(Generic Bootstrapping Architecture): Bootstrapping Server FunctionHistory[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 offset012345678910111213141516171819202122232425262728293031

0versionmessage length

32RPETcommand code

64application ID

96hop-by-hop ID

128end-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-NameAbbr.Code

AA-RequestAAR265

AA-AnswerAAA265

Diameter-EAP-RequestDER268

Diameter-EAP-AnswerDEA268

Abort-Session-RequestASR274

Abort-Session-AnswerASA274

Accounting-RequestACR271

Accounting-AnswerACA271

Credit-Control-RequestCCR272

Credit-Control-AnswerCCA272

Capabilities-Exchange-RequestCER257

Capabilities-Exchange-AnswerCEA257

Device-Watchdog-RequestDWR280

Device-Watchdog-AnswerDWA280

Disconnect-Peer-RequestDPR282

Disconnect-Peer-AnswerDPA282

Re-Auth-RequestRAR258

Re-Auth-AnswerRAA258

Session-Termination-RequestSTR275

Session-Termination-AnswerSTA275

User-Authorization-RequestUAR300

User-Authorization-AnswerUAA300

Server-Assignment-RequestSAR301

Server-Assignment-AnswerSAA301

Location-Info-RequestLIR302

Location-Info-AnswerLIA302

Multimedia-Auth-RequestMAR303

Multimedia-Auth-AnswerMAA303

Registration-Termination-RequestRTR304

Registration-Termination-AnswerRTA304

Push-Profile-RequestPPR305

Push-Profile-AnswerPPA305

User-Data-RequestUDR306

User-Data-AnswerUDA306

Profile-Update-RequestPUR307

Profile-Update-AnswerPUA307

Subscribe-Notifications-RequestSNR308

Subscribe-Notifications-AnswerSNA308

Push-Notification-RequestPNR309

Push-Notification-AnswerPNA309

Bootstrapping-Info-RequestBIR310

Bootstrapping-Info-AnswerBIA310

Message-Process-RequestMPR311

Message-Process-AnswerMPA311

Update-Location-RequestULR316

Update-Location-AnswerULA316

Authentication-Information-RequestAIR318

Authentication-Information-AnswerAIA318

Notify-RequestNR323

Notify-AnswerNA323

This section requires expansion. (December 2009)

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

Bit offset012345678910111213141516171819202122232425262728293031

0AVP code

32VMPAVP length

64vendor 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-NameCodeData Type

Acct-Interim-Interval85Unsigned32

Accounting-Realtime-Required483Enumerated

Acct-Multi-Session-Id50UTF8String

Accounting-Record-Number485Unsigned32

Accounting-Record-Type480Enumerated

Accounting-Session-Id44OctetString

Accounting-Sub-Session-Id287Unsigned64

Acct-Application-Id259Unsigned32

Auth-Application-Id258Unsigned32

Auth-Request-Type274Enumerated

Authorization-Lifetime291Unsigned32

Auth-Grace-Period276Unsigned32

Auth-Session-State277Enumerated

Re-Auth-Request-Type285Enumerated

Class25OctetString

Destination-Host293DiamIdent

Destination-Realm283DiamIdent

Disconnect-Cause273Enumerated

E2E-Sequence300Grouped

Error-Message281UTF8String

Error-Reporting-Host294DiamIdent

Event-Timestamp55Time

Experimental-Result297Grouped

Experimental-Result-Code298Unsigned32

Failed-AVP279Grouped

Firmware-Revision267Unsigned32

Host-IP-Address257Address

Inband-Security-Id299Unsigned32

Multi-Round-Time-Out272Unsigned32

Origin-Host264DiamIdent

Origin-Realm296DiamIdent

Origin-State-Id278Unsigned32

Product-Name269UTF8String

Proxy-Host280DiamIdent

Proxy-Info284Grouped

Proxy-State33OctetString

Redirect-Host292DiamURI

Redirect-Host-Usage261Enumerated

Redirect-Max-Cache-Time262Unsigned32

Result-Code268Unsigned32

Route-Record282DiamIdent

Session-Id263UTF8String

Session-Timeout27Unsigned32

Session-Binding270Unsigned32

Session-Server-Failover271Enumerated

Supported-Vendor-Id265Unsigned32

Termination-Cause295Enumerated

User-Name1UTF8String

Vendor-Id266Unsigned32

Vendor-Specific-Application-Id260Grouped

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.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 back-end account/balance systems (typically an Online Charging System).The application specifies methods for: Quota management (Reserve, Reauthorize, Abandon) Simple Debit/Credit Balance checks Price inquiriesThe 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 4006For 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 NameCCRCCA

Acct-Multi-Session-Id0-10-1

Auth-Application-Id11

CC-Correlation-Id0-10

CC-Session-Failover00-1

CC-Request-Number11

CC-Request-Type11

CC-Sub-Session-Id0-10-1

Check-Balance-Result00-1

Cost-Information00-1

Credit-Control-Failure-Handling00-1

Destination-Host0-10

Destination-Realm10

Direct-Debiting-Failure-Handling00-1

Event-Timestamp0-10-1

Failed-AVP00+

Final-Unit-Indication00-1

Granted-Service-Unit00-1

Multiple-Services-Credit-Control0+0+

Multiple-Services-Indicator0-10

Origin-Host11

Origin-Realm11

Origin-State-Id0-10-1

Proxy-Info0+0+

Redirect-Host00+

Redirect-Host-Usage00-1

Redirect-Max-Cache-Time00-1

Requested-Action0-10

Requested-Service-Unit0-10

Route-Record0+0+

Result-Code01

Service-Context-Id10

Service-Identifier0-10

Service-Parameter-Info0+0

Session-Id11

Subscription-Id0+0

Termination-Cause0-10

User-Equipment-Info0-10

Used-Service-Unit0+0

User-Name0-10-1

Validity-Time00-1

New AVPs for base protocol command codes[edit]Command Code

Attribute NameRARRAA

CC-Sub-Session-Id0-10-1

G-S-U-Pool-Identifier0-10-1

Service-Identifier0-10-1

Rating-Group0-10-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