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

From: James Kempf <[email-masked]>
Date: Thu, 26 Jul 2001 15:12:08 -0700

Rajeev,

I don't understand why there needs to be dual contexts at the MN. In the
single interface case, the MN is only connected to one AP/AR at a time.
And, it is sequentially connected to oAR then nAR, unless a ping-pong
occurs.

So if CT is available,  oAR simply sends the compression context to
nAR when the bicast stream is started, then runs the compression algorithm
until MN shows up and it can start getting packets. The compressor
context on MN just keeps working,  since the CT causes the state
on the nAR side to start out the same as on the  oAR. The MN drops
the old L2 bicast leg when it aquires the new L2 leg through nAR.

Last time I talked  with the ROHC guys (at IETF 50), they seemed OK with
this. The fact that MIPv6 changes CoA after handover was giving them
more heartburn, but that won't be a  problem until  the MN actually
completes new CoA aquisition. Before that the packets should be
coming with the old CoA either from the oAR (if you are using the tunnelling
approach) or from the remote agent (if you are using the simultaneous bindings
approach).

Regarding if bicasting should be part of FMIPv6, I agree that it should be separated
out until we have a better understanding of the issues. The tougher issue 
(and the one I think we are debating) is whether we should make the low latency
MIPv4 spec consistent by also separating it out. I am in favor of consistency,
perhaps as a consequence of my long Germanic ancestory (== a genetic predisposition
towards liking things orderly as opposed to chaotic). 

		jak

>James,
>
>Could you be more specific ? I mentioned that the new-AR *could* do it if it
>got the context (e.g., via CT). But that's not it. It means dual contexts at
>the MN for downlink. And, synchronization issue for uplink contexts (since
>the MN is communicating with old-AR).
>
>Again, here is the point: these are the issues surrounding how to get
>bicasting to work with FMIPv6. This MUST NOT be part of FMIPv6. More
>generally, FMIPv6 must not depend on a particular smoothing technique.
>
>I hope you understand and agree as well!
>
>Regards,
>
>-Rajeev
>
>
>James Kempf wrote:
>
>> Right, having the new AR compress was what I had in mind.
>>
>>                 jak
>>
>> >Gary Kenward writes:
>> > > Rajeev:
>> > >
>> > >   Is one answer that the old AR could send uncompressed packets
>> > > to the new AR, and the new AR would then compress the packets or
>> > > not, depending on whether it had the context (there is a an case
>> > > to be made here for proactive ct ;^}). Depending on what was actually
>> > > sent over the air, this could create a tricky problem to solve
>> > > at the MN, as it may need to process the two streams before it could
>> > > even attempt duplicate removal, and this would require two compression
>> > > state machines, buffers, etc., etc. Not nice.
>> >
>> >   It may not be nice, but I believe it comes with the
>> >   territory. The alternative is to miss packets during
>> >   the transition that you might have otherwise been
>> >   able to recover. For mobile initiated
>> >   break-before-make scenarios, you obviously
>> >   don't want to allow any otherwise valid packets
>> >   to be dropped making the situation worse.
>> >
>> >                Mike
>

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 26 Jul 2001 16:42:39 -0700

Hello James,

> the old L2 bicast leg when it aquires the new L2 leg through nAR.

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.

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.

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.
[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. ]

> approach) or from the remote agent (if you are using the simultaneous bindings

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.

> towards liking things orderly as opposed to chaotic).

Good that we agree regarding separating out bicasting. I would also support it for
FMIPv4.
Consistency will good! (even though my roots sometimes force me to seek order in
chaos!)

Regards,

-Rajeev