Subject: [Mip6] Sending data to CN after handoff?

From: [email-masked]
Date: Sun, 6 Mar 2005 12:04:47 +0100 (CET)

Consider a (wireless) MN communicating with a CN using route
optimization when the MN performs a handoff between APs serving
different IP subnets.

After the MN has detected that it has moved to a new subnet and acquired
a new IPv6 address, what additional message exchanges is it required
to conduct before it can send data towards the CN again? I have tried
to find the answer in RFC 3775, but it is still unclear to me.

To support the discussion I give some different scenarios below.
Which would be possible?
Which (if any) is likely to be utilized is most implementations?
Is there any other scenario not stated here which is to prefer?

>From a handoff performance perspective I would prefer scenario "A".
Any comments are welcome!

* A: Care-of Test and Binding update to CN
  The data flow from the MN to CN would be blocked for a single MN/CN
  round-trip. Data is sent immediately after a BU has been sent to the
  CN. The BU to the CN is sent before (or in parallell with) the BU to
  the HA. The MN has a valid "Home Keygen token" since before.

  1. Send CoTi to CN
  2. Receive CoT from CN with new "Care-of Keygen token".
  3. Form new Kbm and send BU to CN
     BAck not requested in BU (or requested but not waited for)
     Update binding update list in MN
     Resume data transmission towards the CN
  BU to HA send after or in parallell with the message exchange above.

* B: Waiting for BAck from CN
  This case would be similar to the "Fast" approach above, but the MN
  would request and wait for a BAck to be received from the CN before
  updating its "binding update list" and resume data transmission.
  The data flow from the MN to the CN will be blocked during two MN/CN
  round-trips.

  1. Send CoTi to CN
  2. Receive CoT from CN with new "Care-of Keygen token".
  3. Form new Kbm and send BU to CN
     BAck requested in BU
  4. Receive BAck from CN
     Update binding update list in MN
     Resume data transmission towards the CN
  BU to HA send after or in parallell with the message exchange above.

* C: BU to HA first, but no "home address test"
  In this scenario the MN will first perform a BU/BAck exchange with
  the HA before sending the CoTi. As before the MN is assumed to make
  use of an existing "home keygen token" and does not wait for a new
  HoTi/HoT exchange to form the Kbm. IPSec SAs for the BU/BAck
  exchange with the HA is assumed to exist (no IKE exchange required
  here).
  The data flow from the MN to the CN will be blocked during one MN/HA
  round-trip and one or two MN/CN round-trips if scenario "A" or "B"
  is used after the initial BU/Back exchange. ("B" is shown below)

  1. Send BU to HA
  2. Receive BAck from HA
  3. Send CoTi to CN
  4. Receive CoT from CN with new "Care-of Keygen token".
  5. Form new Kbm and send BU to CN
     BAck requested in BU
  6. Receive BAck from CN
     Update binding update list in MN
     Resume data transmission towards the CN

* D: BU to HA first, and "full" return-routability test
  Although the MN is assumed to have a valid "home keygen token" it
  decides to do a HoTi/HoT exchange to form the new Kbm in this
  scenario.
  Assuming that the HoTi/HoT exchange will take more time than the
  CoTi/CoT exchange. The data flow from the MN to the CN will be
  blocked during one MN/HA/CN round-trip and one or two MN/CN
  round-trips if scenario "A" or "B" is used after the initial BU/Back
  exchange. ("B" is shown below)

  1. Send BU to HA
  2. Receive BAck from HA
  3. Send HoTi to CN via HA
     Send CoTi to CN
  4. Receive CoT from CN with new "Care-of Keygen token".
     Receive HoT from CN with new "Home Keygen token".
  5. Form new Kbm and send BU to CN
     BAck requested in BU
  6. Receive BAck from CN
     Update binding update list in MN
     Resume data transmission towards the CN

BW J-O

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

---

From: Jari Arkko <[email-masked]>
Date: Sun, 06 Mar 2005 15:12:45 +0200

What exact additional messages are required depends on
the situation you have, e.g., whether or not you have a
sufficiently fresh home keygen token available. In
addition, RFC 3775 allows freedom for implementations
to choose how aggressive or optimistic they are. I believe
its a requirement that you have to do your home registration
first so your scenarios A and B don't appear correct.
C and D are correct, but as far as I remember there is
no requirement to wait for the home registration to
complete, so you can essentially do the COTI exchange
in parallel with the home registration. So I think the
most optimal and optimistic scenario you can legally
do is

     1a. SEND BU to HA
     1b. Start sending packets via HA (if needed)
     1c. SEND COTI to CN
     2a. RECEIVE BA from HA
     2b. RECEIVE COT from CN
     3a. SEND BU to CN
     3b. Start sending packets to CN

     1 RTT before you can send packets directly to CN

(Assumes all RTTs are equal and that a home keygen token
already exists. And note that the RTT counts are different
from the point of view of the CN; the CN has to wait for 1.5
RTT before it can send packets directly to the MN.)

If you don't have a home keygen token, then we need

     1a. SEND BU to HA
     1b. Start sending packets via HA (if needed)
     1c. SEND COTI to CN
     1d. SEND HOTI to CN
     2a. RECEIVE BA from HA
     2b. RECEIVE COT from CN
     2c. RECEIVE HOT from CN
     3a. SEND BU to CN
     3b. Start sending packets to CN

     1 RTT before you can send packets directly to CN

Both of these flows are optimistic in several ways, however.
They don't wait for BAs from the CN; if the BU is lost you
will notice this only later in the form of errors sent by the
CN from your packets. Similarly, if the home registration
BU is lost your HOTI transmission may be lost, or if the
BU and the HOTI are re-ordered you have the same problem;
generally you can deal with all these issues using retranmission
and recovery procedures related to losing CN's state. Even
if you weren't optimistic you'd still have to prepare for some
messages to be lost so this is nothing new in itself. But these
procedures are perhaps more sensitive to loss of messages,
i.e., the damage is greater if something happened.

--Jari

---

From: [email-masked]
Date: Mon, 7 Mar 2005 10:03:55 +0100 (CET)

First, thanks for a great reply!

> RTT before it can send packets directly to the MN.)

Ok, thus the gap perceived by the MN for traffic from the CN
will be 2RTT, unless it is able to (somehow) receive the
packets in-flight towards its previous CoA at the time
the COTI is sent, right?

> i.e., the damage is greater if something happened.

Using an "optimistic" approach would be fine with me since I am
mostly interested in interactive real-time traffic such as voice.
Thus, in my case I do not mind if the data packets would be
dropped due to a possible loss of a BU packet to the HA or CN,
since the alternative would be to buffer them at the MN, which
likely would cause an unacceptable end-to-end delay where the
packets finally would be dropped by the receiver (CN) anyway.

Yet, I can imagine that most MIPv6 implementors rather(?) design
for robustness and simplicity (i.e., wait for BAcks from CN
and/or HA before sending user data) than using the optimistic
approaches discussed here, which would optimize real-time traffic
handoff support.
Or would they perhaps be willing to add an API where real-time
applications could ask for "optimistic" handover support and
bulk-data (or other) applications could be given a more
"conservative" handover mechanism?
(I'm sorry if this is getting a bit out of scope for this
mailing-list.)

BW J-O

---

From: Jari Arkko <[email-masked]>
Date: Mon, 07 Mar 2005 12:28:27 +0200

>packets in-flight towards its previous CoA at the time
Yes.

>packets finally would be dropped by the receiver (CN) anyway.
Yes. In an optimistic implementation you lose less time
but take a risk about losing a bigger number of data
packets. The question is how fast you will be able to
detect that the signaling packets were lost.

>approaches discussed here, which would optimize real-time traffic
Perhaps. OTOH, there's a lot of interest in various
optimizations of Mobile IPv6, so looks like many people
do care about the efficiency.

>"conservative" handover mechanism?
That might be a good idea!

>(I'm sorry if this is getting a bit out of scope for this
This stuff was discussed a bit in draft-irtf-mobopts-ro-enhancements-00.txt
too, MOBOPTS might be another discussion forum. In fact, the draft
stated that some simulations/measurements in this space would be
useful to find out what the real effects of optimistic behaviour are.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Wed, 9 Mar 2005 12:33:52 -0800

I don't think there is anything in RFC 3775 that would prohibit the MN from
sending packets through the HA after the HA Binding Update completed, even
if route optimization is in effect. The MN's traffic would experience
additional RTT latency of course, but it would avoid having to wait for the
RR to complete, which could cause dropped packets. Once the RR completes,
the MN could start sending packets directly (and if the RR fails, the MN's
traffic continues being delivered).

            jak

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Sunday, March 06, 2005 3:04 AM
Subject: [Mip6] Sending data to CN after handoff?

  1. Send CoTi to CN

  1. Send CoTi to CN

  1. Send BU to HA
  2. Receive BAck from HA
  3. Send CoTi to CN

  1. Send BU to HA
  2. Receive BAck from HA

BW J-O

---

From: Sachin D <[email-masked]>
Date: Tue, 15 Mar 2005 12:18:31 +0530

Hi All,

In RFC 3775 while calculating checksum it says

Section 10.3
"      The pseudo-header contains IPv6 header fields, as specified in
      Section 8.1 of RFC 2460 [11].  The Next Header value used in the
      pseudo-header is 2.  
"

So can someone kindly clarify why 2 is used in next header instead of 135
(MH Header ), is this some typo or some reason is there for having 2 as next
header

Regards
Sachin

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Mar 2005 09:04:41 +0200

Yes, its a known typo. Should be 135.

--Jari