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

[James Kempf <kempf@docomolabs-usa.com>]

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" <brett.pentland@eng.monash.edu.au>
To: "James Kempf" <kempf@docomolabs-usa.com>
Cc: "Dna" <dna@eng.monash.edu.au>
Sent: Monday, May 15, 2006 7:06 AM
Subject: Re: [DNA] Text on Router Reachability for DNA Protocol 
Specification


> 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.
>
> James Kempf wrote:
>> -----------------------------
>>
>> 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.
>>
>>
>>
>
>