Subject: [Mobopts] RE:explanation for draft-zhang-mipshop-multicast-dma-00.txt

From: "[email-masked]" <[email-masked]>
Date: Tue, 14 Jun 2005 10:00:04 +0800

schmidtHi, Thomas and Matthias,
 Thank you for your comments. Glad that we have a common research interest in mobile IPv6 multicast topic. See our responses below. 
 * We seem to understand that in your approach the MN is left out of
Multicast mobility management except for regular MLD reports - correct?
 Re: Yes, you are right.In our approach,the MSA(Multicast Subnet Agent) is responsible for maintaining the multicast  mobility management information of each MN in the subnet, including the current DMA(Dynamic Multicast Agent) and the previous MSAs of the MN. The MN only needs to do regular MLD reports and tell the previous MSA address to its current local MSA. So the additional requirement for MN to support our approach is very little.

 * In your approach there are anchor points called DMA to guide Mobile
Node's movement. The DMA performs an extensive book keeping on MN's
entire history of attachment.  What is this needed for?
 Re: No, in our approach the DMA only keeps a table to record the MN's recent previous MSA history, not its entire attachment history. 
 The use of DMA(Dynamic Multicast Agent) is the key feature of our approach. We think that a static MA(Multicast agent) is not effective, since it may often result in a bottleneck and a very long multicast path between the MN and its MA. And we also think that it's not necessary for all of its local MSAs along the roaming path to join the multicast delivery trees when the MN with multicast services subscription is roaming, since the frequent remote multicast subscription and the resulted multicast tree restructuring are not effective. 
 So We select a comprimised approach, using a Dynamic Multicat Agent to join the multicast delivery trees. When a MN is roaming, its first local MSA address will become its first DMA. Then within an acceptable roaming distance, its DMA will not change althouth its MSA changes. Beyond this distance, its DMA will be switched to a new local MSA address. By keeping a table of  the MN's recent previous MSA, the current DMA of a MN could easily know and decide whether and when to do DMA switch for the MN.

 * After a handover you state that the local Multicast router "MSA
communicates with the previous DMA ..." - how is this achieved? How does
the local MSA know of any previously chosen DMA?
Re: The MN only needs to do regular MLD reports and tell the previous MSA address to its current local MSA. Then the  current local MSA will ask the previous MSA to get the MN's DMA.

 * If - after a handover - the local Multicast router (MSA) is not
already part of the delivery tree, you advise the procedure:
" ... the MSA communicates with the previous DMA of
MN. If the previous DMA selects a new DMA, the MSA of current
 subnet works as new DMA, and it creates and maintains an entry
for this MN in the MSA list of this MSA."
That means the MSA has to subscribe to Multicast group(s) of MN
subsequent to negotiations with DMA, i.e. a remote subscription, which
is retarded by some prior protocol overhead. So, as the overall result,
one would expect a handover performance slower than the immediate remote
subscription.
Re: Only if the MN's DMA need be switched to the current local MSA, the current MSA has to do a multicast group  subscription. However, the DMA switch is not so often within an acceptable roaming distance. We believe that the frequent "immediate MSA multicast remote subscription" is unbearable and much slower. Our approach reduces the frequent remote subscription and multicast tree restructuring by introducing the concept of DMA. 

 * You present an agent-based approach to ASM receiver mobility. This is
in principle not new. There are (or have been) several drafts out, to
mention two:
- Suh, K., Kwon, D.-H., Suh, Y.-J. and Park, Y. "Fast Multicast
Protocol for Mobile IPv6 in the fast handovers environments",
IETF, Internet Draft - (work in progress), February 2004.
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-schmidt-waehlisch-mhmipv6-03.txt
Can you comment on how your approach enhances the previously published work?
Re: Thanks for your reference. But we believe our approach is quite different from these two draft as you mentioned.  First, in our draft the DMA is dynamic and different MN in the same subnet may select different DMA. So the load of one DMA can be lightened and not a performance bottleneck. Second, our approach can avoid the long multicast tunnels frequently between Multicast Agent and MN, and also reduce a lot of multicast tunnels between Multicast Agent and MNs.

Thanks again. We hope to have a chance to discuss with all IETF experts interested in MIP6 multicast. This is a very significant topic for NGI.
Best Regards,
Hong-Ke Zhang

　　　　　　　　HKzhang
　　　　　　　　[email-masked]
　　　　　　　　　　2005-06-14
_______________________________________________
Mobopts mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts