Subject: RE: [mobile-ip] Mobile Prefix Advertisements (more comments)

From: "Powell, Ken" <[email-masked]>
Date: Wed, 27 Jun 2001 12:20:27 -0400

> -----Original Message-----
> From: Charlie Perkins [mailto:[email-masked]]
> Sent: Monday, June 25, 2001 11:08 PM
> To: Powell, Ken
> Cc: 'T.J. Kniveton'; [email-masked]'
> Subject: Re: [mobile-ip] Mobile Prefix Advertisements (more comments)
> 
> "Powell, Ken" wrote:
> >    My comments to section 9.8.2 below request that only the prefixes
> >    that match a particular home registration be sent to the mobile
> >    node in Mobile Prefix Advertisements. If the binding has a zero
> >    prefix length, only the specific prefix for the mobile node's
> >    home address would be sent. For a bindings with a non-zero prefix
> >    length, all prefixes in the aggregate list would be sent.
> 
> I'm going to go out on a limb here, and suggest that the 
> existing semantics
> for the Prefix Length option need substantial change.  I 
> might be missing
> something, but having a nonzero prefix length seems to only 
> have the effect
> of requesting that the home agent should provide service for more home
> addresses.  The addresses served by the home are determined by the
> collection of on-link prefixes, not the actual value of the 
> Prefix Length
> field.  Thus, this purpose could be managed by a single bit.
> 
> That would allow us to use the Prefix Length field for something more
> important -- namely to serve the same function as the proposed
> "Mobile Router Prefix Length Sub-Option", which I wrote about
> earlier and put into the existing intermediate (unfinished) 
> draft which
> I am trying to finish now.  Then we could get rid of that Sub-Option
> and have a more natural specification.

This sounds like a good idea to me. This will probably also remove
confusion caused by having two prefix length fields.

> 
> >    This left a problem, what prefixes do we send in response to a
> >    Router Solicitation? I think the home agent should use the
> >    same prefix selection logic, but the mobile node needs a way to
> >    override this behavior to support initialization. One option is
> >    to add a flag to the Mobile Prefix Solicitation Message:
> >
> >  + Send All Prefixes flag
> >  +
> >  +   If clear, the home agent replies by sending only the prefixes
> >  +   that match the mobile nodes home registration as defined in
> >  +   section 9.8.2. If set, the home agent will send all prefixes
> >  +   for the home network as defined in section 9.8.1. No prefixes
> >  +   will be sent if this flag is clear and the mobile node does
> >  +   not yet have a home registration.
> 
> So, in a way, I am supporting this suggestion.
> 
> 
> > 9.8.2 Sending Changed Prefix Information to the Mobile Node
> >
> >    Due to the number of comments on this section, I'm including
> >    the entire text with ">" marks, and slicing in the comments
> >    where they apply.
> >
> >  > A home agent serving a mobile node will schedule the delivery
> >  > of new prefix information to that mobile node when any of the
> >  > following conditions occur:
> >
> >    Can the following list of MUST and MAY requirements be merged
> >    into the algorithm for sending prefix information below?
> 
> Maybe -- especially if you think it will be clearer.  Would 
> you be willing
> to suggest some reorganized text?  However, one list says how 
> to figure
> out that the list needs to be sent, and the other list says 
> how to figure
> out when to send it.

This will take a bit of thought, I'll let you know
if I come up with something.

> 
> >
> >
> >  > MUST:
> >  > - The valid or preferred lifetime or the state of the flags
> >  >   changes for the prefix of the mobile node's registered home
> >  >   address changes
> >  > - The mobile node requests the information with a Router
> >  >   Solicitation (see section 10.16).
> >  >
> >  > MAY:
> >  > - A new prefix is added to the aggregate list
> >
> >    Why is this a MAY instead of MUST? Is it to cover the case
> >    where a home registration has a zero prefix length?
> 
> It's a MAY because it won't hurt the mobile node not to find out
> this information.

For the most part, I agree. Particularly since all prefixes will
definitely be advertised in an hour anyway. The only time I can
see this being a problem is when other node's try to initiate a
connection to the mobile node using the new address. This isn't
a big concern to me, which kind of implies MUST isn't needed.
Either MAY or SHOULD would make sense.

> 
> >  > - The valid or preferred lifetime or the state of the flags
> >  >   changes for a prefix which is not used in any binding cache
> >  >   entry for this mobile node
> >
> >    I don't understand what your trying to do with this
> >    last MAY requirement.
> 
> Maybe the mobile node didn't like one of the prefixes because
> the lifetime was too short, and it changed to be long enough.
> Really, though, it's almost the same as the previous bullet, thus
> also a MAY.

I didn't understand what was meant by "prefix which is not used
in any binding cache entry for this mobile node". I think I
get it now. I'm don't know if this is a good thing to do. A home
agent that does this will probably end up sending duplicate
information to a mobile node that has multiple bindings. More
on this below...

> 
> >   It looks like its addressing a problem I've been wondering about.
> >   A mobile node with  multiple home addresses could either
> >
> >     o establish a single binding with a non-zero prefix
> >       length to cover all its home addresses, or
> >
> >     o establish multiple bindings each with a zero prefix
> >       length to cover a single home address.
> >
> >    In the latter case, how does the home agent recognize
> >    that a single node has multiple bindings? I believe the
> >    home agent should avoid sending duplicate home prefix
> >    advertisements to the mobile node.
> 
> I'm not totally understanding this.  It seems like a home agent
> is going to have one primary care-of address for a mobile
> node, and that is what binding the mobile node will effect.

Does this rely on an assumption that two bindings
with the same care-of address apply to the same mobile
node? I think this is dangerous because:

  - We don't know what address assignment policy a remote
    network will use. One mobile node that has an active
    binding could suddenly disconnect, and another move
    onto the same remote network and pick up the same
    care-of address before the previous mobile node's
    binding times out.

  - I can envision someone defining an optimization to
    Mobile IPv6 where the mobile node binds it's home
    address to some intermediate router, then uses a
    local mechanism between itself and that router to
    have messages forwarded on the last leg. In such a
    case, multiple mobile nodes would want to use the
    router's address as their care-of address.

> I agree that the home agent shouldn't send duplicate MPAs
> to the mobile node, insofar as it's possible to do so, but
> I didn't get the connection with the previous bullets, sorry.

There is a good reason, I was making assumptions that were
not intended. 

> 
> >    One way to fix this is to have the home agent to only
> >    send prefix information that is applicable to a specific
> >    binding. Is that what your additional requirement was
> >    after? If so, I agree with the intent, but believe more
> >    detail is needed. Perhaps a statement like the following
> >    would help at the start of this section:
> >
> >  + A home agent normally sends only the prefixes that match
> >  + a mobile node's home registration to the mobile node. A
> >  + match exists if the home registration's home address
> >  + contains a prefix or if the home registration's prefix
> >  + length field is non-zero. Each home registration entry
> >  + in the binding cache MUST be treated as if it were
> >  + created for a separate mobile node.
> 
> I like the last sentence, but it belongs in the section on
> "Home Agent Operation..  The first sentences are
> already implicit in the previous parts of the description
> of the Prefix Lengths field (as it is currently, that is).

Let me try to explain where I was going with this.
I see three policies a home agent could use when sending
prefix information:

 1) The home agent sends prefix information for the registered
    home address.
 2) The home agent sends only prefix information that matches
    the binding.
 3) The home agent sends all prefix information for all
    prefixes in the aggregate list.

I think (1) is covered by the MUST requirements. The MAY
requirements seem to cover (3). I was proposing (2) as a
way to reduce the amount of duplicate prefix information
sent to the same mobile node. The reason for the specific
text I proposed was because if we accept (2), then its
important to be clear what "match" means. My other
suggestions below relied on that term to simplify the text.

> 
> >  > The home agent uses the following algorithm to determine when to
> >  > send prefix information to the mobile node.
> >
> >    There is a requirement at the end of section 9.8.3 to send all
> >    prefixes periodically. I think that requirement should be folded
> >    into this section to avoid confusion between the two sections.
> >
> >  + - Send a Home Agent Prefix Advertisement periodically to prevent
> >  +   non-decrementing prefixes from expiring on the mobile node.
> >  +   Calculate the interval between each successive transmission
> >  +   independently as rand()*HomeRtrAdvInterval seconds;
> 
> I did put in a new bullet according to your suggestion, but I was not
> so clear about randomizing the interval.  I see that it would 
> be a good
> idea to avoid having a lot of advertisements happening all at once,
> but the nature of the Binding Update process seems to imply that
> the transmissions will effectively be randomized anyway, and with
> a longer period between periodic transmissions.

OK.

> 
> >  > - If a mobile node sends a solicitation, answer right away.
> >
> >    If the proposal for the Send All Prefixes flag is accepted,
> >    the following text should be added here:
> >
> >  +   If the Send All Prefixes flag in the solicitation was set,
> >  +   include all prefixes from the aggregate list in the 
> advertisement.
> 
> But that would amount to saying the same thing in two different
> places, unnecessarily, wouldn't it?

Yes. I guess its not needed. 

> 
> >  > - If a prefix changes state in a way that causes a mobile node's
> >  >   address to go deprecated, send an advertisement right away.
> >
> >    I believe the algorithm for RAND_ADV_DELAY covers this situation.
> >    It will cause an advertisement to be sent right away if a change
> >    causes an address to go deprecated. Can we remove this special
> >    case from here simplify the text?
> 
> I have done so at your suggestion.
> 
> >  > - For any existing prefix, 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.
> >
> >   This is covered in the RAND_ADV_DELAY scheduling algorithm below.
> >   Can we remove it from here to simplify the text?
> 
> O.K.
> 
> >  > - 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.
> >
> >    Same comment as before, do we need the special case text that is
> >    underlined? Also, this probably should be qualified to be more
> >    precise.
> 
> O.K.  I removed the text.
> 
> >  + - If a prefix in the aggregate list that matches the 
> mobile node's
> >  +   home registration is added or its information changes, 
> ensure that
> >  +   a transmission is scheduled at time RAND_ADV_DELAY in 
> the future.
> 
> I basically merged this with the previous text.
> 
> >  > - 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.
> >
> >    Did you mean Mobile Prefix Advertisement here?
> >
> >    Is it really necessary to send the Binding Acknowledgement in the
> >    same message as the Mobile Prefix Advertisement? I suspect this
> >    will be awkward to implement given that Binding 
> Acknowledgements are
> >    probably handled in the kernel and Mobile Prefix Advertisements
> >    in a daemon.
> 
> I made it a SHOULD.

Thanks.

> 
> >    The 3rd rule in this list says "do not schedule the 
> advertisement"
> >    if a binding update is expected before the prefix becomes
> >    deprecated. The 5th rule says to send an advertisement if "a
> >    prefix advertisement is scheduled". Any change that satisfies
> >    3rd rule will never be sent. Perhaps this last rule should say:
> >
> >  + - If there are any unacknowledged changes to prefix information
> >  +   when a Binding Update arrives for the home registration, send
> >  +   a Mobile Prefix Advertisement to the mobile node
> > immediately.                                          +   If an
> > advertisement was previously scheduled for the changes,
> 
> Done.
> 
> 
> >    Should the following be added here for completeness?
> >
> >  + - If a home registration expires, cancel any scheduled
> >  +   advertisements to the mobile node.
> 
> Done.
> 
> >  > The home agent uses the following algorithm 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.
> >
> >    I understood that the reason for sending only the changed prefix
> >    information instead of all prefix information is to reduce the
> >    connection costs for the mobile nodes on expensive wireless
> >    networks. We don't believe the cost savings for this extra
> >    complexity will be significant. We would prefer this to be an
> >    optional feature.
> 
> You suggest that the home agent should be allowed to send more
> than the minimum amount of information.  This is O.K., except that
> I didn't find a good place to insert the necessary text.  If you can
> suggest some text, I'll put it in.

