Hi Rich, I think your proposal makes sense. The wikipedia document http://en.wikipedia.org/wiki/Mobile_IP provides some links to relative RFCs. We may find details in these RFCs. I will also try to read them.
BR, -Haibin ________________________________________ From: [email protected] [[email protected]] on behalf of Richard Alimi [[email protected]] Sent: Thursday, March 29, 2012 8:09 PM To: Songhaibin Cc: [email protected] Subject: Re: [alto] ALTO discovery in roaming scenario On Thu, Mar 29, 2012 at 12:26 AM, Songhaibin <[email protected]> wrote: > Hi Rich, > > Thank you for the discussion. See inline. > > ________________________________________ > From: [email protected] [[email protected]] on behalf of Richard > Alimi [[email protected]] > Sent: Wednesday, March 28, 2012 11:57 PM > To: Songhaibin > Cc: [email protected] > Subject: Re: [alto] ALTO discovery in roaming scenario > > On Mon, Mar 19, 2012 at 4:28 AM, Songhaibin <[email protected]> wrote: >> Hi, >> >> The indicated by the subject, which is perhaps not fully solved in the >> discovery draft, I guess at least the following scenarios should be >> considered. As I'm not an expert on roaming technology, please correct me if >> you find I am wrong. >> >> (1) The ALTO client has left its home network, and its IP address is >> dynamically assigned by the current network provider (through DHCP or any >> other method), but the ALTO client still uses its home agent to access the >> Internet. In this case, the ALTO server resided in its home network should >> be the right ALTO server to be discovered. >> >> (2) The ALTO client has left its home network, and its IP address is >> dynamically assigned by the current network provider, and the ALTO client >> uses the foreign agent to access Internet or uses its IP address directly to >> access Internet. In this scenario, the ALTO server resided in the current >> network should be the right one. And the existing discovery mechanism works >> in this scenario. >> >> (3) If the ALTO client has a persistent IP address when roaming, and it uses >> home agent to access Internet, but make large data route to the foreign >> agent directly (optimized routing mode). In this scenario, the ALTO server >> resided in the current network should be the right one to be discovered. >> However, if it does not adopt the optimized routing mode, the ALTO server in >> the home network should be the right one. >> > > I'm not familiar with the technologies backing this, but what entity > decides the route that a particular packet will take? Is this DPI > living in the network where the client is roaming? Or is it some > entity on the client itself? > > [Haibin] No, it is not DPI based. Although I'm not an expert on this either, > but I think in the mobile IPv6 scenario, the decision is made through the > negotiation among the mobile node, home agent, and other correspondent nodes. > Thinking about this at the high level, If the mobile node is involved in the negotiation, then it seems like it could work like the following for this case: (1) Discover an ALTO Server using the home agent (same as case 1 above) (2) Discover an ALTO Server using the current network (same as case 2 above) (3) When it comes time to apply the ALTO information, apply the correct set depending on the routing for that particular request. Is that compatible with whatever technologies are used for these scenarios? Details on how this works and the negotiation actually takes place would be useful. Rich > BR, > -Haibin > >> (4) (this one is not about roaming) Assume in a big company which has a few >> branch offices in different locations, and VPN tunnels are used to connect >> these branch offices, employees use one proxy to access Internet. Then the >> ALTO server discovery should be based on the proxy's IP address instead of >> the user's IP address. It also applies to other similar scenarios when >> end-hosts using proxies. >> >> It might not be a problem when doing third party discovery, but have to >> consider when doing the discovery by the end-host itself. >> >> BR, >> -Haibin >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
