Subject: [mobile-ip] MIPv6: UID in BRR and BU superfluous?

From: "Kevin Miles" <[email-masked]>
Date: Thu, 26 Sep 2002 16:23:21 +0100

The UID exchanged in a BRR and its resulting BU doesn't appear to add any value. 

The proposed description of its use, as a response to issue #59, is below. 

6.2.4 new text:

 The Unique Identifier option is valid only in Binding Refresh
 Request, and Binding Update messages.  The Unique Identifier field
 contains a 16-bit value that serves to uniquely identify a Binding
 Refresh Request among those sent by this Source Address, and to
 allow the Binding Update to identify the specific Binding Refresh
 Request to which it responds.

I cannot see how a CN or MN can benefit from having the UID. Consider what happens.

The CN will persist with its BRR until it gets a BU or reaches it's retry limit. If the MN receives a duplicate BRR, it has no way of knowing whether it received it because the BU it just sent got lost or collided with this new BRR. So it will send a further BU. Therefore it doesn't care whether the BRR was a duplicate or not; its behaviour will be the same either way, so the UID doesn't help the MN. At the CN, it will be operating some local policy that causes it to send BRRs for a particular binding. Presumably, when a BU for such a binding arrives, the policy will cause it to cease sending a BRR. If a BU doesn't arrive, it will reach its retry limit and cease sending the BRR. The CN already has a mechanism for associating an unsolicited BU with an existing binding, so the UID doesn't appear to help the CN. 

What's it for? Can we remove it?

Kevin.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 29 Sep 2002 23:57:06 +0300

Kevin Miles wrote:
> The CN will persist with its BRR until it gets a BU or reaches it's retry limit.
> If the MN receives a duplicate BRR, it has no way of knowing whether it received
> it because the BU it just sent got lost or collided with this new BRR. So it will
> send a further BU. Therefore it doesn't care whether the BRR was a duplicate or not;
> its behaviour will be the same either way, so the UID doesn't help the MN. At the CN,
> it will be operating some local policy that causes it to send BRRs for a particular
> binding. Presumably, when a BU for such a binding arrives, the policy will cause it
> to cease sending a BRR. If a BU doesn't arrive, it will reach its retry limit and
> cease sending the BRR. The CN already has a mechanism for associating an unsolicited
> BU with an existing binding, so the UID doesn't appear to help the CN. 

I don't think there's much use of the UID for the CN-MN protocol. For instance,
the CN will be able to see from a combination of its own address and the MN's
home address if this particular binding was the one it was expecting to get
refreshed.

But I think the UID was originally designed for the HA-MN communication, and
in particular the guaranteed delivery of new home prefixes. However, the
current delivery mechanism relies on the home agent's ability to see BUs
for the newly announced prefixes and not UID.

So I agree that UID does not at the moment serve any function, and
removing it would simplify the specification. I would also like to
remove it.

Text proposal:
- Remove 6.2.4
- Remove references to UID from 6.1.2, 6.1.7, 11.6.4, 13.

Jari