Skip to main content

Diameter Sh RA Type from Open Cloud

20 replies [Last post]
perrinm
Offline
Joined: 2006-06-13

Hi all,

This is just a note to introduce myself and let you know about the upcoming release of a proposed Diameter Sh Resource Adaptor Type from Open Cloud. I have seen the discussion on this forum about the subject, and obviously we don't want to diminish that effort at all. We hope to work with the community to agree on a standard RA Type.

The first release will be of the Diameter Sh application, but others will follow. Due to the nature of Diameter and hence the current design of the RA types, we'll also be including the Base RA Type classes. (At this stage the DU will be a monolithic unit, but in SLEE 1.1 implementations, using the library jar mechanism will allow us to have a more componentised and extensible deployment scheme.)

The bundle will consist of the source code and an Ant build file to compile and build the DUs. At this stage we do not have a TCK, but I will include a simple example service that demonstrates use of the RA. I am preparing a wiki page to outline the key design points and API semantics.

Regards,
Perrin Morrow

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
perrinm
Offline
Joined: 2006-06-13

Hi,

Yes I'd started to reply to Bartek's points earlier, but decided it would be
better to concentrate on getting the code submitted before getting into an
in-depth discussion before others had seen the code in detail. I will address
them now.

> Hmm hadnt thought about activities this way.
> At first I was considering creation of different activities for server and
> client part of Sh. But Im wasnt sure how agents should behave. Agent is client
> for one side of connection and for other it acts as server, tricky.

Diameter agents are an interesting problem, and definitely something we need to
give some thought to. There are only two types of agent we need to worry about:
relay and proxy (redirect agents are effectively servers, and translation agents
by nature will have Diameter on only one side). I see most of the issues as
implementation concerns, they shouldn't be significant factors in the design of
the RA type. I have partitioned the client and server activities down the line
of AS/HSS as opposed to sender/receiver and I think this will still fit with
agent requirements. What we may have to look more closely at is how we allow an
agent to maintain transaction and session state as required by the RFC.

> It seems slightly bothersome to create two RAs for each activity, especially
> when other apps will follow.

The idea is that it makes services cleaner to implement and service developers'
jobs easier, for a one-time cost when developing the resource adaptors. It may
be that for other Diameter applications it is better to have a combined RA type,
but I think for Sh it makes sense to separate them.

> "I was referring to the problem that arises when you have two SLEE services
> that use Diameter Sh, and both have subscribed to notifications for a user
> profile."
> hmm Session-Id is required field, in my understanding HSS should respond
> with the same session-id, it doesnt make sense to have such field in
> messages if it is empty or contains random data.

There are no stateful sessions in Sh, so when the Push-Notification-Request is
sent by the HSS, it will be in a new session with a session ID generated by the
HSS. Anyway, I think the problem only presents itself in reasonably obscure
scenarios, so a first cut of the RA type will work with the existing approach.

> "Yes. SBB developers don't need to know about the stack's message
> implementation, they just want to be able to set the contents of the messages in
> a simple way."
> Good idea, simple and it will simplify development, hadnt thought about it.
> However "message bean" should give access to raw message, shouldnt it? Or
> atleast it should give way of accessing/modificating raw contents.

What do you mean by the raw contents? We shouldn't allow a service to create a
badly formatted message.

Perrin

fram
Offline
Joined: 2004-05-13

First of all let me thanks everyone that participates in this interesting discussion for the precious input provided.

Regarding the ra tpye definition from what I can understand the work dom by baratek is to provide a more general support for the diameter protocol and for different diameter application (funny way to refer to extensions ;-) ).

Perrin proposal instead is more targeted to the Sh application and to simplifiy the development of JSLEE Services.

Questions for Baretek about the Base Diameter RA Type:
- How is it going to support the introduction of new diameter application ?
- Are the Sbb responsible for handling new diameter application or should we envision a multiplexer as in the new sip ra to support multiple ra type?

Questions for Perrin about the Sh Application RA Type:
- Regariding the definition of client and server activities the activity definition supports a request response interaction that the SBB can handle asynchronously. Why do you think that we need an activity there instead of simply using the provider synchronous call?

Regarding the notification activity, this activity makes sense from a sbb developer point of view because will ease the development of JSLEE services.

