Subject: [AAA-WG]: RE: Avi Comments: draft-belinchon-aaa-diameter-mm-app-01.txt

From: Avi Lior <[email-masked]>
Date: Fri, 8 Aug 2003 16:38:14 -0400

It seems to me that the major issue in my first review piece was the issue
relating to deployment of Diameter servers.

A single Diameter Server in your document is really a cluster of Diameter
Servers sharing a common State Store.  This is great.  You should perhaps
say that somewhere in your document and be done with this aspect of it.

The issue still remains however.  My gut feel says that having all your
subscribers end up at a single cluster sharing the a common State Store is
restrictive and will not scale.  Think about a carrier with 30 million
subscribers plus a bunch of visiting subscribers.

Is it worthwhile to address how this will be done?  I think yes not sure
what others think.  Others, what do you think?

There are several ways to solve this problem.  You can actually store the
state in the messages (much the same way that RADIUS uses the State
attribute etc).  Not sure what is the best solution for this.

Related to this I think is the notion of portability and mobility.  I
suspect that if one designs this for a 3GPP network one would get different
constraints then if one were to consider a 3GPP2 network.  I think you have
to look at least to these two networks inorder to come up with a solution.
There maybe other scenarios.

More comments inline.

> 
> However if have a short discussion in the past on whether 
> there is a requirement for a network to implement several 
> Diameter servers. Coming from a 3GPP view, the draft has been 
> assuming that, for a paricular user, all its data is stored 
> in a single Diameter server. One can have servers configured 
> in redundant fashion, clusters, or similar things (in order 
> to provide redundancy mainly). But all those servers will 
> contain the same data (will be mirrors), so from the 
> functional perspective, there will be only one Diameter 
> server in the network.
> 
> Now, I would like to understand if this assumption is 
> correct, otherwise we will need to provide the appropriate 
> mechanisms in the draft to make it work in other environments.

My opinion is yes.  

> In this case I believe it should be the same (or a cluster of 
> Diameter servers sharing the same data; I will refer to this 
> as one Diameter server). The issue is than in step 5 the 
> second SIP server will inform the Diameter server that such 
> second SIP server is serving the user. Consequently, further 
> Diameter requrests (such as UAR in step 10) or the LIR 
> command (step 2 in Figure 2) will return in the response 
> routing information, that is, the address of SIP server 2.
> 
> This point is of vital importance for the whole system. If 
> there are several Diameter servers (with a discongruent view 
> of the data, such us serving SIP server or user profile), we 
> will not achieve the desired functionality.
> 
> 
> >    
> >    This request will also serve to make the Diameter server
> >    aware of the SIP or SIPS URI of the SIP server 2, so as to return
> >    subsequent requests of the same user to the same SIP server 2.
> >  
> > [AL] So what you are saying here is that you inform the Diameter 
> > server of the SIP Server selected by SIP1.
> 
> Correct. In doing so, the second SIP server "registers" 
> itself in the Diameter server.
> 
> >   
> > [AL] What subsequent requests? Why wouldnt subsequent commands go 
> > directly to SIP2?
> 
> I will explain this with the help of figure 4. Figure 4 is an 
> example of a user calling sip:[email-masked]. 
> The SIP INVITE will arrive to any of the multiple SIP server 
> 1. This is done by using the procedures in RFC 3263 (Locating 
> SIP servers). This RFC makes usage of DNS to find "entry 
> points" or "edge" SIP servers.
> 
> So the INVITE in step 1 of Figure 4 will arrive to an edge 
> SIP server in ericsson.com. This SIP server does not know the 
> address of the SIP server that is triggering or providing 
> services to me, so SIP server 1 sends the LIR command to a 
> Diameter server in the ericsson.com real (step 2 in figure 
> 4). LIA will return the address of the SIP server allocated 
> to me, that may be something like sip:server33.ericsson.com 
> (in the example this will correspond to SIP server 2).

> What I wanted to say is that my SIP URI will be in the format 
> of user@domain rather than [email-masked], so in general 
> other SIP requests will ***not*** be addressed to 
> sip:[email-masked] but to 
> sip:[email-masked] instead. So those subsequent 
> requests need the routing information from the Diameter server, in 
> order for the SIP request to reach the appropriate SIP server.

Okay.  I understand.  But doesn't the scale of this worry you?  30 million
subscriber's state being maintained in real-time.  Is there a way to make
this more manageable. Is it an issue?

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 11 Aug 2003 08:05:49 +0300

Hi Avi:

Thanks for the comments. Answers inline...

/Miguel

> say that somewhere in your document and be done with this aspect of it.

I think this is a fair proposal. I will add some discussion aligned to 
  this conclusion. At this stage, I don't think we need an 
Applicability Statement section, but I would like to receive 
guidelines from the charis or the ADs.

> what others think.  Others, what do you think?

Not being "others", but... I agree that the solution will not scale as 
it is now. What I can do is to document the solution that 3GPP 
developped to solve this problem. 3GPP has added a new entity to its 
architecture, a Diameter Redirect Agent (in 3GPP parliance, this is 
known as the Subscription Locator Function, SLF).

To make a long story short: SIP servers query the SLF. The SLF, 
operating in redirect mode returns the address of the Diameter server 
where the relevant information for a particular user is stored. 
Needless to say, the SLF contains (or is able to access) a simple 
database that binds users with the Diameter Server that stores the 
data for that user.

Probably there might be other solutions to this problem, and we could 
document them if it is required.

> attribute etc).  Not sure what is the best solution for this.

Due to the multiplicity of SIP servers in the network, I don't know 
how storing a state in the message will help to solve the problem. The 
problem to solve is: given the identity of a particular user, any 
Diameter Client (SIP server) has to be able to find the Diameter 
Server that is storing the data for that particular user.

> There maybe other scenarios.

At least I am aware of the 3GPP solution, and it seems to work. And as 
I said before, I would happy to document other solutions as well.

Regards,

      Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                         Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002