Note

This page has been converted into DocBook XML, and is available online as part of the Diameter User Guide, at the following location:

http://hudson.jboss.org/hudson/job/MobicentsBooks/lastSuccessfulBuild/artifact/diameter/index.html

No further updates will be made to this page.

Mobicents Diameter


Introduction
Diameter is a computer networking protocol for AAA (Authentication, Authorization and Accounting) defined in RFC 3588. It is a successor to RADIUS (and its name is a reference to it, a diameter is twice the radius) offering the following advantages:

    » Reliable transport protocols (TCP or SCTP, not UDP);
    » Network or transport level security (IPsec or TLS);
    » Transition support for RADIUS, although Diameter is not fully compatible with RADIUS;
    » Larger address space for attribute-value pairs (AVPs) and identifiers (32 bits instead of 8 bits);
    » Client-server protocol, with exception of supporting some server-initiated messages as well;
    » Both stateful and stateless models can be used;
    » Dynamic discovery of peers (using DNS SRV and NAPTR);
    » Capability negotiation;
    » Supports application layer acknowledgements, defines failover methods and state machines (RFC 3539);
    » Error notification;
    » Better roaming support;
    » More easily extended; new commands and attributes can be defined;
    » Aligned on 32-bit boundaries;
    » Basic support for user-sessions and accounting;

It was designed in a way to be compatible with RADIUS but also to be easily extended with new use cases within AAA scenario and other IMS scenarios. Extensions are called "Applications".

Each application introduces new kind of messages, message and AVP codes (assigned by IANA) and state machines. Moreover each application has its own Application-Id and Vendor-Id which distinguishes its messages from messages of another application. In addition, application code gives means of telling other peers what operations are supported by connecting peer (Capabilities Exchange).

Diameter is a pretty simple protocol. Message consists of header and payload. Payload is filled with AVPs, which also have their own header and data.

This is what a Diameter Message should look like. You can see it has several headers:
  » Version – Indicates Diameter version, which is always “1”;
  » Message Length – Indicates the length of the Diameter message including the header fields;
  » Command Flags – These bits define if it is a R(equest), if it is P(roxiable), if it is an E(rror) message and/or if it is a T(Potentially re-transmitted message). Remaining 4 bits are reserved for future use and should be set to “0”;
  » Command-Code – Indicates the command associated with the message, ie, what kind of message it is;
  » Application-ID – This is used to identify to which application the message is applicable for.  The application can be an authentication application, an accounting application or a vendor specific application.
  » Hop-by-Hop Identifier – This field aids in matching requests and replies. It should be unique on a given connection at any given time. Answer message must ensure that the Hop-by-Hop Identifier field contains the same value that was found in the corresponding request;
  » End-to-End Identifier – It is used to detect duplicate messages. It should be unique in each message sent, for at least 4 minutes.  The originator of an Answer message must ensure that the End-to-End Identifier field contains the same value that was found in the corresponding request.

After these headers, payload consist in AVPs.

The header fields for AVP are:
  » AVP Code – The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS, without setting the Vendor-Id field.  AVP numbers 256 and above are used for Diameter, which are allocated by IANA;
  » AVP Flags – The AVP Flags field informs the receiver how each attribute must be handled. It can be P(rotected) meaning the need for encryption for end-to-end security, M(andatory) indicating whether support of the AVP is required (default: true), and/or V(endor-Specific) indicating whether the optional Vendor-ID field is present in the AVP header (default: false);
  » AVP Length – Indicates the number of octets in this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID field (if present) and the AVP data;
  » Vendor-ID (optional) – The Vendor-ID field is present if the “V” bit is set in the AVP Flags field.

  » r -  is reserved bit.

Mobicents Diameter Solution

With Mobicents Diameter you get a full solution for your Diameter needs. You can use it as a standalone or inside JAIN SLEE environment by using or Resource Adaptors. Examples are provided for each Application supported. Some are more complex while others are just simple shoot and receive. Please follow the links for more information on each one:

• Core
   » Stack
   » Multiplexer
• JAIN SLEE Resource Adaptor Components:|
   » Base
   » Sh (Client)
   » Sh (Server)
   » Ro
   » Rf
   » Credit Control Application (CCA)
  
• Example applications (both for JSLEE and J2EE)
   » Base and Mobicents SIP Servlets Event Call Charging
   » Sh (Server)
   » Ro
   » Rf
   » Sh (Client) and OpenIMS Integration
   » CCA (Shooter/Shootist)
  

The following image is a diagram of the Mobicents Diameter Solution Architecture:

Mobicents Diameter Roadmap