Personally I like the approach of defining different ra type for different diameter application, the implementation then could support different ra type using a multiplexer approach like the new sip ra.

Let's see if we'll be able to converge on a first ra type draft within next week.

Regards,
Francesco Moggia

david_ferry
Offline
Joined: 2006-05-07

The reason why the "outcall" is async is that you don't know how long the HSS/server will take to respond. If it was a sync call you block a thread for some unknown duration. This has a non-trivial impact on scaling (even with a highly threaded system).

The synchronous remote calls look nice from a the perspective of building a trivial application because you dont have to create an activity, and attach.

One issue with support both async and sync external invocations in the same API then some apps will not scale well under certain load situations, where others will - purely as a function of using the API in two different ways

Message was edited by: david_ferry

baranowb
Offline
Joined: 2006-01-09

Sbbs are not responsible for introducing new apps, its totaly under our control.
MUX pattern is tempting. It would allow us to use same interfaces as OC, ( creating RAs for each app would simplify code in them, however Im not sure how basic diameter messages would fit in those RA's, since some apps use them and some do not. )
I had my doubts about different RA for different app, but after getting along with mux it seems good choice, RA with mux will be modular and easier to maintain.

warrenc5
Offline
Joined: 2006-08-07

SH had activities for each request response pair purley for asthestics.

Having two different RA types for SH would overly complicate service development as it would be a division based upon the service you wish to build ie. 1 ra type for HSS implemenations and 2. another for services that access an HSS. I think the RA type should not be split.

The sessionId in the activities was only a [connvienience] way to match them up in the stack and no way mandated by 3gpp (In fact I recall the 3gpp spec being very vauge on this point): There seems to be some confusion regarding this use of sessionIds for SH in the Diameter RA Types thread. The sessionId should be set transparently to the service programmer anyway.

ivelin
Offline
Joined: 2003-07-13

I am concerned that this design discussion is dragging on for too long. We need to make a decision soon (within days).

Warren, can you tell us a bit more about your use of JSLEE and describe the specific real world use cases where you need the SH RA. That will help understand how much you would be impacted by a potential split of the SH RA Types as suggested by OC.

baranowb
Offline
Joined: 2006-01-09

Perin are You familiar with multiplexer pattern for sip stack we are using in new sipra ?
It looks like good choice to multiplex by type of application.

How basic diameter messages fit into different applications and RA Types for them?
Gotta run, I will try to propose something as api for diameter stack in mux somewhere in the midle of the week.

perrinm
Offline
Joined: 2006-06-13

Hi,

> Perin are You familiar with multiplexer pattern for sip stack we are using in new sipra ?
> It looks like good choice to multiplex by type of application.

I think the multiplexing approach is probably a valid one to consider for
implementing multiple Diameter application RAs on a single stack, but I
don't get how it relates to the discussion about Diameter RA types. Perhaps I
don't understand what you are proposing in enough depth, but I thought we had
agreed at a high level that RA types should be application-specific and oriented
towards making services easier to develop and maintain. Whether you have a
single Diameter stack and multiplex the messages to through a single stack or
have separate stacks on different ports should not affect the design of the RA
type (an RA implementation could potentially support both scenarios).

> How basic diameter messages fit into different applications and RA Types for them?

This would depend on the application, but in most cases I expect the
app-specific RA types will provide specific support for the necessary base
messages. In the case of CCA for example, you could provide a method on the
server activity to send a Re-Auth-Request and a method on the client activity to
send a Re-Auth-Answer since those are the only base messages used.

While I'm posting, a response to one of Francesco's comments:

> Regarding the ra tpye definition from what I can understand the work dom by
> baratek is to provide a more general support for the diameter protocol and for
> different diameter application (funny way to refer to extensions ;) ).

We also have a Base Diameter RA Type that provides a lower level API to create
arbitrary commands and AVPs, but of course we expect service developers will use
the application-specific ones (which all also allow arbitrary AVPs to be added
to messages if permitted by the particular Diameter application).

Cheers
Perrin

baranowb
Offline
Joined: 2006-01-09

