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

From: Kulwinder Atwal <[email-masked]>
Date: Mon, 25 Jun 2001 01:18:00 -0400

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Sunday, June 24, 2001 11:50 PM
> To: Kulwinder Atwal
> Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins';
> [email-masked]'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> and re active CT definitions
> 
> 
> > > 
> > > MN>> Sure, my point was that both starting point and 
> finishing point
> > > for CT are important, so CT does not introduce delays.
> > 
> > They are only important if you are unwilling to design a 
> state machine for
> > the protocol to accommodate an imperfect world.
> > 
> > The packet exchange for context transfer can be the same 
> for proactive and
> > reactive.  
> > The only thing that is really different is where the 
> context request comes
> > from.
> > 
> > With Multi-Phasic Context Transfer there is really no 
> difference between the
> > Reactive or Proactive packet exchanges other than where the 
> request comes
> > from.
> > 
> > I believe we should drop the terms Proactive and Reactive 
> since some people
> > seem to attach them to events in MIP like HandOver.  And, 
> then use HandOver
> > to unnecessarily constrain the design of CTP. 
> > 
> > I would much rather see a protocol that allowed things to 
> happen as fast as
> > hardware will allow rather than wait for some artificial 
> protocol event.
> > The problem with waiting for HO is that it only works well 
> if your network
> > has been tightly engineered from the beginning.  
> > 
> > This expectation does not hold true for private wireless 
> networks connected
> > to Ethernet LANs where packet collisions could re-arrange 
> the packet order
> > of HO and CT.
> > 
> > I would like the terms Proactive and Reactive replaced by 
> packet order
> > neutral terms:
> > 
> > Pre-Connection Context Transfer: The Context Transfer is 
> initiated prior to
> > the newAR recieving a packet directly from the MN. 
> > 
> > Post-Connection Context Transfer:  The Context Transfer is 
> initiated after
> > the newAR recieves a packet directly from the MN.
> 
> *this* I like! However, I disagree with your view on handoffs. I would
> like the pre-handoff and post-handoff context transfer. Pre 
> or post first
> packet doesn't make any sense *at all* to me. How can you 
> guarantee, or know,
> when the first packet will be received?!?

I can't.  How early to do Pre-Connection Context Transfer to get seamless
transfer is implementation specific.

The viewpoint is the newAR.  Either the newAR is notified for a need to CT
from oldAR, or MN.  
The difference is on what interface the newAR is notified.

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: "Charles E. Perkins" <[email-masked]>
Date: Mon, 25 Jun 2001 09:27:01 -0700

Hello Kulwinder,

It seems to me that we are getting closer to some definitions
that can work.

Kulwinder Atwal wrote:

> The viewpoint is the newAR.  Either the newAR is notified for a need
> to CT from oldAR, or MN.

I agree with this, basically.  Please let me know how you think
it applies in the following scenario:

- Previous access router and new access router agree that the mobile
  node should move to the new access router.
- Mobile node is told to move (after this, connectivity between mobile
  node and previous access router may fail)
- Access network controller tells new access router to allocate
  spectrum for mobile node
- New access router asks previous access router for context
- At the same time, mobile node detects beacon from new access
  router and carries out operations for link establishment
- Before finalizing the process of link establishment and the
  installation of the transferred context features, the new
  access router verifies the credentials of the mobile node.

How do you think this scenario applies to your classification?

My answer, is that this is reactive.  The new access router is
reacting to the information that the mobile node has arrived.

I hope we can make definitions to enable the protocol solution
I have outlined, since it my favorite scenario and I believe it
is compatible with 3G designs.

> how early Pre-Connection Context Transfer needs to be done to guarrantee

By previous discussion, we are unlikely to be able to make any
such guarantees.  We can, however, make a darned good stab at it.

Regards,
Charlie P.

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 25 Jun 2001 11:20:28 -0700

> > > the newAR recieves a packet directly from the MN.

Rajeev: I like this classification as well.

> The difference is on what interface the newAR is notified.

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.

Regards,

-Rajeev