Contenido

Introducción

Configuración

Canal de control LWAPP

Intercambios iniciales/únicos

Intercambios en curso

Datos LWAPP

relleno de trama

Fragmentación

Conclusión

Información Relacionada

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

Tabla 1: Direcciones IP referenciales para dispositivos involucrados en el 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:

1. 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.

2. 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

Figura 8: Control LWAPP vs. valores de bytes de tráfico de datos LWAPP comparados

Figura 9: Control LWAPP vs. recuento de paquetes de tráfico de datos LWAPP comparado

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:

Figura 10: Comparación de protocolo basada en una captura de 1 hora con tráfico de datos bajo, fragmentos de IP y LWAPP mayoritario

Información Relacionada

- Registro de AP Ligero (LAP) a un Controlador de LAN Inalámbrica (WLC)

- Fundamentos de LWAPP

- Restablecimiento de la Configuración de LWAPP en un Lightweight AP (LAP)

- Consejos de Troubleshooting de la Herramienta de Upgrade de LWAPP

- Soporte Técnico y Documentación - Cisco Systems