Sri, On Mar 22, 2012, at 12:59 AM, Sri Gundavelli wrote:
> Hi Pierrick, > > Catching up on DMM threads, have been sleeping for a while, some comments > woke me up :) > > > I agree with you. IMO, to achieve DMM we need: > > 1.) Localized Gateway Selection. The ability for the network to assign a > anchor point closer to the UE location. Ex: Geo-location, RNC ID ... Most > already got in Rel-10. > > 2.) Once the session is created and the UE moves to a new location. There > should be a new gateway assignment. The network should continue to Assuming most of the applications/communication would be happy with addresses that come and go within a limited but not too small area.. say a L2 segment that contains multiple access points. How important it is then to reassign the "wide area mobility providing" anchor for the remaining flows? I would also keep the minimizing tunneling setup and amount of tunnel state in the network as one design criteria. > advertise both the prefixes, but the advertised prefixes should have the > proper color to distinguish between those prefixes. Agree. > 3.) Network should set up tunneling for the old prefixes, to the prev > anchor. It should deprecate the older prefixes. See above about tunnels. These tunnels are essentially per prefix (or even per address?) and a MN might soon be dragging quite few of those along when it moves. I am a bit worried that the excess tunneling is what we easily end up with.. > 4.) UE should use enhanced SAS schemes to use the new prefix for the new > flows. If you manage to deprecate an old prefix in 3) then new prefixes in 4) are preferred automatically.. assuming the end host does existing RFC3484 to any decent level. > 5.) Over time, once the old flow die, the tunnel to the prev home is gone > and the UE has optimized traffic flows. > > This introduces simple changes into the mobility architecture and most > semantics are already there in one form, or the other. The missing aspect is > the type of Address and how we enable the UE to leverage that aspect and > make Source Address selection and also for the network to manage those > prefixes in a proper way. To that affect, I agree this is one important > requirement. - Jouni > > > > -- > Regards > Sri > > > > > > On 3/19/12 3:16 AM, "[email protected]" <[email protected]> > wrote: > >> I think it is worth to work on solution providing more information on the >> type >> of address. IMHO, it is a requirement for the UE to play with more than one >> IP >> address and select the more appropriate source address according the >> topological anchor point. DMM is clearly one use-case but, this feature is >> also required for offload purpose in current centralized network based >> mobility. The ongoing proposals for RA extensions, that allow to distinguish >> anchored from local prefix, are interesting. Now, the UE shall have the >> intelligence to make the source address selection according to prefix >> properties; at least extensions to RFC3484 may be defined but more >> sophisticated selection behavior may be required, typically, policies based >> selection, e.g. offload policies. >> >> Pierrick > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
