Subject: [mobile-ip] BETH comments and questions

From: Alper Yegin <[email-masked]>
Date: Tue, 31 Jul 2001 19:16:59 -0700 (PDT)

Hi James, et. al,

Finally I found some time to analyze the BETH draft in detail.. Some comments 
and questions..

As I understand, the approach BETH is taking is to eliminate the L3 signalling 
over the air, therefore eliminate the associated latency. While this goal is 
accomplished, I think this also creates some potential problems for the mobile 
node. Taking mobile node out of the loop makes me uncomfortable, because:

Mobile node is a passive player in this protocol. Since this protocol takes away 
the signalling between the MN and the AR, MN cannot know when BETH takes place. 

Imagine a mobile node that detects it's receiving new router advertisements with 
a different prefix, and no longer hearing advertisements from oldAR. It also has 
detected a L2 break-and-make recently. Mobile node will "discover" this 
"movement", will attempt to unconfigure its oldCoA and configure a newCoA, and 
send BUs around. This, of course, won't play well if there is a BETH going on in 
parallel. 

Maybe ARs should advertise their BETH capability in advance. But, can mobile 
node always count on BETH taking place, and supress other protocols (MIPv6, 
FMIPv6) execution?

Another case... Mobile node has two interfaces. It might just prefer to use 
basic MIPv6 (forwarding from previous CoA) for handoff. oldAR and newAR might 
decide the handover the mobile, while mobile might want to handover to thirdAR 
using it's other interface. How does this play with ARs doing BETH between them? 
Maybe oldAR and newAR should abort the operation as soon as they see mobile node 
sending a BU? Mobile node *might* even choose to send this BU directly to HA or 
CNs, if it doesn't care for forwarding from previous care-of address.

These two are potential problems due to mobile node not being in control, or at 
least not informed. And I think "control" is more needed for multi-interfaced 
mobiles.

Regarding to FMIPv6 analysis (Appendix A.4)... Any traffic that takes place in 
old-link can be categorized under "anticipation". They don't necessarily 
introduce delay in the service, but they require so much anticipation. They have 
to take place before L2 breaks.

And arrival of F-NA at the newAR can be substituted with L2 triggers, which BETH 
already relies on.

So, the L3 Handover Latency table in Appendix A.4 should be re-done IMO.

Draft says BET is torn down when "The MN begins the process of obtaining an nCoA 
through nAR.". How does the newAR know that? Is is through newAR detecting that 
MN is doing a DAD on a CoA?

Draft says "The MN is in the best position to know when it can afford to pay the 
latency cost of CoA establishment." I don't think obtaining a newCoA has a 
latency cost. It can happen in parallel with on-going traffic using oldCoA.

Cheers,

alper