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

Dear Stig & multimob folks,

Thanks for giving the chance to describe our solution as some key points.

I provide the information for our draft http://tools.ietf.org/html/draft-
sijeon-multimob-mms-pmip6-00

Core solution is not changed. But, as soon as, I will upload -01 version
draft describing more detailed than -00 version.

But, for the multimob folks, I want to respond as request first.

1. [Proposal Summary]
 : Our solution is based on local routing scenario in
http://tools.ietf.org/html/draft-deng-multimob-pmip6-requirement-02.
   PMIPv6 multicasting service can be provided by LMA using tunneling
technique. It means that LMA has multicast routing function.
   It is useful and basic solution. However, it may introduce some
optimization problem (i.e., tunnel convergence, ..) and unpredictable
exception.

   For more simple structure and implementation, I propose that a MAG that
having IGMP/MLD forwarding proxy 
   function is connected to the multicast router. So, it does not tunnel
mechanism and can avoid tunnel convergence problem.
   And also, it can avoid unpredictable exception by not using bi-
directional tunnel with LMA.

   To reduce handover latency due to IGMP/MLD action after MN's handoff, we
propose context transfer between MAG-to-MAG 
   for pre-reporting to multicast router. (RFC 5213 also assumes context
transfer mechanism for inter-technology handoff.)

   In the perspective of operators, we think that it would be appropriate
solution.

2. [Bandwidth Usage]
 : A LMA is not involved with multicasting action because a MAG is directly
connected to multicast router.
   So, the MAG does not receive duplicate and redundant packets.

3. [MTU size]
 : We do not use tunneling techniques. So, MTU issue may be not happen.

4. [Multicast Source Support]
 : Explicitly, I do not consider multicast source support. However, 
   And our solution is related to remote-subscription

5. [Tunnel Convergence]
 : A MAG is connected to only one multicast router. So, it can avoid the
tunnel convergence problem.

Thanks for careful reading.

I am quite open comments of multimob friends.

Best Regards,

Seil Jeon

-----Original Message-----
From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On
Behalf Of Stig Venaas
Sent: Saturday, October 17, 2009 6:11 AM
To: multimob@ietf.org
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
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob