Subject: RE: [seamoby] Question on 4.2

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 27 Jun 2001 02:39:48 -0400

> -----Original Message-----
> From: Emil Sturniolo [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 10:57 PM
> To: James Kempf; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [seamoby] Question on 4.2
> 
> 
> James,
> 
> ... snip...
> >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.
> ........
> 
> [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).

I would say that L3 mobility is concerned about routability and not
concerned with movement.
If a router has mulitiple L2 interfaces then a change from one L2 interface
to another will not affect L3.  In this case, L2 can verify routability
because it is still the same AR.

If it is a different AR, then there is a change in routability, and a need
to inform L3 mobility.

Unless, there is another case that comes to mind.

- Kulwinder.

> 
> 
> 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 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.
> 
> [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,
> 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: "Emil Sturniolo" <[email-masked]>
Date: Wed, 27 Jun 2001 08:58:42 -0400

Kulwinder.

I would say that L3 mobility is concerned about routability and not
concerned with movement.
If a router has mulitiple L2 interfaces then a change from one L2
interface
to another will not affect L3.  In this case, L2 can verify
routability
because it is still the same AR.

If it is a different AR, then there is a change in routability, and a
need
to inform L3 mobility.

- Kulwinder.

[Emil] Kulwinder, what I was trying to point out is that even though
it is still the same AR it is still useful to signal L3 that
connectivity has been re-established.  Off the top of my head,
depending on when and the length of time that the MN was disconnected,
after L2 connectivity is reaffirmed, it may need to determine if its
own addressibility is still valid  Furthermore, as I said in my
original note, this indication may also help facilitate recovery
further up the stack. Maybe this is a different trigger that I am
describing here, but it does seem to be consistent with
acquisition/continuation of L2 connectivity.

Cordially,
Emil Sturniolo

---

From: Youngjune Lee Gwon <[email-masked]>
Date: Wed, 27 Jun 2001 16:26:39 -0700 (PDT)

I sort of agree with Emil and let me give you an example I have thought
about. Consider the picture below to illustrate my point.

        | <-->       +----+         =========
       []         #  |AP 1|---------| AR 1  |-----+
       MN         |  +----+      /  =========     |
                  |             /                 |
                  |            /                  |            |
                  |           /                   |  -------   |
                  |          /                    +--|ANG 1|---+ 
                  |  +----+ /                     |  -------   |
                  V  |AP 2|/                      |            |
                     +----+                       |            |
                                                  |            |

If a MN moves from AP1 to AP2, where both APs are connected to the same L3
entity, AR1, there is no MIP process should be involved since the MN does
not change in terms of MIP.

This puts the MN's mobility support, pretty much, relying completely on
the L2 technology of AP1 & AP2. My question is that what if AP1 and AP2
does not support fast/smooth handoff at L2. Does this mean automatically
that the L3 communication during this move is disrupted, blacked out, or
discontinuous for a short time? In other words, the choice of the L2
technology may be crucial for the outcomes at L3?

In any cases, independently from the L2 capability, L3 can still be
seamless without interruptions. This can be possible if L3 is aware of
what events are occurred at L2. To certain degree, I agree L3 should also
be involved in movement matters by interacting with the lower layer. 

Maybe, this is not really the scope of SeaMoby or IETF since this case is
within a single L3 entity while switching only between L2 entities.

Secondly, if AP1 and AP2 are running different access technolgoies, it
gets even more interesting because there is no clear definition of L2
handoff. It may get to a problem where L3 is choosing one link from two
simultaneously available connections. User preference may also come in to
play in this case.  

I just recall that L2 trigger is a special case of this L2-L3 interaction.
At the same time, L2 trigger is a kind of L3-awaring mechanism about the
mobility of a MN itself.  

Any thoughts? Arguments? Objections? Let me know...

Youngjune

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 28 Jun 2001 06:27:35 -0700

If I understand you correctly, I am in agreement. Even if the link layer
doesn't provide "fast handoff", but L3 (e.g. Mobile IP) does (perhaps
via Fast MIP), you can still get seamless service.

My point all along, btw, was that in order for this to occur, we really
need to minimize the number of round trips over the air, and re-using
existing messages in the L3 mobility management protocol is the best
approach. In the MIP case, we are talking about the BU.

PatC

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 28 Jun 2001 07:53:07 -0700

Hello,

I do not understand why this scenario makes sense.
In order for the layer-3 protocol to operate, there would
need to be a previous access router and a new access
router.  Here there is none.  Instead, we have a layer-2
trigger that should initiate a layer-2 context transfer.
If that layer-2 context transfer is carried out by the
access router, then that's fine, but I don't see why it
needs to be the concern of the [seamoby] layer-3
context transfer protocol.

Regards,
Charlie P.

---

From: "Emil Sturniolo" <[email-masked]>
Date: Thu, 28 Jun 2001 15:38:14 -0400

Hello Charlie,
	My major concern when I posted the original note was in reaction to
proposed motion across different L2 technologies but to the same AR
without signaling. I was also concerned that no signaling was defined
for the detached state. In either instance, having L3 be somewhat
cognizant of these motion events can have dramatic positive effects
even across the same technology. From my own experience, I have found
that signaling as Youngjune suggests is helpful at L3. Suffice to say,
traffic flow can be minimized by using this information intelligently
and can be politely ignored when not. If we are going to go down the
path of defining L2 triggers, I would like to see the definition
meaningful to CT, but broad enough that it can be used by other L3
entities as well (hopefully not biting off more the I/we can chew).

Cordially,
Emil Sturniolo

-----Original Message-----
From:	Charlie Perkins [mailto:[email-masked]]
Sent:	Thursday, June 28, 2001 10:53 AM
To:	Youngjune Lee Gwon
Cc:	Emil Sturniolo; [email-masked]
Subject:	Re: [seamoby] Question on 4.2

Hello,

Regards,
Charlie P.

Youngjune Lee Gwon wrote:

> > > this thread has been concern with the situation where
connectivity
> > at

---

From: Youngjune Lee Gwon <[email-masked]>
Date: Thu, 28 Jun 2001 13:39:01 -0700 (PDT)

> entities as well (hopefully not biting off more the I/we can chew).

===> Yes, exactly Emilio. :) Again, all I'm trying to say is to illustrate 
the scope of L2 trigger that can be generally applicable to low-latency or
CT. The case I described may be out of scope of CT in the sense that CT 
of one AR to another is obviously out of the picture, but rather
emphasizes the importance of the L3 awareness toward the events at L2. 

In this intra-AR (intra-L3)  movement, as Charlie has pointed out 
correctly, I should admit no involvement in L3 CT processes, except being
aware of the L2 changes.

Thanks,

Youngjune