Subject: [mobile-ip] questionable mobile node requirement

From: "Ed Remmell" <[email-masked]>
Date: Tue, 18 Mar 2003 17:53:28 -0800

Hello,

I'm busy doing some requirements traceability for the mobile node
requirements, and I ran across the following confusing requirement:

"If the mobile node wants to ensure that its new care-of address has
   been entered into a correspondent node's Binding Cache, the mobile
   node MAY request an acknowledgement by setting the Acknowledge (A)
   bit in the Binding Update.  In this case, however, the mobile node
   SHOULD NOT continue to retransmit the Binding Update once the
   retransmission timeout period has reached MAX_BINDACK_TIMEOUT."

This has been there since draft 18++, perhaps even earlier. The part that I
find questionable is the "SHOULD NOT continue to retransmit...". What SHOULD
the mobile node do in this case, then?

1) assume that the it cannot successfully create a binding in that
correspondent node, i.e. a hard failure for route optimization, and then
disable the use of route optimization with that specific correspondent node
(similar to what the mobile node would do if the CN responded to the BU with
a Binding Error status 2 "Unrecognized MH Type value").

- OR -

2) assume that the correspondent node successfully created the mobility
binding, but isn't compliant to the specification and therefore refuses to
respond with the BA even though the mobile node explicitly requested a BA by
setting the (A) bit in the BU?

It is always possible (although not too likely, but RF is a "lossy" link
type so it could happen) that the BUs and/or some of the BAs that the CN
sent in response were dropped and so the binding was actually successfully
created in the CN after all (however, the MN gave up sending the BU before
it received the BA response).

If the MN assumes that the binding was successfully created in this case (#2
above), even though the lifetime that it stores in the BUL entry won't be
synchronized with the CN binding lifetime (since the MN never received the
BA) at least the MN will get back a Binding Error status 1 "Unknown binding
for Home Address destination option" in the case where the CN didn't create
the binding which allows the MN to reinitiate the return routability
procedure, but then that causes the MN to start sending BUs again so it
seems like nothing was accomplished by the above "SHOULD NOT" requirement
besides adding extra complexity to the mobile node BUL entry state machine?
On the other hand, if the MN transitions this BUL entry to the "route
optimization disabled" state (so that it stops any attempt at return
routability/route optimization with that specific correspondent node), it is
possible that the CN actually did successfully apply the BU and create the
binding, so now the MN believes that the binding was not created and the CN
did actually create it which doesn't sound like a good state to be in.

My suggestion is to just remove this "SHOULD NOT" requirement, and then
mobile node processing in this case becomes identical to the processing of a
home registration BU/BA exchange (which has the mobile node continue to
retransmit the BU to the home agent at the slower rate MAX_BINDACK_TIMEOUT,
if it doesn't know of another home agent to try).

Thanks.
- Ed Remmell
Elmic Systems, USA