Pierrick, On Mar 19, 2012, at 12:16 PM, <[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 To me offloading and DMM go hand in hand, since how the current charter is described emphasizes the use of CoAs (could be the "local prefix"). With some care, solutions developed in DMM space apply to both. At least this is what I want to see to happen. > 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. For example, draft-korhonen-dmm-prefix-properties discuss briefly how to hook into RFC3484bis (and even to RFC3484). The text superseding source address selection Rule 8: Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the "best" communications performance. is especially a good fit here. - Jouni > > Pierrick > >> -----Message d'origine----- >> De : [email protected] [mailto:[email protected]] De la part de >> jouni korhonen >> Envoyé : dimanche 18 mars 2012 21:47 >> À : Carlos Jesús Bernardos Cano; Marco Liebsch >> Cc : [email protected] >> Objet : Re: [DMM] New DMM draft:draft-bernardos-dmm-distributed- >> anchoring-00.txt >> >> >>>> >>>> So you think that the UE should receive multiple IP addresses and >> treat them >>>> differently according to the associated topological anchor point? >> Hmm, yes, possible. >>>> What about real time streaming and other IP data sessions, which >> could have a >>>> longer lifetime, they should be anchored than at a central point as >> well, right? >>>> If the MN had such intelligence and information, it could treat the >> HNPs differently, true. >>> >>> I think thank kind of approaches make sense. >> >> There are a couple proposals on table that go into this direction. We >> put those >> under "addressing enhancements" slot. Basically piggybacking anchoring >> properties >> of a prefix along with address configuration. >> >> - Jouni >> >> >> >>> >>> Carlos >>> >>>> >>>> marco >> >> _______________________________________________ >> dmm mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
