Subject: Re: [multimob] Comments on draft-zuniga-multimob-smspmip-00

From: "Lu, Guang" <[email-masked]>
Date: Sun, 1 Nov 2009 23:26:12 -0500

Hi Thomas and Luis, 

Thank both of you for bringing in the constructive discussions. Please see my input. 

Thanks,
Guang

> -----Original Message-----
> From: Thomas C. Schmidt [mailto:[email-masked]]
> Sent: Saturday, October 31, 2009 9:25 AM
> To: Luis M. Contreras
> Cc: [email-masked]; Lu, Guang
> Subject: Re: [multimob] Comments on draft-zuniga-multimob-smspmip-00
> 
> Hi Luis,
> 
> O.K. - you caught me by being too fast ;)
> 
> The issue nevertheless is only the name "LMA" I guess ... see below:
> 
> Luis M. Contreras wrote:
> 
> > My answer below:
> >
> >>>> Section 4 presents the architecture of the dedicated LMA
> multicast. I
> >>>> have two questions on this:
> >>>> - Both LMAs (unicast and multicast) keep the same information in
> their
> >>>> respective binding caches? How can be guaranteed the coherence of
> the
> >>>> information contained in both binding caches?
> >>> [Guang-JC] Both unicast and multicast LMAs serve independent sets
> of MNs
> >>> so they can have different binding caches. On the other hand, if an
> MN
> >>> has both the unicast LMA and multicast LMA in its policy profile,
> the
> >>> MAG will do the Binding Update to unicast LMA and multicast LMA
> >>> independently.
> >> [Thomas] There is no need for a binding cache here, as - according
> to
> >> the draft - there is only a single MLD proxy instance, thus a single
> >> uplink and therefore only a single multicast LMA. All MAGs
> throughout
> >> the PMIP domain MUST share the uplink for multicast with this
> >> particular LMA. The LMA will thus forward according to
> >> (proxy-initiated) forwarding states at its tunnel interfaces that
> are
> >> independent of individual MNs.
> >>
> > [Luis] According to RFC5213, section 3, the actions taken by the LMA
> > once it receives tha PBU message from the MAG are: "Upon accepting
> this
> > Proxy Binding Update message, the local mobility anchor sends a Proxy
> > Binding Acknowledgement message including the mobile node's home
> network
> > prefix(es). It also creates the Binding Cache entry and sets up its
> > endpoint of the bi-directional tunnel to the mobile access gateway."
> So,
> > if the way of registering in the multicast-dedicated LMA is the
> standard
> > PBU/PBA procedure, a binding cache should be created and maintained
> for
> > the MN there. If not, we are altering the protocol specified in
> RFC5213.
> > Maybe this is an extreme interpretation by myself.
> >
> 
> [Thomas] I agree, you are perfectly right, as long as we call this
> multicast thing "LMA". If we just call it a multicast designated
> router,
> then no binding procedures with the MN ("A receiver") are required. In
> fact, an MLD proxy is supposed to aggregate states ... and a multicast
> router is supposed to maintain only 'anonymous' forwarding states at
> its
> downstream interfaces (towards the MAGs). That actually would make
> things much easier and reduces protocol operations to what is really
> needed.
> 
> > Furthermore something could be said regarding the reference in
> RFC5213
> > to the mobile node's home network prefix(es). I think that if the
> > procedure is not the same for LMA multicast than for LMA unicast we
> are
> > then defining a bit different signalling procedure .
> >
> 
> [Thomas] The home network prefix(es) and all other *unicast*-related
> states of the MN's profile should be maintained by the (untouched)
> unicast entities: there will be an LMA operating unicast mobility as
> described in RFC5213 ... in this proposal, multicast comes as an
> "additional overlay", unseen by the 'standard LMAs', I believe.
> 
> Am I understanding things correctly?
[Guang-JC] Your interpretation in the paragraph above is in-line with our reply on this comment. Please see embedded above. 

> 
> Best regards,
> 
> Thomas
> --
> 
> Prof. Dr. Thomas C. Schmidt
> ° Hamburg University of Applied Sciences                   Berliner Tor
> 7 °
> ° Dept. Informatik, Internet Technologies Group    20099 Hamburg,
> Germany °
> ° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-
> 8452 °
> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-
> 8409 °