Subject: [mobile-ip] question on BET tear down

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 5 Sep 2001 16:57:51 -0500

James and other authors of BETH,

I have a couple of  questions regarding BET tear down:

In section 3.2 it says:

" Once the BET between oCoA and nCoA is in place, it is torn down by 
   one of the following events: ...."

what does a  tunnel between oCoA and nCoA mean here? Do you mean the 
BET between oAR and nAR?

The second event in that same section is

" 2) The MN begins the process of obtaining an nCoA through nAR. 
        This may include either stateless or stateful address 
        configuration. In this case, nAR sends a HRqst(r) with the MN's 
        home address, oCoA, and the R bit set, and the Lifetime field 
        set to zero, indicating that tunneling service is no longer 
        required. The nAR and aAR may elect to postpone terminating 
        tunneling service for some period of time to allow propogation 
        of the MN's nCoA to the HA and CNs. 
 "

My question is, what would the lifetime be set to, if the nAR and aAR
elect to postpone terminating tunneling service?

Thanks,
Madjid

---

From: James Kempf <[email-masked]>
Date: Wed, 5 Sep 2001 15:13:16 -0700 (PDT)

Hi Madjid,

The latest version of the BETH draft clarifies this, I have not yet
posted it because I have been busy with the low latency MIPv4 BETH version,
but I will try to get it out by the end of the week.

Responses below.

>what does a  tunnel between oCoA and nCoA mean here? Do you mean the 

Yes, this is a typo.

>elect to postpone terminating tunneling service?

The nAR needs to renew the tunnel lifetime before it expires, or, if
a request to renew is denied, it must immediately inform the MN that
the MN must obtain a new CoA by sending it a Router Advertisement. 
The nAR needs to send the renewel request sufficiently prior to the
expiration that, if the anchor AR denies the request, the MN has a high 
probability of completing L3 handover before the tunnel times out. This will 
depend on the particular networking configuration, and the MN's traffic (RTT to 
HA and any CNs for BU, etc.), of course, but configuration can estimate a
worst case time.

The new draft has more details about how the tunnel gets torn down
when the MN starts to establish a new CoA. Basically, there are three
ways: the MN has a security association with oAR and sends a BU
after it has the new CoA (same as in existing FMIPv4 draft), the new AR notices 
that the MN is sending traffic with the new CoA as its source address
after the MN has just gone through the process of getting a new CoA (Neighbor
Advertisement and DAD (stateless), or DHCP (stateful)), or some other means, 
like the new AR is snooping the Destination Options to find the BAcks. In the 
first case, the old AR cancels the tunnel, in the second two, the
new AR cancels the tunnel.

		jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 5 Sep 2001 18:11:32 -0500

Thanks for your reply. I think I got my answer, my conclusion
would be: if you want to keep the tunnel up for a while then
you would not send lifetime=0 in the HRqst as it can be interpreted
from the draft, the way it is written.

Also I am getting the impression that MN might like to get
its traffic tunneled to it through BET, even after nCoA acquisition.
Hence at the end the nAR would have to send another HRqst and this
time with lifetime=0 to tear the tunnel down, correct?

Regards,
Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, September 05, 2001 5:13 PM
To: [email-masked]
Subject: Re: [mobile-ip] question on BET tear down

Hi Madjid,

Responses below.

Yes, this is a typo.

depend on the particular networking configuration, and the MN's traffic (RTT
to 
HA and any CNs for BU, etc.), of course, but configuration can estimate a
worst case time.

The new draft has more details about how the tunnel gets torn down
when the MN starts to establish a new CoA. Basically, there are three
ways: the MN has a security association with oAR and sends a BU
after it has the new CoA (same as in existing FMIPv4 draft), the new AR
notices 
that the MN is sending traffic with the new CoA as its source address
after the MN has just gone through the process of getting a new CoA
(Neighbor
Advertisement and DAD (stateless), or DHCP (stateful)), or some other means,

like the new AR is snooping the Destination Options to find the BAcks. In
the 
first case, the old AR cancels the tunnel, in the second two, the
new AR cancels the tunnel.

		jak

---

From: James Kempf <[email-masked]>
Date: Thu, 6 Sep 2001 09:06:52 -0700 (PDT)

>from the draft, the way it is written.

Correct.

>time with lifetime=0 to tear the tunnel down, correct?

When L3 handover is complete (== new CoA aquisition is complete) including
BU/BAck transactions with HA, CNs, and possibly old AR, then either
the old or new AR can initiate tunnel tear down. Prior to that,
tearing down the tunnel runs the risk of stranding any in-flight
packets. The new AR should renew the tunnel when it is about to expire,
even if the MN is in the process of aquiring a new CoA. Only when 
the old or new AR have proof that the MN has a new CoA should
they tear down the tunnel. Such proof was mentioned in the previous
email and is described in the forthcoming draft.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 6 Sep 2001 18:16:24 +0200

