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

From: Jari Arkko <[email-masked]>
Date: Sat, 03 May 2003 01:23:55 +0300

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: "James Kempf" <[email-masked]>
Date: Fri, 2 May 2003 15:34:54 -0700

I favor Erik's position about not mentioning anything, but if we must
mention something, then the text you've provided is best. I would
oppose anything more specific at this point, given our current state
of knowledge.

            jak

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 2 May 2003 16:18:58 -0700

This works for me.

Thanks.
- Ed

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jari Arkko
> Sent: Friday, May 02, 2003 3:24 PM
> To: Mobile IPv6 mailling list

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 02 May 2003 16:40:59 -0700

go ahead and close the issue. 

(grumbling) Vijay

---

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 5 May 2003 13:27:31 +0900

It looks reasonable to me. Thanks for nice work. 

JinHyeock

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 5 May 2003 13:02:10 +0200 (CEST)

Can you send out what all of the movement detection section would look like
with this change? It isn't clear to me all of what you are deleting.

>      default router and potentially to a new primary care-of address.

The above is potentially misleading since switching to a different default
router only helps when the new default router is advertising a different
set of prefixes.

>      been lost, or simply that there was no traffic on the link.

It would be better to say that the lack of such indications mean that
the reachability status from the default router to the mobile node
is unknown.

> This
>      no other traffic exists on the link.

s/traffic on the link/traffic from the default router/

> In this situation it may be

The last paragraph could use a warning about not constantly probing the
default router when there is no traffic.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Tue, 06 May 2003 01:45:07 +0300

> with this change? It isn't clear to me all of what you are deleting.

Yes. Here's a new version of the movement detection section:

11.5.1 Movement Detection

    The primary movement detection mechanism for Mobile IPv6 defined in
    this section uses the facilities of IPv6 Neighbor Discovery,
    including Router Discovery and Neighbor Unreachability Detection.
    The mobile node SHOULD supplement this mechanism with other
    information whenever it is available to the mobile node (e.g., from
    lower protocol layers).  The description here is based on the
    conceptual model of the organization and data structures defined by
    Neighbor Discovery [12].

    Mobile nodes SHOULD use Router Discovery to discover new routers and
    on-link subnet prefixes; a mobile node MAY send Router Solicitations,
    or MAY wait for unsolicited (periodic) multicast Router
    Advertisements, as specified for Router Discovery [12].  Based on
    received Router Advertisements, a mobile node maintains an entry in
    its Default Router List for each router, and an entry in its Prefix
    List for each subnet prefix that it currently considers to be
    on-link.  Each entry in these lists has an associated invalidation
    timer value.  While away from home, a mobile node typically selects
    one default router and one subnet prefix to use as the subnet prefix
    in its primary care-of address.  A mobile node MAY also have
    associated additional care-of addresses, using other subnet prefixes
    from its Prefix List.  The method by which a mobile node selects and
    forms a care-of address from the available subnet prefixes is
    described in Section 11.5.2.  The mobile node registers its primary
    care-of address with its home agent, as described in Section 11.7.1.

    In addition, the mobile node should consider the following events as
    indications that it may have moved:

    o  With some types of networks, indications about link-layer mobility
       might be obtained from lower layer protocols or device driver
       software within the mobile node.  However, all link-layer mobility
       indications do not necessarily indicate a movement of the mobile
       node to a new link, such that the mobile node would need to switch
       to a new default router and primary care-of address.  For example,
       movement of a mobile node from one cell to another in many
       wireless LANs can be made transparent to the IP level through use
       of a link-layer "roaming" protocol, as long as the different
       wireless LAN cells all operate as part of the same IP link with
       the same subnet prefix.  Therefore, link-layer indications do not
       guarantee that a movement has occurred.

       Upon receiving an indication of link-layer mobility, the mobile
       node SHOULD send Router Solicitations to discover the routers and
       prefixes on the new link.  The mobile node SHOULD also mark its
       link-local address as tentative, and follow standard Duplicate
       Address Detection procedures [13].

    o  If Router Advertisements that the mobile node receives include an
       Advertisement Interval option, the mobile node MAY use its
       Advertisement Interval field as an indication of the frequency
       with which it SHOULD expect to continue to receive future
       Advertisements from that router.  This field specifies the minimum
       rate (the maximum amount of time between successive
       Advertisements) that the mobile node SHOULD expect.  If this
       amount of time elapses without the mobile node receiving any
       Advertisement from this router, the mobile node can be sure that
       at least one Advertisement sent by the router has been lost.  It
       is thus possible for the mobile node to implement its own policy
       for determining the number of Advertisements from its current
       default router it is willing to tolerate losing before it SHOULD
       switch to a different router from which it may currently be
       correctly receiving Advertisements.

    o  In Router Discovery it is possible, even if improbable, that two
       routers on different links happen to be using the same link-local
       addresses.  Therefore, tracking the source address of Router
       Advertisements may not always be sufficient.  However, if the
       Router Advertisement sent by the current default router contains a
       modified Prefix Information option with the Router Address (R) bit
       set, and with the On-Link (L) flag set to indicate an on-link
       prefix, then the mobile node SHOULD check all subsequent Router
       Advertisements received from the same link-local address.  In this
       check, some of the Prefix Information options received in the new
       Advertisement should indicate the same global router address which
       was indicated earlier.

       If they do not contain the same address even if the Advertisement
       was sent from the same link-local address, this is an indication
       that a movement may have occurred.  In this case the mobile node
       SHOULD switch to a different router, such as the one from which it
       just received the Advertisement.

    o  When the mobile node is sending packets, it is important to
       quickly detect when the default router becomes unreachable.  To
       detect when its default router becomes unreachable, a mobile node
       SHOULD use Neighbor Unreachability Detection.

       In Neighbor Unreachability Detection indicates that the current
       default router is unreachable, the mobile node SHOULD switch to a
       new default router and potentially to a new primary care-of
       address.

    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, if possible, a new care-of address with a prefix other
    than those advertised by the current default router.  The following
    indications can give the mobile node some assurance that the default
    router can still reach it:

    o  With some types of networks, lower layer protocols in the mobile
       node may be able to indicate that a connection still exists with
       the current default router.

    o  When a mobile node receives any IPv6 packets from the link-layer
       address of its current default router (irrespective of the source
       IPv6 address) it SHOULD use that as an indication that it is still
       reachable from the router.

    o  Since the router sends periodic unsolicited multicast Router
       Advertisements, the mobile node will have an opportunity to check
       if it is still reachable from its default router, even in the
       absence of other packets to it from the router.

    o  On some types of network interfaces, the mobile node MAY also
       supplement this monitoring of Router Advertisements, by setting
       its network interface into "promiscuous" receive mode, so that it
       is able to receive all packets on the link, including those not
       addressed to it at the link layer (i.e., disabling link-level
       address filtering).  The mobile node will then be able to detect
       any packets sent by the router, in order to detect reachability
       from the router.  This use of promiscuous mode may be useful on
       very low bandwidth (e.g., wireless) links.  If this mode is
       supported, its use MUST be configurable, since it is likely to
       consume additional energy resources.

    The lack of such indications means that the reachability status from
    the default router to the mobile node is unknown.  This can happen,
    for instance, if the advertisement interval on the link is large,
    there are no indications from the link layer, and no traffic from the
    default router.  In this situation it may be necessary to probe the
    router in order to test for reachability.  Specific methods for
    probing are outside the scope of this specification.  However, such
    probing can cause unnecessary congestion on the link when there are
    many nodes with no packets to send.  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.

    Indications from lower protocol layers may also be useful to a mobile
    node in deciding to switch its primary care-of address to one of the
    other care-of addresses it has formed on this link.  For example, a
    mobile node MAY use signal strength or signal quality information
    (with suitable hysteresis) for its link with the available routers to
    decide when to switch to a new primary care-of address using that
    router rather than its current default router (and current primary
    care-of address).  Even though the mobile node's current default
    router may still be reachable in terms of Neighbor Unreachability
    Detection, the mobile node MAY use such lower-layer information to
    determine that switching to a new default router would provide a
    better connection.

--Jari

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 6 May 2003 16:59:30 +0900

Jari

Kindly find in line comments.

>        node SHOULD send Router Solicitations to discover the routers and

I think we'd better substitute 'SHOULD' with 'MAY'. Because MN may not 
send RS even after it received link-layer indication. 

For example, assume that only link-layer (and not IP subnet ) change happens 
and MN receives L2 trigger. MN can send NS to check the reachability of its 
current AR. If the current AR replies with solicited NA, MN has no need to 
send RS. 

>        new default router and potentially to a new primary care-of

In above, there are 4 events of movement indication. It seems to me that the 
last item is different with the previous ones. Does the last item describes the 
event which can be considered as indication of movement? I doubt. 

>     determine that switching to a new default router would provide a

Regards

JinHyeock

---

From: Jari Arkko <[email-masked]>
Date: Tue, 06 May 2003 12:39:32 +0300

Your proposed changes sound reasonable, thanks. --Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 May 2003 12:40:49 -0700

> current AR. If the current AR replies with solicited NA, MN has no need to

a better idea would be to do both simultaneously. if the 
current AR replies with a neighbor advertisement, the MN 
need not do anything. otherwise it should configure a new 
CoA and default router when it hears a router advertisement 
from a new router.

SHOULD is the right word. otherwise RS/RA exchange will be
delayed until the probing completes.

JinHyeock, the NS/NA probe was to used when there is no 
mechanism available for detecting movement and the MN hasnt
heard from its default router in a long time. it shouldnt 
be the default mechanism.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Tue, 6 May 2003 12:54:03 -0700

I agree with Vjay.

            jak

----- Original Message -----
From: "Vijay Devarapalli" <[email-masked]>
To: "JinHyeock Choi" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>; "Erik Nordmark"
<[email-masked]>; "Mobile IPv6 mailling list"
<[email-masked]>
Sent: Tuesday, May 06, 2003 12:40 PM
Subject: Re: [mobile-ip] Re: Current movement detection process

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 7 May 2003 14:56:58 +0200 (CEST)

>     indications that it may have moved:

I don't understand the "in addition". Logically the basic movement detection
should be stated above the "in addition" i.e. what information in router
advertisements is used to determine whether the MN is on the same or
on a different link. This is more or less covered in the 3rd bullet below.

>        Address Detection procedures [13].

I think the SHOULD is too prescriptive.
We want to keep the door open to implementations and/or future specifications
that say "first verify if the old default router is still reachable".
In general, from the "in addition" to the end of the section I don't
think there is a need for RFC 2119 terms.

I'd suggest loosening the above paragraph to say
	Upon receiving an indication of link-layer mobility, the mobile
	node might either verify whether the old default router is still
	reachable, and/or send Router Soliciations to discover new routers
	and/or prefixes on the (new) link.  If the mobile node determines
	that it has moved to a new link it also needs to perform Duplicate
	Address Detection [13] on its link-local address, form the Care-of
	address(es), etc. as specified in section XX.

(The last sentence is generic thus it probably belongs outside of the bulleted
list - perhaps above the "in addition" sentence.)

>        correctly receiving Advertisements.

The use of "SHOULD switch" implies that the above type of verification 
is not allowed.
It is better to say that 
								It
>        default router it is willing to tolerate losing before it
	[NEW] considers it likely that it has moved.

>     o  In Router Discovery it is possible, even if improbable, that two

The Connectathon experience indicates that the "even if improbable"
doesn't belong - it is common if the same router uses the same link
layer address on multiple interfaces.
So removing that and adding "For example, a router might use the same
link-local address on different interfaces." would be good.

>        set, and with the On-Link (L) flag set to indicate an on-link

I wonder if we should allow L and/or A to be set.
Either (or both) would contain a prefix associated with the link.

>        Advertisement should indicate the same global router address which

As I said above I think the above paragraph belongs above the "in addition"
with a lead-in saying something like:
	Mobile nodes use the information in received Router Advertisements.
	In doing so it needs to consider the following issues:
	The link-local addresses of routers are not globally unique, hence
	after movement the node might continue to receive RAs with the
	same link-local source address. This might be common if
	routers use the same link-local address on multiple interfaces.
	This issue can easily be avoided when routers use the Router Address (R)
	bit, since that provides a global address of the router.

	There might be multiple routers on the same link thus hearing a new
	router doesn't necessarily constitute movement.

	When there are multiple routers on the same link they might advertise
	different prefixes. Thus even hearing a new router with a new prefix
	might not be a reliable indication of movement. While it might be hard
	to initially avoid interpreting this as movement it is undesirable to
	treat a case with two (or more) routers advertising disjoint prefixes
	as movement each time a Router Advertisement is received. 

I think the actual text suggesting how to do movement detection would actually
need specific details, so perhaps it is sufficient to have the above 3 
considerations in the document.

>        SHOULD use Neighbor Unreachability Detection.

as specified in RFC 2461.

>        In Neighbor Unreachability Detection indicates that the current

s/In/If/

>     router can still reach it:

This part is logically inverted. Getting positive hits that the default
router can not reach the MN is useless, since the MN still needs to
know whether it can reach the default router (even though it defers determining
this until it needs to send packet). Getting a negative hint that the default
router can not reach the MN is useful. If this isn't fixed I think it will
lead to implementations that forgot to do NUD as long as they can hear the
router, which would be bad.

So changing the last sentence above to say:
	Lack of any of the following indications can give the mobile node
	a hint that it has either just lost bidirectional reachability
	with the current default router, and/or that it has moved to a

>        the current default router.

s/that a connection still exists/when a the connection to the current
default router has failed/

>        reachable from the router.

When the mobile node stops receiving any IPv6 packets from
the link-layer address of the current default router (irrespective of the
source IPv6 address) that could be an indication that it is no longer
reachable from the default router. Note that apart from the periodic multicast
Router  Advertisement the node can not be sure when the router will send
packets.

>        absence of other packets to it from the router.

Move this one to be the second in the list.
And change it to say "the absense of these advertisements is a hint
that the node might no longer be reachable from the router.
The advertisement interval option helps the mobile node to make
this determination rapidly."

