[MEXT] simultaneous mobility

["Dr. Daniel Wong" <daniel_wong at ieee.org>]

dear folks

Just a follow-up on our draft "Simultaneous Mobility: Problem Statement" that was briefly presented at IETF 71.

In case you did not get a chance to write down the URLs from the first slide, here they are:

original draft: http://www.ietf.org/internet-drafts/draft-wong-mext-simultaneous-ps-00.txt 
updated draft (March 12) after receiving comments from MEXT mailing list: http://www.argreenhouse.com/IETF/draft-wong-mext-simultaneous-ps-00e.txt
we have also put the presentation slides on the web site: http://www.argreenhouse.com/IETF/wong-dutta-mext-ietf71.ppt 

Thanks to those who provided feedback during the presentation. In particular, two issues which we would like to address are:

a) it was pointed out that the problem has been raised before, and a solution (for simultaneous mobility plus other problems) was proposed, called BUB, a few years ago. thanks for pointing this out. We have taken a look at the BUB draft, and find it very interesting. However, it presents quite a big change, involving the addition of a 3rd mode of operation for Mobile IPv6 (the first and second being "bidirectional tunneling" and "route optimization"), whereas we believe it may also be possible to make Mobile IPv6 more robust to the occurrence of simultaneous mobility through the introduction of minor changes rather than big changes. Hence, we think that if the problem statement can be agreed upon, then a range of possible solutions can be explored. Furthermore, with BUB, as with RFC 3775, control messages go through the home agents, which only reduces the occurrence of the simultaneous mobility problem (but doesn't eliminate the problem, as discussed in the updated draft and as shown in the flow diagrams in the ppt slides).

b) it was suggested that it is not a problem when route optimization signaling is lost, because it will then fall back to bidirectional tunneling. However, once the communication session has been started and route optimization is in use, there is no mechanism specified in RFC 3775 to fall back to bidirectional tunneling (I'll let Ashutosh comment more on this point). Perhaps the introduction of such a fallback mechanism could be considered a candidate solution.

thanks
Daniel

-- 
Dr. Daniel Wong
Assistant Professor
Malaysia University of Science and Technology
** check out my book on wireless IP at http://www.must.edu.my/~dwong/book.html **
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext