Diameter Base Protocol

1). What is Diameter?

The Diameter protocol is an AAA protocol where AAA stands for Authentication, Authorization
and Accounting.
The purpose of the protocol is to:
• provide transport of user authentication information and thereby enabling the authentication of
the user.
• transport service specific authorization information between client and server. This allows the
peers to decide whether to grant the user’s access request or not.
• exchange information about resource usage.
• relay, proxy and redirect Diameter messages.

2). DIAMETER ADVANTAGES OVER RADIUS

Better Transport
 Diameter runs over a reliable transport, TCP or SCTP.
 Lost packets are retransmitted at each hop.
 A persistent connection with an application-level heartbeat message (called a
Watchdog message) supports timely failover.
 TCP and SCTP adapt to network congestion.

Better Proxying
 Hop-by-hop transport failure detection allows failover to occur at the appropriate
place — proxies can locally failover to an alternate next-hop peer.
 The proxy automatically does retransmission of pending request messages following
a failover.
 An AVP that identifies the ultimate destination allows multiple transactions for a
given session to be routed to the same home server.

Better Session Control

 Session management is independent of accounting. Accounting information can be
routed to a different server than authentication/authorization messages. Session
termination is conveyed by a specific Session-Termination message rather than an
Accounting Stop message.
 The server may initiate a message to request session termination.
 The server may initiate a message to request re-authentication and/or reauthorization
of a user.

Better Security
 Hop-by-hop security is provided using IPsec or TLS.
 End-to-end security protects the integrity and/or confidentiality of sensitive AVPs
through intermediate proxies.
3). Diameter Stack

Figure 1: Diameter Stack

The base protocol defines the basic Diameter message format. Data is carried within a
Diameter message as a collection of Attribute Value Pairs (AVPs). An AVP is like a
RADIUS attribute. An AVP consists of multiple fields: an AVP Code, a Length, some
Flags, and Data. Some AVPs are used by the Diameter base protocol; other AVPs are
intended for the Diameter application (e.g. NASREQ); while yet others may be used by
the higher-level end-system application that employs Diameter.

4). TYPES OF DIAMETER NODES

In addition to clients and servers, the Diameter protocol defines relay, proxy, redirect, and
translation agents.

Client
A Diameter Client is a device at the edge of the network that performs access control.
Examples of Diameter clients are Network Access Servers (NAS) and mobility agents
(Foreign Agent).

Server
A Diameter Server is one that handles authentication, authorization, and accounting
requests for a particular realm.

Relay Agent
A Relay Agent routes Diameter messages based on information found in the messages.
This routing decision is performed using a list of supported realms and known peers.
Relay agents are largely transparent. A Relay Agent may modify Diameter messages
only by inserting and/or removing routing information but may not modify any other
portion of a message.

Proxy Agent
A Proxy agent also routes Diameter messages. However, a proxy agent may modify
messages to implement policy decisions, such as controlling resource usage, providing
admission control, and provisioning.

Redirect Agent
A redirect agent also provides a routing function, generally acting as a centralized
source of Realm→Server address mappings for members of a roaming consortium.
Unlike the other agents that relay requests, a redirect agent returns a special type of
answer message to the peer that sent the request. This answer message contains
routing information that allows the peer to resend the request directly to the correct
destination server. The redirect agent is then out of the routing path; a redirect agent
does not relay requests.

Translation Agent
A Translation Agent translates between two protocols, such as RADIUS and Diameter.
In this case, the translation agent supports a RADIUS to Diameter migration, allowing
server conversions to Diameter, for example, while permitting the NASes to be converted at
a slower pace.

5). Diameter Message Structure

A Diameter message consists of the header and the payload. The message header is always
included in every Diameter message, and it contains codes, applications, identifiers and bit flags.
The Message payload contains the AVP data, and each message transported has a specific
command and application.

Hop-by-Hop Identifier – Unique identifier that matches the request and answer message.

End-to-End Identifier – Unique, time-sensitive identifier that detects duplicate messages.

The answer message must have the same end-to-end identifier in a corresponding request.

Attribute Value-Pairs (AVP)- AVPs contain values related to authentication, routing, security
and configuration, all of which are required for request or response messages.
There are four command flags available in the beginning of a diameter message header:
 R-Bit- Indicates whether a message is a request or answer messages.
 P-Bit- Indicates whether the message should be sent to a local or remote proxy.
 E-Bit- Sent in response messages to indicate an error has occurred.
 T-Bit- Sent in failover situations to aid in the processing of duplicate messages.

The next field after the flag is the command code field. One of the benefits of using Diameter is
that it is backward compatible with the RADIUS protocol. The Internet Assigned Numbers
Authority (IANA) has reserved several command codes to support backward compatibility with
RADIUS.

In addition, the IANA also maintains the application-ID numbers that define the application-ID
field for which the message is targeted. These can be standard applications or vendor-specific
applications.

There are several flags defined in the AVP header:

V-Bit– Vendor Specific code space.

M-Bit– Mandatory AVP that all nodes must support. If M-Bit is not enabled, any unrecognized
code is received. The receiver can treat the M-Bit as if it were for informational purpose only.

P-Bit- End-to-End Security encryption indicator required to secure a message.

6). DIAMETER PEERS

Diameter peers — the set of Diameter nodes with which a given Diameter node will directly
Communicate — may be statically configured or may be dynamically discovered.

Capabilities Exchange
The first Diameter messages exchanged between two Diameter peers, after establishing the
transport connection, are Capabilities Exchange messages.
A Capabilities Exchange message carries a peer's identity and its capabilities (protocol version
number, supported Diameter applications, etc.). A Diameter node only transmits commands to
peers that have advertised support for the Diameter application associated with the given
command.
Transport Failure Detection
Application-level heartbeat messages, called the Device-Watchdog-Request and Device-
Watchdog-Answer messages, are used to proactively detect transport failures.
These messages are sent periodically when a peer connection is idle and when a timely response
has not been received for an outstanding request.

Failover/Failback Procedures
In the event that a transport failure is detected with a peer, a Diameter node attempts to failover
to an alternate peer, which means that all pending request messages sent to the failed peer will be
forwarded to the alternate peer.
A Diameter node periodically attempts to re-establish the transport connection with a failed peer.
Should connection be re-established, a node can failback to this peer, i.e. messages can once
again be forwarded to this peer.
A failover to an alternate proxy agent may result in the reception of duplicate request messages
by the home server.

7). DIAMETER APPLICATIONS

A Diameter Application is a protocol that extends the base Diameter protocol by adding new
commands and/or attributes.

Each application is defined by an application identifier and can add new command codes and/or
new mandatory AVPs.

Examples of Diameter applications:

 Diameter Mobile IPv4 Application (Mobile IP)
 Diameter Network Access Server Application
 Diameter Extensible Authentication Protocol Application
 Diameter Credit-Control Application
 Diameter Session Initiation Protocol Application
 Various applications in the 3GPP IP Multimedia Subsystem

8). DIAMETER INTERFACES

Diameter interfaces provide connection among Diameter nodes to enable essential service
provider network functions such as:

 Authentication (Example: Sta, S6a, S6b)

 Authorization (Example: Gxa, Gx, Gy)
 Accounting (Example: Rf)
Figure 4: Diameter Interfaces

9). QPS DIAMETER ARCHITECTURE

10). DIAMETER – CONNECTION ESTABLISHMENT AND MAINTENANCE

 The communication between two diameter peers starts 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).
 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.

CLIENT SERVER

11). DIAMETER – CONNECTION ESTABLISHMENT

 Capabilities Exchange Request (CER)
Initiated by a Diameter client to establish a Diameter connection with a Diameter server.

 CER Initiated by the PCEF to establish a Diameter connection with the PCRF. It
