Subject: [mobile-ip] Improving BETH: chain tunneling

From: "Purnadi Rene (NRC/Dallas)" <[email-masked]>
Date: Tue, 2 Oct 2001 16:35:14 -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

Current BETH:
 
According to draft-kempf-beth-ipv6-02.txt, in the model for the "handoff
to third" a new BET tunnel is established from the anchor AR (aAR) to
the new AR (nAR). Since the MN may maintain the BET tunnels for a while,
there may be some issues related to QoS. In fact, in order to guarantee
that the BET tunnel supports the QoS needed by the MN, we need to either
assume that an SLA is in place between the oAR and nAR or that
"pre-defined" QoS is allocated between the oAR and the nAR. However,
since it is not possible to foresee a-priori where the MN is going to
handoff to and since the BET tunnels will be established not only
between "adjacent" routers but also between non-adjacent routers (HTT
case), the adoption of SLAs or pre-defined QoS in order to guarantee the
QoS for the MN over the tunnel does not scale well. As an alternative,
at the BET establishment a QoS negotiation can take place to ensure the
QoS for the tunnel will be supported. However, such QoS negotiation may
in some situations introduce some latency.

		       new tunnel
       || ==============================================||
       ||                                               ||
  +-------+                  +-------+               +-------+
  |       |    old tunnel    |       |               |       |
  |  aAR  | ================ | oAR   |               |  nAR  |
  |       |                  |       |               |       |
  +-------+                  +-------+               +-------+

            Original BETH procedure

  +-------+                  +-------+                +-------+
  |       |    old tunnel    |       |  new tunnel    |       |
  | aAR   | ================ | oAR   | ===============|  nAR  |
  |       |                  |       |                |       |
  +-------+                  +-------+                +-------+

            Proposed Beth enhancement

Proposed enhancement:
 
We propose that the BETH model should accommodate the option of "chain
tunneling" where, in case of handoff to third, the oAR creates a new
tunnel to the nAR. The procedure to establish the new BET tunnel from
oAR to the nAR is  the same as the procedure to establish the initial
tunnel from the aAR to the oAR. 

Reason:

Different domains will manage traffic and QoS according to specific
mechanisms and policies. Some networks may prefer to support QoS for BET
tunnels by pre-allocating QoS between physically adjacent routers, i.e.
router to which the MN can move in "one step" due to handoff. Given a
router, the number of physically adjacent routers is limited, and the
amount of QoS "pre-allocated" can be determined, e.g. for cellular
links, based on the amount of radio links that can be accepted in a cell
as handoff links (this is already being done in cellular networks, thus
there is no impact on L2). The use of chain tunnels and pre-allocated
QoS is a scalable solution that allows for fast handoffs and guaranteed
QoS with minimal network configuration.

Result:

Creating long tunnel chains may have issues, e.g. many routers in the
chain need to maintain the state. The chaining issues, however, can be
reduced by forcing the MN to obtain a new COA every time it does a BETH
Handoff. The proposed chain tunneling plus the network ability to force
the MN to obtain nCoA and to move to the nAR, solve the issue related to
chain tunneling. For fast moving MN, a new BETH handoff may take place
before the MN has created nCoA and moved to the nAR,thus multiple
tunnels may exist at the same time. However, multiple tunnels are only
temporary.

---

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

Purnadi,

Comments embedded.

>QoS for the MN over the tunnel does not scale well. 

Can you explain why this is any different than standard MIPv6?

>As an alternative,

The difficulty with this proposal is that it introduces the possibility
of routing loops if the MN moves back to aAR. Can you explain how you would 
avoid that, short of forcing the MN to always establish
a nCoA on nAR?

>Handoff. 

This issue comes up all the time, and I am curious why. People
seem to have difficulty with the concept of removing all
IP signalling so that you just have the bare minimum latency. Basically,
any introducion of MIP signalling on handover is going to result
in a disruption of the real time traffic on handover on low
speed links, period. The whole point of BETH is to let the MN decide when to 
perform handover, or have the network force handover if its required.

>The proposed chain tunneling plus the network ability to force

The network is *always* in a position to force handover. If an AR 
requires that the MN establish a nCoA to force QoS negotiation
or for any other reason, it can send an unsolicited Router Advert
and the MN must perform the handover.

		jak

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 29 Oct 2001 10:50:30 -0600

Hello Purandi:
Please find my inline comments/question.
I may provide more comments after 
thoroughly studying your proposal. 
regards,
ajoy 

-----Original Message-----
From: Purnadi Rene (NRC/Dallas) [mailto:[email-masked]]
Sent: Friday, October 26, 2001 4:18 PM
To: [email-masked]
Subject: RE: [mobile-ip] Improving BETH: chain tunneling

Hi James,

Thanks for your comment on our proposal. My comments are embedded. Sorry
for the late reply since I was travelling and then I was swamped with
other things

Rene Purnadi
Phone: +1 972.894.4897
e-mail: [email-masked]

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

Purnadi,

Comments embedded.

Rene>> The MIPv6 does not have the QoS establishment procedure, and the
QoS negotiation happens separately. For a new route or tunnel
establishment, you need to ensure the QoS consistency. This means
additional QoS signaling and the delay associated with signaling and
establishment. This may not be suitable for time critical handoff
procedure. I hope I have answered based upon the correct understanding
of your question.

The difficulty with this proposal is that it introduces the possibility
of routing loops if the MN moves back to aAR. Can you explain how you
would 
avoid that, short of forcing the MN to always establish
a nCoA on nAR?

Rene>> There will not be any routing loops.  One way to do this is, the
aAR can determine that the MN has still CoA from aAR (IP Address Option
containing MN's old Care of Address) and it has established a tunnel to
oAR. It either responds normally to the HRqst with HRply to nAR, but
soon after L2-UP happens at the aAR, it tears down both tunnels to oAR
and nAR/aAR, or it won't create the second tunnel to the oAR and soon
after L2-UP happens at the aAR, it tears down the tunnel to oAR.  There
is no need for tunnel and for nCoA. However, if the MN is in the process
of getting a nCoA then the either the oAR or the nAR (depending on who
sent PrRtAdv) shall keep the tunnel up and change the anchor point.

ajoy-> I think chained approach introduces additional single point 
of failure in the system which may not be a good idea. The chaining 
will also add extra end-to-end delay due to queuing and processing
delay at the chained nodes. 

speed links, period. The whole point of BETH is to let the MN decide
when to 

Rene>>  the idea is that we force the MN to get a nCoA only after the
BET is established and the MN has moved at L2 so that the time critical
L2 handoff can be conducted without interruption. This may happen
immediately or later according to the policies of the AR. In fact, in
case of low speed channels you need already to optimize the way you send
signaling over traffic channels for several reasons. Here, you can
safely assume that the MIP signaling is distributed in such a way that
it has the minimal impact on the quality of the real time service. In
addition, the signaling may be transmitted over the dedicated signaling
channel in cdma2000/UMTS. 

ajoy->Could you please provide me additional information about how Mobile/IP

message can be mapped over cdma2000 dedicated channels? I am not aware of
any
such standard, but I would like to know. My understanding is that cdma2000 
RLP does not support any quality of service and RLP treats all the traffic
received for a Mobile Node as octet stream. 

In any case, it is desirable from the network point of view that the
traffic path is optimized by removing the tunnel as and when determined
by the network.  Hence the network must be able to force the MN to do
new CoA formation.

ajoy-> How much optimization we are talking about ? I guess in typical 
well engineered network, you may not really get substantial 
benefit by optimizing this route. Anyway in case of BETH, network 
can force the Mobile Node to acquire new care of address, hence
this optimization can be obtained.  

Rene>> But our understanding is that if MN has L3 connectivity with oCoA
, it does not need to compute a new CoA with just an unsolicited RtAdv.
Hence, we support an explicit command like PrRtAdv or other.   We both
agree that the network is in control of "forcing" the MN when it wants
as per the local policy of the AR .  But it was not clear from the list
of events provided in the section 2.5 of BETH draft.  It would clarify
to add this event to avoid the confusion.

		jak