Lwapp Mailing List: RE: Another Way to Think about CAPWAP

[Jerome Moisand (jmoisand]

Title: RE: [Lwapp] Another Way to Think about CAPWAP

I've been monitoring this thread for a while. Quite a lively discussion...  ;-)

 

I'm speaking as somebody with experience about large BRAS deployment (working for Juniper Networks), and thinking that it might a natural extension for a RAS system to act as an AR (as explained in the original LWAPP write-ups if I remember well).

 

I think we have to be very careful not to reinvent the wheel.

 

I absolutely agree with the view that discovery & configuration/signaling (what I would call a control plane) should be cleanly separate from a data plane (user data being forwarded). Such control/data separation has been proven a wise architectural construct in many many contexts...

 

I absolutely agree with that the data plane is very performance-sensititive (cf. multimedia/VoIP traffic down the road), and should be based on a STANDARD form of IP tunneling technique (there are more than enough to choose from). I'm not 100% sure encryption is an absolute requirement for such tunneling, but I can see why this might be interesting as an option. I would definitely let 802.11-specific encryption (WEP, TKIP, AES, etc) occur in the AP, since it's applicable only on the 802.11 (MAC) network segment, and requires very specific hardware.

 

So it seems to me that the main task here (after selecting one tunneling protocol or another - preferably a light one-) is to work on the control plane. Here we have a RAS-like device (the AR) controlling a light access device (the AP in this case). This is clearly a new concept, which may (but not necessarily) require a new protocol. Spelling out requirements for such "inband" control protocol should help refine the problem, before jumping to specifications.

 

I can't help but think that such RAS<->AccessDevice scenario is not specific to WiFi/802.11. Please read again the e-mail I sent to you guys a while ago on this topic... For your information, while you guys were meeting at IETF last week, there was a push in the DSL-Forum (also last week!) to have a similar control mechanism between a BRAS and a DSLAM (another form of a layer2 access device).

 

So I tend to believe we should have a fairly generic control protocol, and then some form of information model on top of it to define technology-specific objects to be conveyed... I don't believe there would be that many policy objects for WiFi "light" APs. In this respect, the SNMP idea which was discussed is interesting, although this is likely at odds with performance and simplicity (notably on the AR/RAS side) requirements (SNMP proponents, please don't flame me, just expressing my view). Yet, thinking to the use of a management protocol for such "inband" control has definite merits, as long as it is "transactional-enough and simple-enough".

 

Bottomline: let me suggest to cleanly separate control plane & data plane as a starting principle; then to not start much of yet-another-raging-protocol-debate, but come back to spelling out requirements first.

 

Tx

Jerome

 

-----Original Message-----
From: lwapp-admin [at] frascone.com [mailto:lwapp-admin [at] frascone.com]On Behalf Of Pat R. Calhoun
Sent: Tuesday, November 18, 2003 8:25 AM
To: Rama Krishna Prasad; Yang, Lily L; James Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP
Subject: RE: [Lwapp] Another Way to Think about CAPWAP

There are mainly three different types of data that need to go between AP and AC.
Discovery related messages,  configuration/signaling information and actual
data packets.  Data packet could be voice data and requires QoS. TCP is not
a good transport to transfer this information. For discovery,
multicasting is required and TCP is not suitable. For control and signaling data,
either TCP or UDP with application reliability can be adapted.

<PRC> For the most part you are correct, but it also depends on the aggressiveness
required for control messages. For instance, if TCP's backoff algorithm could harm
the 802.11 service, then it may not be the right transport.

PatC