Subject: Re: [mobile-ip] Unresolved issue #18: Prefix advertisement acknowledgement

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 1 May 2002 19:30:33 -0700 (PDT)

> The problem with this is that the ICMP messages and BRs used to be
> carried in the same packet. If the MH no longer carries extra
> payloads, the delivery of the ICMP and the BR packets happens in
> different packets. This poses a problem for relying on the BR/BA as a
> way to acknowledge the receipt of the ICMP.
> 
> Question: Is it necessary to have a reliable prefix delivery mechanism
> even in the unsolicited case? How can we ensure the delivery? Which of
> the mechanisms below should be used:
> 
> (1) Ignore reliability for the unsolicited prefix advertisements.

> (2) Use any BU as a signal to stop sending the unsolicited advert. The
>      lifetime limit (as discussed above) will force the BCE within the
>      appropriate lifetime of existing prefixes.  If the prefix has
>      expired, a particular error code could indicate the problem which
>      would cause the MN to solicit and advert and possibly form a new
>      HoA.

I am not sure I understand the sequence of events in this case.

Does it mean:
1. MN receives unsolicited prefix adv.
2. MN sends a BU anyway to stop further prefix adv (uses existing HOA ?)
   if the prefix information changes (renumbering), MN configures new HOA,
   continues communication until the valid prefix lifetime, after that
   it solicits prefix adv and subsequently sends BU with new HOA after 
   receiving adv.
   
   If there is no prefix change, MN  just updates the prefix lifetime 
   information.
   Should the HA expect a BU at this point ? If HA expects BU as ACK
   only when prefix changes, then we can avoid extra signalling most
   of the time.
   
   I am not sure which error code is being mentioned here - is it something
   locally generated at MN ?

Can we make security association mandatory for unsolicited unicast prefix
advertisement for reliability ?  

choice (2),  does not require BR/BU sequence for prefix delivery.

 I wonder whether we need unique identifier parameter at all then ?

> (3) Rely on the acknowledgment via BR/BA, even if these are carried
>      in a different packet than that for the prefix advertisement.

This option seems ok too, but somehow MN needs to match up the last
prefix adv with the BR. It seems choice (2) is simpler.

> (4) Require the mobile node to make a solicited prefix query
>      as a form of acknowledgement.
> (5) Add a separate ICMP message type for acknowledgement.
> (6) Add a separate Mobility Option to the BA message to acknowledge
>      the receipt of a prefix advertisement. This may also require
>      adding an identifier to the advertisement to be able to match
>      advertisements and acknowledgements.
> (7) Use a non-final MH for the BR message so that the ICMP
>      can also be carried in the same packet.
> (8) Convert ICMP messages to MH messages. Then, the Mobile Prefix Advert
>      could contain a Unique ID parameter. The BU would act as an ack.
> 
> Proposal: No proposal yet.
> 

-Samita

---

From: Jari Arkko <[email-masked]>
Date: Sun, 05 May 2002 18:19:12 +0300

> 1. MN receives unsolicited prefix adv.

Yes.

>    if the prefix information changes (renumbering), MN configures new HOA,

Yes. So, either the old or the new HoA is used but a BU is sent anyway.

>    only when prefix changes, then we can avoid extra signalling most

Good question. There are though rules that dictate when such unsolicited
prefix advs are to be sent. But if you do send one, how do you know what
the mobile node thinks the prefix is? Would the home agent be able to decide
that for this particular MN we don't need to wait for a BU, because it already
knew the prefix?

>    locally generated at MN ?

A new error code in BA.

> advertisement for reliability ?  

The IPsec SA that is talked about in the text? I believe that doesn't
help with the reliability part.

>  I wonder whether we need unique identifier parameter at all then ?

You are right, we don't need that in this alternative.

Jari