Subject: [mobile-ip] Improving BETH: Tunnel Negotiation

From: "Sreemanthula Srinivas (NRC/Dallas)" <[email-masked]>
Date: Tue, 2 Oct 2001 16:07:40 -0500

We are making the following proposals for improving BETH.  Please refer 
to the following draft for more details.

http://www.ietf.org/internet-drafts/draft-sreeman-enhance-beth-ipv6-00.t
xt

Proposal 1: 
Allow negotiation of lifetime of the BET between the oAR and
the nAR. The smaller of the two timers (Tunnel requester or responder)
should be the one that determines the lifetime of the
tunnel. Negotiation does not mean multiple exchange of messages
between the tunnel end-points. 

Reason: 
Flexibility of deployments especially wherein you have different
domains with differing policies for the way they deal with traffic
coming from within or an external network. 
 
Proposal 2: The support for tunnel refresh or renewal of the lifetime 
of the tunnel should be made known at the time of tunnel setup via 
a flag which indicates whether the tunnel originator or terminator 
allows it. In case either router does not support tunnel refresh, the 
other router needs to react appropriately.

Reason: Prevents subsequent signaling in the network to try to refresh 
the tunnel and discover at that point that the refresh is not possible, 
thus introducing possible latency in the MN handoff. As soon as BETH 
is completed and the MN has moved at L2, the nAR can instruct the 
MN to do get a nCoA. The proposal also provides a mechanism for the 
network of either oAR or nAR to somehow indicate to the MN to HO to 
the nAR at a certain time based on local network policies.

Thanks,
Srinivas Sreemanthula

---

From: James Kempf <[email-masked]>
Date: Fri, 12 Oct 2001 15:34:16 -0700 (PDT)

Sreemanthula, 

Thanx for these proposals. Sorry it took so long to get back to
you, I was on vacation.

>coming from within or an external network. 

I think the current draft has aAR controlling the tunnel
lifetime, but I agree that the above proposal would be desirable. The intent
of having the aAR control the tunnel lifetime is that an
aAR may be serving as an anchor for many tunnels, and so
it may have need to limit the lifetime of tunnels that
it can support. But one could make the same argument for the
other end of the tunnel.

>the nAR at a certain time based on local network policies.

This sounds reasonable to me as well.

Unless anyone else in the WG has objections, can you send specific proposed 
wording changes in the draft to Gopal (cc'ing me at [email-masked])?

		jak

---

From: "Sreemanthula Srinivas (NRC/Dallas)" <[email-masked]>
Date: Thu, 18 Oct 2001 17:54:08 -0500

Hi James, 

Thanks for accepting the proposals. I will draft the text accordingly
and send it.

Regards,
Srini

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: 12 October, 2001 5:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mobile-ip] Improving BETH: Tunnel Negotiation

Sreemanthula, 

lifetime, but I agree that the above proposal would be desirable. The
intent

Unless anyone else in the WG has objections, can you send specific
proposed 
wording changes in the draft to Gopal (cc'ing me at [email-masked])?

		jak