Hi Carlos: Thank you for your reply.
And please see further comments inline. BR Luowen Carlos Jesús Bernardos Cano <[email protected]> 2012/03/16 16:49 请答复 给 [email protected] 收件人 [email protected] 抄送 "[email protected]" <[email protected]> 主题 Re: [DMM] review of draft-bernardos-dmm-distributed-anchoring-00 Hi Luowen, First of all, apologies for my late reply. Please, see inline below. On Tue, 2012-03-13 at 14:43 +0800, [email protected] wrote: > > Hi Carlos > > I have reviewed your draft, and I have two questions to your draft as > following: Thanks for reading it. > > First, let's consider this scenario. Initially, MN is attached to > D-GW1 and has a session#1 (anchored at D-GW1). When moving to D-GW2, > MN starts another session#2 (session#1 keeps on going). As per your > draft, D-GW2 should simulate mndgw1 and mndgw2 and establish a tunnel > with D-GW1 for this MN. MN continues to move to D-GW3. Then D-GW3 > should simulate mndgw1, mndgw2 and mndgw3 and maintains two forwarding > tunnels between itself and D-GW1, D-GW2 for the MN. And MN could > continue to move again and again..... > PMIP requires only one MAG and only one PMIP tunnel for one MN. But it > seems that, your draft requires, for one MN, multiple MAGs (i.e. those > mndgw1, mndgw2 and mndgw3) and multiple tunnels for one MN. If MN The solution requires multiple logical interfaces to be created on the D-GW, but the tunnels between them could be re-used. > keeps on moving, the situation will become worse. I mean, maybe > dozens of MAGs and tunnels are needed for this MN. In this case, > performance of your D-GW will be a big issue. Of course, you can Creation and maintenance of logical interfaces is a very low resource consuming task. If per-MN-per-anchor tunnel creation is a problem, they can be shared among several MNs. **************** [LW] Yes, you can share the tunnel among those MNs. [LW] But for every single mobile node, serving D-GW needs to maintain mobility context in granularity of HNP for this mobile node which means you need more space to strore the binding information. Besides, all those anchor D-GWs of this mobile need maintain mobility context each. One issue of centralized mobility management is known as "Wasting resources to support mobile nodes not needing mobility" ( http://tools.ietf.org/html/draft-chan-dmm-requirements-00, section 4.5). This view concerns too many mobility context need maintenance may cause resources waste. And as per my understanding, your draft may have some contradiction with respect to this view. [LW] Btw, in your demo at IETF83, how many those logical interfaces will you show to us? **************** Besides, in realistic deployments, the chances that an MN has active anchored prefixes in more than 2-3 D-GWs will be very low. Most likely, address continuity will be only provided for one prefix anchored at a different D-GW. ************* [LW] Yes, if most of applications are short lived, your assumption may be ture (i.e. no more than 2-3 D-GW). [LW] But long lived applications (e.g. video streaming, online gaming, voip, ...) should also be considered. In this case, there should be more D-GWs are invloved. And you know LTE has already prepared for those long lived even "always on" applications, e.g. an LTE-UE will get its HNP/IP when its default bearer is established during its intial entry, and this HNP/IP will keep alive always as long as this UE stays in LTE network. My point is, we had better not always build some solution based on the assumption that the applications are short lived. **************** > limited the HNPes one MN can maintain (e.g. 3 HNPes per MN, then only > 3 D-GWs could be involved at most), but to me, it is very hard to > determine the threshold to satisfy every single MN. Otherwise, > network should have a mechanism for terminating IP addresses to > release some D-GWs. But how to determine an IP address (HNP) is not > used by a MN is also a challenge. There are several mechanisms that can be used to determine that an IP address is no longer active. Some of them involve active participation from the MN itself (which is the entity that actually knows it). ************* [LW] Yes, we need to specify this mechanism. To me, just cut off the IP address based on a timer in the GW may not be gentle enough. ************* > > Second, in figure 2 of your draft, D-GW2 simulates two logic GWs (i.e. > mn1dgw1 and mn1dgw2), and MN is attached to both two logic GWs. Does > this indicate MN should maintain tow separated logic link with mn1dgw1 > and mn1dgw2 respectively? If it does, then how can you ensure that MN > will establish an additional logic link with mn1dgw2 when MN moves > from D-GW1 to D-GW2? No, no logical links are required. From the point of view of the MN, it is just as it is attached to a link where two routers are also attached. When MN move to D-GW3, it is as a new router got attached to the link (no configuration step required by the MN). ************* [LW] Well, another question: when MN attaches to D-GW2, D-GW2 will simulate mn1dgw1, mn1dgw2 and send a RA to MN, does this RA contain both prefixes which are are used when MN anchored in D-GW1 and prefixes which belong to D-GW2's management ? ************* Thanks, Carlos > > What do you think? > > BR > Luowen -- Carlos Jesús Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67
signature.asc
Description: Binary data
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
