Subject: [mobile-ip] newer text for MD

From: "Ed Remmell" <[email-masked]>
Date: Fri, 9 May 2003 09:52:14 -0700

Jari -

OK, here is an update to the new text for MD, incorporating the latest
feedback from the list. Note that I also added an explicit NUD bullet to the
2nd list:
"    o  Neighbor Unreachability Detection determines that the default
       router is no longer reachable."

new text follows:

Definitions added to Section 3.2:

    L2 handover - process by which the mobile node changes from one
    link-layer connection to another. For example, a change of wireless
    access point is an 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 an L3 handover.

11.5.1 Movement Detection

    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. The primary goal of movement detection is
    to detect L3 handovers.

    This section does not attempt to specify a generic movement
    detection algorithm which will function optimally for all types of
    applications, link-layers and deployment scenarios; 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].

    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.

    Due to the temporary packet flow disruption and signaling overhead
    involved in updating mobility bindings, the mobile node should avoid
    performing a L3 handover until it is 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.

    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 easily 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:

    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, not all L2
       handovers result in L3 handovers. 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
       an L3 handover has occurred.

    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 a L3 handover indication.

    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 an L3 handover
    that occurred.

Thanks.
- Ed Remmell
Elmic Systems USA, Inc.

Best of Show Winner, ESC 2003
Click on the link and take a look!
http://cmp.iconvention.com/escshowdaily/v33/index.cvn?ID=10183

---

From: Robert Chalmers <[email-masked]>
Date: Fri, 09 May 2003 10:25:01 -0700

Ed and Jari,

> feedback from the list.
<..snip..>
>     link-layer, the mobile node might become unaware of an L3 handover

Small fix: In last paragraph s/it use normal/it uses normal/ or possibly 
employs rather than uses.

enjoy,
bob

-- 
/****************************************************************

  Robert Chalmers
  UCSB Computer Science Doctoral Candidate
  Network and Multimedia Systems Lab (NMSL)

  "My heart is in the code, but my soul lies in the process"

  | [email-masked] || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/

---

From: "James Kempf" <[email-masked]>
Date: Fri, 9 May 2003 10:30:23 -0700

Looks OK, suggested edits below.

            jak

----- > 11.5.1 Movement Detection

  This section does not attempt to specify a generic movement
  detection algorithm which will function optimally for all types of
  applications, link-layers and deployment scenarios. Instead, it
  describes a method that uses IPv6 Neighbor Discovery [12],
  including Router Discovery and Neighbor Unreachability
  Detection, and is based on the conceptual model of the
  the organization and data structures defined in RFC 2461.
  At the time of this writing, this method is considered well
  enough understood to recommend for standardization.
  However, in certain cases, additional information may be
  available from lower protocol layers that can help optimize
  L3 handover, and this information should be utilized
  by mobile nodes if available. Future versions of this
  specification or other specifications may contain updated
  versions of the movement detection algorithm that
  have better performance.

>        bit, since that provides a global address of the router.

  In order to avoid this problem, routers SHOULD use the Router
Address (R)
  bit and provide a global address for the router.

>        an L3 handover has occurred.

  With some types of networks, notification that a L2 handover has
occured
   may be available from lower protocol layers or the device driver
   software. However, depending on the particular L2 wireless
protocol,
   not all L2 handovers result in L3 handovers. Therefore, link-layer
   indications may not guarantee that an L3 handover has occured.

---

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

James -

Thanks again for your feedback, see my feedback below.

>   versions of the movement detection algorithm that

I will tone down the "too slow" wording. However, I think the slowness of
generic move detection is an excellent justification for saying the MN
SHOULD make use of L2 triggers, which is essentially what this paragraph
used to say. I can see that you removed even this SHOULD requirement. Now,
this entire section would contain essentially no requirements and be purely
informational. I would not mind that fact, however I do feel that this
specific "MN SHOULD use L2 triggers" is a movement detection requirement
that should be kept, since we've gotten rid of all of the other movement
detection requirements language.

>    indications may not guarantee that an L3 handover has occured.

Yes, I agree about trimming the example from this text.

Thanks.
- Ed

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 9 May 2003 10:56:15 -0700

James -

>   bit and provide a global address for the router.

Yes, but the general tendency has been to make no requirements in this spec
on any pre-existing IPv6 infrastructure. So, this requirement is currently a
MAY in the spec, however it is a MUST for a MIPv6 home agent. Note that the
important part about consistency of the (R) bit Router Address in RAs has
been addressed, so the MN can use this information reliably for movement
detection (it is a little kludgy still, since only one (R) bit option is
guaranteed to remain consistent across RAs sent by the same router, but it
is workable).

Please refer to section 7.2 "Modified Prefix Information Option Format"
where these requirements live.

Thanks.
- Ed

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 9 May 2003 11:02:21 -0700

OK, here's a new version without the "too slow" verbage, removing some
example text that didn't seem to add much, and correcting a typo per the
list feedback:

    This section does not attempt to specify a generic movement
    detection algorithm which will function optimally for all types of
    applications, link-layers and deployment scenarios; instead, for
    informational purposes it describes one method which uses the
    facilities of IPv6 Neighbor Discovery, including Router Discovery
    and Neighbor Unreachability Detection. The mobile node SHOULD
    supplement this method 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].

    Due to the temporary packet flow disruption and protocol overhead

    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.

    Note that while the mobile node is on a link, it uses normal IPv6

Thanks.
- Ed

---

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

Ed,

Please read RFC 2119 as to when SHOULD, MAY, and MUST are used. There
are only two reasons to use this language:

1) An interoperabilty consideration.

2) "Danger to the net" for example, from congestion collapse.

Neither apply in this case. This case is purely about performance.

            jak

----- Original Message -----
From: "Ed Remmell" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Mobile-Ip"
<[email-masked]>; "Jari Arkko" <[email-masked]>
Sent: Friday, May 09, 2003 10:51 AM
Subject: RE: [mobile-ip] newer text for MD

---

From: "James Kempf" <[email-masked]>
Date: Fri, 9 May 2003 11:29:32 -0700

OK, MAY is fine.

            jak

----- Original Message -----
From: "Ed Remmell" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Mobile-Ip"
<[email-masked]>; "Jari Arkko" <[email-masked]>
Sent: Friday, May 09, 2003 10:56 AM
Subject: RE: [mobile-ip] newer text for MD

---

From: "James Kempf" <[email-masked]>
Date: Fri, 9 May 2003 11:31:02 -0700

I'd like the text back in about "best known at the moment" and "Future
specifications may" please. This is not a research paper, it is an
Internet standard and we must be careful to set people's expectations
about what they are getting now and what they may be getting in the
future.

Thanx.

            jak

----- Original Message -----
From: "Ed Remmell" <[email-masked]>
To: "Mobile-Ip" <[email-masked]>; "Jari Arkko"
<[email-masked]>
Sent: Friday, May 09, 2003 11:02 AM
Subject: RE: [mobile-ip] newer text for MD

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 9 May 2003 11:43:46 -0700

James -

Thanks for the education, you are correct. This should never have been a
SHOULD requirement, I will turn it into a "should" non-requirement.

- Ed

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Friday, May 09, 2003 11:29 AM
> To: Ed Remmell; Mobile-Ip; Jari Arkko
> Subject: Re: [mobile-ip] newer text for MD
>
>
> Ed,
>

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 9 May 2003 11:44:54 -0700

James -

Good point (w/ regards to setting expectations). I'll rework this text.

Thanks.
- Ed

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of James Kempf
> Sent: Friday, May 09, 2003 11:31 AM

---

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

James -

OK, how about this:

"   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. The mobile node should supplement this method with other
    information whenever it is available to the mobile node (e.g., from
    lower protocol layers). 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."

I like the distinction between "fast movement detection algorithm" versus
"generic method", it helps to set expectations and provides the same
information as "too slow" without sounding negative. I pretty much kept all
of your verbage (well, not the "best at the moment" part - but read the
above and see if is OK), just reorganized it some. This actually reads
pretty well to me now.

Thanks.
- Ed

> [mailto:[email-masked]]On Behalf Of Ed Remmell
> Sent: Friday, May 09, 2003 11:45 AM
> To: James Kempf; Mobile-Ip; Jari Arkko

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 May 2003 23:21:03 +0300

Ed, I think this text is good enough now, with the comments that

>     link-layer, the mobile node might become unaware of an L3 handover

It seems a bit strange that NUD usage is introduced later when it
has already been mentioned in one of the bullet items above.
Perhaps we could combine this with the earlier bullet item like
this:

       (Note that Neighbor Unreachability Detection 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 an L3 handover that occurred.)

And perhaps this could be last bullet item.

--Jari

---

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

Hmmm... I hear you... but

> And perhaps this could be last bullet item.

Yes, I can make NUD the last bullet item. But, I think the warning about NUD
deserves its own place in this section. The difference between "reachable
from the router" versus NUD bi-directional reachability is subtle but
important, the real issue being what can happen if you don't use NUD
(because you aren't sending) and you aren't monitoring reachability from the
router. Perhaps I can play with the wording some to try to capture more of
this information, but I think this warning needs to be separate from the
bullet list and it shouldn't be hidden in parens.

Thanks.
- Ed

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 May 2003 23:37:49 +0300

> bullet list and it shouldn't be hidden in parens.

Yes, it is important. My original problem with the text piece was
simply that the part "Note that while the mobile node is on a link, it
uses normal IPv6 mechanisms such as Neighbor Unreachability Detection"
comes after a bullet item has already discussed this issue. Perhaps
we should just move this to the bullet item or even remove it...
This way we could keep the warning as one of the top-level items.

--Jari

---

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

Ahhh...

Let me then move it earlier on up in the discussion, before the bullet list,
around where we first reference NUD. It seemed to me that it might be useful
to have further elaboration about how Router Discovery, Neighbor
Unreachability Detection, etc. are actually used. So, I can perhaps also
(w/out too much text) mention the difference between detecting reachability
from the router, versus NUD reachability, and why both are important. I'll
minimize the actual text, keep it short but meaningful.

Thanks.
- Ed

> From: Jari Arkko [mailto:[email-masked]]
> Sent: Friday, May 09, 2003 1:38 PM
> To: Ed Remmell
> Cc: Mobile-Ip

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 09 May 2003 13:56:51 -0700

thanks for the text, Ed. a few minor comments.

>     router to form new care-of address(es) as described in Section

you can discover both default routers and prefix information through
router discovery. MIPv6 uses the term 'Prefix Discovery' for
describing the mechanism through which the MN lears about the home 
prefixes, through mobile prefix solicitation and mobile prefix 
advertisement. maybe just say

      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 to form new care-of
      address(es) as described in Section ...

>     Specifically, if the MN detects that the curently selected default

s/curently/currently/

>        indications do not guarantee that an L3 handover has occurred.

the last two sentences are repeated. they appear in the first paragraph.

Vijay

---

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

Vijay -

>       address(es) as described in Section ...

Hmmm... but IPv6 Prefix Discovery is not the same as Mobile Prefix Discovery
(or is it called Home Prefix Discovery?), even though they both use the
Prefix Information Option. So, I think the current text is fine. Perhaps
other places in the MIPv6 spec it needs to say Mobile Prefix Discovery
instead of Prefix Discovery. Prefix Discovery is part of RFC-2461, it is
always associated with Router Advertisements.

Thanks.

> the last two sentences are repeated. they appear in the first paragraph.

Excellent point. I kind of noticed that myself, before. I will move the
material from the first paragraph to this bullet, that's where it belongs.
And, then remove the duplication.

Thanks.
- Ed

---

From: Jari Arkko <[email-masked]>
Date: Sat, 10 May 2003 00:24:04 +0300

> always associated with Router Advertisements.

The term has been used in the draft, but Ed may be right here.
It could be confusing, since the term is also used in 2461.

I changed the occurrences of prefix discovery in the draft
to mobile prefix discovery.

--Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 9 May 2003 14:54:35 -0700

Jari -

Does this work for you?

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

Almost done...

- Ed

> Sent: Friday, May 09, 2003 1:53 PM
> To: Jari Arkko
> Cc: Mobile-Ip

---

From: "James Kempf" <[email-masked]>
Date: Fri, 9 May 2003 17:57:12 -0700

Looks great, Ed.

            jak

----- Original Message -----
From: "Ed Remmell" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Mobile-Ip"
<[email-masked]>; "Jari Arkko" <[email-masked]>
Sent: Friday, May 09, 2003 12:17 PM
Subject: RE: [mobile-ip] newer text for MD

> > > > OK, here's a new version without the "too slow" verbage,
removing
> > > some
> > > > example text that didn't seem to add much, and correcting a
typo per
> > > the
> > > >     change in primary care-of address. For example, a change
of
> > > access
> > > >     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
> > > >     detection algorithm which will function optimally for all
types
> > > of
> > > >     organization and data structures defined by Neighbor
Discovery
> > > [12].
> > > >     11.5.2. It then registers its new primary care-of address
with
> > > its
> > > >     involved in updating mobility bindings, the mobile node
should
> > > avoid
> > > >     should generally continue to use that router rather than
switch
> > > away
> > > >     Advertisements to detect L3 handovers. In doing so the
mobile
> > > node
> > > >     o  There might be multiple routers on the same link thus
hearing
> > > a
> > > >        link-local source address.  This might be common if
routers
> > > use
> > > >        the same link-local address on multiple interfaces.
This
> > > issue
> > > >     o  With some types of networks, notification that an L2
handover
> > > has
> > > >        occurred might be obtained from lower layer protocols
or
> > > device
> > > >        Advertisement from this router, the mobile node can be
sure
> > > that
> > > >     Note that while the mobile node is on a link, it uses
normal
> > > IPv6
> > > >     mechanisms such as Neighbor Unreachability Detection [ref]
to
> > > track
> > > >     performed only when the mobile node has packets to send,
and in
> > > the
from
> > > the