The more likely event is that your CBA system manufacturer gets acquired. If you are lucky, the new company continues to support and develop your preferred platform, which is what happened with the Cisco/Airespace deal. If you are unlucky, the product line is killed and your are "encouraged" to migrate.
There's really nothing particularly new about this when it comes to enterprise network infrastructure. I remember almost signing a purchase order for an Alantec backbone switch before Fore Systems acquired them and killed the product line. In retrospect, I'm glad I stuck with Cisco, which did what it needed to do to keep my business. In the case of the current top-tier CBA providers, I think the risks of bankruptcy are very low. It's a growing market and all of these companies have differentiators when compared to Cisco. Plus, there can be an advantage working with a smaller company, where you can influence product directions. I think we'll continue to see greater interoperability as this technology matures but you always have to be on the guard. That's why I've been openly critical of Cisco's CCX program, which provides features that are important to some customers but also has the effect of locking you in. I'm still very skeptical about CAPWAP as a protocol to provide interoperability between AP's and controllers. Check out the e-mail forums at the IETF site sometime for a better understanding of the issues and the large divide between the way Cisco sees this and the way others see it. And even if you could mix and match AP's and controllers, would you really want to? Vendors already price thin AP's very low so they can sell you more controllers and software. That's where they make their money. Ironically, Cisco -- the king of the smart AP via their Aironet acquisition -- has done an excellent job protecting customer investments by offering customers the ability to switch from an IOS-based smart AP to a LWAPP-based thin AP. Some will complain that they don't support older 350 models, but at least give them some credit. dm > -----Original Message----- > From: phanset [mailto:[EMAIL PROTECTED] > Sent: Monday, June 26, 2006 11: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/.
