[Serusers] Carrier-grade framework for SER

[Dragos Vingarzan]

Hi all!
   Fortunately, for now, I don't have to deal with an already deployed 
network on wich to adapt in order to cope with growth. I was in that 
situation but with other technologies and it sure wasn't "funny". You 
will have to use proven technologies, that would not let you down or 
have hidden bugs.
   I will continue my reply inlined...

Greger V. Teigre wrote:

>    I have followed Diameter from a distance for a while, and while it 
> does seem to take hold in the mobile world, I haven't seen many 
> non-mobile implementations (it may be my limited perspective...). Most 
> legacy subcriber databases have a RADIUS interface, but rarely 
> Diameter. In fact, I know that Siemens have implemented a Mobile 
> RADIUS with location-awareness in RADIUS. I think that is an example 
> of the (still) appeal of RADIUS.
>    I would love to have Diameter capabilities, but deploying Diameter 
> in my organization is not really feasible at this point. Hence, we try 
> to do as much as possible with Juha's RADIUS modules.   And here is 
> the point, I think: One thing is what we would like to have, another 
> thing is the context we work in and thus what we have.  I have RADIUS 
> and do all provisioning in an LDAP back-end, other people use mysql 
> also for the subscriber database (which BTW is simple as serweb has 
> been developed and it works).
>
   Diameter deployment will take a while: you will need tested diameter 
support in ser and then a diameter server that will run your application 
logic. The good news is that maybe you could do it gradually, with 
radius/diameter conversion tools. But the fact that you will still have 
to implement all your application logic remains and it is a hard task. 
And of course you will need something of industrial strength...

>    The fact that you (at Fraunhofer) spend time on Diameter and SIP is 
> only a confirmation of how "cutting-edge" such an approach is. (Well, 
> with legacy systems, things do not have to be very cutting-edge to be 
> very far away from implementation...) Secondly, Diameter is the 
> successor of RADIUS, which is a very "simple" technology compared to 
> Diameter.  Just as with our xmlrpc vs soap discussion, you gain 
> complexity when you get functionality and for installation without the 
> need for a certain functionality will only get complexity; and 
> complexity = $$$.
>
   What I am working on is/was part of my Diploma Thesis. I was 
exploring new grounds, while trying to ensure a high performance also. A 
lot of this technologies don't have final specifications and tend to 
change very fast so that a lot of the time I just rewrite obsolete code. 
The 3GPP's IMS is focusing on moving the mobile phones world to the IP 
infrastructure. This is not a "must" for providers of UMTS but more of a 
good thing to have for the future and for integration with the IP world.
   Indeed the complexity is high as you try to get functionality. But 
sometimes, trying to get an old technologies to perform better that it 
was designed to, is a bigger effort that adopting a new one. I am sure 
that none of you will use this very soon, or maybe this will just remain 
in the IMS world. But you should know that it exists and maybe then, 
building big "patching" solutions will not look so feasible.
   From my experience into this and into trying to make it work, I would 
say that it would take some effort for any provider to jump into it, 
because there are so many features that are "provider independent".

>    And do I think keeping location is a natural function of AAA? Hm, 
> traditionally subscriber databases kept all the static information 
> about the subscriber and the subscriber's services.  Location was 
> application specific. In the mobile world, location is key to all 
> services, so HLR (Home Location Registers) had location as a natural 
> part of its functionality. For old/traditional dial-up services, 
> location was more an attribute of the AAA request, so that 
> authorization could be determined based on when and where the 
> subscriber tried to get access.  Location keeps getting more and more 
> important in TCP/IP based services as well, so one may (successfully) 
> argue that location is a part of the AAA domain.  However, where do 
> you stop?  Is the capabilities of your end-user device also 
> information that should be in the AAA domain?  You need to know these 
> capabilities in order to provide quality services...


   In IMS capabilites are stored on the AAA server and message routing 
is also based on that.

>    Enough of this ranting... What I'm trying to say is that we need 
> that "piece-meal" approach to scalability and redundancy: What can we 
> do with existing installations today that gives us what we need and 
> still leads us in the right direction?
>    So, in order to better understand where we should be going, I would 
> love to look at what you are doing 3GPP IMS. ;-) If you have some more 
> information, why don't you post a link?


   If you would like to know more about it I would recommend to read 
this draft: 
http://www.potaroo.net/ietf/idref/draft-ietf-aaa-diameter-sip-app/
   It will make you an ideea of how the architecture looks like, 
although it is more about diameter communication. But the architecture 
is described very well here.
   For 3GPP's IMS see http://www.3gpp.org/specs/numbering.htm into 
Technical Specifaction 29.228 and 29.229.

   Even if the diameter thing looks a little out of reach for now, the 
suggested architecture of the sip servers could be usefull into 
destressing things a little bit.

Regards,

-- 
-----------------------------------------
Dragos Vingarzan
FOKUS/MOBIS
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone +49 (0)30 - 3463 - 7242
Mobile +49 (0)162 - 153 - 0154
eMail vingarzan at fokus.fraunhofer.de
Web www.fokus.fraunhofer.de
Computers are not intelligent. They only think they are.
-------------------------------------------------------