Subject: [DNA] Text on Router Reachability for DNA Protocol Specification

From: James Kempf <[email-masked]>
Date: Sat, 13 May 2006 13:22:09 -0700

In line with Greg's posting about combining drafts, I'm reposting a proposal 
I made after the Dallas IETF about adding some text about router 
reachability to the DNA protocol draft. The text would go into whichever 
draft dealt with host specifications. The problem is that in the current 
DNAv6 solution draft (draft-ietf-dna-protocol-00.txt), address reachability 
is discussed in Section 5.2.6 but there is no text discussing router 
reachablity after a potential Layer 2 handover. This in contrast to the 
DNAv4 draft:

http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-18.txt

which specifies the use of unicast ARP to the mobile node's current default
router in order to confirm bidirectional reachability and discusses router
reachability extensively. Bernard Abboba's draft on architectural link
indications:

http://www.iab.org/documents/drafts/draft-iab-link-indications-04.txt

contains an excellent discussion of why bidirectional reachability tests at
the IP layer are necessary for 802.11-like protocols (they aren't for
cellular, but that is a different story).

Since the current draft says nothing about router reachability detection,
the mobile node would fall back to the NUD procedure described in Section
7.3 of RFC 2461, which does not distinguish between routers and other nodes.
This procedure is likely to be lengthy, and is completely unnnecesary
because the mobile node has already confirmed reachability through the
multicast DNA RS/unicast DNA RA. So the need is for some text in
draft-ietf-dna-protocol-00.txt to specify how the mobile node uses this
information to update its Default Router List.

Below is some proposed text for this (thanx to Christian Vogt for help in
formulating it). If anybody has suggestions for improvement, please
send them so we can have a discussion. I would like to propose
to the WG that this text be accepted into the merged protocol document
when it is decided.

                jak

-----------------------------

Remove the last paragraph in Section 5.2.5, put in the following new section
after Section 5.2.5.1.

5.2.5.2 Router Reachability Detection and Default Router Selection

The receipt of a unicast RA from a router in response to a multicast RS
indicates that the host has bi-directional reachability with the routers
that responded. Such reachability is necessary for the host to use a router
as a default router, in order to have packets routed off the host's current
link. If the destination address of the received RA is a unicast address,
the host knows the router heard its RS, and therefore that the host
has reachability with the router.

Prior to sending a DNA RS in response to an indication of link change,
the host SHOULD set all Neighbor Cache entries for routers on its Default
Router List to STALE. When the host receives an RS in reply to the RA, the
host SHOULD mark that router's Neighbor Cache Entry [3] as REACHABLE,
or add a Neighbor Cache Entry in the REACHABLE state if one does not
currently exist.

The host SHOULD also update its Default Router List in the following
fashion. If any of the routers returning RAs are already on the default
router list, the host SHOULD use the information in the RA to update the
Default Route List entry with the new information. The host SHOULD
add entries to the Default Router List for any routers returning RAs that
are not on the list.The host SHOULD confine selection of a router from the
Default Router List to those routers whose Neighbor Cache entries are in the
REACHABLE state. Note that the Default Router List SHOULD be updated as
described here regardless of whether the RA indicates that the host has
changed to a new IP link, since changes in router reachability are possible
on some link types even if the host remains on the same IP link.

Note that this procedure does not prevent a MN from sending packets to its
current default router while the RA solicitation is in progress and if
reachability with the current default router is unchanged, there should
be no change in default router after the RA solicitation completes. If the
current default router is still reachable, it will forward the packets.

---

From: Greg Daley <[email-masked]>
Date: Sun, 14 May 2006 17:40:33 -0400

Hi James,

thanks for that.

There's been some text on reachability detection in the
hosts draft.   IMO, if we're combining documents, this may
give us text which suffice for the same purpose, matched
to the -protocol- document style.

Greg

----- Original Message -----
From: James Kempf <[email-masked]>
Date: Saturday, May 13, 2006 4:22 pm
Subject: [DNA] Text on Router Reachability for DNA Protocol Specification
To: Dna <[email-masked]>
Cc: Kempf <[email-masked]>

> which specifies the use of unicast ARP to the mobile node's current 
> defaultrouter in order to confirm bidirectional reachability and 
> discusses router
> Since the current draft says nothing about router reachability 
> detection,the mobile node would fall back to the NUD procedure 
> described in Section
> draft-ietf-dna-protocol-00.txt to specify how the mobile node uses 
> thisinformation to update its Default Router List.
> 
> indicates that the host has bi-directional reachability with the 
> routersthat responded. Such reachability is necessary for the host 
> to use a router
> as a default router, in order to have packets routed off the host's 
> currentlink. If the destination address of the received RA is a 
> unicast address,
> the host SHOULD set all Neighbor Cache entries for routers on its 
> DefaultRouter List to STALE. When the host receives an RS in reply 
> to the RA, the
> fashion. If any of the routers returning RAs are already on the 
> defaultrouter list, the host SHOULD use the information in the RA 
> to update the
> described here regardless of whether the RA indicates that the host 
> haschanged to a new IP link, since changes in router reachability 
> are possible
> reachability with the current default router is unchanged, there 
> shouldbe no change in default router after the RA solicitation 
> completes. If the

---

From: Brett Pentland <[email-masked]>
Date: Tue, 16 May 2006 00:06:37 +1000

Hi James,

The proposed text looks very good (except for a swapped RS/RA - see
below).

An observation I have is that it seems that a single lost RA from the
default router that is "currently" being used would cause the host to
swap to a new default router, since the current one would be STALE and
there may be new ones that are REACHABLE.  Presumably this causes some
sort of (minor) disruption to the packet flow.

Would there be any value in having some sort of configuration variable
on the host to specify the number of missed RAs before switching to a
new default router when DNA otherwise indicates no movement?

Regards,
Brett.

                                                   ^^                 ^^

---

From: James Kempf <[email-masked]>
Date: Mon, 15 May 2006 10:06:31 -0700

Brett,

I have no problem with the configuration variable.

Regarding the missed RA, you are right but I think this is likely to be a 
relatively infrequent event on a single link, somewhat equivalent to 
handover but even more infrequent. However, I agree that some kind of 
configuratable variable for lazy v.s. eager switching should be OK.

            jak

----- Original Message ----- 
From: "Brett Pentland" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Dna" <[email-masked]>
Sent: Monday, May 15, 2006 7:06 AM
Subject: Re: [DNA] Text on Router Reachability for DNA Protocol 
Specification

>> current