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. 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.
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. marco > -----Original Message----- > From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com] > Sent: Montag, 19. März 2012 11:17 > To: jouni.nos...@gmail.com; c...@it.uc3m.es; Marco Liebsch > Cc: dmm@ietf.org > 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 : dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] De la part de > > jouni korhonen Envoyé : dimanche 18 mars 2012 21:47 À : Carlos Jesús > > Bernardos Cano; Marco Liebsch Cc : dmm@ietf.org 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 > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
