Re: [multimob] PMIPv6 extension for multicast

["Shuai Gao" <[e-mail]>]

Hi, Hitoshi,

	 In your draft, it's mentioned that the MAG sends PIM Join message to its neighboring router (upstream router).  And the upstream link is selected by the RPF algorithm. That is, the upstream router is dependent on the network topology?  If the upstream router is not a LMA, you choose a direct and native routing. Is this same as the solution proposed by sijeon in draft-sijeon-multimob-direct-routing-pmip6-01?  
	And if the upstream router is the LMA, the M-tunnel is generated and used for mulicast transmission.  Actualy, the LMA is also a direct neighbor of the MAG in this scenario.  I don't understand the necessity of the M-tunnel.  The direct routing  does not work in this scenario?  Or the M-tunnel is used for other purposes, like fast handover?

Regards,

Shuai Gao
	

======= 2011-07-19 10:03:57 您在来信中写道：=======

>Hi folks,
>
>> We revised our PMIPv6 extension draft as follows:
>> 
>> http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-06
>> 
>> This draft specifies the scenario in which both LMA and MAG act as
>> PIM-SM routers. This draft addresses the tunnel convergence problem
>> and provides seamless handover. It defines Proxy Binding Update and
>> Proxy Binding Acknowledgement messages with multicast extension.
>
>I'd like to summarize the points this document focuses on.
>
>This document addresses the tunnel convergence problem by an RPF
>lookup algorithm. Although the approach is straightforward, this
>condition assumes both MAG and LMA act as PIM-SM routers.
>In addition, only enabling PIM-SM on MAG and LMA does not provide
>mobility. Therefore this document also provides handover mechanisms by
>adopting the standard PBU/PBA messages with multicast extension or
>using Policy Store maintaining subscribing multicast channel list.
>
>Note that, to simplyfy the protocol extension, this document does not
>provide any "fast" handover mechanism, such as link-layer specific
>mechanisms (e.g. scan in WLAN), prediction for movement, data
>pre-forwarding, and so on.
>The proposed mechanism aims to be flexible and general; it could
>cooperate with other fast handover mechanism. As one of the examples,
>this document refers the idea of CXTP with multicast extension (*1)
>and illustrates the scenario to cooperate with it.
>(*1) draft-vonhugo-multimob-cxtp-extension-00.txt
>
>Thank you for your attention.
>
>Regards,
>--
>Hitoshi Asaeda
>_______________________________________________
>multimob mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/multimob

= = = = = = = = = = = = = = = = = = = =
			

　　　　　　　　致
礼！
 
				 
Shuai Gao
National Engineering Lab for Next Generation Internet Interconnection Devices
Beijing Jiaotong University
Beijing, China, 100044
[e-mail]
2011-07-20