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

[Greg Daley <Greg.Daley@eng.monash.edu.au>]

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 <kempf@docomolabs-usa.com>
Date: Saturday, May 13, 2006 4:22 pm
Subject: [DNA] Text on Router Reachability for DNA Protocol Specification
To: Dna <dna@eng.monash.edu.au>
Cc: Kempf <kempf@docomolabs-usa.com>

> 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 
> defaultrouter 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 
> thisinformation 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 
> 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 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 
> DefaultRouter 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 
> defaultrouter 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 
> haschanged 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 
> shouldbe no change in default router after the RA solicitation 
> completes. If the
> current default router is still reachable, it will forward the 
> packets.
> 
> 
>