I guess You are right. Lets move to Types.
I think we should take advantage of by app ras and make them slightly more complicated. I mean we have two different types of activities ( I know it I wasnt convinced to it, but after some time ... ) with different life span ( short - request response based and long term AC that last for some time, like notifications AC mentioned in wiki.

What I wanted to be brought up to discusion is how RA and RA Type api will support/handle those activities?
We can take 2 approaches ( I think ):
- less restrictive - proposed in wiki with messages factories
- more restrictive - which would push message creation to activities objects ( for intance for notification AC .createSubscribeReponse , .createSubscribeRequest, .createProfileUpdateNotificationRequest/Response, .terminateSubsription, .sendRequest, .sendResponse ).

Second choice similar what sip api gives to programer ( like createResponse( Request req ) which, I think is quite conveniant ).

Ofoucrse we could implement both approaches.

Second issue is life span of ACs.
ACs like notifications will last for some time, even when server crashes with our service and its ACs subsription will prevail, it seems to be good idea to give notification RA some knowledge about state of its ACs, for instance if notification AC is beeing terminated and hadnt unsubsribe RA should take care of it by inviking explicitly its , lets say "terminateSubsription" method.

One question to wikik that arose some time ago. Why server activity receives/fires requests/responses which clearly are notification "part" of Sh? If there is notification AC lets make it AC which handles all notifications related requests/responses (another AC one for server side another for client). Seems like code in RA will be clearer, wouldnt it?

Any comments

perrinm
Offline
Joined: 2006-06-13

You raise some good points.

First up, I agree that the activity object interfaces should have methods to create answer messages. My initial thinking was that since the message factory can be easily obtained from the activity, and the factory is required to create grouped AVPs anyway, then extra methods to create messages would be redundant. But having thought about it further, I think it does make sense to have methods on the activity similar to the SIP API. It will probably be quite a common scenario to create an answer message, set a result code then send it. Having to get a message factory in those cases will clutter the code unnecessarily.

What I am not so sure about is if activities should also have methods to create request messages. I still think a factory should be used in that case. Thinking back on the services I have written that use Sh, that still feels more natural.

I do think the factory interface should still contain the complete set of message/AVP creation methods though.

Secondly, I also agree with your suggestion to have a separate server notification activity. My original reasoning was that we didn't need a separate activity on the server side because there is no logical activity to be represented in the SLEE for a notification subscription; the activity was simply there to allow interaction with the RA. But the more I think about it, the more I think that it does not make sense to have an activity object where some methods are illegal to use in depending on when the activity is being used (i.e., when the activity is created by the RA for an incoming request vs. when a service requests the activity creation to send a request). I will add an ShServerNotificationActivity to the RA type.

Regarding the lifecycle of the notification activities, there are certainly some issues to be worked through there. The Expiry-Time AVP was only added to the Subscribe-Notification-Request in V7.1.0, and there is no means described for the server to tell the client the subscription is expiring. So if we have an activity on the client side that exists for the duration of the subscription, the client RA will need to maintain a independent timer (that depends on the Expiry-Time AVP in the answer from the server). We will have to decide which issues affect the RA type and which are the responsibility of the implementation.

ivelin
Offline
Joined: 2003-07-13

Perinn committed the initial Diameter SH RA Type to SVN so that it is easier to modify the shared code as the discussion progresses.
https://slee.dev.java.net/svn/slee/trunk/ratype/diameter

perrinm
Offline
Joined: 2006-06-13

Yes, people should be able to do a checkout of the URL above and run the default Ant target. This will build the Javadoc and DUs. It would be nice to get some confirmation that the DUs can be deployed into Mobicents successfully.

By the end of the week, I hope to commit the updated API with the changes we have discussed recently and I will also update the wiki page.

Perrin

perrinm
Offline
Joined: 2006-06-13

I've committed a some changes to Subversion as per the discussion above (as well as a few other improvements). I have also updated the wiki page but it needs more detail, so I will try to spend some time on it next week.

ivelin
Offline
Joined: 2003-07-13

Hi Perrin,

Open Cloud's contribution to the standardization effort is most welcome!

Ivelin

perrinm
Offline
Joined: 2006-06-13

I have created a wiki page that briefly describes the API and design of the Diameter Sh RA Type. The source code should be made available later this week.

http://wiki.java.net/bin/view/Communications/JSLEEDiameterShResourceAdap...

ivelin
Offline
Joined: 2003-07-13

Thank you, Perrin.

Can you please review the work done by Bartek and comment on the differences. We should start working on consolidating the two Diameter Sh types.
http://wiki.java.net/bin/view/Communications/MobicentsDiameterRA

Ivelin

baranowb
Offline
Joined: 2006-01-09

Looks very good.
Why there is different activity for notifications? Seems a little bit artificial.
What if messages bundled with stack do not have bean like accesor methods? API message type implementation should wrap then and provide such methods?

According to what You propose for each app and for each side (client/ server ) there witl bee differen RA, am I right?

"How to identify multiple applications in a single Diameter node?"
Hmm application ID has to be always set in header so this is one way. Other is to lookup message conent for application id AVPs.

Message was edited by: baranowb

perrinm
Offline
Joined: 2006-06-13

> Why there is different activity for notifications? Seems a little bit artificial.

This is a good question, and I admit the reason to have it is not apparent with the existing semantics. It is there in anticipation for when the Notification activity will represent a long-lived subscription to a particular profile. In my opinion this is sufficiently different from the purpose of the other activities, which only exist from when a request is received to when the answer is sent, or from when a request is sent and the answer received. So they have a different lifecycle and different semantics (eg, activity is ended when requested by the client or by an expiry time elapsing).

> What if messages bundled with stack do not have bean like accesor methods? API message type implementation should wrap then and provide such methods?

Yes. SBB developers don't need to know about the stack's message implementation, they just want to be able to set the contents of the messages in a simple way.

> According to what You propose for each app and for each side (client/ server ) there witl bee differen RA, am I right?

Yes, we are proposing that each Diameter application has a separate RA Type.

And yes, the Sh RA has separate client and a server RA type -- we considered them to be sufficiently distinct to warrant this, and you will see there is no overlap in the event types or activities. For other Diameter applications it may make sense not to have separate client and server RA types.

> "How to identify multiple applications in a single Diameter node?"
> Hmm application ID has to be always set in header so this is one way. Other is to lookup message conent for application id AVPs.

Hmm, apologies but I fell into the trap of using the word 'application' ambiguously here. Yes, Diameter applications can be identified by the application ID, and a stack implementation would be able to use it to route incoming messages to a particular RA entity if multiple RAs are sharing the same stack. I was referring to the problem that arises when you have two SLEE services that use Diameter Sh, and both have subscribed to notifications for a user profile. As far as an HSS is concerned, sending the PNR to the Diameter node that sent the SNR is sufficient -- there is no extra information in the message to identify a recipient on that node. The premise in Diameter that each host will have a single monolithic Diameter node causes a number of issues when trying to adapt the protocol to the SLEE container model.

baranowb
Offline
Joined: 2006-01-09

Hmm hadnt thought about activities this way.
At first I was considering creation of different activities for server and client part of Sh. But Im wasnt sure how agents should behave. Agent is client for one side of connection and for other it acts as server, tricky.

It seems slightly bothersome to create two RAs for each activity, especially when other apps will follow.

"I was referring to the problem that arises when you have two SLEE services that use Diameter Sh, and both have subscribed to notifications for a user profile." - hmm Session-Id is required field, in my understanding HSS should respond with the same session-id, it doesnt make sense to have such field in messages if it is empty or contains random data.
I had similar problem. Ivans stack gives very good way to handle messages without session-id or different values ( within the same session ) if current node acts as client. Even when we create activity bound to some session-id value and responses does not contain the same session-id.

Situation is different when node acts as server. No such mechanism. Each message has to be taken under magnifing glass as seperate message or RA has to keep track of hob-by-hop and end-to-end ids - double stacks work ( if session-id is not constant)

"Yes. SBB developers don't need to know about the stack's message implementation, they just want to be able to set the contents of the messages in a simple way." - Good idea, simple and it will simplify development, hadnt thought about it. However "message bean" should give access to raw message, shouldnt it? Or atleast it should give way of accessing/modificating raw contents.

ivelin
Offline
Joined: 2003-07-13

Perinn, thank you for submitting the source code of the proposed RA Type as a bugzilla attachment:
https://slee.dev.java.net/issues/show_bug.cgi?id=1

Let's continue the discussion here and try to get a closure on a first version in the following few days.

Perinn, do you have comments for Bartek's questions?

Ivelin