OK, something else for me to think through.

> However, the important thing is that
> the Mobile Node _MUST_ be able to correctly interpret a partial
> list to contain only _changed_ information.  A mobile node should
> not assume that missing advertisements mean that the prefix has
> been deleted.  The latter operation has to be done by other means.

Good point. I agree. Is this something that should be stated in
section 10.17?

> >
> >  > If the mobile node's binding expires after the Preferred 
> Lifetime,
> >  > then compute
> >
> >    The indentation following this text could be interpreted to mean
> >    we still need to compute RAND_ADV_DELAY even when the IF 
> condition
> >    here is false. As an alternative, perhaps a rewording of this IF
> >    clause combined with text from above would be helpful.
> >
> >  + If the mobile node's binding expires before the 
> Preferred Lifetime,
> >  + then return. The mobile node will get the revised information
> >  + with its next Binding Acknowledgement. Otherwise, 
> continue with the
> >  + following computation:
> >
> >  >    MAX_SCHEDULE_DELAY ==
> >  >    min (MAX_PFX_ADV_DELAY, Preferred Lifetime)
> >  >
> >  > for the newly advertised Preferred Lifetime.
> >  > Then compute RAND_ADV_DELAY =
> >  > MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt)
> >
> >    There may be a problem overwhelming system or network resources
> >    if the scheduling algorithm causes the home agent to transmit a
> >    home prefix advertisement to all mobile nodes at the same time.
> >    The spec should allow a mechanism to avoid this.
> 
> This was supposed to be part of the point of the RAND_ADV_ DELAY.

Yes, but the algorithm still can cause a burst of traffic when
preferred lifetime is zero or near zero.

> 
> >  + A home agent SHOULD perform scheduling of advertisements
> >  + described in this section independently for each home
> >  + registration in the binding cache to avoid a burst of
> >  + advertisements being sent to all mobile nodes at the same time.
> >  + In addition, a home agent MAY throttle transmission of
> >  + advertisements to prevent overwhelming local resources when
> >  + the rules above require immediate transmission of advertisements
> >  + to large numbers of mobile nodes.
> 
> I used most of your words here.
> 
> > Section 9.8.3 Sending Mobile Prefix Advertisements to the 
> Mobile Node
> >
> > > - When the advertisement was triggered by network renumbering, the
> > >   advertisement MUST include a Binding Request destination option.
> >
> >    I agree with your intent of not requesting ACKs for
> >    every advertisement, but I don't think the term "triggered
> >    by network renumbering" catches all the important situations.
> >    How does the following sound?
> >
> >  + The advertisement MUST include a Binding Request destination
> >  + option if this is the first advertisement sent for a home
> >  + registration or if there was a change in prefix information
> >  + since the last acknowledged advertisement was sent to the
> >  + mobile node for the home registration.
> 
> Done!
> 
> >
> >
> >  > The home agent SHOULD periodically continue to retransmit this
> >  > tunneled packet to the mobile node, until it is acknowledged by
> >    ========
> >
> >    The term "tunneled" was removed elsewhere in section 9.8.
> >    Should it be removed here too?
> 
> Done.
> 
> >  > [Delete this paragraph? This is also too much.]
> >  > Whenever a mobile node has a valid binding on a network other
> >  > than its home network, the home agent MUST send a Mobile Prefix
> >  > Advertisement with all prefixes in the aggregate list to the
> >  > mobile node at least once per HomeRtrAdvInterval seconds, and
> >  > upon receipt of a valid Router Solicitation from the mobile
> >  > node.
> 
> O.K.  I reckon it's already been covered earlier.
> 
> >    I have no idea what "a network other than its home network"
> >    means, but I think a requirement to periodically transmit
> >    all prefixes is needed because home addresses on mobile nodes
> >    still have a finite lifetime that will expire unless
> >    periodically updated. As I stated above, I think this requirement
> >   fits better in section 9.8.2.
> 
> It's there now.
> 
> > Section 10.16 Sending Mobile Prefix Solicitations
> >
> >  > The mobile node SHOULD send a Solicitation to the home agent
> >  > when its home address will become invalid within 
> MaxRtrAdvInterval
> >  > seconds, where this value is acquired in a previous Router
> >  > Advertisement from the home agent. ...              ======
> >    =============
> >
> >    Should this be Mobile Prefix Advertisement?
> 
> Done.
> 
> >  > If the mobile node does not have a valid home address 
> available for
> >  > use as the IP source address, it MAY use its care-of 
> address, [but
> >  > there will not be a security association between the 
> Home Agent and
> >  > the care-of address for the corresponding Advertisement to be
> >  > authenticated.]
> >
> >    We think some kind of security association will be needed here.
> 
> I don't know how to specify that, and the home agent can limit this.

