[Mobopts] Re: Review of Multicast Mobility in MIPv6: Problem Statement

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

Dear Imed,

many thanks for reviewing the draft. Please see comments inline:

Romdhani, Imed wrote:
> 
> I have finished reading your draft and I honestly enjoyed it. It is an 
> extraordinary work.
> 
Thanks for the flowers :-)
> 
> I identified many points that could be useful to enhance this draft.
> 
>  
> 
>  From a structural point of view, it will be interesting to re-structure 
> the whole draft based either on top-down multicast architecture approach 
> or on communication type basis. In the former point of view, the draft 
> could be organised into two main sections:
> 
> ·         One-to-many multicast mobile
> 
> ·         Many-to-many multicast mobile
> 
Mhmm, not sure what you have in mind: this document is concerned with 
the problem of mobility extensions for IP-layer multicast. So the idea 
is to remain close to the established IP-layer multicast architecture 
and take the perspective from the well known.
>  
> 
> The multipoint-to-multipoint issue (many-to-many) is not addressed. 
> However, these kinds of application are promising especially for 
> collaborative work or distributed applications. The main challenges in 
> this case will be mainly related to source identification and 
> authorisation to the multicast delivery tree.
> 
Once again I'm a little unsure what you head at: many-to-many 
communication is inherent to ASM, in SSM it is mainly concerned with the 
distribution of the corresponding 'many' source addresses. The latter, 
though, has not been addressed in the draft as it supposedly resides on 
the application layer (e.g. Web sites, SIP distribution, ...).

There is of course the issue of initially discovering CoA addresses in 
case of a mobile source. You are right, this should be mentinoned, even 
though there has been very little work here ...
>  
> 
> If the draft will be structured based on top-down approach, it could 
> include the impacts of IP mobility on all multicast layers: from session 
> description, session announcement, address allocation, to routing and 
> membership management. While the higher layers issues are not already 
> well defined and poorly addressed in the literature, IP mobility can 
> have many restrictions and new extensions are required to handle mobile 
> devices. For example, the periodicity of announcements could be adapted 
> or stopped to cope with mobility frequencies, the session description 
> could include recommendations for nomadic users (to adapt multimedia 
> coding and framing for example, etc.).
> 
I agree, there are many issues on the application layers related to 
mobility extensions of IP multicast. This may be added in another 
release, but would largely extend the document. E.g., if we look at 
adaptive audio/video coding and its relation to mobility aspects, this 
would open up a whole new affair: As you might be pointing at, the ITU 
video coding people are just about to release a Scalable Video Codec 
(SVC) as an extension to H.264, which is supposed to be capable of 
dynamically adjust frame resolution and rates to operative conditions 
(including network performance). Concerning the SDP, there is work to 
replace SDP ...

Maybe we should just add a section pointing to this work - really 
including relevant details would require extra experts and likely make 
it unreadable for IP-centric people.
>  
> 
> As the solutions are concerned, they could be also summarises into two 
> main sections:
> 
> ·         Improvements of the Mobile IP protocol: this section can cover 
> the enhancement of MN and HA features and functions to handle IP 
> multicast. It will be also interesting to investigate the issues and 
> solutions for NEMO as a Mobile Router is a particular case of MN.
> 
> ·         Improvement and adaptation of the multicast infrastructure: 
> improvement of router behaviour, router discovery, multicast control, 
> multicast membership, etc.
> 
We partly tried to follow this in differentiating approaches, which 
solely modify MIPv6 entities or agents from those, modifying the routing 
protocols ... however, it appears tempting to us to stick in the 
solution section to the structure of the problem section ... hope is to 
make it easier to match problems and approaches.

You are right with NEMO - we skipped this ... and feel unsure about its 
relevance to the draft. There are recent discussions regarding MIPv6 : 
NEMO in the unicast case, though.
>  
> 
> Finally, I believe that this draft has omitted to mention some issue 
> that I would like to summarise in the following points (they could be 
> integrated in Section 4.2):
> 
> ·         Membership issue for mobile parties: the periodicity of 
> IGMP/MLD problem has to be slowed down to prevent extra power and 
> process consumption. Queries are no more broadcasted to ALL-nodes, but 
> encapsulated to specific unicast address (Home subscription approach), 
> therefore the HA is aware that there is a unique member at tunnel 
> end-point.
> 
Yes, this we omitted. Should be subject to an updated version.

> ·         Routing issue: even with the Home Subscription approach, a 
> mobile receiver can still suffer from triangle routing issue especially 
> when the HA is not optimally located. It will be recommended to 
> “relocate” the HA to Edge (boundary) of the home network to forward IP 
> multicast packet before they cross the whole network (from ingress to 
> access levels, and then from access level to egress level)
> 
Yes, Home Subscrition (or bi-directional tunneling, as we call it) 
usually leads to triangular routing. Also, we are aware of some work to 
'multiply' Home Agents, mainly to achieve load balancing and fault 
tolerance.
But you're right, we skipped your proposal to use the multiple HAs for 
agent assisted multicast tree geometry ... it appears somewhat similar 
to the (M)-HMIPv6 approach, probably with the distinction that MAPs are 
'fixed' w.r.t. the local subnet and temporary with the MN, while the HA 
hierarchy is 'fixed' w.r.t. the MN, but only 'near' to the visited subnet.

We should add this in the next version.

> ·         Binding Updates issue: solutions that introduce a notification 
> mechanism using Binding Updates between SSM and mobile receivers broke a 
> basic rule of IP multicast: the source has not to know the exact 
> identity of receivers. In addition, the Return Routability has to be 
> clarified if it is used.
> 
In SSM the issues arising from source filtering have to be somehow 
addressed.  All the approaches we know about do this by either masking 
the CoA or by using some update scheme (Thaler, I believe, was the first 
proposal here). These updates, however, are usually not individually 
directed to multicast group members, i.e. no registration & bookkeeping 
at the source is required, but are done via established multicast trees 
(HA-based control tree by Thaler, SDR by Jelger & Noel, the previous 
delivery tree in the Tree Morphing).

My personal believe is, that return routability cannot be used in the 
multicast case. Multicast secure updates need to be one-way, thus 
requiring cryptographic identifiers (s. work of Gab Montenegro).

But you are right: None of the authors have detailed out such a security 
layer, as far as we know.

> ·         Mobile IPv4 and Mobile IPv6 inherit the same issues except 
> that they are using different architectural entities.
> 
... and except that MIPv6 is capable of the address masking and thereby 
of route optimisation ...
>  
> 
> I will enjoy discussing these points with you. Please feel free to 
> correct me if you believe that I am wrong.
> 
Thanks Imed, same goes for us: the field is a little intricate ... so it 
is worth re-thinking and discussing issues. We still don't know wether 
there is a simple and elegant solution, simultaneous complying to all 
requirements and desires ;)

Cheers,

thomas

> --  
> 
> ° Prof. Dr. Thomas Schmidt
> 
> ° HAW Hamburg, Dept. E & I
> 
> ° University of Applied Sciences
> 
> ° Berliner Tor 7, D 20099 Hamburg
> 
> ° Germany
> 
> ° Fon: [phone]
> 
> ° http://www.informatik.haw-hamburg.de/~schmidt

_______________________________________________
Mobopts mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mobopts