To overcome the triple concern of lack of mobility services, per-access-point RADIUS connections, and individual management with standalone access points, the wirelesscontroller was introduced around 2002. The management, security, and wireline-bridging functions of 802.11 are removed from the access point and relocated to this separate appliance, called the controller. This controller looks and functions, to some extent, like a router, collecting traffic destined to or coming from the wireless network and exchanging it across one or two wired ports. Controller-based access points are left with only two nonvolatile configuration pieces: the IP address or name of the controller, and the IP address or DHCP settings it is to use when it boots up. Controller-based access points cannot operate on their own. When they power up, they seek out the controller and establish a connection, where they download their configuration into memory. In order to manage or monitor the access point, the administrator must go to the web interface or CLI of the controller.
Controllers are usually high-end data processing platforms, although every vendor offers low-end models for small office deployments. These devices have more in common with routers than with computer appliances, as they are built to tunnel data quickly.
The management advantage of controller-based architectures is that the statistics and properties of the network can be seen and altered in aggregate. Furthermore, software versioning is taken care of automatically, as the controller upgrades access points to the same version that it is running. The appearance to the administrator is that the access point is somehow "thin," or lightweight. The reality, of course, is that the controller-based access point is built of the same hardware as a standalone access point, which explains why some vendors offer the option to run either standalone or controller-based software on a given model.
Security is also performed centrally. RADIUS transactions are required by the wireless security protocols, and RADIUS needs to have the IP address and password of each device that is allowed to use it for authentication services. With controller-based architectures, there is only one IP to know—that of the controller. Also, because the controller performs the RADIUS authentications, it can cache them as needed, aiding in handoffs. There is variation within the architecture for where encryption is performed. One vendor performs the 802.11 encryption operations on the controller itself; others retain that functionality in the access points.
But most notably for voice mobility, the controller-based architectures implement a kind of transparent "Mobile IP." Data is tunneled from the access point to the controller and vice versa. This allows access points to provide services for networks that they themselves are not placed in. The advantages are readily apparent. A campus with dozens of buildings, each building with its own subnet, can install controller-based access points and yet provide a completely different set of subnets to the wireless devices. A campus-wide, flat voice subnet can be established and dedicated to voice mobility devices, without having to push the subnet throughout the campus, eliminating the need for concern about VLANs, inter-subnet handoffs, and call drops. Moreover, the tunneling used does not involve Mobile IP itself, but rather is an integrated part of the system. There are no additional steps that administrators must take to take advantage of the overlay network that the tunneling provides.
Controller-based architectures can still allow for some traffic to be bridged locally, rather than tunneled. However, this is not recommended for campus deployments—especially not for voice—because it brings up the same mobility concerns as with standalone access point deployments.
The controller-based wireline architecture currently has the most diversity with the over-the-air architectures.
No comments:
Post a Comment