Subject: [Dime] Comments for draft-tsou-dime-base-routing-ext

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 26 Jun 2006 15:49:43 -0400

I have one comment/question regarding 1.1 in draft-tsou-dime-base-routing.
The configuration described is as follows, AFAIU:

 WLAN       3GPP           3GPP
  AN --Wa-- AAA Proxy--Wd--Server

I am not sure whether it is the correct view to consider 3GPP AAA Proxy as a
proxy from Diameter base protocol point of view. It seems to me, it is more
like a Diameter endpoint, which is acting as a proxy from 3GPP AAA service
point of view, i.e. it would have two related sessions: one between WLAN AN
and 3GPP AAA Proxy and the other one betweeen 3GPP Server and 3GPP AAA
Proxy; it would provide interworking/bridging between those two session and
probably would implement some local policy as well. AFAICS, this
interpretation would solve the problem, the draft is trying to address in
1.1. Does this make sense or am I missing something completely?

   Thanks,
   Tolga

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Tony Zhang <[email-masked]>
Date: Tue, 27 Jun 2006 09:53:00 +0800

Hi Tolga:
      In my understand, AAA Proxy in visited network,AAA server in home network.so both nodes belong to different realm.
when AN Send message, the destination Realm should address to AAA server not AAA Proxy.so AAA proxy should do routing,
 AAA Proxy and AAA Server is belong to same  session.
Regards!
    Tony

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 27 Jun 2006 10:43:01 -0400

Hi Tolga,

Thanks for your review.
>  AAA Proxy and AAA Server is belong to same  session.

I hope I'm describing this accurately but a further example maybe in 
terms of accounting exchanges where the visited domain (which may have 
its own AAA proxy) uses a clearing house (which in turn has its own AAA 
proxy in a different domain) prior to reaching the home domain. It's 
probably a more generic scenario which may help clarify the problem 
statement better than the 3gpp example. In some sense, the mechanism is 
similar to SIP Record-Route.

hope this helps,
victor

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 28 Jun 2006 13:40:20 -0400

Hi Victor, Tony,

The issue of routing where proxies are involved is an interesting one. I
don't know how it is supposed to work but I will try to explain my
opinion -which is more a collection of questions- about this topic.

If we consider the example provided by Victor, I can think of two different
ways of doing it(similar thing applies to the example presented in the
draft):
a)Clearinghouse proxy provides message routing and executes local policy but
does not terminate the session. It will be seen as proxy1.clearinghouse.com
from client point of view.

b)Clearinghouse proxy terminates the session and actually proxies the
service provided. It will be seen as AAAserver1.providerB.com from client
point of view.

The way application support is advertised hints slightly and implicitly to
b). Proxies do not advertise supported application/realm pairs in CER/CEA
but just the applications. The realm is implicitly identified by the
DiameterIdentity of the proxy. For example in the above example, there is no
way to tell for the clearinghouse proxy that it can't handle anymore
requests for b.com, if it is handling multiple realms and if a) is used.
With b), it can drop the connection from its AAAserver1.providerB.com
identity to clients. This won't effect that it is handling requests for
other realms, because clearinghouse proxy would assume different identities
for them and would have separate connections to clients.

OTOH, b) would require that clearinghouse proxy assumes identity for each
realm, it is providing service for. I wouldn't think this would be a huge
problem but it probably is not desirable either.

The definition of proxies in RFC3588 2.8.2 doesn't mention about application
level proxying.

>From architectural point of view, I like the idea that Diameter base message
routing is not affected by the specific needs of applications, i.e. if there
is a need to traverse specific nodes, which have semantical application
processing, this should be handled by proxying the service, where each such
proxy decides for the next hop based on application logic (kind of like an
overlay application specific network if I may say so). IMO, the analogy is
that IP routing is not effected by the needs of application level
necessities, e.g. it is the application entity which populates the correct
IP address, if there is a need to traverse a specific set of application
nodes. To me, Diameter base protocol (RFC3588 - Authentication/Authorization
application defined in RFC3588) is a network layer protocol. Relay agents
are similar to routers in IP networks but IMHO any type of proxying is
better handled on application layer.

