Subject: RE: [mobile-ip] Re: Current movement detection process

From: Hesham Soliman <[email-masked]>
Date: Fri, 2 May 2003 18:32:56 -0400

I'm fine with this. 

Hesham

 > -----Original Message-----
 > From: Jari Arkko [mailto:[email-masked]]
 > Sent: Friday, May 02, 2003 3:24 PM
 > To: Mobile IPv6 mailling list
 > Subject: [mobile-ip] Re: Current movement detection process
 > 
 > 
 > I'm still working on a version of the movement detection section
 > which would be formulated around hints about movement (and non-
 > movement). I should be able to post that this weekend.
 > 
 > However, what we have discussed most is the probing part.
 > It seems like most people in the WG would like to have
 > generic text about probing. Vijay and maybe Hesham wanted
 > to have more specific text on how to do NS/NA probing. Erik
 > seems happiest with no text on probing at all.
 > 
 > Let me try to suggest a brief guidelines or educational
 > text approach for the probing part:
 > 
 >      ... To detect when its default router becomes unreachable, a
 >      mobile node SHOULD use Neighbor Unreachability Detection.
 > 
 >      Neighbor Unreachability Detection is applied only when 
 > the mobile
 >      node has packets to send. In order to be able to 
 > receive incoming
 >      packets when the mobile node has nothing to send, it is also
 >      important for the mobile node to keep track of whether 
 > the current
 >      default router can reach the mobile node. If the router can not
 >      reach the mobile node, the mobile node SHOULD switch to a new
 >      default router and potentially to a new primary care-of address.
 >      The following indications can give the mobile node some 
 > assurance
 >      that the default router can still reach it:
 > 
 >      o  (List of hints)
 > 
 >      The lack of such indications can mean either that 
 > reachability has
 >      been lost, or simply that there was no traffic on the link. This
 >      can happen, for instance, if the advertisement interval on the
 >      link is large, there are no indications from the link layer, and
 >      no other traffic exists on the link. In this situation it may be
 >      necessary to probe the router in order to test for reachability,
 >      but specific methods for such probing are outside the 
 > scope of this
 >      specification. In order to avoid congesting the link, probing
 >      should only be done if the mobile node has already attempted to
 >      determine reachability indications according to the list above.
 > 
 > Alternatives to this text would include adding specific
 > words about the use of NS/NA, or striking the last paragraph.
 > But I think this is a good compromise.
 > 
 > --Jari
 >

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 8 May 2003 16:56:27 -0700

James -

Awesome! Thanks, this is what I'm looking for.

- Ed

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, May 08, 2003 4:56 PM
To: Ed Remmell; Jari Arkko
Cc: Mobile IPv6 mailling list
Subject: Re: [mobile-ip] Re: Current movement detection process

Shouldn't the definitions be put into Section 3.2?

    L2 handover - process by which the mobile node changes from one
physical/MAC layer connection to the Internet to another.

    L3 handover - subsequent to an L2 handover, a mobile node detects
a change in an on-link subnet prefix that would require a
                          change in care of address.

Then in the MD section:

    For some wireless L2 technologies and deployment scenarios,  a  L2
handover may not always require a L3 handover, for example, if both
the old link and the new link share the same access router and thus
the same on-link prefixes. The primary goal of movement detection is
to detect  L3 handovers.

            jak

----- Original Message -----
From: "Ed Remmell" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Jari Arkko"
<[email-masked]>
Cc: "Mobile IPv6 mailling list" <[email-masked]>
Sent: Thursday, May 08, 2003 4:35 PM
Subject: RE: [mobile-ip] Re: Current movement detection process

