Mobicents Diameter Resource Adaptor

The Diameter Resource Adaptor is under active development. Initial binary release is expected in Q3Y06^?. Follow the updates on this white board, issue tracker and related forum thread. If you would like to see the RA completed sooner than planned, you're welcome to join the team.

Roadmap

Implement IMS Cx interfaces for both client and server access. A Mobicents server should be able to play the roles (simulate?) of I-CSCF/S-CSCF and HSS.
Implement IMS Sh intefaces for both client and server access. A Mobicents server should be able to play the roles of an Application Server and HSS (simulator?).

Related Resources

Introduction to IMS, artcile on IBM DeveloperWorks^?
Diameter Java library home page
Diameter in IMS Tutorial (pdf}
Diameter Base Protocol, RFC 3588
Diameter Testing Tool, Seagull
Diameter Interoperability document.
Diameter interoperability effort:
- First interop event.
- Mailing List Registration: https://www1.ietf.org/mailman/listinfo/dime
- Announcement of the first interop event results: http://www1.ietf.org/mail-archive/web/dime/current/msg00276.html
- "Meeting minutes": http://www.tschofenig.com/dime-interop-2006/meeting-minutes.txt
- Issue tracker: (also includes issues from other sources than the event): http://www.tschofenig.com:8080/diameter-interop/

Other Diameter related RFCs
Commercial products
- AtosOrigin Marben
- Ulticom Signalware

Related HOWTO

I would strongly recommend to read this howto it gives quite good understanding what is going on in RA and how it works with SLEE.

Diameter

Diameter is descendant od RADIUS. It was designed in way it stays compatibile with RADIUS but can be easly extended with new kind of 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 ), processing logic and so on. Moreover each application has its own code which distinguishes its messages from messages of another application. In addition application code gives means of telling other peers what operations are suported by connecting peer. Diameter is quit simple protocol. Diameter message consists of header and payload. Both consist of AVPs ( Attribute Value Pairs : nameOfAttribute=value). AVP crucial to Base protocol ( and for applications ) has been standarized is related documents ( standarization accepted by IANA ).

Diameter State Machines

These are finite state machines which should be observered by client or server "talking" with other node. Peer connection state machine is impelmented by stack, session state machine and accounting state machines are not. Therefore last two should be implemented by service ( propably they will be partialy implemented by RA/Activities in the future). Click title to see list of states and graph for each machine.

Diameter Agents

Click the title to see agents description. (In near future basic designs of Agents ).

Diameter Basic Protocol

Base protocol defines common part for each application/node. Half of its messages ( CER-CEA/DWR-DWA/DP-DPA) are meant to manage connection between peers. Other half (ACR-ACA/ASR-ASA/STR-STA/ACR-ACA) are used by applications for accounting/authirization purposes and ofcourse session handling ( particulary for session termination ). Second half does not define stand alone functionality, rather as menioned before common part.

Event/Messages types

These are base protocol request and aswer pairs with short desc.

Diameter Base Protocol messages
Message Name	Abbreviation	Code value	Description	RFC 3588 location
Abort-Session-Request	ASR	274	May be sent by any server to the access device that is providing session service, to request that the session identified by the Session-Id be topped.	8.5.1
Abort-Session-Answer	ASA	274	Is sent in response to the ASR. Result code determines wheather session has been terminated sucsesfuly	8.5.2
Accounting-Request	ACR	271	Is sent by a Diameter node, acting as a client, in order to exchange accounting information with a peer.	9.7.1
Accounting-Answer	ACA	271	Is used to acknowledge an Accounting-Request command.	9.7.2
Capabilities-Exchange-Request	CER	257	Is sent to exchange local capabilities when connection between peers is beeing estabilished. It contains codes of supported applications	5.3.1
Capabilities-Exchange-Answer	CEA	257	Is sent in response to a CER message.	5.3.2
Device-Watchdog-Request	DWR	280	Is sent to a peer when no traffic has been exchanged between two peers (see Section 5.5.3 - RFC 3588).	5.5.1
Device-Watchdog-Answer	DWA	280	Is sent as a response to the Device-Watchdog-Request message.	5.5.2
Disconnect-Peer-Request	DPR	282	Is sent to a peer to inform its intentions to shutdown the transport connection. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.	5.4.1
Disconnect-Peer-Answer	DPA	282	Is sent as a response to the Disconnect-Peer-Request message. Upon receipt of this message, the transport connection is shutdown.	5.4.2
Re-Auth-Request	RAR	258	May be sent by any server to the access device that is providing session service, to request that the user be re-authenticated and/or re-authorized.	8.3.1
Re-Auth-Answer	RAA	258	Is sent in response to the RAR. The Result-Code AVP MUST be present, and indicates the disposition of the request. A successful RAA message MUST be followed by an application-specific authentication and/or authorization message.	8.3.2
Session-Termination-Request	STR	275	Is sent by the access device to inform the Diameter Server that an authenticated and/or authorized session is being terminated.	8.4.1
Session-Termination-Answer	STA	275	Is sent by the Diameter Server to acknowledge the notification that the session has been terminated. Upon sending or receipt of the STA, the Diameter Server MUST release all resources for the session indicated by the Session-Id AVP.	8.4.2

