Subject: RE: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0

From: "Martin Julien (ECE)" <[email-masked]>
Date: Thu, 25 Jan 2001 13:29:55 +0100

Hi Tony and Pat,

I would like to know why we can not use a more simple routing scheme based on Destination-NAI AVP (let's call it like that for now), to route the packet directly to the destination server, which could either be a NAS or an AAAH? The format of the Destination-NAI AVP could be something like "[email-masked]", which could be used by the proxies to route messages to their final destination domain, and then to a particular server within the domain. So the order of priority for routing would be something like: (1) Destination-NAI, (2) Routing-Realm. I assumed that the originating servers should always use a Routing-Realm AVP (a default one in the case no User-Name AVP is available) or a Destination-NAI AVP (possibly extracted from the User-Name AVP like "@realm.com" with no server name, only domain) when sending messages. I assumed that the Routing-Realm AVP was only used when we did not really know where the message should go because the User-Name AVP was not yet available? I !
think it would simplify the routing scheme. Would that make any sense? The problem with the Routing-Realm AVP being used as the highest priority routing scheme is that I don't really know what will happen on the different proxies, since they might change it.

Even tough we can assume that if more than one server is part of a AAAH domain and they would all share the same DB for user info, I don't know if it would be desirable to also put user session information in the DB in the case that messages from the access device (NAS) would need to send a STR to its very particular AAAH server. Then, the message could get routed to another server within the domain, that does not have access to the memory resident user session info. It remains the responsibility of the domain to use the "server1" part of the "[email-masked]" address as it wishes, which should not be a problem if user sessions are shared among AAAH servers for load balancing and 100% availability. This solution would be more generic, which I think you like.  

Basically, I liked to idea behind the Resource-Owner AVP routing concept very much and think it is good, but I thought it also needed to be extended to handle both-ways messaging.

BR,
Martin

> -----Original Message-----
> From: Tony Johansson [mailto:[email-masked]]
> Sent: Tuesday, January 23, 2001 11:59 PM
> To: Pat Calhoun
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments
> Section 3.0
> 
> 
> I would prefer Destination-NAI AVP or something similar, thus 
> a more general name,
> which works well for both a NAS (with re-auth and ST* 
> messages) or an FA (with ST*
> messages).
> 
> BR,
> 
> /Tony
> 
> Pat Calhoun wrote:
> 
> > > Hi Pat,
> > >
> > > True, for the cases of home server initiated messages, 
> like STI and re-auth
> > > request to the NAS, we do need some thing to route the 
> message to the right
> > > NAS or FA and the AVP for that is the Resource-Owner-NAI 
> AVP. Correct? If
> > > the idea here is only to change the name from 
> Resource-Owner-NAI AVP to
> > > Destination-NAI AVP, it is fine with me.
> >
> > yes, the issue is that the REsource-Owner-NAI is tied to 
> ST* messages. We need
> > something that can be used with re-auth as well. 
> Destination-NAI is one name
> > we could use.
> >
> > >
> > > Furthermore, just as clarification, if the case is to change the
> > > Resource-Owner-NAI AVP to the Destination-NAI AVP it 
> should stated in the
> > > text that the Destination-NAI AVP should ONLY be used for messages
> > > originated from the AAA server. Correct?
> >
> > Correct. If that is the case, perhaps NAS-NAI is more appropriate.
> >
> > PatC
> 
> --
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> _/_/_/_/_
> 
>   Tony Johansson
>   Mobile Networking Research
>   Ericsson Inc.    mobile: +1 510 305 6108
>   2100 Shattuck Avenue
>   Berkeley, CA, 94704
>                          mailto:[email-masked]
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> _/_/_/_/_
> 
> 
>

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 25 Jan 2001 07:30:55 -0800 (PST)

Martin,

Thanks for the comment.

I understand your concern, but from what I've heard on this list is that
people do not want to tie users to a particular AAA home server (anyone,
correct me if I am wrong). So, the Destination-NAI is (sort-of) the equivalent
of the User-Name AVP, but in the reverse direction. When a message is destined
for the home AAA server, the User-name is used to identify the home network.
For messages directed towards the NAS, the Destionation-NAI is used. [now that
I think of it, I am not sure this is clearly stated in the I-D]. The
destination-NAI is slightly different since it also encodes the host name to
which the message must be forwarded to.

Again, if people really want to tie users to a particular AAA server, then we
can relax the Destionation-NAI rules. Comments?

PatC
> Hi Tony and Pat,
> 
> I would like to know why we can not use a more simple routing scheme based
> on Destination-NAI AVP (let's call it like that for now), to route the
> packet directly to the destination server, which could either be a NAS or an
> AAAH? The format of the Destination-NAI AVP could be something like
> "[email-masked]", which could be used by the proxies to route messages to
> their final destination domain, and then to a particular server within the
> domain. So the order of priority for routing would be something like: (1)
> Destination-NAI, (2) Routing-Realm. I assumed that the originating servers
> should always use a Routing-Realm AVP (a default one in the case no
> User-Name AVP is available) or a Destination-NAI AVP (possibly extracted
> from the User-Name AVP like "@realm.com" with no server name, only domain)
> when sending messages. I assumed that the Routing-Realm AVP was only used
> when we did not really know where the message should go because the
> User-Name AVP was not yet available? I ! think it would simplify the routing
> scheme. Would that make any sense? The problem with the Routing-Realm AVP
> being used as the highest priority routing scheme is that I don't really
> know what will happen on the different proxies, since they might change it.
> 
> Even tough we can assume that if more than one server is part of a AAAH
> domain and they would all share the same DB for user info, I don't know if
> it would be desirable to also put user session information in the DB in the
> case that messages from the access device (NAS) would need to send a STR to
> its very particular AAAH server. Then, the message could get routed to
> another server within the domain, that does not have access to the memory
> resident user session info. It remains the responsibility of the domain to
> use the "server1" part of the "[email-masked]" address as it wishes,
> which should not be a problem if user sessions are shared among AAAH servers
> for load balancing and 100% availability. This solution would be more
> generic, which I think you like.  
> 
> Basically, I liked to idea behind the Resource-Owner AVP routing concept
> very much and think it is good, but I thought it also needed to be extended
> to handle both-ways messaging.
> 
> BR,
> Martin
>