RE: [WIRELESS-LAN] Controller Architecture vs FAT APs

[Emerson Parker]

please don't take this as a vendor point of view, it certainly is NOT...   "thin APs" are generally a software definition, not a hardware definition.   For instance, I can run openWRT on an aruba AP and have it do whatever I want.  You can get the aruba boot code from sourceforge and practically turn any ap into one that will tie to their central controller (using openWRT).   But the real issue here is what will be supported from vendors.  hopefully, when CAPWAP, LWAPP or whatever the heck it will be - should allow APs to go both ways.  APs that need to decrypt and then tunnel the data to the controller for further direction should be able to do this.  APs that tunnel everything back (for decrypt) should be able to do this as well.  But, as we have seen in the past with standards..........  who knows!    Central controllers provide an truly amazing set of features / capabilities, not to mention making large wifi networks _extremely_ easy to config/manage/monitor. any vendor ;)     -Emerson       From: Dave Molta [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 2:43 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Controller Architecture vs FAT APs I personally feel that traditional FAT AP's can be made to work effectively, even in large environments, but it requires a considerable amount of integration and more staff expertise than controller-based systems. In addition, since the industry as a whole is clearly moving towards the controller architecture, it's likely that most innovation and new functionality will appear on these new platforms. There are a lot of Fat AP's out there in the field, and even significant demand for new purchases, perhaps enough to prevent vendors from end-of-lifing these offerings for several years and also to sustain a third-party market for management tools.    I disagree with Brian's point about whether these systems are proprietary. Yes, they all adhere to 802.11 standards so you don't have to worry too much about whether they will be compatible with client devices but the fact is that the interface between the AP's and the controllers is proprietary to every vendor. Yes, there are some efforts to standardize this interation (e.g., CAPWAP) but I personally think that is a bit of a pipe dream. The interaction between AP's and controllers is very much dependent on the architecture. For example, Aruba does centralized crypto while Cisco handles it in the AP's. You can't make those systems interoperable just by standardizing the AP-to-controller protocol.    For what it's worth, the surveys we have done indicate that IT professionals want very much to see true interoperability, where you can purchase AP's from one vendor and controllers from another and make them work together. I'm not very optimistic this will happen.    dm From: Brian J David [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 1:44 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Controller Architecture vs FAT APs Tom, I would like to start of by saying that we also are a big Aruba networks shop. We replaced out FAT 802.11b AP’s with Aruba a/b/g AP 70’s and it could have been any easier if we tried. (2 people) Some here my lead you to believe that controllers are PC’s but each company they quoted has a dedicated appliance. I know that the Aruba 5000/6000 controllers have dedicated processors for each wireless process for example Firewall, encryption, etc. Aruba also just announced a code upgrade the will enable the controllers to handle and I quote here  “A single Aruba WLAN system is now capable of supporting up to 1000 simultaneous 802.1X authentication transactions per second” They also have plans to handle 802.11n as well. Don’t be lead down the path that thin AP’s are proprietary that is just not the case, they adhere to the same standards as the FAT’s. IMHO the deep frying of AP’s is going to be in the FAT AP’s, just ask me I have 500 802.11b AP’s ready to drop into the fry-O-lator. :-)        Brian J David Network Systems Engineer Boston College From: Zeller, Tom S [mailto:[EMAIL PROTECTED] Sent: Friday, June 23, 2006 9:43 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Controller Architecture vs FAT APs   I would be interested in other opinions on the following analysis of this issue:     Using AirWave’s AMP management platform has almost eliminated the management advantage of the controller-based architecture (CBA).  AMP monitors, reports, and updates Fat APs just fine.  Also, some CBAs don’t yet have a single management platform for multiple controllers. CBA is considerably more expensive, in the 1.5 – 2.0 x range compared to Fat APs The other advantages of CBA boil down to the following.  If others I’d like to hear.  And if these are fictitious, also of interest: Roaming, theoretically across an entire campus, without requiring a single vlan Significantly faster handoff between APs due to 802.1x keys on the controller, important for voice support. Automagic dense AP deployment from radio feedback to and adjustments from controller (or Meru’s approach).   Obviously I’m considering sticking with Fat APs for another few years and allowing the CBA products to mature, but  I ain’t got no religion here, and would welcome success/horror stories from large scale CBA deployments.   Tom Zeller Indiana University [EMAIL PROTECTED] 812-855-6214   ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/ ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.