Re: [multimob] Comparing the proposals for basic multicast support

["Lu, Guang" <[e-mail]>]

Hi Thomas, 

Thank you for reviewing our draft and providing comments. Please see our replies embedded below.

Best regards
Guang & Juan Carlos

> -----Original Message-----
> From: Thomas C. Schmidt [mailto:[e-mail]]
> Sent: Saturday, October 24, 2009 1:38 PM
> To: Lu, Guang
> Cc: Stig Venaas; [e-mail]
> Subject: Re: [multimob] Comparing the proposals for basic multicast
> support
> 
> Hi Guang and Juan Carlos,
> 
> here comes the "real review" - sorry for the previous mismatch.
> 
> I read through your draft and have the following comments:
> 
>    Section 3:
> 
> Here you sketch in brief what has been detailed out in previous work.
[Guang-JC] We read the existing drafts. This section meant to explain our view of the basic solutions, as suggested in the charter. It is good that solutions from different drafts are converging.

> Does Figure 3 omit MLD queries, as well? If not, why should a MN send
> an
> MLD report subsequent to re-attachment?
[Guang-JC] All MLD queries were omitted in the figures for simplicity. MN can also send unsolicited reports.

> Another remark on presentation: you skip additional LMAs that may be
> around for other MNs. In doing so, the draft expresses the misleading
> intuition of a uniquely defined path from MAGs to 'the' LMA - in
> PMIPv6,
> there is need for a mapping.
[Guang-JC] Since the call flows illustrated one LMA, we showed one LMA only in the architecture figure. We can add another LMA in Figure 1, but that LMA would not be used in the call flows and that might also create confusion.

> 
>    Section 4:
> 
> In this section you contribute the proposal to concentrate all
> multicast
> channels on one dedicated LMA. This approach obsoletes a MN <-> LMA
> mapping at MAGs in the case of multicast and resolves redundant traffic
> possibly arriving at one MAG. In eliminating the tunnel convergence
> problem at the MAG, you place the burden at the LMA and may encounter
> the traditional tunnel convergence problem of a HA in the bi-
> directional
> tunneling approach (see
> http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-09). The
> scalability constraint arises from the burden at the LMA to serve
> \sum_{i in MAGs}{Mcast-Streams-at-MAG_i} simultaneously. A large number
> of MAGs with various mcast listeners is your problem here, while a
> large
> number of MNs attached at one MAG, but associated to different LMAs is
> the problem of the solution in
> [draft-schmidt-multimob-pmipv6-mcast-deployment-02].
[Guang-JC] The tunnel convergence issue, as you said, is a traditional issue with PMIP. Actually the dedicated multicast LMA architecture can help to avoid tunnel convergence, and control the traffic load at LMA. For example, one multicast tunnel can be used instead of multiple unicast tunnels for multicast traffic.

> 
> Furthermore, as written earlier:
> A corresponding deployment would be as follows: Operators have a PMIP
> (unicast) domain and add (and statically pre-configure at MAGs) an
> additional multicast LMA that serves all groups. This is a set-up not
> considered so far, but may be feasible for operators???
> 
> ==> Operator comments should debate on that.
> 
>    Section 5:
> 
> This section I don't really understand: you call for HO-triggers
> without
> specifying them. Do you just speak about L2 triggers at re-attachment?
> This I believe is independent of multicast, outside the scope of
> Multimob and solved elsewhere, anyway.
> Do you speak about a L3 trigger of re-attachment? This actually is
> present in PMIP with the RtrSol. There is nothing new then.
> Or do you speak about fast predictive handovers (as indicated between
> the lines)? Then you should look at
> http://tools.ietf.org/html/draft-ietf-mipshop-pfmipv6-09, but multicast
> considerations for fast handovers are still out of scope from the
> charter.
[Guang-JC] We used a general term of "HO Trigger" to refer to any kind of triggers regarding to HO before re-attachments. These triggers can be in different forms, such as L2 triggers, or a command from the network, etc. We are aware of such discussions within other groups. Our purpose is not to propose such triggers, but to illustrate how such information can be used in PMIP to facilitate HO for multicast services. Also, draft-ietf-mipshop-pfmipv6-09 proposes a tunnel between pMAG and nMAG for traffic forwarding. We propose to pass the control information only, not the data between the network nodes.

> 
>   Section 6:
> 
> You propose two "MLD enhancements": In 6.1 you sketch a predictive JOIN
> - this again is a brick of a (generally much more complex) fast
> handover
> scenario (s.o.).
[Guang-JC] We wanted to state how the multicast JOIN procedure can be enhanced in general. It can be based on other work, say the fast handover solutions.

> In section 6.2, you consider a "fast join" send by the MN on
> re-attachment. This actually requires an active participation of the MN
> in the PMIP HO process - and is violating the key objective of PMIP to
> leave mobility operations at the network side.
[Guang-JC] In our view, this does not require the MN to participate in the HO process. It only requires that the MN is "aware" that a new interface is up, which is usually available at a host.

> 
> In summary, I would extract the "dedicated LMA for multicast" as the
> valid contribution, which you jointly propose with
> [draft-contreras-multimob-msd-00]. There should probably follow a
> discussion on
> 
>   a) Deployment issues: Would a separate Multicast LMA be a feasible
> deployment path
>      that is preferred over multicast traffic arriving through standard
> LMAs for unicast?
> 
>   b) Scalability issues: What is the more severe scalability concern,
> many MAGs being
>      served by a single LMA (tunnel convergence problem at the LMA), or
> many LMAs serving
>      a single MAG (tunnel convergence problem at the MAG)?
> 
> Thanks for bringing this up!
[Guang-JC] We will be very glad to discuss more with the group in Hiroshima!

> 
> Thomas
> 
> Lu, Guang wrote:
> > Hello all,
> >
> > Below you will find some more information about our draft:
> > http://tools.ietf.org/html/draft-zuniga-multimob-smspmip-00
> >
> > We will be glad to present this proposal at the meeting, and please
> let
> > us know if you have any questions or comments.
> >
> >
> > [Summary]
> > The draft discusses how multicast services and mobility can be
> supported
> > using the current Proxy Mobile IPv6, IGMP/MLD protocols. The draft
> > consists of three parts:
> > *	First, the draft describes scenarios to initiate multicast
> > services, and inter-MAG mobility using one LMA
> > *	Second, the draft proposes an improved multicast support using a
> > dedicated LMA for multicast services
> > *	Third, the draft discusses enhanced multicast mobility support
> > utilizing handover triggers
> >
> > Pros:
> > The draft covers both the basic and improved solutions using the
> current
> > protocols.
> > The basic multicast support (section 3) can work independently as a
> > solution.
> > The use of dedicated multicast LMA (section 4) solves the issue of
> > duplicate subscription and multicast traffic redundancy.
> > In addition, the draft discusses various methods to enhance multicast
> > mobility and MLD/IGMP (section 5&6).
> >
> > Cons:
> > Enhanced mobility depends on the availability of handover triggers,
> and
> > exchange of information between PMIPv6 nodes.
> >
> > [What is the additional functionality required of MAGs and LMAs]
> > MAG is the multicast proxy, and LMA as multicast router (or proxy),
> as
> > defined in RFC 4605.
> >
> > [Bandwidth usage]
> > The proposed dedicated multicast LMA approach can largely reduce
> traffic
> > redundancy and bandwidth usage.
> >
> > [MTU, with various tunneling techniques, MTU may be an issue]
> > The draft does not affect the MTU issue.
> >
> > [Handover]
> > The draft discusses how multicast mobility can be supported for
> > inter-MAG handover, using procedures defined in PMIPv6.
> >
> >
> > Best regards,
> >
> > Guang and Juan Carlos
> >
> >
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Stig Venaas
> > Sent: Friday, October 16, 2009 5:11 PM
> > To: [e-mail]
> > Subject: [multimob] Comparing the proposals for basic multicast
> support
> >
> > I think we need to get some discussion started on the various
> > proposals for basic multicast support. Basically the proposals
> > that are aimed at fulfilling our first charter milestone:
> >
> >      Nov 2009 - Initial version of a document explaining the use
> >      of multicast in PMIPv6
> >
> > Here is what I would like to see from people that are submitting
> > proposals they believe are candidates for this milestone.
> >
> > o You should request a slot and present it in Hiroshima. If there
> >    are drafts where none of the authors can be present, please let
> >    us know. To request a slot, email Behcet and me.
> >
> > o Please soon send an email to the list summarising your proposal,
> >    and its pros and cons.
> >
> > When describing the proposal, I think it could be interesting
> > to hear how it deals with some of the following points:
> >
> > o What is the additional functionality required of MAGs and LMAs
> >
> > o Bandwidth usage (e.g. if multiple nodes join the same groups)
> >
> > o MTU, with various tunneling techniques, MTU may be an issue
> >
> > o Handover, within a MAG, between MAGs
> >
> > o Can a MN source multicast? (I'm not sure whether this is a
> >    requirement, but nice to have IMO)
> >
> > I guess there are other points I haven't thought of. I would
> > be interested to hear what else.
> >
> > I hope by doing this, we can get some data points to better
> > compare the proposals, and get some good discussion started
> > before we meet in Hiroshima.
> >
> > Stig
> >
> > _______________________________________________
> > multimob mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/multimob
> > _______________________________________________
> > multimob mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/multimob
> 
> --
> 
> 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: [phone]-
> 8452 °
> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone]-
> 8409 °