RE: LWAPP/CAPWAP charter => my two cents

Folks,

seemed that I didn't use the proper e-mail list for this discussion. As I said, I'm catching up on this topic...   ;-)

So apologies for this mistake, and thanks to the nice folks who told me where to go: [email protected]

I will send my e-mail again to this list, then...

Tx
Jerome

>  -----Original Message-----
> From: 	Jerome Moisand  
> Sent:	Wednesday, September 17, 2003 12:16 PM
> To:	'[email protected]'
> Subject:	LWAPP/CAPWAP charter => my two cents
> 
> 
> Folks,
> 
> The lwapp/capwap discussion has been raised to my attention by several industry players. I am catching up on this topic, and didn't have an opportunity to attend the corresponding BOF at the last IETF meeting, so pardon me if some topics I mention were already discussed.
> 
> I do see the point of distributing processing between an 802.11 Access Point and some "controlling & aggregation device", based on multiple experiences with the deployment of HotSpots services by carriers. Which usually express a desire to lower the capex/opex for the gear located in the HotSpots, leveraging on more semi-centralized smarts in a "controlling & aggregation device". Which could be viewed as a NAS (Network Access Server).
> 
> So my first comment is: let's make sure the problem statement includes topologies for carrier-based services (HotSpots being only one incarnation of this) as well as topologies for private WLAN within an enterprise site or a campus. But this is probably obvious for you guys.
> 
> Next, I'd like to point out (hoping to not be disruptive, but maybe I will!) that this problem seems to be only one incarnation of a larger problem. The more general problem I'd see is the case of a lightweigh (usually layer2 "+", but not always) access device which requires some level of inband control by a "controlling & aggregation" (usually layer 3 "+") NAS device of some sort, which is itself likely somewhat driven by a policy/AAA server of some sort.
> 
> The aggregation is typically hub-like, a controlling device aggregating X lite access devices, with some hierarchical layer2 connectivity (or sometimes a layer3 tunnel). And then the capex and opex goals strike again, exactly like in the 802.11 space. And betting on external OSS systems to directly control the "lite" access devices is usually a non-starter (doesn't scale, doesn't allow fast sub-second policy decisions). 
> 
> Let me give a few examples (which are carrier-oriented, because it's my area of expertise, but I'm sure there is more):
> 
> a) in the DSL world, the DSL residential gateway (a CPE) is becoming more than a simple modem (look at the recent work in the DSL-Forum), but actually a service point. Yet one would like to keep it low capex/opex, which may spell out an inband control protocol from a BRAS/NAS system to push some form of policy/service rules, or pull some form of topology information.
> 
> b) again, in the DSL world, you can make a similar case between DSLAMs and BRAS systems. For similar reasons, including multicast scenarios and access topology discovery. 
> 
> c) in the same vein, the cable Docsis world ended up specifying an inband control protocol between Cable Modems (which are clearly more than modems!) an Cable Modem Termination Systems (CMTS). This was done at the MAC layer, which always made me cringe. I'm not saying IETF should revolutionize this specific cable space (too late!), but just making a point that the problem is bigger than a specific access technology area.
> 
> d) more generally, whatever the broadband access technology (DSL, Cable, Metro-Ethernet, PON, Fixed Wireless, etc), one will likely always find a couple of service-related parameters & mechanisms that would benefit from some inband control mechanism from a "controlling & aggregation device". And will always find benefits in some form of auto-discovery of the access topology. And in some cases, may find some necessary linkage with authentication/authorization dynamic processes and the various access devices being involved. > 
> 
> e) again, I'm no expert here, but I can venture a guess that in the enterprise/campus space, there are similar "wireline" scenarios in addition to the WLAN scenario. Heck, there isn't that much difference between a wireless LAN and a wireline LAN...
> 
> So let me suggest to possibly explore a wider scope for such an inband control protocol, taking some of the fundamental ideas behind lwapp/capwap, but extending it to a more generic mechanism. This mechanism would of course require a generic framework (and protocol or set of protocols), but then allow technology-specific extensions (a form of information model, I would venture to guess) to address peculiarities of DSL, 802,11, PON, etc.
> 
> This topic obviously deserves more detailed discussion to find a good balance, not go out-of-bounds, nor get too narrow... Not so easy!  ;-)
> 
> Thoughts? Feedback?
> 
> Tx
> Jerome Moisand
> Juniper Networks