Subject: [mobile-ip] Mipv6 issue #245: prefix fetching intervals

From: Jari Arkko <[email-masked]>
Date: Mon, 17 Feb 2003 10:04:07 +0200

Hi,

Here's an analysis of the current situation and
problems:

   (1) The mobile node does not get MaxRtrAdvInterval, or any other
       indication of what the MPA interval from the home agent might
       be. However, current text in 11.4.2 requires this information to
       follow the instructions which dictate the exact timing for
       solicited prefix discovery.

   (2) Again in the timing for solicited prefix discovery,
       MAX_PFX_ADV_DELAY is not defined. Currently it is used as the
       default value if the information in (1) is not available.

   (3) Still in the same timing instructions, MaxRtrAdvInterval maybe
       the wrong variable as the minimum lifetime of the home address
       before an MPS must be sent. This variable is for the on-link
       advertisements, not MPAs. MaxMobPfxAdvInterval should have been
       used instead.

   (4) The scheduling of advertisements is based on HomeRtrAdvInterval,
       default 3600, while the randomization process is based on
       {Min,Max}MobPfxAdvInterval, default 86400. That is, we
       schedule advertisements every hour but the random variation
       in the actual send times is in the order of a day.

   (5) The 10.6.2 instructions which tell us how to use
       HomeRtrAdvInterval are unclear. It does not clearly say whether
       the randomization process is a part of this kind of scheduled
       transmission.

   (6) HomeRtrAdvInterval reference from 10.6.2 points to the
       wrong section, should be 13 not 12.

Looking back at issue #120, we agreed to replace MAX_PFX_ADV_DELAY
with MaxMobPfxAdvInterval. But the former variable still appears in
11.4.2.

In issue #120, we apparently also agreed to rename HomeRtrAdvInterval
to MaxMobPfxAdvInterval, but both contansts still exist.

In issue #207, we made the decision to remove the AI option along with
the SLLA option from MPAs. The main reason for removing them was that
there was no text that would describe how to use the results of the AI
option by the MN. As can be seen from the above discussion we may
actually need some functionality like this, but the problem with the
old text was that it talked about the transmission of the
MaxRtrAdvInterval through it, not the parameters related to prefix
discovery.

Here's one possible approach to fix the current mess with the advertisement
intervals:

1. Relax the rules for mobile nodes regarding the exact timing of
    sending MPS messages. There does not appear to be a reason to
    require more exact timing than doing it well in advance of the
    prefix being deprecated.

    If we do this, we will also avoid the need to send any unsolicited
    MPA timing parameters from the home agent to the mobile node. And
    we will avoid the MaxRtrAdvInterval / MaxMobPfxAdvInterval problem,
    as well as get rid of MAX_PFX_ADV_DELAY.

    In any case, the home agent is in the best position to select the
    right frequency based on expected changes in prefixes. Also, the
    lifetimes of prefixes sent through MPA will force the mobile nodes
    to update their information at some point.

2. Remove HomeRtrAdvInterval and just use MaxMobPfxAdvInterval
    instead.

3. Make it clear that all unsolicited MPAs are under the same timing
    randomization rules. Solicited MPAs are sent immediately.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 17 Feb 2003 17:05:26 +0200

>    randomization rules. Solicited MPAs are sent immediately.

Here's the text proposal related to the above solution:

Changed contents in Section 10.6.2:

    10.6.2 Scheduling Prefix Deliveries

    ...

    The home agent uses the following algorithm to determine when to send
    prefix information to the mobile node.

    o  If a mobile node sends a solicitation, answer right away.

    o  If the mobile node has not received the prefix information within
       the last MaxMobPfxAdvInterval (see Section 13) seconds, then
       ensure that a transmission is scheduled. The actual transmission
       time is randomized as described below.

    o If a prefix in the aggregate list that matches the mobile node's
       home registration is added, or if its information changes in any
       way that does not cause the mobile node's address to go
       deprecated, ensure that a transmission is scheduled. The actual
       transmission time is randomized as described below.

    o  If a home registration expires, cancel any scheduled
       advertisements to the mobile node.

    ...

New contents of Section 11.4.2:

    11.4.2 Sending Mobile Prefix Solicitations

    When a mobile node has a home address that is about to become
    invalid, it SHOULD send a Mobile Prefix Solicitation to its home
    agent in an attempt to acquire fresh routing prefix information.
    The new information also enables the mobile node to participate in
    renumbering operations affecting the home network, as described in
    Section 10.6.

    The mobile node MUST use the Home Address destination option to carry
    its home address.  The mobile node MUST support and SHOULD use IPsec
    to protect the solicitation.  The mobile node MUST set the Identifier
    field in the ICMP header to a random value.

    As described in Section 11.7.2, Binding Updates sent by the mobile
    node to other nodes MUST use a lifetime no greater than the
    remaining ...

New contents of Section 13:

    13. Protocol Configuration Variables

      MaxMobPfxAdvInterval            Default: 86,400 seconds
      MinDelayBetweenRAs              Default: 3 seconds,
                                      Min: 0.03 seconds
      MinMobPfxAdvInterval            Default: 600 seconds
      InitialBindackTimeoutFirstReg   Default: 1.5 seconds

    Home agents MUST allow the first three variables to be configured
    by system management, and mobile nodes MUST allow the last variable
    to be configured by system management. ...

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 19 Feb 2003 02:49:08 +0100

Your proposed solution sounds good. Just one minor question and nit...

>    o  If the mobile node has not received the prefix information within

Did you mean?:
"If prefix information has not been sent to the mobile node within"

>       way that does not cause the mobile node's address to go

s/go/become/

>       deprecated, ensure that a transmission is scheduled. The actual

-gabriel

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Feb 2003 14:36:28 +0200

Thanks for your comments Gabriel and TJ. See below:

 > I think the Home Agent was originally supposed to know that the mobile
 > received the prefix information, because it responds with a binding
 > update!

The unsolicited advertisements are still "acked", though with the
reception of an MPS. So, the home agent not only knows when it has
sent information but also knows what the mobile node has received.
However, we don't want to formulate the rule so that it would keep
scheduling new deliveries to a mobile node who is not responding. So I
think we should base our delivery schedule on the latest MPS from the
mobile, or the latest unsolicited MPA to the mobile, whichever was
later. This turns out to be equivalent to the time of the last MPA
(solicited or unsolicited) transmission to the mobile node in
question.

Modified text proposal below and also in the latest draft version in
the web.

    ...

    o  If no Mobile Prefix Advertisement has been sent to the mobile
       node in the last MaxMobPfxAdvInterval (see Section 13) seconds,
       then ensure that a transmission is scheduled. The actual
       transmission time is randomized as described below.

    o  If a prefix in the aggregate list that matches the mobile node's
       home registration is added, or if its information changes in any
       way that does not deprecate the mobile node's address, ensure
       that a transmission is scheduled. The actual transmission time
       is randomized as described below.

    ...