Re: [multimob] PMIPv6 extension for multicast

[Behcet Sarikaya <[e-mail]>]

> 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 Section 3.2 you have:

The MAG selects only one upstream link for a multicast channel by the    Reverse 
Path Forwarding (RPF) algorithm even if the MAG has    established multiple 
M-Tunnels to LMAs.  This does not cause the    tunnel convergence problem, 
because duplicate packets are not    forwarded to the MAG.This means that MAG 
does not send any new joins to the same group upstream, right?
I agree that it would solve the problem but does it create new problems, like 
what happens if the member MN leaves the group and no more data can be received 
while other MNs possibly wanted to continue.


> 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


I am confused here.
If we use draft-vonhugo-multimob-cxtp-extension then the handover in Section 8 
would not be needed? Is the technique in draft-vonhugo-multimob-cxtp-extension 

stand alone and would achieve fast handover by itself or not?



Regards,

Behcet