includes all connection information that a PCRF needs to establish the connection.
 Capabilities Exchange Answer (CEA)
Initiated by a Diameter server in response to a Client’s CER request.

 CEA Initiated by the PCEF in response to Diameter CEA request by the PCEF. It
advertises peer identity and supported applications.
12). DIAMETER – SESSION COMMANDS
 Credit Control Request (CCR)
Sent from Client to Server to request authorization for a given service.

 CCR-I Initiated by the PCEF to create and initialize a session on the PCRF. It
includes all session information that PCRF might use to determine applicable
logic and policies.

 CCR-U Initiated by the PCEF to send updates for a previously created session,
based on one of the triggers that PCRF set during session initialization.

 CCR-T Initiated by the PCEF to terminate an existing session.

 Credit Control Answer (CCA)

Sent from Server to Client and carries the result of the corresponding authorization
request.

 CCA-I Initiated by the PCRF in response to a CCR-I request. It used by the

PCRF to communicate the result of the request, and provide the set of attributes
that PCEF should enforce to subscriber’s session.

 CCA-U Initiated by the PCRF in response to a CCR-U request. The PCRF has
full control to deny/modify policies on PCEF for an existing subscriber session,
by provisioning any of the rules and applicable.

 CCA-T Initiated by the PCRF in response to a CCR-T request. The PCRF

simply acknowledges that the request has been processed. Failure to send a CCA-
T can cause the PCEF to re-transmit the CCR-T to a secondary PCRF.

13). DIAMETER COMMANDS

 Reauthorization Request (RAR)

Sent by the Server to initiate a change for an existing session.

 RAR Initiated by the PCRF to push new policy attributes similar to CCA-I and
CCA-U. A RAR can also be used by the PCRF to request explicit volume usage-
report.
 Reauthorization Answer (RAA)
Sent by the client in response to a Reauthorization Request.

 RAA Initiated by the PCEF in response to RAR messages, and can be used to
provide current volume usage-report.

 Device-Watchdog-Request (DWR)

 After the CER/CEA messages are exchanged, if there is no more traffic between
peers for a while, to monitor the health of the connection, DWR message is sent
from the client. The Device Watchdog timer (Tw) is configurable in PCEF/GW
and can vary from 6 through 30 seconds. A very low value will result in
duplication of messages. The default value is 30 seconds. On two consecutive
expiries of Tw without a DWA, the peer is taken to be down.

 Device-Watchdog-Answer (DWA )

 This is the response to the DWR message from the server. This is used to monitor
the connection state.

 Disconnect-Peer-Request (DPR):
 This message is sent to the peer to inform to shutdown the connection. PCEF/GW
only receives this message. There is no capability currently to send the message to
the diameter server.

 Disconnect-Peer-Answer (DPA):
 This message is the response to the DPR request from the peer. On receiving the
DPR, the peer sends DPA and puts the connection state to “DO NOT WANT TO
TALK TO YOU” state and there is no way to get the connection back except for
reconfiguring the peer again.
14). DIAMETER – SESSION ESTABLISHMENT
SGSN/SGW PCEF PCRF SPR
15). DIAMETER – MID-SESSION
 PCEF INITIATED

PCEF PCRF SPR

 PCRF INITIATED
PCEF PCRF SPR
16). DIAMETER – CCR-I & CCA-I EXAMPLE
17). RESULT-CODE AVP

The Result-Code AVP (AVP Code 268) is of type Unsigned32 and indicates whether a particular
request was completed successfully or an error occurred. All Diameter answer messages in
IETF-defined Diameter application specifications MUST include one Result-Code AVP. A non-
successful Result-Code AVP (one containing a non-2xxx value other than
DIAMETER_REDIRECT_INDICATION) MUST include the Error-Reporting-Host AVP if the
host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP.

