Hi Carlos and Marco, As Marco said
*********************************************************************** 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 also think it is possible to let UE treat those multiple IP addresses differently. Some modification may be needed to let mobile node to have such intelligence. But the question is, one of principles of PMIP is not to touch mobile node. And you know, MIP already supports distinguishing between HoA and CoA in mobile node. Since we will touch mobile node anyway, why don't we use MIP directly? BR Luowen Marco Liebsch <[email protected]> 发件人: [email protected] 2012/03/16 18:00 收件人 "[email protected]" <[email protected]> 抄送 "[email protected]" <[email protected]> 主题 Re: [DMM] New DMM draft: draft-bernardos-dmm-distributed-anchoring-00.txt Carlos, thanks for your feedback. Please see inline. > -----Original Message----- > From: Carlos Jesús Bernardos Cano [mailto:[email protected]] > Sent: Freitag, 16. März 2012 09:51 > To: Marco Liebsch > Cc: [email protected] > 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. > > > > > 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. > > > > > 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. marco > > Thanks, > > Carlos > > > > > What do you think? > > > > Thanks, > > marco > > > > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > Behalf > > > Of Carlos Jesús Bernardos Cano > > > Sent: Montag, 5. März 2012 18:40 > > > To: [email protected] > > > 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-distributed- > > > 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 _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
