Subject: Re: [mobile-ip] Handover Smoothing - What to Do?

From: James Kempf <[email-masked]>
Date: Thu, 26 Jul 2001 18:28:09 -0700 (PDT)

Hi Rajeev,

>
>By dual contexts I didn't mean the two are simultaneously active. However, that 
is a
>separate problem.
>Indeed, I mentioned that only the old-AR has the up-to-date uplink context.
>

OK, now I understand. You are thinking of the uplink context.

I agree that the uplink context will have to be break before make.

Sorry for being so dense.

>Even if you can get the semantics right (i.e, make sure that the route entry is 
ok
>since you are bicasting to an old IP address), the switch of contexts when the 
MN joins
>the new-AR is not automatic. As I said previously, some fields change, e.g., 
Hop Limit,
>TC. And then there are tunneling extensions to consider. So, the state that the
>new-AR has is not the same as old-AR and this affects the corresponding state 
in the
>MN. This means when the MN shows up at new-AR, the state that new-AR has is not
>consistent wrt that of the MN's.
>

If you do IP in IP, why would the header change? The point is to
put the pristine, incoming packet into the tunnel, then pop it out
on the other end, without adding anything.

>We have identified the fields necessary to have the state consistent and 
proposed
>extensions in our recent draft (draft-koodli-seamoby-hc-relocate-01.txt). Your 
comments
>would be appreciated.

OK, I'll take a look.

>[If you do CT after the old-AR stops forwarding packets to MN, then you could 
have
>consistent state in both uplink and downlink with the extensions. ]
>

Right, that seems to be the best bet. MN disappears from old link, old AR
transfers context to new AR, MN reappears and starts sending packets,
new AR uses transferred context to compress/decompress.

Unless you could figure out some way to get the compression context
reinitialized quickly.

Or put the compressed packets into the tunnel on old AR, so the
context wouldn't have to be transferred.

>Actually, we have defined a "New-IP-Address" extension that a MN sends right 
after it
>attaches to the new-AR. [In FMIPv6, the new CoA acquisition happens before the 
MN
>attaches to the new-AR.] This would be an extension to a compressed rohc packet 
that
>updates the state at the new-AR. Note that there is a framework defined in 
rohc-rtp
>draft (now an RFC) to carry extensions.
>

I am really skeptical of the MN doing any signalling over the air when it
gets to new AR on 3G-like links. I frankly don't think there will be time for
all the stuff in the FMIPv6 draft (FBU,FBACK, etc.) if there is
a 6-8 kbps real time stream coming at the mobile and the uplink 
is 9.6 kbps. To say nothing of additional extensions. Hence
the BETH proposal. 

I think there needs to be an option in fast handover where there
is absolutely no L3 signalling between the MN and network, for
those cases where the radio uplink is slow and the incoming data
stream is about using up the uplink capacity.

		jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 27 Jul 2001 09:47:05 -0700

James Kempf wrote:

Hello James,

> is 9.6 kbps. To say nothing of additional extensions. Hence

I agree that it can be "customized". The reason for keeping the control to the MN
is a) it is a general-purpose solution, b) you never know if the MN will actuall
use the new IP address for sure until the MN actually arrives at the new-AR, and c)
this extension would fit right into the existing [rohc] framework so that no
modifications to the compression method on the MN is necessary.

Perhaps in the next revision, we will define how to optimize the signaling while
also taking the above reasons (esp c)) into account.

Regards,

-Rajeev