Subject: RE: [mobile-ip] some issues with IPv6 mobility draft (sharif)

From: "Shahrier, Sharif M." <[email-masked]>
Date: Mon, 9 Apr 2001 16:34:57 -0400

Phil,

	I checked the draft section 10.8. It doesn't seem to specify when
the BU
	is sent, i.e. before or after. I guess this is determined in part by
handoff
	protocols. 

	Also, I don't believe that sending the BU after the move will solve
the 
	problem. For example, suppose A and B move at the same time. After
the move
	they both send a BU to each others respective *original*
destinations. Thus,
	again neither will be advised of their new locations. 

Best Regards,

Sharif Shahrier
InterDigital

Sharif,

Doesn't the BU get sent shortly *after* every move?  So the condition where
you send the BU and then move seems to be a rare case or perhaps when
handoffs are occuring in *rapid* succession (i.e. faster than the latency
between MN_A and CN_B).  If the ping time between MN_A and CN_B
is longer (on average) than the inter-handoff time MIP breaks in many
awful ways right (i.e. it doesn't work) right?

----- Original Message -----
From: "Shahrier, Sharif M." <[email-masked]>
To: <[email-masked]>
Sent: Monday, April 09, 2001 2:46 PM
Subject: [mobile-ip] some issues with IPv6 mobility draft (sharif)

>
> > I have some issues to discuss with the document:
> >
> > "Mobility Support in IPv6"
> > <draft-ietf-mobileip-ipv6-13.txt>
> >
> > I would be grateful if people can take a look and make any contructive
> > comments. Thanks.
> >
> >
> > 1. Consider A, B where A is the mobile and B is the correpondent node.
> > A is currently
> > away from its  home agent. B is also a mobile node. Suppose A send a
> > BU(A) and moves
> > to its new location. The network is heavily loaded, and B has not
> > yet received the
> > binding update. B also was to move. Thus, similarly, it sends a
> > BU(B) to A, and moves
> > to its new location. The binding updates BU(A) and BU(B) eventually
> > arrives at A's
> > and B's previous locations, respectively. But A and B have already
> > moved. This means
> > that nodes neither A or B will are aware of each other new
> > respective locations.
> >
> > Thus, I believe this is be an erronous condition wrt A and B not
> > knowing each others
> > final destination addresses.
> >
> > 2. In light of the potential problem in (1), I propose that we
> > eliminate all signaling
> > between mobile-to-mobile with respect to Binding Update and Binding
> > Request messages.
> > Instead, after a mobile has moved to a new location:
> >
> > - It only sends a Binding Update to its home agent.
> > - Home agent updates the binding for the mobile.
> > - The home agent maintains a Binding Update List containing
> > all the
> >   correspondent nodes that are currently communicating with
> > the mobile.
> > - The home agent (uni)multicasts a Binding Update to all the
> > nodes in
> >   that Binding Update List.
> > - The correspondent nodes send back Binding Acknowledgement
> > to the
> >   home agent.
> > - Home agent, in turn, sends back Binding Acknowlegement to
> > the mobile.
> >
> > Under this scheme, we eliminate the need for mobile-to-mobile
> > signaling. Only
> > signaling between home agent and the mobile and correspondent(s)
> > nodes are
> > neccessary. Also, something like the scheme above may slove the
> > problem
> > described in (1).
> >
> > 3. If the home agent has failed/reconfigured, I believe that "dynamic
> > home agent
> > discovery" is used to locate a new home agent on the home link.
> > However, it
> > does not guard against failure to the home link itself. For this
> > pupose we
> > need to add fault tolerent capability to guard against link failure.
> >
> >
> > Designate a "primary" home link and a "secondary" home link. Under
> > non failure
> > conditions, primary link is used as the home link. If the primary
> > link fails,
> > then the secondary link is used. New home agent is located. Of
> > course, the
> > number of links can be increased to an arbitrary number.
> >
> > These three points are not intended as final solutions, but as
> > a framework from which a formal solution can be drafted.
> >
> >
> > Best Regards,
> >
> > Sharif Shahrier
> > InterDigital
> >
> >
> >
>

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 9 Apr 2001 16:02:08 -0500

Hi Sharif,

*If* this is a real problem and it certainly seems to be, I guess I
would like to propose a solution that does *not* involve the HA.

What COULD be done is to perhaps send the hand off candidate
*list* (collection of HA/FA advertisements) heard by MN_A in
the BU to CN_B.  Then CN_B could multi-cast traffic temporarily
to all the "advertised" new homes.  I would prefer this solution
since it requires only a small change on the MN not at HA.

Thanks,

Phil Neumiller

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 09 Apr 2001 14:39:03 -0700

Okay, they wont. A keeps sending BUs to B's old CoA. It 
would keep getting ICMP unreachable messages for B's old
CoA. then A would delete the binding cache entry it has 
for B. A would then send the next BU to B's home address, 
which is forwarded to B by B's home agent. so B eventually 
knows where A is.

this works because you fall back to the home address when
you cant reach someone at a particular CoA.

it doesnt make sense for the Home Agent to maintain binding
update lists for each mobile that it seves as the home agent.

vijay

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 9 Apr 2001 17:15:23 -0500

It would seem that perhaps an optimization is possible here then?
I wonder "how long" it would take for the fall back to occur and
how frequently this particular pathological race condition could
occur.

-pdn

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 09 Apr 2001 15:46:29 -0700

Phil,

If A has an active session going on with B, then it wouldnt 
take long for A to figure out that B is not reachable.

there is no 'race condition' here. they are just unreachable
for a short duration of time. wonder how you came up with
the term 'race condition' for this?

vijay