 |
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
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 ).
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.
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 )
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
-- Main.ivelin - 15 Apr 2006
-- Main.baranowb - 19 May 2006
|