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

From: James Kempf <[email-masked]>
Date: Wed, 25 Jul 2001 16:09:48 -0700 (PDT)

Rajeev,

>I would like to add that there are issues surrounding header compression as
>well. Note that the context resides on the old-AR. What type of packet does it
>bicast ? compressed or uncompressed packet ? If it is uncompressed, it is not
>useful without the new-AR having the compression context.

See draft-kenward-seamoby-ct-rohc-reqs-00.txt for how to get that
header compression state to the new AR.

>On the other hand,
>if the new-AR has to possess the context *simultaneously*, this adds a new
>dimension to header compression: Many-to-One header compression! 

I don't follow. If the old AR gets the trigger for context transfer
soon enough, it can send the header compression state to the new
AR. New AR installs it, compresses incoming bicast packet headers.

> If the old-AR
>sends compressed packets to the new-AR, how does the latter handle them ?

There has been some talk about handling this, but nobody has
come out with a coherent scheme yet.

>Also, since the MN is not bicasting in the uplink, the uplink context is
>current only on the old-AR even if the new-AR has the context. So, there is a
>synchronization issue as well.
>

I don't follow. What does the MN not bicasting have to do with it? The
MN sends packets either on the old L2 or through new AR on the new
L2. If on the latter, MN must either have a valid CoA  for the new
subnet or new AR must tunnel to old AR. 

		jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 25 Jul 2001 16:35:05 -0700

Hello James,

> header compression state to the new AR.

Thanks. I will take a look.You might also want to look at
draft-koodli-seamoby-hc-relocate-01.txt :-)

> AR. New AR installs it, compresses incoming bicast packet headers.

First, what is this soon enough ? Second, you need special route entry to make
sure that a packet addressed to old-IP address of the MN is properly forwarded.
Third, the some fields do not necessarily remain constant due to processing at
new-AR. What happens to the Hop Limit and perhaps the Traffic Class field ? If
they change, how does the MN's compression engine know about this ?

> come out with a coherent scheme yet.

I also have an idea. Not sure where to specify it. Or is it needed to be specified
at all..

> subnet or new AR must tunnel to old AR.

If there is a context at both the ARs, the uplink context is current only on the
old-AR to which the MN is connected. The MN does not transmit packets to both the
ARs (uplink bicasting) correct ?
Hope this helps.

Anyway, my point is there are (important, hairy) issues to consider when combining
bicasting with compression. I don't want unwanted complexity in implementing
header compression due to bicasting (even if you can specify how to do it)! If you
really want bicasting, propose it as a separate draft.

Regards,

-Rajeev

---

From: Michael Thomas <[email-masked]>
Date: Wed, 25 Jul 2001 16:32:28 -0700 (PDT)

> AR. New AR installs it, compresses incoming bicast packet headers.

   The problem is that you have one ROHC context with two
   packet sources, AR1 and AR2. Sounds like the ROHC context
   needs to be forked (cloned) on MN too, and the MN needs to pay 
   attention to the i/f it came in on for real (which already
   does, I assume).

	   Mike