Ramblings on Infrastructure Design

Ramblings on Infrastructure Design

By CWNP On 08/14/2007 - 3 Comments

You hear all the time about how 802.11n is going to change everything - especially the design infrastructure.  I thought I'd ramble about that a bit.

 

Certainly there's the PoE issue.  802.11n uses multiple radio chains - 2x2, 2x3, or 3x3 typically.  That's "Tx x Rx" for you that are unfamiliar at this point.  More radio chains means more power draw.  802.3, clause 33 (aka 802.3af) gives us a whopping 12.95W max power draw.  That isn't going to cut it for most 802.11n APs.  802.3at will likely be here in 6-9 months, but until then, what's a poor administrator to do?  Well, you could string dual PoE feeds to each AP.  You'd think that would give you a redundant data path, but it doesn't because if one line fails, the AP shuts off.  Additionally, some vendors are working on putting two dual-band 802.11n radios for connectivity and another 802.11n radio for WIPS functionality into a single enclosure.  Now THAT's going to take some power.  If your high-quality AP is 3x3 MIMO, then having 3 such radio chains would mean 9 transmitters and 9 receivers in a single enclosure.  

Then there's the architecture changes.  Everyone keeps harping on the fact that 802.11n's high throughput capabilities are going to overwhelm the WLAN controller.  Well, that's certainly possible if you have thirty 802.11n users slamming every 802.11n AP, but how often does that happen?  Everyone realizes that if you introduce a system with more bandwidth, then users will keep increasing their use of it over time.  Considering the fact that practically nobody has saturated a properly designed 802.11a or 802.11g network, I highly doubt that today's controllers are going to be overwhelmed by 802.11n APs anytime soon in a decent deployment.  If 802.11n weren't available, 802.11a/g networks would undoubtedly keep up with throughput demands for at least 3 more years in 99% of all deployments.  I've even read documents where people suggest you don't roll out 802.11n until the Ethernet infrastructure has been upgraded to gigabit everywhere.  Nonsense.  A 10/100 Ethernet infrastructure is AOK to support 802.11n for the time being, and likely will be for quite a while.  That issue pales in comparison to RF-planning and protection mechanism issues anyway.  I do wonder, however, how many desktops may be migrated over from 10/100 to 802.11n (via USB2 wireless adapters) across the enterprise once an 802.11n infrastructure is in place.  If desktop migration to wireless got to be the norm, I think my perspective might change a little.  Consider also that many WLANs are comprised primary of handheld client devices (scanners, phones, etc) that won't even be able to use the 802.11n PHY for a long time.  It's important that those vendors move to 802.11n radios if for no other reason than to avoid use of protection mechanisms.

Many vendors are eyeing the distributed data forwarding (DDF) (previously called hybrid) architecture where the data plane is moved back to the AP so that the AP can send data frames directly to their destination.  In implementing the DDF architecture, traditional problems such as VLAN tagging at the edge (often called VLAN explosion) and L3 roaming may have to be readdressed (depending on implementation).  These were some of the reasons for moving to the centralized architecture to start with.  

One approach to handling L3 roaming in a DDF architecture is to tunnel the data plane back to the WLAN controller only for L3 roamers, but send the data directly to its destination the rest of the time.  VLAN explosion could be addressed in the same manner.  APs on the same VLAN could handle the data plane so long as the client station is assigned to the same VLAN through its WLAN profile, but tunnel the data back to the controller when the client station is using a WLAN profile (and hence VLAN) not handled by the AP.  

Another possible solution is to add application-layer intelligence (and configuration options) to both the controller and AP whereby time/latency-sensitive frames are switched directly to their destination (DDF), and security-sensitive applications are tunneled back to the controller (centralized).  For instance, the administrator may choose to tunnel all guest traffic to a centralized or segregated controller, but use DDF for all the employee traffic.  Or he may use DDF for all the voice traffic, but send all other traffic to the centralized controller.  Some vendors are are now giving us the flexibility to choose any model or to have all models simultaneously.  This is excellent considering today's enterprise mix of high-security and time/latency-sensitive applications.

In the DDF architecture, distributed encryption/decryption is necessary.  While centralized encryption/decryption is excellent from a security perspective, it will cause scalability issues somewhere down the line.  In mesh environments (where mesh points have been added to a traditional switched WLAN infrastructure) over-the-air bandwidth is scarce, so reducing the need to backhaul traffic to the wired network helps to conserve and optimize usage of bandwidth.

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.