>        consume additional energy resources.

Fold together with second bullet since the same "don't know what lack
of packets mean" applies?
Both bullets are trying to infer something from a change in the
traffic pattern by packets sent from the router. If the MN is too agressive
presumably it will cause additional verification traffic (e.g. doing NS/NA
to check if the router is reachable). Thus I think it would be wise
to mandate some form of rate limiting of such verification traffic when
the only hint is a instantaneous drop in the packet rate from the router to
zero.

>     attempted to determine reachability indications according to the list

The above paragraph seems superflous. But the issue (noted above) is
that we probably need to say something about the verification.

>     determine that switching to a new default router would provide a

Isn't the above a variant of the first bullet in the list with the information
being better than binary (link dead vs. a signal strength)?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 7 May 2003 15:28:36 +0200 (CEST)

> CoA and default router when it hears a router advertisement 

[I'm thinking about what to put in a future movement detection spec and
not in the base spec now.]

To avoid generating too much (multicast) traffic it might be
useful to have MNs that keep track of a decaying notion of
the accuracy of the movement hints.

Thus the MN gets a hint of type X it would base whether to
do just RS, RS+NS, or just NS based on this history
and then, based on whether it in fact had moved at L3 or not,
it would update that estimate. The "decaying" aspect is that you'd like
older information to have less of an impact on the estimate than
newer information.

Different types of hints, like a new AP at L2 vs. hearing a new router, 
might very well have different estimates thus it probably makes sense
to track this per type.

  Erik

---

From: Markku Savela <[email-masked]>
Date: Wed, 7 May 2003 16:25:24 +0300

This is just a side comment for consideration...

> From: Erik Nordmark <[email-masked]>

> think there is a need for RFC 2119 terms.

I'm somewhat troubled by the constant references to "default router".

IMHO, it would be much better to state: MN has moved in respect to
specific care-of address, when this address is no more valid
(e.g. address is deconfigured from interface).

There could be other reasons than just movement, when address becomes
invalid (like prefix expiring, someone manually deconfiguring it), and
it would be nice if the base mobile-ip specification would apply for
those two.

The true "mobile-ip movement detection" should be a different
RFC/document. When one implements "movement detection module", it
would deconfigure prefix/address when it detects movement (by whatever
logic, like by probing "default routers" or by some layer 2
signaling, or something else).

---

From: "James Kempf" <[email-masked]>
Date: Wed, 7 May 2003 08:55:19 -0700

Erik,

> address(es), etc. as specified in section XX.

I think there might be an interoperability problem unless this is a
SHOULD. Consider the following case. Suppose there is a link layer
where the requisite indication occurs and a particular host vendor
chooses not to implement RS sending upon receipt of the link layer
indication, because the specification doesn't require it. Suppose that
a user with such a host wanders into a network where the network
operator has turned down or off RA beaconing, perhaps because the 16.6
kbps overhead on the wireless link is considered too much, and,
besides, the link layer assist is available for high performance. Such
a host would not properly perform handover when it moves onto a new
subnet, because it would not detect the subnet change (unless it used
some other indication of router unreachability), or if it did, the
change would be detected very late, disrupting the host's IP traffic.

What this and the other comments you and others have made on this
section indicate to me is that the MD area is very tricky and that
trying to come up with a design that will be interoperable and perform
well this late in the process is fraught with the possibility of
casting something into the spec that may later turn out to be a
mistake. Perhaps that is not so serious, in that the spec is only
going to PS and not DS, but it might make sense to rethink trying to
refine any specification of movement detection in the base spec,
remove this section, and just leave the simple RA beaconing without
any refinements, since it has a track record in Mobile IPv4 and past
Mobile IPv6 interoperability tests, so that we can publish the base
spec. Then we can spend some time refining MD and have some confidence
that the refinements will have some sticking power.

                    jak

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 7 May 2003 18:21:55 +0200 (CEST)

> change would be detected very late, disrupting the host's IP traffic.

Yes, but I could make the same arguments about non-scalability
of solutions which always send a multicast RS each time there is
some hint. If the hint is "unreliable"  (see other message I sent today)
then doing a unicast NS/NA exchange to the current router.

Thus we are walking a fine line between saying enough in this document
to be useful yet not misleading to implementors, and specifying all of
the good movement detection work in the base specification.
I think the SHOULD language is misleading if we in fact will specify
NS/NA verification in some future movement detection specification.

> that the refinements will have some sticking power.

I'm trying to drive things to at least state clearly
how to tell from the RA whether you are on a new link, which seems useful
given the Connectathon experience, and pointing out issues
in and around movement detection. In my view stating "SHOULD do X" is
beyond this and belongs in a future movement detection specification.

  Erik

---

From: "James Kempf" <[email-masked]>
Date: Wed, 7 May 2003 09:54:07 -0700

> NS/NA verification in some future movement detection specification.

Why not simply drop this paragraph then? It is completely unrelated to
what information in an RA tells the mobile whether it has moved (re.
your comments below).

> beyond this and belongs in a future movement detection
specification.

Sure.  But there is much more in this section than that, e.g. putting
the interface into promiscuous mode. If you're happy with keeping
other stuff in, then I've not got an objection. We can always weed out
stuff that doesn't work or nobody implements on the next round.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 07 May 2003 10:30:57 -0700

> then doing a unicast NS/NA exchange to the current router.

no Erik. I would send an RS on a strong hint. not a weak hint.
an L2-up trigger is a very strong "hint". when you attach to
a new access point, there is a very high possibility that you
have changed the router (if not the IP subnet itself).

Jari's text says the MN SHOULD send an router solititation if
gets an indication of movement from the link layer.

for every other hint (based on listening to the traffic from
the router, listening to any traffic involving the router,
absense of router advertisements from the router, etc), the MN 
first probes to see if the old router is reachable and then
does router discovery.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 07 May 2003 10:41:46 -0700

Jari's text talks first about a strong hint that the MN has 
moved (the L2-up trigger). and what the MN should do when 
it gets the L2 trigger (send an RS according to RFC 2461). 
IMO, this is going to the most common mechanism for movement 
detection. we need to make sure we specify this correctly. 
doing router discovery is the right thing if there is an L2 
trigger. otherwise it could lead to interoperability problems 
that James Kempf mentioned.

the latter text talks about a bunch of weak hints for 
movement detection. these include not hearing router 
advertisements from the default router when you were supposed
to get one, not hearing any traffic from the default router,
hearing a new router, etc..... in this case, Jari's text
talks about first probing the current router to see if it is
still reachable. and then NUD followed by router discovery.

this makes sense to me.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 May 2003 02:29:17 +0300

Hi Erik,

Thanks for your suggestions regarding the text. I have taken them into
account, I think (but its 2 AM so...) and the new text is at:
http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#move

The discussion seemed to continue on:
- keyword language
- markku's suggestion on not talking about default routers
- your comment "it is sufficient to have the above 3 considerations
   in the document" which wasn't sure what you meant

> on a different link. This is more or less covered in the 3rd bullet below.

Ok, reading on...

> think there is a need for RFC 2119 terms.

I have tentatively put in this suggestion, but I see it being
discused on the list.

> list - perhaps above the "in addition" sentence.)

Ok.

> 	[NEW] considers it likely that it has moved.

Ok.

> link-local address on different interfaces." would be good.

Ok.

> Either (or both) would contain a prefix associated with the link.

I think so.

> 	as movement each time a Router Advertisement is received. 

Sounds good.

> considerations in the document.

Clarification: do you want to replace the movement detection section
with the above text, but not talk about the other things that are
currently listed? Or just delete the bullet about the same link
local?

> as specified in RFC 2461.

Ok.

> 	different default router and perhaps a different link:

Ok.

> Router  Advertisement the node can not be sure when the router will send

Ok.

> this determination rapidly."

Ok.

> the only hint is a instantaneous drop in the packet rate from the router to

Ok.

> that we probably need to say something about the verification.

I included the rate limiting part and made the paragraph shorter.

> being better than binary (link dead vs. a signal strength)?

Well, yes. I'm getting pretty desperate in trying to get the text crafted
for this section. The above does not appear to be an absolutely necessary
component of the base specification. So I deleted it.

--Jari

---

From: Greg Daley <[email-masked]>
Date: Thu, 08 May 2003 16:33:01 +1000

Hi Jari & Erik,

I'm still digesting the likely effect of changes to the
base draft, and have been analysing interactions
with the currently proposed text and other likely
movement detection/configuration optimizations.

It appears that there is a gravitation for the base
draft to suggest using NS/NA probing (or even full NUD)

>> as specified in RFC 2461.

I believe that there are still negative protocol
interactions which have not been considered, as
in the following example scenario:

MN Assumption: If the MN has received a link up trigger,
then it is advisable to treat the MN's link-local address
as tentative, the MN may be on a new link, where this address
collides with another node. (This can be done with Optimistic DAD).

If movement can be discounted (with an RA or NA) the
Link-local address is no-longer tentative.

The issue is that Optimistic DAD prevents sending (non-DAD)
NS messages from a tentative address. This is due to the
possibility of overriding neighbor cache entries when a
collision occurs.

In this case:
--> NS/NA (or NUD) cannot occur with the link-local address,
which prevents checking reachability with the current router.

While our team believes that this issue may be
correctable if the current AR advertised a global
'Router Address', I'm not sure that we have enough
experience with probing for Movement Detection to include
it as a succinct and complete solution in the draft spec.

I am very interested in exploring this mechanism for inclusion
in a follow-up document though.

Greg D.

---

From: Brett Pentland <[email-masked]>
Date: Thu, 08 May 2003 16:51:59 +1000

> that the refinements will have some sticking power.

I agree wish this.  RA beaconing is simple and well known and with the
higher rates allowed by MIPv6, not all that slow.  We've been thinking
about movement detection optimizations quite a bit lately and keep
coming across new pitfalls.

Even though NS/NA probing sounds simple, I don't think it has been fully
explored yet.  If an MN has an indication that it has moved to a new
network but it's not sure, what state are its addresses in?  Should they
be tentative?  If so then it can't send a unicast NS with a SLLAO.  This
may not be a huge problem because it's probably not a bad idea to hang
onto its global address(es) and probe using those - as long as the old
AR has included a global address in its RAs that can be the target.

In short, I think that existing MD methods (ie. missing RAs) are
sufficient for the base spec, and that these other optimizations should
be explored more fully and included in a movement detection
optimizations document when all the details have been ironed out.

Brett.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 May 2003 15:01:20 +0300

>>>>       SHOULD use Neighbor Unreachability Detection.

...

> collides with another node.

...

> which prevents checking reachability with the current router.

While I agree that the NS extra probing that was previously
discussed in the specification needs to be in another document,
I don't believe that we should start changing normal reachability
tests that IPv6 is already doing while communicating with other
nodes.

The issue with the text that you quoted above is priority,
i.e. if if you get a movement hint then even such basic
things as regular IPv6 control signaling (NUD) or payload
traffic needs to stop, until we have done whatever it is
that we need to do when we move. Whether or not we actually
moved is irrelevant, imho.

We may optimize this, but has to happen later.

> it as a succinct and complete solution in the draft spec.

Agreed, for the extra probing. I don't think we should
start changing regular NUD.

> in a follow-up document though.

Yes, me too... (assuming I ever finish this document)

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 May 2003 16:33:28 +0300

> (e.g. address is deconfigured from interface).

I think you are right in that the prefixes need to be considered.
But we also need to track the default router. Otherwise, we could
be sending our outgoing packets to /dev/null.

I changed the beginning of 11.5.2 (Forming a Care-of Address)
to the following text to make this clearer:

  "After detecting that it has moved a mobile node SHOULD generate a new
   primary care-of address using normal IPv6 mechanisms. This SHOULD also
   be done when the current primary care-of address becomes deprecated."

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 May 2003 19:01:38 +0300

I'm becoming more and more concerned that nailing down text that
everyone agrees upon for movement detection is too hard. In this e-mail
I'll attempt to summarize the issues and propose a way forward.

So far, we've done the following:
- removed claims that inbound reachability proves symmetric reachability
- clarified that NUD is neither replaced or modified
- added a discussion of what to look at in the RAs for movement detection
- clarified that mobile nodes need to track prefix lifetimes as well
- added warnings about bad effects of careless probing
- added a requirement that after movement you should do DAD etc
- clarified the implications of the dont-hear-router -indications
- removed most of the keywords
- made many text changes
- agreed that a full-blown movement detection is done later, separately

The current text is here:
http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#move

Looking at the discussion and the current result, I believe we still
have the following issues:

#1 Whether to use keyword for sending the RS upon L2 up indication.

#2 Whether to include anything beyond regular RAs, L2 indications,
    and AI. That is, should the NUD discussion be kept? Should the
    inbound reachability discussion be kept, should the probing
    text be kept?

#3 The text is weak in that it does not say how to make the
    jump from "may have moved" to "has moved". For instance,
    the bullet item about the use of the AI information does
    not say what to *do* if you miss too many RAs. Same thing
    with lack of inbound reachability; probing is discussed
    but not in a way that allows anything to be implemented.

#4 I don't think the logic of the last bullet item list
    is right, even with Erik's improvements. The lead in
    paragraph talks about lack of indications, but the
    list items are about e.g. L2 failure or lack of any
    packets from the router.

Here's what I'd like to do in order to move forward:

First, based on the lack of actual instructions on what can
be done, I'm not sure how helpful the inbound reachability
discussion is. Perhaps we should just explain that when
the MN is not sending anything and AI option not used or
interval is too long then the mobile node could get out
of coverage without knowing. That is, point the reader
to a limitation of this specification and leave it at
that.

Secondly, we could perhaps delete the NUD text because
IPv6 specifications require you to do that anyway in
the usual way.

Thirdly, I'd like to keep the L2 "change" or "up" indication,
and I'd like it to say "needs to send RS".

Fourth, I'd like to make miss-too-many-RAs-per-AI an
equally strong hint as the L2 "up" indication is.
Therefore, both the L2 and the miss-too-many-RAs-per-AI
indications would allow you to conclude that you are
on a new link.

