RFC 5414
Wireless LAN Control Protocol (WiCoP)
RFC 5414: Wireless LAN Control Protocol (WiCoP) 🦋
okay bestie, this is RFC 5414 (part 1 of 11), and it's the whole WiCoP spec 💖
- Stream: Independent Submission
- Category: Historic (published for the historical record, not as a standard 📜)
- Authors: S. Iino, S. Govindan, M. Sugiura, and H. Cheng, all from Panasonic 🧚
- Date: February 2010
- ISSN: 2070-1721
- Obsoleted by: RFC 5415 💅
Abstract ✨
ngl, WLANs (wireless local area networks) are EVERYWHERE now 📶. Every building, campus, and shopping centre wants Wi-Fi, so the networks keep getting bigger and bigger. Huge deployments with tons of wireless termination points (WTPs) covering massive areas are super common now 🌸.
So the Wireless LAN Control Protocol (WiCoP) in this document is built to control and provision these giant WLANs 👑. It lets you manage all of them from one central spot, and it's designed to hit the goals set for the Control And Provisioning of Wireless Access Points (CAPWAP) 🎀.
Status of This Memo 🌈
Okay, the vibe here is "this is for the history books" 📚. It's NOT an Internet Standards Track spec, it's just published as a Historic Document for the Internet community 🕰️.
It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor picked to publish it at their own discretion and makes no promises about whether you should implement or deploy it 🙈. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard. See Section 2 of RFC 5741 for the details 💜.
Want the current status, any errata, or a way to send feedback? Check http://www.rfc-editor.org/info/rfc5414 🔗.
IESG Note 🫶
Real talk, this bit is important 😭. This RFC records the WiCoP protocol as it was when it got submitted to the IETF, as a starting point for more work in the CAPWAP Working Group. That's why it may look a lot like the CAPWAP protocol spec in RFC 5415, and like other IETF work too ✨.
It's being published ONLY for the historical record, and the protocol hasn't been thoroughly reviewed, so it may have errors and omissions 🙈. Please don't treat it as gospel!
RFC 5415 is the standards track solution from the CAPWAP Working Group, and it obsoletes any and all mechanisms defined in this RFC 👑. This RFC isn't a candidate for any level of Internet Standard, and you should not use it as a basis for any sort of Internet deployment 💀.
Copyright Notice 🎀
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 💖.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:trustee.ietf.org/license-info) as they were on the publication date. Go read those carefully, because they spell out your rights and restrictions for this document 📜.
Table of Contents 🍓
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Protocol Overview ...............................................6
4. WiCoP Format ....................................................7
4.1. WiCoP Header ...............................................8
4.2. WiCoP Control Packet ......................................11
4.2.1. WiCoP Control Messages .............................12
4.2.2. WiCoP Control Message Elements .....................12
4.2.3. WiCoP Control Message Description ..................27
4.3. WiCoP Data Packet .........................................36
4.4. WiCoP Timers ..............................................37
4.4.1. Active Presence Timer ..............................37
4.4.2. Feedback Interval ..................................37
4.4.3. Response Timer .....................................37
4.4.4. Wireless Connectivity Timer ........................38
5. WiCoP Processes ................................................38
5.1. Initialization ............................................38
5.2. Capabilities Exchange .....................................38
5.3. Connection ................................................39
5.4. Configuration .............................................40
5.4.1. Logical Groups .....................................41
5.4.2. Resource Control ...................................41
5.5. Operation .................................................41
5.5.1. Updates ............................................42
5.5.2. Feedback and Statistics ............................42
5.5.3. Non-Periodic Events ................................43
5.5.4. Firmware Trigger ...................................43
5.5.5. Wireless Terminal Management .......................43
5.5.6. Key Configuration ..................................46
6. WiCoP Performance ..............................................51
6.1. Operational Efficiency ....................................51
6.2. Semantic Efficiency .......................................51
7. Summary and Conclusion .........................................51
8. Security Considerations ........................................52
9. Informative References .........................................531. Introduction 🌸
WLANs have blown up in popularity, and that's led to a LOT of designs and solutions that don't play nicely together 😩. The CAPWAP Architecture Taxonomy [RFC4118] breaks down the major variations of these designs. Two of the biggest categories are the Local MAC (Media Access Control) and Split MAC architecture designs 🦋.
WiCoP is all about recognizing those major architecture designs and giving them a common platform where WLAN entities from different designs can hang out together 🫶. That means WTPs and WLAN access controllers (ACs) from different architectures can actually interoperate ✨. It also makes cheap WLAN expansions possible, and it can handle future WLAN tech too 🚀.
Here's another big thing: shared infrastructure WLANs are trending, and they need management to tell apart and isolate control for the different logical groups that share one physical WLAN 👑. WiCoP handles this by running WLANs through a bunch of tunnels that separate traffic by logical group 🎀.
So in Figure 1, each WTP uses a few tunnels to keep control traffic and each logical group's traffic separated 💅. The protocol lets you manage WLANs in a way that matches the logical groups sharing the physical gear 🧚.
Local MAC WTP
+-------+ +-------+
| | | | Logical Groups
| (=====Control Tunnel======) |
| | | | ~~~~~~~
| | | | / /
| <=====Logical Group A=====> | / A /~~~~
| | | | / / /
| <=====Logical Group B=====> | ~~~~~~~ /~~~~
| | | | / B / /
| <=====Logical Group C=====> | ~~~~~~~ /
| | | | / C /
| | +-------+ ~~~~~~~
| |
| |
| AC |
| |
| | Split MAC WTP
| |
| | +-------+ Logical Groups
| | | |
| [=====Control Tunnel======] | ~~~~~~~
| | | | / /
| | | | / 1 /~~~~
| <=====Logical Group 1=====> | / / /
| | | | ~~~~~~~ /
| <=====Logical Group 2=====> | / 2 /
| | | | ~~~~~~~
+-------+ +-------+
Figure 1Now look at Figure 1 🔍. WiCoP sets up and runs control tunnels and logical group tunnels between the AC and two kinds of WTPs 🌈. The control tunnels carry WiCoP messages about configuring, monitoring, and managing each WTP as one whole physical box 🧚. The logical group tunnels keep the traffic for each logical group on a physical WTP separate 🎀.
2. Terminology 💜
This document follows the terminology in [RFC4118] and [RFC4564] 📖.
3. Protocol Overview ✨
okay so WiCoP (the Wireless LAN Control Protocol) is all about making different WLAN gear actually talk to each other in shared infrastructure networks 🫶 It's built to work with lots of different wireless technologies, not just one. This doc covers the general stuff WiCoP does AND the specific use cases for IEEE 802.11-based systems 📶
The state machine for WiCoP is shown in Figure 2 🦋
+--------------------------------+
| |
| +------------------+ |
V V | |
+-------------+ +-------------+ +-------------+ |
| | | | | | |
| Initial- |-------->| Capabilities|-------->| Connection | |
| ization | | Exchange | | | |
| | | | | | |
+-------------+ +-------------+ +-------------+ |
A A | |
| | | |
| | | |
| | | |
| | V |
| | +-------------+ |
| | | | |
| +----------------| Configur- | |
| | ation | |
| | | |
| +-------------+ |
| | |
| | |
| | |
| | |
| V |
| +--------------+ |
| | | |
+----------------------------------------| |-+
| Operation |
| |
+--------------+
Figure 2The Initialization state is where WTPs and AC start out 🌱 A WTP or AC in this state powers on, clears internal registers, runs hardware self-tests, and resets network interfaces. Fresh start, bestie! 🧼
The Capabilities Exchange state is the first real handshake between a WTP and AC 🤝 A WTP here figures out which ACs it can get management services from. An AC here checks out the WTP's capabilities and whether that WTP is compatible with the management services it offers. Main character energy for both of them 💅
The Connection state is where the security infrastructure gets built between a WTP and AC 🔐 This means mutual authentication and setting up a secure connection between the WiCoP entities. Very serious, very important, iconic 👑
The Configuration state is where long-term operational parameters and settings get swapped between a WTP and AC 🎀 A WTP here receives configuration info so it can operate consistently within the WLAN the AC manages. The AC hands over that info based on the WTP's capabilities and network policies.
The Operation state is the active part, where WiCoP monitoring and management messages are flowing 🚀 WTPs send regular status updates to the AC and get management instructions back. This state also covers firmware and configuration updates that happen when network conditions or administrative policies change. Always updating, never bored 🔥
4. WiCoP Format 🎀
okay now the fun part, the packet formats 🧚 WiCoP uses separate packets for control messages and data messages going between the AC and WTPs. Both types share a common header, and a single-bit flag tells you which kind of packet you're looking at. This section walks through the packet formats 💖
4.1. WiCoP Header 💜
Figure 3 shows the WiCoP common header for control and data packets. Here's the layout 👀
0 31
| 7 15 23 |
|-------|-------|-------|-------|-------|-------|-------|-------|
| |
+---------------+-+-+-+-+-+-+-+-+-------------------------------+
| Version |M|D|C|R|E|F|L| | Reserve |
+---------------+-+-+-+-+-+-+-+-+-------------------------------+
| Fragment ID | Fragment No. | Length |
+---------------+---------------+-------------------------------+
Figure 3Version Field
This field tells you the protocol version. Simple, but important 🔢
'M' Field
The MAC-type field, 'M', tells apart Local MAC WTPs and Split MAC WTPs 🧩 It's what makes it possible to get interoperability between WTPs of these two different designs. A '0' means WiCoP is exchanging with a Split MAC WTP, and a '1' means it's exchanging with a Local MAC WTP.
Having this bit right in the common header speeds things up at the AC ⚡ The AC parses the common header once and then knows exactly how to process that WiCoP packet. Efficient, no cap.
'D' Field
The differentiator field, 'D', is used to tell apart WTP variants inside one type of WTP design 🦋 The CAPWAP Architecture Taxonomy [RFC4118] shows that the Split MAC design lets encryption/decryption happen at either the WTP or the AC. The same Taxonomy also says the Local MAC design lets authentication happen at either the WTP or the AC.
WiCoP accounts for these major variants by using the 'D' field together with the 'M' field 💅 For a Split MAC WTP, 'D' indicates where encryption/decryption happens. For a Local MAC WTP, 'D' indicates where authentication happens. Here's the table:
'M' 'D' Description
0 0 Split MAC WTP - Encryption/decryption
is performed at WTP
0 1 Split MAC WTP - Encryption/decryption
is performed at AC
1 0 Local MAC WTP - Authentication is
performed by WTP
1 1 Local MAC WTP - Authentication is
performed by ACJust like with 'M', having this info in the common header helps the AC speed up processing with a single parse 🏃♀️ Since these bits show up in every packet of a session, the AC can speed things up across the board. Otherwise it would have to check every arriving packet against an internal register, and that means processing gets delayed. Nobody wants that, periodt 🙄
'C' Field
This field tells a WiCoP control packet apart from a WiCoP data packet 📦 Each kind of info gets tunneled separately across the WiCoP tunnel interfaces between WTPs and the AC. A '0' means a data packet, and a '1' means a control packet.
The 'C' field also assigns WiCoP packets to separate data and control tunnels between the AC and WTP 🛤️ And WiCoP uses the 'C' field to keep logical groups in WLANs. Organized, bestie 🗂️
'R' Field
The retransmission field, 'R', tells the first transmission of a WiCoP packet apart from the ones after it 🔁 It's used for critical WiCoP packets, like the ones dealing with security key exchanges. A '0' means it's the first transmission, and a '1' means it's a retransmission.
'E' Field
The encryption field, 'E', says whether a WiCoP packet is encrypted between the AC and WTPs 🔒 It's used for packets exchanged during initialization. A '0' means unencrypted, and a '1' means encrypted.
'F' Field
The fragmentation field says whether a packet is a fragment of a bigger packet 🧩 A '0' means it's not fragmented, and a '1' means it is. The 'F', 'L', 'Fragment ID', and 'Fragment No.' fields all work together here 🫶
'L' Field
This field marks the last fragment of a bigger packet 🏁 It only means something when the 'F' field is '1'. A '0' in 'L' means it's the last fragment, and a '1' means it's an intermediate fragment. Again, 'F', 'L', 'Fragment ID', and 'Fragment No.' all work as a team 👯
Fragment ID Field
The Fragment ID identifies which bigger packet got fragmented 🆔 It's how you tell fragments of different large packets apart. This field is only valid when 'F' is '1', and it works together with 'F', 'L', and 'Fragment No.'
Fragment No. Field
The fragment number tells you the order of fragments in a bigger packet 🔢 Its value goes up by one for each fragment, so you can see the sequence. This field is only valid when 'F' is '1', and once again it's a team effort with 'F', 'L', and 'Fragment ID' 💖
Length Field
This field tells you the length of the WiCoP payload that comes after the header 📏
4.2. WiCoP Control Packet 🌸
The WiCoP control header comes right after the WiCoP common header 🍓 Here it is in Figure 5:
0 31
| 7 15 23 |
|-------|-------|-------|-------|-------|-------|-------|-------|
| |
+---------------+---------------+-------------------------------+
| Msg Type | Reserve | Seq Num |
+---------------+---------------+-------------------------------+
| Msg Element Length |
+-------------------------------+
Figure 5The control packet adds four more fields on top of the common header. Here's what each one does 🫶
Msg Type Field
This field says what type of control message the packet carries 💌 The list of control messages is in Section 5.2.1, so go check it out 👀
Seq Num Field
The sequence number field is how WiCoP matches up request and response sequences 🔗 The initiator of a WiCoP request message bumps up the Seq Num field for every new request. The responder then copies those Seq Num values into its matching response messages. It's like a tiny ticket system, and it's giving order ✨
Msg Element Length Field
This field gives the length, in bytes, of the WiCoP control message element that follows 📐
4.2.1. WiCoP Control Messages ✨
okay bestie, here's the full lineup of WiCoP control messages 💅 every one gets its own Msg Type number so you always know which one you're looking at 🎀
Message Msg Type
------------------------------------------------------------
Capabilities 1
Capabilities Response 2
Connection 3
Connection Response 4
Configuration Request 5
Configuration Response 6
Configuration Data 7
Configuration Data Response 8
Configuration Trigger 9
Configuration Trigger Response 10
Feedback 11
Feedback Response 12
Reset 13
Reset Response 14
Firmware Download 15
Firmware Download Response 16
Terminal Addition 17
Terminal Addition Response 18
Terminal Deletion 19
Terminal Deletion Response 20
Key Configuration 21
Key Configuration Response 22
Notification 23
Notification Response 244.2.2. WiCoP Control Message Elements 🦋
every WiCoP control message comes with a control message header up front, and then it's followed by one or more message elements 💖 here's the table of elements, bestie:
+-----------------+-----------+-------------------------------------+
| Message Element | Type | Description |
+-----------------+-----------+-------------------------------------+
| WTP-Info | 1 | Information regarding WTPs, such as |
| | | manufacturer ID, MAC address, etc. |
| | | |
| Cap-from-WTP | 2 | Quality-of-Service (QoS) abilities |
| | | (WME-Wireless Multimedia Extension) |
| | | and security abilities |
| | | (IEEE 802.11i) are included |
| | | |
| Conf-If-Data | 3 | Physical Layer (PHY) information for|
| | | each wireless interface |
| | | |
| Conf-WTP-Data | 4 | Information regarding logical |
| | | groups on a per-logical group basis |
| | | (e.g., per-virtual AP) |
| | | |
| Cap-to-WTP | 5 | Setup data sent to WTPs by an AC on |
| | | a per-logical group basis |
| | | |
| QoS-Value | 6 | QoS setup (access categories) |
| | | |
|Timer-Init-Value | 7 | Initial values of timers such as |
| | | aging, echo interval, etc. |
| | | |
| Terminal-Data | 8 | Information relevant to wireless |
| | | terminals - Basic Service Set |
| | | Identifier (BSSID), association ID, |
| | | etc. |
| | | |
| BSSID | 9 | BSSID, and terminal MAC address |
| | | |
| Encryption-Data | 10 | Details of the security framework - |
| | | cipher suit, operation mode, etc. |
| | | |
| EAP-Frame | 11 | Extensible Authentication Protocol |
| | | (EAP) frame |
| | | |
| Statistics | 12 | Various statistics information - |
| | | transmission attempts, Frame Check |
| | | Sequence (FCS) errors, etc. |
| | | |
| Interface-Error | 13 | Type of wireless interface failure |
| | | |
| FROM-Error | 14 | Flash ROM Error information |
| | | |
| QoS-Capability | 15 | Network congestion information |
| | | |
| TFTP-Data | 16 | Firmware-related details |
| | | |
| Result | 17 | Result of protocol operations - |
| | | success or failure |
| | | |
| OID | 18 | Simple Network Management Protocol |
| | | (SNMP) Object Identifiers (OIDs) |
| | | |
| GTK-Flag | 19 | Determines type of Group Temporal |
| | | Key (GTK) - new or existing |
+-----------------+-----------+-------------------------------------+each message element is made up of a bunch of information items, and we'll break those down below 🌸 the length of each information item is given in bytes, so you can count them like a pro 🧮
WTP-Info:
WTP-Info is provided per-WTP, so each WTP exchanges one WTP-Info message element. ✨
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| Manufacturer | 8 | DisplayString | Manufacturer ID |
| ID | | | |
| | | | |
| MAC Address | 6 | PhyAddress | WTP MAC Address |
| | | | |
| Firmware | 8 | DisplayString | Firmware version of |
| Version | | | WTP |
| | | | |
| Start Time | 4 | TimeTicks | Starting time of WTP |
| | | | (UNIX Time) |
+--------------+----------+----------------+------------------------+Cap-from-WTP:
Cap-from-WTP is also per-WTP, so each WTP exchanges one Cap-from-WTP message element. 🎀
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| 802.11e Cap | 2 | Integer | Length of 802.11e |
| Length | | | capabilities |
| | | | |
| 802.11e | Variable | OCTETString | 802.11e capabilities |
| Capabilities | | | of WTP. If WTP does |
| | | | not have such |
| | | | capabilities, this |
| | | | field is filled with |
| | | | '0' |
| | | | |
| 802.11i Cap | 2 | Integer | Length of 802.11i |
| Length | | | capabilities |
| | | | |
| 802.11i | Variable | OCTETString | 802.11i capabilities |
| Capabilities | | | of WTP. If WTP does |
| | | | not have such |
| | | | capabilities,this |
| | | | field is filled with |
| | | | '0' |
| | | | |
| AuthType | 2 | OCTETString | Type of authentication |
| | | | mechanism used between |
| | | | WTPs and the AC |
+--------------+----------+----------------+------------------------+Conf-If-Data
okay this one's all about the wireless interface 📡 a WTP with lots of interfaces will send a bunch of Conf-If-Data message elements in its control messages to the AC 💜 they get indexed by the If ID information item, so you can tell them apart 🦋
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| If ID | 1 | Integer | Denotes identification |
| | | | of a wireless |
| | | | interface |
| | | | |
| Current | 1 | Integer | Current Power Level |
| Power | | | ('1' = Max; '2' = 1/2; |
| | | | '3' = 1/4; '4' = 1/8 |
| | | | |
| Radio | 1 | Integer | Radio channel of |
| Channel | | | operation |
| | | | |
| 2Dot4Mode | 1 | Integer | Interface mode in |
| | | | 2.4GHz. ('1' = IEEE |
| | | | 802.11b; '2' = IEEE |
| | | | 802.11g; '3' = Both) |
+--------------+----------+----------------+------------------------+Conf-WTP-Data
configuration info is handed out per logical group, like virtual APs 🌈 there are multiple Conf-WTP-Data message elements so every logical group in a WLAN managed by WiCoP gets covered 👑 these are indexed by the BSSID information item, so they're easy to find 🫶
Okay bestie, let's keep going 🫶✨ Here's the first table, full of items that set up the logical groups in a WLAN managed by WiCoP 🎀
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| BSSID | 6 | OCTETString | BSSID |
| | | | |
| ESSID | 32 | OCTETString | Extended Service Set |
| | | | Identifier (ESSID) |
| | | | |
| BSSID - | 32 | OCTETString | Mapping for logical |
| TunnelID | | | groups across BSSID |
| | | | and WiCoP tunnels |
| | | | |
| Beacon | 1 | Integer | Time interval between |
| Period | | | Beacon transmissions |
| | | | |
| DTIM Period | 1 | Integer | Delivery Traffic |
| | | | Indication Message |
| | | | (DTIM) period of |
| | | | Beacon transmissions |
| | | | |
| AnyRejectFla | 1 | Integer | Flag indicating WTP |
| g | | | rejection of any Probe |
| | | | Request within any |
| | | | SSID - ('1' = |
| | | | Rejected; '2' = Not |
| | | | Rejected) |
| | | | |
| SSID Stealth | 1 | Integer | Flag indicating |
| Flag | | | inclusion of ESSID |
| | | | within Beacon Frames |
| | | | ('1' = ESSID included; |
| | | | '2' = ESSID not |
| | | | included) |
| | | | |
| Operation | 2 | Integer | Data rates supported |
| Rate Set | | | by WTP for terminal |
| | | | being added using a |
| | | | 12-bit format for 1.1, |
| | | | 2.2, 3.55, 4.6, 5.9, |
| | | | 6.11, 7.12, 8.18, |
| | | | 9.24, 10.36, 11.48, |
| | | | and 12.54 Mbps |
| | | | |
| Encryption | 1 | Integer | Encryption Type - |
| Type | | | （'1' = OFF; '2' |
| | | | = WEP40; '3' = WEP104; |
| | | | '4' = WEP128) |
| | | | |
| Encryption | 16 | OCTETString | Static Encryption Key |
| Key | | | |
+--------------+----------+----------------+------------------------+Cap-to-WTP 💅 is where the capability info lives, and it's given per logical group, like virtual APs 📡 So there are multiple Cap-to-WTP message elements, one for each logical group inside a WLAN that WiCoP manages. Conf-to-WTP message elements are indexed by the BSSID information item. If logical groups get created some other way, their identifier is the index instead 🌸
Here's the table for it:
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| BSSID | 6 | OCTETString | BSSID |
| | | | |
| 802.11e Cap | 2 | Integer | Length of 802.11e |
| Length | | | capabilities |
| | | | |
| 802.11e | Variable | OCTETString | 802.11e capabilities |
| Capabilities | | | of WTP. If WTP does |
| | | | not have such |
| | | | capabilities, this |
| | | | field is filled with |
| | | | '0' |
| | | | |
| 802.11i Cap | 2 | Integer | Length of 802.11i |
| Length | | | capabilities |
| | | | |
| 802.11i | Variable | OCTETString | 802.11i capabilities |
| Capabilities | | | of WTP. If WTP does |
| | | | not have such |
| | | | capabilities, this |
| | | | field is filled with |
| | | | '0' |
+--------------+----------+----------------+------------------------+QoS-Value 🎀 is next, and it's all about making sure each logical group gets QoS parameters that fit its own conditions and needs 💖 QoS-Value message elements are provided per logical group too. They're indexed by the BSSID information item, and if logical groups are made some other way, their identifier is the index 🦋
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| BSSID | 6 | OCTETString | BSSID |
| | | | |
| WTP AC_BE | 2 | Integer | AC Parameters Record |
| | | | AC_BE in WTP |
| | | | |
| WTP AC_BK | 2 | Integer | AC Parameters Record |
| | | | AC_BK in WTP |
| | | | |
| WTP AC_VI | 2 | Integer | AC Parameters Record |
| | | | AC_VI in WTP |
| | | | |
| WTP AC_VO | 2 | Integer | AC Parameters Record |
| | | | AC_VO in WTP |
| | | | |
| TE AC_BE | 2 | Integer | AC Parameters Record |
| | | | AC_BE in terminals |
| | | | |
| TE AC_BK | 2 | Integer | AC Parameters Record |
| | | | AC_BK in terminals |
| | | | |
| TE AC_VI | 2 | Integer | AC Parameters Record |
| | | | AC_VI in terminals |
| | | | |
| TE AC_VO | 2 | Integer | AC Parameters Record |
| | | | AC_VO in terminals |
+--------------+----------+----------------+------------------------+Timer-Init-Value ⏰ works a bit differently 🧚 WiCoP timers are used for the WTP as a whole, so this message element is provided per WTP, not per logical group ✨
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| BSSID | 6 | OCTETString | BSSID |
| | | | |
| Response | 4 | Integer | Initial value of |
| Timer | | | Response Timer |
| | | | |
| Active | 4 | Integer | Initial value of |
| Presence | | | Active Presence Timer |
| Timer | | | |
| | | | |
| Feedback | 4 | Integer | Initial value of |
| Interval | | | Feedback Interval |
| Timer | | | Timer |
+--------------+----------+----------------+------------------------+Terminal-Data 📱 applies to both Local MAC and Split MAC WTP designs 💜 With Local MAC, Terminal-Data is sent from WTPs to the AC. With Split MAC, it goes the other way, from the AC to WTPs. So the direction depends on which kind of WTP is doing the wireless terminal operations 👑 And ngl, some information items may be optional, depending on the WTP design 🙈
BSSID, Encryption-Data, EAP-Frame, Statistics, Interface-Error, and FROM-Error are the last few message elements in this bunch, and each one has its own little job. Here's the first one, the Add-Station table, which carries on from the last part 💅
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| BSSID | 6 | PhyAddress | BSSID in which |
| | | | terminal is being |
| | | | added |
| | | | |
| MAC Address | 6 | PhyAddress | MAC address of |
| | | | terminal being added |
| | | | |
| Association | 2 | Integer | Association ID of |
| ID | | | terminal being added |
| | | | |
| Operation | 2 | Integer | Data rates supported |
| Rate Set | | | by WTP for terminal |
| | | | being added using a |
| | | | 12-bit format for 1.1, |
| | | | 2.2, 3.55, 4.6, 5.9, |
| | | | 6.11, 7.12, 8.18, |
| | | | 9.24, 10.36, 11.48, |
| | | | and 12.54 Mbps |
| | | | |
| Listen | 2 | Integer | Listen period |
| Period | | | |
+--------------+----------+----------------+------------------------+BSSID: 🦋
The BSSID message element is used to identify logical groups within a WLAN. It's giving "group chat for Wi-Fi" 😭 WiCoP can be extended to cover other kinds of logical groups too, just by adding more message elements. Iconic, honestly 🌈
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| BSSID | 6 | PhyAddress | BSSID in which |
| | | | terminal is being |
| | | | added |
| | | | |
| MAC Address | 6 | PhyAddress | MAC address of |
| | | | terminal being added |
+--------------+----------+----------------+------------------------+Encryption-Data: 🔐
This one holds the info needed to configure security keys at WTPs. It's used in setups where the authentication and encryption points live in separate WLAN entities. Two different bouncers, one club, very organised 💅
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| MAC Address | 6 | PhyAddress | MAC address of |
| | | | terminal |
| | | | |
| Operation | 1 | Integer | Operational Mode ('1' |
| | | | = Set Key; '2' = |
| | | | Delete Key) |
| | | | |
| Key Index | 1 | Integer | Key Index - valid when |
| | | | Operational Mode = Set |
| | | | Key |
| | | | |
| Key Flag | 1 | Integer | Key Flag ('1' = |
| | | | Unicast Key or PTK; |
| | | | '2' = Broadcast Key or |
| | | | GTK) - valid only when |
| | | | Operational Mode = Set |
| | | | Key |
| | | | |
| Cipher Suit | 1 | Integer | Encryption Type ('1' = |
| | | | WEP40; '2' = WEP104; |
| | | | '3' = WEP128; '4' = |
| | | | TKIP; '5' = AES) - |
| | | | valid only when |
| | | | Operational Mode = Set |
| | | | Key |
| | | | |
| Key | 32 | OCTETString | Key body - valid only |
| | | | when Operational Mode |
| | | | = Set Key |
+--------------+----------+----------------+------------------------+EAP-Frame: 🎀
This element carries EAP frames, which are used when configuring and managing the WLAN. Think of it as the envelope the important letters ride in ✉️✨
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| MAC Address | 6 | PhyAddress | MAC address of |
| | | | terminal |
| | | | |
| EAP | Variable | OCTETString | EAP Frames |
+--------------+----------+----------------+------------------------+Statistics: 📊🌸
Statistics cover all aspects of WTPs, so this element is provided on a per-WTP basis. Bestie, the cool part is that WiCoP messages carrying the Statistics element also double as keepalive signals between WTPs and the AC. Two jobs, one message, lowkey genius 🧠💖
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| OutOctet | 4 | Counter 32 | Octet number of frame |
| | | | WTP transmits |
| | | | |
| Transmit | 4 | Counter 32 | Total number of frames |
| Count | | | transmitted by WTP |
| | | | |
| Successful | 4 | Counter 32 | Total number of ACKs |
| Transmit | | | received |
| Count | | | |
| | | | |
| ACK Failure | 4 | Counter 32 | Total number of failed |
| Count | | | ACKs |
| | | | |
| InOctets | 4 | Counter 32 | Octet number of frame |
| | | | WTP receives |
| | | | |
| Receive | 4 | Counter 32 | Total number of frames |
| Count | | | received by WTP |
| | | | |
| Receive | 4 | Counter 32 | Total number of |
| Discard | | | received frames that |
| | | | are discarded |
| | | | |
| Retransmissi | 4 | Counter 32 | Number of WTP |
| on Count | | | retransmission |
| | | | attempts" |
| | | | |
| Duplicate | 4 | Counter 32 | Number of duplicate |
| Receive | | | frames received by WTP |
| Count | | | |
| | | | |
| FCS Error | 4 | Counter32 | Number of frames |
| Receive | | | received with FCS |
| Count | | | errors |
| | | | |
| Unknown | 4 | Counter 32 | Number of unknown |
| Frame | | | protocol frames |
| Receive | | | received |
| Count | | | |
| | | | |
| Beacon | 4 | Counter 32 | Number of transmitted |
| Transmit | | | Beacon frames |
| Count | | | |
| | | | |
| Probe | 4 | Counter 32 | Number of transmitted |
| Transmit | | | Probe Response frames |
| Count | | | |
| | | | |
| Probe | 4 | Counter 32 | Number of received |
| Receive | | | Probe Response frames |
| Count | | | |
| | | | |
| Decrypt CRC | 4 | Counter 32 | Number of received |
| Error Count | | | frames that cannot |
| | | | decrypt |
+--------------+----------+----------------+------------------------+Interface-Error: ⚠️💜
This element exchanges info on error conditions related to the wireless interface. It's the group chat's "something's not vibing with the signal" alert 📡💀
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| Interface | 1 | Integer | Interface ID |
| Index | | | |
| | | | |
| Error Type | 1 | Integer | Type of error ('1' = |
| | | | Unrecoverable; '2' = |
| | | | Recoverable) |
+--------------+----------+----------------+------------------------+FROM-Error: 🧚
The FROM-Error message element is used to exchange information on error conditions related to flash ROMs in WTPs or the AC. Flash ROM drama, but make it protocol 🍓
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| FROM Index | 1 | Integer | FROM ID |
| | | | |
| Error Type | 1 | Integer | Type of error ('1' = |
| | | | Unrecoverable; '2' = |
| | | | Recoverable) |
+--------------+----------+----------------+------------------------+QoS Capability 💖 okay so this one is all about bringing up the EDCA and HCCA capabilities of WTPs. Basically it's how the WTP tells everyone what QoS tricks it can do, and it's giving very organized energy ✨
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| EDCA | 1 | Integer | EDCA Capability ('1' = |
| | | | Capable; '2' = Not |
| | | | capable) |
| | | | |
| HCCA | 1 | Integer | HCCA Capability ('1' = |
| | | | Capable; '2' = Not |
| | | | capable) |
+--------------+----------+----------------+------------------------+TFTP-Data 🌸 this one is for firmware data going from an AC down to WTPs. Firmware delivery, bestie, it's serious business 💅
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| TFTP Data | Variable | OCTETString | Details of Trivial File|
| | | | Transfer Protocol |
| | | | (TFTP) |
+--------------+----------+----------------+------------------------+Result 🦋 this is the element that shows up in every WiCoP response message, and its whole job is to say how the WiCoP request went. OK / NG, that's the tea ☕
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| Result Code | 1 | Integer | '1' = OK; '2' = NG |
+--------------+----------+----------------+------------------------+OID 🧚 used for general configuration info that's identified by OIDs. It's giving flexible, and it's got three parts: a length, an OID string, and a value 💜
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| Length | 1 | Integer | Length of OID String |
| | | | and OID Value |
| | | | |
| OID String | Variable | OCTETString | Object Identifier that |
| | | | is assigned according |
| | | | to Basic Encoding |
| | | | Rules (BER) |
| | | | |
| Value | Variable | OCTETString | Value |
+--------------+----------+----------------+------------------------+GTK-Flag 🔥 this one tells the WTP what type of GTK is being used, and that also decides how the KeyMIC gets computed. Very key-coded, iykyk 🙈
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| GTK Flag | 1 | Integer | Determines the type of |
| | | | GTK ('1' = New; '2' = |
| | | | Existing) |
+--------------+----------+----------------+------------------------+4.2.3. WiCoP Control Message Description 🎀
Okay now we're getting into the actual messages, and this is where the whole conversation happens 🍓 Each one has a direction, a type, and a little description of what it's for, plus the message elements it carries.
Message: Capabilities 👑 Direction: WTP -> AC Type: Request
Description: WTPs send a Capabilities message right after moving from the Initialization state to the Capabilities Exchange state. It's how they find and identify the controlling AC of the WLAN and hand over their identification and capabilities info. In the IEEE 802.11 use-case, the Capabilities message also spells out the WTP's IEEE 802.11e and IEEE 802.11i features 🌈
TLV: The Capabilities message includes message elements of types 1 and 2.
+----------------+
| Capabilities |
+----------------+
| WTP-Info |
| |
| Cap-from-WTP |
+----------------+Message: Capabilities Response 💜 Direction: AC -> WTP Type: Response
Description: The AC sends this one after checking whether the WTP and its capabilities are compatible. That compatibility check is about the MAC architecture the AC can support. If the WTP passes, the Capabilities Response also carries info about the AC's own capabilities ✨
TLV: The Capabilities Response message includes message elements of types 5 and 17. The Cap-to-WTP message elements are told apart by BSSIDs, so they represent different logical groups 🦋
+-----------------------+
| Capabilities Response |
+-----------------------+
| Cap-to-WTP 1 |
| |
| Cap-to-WTP ... |
| |
| Cap-to-WTP n |
| |
| Result |
+-----------------------+Message: Connection 🔐 Direction: WTP -> AC Type: Request
Description: The Connection message kicks off the mutual security association between an AC and WTPs. It carries the first message of whichever security protocol got chosen. The specific authentication mechanism is out of scope for the WiCoP specifications, so that part isn't on this doc's plate 💅
TLV: The Connection message includes message elements of type 2.
+---------------+
| Connection |
+---------------+
| Cap-from-WTP |
+---------------+Message: Connection Response 🫶 Direction: AC -> WTP Type: Response
Description: Once the security protocol exchange is done, this message reports the result of the WTP-AC security association. If it worked, it also means the WTP has been admitted into the WLAN. Main character admission energy 👑
TLV: Type 17 message element is included.
+---------------------+
| Connection Response |
+---------------------+
| Result |
+---------------------+Message: Configuration Request ⭐ Direction: WTP -> AC Type: Request
Description: This message starts the Configuration state for the WTP. It's the WTP asking the AC for configuration information 🧚
Message: Configuration Response 🌸 Direction: AC -> WTP Type: Response
Description: This is the acknowledgement for the Configuration Request message. Simple and iconic 💖
TLV: Type 17 message element is included.
+------------------------+
| Configuration Response |
+------------------------+
| Result |
+------------------------+Message: Configuration Data 🔥 Direction: AC -> WTP Type: Request
Description: This is where the configuration info gets delivered, including operational parameters, QoS settings, and timer values. The same message is also reused for configuration updates in the Operation state of WiCoP, so it's versatile, bestie 🌈
TLV: This message includes message elements of types 3, 4, 5, 6, and 7. The Conf-WTP-Data and QoS-Value message elements are identified by BSSIDs to denote logical groups, while the Conf-If-Data message elements are identified by If-IDs to denote multiple wireless radios 🦋
+---------------------+
| Configuration Data |
+---------------------+
| Conf-If-Data 1 |
| |
| Conf-If-Data ... |
| |
| Conf-If-Data n |
| |
| Conf-WTP-Data 1 |
| |
| Conf-WTP-Data ... |
| |
| Conf-WTP-Data n |
| |
| Cap-to-WTP 1 |
| |
| Cap-to-WTP ... |
| |
| Cap-to-WTP n |
| |
| QoS-Value 1 |
| |
| QoS-Value ... |
| |
| QoS-Value n |
| |
| Timer-Init-Value |
+---------------------+Message: Configuration Data Response 💜 Direction: WTP -> AC Type: Response
Description: The acknowledgement for the Configuration Data message. The WTP says "got it" 🫶
TLV: Type 17 message element is included.
+-----------------------------+
| Configuration Data Response |
+-----------------------------+
| Result |
+-----------------------------+Message: Configuration Trigger ✨ Direction: AC -> WTP Type: Request
Description: This message triggers the activation of the configuration info sent in earlier Configuration messages. It's the "okay, go live now" button 🚀
Message: Configuration Trigger Response 🎀 Direction: WTP -> AC Type: Response
Description: The acknowledgement of the Configuration Trigger. This response gets sent before the configuration info is actually activated, so the WTP is basically saying "on it" before the glow-up happens 💅
TLV: Message elements of type 17 are included.
+--------------------------------+
| Configuration Trigger Response |
+--------------------------------+
| Result |
+--------------------------------+Message: Reset 🔥 Direction: AC -> WTP Type: Request
Description: This one is the AC telling the WTP to clear its registers and go back to initial conditions. Full reset, fresh start, no cap 💀
4. WiCoP Format ✨
4.2.3. WiCoP Control Message Description (continued) 💅
Okay, let's keep going with the message list! 🎀
Message: Reset Response Direction: WTP -> AC Type: Response
This one is the WTP's little "got it!" 💖 It's the acknowledgement for the Reset message, sent back to the AC. It carries message elements of type 17.
+----------------+
| Reset Response |
+----------------+
| Result |
+----------------+Message: Feedback Direction: WTP <-> AC Type: Request
Feedback is giving main character energy 🦋 It's used for two things, depending on who's talking:
- WTP: It sends regular statistics to the AC, and it doubles as a keepalive that refreshes the Active Presence Timer the AC is keeping track of. 💜
- AC: It's how the AC figures out which WTPs are still active. 👑
It carries message elements of type 12.
+-------------+
| Feedback |
+-------------+
| Statistics |
+-------------+Message: Feedback Response Direction: WTP <-> AC Type: Response
This is the acknowledgement for Feedback messages. 🌸 It carries message elements of type 17.
+-------------------+
| Feedback Response |
+-------------------+
| Result |
+-------------------+Message: Firmware Download Direction: AC -> WTP Type: Request
The AC uses this one to tell WTPs to update their firmware 🔥 The message element holds info about the new firmware. It carries message elements of type 16.
+-------------------+
| Firmware Download |
+-------------------+
| TFTP-Data |
+-------------------+Message: Firmware Download Response Direction: WTP -> AC Type: Request Response
This is the acknowledgement for the Firmware Download message. 🧚 It carries message elements of type 17.
+----------------------------+
| Firmware Download Response |
+----------------------------+
| Result |
+----------------------------+Message: Notification Direction: WTP <-> AC Type: Request
Notification is for the non-periodic events, the "wait, something just happened!" moments 🚨 Either a WTP or the AC can send it. Notifications flag failures, non-periodic changes, and stuff like that. It carries message elements of types 13 and 14.
+------------------+
| Notification |
+------------------+
| Interface-Error |
| |
| FROM-Error |
+------------------+Message: Notification Response Direction: WTP <-> AC Type: Response
This is the acknowledgement for the Notification message 🫶 It may be followed by Configuration messages to rectify errors. It carries message elements of type 17.
+-----------------------+
| Notification Response |
+-----------------------+
| Result |
+-----------------------+Message: Terminal Addition Direction: WTP <-> AC Type: Request
Terminal Addition is the "a new device just joined the party!" message 🎉 It may be sent from WTPs or the AC, depending on the WTP type. Either way, it goes out in response to an IEEE 802.11 association frame.
- Split MAC WTPs: Terminal Addition goes from the AC to the WTPs, and it carries info about the wireless terminal that matters to the WTP. 🌈
- Local MAC WTPs: Terminal Addition goes from a WTP to the AC, and it carries info about the wireless terminal that matters to the AC. 🍓
It carries message elements of type 8.
+-------------------+
| Terminal Addition |
+-------------------+
| Terminal-Data |
+-------------------+Message: Terminal Addition Response Direction: WTP <-> AC Type: Response
This is the acknowledgement for Terminal Addition, sent by either the WTPs or the AC depending on the WTP type. 💜 It carries message elements of type 17.
+----------------------------+
| Terminal Addition Response |
+----------------------------+
| Result |
+----------------------------+Message: Terminal Deletion Direction: WTP <-> AC Type: Request
Terminal Deletion is the goodbye message 👋 It's sent when a wireless terminal disconnects, and it can come from WTPs or the AC. Either way, it tells the recipient to remove any state information about that specific wireless terminal. It gets sent in response to any of these:
- an IEEE 802.11 disassociation frame
- an IEEE 802.11 deauthentication frame
- the Active Presence Timer expiring 💀
- Split MAC WTPs: Terminal Deletion goes from the AC to the WTPs.
- Local MAC WTPs: Terminal Deletion goes from the WTPs to the AC.
It carries message elements of type 9.
+-------------------+
| Terminal Deletion |
+-------------------+
| BSSID |
+-------------------+Message: Terminal Deletion Response Direction: WTP <-> AC Type: Response
This is the acknowledgement for Terminal Deletion, sent by either the WTPs or the AC depending on the WiCoP interface. 🌸 It carries message elements of type 17.
+----------------------------+
| Terminal Addition Response |
+----------------------------+
| Result |
+----------------------------+Message: Key Configuration Direction: AC -> WTP Type: Request
Key Configuration is for when the authentication and encryption points live in different WLAN entities 🔐 WiCoP uses it when 'M' = 0 and 'D' = 0, or when 'M' = 1 and 'D' = 1. It's how the AC sends security key info down to the WTPs.
The following message elements are included for Key Configuration.
+-------------------+
| Key Configuration |
+-------------------+
| GTK-Flag |
| |
| Encryption-Data |
| |
| EAP-Frame |
+-------------------+Message: Key Configuration Response Direction: WTP -> AC Type: Response
This is the acknowledgement for the Key Configuration message 🗝️ It carries message elements of type 17.
+----------------------------+
| Key Configuration Response |
+----------------------------+
| Result |
+----------------------------+4.3. WiCoP Data Packet 🦋
WiCoP data packets are the WiCoP common header followed by a payload. 💖 They're there to tell data traffic apart from control traffic when both paths are identical. That happens when the WTPs' data traffic goes through the AC. But large-scale WLAN deployments are super diverse, so sometimes the data and control paths are separate. WiCoP works in both cases. ✨
The WiCoP data packet format is shown in Figure 7 below, together with the WiCoP common header.
0 31
| 7 15 23 |
|-------|-------|-------|-------|-------|-------|-------|-------|
| |
+---------------+-+-+-+-+-+-+-+-+-------------------------------+
| Version |M|D|C|R|E|F|L| | Reserve |
+---------------+-+-+-+-+-+-+-+-+-------------------------------+
| Fragment ID | Fragment No. | Length |
+---------------+---------------+-------------------------------+
| Payload |
+---------------------------------------------------------------+Figure 7
4.4. WiCoP Timers ⏰
WiCoP runs a bunch of timers to figure out the WLAN status and keep performance healthy. 🍓 Every WiCoP entity maintains timers.
4.4.1. Active Presence Timer 👀
The Active Presence Timer is how each WiCoP entity (the AC and the WTPs) checks that the other one is still around. 🫶 If no reply to a Feedback message comes back before the timer runs out, the other entity is considered inactive, and contingency operations like reset kick in. The value ranges from 10 to 300 seconds, with a default of 30 seconds.
4.4.2. Feedback Interval 📊
Feedback messages go out periodically, at the frequency set by the Feedback Interval. The WTP configuration sets this interval. It ranges from 1 to 100 seconds, with a default of 10 seconds.
The Feedback Interval timer sets how often WLAN system audits happen. So with this timer, the WLAN controller gets regular info on the state of the WLAN and all of its WTPs. 🌈
4.4.3. Response Timer ⚡
This is a general-purpose timer that limits how long you wait between sending a request message and getting the matching response. It ranges from 1 to 3 seconds, with a default of 1 second.
4.4.4. Wireless Connectivity Timer 📡
This timer triggers any changes in wireless connectivity. 💜 WiCoP uses it to send Notification and other messages about wireless conditions. It's also used to trigger disconnection of mobile terminals without disassociation. The value ranges from 1 minute to 86,400 minutes, with a default of 10 minutes.
5. WiCoP Processes 🎀
The processes of the Wireless LAN Control Protocol are described in this section, organized by the operational state they happen in. 💅
5.1. Initialization 🌸
The Initialization state is the starting point for WiCoP entities. WTPs and ACs in this state are powered on, run hardware self-check tests, and reset their network interfaces. ⭐
State transition: Initialization -> Capabilities Exchange
WTP: Automatically upon detecting an active network interface
AC: Upon receiving a Capabilities message from a WTP5.2. Capabilities Exchange ✨
okay so Capabilities Exchange is the state where WTPs go hunting for an AC and then swap capabilities info with it 🔍💖 it's the matchmaking phase, bestie
WiCoP is built to control WLANs with both Local MAC and Split MAC WTPs 🦋 the differences between those two setups get sorted out right here in this state
the WTP fires off a Capabilities message the moment it leaves its Initialization state 📣 that message is how it discovers ACs, and it carries info about its identity and capabilities
the AC that receives the Capabilities message leaves its own Initialization state 🌸 it checks whether it's compatible with the WTP type and its capabilities, then sends back an appropriate Capabilities Response message
the WTP keeps sending Capabilities messages at an interval set by the Response Timer until a Capabilities Response message finally shows up from an AC 🫶
the AC also keeps a count of the Capabilities messages it gets from each WTP 🙈 once a WTP goes over a limit, the AC ignores it. this is so rogue WTPs that aren't compatible with the AC can't keep knocking over and over. the limit is 3 connection attempts within 60 seconds 💀
the 3-within-60-seconds rule is the AC's bouncer. don't be the 4th knock in a minute, periodt 🚫
State transition: Capabilities Exchange -> Connection
State transition: Capabilities Exchange -> Connection
WTP: Upon receiving a positive Capabilities Response message
from an AC
AC: Upon receiving a Connection Request message from a WTP5.3. Connection ✨
Connection is where the two sides build their security infrastructure 🔐 the vibe is "establish trust, then we talk"
the WTP sends a Connection message to kick off the authentication and security mechanism. in other words, this message starts an IPsec security association 🔑
the AC replies with a positive Connection Response message once the security association is set up, or a negative Connection Response message if something goes wrong 😬 the AC also keeps an eye on the WiCoP control messages it receives so it can prevent replay attacks 🛡️
the security association between an AC and its WTPs covers mutual authentication, and it also protects subsequent traffic for integrity, confidentiality, and protection against modification 👑 main character security energy
so legitimate WTPs don't get forcefully disconnected after a successful Connection, the AC ignores Capabilities messages that come in with a WTP identification it has already registered 🫶
State transition: Connection -> Configuration
State transition: Connection -> Configuration
WTP: Upon successful establishment of security infrastructure
marked by sending of a Configuration Request message
AC: Upon receiving Configuration Request message from a WTP
after successful establishment of security infrastructureState transition: Connection -> Capabilities Exchange
State transition: Connection -> Capabilities Exchange
WTP: Upon expiry of the WTP Response Timer before receipt of a
positive Connection Response message from an AC or upon
receipt of a negative Connection Response message
AC: Upon expiry of AC Response Timer before receipt of
Configuration Request message from WTP5.4. Configuration ✨
Configuration is where the relatively long-term operational parameters get exchanged, like identification and logical groups 🎀 these are based on the capabilities info from before, plus network policies
the WTP sends a Configuration Request message to the AC 💌
the AC acknowledges the WTP's Configuration Request first 💅 then it sends the right configuration info in later Configuration Data messages. WiCoP also puts MIB objectives into message elements in some Configuration Data messages, which makes WTP configuration way easier 🧚
the WTP acknowledges Configuration Data messages either one at a time or en bloc with Configuration Data Response messages 🍓 the Response Timer runs at both the WTP and the AC to keep track of these exchanges
the AC also sets up processing schedules that match the WTP's architecture 🧠 for Split MAC WTPs, the AC schedules its processing to parse IEEE 802.11 control and management messages. for Local MAC WTPs, the AC schedules processing so it skips parsing IEEE 802.11 management messages. different architecture, different vibe 🌈
after it's sent all the relevant configuration info, the AC sends a Configure Trigger message to the WTP ⚡
the WTP acknowledges the Configure Trigger message with a Configure Trigger Response message, and only then does it activate the configuration parameters it got earlier 🔥
again, so legitimate WTPs don't get forcefully disconnected after successful Configuration, the AC ignores Capabilities messages that come in with a WTP identification it already registered 🫶
State transition: Configuration -> Operation
State transition: Configuration -> Operation
WTP: After receiving final Configuration Data message from the
AC marked by receipt of a Configure Trigger message from
the AC
AC: Upon receiving acknowledgement for Configure Trigger
message marked by receipt of a Configure Trigger Response
message from WTPState transition: Configuration -> Capabilities Exchange
State transition: Configuration -> Capabilities Exchange
WTP: Upon expiry of the WTP Response Timer before receipt of a
Configure Trigger message from the AC
AC: Upon expiry of the AC Response Timer before receipt of
Configure Data Response message or Configure Trigger
Response messagethe following covers the major configuration aspects of WiCoP 💖
5.4.1. Logical Groups ✨
Configuration Data messages are how logical groups get set up in the WLAN, and also how traffic gets separated between them 🦋 the logical groups are built from network administrative policies and other external considerations. in the IEEE 802.11 use-case, logical groups are made with BSSID-based virtual APs, and they're kept apart over the WiCoP interface using tunnels 🚇
the AC assigns particular BSSIDs of the WTP to specific VLAN tunnels 🎀 that assignment gets passed to the WTP using the BSSID-TunnelID parameter in the Configuration Data message. so the logical group mapping works across both the wireless and WiCoP interfaces 💜
the WTP then treats the specified BSSID and VLAN tunnel as one logical group 🌸 it creates internal state so traffic from that logical group stays distinct from every other logical group
the AC and WTP also use separate VLAN tunnels for data traffic and control traffic 🫶 the 'C' field in the WiCoP header is what tells them which WiCoP packets belong to the data tunnel and which belong to the control tunnel
5.4.2. Resource Control ✨
the AC sends QoS information using QoS-Value message elements in Configuration Data messages 💅 the QoS-Value message element holds values for EDCA and HCCA parameters. this info is specified for each logical group. in the IEEE 802.11 use-case, QoS-Value message elements are specified for each BSSID 🍓
the WTP configures QoS parameters locally and also forwards the relevant settings to wireless terminals in the right encapsulations 📡 in the IEEE 802.11 use-case, those QoS parameters go out to wireless terminals in the corresponding Beacon or Probe Response frames ✨
5.5. Operation ✨
Operation is the active state of the WLAN, where the short-term dynamics get examined 👀💖
the WTP begins operating according to the operational parameters exchanged in the previous Configuration state 🚀
the AC monitors WTPs according to network administrative policies and configurations 🧐
again, so legitimate WTPs don't get forcefully disconnected after successful Operation setup, the AC ignores Capabilities messages that come in with a WTP identification it already registered 🫶
State transition: Operation -> Capabilities Exchange
State transition: Operation -> Capabilities Exchange
WTP: Upon expiry of the WTP Active Presence Timer before receipt
of a Feedback Response message from the AC
AC: Upon expiry of the AC Active Presence Timer before receipt
of a Feedback message from the WTPState transition: Operation -> Initialization
State transition: Operation -> Initialization
WTP: Upon receipt of a Reset message from an AC
AC: Upon receipt of a Reset Response message from a WTPthe following covers the major operation aspects of WiCoP 🌈
5.5.1. Updates ✨
WLAN systems are dynamic, so they need regular updates to network operations 🔄
the AC sends additional configuration info in Configuration Data messages 💫 this covers things like setting up new logical groups, changing existing ones, changing QoS settings, and so on. the configuration info is followed by a Configure Trigger message ⚡
the WTP sends a Configure Trigger Response before it activates the additional configuration info 🎀
configuration updates can also be used to clear statistics by reflecting initial values 🧹
the most extreme version of a configuration update is the Reset message from the AC, which tells the WTP to go back to its initial conditions 💀 the WTP replies with a Reset Response message before it reverts to its initial state 🫠
5.5.2. Feedback and Statistics ✨
the Operation state also sees regular feedback from WTPs to the AC 📊
the WTP sends Feedback messages to report various statistics and congestion condition info 📈 Feedback also covers the state of the WTP and the wireless medium, like queue levels and channel interference 📻 Feedback messages go out at a frequency set by the Feedback Interval ⏰ on top of the statistics, a Feedback message doubles as a WTP keepalive indicator for the AC 💓 so Feedback combines statistics with WTP status info, a true 2-in-1 moment 💅
the AC monitors Feedback messages for their statistics value and as an implicit sign of WTP activity 🔍 it also tracks congestion at wireless terminals and WTPs 🚦 this helps the AC adapt its downstream transmissions, like scheduling transmissions away from congested WTPs to relieve congestion 🌊
the AC also uses the Feedback message to randomly determine which WTPs are active 🎲 an active WTP answers with a matching Feedback Response message ✅
5.5.3. Non-Periodic Events ✨
the WTP and AC use the Notification message for non-periodic events 🔔 they send Notification messages to flag error conditions or drastic changes in congestion state 🚨
the recipient of a Notification message acknowledges it with a Notification Response message 💌 that response may include info on fixing the error, or it may just be a plain acknowledgement 🫶
5.5.4. Firmware Trigger ✨
the AC sends a Firmware Download message to update firmware at WTPs 💾 the Firmware Download message carries TFTP information, which the WTP uses to refresh its firmware 🪄 this happens when a new firmware version is available for the WTPs 🆕
the WTP acknowledges new firmware with a Firmware Download Response message, and after that the firmware gets activated 🔥✨
5.5.5. Wireless Terminal Management 📱✨
okay so the Operation state of WiCoP is also where the WTPs and the AC get to swap wireless terminal-specific info 🫶 it's giving teamwork
the Terminal Addition message is used when a new wireless terminal shows up in the WLAN 🦋 this message may be sent by either the WTPs or the AC, depending on which WiCoP interface is being used 💅 whoever receives it replies with the Terminal Addition Response message
then there's the Terminal Deletion message 🥀 which is used when a wireless terminal leaves the WLAN. it deletes the state info that was being kept by either the WTPs or the AC, and it gets acknowledged with the Terminal Deletion Response message 💜
Figure 8 below shows how the Terminal Addition and Terminal Deletion exchanges look for both Local-MAC and Split-MAC WiCoP interfaces 🌈
so the WiCoP Terminal Addition message gets triggered as a response to an IEEE 802.11 Association message 🎀 with a Local MAC architecture, the WTP sends it to the AC. but with a Split MAC architecture, Terminal Addition goes from an AC to the WTP 🧚
+----------+ +---------------+ +------+
| Terminal | | Local MAC WTP | | AC |
+----------+ +---------------+ +------+
| | |
| | |
| IEEE 802.11 Association | WiCoP |
|------------------------->| Terminal Addition |
| |===========================>|
| | |
| | WiCoP Terminal |
| |<===========================|
| IEEE 802.11 Association | Addition Response |
|<-------------------------| |
| Response | |
| | |
| | |
| |
| |
| |
| +---------------+ |
| | Split MAC WTP | |
| +---------------+ |
| | |
| | |
| IEEE 802.11 Association | |
|------------------------->| |
| | IEEE 802.11 Association |
| |===========================>|
| | (Over WiCoP) |
| | |
| | |
| | WiCoP |
| | Terminal Addition |
| |<===========================|
| | |
| | |
| | WiCoP Terminal |
| |===========================>|
| | Addition Response |
| | |
| | |
| | IEEE 802.11 Association |
| |<===========================|
| | Response (Over WiCoP) |
| IEEE 802.11 Association | |
|<-------------------------| |
| Response | |
Figure 85.5.6. Key Configuration 🔐
okay so, Split MAC and Local MAC WTPs don't all agree on where the over-the-air encryption happens 🫶 Some do it locally, and others leave it to the AC. WiCoP is lowkey flexible about this. When encryption happens at the WTP, the Key Configuration process is how the keys get set up there. So the whole encryption setup depends on the WiCoP protocol interface 💅
When dynamic WEP is used, the WiCoP Key Configuration message is how WTPs get encryption keys for each associated wireless terminal 🎀 The EAP over LAN (EAPoL) Key frame gets wrapped up inside the Key Configuration message and sent to a WTP. Once the WTP gets that message, it sets the encryption key in its local security table, unwraps the EAPOL Key frame, and forwards it to the wireless terminal. Here's the visual, Figure 9 ✨
+----------+ +-----+ +------+
| Terminal | | WTP | | AC |
+----------+ +-----+ +------+
| | |
| 802.1x Authentication |
|<=====================================================>|
| | |
| | |
PMK | PMK
| | |
| | |
|<-------------------------|<===========================|
| EAPoL Packet | WiCoP Control Packet |
| | (Key Configuration) |
| | | +-----------------------+
| | \|- Encryption-Data |
| | | Unicast-Key |
Set Receive |- EAP-Frame |
Unicast-Key Unicast-Key | Key Signature |
| | +-----------------------+
| | |
| |===========================>|
| | WiCoP Control Packet |
| | (Key Configuration |
| | Response ) |
| | |
| | |
| | |
| | |
|<-------------------------|<===========================|
| EAPoL Packet | WiCoP Control Packet |
| | (Key Configuration) |
| | | +-----------------------+
| | \|- Encryption-Data |
| | | Broadcast-Key |
Set Receive |- EAP-Frame |
Broadcast-Key Broadcast-Key | Key Signature |
| | | Broadcast Key |
| | +-----------------------+
| | |
| |===========================>|
| | WiCoP Control Packet |
| | (Key Configuration |
| | Response ) |
Figure 9Now the fun part 🌈 When WPA or IEEE 802.11i is used, and the authenticator sits at the AC while encryption happens at the WTPs, the 4-way handshake exchanges get handled differently. The AC can't calculate the KeyMIC because it doesn't know the KeyRSC sequence counter, so it's not in a position to do the math 🙈 Instead, a WiCoP Key Configuration message carries the 3rd message of the 4-way handshake, which holds the EAPoL-Key, with the KeyRSC and KeyMIC fields left unassigned.
When the WTP gets that Key Configuration message, it fills in the sequence number value in the KeyRSC field first. Then it calculates the KeyMIC value using the PTK and KeyRSC. So the KeyMIC gets calculated at the WTP instead of the AC, which is honestly iconic 👑 The GTK-Flag message element decides how the KeyMIC is calculated. For a new GTK, the KeyMIC is computed with a KeyRSC value of 0. For an existing GTK, it's computed with a KeyRSC value that matches the actual counter.
Figure 10 shows this case, where the WiCoP common header is either 'M' = 0 and 'D' = 0, or 'M' = 1 and 'D' = 1 🦋
+----------+ +-----+ +------+
| Terminal | | WTP | | AC |
+----------+ +-----+ +------+
| | |
| 802.1x Authentication |
|<=====================================================>|
| | |
PMK | PMK
| | |
Generate | Generate
SNonce | ANonce
| | |
| | |
| Message 1 |
|<-------------------------|<---------------------------|
| EAPoL Packet | WiCoP Data Packet |
Receive | |
ANonce | |
Generate | |
PTK | |
| | |
| Message 2 |
|------------------------->|--------------------------->|
| EAPoL Packet | WiCoP Data Pakcet |
| | Receive
| | SNonce
| | |
| | Generate
| | PTK
| | GTK
| Message 3 |
|<-------------------------|<===========================|
| EAPoL Packet | WiCoP Control Packet |
| | (Key Configuration) |
| | | +-----------------------+
| | \|- GTK-Flag |
Receive Receive |- Encryption-Data(PTK) |
GTK PTK |- Encryption-Data(GTK) |
| GTK |- EAP-Frame |
| | +-----------------------+
| | |
| | |
| | |
| Message 4 |
|------------------------->|--------------------------->|
| EAPoL Packet | WiCoP Data Pakcet |
| | |
Figure 10The 1st, 2nd, and 4th messages of the 4-way handshake ride along in WiCoP data packets. Those packets get priorities that are similar to WiCoP control packets, so they're treated kind of like VIPs 💖
The group key handshake for WPA and IEEE 802.11i works in a similar way ✨ The 1st message gets sent using the WiCoP Key Configuration message with an unassigned KeyRSC. The WTP then assigns the sequence number value to the KeyRSC and calculates the KeyMIC. The 2nd message, though, goes in WiCoP data packets with priorities similar to WiCoP control packets. Figure 11 has the full picture 🍓
+----------+ +-----+ +------+
| Terminal | | WTP | | AC |
+----------+ +-----+ +------+
| | |
| Message 1 |
|<-------------------------|<===========================|
| EAPoL Packet | WiCoP Control Packet |
| | (Key Configuration) |
| | | +-----------------------+
| | \|- GTK-Flag |
Receive Receive |- Encryption-Data(GTK) |
GTK GTK |- EAP-Frame |
| | +-----------------------+
| | |
| | |
| | |
| | |
| Message 2 |
|------------------------->|--------------------------->|
| EAPoL Packet | WiCoP Data Pakcet |
| | |
Figure 11The Key Configuration Response message is how the WTP tells the AC how the encryption setup went 🌸
6. WiCoP Performance ✨
WiCoP is an efficient protocol, bestie 🧚 This section shows a few examples of just how efficient it is.
6.1. Operational Efficiency
Managing WTPs of different designs takes a single operation in WiCoP, and that's what makes it operationally efficient 💅 WiCoP assigns dedicated classification bits in the common header, so an AC only has to parse incoming packets once to figure out how each one should be processed. Without those dedicated classifications, the AC would have to do a lookup after parsing every single incoming packet, and that would slow processing down 😭 Large-scale deployments are sensitive, so WLAN control protocols really do need to be efficient to run smoothly.
6.2. Semantic Efficiency
WiCoP sometimes combines utilities into one operation, and statistics and activity feedback are a perfect example 🦋 WTPs regularly send a single Feedback message that carries statistics and other state information. That same message also works as an implicit keepalive mechanism, which is so smart. It cuts down on the number of message exchanges and keeps protocol implementation simpler. The Capabilities messages do double duty too: they help WTPs find ACs and tell those ACs what the WTP can do and how it's designed 🎀
7. Summary and Conclusion ✨
okay so WiCoP is basically the answer to managing big WLANs with a bunch of different gadgets 🧚 it tackles the challenges in the CAPWAP Problem Statement [RFC3990] and actually delivers on the requirements of the CAPWAP Objectives [RFC4564] 👑
the protocol gives you integral control over both Split MAC and Local MAC WTPs 💅 it does this by defining differentiators inside the protocol message exchanges and processes. it also handles architectures where the authenticator and the encryption points live on separate entities, so the interoperability objective and its benefits are covered too 🫶
WiCoP is also giving shared WLAN deployments 🎀 it configures and manages WTPs on a logical group basis, and it's set up to separate control traffic from data traffic within WLANs. so yeah, both the logical groups objective and the traffic separation objective are addressed 🦋
overall? the specs in this document make for a seriously effective WLAN control and provisioning protocol 😭✨
8. Security Considerations 💀
okay this section is serious, so let's go 🔥 illegitimate WTPs and ACs are a big threat to WLAN security. the mitigation is to require every WiCoP entity to be mutually authenticated before it starts critical protocol exchanges. WiCoP includes a trigger for a suitable authentication mechanism, so a different security mechanism can be used between the WTPs and the AC depending on the deployment 🌸
beyond mutual authentication, the protocol information exchanged between the WTPs and the AC needs to be protected too 🛡️ those exchanges have to be guarded against alterations of any sort and against Denial-of-Service (DoS) attacks. the information should also not be accessible to any third party, so encryption of protocol exchanges is necessary. WiCoP includes procedures to select and establish a security association between the WTPs and the AC in the Connection state 🔐
now the replay attack situation 😱 in architectures where authentication happens at the AC and encryption happens at the WTPs, replay attacks can be a real problem. the AC doesn't know the exact value of the sequence counter, so it won't make the matching assignment within the 4-way handshake. that leaves the wireless terminal accepting every incoming frame, illegitimate ones included, because it can't verify the sequence counter value. this threat has to be guarded against by letting the WTP assign the correct sequence counter value. WiCoP does this by sending the 3rd message of the 4-way handshake to the WTP inside a control message, and the WTP then updates the sequence counter field before forwarding it to the wireless terminals 🙈
one more thing to watch: rogue WTPs using identifiers that look like legitimate ones. a rogue WTP can send a Capabilities message to the AC and knock the existing legitimate WTP with the same identifier offline 🚫 so it's really important that the AC ignores Capabilities messages received with existing identifiers 🫶
9. Informative References 📚
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access Points
(CAPWAP)", RFC 4118, June 2005.
[RFC4564] Govindan, S., Ed., Cheng, H., Yao, ZH., Zhou, WH., and L.
Yang, "Objectives for Control and Provisioning of Wireless
Access Points (CAPWAP)", RFC 4564, July 2006.
[RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and
Provisioning for Wireless Access Points (CAPWAP) Problem
Statement", RFC 3990, February 2005.Authors' Addresses 🎀
Satoshi Iino
Panasonic Mobile Communications
600, Saedo-cho
Tsuzuki-ku
Yokohama 224 8539
Japan
Phone: +81 45 938 3789
EMail: iino.satoshi@jp.panasonic.com
Saravanan Govindan
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534 415
Singapore
Phone: +65 6550 5441
EMail: saravanan.govindan@sg.panasonic.com
Mikihito Sugiura
Panasonic Mobile Communications
600, Saedo-cho
Tsuzuki-ku
Yokohama 224 8539
Japan
Phone: +81 45 938 3789
EMail: sugiura.mikihito@jp.panasonic.com
Hong Cheng
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534 415
Singapore
Phone: +65 6550 5447
EMail: hong.cheng@sg.panasonic.com📦 where this page comes from
- ietf: rfc5414 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms