Subject: RE: [seamoby] Question on 4.2

From: James Kempf <[email-masked]>
Date: Tue, 26 Jun 2001 14:33:21 -0700 (PDT)

Youngjun,

>I have looked thru the FMIPv4 draft (-01.txt) and Section 1.3 is devoted
>for describing L2 trigger, required for Pre- and Post-Registration
>methods. I think the section is well written and really trying to unveil
>the role of L2 trigger. Actually, it is quite informational as well since
>we haven't quite seen anything in this detail regarding L2 trigger.  
>
>IMHO, though, what SeaMoby requires (in terms of handoff trigger) is the
>superset that not only covers the scope of the triggering mechanism that
>FMIPv4 draft requires, but also other context.
>
>As an example, L2 trigger described in FMIPv4 draft Section 1.3 specifies
>the recipient, content (IP address/IP address identifier etc.), and timing
>of the arrival of this special signal. CT trigger may require more
>information than these. 
>

I agree that there may need to be some additions to the defined
set of L2 triggers in the FMIPv4 draft to cover Seamoby. The discussion
in the draft only covers fast handoff, context transfer is likely
to impose its own requirements on the L2/L3 interaction.

>Going back to discussions regarding L2/L3 trigger between Rajeev and
>Kulwinder, I think SeaMoby also should consider abstract description of
>this trigger business. I've always thought about pursuiting a work in
>triggering mechanism, but I wasn't sure I'm digging into the legitimate
>scope of work for the WG. Can anybody share some thoughts regarding this
>with me?
>

I also agree, but I think it might be worthwhile to combine the
handoff and context trigger descriptions in one document, since
they are likely to be intimately related.

>Lastly, the trigger mechanism should be constructed in the following
>steps - this is my opinion and you are welcome to disagree with me.
>
>1. Fast movement detection/prediction

Well, actually, I do disagree here.

I believe the following view more accurately reflects
what is going on between L2 and L3 around handover. Basically, L3
is not concerned with movement, it is concerned with routability
changes, L2 is concerned with movement. To be more specific, L3 is
only concerned with movement to the extent that a movement at L2 causes
a change in routability that requires (for MIP) a change in CoA. If movement
causes no change in routability, then L3 should not be involved. Therefore,
I believe that the abstract L2 triggers should be designed to convey
to L3 information required for fast and efficient re-establishment of
routablilty when movement is about to occur or has occured. 

My motivation for this view is that I think it more accurately reflects
the partitioning of functionality between IP as an L3 protocol and
the L2 protocols on which it sits. IP is designed primarily for routability 
between different link layers, wireless to wired is a perfect example. The
L2 protocols are designed for establishing the basic link connection,
and, for wireless protocols, that means re-establishing a link when
radio conditions require moving to a different access point. I think
maintaining this distinction (which has been fundamental to IP since
its initial design) is important to get a clean abstraction of link
layer triggers for handover.

>2. Handoff Candidate Discovery (e.g. obtaining nFA IP Addr ID)

While I can see the benefit of being able to select an access point
in a multitechnology handover situation, I believe that it will, in general, be 
a relatively slow process perhaps even involving the user. Since a 
multitechnology handover situation is likely to involve multiple interfaces, the 
MN can take its time setting up the new interface while real time traffic 
continues on the old, then switch at the last minute.  Therefore,
while I think this is important, I do  not see it as influencing the
structure of an abstract L2 trigger design. The only exception is
perhaps a software defined radio that can switch a single interface
to a different technology access point, but I don't know much about
software defined radios (but I have the impression that they are
not to the point where one could switch from, say, Bluetooth to
802.11, or GSM, anyway).

>3. Signaling handoff initiator (trigger is in fact a special signal)
>

Yes, this is what the FMIPv4 section on L2 triggers is trying to do.
Set up a timeline for handover and define where L2 triggers will help
accelerate the process and what information needs to be conveyed
from L2 to L3 to help reestablish routability on the new AR as
quickly as possible.

I imagine the same sort of thing will be needed for Seamoby.

		jak

---

From: Youngjune Lee Gwon <[email-masked]>
Date: Tue, 26 Jun 2001 15:22:09 -0700 (PDT)

James, 

Thank you for your quick insight. Please find my comments below ...

> they are likely to be intimately related.

