Skip to main content

Diameter RA Type(s)

28 replies [Last post]
ivelin
Offline
Joined: 2003-07-13
Points: 0

Transfering to this forum a discussion about standardizing Diameter RA Type(s).

A related discussion was started earlier on the following public Mobicents forum:
http://forums.java.net/jive/thread.jspa?messageID=113782&#113782

Ivelin

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
isj_javadiameter
Offline
Joined: 2006-05-21
Points: 0

I had a very quick look at TS 29.329 which covers the messages toward the HSS regarding:
- UDR/UDA (user-data)
- PUR/PUA (profile-update)
- SNR/SNA (subscribe-notifications)
- PNR/PNA (push-notifications)

It appears that the messages do not have any specific order and look at lot like non-related request/reply.

This indicates (I have not read all the documents, so beware) that the originator can just invent a session-id for that purpose, as I cannot see any reason that the session-id is there (except that some implementations obviously prefer to always have a session-id).

So in the case that Mobicents is the originating node it can invent a session-id (use dk.i1.diameter.node.makeNewSessionId()) and use that in the request.

In the case where Mobicents is the server (HSS) it can simply ignore the session-id because it has no use for it. And it should not create a "session" object or anything.

In the case where Mobicents is a proxy the best behaviour is probably to just forward the request and answer, possibly enriching them. But otherwise not keep any state.

isj_javadiameter
Offline
Joined: 2006-05-21
Points: 0

> It looks like session is estabilished in Sh operations only by specifing Session-Id, am I right?

The device transforming the network event (such as a user switching on his equipment) into diameter messages is responsible for producing a unique session-id. Conceptually the session exists from that time, but has not yet been authenticated/authorized. This state is what RFC3588 calls "pending" (section 8.1 page 93)

Another example is when a network probe detects that a user attempts to access a pay-per-use site. At that point the probe has to invent a session-id and use that for the authorization (reserve), and when the user has retrieved the content (commit reservation).

It is never the server that invents the session-id. It is always the originating diameter node that produces the session-id.

baranowb
Offline
Joined: 2006-01-09
Points: 0

Well thats what I had in mind, I should be more specific.
Correct me if Im wrong. When some node creates client type of Sh interface request is creates Session-Id and attaches it to request ( always ). HSS stores Session-Id and responds with the same Session-Id to that client.
Does is look like that?
Any way, diameter applications are extension so it looks resonable to create objects encapsulating base protocol activities ( one for server and one for client ) and extend them for client/server activities of applications.

It would be compatible with logic of extensions, wouldnt it?

baranowb
Offline
Joined: 2006-01-09
Points: 0

But Sh interface doesnt have authenticate/autorize operations. So session exists but it wont be in other state than "pending"?? HSS always checks if AS requesting some information is legitimate to receive them ( every time request is made ) So can we asume that "pending" is final state ofr session in Sh ?

ivelin
Offline
Joined: 2003-07-13
Points: 0

> I cant understand one thing. In introduction do
> Diameter author says that session is estabilished
> when authenticate user request is beeing sent ( just
> by adding Session-Id). But how session is
> estabilished in Sh?? There is no AUR in Sh. I cant
> find answer in TS's regarding Sh. It looks like
> session is estabilished in Sh operations only by
> specifing Session-Id, am I right?

I am not sure what the answer is, but hopefully someone else can respond. I will also ask Ivan to help here.

jbemmel
Offline
Joined: 2005-03-01
Points: 0