Comments?

Sample text below:

11.5.1 The Incredibly Shrinking Section

    from its Prefix List.

    If the mobile node determines that it has moved to a new link it
    needs to perform Duplicate Address Detection [13] on its link-local
    address, form the care-of address(es) as described in Section 11.5.2,
    and register its primary care-of address with its home agent, as
    described in Section 11.7.1.

    Mobile nodes use the information in received Router Advertisements.
    In doing so the mobile node needs to consider the following issues:

    o  There might be multiple routers on the same link thus hearing a
       new router does not necessarily constitute movement.

    o  When there are multiple routers on the same link they might
       advertise different prefixes.  Thus even hearing a new router with
       a new prefix might not be a reliable indication of movement.
       While it might be hard to initially avoid interpreting this as
       movement it is undesirable to treat a case with two (or more)
       routers advertising disjoint prefixes as movement each time a
       Router Advertisement is received.

    o  The link-local addresses of routers are not globally unique, hence
       after movement the node might continue to receive Router
       Advertisements with the same link-local source address.  This
       might be common if routers use the same link-local address on
       multiple interfaces.  This issue can easily be avoided when
       routers use the Router Address (R) bit, since that provides a
       global address of the router.

    o  If Router Advertisements that the mobile node receives include an
       Advertisement Interval option, the mobile node may use its
       Advertisement Interval field as an indication of the frequency
       with which it should expect to continue to receive future
       Advertisements from that router.  This field specifies the minimum
       rate (the maximum amount of time between successive
       Advertisements) that the mobile node should expect.  If this
       amount of time elapses without the mobile node receiving any
       Advertisement from this router, the mobile node can be sure that
       at least one Advertisement sent by the router has been lost.  It
       is thus possible for the mobile node to implement its own policy
       for determining the number of Advertisements from its current
       default router it is willing to tolerate losing before it
       considers it likely that it has moved.

    Upon receiving such indications, the mobile needs to send Router
    Solicitations to discover routers and prefixes on the new link.

    Note that while the mobile node is on a link, it use normal IPv6
    mechanisms such as Neighbor Unreachability Detection [ref] to track
    reachability of the default router. However, such tracking is
    performed only when the mobile node has packets to send, and in the
    absence of frequent Router Advertisements or indications from the
    link-layer, the mobile node might become unaware of a movement
    that occurred.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Thu, 8 May 2003 09:28:50 -0700

Jari,

The proposed new text looks fine.

            jak

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; "Mobile IPv6 mailling
list" <[email-masked]>
Sent: Thursday, May 08, 2003 9:01 AM
Subject: Re: [mobile-ip] Re: Current movement detection process

> The current text is here:
http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#m
ove

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 8 May 2003 11:07:07 -0700

Jari -

So, we completely remove any discussion about why it is important for the MN
to avoid moving if it is unnecessary? I.e. some form of hysteresis that has
the MN first verify that its current default router is truly unreachable
("probe using unicast NS") before assuming movement to a new link? The way
this reads now, whenever you get an indication of movement, you assume a L3
move has occurred, you send a RS to discover new routers and new prefixes on
the new link. What if you no L3 move has occurred? What if your current
default router is still bi-directionally reachable? I do not think you
should switch away from it in that case.

Also, a clarification about the L2 link-up event: this could mean that you
have moved to a new access point, and not a new access router (i.e. L2 move,
but not L3 move), and also it could indicate that you have temporarily moved
off of and then back onto the SAME LINK. It will happen that a wireless
device experiences a temporary loss of wireless connectivity due to
interference, sunspots, obstacles blocking the transmission path, fading,
entering a RF null, terrain, any number of things... and it is quite likely
that if the mobile node is actually moving at the time, that this loss of RF
connectivity will be temporary, and then it comes back on the same link. So,
it gets a L2 link-up event notification, should it assume that this is a L3
move?

I think there needs to be some mention in this text that is important for
the MN to not switch away from a default router if that default router is
still bi-directionally reachable, which can be confirmed by probing it using
a unicast NS for example.

I guess we've backed off on making the recommendation to probe with unicast
NS because of the potential that the MN has moved to a new link, and that
the link-local scope address it is using is actually a duplicate address on
that new link? What are the chances of that happening... you don't mention
that as a potential issue with using NUD with Mobile IPv6, but it is the
same type of probe. If you want really fast handoffs, then uses a globally
unique interface ID (derived from the MAC layer address, for example),
disable DAD on the mobile interface, etc. Otherwise, use something like
optimistic DAD, which allows you to respond to an Address Resolution request
on your tentative link-local scope address with a NA that has the Override
bit cleared. Otherwise, you'd have to wait 1 second for DAD to complete
(after suspecting link movement, and restarting DAD on your link-local scope
address) before you can respond to address resolution requests made on your
link-local scope address. This kind of information doesn't need to go into
the spec, instead I'd just like to see the simple addition of some text that
says that the MN should not switch away from a perfectly good
bi-directionally reachable router until it knows that it is no longer
reachable. Or, at least the MN implements some kind of hysteresis to avoid
switching too frequently. W/ regards to what does "too frequently" mean,
well what you are trying to avoid is all of the extra overhead involved in
forming a new primary CoA, updating your home registration with the new
primary CoA, updating peers that you perform route optimization with with
you new primary CoA, etc.

Thanks.
- Ed Remmell
Elmic Systems, USA

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jari Arkko
Sent: Thursday, May 08, 2003 9:02 AM
To: James Kempf
Cc: Erik Nordmark; Mobile IPv6 mailling list
Subject: Re: [mobile-ip] Re: Current movement detection process

Comments?

Sample text below:

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 May 2003 23:08:50 +0300

> it gets a L2 link-up event notification, should it assume that this is a L3

I think we need to say something about finding out that the
suspected move was not really a move. Also about hysteresis.

But it doesn't appear to be possible to agree on bullet
proof text for the NS probe before we have thought about
it some more, with the DAD implications etc.

[This doesn't mean you couldn't do it in your product, however.
Many people are probably going to do something like that, and
later we will standardize the right way to do it. Remember that
at least the simple probing schemes use existing protocol
messages, routers aren't really affected, even if the quality
and efficiency of the different MN implementations could vary
significantly.]

> address) before you can respond to address resolution requests made on your

Agree on all of the above, but it sounds to me like we have efforts
in place to eventually have specifications for all of the above.

> you new primary CoA, etc.

Agreed. Care to post some text for that?

--Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 8 May 2003 13:12:35 -0700

> Agreed. Care to post some text for that?

OK, I will work on it this afternoon. I'll go through all of the latest
postings on MN, massage/restructure the latest text for MD you posted, and
make these additions where it makes sense. I should have some new/proposed
MD text to send to the list later today.

Thanks.
- Ed

---

From: "James Kempf" <[email-masked]>
Date: Thu, 8 May 2003 14:00:00 -0700

Hi Ed,

