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

From: "Romdhani, Imed" <[email-masked]>
Date: Fri, 5 Oct 2007 16:09:58 +0100

Dear All,

Please see my comments bellow. They are preceded by "[Imed]": 
 
>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.

[Tony]: 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.

[Imed]: The current specification of Mobile IP and especially MIPv6 (RFC3775) states in Sections 10.4.3 and 11.3.4 that every home agent should support the multicast group membership control protocols. In addition, in order to obtain the mobile node's current multicast group membership the home agent must periodically transmit MLD Query messages through the tunnel to the mobile node (MN). This means that the home agent could be a capable multicast router with Querying feature or an MLD proxy. The MLD packets between the mobile node and the home agent are encapsulated within the same tunnel header used for other packet flows (i.e. unicast) between the mobile node and home agent.

The problems that rise here are: (1) the periodicity of MLD Query messages and (2) the response delay experienced by an MN to renew his membership after the handover while it is away. In other words, periodic transmission seems to be power consuming for an MN as only a single and unique MN is targeted at the tunnel end-point. Periodic transmission is designed to broadcast link-local MLD queries where the number of potential receivers is unknown. The second problem is inherited from the fact that an MN should register first its CoA and also wait an MLD query message to be received from his home agent before being authorised to send back his MLD report message. I do believe that it will be more reasonable to remove the second condition and allow an MN to send its BU and an MDL report messages simultaneously without waiting for an MLD query to be sent by the home agent after each handover. The home agent could maintain a state that indicates that the MN has already received at least one MLD query independently of its handover instances.

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

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

[Imed] I do agree with Thomas. The impact of source mobility could affect the efficiency of some routing protocols. For instance, when a source is mobile and it sends traffic to many-to-many multicast group, multicast designated forwarders have to be aware of its mobility to update the forwarding entries in their routing tables and if necessary update the access lists to allow a continuous transmission of multicast traffic after each handover completion.

>
>?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				|
 +--------------------------------------+

This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the 
University's system is subject to routine monitoring and filtering by the University. 

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

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 05 Oct 2007 20:28:10 +0200

Dear Imed et all,

please see comments inline.

> [Tony]: 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 t…
[Thomas] IGMPv3/MLDv2 is not used at sources.

> The problems that rise here are: (1) the periodicity of MLD Query messages and (2) the response delay experienced by an MN to renew his membership after the handover while it is away. In other words, periodic transmission seems to be power consuming for an MN as only a single and unique MN is targeted at the tunnel end-point. Periodic transmission is designed to broadcast link-local MLD queries where the number of potential receivers is unknown. The second problem is inherited from the fact that an MN should register first its CoA and also wait an MLD query message to be received from his home agent before being authorised to send back his MLD report message. I do believe that it will be more reasonable to remove the second condition and allow an MN to send its BU and an MDL report messages simultaneously without waiting for an MLD query to be sent by the home agent after each handover. The home agent could maintain a state that indicates that the MN has already received a
t l
>  east one MLD query independently of its handover instances.
> 
[Thomas] You are referring to bi-directional tunneling through the HA, 
here. In this case, and in other tunneling scenarios, e.g., HMIPv6, we 
indeed have a point-to-point link and MLD queries by routers are an 
effort redundant to MIPv6 binding management (except for lost MLD 
listener reports).

How do you conclude that MLD Joins are only allowed in response to 
membership queries?
RFC 3775 states in section 10.4.3 "These [MLD listener report] messages 
are issued whenever the mobile node decides to enable reception of 
packets for a multicast group or in response to an MLD Query from the 
home agent." - which seems perfectly reasonable to me and does not imply 
any such restriction ??

As for the sequential signaling (BU -> BACK -> JOIN/MLD): this may be 
easily resolved by piggybacking the BU, I guess.

> [Imed] I do agree with Thomas. The impact of source mobility could affect the efficiency of some routing protocols. For instance, when a source is mobile and it sends traffic to many-to-many multic…

[Thomas] You are referring to Source Specific Multicast here. Yes, I 
agree. In any approach, which is not equivalent to bi-directional 
tunneling, unmodified SSM source filters will prevent packet forwarding 
down an established distribution tree when CoA's change.

Best wishes,

thomas

-- 

° 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