> I want to add the following new definitions to the beginning of the
movement
> detection section, because it will help clarify (and shorten) the
other
> material:
>
>     Handover is the process of a mobile node moving from an old link
to
>     a new link. In some wireless network implementations, a change
of
>     physical link may not always require a change of primary care-of
>     address (i.e. both the old link and the new link may share the
same
>     access router and thus the same on-link prefixes). This change
of
>     physical link is referred to as a L2 handover. If the L2
handover
>     results in a change of access router, on-link prefixes and
>     subsequently a change of primary care-of address (i.e. the
prefix of
>     the primary care-of address is not one of the on-link prefixes
>     advertised by the new access router), then it is referred to as
a
>     L3 handover. The primary goal of movement detection is to detect
>     L3 handovers.
>
> Please let me know if you have objections to this addition, and/or
if you
> can suggest improvements.
>
> Thanks.
> - Ed
>
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ed Remmell
> Sent: Thursday, May 08, 2003 3:23 PM
> To: James Kempf; Jari Arkko
> Cc: Mobile IPv6 mailling list
> Subject: RE: [mobile-ip] Re: Current movement detection process
>
>
> James -
>
> Definitely. That's a tall order if you want to include any real MD
> guidelines for implementors, but that was my goal.
>
> Thanks.
> - Ed
>
> From: James Kempf [mailto:[email-masked]]
> Sent: Thursday, May 08, 2003 2:56 PM
> To: Jari Arkko; Ed Remmell
> Cc: Mobile IPv6 mailling list
> Subject: Re: [mobile-ip] Re: Current movement detection process
>
>
> But please...keep it simple.
>
>         jak
>
> ----- Original Message -----
> From: "Jari Arkko" <[email-masked]>
> To: "Ed Remmell" <[email-masked]>
> Cc: "James Kempf" <[email-masked]>; "Mobile IPv6 mailling
> list" <[email-masked]>
> Sent: Thursday, May 08, 2003 2:15 PM
> Subject: Re: [mobile-ip] Re: Current movement detection process
>
>
> > Ed Remmell wrote:
> > > OK, so then I don't need to spend any time this afternoon
> improving Jari's
> > > text, you feel that no further clarification is needed? Heck,
> that's fine by
> > > me!
> >
> > Ed: I think we do need to add at least a statement about what it
> means to
> > discovery that we didn't move after all, and maybe about the
> hysteresis.
> >
> > James: I think we already agreed with Ed that we don't do any of
the
> > finer stuff now, but now we are talking about details in the
> > remaining part.
> >
> > --Jari
> >
> >
>
>
>
>

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 12 May 2003 13:27:54 -0400

Erik,

 > > But there may be a difference between what is dangerous and
 > > what is simply non-optimal. Most folks agree that we can develop
 > > optimized movement detection schemes that use both NS and RS.
 > > But is sending RSes upon L2 trigger dangerous or simply 
 > non-optimal?
 > 
 > I don't feel I have much data.
 > 
 > My gut feel is that large 802.11 deployments are the ones 
 > that are at most
 > risk. I've been in IETF meetings where the 802.11 driver I use has
 > indicated down/up with a few seconds in between. Did all 600 
 > in the same
 > room see the same rate of down/up? I don't know.

=> I haven't personally done much coding with the
drivers, but I think the "up/down" terminology that
we're using can be misleading. There is an "up/down"
indication when the interface is started and when
the link is down, respectively. But I don't think 
that same trigger is given when an interface 
associates with a different AP. 
This does not contradict the point you're making above,
it's probably a separate point about the naming 
of this trigger. We might want to look for a better
name because most people think of the "up/down"
trigger as the one that they get when the interface
is started, which is not really what we're looking
for when we talk about movement.

Hesham

 > 
 > So perhaps the "probe" + "for furter study" language I 
 > suggested in another
 > email is a reasonably conservative way to move forward with 
 > this spec?
 > 
 > > So perhaps it would be better if instead of "the mobile node
 > > needs to send Router Solicitations" we would say "the mobile
 > > node performs Router Discovery".
 > 
 > Perhaps even be more explicit and point at a section in RFC 
 > 2461 that talks
 > about the timer and waiting for RAs?
 > 
 >    Erik
 >