Haibin,
The draft already states:
o A change of the IP address at an interface invalidates the result
of the ALTO server discovery procedure. For instance, if the IP
address assigned to a mobile host changes due to host mobility, it
is required to run the ALTO server discovery procedure for the new
IP address without relying on earlier gained information.
Could you please explain what text is missing in the draft, and what technical
solution you suggest? For instance, if the mobile network uses "Proxy Mobile
IP"?
My understanding is that in reality roaming/normadic use results in either of
two possibilities:
(1) There is a change of the IP address of the mobile host. This case is
already explained in the draft.
(2) The IP address of the mobile host does not change. Then, the host remains
in the same IP subnet, and thus the ALTO discovery result is still valid.
In both cases, the current text in the discovery draft seems to be just fine,
right?
Thanks
Michael
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Songhaibin
> Sent: Monday, June 18, 2012 1:22 PM
> To: Songhaibin; Richard Alimi
> Cc: [email protected]
> Subject: Re: [alto] ALTO discovery in roaming scenario
>
> I would like to dig this from the tomb and see how the WG
> would like to solve the ALTO discovery in the roaming/nomadic
> scenario. I would also like to see it in the ALTO server
> discovery document.
>
> -Haibin
>
>
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> On Behalf
> > Of Songhaibin
> > Sent: Thursday, March 29, 2012 8:34 PM
> > To: Richard Alimi
> > Cc: [email protected]
> > Subject: Re: [alto] ALTO discovery in roaming scenario
> >
> > 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
> _______________________________________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/alto
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
