Subject: [mobile-ip] MIPv6 Fast Handover

From: [email-masked]
Date: Mon, 10 Feb 2003 00:07:05 +0530

Hi,

I have some queries about the Fast MIPv6 draft:

1. Formation of NCoA.
NCoA is provided to MN by the network (PAR or NAR) in case of MN initiated
anticipated handover case only. Why was the formation of NCoA by Access
Routers left out in case of network initiated handovers?

2. What happens if MN moves to new link after receiving FBAck which
indicated that NCoA is invalid? MN will not send NA or FNA in this case,
then when will NAR stop buffering and start forwarding packets to MN?

3. On receiving FNA, the NAR sends NAAck to MN indicating the status of
NCoA. If the NCoA is valid, the draft requires the RA containing NAAck to
be sent to MN's NCoA. But I think, the MN should not be allowed to
configure NCoA till it gets a confirmation from either PAR (FBAck) or from
NAR (NAAck). In that cse shouldn't the NAAck be sent always to MN's PCoA,
irrespective of the status?

4. In MN initiated non-anticipated case, the MN sends FBU on attaching to
new link. But since the tunnel between the ARs is not established yet, the
AR will simply try to forward the FBU (after ingress filtering etc).
Whereas, in anticipated case, the FBU is forwarded due to already
established tunnel. Is this the desired behaviour?

5. About the Handover capability exchange:
Should the Handover capability extension be added to the periodic RA sent
by AR's or should it be added only to RA's sent in response to solicited
RA?

regards,
suvidh

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 10 Feb 2003 10:00:02 -0800

Hello Suvidh,

> Routers left out in case of network initiated handovers?

This is allowed. See Section 6.1.2.
..
"A Proxy Router Advertisement with Code 0 and a New
   CoA Option means that the MN SHOULD use the CoA indicated as a NCoA
   at the NAR. The New CoA MUST be used when Stateful CoA configuration
   is indicated and MAY be used to assist the PAR and MN calculate the
   same NCoA when Stateless address configuration is used."

> then when will NAR stop buffering and start forwarding packets to MN?

Good point. I think we need the MN to send FNA (or an equivalent option
in Router Solicitation) in this case as well. In general, I think we need a
mechanism to announce to the NAR that the MN has attached. So, I think
it would be good to define an option for RS.

> irrespective of the status?

I think it should be sent to the link-local address.

> established tunnel. Is this the desired behaviour?

The question is when can the tunnel be established. If it cannot be
established prior to the MN attaching to the new link, then it is done
subsequent to new link establishment.

Note however that, when we move PrRtSol and PrRtAdv ahead of handover,
a tunnel is not established until FBU is processed. So, in that case, the two

scenarios you mention above should have the same behavior.

> by AR's or should it be added only to RA's sent in response to solicited

Sending it as a response limits it to those that are Fast Handover capable.

Thank you for your questions.

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Feb 2003 10:20:23 -0800

> it would be good to define an option for RS.

I think that we should introduce an invariant: either the MN knows it has a
valid new CoA before moving to the new link or it doesn't. If it doesn't, then
it must proceed to form a new CoA on the new link. If it does, then it can
proceed with BUs to HA and CN.
That would allow us to drop FNA and thus simplify the protocol.

> scenarios you mention above should have the same behavior.

This point has bothered me for some time. Why should the new AR's ingress filter
allow the FBU through to the previous AR, if there has been no signaling between
the routers prior to the handover to establish the tunnel?

        jak

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 10 Feb 2003 11:02:30 -0800

> That would allow us to drop FNA and thus simplify the protocol.

I think there is already an invariant: the MN's LL address which is
present both in HI and FNA. The original purpose of FNA was to confirm a
new CoA when FBAck has not been received. I agree we should (now) require the MN
to always send a single message, perhaps as an option in RS, upon connecting
to the new link. This message would

- confirm a new CoA
- obtain a new CoA (when FBack is received but negates the requested CoA)
- announce the presence to the new router

I believe you (James) proposed something along these lines before the last IETF..
We can refine the current FNA format to accomplish this.
What do folks think ?

> the routers prior to the handover to establish the tunnel?

I believe there was considerable discussion on this topic before
the last IETF. I would let others respond :-)

Regards,

-Rajeev