Contents

Introduction

Instalação

Canal de controle LWAPP

Trocas iniciais/únicas

Trocas contínuas

Dados LWAPP

Preenchimento de Quadro

Fragmentação

Conclusão

Informações Relacionadas

Introduction

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.

Instalação

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 LWAPP

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

Canal de controle LWAPP

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.

Trocas iniciais/únicas

Descoberta de LWAPP (solicitação e resposta)

Figura 2: Fluxo de pacote de solicitação e resposta de descoberta LWAPP

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.

Associação LWAPP (solicitação e resposta)

Figura 3: Fluxo de pacote de solicitação e resposta de união LWAPP

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.

configuração LWAPP

Figura 4: LWAPP Configurar o estado e o fluxo do pacote de provisionamento do AP

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:

1. Na fase inicial, quando o AP ingressa em um controlador e precisa ser provisionado com todas as configurações 802.11 configuradas no controlador.

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

RRM (Radio Resource Management, gerenciamento de recursos de rádio)

Figura 5: Fluxo de pacote RRM inicial

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 acesso

Estatí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

Trocas contínuas

Pulso

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.

Medições de RRM

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

Medidas invasoras

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 acesso

Estatí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 normal

Figura 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

Dados LWAPP

Preenchimento de Quadro

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]

Fragmentação

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.

Conclusão

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:

Figura 10: Comparação de protocolos com base em uma captura de 1 hora com baixo tráfego de dados, fragmentos de IP e LWAPP majoritário

Informações Relacionadas

- Registro de AP leve (LAP) em um Wireless LAN Controller (WLC)

- Fundamentos do LWAPP

- Redefinição da configuração do LWAPP em um AP leve (LAP)

- Dicas de solução de problemas da ferramenta de atualização LWAPP

- Suporte Técnico e Documentação - Cisco Systems