Basics of Diameter

Agenda
Diameter Base Protocol
Introduction of Diameter
Diameter Base Protocol Diameter Applications Types of Diameter nodes

Typical Diameter Message Exchanges

Capabilities Exchange procedure Transport Failure Detection Diameter error handling Diameter Header Format AVP Header Format

Diameter Packet Format Comparison with RADIUS

Diameter Credit Control Application

Signaling in EPS

Introduction to Diameter
Diameter is an authentication, authorization and accounting protocol for computer networks It is a successor to RADIUS It was initially developed by Pat R. Calhoun, Glen Zorn and Ping Pan in 1998 The Diameter base protocol is defined by RFC 3588 (Obsoleted by RFC 6733) Diameter Applications can extend the base protocol, by adding new commands and/or attributes

Diameter overview
AAA protocol that improves and can replace Radius TCP or SCTP as reliable transport protocol Diameter Security provided by IPsec or TLS TCP SCTP One Diameter session can carry many connections that consist of transactions (request - answer pairs)

Base protocol & Applications

Base Protocol
Base protocol defines basic principles
Message format that is based on attribute-value (AVP) pairs Transport connection setup, monitoring and failover Request routing Error reporting & security Relaying, proxying, redirection and translation of messages

Functionality common to all supported services. The base Diameter protocol is never used on its own. It is always extended for a particular application, which defines DIAMETER command codes

Diameter Applications
A Diameter Application is not a software application It is a protocol based on the Diameter base protocol Each application is defined by an application identifier New command codes and/or new mandatory AVPs can be added Adding a new optional AVP does not require a new application

Diameter Applications Cont.

Diameter applications define application specific AVPs and semantics
RFC 4004 Diameter Mobile IPv4 Application RFC 4005 Diameter Network Access Server Application RFC 4006 Diameter Credit-Control Application RFC 4072 Diameter Extensible Authentication Protocol (EAP) Application RFC 4740 Diameter Session Initiation Protocol (SIP) Application RFC 5224 Diameter Policy Processing Application RFC 5431 Diameter ITU-T Rw Policy Enforcement Interface Application RFC 5866 Diameter Quality-of-Service Application RFC 6737 The Diameter Capabilities Update Application.

Why Diameter was needed

It provides a Authentication, Authorization, and Accounting (AAA) framework that could overcome the limitations of RADIUS RADIUS had issues with reliability, scalability, security and flexibility RADIUS cannot effectively deal well with remote access, IP mobility and policy control

Why Diameter was needed (Cont.)

Like RADIUS, Diameter provides AAA functionality, but in addition it is made more reliable by using TCP and SCTP instead of UDP lt is further enhanced 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 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

Types of Diameter Nodes

JMi / 11/2007

Typical Diameter Message Exchanges

Client
Peer Discovery Peer Discovery Capabilities Exchange Request

Agent

Server

Discovery via DNS or Static Configuration 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. Application-level heartbeat 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. There are two types of messages, Requests and Answers.. Every answer message carries a Result-Code AVP. The data value of the Result-Code AVP is an integer code indicating whether a particular request was completed successfully or whether an error occurred.

Capabilities Exchange Request Capabilities Exchange Answer

Capabilities Exchange Answer

Device Watchdog Request Device Watchdog Answer

Request Request Answer Answer

Capabilities Exchange procedure

Mandatory procedure once transport connection is established Capabilities are cached. Originating peer sends CER command announcing supported applications Terminating peer sends CEA command with its supported applications. Result-Code AVP in CEA will usually contain:
DIAMETER_SUCCESS (2001) DIAMETER_NO_COMMON_APPLICATION (5010) DIAMETER_UNKNOWN_PEER (3010)

In case of failure, transport connection is closed

Transport Failure Detection

Application layer watchdog procedure is used DWR command is sent when no traffic has been exchanged in transport connection for Tw seconds If no DWA has been received, transport connection will be closed. DWR message isnt retransmitted because diameter uses realiable transport protocols (TCP, SCTP) All requests will forwarded to the alternate peer.

Diameter error handling

There are two different types of errors in Diameter; protocol and application errors.
A protocol error is one that occurs at the base protocol level, and MAY require per hop attention (e.g., message routing error). Application errors, on the other hand, generally occur due to a problem with a function specified in a Diameter application (e.g., user authentication, Missing AVP).

All Diameter answer messages defined in IETF applications 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. 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)

Diameter Packet Format

MAC header IP header TCP header Diameter header AVPs

Command is a Request or Response. Both have the same command code. Commands are used to exchange information between peers. A command is identified by its code, flags and application id. For every Request command theres an Answer command. The information is carried as list of AVPs.

Diameter Packet Format (Cont.)

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

