Estudio del Tráfico de LWAPP
Contenido
Introducción
El borrador IETF-RFC, enviado al grupo de trabajo de control y aprovisionamiento de puntos de acceso inalámbricos (CAPWAP), describe el protocolo de punto de acceso de peso ligero (LWAPP) como un protocolo desarrollado con el objetivo de definir directrices de comunicación entre puntos de terminación inalámbrica (puntos de acceso) y controladores de acceso (controladores de LAN inalámbrica). Todas las comunicaciones LWAPP se pueden clasificar en uno de estos dos tipos de mensajes:
-
Canal de control LWAPP
-
Datos encapsulados LWAPP
El LWAPP puede funcionar en el modo de transporte de Capa 2 o Capa 3. Las comunicaciones LWAPP de capa 2 se encapsulan en tramas Ethernet y se pueden identificar con un valor EtherType de 0x88BB. Debido a su confiabilidad en Ethernet, el modo de funcionamiento de LWAPP de Capa 2 no es enrutable y requiere visibilidad de Capa 2 entre los WLC y los AP. La capa 2 se considera obsoleta y las estadísticas de protocolo descritas en este estudio del tráfico se basan en el modo de transporte LWAPP de la capa 3. El modo de transporte LWAPP de Capa 3 especifica el intercambio de mensajes LWAPP en la red IP en forma de paquetes encapsulados UDP. El túnel LWAPP se mantiene con la dirección IP de la interfaz WLC (administrador de AP) y la dirección IP del AP. Este estudio del tráfico revela la cantidad real de sobrecarga que los mensajes LWAPP presentan en una red y una línea de base de la operación LWAPP en una instalación estándar.
Nota: La especificación del LWAPP se discute con gran detalle en el borrador del LWAPP-IETF.
Configuración
Este documento presenta estadísticas relacionadas con el funcionamiento del LWAPP solamente y cualquier funcionalidad que no esté definida por la especificación del protocolo, como el roaming entre controladores, está fuera del alcance de este documento. Además, el estudio del tráfico sólo abarca el modo de capa 3 del funcionamiento del LWAPP.
Figura 1: Configuración del estudio de tráfico LWAPP 
| Interfaz/Dispositivo | IP Address |
|---|---|
| WLC - Interfaz de administración | 192.168.10.102 |
| WLC - interfaz del administrador de AP | 192.168.10.103 |
| AP de peso ligero | 192.168.10.22 |
A efectos de este estudio del tráfico, la configuración se creó con un solo punto de acceso para establecer las líneas de base de los cambios iniciales de intercambio y configuración. Posteriormente se agregaron más AP para determinar los efectos de escalar el número de AP en la cantidad de tráfico generado en el cable.
Canal de control LWAPP
El AP utiliza puertos efímeros cuando habla con el WLC. Los números de puerto utilizados por el WLC, a cambio, son el puerto UDP 12222 y el puerto UDP 12223 para el tráfico de datos LWAPP y el control LWAPP respectivamente. Una trama de control LWAPP se distingue de una trama de datos LWAPP por el bit "C" en el campo de indicador de encabezado del LWAPP. Si se establece en 1, es una trama de control.
Intercambios iniciales/únicos
Detección de LWAPP (solicitud y respuesta)
Figura 2: Flujo de paquetes de respuesta y solicitud de detección de LWAPP 
Las solicitudes de detección de LWAPP, enviadas por el punto de acceso, se utilizan para determinar qué WLC están presentes en la red.
Un paquete de solicitud de detección es de 97 bytes, que incluye el FCS de 4 bytes. Un paquete de respuesta de detección es de 106 bytes, que incluye el FCS de 4 bytes.
Unión LWAPP (solicitud y respuesta)
Figura 3: Flujo de paquetes de solicitud de unión y respuesta de LWAPP 
El punto de acceso utiliza un paquete de solicitud de unión LWAPP para informar al WLC de que desea prestar servicio a los clientes a través del controlador. La fase de solicitud de unión también se utiliza para detectar la MTU soportada por el transporte. La solicitud de unión inicial enviada por el punto de acceso siempre se agrega con un elemento de prueba de 1596 bytes. Según cómo se configura el transporte entre el AP y el controlador, estas tramas de solicitud de unión también pueden fragmentarse. Si se recibe una respuesta de unión para la solicitud inicial, el AP reenvía tramas sin ninguna fragmentación. La respuesta de unión también inicia el temporizador de latido del corazón (un valor de 30 segundos) que, cuando caduca, elimina la sesión WLC-AP. El temporizador se actualiza al recibir la solicitud de eco o los reconocimientos.
Si la solicitud de unión inicial no da ninguna respuesta, el AP envía otra solicitud de unión con el elemento de prueba, lo que lleva la carga útil total a 1500 bytes. Si la segunda solicitud de unión tampoco da una respuesta, el AP continúa moviéndose entre los paquetes grandes y pequeños y, finalmente, se agota el tiempo de espera para comenzar de nuevo desde la fase Discovery.
Los tamaños de paquetes para los mensajes de solicitud de unión y respuesta varían según la descripción, pero el intercambio de paquetes capturado para los fines de este estudio de tráfico entre el AP y el WLC (interfaz de administrador de AP) es de 3,000 bytes.
configuración de LWAPP
Figura 4: LWAPP Configure el estado y el flujo de paquetes de aprovisionamiento de AP 
Las solicitudes y respuestas de configuración del LWAPP se intercambian entre los puntos de acceso y los controladores para crear, cambiar (actualizar) o eliminar los servicios ofrecidos por un AP.
En general, un AP envía un mensaje de solicitud de configuración para enviar su configuración actual a su WLC.
La solicitud de configuración se puede enviar en dos escenarios:
-
En la fase inicial cuando el AP se une a un controlador y necesita ser aprovisionado con todos los ajustes 802.11 configurados en el controlador.
-
En el caso de cambios administrativos a demanda, como un cambio a un parámetro WLAN
El WLC envía el tipo de mensaje de respuesta de configuración del LWAPP al AP para acusar la recepción de la solicitud de configuración del LWAPP desde el AP. Esto proporciona una oportunidad para que el WLC invalide la configuración solicitada del AP. No hay elementos de mensaje especiales contenidos en ese marco.
El intercambio inicial entre el AP y el WLC (interfaz de administrador de AP) es aproximadamente de 6,000 bytes y un cambio de configuración de una sola vez promedia 360 bytes e involucra 2 paquetes cada uno desde el AP y la interfaz de administrador de AP del WLC.
Administración de recursos de radio (RRM)
Figura 5: Flujo de paquetes RRM inicial 
Un intercambio de información relacionado con RRM se realiza una vez que se aprovisiona el AP. Un intercambio típico entre el AP y el WLC (interfaz de administrador de AP) es aproximadamente de 1400 bytes. En caso de un cambio de configuración relacionado con RRM, hay un intercambio de cuatro paquetes entre el AP y la interfaz del administrador de AP del WLC. Este intercambio promedia 375 bytes.
Una captura de muestra de 20 minutos que incluye los procesos de detección, conexión, configuración y en curso dio como resultado estas estadísticas de tráfico en un segmento de 100 Mbps:
Tabla 1: Estadísticas de tráfico LWAPP iniciales para un único punto de acceso| Estadística | Valor |
|---|---|
| Total bytes | 84,869 |
| Utilización media (porcentaje) | 0.001 |
| Utilización media (kilobits/s) | 0.425 |
| Utilización máxima (porcentaje) | 0.004 |
| Utilización máxima (kilobits/s) | 5.384 |
La figura 6 es una representación pictórica de todo el proceso.
Figura 6: Comparación de protocolo durante la fase de detección, incorporación y aprovisionamiento de AP 
Intercambios en curso
Latido
La arquitectura del LWAPP proporciona un temporizador de latidos que se logra mediante una serie de solicitudes de eco y respuestas de eco. Un AP envía periódicamente solicitudes de eco para determinar el estado de la conexión entre el AP y el WLC. En respuesta, el WLC envía la Respuesta de Eco para acusar recibo de la Solicitud de Eco. El AP, luego, restablece el temporizador de latido al EchoInterval. El borrador de la especificación del protocolo LWAPP contiene una descripción detallada de estos temporizadores. El latido del sistema, junto con el mecanismo de repliegue, es de 4 paquetes cada 30 segundos y está compuesto por estos paquetes:
LWAPP ECHO_REQUEST from AP (78 bytes) LWAPP Echo-Response to AP (64 bytes) LWAPP PRIMARY_DISCOVERY_REQ from AP (93 bytes) LWAPP Primary Discovery-Response to AP (97 bytes)
Este intercambio genera 33 bytes de tráfico cada 30 segundos.
Mediciones RRM
Hay dos intercambios de RRM en curso. La primera, cada intervalo de 60 segundos, es la medición de la carga y la señal y consta de 4 paquetes. Este intercambio siempre suma hasta 396 bytes:
LWAPP RRM_DATA_REQ from AP (107 bytes) LWAPP Airewave-Director-Data Response to AP (64 bytes) LWAPP RRM_DATA_REQ from AP (161 bytes) LWAPP Airewave-Director-Data Response to AP (64 bytes)
La segunda secuencia de paquetes es la medición de ruido que incluye una solicitud de información de estadísticas y una secuencia de respuesta. Se hace cada 180 segundos. Este breve intercambio de paquetes promedia aproximadamente 2.660 bytes y normalmente dura 0,01 segundos. Consta de estos paquetes:
LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP STATISTICS_INFO from AP LWAPP Statistics-Info Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP 00:14:1b:59:41:80 LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP STATISTICS_INFO from AP LWAPP Statistics-Info Response to AP
Mediciones no autorizadas
Las mediciones no autorizadas se realizan como parte del mecanismo de escaneo y se incluyen en el intercambio RRM cada 180 segundos. Refiérase a Administración de Recursos de Radio en Redes Inalámbricas Unificadas para obtener más información.
La captura de muestra de 20 minutos resultó en los siguientes valores para los intercambios de paquetes en curso en un segmento de 100 Mbps:
Tabla 2: Estadísticas de tráfico LWAPP en curso para un único punto de acceso| Estadística | Valor |
|---|---|
| Total bytes | 45,805 |
| Utilización media (porcentaje) | < 0.001 |
| Utilización media (kilobits/s) | 0,35 |
| Utilización máxima (porcentaje) | < 0.001 |
| Utilización máxima (kilobits/s) | 0.002 |
Las estadísticas y los intercambios que figuran en el cuadro 2 se muestran en estas imágenes:
Figura 7: Un ejemplo de comparación de protocolo de 20 minutos mientras el AP está en funcionamiento normal 
Datos LWAPP
relleno de trama
El encabezado de trama de datos LWAPP agrega 6 bytes a los paquetes 802.11 existentes. Este encabezado se agrega antes de la trama encapsulada 802.11 e incluye lo siguiente:
Light Weight Access Point Protocol [0-40]
Flags: %00000000 [42-48]
00.. .... Version: 0
..00 0... Radio ID: 0
.... .0.. C Bit - Data message [0-29]
.... ..0. F Bit - Fragmented packet [0-34]
.... ...0 L Bit - Last fragment [0-30]
Fragment ID: 0x00 [43-55]
Length: 74 [44-52]
Rec Sig Strngth Indic:183 dBm [46-77]
Signal to Noise Ratio:25 dB [47-76]
Fragmentación
Dado que las tramas LWAPP se pueden fragmentar, se incluye un campo de ID de fragmentación. El tamaño total del paquete se puede determinar si agrega la trama original y el fragmento IP. Es importante tener en cuenta que el fragmento IP no está encapsulado en ningún encabezado LWAPP.
Conclusión
Como se desprende de los resultados de este estudio del tráfico, el funcionamiento del LWAPP no introduce requisitos de ancho de banda pesados en la infraestructura, y en la mayoría de las implementaciones habituales, no hay necesidad de añadir capacidad adicional a la infraestructura para acomodar la arquitectura Cisco Unified Wireless. Como resumen del estudio del tráfico, se pueden tener en cuenta estos datos rápidos sobre el funcionamiento del LWAPP:
-
Aunque la latencia es una consideración importante, este estudio del tráfico sólo presenta consideraciones sobre el rendimiento. Como guía general, el link AP-to-WLC no debe exceder la latencia de ida y vuelta de 100 ms.
-
Hay dos canales separados para el funcionamiento del LWAPP:
-
Datos LWAPP
-
Tráfico de control LWAPP
-
-
El funcionamiento del LWAPP se divide en dos grandes categorías:
-
intercambios únicos
-
intercambios continuos
-
-
Una muestra de 20 minutos que incluye los intercambios iniciales da como resultado una estadística de utilización media del 0,001%.
-
Una muestra de 20 minutos de intercambios en curso da como resultado una estadística de utilización máxima de 0,35 kilobits/segundo.
-
El canal de datos LWAPP agrega un encabezado de 6 bytes a cada paquete de datos 802.11. No hay sobrecarga adicional para fragmentos IP.
-
Una muestra de una hora de duración presenta esta ruptura de protocolos y sus respectivos porcentajes:
Comentarios