Unlike for SIP, there is no need to expose transactions for the Diameter RA API. They should be handled internally by the Diameter stack. If you look at the API (http://i1.dk/JavaDiameter/doc/) you will see that there are no transaction objects there

The reason for this is that Diameter creates a transaction for every request / response, while in SIP it is optional. For SIP the application may choose.

baranowb
Offline
Joined: 2006-01-09
Points: 0

No there are no transaction objects, only Session object.
Sessions are end receivers of diameter messages in one session. Session manager manages messages and delivers to apropriate session object for processing. There is one but here ( or maybe Im mistaken, correct me if Im wrong ) Session objects are not created when request comes from another node ( when current node acts like server ).
This is why I have created Transactions objects.
By transactions I have in mind Response/Request actions generated during one session.
This way for both Server and Client activities we will have similar way of handling events (reating requests and responses).

Should RA and Transactions objects implement diameter state machine? Or should this be pushed to implemented services? ( AA and other cases, not Sh where session is propably initiated ). This seems resonable when Session objects are end receivers of message, but in SLEE Sbb are end receivers.

By the way thanks jbemmel and isj for joining discussion.

jbemmel
Offline
Joined: 2005-03-01
Points: 0

> No there are no transaction objects, only Session
> object.
> Sessions are end receivers of diameter messages in
> one session. Session manager manages messages and
> delivers to apropriate session object for processing.
> There is one but here ( or maybe Im mistaken, correct
> me if Im wrong ) Session objects are not created when
> request comes from another node ( when current node
> acts like server ).

In some cases you may skip the creation of a Session object, and simply copy the session id from the request to the answer. In general a server would create sessions (application decision)

> This is why I have created Transactions objects.
> By transactions I have in mind Response/Request
> actions generated during one session.

Then call them RequestEvent and AnswerEvent. "Transaction" is confusing as there are transactions in Diameter, but a different kind than what you're talking about here

> This way for both Server and Client activities we
> will have similar way of handling events (reating
> requests and responses).
>
> Should RA and Transactions objects implement diameter
> state machine? Or should this be pushed to
> implemented services? ( AA and other cases, not Sh
> where session is propably initiated ).

The Diameter stack you have will probably handle the Diameter state machine for you. If there are application specific state machines (such as for some of the charging cases), then the application / SBB should handle this

> This seems
> resonable when Session objects are end receivers of
> message, but in SLEE Sbb are end receivers.
>

Guiding principle should IMHO be: do what you can to make things simple for applications, but not so much that it restricts potential applications

> By the way thanks jbemmel and isj for joining
> discussion.

baranowb
Offline
Joined: 2006-01-09
Points: 0

Ok. So here it is.
Please comment:

-When Sbb would like to send request it will create XClientEvents objects where X is some diameter app. This object would be registered as activity. After creation of this object Sbb would be able to create client kind of requests with this object ().
-When client kind request is received RA will create XServerEvents object and register it as activity. Each sbb subscribed to receive this particular kind of request will be able to create with this object answers/requests accordingly to app semantics. ( If session-id was specified in request it will be added to messages created with this Events object)
( By client kind I mean request made only by clients for instance STR )

And here come Base Protocol messages (ASR, STR, ACR,RAR )
It looks to me that each application should be able to create them. So each XXEvents (for instance ShInterfaceServerEvents) class for new application should extend BaseProtocolXXEvents, shouldnt it be like that?
How can one determine for which diameter app request/respose has been sent (BaseProtocol requests)? Does Auth-App-Id, Acc-App-Id and Vendor-Specific-App-Id are reliable source to determine this?

jbemmel
Offline
Joined: 2005-03-01
Points: 0

> Ok. So here it is.
> Please comment:
>
> -When Sbb would like to send request it will create
> XClientEvents objects where X is some diameter app.
> This object would be registered as activity. After
> creation of this object Sbb would be able to create
> client kind of requests with this object ().

Yes, but I would call this "XRequestFactory"

> -When client kind request is received RA will create
> XServerEvents object and register it as activity.
> Each sbb subscribed to receive this particular kind
> of request will be able to create with this object
> answers/requests accordingly to app semantics. ( If
> session-id was specified in request it will be added
> to messages created with this Events object)
> ( By client kind I mean request made only by clients
> for instance STR )
>

Same for 'XAnswerFactory'. I would suggest to have applications register at the Diameter application type level (e.g. Sh server application, to receive all Sh requests) rather than at the request type level.

> And here come Base Protocol messages (ASR, STR,
> ACR,RAR )
> It looks to me that each application should be able
> to create them. So each XXEvents (for instance
> ShInterfaceServerEvents) class for new application
> should extend BaseProtocolXXEvents, shouldnt it be
> like that?

If there are indeed common types of requests, you can design it like ApplicationRequestFactory extends CommonRequestFactory.

> How can one determine for which diameter app
> request/respose has been sent (BaseProtocol
> requests)? Does Auth-App-Id, Acc-App-Id and
> Vendor-Specific-App-Id are reliable source to
> determine this?

Yes. You can have multiple applications share the same TCP port, but for security reasons some applications might want their own port (TLS)

This implies that per application id you can have at most 1 registered Sbb

baranowb
Offline
Joined: 2006-01-09
Points: 0

>I would suggest to have applications register at the Diameter application type level (e.g. Sh server application, to receive all Sh requests) rather than at the request type level.

But some types of requests are made onyl by clients, and some only by servers. So it seems reasonable to create two different "factories" for each type of node.

I itend to create those factories in way which will hide session from user, is this a good approach?

Here is how I would like it to work.
Sbb is going to be a Sh client. It creates ShClientEvents ( which has session Id, dest-host,dest-realm.... ) client uses it to create for instance subscribe request, and when
update notification is received it uses it to create response.

Or shouldnt I care about something like that and create only request/response "factories" ?? one will be reponsible for creating requests, no matter what kind of ( in one app ) and other for responses. If this is the way, which object would be suitable for activity? ( Im getting slightly lost here )

jbemmel
Offline
Joined: 2005-03-01
Points: 0

> >I would suggest to have applications register at the
> Diameter application type level (e.g. Sh server
> application, to receive all Sh requests) rather than
> at the request type level.
>
> But some types of requests are made onyl by clients,
> and some only by servers. So it seems reasonable to
> create two different "factories" for each type of
> node.
>

You could create a factory for all requests (per application), and a response creation method as part of the event that is delivered to the server side application

I would suggest to only do this for the most popular Diameter applications, and allow general (perhaps yet to be defined) Diameter applications too.

> I itend to create those factories in way which will
> hide session from user, is this a good approach?
>

On the client side the application may have several ongoing sessions, it will still need to indicate on which session a request is to be sent.

A Session object with a 'sendRequest' method seems appropriate; the factory can remain independent of sessions, as long as the above mentioned method fills in the session id in the request.

The session can also fill in the other data that remains constant for the session (dest-host etc), so the request factory would produce 'half products'

> Here is how I would like it to work.
> Sbb is going to be a Sh client. It creates
> ShClientEvents ( which has session Id,
> dest-host,dest-realm.... ) client uses it to create
> for instance subscribe request, and when
> update notification is received it uses it to create
> response.
>

Yes, as long as the number of supported applications is limited to a handful. CCRequestEvent and ShRequestEvent would be fine, but there are 2^32-3 other non-vendor-specific potential applications...

> Or shouldnt I care about something like that and
> create only request/response "factories" ?? one will
> be reponsible for creating requests, no matter what
> kind of ( in one app ) and other for responses.

It would reduce mistakes if the interface offered to applications upon receiving a request always and only creates the right type of response

> If
> this is the way, which object would be suitable for
> activity? ( Im getting slightly lost here )

I know too little about activities to answer that question, but if a SIP dialog is an activity, I would expect a Diameter session to be one too

baranowb
Offline
Joined: 2006-01-09
Points: 0

I have slighly modified wiki and added some content:
http://wiki.java.net/bin/view/Communications/MobicentsDiameterRA

Please comment.

I have one question which has been bothering me lately. Should RA check wheather request it got is in the supported application list?
Suppose diameter stack has been configured to advertise that it supports app A,B and C. It receives request which is application D request ( apps A-D are implemented and RA is capable of craeting activity for request to app D ).
Should RA check capabilities of its stack to decide wheather this message should trigger activity creation or not?

jbemmel
Offline
Joined: 2005-03-01
Points: 0

> I have one question which has been bothering me
> lately. Should RA check wheather request it got is in
> the supported application list?
> Suppose diameter stack has been configured to
> advertise that it supports app A,B and C. It receives
> request which is application D request

If the stack is configured for applications A,B,C, IMO it should no pass a request for application D to the upper layer (i.e. the RA in this case), but respond with 'not supported' error instead

isj_javadiameter
Offline
Joined: 2006-05-21
Points: 0

Correct. This is what JavaDiameter do. The upper layer will never see messages for applications that were not negotiated.

fram
Offline
Joined: 2004-05-13
Points: 0

Hi All,
I would like to know the status of the mobicents implementation for the diameter sh application RA.
Should we start a new project for the RA implementation?
Francesco

ivelin
Offline
Joined: 2003-07-13
Points: 0
abraun
Offline
Joined: 2007-11-09
Points: 0

Hi together,

is some development on diameter RA still going on? In what state is the RA now? Is it usable?

Regards,
Andre

baranowb
Offline
Joined: 2006-01-09
Points: 0

I have sent new project with ra type of base and sh interface to OC for review and possible approval, if they agree things look better we will reimplement current RA,
Last code patch to current RA has been provided long time ago, no feedback or interest in this RA caused this blackout in hack on this. I would suggest waiting for new ra, since it will be standarized - atleast between MC and Rhino - possibly more.

jbemmel
Offline
Joined: 2005-03-01
Points: 0

Diameter and SIP are two *very different* protocols, even if both use transactions and sessions/dialogs.

To start, transactions in SIP are optional, whereas in Diameter they are always used. Because of this, a Diameter application need not worry about them, and the API should hide them. You need a notion of session and a sendRequest / sendAnswer, but no transactions. The RA should handle them internally (i.e. assign ids, assuming the stack handles retransmissions)

baranowb
Offline
Joined: 2006-01-09
Points: 0

jbemmel could You be more specific about "handling internaly" ??
Notice that I said ClientTransactions and ServerTransactions.
Each will handle different tasks. ServerTs will create responses and requests specific to server side logic ( similar ClientTs).
When Client transaction will be created it will be assigned by RA session-id, which will be added to each request created with that ClientTs.

When Client issues request to server RA will create ServerTs and will assign to it session-id from request it has received.

Transactions are going to be persistent for the time of session.

Should RA and Activity objects handle state machines for sessions?

baranowb
Offline
Joined: 2006-01-09
Points: 0

It looks as follows.
Diameter is a p2p protocol. Each node can be server and client at the same time ( it depends how node is created - it can act only as a client or as a client and server ).
Diameter message consists of AVPs ( Atribute Value Pairs )
for instance UID = baranowb ( its not as simple as here, but the idea is the same)

Each node has its "Capabilities" - list of activities it supports, for instance Accounting.
Upon creation node estabilishes connection to given peers. If given peers support the same capabilities conection is susteined, otherwise its canceled.
Messages are delivered to those peers and if needed, forwarded to next peer on the path to destintation host.

Diameter messages are divided into two groups: Requests and Responses. Each is identified by few AVPs
for example hop-by-hop, end-to-end identifiers vendor-id and so on.

Diameter library comes with few handy classes (actually core classes):Node,NodeManager, BaseSession and SessionManager.

Each has handleAnswer and handlerRequest methods ( with different signatures )
NodeManager encapsulates Node and manages hop-by-hop and end-to-end identifiers, moreover it keeps track of connections and in-/out-going messages.

Session objects are entities which are ment to receive messages bound to them ( to specific session ).
Session objects represent logical connection across peers between two Nodes ( session is often estabilished between two distant nodes)

SessionManager class extends NodeManager. SM class handles messages on behalf of sessions registered in it. It keeps track of sessions and dispatches messages to appropriate session object. Also it sends messages on behalf of sessions.

It is tempting to use Session objects as Activities or as part of them. However Sessions are not created when Node receives request from another Node ( when Session has not been initiated localy ). This would cause assimetric handling of Requests comming to SLEE from other nodes.
But still it looks like good joice to me.

If something is unclear let me know.

ivelin
Offline
Joined: 2003-07-13
Points: 0

Nice intro, Bartek.

Have you been able to look at the RFCs relating Diameter to SIP. I think I've notived places where SIP is used for establishing connection between nodes and Diameter is the message payload.

From your description, Diameter behaves similarly to SIP. It probably makes sense for the basic Diameter RA to support two kinds of activities - Client/Server Transaction and Session(or Dialog) similar to the SIP RA.

Ivelin

baranowb
Offline
Joined: 2006-01-09
Points: 0

Well it behaves similar. However sessions are requirement of communication ( atleast Session-Id AVP is obligatory in all messages). So client/server transactions should support sessions.

Here are flow/logic diagrams for Sh and ra-type prototype: https://mobicents.dev.java.net/issues/show_bug.cgi?id=68

I cant understand one thing. In introduction do Diameter author says that session is estabilished when authenticate user request is beeing sent ( just by adding Session-Id). But how session is estabilished in Sh?? There is no AUR in Sh. I cant find answer in TS's regarding Sh. It looks like session is estabilished in Sh operations only by specifing Session-Id, am I right?

baranowb
Offline
Joined: 2006-01-09
Points: 0

Ok here is what just has dawned on me. Lets create two classes Client/ServerTransactions . Each will be "reponsible" for requests, answers in one session (To one host/realm - I didnt find anything on this, but it seems that session shouldnt be extended to other hosts than client server. Client wont be making provisional requests to other server in the same session, rather it should create new session). If SLEE enpoint woudl like to create new session it would create new Transactions class ( it will register new activity ine SLEE ).
Ant use it to creates messages.

How does this sound?

ivelin
Offline
Joined: 2003-07-13
Points: 0

Bartek,

The diagrams are quite helpful. However it is hard to evaluate the code in the binary jar you've submitted. Let's try with a detailed wiki description of the design, types and events. The format is working well for the SIP RA extensions:
http://wiki.java.net/bin/view/Communications/MobicentsSIPRA#Work_in_prog...

One comment I can make at this point is that we should be using net.java.slee.* package naming convention for any Java classes in the RA that are visible to SBBs, including events.

Ivelin

baranowb
Offline
Joined: 2006-01-09
Points: 0

Ops. Sorry about the jar file. I forgot that with creation of DU java files will be compiled. I will update wiki as soon as possible, propably now.

ivelin
Offline
Joined: 2003-07-13
Points: 0

here is a reference to the wiki for folks that are looking for it:
http://wiki.java.net/bin/view/Communications/MobicentsDiameterRA