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

From: "Purnadi Rene (NRC/Dallas)" <[email-masked]>
Date: Fri, 26 Oct 2001 16:18:25 -0500

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.

>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. 

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

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.

>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. 
>

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.

>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. 

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.

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. 

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.

>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.
>
>

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.

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

---

From: "James kempf" <[email-masked]>
Date: Fri, 26 Oct 2001 16:52:19 -0700

Hi Purnadi,

> procedure. I hope I have answered based upon the correct understanding

I guess I still don't understand the problem, sorry. If the network is
doing QoS, then I assume a new QoS treatment for the mobile's
packets will need to be set up at the new AR regardless of
whether FMIPv6, SMIPv6 (standard MIPv6), or BETH is used.
Why is tunnel establishment any different? In Solaris (with
which I am a little familar), there is no need for special
QoS when establishing a tunnel.

> sent PrRtAdv) shall keep the tunnel up and change the anchor point.

Actually, after I wrote this, I realized that you could prevent routing
loops by having nAR check whether it already has an outstanding
tunnel for that Care of Address or L2 address.

If the handover is target triggered, then the L2 address in the trigger to
the aAR will
be the same as an L2 address for which the aAR currently has an
open tunnel. If the handover is source triggered, then the oAR will
send the old CoA, which the aAR will recognize as being on its subnet.
In either case, aAR (==nAR) would send a lifetime of zero for the tunnel
back to oAR, indicating that
no tunnel was necessary, tear down the tunnel going out, and take
the MN directly without setting up a new tunnel to oAR. .

So I guess this problem could be handled. But I'm not so sure about
how to terminate the tunnel in the general case. It seems to me that
this would result in a cascade of tunnel termination signaling. It might get
tricky, I think it needs more study.

> by the network.  Hence the network must be able to force the MN to do

Sure, I've got no problem with letting the network remove the tunnel when
it needs to.

I think I understand your point now.
It seems like you are proposing using traffic engineering between ARs in
order
to get better performance on the wired edge, correct? I could even see this
extending to using MPLS LSPs instead of IP in IP tunnels. If it is not
possible to do tunnel chaining, then the network operator is forced to
mesh connect the ARs. This may not be physically possible, or it may not be
optimal.
If tunnel chaining is possible, the network operator has the option of doing
a mesh
or a chain, depending on how the physical and logical parameters of the
particular
deployment dictate.

> , it does not need to compute a new CoA with just an unsolicited RtAdv.

No, this is not so. If the MN receives an unsolicted RtAdv, it is a signal
that
the network wants it to apply for a nCoA. See Section 2.6.1

> to add this event to avoid the confusion.

I've got no objection to using PrRtAdv, but someone else pointed up that
since handover is not occuring, this is not the right message to use.

It sounds to me like you've got some particular cdma2000 applications in
mind. I wonder if any of the other cdma2000-knowledgable folks on the
list care to comment?

I think I'd like to think about how tunnel termination would work with
chained tunnels, and perhaps you could too (and maybe others have
some ideas) before I agree to this. Tunnel termination is one of the
trickiest parts of BETH, and I think I understand how it works with
tunnel handover, I'm not sure I do (yet) with tunnel chaining. If you come
up with something on how tunnel chains would be terminated, please
post it, as will I.

            jak