 |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | |
- 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. | | | -- Main.ivelin - 15 Apr 2006
-- Main.baranowb - 19 May 2006 |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | |
Main Concept of RA/RAType | |
<
< | So what do we know?
Diameter Request/Response message flow is similar to SIP message flow. So why not use same idea that has been implemented by SIP?
SIP Server/ClientTransaction pattern fits here perfectly. We would have two different interface relating to client/server activities. Thus it would be logical to create two different Activity objects.
First one implementing ClientTransactions and second Implementing ServerTransactions.
Objects implementing ClientTransactions interface would define methods of creating requests ( and in some cases responses ) with correspondence to appropriate application. Similar behaviour would characterize ServerTransactions.
Server/ClientTransactions objects would be SLEE ActivityObjects?. Each instance would be responsible for maintaining one session. ServerTransactions objects would be created by RA when request is beeing handled ( ofcourse when there is no other ServerTransactions object bound to Session-Id AVP value), before delivery to SLEE. One the orher hand ClientTransactions would be created by SLEE application to handle new session.
Lets make it more clear with some diagrams. On first diagram we see data/control flow in scenerio in which Sbb acts as client of one of Diameter Server nodes.
One session example
Now lets look closer to the flow:
- Sbb has a need to act as a Diameter Client. It calls __createXXXInterfaceClientTransactions method of some interface ( lets call it TransactionsProvider?).
- TransactionsProvider? objects forwards this request to RA.
- RA creates new ClientTransactions object and registers it in its Activities storage. ClientTransaction? objects knows to which host messages should be sent it also knows for which application it has been created and for which session it works as activity.
- RA returna newly created ClientTransactions in order to provide Sbb with means to create Request to particular host.
- Sbb uses ClientTransactions to create and send request.
- Request is sent by Diameter stack with use of appropriate method.
Now lets see what actions will be undertaken when response to some request will be received:
- Server node creates response and sends it back to originating node.
- This step is "internal". RA checks wheather message is Request or Response ( Request processing is explained on other dagram ).
- RA simply fires "Response" to SLEE.
- Sbb receives Reponse and ClientTransactions object (within ActivityContextInterface? object ) created earlier so it can create new request in the same session.
Scenario in which Sbb is "talking" with two different nodes in two different sessions is quite simple because it does not introduce nothing new to first ones. However lets atleast have a look on it:
More than one session
Acting ass server node
- Client creates and sends request to our node.
- If there is no ServerTransactions object associated with ongoing session RA creates one
- RA fires event to SLEE
- Sbb receives Requestand ServerTransactions object (within ActivityContextInterface? object ) created earlier so it can create response ( and sometimes requests ) in the same session.
| | | | |
>
> | 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
| | | -- Main.ivelin - 15 Apr 2006
-- Main.baranowb - 19 May 2006 |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | 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. | |
<
< | Short Diameter description
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.
Extensions are called "Applications". Each application introduces new kind of messages,codes assigned to those kind by IANA, processing logic and so on. | >
> | 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 Session State Machines
Here are session state machines which according to rfc 3588 should be implemented in Diameter Services
For message codes see [ [http://wiki.java.net/bin/view/Communications/MobicentsDiameterRA#Pure_Diameter][this table] ]
Stateful Client
The following state machine is observed by a client when state is maintained on the server:
| State Machine Transitions for Stateful Client |
|---|
| State | Transition | Cause | Response/Action |
|---|
| Idle | 1 | Client requests access | Send to server service specific auth request |
| Idle | 10 | ASR Received for unknown session | Send ASA to server with Result-Code= UNKNOWN_SESSION_ID |
| Pending | 3 | Successful Service-specific authorization answer received with default Auth-Session-State value | Grant Access |
| Pending | 4 | Successful Service-specific authorization answer received but service not provided | Sent STR to server |
| Pending | 4 | Error processing successful Service-specific authorization answer | Sent STR to server |
| Pending | 2 | Failed Service-specific authorization answer received | Cleanup - free resources allocated for session |
| Open | 6 | User or client device requests access to service | Send service specific auth req |
| Open | 6 | Successful Service-specific authorization answer received | Provide Service |
| Open | 7 | Failed Service-specific authorization answer received. | Discon. user/device |
| Open | 5 | Session-Timeout Expires on Access Device | Send STR |
| Open | 5 | ASR Received, client will comply with request to end the session | Send ASA with Result-Code = SUCCESS,Send STR. |
| Open | 6 | ASR Received, client will not comply with request to end the session | Send ASA with Result-Code = SUCCESS |
| Open | 5 | Authorization-Lifetime + Auth-Grace-Period expires on access device | Send STR |
| Discon | 8 | ASR Received | Send ASA |
| Discon | 9 | STA Received | Discon. user/device |
Stateful Server
The following state machine is observed by a server when it is maintaining state for the session:
| State Machine Transitions for Stateful Server |
|---|
| State | Transition | Cause | Response |
|---|
| Idle | 1 | Service-specific authorization request received, and user is authorized | Send successful serv. specific answer |
| Idle | 7 | Service-specific authorization request received, and user is not authorized | Send failed serv. specific answer |
| Open | 3 | Service-specific authorization request received, and user is authorized | Send successful serv. specific answer |
| Open | 2 | Service-specific authorization request received, and user is not authorized | Send failed serv. specific answer, Cleanup |
| Open | 4 | Home server wants to terminate the service | Send ASR |
| Open | 2 | Authorization-Lifetime (and Auth-Grace-Period) expires on home server. | Cleanup |
| Open | 2 | Session-Timeout expires on home server | Cleanup |
| Discon | 5 | Failure to send ASR | Wait,resend ASR |
| Discon | 6 | ASR successfully sent and ASA Received with Result-Code | Cleanup |
| Not Discon | None | ASA Received | None |
| Any | 2,6,7 | STR Received | Send STA |
Stateless Client
The following state machine is observed by a client when state is not maintained on the server:
| State Machine Transitions for Stateless Client |
|---|
| State | Transition | Cause | Response |
|---|
| Idle | 1 | Client or Device Requests access | Send service specific auth req |
| Pending | 2 | Successful Service-specific authorization answer received with Auth-Session-State set to NO_STATE_MAINTAINED | Grant Access |
| Pending | 4 | Failed Service-specific authorization answer received | Cleanup |
| Open | 3 | Session-Timeout Expires on Access Device | Discon. user/device |
| Open | 3 | Service to user is terminated | Discon. user/device |
Stateless Server
The following state machine is observed by a server when it is not maintaining state for the session:
| State Machine Transitions for Stateless Server |
|---|
| State | Transition | Cause | Response |
|---|
| Idle | 1 | Service-specific authorization request received, and successfully processed | Send serv. specific answer |
Resource Adaptor Type
First thing on path to creating Resource adaptor is to create RA Type. It usually consists of XML files describing event types, resurce adaptor type and propably file desribing deployable unit.
Event types
Event "types" are defined in event-jar.xml file. Each event is distinguished by combination of venor, version and name. See section 3.2 of JAIN SLEE spec. for more details.
Each application type in defined in Diameter will with high propability define some new message codes and values of standard ( and newly defined AVPs ) AVPs. Here is short listing of message codes and description of messages.
Pure Diameter | >
> |
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 |
| | |
| 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 |
| |
<
< | Sh interface (3GPP Application)
Here are codes and desriptions for message types defined for 3GPP application by IANA
| 3GPP messages |
|---|
| Message Name | Abbreviation | Code value | Description | RFC 3588 location |
|---|
| User-Data-Request | UDR | 306 | Is sent by AS to HSS when AS needs to access/ retireve soem data regarding user | 6.1.1 |
| User-Data-Answer | UDA | 306 | Response either conatinin data requested in UDR or apprioriate error code | 6.1.2 |
| Profile-Update-Request | PUR | 307 | Is sent by AS to update some data in HSS. | 6.1.3 |
| Profile-Update-Answer | PUA | 307 | Response for PUR | 6.1.4 |
| Subscribe-Notifications-Request | SNR | 308 | Is sent by AS when it wonts to be notified (or not ) when some data has changed after subsritpion. Works as subsribe/unsubsribe . | 6.1.5 |
| Subscribe-Notifications-Answer | SNA | 308 | Response to SNR . | 6.1.6 |
| Push-Notification-Request | PNR | 309 | Request sent by HSS to AS which has subsribed itself for notifications | 6.1.7 |
| Push-Notification-Answer | PNA | 309 | Reponse to PNA | 6.1.8 |
| >
> | Diameter Applications
Here is list of supported applications. ( Or currently in implementation ) | | | | |
<
< | Resource Adaptor Type design | | | | |
>
> | Main Concept of RA/RAType | | | So what do we know?
Diameter Request/Response message flow is similar to SIP message flow. So why not use same idea that has been implemented by SIP? |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | | |
>
> | | | |
- Diameter Interoperability document.
- Diameter interoperability effort:
|
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | Short Diameter description
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.
Extensions are called "Applications". Each application introduces new kind of messages,codes assigned to those kind 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. | >
> | 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 Session State Machines
For message codes see [ [http://wiki.java.net/bin/view/Communications/MobicentsDiameterRA#Pure_Diameter][this table] ]
Stateful Client
| State Machine Transitions for Stateful Client |
|---|
| State | Transition | Cause | Response/Action |
|---|
| Idle | 1 | Client requests access | Send to server service specific auth request |
| Idle | 10 | ASR Received for unknown session | Send ASA to server with Result-Code= UNKNOWN_SESSION_ID |
| Pending | 3 | Successful Service-specific authorization answer received with default Auth-Session-State value | Grant Access |
| Pending | 4 | Successful Service-specific authorization answer received but service not provided | Sent STR to server |
| Pending | 4 | Error processing successful Service-specific authorization answer | Sent STR to server |
| Pending | 2 | Failed Service-specific authorization answer received | Cleanup - free resources allocated for session |
| Open | 6 | User or client device requests access to service | Send service specific auth req |
| Open | 6 | Successful Service-specific authorization answer received | Provide Service |
| Open | 7 | Failed Service-specific authorization answer received. | Discon. user/device |
| Open | 5 | Session-Timeout Expires on Access Device | Send STR |
| Open | 5 | ASR Received, client will comply with request to end the session | Send ASA with Result-Code = SUCCESS,Send STR. |
| Open | 6 | ASR Received, client will not comply with request to end the session | Send ASA with Result-Code = SUCCESS |
| Open | 5 | Authorization-Lifetime + Auth-Grace-Period expires on access device | Send STR |
| Discon | 8 | ASR Received | Send ASA |
| Discon | 9 | STA Received | Discon. user/device |
Stateful Server
| State Machine Transitions for Stateful Server |
|---|
| State | Transition | Cause | Response |
|---|
| Idle | 1 | Service-specific authorization request received, and user is authorized | Send successful serv. specific answer |
| Idle | 7 | Service-specific authorization request received, and user is not authorized | Send failed serv. specific answer |
| Open | 3 | Service-specific authorization request received, and user is authorized | Send successful serv. specific answer |
| Open | 2 | Service-specific authorization request received, and user is not authorized | Send failed serv. specific answer, Cleanup |
| Open | 4 | Home server wants to terminate the service | Send ASR |
| Open | 2 | Authorization-Lifetime (and Auth-Grace-Period) expires on home server. | Cleanup |
| Open | 2 | Session-Timeout expires on home server | Cleanup |
| Discon | 5 | Failure to send ASR | Wait,resend ASR |
| Discon | 6 | ASR successfully sent and ASA Received with Result-Code | Cleanup |
| Not Discon | None | ASA Received | None |
| Any | 2,6,7 | STR Received | Send STA |
Stateless Client
| State Machine Transitions for Stateless Client |
|---|
| State | Transition | Cause | Response |
|---|
| Idle | 1 | Client or Device Requests access | Send service specific auth req |
| Pending | 2 | Successful Service-specific authorization answer received with Auth-Session-State set to NO_STATE_MAINTAINED | Grant Access |
| Pending | 4 | Failed Service-specific authorization answer received | Cleanup |
| Open | 3 | Session-Timeout Expires on Access Device | Discon. user/device |
| Open | 3 | Service to user is terminated | Discon. user/device |
Stateless Server
| State Machine Transitions for Stateless Server |
|---|
| State | Transition | Cause | Response |
|---|
| Idle | 1 | Service-specific authorization request received, and successfully processed | Send serv. specific answer |
| | | | |
<
< | 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 ). | | | Resource Adaptor Type
First thing on path to creating Resource adaptor is to create RA Type. It usually consists of XML files describing event types, resurce adaptor type and propably file desribing deployable unit.
Event types |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | |
- Diameter Interoperability document.
- Diameter interoperability effort:
| |
>
> | | | | |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | | |
<
< | | >
> |
- Diameter interoperability effort:
| | | |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | | |
<
< |
- Free or Open Source Diameter Products:
| | | | | | Diameter Request/Response message flow is similar to SIP message flow. So why not use same idea that has been implemented by SIP?
SIP Server/ClientTransaction pattern fits here perfectly. We would have two different interface relating to client/server activities. Thus it would be logical to create two different Activity objects. | |
<
< | First one implementing ClientTransactions? and second Implementing ServerTransactions?. | >
> | First one implementing ClientTransactions and second Implementing ServerTransactions. | | | | |
<
< | Objects implementing ClientTransactions? interface would define methods of creating requests ( and in some cases responses ) with correspondence to appropriate application. Similar behaviour would characterize ServerTransactions?.
Server/ClientTransactions objects would be SLEE ActivityObjects?. Each instance would be responsible for maintaining one session. ServerTransactions? objects would be created by RA when request is beeing handled ( ofcourse when there is no other ServerTransactions? object bound to Session-Id AVP value), before delivery to SLEE. One the orher hand ClientTransactions? would be created by SLEE application to handle new session. | >
> | Objects implementing ClientTransactions interface would define methods of creating requests ( and in some cases responses ) with correspondence to appropriate application. Similar behaviour would characterize ServerTransactions.
Server/ClientTransactions objects would be SLEE ActivityObjects?. Each instance would be responsible for maintaining one session. ServerTransactions objects would be created by RA when request is beeing handled ( ofcourse when there is no other ServerTransactions object bound to Session-Id AVP value), before delivery to SLEE. One the orher hand ClientTransactions would be created by SLEE application to handle new session. | | | Lets make it more clear with some diagrams. On first diagram we see data/control flow in scenerio in which Sbb acts as client of one of Diameter Server nodes. | |
>
> | One session example | | |
Now lets look closer to the flow:
- Sbb has a need to act as a Diameter Client. It calls __createXXXInterfaceClientTransactions method of some interface ( lets call it TransactionsProvider?).
- TransactionsProvider? objects forwards this request to RA.
| |
<
< |
- RA creates new ClientTransactions? object and registers it in its Activities storage. ClientTransaction? objects knows to which host messages should be sent it also knows for which application it has been created and for which session it works as activity.
- RA returna newly created ClientTransactions? in order to provide Sbb with means to create Request to particular host.
- Sbb uses ClientTransactions? to create and send request.
| >
> |
- RA creates new ClientTransactions object and registers it in its Activities storage. ClientTransaction? objects knows to which host messages should be sent it also knows for which application it has been created and for which session it works as activity.
- RA returna newly created ClientTransactions in order to provide Sbb with means to create Request to particular host.
- Sbb uses ClientTransactions to create and send request.
| | |
- Request is sent by Diameter stack with use of appropriate method.
Now lets see what actions will be undertaken when response to some request will be received: | |
<
< |
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.
Short Diameter description
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.
Extensions are called "Applications". Each application introduces new kind of messages,codes assigned to those kind 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 ).
Resource Adaptor Type
First thing on path to creating Resource adaptor is to create RA Type. It usually consists of XML files describing event types, resurce adaptor type and propably file desribing deployable unit.
Event types
Event "types" are defined in event-jar.xml file. Each event is distinguished by combination of venor, version and name. See section 3.2 of JAIN SLEE spec. for more details.
Each application type in defined in Diameter will with high propability define some new message codes and values of standard ( and newly defined AVPs ) AVPs. Here is short listing of message codes and description of messages.
Pure Diameter
| 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 |
Sh interface (3GPP Application)
Here are codes and desriptions for message types defined for 3GPP application by IANA
| 3GPP messages |
|---|
| Message Name | Abbreviation | Code value | Description | RFC 3588 location |
|---|
| User-Data-Request | UDR | 306 | Is sent by AS to HSS when AS needs to access/ retireve soem data regarding user | 6.1.1 |
| User-Data-Answer | UDA | 306 | Response either conatinin data requested in UDR or apprioriate error code | 6.1.2 |
| Profile-Update-Request | PUR | 307 | Is sent by AS to update some data in HSS. | 6.1.3 |
| Profile-Update-Answer | PUA | 307 | Response for PUR | 6.1.4 |
| Subscribe-Notifications-Request | SNR | 308 | Is sent by AS when it wonts to be notified (or not ) when some data has changed after subsritpion. Works as subsribe/unsubsribe . | 6.1.5 |
| Subscribe-Notifications-Answer | SNA | 308 | Response to SNR . | 6.1.6 |
| Push-Notification-Request | PNR | 309 | Request sent by HSS to AS which has subsribed itself for notifications | 6.1.7 |
| Push-Notification-Answer | PNA | 309 | Reponse to PNA | 6.1.8 |
| | | | |
>
> | | | | | |
<
< | Resource Adaptor Type design | >
> |
- Server node creates response and sends it back to originating node.
- This step is "internal". RA checks wheather message is Request or Response ( Request processing is explained on other dagram ).
- RA simply fires "Response" to SLEE.
- Sbb receives Reponse and ClientTransactions object (within ActivityContextInterface? object ) created earlier so it can create new request in the same session.
| | | | |
<
< | So what do we know? | >
> | Scenario in which Sbb is "talking" with two different nodes in two different sessions is quite simple because it does not introduce nothing new to first ones. However lets atleast have a look on it:
More than one session | | | | |
<
< | Diameter Request/Response message flow is similar to SIP message flow. So why not use same idea that has been implemented by SIP?
SIP Server/ClientTransaction pattern fits here perfectly. We would have two different interface relating to client/server activities. Thus it would be logical to create two different Activity objects.
First one implementing ClientTransactions? and second Implementing ServerTransactions?. | >
> | | | | | |
<
< | Objects implementing ClientTransactions? interface would define methods of creating requests ( and in some cases responses ) with correspondence to appropriate application. Similar behaviour would characterize ServerTransactions?.
Server/ClientTransactions objects would be SLEE ActivityObjects?. Each instance would be responsible for maintaining one session. ServerTransactions? objects would be created by RA when request is beeing handled ( ofcourse when there is no other ServerTransactions? object bound to Session-Id AVP value), before delivery to SLEE. One the orher hand ClientTransactions? would be created by SLEE application to handle new session. | >
> | | | | | |
<
< | Lets make it more clear with some diagrams. On first diagram we see data/control flow in scenerio in which Sbb acts as client of one of Diameter Server nodes. | >
> | Acting ass server node | | | | |
>
> | | | | | |
<
< | | >
> |
- Client creates and sends request to our node.
- If there is no ServerTransactions object associated with ongoing session RA creates one
- RA fires event to SLEE
- Sbb receives Requestand ServerTransactions object (within ActivityContextInterface? object ) created earlier so it can create response ( and sometimes requests ) in the same session.
| | | | |
<
< |
- Server node creates response and sends it back to originating node.
- This step is "internal". RA checks wheather message is Request or Response ( Request processing is explained on other dagram ).
- RA simply fires "Response" to SLEE.
- Sbb receives Reponse and ClientTransactions? object (within ActivityContextInterface? object ) created earlier so it can create new request in the same session.
| | | -- Main.ivelin - 15 Apr 2006
-- Main.baranowb - 19 May 2006 |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | | |
>
> |
- Free or Open Source Diameter Products:
| | | | | | Now lets see what actions will be undertaken when response to some request will be received: | |
>
> |
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.
Short Diameter description
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.
Extensions are called "Applications". Each application introduces new kind of messages,codes assigned to those kind 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 ).
Resource Adaptor Type
First thing on path to creating Resource adaptor is to create RA Type. It usually consists of XML files describing event types, resurce adaptor type and propably file desribing deployable unit.
Event types
Event "types" are defined in event-jar.xml file. Each event is distinguished by combination of venor, version and name. See section 3.2 of JAIN SLEE spec. for more details.
Each application type in defined in Diameter will with high propability define some new message codes and values of standard ( and newly defined AVPs ) AVPs. Here is short listing of message codes and description of messages.
Pure Diameter
| 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 |
Sh interface (3GPP Application)
Here are codes and desriptions for message types defined for 3GPP application by IANA
| 3GPP messages |
|---|
| Message Name | Abbreviation | Code value | Description | RFC 3588 location |
|---|
| User-Data-Request | UDR | 306 | Is sent by AS to HSS when AS needs to access/ retireve soem data regarding user | 6.1.1 |
| User-Data-Answer | UDA | 306 | Response either conatinin data requested in UDR or apprioriate error code | 6.1.2 |
| Profile-Update-Request | PUR | 307 | Is sent by AS to update some data in HSS. | 6.1.3 |
| Profile-Update-Answer | PUA | 307 | Response for PUR | 6.1.4 |
| Subscribe-Notifications-Request | SNR | 308 | Is sent by AS when it wonts to be notified (or not ) when some data has changed after subsritpion. Works as subsribe/unsubsribe . | 6.1.5 |
| Subscribe-Notifications-Answer | SNA | 308 | Response to SNR . | 6.1.6 |
| Push-Notification-Request | PNR | 309 | Request sent by HSS to AS which has subsribed itself for notifications | 6.1.7 |
| Push-Notification-Answer | PNA | 309 | Reponse to PNA | 6.1.8 |
Resource Adaptor Type design
So what do we know?
Diameter Request/Response message flow is similar to SIP message flow. So why not use same idea that has been implemented by SIP?
SIP Server/ClientTransaction pattern fits here perfectly. We would have two different interface relating to client/server activities. Thus it would be logical to create two different Activity objects.
First one implementing ClientTransactions? and second Implementing ServerTransactions?.
Objects implementing ClientTransactions? interface would define methods of creating requests ( and in some cases responses ) with correspondence to appropriate application. Similar behaviour would characterize ServerTransactions?.
Server/ClientTransactions objects would be SLEE ActivityObjects?. Each instance would be responsible for maintaining one session. ServerTransactions? objects would be created by RA when request is beeing handled ( ofcourse when there is no other ServerTransactions? object bound to Session-Id AVP value), before delivery to SLEE. One the orher hand ClientTransactions? would be created by SLEE application to handle new session.
Lets make it more clear with some diagrams. On first diagram we see data/control flow in scenerio in which Sbb acts as client of one of Diameter Server nodes. | | | |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | |
| |
>
> | Now lets look closer to the flow:
- Sbb has a need to act as a Diameter Client. It calls __createXXXInterfaceClientTransactions method of some interface ( lets call it TransactionsProvider?).
- TransactionsProvider? objects forwards this request to RA.
- RA creates new ClientTransactions? object and registers it in its Activities storage. ClientTransaction? objects knows to which host messages should be sent it also knows for which application it has been created and for which session it works as activity.
- RA returna newly created ClientTransactions? in order to provide Sbb with means to create Request to particular host.
- Sbb uses ClientTransactions? to create and send request.
- Request is sent by Diameter stack with use of appropriate method.
Now lets see what actions will be undertaken when response to some request will be received:
- Server node creates response and sends it back to originating node.
- This step is "internal". RA checks wheather message is Request or Response ( Request processing is explained on other dagram ).
- RA simply fires "Response" to SLEE.
- Sbb receives Reponse and ClientTransactions? object (within ActivityContextInterface? object ) created earlier so it can create new request in the same session.
| | | -- Main.ivelin - 15 Apr 2006
-- Main.baranowb - 19 May 2006 |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | Objects implementing ClientTransactions? interface would define methods of creating requests ( and in some cases responses ) with correspondence to appropriate application. Similar behaviour would characterize ServerTransactions?.
Server/ClientTransactions objects would be SLEE ActivityObjects?. Each instance would be responsible for maintaining one session. ServerTransactions? objects would be created by RA when request is beeing handled ( ofcourse when there is no other ServerTransactions? object bound to Session-Id AVP value), before delivery to SLEE. One the orher hand ClientTransactions? would be created by SLEE application to handle new session. | |
>
> | Lets make it more clear with some diagrams. On first diagram we see data/control flow in scenerio in which Sbb acts as client of one of Diameter Server nodes.
| | | -- Main.ivelin - 15 Apr 2006
-- Main.baranowb - 19 May 2006 |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | Event "types" are defined in event-jar.xml file. Each event is distinguished by combination of venor, version and name. See section 3.2 of JAIN SLEE spec. for more details.
Each application type in defined in Diameter will with high propability define some new message codes and values of standard ( and newly defined AVPs ) AVPs. Here is short listing of message codes and description of messages.
Pure Diameter | |
<
< |
| Diameter Base Protocol messages |
| Message Name | Abbreviation | Code value | Description | RFC 3588 location |
| >
> |
| 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 |
| | |
Sh interface (3GPP Application)
Here are codes and desriptions for message types defined for 3GPP application by IANA | |
<
< |
| 3GPP messages |
| Message Name | Abbreviation | Code value | Description | RFC 3588 location |
| >
> |
| 3GPP messages |
|---|
| Message Name | Abbreviation | Code value | Description | RFC 3588 location |
|---|
| | |
| User-Data-Request | UDR | 306 | Is sent by AS to HSS when AS needs to access/ retireve soem data regarding user | 6.1.1 |
| User-Data-Answer | UDA | 306 | Response either conatinin data requested in UDR or apprioriate error code | 6.1.2 |
| Profile-Update-Request | PUR | 307 | Is sent by AS to update some data in HSS. | 6.1.3 |
| | |
| Subscribe-Notifications-Answer | SNA | 308 | Response to SNR . | 6.1.6 |
| Push-Notification-Request | PNR | 309 | Request sent by HSS to AS which has subsribed itself for notifications | 6.1.7 |
| Push-Notification-Answer | PNA | 309 | Reponse to PNA | 6.1.8 |
| |
>
> | | | | Resource Adaptor Type design
| |
>
> | So what do we know?
Diameter Request/Response message flow is similar to SIP message flow. So why not use same idea that has been implemented by SIP?
SIP Server/ClientTransaction pattern fits here perfectly. We would have two different interface relating to client/server activities. Thus it would be logical to create two different Activity objects.
First one implementing ClientTransactions? and second Implementing ServerTransactions?.
Objects implementing ClientTransactions? interface would define methods of creating requests ( and in some cases responses ) with correspondence to appropriate application. Similar behaviour would characterize ServerTransactions?.
Server/ClientTransactions objects would be SLEE ActivityObjects?. Each instance would be responsible for maintaining one session. ServerTransactions? objects would be created by RA when request is beeing handled ( ofcourse when there is no other ServerTransactions? object bound to Session-Id AVP value), before delivery to SLEE. One the orher hand ClientTransactions? would be created by SLEE application to handle new session. | | | -- Main.ivelin - 15 Apr 2006
-- Main.baranowb - 19 May 2006 |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | 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.
Short Diameter description | |
<
< | Diameter is meant to be extensible protocol. However this extensibility has to be under some kind of surveillance. IANA holds grasp over Diameter extensibility. This organization assigns message codes and values for protocol related AVPs. | >
> | 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.
Extensions are called "Applications". Each application introduces new kind of messages,codes assigned to those kind 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 ). | | | Resource Adaptor Type
First thing on path to creating Resource adaptor is to create RA Type. It usually consists of XML files describing event types, resurce adaptor type and propably file desribing deployable unit.
Event types | | |
| 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 | 5.3.1 |
| >
> |
| 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 |
| | | Here are codes and desriptions for message types defined for 3GPP application by IANA
| 3GPP messages |
| Message Name | Abbreviation | Code value | Description | RFC 3588 location |
| |
<
< |
| User-Data-Request | UDR | 306 | 6.1.1 |
| User-Data-Answer | UDA | 306 | 6.1.2 |
| Profile-Update-Request | PUR | 307 | 6.1.3 |
| Profile-Update-Answer | PUA | 307 | 6.1.4 |
| Subscribe-Notifications-Request | SNR | 308 | 6.1.5 |
| Subscribe-Notifications-Answer | SNA | 308 | 6.1.6 |
| Push-Notification-Request | PNR | 309 | 6.1.7 |
| Push-Notification-Answer | PNA | 309 | 6.1.8 |
Sh interface design | >
> |
| User-Data-Request | UDR | 306 | Is sent by AS to HSS when AS needs to access/ retireve soem data regarding user | 6.1.1 |
| User-Data-Answer | UDA | 306 | Response either conatinin data requested in UDR or apprioriate error code | 6.1.2 |
| Profile-Update-Request | PUR | 307 | Is sent by AS to update some data in HSS. | 6.1.3 |
| Profile-Update-Answer | PUA | 307 | Response for PUR | 6.1.4 |
| Subscribe-Notifications-Request | SNR | 308 | Is sent by AS when it wonts to be notified (or not ) when some data has changed after subsritpion. Works as subsribe/unsubsribe . | 6.1.5 |
| Subscribe-Notifications-Answer | SNA | 308 | Response to SNR . | 6.1.6 |
| Push-Notification-Request | PNR | 309 | Request sent by HSS to AS which has subsribed itself for notifications | 6.1.7 |
| Push-Notification-Answer | PNA | 309 | Reponse to PNA | 6.1.8 |
Resource Adaptor Type design | | | -- Main.ivelin - 15 Apr 2006 |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | Pure Diameter
| Diameter Base Protocol messages |
| Message Name | Abbreviation | Code value | Description | RFC 3588 location |
| |
<
< |
| Abort-Session-Request | ASR | 274 | | 8.5.1 |
| Abort-Session-Answer | ASA | 274 | | 8.5.2 |
| Accounting-Request | ACR | 271 | | 9.7.1 |
| Accounting-Answer | ACA | 271 | | 9.7.2 |
| Capabilities-Exchange-Request | CER | 257 | | 5.3.1 |
| Capabilities-Exchange-Answer | CEA | 257 | 5.3.2 |
| Device-Watchdog-Request | DWR | 280 | | 5.5.1 |
| Device-Watchdog-Answer | DWA | 280 | | 5.5.2 |
| Disconnect-Peer-Request | DPR | 282 | | 5.4.1 |
| Disconnect-Peer-Answer | DPA | 282 | | 5.4.2 |
| Re-Auth-Request | RAR | 258 | | 8.3.1 |
| Re-Auth-Answer | RAA | 258 | | 8.3.2 |
| >
> |
| 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 | 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 |
Sh interface (3GPP Application) | |
>
> | Here are codes and desriptions for message types defined for 3GPP application by IANA
| 3GPP messages |
| Message Name | Abbreviation | Code value | Description | RFC 3588 location |
| User-Data-Request | UDR | 306 | 6.1.1 |
| User-Data-Answer | UDA | 306 | 6.1.2 |
| Profile-Update-Request | PUR | 307 | 6.1.3 |
| Profile-Update-Answer | PUA | 307 | 6.1.4 |
| Subscribe-Notifications-Request | SNR | 308 | 6.1.5 |
| Subscribe-Notifications-Answer | SNA | 308 | 6.1.6 |
| Push-Notification-Request | PNR | 309 | 6.1.7 |
| Push-Notification-Answer | PNA | 309 | 6.1.8 |
| | | Sh interface design
-- Main.ivelin - 15 Apr 2006 |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | Event "types" are defined in event-jar.xml file. Each event is distinguished by combination of venor, version and name. See section 3.2 of JAIN SLEE spec. for more details.
Each application type in defined in Diameter will with high propability define some new message codes and values of standard ( and newly defined AVPs ) AVPs. Here is short listing of message codes and description of messages.
Pure Diameter | |
<
< |
| Diameter Base Protocol messages |
| Message Name | Abbreviation | Code value | Description | Format | RFC 3588 location |
| Abort-Session-Request | ASR | 274 | | | 8.5.1 |
| Abort-Session-Answer | ASA | 274 | | | 8.5.2 |
| Accounting-Request | ACR | 271 | | | 9.7.1 |
| Accounting-Answer | ACA | 271 | | | 9.7.2 |
| Capabilities-Exchange-Request | CER | 257 | | | 5.3.1 |
| Capabilities-Exchange-Answer | CEA | 257 | | | 5.3.2 |
| Device-Watchdog-Request | DWR | 280 | | | 5.5.1 |
| Device-Watchdog-Answer | DWA | 280 | | | 5.5.2 |
| Disconnect-Peer-Request | DPR | 282 | | | 5.4.1 |
| Disconnect-Peer-Answer | DPA | 282 | | | 5.4.2 |
| Re-Auth-Request | RAR | 258 | | | 8.3.1 |
| Re-Auth-Answer | RAA | 258 | | | 8.3.2 |
| Session-Termination-Request | STR | 275 | | | 8.4.1 |
| Session-Termination-Answer | STA | 275 | | | 8.4.2 |
| >
> |
| Diameter Base Protocol messages |
| Message Name | Abbreviation | Code value | Description | RFC 3588 location |
| Abort-Session-Request | ASR | 274 | | 8.5.1 |
| Abort-Session-Answer | ASA | 274 | | 8.5.2 |
| Accounting-Request | ACR | 271 | | 9.7.1 |
| Accounting-Answer | ACA | 271 | | 9.7.2 |
| Capabilities-Exchange-Request | CER | 257 | | 5.3.1 |
| Capabilities-Exchange-Answer | CEA | 257 | 5.3.2 |
| Device-Watchdog-Request | DWR | 280 | | 5.5.1 |
| Device-Watchdog-Answer | DWA | 280 | | 5.5.2 |
| Disconnect-Peer-Request | DPR | 282 | | 5.4.1 |
| Disconnect-Peer-Answer | DPA | 282 | | 5.4.2 |
| Re-Auth-Request | RAR | 258 | | 8.3.1 |
| Re-Auth-Answer | RAA | 258 | | 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 |
| | |
Sh interface (3GPP Application)
Sh interface design |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | Event "types" are defined in event-jar.xml file. Each event is distinguished by combination of venor, version and name. See section 3.2 of JAIN SLEE spec. for more details.
Each application type in defined in Diameter will with high propability define some new message codes and values of standard ( and newly defined AVPs ) AVPs. Here is short listing of message codes and description of messages.
Pure Diameter | |
<
< |
| Diameter Base Protocol messages |
| Message Name | Abbreviation | Code value | Description | Format |
| >
> |
| Diameter Base Protocol messages |
| Message Name | Abbreviation | Code value | Description | Format | RFC 3588 location |
| Abort-Session-Request | ASR | 274 | | | 8.5.1 |
| Abort-Session-Answer | ASA | 274 | | | 8.5.2 |
| Accounting-Request | ACR | 271 | | | 9.7.1 |
| Accounting-Answer | ACA | 271 | | | 9.7.2 |
| Capabilities-Exchange-Request | CER | 257 | | | 5.3.1 |
| Capabilities-Exchange-Answer | CEA | 257 | | | 5.3.2 |
| Device-Watchdog-Request | DWR | 280 | | | 5.5.1 |
| Device-Watchdog-Answer | DWA | 280 | | | 5.5.2 |
| Disconnect-Peer-Request | DPR | 282 | | | 5.4.1 |
| Disconnect-Peer-Answer | DPA | 282 | | | 5.4.2 |
| Re-Auth-Request | RAR | 258 | | | 8.3.1 |
| Re-Auth-Answer | RAA | 258 | | | 8.3.2 |
| Session-Termination-Request | STR | 275 | | | 8.4.1 |
| Session-Termination-Answer | STA | 275 | | | 8.4.2 |
| | | Sh interface (3GPP Application)
Sh interface design |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
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 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.
Short Diameter description
Diameter is meant to be extensible protocol. However this extensibility has to be under some kind of surveillance. IANA holds grasp over Diameter extensibility. This organization assigns message codes and values for protocol related AVPs.
Resource Adaptor Type
First thing on path to creating Resource adaptor is to create RA Type. It usually consists of XML files describing event types, resurce adaptor type and propably file desribing deployable unit.
Event types
Event "types" are defined in event-jar.xml file. Each event is distinguished by combination of venor, version and name. See section 3.2 of JAIN SLEE spec. for more details.
Each application type in defined in Diameter will with high propability define some new message codes and values of standard ( and newly defined AVPs ) AVPs. Here is short listing of message codes and description of messages.
Pure Diameter
| Diameter Base Protocol messages |
| Message Name | Abbreviation | Code value | Description | Format |
Sh interface (3GPP Application)
Sh interface design | | | | |
<
< | Resource Adaptor Type design | | | -- Main.ivelin - 15 Apr 2006
-- Main.baranowb - 19 May 2006 |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | | |
<
< | | >
> | Resource Adaptor Type design | | | -- Main.ivelin - 15 Apr 2006 | |
>
> | -- Main.baranowb - 19 May 2006 |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | | |
>
> | | | |
-- Main.ivelin - 15 Apr 2006 |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
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 and the related forum thread. If you would like to see the RA completed sooner than planned, you're welcome to join the team. | >
> | 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.
| | | | |
>
> | | | | |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
Mobicents Diameter Resource Adaptor | | | | |
>
> | | | | |
| |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
| |
>
> | 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 and the 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 | | | -- Main.ivelin - 15 Apr 2006 |
|
>
> |
| META TOPICPARENT | name="MobicentsFAQ" |
|---|
The Diameter Resource Adaptor is under active development. Initial binary release is expected in Q3Y06?. Follow the updates on this white board and the related forum thread. If you would like to see the RA completed sooner than planned, you're welcome to join the team.
-- Main.ivelin - 15 Apr 2006 |
|