> email and is described in the forthcoming draft.
	=> So for the nAR to know that the above has happened, 
	does it monitor te MN's traffic to see whether BAcks from 
	the HA and CN have been received ?

	Hesham

---

From: James Kempf <[email-masked]>
Date: Thu, 6 Sep 2001 09:47:47 -0700 (PDT)

Hesham,

>	the HA and CN have been received ?

As I mentioned in my reply to Madjid yestereday, it doesn't have to.
The oAR can initiate the tunnel tear down if the MN has a
security association (and it *must* in order to send a BU) as
in standard FMIPv6, or the nAR can simply notice that the MN is
sending packets with the nCoA as the source address, so the
tunnel is no longer needed. The nAR can monitor the traffic
to match BU/BAck if it chooses, but it is not necessary.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 6 Sep 2001 19:05:27 +0200

> in standard FMIPv6, 
	=> I understand this part. 

> or the nAR can simply notice that the MN is
	=> But you were explaining that you have it as an option
	so perhaps it needs to be shown how this can happen. 
	I can't see monitoring traffic for BU/BA as being an option really, 
	routers just won't do that. Even if they do, you may not 
	get a BA from CNs. So I'm not sure that having 
	it as an option is useful because it is not a realistic one. 

	Looking for the source address is not accurate either because
	using a new CoA doesn't tell you that the routing is 
	optimised or symmetric. 

	Hesham

---

From: James Kempf <[email-masked]>
Date: Thu, 6 Sep 2001 10:51:57 -0700 (PDT)

Hesham,

>	routers just won't do that. Even if they do, you may not 

Why? If the traffic is encrypted, it would naturally be a problem, but
if its not, then it's a possibility. This is not meant to be a 
prescription but a way that the AR can optimize tunnel management,
more of a hint. Ultimately, the tunnel will time out anyway, these
techniques are to help optimize managment.

>	it as an option is useful because it is not a realistic one. 

According to Section 8.5 draft-ietf-mobileip-ipv6-13.txt (the latest draft I
have), the CN MUST send a BA to the MN if it receives a BU. So the only
reason that a MN would not receive a BAck is that it was dropped in transit.
Section 10.10 says that a MN SHOULD retransmit the BU until a BAck
is received. The draft does not state what the MN should do if 
it does not receive a BAck by MAX_BINDACK_TIMEOUT, perhaps it should.
But, should this occur, it would be no different than in standard
MIPv6, and would constitute a routing update failure. In BETH/FMIPv6,
the situation is better than in standard MIPv6 because the MN is
getting packets through the forward tunnel under its old CoA, so
if a routing update failure occurs, the MN can simply forgo 
sending the BU to the oAR, or the nAR can forgo tearing down
the tunnel when it sees packets going out under the MN's old
CoA.

>	using a new CoA doesn't tell you that the routing is 

I'm not sure I understand. This is a problem in standard MIP and
FMIPv6 as well. The forward tunnel is only needed as long as packets
are coming into the oAR with destination address the old CoA. The reverse tunnel
is only needed as long as packets are coming from the MN
with the old CoA as the source address. When that is no longer happening
the tunnel can be dropped. We could specify a timeout for how long
an AR should wait after seeing the last packet with the old CoA, but
it seems that this may depend on the network configuration and so
should be left up to the network administator. Am I missing something?

		jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 6 Sep 2001 14:50:40 -0500

James,

Thanks for the reply, please see below.

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 11:48 AM
To: [email-masked]
Subject: RE: [mobile-ip] question on BET tear down

Hesham,

		jak

Madjid> Ok, the problem is the following scenario:

the MN has acquired nCoA, but the tunnel is
not torn down, since we want to make sure everybody knows about this nCoA,
in the mean time, traffic might still be going through the tunnel (before it
is torn down), which means the header compression states are also changing.
This means as long as the traffic is flowing through the tunnel, I cannot 
transfer the header compression context from oldAR to newAR.

So I am trying to find out exactly when the traffic stops:
I guess this is when the tunnel is torn down. But when does tear down
 happen:

1-oldAR receives a BU from MN and sends a tunnel tear down to nAR.
2-nAR somehow finds out MN is using its newCoA, by monitoring
MN's traffic.
Does the  MN suddenly starts using its newCoA, without notifying nAR?

I thought in FMIP, the MN sends an NA and gets some ack back from nAR.
Shouldn't that be used as a sure tunnel tear down trigger?

Am I making any sense?

Madjid

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 6 Sep 2001 22:02:34 +0200

> techniques are to help optimize managment.
	=> I didn't say it's impossible, I said that router jsimply won't 
	do it. It's an unnecessary and unrealistic thing to expect. 
	It adds delays per packet for no reason.

> reason that a MN would not receive a BAck is that it was dropped in transit.
	=> Section 8.5:

	   "When any node receives a packet containing a Binding Update option
	   in which the Acknowledge (A) bit is set, it MUST return a Binding
	   Acknowledgement option acknowledging receipt of the Binding Update."

	You've ignored the "A flag set" part.

> the tunnel can be dropped. 
> 
	=> Only in one direction, because packets may stillbe forwarded 
	from the old AR. 

	Hesham

> We could specify a timeout for how long

---

From: James Kempf <[email-masked]>
Date: Thu, 6 Sep 2001 13:25:13 -0700 (PDT)

Madjid,

>1-oldAR receives a BU from MN and sends a tunnel tear down to nAR.

Yes, that is one possibility.

>Does the  MN suddenly starts using its newCoA, without notifying nAR?

Currently, there is nothing in the protocol, nor in FMIPv6, for
the MN to notify newAR when the process of L3 handover, including
routing updates to HA and CNs, completes. If the MN sends a BU to the oldAR,
the newAR gets informed when it gets the HRqst(r) to terminate the
tunnel.

>Shouldn't that be used as a sure tunnel tear down trigger?

MN does send a NA but I believe that happens before sending the BUs and receipt 
of the BAcks from the HA and CNs. If the new AR terminates the tunnel
prior to the MN getting the BAcks, in-flight packets could be lost.

I suppose we could put in a BU to the new AR, but, again, there is
the issue of a security association. Presumably,the new AR
gets it via a context transfer from the old AR, but I don't think
BETH/FMIPv6 can assume this.

Actually, I'm not sure there's an issue here. If the MN has a real
time session going, it can use BETH to delay handover until the
session has stopped. At that point, the header compression state
becomes moot anyway. If it doesn't have a real time session going,
then it can perform L3 handover via the standard FMIPv6 algorithm,
or on the new router, and the compression state can either be
transferred or not. If not, it won't make much difference because
it will get reestablished within 3-4 packets on the new router anyway,
and there is no time critical human waiting for the result.

Am I missing anything here?

		jak

---

From: James Kempf <[email-masked]>
Date: Thu, 6 Sep 2001 14:01:28 -0700 (PDT)

Hesham,

>> >	it as an option is useful because it is not a realistic one. 

OK.

>	=> Only in one direction, because packets may stillbe forwarded 

If the nAR notices that packets are no longer being sent from the MN
with the old CoA, it can send a HRqst(r) with lifetime 0 to the old AR.
The old AR can return an HRqst(r) with lifetime nonzero to indicate
that it would like to prolong the forward tunnel, if there are 
still packets coming from CNs with the MN's old CoA. 

Anyway, the definitive indication is for the MN to send a BU to the
old AR, as per FMIPv6, when the BU/BAcks are in, and for old AR
to send the HRqst(r) to new AR with lifetime zero. This technique
is only for when there is no security association between the
MN and the old AR.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 6 Sep 2001 23:16:55 +0200

> still packets coming from CNs with the MN's old CoA. 
	=> hmm, starting to look a bit messy though.

> is only for when there is no security association between the
	=> I'm not sure that relying on the BU to the oAR is a good
	idea. In some cases there can be one BU sent if the HA is close
	(local) or a MAP...etc.
	I don't have an answer though as to how the tunnel should be torn.

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 7 Sep 2001 00:28:53 +0200

> But doable. :-)
	=> Yes, and I can make it to Mars one day :)
	No seriously, this is like a NAT handling UDP connections, the same 
	problems apply, except in this case we want a much higher 
	certainty about the timers. 

> What solution did the original FMIPv6 design team envision for this? 
> The original design also had a forward tunnel to the new AR, though not the 
> reverse tunnel, possibly for bicasting. I thought that the original
> idea was to send the BU to the old AR  after the MN had completed
> everyting for new CoA establishment. 
> 
	=> The original design had a tunnel to the nAR but only as an
	error case if the address was not useable. The possibility 
	of that happening is minimal. However, if it did happen the 
	problem would have been the same. I didn't get any 
	concrete answers back then either but because it was 
	an error case it wasn't urgent. Bicasting was not an issue 
	for this case, the tunnel end point would have been the MN. 

	For bicasting we were focused on the BU based bicasting.

> We could write the spec to discourage using a tunnel lifetime of
> 0xffff, which is good till cancelled, unless the ARs have some
> means of definitively telling that the MN has completed L3 handover,
> 
	=> "some means" above is the problem. 

> such as the BU or maybe the HRqst(r)/HRply(r) exchange. That way,
> the tunnel will time out eventually if not renewed.
> 
	=> it's a tradeoff between keeping unnecessary state and making 
	sure no packets are dropped. I suspect the exact numbers will depend
	on the system calculations but the draft should highlight the 
	issues and put some guidelines with a safety factor. 

	Hesham

---

From: James Kempf <[email-masked]>
Date: Thu, 6 Sep 2001 15:37:00 -0700 (PDT)

Hesham,

>	issues and put some guidelines with a safety factor. 

OK, I'll write the spec with this in mind. Thanx for the input.

		jak