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 15:05:57 -0700 (PDT)

Ok, then it does seem we agree (or perhaps Gary doesn't?) that
there is an ordering on what's needed for nAR to be primed for
that first packet. nAR must have the HO signaling and the CT
signaling, and if it doesn't have the first, it must wait 
for the second, and vice versa. 

IMHO, whether or not that is done by doing the signaling separately
(and thus incurs the overhead of maintaining timers on the router)
or together is an implementation decision. I suppose whoever does
the MIP binding will determine that.

		jak

>Delivered-To: [email-masked]
>Date: Wed, 11 Jul 2001 13:41:41 -0700
>From: Pat Calhoun <[email-masked]>
>To: James Kempf <[email-masked]>
>Cc: [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked]
>Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,    
      RE: Issue #4)
>Mail-Followup-To: James Kempf <[email-masked]>, [email-masked], 
[email-masked], [email-masked], 
[email-masked], [email-masked]
>Content-Disposition: inline
>User-Agent: Mutt/1.2.5i
>
>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
>On Wed, Jul 11, 2001 at 01:43:51PM -0700, James Kempf wrote:
>> 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: "Kulwinder Atwal" <[email-masked]>
Date: Thu, 12 Jul 2001 06:50:55 -0400

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, July 11, 2001 6:05 PM
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,
RE: Issue #4)

> (and thus incurs the overhead of maintaining timers on the router)

When a context is 'too stale' is really context dependant, not whether or
not the HO happens according to some ideal.
Therefore, the timers I would think would be for things like ROHC
specifically, but not for static context or CT/HO in general.

In fact, an AR in a private wireless network could hold on to static context
in FLASH memory and reuse it, since it knows that there are only a few MNs
in the small private network.  Such an AR would only ever need to request
dynamic context and authentication.

In general, as Gary has suggested, CT/HO state could just be the subject of
garbage collection at an implemenation specific interval.

- Kulwinder.