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 15:05:06 -0400

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Wednesday, June 27, 2001 12:38 PM
> 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 12:09:06PM -0400, Kulwinder Atwal wrote:
> > > 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.
> > 
> 
> 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

The below example is triggered by oldAR.  All or some of the context is sent
with the CT message in this case.  In the forward direction, oldAR to newAR,
the CT req msg can be combined with Context.  The CT req msg in this case
can be thought of as a subset of the Context Transfer packet.

- Kulwinder.

> > Post-Connection:
> > Pre-Connection:
> > 2. From oldAR to newAR
> > IP Header
> > CT Header
> > MN IP address
> > newAR IP address
> > + Context

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 27 Jun 2001 12:03:47 -0700

> can be thought of as a subset of the Context Transfer packet.

ok, perhaps I missed something in your text. So both pre and post connection
can occur in both directions, right?

As someone else stated, I think that this is just becoming more and more
complicated. Why not just define the protocol, and leave the implementor to
decide when CT occurs? The messages would most likely be exactly the same in
both cases anyways. With support for Multi-Phasic transfer, it allows critical
info to be transferred to do things such as setup the L2 and L3 connections.

PatC