Diameter Base Protocol and Credit Control Application

Aricent Wireless Offering

Page

Diameter
What is Diameter ? - Extensible, ASCII based messaging protocol to enable Authentication ,Authorization, and Accounting (AAA) function in IP and multimedia networks. - Defined in the IETF(rfc 3588) and extended in 3GPP(rfc4006). - Diameter supports a scalable architecture with the base protocol and application can run on different processors. - Diameter operates on top of reliable transport protocols like TCP and SCTP. - Its secure and reliable transports make it a suitable choice for charging Applications

Diameters AAA Usage

Whats More in Diameter than RADIUS

Diameter Radius

Transportation Protocol Connection-Oriented Connectionless Protocol Protocols (TCP and SCTP) (UDP) Agent Support Security Capabilities Negotiation Relay, Proxy, Redirect, Translation Hop-to-Hop, End-to-End Negotiate supported applications and security level Implicit support. Hop-to-Hop only Doesn't support

Peer Discovery
Server Initiated Message

Static configuration and dynamic lookup

Supported. for example, re-authentication Message, Session termination

Static configuration
Doesn't support

Diameter Stack

Diameter Stack..
- Base Diameter Protocol(RFC: 3588) - Uses IP for Network Layer Functionality. - Operates on top of reliable transport protocols like TCP and SCTP. - SH ,CX,RO,RF interfaces defined by 3GPP for IMS. - The SH and CX Diameter applications extend the Base Diameter Command codes and AVPs to support the authentication and authorization functions.

Diameter Stack.
Ro interface is used for real-time charging. Based on the IETF defined Credit Control Application (RFC 4006). The Rf interface is based on the accounting functionality of IETFdiameter base (RFC 3588). Applications - Purpose specific: CCA ,SIP, NASREQetc. - Identified by application Id - IANA-assigned application identifier - Used also for diameter message routing

Diameter Base Functionality (RFC 3588)

Diameter Client Diameter Client Application Diameter Server Diameter Server Application

Session Management

Session Management
Routing Management

Routing Management

Connection Management
Base Protocol

Connection Management
Base Protocol

Page 8

Diameter - Basic Functionality

Base Protocol - Connectivity: Peering and Routing - Application support: Application session management

Diameter - Message Format

Diameter - Message
Diameter Header AVP AVP AVP

AVP Header

AVP Data

Diameter Header = Version, Length, Flags, Code, AppId, H2H Id, E2E {
Id }

AVP Header = Code, Flag, Length, Vendor-Id (Opt) Each message is defined using an ABNF grammar. Pre-defined AVP data types (Integer32, Float, OctetString etc.)

Diameter -Packet Format

length Flags

FLAGS :

R- Request

P - Proxiable
E- error , T- Retransmit Flags :VMP-

Diameter ABNF Example

<CER> ::= < Diameter Header: 257, REQ > { Origin-Host } /* Required AVP, Occurrence: 1 */ { Origin-Realm } { Vendor-Id } * [ Auth-Application-Id ] { Product-Name } [ Origin-State-Id ] /* Optional AVP, Occurrence: 0 or 1 */ * [ Supported-Vendor-Id ] /* Optional AVP, Occurrence: 0+ */ * [ Acct-Application-Id ] * [ Vendor-Specific-Application-Id ] * [ AVP ]

Diameter ABNF Example

<CEA> ::= < Diameter Header: 257 >

{ Result-Code } { Origin-Host } { Origin-Realm } { Vendor-Id } { Product-Name } [ Origin-State-Id ] [ Error-Message ] * [ Failed-AVP ] * [ Supported-Vendor-Id ] * [ Auth-Application-Id ]

* [ Inband-Security-Id ] *

Connection Management

Peer Discovery Transport Capabilities negotiation Peer liveness and disconnection

Connection Management

