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

From: Kulwinder Atwal <[email-masked]>
Date: Fri, 22 Jun 2001 02:39:35 -0400

> -----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?

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

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.

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.

- Kulwinder.

> 2. Retrofit in an existing MM solution, and perhaps create CT 
> documents that 
>    describe the CT profile for MM. Example, a document that 
> states how the
>    MIPv6 binding update can be used as a substitute for L2 signalling.
> 
> I, personally, much prefer option 2, but it does restrict CT 
> to work only 
> when an MM is present, which I believe would always be the 
> case anyways.
> 
> PatC
>

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 22 Jun 2001 15:05:17 -0700

> 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.

> 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.

> 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.

> 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: Rajeev Koodli <[email-masked]>
Date: Mon, 25 Jun 2001 18:00:17 -0700

> parrallel could significantly reduce Reactive Context Transfer.

Exactly. As soon as the MN detects that it has undergone handover, it sends a
message which includes BU as an encapsulation. The new AR sends the CT message
towards the old AR and the BU towards the mobility agent.
We proposed this (the message is SHIN) in our -smoothv6-.txt draft (in
Pittsburgh IETF).

Regards,

-Rajeev