Diameter Applications

Here is list of supported applications. ( Or currently in implementation )

Sh interface (3GPP Application)

Main Concept of RA/RAType

So what do we know, what do we need? Lets see,what do we know :

Diameter is extensible. Extensions are called "Applications" and depending on application kind, application may inherit base protocol messages ( some part of them ).
more or less Request/Answer orientated ( exception would be EAP authentication - comment)
according to RFC 3588 each Diameter message has to contain value identificating session, unique value.
Applications can be distinguished easly by their IDs ( each meassage has it in header )
Diameter agents provide other diameter nodes with some functionality( proxy, relay, etc ). depending on type of agent its activity can be transparent or not.
RFC 3588 introduces state machines, which have to/should be followed by implementations. It seems that states are changed accordingly to specifical application.
Diameter is P2P so nodes are only aware of they neighboors ( see Diameter Agents ).

So now lets see how can we place Diameter Stack into SLEE. Following diagrams are meant to ilustrate approach that looks most reasonable. Time will show if its desired one. Its not finall, it should be treated ass starting point in disscusion. Design assumptions:

To standarize way of handling reqeust/responses we assume that each consequent request/response pair in one session will contain valid, unique and constant ( for duration of session ) Session-ID, besides this is what RFC 3588 states.
Activities should be aware of destination of their messages and from where messages come or shoul dbe sent ( and ofcourse through which connection).
Events delivered to SLEE should identify peer from which we have received message ( by address and connection )
Answer not matching any activity should be discarded
More ?

Lets see some use cases following guides mentioned above.

Sbb as Client of another node: sending request

What is going on here:

Sbb demands from Provider new activity. Sbb passes some information to Provider regarding this activity. First one is connection thorugh which requests should be sent to that node, second are host name an realm of destination node ( and few more less relevant information ).
Provider creates acitvity - or delegates it to DiameterRA.
Provider registers activity in DiameterRA
DiameterRA adds activity to activities pool.
Provider create ActivityContextInterface coresponding to created activity object.
Provider returns ACI to Sbb.
Sbb calls ACI's factory method and send method
Request is sent through apriopriate connection

Sbb as Client of another node: receiving answer

What is going on here:

Server node creates answer to our request, it fills Session-ID to one specified by us, otherwise no activity will be matched with this answer and it will get dropped.

Server node sends answer back

Resource Adaptor searches for apriopriate activity, if none is found it drops message
SLEE/RA delivers message to sbbs attached to acitivity ACI.

Sbb as Server for another node: receiving request

What is going on here:

Some node creates request destinated to SLEE.
Node sends this request
RA checks with current capabilities of node if application on behalf which this request has been created, is currently supported ( configured from properties file )
If application is supported RA creates apriopriate activity object and adds it to pool.
SLEE/RA delivers event to sbb.

WrappingEvent contains request, peer from which this request has been received ( not originating peer - but it could be when originating peer is our directly connected neighboor ) andconnection identifier which identifies connection through which request has been received.

Sbb as Server for another node: receiving answer

What is going on here:

Sbb creates answer with one of factory methods
Sbb calls ACIs answer method to send created answer.
RA sends asnwer through apriopriate connection

According to DIME Realm and Host should be equal. Both values are NAI ( Netowrk Address Identifier ) but it conflicts with rfc 3588.

Test Implementation (Subject to change)

Here You can find way of configuring RA prototype and some info about testing sevice/sbb

Test Impl

-- Main.ivelin - 15 Apr 2006

-- Main.baranowb - 19 May 2006

----- Revision r25 - 29 Jul 2006 - 16:35:50 - Main.baranowb