The AP and controller are linked by the CAPWAP protocol using both a "control" channel for access point management, configuration, and control, and a "data" channel for forwarding of user traffic between the two entities in the cases where user traffic is tunneled all the way to the controller (central bridging). These two channels are nothing more than CAPWAP encapsulated UDP packets using port 5246 (control) and 5247 (data) since Cisco code version 5.2. Earlier versions of code used the LWAPP protocol, which was CAPWAP's predecessor, and use UDP ports 12223 (control) and 12222 (data).
It is important for wireless engineers designing, deploying, administering, and troubleshooting solutions using this type of architecture to understand the functions carried out by the controller versus the access point.
The industry is currently in a transition back to a de-centralized model, with local data bridging coming into higher demand as 802.11n data rates strain controller bandwidth capacity and branch offices struggle to cost-justify the additional expense of controllers. This is evident with the emergence of Cisco H-REAP, Aruba RAP, Motorola Adaptive APs, and taken to the extreme by Aerohive in their controller-less architecture. This trend will only continue, but engineers will still be required to fully understand the split-MAC concept even under these circumstances as the large vendors are likely to require centralized controllers for some control-plane functions.
The split-MAC functionality is divided between controller and AP in the following fashion:
Controller Responsibilities:
- Security management (policy enforcement, rogue detection, etc.)
- Configuration and firmware management
- Northbound management interfaces
- Non real-time 802.11 MAC functions
- Association, Dis-Association, Re-Association
- 802.11e/WMM Resource Reservation (CAC, TSPEC, etc.)
- 802.1x/EAP Authentication
- Encryption Key Management
- 802.11 Distribution Services
- Wired and Wireless Integration Services
Access Point Responsibilities:
- Real-Time 802.11 MAC Functions
- Beacon generation
- Probe responses
- Informs WLC of client probe requests
- Power management and packet buffering
- 802.11e/WMM scheduling and queuing
- MAC layer data encryption and decryption
- 802.11 control messages (ACK, RTS/CTS)
- Data encapsulation and de-capsulation via CAPWAP
- Fragmentation and re-assembly
- RF spectral analysis
- WLAN IDS signature analysis
In future posts, I detail how CAPWAP APs discover, select, join, and maintain association with a controller.
Cheers,
Andrew
Hi Andrew,
ReplyDeleteTimely post. Well-articulated and spot-on accurate. Kudos.
Your functionality list isn't comprehensive, and unless you had an extra 12 hours to work on it, it likely wouldn't be, so I've taken that into account. :)
It's important to note some other big functionality though, such as:
L3 roaming/anchoring
Radio Resource Management
Authentication Infrastructure Integration
These types of functionality require pretty significant resources, either requiring controller hardware or beefy AP hardware. CPU/RAM (horsepower) is the reason that most controller vendors will have to step into a distributed architecture one step at a time. http://blog.aerohive.com/blog/?p=696
It's also important to note that each vendor places various parts of the MAC (especially the control plane) in different places. It's usually a given that vendors now place QoS within the AP, which would include airtime fairness controls as well. Otherwise, they don't work very well because they're too far from the air interface. Some vendors struggle with what belongs where in the Split-MAC model...and have for years...which is why there's such a diversity of who does what, and where. Given that we don't use controllers, Aerohive puts everything into the AP, so luckily we don't have to worry about the "where" part. :)
Keep these great posts coming! Speaking on behalf of a bunch of Wi-Fi nerds, we all enjoy them.
Devin Akin
Chief Wi-Fi Architect
Aerohive Networks
Thanks Andrew, perfect explanation.
ReplyDeleteMatt Reath, CCIE #27316 (SP)
Director of Sales Engineering
CCI Systems
Anyone focus on Split-MAC Architecture for software defined wlan？
ReplyDelete