Introduction to the Diameter Protocol

Outline

AAA protocol in the IMS: Diameter

Diameter Application in IMS

Origin and Development of Diameter

AAA refers to authentication, authorization, and

accounting.
The traditional charging protocol, Radius, is widely used
because of its simplicity, security, ease of management,
and excellent scalability.
The introduction of new access technologies and the fast
expansion of access networks pose new requirements for
AAA protocols and make the structural shortcomings of the
traditional Radius ever more noticeable.
This calls for the use of the new-generation AAA protocol,
Diameter.

Architecture

Diameter position in the IETF protocol stack

Base protocol
Cryptographic Message Syntax (CMS)
Mobile IP
Network access service (NAS)
Extensible authentication protocol (EAP)

Security Mechanism

Connection layer
Maintains the Diameter connection status machine between two peers,
providing a transmission channel for the data from upper layers.
Transaction layer
Deals with the transaction part of a Diameter message, including
maintenance of the message cache queue, the relationship between a
request message and a response message, and maintenance and
management of the hop-by-hop transaction identifier.
Session layer
Builds and maintains session status machines of authentication,
authorization, and accounting.
Application layer
Defines the structure and parameters of the Diameter message based
on a session status machine, thus satisfying the service requirements.

Functions of the Diameter Protocol

Transmitting AVP Information

Maintaining and Managing Diameter Connections
Caching Transactions
Negotiating Capabilities
Discovering and Configuring Peers

Features of the Diameter Protocol

Failure recovery
The Diameter protocol provides a universal failure recovery method,
which supports failure confirmation at the application layer, defines the
algorithms about failure recovery, and the corresponding status
machines.

TLS
Provides a universal TLS mechanism. The Diameter requires that
IPSEC is compulsory and TLS is optional.

Reliability of the transmission layer

The Diameter protocol runs above the TCP and SCTP, thus ensuring
the transmission reliability. The basic protocol of Diameter runs on port
3868 of TCP and SCTP, which will be compulsory in the later versions.

Features of the Diameter Protocol

Supports proxies
RADIUS does not support proxies explicitly, such as a proxy server, a relay
server, and a redirecting server. Whereas the Diameter protocol support the
proxies mentioned above.

Monitors data security

RADIUS does not provide a data-based security mechanism, so the
modification on data cannot be found after the data transmission. The
Diameter protocol provides an optional CMS function to protect the data.

Supports transition
Since Diameter and RADIUS do not share any data protocol units, both
protocols can be used in the same network as long as one of them supports
the gateways of both RADIUS and Diameter.

Supports server-initiated messages

The function of server-initiated messages is required in the Diameter protocol.

Architecture

Client
Server
Relay

Relays forward requests and responses according to

route-relevant AVP and the realm route table.
Relay can be used to centralize the NAS requests in a
certain geographical range.
Since relays do not make decisions on policies, they do
not inspect or change non-route AVPs.Relays need to
maintain transaction status but not the session status.

Architecture

Proxy

Routes Diameter messages using the Diameter route table

Modifies messages according to the implemented policy

The proxies that need to limit resources must maintain session

status. All the proxies must maintain transaction status.

Redirect server

The Redirect Agent guides Diameter clients to the server and

enables them to communicate directly.

Translation server

It executes protocol translation between Diameter and other AAA

protocols (such as RADIUS).

Architecture

Architecture

Message Format
MessageHeaderFormat
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Version

Message Length

Command flags

Command-Code

Application-ID
Hop-by-Hop Identifier
End-to-End Identifier
AVPS..

Message Header Format

The length of the Diameter message header is 20 bytes.

Version: Diameter version number. It is set to 1.
Message Length: includes the length of the message header.
Command Flags: 8 bits

01234567
+-+-+-+-+-+-+-+-+
|R P E T r r r r|
+-+-+-+-+-+-+-+-+
R(equest): if it is set, this message is a request; if it is cleared, this
message is a response.
P(roxiable): if it is set, this message can be sent by proxy, relay, or the
redirect server; if it is cleared, this message must be processed locally.
E(rror): it indicates that the message contains a protocol error and cannot
exist in a request.

Message Header Format

T(Potentially re-transmitted message)

This flag avoids repeated requests after changeover. It needs to be set only
when no response is received and a request needs to be retransmited. It can
be set only in a request. When retransmitting a received message that
contains Tbit, the diameter agent must keep Tbit.

r(eserved): it must be set to 0. Receivers can ignore these reserved bits.

Command-Code: three octets.

The space address of 24bit command code is managed by IANA in a universal way.
The command codes 16,777,214 and 16,777,215 are used for test.

Application-ID

It indicates the application that a message belongs to. IANA must assign an ID for
each application. Support for basic protocols is compulsory, so they do not need
application IDs. In the process of capability negotiation, the Diameter node notifies
the peer of the applications that it supports. All the diameter messages must contain
the application ID.

Message Header Format

Currently the defined applications include:

Diameter Common Messages
0
NASREQ
1 [NASREQ]
Mobile-IP
2[DIAMMIP]
Diameter Base Accounting
3
Relay
0xffffffff
Relays and redirect servers must broadcast the application ID of relays,
while other nodes must broadcast the locally supported applications.
Hop-by-Hop Identifier
It is used to correspond a request to a response.
End-to-End Identifier
It is used to check repeated messages. It cannot be modified by any
agent. Used together with Origin-Host, it can check repeated messages.
AVPs
Contain certain data

Message Format of Diameter-Structure of

AVP Message Header
0

AVP Code

VM Prrrrr

Vendor-ID (opt)

Data..

AVP Length

Message Format of Diameter-Structure of AVP

Message Header

The AVP message header contains eight to 12 bytes.

AVP Code: AVP code and Vendor-Id determines the AVP properties.
AVPs (1 to 255) are reserved to be backward compatible with RADIUS
(without Vendor-Id). 256 and AVPs greater than 256 are used for
Diameter and are assigned by IANA.
AVP Flags:

r bit is reserved and set to 0.

P bit indicates encryption for end-to-end security.
M bit indicates that the support for this AVP is necessary. If AVPs without
Mbit cannot be identified or supported, they will be ignored.
Vbit indicates that the optional vendor ID exists in the AVP header. If Vbit is
set, it indicates that the AVP code belongs to the specified vendor.

AVP Length

Three bytes. Indicates AVP code, AVP flag bit, vendor ID and AVP-DATA. If
the length is not correct, the message will be refused.

Key Technologies (1)

Capability exchange

Capabilities-Exchange-Request (CER)

Capabilities-Exchange-Answer (CEA)

Interruption of Diameter peer connection

When the connection between a Diameter node and its peer is

interrupted, the peer cannot know the interruption reason.

In this case, the peer might judge that the connection is interrupted
or its peer is restarted. Therefore, it tries to reconnect periodically.
This action is controlled by the TC timer. Normally it is
recommended to set to 30 seconds.

If the reason is that internal resources are insufficient or the peer

does not want to keep connection, the peer must inform the other
one of the reason, and thus to avoid unnecessary periodical retries.

Disconnect-Peer-Request (DPR) & Disconnect-Peer-Answer (DPA)

Key Technologies (2)

Check of transmission failure

Finding out errors quickly can prevent the messages from being sent to
invalid agents, thus reducing unnecessary delays and providing better
failover performance.

Device-Watchdog-Request (DWR) Device-Watchdog-Answer (DWA)

Failover and Failback

When finding that the transmission to a peer failed, the system must send
the request messages to be processed to an agent.

The Diameter node must maintain the message waiting queue of the
specified peer.

The diameter node need to reconnect the failure peers periodically in order
to reestablish the connection. When the transmission resumes normal, the
messages can be resent to the peer. This is called failback.

Key Technologies (3)

Check of repeated messages

Using this function, an application server checks whether a
received message is repeated.
T bit in the Diameter message is used to indicate the
retransmission event at the application layer.
End-to-End Identifier and Origin-Host AVP in the Diameter
message header are used to identify repeated messages.

Outline

AAA protocol in the IMS: Diameter

Diameter Application in IMS

Diameter Applications in IMS-CX/DX/SH

HSS
C

Gr

Gc

gsmSCF

GMSC

MSC / VLR

SGSN

GGSN

Sh

PS Domain

Cx

IM-SSF

CSCF

SIP Application
Server
OSASCS
-

CS Domain

Si

IM CN subsystem

Diameter Application in IMS

3GPP is the vendor of the Diameter protocol. The vendor

ID assigned to 3GPP by IANA is 10415.

The Diameter application ID assigned to CX/DX interface

by IANA is 16777216, while that assigned to the SH
interface 16777217.

A new command code is assigned to the CX/DX/SH

interface message.

A new AVP is added in the CX/DX/SH interface.

Definition of CX and DX Interfaces

The CX interface is defined between I-CSCF and HSS, or

between S-CSCF and HSS.

The DX interface is defined between I-CSCF and SLF, or

between S-CSCF and SLF.

SLF is the Diameter redirect agent. HSS is the Diameter

server, and I/S-CSCF is the Diameter client.

Diameter Applications in IMS-CX/DX/SH Interface

Message
Command-Name

Abbreviation

Code

User-Authorization-Request

UAR

300

User-Authorization-Answer

UAA

300

Server-Assignment-Request

SAR

301

Server-Assignment-Answer

SAA

301

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

Diameter Command Codes of CX/DX

Interface

User authorization request (UAR), user authorization

answer (UAA)

Multimedia authentication request (MAR), multimedia

authentication answer (MAA)

After receiving an SIP registration request from the IMS terminal,

the I-CSCF sends the UAR message.

When the S-CSCF receives an initial SIP registration request, it

needs to authenticate the IMS user.

Server assignment request (SAR), server assignment

answer (SAA)

After the S-CSCF authenticates the user, it sends SAR to HSS for
the user archive.

User Registration Flow

UE

HSS

Registration
Registration
UAR
UAA
Registration
MAR
MAA

401
Registration

401

401 Unauthorized

Registration
UAR
UAA
Registration
SAR

200

200

200OK

SAA

Diameter Applications in IMS-SH Interface

Message
Command-Name

Abbreviation

Code

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