AIGA: Um Ambiente Integrado de Gerência para Redes em ...
Transcript of AIGA: Um Ambiente Integrado de Gerência para Redes em ...
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA
DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E
COMPUTAÇÃO MESTRADO EM SISTEMAS E COMPUTAÇÃO
AIGA: Um Ambiente Integrado de Gerência para Redes em MalhaSem Fio IEEE 802.11s
Dhiego Fernandes Carvalho
Natal - RNMarço de 2014
Dhiego Fernandes Carvalho
AIGA: Um Ambiente Integrado de Gerência para Redes em MalhaSem Fio IEEE 802.11s
Dissertação de Mestrado apresentada ao curso de Pós-Graduação em Ciênciae Computação, da Universidade Federal do Rio Grande do Norte comorequisito parcial para a obtenção do grau de Mestre em Ciência eComputação.
Orientador: Prof. Dr. Marcos César Madruga A. Pinheiro
PPgSC – Programa de Pós-Graduação em Sistemas e Computação DIMAp – Departamento de Informática e Matemática Aplicada
CCET – Centro de Ciências Exatas e da Terra UFRN – Universidade Federal do Rio Grande do Norte
Natal - RNMarço de 2014
Dissertação de Mestrado sob o título AIGA: Um Ambiente Integrado de Gerência para Redes em
Malha Sem Fio IEEE 802.11s apresentada por Dhiego Fernandes Carvalho e aceita pelo Programa
de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática
Aplicada da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros
da banca examinadora abaixo especificada:
______________________________________________
Prof. Dr. Marcos César Madruga A. PinheiroPresidente
UFRN – Universidade Federal do Rio Grande do Norte DIMAp – Departamento de Informática e Matemática Aplicada
______________________________________________Augusto José Venâncio Neto
Examinador InternoUFRN – Universidade Federal do Rio Grande do Norte
DIMAp – Departamento de Informática e Matemática Aplicada
_____________________________________________Rommel Wladimir de Lima
Examinador Externo à InstituiçãoUERN – Universidade do Estado do Rio Grande do Norte
DI – Departamento de Informática
Natal, 31 de março de 2014
Agradecimentos
Dedico esse trabalho em primeiro lugar a minha filha Diana, que apesar de vivermos longe,
ela sempre esteve nos meus pensamentos diários e foi um dos meus maiores estímulos em continuar
com a minha carreira acadêmica.
Agradeço também ao meu orientador Marcos César Madruga A. Pinheiro, pois neste longo
tempo que esteve sendo meu orientador e professor, sempre esteve ao meu lado, orientando na
minha vida acadêmica, profissional e pessoal. Posso considerá-lo além do meu orientador e
professor, meu amigo pessoal que sou eternamente grato.
Agradeço aos meus pais por me darem condições de estudo, as oportunidades e ferramentas
que hoje são necessárias para ser o que sou. Muitas coisas que tenho hoje, principalmente por estar
concluindo a minha dissertação de mestrado, devem-se a eles. Sem meus pais, eu não teria as
oportunidades que muitas pessoas infelizmente não tiveram em suas vidas.
Sou grato aos meus amigos, que são muitos e não posso citar todos, que nos momentos de
dificuldade nesse longo período que passei até concluir esta dissertação, passando por alguns
tropeços que a vida dar, ajudaram-me e estivaram ao meu lado, incentivando-me mesmo que seja
com uma simples palavra de apoio.
Por fim, sou profundamente grato e dedico este trabalho a todos vocês.
AIGA: Um Ambiente Integrado de Gerência para Redes EmMalha Sem Fio IEEE 802.11s
Autor: Dhiego Fernandes CarvalhoOrientador: Prof. Dr. Marcos César Madruga A. Pinheiro
RESUMO
Por serem redes com diversas características interessantes como auto-organização e
tolerância a falhas, as Wireless Mesh Networks (WMN) vem sendo estudadas a bastante tempo pela
comunidade científica. Muitos desses estudos tipicamente são conduzidos utilizando redes em
ambientes controlados conhecidos como testbeds. Além disso, após a conclusão do processo de
padronização do IEEE 802.11s as WMN baseadas nessa tecnologia vem sendo cada vez mais
utilizadas como redes de produção nas organizações. Como são redes bastante flexíveis no que diz
respeito ao seu modo de operação, pois suportam um elevado número de parâmetros de
configuração, a tarefa de gerenciamento dessas redes tende a ser muito complexa. Não existe uma
configuração ideal que atenda a qualquer cenário, sendo preciso identificar o conjunto de valores
que oferecem o melhor desempenho para cada caso. Desse modo, após a configuração da rede é
importante verificar se ela se comporta conforme esperado. Para isso, é necessário injetar tráfego na
rede e monitorar seu comportamento. Este trabalho propõe o AIGA, um Ambiente Integrado de
Gerência para Redes em Malha Sem Fio IEEE 802.11s, que facilita o gerenciamento de WMNs de
produção bem como da utilização de testbeds para realização de experimentos.
Palavras-chave: Redes em Malha Sem Fio, WMN, IEEE 802.11s, Testbeds, gerenciamento.
AIGA: A Management Integrated Environmental for Wireless
Mesh Networks IEEE 802.11s
Author: Dhiego Fernandes Carvalho
Supervisor: Marcos César Madruga A. Pinheiro
ABSTRACT
A Wireless Mesh Network (WMN - Wireless Mesh Network) IEEE 802.11s standard to become
operational it is necessary to configure the parameters that meet the demands of its users, as
regards, for example, the frequency channels, the power antennas, IPs addresses, meshID,
topology, among others. This configuration can be done via a CLI (Command - Line Interface) or a
remote interface provided by the equipment manufacturer, both are not standardized and
homogeneous, like black boxes for the developers, a factor that hinders its operation and
standardization. The WMN, as a new standard, is still in the testing phase, and tests are necessary
to evaluate the performance of Path Discovery Protocol, as in this case of HWMP (Hybrid Wireless
Mesh Protocol), which still has many shortcomings. The configuration and test creation in a WMN
are not trivial and require a large workload. For these reasons this work presents the AIGA, a
Management Integrated Environment for WMN IEEE 802.11s, which aims to manage and perform
testbeds for analyzes of new Path Discovery Protocols in a WMN.
Keywords: Wireless Mesh Networks, IEEE 802.11s, Testbeds, Management.
Lista de Figuras
Figura 1: Comparação Entre Uma Rede IEEE 802.11 Infraestruturada (a) E Outra Em Malha (b). .22
Figura 2: HWMP No Modo Reativo..................................................................................................25
Figura 3: Anúncios De Quadros PREQ No Modo Pró-ativo Informando Quem É O Nó Raiz.........26
Figura 4: HWMP Trabalhando No Modo Pró-ativo...........................................................................26
Figura 5: Menu De Configuração Do Attitude Adjustment................................................................28
Figura 6: Estrutura Do AIGA.............................................................................................................37
Figura 7: Cenário Da Rede 802.11s....................................................................................................38
Figura 8: Configuração Da Rede IEEE 802.11s E Seus Atributos.....................................................40
Figura 9: Programas Que Compõem O Gerador De Tráfego.............................................................41
Figura 10: Geração De Tráfego..........................................................................................................43
Figura 11: Programa De Geração De Tráfego....................................................................................44
Figura 12: Monitoramento Dos Parâmetros De Rede........................................................................46
Figura 13: Monitoramento Dos Quadros Do Protocolo De Descoberta De Caminho Da Rede IEEE
802.11s................................................................................................................................................48
Figura 14: Diagrama De Sequência Dos Componentes Do Módulo De Gerenciamento SNMP.......50
Figura 15: Pacote De Configuração Do Protocolo De Geração De Tráfego......................................54
Figura 16: Pacote De Requisição Do Protocolo De Geração De Tráfego..........................................55
Figura 17: Pacote De Resposta Do Protocolo De Geração De Tráfego.............................................56
Figura 18: Diagrama De Sequência Do Protocolo De Geração De Tráfego......................................56
Figura 19: Configuração Das Máquinas Da WMN No AIGA...........................................................58
Figura 20: Configuração Da Topologia Da WMN No AIGA.............................................................60
Figura 21: Configuração De Tráfego Da WMN Do AIGA................................................................61
Figura 22: Coleta Das Informações Da WMN No AIGA..................................................................62
Figura 23: Testbed Com Os Doze Roteadores....................................................................................64
Figura 24: Topologia 3 X 4 Disparando Pacotes Do Roteador 9 Ao Roteador 4...............................65
Figura 25: Topologia 3 X 3 Disparando Pacotes Do Roteador 9 Ao Roteador 3...............................68
Figura 26: Topologia 2 X 2 Enviando Pacotes Do Roteador 5 Ao Roteador 2..................................70
Figura 27: Topologia Em Linha Enviando Pacotes Do Roteador 5 Ao Roteador 11.........................72
Figura 28: Comparação Dos Resultados Dos Bytes Transferidos Dos Pacotes TCP Entre As
Diferentes Topologias ........................................................................................................................74
Figura 29: Comparação Dos Resultados Dos Taxa De Transmissão Dos Pacotes TCP Entre As
Diferentes Topologias ........................................................................................................................75
Figura 30: Comparação Dos Resultados Dos Bytes Transferidos Pelos Pacotes UDP Entre As
Diferentes Topologias ........................................................................................................................76
Figura 31: Comparação Dos Resultados Das Taxas De Transmissão Dos Pacotes UDP Entre As
Diferentes Topologias.........................................................................................................................76
Figura 32: Comparação Dos Resultados Das Variações De Tráfego (jitter) Dos Pacotes UDP Entre
As Diferentes Topologias...................................................................................................................77
Figura 33: Comparação Dos Resultados Das Taxas De Perda Dos Pacotes Dos Pacotes UDP Entre
As Diferentes Topologias...................................................................................................................77
Índice De Tabelas
Tabela 1: Comparação Entre Os Trabalhos Pesquisados....................................................................34
Tabela 2: Objetos Da MIB Utilizados Pelo AIGA.............................................................................51
Tabela 3: Especificação Das Máquinas Utilizadas Nos Testes Da Rede 802.11s..............................63
Tabela 4: Configurações Dos Pacotes UDP.......................................................................................64
Tabela 5: Configurações Dos Pacotes TCP........................................................................................64
Tabela 6: Resultados Dos Tráfegos Gerados Pelos Pacotes TCP No Modo Reativo Na Topologia 3 X
4..........................................................................................................................................................66
Tabela 7: Resultados Dos Tráfegos Gerados Pelos Pacotes UDP No Modo Reativo Na Topologia 3
X 4......................................................................................................................................................66
Tabela 8: Resultados Dos Tráfegos Gerados Pelos Pacotes TCP No Modo Pró-ativo Na Topologia 3
X 4......................................................................................................................................................67
Tabela 9: Resultados Dos Tráfegos Gerados Pelos Pacotes UDP No Modo Pró-ativo Na Topologia 3
X 4......................................................................................................................................................67
Tabela 10: Resultados Dos Tráfegos Gerados Pelos Pacotes TCP No Modo Reativo Na Topologia 3
X 3......................................................................................................................................................68
Tabela 11: Resultados Dos Tráfegos Gerados Pelos Pacotes UDP No Modo Reativo Na Topologia 3
X 3......................................................................................................................................................68
Tabela 12: Resultados Dos Tráfegos Gerados Pelos Pacotes TCP No Modo Pró-ativo Na Topologia
3 X 3...................................................................................................................................................69
Tabela 13: Resultados Dos Tráfegos Gerados Pelos Pacotes UDP No Modo Pró-ativo Na Topologia
3 X 3...................................................................................................................................................69
Tabela 14: Resultados Dos Tráfegos Gerados Pelos Pacotes TCP No Modo Reativo Na Topologia 2
X 2......................................................................................................................................................70
Tabela 15: Resultados Dos Tráfegos Gerados Pelos Pacotes UDP No Modo Reativo Na Topologia 2
X 2......................................................................................................................................................70
Tabela 16: Resultados Dos Tráfegos Gerados Pelos Pacotes TCP No Modo Pró-ativo Na Topologia
2 X 2...................................................................................................................................................71
Tabela 17: Resultados Dos Tráfegos Gerados Pelos Pacotes UDP No Modo Pró-ativo Na Topologia
2 X 2...................................................................................................................................................71
Tabela 18: Resultados Dos Tráfegos Gerados Pelos Pacotes TCP No Modo Reativo Na Topologia
Em Linha............................................................................................................................................72
Tabela 19: Resultados Dos Tráfegos Gerados Pelos Pacotes UDP No Modo Reativo Na Topologia
Em Linha............................................................................................................................................72
Tabela 20: Resultados Dos Tráfegos Gerados Pelos Pacotes TCP No Modo Pró-ativo Na Topologia
Em Linha............................................................................................................................................73
Tabela 21: Resultados Dos Tráfegos Gerados Pelos Pacotes UDP No Modo Pró-ativo Na Topologia
Em Linha............................................................................................................................................73
Tabela 22: Média Dos Tráfegos Gerados Pelos Pacotes TCP Na Rede 802.11s................................74
Tabela 23: Média Dos Tráfegos Gerados Pelos Pacotes UDP Na Rede 802.11s...............................75
Sumário 1 Introdução.......................................................................................................................................15
1.1 Motivações E Justificativas....................................................................................................16
1.2 Objetivos.................................................................................................................................17
1.2.1 Objetivos Específicos......................................................................................................17
1.3 Organização Da Dissertação...................................................................................................18
2 Embasamento Teórico....................................................................................................................19
2.1 Gerência..................................................................................................................................19
2.2 IEEE 802.11s..........................................................................................................................20
2.2.1 Arquitetura Do 802.11s...................................................................................................21
2.2.2 Protocolo De Descoberta De Caminho...........................................................................22
2.2.2.1 Modo Reativo..........................................................................................................23 2.2.2.2 Modo Pró-ativo........................................................................................................24 2.2.2.3 Modo Híbrido..........................................................................................................25
2.3 OpenWRT...............................................................................................................................26
2.4 Testbed....................................................................................................................................27
2.4.1 Roofnet............................................................................................................................28
2.4.2 Testbed De WMN Baseado No Padrão IEEE 802.11......................................................28
2.4.3 IMesh..............................................................................................................................28
3 Trabalhos Relacionados..................................................................................................................29
3.1 Abaré.......................................................................................................................................29
3.2 Janus........................................................................................................................................29
3.3 Meshadmin..............................................................................................................................30
3.4 SCUBA...................................................................................................................................31
3.5 MeshFlow...............................................................................................................................31
3.6 MAYA.....................................................................................................................................32
3.7 OpenFlow................................................................................................................................32
3.8 Comparação Entre Os Trabalhos Pesquisados........................................................................33
4 Arquitetura Do AIGA.....................................................................................................................35
4.1 Módulo De Configuração.......................................................................................................37
4.2 Módulo De Geração De Tráfego.............................................................................................40
4.3 Módulo De Monitoramento....................................................................................................44
4.3.1 Parâmetros De Desempenho De Rede............................................................................44
4.3.2 Parâmetros Da Rede IEEE 802.11s.................................................................................45
5 Visão Geral Da Implementação Do AIGA.....................................................................................48
5.1 Net-SNMP..............................................................................................................................48
5.1.1 Extensão Da MIB............................................................................................................49
5.2 Protocolo De Geração De Tráfego..........................................................................................52
5.2.1 Mensagem De Configuração...........................................................................................53
5.2.2 Mensagem De Requisição...............................................................................................54
5.2.3 Mensagem De Resposta..................................................................................................54
5.3 Interface Gráfica.....................................................................................................................56
5.3.1 Configuração Das Máquinas...........................................................................................56
5.3.2 Configuração Da Topologia............................................................................................58
5.3.3 Configuração De Tráfegos..............................................................................................59
5.3.4 Coleta Das Informações..................................................................................................60
6 Avaliação........................................................................................................................................62
6.1 Topologia Em Grade 3 X 4.....................................................................................................64
6.1.1 Modo Reativo..................................................................................................................65
6.1.2 Modo Pró-ativo...............................................................................................................65
6.2 Topologia Em Grade 3 X 3.....................................................................................................66
6.2.1 Modo Reativo..................................................................................................................67
6.2.2 Modo Pró-ativo...............................................................................................................68
6.3 Topologia Em Grade 2 X 2.....................................................................................................68
6.3.1 Modo Reativo..................................................................................................................69
6.3.2 Modo Pró-ativo...............................................................................................................70
6.4 Topologia Em Linha...............................................................................................................70
6.4.1 Modo Reativo..................................................................................................................71
6.4.2 Modo Pró-ativo...............................................................................................................72
6.5 Comparações Dos Resultados.................................................................................................72
7 Conclusões......................................................................................................................................78
Lista de Siglas
AP – Access Point (Ponto de Acesso)
AODV – Ad hoc On Demand Distance Vector (Vetor de Distância por Demanda Ad Hoc)
CLI – Command-line Interface (Interface de Linha de Comando)
DO - Destination Only Flag (Bandeira de Somente o Destino)
GUI – Graphical User Interface (Interface Gráfica de Usuário).
FCAPS - Fault, Configuration, Accounting, Performance and Security (Falha, Configuração,
Contabilidade, Desempenho e Segurança).
HWMP – Hybrid Wireless Mesh Protocol (Protocolo de Malha Sem Fio Híbrido)
ISO – International Organization for Standardization (Organização Internacional para
Padronização)
IEEE – Institute of Electrical and Electronics Engineers (Instituto de Engenheiros Eletricistas e
Eletrônicos)
IP – Internet Protocol (Protocolo de Internet)
LAN – Local Area Network (Rede de Área Local)
MAP – Mesh Access Point (Ponto de Acesso Mesh)
MAC – Media Access Control (Controle de Acesso ao Meio)
MIB – Management Information Base (Base de Gerência de Informação)
MP – Mesh Point (Ponto Mesh)
MPA – Mesh Point Access (Acesso do Ponto Mesh)
MPP – Mesh Portal Point (Portal do Ponto Mesh)
OSI - Open Systems Interconnection (Interconexão de Sistemas Abertos)
PERR – Path Error (Erro de Caminho)
RM – Root Mesh (Mesh Raiz)
PREQ – Path Request (Solicitação de Caminho)
PREP – Path Reply (Resposta de Caminho)
RF - Reply and Forward Flag (Bandeira de Resposta e Encaminhamento)
RRAN - Root Annoucenement (Anúncio do Raiz)
SNMP – Simple Network Management Protocol (Protocolo de Gerência de Redes Simples)
SNMPv1 - Simple Network Management Protocol version 1 (Protocolo de Gerência de Redes
Simples versão 1)
SNMPv3 - Simple Network Management Protocol version 3 (Protocolo de Gerência de Redes
Simples versão 3)
STA – Station (Estação)
TCP – Transport Control Protocol (Protocolo de Controle de Transporte)
UDP – User Datagram Protocol (Protocolo de Datagrama de Usuário)
WMN – Wireless Mesh Network (Rede em Malha Sem Fio)
WFA – Wi-Fi Alliance (Aliança Wi-Fi)
1 Introdução
Tradicionalmente as redes sem fio baseadas no padrão IEEE 802.11 eram utilizadas no modo
de operação infra-estruturado ou no modo adhoc. Há alguns anos o IEEE definiu mais um modo de
operação que suporta a criação de Wireless Mesh Networks (WMN). Esse modo, especificado pelo
IEEE 802.11s [IEEE Std 802.11 2012], tem sido adotado por várias indústrias e fabricantes de
equipamentos, desde que foi inicialmente proposto, em março 2006. O processo de padronização foi
concluído recentemente, no ano de 2012, e muito da sua estrutura está sob análise em busca de
possíveis melhorias.
Uma vez que as WMNs são redes de múltiplos saltos, que criam um único domínio de nível
dois (camada de enlace do modelo OSI/ISO), é necessário que exista um protocolo para descoberta
das rotas referentes aos endereços MAC. As rotas são armazenadas em tabelas, que utilizam
endereços MAC ao invés de endereços IP, de modo que tais protocolos são chamados de protocolos
de Descoberta de Caminho, ao invés de protocolos de roteamento, enfatizando a diferença para o
roteamento IP, referente a camada três do modelo OSI/ISO. Embora o IEEE 802.11s defina um
protocolo padrão de descoberta de caminho, chamado HWMP [Bahr 2006], que inclusive já passou
por várias melhorias [Bahr 2008], ele permite a utilização de qualquer outro protocolo. Apesar do
HWMP ser um protocolo que apresenta desempenho satisfatório em determinadas situações, ele
possui algumas limitações, como, por exemplo, a baixa escalibidade, que restringe a quantidade de
nós que podem participar da rede. Isso ocorre, porque em ambos os modos de operação do HWMP,
reativo e pró-ativo, os nós enviam seus quadros de descoberta de caminho em difusão.
Adicionalmente, no modo pró-ativo há um congestionamento no nó raiz, diminuindo e muito o
desempenho da rede [Wang e Lim 2007]. Tais fatos têm levado à comunidade científica a
desenvolver diversos outros protocolos de descoberta de caminho para redes IEEE 802.11s.
No desenvolvimento de novos Protocolos de Descoberta de Caminho para redes IEEE
802.11s, a melhor forma de analisar seus respectivos desempenhos de modo a indicar qual é o mais
eficiente, é analisá-los com diferentes cenários de rede. Porém, para cada cenário a ser analisado
existe um elevado número de parâmetros a serem configurados, como por exemplo, canais de
frequência, potência do sinal, topologia da rede (quem são os vizinhos de um nó). Além desses, para
cada protocolo de Descoberta de Caminho existem diversos outros parâmetros a serem
configurados. No HWMP (Hybrid Wireless Mesh Network), por exemplo, pode-se definir se haverá
ou não um nó raiz, definir se nós intermediários podem responder requisições de rotas, definir
15
tempo de respostas para mensagens, entre outras opções. Após essas configurações, é necessário
gerar tráfego para poder analisar o comportamento de rede com o protocolo utilizado. Novamente
existe uma grande possibilidade de combinações, como por exemplo, tipo dos pacotes (ex: tcp, udp
etc), tamanho dos pacotes, intervalo de tempo entre o envio dos pacotes, origem e destino dos
pacotes, entre outros. Por fim, é importante definir quais parâmetros são necessários medir (vazão
da rede, perda de pacotes, atraso, número de quadros em difusão etc) e coletar essas informações.
1.1 Motivações e Justificativas
Além do seu uso para fins de pesquisas pela comunidade acadêmica, as WMN IEEE 802.11s
vem ganhando cada vez mais espaço como redes de produção nas organizações. De qualquer modo,
em ambos os casos, a tarefa de configuração dessas redes para que entrem em operação e o
gerenciamento posterior para mantê-las operacionais são tarefas complexas. Isso ocorre porque
essas redes possuem uma arquitetura bastatnte flexível. Ou seja, como a exelente característica de
auto-organização e tolerância a falhas inerentes dessas redes decorrem principalmete de não existir
um modelo rígido de estrutura que a rede deve seguir, isso significa também que não existe uma
configuração ideal que atende a todas as situações. Desse modo, é preciso identificar para cada caso
qual a configuração para o conjunto possível de parâmetros que proporciona o melhor desempenho
e confiabilidade para a rede.
Conforme citado na seção anterior, o número de parâmetros que devem ser monitorados e
controlados é muito elevado, abrangendo os canais de frequência, potência das antenas, endereços
IPs, máscara de rede, meshID, topologias (quem são os vizinhos de cada nó), parâmetros do
protocolo de descoberta de caminho (no caso do HWMP, por exemplo, se a rede trabalha no modo
reativo ou protivo), entre outros. A falha na configuração adequada desses parâmetros pode levar a
diversos problemas, entre os quais podemos citar: a utilização de canais de frequência já utilizados
por outras redes coexistindo no mesmo espaço físico pode degradar bastante o desempenho; a
utilização de uma potência muito alta no radio pode elevar o nível de interferência com outros nós;
uma configuração de topologia inadequada pode levar a segmentação da rede deixando alguns nós
isolados (o mesmo pode ocorrer se a potência do rádio for muito baixa); uma definição de
parâmetros do protocolo de encaminhamento de quadros inadequada pode aumetar o número de
mensagens em broadcast transmitidas, bem como elevar o tempo para descoberta das rotas.
Tipicamente a configuração dos equipamentos pode ser feita através de uma Command Line
Interface (CLI) ou por uma interface remota oferecida pelo fabricante do equipamento, como é o
caso de uma interface web. Em ambos os casos, essas interfaces não são padronizadas, dificultando
16
a configuração e o monitoramento da rede, uma vez que uma grande rede normalmente é composta
por vários equipamentos de fabricantes diferentes.
Naturalmente a forma para evitar esses problemas é utilizar um protocolo padronizado. Por
isso o SNMP [Stallings 1998] tem sido empregado em vários trabalhos sobre gerenciamento de
redes sem fio, conforme poderá ser visto no capítulo 3 desse texto. Entretanto, na MIB IEEE 802.11
[CISCO MIB 2014], diversos parâmetros específicos das redes WMN IEEE 802.11s não são
suportados, principalmente os específicos do protocolo de descoberta de caminho HWMP.
Embora não faça parte da tarefa de gerenciamento da rede proriamente dita, sempre que se
realiza a configuração de uma rede, seja ela cabeada ou sem fio, se realizam também testes para
verificar a efetividade da configuração feita. Esses testes tipicamente incluem a geração de algum
tipo de tráfego na rede e a coleta de informações a respeito do comportamento da rede.
Pelo que foi exposto pode-se observar a necessidade de uma solução de gerenciamento de
WMNs que utilize SNMP e permita a configuração dos parâmetros específicos do IEEE 802.11s,
bem como a realização de testes para validar a efetividade da configuração realizada.
1.2 Objetivos
O objetivo geral deste trabalho é propor, desenvolver, implementar e avaliar um Ambiente
Integrado de Gerência para Redes IEEE 802.11s, que integra as tarefas de configuração da rede,
geração de tráfego e coleta de dados, permitindo assim, que se possa verificar se uma dada
configuração de rede realizada produz o resultado esperado. Para isso, um ponto chave desse
trabalho é a expansão da MIB IEEE 802.11 para suportar um maior número de atributos
relacionados as redes em malha sem fio.
Embora possa ser utilizado para analisar diversos aspectos de uma rede em malha sem fio, o
ambiente proposto, que se chama AIGA (Ambiente Integrado de Gerência para Redes em Malha
sem fio IEEE 802.11s), tem como foco de interesse principal permitir a análise dos protocolos de
descoberta de caminho.
1.2.1 Objetivos Específicos
Para atingir o objetivo geral desse trabalho, os seguintes objetivos específicos precisam ser
alcançados:
• Configuração da Rede: criação de um módulo de configuração das máquinas da rede
IEEE 802.11s com os parâmetros de rede necessários (meshID, potência das antenas,
canal de configuração, endereço IP das interfaces sem fio etc) para deixar a WMN
17
operacional;
• Geração de tráfego: criação de um módulo que permita a definição dos tráfegos a
serem gerados para a realização dos testes da rede IEEE 802.11s;
• Monitoramento (coleta de resultados): criação de um módulo que tem a função de
coletar informações decorrentes dos tráfegos gerados na WMN que são utilizados nos
testes. Essas informações incluem tanto dados de desempenho (atraso, vazão etc), bem
como informações sobre o comportamento do protocolo de encaminhamento de quadros
(número de mensagens do protocolo que foram transmitidas, por exemplo).
Sem o ambiente proposto, a configuração da rede IEEE 802.11s e criação dos testes seriam
tarefas trabalhosas, inflexíveis e lentas, pois cada uma dessas etapas (configuração, geração de
tráfego e monitoramento) requer uma grande carga de trabalho. Desse modo, os principais
benefícios do AIGA são: configuração da rede para torná-la operacional e criação de testes,
podendo-se modificar as configurações de rede e os testes (variando-se, por exemplo, o tipo de
tráfego gerado, ou topologia da rede) com o mínimo de esforço.
1.3 Organização da Dissertação
Este trabalho é dividido do seguinte modo: o capítulo 2 mostra o embasamento teórico
sobre os temas relacionados ao assunto abordado nessa dissertação; o capítulo 3 apresenta os
trabalhos relacionados sobre gerência em redes IEEE 802.11s que serviram de base para esta
dissertação; o capítulo 4 apresenta a arquitetura do ambiente proposto; o capítulo 5 descreve sobre
a implementação e as tecnologias utilizadas; o capítulo 6 a avaliação do AIGA; o capítulo 7
apresenta as conclusões sobre o trabalho e os novos recursos que podem ser incorporados em
versões futuras.
18
2 Embasamento Teórico
Alguns conhecimentos prévios sobre os assuntos que serão abordados por este trabalho são
necessários para uma melhor compreensão do mesmo. Neste capítulo serão abordados alguns destes
importantes temas.
2.1 Gerência
Para garantir a correta e eficiente operação de uma rede é necessário que seu comportamento
seja monitorado e controlado através de softwares e protocolos de gerenciamento. Quanto mais
heterogênas e dinâmicas forem as redes, como pode ser o caso, por exemplo, das WMNs, maior é a
necessidade de gerenciamento.
Gerenciar uma rede consiste, resumidamente, em: obter informações da rede, tratá-las para
diagnosticar possíveis falhas e encaminhar as soluções dessas falhas [Telecom 2014]. Para realizar
tais tarefas programas de gerência devem ser incorporados a todos os dispositivos de rede que
estejam em operação. A gerência consiste em praticamente em três entidades:
• Estações de gerência: têm a função de gerenciar os dispositivos gerenciados;
• Dispositivos gerenciados: são os equipamentos de rede que mantêm a rede em operação
e que são gerenciados pela estação de gerência;
• Protocolo de gerência: é responsável pela troca de informação entre as estações de
gerência e os dispositivos gerenciados;
De acordo com a ISO [ISO/IEC 7498-4 1989], a gerência pode ser classificada por cinco
áreas funcionais: gerência de falha, configuração, contabilidade, desempenho e segurança. Essas
cinco áreas são conhecida como o modelo FCAPS (Fault, Configuration, Accounting, Performance
and Security):
• Gerência de Falha: cada dispositivo de rede deve ser monitorado individualmente para
garantir seu perfeito funcionamento. Quando acontece uma falha é importante saber
exatamente onde ela ocorreu, ou está ocorrendo, isolar a falha, reconfigurar a rede para
que funcione sem o dispositivo defeituoso, e consertar o dispositivo de rede com
problemas;
• Gerência de Configuração: está relacionado as tarefas de manutenção, adição e
atualização, referentes aos equipamentos e aos canais de comunicação.
• Gerência de Contabilização: Corresponde ao registro e controle do uso dos recursos da
rede por parte dos usuários;
19
• Gerência de Desempenho: consiste em monitorar os dispositivos de rede para
determinar o comportamento da rede durante sua operação. O desempenho da rede está
focado em alguns parâmetros de rede (latência, atraso, variação do atraso, perda de
pacotes, erro, taxa de transmissão, etc). Coletar tais informações ajuda na descoberta de
situações anormais na rede e a evitar problemas antes mesmo que eles aconteçam
(gerenciamento pró-ativo).
• Gerência de Segurança: provê facilidades para proteger os recursos da rede e as
informações dos usuários, devendo ser implantada de acordo com a política de
segurança da organização.
2.2 IEEE 802.11s
A portabilidade e a interoperabilidade são grandes virtudes do mundo moderno, pois quanto
mais fácil a comunicação entre dispositivos de diferentes tipos, melhor é a disseminação da
informação. As Redes Sem Fio no padrão IEEE 802.11, estão bastante difundidas, principalmente
em LANs, devido a facilidade de instalação, portabilidade, interoperabilidade, mobilidade, custo e
suporte. Apesar de sua gama de facilidades, ainda há muitos desafios a serem superados, de modo
que apesar de já existirem vários adendos ao padrão IEEE 802.11 (a, b, g, n, etc) novos recursos
continuam sendo incorporados, como por exemplo, segurança, mobilidade, taxa de transmissão,
entre outros, como é o caso das WMNs, definidas no adendo IEEE 802.11s .
Nas Redes Locais Sem Fio IEEE 802.11 convencionais, tipicamente é utilizada uma
infraestrutura cabeada para interconectar todos os APs. O padrão IEEE 802.11s define que a
comunicação entre as máquinas (sendo APs ou não) deve ser sem fio, formando Pares de Conexão,
eliminando a necessidade de uma rede cabeada, e formando uma WMN. A Figura 1 ilustra esses
dois modos de operação.
20
As WMNs têm recebido grande atenção nos últimos anos, de modo que muitas empresas
passaram a utilizar esse modelo ou comercializam produtos, por exemplo, roteadores e APs,
relacionados a ele. Muitas delas têm se juntado em uma força tarefa para convergir as WMNs e
incentivar a sua adoção em escala mundial. Em outubro de 2006, a Aliança Wi-Fi (WFA – Wi-Fi
Alliance) estabeleceu uma força tarefa para as redes em malha baseadas no IEEE 802.11,
encarregada em criar um documento de Marketing, uma especificação de uma certificação e um
plano de testes.
A primeira versão do IEEE 802.11s foi lançada em Março de 2006, propondo um padrão
inovador que estabelecia a descoberta e encaminhamento de quadros em vários saltos, uma vez que,
até então esse modelo não era suportado. Apenas em 2012 o IEEE conseguiu concluir o processo de
padronização do 802.11s incorporando-o ao IEEE 802.11.
2.2.1 Arquitetura do 802.11s
De acordo com a especificação do IEEE 802.11s, os componentes da arquitetura da WMN
são:
Cliente (STA): São os equipamentos que não suportam o modo mesh, mas entram na
rede através dos Pontos de Acesso Mesh (MAP).
Nó Mesh (MP): são os nós que formam o núcleo do 802.11s, uma vez que é através
deles que os quadros Mesh são encaminhos na da rede.
Ponto de Acesso Mesh (MAP): é um MP que também é um Ponto de Acesso,
incorporando as duas funcionalidades: os STAs se associam ao MAP e os quadros do
IEEE 802.11s são encaminhados por ele. Ou seja, converte quadros mesh em não mesh,
e vice-versa.
21
Figura 1: Comparação entre uma rede IEEE 802.11 infraestruturada (a) e outra em malha (b)
Portal Mesh (MPP): é um MP que também é um gateway, ou seja, um ponto de
interconexão de duas redes diferentes, por exemplo, a rede Local em Malha Sem Fio e
uma rede cabeada. Os demais Nós da Rede sabem quem é o portal através de anúncios
de quadros GANN (Gate Annoucenement) ou de quadros RANN (Root Annoucenement).
Nó Raiz (RM): é um tipo de Nó Mesh que é utilizado apenas no modo pró-ativo do
protocolo de encaminhamento de quadros. Os demais Nós Mesh sabem de sua existência
através de anúncios de quadros PREQ no modo pró-ativo, ou de anúncios de quadros
RANN que informam e constroem um caminho ao Nó Raiz.
No IEEE 802.11s cada par de conexão é chamado de Peer Link. O mecanismo de descoberta
dos vizinhos de um nó é praticamente o mesmo do padrão IEEE 802.11, havendo uma varredura da
rede de modo ativo ou passivo. Além disso, os beacons e probes, quadros de sinalização definidos
pelo padrão IEEE 802.11, são estendidos para incluírem novos campos referentes à WMN.
Nas Redes Sem Fio infraestruturadas (IEEE 802.11) é estabelecido um SSID para permitir a
identificação do AP de cada rede sem fio separadamente. Cada AP pode ter um SSID diferente, ou
um grupo de APs podem ter o mesmo SSID quando estão conectados em uma mesma rede. No
padrão IEEE 802.11s há também um identificador (ID), chamado de Mesh ID, semelhante ao SSID,
pois cada WMN precisa ser identificada separadamente.
2.2.2 Protocolo de Descoberta de Caminho
Para que um nó da WMN consiga se comunicar com outro que não seja seu vizinho (não
possui um Par de Conexão diretamente), é necessário que seja identificado o caminho até ele. Desse
modo, faz necessário um Protocolo de Descoberta de Caminho para descobrir e selecionar a rota
para cada nó da rede.
O IEEE 802.11s define como protocolo padrão de descoberta de caminho o Hybrid Wireless
Mesh Protocol (HWMP), e como métrica padrão para escolha do melhor caminho o Air Link Metric
(Métrica de Ligação Aérea). Embora o HWMP seja o protocolo padrão, o IEEE 802.11s suporta a
utilização de outros protocolos de encaminhamento de quadros. O HWMP pode ser configurado
para trabalhar em dois modos:
Modo reativo: funcionalidade desse modo sempre está disponível, independente se o nó
raiz está configurado na rede Mesh ou não. Nesse modo a rota para um dado destino é
descoberta apenas no momento em que se precisa enviar um quadro para ele;
Modo proativo: neste modo um Nó Mesh deve ser configurado como nó raiz e se
22
anuncia na rede periodicamente. Para isso ele pode utilizar mensagens PREQ de modo
pró-ativo ou mensagens RANN que serão detalhados a seguir;
O protocolo é chamado de híbrido porque pode trabalhar nos dois modos. Os tipos de
mensagens do HWMP são:
Path Request (PREQ): é o quadro enviado para descobrir o caminho para um dado
endereço MAC. São enviados em difusão por toda rede no modo reativo. No modo
proativo tem a função de difundir a rota do nó Raiz para todos os nós da WMN;
Path Reply (PREP): é o quadro de resposta do destino. É enviado em resposta pelo MP
de destino quando o quadro PREQ chega a ele socilitando um caminho. Quando o modo
proativo é utilizado, os nós mesh que receberam um PREQ do nó raiz, respondem com
um PREP com o valor especial;
Path Error (PERR): é o quadro que indica erro no caminho. Quadro usado para
anunciar que um ou mais destinos não estão acessíveis. O anúncio é feito a todas as
fontes de tráfico que tem um caminho ativo ao destino;
Root Annoucenement (RANN): é o quadro que informa quem é o nó raiz (root) da rede.
Ele é enviado por difusão por toda a rede para que todos os nós saibam quem é a raiz da
rede IEEE 802.11s. Este tipo de quadro é usado apenas no modo pró-ativo. Como
normalmente o nó raiz é o mesmo que o portal da rede, para não ter que enviar quadros
GANN e RAAN ao mesmo tempo, o RANN é setado com seu flag em 1, indicando que
também é o portal, de modo a minimizar o número de quadros que são enviados na rede;
Gate Annoucenement (GANN): é o quadro usado para anunciar a presença de um Portal
Mesh (ponto de interconexão entre duas redes distintas, que normalmente também é o
Nó Raiz). Os Anúncios de Portal permitem que os Nós Mesh construam um caminho até
a ele;
A seguir serão apresentados os modos de funcionamento do HWMP.
2.2.2.1 Modo Reativo
No modo reativo as rotas só são criadas quando se precisa transmitir algo para um dado nó.
Supondo que na rede ilustrada pela Figura 2, o MP3 (Nó Mesh 3) precise enviar pacotes para o
MPA7 (Ponto de Acesso Mesh 7), é necessário primeiro descobrir o caminho para ele. Neste caso,
sendo utilizado o modo reativo o MP3 envia um mensagem PREQ, que é propagada em difusão por
toda rede até chegar ao destino, o MPA7, que por sua vez irá enviar uma mensagem PREP de
resposta para a origem (MP3). A medida que o PREQ é encaminhado na rede, os nós intermediários
23
criam uma rota para o nó que a originou (MP3). É por isso que o PREP pode ser transmitido para o
nó que originou o PREQ sem usar broadcast. Do mesmo modo, a medida que o PREP é transmitido
para o nó de origem, uma rota é criada para o nó que originou o PREP (MP7), sempre apontando
para o nó que acabou de reencaminhá-lo. O HWMP faz cache dessas rotas, mas periodicamente
envia as mensagens novamente para verificar se existe uma nova rota melhor que a atual.
2.2.2.2 Modo pró-ativo
No modo pró-ativo, antes de qualquer transmissão, todos os nós da Rede Local em Malha
Sem Fio devem saber quem é o nó raiz da rede mesh. Existem duas formas para quep os nós da rede
saibam quem é o raiz:
Envio de mensagens PREQ no modo pró-ativo: as mensagens PREQ pró-ativas são
enviadas pelo nó raiz com seu flag pró-ativo configurado em 1 (um) a todos os nós da
rede em um intervalo de tempo específico (dot11MeshRootInterval). O PREQ pró-ativo
pode ser configurado com um o flag PREP pró-ativo em 1 (um) ou 0 (zero). No primeiro
caso o nó mesh contrói uma rota reversa para o nó raiz e no segundo é configurada uma
rota reversa ao nó raiz apenas se o nó mesh tiver dados a enviar ao nó raiz.
Envio de mensagens RANN: as mensagens RANN são enviadas pelo nó raiz a todos os
nós da rede em um intervalo de tempo específico (dot11MeshHWMPrannInterval). Os
nós que receberam as mensagens RANN respondem com um PREQ (flag pró-ativo
setado em 0) ao raiz. Ele responde de volta com um PREP (flag pró-ativo setado em 0) e
desta forma é estabelecido por todos os nós da rede um caminho direto e reverso ao nó
Raiz.
Na Figura 3 é mostrado um exemplo de como são feito os anúncios de quem é o nó Raiz
24
Figura 2: HWMP no modo reativo
através do PREQ no modo pró-ativo. As transmissões dos PREQs no modo pró-ativo são feitas
depois de um intervalo de tempo (em milisegundos) definido pelo administrador da rede.
A Figura 4 mostra o exemplo de uma rede mesh trabalhando no modo pró-ativo.
Normalmente o raiz é o próprio portal mesh (MPP1), pois este nó da WMN é quem trabalha
diretamente na borda da rede e conecta outros tipos diferentes de redes. Todos os nós da rede sabem
quem é o raiz, através dos anúncios RANN ou PREQ pró-ativos. Quando MP3 quer enviar dados
ao MP7, por exemplo um tráfego TCP, todos os pacotes passam pelo nó raiz da rede.
2.2.2.3 Modo Híbrido
O HWMP pode trabalhar no modo reativo e proativo concorrentemente, por tal motivo o
25
Figura 4: HWMP trabalhando no modo pró-ativo
Figura 3: Anúncios de quadros PREQ no modo pró-ativo informando quem é o nó raiz.
HWMP é chamado de protocolo híbrido. Este tipo de operação permite que a comunicação comece
imediatamente, encaminhando todo o tráfego para o nó raiz (através de todo mecanismo descrito na
sessão 2.1.2.2), enquanto o modo reativo descobre o caminho mais curto entre os dois nós mesh
(sessão 2.1.2.1). Depois de descoberto o melhor caminho, o tráfego é enviado por ele.
2.3 OpenWRT
As máquinas que fazem parte do IEEE 802.11s, descritas nas figuras 2, 3 e 4, necessitam de
um sistema operacional para uma WMN estar operacional. Nessa dissertação foi utilizado nas
máquinas da WMN o OpenWrt que é uma distribuição do Linux usada em sistemas embarcados,
tipicamente roteadores sem fio. Ao invés de criar um único e estático firmware, o OpenWrt provê
um sistema de arquivos configurável com um pacote de gerenciamento para customizar o seu
sistema operacional embarcado. Qualquer pessoa está apta a inserir e remover pacotes no seu
sistema de acordo com a sua necessidade. Para os desenvolvedores, o OpenWrt é um framework
para construir uma aplicação sem ter que desenvolver um firmware completo em volta dele, e para
os usuários ele significa a capacidade de ter uma completa customização do seu sistema
[OPENWRT 2013].
No caso do desenvolvimento deste trabalho, a versão do OpenWRT utilizada foi o attitude
adjustment (12.09, usa versão 3.3 do kernel do Linux), lançado em maio de 2013. Ele é uma
plataforma customizável, podendo ser compilado para diversos tipos de arquitetura de hardware.
Isso é denominado de “Sistema Alvo” na configuração do OpenWrt. Como nesse projeto foram
utilizados roteadores Mikrotik 433AH, a arquitetura alvo selecionada no OpenWrt foi
AR71xx/AR7240/AR913x, conforme mostrado na Figura 5.
Esse modelo customizável do OpenWrt permitiu que a implementação dos agentes SNMP e
do módulo gerador de tráfego fossem implantados no sistema operacional dos roteadores sem
maiores problemas.
A fase inicial na geração de um sistema OpenWrt consiste, portanto, em selecionar os
programas desejados, drivers, o “Sistema Alvo”, entre outras opções, conforme demostrado na
Figura 5. Depois de definidas essas informações, é necessário compilar para gerar a imagem de um
sistema operacional. Essa imagem pode ser instalada na memória flash do roteador ou ser
armazenada em um servidor TFTP de modo a ser obtida via rede e carregada para a memória RAM
dos roteadores no momento de sua inicialização. Durante o desenvolvimento do AIGA utilizou-se a
segundo opção por ser mais flexível e ágil, uma vez que permite que sejam feitas alterações no
sistema gerado sem requerer a instalação manual da nova versão em cada roteador.
26
O Openwrt é um sistema Linux e oferece uma interface de comandos ao usuário. Tal fato é
muito importante pois facilita no processo de desenvolvimento e testes dos sistemas implantados
nos equipamentos, como é o caso do AIGA.
2.4 Testbed
Embora o ambiente proposto nesse trabalho possa ser utilizado para realizar o
gerenciamento de qualquer WMN baseada no padrão IEEE 802.11s, é importante ressaltar que
durante a análise das tecnologias e protocolos de rede é muito comum se fazer uso de redes
implantadas em ambientes controlados, as quais são chamadas de testbeds. Testbed é uma
plataforma de experimentação de grandes projetos em desenvolvimento. Ele permite o teste de
ferramentas e novas plataformas em um determinado cenário no mundo real. Este tipo de
experimento é usado como prova que uma certa tecnologia funciona em local supervisionado e que
os testes são controlados em um ambiente computacional específico.
Um testbed pode incluir software, hardware e componentes de rede. No desenvolvimento de
um software, o hardware e os componentes de redes são configurados para que uma aplicação seja
projetada a um determinado tipo de teste. Pode-se dizer que um testbed é um ambiente de teste
controlado.
No caso do desenvolvimento de um novo Protocolo de Descoberta de Caminho para o IEEE
802.11s, um testbed pode ser criado para analisá-lo. Tipicamente os roteadores seriam posicionados
em um ambiente controlado, como, por exemplo, em uma sala.
Existem diversos testbeds usados em WMNs, alguns dos quais serão descritos a seguir.
27
Figura 5: Menu de Configuração do Attitude Adjustment
2.4.1 Roofnet
Testbed criado pela Computer Science and Artificial Intelligence Laboratory do
Massachusetts Intitute of Tecnology (MIT) [Bicket et al. 2003], tem como objetivo descobrir o
caminho mais rápido de um ponto A ao ponto B dentro de uma rede mesh e monitorar
constantemente os caminhos de rede. Foram disponibilizados quarenta nós mesh em apartamentos
espalhos em mais de oito quilômetros quadrados de área urbana, sendo que o percurso mais longo
entre eles não pode ultrapassar quatro saltos. Através do roofnet, procurou-se fornecer acesso à
Internet aos estudantes da universidade. A distância, perda de sinal e perda de pacotes eram medidos
por um programa executando dentro dos nós mesh.
2.4.2 Testbed de WMN baseado no padrão IEEE 802.11
Testbed desenvolvido para validar a perfomance de uma WMN em um ambiente real [Song
et at. 2009]. O testbed proposto foi implantado em uma sala fechada com três roteadores e dois
clientes mesh, onde os roteadores têm o mínimo de mobilidade. Serviços multimídia tais como: voz,
vídeo e texto também foram usados para confirmar as funções dos componentes do testbed
(roteadores e clientes).
2.4.3 iMesh
O iMesh é uma infraestrutura de Rede em Malha baseada no modo IEEE 802.11b, antes da
criação do 802.11s [Navda et al. 2005]. Nela foi feita uma implementação de testbed com seis
Access Points (APs) e um dipositível móvel que analisa a transição de uma célula para outra dentro
da rede (handoff) e também o desempenho dos fluxos TCP e UDP quando há frequentes handoffs.
28
3 Trabalhos Relacionados
Esse capítulo tem como objetivo apresentar os trabalhos encontrados na literatura que
abordam os assuntos mencionados no capítulo anterior (redes IEEE 802.11s, OpenWRT e testbeds)
e que possuem objetivos semelhantes ao trabalho proposto. Entender os principais objetivos de cada
um desses trabalhos, e analisar as arquiteturas propostas ajudou na especificação e modelagem do
AIGA.
3.1 Abaré
[Pinheiro et al. 2010] propõem o Abaré que tem o objetivo de implantar e manter uma
WMN em grande escala, sendo dividido em três camadas::
Administração: o agente gerente e o agente instalador se encontram nesta camada. É
responsável pela comunicação direta entre os roteadores e o administrador da rede;
Núcleo: é onde se encontra o Abaré Core API e outros módulos que compõem o núcleo
da ferramenta. Aqui estão localizados os módulos responsáveis por enviar, armazenar,
processar e coletar as informações transmitidas.
Roteador: o Middrrouter está localizado nesta camada. Ele é responsável pelos
programas instalados no roteador.
O framework utiliza scripts para coletar dados em cada roteador. A configuração dos
roteadores está na mudança de endereços IPs, criação de scripts que executarão as tarefas que serão
processadas em cada roteador e a mudança do firmware de cada máquina. A comunicação entre os
gerentes e agentes são realizadas através da linguagem XML que serão executadas pelo
Middrrouter. O administrador da rede tem uma visualização de toda rede através de um servidor
Web que está localizado no Abare Core API.
Apesar do Abaré ser feito para WMNs, ele não é baseado no padrão IEEE 802.11s.
3.2 Janus
[Riggio e Miorandi 2007] propõem o framework JANUS, uma ferramenta de gerência para
redes IEEE 802.11s. A arquitetura da ferramenta, que é muito parecida com a do SNMP, possui os
seguintes componentes:
Mesh Node: é um nó Mesh que participa do WMN e roda o Janus Agent.
Janus Agent: é um programa que roda nos dispostivos gerenciados. Ele tem o
conhecimento geral da rede e fornece as informações de gerencimamento para o Janus
29
Client, mantendo o controle de vários aspectos do dispositivo gerenciado. O Janus
Agent fica ouvindo as conexões TCP do Nó do WMN.
Mesh Knowledge Base: é o banco de dados do dispositivo gerenciado. Todas as
informações que podem ser localizadas e rastreadas sobre o Nó Mesh estão aqui.
Janus Client: é o programa executando em cada máquina. Pode ser considerado uma
versão distribuída do Mesh Knowledge Base. Responsável pelo polling e o recebimento
das traps enviadas pelo Janus Agent. Serve também para mudar as variáveis gravadas
dentro de cada dispositivo gerenciado.
Apesar do JANUS usar uma arquitetura idêntica ao SNMP, ele não utiliza esse protocolo.
Cada Junus Client consulta o Janus Agent periodicamente na porta 1167 para obter os objetos
gerenciados. Quandos os objetos gerenciados são entregues ao Janus Client, então o cliente grava os
objetos gerenciados no Mesh Knowledge Base. Um testbed em ambiente fechado foi realizado com
a ferramenta usando seis Nós (computadores) Sem Fio e um servidor web (utilizado para monitorar
todo o tráfego da rede e plotar as informações em um gráfico). O tráfego gerado no testbed foi
analisado por um outro programa separado da ferramenta.
3.3 Meshadmin
[Valle e Muchaluat-Saade 2011] propõem o MeshAdmin, framework criado dentro da UFF.
O meshAdmin é uma ferramenta de gerência de Redes em Malha Sem Fio utilizando o protocolo
SNMP para sua implementação. A estrutura do Meshadmin possui cinco módulos principais:
Módulo de coleta de dados: realiza a coleta dos dados nos nós e enlaces entre eles. Em
cada Nó Mesh foi adicionado um programa agente (Mini SNMP) que é utilizado para
coleta das informações solicitadas pelo gerente da rede.
Módulos de armazenamento de dados: As informações obtidas pelo módulo de coleta
são armazenadas no módulo de armazenamento de dados. Este módulo recebe as
informações adicionadas pelo administrador da rede através do Painel de Configuração e
armazena as mensagens geradas pelo módulo de alerta.
Painel de configuração da ferramenta: é o painel utilizado pelo administrador para
inserir os nós da rede Mesh e outros parâmetros de configuração. Este painel é dividido
em quatro partes: Autenticação, Configuração, Diagnóstico e Monitoramento.
Módulo de Alerta: tem como objetivo alertar o administrador sobre qualquer problema
que esteja acontecendo na rede. Os alertas são divididos em: crítico, aviso e informação.
Módulo de Exibição: para uma melhor visualização da ferramenta, o MeshAdmin
30
oferece uma interface web desenvolvida utilizando o Django [Ref]. A tela inicial da
ferramenta é dividida em três partes: visualização da topologia, informação de redes e
nós e mensagens de alerta. O módulo de exibição tem como objetivo gerenciar a rede em
tempo real.
A ferramenta foi testada em ambiente aberto na própria UFF com o intuito de verificar o
impacto do overhead gerado pelo tráfego de monitoramento injetado pelo módulo de Coleta. Nos
testes foram elaborados cinco cenários com 5, 7, 9, 10 e 12 nós, e foram realizadas 30 medições
com intervalos de 20 minutos cada. Todos os testes realizados obtiveram resultados satisfatórios.
3.4 SCUBA
[Jardosh et al.] proprõem o SCUBA, uma ferramenta de monitoramento das WMNs. Possui
um banco de dados e uma plataforma de visualização de toda a WMN feita em Java. O diagnóstico
da rede é obtida através das métricas que são dividas em três tipos de contextos:
Contexto do Roteador: consiste nas métricas de Vazão dos pacotes TCP e no RTT
(Round-Trip Time) dos pacotes UDP. Essas métricas têm o objetivo de medir a qualidade
entre os roteadores e o gateway de rede.
Contexto de Enlace: o Contador de Transmissões Esperadas é a única métrica neste
contexto. Determina a qualidade dos enlaces entre os nós do WMN.
Contexto do Cliente: números de clientes associados a cada roteador, a porcentagem de
cada canal utilizado por cliente, RSSI e o volume de interferências externas são as
quatros métricas utilizadas neste contexto. São as métricas do ponto de vista do cliente
porque descrevem as conexões de cada um deles e o tráfego gerado dentro do WMN.
Todas essas métricas podem ser vistas em dois tipos de visões dos nós da rede: Planar e
Hiperbólica. As duas possuem suas específicas vantagens e desvantagens. A ferramenta foi testada
em ambiente fechado (UCSB MeshNet), possuindo 14 roteadores 802.11 a/g e um gateway. O
objetivo do teste era verificar como o SCUBA indetificava um simples problema na rede MeshNet.
O resultado foi satisfatório, mas se verificou um overhead computacional e nas transmissões dos
pacotes na rede.
3.5 MeshFlow
[Huang et al. 2007] propõem o Meshflow. Ele é uma proposta de estrutura para análise de
Redes em Malha Sem Fio, que pode ser implementada em diferentes formas. Todo o escopo é
concentrado no registro das informações coletadas na rede, que pode ser um pacote contendo
31
algumas propriedades do tráfego que passa por cada nó da WMN. O framework é dividido em cinco
partes:
Definição do registro: defini-se o que se deve gerenciar.
Criação do registro: cria-se o registro para ser trafegado na rede.
Gravação do registro: registros são gravados nas máquinas da rede.
Exportação do registro: registro é exportado até a máquina de gerenciamento dedicada.
Análise do registro: depois de exportado, os registros são gravados na máquina de
gerenciamento e submetida a uma análise completa da rede.
Definido as cincos partes do MeshFlow, a implementação fica a cargo do desenvolvedor que
deve denificar as peculiaridades da rede para colocar em prática a estrutura da ferramenta proposta.
3.6 MAYA
[Manzoni et al. 2007] propõem o MAYA, Uma Ferramenta de Gerência para WMN. A
arquitetura do MAYA é dividida em três partes:
• Nó Servidor: a interface web e o banco de dados do MAYA são instalados neste nível.
• Sistema de Distribuição da Rede Mesh: a rede distribuída é instalada neste nível,
composta dos Roteadores Sem Fio usando uma aproximação de uma rede adhoc.
• Clientes: são os equipamentos que se associam aos roteadores da rede.
A implementação do MAYA é dividida em uma GUI, utilizando linguagens web, e um
módulo de instalação de configuração, sendo feito por em linguagem C. O servidor usa tanto
mensagens UDP e conexões SSH para configurar os roteadores. O protocolo utilizado nos testbeds é
o AODV no OpenWRT.
3.7 OpenFlow
[McKeown et al 2008] propõem o OpenFlow, uma forma de novos pesquisadores
experimentar novos protocolos em redes que são usadas no dia a dia. O OpenFlow é baseado em
switches e roteadores com tabelas de fluxo internas e uma interface padronizada para adicionar e
remover entradas das tabelas de fluxo. O OpenFlow é constituído de três partes principais:
• Tabela de Fluxo: com uma associação para cada entrada de fluxo para dizer aos
switches e roteadores OpenFlow como processar o fluxo.
• Canal Seguro: conecta os switches e roteadores OpenFlow ao processo de controle
remoto (chamado de controlador), permitindo comandos e pacotes sejam enviados entre
32
o controlador e os roteadores e switches do OpenFlow.
• Protocolo OpenFlow: que provê forma aberta e padronizada para o controlador
comunicar com os switches e roteadores OpenFlow.
Muitos testbeds foram implementados com o OpenFlow, um exemplo é o testbed realizado
na Universidade de StandFord utilizando NetFPGA em redes cabeadas [Covington et al 2008].
Outro exemplo em Redes Sem Fio, especificamente em WMN, é o de KUAMesh [Dely et al 2011].
3.8 Comparação entre os trabalhos pesquisados
As características de cada um dos trabalhos encontrados na literatura estão resumidas na
Tabela 1.
Tabela 1: Comparação entre os trabalhos pesquisados
Trabalhos /Característic
as
Monitoramento
Configuração SNMP Possui MIBProprietária
Interface Gráfica
Abaré Sim Sim. Mudafirmware dosroteadores,
endereços IPs ecriação de scripts.
Não (Scripts) Não, possuibanco de dados
proprietário
Sim (WebService – Apache)
MeshAdmin Sim Sim. Adicionanós mesh econfigura asmáquinas.
Sim - v3 Sim – Partedele
Sim (WebService – API JavaScriptdo Google Maps)
SCUBA Sim Não Não Não, possui umbanco de dados
proprietário
Sim. Plataforma feita em Java.
MeshFlow Sim Pode configurarou não
Pode usar ounão
Pode ter ou não Pode ter ou não
JANUS Sim Não Não Não, possuibanco de dados
proprietário.
Sim (Webservice- Geoplot)
MAYA Sim Sim. Através deScripts
Não Não Sim. Interface Web
OpenFlow Não. Limitadoas
informaçõessobre osfluxos.
Sim. Usado paratestar novosprotocolos.
Não. Usa opróprio
protocoloOpenFlow
Não Não
Os trabalhos pesquisados não se encaixam completamente no perfil dessa dissertação. O
foco do OpenFlow é mais definir como ocorre o encaminhamento dos dados na rede do que
propriamente especificar parâmetros de configuração dos equipamentos e protocolos, como por
33
exemplo, os parâmetros específicos do HWMP. Os demais trabalhos não incluem recursos
relacionados a testes nem suportam a configuração de diversos atributos específicos das redes IEEE
802.11s.
Conclui-se que nenhum dos trabalhos pesquisados na literatura atendem aos objetivos dessa
dissertação que são gerenciar uma WMN com suporte aos parâmetros específicos do IEEE 802.11s,
incorporando funções que facilitem analisar a efetividade das configurações realizadas.
34
4 Arquitetura do AIGA
No capítulo anterior foram mostrados os trabalhos pesquisados na literatura que se
relacionam com os objetivos propostos deste trabalho. Conforme foi discutido, nenhum deles
atendia completamente as necessidades desta dissertação, pois o gerenciamento de uma WMN,
incluindo o suporte a realização de testes para analisar o correta operação da rede, requer a
realização das seguintes tarefas:
Configuração: configurar as máquinas (roteadores) e os parâmetros dos protocolo
Descoberta de Caminho para atenderem a diferentes cenários de testes (ex: diferentes
topologias, diferentes tráfegos etc);
Geração de tráfego: é necessário para a geração de testes, pois diferentes tipos de
tráfegos são necessários para medir o desempenho do protocolo de Descoberta de
Caminho;
Monitoramento: é a coleta das informações referentes ao desempenho dos tráfegos
gerados de acordo com a configuração de rede e do protocolo de Descoberta de Caminho
utilizados.
Conforme citado no capítulo 1, este trabalho propõe um ambiente chamado AIGA, que
integra a realização dessas três tarefas acima mencionadas, podendo ser utilizado para gerenciar
WMNs em cenários reais (de produção) ou em ambientes controlados (testbeds). Embora o AIGA
possa ser utilizada para analisar diversos aspectos de uma WMN seu foco principal é permitir a
análise dos protocolos de Decoberta de Caminho do IEEE 802.11s.
No gereciamento, pode-se optar, por exemplo, configurar uma rede com um determinado
meshID, endereços IPs em uma determinada faixa, utilizar um canal de frequência em comum para
todas as interfaces sem fio das máquinas da WMN, configurar quem serão os seus Pares de
Conexões etc. Também no gerenciamento é importante configurar os parâmetros do Protocolo de
Descoberta de Caminho, como, por exemplo, no caso do HWMP, alterar se o protocolo irá trabalhar
no modo reativo ou pró-ativo. Após reconfigurações na rede, principalmente quando testbeds são
utilizados para analisar o desempenho dos protocolos de Descoberta de Caminho, é necessário gerar
tráfego na rede para em seguida medir seu desempenho de acordo com os parâmetros configurados.
A estrutura do AIGA é baseada em quatros entidades principais:
Gerente: é o programa responsável pelo gerenciamento da WMN. É a entidade central
da rede, controlada por um administrador da rede.
Agente: programa instalado nos dispositivos de rede que responde as requisições SNMP
35
(o SNMP é utilizado por ser o protocolo mais comum em gerência de redes) do gerente
para a configuração e solicitação de objetos na MIB. Ele controla todas as mensagens
SNMP do software gerente que chegam até ele.
MIB: é a estrutura de armazenamento hirárquica em árvore que armazena as
informações sobre os objetos que serão acessados e configurados pelo gerente da rede.
Software de geração de tráfego: é o software responsável pela geração de tráfego. Sua
comunicação com o gerente é feita através de um protocolo próprio, desenvolvido nesse
trabalho.
A Figura 6 mostra os componentes do AIGA e o relacionamento entre suas quatro entidades
principais.
O AIGA faz uso do SNMP para as tarefas de configuração e monitoramento, bem como de
um programa adicional a ser executado nas máquinas que é encarregado da geração de tráfego.
A Figura 7 mostra o gerente da rede utilizando o AIGA para gerenciar e realizar um testbed
em uma WMN de acordo com o cenário desejado para cada experimento, onde a topologia desse
experimento consiste de uma rede em grade, com cada máquina estabelecendo conexões apenas
com seus vizinhos imediatos na horizontal e vertical (independente do layout físico do testbed).
36
Figura 6: Estrutura do AIGA
O AIGA é dividido em três módulos que realizam as tarefas necessárias para a realização de
da gerência e testbeds para avaliar o desempenho dos protocolos de Descoberta de Caminho. A
junção das especificações desses módulos, que são feitos pelo gerente da rede, caracteriza um
experimento, ou seja, um testbed. O restante desse capítulo apresenta cada um desses módulos em
detalhes.
4.1 Módulo de Configuração
O primeiro passo para gerenciar uma WMN é configurar a rede de acordo com os
parâmetros de rede e do protocolo de Descoberta de Caminho. O módulo de configuração tem o
objetivo de configurar as máquinas da rede (meshID, Pares de Conexão, canal de frequência etc) e
configurar o protocolo de Descoberta de Caminho utilizado, neste caso o HWMP.
De modo que se possa realizar a configuração desejada, as máquinas possuem atributos de
configuração que podem ser alterados pelo gerente da rede, sendo divididos nas categorias de
Configuração IP e Configuração Wi-Fi. Esses atributos são apresentados a seguir:
Configuração IP
Endereço IP: endereço IP da interface IEEE 802.11s;
Máscara de Rede: máscara de rede da Interface IEEE 802.11s;
Configuração Wi-Fi (IEEE 802.11)
Placa ativa: ativa ou desativa a placa sem fio da rede IEEE 802.11s;
Endereço MAC: identifica e altera o endereço MAC da placa de rede sem fio da
37
Figura 7: Cenário da Rede 802.11s
rede IEEE 802.11s;
Potência das antenas: modifica a potência em dBm das antena da rede IEEE
802.11s da máquina;
Canal de cada placa Wi-Fi: canal de frequência que a interface sem fio da máquina
irá trabalhar;
Mesh (802.11s)
Mesh ID: é o SSID Mesh utilizado para associação dos pares de conexão da
interface IEEE 802.11s da máquina;
Topologia Mesh: identifica quem são os pares de conexão da interface IEEE
802.11s da máquina;
Deletar Par de Conexão: elimina determinado par de conexão da interface IEEE
802.11s da máquina;
Liberar Novos Pares de Conexão: identifica se a interface IEEE 802.11s da
máquina pode ou não estabelecer novos pares de conexão. OBS: Esse atributo de
configuração é necessário, pois se um determinado par de conexão for eliminado,
ele poderá voltar a ser associado à máquina caso a outra máquina da rede IEEE
802.11s também esteja liberada para novos pares de conexão.
Encaminhar quadros Mesh: identifica se a interface IEEE 802.11s da máquina
pode ou não encaminhar quadros IEEE 802.11s na rede;
Algoritmo de Descoberta de caminho (HWMP);
HWMP
Targe Only Flag (TO): se definido em 1 (um), somente o nó de destino
poderá responder com um PREP;
Reply and Forward Flag (RF): se setado em 0 (zero), o Nó Mesh
intermediário não poderá encaminhar os PREQ, tal mecanismo acontece
quando o TO estiver com o valor 0.
Nó Raiz: Identifica se a rede está trabalhando em modo pró-ativo e qual
modo é o nó raiz. Existem três modos de operação para anunciar quem é
a raiz da rede IEEE 802.11s: quadros RANN, quadros PREQs pró-ativo
sem PREPs pró-ativos e quadros PREQs pró-ativos com PREPs pró-
ativos.
38
Portal: identifica quem é o portal da rede (ponto de interconexão entre
uma rede IEEE 802.11s e outra que não seja).
Recomenda-se que cada máquina da WMN usada em testbed possua também uma placa de
rede ethernet, configurada com um endereço IP (provavelmente através de um servidor DHCP) para
ser a interface utilizada para conexão do modulo de configuração do AIGA à maquina da rede.
Optou-se por utilizar esse método de configuração, normalmente chamado de “fora de banda”
(offband), para que o tráfego do AIGA não interfira no tráfego da WMN, bem como para evitar o
risco de se perder a conectividade com os equipamentos; fato que poderia ocorrer se as próprias
interfaces IEEE 802.11s fossem utilizadas para esse fim.
O AIGA permite que cada configuração, tanto de rede e protocolo de Descoberta de
Caminho, seja salva em um arquivo, para que possa ser utilizada futuramente. Isso evita que todos
os passos da etapa de configuração precisam ser repetidos para a criação de cada testbed,
simplificando bastante essa tarefa.
Conforme foi dito no início dessa seção, a configuração é o passo inicial para gerenciar uma
WMN de acordo com os parâmetros de rede e do protocolo de Descoberta de Caminho. A Figura 8
mostra um exemplo de como uma rede IEEE 802.11s foi configurada; os traços entre as máquinas
(roteadores) representam as associações sem fio entre eles, ou seja, os pares de conexão (Peer
Links). Foram estabelecidos endereços IPs para a interface IEEE 802.11s de cada máquina, na faixa
entre 192.168.1.1 a 192.168.1.12 com máscara vinte e quatro (255.255.255.0). Todas as interfaces
IEEE 802.11s de cada máquina tem o meshID com o nome “teste”, trabalhando no canal 11 (onze) e
com uma potência de 40 dBm. Todos os passos do AIGA de geração de testes são realizados entre o
programa gerência darede e o programa agente instalado nas máquinas da WMN via protocolo de
39
Figura 8: Configuração da rede IEEE 802.11s e seus atributos
Gerência SNMP.
Depois de configurada a rede, é importante gerar tráfego para verificar se ela se comporta
conforme esperad. Para isso, deve-se injetar pacotes na rede para que se possa medir o desempenho
da mesma e do protocolo de Descoberta de Caminho, conforme descrito na próxima seção.
4.2 Módulo de Geração de Tráfego
A pós a configuração da rede, o segundo passo é a definição do tráfego a ser gerado na rede.
Essa definição é feita na estação de gerência e permite que se especifique o tráfego a ser gerado por
cada máquina da rede individualmente. Uma vez realizada a especificação do tráfego, essas
informações precisam ser transmitidas para as máquinas da WMN, pois são eles que de fato fazem a
geração do tráfego. Isso é feito utilizando um protocolo de comunicação próprio, definido
exclusivamente para esta finalidade, e que será detalhado posteriormente. Uma vez que cada
equipamento receba a especificação do tráfego, eles iniciam a geração dos pacotes.
A Figura 9 apresenta os programas que compõem o módulo de geração de tráfego. O TC-
Server (Traffic Control Server) é um programa que deve executar em cada máquina da WMN,
enquanto o TC-Client (Traffic Control Client) faz parte do software em execução na máquina de
gerência. A função do TC-Server é receber do TC-Client a especificação do tráfego a ser gerado,
interpretar essas mensagens, e chamar um segundo programa para gerar os pacotes, passando para
ele os parâmetros adequados. Não houve necessidade de desenvolver esse segundo programa no
AIGA, pois optou-se por utilizar um programa bastante conhecido e já amplamente utilizado pela
comunidade de redes, chamado iperf [IPERF 2013].
O TC-Client representa a gerência, enquanto que o TC-Server, o Iperf Server UDP e o Iperf
Server TCP representam a geração de tráfego na máquina conforme demostrado na figura 6 no
início desse capítulo.
40
Figura 9: Programas que compõem o gerador de tráfego
O Iperf [Iperf 2013] é um programa utilizado para testar a largura de banda, variação do
atraso (jitter), perda de pacotes e taxa de transmissão do pacotes da rede. Para realizar a medição
desses parâmetros, o iperf injeta pacotes TCP ou UDP com diferentes atributos em uma determinada
rede. Como utiliza o modelo cliente servidor, o Iperf requer que exista um servidor executando na
máquina de destino de acordo com o protocolo (TCP ou UDP) utilizado pelo cliente. Desse modo,
cada máquina da WMN deve executar duas instâncias do Iperf em modo servidor (uma para TCP e
outra para UDP), conforme mostrado na Figura 9. Embora nem sempre sejam utilizadas em todas as
máquinas, pois isso dependerá do testbed a ser realizado, essas instâncias são necessárias para que
qualquer máquina da WMN possa ser alvo de um fluxo de dados. Naturalmente, cada máquina que
for gerar algum tráfego (fluxo) para outra, executará temporariamente uma instância do Iperf em
modo cliente.
O tipo de tráfego a ser gerado pelo Iperf, deve inicialmente ser especificado na estação de
gerência e essa especificação deve ser transferida pelo TC-Client ao TC-Server de cada máquina
envolvida, utilizando o protocolo de geração de tráfego que será especificado no capítulo 5.
Lembrando que vários fluxos podem ser definidos para cada equipamento, a seguir são mostrados
os parâmetros que podem ser configurados para cada fluxo TCP e UDP.
• Fluxo TCP
• IP de origem: IP da máquina de origem que irá injetar de pacotes na rede;
• IP de destino: IP da máquina de destino que receberá os pacotes enviados pela
máquina de origem;
• ID do fluxo: cada solicitação de tráfego terá um identificador para cada conexão
TCP injetada pela máquina de origem;
• Janela de Transmissão: é o tamanho do buffer da máquina de destino que
armazenará os pacotes TCP que chegarão a ele;
• Tempo de Transmissão: é a quantidade de tempo em segundos que o programa na
máquina de origem (iperf) injetará pacotes TCP na rede;
• Tamanho do Pacote: é o tamanho do buffer para ler e escrever. O iperf trabalha em
escrever um vetor por um “tamanho” de bytes em uma quantidade de vezes
• MSS (Maximum Segment Size – Tamanho Máximo de Segmento): é o tamanho do
maior segmento TCP que o iperf pode transmitir na rede.
• Fluxo UDP
• IP de origem: IP da máquina de origem que irá iniciar a injeção de pacotes na rede;
• IP de destino: IP da máquina de destino que receberá os pacotes enviados pela
41
máquina de origem;
• ID do fluxo: cada solicitação de tráfego terá um identificador para cada transmissão
UDP injetada pela máquina de origem;
• Banda de Transmissão: é a banda passante que será fixada para a transmissão dos
pacotes UDP.
• Tempo de Transmissão: é a quantidade de tempo em segundos que o programa na
máquina de origem (iperf) injetará pacotes UDP na rede;
• Tamanho do Pacote: tamanho do pacote UDP que será injetado na rede;
É importante ressaltar que as máquinas suportam a geração simultânea de tráfego, ou seja,
um mesmo roteador pode gerar pacotes para dois roteadores, ou mais, simultaneamente. Por isso, é
utilizado o parâmetro “ID do fluxo”, de modo que se possa identificar unicamente cada fluxo de
dados enviado por uma dada máquina. Portanto, para cada máquina deve-se utilizar um ID diferente
para cada fluxo configurado. Esse atributo será utilizado pelo módulo de monitoramento.
A Figura 10 mostra uma visão macro do processo de geração de tráfego para enviar um
fluxo de dados, cujo identificador será 20, da máquina 1 para a máquina 12 com os seguintes
parâmetros:
• Identificador: vinte (20);
• Tempo: vinte segundos;
• Janela: 10 Kilobytes;
• Tamanho: 1 Kilobyte;
• Tamanho Máximo de Segmento (MSS): 1,5 Kilobytes;
Evidentemente, a rota criada da origem ao destino a ser utilizada para encaminhamento dos
42
Figura 10: Geração de Tráfego
pacotes não é definida pelo administrador da rede, mas criada automaticamente pelo Protocolo de
Descoberta de Caminho em uso na rede IEEE 802.11s.
A Figura 11 detalha o exemplo mostrado na Figura 9, enfatizando porém a comunicação
entre os programas envolvidos. Inicialmente o administrador da rede utiliza o TC-Client para
especificar e transferir a definição de tráfego (um fluxo) para o TC-Server que está executando no
roteador 1 da WMN. Essa máquina é a máquina que consta como origem do fluxo, e essa
mensagem é transferida utilizando o protocolo de geração de tráfego que será detalhado no capítulo
5 (passo 1). O TC-Server gera uma chamada para executar o Iperf em modo cliente passando para
ele os parâmetros necessários para gerar o tráfego desejado (passo 2). O Iperf envia pacotes para o
servidor TCP executando no roteador 12 (passo 3). Durante a geração dos pacotes no passo 3, o
Iperf também calcula alguns parâmetros relacionados ao desempenho da transmissão. Como essas
informações são calculadas pelo Iperf Servidor, elas são enviadas para o Iperf cliente do roteador 1
e são armazenadas pelo TC-Server (passo 4) desse roteador.
O modelo de geração de tráfego utilizado no AIGA permite que se criem diversos padrões de
tráfego para serem aplicados sobre uma mesma configuração de rede, de modo a analisar como ela
se comporta sob cada um deles, bem como de aplicar o mesmo padrão de tráfego sobre
configurações de rede diferentes, permitindo identificar qual delas melhor suporta esse tipo de
tráfego.
Depois de configurada a rede IEEE 802.11s, e realizada a geração do tráfego de dados, deve-
se analisar as informações coletadas por cada máquina durante esse período para que se tenha uma
visão do comportamento da rede.
43
Figura 11: Programa de Geração de Tráfego
4.3 Módulo de Monitoramento
Para entender o comportamento da rede durante a transmissão do tráfego gerado diversas
informações precisam ser coletadas. No AIGA, esse conjunto de informações é fixo e será descrito
posteriormente nessa seção. Dessa forma, o papel do módulo de monitoramento é realizar de fato a
coleta das informações e transmiti-las para a estação de gerência.
O administrador da rede, através da estação de gerência, solicita as informações coletadas
por cada equipamento de modo que possa analisá-las de forma centralizada e ter, assim, uma visão
global do comportamento da rede.
Existem dois tipos de informações coletadas durante a fase de geração de tráfego, que são:
Parâmetros de Desempenho de rede: sendo divididos em taxa de transferência,
largura de banda, variação do retador e taxa de erro de pacotes;
Parâmetros da Rede IEEE 802.11s: números de quadros do protocolo de Descoberta
de Caminho; na versão atual do AIGA são analisadas apenas mensagens (PREQ, PREP,
PERR, e RANN) do protocolo HWMP.
4.3.1 Parâmetros de Desempenho de Rede
Os parâmetros de desempenho de rede referem-se às informações relacionadas a própria
transmissão dos pacotes gerados, que são:
Largura de Banda: é a taxa de pacotes enviados por segundo que sai da máquina de
origem à máquina de destino;
Taxa de Transferência: quantidade de pacotes que foram enviados da origem ao destino
em um determinado período de tempo;
Variação do Atraso (jitter): é a variação do atraso dos pacotes que chegam ao destino
(calculado apenas na transferência de pacotes UDP).
Taxa de erro: número de pacotes que não chegaram à maquina de destino (calculado
apenas na transferência de pacotes UDP);
A observação desses parâmetros têm como objetivo permitir analisar, por exemplo, como
um determinado protocolo de Descoberta de Caminho, e a configuração da rede, suportam a
transmissão de determinado tipo de tráfego. Também ajuda a identificar a configuração do
protocolo de Descoberta de Caminho que fornece o melhor resultado para algum desses parâmetros,
como por exemplo, para obter uma menor variação de atraso.
Deve-se observar que essas informações não são armazenadas na MIB, mas sim no próprio
44
programa que controla a geração de tráfego, ou seja, no TC-Server. Assim sendo, a solicitação
dessas informações também não é feita via SNMP, mas sim pelo protocolo de geração de tráfego
desenvolvido, e já citado anteriormente.
A Figura 12 mostra como ocorre a obtenção dos parâmetros de desempenho medidos por
uma máquina da rede, usando como exemplo o caso das Figuras 10 e 11, onde, durante a fase de
geração de tráfego, foi solicitado à máquina 1 que enviasse pacotes TCP à máquina 12, sendo
utilizado o identificador 20 para esse fluxo. Desse modo, a máquina de gerência solicita à máquina
12 que envie as informações a respeito da largura de banda e da taxa de transferência obtidas pelos
pacotes TCP durante a transmissão do fluxo com ID de fluxo 20. O gerente informa o identificador
do fluxo desejado para que o equipamento possa identificar, entre os muitos fluxos que ele pode ter
transmitido, qual deles o gerente esta requisitando. Nesse exemplo, esse identificador possui o valor
20.
4.3.2 Parâmetros da Rede IEEE 802.11s
Os parâmetros da rede IEEE 802.11s monitorados pelo AIGA referem-se ao número total de
quadros transmitidos pelo protocolo de Descoberta de Caminho. Embora atualmente o AIGA
suporte apenas a contabilização dos quadros do HWMP, futuramente outras informações podem ser
incorporadas, como por exemplo, o tempo gasto para descoberta das rotas, bem como o suporte a
outros protocolos de descoberta de caminho. O AIGA contabiliza o número de mensagens HWMP
transmitidas dos seguintes tipos:
PREQ (enviado em difusão): quadro de Requisição de Caminho;
PREP: quadro de Reposta de Caminho;
45
Figura 12: Monitoramento dos Parâmetros de Rede
RANN (enviado em difusão): quadro que informa quem é o raiz (root) da rede;
PERR (enviado em difusão): quadro de erro de caminho;
O monitoramento dessas mensagens HWMP é feito pelos agentes instalados nas máquinas.
Como se sabe, agentes são responsáveis por monitorar as informações especificadas na MIB e
responder as requisições que lhes são enviadas via SNMP.
Os dois principais objetivos para realizar a contabilização dessas mensagens são: i) analisar
como a mudança de topologia e a alternância do tipo de tráfego injetado afetam o comportamento
do protocolo de Descoberta de Caminho; ii) identificar como o protocolo de Descoberta de
Caminho afeta o desempenho da rede, por exemplo, identificando uma sobrecarga devido ao envio
de um número muito alto de mensagens HWMP em difusão.
Embora a contabilização dessas mensagens pudesse ser feita utilizando um programa no
espaço de usuário que empregasse uma biblioteca como a libpacap [Tcpdump 2014], optou-se por
desenvolver um módulo de kernel para essa finalidade. Essa decisão objetivou reduzir a sobrecarga
no equipamento um vez que reduz o número de chaveamentos entre o espaço de kernel e o espaço
de usuário. Para simplificar a obtenção dessa informação pelo agente, de modo que ele ão precise se
comunicar com o kernel, as informações sobre a quantidade de cada tipo de mensagem HWMP
transmitida são disponibilizadas usando o sistema de arquivos virtual sysfs. Desse modo, foi criado
nesse sistema de arquivos um pseudo arquivo para cada tipo de mensagem monitorada, e cada
arquivo possui o nome da mensagem ao qual se refere. Desse modo, tudo que o agente precisa fazer
para obter, por exemplo, o número de quadros PREQ transmitidos, é ler o arquivo
/sys/kernel/AIGA/preq.
Conforme pode ser observado pela Figura 13, a estação de gerência utiliza o SNMP para
obter de cada máquina da WMN a quantidade de cada mensagem HWMP que ele
transmitiu/retransmitiu. Em seguida todas as respostas são somadas para conhecer o total de
mensagens de cada tipo que trafegaram na rede.
46
47
Figura 13: Monitoramento dos quadros do Protocolo de Descoberta de Caminho da rede IEEE802.11s
5 Visão Geral da Implementação do AIGA
Neste capítulo são apresentados os aspectos principais referentes ao desenvolvimento e
implementação do AIGA. Como foi visto anteriormente, uma parte do AIGA executa na estação de
gerenciamento e outra nas máquinas da WMN (chamados aqui de roteadores). Por isso, iniciar-se
esse capítulo apresentando brevemente a API utilizada para a implementação do SNMP.
5.1 Net-SNMP
O Net-SNMP [Net-SNMP 2013] é uma API para ser utilizada com o protocolo SNMP, tendo
como objetivo principal permitir o desenvolvimento e implementação de ferramentas de
configuração e monitoramento de dispositivos de redes. Ele está licenciada sob a licença GPL
(General Public License) e a versão utilizada na implementação dessa dissertação foi a 5.7.2. A API
do NET-SNMP é utilizada neste trabalho para transmitir as mensagens SNMP entre as máquinas da
rede IEEE 802.11s e o programa na máquina de gerência. Uma solução de gerenciamento que
utilize a API do Net-SNMP, é composta pelos seguintes programas:
Agente Mestre: daemon principal (snmpd) que implementa o servidor SNMP. Embora
seja esse agente que receba as mensagens do gerente e envie as respostas para o mesmo,
não é ele que manipula a MIB. Para ler ou configurar os objetos da MIB esse agente
mestre chama os subAgentes.
subAgentes: são pequenos programas instalados nos equipamentos gerenciados que são
responsáveis de fato pela configuração e monitoramento dos recursos. Os subAgentes se
comunicam diretamente com o programa mestre (snmpd) para responderem as
solicitações recebidas do gerente. Para a instalação dos subAgentes nos roteadores, foi
necessário fazer compilação cruzada do código para a arquitetura MIPS, que é a
arquitetura do Mikrotik 433AH.
Programa de gerência: é o componente final da arquitetura do SNMP. Funciona como
um cliente em uma comunicação cliente/servidor. Realiza requisições aos dispositivos
gerenciados e recebe as informações dos atributos solicitados.
48
A Figura 14 mostra o diagrama de sequência entre estação de gerência, o agente mestre e o
SubAgente. Quando o gerente solicita, por exemplo, um determinado objeto da MIB, é o agente
mestre que recebe essa mensagem SNMP. Após interpretar essa mensagem, ele chama o SubAgente
responsável pelo OID (indicando o atributo da MIB) referenciado na mensagem. O SubAgente por
sua vez faz o acesso requerido à MIB. Caso seja uma mensagem de GET, por exemplo, depois de
obter as informações do atributo, o subAgente as envia para o Agente Mestre, que por sua vez
transmite a mensagem SNMP de resposta para a Estação de Gerência.
5.1.1 Extensão da MIB
Embora o IEEE 802.11 defina uma MIB que possui um conjunto de objetos SNMP que
podem ser gerenciados, diversos atributos considerados importantes pelo AIGA não são suportados
nessa MIB. Desse modo, o AIGA criou uma extensão da MIB padrão especificando diversos novos
objetos gerenciados e desenvolveu os respectivos subagentes para implementar esses objetos.
A Tabela 2 apresenta os objetos da MIB que são utilizados no AIGA. As atributos já
definidos pelo IEEE 802.11 são indicados com o valor “MIB padrão” na coluna MIB. Já os novos
atributos criados pelo AIGA possuem o valor “MIB Proprietária” nessa coluna. É importante
ressaltar que, embora sejam informados os valores dos OIDs (Object IDentifier) de cada novo
atributo criado pelo AIGA, esses identificadores não foram obtidos da entidade responsável
(IANA), de modo que precisarão ser alterados posteriormente.
49
Figura 14: Diagrama de Sequência dos componentes do módulo de gerenciamento SNMP
Tabela 2: Objetos da MIB utilizados pelo AIGA
Nome Descrição Sintaxe Acesso MIB OID
netIPAddress Atributo que define oIP da interface 802.11sda máquina.
STRING read-write MIBProprietária
1.3.6.1.4.1.2022.2.1.5.0
netSubnetMask Atributo que define aMáscara de Rede dainterface 802.11s damáquina.
STRING read-write MIBProprietária
1.3.6.1.4.1.2022.2.1.5.1
netIPDNSAddress Atributo que define oIP do Servidor DNSda interface 802.11sda máquina.
STRING read-write MIBProprietária
1.3.6.1.4.1.2022.2.1.5.2
dot11MACAddress Atributo que indica oendereço MAC únicoassociado à interface802.11s da máquina.
STRING read-write MIB Padrão 1.3.6.1.4.1.2022.2.1.5.11
dot11IfChannel Atributo que indica ocanal de comunicaçãoque a interface802.11s da máquina
INTEGER read-write MIBProprietária
1.3.6.1.4.1.2022.2.1.5.4
Dot11IfActiveInterface Atributo que indica sea interface 802.11s damáquina está ativa ounão.
INTEGER0 – Interfacedesativada1 – Interfaceativada
read-write MIBProprietária
1.3.6.1.4.1.2022.2.1.5.12
dot11IfAntennaPower Atributo que indica apotência da AntenaSem Fio da máquina.
INTEGER read-write MIBProprietária
1.3,.6.1.4.1.2022.2.1.5.9
dot11MeshID Atributo que associaum Mesh ID àinterface 802.11s damáquina.
STRING read-write MIB Padrão 1.3,.6.1.4.1.2022.2.1.5.3
dot11MeshNumberOfPeerings
Atributo que indica oNúmero de Pares deConexão associados àinterface 802.11s damáquina.
UNSIGNED32 read-write MIB Padrão Não implementado(Trabalho posterior)
dot11MeshAcceptingAdditionalPeerings
Atributo que infromase a interface 802.11sda máquina estáaceitando novos Paresde Conexão ou não.
INTEGER 0 – Não aceita 1 – Aceita novosPeer Links
read-write MIB Padrão 1.3,.6.1.4.1.2022.2.1.5.5
dot11MeshMACPeering
Atributo usado parainformar quais são osroteadores que fazemPares de Conexãocom a interface802.11s da máquina.
MACADDRESS read-write MIBPropietária
1.3.6.1.4.1.2022.2.1.5.18
dot11MeshDelPeering Atributo usado paradeletar umdeterminado Par deConexão associado à
STRING read-write MIBProprietária
1.3.6.1.4.1.2022.2.1.5.13
50
interface 802.11s damáquina, informandoo seu endereço MAC.
dot11MeshHWMPrannInterval
Atributo usado paradefinir o intervalomínimo que ainterface 802.11senvie outro quadroRANN, quando odot11MeshHWMProotMode estiver com ovalor 4 (quatro).
INTEGERem milisegundos
read-write MIB Padrão 1.3.6.1.4.1.2022.2.1.5.10
dot11MeshHWMPRootInterval
Atributo usado paradefinir o intervalomínimo que ainterface 802.11senvie outro quadroPREQ no modo pró-ativo, quando odot11MeshHWMProotMode estiver com ovalor 2 (dois) ou 3(três).
INTEGERem milisegundos
read-write MIB Padrão 1.3.6.1.4.1.2022.2.1.5.18
dot11MeshActivePathSelectionProtocol
Atributo usado paraselecionar o Protocolode Seleção deCaminho da Rede802.11s.
INTEGER read-write MIB Padrão Não implementado(O linux não dásuporte)
dot11MeshActivePathSelectionMetric
Atributo usado paraindicar qual é amétrica de seleção decaminho usada peloProtocolo de Seleçãode Caminho da rede802.11s
INTEGER read-write MIB Padrão Não implementado(O linux não dásuporte)
dot11MeshForwarding Atributo usado paraindicar se a interface802.11s pode ou nãoencaminhar quadrosMesh.
INTEGER0 – NãoEncaminha1 - Encaminha
read-write MIB Padrão 1.3,.6.1.4.1.2022.2.1.5.8
dot11MeshGateAnnouncements
Atributo usado parainformar se a interface802.11s é o portal darede Mesh (trabalhano modo pró-ativo)
INTEGER0 – Não é umportal 1 – É um portal
read-write MIB Padrão ING )1.3.6.1.4.1.2022.2.1.5.7
dot11MeshHWMProotMode
Atributo usado paraindicar se a interface802.1ss é a raiz doMesh (trabalha nomodo pró-ativo)
INTEGER0 – Não é raiz 2 – É raiz comPREQ pró-ativo esem PREP pró-ativo3 – É raiz comPREQ pró-ativo ecom PREP pró-ativo4 – É raiz comRANN
read-write MIB Padrão 1.3.6.1.4.1.2022.2.1.5.6
51
dot11MeshHWMPtargetOnly
Atributo usado paraindicar se apenas oMesh Point (EstaçãoMesh) de destino pode(1) ou não (0)responder um PREQcom um PREP
INTEGER0 – RoteadoresMesh no meio docaminho podemresponder1 – Apenas oRoteador Meshde Destino poderesponder.
read-write MIB Padrão Não implementado(O linux não dásuporte ainda)
dot11MeshNumberOfPREQ
Atributo usado paraindicar a quantidadede quadros PREQ quechegaram ou passarampela máquina da rede802.11s.
INTEGER read-only MIBProprietária
1.3.6.1.4.1.2022.2.1.5.14
dot11MeshNumberOfPREP
Atributo usado paraindicar a quantidadede quadros PREP quechegaram ou passarampela máquina da rede802.11s.
INTEGER read-only MIBProprietária
1.3.6.1.4.1.2022.2.1.5.15
dot11MeshNumberOfPERR
Atributo usado paraindicar a quantidadede quadros PERR quechegaram ou passarampela máquina da rede802.11s
INTEGER read-only MIBProprietária
1.3.6.1.4.1.2022.2.1.5.16
dot11MeshNumberOfRANN
Atributo usado paraindicar a quantidadede quadros RANN quechegaram ou passarampela máquina da rede802.11s.
INTEGER read-only MIBProprietária
1.3.6.1.4.1.2022.2.1.5.17
Também é importante ressaltar que embora existam MIBs proprietárias que definem
atributos relacionados aos endereços de rede (netIPDNSAddress, netIPDHCPAddress,
netSubnetMask, netIpAddress), como é o caso, por exemplo da IP-MIB, esse atributos são de
acesso somente leitura (read-only). Como o AIGA necessita que os atributos referentes ao endereço
IP possuam acesso de leitura e escrita (read-write), houve a necessidade de se criarem objetos na
MIB estendida de modo a atender a esse requisito.
5.2 Protocolo de Geração de Tráfego
No capítulo 4 foi explicado como os programas relacionados ao controle da geração de
tráfego funcionam. Nessa seção será apresentado o protocolo utilizado para a troca de mensagens
entre os programas TC-Client e TC-Server. As mensagens desse protocolo, que se chama Protocolo
de Geração de Tráfego, são encapsuladas em pacotes TCP, e o servidor TC-Server escuta na porta
52
10000 (dez mil).
O protocolo é dividido em três partes: configuração, requisição e resposta, que são
detalhadas a seguir. Todas as mensagens possuem como os dois primeiros campos o código que
identifica o tipo da mensagem, dentre os três tipos existentes, e o identificador do fluxo. O primeiro
campo se chama Operador e o segundo ID.
5.2.1 Mensagem de Configuração
As mensagens de configuração, usadas na fase de configuração do programa de geração de
tráfego, são enviadas do gerente (pelo TC-Client) para as máquinas que atuam como origem de
tráfego, e tem o objetivo de configurar os parâmetros dos pacotes que serão enviados por aquela
máquina. O protocolo de configuração é dividido em requisições TCP e UDP, coforme mostrado na
Figura 15.
Os campos das mensagens são descritos a seguir.
Operador: define qual o tipo de mensagem. Neste caso terá valor 1 para indicar que se
trata de uma mensagem de configuração;
ID (Identificador): usado para identificar cada fluxo de pacotes gerado pelo protocolo;
IP: parâmetro que define qual é o IP da máquina de destino. Usado pelo iperf para saber
qual o destino dos pacotes enviados;
Protocolo: define qual o tipo de protocolo a ser utilizado no envio dos pacotes desse
fluxo. Utiliza-se o valor 0 para o TCP e o 1 para UDP;
Janela: utilizada pelo TCP, a janela é a quantidade de bytes armazenada no buffer da
máquina de destino;
Tempo: parâmetro que define a quantidade de tempo em segundos durante o qual que a
máquina de origem enviará os pacotes à maquina de destino;
53
Figura 15: Pacote de Configuração do Protocolo de Geração de Tráfego
Banda: utilizado pelo UDP para fixar o valor da largura de banda dos pacotes trafegados
na rede;
Tamanho: é o tamanho do buffer para ler e escrever. O iperf trabalha em escrever um
vetor por um “tamanho” de bytes em uma quantidade de vezes. No protocolo UDP, ele
indica o tamanho do datagrama;
MSS (Maximum Segment Size – Tamanho Máximo do Segmento): é o tamanho do
maior segmento que o protocolo TCP pode transmitir;
5.2.2 Mensagem de Requisição
A mensagem de requisição, é enviada pela estação de gerência quando se deseja obter os
parâmetros de desempenho medidos durante a fase de geração de tráfego, conforme descrito na
seção 4.3.1. Vale lembrar que o TC-Client chama o Iperf, e após a conclusão deste, recebe os dados
de desempenho medidos por ele, e armazena essas informações. Essa mensagem de requisição é
exatamente para obter essas informações. Portanto, cada mensagem de requisição obtém os dados
referentes a um fluxo de dados transmitidos pelo Iperf. O formato dessa mensagem de requisição do
protocolo de Geração de Tráfego é apresentado na Figura 16.
Os campos da mensagem são descritos a seguir.
Operador: define qual o tipo do mensagem. Neste caso terá valor 2 para indicar que se
trata de uma mensagem de requisição;
ID (Identificador): usado para identificar o fluxo de pacotes para o qual se deseja obter
informações;
Protocolo: define o protocolo a ser solicitado (UDP = 1 e TCP = 0) – para o caso de
existirem dois fluxos (TCP e UDP) com o mesmo ID;
5.2.3 Mensagem de Resposta
As mensagens de resposta do protocolo de Geração de Tráfego são enviadas quando um
equipamento recebe uma mensagem de requisição (descrita na seção 5.3.2). São portanto, enviadas
54
Figura 16: Pacote de Requisição do protocolo de Geração de Tráfego
dos roteadores da rede em malha para a estação de gerência. O conteúdo da mensagem descreve as
informações referentes à transmissão do fluxo solicitado na mensagem de requisição que estavam
armazenadas no TC-Client. Existem dois formatos diferentes para dependendo do tipo de fluxo ao
qual ela se refere (TCP ou UDP). Esse formatos são apresentados na Figura 17.
Os campos das mensagens são descritos a seguir.
Operador: define qual o tipo de mensagem. Neste caso terá valor 3 para indicar que se
trata de uma mensagem de resposta;
ID (Identificador): usado para identificar o fluxo ao qual as informações se referem;
Protocolo: indica qual foi o protocolo utilizado nesse fluxo (UDP = 1 ou TCP = 0);
Bytes Transferidos: quantidade de bytes transferidos do roteador de origem ao destino;
Banda: a largura de banda dos pacotes que foram transferidos na rede 802.11s;
Taxa de Erros: A porcentagem (%) da quantidade pacotes que foram perdidos na rede.
Usado apenas no UDP;
Jitter (Variação do atraso): variação do atraso dos pacotes que trafegaram na rede em
milisegundos. Usado apenas no UDP;
55
Figura 17: Pacote de Resposta do Protocolo de Geração de Tráfego
Figura 18: Diagrama de Sequência do Protocolo de Geração de Tráfego
A figura 18 mostra o diagrama de sequência do Protocolo de Geração de tráfego e as
interações de suas mensagens. A mensagem de Configuração é o passo inicial para configurar o
fluxo desejado. Ao enviar a mensagem à máquina de origem, ela dispara o fluxo desejado (pacotes
TCP ou UDP) para a máquina de destino e em seguida mede o desempenho do fluxo gerado. Em
seguida, a estação de gerência solicita o desempenho do fluxo gerado através da Mensagem de
Requisição e a máquina de origem responde com uma Mensagem de Resposta informando o
desempenho do fluxo gerado.
5.3 Interface Gráfica
Na implementação da interface gráfica do AIGA foi utilizada a ferramenta QT Designer [QT
Project 2014] e a linguagem de programação C++. A interface gráfica é dividida em quatro partes:
configuração das máquinas, configuração da topologia, geração de tráfego e coleta das informações.
As seções a seguir, descrevem cada uma dessas partes separadamente.
5.3.1 Configuração das Máquinas
Conforme mostrado na Figura 18, a interface gráfica do AIGA possui uma aba para a
configuração as máquinas da rede 802.11s. Os atributos que podem ser configurados para cada
máquina são:
• IP da Máquina: IP da interface Ethernet que será usado para a gerência remota da
máquina;
• Mesh ID: o nome do Identificador Mesh que será configurado para a interface 802.11s
da máquina a ser configurada;
• IP da interface Mesh: IP a ser configurado da interface 802.11s da máquina;
• Máscara da interface Mesh: máscara de rede a ser configurada da interface 802.11s da
máquina;
• MAC da interface Mesh: endereço MAC a ser configurado da interface 802.11s da
máquina;
• Canal de Comunicação: canal de comunicação a ser configurado da interface 802.11s
da máquina;
• Ativar a Interface Mesh: configurar se a interface 802.11s da máquina será ativada ou
não;
56
Ainda observando a Figura 19, pode-se observar que na parte esquerda da aba de
configuração estão os atributos que de configuração que podem ser definidos, e já foram citados, e a
direita uma tela demonstrando como o equipamento foi configurado. A seguir temos a descrição do
botões existentes, são eles:
• Gravar Máquina: é responsável por gravar os atributos da máquina solicitada em
memória;
• Exportar Máquinas: é utilizado para exportar as máquinas gravadas em memória em
um arquivo. Este botão tem uma enorme importância na automatização de testes da
ferramenta, pois permite que as configurações das máquinas sejam reutilizadas em
requisições futuras;
• Ler Máquinas: é usado para ler as configurações das máquinas salvas em arquivo.
Pode-se ler as configurações de apenas uma máquina ou de uma conjunto de máquinas.
Essa possibilidade simplifica bastante a tarefa de reexecutar os experimentos, uma vez
que não requer que os parâmetros que definem a configuração da rede sejam digitados
novamente.
• Enviar: é responsável por enviar os atributos de configuração para as máquinas da rede
em malha, ou seja, por de fato configurar a rede. Quando se utiliza a opção anterior (Ler
Máquinas) para carregar a configuração de várias máquinas, esse botão (Enviar)
configura todas elas de uma única vez.
• Mostrar: é utilizado para mostrar os atributos de configuração da máquina solicitada;
57
Figura 19: Configuração das Máquinas da WMN no AIGA
5.3.2 Configuração da Topologia
A parte de configuração da Topologia do AIGA, como o próprio nome indica, tem o objetivo
de configurar a topologia (definir quem são os Pares de Conexões). É importante ressaltar que a
configuração da topologia só pode ser realizada depois da configuração das máquinas, descrita na
seção anterior. Além da topologia, essa aba também permite definir outros parâmetros relacionados
ao IEEE 802.11s, como por exemplo, os parâmetros do Protocolo de Descoberta de Caminho. Os
atributos de configuração que podem ser definidos, e estão mostrados na Figura 20, são:
• IP da Máquina: IP da interface Ethernet que será usado para a gerência remota da
máquina;
• MAC do Peer Link a ser deletado: endereço MAC correspondente ao Par de Conexão
a ser deletado da interface 802.11s da máquina;
• A máquina é raiz da rede?: configura se a máquina é raiz ou não da rede (a rede
802.11s trabalhará no modo pró-ativo);
• Qual é o modo de funcionamento do Nó Raiz?: define o modo de funcionamento do
nó raiz, quando este for configurado. As três opções correspondem aos seguintes modos:
quadros PREQ pró-ativos sem PREP pró-ativos, quadros PREQ com PREP pró-ativos e
quadros RANN;
• Intervalo Root – PREQ (milisegundos): intervalo de tempo que o nó Raiz demora
enviar um quadro PREQ pró-ativo na rede 802.11s (se a máquina for raiz da rede);
• Intervalo Root – RANN (milisegundos): intervalo de tempo que o nó Raiz demora
enviar um quadro RANN na rede 802.11s (se a máquina for raiz da rede);
• A máquina é o portal da rede?: configura se a máquina é o portal da rede;
• Liberar Novos Pares de Conexão?: configura se a máquina pode ou não estabelecer
novos pares de conexão. A definição desse atributo de configuração é importante, pois se
a máquina estiver liberada para fazer novos pares de conexão, os que foram deletados
poderão ser associados novamente se as outras máquinas da rede 802.11s também
estiverem liberadas para novos pares de conexão;
• Encaminhar Quadros Mesh: Configura se a máquina pode ou não encaminhar quadros
802.11s.
58
A seguir temos uma descrição da funcionalidade cada botão existente na aba “Topologia”:
• Gravar Topologias: é responsável por gravar os atributos da topologia solicitada em
memória;
• Exportar Topologias: é utilizado para exportar as topologias salvas em memória em um
determinado arquivo.
• Ler Topologias: é usado para ler os atributos das topologias gravadas em arquivo. Essa
possibilidade simplifica bastante a tarefa de reexecutar os experimentos, ou criar outros
cenários com topologias semelhantes;
• Enviar: é responsável por enviar os atributos de configuração para as máquina da rede
IEEE 802.11s;
• Mostrar: é utilizado para exibir os atributos de configuração da máquina solicitada;
• Excluir: usado para excluir o par de conexão estabelecido com o equipamento cujo
endereço MAC é informado.
5.3.3 Configuração de Tráfegos
A parte de configuração de Tráfego no AIGA tem a função de configurar o tráfego gerado na
rede, o que é feito definindo os fluxos que cada máquina deve transmitir. Essa etapa só pode ser
realizada depois de configuradas as máquinas e a topologia da rede, conforme descritas nas seções
anteriores. Os atributos de configuração suportados foram todos descritos na seção 4.2 deste
documento.
59
Figura 20: Configuração da Topologia da WMN no AIGA
A aba “Tráfegos” do AIGA é mostrada na Figura 21. A seguir temos uma descrição dos
botões existentes:
• Gravar Tráfego: é responsável por gravar os atributos do fluxo solicitado em memória;
• Exportar Tráfegos: é utilizado para exportar as configurações dos fluxos em um
determinado arquivo.
• Ler Tráfegos: é usado para ler as configurações de fluxos gravadas em arquivo. Essa
possibilidade simplifica bastante a tarefa de reexecutar os experimentos, ou criar outros
cenários, pois as configurações de tráfegos anteriores podem ser reutilizadas sem a
necessidade de que a configuração seja feita novamente;
• Enviar: é responsável por enviar os atributos de configuração de tráfego para as
máquinas da rede IEEE 802.11s. Isso é feito utilizando o protocolo de configuração de
tráfego.
5.3.4 Coleta das Informações
A parte da interface gráfica do AIGA referente a coleta das informações tem a função obter
as informações referentes ao desempenho da rede que foram coletadas pelo módulo de
monitoramento durante a fase de geração de tráfego, conforme apresentado na seção 4.3. Ou seja,
obtêm-se as informações referentes à transmissão dos fluxos de dados e ao protocolo HWMP. Para
obter as informações de um único equipamento, deve-se informar seu endereço IP no campo IP de
origem. Caso se deseje obter as informações de todos os equipamentos da rede, deve-se informar o
60
Figura 21: Configuração de Tráfego da WMN do AIGA
valor 0.0.0.0 para esse campo. De modo semelhante, para se obter a informação referente a um
fluxo específico de um equipamento deve-se informar o identificador desse fluxo no campo ID, e
caso se deseje obter as informações sobre todos os fluxos de um equipamento utiliza-se o ID 0. As
informações referentes ao total de mensagens transmitidas pelo protocolo HWMP são sempre
recuperadas. Veja figura 22:
A seguir é feita uma explicação sobre a função dos botões existentes na aba “Resultados”:
• Gravar Resultado: é usado para gravar as informações obtidas em memória;
• Salvar Resultados: é utilizado para salvar as informações obtidas em um determinado
arquivo.
• Ler Tráfegos: é usado para ler as informações gravadas em arquivo;
• Enviar: é responsável por enviar as requisições para o(s) equipamento(s) de modo a
obter as informações desejadas.
61
Figura 22: Coleta das Informações da WMN no AIGA
6 Avaliação
Neste capítulo são apresentados os testes realizados com o AIGA para demonstrar como ele
simplifica a gerência de WMNs no padrão IEEE 802.11s. Os testes realizados consistiram em
reconfigurar um testbed composto por doze equipamentos reais utilizando diversos cenários
diferentes, de modo a analisar o comportamento das redes IEEE 802.11s. As máquinas utilizadas
(roteadores) possuíam a mesma configuração de hardware, conforme mostrado na Tabela 3.
Tabela 3: Especificação das máquinas utilizadas nos testes da rede 802.11s.
CPU Atheros AR7161 680MHz
Memória 128MB DDR SDRAM
Armazenamento 64MB NAND onboard
Portas Ethernet Três portas (10/100bps)
Interfaces Sem fio Dois slots MiniPCI (foi utilizada apenas ainterface WiFi)
Porta Serial Conector DB9 RS232
Sistema Operacional OpenWrt, kernel 3.3
O testbed é localizado no laboratório de pós-graduação do Departamento de Informática e
Matemática Aplicada (DIMAp) na Universidade Federal do Rio Grande do Norte (UFRN). O
sistema operacional dos doze roteadores eram carregados pela rede durante sua inicialização através
de suas respectivas portas Ethernet utilizando um servidor DHCP e TFTP, desta forma o tráfego do
AIGA não interferiria no tráfego da WMN. O servidor DHCP é responsável por informar os
endereços IPs das interfaces Ethernet dos roteadores que foram conectadas a um switch, e o servidor
TFTP foi responsável por transferir a imagem contendo o Sistema Operacional dos roteadores
(OpenWrt). A Figura 22 mostra como foram disponibilizados os doze roteadores no laboratório.
62
Percebe-se pela figura 23 que todos os roteadores inicialmente foram disponibilizados em
uma arquitetura física em grade três por quatro (3 x 4). Foram utilizados quatro tipos de topologias
lógicas nos testes empregados: três por quatro (todos os roteadores) em grade, três por três (3 x 3)
em grade, dois por dois (2 x 2) em grade e em linha (com cinco roteadores). O protocolo HWMP foi
utilizado para a Descoberta de Caminho na rede 802.11s, e foram testados tanto o modo pró-ativo
com o reativo. No modo pró-ativo (com nó raiz), foram utilizados intervalos RANN de 5000 (cinco
mil) milissegundos, com o nó raiz sendo sempre o roteador 1 (um). Foram gerados fluxo para
pacotes UDP e TCP, com as configurações descritas nas tabelas 4 e 5 respectivamente.
Tabela 4: Configurações dos Pacotes UDP
Tempo 60 segundos
Banda de Transmissão 100 Kilobytes/s
Tamanho do Pacote 8 Kilobytes
Tabela 5: Configurações dos Pacotes TCP
Tempo 60 segundos
Janela de Transmissão 1 Megabyte
Tamanho do Pacote 8 Kilobytes
MSS (Tamanho Máximo de Segmento) 8 Kilobytes
Na gerência e geração de cada teste nos diferentes cenários criados pelo o AIGA, foram
63
Figura 23: Testbed com os doze roteadores
disparadas cinco rajadas simultâneas de tráfegos que serão detalhadas com cada tipo de topologia
configurada e os parâmetros do protocolo de Descoberta de Caminho, neste caso o HWMP, foram
configurados nos seus respectivos modos de operação (reativo e pró-ativo). A seguir cada
experimento é descrito em mais detalhes e os resultados dos testbeds são discutidos no final desse
capítulo, apesar de não ser o foco do AIGA, é necessário frisar como o AIGA pode analisar o
desempenho de uma WMN. É importante observar que nessa seção não se está interessado de fato
nos valores obtidos, mas sim na facilidade proporcionada pelo AIGA para que se realizem a
gerência e os testes de uma WMN com um variado número de cenários.
Todos as configurações dos testbeds (máquinas, topologias, tráfegos e coleta) foram salvas
(“exportados”, descritos na seções 5.3.1, 5.3.2, 5.3.3 e 5.3.4) em arquivos modo texto para
experimentos futuros. Desta forma automatizando a gerência e os futuros testbeds realizados com o
AIGA.
6.1 Topologia em Grade 3 X 4
A topologia em grade três por quatro (3 x 4) tem o objetivo em demonstrar como se
comporta o protocolo HWMP em um alto nível de conectividade entre os roteadores na rede IEEE
802.11s. Foram feitos testes disparando pacotes TCP e UDP do roteador 9 (nove) para o roteador 4
(quatro). A Figura 24 apresenta como a topologia foi utilizada.
64
Figura 24: Topologia 3 x 4 disparando pacotes doroteador 9 ao roteador 4
OBS: A rota estabelecida entre os roteadores é estabelecida pelo protocolo HWMP, podendo ser
qualquer outra além da demonstrada na figura 24.
6.1.1 Modo reativo
A tabela 6 apresenta os resultados obtidos para os fluxos TCP.
Tabela 6: Resultados dos tráfegos gerados pelos pacotes TCP no modo reativo na topologia 3 x 4.
Tráfego Bytes Transferidos Taxa de Transmissão
1 1.07 Mbytes (1095,68 Kbytes) 134 Kbites/s
2 208 KBytes 12.0 Kbits/sec
3 352 KBytes 17.0 Kbits/sec
4 352 KBytes 39.3 Kbits/sec
5 1.05 Mbytes (1075.2 Kbytes) 145 Kbits/sec
Média 616.57 KBytes 69.46 Kbits/sec
A tabela 7 apresenta os resultados obtidos para os fluxos UDP.
Tabela 7: Resultados dos tráfegos gerados pelos pacotes UDP no modo reativo na topologia 3 x 4.
Tráfego BytesTransferidos
Tx. deTransmissão
Jitter (Variaçãodo Atraso)
Taxa de Perda dePacotes (%)
1 41.6 KBytes 5.64 Kbits/sec 7.297 ms 66/ 95 (69%)
2 31.6 KBytes 4.26 Kbits/sec 14.171 ms 73/ 95 (77%)
3 30.1 KBytes 4.03 Kbits/sec 50.061 ms 74/ 95 (78%)
4 38.8 KBytes 5.21 Kbits/sec 48.431 ms 68/ 95 (72%)
5 40.2 KBytes 5.31 Kbits/sec 86.738 ms 65/ 93 (70%)
Média 36.46 Kbytes 4.68 Kbits/s 41.339 ms 73.2%
6.1.2 Modo pró-ativo
A tabela 8 apresenta os resultados obtidos para os fluxos TCP.
65
Tabela 8: Resultados dos tráfegos gerados pelos pacotes TCP no modo pró-ativo na topologia 3 x 4.
Tráfego Bytes Transferidos Taxa de Transmissão
1 1.05 Mbytes (1075,2 Kbytes) 119 Kbits/sec
2 808 KBytes 108 Kbits/sec
3 576 KBytes 59.9 Kbits/sec
4 568 KBytes 73.4 Kbits/sec
5 648 KBytes 85.0 Kbits/sec
Média 735,04 KBytes 89.06 Kbits/sec
A tabela 9 apresenta os resultados obtidos para os fluxos UDP.
Tabela 9: Resultados dos tráfegos gerados pelos pacotes UDP no modo pró-ativo na topologia 3 x 4.
Tráfego BytesTransferidos
Tx. deTransmissão
Jitter (Variaçãodo Atraso)
Taxa de Perda dePacotes (%)
1 43.1 KBytes 539 bits/sec 45.986 ms 63/ 93 (68%)
2 X X X X
3 X X X X
4 38.8 KBytes 485 bits/sec 36.407 ms 68/ 95 (72%)
5 X X X X
Média 40.95 KBytes 512 bits/sec 41.19 ms 70%
OBS: Os campos marcados com “X” significam que não houveram medição dos pacotes para o
tráfego especificado devido à alta taxa de perda de pacotes.
6.2 Topologia em Grade 3 X 3
A topologia em grade três por três (3 x 3) tem o objetivo em demonstrar como se comporta o
protocolo HWMP em um nível mais baixo de conectividade entre os roteadores em comparação à
topologia três por quatro (3 x 4) na WMN. Foram feitos testes disparando pacotes TCP e UDP do
roteador 9 (nove) para o roteador 3 (três). A Figura 25 apresenta a topologia utilizada.
66
6.2.1 Modo reativo
A tabela 10 apresenta os resultados obtidos para os fluxos TCP.
Tráfego Bytes Transferidos Taxa de Transmissão
1 280 KBytes 17.4 Kbits/sec
2 712 KBytes 89.0 Kbits/sec
3 208 KBytes 21.2 Kbits/sec
4 856 KBytes 90.8 Kbits/sec
5 504 KBytes 55.9 Kbits/sec
Média 512.2 KBytes 54.84 Kbits/sec
Tabela 10: Resultados dos tráfegos gerados pelos pacotes TCP no modo reativo na topologia 3 x 3.
A tabela 11 apresenta os resultados obtidos para os fluxos UDP.
Tráfego BytesTransferidos
Tx. deTransmissão
Jitter (Variaçãodo Atraso)
Taxa de Perda dePacotes (%)
1 44.5 KBytes 5.95 Kbits/sec 12.810 ms 62/ 93 (67%)
2 X X X X
3 48.8 KBytes 6.55 Kbits/sec 08.427 ms 59/ 93 (63%)
4 34.5 KBytes 4.55 Kbits/sec 55.296 ms 69/ 93 (74%)
5 38.8 KBytes 5.16 Kbits/sec 67.239 ms 68/ 95 (72%)
Média 41,65 KBytes 5.55 Kbits/sec 35.94 ms 69%
Tabela 11: Resultados dos tráfegos gerados pelos pacotes UDP no modo reativo na topologia 3 x 3.
67
Figura 25: Topologia 3 x 3 disparando pacotes doroteador 9 ao roteador 3
6.2.2 Modo pró-ativo
A tabela 12 apresenta os resultados obtidos para os fluxos TCP.
Tabela 12: Resultados dos tráfegos gerados pelos pacotes TCP no modo pró-ativo na topologia 3 x3.
Tráfego Bytes Transferidos Taxa de Transmissão
1 1.05 Mbytes (1075,2 Kbytes) 144 Kbits/sec
2 576 KBytes 76.7 Kbits/sec
3 280 KBytes 33.0 Kbits/sec
4 952 KBytes 124 Kbits/sec
5 784 KBytes 97.4 Kbits/sec
Média 733.4 KBytes 95.02 Kbits/sec
A tabela 13 apresenta os resultados obtidos para os fluxos UDP.
Tabela 13: Resultados dos tráfegos gerados pelos pacotes UDP no modo pró-ativo na topologia 3 x3.
Tráfego BytesTransferidos
Tx. deTransmissão
Jitter (Variaçãodo Atraso)
Taxa de Perda dePacotes (%)
1 41.6 KBytes 5.57 Kbits/sec 6.926 ms 66/ 95 (69%)
2 X X X X
3 X X X X
4 48.8 KBytes 6.34 Kbits/sec 08.188 ms 61/ 95 (64%)
5 X X X X
Média 45.2 KBytes 5.95 Kbits/sec 7.577 ms 67%
6.3 Topologia em Grade 2 X 2
A topologia em grade dois por dois (2 x 2) tem o objetivo demonstrar como se comporta o
protocolo HWMP em um baixo nível de conectividade entre os roteadores em comparação à
topologia três por três (3 x 3) na WMN. Foram feitos testes disparando pacotes TCP e UDP do
roteador 5 (cinco) para o roteador 2 (dois). A Figura 26 apresenta a topologia utilizada.
68
6.3.1 Modo reativo
A tabela 14 apresenta os resultados obtidos para os fluxos TCP.
Tabela 14: Resultados dos tráfegos gerados pelos pacotes TCP no modo reativo na topologia 2 x 2.
Tráfego Bytes Transferidos Taxa de Transmissão
1 1.54 MBytes 207 Kbits/sec
2 1.82 MBytes 247 Kbits/sec
3 1.76 MBytes 244 Kbits/sec
4 2.03 MBytes 281 Kbits/sec
5 1.77 MBytes 242 Kbits/sec
Média 1.784 Mbytes (1826.81Kbytes)
244.2 Kbits/sec
A tabela 15 apresenta os resultados obtidos para os fluxos UDP.
Tabela 15: Resultados dos tráfegos gerados pelos pacotes UDP no modo reativo na topologia 2 X 2.
Tráfego BytesTransferidos
Tx. deTransmissão
Jitter (Variaçãodo Atraso)
Taxa de Perda dePacotes (%)
1 80.4 KBytes 10.8 Kbits/sec 3.551 ms 39/ 95 (41%)
2 77.5 KBytes 10.5 Kbits/sec 8.950 ms 41/ 95 (43%)
3 86.1 KBytes 11.6 Kbits/sec 6.972 ms 35/ 95 (37%)
4 77.5 KBytes 10.3 Kbits/sec 7.935 ms 39/ 93 (42%)
5 81.8 KBytes 11.0 Kbits/sec 7.412 ms 52/ 93 (56%)
Média 80.66 KBytes 10.84 Kbits/sec 6.954 ms 43.8 %
69
Figura 26: Topologia 2 x 2 enviandopacotes do roteador 5 ao roteador 2
6.3.2 Modo pró-ativo
A tabela 16 apresenta os resultados obtidos para os fluxos TCP.
Tabela 16: Resultados dos tráfegos gerados pelos pacotes TCP no modo pró-ativo na topologia 2 x2.
Tráfego Bytes Transferidos Taxa de Transmissão
1 1.27 MBytes 176 Kbits/sec
2 1.84 MBytes 253 Kbits/sec
3 1.78 MBytes 240 Kbits/sec
4 1.89 MBytes 257 Kbits/sec
5 1.78 MBytes 242 Kbits/sec
Média 1.712 Mbytes (1753.08Kbytes)
233.6 Kbits/sec
A tabela 17 apresenta os resultados obtidos para os fluxos UDP.
Tabela 17: Resultados dos tráfegos gerados pelos pacotes UDP no modo pró-ativo na topologia 2 X2.
Tráfego BytesTransferidos
Tx. deTransmissão
Jitter (Variaçãodo Atraso)
Taxa de Perda dePacotes (%)
1 57.4 KBytes 7.82 Kbits/sec 8.960 ms 55/ 95 (58%)
2 71.8 KBytes 9.78 Kbits/sec 3.459 ms 45/ 95 (47%)
3 63.2 KBytes 8.59 Kbits/sec 7.103 ms 51/ 95 (54%)
4 66.0 KBytes 8.93 Kbits/sec 4.055 ms 47/ 93 (51%)
5 63.2 KBytes 8.59 Kbits/sec 0.955 ms 51/ 95 (54%)
Média 64,32 KBytes 8.742 Kbits/sec 4.960 ms 52.8 %
6.4 Topologia em Linha
A topologia em linha tem o objetivo demonstrar como se comporta o protocolo HWMP em
um baixíssimo nível de conectividade em comparação à topologia dois por dois (2 x 2) na rede
802.11s. Foram feitos testes disparando pacotes TCP e UDP do roteador 5 (cinco) para o roteador 11
(onze). A Figura 27 apresenta a topologia utilizada.
70
6.4.1 Modo Reativo
A tabela 18 apresenta os resultados obtidos para os fluxos TCP.
Tabela 18: Resultados dos tráfegos gerados pelos pacotes TCP no modo reativo na topologia emlinha.
Tráfego Bytes Transferidos Taxa de Transmissão
1 1.11 MBytes 148 Kbits/sec
2 1.62 MBytes 225 Kbits/sec
3 1.87 MBytes 259 Kbits/sec
4 1.48 MBytes 202 Kbits/sec
5 1.98 MBytes 271 Kbits/sec
Média 1.612 Mbytes (1650.68Kbytes)
221 Kbits/sec
A tabela 19 apresenta os resultados obtidos para os fluxos UDP.
Tabela 19: Resultados dos tráfegos gerados pelos pacotes UDP no modo reativo na topologia emlinha.
Tráfego BytesTransferidos
Tx. deTransmissão
Jitter (Variaçãodo Atraso)
Taxa de Perda dePacotes (%)
1 111 KBytes 15.3 Kbits/sec 3.847 ms 18/ 95 (19%)
2 109 KBytes 15.1 Kbits/sec 0.454 ms 19/ 95 (20%)
3 112 KBytes 15.4 Kbits/sec 8.644 ms 17/ 95 (18%)
4 113 KBytes 15.6 Kbits/sec 5.446 ms 16/ 95 (17%)
5 112 KBytes 15.5 Kbits/sec 4.028 ms 17/ 95 (18%)
Média 111.4 KBytes 15.38 Kbits/sec 4.483 ms 18.4 %
71
Figura 27: Topologia em Linha enviando pacotes do roteador 5 ao roteador 11
6.4.2 Modo Pró-ativo
A tabela 20 apresenta os resultados obtidos para os fluxos TCP.
Tabela 20: Resultados dos tráfegos gerados pelos pacotes TCP no modo pró-ativo na topologia emlinha.
Tráfego Bytes Transferidos Taxa de Transmissão
1 1.56 MBytes 216 Kbits/sec
2 1.26 MBytes 175 Kbits/sec
3 1.98 MBytes 268 Kbits/sec
4 1.91 MBytes 266 Kbits/sec
5 1.77 MBytes 238 Kbits/sec
Média 1.696 Mbytes (1736.7Kilobytes)
232.6 Kbits/sec
A tabela 21 apresenta os resultados obtidos para os fluxos UDP.
Tabela 21: Resultados dos tráfegos gerados pelos pacotes UDP no modo pró-ativo na topologia emlinha.
Tráfego BytesTransferidos
Tx. deTransmissão
Jitter (Variaçãodo Atraso)
Taxa de Perda dePacotes (%)
1 112 KBytes 15.0 Kbits/sec 0.931 ms 17/ 95 (18%)
2 106 KBytes 14.3 Kbits/sec 4.761 ms 21/ 95 (22%)
3 115 KBytes 15.4 Kbits/sec 3.145 ms 15/ 95 (16%)
4 126 KBytes 17.0 Kbits/sec 4.942 ms 7/ 95 (7.4%)
5 111 KBytes 14.8 Kbits/sec 7.299 ms 16/ 93 (17%)
Média 114 KBytes 15.3 Kbits/sec 4.215 ms 16.08%
6.5 Comparações dos Resultados
É importante realizar a comparação entre as diferentes topologias empregadas e seus modos
de operação (reativo e pró-ativo) para ter uma melhor compreensão de como os tráfegos gerados se
comportaram em cada uma dessas configurações. As tabelas 22 e 23 correspondem respectivamente
aos tráfegos TCP e UDP.
72
73
Figura 28: Comparação dos resultados dos Bytes Transferidos dos pacotes TCP entre as diferentestopologias .
Topologia 3 x 4 modo reativo
Topologia 3 x 4 modo proativo
Topologia 3 x 3 modo reativo
Topologia 3 x 3 modo proativo
Topologia 2 x 2 modo reativo
Topologia 2 x 2 modo proativo
Topologia em linha modo reativo
Topologia em linha modo proativo
0 200 400 600 800 1000 1200 1400 1600 1800 2000
Pacotes TCP
Bytes Transferidos
Bytes Transferidos (KBytes)
Tip
o d
e T
op
olo
gia
Tabela 22: Média dos tráfegos gerados pelos pacotes TCP na rede 802.11s.
PACOTES TCP: Bytes Transferidos (Média – Kbytes) Taxa de Transmissão (Média – Kbits/s)Topologia 3 x 4 modo reativo 616,57 69,46Topologia 3 x 4 modo proativo 730 89,06Topologia 3 x 3 modo reativo 512,2 54,84Topologia 3 x 3 modo proativo 733,4 95,02Topologia 2 x 2 modo reativo 1826,816 244,2Topologia 2 x 2 modo proativo 1753,088 232,6Topologia em linha modo reativo 1650,688 221Topologia em linha modo proativo 1736,704 232,6
As figuras 28 e 29 demonstram detalhadamente o comportamento em diferentes topologias
da média dos Bytes Transferidos e a Taxa de Transmissão dos pacotes TCP respectivamente.
74
Tabela 23: Média dos tráfegos gerados pelos pacotes UDP na rede 802.11s.
PACOTES UDP: Bytes Transferidos (Média – Kbytes) Taxa de Transmissão (Média – Kbits/s) Jitter (milisegundos) Taxa de Perda de Pacotes (%)Topologia 3 x 4 modo reativo 36,46 4,68 41,339 73,3
Topologia 3 x 4 modo proativo 40,95 0,5 41,19 70
Topologia 3 x 3 modo reativo 41,65 5,55 35,94 69Topologia 3 x 3 modo proativo 45,2 5,95 7,577 67Topologia 2 x 2 modo reativo 80,66 10,84 6,954 43,8
Topologia 2 x 2 modo proativo 64,32 8,742 8,742 52,8
Topologia em linha modo reativo 111,4 15,38 4,483 18,4
Topologia em linha modo proativo 114 15,3 4,215 16,08
Figura 29: Comparação dos resultados dos Taxa de Transmissão dos pacotes TCP entre asdiferentes topologias .
Topologia 3 x 4 modo reativo
Topologia 3 x 4 modo proativo
Topologia 3 x 3 modo reativo
Topologia 3 x 3 modo proativo
Topologia 2 x 2 modo reativo
Topologia 2 x 2 modo proativo
Topologia em linha modo reativo
Topologia em linha modo proativo
0 50 100 150 200 250 300
Pacotes TCPTaxa de Transmissão
Taxa de Transmissão (Kbits/s)
Tip
o d
e T
op
olo
gia
75
Figura 31: Comparação dos resultados das Taxas de Transmissão dos pacotes UDP entre asdiferentes topologias.
Topologia 3 x 4 modo reativo
Topologia 3 x 4 modo proativo
Topologia 3 x 3 modo reativo
Topologia 3 x 3 modo proativo
Topologia 2 x 2 modo reativo
Topologia 2 x 2 modo proativo
Topologia em linha modo reativo
Topologia em linha modo proativo
0 2 4 6 8 10 12 14 16 18
Pacotes UDP
Taxa de Transmissão
Taxa de Transmissão (Kbits/s)
Top
olo
gia
Figura 30: Comparação dos resultados dos Bytes Transferidos pelos pacotes UDP entre asdiferentes topologias .
Topologia 3 x 4 modo reativo
Topologia 3 x 4 modo proativo
Topologia 3 x 3 modo reativo
Topologia 3 x 3 modo proativo
Topologia 2 x 2 modo reativo
Topologia 2 x 2 modo proativo
Topologia em linha modo reativo
Topologia em linha modo proativo
0 20 40 60 80 100 120
Pacotes UDP
Bytes Transferidos (Média)
Bytes Transferidos (Kbits/s)
Top
olo
gia
As figuras 30, 31, 32 e 33 demonstram detalhadamente o comportamento em diferentes
topologias da média dos Bytes Transferidos, Taxa de Transmissão, Jitter (variação de atraso) e Taxa
76
Figura 33: Comparação dos resultados das Taxas de Perda dos Pacotes dos pacotes UDP entreas diferentes topologias.
Topologia 3 x 4 modo reativo
Topologia 3 x 4 modo proativo
Topologia 3 x 3 modo reativo
Topologia 3 x 3 modo proativo
Topologia 2 x 2 modo reativo
Topologia 2 x 2 modo proativo
Topologia em linha modo reativo
Topologia em linha modo proativo
0 10 20 30 40 50 60 70 80
Pacotes UDP
Taxa de Perda de Pacotes
Taxa de Perda de Pacotes (%)
Top
olo
gia
Figura 32: Comparação dos resultados das Variações de Tráfego (jitter) dos pacotes UDP entreas diferentes topologias.
Topologia 3 x 4 modo reativo
Topologia 3 x 4 modo proativo
Topologia 3 x 3 modo reativo
Topologia 3 x 3 modo proativo
Topologia 2 x 2 modo reativo
Topologia 2 x 2 modo proativo
Topologia em linha modo reativo
Topologia em linha modo proativo
0 5 10 15 20 25 30 35 40 45
Pacotes UDPJitter (média)
Jitter (milisegundos)
Top
olo
gia
de Perda de Pacotes dos pacotes UDP respectivamente.
Através do AIGA, percebe-se pelas médias de tráfegos obtidas nas diferentes topologias,
tanto com TCP quanto com UDP, que o modo de operação (reativo ou pró-ativo) do protocolo
HWMP não causou diferenças significativas nos resultados. Outro fato interessante a ser detalhado
é uma queda considerável de desempenho em topologias com um maior número de equipamentos
(topologias 3 x 4 e 3 x 3) em comparação comparação às topologias com um baixo número de
conectividade (topologias 2 x 2 e em linha).
Apesar das considerações feitas a respeito do desempenho da rede com o protocolo HWMP,
o objetivo dessa seção de testes, conforme já foi mencionado, não é realizar uma análise do
protocolo HWMP, mas sim mostrar que o AIGA permite que a gerência e a realização de testbeds da
WMN sejam feitas de forma simplificada. Nos testes realizados foram utilizadas quatro topologias
de rede (linha, 2 x 2, 3 x 3, e 4 x 3), sendo que para cada uma delas a rede foi configurada uma vez
com o modo reativo do protocolo HWMP e outra com o modo pró-ativo. Além disso, para cada um
desses cenários foram gerados tanto tráfego TCP quanto UDP. Desse modo, foram criados oito
cenários de testes.
O AIGA simplificou bastante a gerência da rede através da reconfiguração do testbed de
acordo com os diversos cenários analisados, uma vez que os arquivos exportados com as definições
das configurações das máquinas, das topologias e do tráfego, de cada cenário serviu de base a a
criação de outro cenário. Além disso, a execução de cada experimento e a coleta das informações
monitoradas tornou-se uma tarefa bastante simples, por causa da estação de gerência que permitiu
que todas essas tarefas fossem automatizadas e realizadas de um único ponto.
77
7 Conclusões
Este trabalho apresentou o AIGA, que simplifica o gerenciamento de IEEE 802.11s WMNs.
Inicialmente discutiu-se sobre o fato de que ainda existe muita pesquisa de novos protocolos para o
IEEE 802.11s e essa atividade tipicamente envolve a realização de experimentos em testbeds.
Também foi dito que após o a conclusão do processo de padronização do IEEE 802.11s as redes
utilizando essa tecnologia estão sendo cada vez mais empregadas em ambientes de produção.
Mostrou-se que o gerenciamento dessas redes em qualquer desses dois casos de uso é uma tarefa
complexa, de modo que após reconfigurações na rede é necessário verificar seu correto
funcionamento. Desse modo, uma solução de gerenciamento completa deve incluir as seguintes
tarefas: configuração da rede, definição e geração de tráfego, monitoramento e coleta de
informações referentes a desempenho. Mostrou-se que embora existam diversos trabalhos que
abordam como realizar cada uma dessas tarefas isoladamente, não foi identificado nenhum trabalho
na literatura pesquisada que tratasse as três tarefas em conjunto.
Ao longo desse texto foi mostrado como o AIGA consegue integrar as três tarefas acima
citadas de modo a fornecer um ambiente que possibilite o gerenciamento das WMNs de modo
simplificado. Também foi explicitado que embora o AIGA possa ser utilizado para gerenciar e
analisar diversos aspectos das redes IEEE 802.11s, seu maior foco de interesse é simplificar a
análise dos protocolos de Descoberta de Caminho.
Existem dois pontos importantes a serem destacados no AIGA. O primeiro é seu protocolo
de geração de tráfego que permite à estação de gerência coordenar a geração de tráfego originando-
se em diferentes máquinas da rede, bem como obter informações sobre o desempenho obtido
durantes as transmissões dos mesmos. O segundo ponto importante é a extensão da MIB padrão
IEEE 802.11 incorporando novos objetos que são importantes para a configuração e análise do novo
modo de operação em malha incorporado com o adendo IEEE 802.11s.
Por tudo o que foi exposto neste trabalho conclui-se que o mesmo é bastante útil para a
gerência das WMNs, principalmente para a análise dos protocolos de Descoberta de Caminho. Sua
utilização facilitará, por exemplo, a comparação do HWMP com outros protocolos existentes, bem
como com os que ainda venham a ser propostos, indicando em quais cenários cada um deles é mais
adequado.
Entre os novos recursos que podem ser incorporados ao AIGA pode-se citar: criar novas
formas de exibição das informações de desempenho coletadas, como por exemplo, utilizando
gráficos; desenvolver o módulo de geração de tráfego em um hardware independente (como
Arduino [Arduino 2014]) de modo que possa ser conectado ao roteador quando não for possível
78
alterar o firmware do mesmo. Além disso, algumas melhorias na implementação podem ser
realizadas, como por exemplo, utilizar o SNMPv3 para melhorar o nível de segurança, aprimorar a
interface gráfica do usuário, e reestruturar o código para permitir que módulos de monitoramento
para outros protocolos de Descoberta de Caminho sejam mais facilmente incorporados ao AIGA.
79
Referências
Arduino (2014). http://www.arduino.cc/. Acessado em Março de 2014.
Bahr, M. (2006). Proposed Routing for IEEE 802.11s WLAN Mesh Networks. In 2nd annual
internacional wireless internet conference (WICON), Boston, MA, USA.
Bahr, M. (2008). Update on the Hybrid Wireless Mesh Protocol of IEEE 802.11s.
Bicket, J., Biswas S. e Aguayo, D. (2003). Architecture and Evaluation of the MIT Roofnet Mesh
Network (DRAFT). M.I.T. Computer Science and Artificial Intelligence Laboratory.
CISCO MIB (2014). MIB CISCO do padrão IEEE 802.11.
http://tools.cisco.com/Support/SNMP/do/BrowseMIB.dolocal=en&step=2&mibName=IEEE802
dot11-MIB. Acessado em Maio de 2014.
Covington G., Naous J., Erickson D., Appenzeller G., McKeown N. (2008). Implementing a
OpenFlow Switch on the NetFPGA platform.
Dely P., Kassler A., Bayer N. (2011). OpenFlow for Wireless Mesh Networks. Computer
Communications and Networks ICCN, Proceedings of 20th International Conference on, 2011.
Huang, F., Yang, Y., e He, L. (2007). A Flow-Based Network Monitoring Framework for Wireless
Mesh Networks. IEEE Wireless Communications, 14(5).
ISO/IEC 7498-4 (1989). Information Processing System – Open System Interconnection – Basic
Referencia Model: Management Framework.
IEEE Std 802.11 (2012). Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications, pages: 1352 – 1441.
Iperf (2013). Iperf Tool. iperf.fr. Acessado em Julho de 2013.
Jardosh A., Suwannatat P., Hollerer T., Belding E. e Almeroth K. (2008). SCUBA: Focus and
Context for Real-time Mesh Network Health Diagnosis. Lecture Notes in Computer Science,
4979:162.
Manzano D., Cano J., Calafate C., Manzoni P. (2007). MAYA: A Tool for Wireless Mesh Network. In
Proc. of IEEE MASS vol. 1, no. 6, pp.8-11 Oct. 2007.
McKeown N., Anderson T., Balakrishnan H., Parulkar G., Peterson L., Rexford J., Shenker S., e
Turner J. (2008). OpenFlow: Enabling innovation in campus networks. SIGCOMM Comput.
Commun. Rev., 38(2):69–74, 2008.
80
Net-SNMP (2013). Framework do SNMP. www.net-snmp.org. Acessado em Novembro de 2013.
Navda, V., Kashyap A. e Das, S (2005). Design and Evaluation of iMesh: an Infrastructure-mode
Wireless Mesh Network. Computer Science Department State University of New York at Stony
Brook.
OpenWRT (2013). Openwrt wireless freedom. www.openwrt.org. Acessado em Novembro de 2013.
Pinheiro, B., de Brito Nascimento, V., Cerqueira, E., Abelém, A. e Neto, A. (2010). Abaré: Um
Framework para Implantação, Monitoramento e Gerenciamento Coordenado e Autônomo para
Redes em Malha sem Fio. In XV Workshop de Gerência e Operação de Redes e Serviços,
Gramado, RS, Brasil.
QT Project (2014). http://qt-project.org/ . Acessado em Abril de 2014.
Riggio, R. e Miorandi, D. (2007). Janus: a framework for distributed management of wireless mesh
networks. In TridentCom 2007. 3rd International Conference.
Stallings, William. (1998). SNMP, SNMPv2, SNMPv3, and RMON 1 and 2. Addison-Wesley
Longman Publishing.
Song, H., Kim, B., Lee, J. e Lee Hwang (2009). IEEE 802.11-based Wireless Mesh Network.
Division of Electrical Engineering, School of EECS, KAIST.
Tcpdump (2014). Tcpdump e libpcap. http://www.tcpdump.org/. Acessado em Março de 2014.
Telecom (2014). Gerenciamento e monitoramento de Rede.
http://www.teleco.com.br/tutoriais/tutorialgmredes1/pagina_3.asp. Acessado em Maio de 2014.
Valle, R. e Muchaluat-Saade, D. (2011). MeshAdmin: Plataforma Integrada de Gerência para Redes
em Malha sem Fio. In XVI Workshop de Gerência e Operação de Redes e Serviços, Campo
Grande, MS, Brasil.
Wang, X. e Lim, A. (2007). IEEE 802.11s Wireless Mesh Networks: Framework and challenges.
81