Carlos, please see inline. > -----Original Message----- > From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] > Sent: Sonntag, 18. März 2012 20:59 > To: Marco Liebsch > Cc: dmm@ietf.org > Subject: RE: [DMM] New DMM draft: draft-bernardos-dmm-distributed- > anchoring-00.txt > > Hi Marco, > > Thanks for your comment. Please see inline below. > > On Fri, 2012-03-16 at 10:00 +0000, Marco Liebsch wrote: > > Carlos, > > thanks for your feedback. Please see inline. > > > > > -----Original Message----- > > > From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es] > > > Sent: Freitag, 16. März 2012 09:51 > > > To: Marco Liebsch > > > Cc: dmm@ietf.org > > > Subject: RE: [DMM] New DMM draft: draft-bernardos-dmm-distributed- > > > anchoring-00.txt > > > > > > Hi Marco, > > > > > > Apologies for the late reply. Thanks for reading the draft. Please > > > see some answers to your questions/comments inline below. > > > > > > On Fri, 2012-03-09 at 11:51 +0000, Marco Liebsch wrote: > > > > Hi Carlos, > > > > > > > > I have a few clarifying questions to your new draft. The draft > > > > proposes the distributed logical interface. I don't really get the > > > > advantage of virtualizing the previous LMA on the MN's current LMA > > > > if packets are routed through the previous LMA anyway. Why not > > > > using the current LMA to serve simply as MAG for forwarded traffic > > > > (which remains anchored at previous LMA) and using the new LMA to > > > > anchor the > > > new address/prefix? > > > > > > What you just mention is exactly what the draft does. Additionally, > > > the logical interface simplifies the interface between the MN and > > > the access router that behaves as LMA/MAG. It does so because by > > > interacting with the MN as different "logical" routers (one per > > > anchoring LMA), you can make full use of the ND based features (e.g., > RFC4191) in a very easy way. > > > > > > > > > > > The draft writes that the idea hides the change of the anchor from > > > > the mobile node. The DGW2IF on the new LMA does not pretend to be > > > > LMA1, > > > or? > > > > I don't see how the anchor change is kept transparent to the MN. > > > > > > The point is that from the point of view of the MN, it always "sees" > > > as directly connected (1-hop away) each of the anchor LMAs. Every > > > time the MN moves and attaches to a new access router, the only > > > thing it notices is that a new > > > ("logical") router appears on the link, advertising a new prefix > > > (and, in most use cases, the others start advertising the prefixes > > > with lifetime=0 to deprecate them). > > > > The LMA function should be transparent to the MN anyway, so it does > > not matter whether the LMA, which serves as anchor, is on the previous > > AR or on the current one. Invalidating the previous HNP and validating > > the new HNP can be done independently of whether the responsible LMA > > instance is co-located with the local AR or the previous AR. But I > > must admit that I probably have to check that part of your draft again. > > If it just invalidating the prefix, this can be done, true. But the point is > that > the DLIF concept enables to do more that just invalidating a prefix. Besides, > it > makes easier to implement this prefix deprecation.
Ok, I'll check the description to better understand the DLIF function. > > > > > > > > > > > > > > > > I somehow agree also to Pete's opinion that solving the packet > > > > routing after anchor relocation above the anchors is a good > > > > option. It simply allows more optimal routes. > > > > > > I have to read his draft, but unless you have control on the routing > > > infrastructure (and this is not always possible, and it takes time > > > to converge), I don't see many other options to ensure address > continuity. > > > > I don't expect this to take long time, as the routing states are not > > to be enforced in all routers, at least not in our proposal. > > Intention is to keep the routing plane as it is and update states only > > is one dedicated router per data session, which translates the MN's IP > > address into a routable one to ensure that remaining routers in the > > network forward the downlink packet to the MN's current anchor point. > > The previous anchor point is released from any forwarding tasks. Further > advantage is that routes are potentially more optimal compared to > forwarding from a previous anchor. > > Which does not mean that both approaches cannot co-exist. A DMM > > solution could rely on forwarding while the state in the routing plane is > established. > > I have to admit I haven't checked your proposal yet. No problem ;-) > What you mention > seems like a NAT-based approach, is it true? We propose NAT to save per-packet overhead and use the prefix/IP address being assigned and anchored at the new anchor as locator, which intrinsically has identifier information. So, reverse NAT on the new anchor is easily possible. But that's not the key of the approach, as NAT can be easily replaced by IP tunnels. The key approach is to solve DMM in the routing plane above anchors while using the existing routing plane. > and if there is a dedicated > router, isn't it a centralized entity? It's exactly the opposite. No additional hierarchy level for mobility. Forwarding is being done by standard routers which build the routing plane in the core, metro and aggregation network. They can setup a transient per-host state after the MN's anchor has been relocated and perform a longest prefix match. These routers are distributed throughout the routing plane. After NAT or encapsulation, remaining routers on the path to the MN's current anchor perform routing according to their existing entries, as the used IP address represents a routable address and locator, which is anchored at the MN#s current mobility anchor. >if the point is that that entity is closer to > the MN (not deep in the operator's core), then I see that as a kind-of > hierarchical-alike solution. Mobility anchors are distributed and located closer to the MN. No additional hierarchy level is introduced, as there is no additional anchor above the distributed mobility anchors. marco > > > > > > > > > > > > > > > > Now I am deviating a bit, but into the direction of an important > question: > > > > That's directly related to the question of how persistent we need > > > > to be about IP address continuity. Now, some proposals consider > > > > termination of an IP address prefix, which is anchored at a > > > > previously used anchor point, as soon as the IP session, which > > > > uses that address, terminates. New sessions can use the address > > > > being anchored at the new mobility anchor. My opinion is that we > > > > need to find a good choice about the lifetime of such an anchored > > > > IP address, as it may also be registered with other services, e.g. > > > > IMS, messaging, etc, and would require > > > an updated registration after a change in the registered address. > > > > And even if such lifetime is short, we may not accept suboptimal > > > > routing paths via the previous anchor after anchor relocation. > > > > > > Session lifetime and prefix anchoring termination is a tricky and > > > important issue. As I see it, DMM is compatible with a "classical" > > > centralized approach (at least for the solutions that are basically > > > extending currently standardized IP mobility protocols to operate in > > > a more "distributed" way). For those applications that are known in > > > advance to require very long address lifetime (compared to the > > > anchoring mobility rate), I'd say that those sessions it might make > > > sense to keep them centrally anchored (or to enable applications to > > > be able to survive to an IP address change). > > > > 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. > > Carlos > > > > > marco > > > > > > > > > > Thanks, > > > > > > Carlos > > > > > > > > > > > What do you think? > > > > > > > > Thanks, > > > > marco > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On > > > Behalf > > > > > Of Carlos Jesús Bernardos Cano > > > > > Sent: Montag, 5. März 2012 18:40 > > > > > To: dmm@ietf.org > > > > > Subject: [DMM] New DMM draft: draft-bernardos-dmm-distributed- > > > > > anchoring-00.txt > > > > > > > > > > Dear all, > > > > > > > > > > We've just submitted a new I-D on the DMM space. The draft > > > > > describes a network-based DMM approach extending PMIPv6, and > > > > > focusing on the required extensions to effectively support > > > > > simultaneously anchoring several flows at different distributed > anchors. > > > > > > > > > > As usual, comments would be warmly welcomed! > > > > > > > > > > More info below: > > > > > > > > > > Title : PMIPv6-based distributed anchoring > > > > > Author(s) : Carlos J. Bernardos > > > > > Juan Carlos Zuniga > > > > > Filename : > > > > > draft-bernardos-dmm-distributed-anchoring-00.txt > > > > > Pages : 23 > > > > > Date : 2012-03-05 > > > > > > > > > > Distributed Mobility Management solutions allow for setting up > > > > > networks so that traffic is distributed in an optimal way and does > > > > > not rely on centralized deployed anchors to provide IP mobility > > > > > support. > > > > > > > > > > There are many different approaches to address Distributed > Mobility > > > > > Management, as for example extending network-based mobility > > > protocols > > > > > (like Proxy Mobile IPv6), or client-based mobility protocols (as > > > > > Mobile IPv6), among others. This document follows the former > > > > > approach, and proposes a solution based on Proxy Mobile IPv6 in > which > > > > > mobility sessions are anchored at the last IP hop router (called > > > > > distributed gateway). The distributed gateway is an enhanced > access > > > > > router which is also able to operate as local mobility anchor or > > > > > mobility access gateway, on a per prefix basis. The draft focuses > > > > > on > > > > > the required extensions to effectively support simultaneously > > > > > anchoring several flows at different distributed gateways. > > > > > > > > > > This draft introduces the concept of distributed logical interface > > > > > (at the distributed gateway), which is a software construct that > > > > > allows to easily hide the change of anchor from the mobile node. > > > > > Additionally, the draft describes how to provide session continuity > > > > > in inter-domain scenarios in which dynamic tunneling or signaling > > > > > between distributed gateways from different operators is not > allowed. > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-bernardos-dmm-distribu > > > > > ted- > > > > > anchoring-00.txt > > > > > > > > > > Thanks, > > > > > > > > > > Carlos > > > > > > > > > > -- > > > > > Carlos Jesús Bernardos Cano http://www.netcom.it.uc3m.es/ GPG > FP: > > > > > D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > > > > > -- > > > Carlos Jesús Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: > > > D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > > > -- > Carlos Jesús Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B > 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
