All the major enterprise WLAN vendors made their way to Interop Las Vegas 2007 last week, and I had the opportunity to meet with the majority of them. Top on my list: IEEE 802.11n and enterprise WLAN architecture providers. While previous briefings sketched out the key issues, these one-on-one meetings fleshed out some of the details (live demos didn't hurt, either).

Since I wrote my last column less than two weeks ago, Aruba Networks released a white paper on 802.11n, marking the first enterprise WLAN vendor document on the topic. Author Peter Thornycroft discusses the technical aspects of this unfinished standard and provides some perspective and recommendations regarding implementation. Although not completely without vendor bias, it's the first vendor treatise on this subject and I hope the other vendors follow suit. The 802.11n standard is much more complex than the previous three 802.11 connectivity standards, and organizations looking to experiment or engage in early deployments would do well to enter in with both eyes wide open.

Chipsets: It seems that all the enterprise WLAN vendors, save Cisco perhaps, will bring products to market based on an Atheros chipset design. The features appear to be the same: Support for 3x3 MIMO, two spatial streams and compatibility with the 802.11n Draft 2.0 specification. Note that there is support for only two spatial streams, even though there are three antennas. According to one vendor, this is because of the additional processing (and cost) requirements. When asked, Atheros did not directly address the resource concern. Also, transmit beamforming will not be in the initial release(s).

From our conversations with vendors at the show, it appears that Atheros' first chipset is truly a 1.0 release. As such, some vendors are holding back until Atheros' second-generation 802.11n chipset, currently planned for general availability in July/August. Atheros confirmed that there would be better price points, especially in the consumer market, but other items such as product performance, link stability and power usage likely will come into play, too.

Antenna Placement: Simple two-stick antenna deployments are quickly fading into history, at least in the high-end consumer market. The pre-standard 802.11n consumer targeted APs (access points) from Linksys and NetGear come with three antennas positioned at a variety of angles. No doubt the antennas are used as a marketing tool for consumers (more antennas means better and faster transmissions, right?).

Only Meru has introduced an AP with a large number of external antennas, six in fact. Each band uses three. Xirrus' 802.11n radio module has all the antennas built into the board, and the company was unwilling to show the design at its booth because of IP concerns. Trapeze's new AP is slightly larger than its previous models (though it retains the same smoke-detector design) and stuffs the necessary three antennas into its box. Colubris made it clear in its initial briefing that antenna placement was no small feat and that it took some careful RF modeling to guarantee an optimal design. The company has a unique flap that opens up to allow for omni-directional or patch configuration as well as a third antenna that opens up perpendicularly, which is effective for MIMO support on both bands.

Power over Ethernet (PoE): The IEEE 802.3af standard allows for approximately 15 watts of power. But the enterprise WLAN vendors have indicated that most pre-802.11n-capable APs will draw more than this, because 802.11n's use of multiple radio chains and advanced signal processing pushes up power requirements. Chipsets are normally optimized for power consumption in every subsequent release, but this concern is all the more important because most vendors plan to include a second radio, whether it supports only 802.11a/b/g or a pre-802.11n-capable one.

The IEEE 802.3at standard (sometimes called PoE Plus), capable of supplying 30 watts of power, will not be ratified until next year. This means Ethernet switches that incorporate the finished standard won't be available until late 2008 at the absolute earliest, and it will be 2009/2010 before there is significant quantity. Vendor Microsemi (formerly PowerDsine), a manufacturer of PoE devices, told me that switch vendors typically have product available two years after the standard is completed, and that mid-span devices (a PoE injector that sits between the Ethernet switch and the horizontal cabling) will be the enterprise's first option. Although Microsemi clearly has a bias toward mid-span devices, which offer a greater margin than an integrated component on a chipset, the gist of the facts remains true.

So, how do the enterprise WLAN vendors fare in this regard? Aruba hasn't publicly announced any pre-standard 802.11n gear, but the company's white paper confirms it is cognizant of the power consumption challenges.

Cisco also hasn't publicly announced any pre-standard 802.11n gear, even though its new AP is an element of the Wi-Fi Alliance's 802.11n Draft 2.0 certification test bed. Cisco documents one unreleased AP on its Web site--the 1250, which draws just a hair over 20 watts of power--suggesting this is likely the company's upcoming 802.11n product. A note states that, "When using both radios in the 1250 series AP, you must use a power injector or 802.3at PoE." It wasn't all that long ago that Cisco migrated away from its own proprietary PoE solution and toward the 802.3af standard in its switches, wireless APs and VoIP phones. Hundreds of thousands of Cisco APs are deployed with Cisco's own external injectors, so enterprises eager to move to 802.11n aren't likely to fuss too much if the same is required this time around. It could be as simple as visiting each wiring closet and swapping them out.

Colubris surprised us when the company shared that it is aiming to power its new dual-radio AP, the Multiservice AP 625 or MAP-625, with a single 802.3af PoE feed. Colubris claims to be working closely with chipset manufacturer Atheros to tweak power consumption requirements so that both 802.11n and 802.11abg radios operating at full transmit power and functionality (40 MHz wide channel, three radio chains, two spatial streams and so on) can be powered. Atheros shared that, "we work closely with our customers and design partners to review and suggest design, and identify and select components that lend an efficient POE architecture. Components such as power supply, optimizing and tuning front-end radio chains are done by us with our partners to achieve lower power." Don't hold your breath, though: Any vendor with two 802.11n radios is not going to operate them with full functionality within an 802.3af power budget anytime soon.

Meru has built a pre-standard 802.3at port into its own AP300 AP. Will this pre-standard PoE implementation be anymore upgradeable than the pre-standard 802.11n chipset? While this remains an unknown, pre-standard PoE injectors are already available from vendors including Microsemi, so enterprises eager to deploy gear will have a viable method to power them. What Meru demoed to me in a private suite at the show used an external power adapter. And for those who noticed that Meru's AP300 has a second Ethernet port, it's used for bonding Ethernet traffic using LACP not as a second powering point.

Trapeze also supports pre-standard 802.3at with its pre-standard 802.11n AP, the MP 432. Trapeze was the only vendor to introduce a pre-standard 802.11n product at Interop. Mirroring some of its other products, this new AP includes two Ethernet ports. If only one Ethernet port is powered with PoE, a sub-set of the AP's capabilities will operate. But Trapeze engineers were clever enough to simultaneously use the second Ethernet port for power, which enables the AP's full features. Although customers like options, unless the second cable is already run or it's a greenfield site, it's significantly more cost effective to install a pre-standard 802.3at injector with the existing cable run.

Xirrus introduced its own proprietary PoE injector, which provides about 60 watts of power. When asked why the IEEE 802.3at standards committee wasn't able to achieve a higher level of power, company representatives could only point to the fact that most vendors are easily satisfied with the 30 watts currently proposed and that the IETF's involvement was stirring things up. Xirrus claims that its unique power requirements haven't been a deal breaker and its unique architecture more than compensates for this nonstandard network element.

Gigabit Edge Ports: One vendor I spoke with made it sound like enterprises will have to upgrade their edge switch ports to gigabit Ethernet with 802.3at or mid-spans at the same time they move to 802.11n. My advice is, don't present that purchase order to your CIO for signing the same week he's calculating your holiday bonus.

Even better, don't worry about upgrading your edge ports. I challenge an organization to document a pre-standard 802.11n AP filling up a 100-Mbps Ethernet switched port over a 5-minute period. While link rates may climb to 600 Mbps, data throughput will likely peak out at 300 to 400 Mbps when using two radios in an AP. Yes, a 100-Mbps Ethernet port will cap bursty traffic, but those application requirements don't reflect a typical usage scenario. Mix in several clients operating at a variety of distances from the AP, and aggregate throughput will likely fall into the 100-Mbps range. Meru demonstrated in a private suite its new pre-standard 802.11n AP using eight laptop clients, each playing different unicast HD video streams running at 7 Mbps. Trapeze also demonstrated its pre-standard 802.11n AP using a single client downloading a file with FTP. Link rates hovered at 130 Mbps and throughput was shown to be in the 65-Mbps range. Although it was exciting to see greater than 50-Mbps throughputs on pre-IEEE standard products, they were still not at the top end for speed.

By the time 802.11n traffic flows consistently require 100 Mbps, you will be swapping out any remaining 10/100 switches with their gigabit equivalents. And don't forget that because Wi-Fi is a half-duplex medium, even 120 Mbps of usage that is split 90/30 between downstream and upstream will still operate effectively against a 100-Mbps full-duplex connection.

Several distributed switching WLAN vendors have suggested that their competitors' centralized architectures will force organizations with 802.11n to upgrade their distribution layer to 10 Gbps, but the reality is that if you don't need that kind of link capacity today for your wired users, who likely have 1-Gbps interfaces on their desktops, it's very unlikely that your wireless users are going to force that transition.

Migration Strategy: One element of consensus among all the vendors we spoke with is that mixing legacy 802.11a/b/g clients with 802.11n clients will effectively eliminate the significant performance benefits that the 802.11n standard brings. This is not unlike 802.11b and 802.11g coexistence, where a pure 802.11g environment will support an aggregate throughput over 20 Mbps but in a mixed environment top out in the low teens. The vendors almost unanimous solution? Dedicate a radio to 802.11n clients in the 5-GHz range. In a greenfield situation, an organization could use a dual-radio AP where the 2.4-GHz radio serves legacy 802.11b/g clients and the 5-GHz radio serves any new 802.11n clients.

In existing deployments it becomes a bit more complicated, though it can be boiled down to two scenarios. If the organization offers only 2.4-GHz service today (either 802.11b or 802.11b/g), then the existing APs can be swapped out for dual-radio APs supporting 802.11b/g in the 2.4-GHz range and 802.11n in the 5-GHz range. The extended level of viable coverage achievable in 802.11n via MIMO (and beamforming in future chipsets) will make up for the traditional shorter signal propagation of 5 GHz. The vendors we spoke with said it was too earlier to make any firm predictions, but we heard conservative numbers of 10 percent beyond 802.11a and I'm willing to bet that we'll see double or triple that number once chipsets have been revised and the vendors have had more experience. Interestingly enough, Atheros was not able to share any coverage data for the 5-GHz range.

The second scenario carries a bit more baggage and applies to those deployments experiencing medium to heavy usage of 802.11a. Syracuse University, a dual-radio, dual-band deployment, has about 30 percent of its clients using 802.11a radios. According to Xirrus, some of its education customers are evenly split between 802.11a and 802.11b/g. If an 802.11a-heavy organization swapped out its legacy dual-radio APs with new ones operating 2.4-GHz 802.11b/g and 5-GHz 802.11n, the 802.11a clients would default to 802.11b/g; this would result in a massive influx of usage, thereby reducing overall performance. No vendor has indicated that it will be offering a tri-radio AP (2.4 GHz for 802.11b/g, 5 GHz for 802.11a and 5 GHz for 802.11n) for these situations, so the most obvious solution would be a separate overlay of single-radio 802.11n APs operating in the 5-GHz range. Benefits include a single-radio 802.11n AP, which can be powered with existing 802.3af-based PoE and a lower unit cost. The legacy dual-radio APs can continue to operate indefinitely and can be phased out, given enough time.

Vendor differences in Wi-Fi architecture continue to become more nuanced. While the centralized model for enterprise Wi-Fi has been well received over the last few years, there's been a shift back to a more distributed architecture. As a result, it's now more important than ever to understand the placement of the management, control and data planes. It's my bet that the increased speeds of 802.11n combined with the growing pervasiveness of wireless will highlight the potential bottlenecks of a centralized architecture, if not in performance then in price.

The management plane controls the APs and any other WLAN elements. At a minimum, it includes applying a configuration on the AP and retrieving its status. Historically, this was one of problems of scaling the traditional fat AP deployment, and companies such as AirWave, Bluesocket, Vernier Networks and WaveLink stepped in to fill that void. But wireless switch vendors eventually subsumed them in market share.

The control plane oversees central security (the exchange of security keys between APs and controllers), roaming and RF control, among other things. Although the control plane is important, failure does not mean that clients are knocked off, but existing clients may lose the ability to roam and new clients may not be able to join.

The data plane is made up of end-user data targeted at other devices (such as servers) or locations (the Internet). It also involves QoS tagging, security enforcement (access control lists and firewalls) and packet forwarding. The data plane makes up the bulk of the traffic in a moderate to busy wireless network, but during idle times it may be dwarfed by a wireless network's 802.11n management traffic (not to be confused with the management plane).

In the past, I've given credit to Colubris Networks for being the pioneer in separating out data from the other planes, Siemens has also provided something very similar from day one. Unfortunately, Siemen's wireless product--when it was still the startup Chantry--did not gain significant traction, but the company appears to be doing well in the healthcare market.

Aruba gave Aerohive a bit of a fright last week when the company introduced its "Mobile AP." Aerohive, Interop's Best Startup Product winner, demonstrated in its presentations the benefits of a controller-less architecture, where both the management and the control planes reside. The advantage? No controller--or second controller for redundancy--is required at branch offices or retail stores, thereby reducing capital and implementation costs. But Aruba's Mobile AP software, in conjunction with its mesh software also announced last week, allows a branch office to leverage its centralized controller for management without a controller at the edge. The remote office still retains role-based user access control, a stateful firewall, NAT and split tunneling. Although Aruba won't readily admit it, a lot of its centralized controller's functions have been brought to the edge, and I believe it's a sign of things to come that the company will soften its "centralized-only" stance. A second data point is that its mesh product, also recently announced, will allow for two mesh-attached devices that use encryption to communicate directly with each other rather than traverse over the latency-inducing wireless backhaul to the controller and back again.

Cisco was all about fat APs in its first days with Aironet products and WLSE, but later developed WLSM (Wireless LAN Services Module) for the Catalyst 6500. Not being able to move quickly enough itself, Cisco purchased successful startup Airespace--with its centralized model--and introduced WiSM (Wireless Services Module) and rebranded the controllers. Since that time wireless support has found its way into Cisco's ISR (Integrated Services Router) and its Catalyst 3750G switch. With Cisco's leadership position in the switching market, it's reasonable to speculate that the company may also push some of the data plane into the edge via a software load in high-end edge switches. In addition, Cisco has its H-REAP (Hybrid Remote Edge AP), designed for branch and remote offices. It performs local switching of traffic and some control plane functions.

Meru was somewhat maligned for its slow support of 802.11a, but last month came early out of the gate with announcements on 802.11n and its new 3TDS (3 Tier Traffic Distribution System) architecture. Rather than centralize the three planes at the core, Meru has introduced "Distribution Points" that sit closer to the edge and place the data traffic onto the edge. It's not exactly clear why Meru wants to push the traffic to the edge. Unlike Trapeze, which appeared to need a differentiator and possibly had some centralized controller scaling concerns, Meru's single-channel architecture was unique enough. Some competing vendors speculated that perhaps the compressed timescales of 802.11n signaling would challenge the centralized model. But Meru was adamant that its coordinated and deterministic algorithms are not limited by LAN latencies--even if they were as high as the 20 to 40 msec I threw out. The only consideration left to consider is that the company also had controller scalability concerns. Its latest controller introduction, the MC5000, supports up to 200 APs and has a list price starting at $65 thousand. In our briefing, Meru stated that whether the customer chose a centralized or distributed model, the pricing is approximately the same. Aruba's 6000 has a lower price point--$67 thousand for 512 APs--and its pre-802.11n APs promise to be much cheaper than Meru's.

Trapeze previously offered a centralized WLAN switching model (a la Aruba). But anticipating the traffic rate increases of 802.11n and the demand that would place on its controllers as well as conceding to the benefits of distributed switching, the company introduced "Smart Mobile" a little over six months ago. This implementation of this marketing term essentially imitates what Colubris has done for a long time: placing the data plane on the AP and the management and control plane on the controller. In its marketing pitches I missed the fact that this is not a migration strategy but rather offers customers a choice. In fact, Trapeze's vice president of marketing, David Cohen, confirmed that most of the company's customers continue to centralize their data flows. Traffic can be locally switched by the AP on a per SSID or per VLAN basis. Clients, such as Vo-Fi phones, can be placed into a specific voice VLAN, in which case all traffic might be locally switched for reduced latency. But multi-function clients, such as a PC with a Web browser a VoIP softphone, would have to choose one mode over another and not on a per-application basis. Choice often leads to complexity, and in this case wireless network administrators will need to plan carefully which client traffic they want to manage centrally and which client traffic will switch at the edge.

At the end of the day, each enterprise WLAN vendor offers some level of flexibility in regards to centralized or distributed architecture. And much as we see in partisan politics, the reality is somewhere closer to the middle than at the extremes. The architectural choices that an enterprise makes depend more on its client base and preferred traffic patterns. Guest traffic will almost surely be centralized and dropped into the DMZ. Organizations with a decentralized IT implementation and many servers at the edge or branch offices will lean toward a distributed switching model, bypassing routing all the wireless traffic to the core and back again. But smaller single-site organizations that host a single router at the core are better off containing the VLAN "explosion" at the edge and sticking to a centralized model. In the same vein, IT staff who can't control their organization's edge switching infrastructure will prefer the overlay model.

Here's some free advice: Don't let your WLAN vendor dictate your architectural decision. Choose the architecture that works for your organization's traffic flows, security policies and network management routines, and then select a vendor that best matches them. If you find yourself attracted to a WLAN vendor that requires redesigning your wired network toward distributed, which many mean pushing VLANs out to the edge and redesigning your firewall/ACL policies, or toward centralized, which may increase distribution layer traffic and potentially add latency, you need to take a step back and carefully reconsider your original choices. There's no white knight for enterprise WLANs. If there were, the healthy competition that exists between Cisco and everyone else wouldn't exist.