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,