Subject: RE: [mobile-ip] Mobile IPv6 Issue 154: ND Constants (Router Advertisement)

From: [email-masked]
Date: Fri, 6 Dec 2002 17:09:17 -0600

> 
> Hi James,
> 
> I've just sent the other email.
> 
> There's no consensus to make all ND changes in the base
> draft.  The main reason is to identify all the areas
> covered by the AD comments on ND and cover them.

Yes. The current text in the movement detection section that
says that DAD is optional needs to be removed. DAD optimization
can be pursued independently.

> 
> Issue 154 still had some reference to RS, which was
> not yet addressed in any other issue.  There are
> also some minor modifications to ND timers in MIPv6-19,
> which seem to be innocuous and limited in scope,
> as well as those in section 7.5/7.6.
> 
> The main idea was to get the RA intervals specified
> and determine what to do with the RS stuff.

This is what we agreed to in Atlanta, IMO.

> Maybe the RS specific comments can be directed to the
> other thread, so that we can concentrate on getting
> to an agreement on the requirements for RA interval,
> in this one.

Yep. Lets close at least the RA interval issue immediately and
see if we can also close the RS issue. Is there a recommendation
already for the RS issue? 

> Greg

-Basavaraj

---

From: Greg Daley <[email-masked]>
Date: Mon, 09 Dec 2002 13:25:12 +1100

Hi Basavaraj,

At this stage, I'd probably remove all the text
from section 7.6 (about RS mods), unless there's
implementation experience to support the modifications.

There's been no response yet as to how to handle this.

The other issues related to RS's are the
MAX_RTR_SOLICITATION_DELAY, which is used for both
DAD delays and RS delay on link-up (maybe RA reception
in DAD).  The MN 'SHOULD' wait a random period up to
MAX_RTR_SOLICITATION_DELAY (per 2461) in order to prevent
multicast bombing of links and routers on link-up.

While James Kempf proposed that the issue with RS bombing
is likely to be unimportant,  I'm not sure anyone has
empirical evidence yet for this for large numbers
(dozens?) of nodes moving simultaneously.

MIPv6 only mentions this issue for DAD delays
(not RS delays).  There's still text regarding the DAD
delays, which may cause problems on simultaneous reception
of multicast new prefix RA's by many nodes.

I'm not sure how big an issue the DAD bombing on multicast RA
reception is either though (though there's no implicit
serialization on WLAN for this).

It may be worth noting that FastRA will not be affected by
this issue since it sends unicast RA messages and has
a backoff limit. Similarly APs caching RAs (fastRD)
can be made to send packets to unicast mac addresses,
and back off after sending a maximum number of messages.

In both of these cases, the fallback could be multicast RA
reception with some random delay before address
configuration/DAD occurs.

The SHOULD from rfc2461 gives us an easy-out in experimental
implementations (i.e. skip delays), but I'm not sure what to
specify in MIPv6 today, since that's what's going to be
implemented by the community.

The way I'm thinking, a few checks need to be run before
we can really indicate the right behaviour.
Should we remove the DAD/RS delay optimizations from the base
spec?

Greg

[email-masked] wrote:
[part snipped]

---

From: "James Kempf" <[email-masked]>
Date: Mon, 9 Dec 2002 13:14:40 -0800

> Should we remove the DAD/RS delay optimizations from the base

IMHO, yes.

            jak

---

From: Greg Daley <[email-masked]>
Date: Wed, 11 Dec 2002 17:08:56 +1100

Hi, here is a set of text for the router advertisement section
(7.5) and the modified protocol constants for Router Advertisement
(section 12)

Here are the points from the previous email, and where they
have been addressed.

* Specify new lower bounds for the advertisement interval
   constants, making explicit that these are the lowest values
   currently required in MIPv6 (to simplify the task of implementors).
   (2-3 lines??)

-->(end para 5)

* Explain the mean interval generated by using the low bound constants
   (1 line ??)

-->(para 6 line 1).

* Provide an applicability statement, ensuring that these values
   are not configured by default, and that deployers check that
   the interval is necessary, and not harmful in their environment.
   (2-3 lines??)

-->(para 6)

* Keep current information about Link triggers, to indicate
    an alternative to short multicast intervals.

-->(para 8)

* Specify a safety boundary/grace time for handling of the
    "Advertisement Interval" option in RA's, to make sure
    that scheduling/link jitter doesn't cause excessive
    Router Solicitations at the short intervals we're currently
    discussing.
    (3-4 lines??)
  (para 7)
   G: I'm not sure of other values, but know linux
      has a 10ms jiffy timer.

(Section 12)

* Specify all modified RA protocol constants (in list, and
   references to rfc 2461).
(specified below).

"7.5. Changes to Sending Router Advertisements

