Next Generation Protocol - Diameter
Fri, 08/28/2009 - 18:05 | 
9797
Introduction to Diameter
Next generation protocol
Diameter a protocol, derived from the RADIUS protocol with a lot of improvements in different aspects.The RADIUS (Remote Authentication Dial In User Service) protocol is widely deployed in current intranet and internet configurations. DIAMETER introduces many enhancements in order to address several RADIUS shortcomings and deficiencies such as lack of end-to end security, limited size of length and identifier fields, and limited failure detection mechanisms. Diameter is defined as a base protocol used in conjunction with a set of applications. Its base protocol provides mechanisms for reliable transport, message delivery and error handling between DIAMETER clients and servers.
http://whytelecom.com/modules/fckeditor/fckeditor/editor/css/images/fck_...); background-repeat: no-repeat; padding-left: 18px; background-position: 0px 50%; ">Few Examples of Diameter applications:
• Diameter Mobile IPv4 Application (Mobile IP, RFC 4004)
• Diameter Network Access Server Application (NASREQ, RFC 4005)
• Diameter Extensible Authentication Protocol Application (RFC 4072)
• Diameter Credit-Control Application (DCCA, RFC 4006) in Real-time Billing
• Diameter Session Initiation Protocol Application (RFC 4740) for call Control
• Various applications in the 3GPP IP Multimedia Subsystem
• Both the HSS and the SLF communicate using the Diameter protocol (In IMS)
The Messages defined in the Diameter base protocol
|
Message name
|
Abbreviation
|
Command code
|
|
Abort-Session-Request
|
ASR
|
274
|
|
Abort-Session-Answer
|
ASA
|
274
|
|
Accounting-Request
|
ACR
|
271
|
|
Accounting-Answer
|
ACA
|
271
|
|
Capabilities-Exchanging-Request
|
CER
|
257
|
|
Capabilities-Exchanging-Answer
|
CEA
|
257
|
|
Device-Watchdog-Request
|
DWR
|
280
|
|
Device-Watchdog-Answer
|
DWA
|
280
|
|
Disconnect-Peer-Request
|
DPR
|
282
|
|
Disconnect-Peer-Answer
|
DPA
|
282
|
|
Re-Auth-Request
|
RAR
|
258
|
|
Re-Auth-Answer
|
RAA
|
258
|
|
Session-Termination-Request
|
STR
|
275
|
|
Session-Termination-Answer
|
STA
|
275
|
Although Diameter supports different RFC’s, here in this tutorial I am much concentrating on Diameter Credit Control Applications (RFC 4006) alone, as it serves much bigger role in Telecommunication World. The Diameter protocol is currently used widely in the IMS (IP Multimedia Subsystem) architecture for IMS entities to exchange AAA-related information and also as a charging Interface to the external world.
During the past few years the online charging in the form of prepaid services has become very widespread in wireless networks. The online charging mechanism is often carried out by using IN services or as an adaptation of IN technology, CAMEL. Diameter Credit Control Application utilizes the mechanisms provided by the Diameter Base protocol to provide real-time credit control to the service charging in IP networks. By accomplishing Diameter Base protocol with bidirectional credit control functionality the on-line charging support can be provided by AAA infrastructure. The Credit Control Application supports functionality for service charging with credit reservation, direct debiting and refunding, service price enquiry and subscriber’s account balance check.
Credit Control Application Overview
• Diameter Credit control application Can be used to provide real time credit control for various applications, e.g. messaging services, gaming services, Real time content charging in telecom industry etc
• The basic architecture to implement CC (Credit control) Application needs at least
CLIENT - The network element providing the service
SERVER - credit control server
Real world scenario explaining the need for Credit control Application with a Example
Presently the CAMEL protocol provides powerful capabilities to perform real-time credit control but due to its high functional bonding with circuit-switched call control and GPRS session management it is not really suitable for IP network.
But the Telecom Standard bodies made other alternative mechanism to support online content charging, one such example was OSA/Parlay framework that supports content-based charging API (specified by 3GPP/ETSI and Parlay Group). But the applicability of OSA/Parlay charging API is limited to services that have been built using the OSA/Parlay framework. So this solution was not the promising solution for the telecom's Future.
So the powerful and flexible Diameter session-based application with (start, interim, stop) accounting records are utilized for this functionality.
When the user requests a service from the service node (example: Content server to download a wallpaper) the end user may be authenticated and authorized. Then the service node contacts the credit control server (subscribers Balance from the billing database)in order to check whether the user has credit on his account and reserves units from the account for service Execution.
If the credit control server accepts the service request it returns the granted units to the service node. The reservation is valid only for certain duration. Therefore the service node should contact the credit control server again when the reservation time expires in order to refresh the reservation or when all the granted
Units have been consumed.
When the service node contacts the credit control server it reports the units (No of wallpaper or ringtone downloaded) used this far and may request new credit reservation from the account.At the end of service, the service node reports the used units to the credit control server that deducts the corresponding monetary amount from the User’s account (Then the subscriber balance is debited according to the usage of service).
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
There are two modes of operation supported by Credit control application
Session and Event Based
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
Understanding Credit Authorization Models
RFC 4006 defines two basic types of credit authorization models:
Credit authorization with unit reservation, and
Credit authorization with direct debiting
Credit authorization with unit reservation can be performed with either event-based or session-based charging events. Credit authorization with direct debiting uses immediate charging events. In both models, the CTF requests credit authorization from the OCF prior to delivering services to the end user. In both models the sections that follow describe each model in more detail.
Credit Authorization with Unit Determination
RFC 4006 defines both Event Charging with Unit Reservation (ECUR) and Session Charging with Unit Reservation (SCUR). Both charging events are session-based, and require multiple transactions between the CTF and OCF. ECUR begins with an interrogation to reserve units before delivering services, followed by an additional interrogation to report the actual used units to the OCF upon service termination. With SCUR, it is also possible to include one or more intermediate interrogations for the CTF in order to report currently-used units, and to reserve additional units if required. In both cases, the session state is maintained in both the CTF and OCF. For both ECUR and SCUR, the online charging client implements the “CLIENT, SESSION BASED” state machine described in RFC 4006.
Credit Authorization with Direct Debiting
For direct debiting, Immediate Event Charging (IEC) is used. With IEC, a single transaction is created where the OCF deducts a specific amount from the user's account immediately after completing the credit authorization. After receiving the authorization, the CTF delivers services. This form of credit authorization is a one-time event in which no session state is maintained. With IEC, the online charging client implements the “CLIENT, EVENT BASED” state machine described in IETF RFC 4006.
Determining Units and Rating
Unit determination refers to calculating the number of non-monetary units (service units, time, and events) that can be assigned prior to delivering services. Unit rating refers to determining a price based on the non-monetary units calculated by the unit determination function. It is possible for either the OCF or the CTF to handle unit determination and unit rating. The decision lies with the client application, which controls the selection of AVPs in the credit control request sent to the OCF.
CCR/CCA Message structures
<Credit-Control-Request> ::= < Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Service-Context-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ Destination-Host ]
[ User-Name ]
[ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
*[ Subscription-Id ]
{ Subscription-Id-Type }
{ Subscription-Id-Data }
[ Service-Identifier ]
[ Termination-Cause ]
[ Requested-Service-Unit ]
[ CC-Time ]
[ CC-Money ]
{ Unit-Value }
[ Currency-Code ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
[ Requested-Action ]
*[ Used-Service-Unit ]
[ Tariff-Change-Usage ]
[ CC-Time ]
[ CC-Money ]
{ Unit-Value }
[ Currency-Code ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
[ Multiple-Services-Indicator ]
*[ Multiple-Services-Credit-Control ]
[ Requested-Service-Unit ]
[ CC-Time ]
[ CC-Money ]
{ Unit-Value }
[ Currency-Code ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
*[ Used-Service-Unit ]
[ Tariff-Change-Usage ]
[ CC-Time ]
[ CC-Money ]
{ Unit-Value }
[ Currency-Code ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
*[ Service-Identifier ]
[ Rating-Group ]
*[ AVP ]
*[ Service-Parameter-Info ]
{ Service-Parameter-Type }
{ Service-Parameter-Value }
[ CC-Correlation-Id ]
[ User-Equipment-Info ]
{ User-Equipment-Info-Type }
{ User-Equipment-Info-Value }
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]
<Credit-Control-Answer> ::=
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Application-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ User-Name ]
[ Destination-Host ]
[ CC-Session-Failover ]
[ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
[ Granted-Service-Unit ]
[ Tariff-Time-Change ]
[ CC-Time ]
[ CC-Money ]
{ Unit-Value }
{ Value-Digits }
[ Exponent ]
[ Currency-Code ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
*[ Multiple-Services-Credit-Control ]
[ Granted-Service-Unit ]
[ Tariff-Time-Change ]
[ CC-Time ]
[ CC-Money ]
{ Unit-Value }
{ Value-Digits }
[ Exponent ]
[ Currency-Code ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
[ Tariff-Change-Usage ]
*[ Service-Identifier ]
[ Rating-Group ]
*[ G-S-U-Pool-Reference ]
{ G-S-U-Pool-Identifier }
{ CC-Unit-Type }
{ Unit-Value }
{ Value-Digits }
[ Exponent ]
[ Validity-Time ]
[ Result-Code ]
[ Final-Unit-Indication ]
{ Final-Unit-Action }
*[ Restriction-Filter-Rule ]
*[ Filter-Id ]
[ Redirect-Server ]
{ Redirect-Address-Type }
{ Redirect-Server-Address }
*[ AVP ]
[ Cost-Information]
{ Unit-Value }
{ Value-Digits }
[ Exponent ]
{ Currency-Code }
[ Cost-Unit ]
[ Final-Unit-Indication ]
{ Final-Unit-Action }
*[ Restriction-Filter-Rule ]
*[ Filter-Id ]
[ Redirect-Server ]
{ Redirect-Address-Type }
{ Redirect-Server-Address }
*[ AVP ]
[ Check-Balance-Result ]
[ Credit-Control-Failure-Handling ]
[ Direct-Debiting-Failure-Handling ]
[ Validity-Time]
*[ Redirect-Host]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ Failed-AVP ]
*[ AVP ]
Below chart shows the http://whytelecom.com/modules/fckeditor/fckeditor/editor/css/images/fck_...); background-repeat: no-repeat; padding-left: 18px; background-position: 0px 50%; ">Comparison of Diameter and RADIUS protocols
|
Diameter
|
RADIUS
|
|
|
Transportation Protocol
|
Connection-Oriented Protocols (TCP and SCTP)
|
Connectionless Protocol (UDP)
|
|
Security
|
Hop-to-Hop, End-to-End
|
Hop-to-Hop
|
|
Agent Support
|
Relay, Proxy, Redirect, Translation
|
Implicit support, which means the agent behaviors might be implemented in a RADIUS server
|
|
Capabilities Negotiation
|
Negotiate supported applications and security level
|
Don't support
|
|
Peer Discovery
|
Static configuration and dynamic lookup
|
Static configuration
|
|
Server Initiated Message
|
Supported. for example, re-authentication message, Session termination
|
Don't support
|
|
Maximum Attribute Data Size
|
16,777,215 octets
|
255 octets
|
|
Vendor-specific Support
|
Support both vendor-specific messages and attributes
|
Support vendor-specific attributes only
|