I'm sorry, but I don't read it this way. What I read is "use RFC 2461
Router Discovery". That's really all we need for now because that's
all that's been proven to work. The considerations you've brought up
are interesting and valuable, but  putting them into the spec at the
last minute without multiple implementations, testing, and further
discussion is asking for trouble. Once code gets into millions of
hosts, it's pretty difficult to remove. The Monash guys and us here at
DoCoMo have studied this problem for about two years, and there are
still alot of issues to work out. We should wait until after the spec
is done, then return specifically to the issue of MD, try out some of
your ideas, and those of others, and either put the result into the
next round of the base MIP spec, or have a separate spec that
explicitly deals with MD and local link movement.

            jak

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

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 8 May 2003 14:09:01 -0700

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

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

Hi Ed,

            jak

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 May 2003 00:15:02 +0300

> text, you feel that no further clarification is needed? Heck, that's fine by

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: "Ed Remmell" <[email-masked]>
Date: Thu, 8 May 2003 14:16:18 -0700

Jari -

OK, will do. Also, when I was reading through your text, the structure was a
little difficult, so I plan to try to improve on that. That's what I meant
by "massage/restructure".

Thanks.
- Ed

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

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Thu, 8 May 2003 14:56:23 -0700

But please...keep it simple.

        jak

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 8 May 2003 15:23:07 -0700

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

-----Original Message-----
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

        jak

---

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

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

-----Original Message-----
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 -

Thanks.
- Ed

-----Original Message-----
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

        jak

---

From: Greg Daley <[email-masked]>
Date: Fri, 09 May 2003 11:02:28 +1000

Hi Ed,

It sounds like a succinct definition of MD to me.
I prefer using the terms link-layer and network-layer
(instead of L2, L3) though.

What does the rest of the MIPv6 document use?

Greg

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

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 8 May 2003 17:23:01 -0700

Greg -

Good point. But, L2 is used in other contexts in other related drafts, such
as L2 triggers, etc. So, how about the following:

Definitions added to Section 3.2:

    L2 handover - process by which the mobile node changes from one
    link-layer connection to the Internet to another. For example, a
    change of wireless access point is a L2 handover.

    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 primary care-of address. For example, a change of access
    router subsequent to a change of wireless access point typically
    results in a L3 handover.

    For some wireless 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.
...

I can change it to "network-layer handover", but then "L3 handover" is more
succinct and IMO clearly defining it in section 3.2 should take care of the
any confusion introduced by a new term like "L3". Same goes for L2. But if
you disagree... I'll change it.

Thanks.
- Ed

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

Hi Ed,

Greg

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 8 May 2003 17:24:24 -0700

Some more proposed changes to existing MD text:

"The primary movement detection mechanism for Mobile IPv6 defined in
    this section
    The mobile node SHOULD supplement this mechanism with other
    information whenever it is available to the mobile node (e.g., from
    lower protocol layers).  The description here is based on the
    conceptual model of the organization and data structures defined by
    Neighbor Discovery [12]."

Well, everyone has agreed that this generic movement detection isn't really
fast enough w/ just regular NUD, also it isn't complete enough w/out the
addition of checking for reachability from the current default router. I
want to rework this to highlight the fact that this section is more
informational, and additional optimizations will need to be implemented on
top of generic move detection (i.e. NUD), but that the purpose of this
specification is not to specify what those
optimizations are. So, here is some new text for this paragraph:

"This section does not attempt to specify a generic movement detection
algorithm which will function optimally for all types of applications,
link-layers and network topologies, instead for informational purposes it
describes one method which uses the facilities of IPv6 Neighbor Discovery,
including Router Discovery and Neighbor Unreachability Detection. This
method is generally considered to be too slow, and therefore the mobile node
SHOULD supplement it with other information whenever it is available to the
mobile node (e.g., from lower protocol layers).  The description here is
based on the conceptual model of the organization and data structures
defined by Neighbor Discovery [12]."

Comments?

Thanks.
- Ed

-----Original Message-----
Sent: Thursday, May 08, 2003 4:36 PM

Thanks.
- Ed

-----Original Message-----

James -

Thanks.
- Ed

-----Original Message-----
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

        jak

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: "Ed Remmell" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "Mobile IPv6 mailling

improving Jari's
that's fine by
means to
hysteresis.

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 8 May 2003 17:26:52 -0700

"network topologies" => "deployment scenarios" (thanks, James)

Thanks.
- Ed

-----Original Message-----

Thanks.
- Ed

-----Original Message-----

James -

Thanks.
- Ed

-----Original Message-----
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

        jak

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: "Ed Remmell" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "Mobile IPv6 mailling

improving Jari's
that's fine by
means to
hysteresis.

---

From: Greg Daley <[email-masked]>
Date: Fri, 09 May 2003 12:25:05 +1000

Hi Ed,

I don't mind so long as there is consistency within a draft.
We're not writing an academic paper..

Greg

Ed Remmell wrote:
> ....

---

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

This section in MD:

    "Mobile nodes SHOULD use Router Discovery to discover new routers and
    from its Prefix List."

I'm not sure how useful it is. Using Router Discovery to discover new
routers and on-link subnet prefixes is standard IPv6 behavior, why does it
need to be mentioned here qualified by "SHOULD". Also, MAY send Router
Solicitions, MAY wait for unsolicited RAs, - no specific requirement here.
Also, the rest of the paragraph repeats standard Neighbor Discovery
processing, except for this:

    "While away from home, a mobile node typically selects
    one default router and one subnet prefix to use as the subnet prefix
    in its primary care-of address.  A mobile node MAY also have
    associated additional care-of addresses, using other subnet prefixes
    from its Prefix List."

The additional care-of addresses part is already described in section 11.5.2
Forming New Care-of Addresses, therefore part of this is redundant.

So, here is the rewrite of this paragraph, combining it with a related
paragraph (and with some new information discussing why hysteresis should
generally be used to stick with a default router that is still
bi-directionally reachable, because of the additional signalling overhead
required to update mobility bindings in the home agent and in correspondent
nodes with the new primary care-of address):

"When the mobile node detects a L3 handover, it performs Duplicate Address
Detection [13] on its link-local address, Router Discovery to select a new
default router, Prefix Discovery with that router to form new care-of
address(es) as described in Section 11.5.2, and then it registers its new
primary care-of address with its home agent as described in Section 11.7.1,
and also updates the associated mobility bindings in correspondent nodes
that it is performing route optimization with as specified in Section
11.7.2. Because of the additional protocol signalling overhead involved in
the mobile node updating the home agent and correspondent nodes with its new
care-of address, as well as the temporary interruption of network
connectivity caused by the L3 handover process and the potential for dropped
packets, generally L3 handovers should be avoided. Specifically, if the
mobile node detects that the old default router on the old link is still
bi-directionally reachable, it should generally continue to use that router
rather than switch away from it to use a new default router."

I'm not in favor of making any of this a requirement (i.e. SHOULD instead of
should) because there is at least one case when it makes sense to switch
away from a perfectly good default router, specifically when the mobile node
supports multiple interfaces, and one interface that wasn't available before
(i.e. 802.11) is now available and offers a better quality of service and
higher throughput than the interface (for example, Bluetooth) that the
current default router was discovered on. However, I think this is a useful
guideline for implementors.

Comments?

