> -----Message d'origine----- > De : Marco Liebsch [mailto:[email protected]] > Envoyé : lundi 19 mars 2012 11:53 > À : SEITE Pierrick RD-RESA-REN; [email protected]; [email protected] > Cc : [email protected] > Objet : RE: [DMM] New DMM draft:draft-bernardos-dmm-distributed- > anchoring-00.txt > > Hi Pierrick, > > I agree that this is an interesting approach from research point of > view. The question > is how practical this is. Intelligence on the MN is ok, but to take a > decision about which > IP address to use, the MN needs information. If information is solely a > binding between the prefix > and the level of the associated anchor in a hierarchy of anchors, then > the > MN may select a prefix/address according to the expected IP session > duration to avoid > a change in the topological anchor of the used IP address. Taking such > decision requires also > some information about the topology, which I doubt operators will > reveal.
I confirm :-) Important > here is the location of the anchor and the location of the used serving > point. Latter could > be a public Internet service, hence knowledge of the operator's IX > peering points may > be relevant. If the serving point is operator CDN-like, typically the > MN is served > by transparent caching, hence, the location of the cache is not known > to the MN. > You're right but, actually, we may not need a so smart selection. I was not talking about a so sophisticated selection; actually, IMHO, the requirement, is just that the UE can distinguish anchored prefix/address to be used by the application which need mobility support. Today, with network based mobility management, there is no way for the UE to know the type of address. > A different and pragmatic approach is to select the closest anchor > point to serve any IP session > of the UE and to provide a good solution to handle routing after anchor > relocation plus > renewal of the MN's IP address from time to time. IMO, such approach > enables short > routing paths between any source and the MN while offloading traffic > from the core > network as its best. > I agree, IMO, this is basic requirement of DMM; but I do not see this approach as different, it is complementary. BR, Pierrick > marco > > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > Sent: Montag, 19. März 2012 11:17 > > To: [email protected]; [email protected]; Marco Liebsch > > Cc: [email protected] > > Subject: RE: [DMM] New DMM draft:draft-bernardos-dmm-distributed- > > anchoring-00.txt > > > > 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 > > > > > -----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
