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

From: Jari Arkko <[email-masked]>
Date: Thu, 02 May 2002 01:57:56 +0300

(Originally brought up by Robert Chalmers.)

Background: A mechanisms exists in Draft 16 to distribute home network
prefixes to mobile nodes. These prefixes are sent along ICMP Mobile
Prefix Advertisement messages. This message can be either solicited
through the ICMP Mobile Prefix Solicitation message, or it can be
unsolicited when the prefixes change. Section 9.9.3 says the
following:

    The advertisement MUST include a Binding Request destination option
    if this is the first advertisement 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.  The Binding Request destination option MUST include
    a Unique Identifier Sub-Option (Section 5.5), with the unique
    identifier in the sub-option data set to a value different than
    that in any other Binding Request sent recently by this home agent.

On the receiving side of this unsolicited advertisement, Section 10.19
"Receiving Mobile Prefix Advertisements" requires the following:

    If 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 transmitting.

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 02 May 2002 10:12:24 +0200

I believe the prefix advertisement stuff which is complex, not yet
useful, etc, should be moved to another document. The current I-D
is already far too long!

Regards

[email-masked]

---

From: Robert Chalmers <[email-masked]>
Date: Mon, 06 May 2002 16:07:35 -0700

Jari Arkko wrote:

> unsolicited when the prefixes change.
 
(.snip.)

>      could contain a Unique ID parameter. The BU would act as an ack.
I personally think that all of the ICMP messages should be converted
into mobility messages (via MH). Since the MH is now a full-fledged
protocol, and not just a collection of destination options, why should
we maintain the separate set of ICMP messages?  By making the Mobile
Prefix Advert into a mobility message, the Unique ID parameter could be
sent along. Then a matching BU could be used to reply.

enjoy,
Bob

-- 
/****************************************************************

 Robert Chalmers
 UCSB Computer Science Doctoral Candidate
 Network and Multimedia Systems Lab (NMSL)

 "My heart is in the code, but my soul lies in the process"
 
 | [email-masked] || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/