Thanks.
- Ed

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 8 May 2003 18:45:02 -0700

Because of the part that I added about hysteresis (see new text below), part
of the following MD text is now unnecessary:

    o  When there are multiple routers on the same link they might
       advertise different prefixes.  Thus even hearing a new router with
       a new prefix might not be a reliable indication of a L3 handover.
       While it might be hard to initially avoid interpreting this as
       a L3 handover, it is undesirable to treat a case with two (or more)
       routers advertising disjoint prefixes as a L3 handover each time a
       Router Advertisement is received.

This can now be shortened to:

    o  When there are multiple routers on the same link they might
       advertise different prefixes.  Thus even hearing a new router with
       a new prefix might not be a reliable indication of a L3 handover.

Thanks.
- Ed

-----Original Message-----
Sent: Thursday, May 08, 2003 6:31 PM

---

From: Greg Daley <[email-masked]>
Date: Fri, 09 May 2003 13:01:54 +1000

Hi Ed,

I think that we may be able to provide more text structure
and be more succinct on a couple of points:

This is just using the points that you've got in your paragraph:

"When the mobile node detects a L3 handover, it performs Duplicate 
Address Detection [13] on its link-local address, Router Discovery
to select a new default router and Prefix Discovery with that router to 
form new care-of address(es) as described in Section 11.5.2.
Subsequently the MN performs mobility signaling to the HA (Section
11.7.1) and CNs (Section 11.7.2) in order to inform them
of the change of CoA.

Due to the temporary packet flow disruption and overhead involved in
performing binding signaling, the MN should avoid performing L3
Handovers unless they are strictly necessary.
Specifically, if the MN detects that the curently selected default
router on the old link is still bi-directionally reachable, it should
generally continue to use that router rather than switch away from it
to use a new default router."

I'm not sure if this is more readable, but I generally think that
paragraphs which are short are easy to digest.

What do you think?

Greg

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 8 May 2003 19:23:24 -0700

Greg -

Works for me, thanks!

- Ed

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

Hi Ed,

What do you think?

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 May 2003 14:38:25 +0200 (CEST)

> gets an indication of movement from the link layer.

Yes, and it doesn't say "strong hint" as you said above.
Defining the difference between a "weak" and "strong" hint
I think is best left to a future document.

We seem to be in volient agreement about reasoanble ways to 
specify this with the disagreement being what text to put in the base
document.
FWIW I don't think "indication of movement from the link layer"
necessarily is a strong hint of L3 movement - it might just be a different
AP in 802.11 while still on the same link.

> first probes to see if the old router is reachable and then

But the document doesn't say "SHOULD probe" hence there is an imbalance
which will make folks that try to implement from the spec likely
to send a mutlicast RS too often.
And we can't say "SHOULD probe" without actually defining what "probe"
means. Thus saying less in the base spec is better than saying more.

  Erik

---

From: "James Kempf" <[email-masked]>
Date: Fri, 9 May 2003 07:52:01 -0700

fine by me.

            jak

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

> > I want to add the following new definitions to the beginning of
the
> movement

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 May 2003 23:12:35 +0200 (CEST)

> > I think the actual text suggesting how to do movement detection would
> actually > need specific details, so perhaps it is sufficient to have the
> above 3  > considerations in the document.
> 

Let me go look at the proposed new text.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 10 May 2003 00:29:03 +0200 (CEST)

> and I'd like it to say "needs to send RS".

I have the same concerns as Ed that the L2 indication might not
imply L3 movement.
But going into when it is best to assume movement (addresses marked tentative,
send RS) and assume non-movement (unicast NS with no SLLA option),
is best left to the movement detection spec. This might be a function
of the type of L2, or other deployment related issues.
So perhaps we need to leave L2 indications out of the base spec?

Or add some useful warnings about how implementations can cope with L2's
that give up/down indications that are not related to L3 movement?

> indications would allow you to conclude that you are

At least it is an indication that you are disconnected from the current
default router. Sending an RS will tell you if there are other default
routers (and whether they are on the same link or not) as the previous
default router.
But I think the miss-too-many-RAs-per-AI is actually stronger than an L2
down/up indication (at least based on observing down/up events using 802.11
at IETF meetings :-)

  Erik

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 9 May 2003 17:13:51 -0700

Erik -

> So perhaps we need to leave L2 indications out of the base spec?

L2 indications are generally pretty essential to any kind of usable MIPv6
movement detection. So, since this new rewrite of the movement detection
section is all informational, it doesn't hurt to at least provide the basis
for the future movement detection spec. w/ regards to having a general
discussion of the main MD issues, core MD functionality and key definitions.

> that give up/down indications that are not related to L3 movement?

I'd say if you get a L2 indication of link-up, and you don't know for sure
it is a L3 handover, you should probe your default router to see if it is
still bi-directionally reachable (there's that "probe" word again that we've
been trying to avoid lately) - if it isn't, then assume L3 handover and
start soliciting for a new router.

