[psg.com #256] Eliminate random delay in RS transmission

[rt+ipv6-2461bis@xxxxxxxxxx]

This issues is now closed.

Hesham

> [kempf@docomolabs-usa.com - Tue Jul 20 15:42:13 2004]:
> 
> Looks fine to me.
> 
>             jak
> 
> ----- Original Message ----- 
> From: <rt+ipv6-2461bis@rt.psg.com>
> Cc: <ipv6@ietf.org>
> Sent: Tuesday, July 20, 2004 12:54 AM
> Subject: [psg.com #256] Eliminate random delay in RS transmission
> 
> 
> 
> Issue:
> -------
> This issue was raised in order to speed movement detection
> for mobile nodes. The random delay added before sending
> router solicitation slows down movement detection significantly.
> In Seoul, we agreed to allow the removal of this delay after
> handovers.
> 
> Suggestion:
> -----------
> 
> The current version of 2461bis contains the following text
> in 6.3.7
> 
>    Before a host sends an initial solicitation, it SHOULD delay the
>    transmission for a random amount of time between 0 and
>    MAX_RTR_SOLICITATION_DELAY.  This serves to alleviate congestion when
>    many hosts start up on a link at the same time, such as might happen
>    after recovery from a power failure.  If a host has already performed
>    a random delay since the interface became (re)enabled (e.g., as part
>    of Duplicate Address Detection [ADDRCONF]) there is no need to delay
>    again before sending the first Router Solicitation message. In some
>    cases, the random delay MAY be omitted if necessary. For instance, a
>    mobile node, using [MIPv6], moving to a new link would need to
>    discover such movement as soon as possible to minimize the amount of
>    packet losses resulting from the change in its topological movement.
>    Router Solicitations provide a useful tool for movement detection in
>    Mobile IPv6 as they allow mobile nodes to determine movement to new
>    links. Hence, if a mobile node received link layer information
>    indicating that movement might have taken place, it MAY send a Router
>    Solicitation immediately, without random delays. The strength of such
>    indications should be assessed by the mobile nodeÆs implementation
>    and is outside the scope of this specification.
> 
> 
> (I'll remove the non ASCII character in the next rev).
> 
> Hesham
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> 
> 
> 
> 
> 


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------