Subject: [multimob] FW: comments on the BOF proposal

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Oct 2007 08:23:38 +0300

This is one of the comments we've received in a directorate
review of the BOF proposal:

> Currently the BOF seems to be about creating a generic work basket of
> multicast + mobility enhancements for various situations, and I
> predict that most people would only be interested in a subset of WG
> products which might pose a few management challenges.  Before work
> would be chartered I suppose some focusing would be needed.
>
> "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).
>
> "- 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).
>
> As such I would be comfortable with this direction of work only if
> modifications at the multicast source were explicitly out of scope.
>
> "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.
>
> 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.
>
> [1]
> http://tools.ietf.org/html/draft-ietf-magma-msnip-05

Thoughts, responses?

Jari

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

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 01 Oct 2007 09:21:42 +0200

Hi,

please see comments inline:

>> together (e.g., I'd be interested in working with fast leave/join but
At first, the prerequisites should be revised: The statement "In mobile 
envorinments, the link is point-to-point." is not generally valid.

Fast join/leave extensions of IGMPv3/MLDv2 tend to raise debates - so 
there might be demands to clarify/document/work out protocol enhancements.

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.

>> from source to MNs is even less scalable than today).

There is an emerging problem statement from IRTF/mobopts, which 
discusses these subjects:
http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps

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.

>> modifications at the multicast source were explicitly out of scope.

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?

Nevertheless you are right: A working group dealing with receiver 
mobility, only, is unaffected by any of these issues.

>> changes to multicast routing protocols.

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.

>> related) multicast routers and multicast routing protocols are out of

:-) This will steer work within the realm of deployability.

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.

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