Subject: Re: [MOBILE-IP] How Mobile IPv6 should handle home network renumb ering

From: "Powell, Ken" <[email-masked]>
Date: Tue, 7 Nov 2000 16:39:18 -0500

Charlie,

I like the intent of your changes, but have questions
on the details. My comments are sliced in below.

Ken

> -----Original Message-----
> From: Charlie Perkins [mailto:[email-masked]]
> Sent: Friday, November 03, 2000 8:40 PM
> To: [email-masked]
> Subject: Re: [MOBILE-IP] How Mobile IPv6 should handle home network
> renumbering
>
>
> Hello again,
>
> In Ken's note, a proposal is made for how the home agent
> should forward relevant router advertisement information to
> the mobile node, when the mobile node is away from its
> home network.
>
> I have devised an algorithm by which a home agent can
> delay the transmission of this information to the mobile
> node, in hopes that the actual transmission can be avoided
> entirely if the mobile node might send a Binding Update
> to the home agent.  In that case, the home agent could
> include all the relevant information in the Binding
> Acknowledgement.
>
> Item 2 is "What triggers a home agent to send router"
>
> Ken suggested:
>
> > Item 2 (perhaps replace similar text in section 9.7)
> > ====================================================
> >
> > A home agent serving a mobile node SHOULD construct and
> > tunnel to the mobile node a new Router Advertisement when
> > any of the following conditions occur:
> >
> >   o A valid or preferred lifetime of a prefix in the
> >     aggregate list of prefixes is suddenly reduced to
> >     less than HomeRtrAdvInterval.
> >
> >   o The state of the flags for a prefix in the aggregate
> >     list changes.
> >
> >   o A new prefix is created in the aggregate list.
> >
> > The home agent constructs a new Router Advertisement message
> > containing no options other than the Prefix Information options
> > describing the prefixes for which one of the conditions above
> > has occurred since the last Router Advertisement tunneled to and
> > acknowledged by the mobile node.
> >
> > In addition, the home agent MUST send a router advertisement
> > with all prefixes in the aggregate list to the mobile node at
> > least once per HomeRtrAdvInterval and upon receipt of a valid
> > Router Solicitation from the mobile node.
> >
> > The home agent MAY (SHOULD?) rate limit the frequency at which it
> > sends Router Advertisements to the mobile node by delaying
> transmission
> > until receipt of a Binding Update option from the mobile node.
> > When multiple conditions occur at or near the same time, the
> > home agent SHOULD attempt to combine them into a single Router
> > Advertisement message to the mobile node.
>
> Instead of a specific rate-limiting feature, I suggest the following
> algorithm:
>
> ===== How to send router advertisements to mobile nodes.
>
> - If a mobile node sends a solicitation, answer with everything.
>
> - If a prefix changes state in a way that causes a mobile node's
>   address to go deprecated, send an advertisement right away.
>
> - If the mobile node's binding expires before the advertised
>   Preferred Lifetime, do not schedule the advertisement.
>   The mobile node will get the revised information in its next
>   Binding Acknowledgement.
>
> - If a prefix is added, or if it changes in any way that does not
>   cause the mobile node's address to go deprecated, ensure that
>   a transmission is scheduled at time RAND_ADV_DELAY in the future.

If I assume the third item takes precedence over the fourth,
then scheduling with RAND_ADV_DELAY will only occur when
the prefix is due to deprecate soon or has already deprecated.
Did I read this right?

>
> - If a prefix advertisement is scheduled, and a Binding
>   Update arrives, perform that advertisement and include
>   the information in a Router Advertisement that has the
>   Binding Acknowledgement as a Destination Option.  Remove
>   the future scheduled advertisement.
>
> ===== How to compute RAND_ADV_DELAY, the offset from the
>       current time for the scheduled transmission
>
> If there is a transmission already scheduled, then
>  if the current RAND_ADV_DELAY would cause another
>  transmission BEFORE the Preferred Lifetime of the
>  mobile node's home address derived from the prefix
>  whose advertisement information has changed, then
>                add the new information to be transmitted
>                to the existing scheduled transmission
>                -- return.
>           otherwise,
>                continue with the following computation,
>                and add the data from the existing scheduled
>                transmission to the newly scheduled transmission,
>               deleting the previously scheduled transmission
>                event.
>
> If the mobile node's binding expires after the Preferred
> Lifetime, then compute
>            MAX_SCHEDULE_DELAY ==
>                      min (MAX_PFX_ADV_DELAY, Preferred Lifetime)

This would cause all changes that happen after a prefix is
deprecated (preferred lifetime = 0) but not yet expired
(valid lifetime > 0) to be sent immediately. Would it
make sense to switch back to waiting for the next binding
update after the prefix has been deprecated? A prefix
could be in the deprecated but not yet expired state
for a few weeks during a normal renumbering.

> for the newly advertised Preferred Lifetime.
> Then compute RAND_ADV_DELAY =
>              MinRtrAdvInt + rand()*{MAX_SCHEDULE_DELAY - MinRtrAdvInt}

Is it possible for MAX_SCHEDULE_DELAY to be less than MinRtrAdvInt,
perhaps if Preferred Lifetime is very close to zero?

Ken