Subject: [mobile-ip] New Fast Handover Draft

From: Rajeev Koodli <[email-masked]>
Date: Mon, 01 Jul 2002 10:15:25 -0700

Hello folks,

I have submitted a new version of the fast handover
draft to the ID registrar. However, I missed the 6 am (PST)
deadline..You may access it from the following URL

http://people.nokia.net/~rajeev/draft-ietf-mobileip-fast-mip6-05.txt

Comments welcome!

Regards,

-Rajeev

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 2 Jul 2002 02:55:17 +0859 ()

Rajeev;

> http://people.nokia.net/~rajeev/draft-ietf-mobileip-fast-mip6-05.txt

A statement in abstract

	 comparison to the inevitable link switching latency.

is incorrect, because, with two transceivers, it is not inevitable.

						Masataka Ohta

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 01 Jul 2002 16:37:23 -0700

> is incorrect, because, with two transceivers, it is not inevitable.

Could you elaborate more ? There could be scenarios
when the link switching delay could be reduced to a "very small
amount". The intention however is to provide a protocol that
works well under such scenarios as well.

Regards,

-Rajeev

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 2 Jul 2002 09:08:10 +0859 ()

Rajeev;

> amount".

Sure.

> The intention however is to provide a protocol that

Then,

   The intent of this
   document is to describe protocol enhancements to reduce handover
   latency due to IP protocol operations as small as possible in
   comparison to the inevitable link switching latency.

should be:

   The intent of this
   document is to describe protocol enhancements to reduce handover
   latency due to IP protocol operations as small as possible when
   link switching latency is smaller than what is acceptable to
   support real-time or delay sensitive traffic or is small enough
   for non real-time, throughput-sensitive applications.

							Masataka Ohta

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 01 Jul 2002 18:04:52 -0700

>    for non real-time, throughput-sensitive applications.

Ok, so there is link-switching latency..
Your comment above seems to belong to an applicability statement
section. In an abstract, wouldn't it suffice to say that the latency due to
IP protocol operations should be as small as possible in comparison
with the link-switching latency, whatever the latter might be ?

Regards,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 01 Jul 2002 18:06:52 -0700

> Hello folks,

I will be away for the rest of the week. I will
catch up with the discussion upon returning.

Regards,

-Rajeev

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 2 Jul 2002 10:17:03 +0859 ()

Rajeev;

> section.

That's fine to put it in the section.

> In an abstract, wouldn't it suffice to say that the latency due to

The problem of the current abstract is that it is saying

even though link switching latency is not inevitable.

   comparison to the link switching latency.

would be OK.

							Masataka Ohta

---

From: "Dana L. Blair" <[email-masked]>
Date: Mon, 01 Jul 2002 21:37:04 -0400

One option might be to clarify that the draft is addressing break-before-make
handover.  If you have two transceivers, then make-before-break handover
is possible with simple home agent registration.

thanks,
Dana

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 2 Jul 2002 10:51:47 +0859 ()

Dana;

> is possible with simple home agent registration.

That's not enough to clarify that the protocol is not applicable very
well if link latency is large.

						Masataka Ohta

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Jul 2002 08:52:01 -0700

> is possible with simple home agent registration.

I think the draft may even apply in the make before break case, if some percentage of the handovers are disrupted because the
channel to the old router needs to be deallocated permaturely. I think changing the wording on the abstract to remove "inevitable"
should do. It might also be appropriate to have a paragraph in the introduction to discuss this.

            jak

---

From: zb <[email-masked]>
Date: Wed, 03 Jul 2002 17:59:54 +0900

hi all,

I have read several draft on L2 trigger in the group. I have a question on
the source node and destination node of the L2 trigger. The definition does
not say it explicitly. Do they locate in the same node or in different node?
If in different node, how is it implemented?

thanks in advanced.

bin
*************************************
Zhen Bin

i-Networking lab,
Samsung Advanced Institute of Technology,
San14-1, NongSeo-ri, Kiheung-Eup,
Yongin, Kyungki-do, 440600, Korea

82-31-2809569 (fax)
82-31-2809534 (o)
82-31-2122268 (h)
*************************************

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 3 Jul 2002 22:33:47 +0859 ()

James;

> channel to the old router needs to be deallocated permaturely.

Just for clarification, are you saying

	L2make-before-L2break-before-L3handover

?

						Masataka Ohta

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 3 Jul 2002 11:05:57 -0700

Hello,

> If in different node, how is it implemented?

L2 triggers are generated by the link-layer on a node.
And they are consumed by the network-layer of a node.
These two can be the same node, for example, in the
case of a WLAN client receiving a link-up. Therefore
an internal communication mechanism between the
link-layer and IP would be sufficient.

On the other hand, in the case of WLAN access point
receiving a link-up, the consumer of this trigger is located
on a separate node, like a router behind the AP. In this
case there needs to be a protocol to carry the L2 trigger
from the AP to the AR. Please see following draft which
attempts to define such a protocol:

http://www.ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt

alper

> bin
**********************Confidentiality Note**********************
Privileged/Confidential Information may be contained in this e-mail and any
attachment to it and may be covered by existing non-disclosure or
confidentiality agreements.
If you are not the addressee (or authorized to receive for the addressee),
you may not use, copy or disclose to anyone any information contained in
this e-mail.  If you have received this e-mail in error, please notify the
sender immediately by reply e-mail and delete it from your system.
Thank you very much.
*************************************************************

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 03 Jul 2002 13:36:31 -0500

I suggested to ZB to take this discussion to pilc ([email-masked]) 
mailing list where L2 Triggers
related discussions have already been taking place. You can get to know 
what is going on by consulting the mailing list of pilc.

Regards,

-- 
Behcet

---

From: "James Kempf" <[email-masked]>
Date: Wed, 3 Jul 2002 10:38:13 -0700

The idea behind an L2 trigger is that the trigger is delivered to the IP stack on a particular node. The trigger can be implemented
as an API, protocol, or in some other way. The question of what the source node is is therefore a question of the implementation. If
the trigger occurs within a single node, like a router, then there is no source in the protocol sense, though there may be in the
API sense (like it comes from the wireless link driver). If the trigger is an extension of the Layer 2 protocol, then there will be
a source and destination node.

            jak

---

From: zb <[email-masked]>
Date: Thu, 04 Jul 2002 16:07:56 +0900

From your answer, the source node and destination node of "L2 Trigger" can
be either in a same device or in seperated device. The "L2 Trigger" only
define its mechanism and ability. How to implement it is another issue.

thanks,

bin