Subject: Re: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00

From: Tina TSOU <[email-masked]>
Date: Wed, 23 Aug 2006 10:44:19 +0800

Hi all,
   In [RFC3588], routing of request messages from source to the
   destination is based solely on the routing decision made by each node
   along the path.  In a topology where multiple paths are possible from
   source to destination, it is not guaranteed that all messages
   constituting a session will take the same path.  For a proxy node
   residing along a path that maintains stateful information for a
   session, it is desirable that it remains in the routing path of all
   message exchanges of that a session.

   In general, a session which comprises of multiple message exchanges
   and requires intermediary proxy functions will require explicit
   routing for all request messages within that session.  An example of
   a stateful proxies are in the WLAN 3GPP IP access [TS23.234].  The
   WLAN Access Network (WLAN AN) can use Diameter EAP with the 3GPP AAA
   server or proxy for authentication & authorization.  In the roaming
   case, the WLAN AN is communicating with a 3GPP AAA Proxy in the
   visited network over the Wa reference point.  The 3GPP AAA proxy is
   then connected to the 3GPP Server in the home network over the Wd
   reference point.  The 3GPP AAA Proxy among its many functions will
   enforce local policies on access based on agreement with the 3GPP
   Home Network and with the WLAN operator.  It will also send per user
   charging information for the session to the Offline Charging system.
   This necessitates that the proxy maintains the session state
   information and hence it needs to remain in-path for the entire
   session.

   Given that there are cases where a stateful proxies need to be in the
   routing path of a session, a generic description of the problem is
   shown in Figure 1.  In this scenario there is a relay in the visited
   network (Relay1) and two(2) proxies in the home network (Proxy2 and
   Proxy3).  Relay1 is connected to Proxy2 and Proxy3 for scalability
   and/or redundancy.  If a session is composed of several request/
   answer exchanges it is possible that each request of the session
   takes different paths towards the Home Server.  As an example, if
   Relay1 can route messages via Proxy2 or Proxy3 based on some policy
   independent of the session then the first message of the session can
   take the path Client->Relay1->Proxy2->Home Server while subsequent
   message can take the path Client->Relay1->Proxy3->Home Server.  In
   this case if Proxy2 is stateful then it expects to process not only
   the first message but subsequent request as well.
              VISITED NETWORK     |    HOME NETWORK
                                  |
      +--------+     +--------+   |   +--------+
      | Client |<--->| Relay1 |<----->| Proxy2 |
      +--------+     +--------+   |   +--------+\
                               \  |              \+-------------+
                                \ |               | Home Server |
                                 \|              /+-------------+
                                  \   +--------+/
                                  |---| Proxy3 |
                                  |   +--------+

   Figure 1: Generic Stateful Proxy Problem

   In larger deployments, the issue can be aggrevated when there are a
   greater number of proxy nodes in both visited and home networks in
   Figure 1.  Further escalation of the problem occurs if the deployment
   adds stateless relays preceding any of the proxy nodes in Figure 1.

   In [RFC3588], it is possible to use static routing between the source
   and the proxy to ensure all message exchanges traverses the proxy in
   question.  However, static routing in general, introduces many
   limitations.

   o  Static routing implies that all messages, regardless of session,
      will have to traverse the same proxy.  This introduces a single
      point of failure in the routing path and affects any and all
      sessions regardless of whether the session is of interest to the
      proxy.

   o  It compromises failover procedure in the node adjacent to the
      proxy and preceding it in the request forwarding path.  This
      becomes apparent if the adjacent node explicitly and statically
      routes only towards the proxy.

   o  In the event of more complex topologies where multiple proxies are
      traversed between source and destination, the administrative
      burden of static configuration along the path may be considerable.

   o  No provision for load balancing as all the nodes in the path will
      be subjected to static routing.

   Considering these limitations, an alternative and more dynamic method
   of establishing an explicit routing is proposed.

B. R.
Tina

----- Original Message ----- 
From: "Glen Zorn (gwz)" <[email-masked]>
To: "Victor Fajardo" <[email-masked]>; "Tschofenig, Hannes" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 22, 2006 4:34 AM
Subject: RE: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00

