How to approach wireless LAN architecturesDate: Feb 02, 2011
Poorly planned wireless LAN architectures can mean disaster for wireless networks. Networking professionals need to understand the two paths in wireless networking: controller-centric approach, and a decentralized -- also known as controller-less or smart AP -- approach.
In this video, senior site editor Rivka Little sits down with Lisa Phifer, president of Core Competence, to discuss WLAN architectures. Phifer discusses the two approaches at length, including the benefits of a controller-centric approach and a decentralized (controller-less or smart AP) approach.
Lisa Phifer is president and co-owner of Core Competence, a consulting firm focused on business use of emerging network and security technologies. At Core Competence, Lisa draws upon her 27 years of network design, implementation, and testing experience to provide a range of services, from vulnerability assessment and product evaluation to user education and white paper development.
Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact firstname.lastname@example.org.
How to approach wireless LAN architectures
Rivka Little: Hi, I'm Rivka Little, site editor of
SearchNetworking, and I am here
with Lisa Phifer, President of Core Competence. Hi Lisa.
Lisa Phifer: Hi Rivka.
Rivka Little: Lisa, there seem to be two paths to wireless LAN architecture. Could
you explain these two paths?
Lisa Phifer: Sure. So, actually I think in reality there are as many different paths
as there are products because vendors distribute functionality in
different ways. But from a 30,000-foot level, there are really two
basic architectures. One is the fully distributed autonomous access point
approach, and the other is the centralized controller-based approach. The
fully distributed approach is actually the way wireless LAN started. The
very first wireless LANs were composed of access points that were
completely autonomous and operated independently. But as wireless LANs grew,
as they entered the business place, as they grew in size and complexity,
that approach really became hard to manage. And that's where the controller-based approach came from. Aerospace, which was acquired by Cisco, pioneered
the controller-based approach of putting a number of functions into a
central point, which they call a wireless LAN controller; some people
call it a switch. Today though, we're starting to see a shift back in
the other direction due to geographically large wireless LANS,
higher bandwidth, and applications that require lower latency.
Rivka Little: What are the benefits to the controller-centric approach, and then
the benefits to the decentralized approach?
Lisa Phifer: So the reason that controllers really came about is because of the
management problem. As you had a larger number of access points, say more
than a dozen, it became hard to, you know, independently manage all those
devices. So for enterprise wireless LANs to succeed, functionality had to
be centralized in some way. The main benefit of the controller-based
approach, was to centralize management functions. That gave you a single
place to put your firmware so you could push it to all of your access points. It gave you a very quick way to provision new access points. It gave you one
place to go to whenever you wanted to make a configuration change, one
dashboard to look at when you wanted to look at real time status, and
usually one database that you could pull all your alerts to or your logs to
to get information about your network. The other thing that controllers did,
though is that they centralized control path functionality. And what that means, for example, is that they made decisions about channel allocation and
adjusting transmit power so that access points wouldn't step on each
other. Controllers also would do things like get involved in
authentication. They would cache keys so users could roam very fast
between access points. Let's see, what else do controllers do? Controllers
also get involved in radio resource management. The advantages of
performing all those functions actually helped wireless LANs scale quite a
bit. The problem is that no matter how big your controller is, eventually
it will run out of steam. And as wireless LANs got bigger and bigger,
bandwidth got higher. Latency requirements also became more stringent
with applications like voice. Controllers kind of hit their Waterloo; they
hit a wall, if you will, where they really just couldn't scale anymore. And
that's why we're seeing the shift back to more distributed architectures
that have more autonomous access points. Some vendors like to call them
smarter access points as opposed to thin access points.
Rivka Little: And what are the benefits beyond that of these, of this
decentralized approach, or these intelligent access points?
Lisa Phifer: So moving that functionality back out, if you will, manager
functionality still stays centralized, so you get the benefit of
reduced cost of operations and the benefit of central point monitoring.
But control functionality and also data path functionality gets pushed all
the way back out to the access point again. The access points become more
powerful, they have the intelligence, and they have the autonomy to
basically work without supervision. Those are some of the things that distributed
architectures can do, and it's hard to generalize because products are
changing now. Different vendors are moving that functionality out. And it's
a question of how much they move back out to the access point. Some of
the things you can do in a decentralized architecture, for example,
the access points can organize themselves. They can use what they hear in
the air to determine what other access points are close to them and use
that for mesh routing decisions, for example. Access points can use what
they hear in the air to change their channel when they need to. To adjust
their transmit power to interfere less with nearby devices. The autonomous
distributed architecture can also do things like make decisions that have
to be made very, very quickly. For example, based on how clients are
actually using the air at any given time, it makes adjustments to how much time
they get on the air in order to meet SLAs. Now the SLAs might still be
defined centrally; they still might be provisioned and managed centrally.
It's that the access points are better placed to enforce those decisions.
Rivka Little: Are there more difficulties with troubleshooting when it comes to
having a decentralized architecture with smart access points?
Lisa Phifer: Difficulty in troubleshooting a distributed network really comes
into play if you don't have visibility into what's going on. As long as the
autonomous access point still forwards information back to a management
system, that gives you that visibility. You still have the capability to
understand what's going on and troubleshoot depending on what tools are
provided to you. Access points do, though, have to have the ability to be
tuned and to communicate somewhat with each other. For example, with self-
organizing wireless mesh networks, those access points have to
coordinate with each other very carefully to make sure everybody doesn't
make different decisions or jump onto the same channel.
Rivka Little: OK. Thank you so much for joining us.
Lisa Phifer: You're welcome.