Subject: RE: [mobile-ip] newest text for MIPv6 movement detection

From: "Ed Remmell" <[email-masked]>
Date: Fri, 9 May 2003 16:20:48 -0700

Erik -

> Much improved!

Thanks! Yes, there was some baggage still in the other text, remnants and
structure leftover from prior drafts. It was really starting to get on my
nerves, so I just had to step in and clean it up ;-)

> >     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 an L3 handover.
>
> The above reads as if it prefers only one default router per link.
> But I can live with the text as it is; a future document can make
> this more clear.

It is actually easier to implement (correctly, I should say - anyone can do
it the sloppy way) mobile node movement detection if you treat the
association with the current default router as a virtual link, and then when
you switch away from that router all prefix information (and associated
CoAs) you discovered using it needs to be immediately invalidated (assuming
that those prefixes aren't advertised by the new router you switch to). In
our implementation, when mobile node functionality is active, we filter
Prefix Discovery and Parameter Discovery (not Router Discovery obviously)
using the current default router. So, we in effect treat each router as its
own virtual link. This handles the case of multiple routers on the same link
advertising different sets of prefixes the same as those same routers on
different physical links but interfering with each other so that they appear
to the MN to be on the same link/channel/etc. Anyways, what does the mobile
node need multiple routers for on a foreign link? It just needs one that
works (bi-directionally reachable, that is) and that advertises global scope
prefixes, to discover global prefixes from that it can use to auto-configure
its primary CoA. BTW, it would be a very bad idea (IMO) for the MN to
implement some kind of round-robin approach to load balancing on the foreign
link by sending successive packets out different default routers in its
default router list. Restricting the MN to having only a single router in
its default router list when operating on a foreign link may not be a bad
recommendation, but I know it will piss off the Linux guys (because it would
be a MIPv6-specific kernel hack) and that's why I'm not mentioning it ;-)

> >     When the mobile node detects an 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. 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.
>
> The above reads a bit odd given that in order to detect L3
> handover the node needs to at least receive an RA from a new router
> and perhaps also send an RS. If an RS is sent in order to detect
> L3 movement
> it is odd that the RS is sent at the end in the above text.
> But I don't have a sugestion for alternative text.
> Should it say "suspects" instead of "detects" in the first sentence?

Ahhh, I see what you are getting at. There is the indication of L3 handover
(the basic indication being that your default router is no longer
reachable), and then the confirmation of L3 handover which is when you
receive a RA from a different router and the prefix of your primary CoA is
not one of the on-link prefixes advertised by that new router. OK.... I'll
see what I can do with this text.

> >     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.
>
> This is good to mention. I wonder if should also have a explicit
> warning about
> ping-poinging between two or more routers.
> For instance, adding
> 	For example, hearding router advertisements from a new router and/or
> 	containing new prefixes, should not cause the mobile node to abandon
> 	its current defaut router.

OK, I'll reword this. This is all informational anyways. I do want to leave
it open for eager cell switching, which has the mobile node switch routers
as soon as it gets a RA from a new router (NOTE: eager cell switching is an
advanced movement detection algorithm that is being worked some on the side,
not ready to put into this spec, and it requires the mobile node to track
the reachability of multiple routers to avoid the ping-ponging effect).

> >     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, not all L2
> >        handovers result in L3 handovers. Therefore, link-layer
> >        indications do not guarantee that an L3 handover has occurred.
>
> I have the same concerns as you that some L2 up/down indications will
> have nothing to do with L3 movement. The above doesn't say anything to do
> differently with L2 handover than the 1st and 3rd item in the list.
> Should we at least suggest rate limiting RSs caused by L2 indications?

Not a bad suggestion. What specific rate limiting do you have in mind?

> An alternative would be to move L2 indications to the future
> movement detection
> spec were we can go into more details.

No, please let's not do this. L2 indications are very useful. In fact,
without frequent RA beacons per a relatively short Advertisement Interval,
generic movement detection w/out L2 indications generally detects L3
handovers so slowly as to be practically unusable.

Thanks.
- Ed

---

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

> Not a bad suggestion. What specific rate limiting do you have in mind?

I have no idea.

Elsewhere you said:
> 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.

So either the spec is silent about L2 indications or we say something
useful about the "probe" word.
Here is an attempt at the latter:
	While furthers details around handling L2 indications and hint of
	movement is an item for further study, the consensus at the time
	of writing this specification is as follows:

	An L2 link up indication may or may not imply L2 movement and L2
	movement may or may not imply L3 movement; the correlations might
	be a function of the type of L2 but might also be a function of
	actual deployment of the radio topology.

	If it is not well-known that an L2 link up indication is likely
	to imply L3 movement it is best, instead of immediately multicasting
	a router solicitation, to attempt to verify whether the default router
	is still bidirectionally reachable.  This can be accomplished by
	sending a unicast Neighbor Solicitation and waiting for
	a Neighbor Advertisement with the solicited flag set. Note that
	this is similar to Neighbor Unreachability detection but it does
	not have the same state machine (with e.g. the STALE state).

	If the default router does not respond to the NS it makes sense
	to proceed to multicasting a Router Solicitation.

I think the above says something much more concrete and useful than
my earlier suggestion of "rate limit" without saying how.

Does the above loose language cause heart-burn for anybody?

   Erik

---

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

No heartburn here. I like it!

Thanks.
- Ed

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Monday, May 12, 2003 6:54 AM
> To: Ed Remmell
> Cc: Erik Nordmark; Mobile IPv6 mailling list; Jari Arkko
> Subject: RE: [mobile-ip] newest text for MIPv6 movement detection
>
>

---

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

Hello Erik and thanks for your suggestion. I'm quite happy with
the text. Regarding Karim's concern, perhaps we could tone the
current "it is best" down a bit. Maybe say "a possibly better
strategy is to ...". That would leave it open for implementations
and future specifications to decide exactly when they wish to
send NS first and when RS first.

--Jari

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 12 May 2003 23:03:46 +0200

> send NS first and when RS first.

Yes, notice that in Karim's scenario:

    "...physically disconnect from Router A
    and connect to Router B and get a L2 indication..."

Then the current wording does not quite apply:

    "...If it is not well-known that an L2 link up indication is likely
    to imply L3 movement it is best,..."

Because in this case *it IS well-known than L2 means L3.
Even if this weren't the case, if you read the text you'll
notice that there's enough weasel-wording to not imply this
mandates any absolutes, so you're allowed to depart from
the text.

Still, I agree with Jari about toning down the text as
he suggests.

But other than toning down (e.g. perhaps instead of "consensus" use
"it is considered reasonable") I think we've tweaked this one to
death, and it's time to move on.

-gabriel