Peer Discovery :
Static configuration: mandatory [(Peer Table and Peer Routing Table] DNS(Broadcast): optional

Transport : Protocols : Clients must support at least SCTP or TCP(Port 3868)

Server and Relay must support SCTP and TCP

Security : TLS(Client and Server) and IPSec

Selection Process : IPSec, SCTP, TCP, TLS

Connection Management
Capabilities Negotiation
Capabilities Exchange - Use of Capabilities-Exchange (CER/CEA) messages - Message exchange advertises: - Supported applications - Peer Identity - Security schemes Indicates the use of TLS/IPSec - SCTP host addresses if used - CER/CEA should not be proxied Peer Table Creation - Lists all peers that passes capabilities negotiation - Indicates the connection status of each peers - Also Used for message routing

Diameter Base Functionality (RFC 3588)

Peer Liveness and Disconnection Liveness Test - Use of Device-Watchdog exchange (DWR/DWA) - Aid in Fail over performance: pro-active detection of failure
Disconnection

- Use of Disconnect-Peer exchange (DPR/DPA) - Provides hints for future reconnection attempts - Routing and peer table updates

Routing

Types of Diameter Nodes Request Routing Answer Routing

Duplicate Detection Failover-Fallback Procedure

Diameter Nodes
Diameter Clients and Severs
Request and Answer Originators Where application normally reside Advertises supported applications only Diameter Agents Request and Answer forwarders Relay Agents Provides basic message forwarding Does not inspect content of the message other than DestinationHost and/or Realm and AppIds Advertises support all applications

Diameter Nodes
Lookup([Link]) Local Process

Lookup([Link]) route to Relay Agent

[Link]
Lookup([Link]) route to Relay Agent [Link]

Diameter Server
Request Queue

Diameter Client
Request Queue

Diameter Relay Agent Request

Queue

[Link]

[Link]

4. Answer

[Link] Diameter Server [Link]

Request Routing Information used for routing:

Application-Id: present is in the header Destination-Host OR Destination-Realm AVP Advertises supported applications only

Routing rules:
If local identity == Destination-Host AVP then process locally, otherwise If peer identity == Destination-Host AVP then send that peer, otherwise (use Peer Table) Lookup realm table with Destination-Realm and AppId If found send to the designated next-hop Otherwise, send an UNABLE_TO_DELIVER answer(with E=1) Advertises support all applications Use of Request Queue :Successfully forwarded requests are queued

Request Routing..
Realm Routing Table : List of realm routing entries Realm routing entry looks like : Realm (*), AppId (**), Action, Next-hop Peer, isStatic, ExpireTime Realm: Primary key, matched with Destination-Realm AVP AppId: Secondary key, matched with AppId in message header, Action: For each matching entry, possible actions are, LOCAL, RELAY, REDIRECT isStatic: Indication of static or dynamic route ExpireTime: Time before dynamic route are no longer valid

Answer Routing
Information used for routing
Hop-by-Hop Id is used instead of Destination-Host or Destination- Realm AVP Hop-by-Hop Id is unique within each hop Answer routing path is the reverse of the request path

Routing Rules:
For answer originators: - Use the same Hop-by-Hop Id found in the request For answer forwarders: - Lookup Hop-by-Hop Id in request queue. - If found, forward answer to appropriate peer and remove request from the queue - Otherwise, discard

Fail Over-Fallback Procedure Fail-Over :

Attempt to re-route pending request to an alternate peer in

case of transport failure T bit is set for re-routed requests

Fall-Back:
Switch back to the original next hop when connection is re-

established

Fail Over-Fallback Procedure

Relay-2
Lookup([Link]) route to Relay Agent
Request Queue

[Link]

[Link] T=1

[Link] r

[Link] T=1 [Link]

[Link]

Relay-1
Request Queue

Diameter Client
Request Queue

Diameter Server
[Link]
Request Queue

[Link]

[Link]

[Link]

Diameter Credit Control Application

Content
Diameter Credit Control Application Overview Messages Operation Modes Other Protocol Features Timers Duplicate Detection High Availability/Failure Handling Notes for Authors of New Applications

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

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)

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

Answer (RAA)

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

Server

Session Based Scenario Example

Client Server
CCR, Session-Id = S-Id1, Requested-Service-Unit 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

Credit Control Timers

Tx timer

Used by client to guard against non-receipt of CCA after a CCR is sent

Cant rely on Tw, configuring Tw to a low value may be undesirable and Tw on the whole message path may not be under control of the client administrating entity

Tcc

timer

Used by server to guard against non-receipt of CCR for session based scenarios

Server can inform client when a tariff change will occur with Tariff-Time-Change AVP

Tariff-Change
Client reports used units before and after tariff change with Tariff-Change-Usage AVP

Duplicate Detection
Session-Id AVP, CC-Request-Number AVP and CC-RequestType can be used to detect duplicates (mechanism described in RFC3588 will work too, i.e. using Origin-Host AVP and Endto-End Identifier

High Availability/Failure Handling Features

CC-Session-Failover AVP Used by servers to inform clients whether a backup instance is present ( Client needs to know identity of backup peer by other means FAILOVER_NOT_SUPPORTED, FAILOVER_SUPPORTED )

Credit-Control-Failure-Handling AVP Used by server to inform client about the expected behavior for session based scenarios, when CCA for a CCR is not received(TERMINATE , CONTINUE)

Direct-Debiting-Failure-Handling AVP

Used by server to inform client about the expected behavior for event based scenarios, when CCA for a CCR is not received(TERMINATE_OR_BUFFER , CONTINUE )

Thank you