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 12:09:06 -0400

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Wednesday, June 27, 2001 9:57 AM
> To: Kulwinder Atwal
> Cc: 'Pat Calhoun'; Rajeev Koodli; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles
> E. Perkins'; [email-masked]'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> an d re active CT definitions
> 
> 
> On Wed, Jun 27, 2001 at 02:22:19AM -0400, Kulwinder Atwal wrote:
> > > 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.
> 
> Now sure that you meant to generalize here, but you are 
> assuming a target trigger.
> How would it work in source triggers?

Here is the general idea.  The message could be combined with the CT in the
forward direction 
(oldAR to newAR).  I am not implying the use of, or absence of, any
transport here.  Just the general idea.

Post-Connection:

1. From newAR to oldAR

IP Header
CT Header
MN IP address
newAR IP address

From oldAR to newAR

IP Header
CT Header
MN IP address
newAR IP address
+ Context

Pre-Connection:

2. From oldAR to newAR

IP Header
CT Header
MN IP address
newAR IP address
+ Context

3. From other Entity to oldAR

IP Header
CT Header
MN IP address
newAR IP address

Followed by from oldAR to newAR

IP Header
CT Header
MN IP address
newAR IP address
+ Context

- Kulwinder.

> PatC

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 27 Jun 2001 09:38:21 -0700

> transport here.  Just the general idea.

Right, but all of your examples assume that the handoff is initiated by
the target (newAR). There are many cases where the source (oldAR) can
initiate the handoff.

If we bind the protocol to your recommendation below, a source trigger
would require an additional trip between oldAR to newAR to get CT initiated.

Hence my problem,

PatC