O rascunho IETF-RFC, submetido ao grupo de trabalho Controle e Provisionamento de Pontos de Acesso Sem Fio (CAPWAP - Wireless Access Points), descreve o LWAPP (Light Weight Access Point Protocol) como um protocolo desenvolvido com o objetivo de definir diretrizes de comunicação entre Pontos de Terminação Sem Fio (Access Points) e Controladores de Acesso (Wireless LAN Controllers). Todas as comunicações LWAPP podem ser classificadas em um destes dois tipos de mensagem:
Canal de controle LWAPP
Dados encapsulados LWAPP
O LWAPP pode funcionar no modo de transporte de Camada 2 ou Camada 3. As comunicações LWAPP da camada 2 são encapsuladas em quadros Ethernet e podem ser identificadas com um valor EtherType de 0x88BB. Devido à sua confiabilidade na Ethernet, o modo de operação LWAPP da camada 2 não é roteável e exige visibilidade da camada 2 entre as WLCs e os APs. A camada 2 é considerada obsoleta e as estatísticas de protocolo descritas neste estudo de tráfego são baseadas no modo de transporte LWAPP da camada 3. O modo de transporte LWAPP da camada 3 especifica a troca de mensagens LWAPP na rede IP na forma de pacotes encapsulados UDP. O túnel LWAPP é mantido com o endereço IP da interface WLC (ap-manager) e o endereço IP do AP. Este estudo de tráfego revela a quantidade real de sobrecarga que as mensagens LWAPP apresentam em uma rede e uma linha de base da operação LWAPP em uma instalação padrão.
Observação: a especificação do LWAPP é discutida com detalhes no Rascunho LWAPP-IETF.
Este documento apresenta estatísticas relacionadas somente à operação do LWAPP e qualquer funcionalidade que não seja definida pela especificação do protocolo, como roaming entre controladores, está fora do escopo deste documento. Além disso, o estudo de tráfego aborda somente o modo de Camada 3 da operação do LWAPP.
Figura 1: Configuração do Estudo de Tráfego LWAPPTabela 1: Endereços IP referenciais para dispositivos envolvidos no estudo de tráfego do LWAPP
Interface/Dispositivo | IP Address |
---|---|
WLC - Interface de gerenciamento | 192.168.10.102 |
WLC - Interface ap-manager | 192.168.10.103 |
AP leve | 192.168.10.22 |
Para os fins deste estudo de tráfego, a configuração foi criada com apenas um ponto de acesso para estabelecer as linhas de base de troca e alterações de configuração iniciais. Mais APs foram adicionados posteriormente para determinar os efeitos do dimensionamento do número de APs na quantidade de tráfego gerado no fio.
O AP usa portas efêmeras quando se comunica com a WLC. Os números de porta usados pela WLC, em troca, são a porta UDP 12222 e a porta UDP 12223 para dados LWAPP e tráfego de controle LWAPP, respectivamente. Um quadro de controle LWAPP é diferenciado de um quadro de dados LWAPP pelo bit "C" no campo de flag do cabeçalho do LWAPP. Se definido como 1, é um quadro de controle.
As solicitações de descoberta do LWAPP, enviadas pelo ponto de acesso, são usadas para determinar quais WLCs estão presentes na rede.
Um pacote de solicitação de descoberta tem 97 bytes, o que inclui o FCS de 4 bytes. Um pacote de resposta de descoberta tem 106 bytes, o que inclui o FCS de 4 bytes.
Um pacote de solicitação de união LWAPP é usado pelo ponto de acesso para informar à WLC que deseja atender os clientes através do controlador. A fase de solicitação de junção também é usada para descobrir a MTU suportada pelo transporte. A solicitação de junção inicial enviada pelo Ponto de Acesso é sempre preenchida com um elemento de teste de 1596 bytes. Com base em como o transporte entre o AP e o controlador é configurado, esses quadros de solicitação de junção também podem ser fragmentados. Se uma resposta de junção for recebida para a solicitação inicial, o AP encaminhará quadros sem nenhuma fragmentação. A resposta de junção também inicia o temporizador de pulsação (um valor de 30 segundos) que, quando expira, exclui a sessão WLC-AP. O temporizador é atualizado após o recebimento da Solicitação ou Confirmações de Eco.
Se a solicitação de junção inicial não gerar nenhuma resposta, o AP envia outra solicitação de junção com o elemento de teste, o que leva o payload total a 1.500 bytes. Se a segunda solicitação de junção também não der uma resposta, o AP continua a alternar entre os pacotes grandes e pequenos e, eventualmente, expira para começar novamente da fase de descoberta.
Os tamanhos de pacote para a solicitação de junção e as mensagens de resposta variam com base na descrição, mas a troca de pacotes capturada para os fins deste estudo de tráfego entre o AP e a WLC (ap-manager interface) é de 3.000 bytes.
As solicitações e respostas de configuração do LWAPP são trocadas entre os Pontos de Acesso e os controladores para criar, alterar (atualizar) ou excluir os serviços oferecidos por um AP.
Em geral, uma mensagem Configure Request é enviada por um AP para enviar sua configuração atual para sua WLC.
A solicitação de configuração pode ser enviada em dois cenários:
Na fase inicial, quando o AP ingressa em um controlador e precisa ser provisionado com todas as configurações 802.11 configuradas no controlador.
No caso de alterações administrativas sob demanda, como uma alteração em um parâmetro WLAN
O tipo de mensagem de resposta de configuração do LWAPP é enviado pela WLC ao AP para confirmar o recebimento da solicitação de configuração do LWAPP do AP. Isso oferece uma oportunidade para a WLC substituir a configuração solicitada do AP. Não há elementos de mensagem especiais contidos em tal quadro.
A troca inicial entre o AP e a WLC (ap-manager interface) é de aproximadamente 6.000 bytes e uma alteração de configuração única é de 360 bytes, e envolve 2 pacotes cada um do AP e da interface ap-manager da WLC.
Uma troca de informações relacionada ao RRM ocorre quando o AP é provisionado. Uma troca típica entre o AP e a WLC (ap-manager interface) é de aproximadamente 1.400 bytes. No caso de uma alteração de configuração relacionada ao RRM, há uma troca de quatro pacotes entre o AP e a interface do gerenciador de AP da WLC. Essa troca tem em média 375 bytes.
Uma captura de amostra de 20 minutos que inclui a descoberta, a junção, a configuração e os processos em andamento resultou nessas estatísticas de tráfego em um segmento de 100 Mbps:
Tabela 1: Estatísticas iniciais de tráfego LWAPP para um único ponto de acessoEstatística | Valor |
---|---|
Total de bytes | 84,869 |
Utilização média (percentual) | 0.001 |
Utilização média (quilobits/s) | 0.425 |
Utilização máxima (percentual) | 0.004 |
Utilização máxima (quilobits/s) | 5.384 |
A Figura 6 é uma representação gráfica de todo o processo.
Figura 6: Comparação de protocolo durante a fase de descoberta, junção e provisionamento de AP
A arquitetura do LWAPP fornece um temporizador de pulsação que é realizado por uma série de Solicitações de Eco e Respostas de Eco. Um AP envia periodicamente solicitações de eco para determinar o estado da conexão entre o AP e a WLC. Em resposta, a WLC envia a Resposta de Eco para confirmar o recebimento da Solicitação de Eco. O AP, então, redefine o temporizador de pulsação para o EchoInterval. O rascunho da especificação do protocolo LWAPP contém uma descrição detalhada desses temporizadores. O heartbeat do sistema, juntamente com o mecanismo de fallback, é de 4 pacotes a cada 30 segundos e é composto destes pacotes:
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)
Essa troca gera 33 bytes de tráfego a cada 30 segundos.
Há duas trocas de RRM em andamento. O primeiro, a cada intervalo de 60 segundos, é a medição de carga e sinal e consiste em 4 pacotes. Essa troca sempre adiciona até 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)
A segunda sequência de pacotes é a medição de ruído que inclui uma solicitação de informação estatística e uma sequência de resposta. É feito a cada 180 segundos. Essa troca curta de pacotes tem uma média de aproximadamente 2.660 bytes e dura geralmente 0,01 segundo. Ele consiste nestes pacotes:
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
As medições invasoras são feitas como parte do mecanismo de varredura e incluídas na troca RRM a cada 180 segundos. Consulte Gerenciamento de recursos de rádio em Redes sem fio unificadas para obter mais informações.
A captura de amostra de 20 minutos resultou nos seguintes valores para trocas contínuas de pacotes em um segmento de 100 Mbps:
Tabela 2: Estatísticas de tráfego LWAPP contínuas para um único ponto de acessoEstatística | Valor |
---|---|
Total de bytes | 45,805 |
Utilização média (percentual) | < 0,001 |
Utilização média (quilobits/s) | 0,35 |
Utilização máxima (percentual) | < 0,001 |
Utilização máxima (quilobits/s) | 0.002 |
As estatísticas e as trocas no quadro 2 são descritas nas seguintes imagens:
Figura 7: Um exemplo de 20 minutos de comparação de protocolo enquanto o AP está em operação normalFigura 8: Valores de byte de tráfego de dados LWAPP Control vs. LWAPP
Figura 9: Controle LWAPP versus contagem de pacotes de tráfego de dados LWAPP comparados
O cabeçalho do quadro de dados LWAPP adiciona 6 bytes aos pacotes 802.11 existentes. Este cabeçalho é adicionado antes do quadro 802.11 encapsulado e inclui o seguinte:
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]
Como os quadros LWAPP podem ser fragmentados, um campo de ID de fragmento é incluído. O tamanho total do pacote pode ser determinado se você adicionar o quadro original e o Fragmento IP. É importante observar que o Fragmento IP não é encapsulado em nenhum cabeçalho LWAPP.
Como evidenciado pelas descobertas neste estudo de tráfego, a operação do LWAPP não introduz requisitos de largura de banda pesados na infraestrutura e, na maioria das implantações típicas, não há necessidade de adicionar capacidade extra à infraestrutura para acomodar a Cisco Unified Wireless Architecture. Como resumo do estudo de tráfego, esses fatos rápidos sobre a operação do LWAPP podem ser lembrados:
Embora a latência seja uma consideração importante, esse estudo de tráfego apresenta apenas considerações sobre o throughput. Como diretriz geral, o link AP-WLC não deve exceder a latência de ida e volta de 100 ms.
Há dois canais separados para a operação do LWAPP:
Dados LWAPP
Tráfego de controle LWAPP
A operação do LWAPP é dividida em duas grandes categorias:
troca única
trocas contínuas
Uma amostra de 20 minutos que inclui trocas iniciais resulta em uma estatística de utilização média de 0,001%.
Uma amostra de 20 minutos de trocas em andamento resulta em uma estatística de utilização máxima de 0,35 kilobits/segundo.
O canal de dados LWAPP adiciona um cabeçalho de 6 bytes a cada pacote de dados 802.11. Não há sobrecarga adicional para Fragmentos IP.
Um exemplo de uma hora apresenta esta separação de protocolos e suas respectivas porcentagens: