Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 27 Jun 2001 02:22:19 -0400

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 7:17 PM
> To: Rajeev Koodli
> Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri 
> Madjid-MNAKHJI1'; 'Charles
> E. Perkins'; [email-masked]'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> and re active CT definitions
> 
> 
> On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev Koodli wrote:
> > > >
> > > > Rajeev: I guess the point is that you would do CT either
> > > >
> > > > 1. before the new AR becomes the MN's default router, or
> > > > 2. after the new AR becomes the MN's default router
> > > >
> > > > Both 1) and 2) are related to handover.
> > >
> > >
> > 
> > The point of above text was to indicate that defining 
> context transfer to be
> > independent of handover is perhaps not sensible. Getting it 
> to work with
> > handovers is the challenge we are peddling.
> > If we all agree on this, may be we should try to close the issue ?
> 
> The issue I have is that the current definitions use some 
> random packet destined
> for the mobile as the timing "event". This, im my mind, makes 
> no sense whatsoever,
> because one side (oAR) may not know when the packet shows up, 
> and therefore it
> has no idea whether a reactive or proactive CT is to be invoked.

The oldAR recieves the signalling message from newAR that states which type
of CT to invoke.
This is the common IP signalling message from newAR to oldAR on the direct
link between newAR and oldAR.

The oldAR is provided with everything it needs to know to do CT in the
signalling message.

- Kulwinder.

> 
> FWIW, some CTs will transfer L2 session keys used for 
> authentication and 
> encryption, so this is where the first packet doesn't make sense.
> 
> PatC
> > 
> > Regards,
> > 
> > -Rajeev
> > 
> > 
> > > Yes, but handover is pretty vague. Like Gary said, is the 
> start, exact
> > > middle, or end of handover, or some special protocol 
> event in the middle.
> > > In a collision based wired, or a wireless network we 
> can't be certain which
> > > protocol packet will arrive first.
> > >
> > > Also, we all seem to agree that if pre-connection Context 
> Transfer takes too
> > > long due to the uncertain nature of wireless (End-user 
> drives through a
> > > tunnel), it is very likely that several post-connection 
> events will pass
> > > before the transfer is complete.
> > >
> > > So, we may start with the best of intentions with the 
> intent of being early
> > > enough to not affect the user experience, but events may 
> overtake us such
> > > that we find ourselves out of time.
> > >
> > > So, what do we do at that point in time?
> > >
> > > A particular technology may find it advantageous to do 
> post-connection, if
> > > the data is available, even after the user has 
> experienced a distruption,
> > > becuase the connection setup time will be longer than the 
> post-connection
> > > Context Transfer time.
> > >
> > > An other technology may find it advantageous to 
> re-establish new context,
> > > because the Context Transfer time (Round-Trip Times) are 
> greater than new
> > > connection setup.
> > >
> > > - Kulwinder.
> > >
> > > >
> > > > Regards,
> > > >
> > > > -Rajeev
> > > >
> > > >
> > > > > It is up to the implementor to take into account particular
> > > > network and
> > > > > inter-network characteristics and real-time flow
> > > > requirements to determine
> > > > > how early Pre-Connection Context Transfer needs to be done
> > > > to guarrantee
> > > > > seamless.
> > > > >
> > > > > - Kulwinder.
> > > > >
> > > > > > In all cases that I
> > > > > > know of, some
> > > > > > signalling, either at L2 or L3, is used to register the
> > > > > > mobile locally (or
> > > > > > some signal strength measurements), but there is always an
> > > > > > indication of handoff.
> > > > > >
> > > > > >
> > > > > > > But, really why should we care where the request for CT
> > > > > > comes from if we are
> > > > > > > going to process it just the same?
> > > > > > >
> > > > > > > The only thing that is important is that the requesting
> > > > > > entity recieve a
> > > > > > > packet indicating the success or failure mode of the CT
> > > > operation.
> > > > > >
> > > > > > ditto.
> > > > > >
> > > > > > PatC
> > > > > >
> > > >
> > 
>

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 27 Jun 2001 06:56:34 -0700

> The oldAR is provided with everything it needs to know to do CT in the

Now sure that you meant to generalize here, but you are assuming a target trigger.
How would it work in source triggers?

PatC