Re: [multimob] Comparing the proposals: draft-schmidt-multimob-pmipv6-mcast-deployment

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

Dear Stig & all,

thanks for stimulating a discussion to meet essential key points. We are 
happy to catch your trigger and provide the info for our draft 
http://www.ietf.org/id/draft-schmidt-multimob-pmipv6-mcast-deployment-02.txt 


[Proposal Summary:]

Objective and guideline of this proposal is the deployment of multicast 
on PMIPv6 domains with the help of standardized protocols and functions, 
only. No new messages, entities or functions have been defined in this 
draft.
The key step is to deploy MLD proxy instances on MAGs for each LMA-MAG 
tunnel uplink. Then MAG acts as a proxy and LMA as a standard multicast 
querier.

Pros: Multicast service with a good deal of traffic aggregation can be 
achieved by using standardized solutions.

Cons: Traffic need not be fully optimized. It may happen that a MAG 
receives duplicated multicast data from different LMAs, as well as 
transmit duplicate streams down the wireless links. There is no path to 
multicast reception without an LMA, as standard PMIPv6 traffic streams 
are bound to LMA-MAG tunnels.

[Bandwidths usage:]

Depending on their association to LMAs, multiple MNs may receive the 
same multicast stream, or may initiate redundant forwarding via distinct 
LMAs.

[MTU-Size:]

As data is transmitted via LMA-MAG tunnels, MTU-size issues may arise 
according to tunnel MTU-sizes. For a discussion on the MTU-size issues 
we refer to the problem statement: 
http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps

[Handovers:]

Handover operations remain in full analogy to standard PMIPv6 (use same 
tunnel and binding states), so the performance of unicast should equally 
apply to the multicast case.

[Multicast source support:]

There is no explicit support for mobile multicast sources - this was out 
of scope from the charter. There will be easy ways to extend the 
solution to sender mobility (and we can add a remark on that), but with 
the charter in mind, we concentrated on multicast receivers ;)

[Additional Point: Link Model]

PMIPv6 is currently bound to a point-to-point link model, which is 
actually not very advantageous for group communication. The draft 
discussed here (in its current version 2) eliminated the addiction to 
the point-to-point link model. It equally applies to shared links, once 
the PMIPv6 spec extends to a larger domain of wireless technologies.

That's our contribution in brief - we'll be very grateful for input that 
helps to improve the document!

Thomas


Stig Venaas wrote:
> 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