===> Yes, this is what I'm trying to say all along. I strongly agree with
coming up with a draft about triggering mechanism (abstraction perhaps)
that sort of reflects both low-latency, CT point of view, and others (if
there's any) in a superset. Objective of the draft is that any sound L3
handoff schemes/CT should be benefitted by the draft. 

> layer triggers for handover.

===> Here, I'm not trying to say that L3 method should be replaced for L2!
I don't know why you automatically assume my view is pro-L3 method. I
understand your point here with your arguments on L2. :)
  
What I am trying to make sense here by fast movement/prediction is that
this is the point when preparing trigger should be started, thus should
be the part of triggering mechanism. That's all. 

> not to the point where one could switch from, say, Bluetooth to

===> Information about the next access point is included in the trigger
in FMIP sense. Obtaining such info is related to this step. I believe
similar processes should be happend for SeaMoby. Also, isn't it required
for CT to discover not just AR/nFA ID, but also capabilities, resources
available and so forth? 

As you mentioned, trying to figure out what access technologies are
available is also interesting if combined with user preference.

---

From: "Emil Sturniolo" <[email-masked]>
Date: Tue, 26 Jun 2001 22:56:58 -0400

James,

... snip...

I believe the following view more accurately reflects
what is going on between L2 and L3 around handover. Basically, L3
is not concerned with movement, it is concerned with routability
changes, L2 is concerned with movement. To be more specific, L3 is
only concerned with movement to the extent that a movement at L2
causes
a change in routability that requires (for MIP) a change in CoA. If
movement
causes no change in routability, then L3 should not be involved.
........

[Emil]. James, I'd like to add one scenario that might slightly change
the semantics, if it's within the scope of the conversation. Most of
this thread has been concern with the situation where connectivity at
L2 is constant and possibly predictive. However, it has been my
experience that this is not truly reflective of reality. IMHO L3
should be involved if a mobile node becomes detached and then
reattached to the same network, even though no changes in routability
may have occurred. L3 needs to be knowledgeable of this event to at
least verify routability and possibly facilitate faster recovery at
even higher levels in the protocol stack (slings and arrows welcome).

Cordially,
Emil Sturniolo
[email-masked]
www.NetMotionWireless.com
330-723-9099
330-461-0326 - Mobile/Voice Mail
=====================

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
On Behalf Of James Kempf
Sent:	Tuesday, June 26, 2001 5:33 PM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: [seamoby] Question on 4.2

Youngjun,

I agree that there may need to be some additions to the defined
set of L2 triggers in the FMIPv4 draft to cover Seamoby. The
discussion
in the draft only covers fast handoff, context transfer is likely
to impose its own requirements on the L2/L3 interaction.

I believe the following view more accurately reflects
what is going on between L2 and L3 around handover. Basically, L3
is not concerned with movement, it is concerned with routability
changes, L2 is concerned with movement. To be more specific, L3 is
only concerned with movement to the extent that a movement at L2
causes
a change in routability that requires (for MIP) a change in CoA. If
movement
causes no change in routability, then L3 should not be involved.

[Emil]. James, I need to add one case that might change the semantics
here slightly. IMHO L3 should be involved here if a mobile node
becomes detached and then reattached to the network, even though no
changes in routability occurred. L3 may need to be involved at this
point to at least verify routability and possibly facilitate faster
recovery at even higher levels in the stack.

Therefore,

My motivation for this view is that I think it more accurately
reflects
the partitioning of functionality between IP as an L3 protocol and
the L2 protocols on which it sits. IP is designed primarily for
routability
between different link layers, wireless to wired is a perfect example.
The
L2 protocols are designed for establishing the basic link connection,
and, for wireless protocols, that means re-establishing a link when
radio conditions require moving to a different access point. I think
maintaining this distinction (which has been fundamental to IP since
its initial design) is important to get a clean abstraction of link
layer triggers for handover.

While I can see the benefit of being able to select an access point
in a multitechnology handover situation, I believe that it will, in
general, be
a relatively slow process perhaps even involving the user. Since a
multitechnology handover situation is likely to involve multiple
interfaces, the
MN can take its time setting up the new interface while real time
traffic
continues on the old, then switch at the last minute.  Therefore,
while I think this is important, I do  not see it as influencing the
structure of an abstract L2 trigger design. The only exception is
perhaps a software defined radio that can switch a single interface
to a different technology access point, but I don't know much about
software defined radios (but I have the impression that they are
not to the point where one could switch from, say, Bluetooth to
802.11, or GSM, anyway).

		jak