p1
    The Neighbor Discovery protocol specification [12] limits routers to
    a minimum interval of 3 seconds between sending unsolicited multicast
    Router Advertisement messages from any given network interface
    (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that:

p2
       "Routers generate Router Advertisements frequently enough
       that hosts will learn of their presence within a few
       minutes, but not frequently enough to rely on an absence
       of advertisements to detect router failure; a separate
       Neighbor Unreachability Detection algorithm provides failure
       detection."

p3
    This limitation, however, is not suitable to providing timely
    movement detection for mobile nodes.  Mobile nodes detect their
    own movement by learning the presence of new routers as the mobile
    node moves into wireless transmission range of them (or physically
    connects to a new wired network), and by learning that previous
    routers are no longer reachable.  Mobile nodes MUST be able to
    quickly detect when they move to a link served by a new router, so
    that they can acquire a new care-of address and send Binding Updates
    to register this care-of address with their home agent and to notify
    correspondent nodes as needed.

p4
    One method which can provide for faster movement detection, is to
    increase the rate at which unsolicited Router Advertisements are
    sent.  Mobile IPv6 relaxes this limit such that routers MAY send
    unsolicited multicast Router Advertisements more frequently.
    This method can be applied where the router is expecting to
    provide service to visiting mobile nodes (e.g., wireless network
    interfaces), or on which it is serving as a home agent to one or
    more mobile nodes (who may return home and need to hear its
    Advertisements).

p5
    Routers supporting mobiltity SHOULD be able to be configured
    with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value
    to allow sending of unsolicited multicast Router Advertisements
    more often.  The minimum allowed values are:

     -  MinRtrAdvInterval       0.03 seconds

     -  MaxRtrAdvInterval       0.07 seconds

p6
    In the case where the minimum intervals are used, the mean time
    between unsolicited multicast router advertisements is 50ms.
    Use of these modified limits MUST be configurable. Systems where
    these values are available MUST NOT default to them, and
    SHOULD default to values specified in RFC 2461. Knowledge of
    the type of network interface and operating environment SHOULD be
    taken into account in configuring these limits for each network
    interface. This is important with some wireless links, where
    increasing the frequency of multicast beacons can cause
    considerable overhead.  Routers SHOULD adhere to the intervals
    specified in RFC 2461[12], if this overhead is likely to cause
    service degradation.

p7
    Additionally, the possible low values of MaxRtrAdvInterval may
    cause some problems with movement detection in some MNs.  To ensure
    that this is not a problem, Routers SHOULD add 20ms to any
    Advertisement Intervals sent in RAs, which are below 200 ms, in
    order to account for scheduling granularities on both the MN and
    the Router.

p8
    Note that multicast Router Advertisements are not always required
    in certain wireless networks that have limited bandwidth.  Mobility
    detection or link changes in such networks may be done at lower
    layers.  Router advertisements in such networks SHOULD be sent only
    when solicited.  In such networks it SHOULD be possible to disable
    unsolicited multicast Router Advertisements on specific interfaces.
    The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be
    set to some high values.

p9
    When sending unsolicited multicast Router Advertisements more
    frequently than the limit specified in the Neighbor Discovery RFC,
    the sending router need not include all options in each of these
    Advertisements, but it SHOULD include at least one Prefix
    Information option with the Router Address (R) bit set (Section 7.2)
    in each."

"12. Protocol Constants

       HomeRtrAdvInterval       3,600 seconds
       DHAAD_RETRIES            3 retransmissions
       INITIAL_BINDACK_TIMEOUT  1 second
       INITIAL_DHAAD_TIMEOUT    2 seconds
       INITIAL_SOLICIT_TIMER    2 seconds
       MAX_ADVERT_REXMIT        3 transmissions
       MAX_BINDACK_TIMEOUT      256 seconds
       MaxMobPfxAdvInterval     86,400 seconds
       MAX_NONCE_LIFE           240 seconds
       MAX_TOKEN_LIFE           210 seconds
       MAX_RR_BINDING_LIFE      420 seconds
       MAX_UPDATE_RATE          once per second
       MinDelayBetweenRAs       0.03 seconds
       MinMobPfxAdvInterval     600 seconds
       PREFIX_ADV_RETRIES       3 retransmissions
       PREFIX_ADV_TIMEOUT       5 seconds
       SLOW_UPDATE_RATE         once per 10 second interval

    The value MinDelayBetweenRAs overrides the value of the protocol
    constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 2461 [12]."

Please let me know what needs work.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Wed, 11 Dec 2002 09:02:29 -0800

Greg.

Looks good with one minor editorial nit, noted below.

            jak

----- Original Message -----
From: "Greg Daley" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, December 10, 2002 10:08 PM
Subject: Re: [mobile-ip] Mobile IPv6 Issue 154: ND Constants (Router
Advertisement)

>     frequently than the limit specified in the Neighbor Discovery RFC,

Should be RFC 2461, with reference.