> down/up indication (at least based on observing down/up events

Yes, miss-too-many-RAs-per-AI is an indication of L3 handover.

Thanks.
- Ed

---

From: Jari Arkko <[email-masked]>
Date: Sat, 10 May 2003 10:30:57 +0300

Re: L2 does not imply L3 movement & possibly leaving L2
indications out of the base spec. I agree with Ed here,
talking about L2 indications seems necessary, and it
doesn't hurt given the new informative nature of this
section. Erik talked about adding a warning about the
rate of RAs based on L2 indications, and Ed talked about
probing. I agree with Ed, but I wouldn't attempt to put the
probing text in the base spec. Instead, we can extend
the current warning to say that implementations need
to be careful about sending RAs due to these concerns.
Suggested text at the end of this e-mail.

Re: Erik's issue about the order of detecting L3 handover
and doing Router Discovery. I'm happy with Ed's new
formulation "... selects a new default router as a
consequence of Router Discovery...". It nicely hides
the time that this happens.

Re: difference between symmetric and inbound reachability.
The new text looks good.

Conclusion: I think this issue is now resolved, pending
Erik's Ok that we mention RA rate limitation for L2
indications. Thank you Ed for the text! I have put the
new text in the web as well. And lets continue the
discussion about full movement detection, probing,
and so on in the list and in the form of drafts...

--Jari

    The primary goal of movement detection is to detect L3 handovers.
    This section does not attempt to specify a fast movement detection
    algorithm which will function optimally for all types of
    applications, link-layers and deployment scenarios; instead, it
    describes a generic method that uses the facilities of IPv6 Neighbor
    Discovery, including Router Discovery and Neighbor Unreachability
    Detection.  At the time of this writing, this method is considered
    well enough understood to recommend for standardization, however it
    is expected that future versions of this specification or other
    specifications may contain updated versions of the movement detection
    algorithm that have better performance.

    Generic movement detection uses Neighbor Unreachability Detection to
    detect when the default router is no longer bi-directionally
    reachable, in which case the mobile node must discover a new default
    router (usually on a new link).  However, this detection only occurs
    when the mobile node has packets to send, and in the absence of
    frequent Router Advertisements or indications from the link-layer,
    the mobile node might become unaware of an L3 handover that occurred.
    Therefore, the mobile node should supplement this method with other
    information whenever it is available to the mobile node (e.g., from
    lower protocol layers).

    When the mobile node detects an L3 handover, it performs Duplicate
    Address Detection [13] on its link-local address, selects a new
    default router as a consequence of Router Discovery, and then
    performs Prefix Discovery with that new router to form new care-of
    address(es) as described in Section 11.5.2.  It then registers its
    new primary care-of address with its home agent as described in
    Section 11.7.1.  After updating its home registration, the mobile
    node then updates associated mobility bindings in correspondent nodes
    that it is performing route optimization with as specified in Section
    11.7.2.

    Due to the temporary packet flow disruption and signaling overhead
    involved in updating mobility bindings, the mobile node should avoid
    performing an L3 handover until it is strictly necessary.
    Specifically, when the mobile node receives a Router Advertisement
    from a new router that contains a different set of on-link prefixes,
    if the mobile node detects that the currently selected default router
    on the old link is still bi-directionally reachable, it should
    generally continue to use the old router on the old link rather than
    switch away from it to use a new default router.

    Mobile nodes can use the information in received Router
    Advertisements to detect L3 handovers.  In doing so the mobile node
    needs to consider the following issues:

    o  There might be multiple routers on the same link, thus hearing a
       new router does not necessarily constitute an L3 handover.

    o  When there are multiple routers on the same link they might
       advertise different prefixes.  Thus even hearing a new router with
       a new prefix might not be a reliable indication of an L3 handover.

    o  The link-local addresses of routers are not globally unique, hence
       after completing an L3 handover the mobile node might continue to
       receive Router Advertisements with the same link-local source
       address.  This might be common if routers use the same link-local
       address on multiple interfaces.  This issue can be avoided when
       routers use the Router Address (R) bit, since that provides a
       global address of the router.

    In addition, the mobile node should consider the following events as
    indications that an L3 handover may have occurred.  Upon receiving
    such indications, the mobile node needs to send Router Solicitations
    to discover routers and prefixes on the new link.

    o  If Router Advertisements that the mobile node receives include an
       Advertisement Interval option, the mobile node may use its
       Advertisement Interval field as an indication of the frequency
       with which it should expect to continue to receive future
       Advertisements from that router.  This field specifies the minimum
       rate (the maximum amount of time between successive
       Advertisements) that the mobile node should expect.  If this
       amount of time elapses without the mobile node receiving any
       Advertisement from this router, the mobile node can be sure that
       at least one Advertisement sent by the router has been lost.  The
       mobile node can then implement its own policy to determine how
       many lost Advertisements from its current default router
       constitute an L3 handover indication.

    o  Neighbor Unreachability Detection determines that the default
       router is no longer reachable.

    o  With some types of networks, notification that an L2 handover has
       occurred might be obtained from lower layer protocols or device
       driver software within the mobile node.  However, for some
       wireless technologies and deployment scenarios, an L2 handover may
       not always require an 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.  Therefore, link-layer indications do not
       guarantee that an L3 handover has occurred.  For this reason
       mobile nodes should limit the rate at which they send Router
       Solicitations based on link-layer indications.

---

From: Brett Pentland <[email-masked]>
Date: Mon, 12 May 2003 11:48:15 +1000

Hi Jari,

The text looks good (thanks also to Ed).

I have one slight concern about the very last sentence about rate
limiting RSs following L2 triggers.  I wonder how one would go about
implementing this sentence without more explicit guidance.  In any case,
RSs are sent to the (presumably fairly small) all-routers multicast
group, and multicast responses are already rate-limited per RFC-2461. 
Should a router choose to send unicast responses it is less of a problem
anyway.  While I think it's completely appropriate for the base draft to
consider how its use may burden networks (by rate-limiting, etc.), I
don't this particular case is all that much of a problem.

In short, I don't think the last sentence really adds much.

Regards,
Brett.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 May 2003 10:42:08 +0300

> don't this particular case is all that much of a problem.

Rate-limiting of RSes upon receiving a L2 trigger was one of
the possibilities Erik suggested as a remedy for the worries
that L2 movement doesn't imply L3 movement. I think the issue
is mainly that the decision of whether to assume movement (send
RS etc) or non-movement (probe current default router) needs
to be explored more fully in the movement detection draft. So
I guess the concern was that if the text says "send RS upon L2
trigger", the reader is left with a too simplistic view of the
situation.

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?

Brett, you argued above for the safeguards already in present
in RFC 2461 for the RAs. I'd like to add two points:

  o  There's a random 0..1s delay for sending RSes mandated
     by RFC 2461. This works as a rate limitation as well,
     in the worst case you could be sending 2 RSs/s.

  o  Sending an RS upon L2 up trigger is the current
     behaviour in RFC 2461. Section 6.3.7:

     "Router Solicitations may be sent after any of
      the following events:

       - ...

       - The host attaches to a link for the first time.

       - The host re-attaches to a link after being detached for some
         time."

In conclusion, perhaps sending RSes is simply non-optimal (and
we warn about the non-optimality of MD already) and not dangerous.
Therefore, we could skip the rate limitation text.

Erik, what do you think?

--Jari

---

From: Brett Pentland <[email-masked]>
Date: Mon, 12 May 2003 18:15:37 +1000

>      in the worst case you could be sending 2 RSs/s.

This doesn't actually rate limit a large number of hosts soliciting, but
does desynchronize them.  There is rate limiting on the multicast
responses (RAs), however.

> Therefore, we could skip the rate limitation text.

Sounds fine to me.

Brett.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 May 2003 12:29:23 +0300

Brett Pentland wrote:
> does desynchronize them.

But wouldn't the host skip sending its own RS if it already has
heard RAs sent to the all-node mc address due to the other hosts'
requests?

The behaviour is by the way the same regardless of the hint that
we get -- the same large group of hosts could be travelling in a
train and all decide at the same time that too many periodic RAs
have been missed.

That this, if the mobile node has a hint of movement (L2,
missed RAs per AI, NUD fails), IMHO it enters a state where
it wants to send an RS, but is waiting for the 0..
MAX_RTR_SOLICITATION_DELAY timer before it can actually
do so. If it receives RAs during this time, it should
conclude that it has moved and not send an RS.

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".

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 12 May 2003 15:54:32 +0200 (CEST)

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

So perhaps the "probe" + "for furter study" language I suggested in another
email is a reasonably conservative way to move forward with this spec?

> 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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 May 2003 10:42:08 +0300

- ...

Erik, what do you think?

--Jari

.

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 12 May 2003 10:26:10 -0700

Jari -

> node performs Router Discovery".

Awesome. This works for me, thanks.

- Ed

---

From: Brett Pentland <[email-masked]>
Date: Tue, 13 May 2003 12:49:06 +1000

> heard RAs sent to the all-node mc address due to the other hosts'

Yes, good point - I missed that.  Routers may choose to unicast their
responses but that is hopefully less of a problem (though it still chews
up some bandwidth on a shared medium).
> node performs Router Discovery".

This is fine with me, or possibly with Erik's suggestion of specific
references to RFC-2461.

Brett.