Subject: [MEXT] simultaneous mobility

From: "Dr. Daniel Wong" <[email-masked]>
Date: Thu, 27 Mar 2008 15:46:58 +0800

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
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: marcelo bagnulo <[email-masked]>
Date: Thu, 27 Mar 2008 09:35:15 +0100

> 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.
>
FWIW, imho this is how i would expect RFC3775 should behave, so imho 
this is simply something that was not fully specified in rfc3775.
I would treat it as an update in rfc3775bis

regards, marcelo

> http://www.must.edu.my/~dwong/book.html 
> <http://www.must.edu.my/%7Edwong/book.html> **
> ------------------------------------------------------------------------
>

---

From: Ashutosh Dutta <[email-masked]>
Date: Fri, 28 Mar 2008 16:50:27 -0400

Marcelo,
         As per your suggestion and brief discussion during IETF 
meeting, I looked at RFC 3775. However, I have not seen anywhere about 
the fall back option if the mobile is already operating in RO mode. 
Section 11.8 in RFC 3775 discusses about the re-transmission of Care-of 
Test Init messages and Binding Update that may go on indefinitely.

"The retransmissions by the mobile node MUST use an exponential back-
off process in which the timeout period is doubled upon each
retransmission, until either the node receives a response or the
timeout period reaches the value MAX_BINDACK_TIMEOUT.  The mobile
node MAY continue to send these messages at this slower rate
indefinitely."

However, if the retransmission goes on for indefinitely due to 
simultaneous mobility and there is no fall back option, it might affect 
the real-time communication because of the delayed RO. Thus, we will 
probably need to find some solution either by specifying it as part of 
RFC 3775bis or some other solution.

It would be good to have some discussion on how to take care of this 
specific problem.

Regards
Ashutosh

---

From: marcelo bagnulo <[email-masked]>
Date: Sat, 29 Mar 2008 10:02:37 +0100

Hi Ashutosh,

i would suggest you to suggest what text need to be changed in rfc3775 
to solve this issue and send it to the list so people can comment

regards, marcelo

Ashutosh Dutta escribió:
> Section 11.8 in RFC 3775 discusses about the re-transmission of 
> Care-of Test Init messages and Binding Update that may go on 
> indefinitely.
>
> simultaneous mobility and there is no fall back option, it might 
> affect the real-time communication because of the delayed RO. Thus, we 
> will probably need to find some solution either by specifying it as 
> part of RFC 3775bis or some other solution.
>