Subject: [mobile-ip] BETH comments and questions

From: "alper" <[email-masked]>
Date: Mon, 6 Aug 2001 03:19:00 -0700

[my mail server was down. I dont seem to receive these e-mails. following
them from the mobile-ip archieve..]

Hi Ajoy,

I understand that the BETH should be deployed in a domain, therefore
neighbor
ARs in this domain will be BETH capable. But we cannot claim "all" the
neighbor
routers will be BETH capable, as the whole Internet is not a single domain,
and
we don't expect every ARs to support BETH.

Therefore, I cannot speculate how often but, MN will attach to
BETH-incapable
ARs.

It's perfectly fine if handoff performance is better when BETH kicks in, and
the performance is as good as stock-MIPv6 whenever BETH is not available.

But, I think performance of handoff is worse than stock-MIPv6 when MN does a
BETH-to-nonBETH handoff. First it has to wait and detect that BETH didn't
work.
Only after than it can start stock-MIPv6 handoff. I don't know how much
delay
this introduces as the draft doesn't outline the process in this case. So,
how
soon can we detect a real-time flow is cut?

Also once the MN enters a non-BETH domain, it better "learn" that this is a
non-BETH domain, so it doesn't get hit at every handoff in this domain.

alper

Hello Alper:

Sorry for jumping in the middle of discussion.
Please find my inline response.

regards,
ajoy

During a real-time communication, if your MN detects that it has attached to
a new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and
MN would do nothing, as I understand. But, what if the newAR is not BETH
capable, or BETH has failed for some reason. The only way to figure this out
is to wait, I think. There seems to be no other way, because there's no L3
signaling between MN and newAR. And this wait will effect the handoff time,
if newAR is not doing BETH.

ajoy: If BETH is deployed in particular access technology, it is assumed
that
neighboring routers will be BETH capable. Neighboring routers have to
understand same protocol to support fast handover. For example, if
neighboring routers do not support same protocol, we cannot support context
transfer, the MN has to negotiate context. This is true for any protocol in
general. If BETH fails due to any reason, MN will detect service disruption
because real time traffic flow will stop. MN can use this information as a
trigger to acquire new COA. If you do not support BETH in low data rate
channel, the service of user will be affected every time MN moves from one
AR
to other. Which one you will choose ?

---

From: Sebastian Thalanany <[email-masked]>
Date: Mon, 06 Aug 2001 08:01:14 -0500

Hello Alper,
                      To achieve the BETH support for real-time traffic streams,
the assumption is that the neighboring ARs are BETH capable. BETH capability is
required to be installed via system engineering to support the handoff of
real-time traffic streams.
                      In the absence of BETH, the stock MIPv6 procedures are
applicable. In the case that BETH was only partially deployed, the impact on the
handoff of real-time traffic streams would be less severe than if only the stock
MIPv6 procedures were available. In the specific cases, where a handoff occurred
from a BETH capable AR to a non-BETH capable AR, the additional latency incurred
in the detection and switching to the stock MIPv6 procedures could be used as a
trigger for network management to re-engineer the system for BETH deployment.

Regards,
   Sebastian