Nous avons vu que dans l'architecture centralisée, les points d'accès abandonnaient certaines fonctions au profit des contrôleurs, et qu'ils étaient pilotés par ceux-ci.
Pour communiquer entre elles, ces entités utilisent un protocole d'échange : il s'agit de LWAPP (LightWeight Access Point Protocol). Celui-ci a d'abord été introduit en 2002 par la société Airespace, rachetée par Cisco en 2005.
Le protocole LWAPP est une solution propre à Cisco (mais non propriétaire), qui n'est pas compatible avec les matériels d'autres constructeurs. Il est documenté par le RFC 5412.
Dans un effort pour l'interopérabilité, des travaux ont été entrepris en vue de l'élaboration d'un standard IETF. Cela a abouti à la création d'un nouveau protocole, nommé CAPWAP (Configuration And Provisioning of Wireless Access Points), largement basé sur LWAPP. Le protocole est devenu un standard officiel de l'IETF, formalisé sous le RFC 5415. Il est cependant en deça de ce que peut offrir LWAPP, car ses ambitions étaient moindres (lire cet article).
L'établissement d'un tunnel du point d'accès jusqu'au contrôleur est le préalable à l'établissement de la communication entre ces deux entités. On le nomme tunnel LWAPP.
Le protocole peut opérer à deux niveaux : au niveau 2, il se situe au-dessus d'Ethernet, et au niveau 3, il est encapsulé dans un datagramme IP utilisant UDP comme protocole de transport.
Le fonctionnement en mode niveau 2 est considéré comme obsolète. En effet, il n'est pas routable (impossible de répartir les points d'accès sur plusieurs réseaux différents) et il oblige à une visibilité directe du contrôleur et des points d'accès (même VLAN).
Dans le tunnel LWAPP, le trafic, encapsulé dans un datagrappe UDP, se répartit en deux types distincts :
Les flux de contrôle utilisent le port destination UDP 12223. Les données sont chiffrées par une clé symétrique à l'aide de l'algorithme AES-CCM. L'échange des clés de session est réalisé au travers d'un tunnel établi suite à l'échange de certificats X.509 générés par la PKI de Cisco. Un certificat est présent dans la mémoire morte de tous les points d'accès Cisco.
Quant aux flux véhiculant les données des clients, ceux-ci utilisent le port UDP 12222. La totalité de la trame 802.11 reçue par le point d'accès est recopiée dans le datagramme en clair, et envoyée au contrôleur en unicast.
L'en-tête LWAPP est commun aux deux types de trafic. Il est formé comme suit :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VER| RID |C|F|L| Frag ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status/WLANs | Payload... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La distinction entre les types de trafic est réalisée en lisant le contenu du bit 'C' : il est à 1 pour une trame de type contrôle, et à 0 pour des données utilisateur.
La charge utile de la trame (payload) diffère selon le type de données transportées :
Layer 3 LWAPP Control Frame
+--------------------------------------------+
| MAC Header | IP | UDP | LWAPP Header [C=1] |
+--------------------------------------------+
| Control Message | Message Elements ... |
+-----------------+----------------------+
Layer 3 LWAPP Data Frame
+--------------------------------------------+
| MAC Header | IP | UDP | LWAPP Header [C=0] |
+--------------------------------------------+
|Forwarded Data ... |
+-------------------+
Puisque LWAPP encapsule les données des clients en ajoutant une couche, la question de l'efficacité du protocole se pose. Quelle est la quantité d'informations supplémentaires qu'il faut acheminer quand on utilise LWAPP ?
Dans les faits, celle-ci est minime : l'en-tête LWAPP, commun à toutes les trames, introduit une surcharge de 6 octets. Pour le transport des données utilisateur, la surcharge consiste en : un en-tête MAC, un en-tête IP, un en-tête UDP et un en-tête LWAPP, ce qui représente 48 octets, soit 3% du MTU standard sur les réseaux Ethernet (1500 octets).
Une étude a montré que cette surcharge n'a pas d'impact sur le fonctionnement du réseau, et en particulier qu'il n'est pas nécessaire d'augmenter la capacité des liens reliant les contrôleurs (centre) aux points d'accès (périphérie).
Il existe une situation où l'utilisation des tunnels jusqu'au contrôleur est fortement pénalisante, elle survient quand deux clients associés au même point d'accès s'envoient des données directement. Dans ce cas, chaque trame est remontée au contrôleur... pour revenir immédiatement au point d'accès vers le client de destination. En effet, les points d'accès ne possèdent pas de table ARP pour leur interface radio et sont incapables de transmettre les trames sans passer par le contrôleur. Il convient toutefois de relativiser ce point négatif, car la majorité des communications en entreprise consiste pour le client à accéder à une ressource centrale (bureau à distance, partage de fichiers) ; il est alors obligatoire de remonter le trafic vers le centre du réseau.