OK.

> 
> > Section 10.17 Receiving Mobile Prefix Advertisements
> >
> >  > - The Source Address of the IP packet carrying the Router
> >  >   Advertisement is .....                           ======
> >      =============
> >
> >    Should this be Mobile Prefix Advertisement?
> 
> Fixed.
> 
> >  > Since the advertisement contains a Binding Request 
> option, the mobile
> >  > node SHOULD return a Binding Update, which will be 
> viewed by the home
> >  > agent as an acknowledgement of the corresponding Mobile Prefix
> >  > Advertisement, which it can cease retransmitting.
> >
> >    Should this paragraph start with "If the advertisement 
> contains..."?
> >    The Binding Request option does not always need to be 
> included with
> >    a Mobile Prefix Advertisement.
> 
> Fixed.
> 
> > Appendix A:  Remote Home Address Configuration
> >
> >    I noticed you didn't attempt to fix this part. How about:
> >
> >    Delete:
> >
> >  > A mobile node MAY generate a temporary home address using the
> >  > following information:
> >  >
> >  > - the subnet prefix from the home network's mobile agent anycast
> >  >    address, and
> >  >
> >  > - the globally unique interface identifier that would have been
> >  >   used to generate the link local address if the mobile node were
> >  >   attached directly to the home network.
> >  >
> >  > Such a temporary address could be used to establish a 
> binding with
> >  > a home agent in the absence of any other known home 
> addresses.  It
> >  > could be created with short valid lifetime and a 
> preferred lifetime
> >  > of zero to ensure a quick transition to other addresses generated
> >  > when stateless or stateful (DHCPv6) address 
> autoconfiguration runs.
> >
> >    Your new Mobile Prefix Solicit/Advertisement exchange capability
> >    between the mobile node's care-of address and home agent 
> makes this
> >    hack unnecessary.
> >
> >    Change steps 5 through 9 to:
> >
> >  + 5. Select the most preferred home agent and establish a security
> >  +    association between the mobile node's current care-of address
> >  +    and the home agent for temporary use during 
> initialization only.
> >  +
> >  + 6. Send a Home Prefix Solicitation message with the Request All
> >  +    Prefixes flag set to the home agent from the mobile node's
> >  +    care-of address.
> >  +
> >  + 7. Receive a Home Prefix Advertisement message from the 
> home agent,
> >  +    follow stateless address autoconfiguration rules to configure
> >  +    home addresses for prefixes received.
> >  +
> >  + 8. Create a security association between the mobile node's home
> >  +    address and the home agent.
> >  +
> >  + 9. Send a binding update(s) to the home agent to register the
> >  +    mobile node's home addresses.
> >  +
> >  + 10. Receive binding acknowledgement(s) then begin normal
> >  +    communications.
> 
> Done, to a close approximation.
> 
> Regards,
> Charlie P.
> 
> 
>