Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)

From: James Kempf <[email-masked]>
Date: Wed, 11 Jul 2001 13:43:51 -0700 (PDT)

Gary,

>Err, no. That's not what I was agreeing to. 
>Once again, proactive ct should be driven by the initiation
>event, not the deadline event. It is preferable that context
>be installed before the traffic arrives at the newAR, but it's
>not a MUST requirement, and it certainly does not dictate that
>ho and ct protocols must be synchronous.
>

I'm not sure I understand. If nAR can't deliver packets unless
the CT is installed, then how can it not be a MUST requirement?
Seems to me, that the completion of the handover is predicated
on CT working.

>And I see no reason for requiring handover signalling to complete
>before ct (MIP may require it, but that's would be a potential 
>MIP weakness, were it true). Even if this is true, it applies only
>to reactive ct, and contradicts the purpose of proactive ct.
>

Right, I didn't say it was a general requirement, I only said
I see it as a requirement for a particular solution. And I don't
necessarily see it as a weakness, if it results in faster handover for MIP.

>You seem to be implying that there is some dire consequence to be
>realized if a ct happens but an ho doesn't. At best, the new AR
>will be holding onto useless context. At worse, the new AR may
>reserve resources that could be used elsewhere. Either situation 
>seems resolvable with some sort of "life timer" and garbage 
>collection. It does not imply that the two protocols be 
>synchronous.
>

I'm not implying anything, I'm just trying to figure out where
you are coming from. I've had my head embedded in this handover
problem for a while now, particularly with regard to making
MIP handover fast enough for real time streams, and every time
I tune into the CT discussion, it seems to be drifting off into
philosophy and further away from what IMHO is essential engineering
for getting MIP to work fast. I'm sure I'm probably missing
alot of context here (so to speak), and I do admit to a MIP bias, but I'm
having some real trouble extracting anything out of this.

>I'm missing the critical state relationship between ct and ho
>that you are alluding to.
>

Sure I am. Let's take  a specific example. Suppose we are doing
network assisted handover in MIP. Suppose that we want to transfer
the authentication  context and header compression context so that
we can start up the real time stream on the MN just as soon as
it shows up on the L2 (otherwise the user ends up hearing a half
duplex converstation). In order for the handover to successfully
conclude, the nAR needs:

	1) Signaling from oAR that MN is coming soon,
	2) The relevent CT for nAR to install,
	3) Tunneled packets until MN gets around to changing its CoA.

and it needs them in that order. 

Suppose they do not arrive in that order. Clearly, 3) being out of
order first can be ruled out. If 3) arrives before 1, nAR doesn't
know that MN is coming. If 2) arrives before 1), nAR can wait for 1),
but that implies a timer. If 3) arrives before 2), the proper
authentication and header compression state isn't around. 

What am I missing?

		jak

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 11 Jul 2001 13:41:41 -0700

James,

I believe that there are ways around this. One example is a very
simple MIP extension that is sent stating that a CT is forthcoming 
(or may have already been sent). At least, this would be enough for
the receiver to know that it must wait for CT before sending packets
to the mobile.

PatC

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 11 Jul 2001 15:42:25 -0700

Hello James,

> MIP handover fast enough for real time streams, and every time

Rajeev: We have gone through similar exercises, and we believe that doing CT
along with handover signaling (esp FMIPv6) is beneficial in multiple ways. May
be this is not a requirement, but must not be excluded.

>         1) Signaling from oAR that MN is coming soon,

Rajeev: This can be done using HI message.

>         2) The relevent CT for nAR to install,

Rajeev: You can send the contexts as options in the HI message

>         3) Tunneled packets until MN gets around to changing its CoA.

Rajeev: In FMIPv6, if the MN has received a F-BAck, it already knows what its
new CoA is. If not, FMIPv6 says you need to send a F-NA which would work.
There are other optmizations that are possible as well.
In any case, the result of HI-HAck sequence is that after the old AR receives
a BU, there is already a tunnel established.

> authentication and header compression state isn't around.

Rajeev: All these scenarios can be avoided if you do CT _along-with_ handover
signaling. That does not mean that that's the only way to do CT. We explain
how to do CT with handover signaling in

draft-koodli-seamoby-ctv6-00.txt

which was submitted in February. [FYI, its precursor was submitted to
Pittsburgh IETF] There is also a companion draft

draft-koodli-seamoby-hc-relocate-00.txt

I suggest you take a look at them. They should address a lot of the things you
are referring to.

Regards,

-Rajeev