I don't know, which one of those models is the one, Diameter authors had in
mind for such scenarios, just I hope by considering all pros/contras we can
clarify -and if necessary fix- this thing.

     Thanks,
     Tolga

> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Tuesday, June 27, 2006 10:43 AM
> To: Tolga Asveren
> Cc: Tony Zhang; [email-masked]
> Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext
>
>
> Hi Tolga,
>
> Thanks for your review.
> > Hi Tolga:
> >       In my understand, AAA Proxy in visited network,AAA server
> in home network.so both nodes belong to different realm.
> > when AN Send message, the destination Realm should address to
> AAA server not AAA Proxy.so AAA proxy should do routing,

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 29 Jun 2006 10:16:31 -0400

Hi Tolga,

> The definition of proxies in RFC3588 2.8.2 doesn't mention about application
In general, the above scenarios you describe will work. However, I'm 
guessing that it assumes that there is only one single AAA proxy in the 
clearing house which will manage all sessions for all visited domains. 
In normal deployments, there will most likely be more than one of these 
proxies for scalability purposes and flexibility in the topology. So I 
think the draft attempts to solve a slightly different issue. As an 
example, if we do have multiple proxies in the clearing house and there 
is a relay in between the proxies and visited domains which routes 
messages based on some scaling policy but independent of the sessions 
then the problem statement in the draft holds true.

> overlay application specific network if I may say so). 
I agree with you and the draft does not mandate changes to the base 
protocol routing that affects any and all proxies. I think this is why 
the routing scheme in the draft is bounded to an application's sessions. 
In such a case, the routing scheme is will be based on the requirements 
of the application and the proxy services that supports them as you have 
mentioned. It would then be the responsibility of the applications to 
manage destination-host/destination-realm and the draft simply proposes 
a generic method for applications to accomplish this.

> IMO, the analogy is
To extend your IP analogy, the proposed scheme would be similar to IP 
strict source routing.

many thanks,
victor

>>>> I have one comment/question regarding 1.1 in
>>>>         
>> draft-tsou-dime-base-routing.
>>     
>>>> I am not sure whether it is the correct view to consider 3GPP
>>>>         
>> AAA Proxy as a
>>     
>>>> proxy from Diameter base protocol point of view. It seems to
>>>>         
>> me, it is more
>>     
>>>> like a Diameter endpoint, which is acting as a proxy from 3GPP
>>>>         
>> AAA service
>>     
>>>> point of view, i.e. it would have two related sessions: one
>>>>         
>> between WLAN AN
>>     
>>>> Proxy; it would provide interworking/bridging between those
>>>>         
>> two session and
>>     
>>>> interpretation would solve the problem, the draft is trying to
>>>>         
>> address in
>>

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 29 Jun 2006 17:37:43 -0400

Hi Tolga,
> [TOLGA]I agree with that. Initally I thought why do we need such a
> mechanism, if proxies involved are already stateful. The answer is existence
> of stateles intermediares, i.e. relay agents. IMO there are two different
> situations:
> a)All intermediares on the path are stateful
> b)At least one intermediary in the path is stateless.
>
> For a), I believe there is a relatively easy solution, which does not
> require protocol involvement: All nodes send messages belonging to the saem
> session to the same peer. I know this is not mandated in RFC3588 -at least I
> don't recall it being mandated somewhere-. OTOH, I believe it is common
> sense to do so and is useful. It would help to prevent some probbaly quite
> unlikely but still possible missequencing of messages. I think, you may want
> to mention about a) and how it could provide a solution to cover all cases.
> Actually maybe that type of message routing is something, which can be
> included in a possible Diameter-bis document: "All Diameter nodes, which are
> keeping session state SHOULD send requests belonging to the same session to
> the same next hop unless htere is a failure."
>   

Sounds good to me.

best regards,
victor
>   
>>> >From architectural point of view, I like the idea that
>>>       
>> Diameter base message
>>     
>>> routing is not affected by the specific needs of applications,
>>>       
>> i.e. if there
>>     
>>> processing, this should be handled by proxying the service,
>>>       
>> where each such
>>     
>>> proxy decides for the next hop based on application logic (kind
>>>       
>> of like an
>>     
>>> necessities, e.g. it is the application entity which populates
>>>       
>> the correct
>>     
>>> nodes. To me, Diameter base protocol (RFC3588 -
>>>       
>> Authentication/Authorization
>>     
>>> application defined in RFC3588) is a network layer protocol.
>>>       
>> Relay agents
>>     
>>> I don't know, which one of those models is the one, Diameter
>>>       
>> authors had in
>>     
>>> mind for such scenarios, just I hope by considering all
>>>       
>> pros/contras we can
>>     
>>>>>> and 3GPP AAA Proxy and the other one betweeen 3GPP Server
>>>>>>             
>> and 3GPP AAA
>>

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 29 Jun 2006 16:17:57 -0400

Hi Victor,

> Sent: Thursday, June 29, 2006 10:17 AM
> To: Tolga Asveren

---

From: Tony Zhang <[email-masked]>
Date: Fri, 30 Jun 2006 10:32:49 +0800

> the same next hop unless htere is a failure."

maybe should change the other part also,because RFC Diameter,the request route process should change.
last time is base on Destination Host and Destination Realm.now should base on next hop.

because one node cannot assure which all node in session path  been stateful or not.
so should only give one solution cover both situations.

i also agree with you,this solution is application independent.

Regards
 Tony

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 30 Jun 2006 08:22:51 -0400

Hi Tony,

> From: Tony Zhang [mailto:[email-masked]]
> Sent: Thursday, June 29, 2006 10:33 PM
> To: Tolga Asveren; Victor Fajardo
> Cc: [email-masked]
[TOLGA]Just to prevent a confusion, my suggestion is not about changing
anyhting in RFC3588 per se. RFC3588 does not mandate, how the next hop is
selected if next hop is not the node identified by Destination-Host AVP. My
proposal is only mentioning about a common-sense approach, which could be
useful for certain configurations.
> so should only give one solution cover both situations.
[TOLGA]That I disagree. Topology may be known in advance based on agreement
between different parties. I personally don't see much difference between
saying "Your nodes should support Diameter Strict Source Routing extension"
and "All your nodes should keep session state." Depending on situation one
or another may be the preferrable solution. IMO, let's provide the tools,
and let the people choose which tool is more suitable for their specific
need.

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 30 Jun 2006 09:26:18 -0400

Hi guys,
> useful for certain configurations.

Yes. I do not think there is a need to change the base protocol routing 
to accomodate the proposed scheme. This is why the scheme is application 
dependent. Note that for a single diameter node, not all the 
applications in that node can/should support this scheme so it should be 
transparent to base protocol routing.

> and let the people choose which tool is more suitable for their specific
I agree.

regards,
victor
>>>>> The issue of routing where proxies are involved is an
>>>>>           
>> interesting one. I
>>     
>>>>> If we consider the example provided by Victor, I can think of
>>>>>           
>>>> two different
>>>>         
>>>>> ways of doing it(similar thing applies to the example
>>>>>           
>> presented in the
>>     
>>>>> draft):
>>>>> a)Clearinghouse proxy provides message routing and executes
>>>>>           
>>>> local policy but
>>>>         
>>>>> does not terminate the session. It will be seen as
>>>>>           
>>>> proxy1.clearinghouse.com
>>>>         
>>>>> b)Clearinghouse proxy terminates the session and actually
>>>>>           
>> proxies the
>>     
>>>>> service provided. It will be seen as AAAserver1.providerB.com
>>>>>           
>>>> from client
>>>>         
>>>>> point of view.
>>>>>
>>>>> The way application support is advertised hints slightly and
>>>>>           
>>>> implicitly to
>>>>         
>>>>> b). Proxies do not advertise supported application/realm pairs
>>>>>           
>>>> in CER/CEA
>>>>         
>>>>> DiameterIdentity of the proxy. For example in the above
>>>>>           
>>>> example, there is no
>>>>         
>>>>> requests for b.com, if it is handling multiple realms and
>>>>>           
>> if a) is used.
>>     
>>>>> With b), it can drop the connection from its
>>>>>           
>> AAAserver1.providerB.com
>>     
>>>>> identity to clients. This won't effect that it is handling
>>>>>           
>> requests for
>>     
>>>>> other realms, because clearinghouse proxy would assume
>>>>>           
>>>> different identities
>>>>         
>>>>> OTOH, b) would require that clearinghouse proxy assumes
>>>>>           
>>>> identity for each
>>>>         
>>>>> realm, it is providing service for. I wouldn't think this would
>>>>>           
>>>> be a huge
>>>>         
>>>>> The definition of proxies in RFC3588 2.8.2 doesn't mention
>>>>>           
>>>> about application
>>>>         
>>>>> level proxying.
>>>>>
>>>>>           
>>>> guessing that it assumes that there is only one single AAA
>>>>         
>> proxy in the
>>     
>>>> In normal deployments, there will most likely be more than
>>>>         
>> one of these
>>     
>>>> example, if we do have multiple proxies in the clearing house
>>>>         
>> and there
>>     
>>> mechanism, if proxies involved are already stateful. The answer
>>>       
>> is existence
>>     
>>> of stateles intermediares, i.e. relay agents. IMO there are two
>>>       
>> different
>>     
>>> situations:
>>> require protocol involvement: All nodes send messages belonging
>>>       
>> to the saem
>>     
>>> session to the same peer. I know this is not mandated in
>>>       
>> RFC3588 -at least I
>>     
>>> sense to do so and is useful. It would help to prevent some
>>>       
>> probbaly quite
>>     
>>> unlikely but still possible missequencing of messages. I think,
>>>       
>> you may want
>>     
>>> to mention about a) and how it could provide a solution to
>>>       
>> cover all cases.
>>     
>>> included in a possible Diameter-bis document: "All Diameter
>>>       
>> nodes, which are
>>     
>>> keeping session state SHOULD send requests belonging to the
>>>       
>> same session to
>>     
>>>>> is a need to traverse specific nodes, which have semantical
>>>>>           
>> application
>>     
>>>> the routing scheme in the draft is bounded to an
>>>>         
>> application's sessions.
>>     
>>>> In such a case, the routing scheme is will be based on the
>>>>         
>> requirements
>>     
>>>> of the application and the proxy services that supports them
>>>>         
>> as you have
>>     
>>>> manage destination-host/destination-realm and the draft
>>>>         
>> simply proposes
>>     
>>>>> IP address, if there is a need to traverse a specific set
>>>>>           
>> of application
>>     
>>>>> are similar to routers in IP networks but IMHO any type of
>>>>>           
>> proxying is
>>     
>>>>>> I hope I'm describing this accurately but a further
>>>>>>             
>> example maybe in
>>     
>>>>>> terms of accounting exchanges where the visited domain
>>>>>>             
>> (which may have
>>     
>>>>>> its own AAA proxy) uses a clearing house (which in turn
>>>>>>             
>> has its own AAA
>>     
>>>>>> proxy in a different domain) prior to reaching the home
>>>>>>             
>> domain. It's
>>     
>>>>>> statement better than the 3gpp example. In some sense, the
>>>>>>             
>> mechanism is
>>

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 30 Jun 2006 16:43:53 -0400

Should SRR-Originators need to be initiators of the corresponding session?
This makes it mandatory to know at the message originator, whether there is
an intermediary which wants to stay in the message path. This may not always
be practical.

I can see that it is necessary that client is strict-routing-aware, but that
is different than it being SRR-Originator.

    Thanks,
    Tolga