The Result-Code data field contains an IANA-managed 32-bit address space representing errors.
Diameter provides the following classes of errors, all identified by the thousands digit in the
decimal notation:

 1xxx (Informational)

 2xxx (Success)

 3xxx (Protocol Errors)

 4xxx (Transient Failures)

 5xxx (Permanent Failure)

An unrecognized class (one whose first digit is not defined in this section) MUST be handled as
a permanent failure.

18). Session and Policy control over Diameter

3GPP Gx is built on Diameter Credit Control (RFC 3588) but for policy control purposes and so
does not reuse all aspects. For session establishment and policy control over Gx, following
messages are used:

Initiated from PCEF to PCRF (PULL):

 CCR-I : Initialization of session from PCEF to PCRF, exchanging session information from
subscriber, and all relevant information that PCRF might use to determine logic and policies that
will apply. There is one Gx CCR-I per IP-CAN session (i.e. for primary and all secondary PDP
context or Default bearers plus all Dedicated bearers). Some of the attributes are:
o Session Id - a unique identifier allocated by the PCEF for the particular subscriber session that is
used in all subsequent messages.
o Equipment and subscriber identification: MSISDN, IMSI, and IMEI
o SGW/SGSN info: PLMNID and IP address
o User location information (if provided by the RAN)
o Radio access type, and QoS information that was requested for subscriber session

 CCA-I : PCRF’s answer to CCR-I request. In this message PCRF includes result-code that
defines if authorization is successful, or not. Also with authorization for session, PCRF provides
set of attributes that PCEF should enforce to subscriber’s session. This can be:
o Result code: defining if PCRF accepts session or terminates it. Valid codes and expected causes
are reused from 3GPP 29.212, RFC 4006 and RFC 3588.
o QoS change and THP/ARP setting change for session
o Event trigger provisioning : setting monitoring points triggers for which PCRF wants to be
notified from PCEF
o PCC rule and/or group of PPC rules install/remove commands: activating/deactivating pre-
defined dynamic rules on PCEF, with option to set predefined future time of automatic activation
and deactivation.
o Volume monitoring & reporting: Setting up thresholds for monitoring keys, which enables PCEF
to count and report counted volume per Service Data Flow (or set of SDFs) or for entire session.

 CCR-U : PCEF sends update for session, based on one of the triggers that PCRF set during
session initialization. Update message is sent together with trigger that caused this update
message, and with attributes that are related to the change, for example new RAT TYPE, new
QOS, Usage-Report due to Volume monitoring threshold exceeded, access network gateway
(e.g. SGW/SGSN) change or Revalidation timer.

 CCA-U : PCRF answer to CCR-U request. In this message PCRF has full control to
deny/modify policies on PCEF for subscriber session, by setting up result-code and provisioning
any of the rules and applicable modifications with same procedure as in INIT message
(Changing QoS, Setting new event-triggers, installing new rules, setting up or discarding volume
monitoring).

 CCR-T : PCEF sends TERMINATE request when subscriber session is closed, due to any
reason (UE PDP disconnection, or administrative disconnect by other entity). In termination
request message, PCEF reports termination-reason, and also any outstanding information that
was valid at session termination stage (Like reporting used volume or active volume-monitoring
threshold).

 CCA-T : PCRF answer to CCR-T request which just acknowledges that the request has been
processed. Failure to send a CCA-T can cause the PCEF to retransmit the CCR-T to a secondary
PCRF.

Initiated from PCRF to PCEF (PUSH):

 RAR : PCRF can initiate change by itself using Re-Authorization-Request. Unlike Gy and
Diameter Credit Control, this message does not trigger a CCR-U, instead this is used when
PCRF needs to modify session policy control during active session. With RAR, PCRF can push
new policy attributes like in INIT response and UPDATE response messages, and also PCRF can
request explicit volume usage-report.
 RAA : PCEF answer to RAR. It’s used to respond if PCEF accepted changes in RAR, and to
provide current volume usage-report if PCRF requested it.

Common message flow for Gx session messages: