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

["Thomas C. Schmidt" <[e-mail]>]

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.
Does Figure 3 omit MLD queries, as well? If not, why should a MN send an 
MLD report subsequent to re-attachment?
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.

   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].

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.

  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.).
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.

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!

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] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °