Subject: [seamoby] Question on 4.2

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 16:51:22 -0700

I do recall a recent discussion on this, so I appologize if this has already
come up. Does the following text, which appears under section 4.2, imply that
seamoby will define the triggers?

"  This implies that there are general
   characteristics of an IP level trigger that need to be defined so 
   that the triggers generated by different layer 2 solutions will have
   identical semantics at the IP level."

PatC

---

From: [email-masked]
Date: Thu, 21 Jun 2001 09:35:54 +0300

Hi Pat,

> I do recall a recent discussion on this, so I appologize if 
> this has already come up. Does the following text, which appears 
> under section 4.2, imply that seamoby will define the triggers?
> 
>    that the triggers generated by different layer 2 solutions 
>    will have identical semantics at the IP level."

This I am not sure of, and this gets to my point about it being much
more of an API issue. Can we re-word the text so that IP level
triggers are supported (but don't have to go into the dirty
details of what they are yet)?

John

---

From: kempf <[email-masked]>
Date: Sat, 23 Jun 2001 09:15:28 -0700 (PDT)

Pat,

A bunch of us are in discussion about doing a draft on abstract L2
triggers. Currently, there is some unpublished material and the
material embedded in the FMIPv4 draft that we would like to pull
together. This should allow people to refer to a common source
on L2 triggers. We are unclear yet whether this belongs in MIP,
Seamoby, or other. It is clearly important for the MIP fast handoff
work, and also perhaps Seamoby context transfer.

		jak
		
>Delivered-To: [email-masked]
>Date: Tue, 19 Jun 2001 16:51:22 -0700
>From: Pat Calhoun <[email-masked]>
>To: [email-masked]
>Subject: [seamoby] Question on 4.2
>Mail-Followup-To: [email-masked]
>Content-Disposition: inline
>User-Agent: Mutt/1.2.5i
>

---

From: Phillip Neumiller <[email-masked]>
Date: Tue, 26 Jun 2001 12:45:41 -0400

Hi James,

I have tried to start such an effort many times.  Who is this
bunch of you?  Whenever I have tried in the past, people were
not interested.  Also, I sent a request to Scott B.   a
couple of months ago to get this started in the sub-IP area.
I wrote up a draft for the WG charter.  He never got back.
So, I guess I would like to know if you created a mail list or
if not I welcome you to use:

http://internet.motlabs.com/mailman/listinfo/wirelessinternet

Thanks,

Phil

> -----Original Message-----
> From: kempf [mailto:[email-masked]]
> Sent: Saturday, June 23, 2001 12:15 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [seamoby] Question on 4.2
> 
> 
> Pat,
>

---

From: Phillip Neumiller <[email-masked]>
Date: Tue, 26 Jun 2001 13:20:43 -0400

That is unfortunate.  A generic L2 triggering mechanism COULD 
be very useful to QoS WGs, MIP, MANET, and SeaMoby.   I do 
realize the IETF is better suited to work on very narrow
problem statements and generalizations have to be done with
the "death-by-a-thousand cuts" method.

Best regards,

Phil

> From: James Kempf [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 1:01 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [seamoby] Question on 4.2
> 
> 
> Thanx for the pointer, but I think we are going to do this as a draft
> rather than a working group, probably through MIP first because
> it keeps coming up.
> 
> 		jak
> 		
> >From: Phillip Neumiller <[email-masked]>
> >To: "'kempf'" <[email-masked]>, [email-masked], 
> [email-masked]
> >Subject: RE: [seamoby] Question on 4.2
> >Date: Tue, 26 Jun 2001 12:45:41 -0400
> >
> >Hi James,
> >

---

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

> From: James Kempf [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 5:33 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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.

If the user sets up an handover policy stating user preferences the MN can
use this policy in selecting an AR. 

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

It can be done at the IP level.  IP just sees different radio-modems as
different L2 interfaces.
If each radio-modem is assigned an IPv6 interface ID, it can be done with IP
switching between different IP interfaces.

http://www.ietf.org/rfc/rfc1884.txt?number=1884

- Kulwinder.

> 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: Kulwinder Atwal <[email-masked]>
Date: Wed, 27 Jun 2001 09:13:48 -0400

> From: Emil Sturniolo [mailto:[email-masked]]
> Sent: Wednesday, June 27, 2001 8:59 AM
> To: Kulwinder Atwal; James Kempf; [email-masked]
> [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.

Maybe these triggers could be called:

1. Link Lost Trigger
2. Link Connected Trigger

- Kulwinder.

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

---

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 28 Jun 2001 14:57:42 -0400

I suppose if AP 1 and AP 2 are assigned different IP addresses then it
becomes a L3 routability problem.

- Kulwinder.

> From: Youngjune Lee Gwon [mailto:[email-masked]]
> Sent: Wednesday, June 27, 2001 7:27 PM
> To: Emil Sturniolo
> Cc: Kulwinder Atwal; James Kempf; [email-masked];
> [email-masked]
> 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
> 
> On Wed, 27 Jun 2001, Emil Sturniolo wrote:
> 
> > Kulwinder.
> > 
> > > James,
> > >
> > > ... snip...
> > > 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.
> >