28 Jan
2005
28 Jan
'05
10:12 p.m.
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(a)fokus.fraunhofer.de
Web www.fokus.fraunhofer.de
Computers are not intelligent. They only think they are.
-------------------------------------------------------