Subject: RE: [seamoby] Issue 2: Make IP messages uniform

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 25 Jun 2001 14:24:42 -0500

I prefer that we don't introduce explicit messaging, at least for now.
Defining a general CT trigger that each technology can map onto should be
good enough.

I am with option 2.

Madjid
-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Friday, June 22, 2001 5:05 PM
To: Kulwinder Atwal
Cc: 'Pat Calhoun'; [email-masked]
Subject: Re: [seamoby] Issue 2: Make IP messages uniform

On Fri, Jun 22, 2001 at 02:39:35AM -0400, Kulwinder Atwal wrote:
> 
> 
> > -----Original Message-----
> > From: Pat Calhoun [mailto:[email-masked]]
> > Sent: Thursday, June 21, 2001 6:45 PM
> > To: [email-masked]
> > Subject: [seamoby] Issue 2: Make IP messages uniform
> > 
> > 
> > If I understand this particular issue properly, it is a 
> > request for a layer 3
> > message be created to initiate CT. However, I believe that 
> > the mobility management
> > used already has messages that initiate L3 handoffs, and 
> > these could be used
> > to initiate CT.
> > 
> > So, we have two options:
> > 1. Create a message, which will introduce additional over the 
> > air latency in
> >    getting the CT initiated.
> 
> The newAR will need to request CT from a peer AR.  Are you suggesting that
> MIPv6 uses the Peer-to-Peer model such that the oldAR will hold the CoA?
> Or, is it quite possible that the CoA and the oldAR may not be co-located?
> 
> Also, if the MN to AR link is 55 Mbps, as Charlie has suggested, for some
> technology do we really care about over the air latency for a few bytes?

no, but look at option 2 below. My point is that there is already some
signalling, either at L2 (e.g. signal strength), or at L3 (binding update).
Why require another message, since we've already agreed to co-locate with
other MM protocols.

> 
> Of course some lower bandwidth technologies will use an L2 Trigger at the
> newAR, but the choice is really technology specific.

right, so we allow for L2 or L3. The question is whether CT needs to define
another message, or if an existing one can be used.

I much prefer the latter.

> 
> Further, I would hope that if the CoA were not co-located with the oldAR
> that some time could be saved by sending a change in route to the parent AR
> on the newAR-to-ParentAR link, while at the _same_ time sending a message to
> the oldAR on the oldAR-to-newAR link to transfer Context.
> 
> Since time is very critical in Reactive Context Transfer it would seem like
> a very useful method to reduce latency.

right, but I don't see how a CT L3 message would be faster, and therefore enable
reactive CT, than would a binding update.

> Additionally, a MN message on a high bandwidth link could be forwarded by
> the currentAR to the oldAR to request CT, and at the _same_ time a MN
> message could be forwarded by the currentAR to the ParentAR to affect a
> route change.
> 
> The route change message may travel to a different entity along a different
> link, than the Context Transfer request message.  Having them happen in
> parrallel could significantly reduce Reactive Context Transfer.

ok, this is the one and first argument that I've heard that could convince
me to agree to MN-initiated CT.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 25 Jun 2001 15:05:50 -0700

> Defining a general CT trigger that each technology can map onto should be

so if I understand correctly, perhaps a wireless technology profile would
be useful (e.g. 802.11 profile, mip profile (for non-l2 signalling), cdma2000 profile)

PatC

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 25 Jun 2001 18:08:43 -0700

> be useful (e.g. 802.11 profile, mip profile (for non-l2 signalling), cdma2000 profile)

I think we need to define an *option type* that can go with any handover message.
To take this one step further, CT itself should focus on defining the feature context
defintions that can be carried in different signals. Given that the transport discussion
is pending (read: diversity of features requiring different levels of reliability), it is
far more productive this way.

Regards,

-Rajeev