Subject: [Capwap] Change Request 9.2.3. Data Encapsulation Standard

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 28 Sep 2005 14:46:44 -0700

This optional change request is to make modifications to LWAPP to make
use of the L2TP or GRE encapsulation protocols instead. The goal stated
is re-use of code.
 
There are two alternatives proposed in this section, which is to make
use of either GRE or L2TP with the goal of code re-use. While I agree
that using GRE means one gets to re-use a GRE module, I believe the cons
far outweigh the pros. Having been the person that pushed for the use of
GRE in PPTP, I am very well aware of the issues this created in terms of
NAT traversal. Basically, in order for PPTP to be NATed, every FW or NAT
server had to implement the PPTP ALG in order to be able to extract the
session identifier out of the control path, which is used to correlate
the control and data path. Conversely, L2TP is NAT'ed for free because
it is based on UDP. 

Furthermore, even with GRE, we would still need to use the LWAPP header
in order to exchange SNR/RSSI information. So, personally, I see GRE is
being an alternative to UDP instead of being an alternative to LWAPP.

Of course, there is then L2TP, but I would argue that LWAPP uses the
same transport mechanism as L2TP, which is UDP. The evaluators state:
"Using a standard gives the opprotunity for code reuse, whether it is
off-the-shelf microcode for processors, code modules that can be
purchased for real time operating systems, or open-source
implementations for Unix based systems"

There are a few issues with this. First, in unix based systems, most
kernels modules have a 1:1 relationship with the control protocol. It is
not clear to me how two daemons (l2tpd and lwappd) could configure L2TP
tunnels. Further, given that we would have to define a new layer 2
specific subtype for L2TP, the current modules would have to be modified
anyways. The new L2 subtype issue holds for microcode as well. In terms
of purchasing source code, I would argue that data header parsing
routines are generally not really worth paying the price of a full L2TP
stack, because 85% of the code would not be re-usable (and the part that
is useful would have to be re-worked).

Therefore, I respectfully disagree with this recommendation.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap