That's why I believe vendor viability should be a key element in the decision-making process for enterprise WLAN infrastructure systems, unless a certain vendors technology or pricing is so compelling that it's worth the risk.
Frank -----Original Message----- From: phanset [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 10:46 PM To: [email protected] Subject: Re: [WIRELESS-LAN] Controller Architecture vs FAT APs Here is an example of my concerns: I decide to buy an CBA system. 3 years later the CBA system files chapter 11. Which APs will I buy for that new building that needs a Wi-Fi install? I could live with the absence of code releases, but not the absence of those APs that do prorietary tunnels to their controllers. In the switch world, if you use for instance 802.1q for trunking and IGMP for multicasting you should be able to buy from any switch vendor and support your infrastructure. In today's CBA world it's more like using ISL and CGMP! Philippe Hanset University of Tennessee >===== Original Message From "802.11 wireless issues listserv" <[email protected]> ===== >I agree that it will be just a matter of time before CAPWAP/LWAPP or what >ever they are going to call it will become a standard, how long? About as >long as it took for 802.11g to become one ;-) This same type of issue has >not just been in the WiFi technology but as well in the switch technology. >Can Cisco works or other switch vendor's management platform manage other >switch vendors equipment? Yes, but not all features of the vendors switch. >The list could go on. Fact is there are proprietary things in all vendors >management of equipment but as long as it does not affect the clients >ability to use standards to do their work there should be no problem. > > > >bd > > > >Brian J David > >Network Systems Engineer > >Boston College > > _____ > >From: Emerson Parker [mailto:[EMAIL PROTECTED] >Sent: Monday, June 26, 2006 5:15 PM >To: [email protected] >Subject: Re: [WIRELESS-LAN] Controller Architecture vs FAT APs > > > >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: [email protected] >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: [email protected] >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: [email protected] >Subject: [WIRELESS-LAN] Controller Architecture vs FAT APs > > > >I would be interested in other opinions on the following analysis of this >issue: > > > > > >1. 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. >2. CBA is considerably more expensive, in the 1.5 - 2.0 x range >compared to Fat APs >3. 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: > >a. Roaming, theoretically across an entire campus, without requiring a >single vlan >b. Significantly faster handoff between APs due to 802.1x keys on the >controller, important for voice support. >c. 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/. > >********** >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/.
