Subject: [multimob] Re: FW: comments on the BOF proposal (Tony)

From: "Tony" <[email-masked]>
Date: Fri, 5 Oct 2007 22:18:25 +0800

Hi everyone

>Jari Arkko wrote:
>
>>> "IGMPv3/MLDv2 is originally defined for wired networks with shared
>>> links. In mobile envorinments, the link is point-to-point. Also mobile
>>> nodes have to save battery by entering into the dormant mode. Dormant
>>> mode operation needs to be supported. There are also concerns related
>>> to the latency of joins and leaves that IGMPv3/MLDv2 provides. The
>>> latency needs to be minimized. In Multimob these issues will be
>>> addressed and IGMPv3/MLDv2 for mobile environments will be standardized."
>>>
>>> So what is being proposed here?  Documenting already
>>> implemented/deployed fast join/fast leave extensions?  Increasing the
>>> timer values to support dormant mode?  The first item is not mobility
>>> specific and the fate of these two solutions should not be tied
>>> together (e.g., I'd be interested in working with fast leave/join but
>>> not dormant mode stuff).
>>>
>[Thomas] At first, the prerequisites should be revised: The statement "In mobile 
>envorinments, the link is point-to-point." is not generally valid.
>
>[Thomas] Fast join/leave extensions of IGMPv3/MLDv2 tend to raise debates - so 
>there might be demands to clarify/document/work out protocol enhancements.
>
>[Thomas] As for the dormant mode: I guess the timescales of IGMPv3/MLDv2 and 
>dormant mode invocation at mobile devices are quite distinct - so I have 
>doubts about relevant issues here.

I think the key point of IGMPv3/MLDv2 in mobile envorinments is the transfer of 
multicast states for mobile subscribers (receivers or sources). The current IGMPv3/
MLDv2 is link-local, and these messages can not be transmitted to the other subnets 
when MN moves. Perhaps, we need to make some change to support mobile subscribers.
>
>>> "- In route optimization (RO) mode, a mobile node can communicate
>>> directly with the corresponding node (CN) without going through its
>>> home agent. RO mode establisment with the multicast source node as CN
>>> will be investigated. A problem statement will first be developed and
>>> any solution space possibilities will be explored and the solution
>>> will be standardized."
>>>
>>> I don't understand how this applies.  The current BOF proposal
>>> restricts itself to receiver mobility.  However, multicast sources
>>> just send out their data, they have no knowledge of receivers. Adding
>>> such knowledge goes against this principle (there has been one attempt
>>> in the past but it was discontinued due to lack of interest [1]), and
>>> I do not see what the source could do about it (certainly tunneling
>>> from source to MNs is even less scalable than today).
>>>
>
>[Thomas] There is an emerging problem statement from IRTF/mobopts, which 
>discusses these subjects:
>http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps
>
>[Thomas] An immediate transfer of MIPv6 RO to multicast is of course beyond 
>reach. However, there are proposals around that improve multicast source 
>mobility without relying on receiver knowledge.
>

>>> As such I would be comfortable with this direction of work only if
>>> modifications at the multicast source were explicitly out of scope.
>>>
>
>[Thomas] I don't see the evidence of the emphasis here: In an end-to-end 
>signaling scheme, why should a multicast-aware mobility stack not modify 
>sender behavior? If this is handled in a router-agnostic fashion, no 
>fundamental difference to related protocols (e.g., MIPv6) occurs to me?
>
>[Thomas] Nevertheless you are right: A working group dealing with receiver 
>mobility, only, is unaffected by any of these issues.
>
Mobile source is an important issue in mobile multicast, while IMO mobile 
receiver is more important for some applications.

>>> "It is also a goal of the new working group to possibly standardize an
>>> agent based solution to reduce time delay and overhead effort e.g. on
>>> path re-construction. Both traffic and movement characteristic based
>>> and local agent based approaches to deciding on bidirectional
>>> tunnelling or remote subscription will be considered."
>>>
>>> What does 'agent based solution' refer to?  Without prior knowledge of
>>> the work it's not clear, but it doesn't sound good if it would mean
>>> changes to multicast routing protocols.
>>>
>
>[Thomas]Mobile multicast protocols, which are assisted by some sort of 
>mobility-aware route entity, commonly are referred to as "agent based".
>Examples would be extensions to HMIPv6 or FMIPv6, where a MAP or the ARs 
>play the role of "agents". There are many more such agent functions 
>suggested, so one likes to summarize these under one term.

According to the draft: http://ietfreport.isoc.org/all-ids/draft-zhang-multimob-memcast-ps-00.txt
I think anent is referred to the "Multicast forwarder" .

>>> As a general comment about the whole BOF proposal, maybe it would be
>>> best to spell out outright that modifications to (non-mobility
>>> related) multicast routers and multicast routing protocols are out of
>>> scope.
>>>
>
>[Thomas] :-) This will steer work within the realm of deployability.
>
>[Thomas] Conversely, there are tough parts in the mobile multicast regime and to 
>me it would make a lot of sense, if mobility related thinking will be 
>injected into future mcast routing protocol development - bi-dir PIM may 
>be a good starting point here.

Right, the current mobile multicast is only used in the access networks, and it is independent of 
the multicast routing protocols.

>
>?Prof. Dr. Thomas C. Schmidt
>?HAW Hamburg, Dept. Informatik
>?University of Applied Sciences
>?Berliner Tor 7, D 20099 Hamburg
>?Germany, Fon: +49-40-42875-8157
>?http://www.informatik.haw-hamburg.de/~schmidt
>
>
>
>------------------------------
>
>_______________________________________________
>multimob mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/multimob
>
>
>End of multimob Digest, Vol 7, Issue 2
>**************************************

= = = = = = = = = = = = = = = = = = = =
			 
　　　　　　　　Tony
　　　　　　　　[email-masked]
　　　　　　　　　　2007-10-05
 +--------------------------------------+
 |	NGIRC, Beijing JiaoTong University	|
 |	BeiJing, China,100044				|
 |	Http://www.njtu.edu.cn				|
 +--------------------------------------+

_______________________________________________
multimob mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/multimob