Victor Fajardo <mailto:[email-masked]> supposedly scribbled:

> Hi Hannes,
>> Hi Victor,
>> 
>> in the discussions the 3GPP WLAN work was mentioned as the usage
>> scenario. 
>> Is it a real problem in their environment? I have never heard
>> something about problems along these lines. 
>> 
> 
>  From what I understood, it is a problem envisioned by some folks
> when trying to deploy diameter in such environment. I think Tina and
> others can shed light into this better than I can.  

I, for one, would _really_ like to hear this.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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

---

From: Tina TSOU <[email-masked]>
Date: Sat, 26 Aug 2006 10:23:24 +0800

Hi all,
Furthermore,
1) What scenario is there Diameter Relay?
Between home network and visit network, one network (e.g. visit network) does not want to expose the IP address of all its AAA servers to the other network (e.g. home network). So, visit network puts a Diameter Relay as the single contact point for home network. At the same time, it reduces the connections number between home network and visit network.

2) What scenario is this Diameter Relay connected to two Diameter Proxies?
The capability of one Diameter Proxy is not enough to process all the users in one network. One network has more than 1,000,000 users. However, one Diameter Proxy has the capability of 1,000,000 users. Hence, more than one Diameter Proxies are needed in this network.

Have a great weekend:)

B. R.
Tina
  ----- Original Message ----- 
  From: Tina TSOU 
  To: Tschofenig, Hannes ; Victor Fajardo ; Glen Zorn (gwz) 
  Cc: [email-masked] 
  Sent: Wednesday, August 23, 2006 10:44 AM
  Subject: Re: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00

  Hi all,

  B. R.
  Tina

  ----- Original Message ----- 
  From: "Glen Zorn (gwz)" <[email-masked]>
  To: "Victor Fajardo" <[email-masked]>; "Tschofenig, Hannes" <[email-masked]>
  Cc: <[email-masked]>
  Sent: Tuesday, August 22, 2006 4:34 AM
  Subject: RE: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00

  ...

  Hope this helps,

  ~gwz

------------------------------------------------------------------------------

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 28 Aug 2006 08:36:19 -0400

IMHO, the problems Tina explained (and which are also explained in tne
draft) need to be addressed, so I think the draft defines a useful
mechanism.

The problems I see with the draft are:
a)It defines two different functionalities, they need to be separated.
b)It doesn't mention about alternative solutions (using stateful agents,
using ALG type approach to regenerate messages etc..). I don't know whether
this should be a different draft though (one about possible solutions for
"how to stay on the message path during the session" problem and one
defining the mechanism described in the draft, where it is referred to from
the first one)

    Thanks,
    Tolga

-----Original Message-----
From: Tina TSOU [mailto:[email-masked]]
Sent: Friday, August 25, 2006 10:23 PM
To: Glen Zorn (gwz); Victor Fajardo; Tschofenig, Hannes
Cc: [email-masked]
Subject: Re: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00

Hi all,
Furthermore,
1) What scenario is there Diameter Relay?
Between home network and visit network, one network (e.g. visit network)
does not want to expose the IP address of all its AAA servers to the other
network (e.g. home network). So, visit network puts a Diameter Relay as the
single contact point for home network. At the same time, it reduces the
connections number between home network and visit network.

2) What scenario is this Diameter Relay connected to two Diameter Proxies?
The capability of one Diameter Proxy is not enough to process all the users
in one network. One network has more than 1,000,000 users. However, one
Diameter Proxy has the capability of 1,000,000 users. Hence, more than one
Diameter Proxies are needed in this network.

Have a great weekend:)

B. R.
Tina
----- Original Message -----
From: Tina TSOU
To: Tschofenig, Hannes ; Victor Fajardo ; Glen Zorn (gwz)
Cc: [email-masked]
Sent: Wednesday, August 23, 2006 10:44 AM
Subject: Re: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00

Hi all,

B. R.
Tina

----- Original Message -----
From: "Glen Zorn (gwz)" <[email-masked]>
To: "Victor Fajardo" <[email-masked]>; "Tschofenig, Hannes"
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 22, 2006 4:34 AM
Subject: RE: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00

...

Hope this helps,

~gwz