Diameter Command-Code values

There are separate commands for DCCA application layer and Base Diameter Protocol. Base Diameter Command Codes
Command-Name Abort-Session-Request Abort-Session-Answer Accounting-Request Accounting-Answer Capabilities-Exchange-Request Capabilities-Exchange-Answer Device-Watchdog-Request Device-Watchdog-Answer Disconnect-Peer-Request Disconnect-Peer-Answer Re-Auth-Request Re-Auth-Answer Session-Termination-Request Session-Termination-Answer Abbr. ASR ASA ACR ACA CER CEA DWR DWA DPR DPA RAR RAA STR STA Code 274 274 271 271 257 257 280 280 282 282 258 258 275 275 Credit-Control-Request Credit-Control-Answer

Diameter Command Codes for DCCA

Command-Name Abbr . CCR CCA Code 272 272

Attribute Value Pairs (AVP)

An AVP is a container for data delivered by Diameter. Some of the AVP values are used by the Diameter protocol itself, while others deliver data associated with particular applications that employ Diameter. AVPs may be added arbitrarily to Diameter messages. AVPs are used by the base Diameter protocol to support the following required features:
Transporting of user authentication information, for the purposes of enabling the Diameter server to authenticate the user. Transporting of service specific authorization information, between client and servers, allowing the peers to decide whether a users access request should be granted. Exchanging resource usage information, which MAY be used for accounting purposes, capacity planning, etc. Relaying, proxying and redirecting of Diameter messages through a server hierarchy.

AVP Header Format

The packet consists of a AVP header and a variable data

AVP Header Format (Cont.)

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 3GPP specific AVP codes are listed in TS29.230

Comparison Radius & Diameter

JMi / 11/2007

Comparison Radius & Diameter Cont.

JMi / 11/2007

Diameter Credit Control Application

3GPP PCC Logical Architecture

Credit Control Application Overview

Specified in RFC 4006 Can be used to provide real time credit control for various applications, e.g. messaging services, gaming services Used between the network element providing the service (client) and credit control server (server) Uses Application-Id 4, Command code 272

Credit Control Application Messages

Credit Control Request (CCR)
Sent from client to server to request authorization for a given service

Credit Control Answer (CCA)

Sent from server to client and carries the result of the corresponding authorization request

Reauthorization Request (RAR) - Base

Sent by server to trigger a new CCR, e.g. after successful credit replenishment during a service

Reauthorization Answer (RAA) - Base

Sent by client as an answer to RAR

Operation Modes

Event Based
A single CCR/CCA exchange in each session Used when it is sure that requested service event will be successful

Session Based
Multiple CCR/CCA exchanges in a session Required when there is a need to reserve credits before providing the service Requires state maintenance on the server side Server first reserves the credits and debits them after receiving the subsequent CCR

Some important AVPs

CC-Request-Type AVP
Indicates type of the request for a CCR Possible values are INITIAL_REQUEST, UPDATE_REQUEST, TERMINATION_REQUEST for session based scenarios and EVENT_REQUEST for event based scenarios

CC-Request-Number AVP
Identifies a request within a session

Requested-Action AVP
Used to indicate type of the requested action for event based scenarios. Possible values are DIRECT_DEBITING, REFUND_ACCOUNT, CHECK_BALANCE and PRICE_ENQUIRY

Event Based Scenario Example

Client
CCR, Session-Id = S-Id1, Service-Identifier CC-Request-Type = EVENT_BASED Requested-Action = PRICE_ENQUIRY CCA, Session-Id = S-Id1 Cost-Information CCR, Session-Id = S-Id2, Subscription-Id, CC-Request-Type = EVENT_BASED Requested-Action = BALANCE_CHECK, Service-Identifier CCA, Session-Id = S-Id2 Check-Balance-Result CCR, Session-Id = S-Id3, Service-Identifier CC-Request-Type = EVENT_BASED Requested-Action = DIRECT_DEBITING Subscription-Id CCA, Session-Id = S-Id3 Granted-Service-Unit

Server

Session Based Scenario Example

Client
CCR, Session-Id = S-Id1, Requested-Service-Unit CC-Request-Type = INITIAL_REQUEST Subscription-Id CCA, Session-Id = S-Id1 Granted-Service-Unit, Validity-Time CCR, Session-Id = S-Id1, Requested-Service-Unit, CC-Request-Type = UPDATE_REQUEST Subscription-Id CCA, Session-Id = S-Id1 Granted-Service-Unit, Validity-Time CCR, Session-Id = S-Id1, CC-Request-Type = TERMINATION_REQUEST Used-Service-Unit CCA, Session-Id = S-Id1 Cost-Information

Server

Thank You

Presentation / Author / Date