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

["Tolga Asveren" <asveren at ulticom.com>]

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:vfajardo at tari.toshiba.com]
> Sent: Tuesday, June 27, 2006 10:43 AM
> To: Tolga Asveren
> Cc: Tony Zhang; dime at ietf.org
> 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,
> >  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
>
> > Regards!
> >     Tony
> >
> > ----- Original Message -----
> > From: "Tolga Asveren" <asveren at ulticom.com>
> > To: <dime at ietf.org>
> > Sent: Tuesday, June 27, 2006 3:49 AM
> > Subject: [Dime] Comments for draft-tsou-dime-base-routing-ext
> >
> >
> >
> >> 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
> >> DiME at ietf.org
> >> https://www1.ietf.org/mailman/listinfo/dime
> >>
> >>
> >
> > _______________________________________________
> > DiME mailing list
> > DiME at ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> >
> >
> >


_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime