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


Figura 30: Comparação Dos Resultados Dos Bytes Transferidos Pelos Pacotes UDP Entre As


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


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


X 2......................................................................................................................................................70


2 X 2...................................................................................................................................................71


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


Em Linha............................................................................................................................................73


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.1 Modo Reativo..................................................................................................................67

6.2.2 Modo Pró-ativo...............................................................................................................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


Deletar Par de Conexão: elimina determinado par de conexão da interface IEEE


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.


1.3.6.1.4.1.2022.2.1.5.1

netIPDNSAddress Atributo que define oIP do Servidor DNSda interface 802.11sda máquina.


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 à


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


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


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.


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


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.


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



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%)





Média 36.46 Kbytes 4.68 Kbits/s 41.339 ms 73.2%

6.1.2 Modo pró-ativo


65

Tabela 8: Resultados dos tráfegos gerados pelos pacotes TCP no modo pró-ativo na topologia 3 x 4.


1 1.05 Mbytes (1075,2 Kbytes) 119 Kbits/sec

2 808 KBytes 108 Kbits/sec




Média 735,04 KBytes 89.06 Kbits/sec


Tabela 9: Resultados dos tráfegos gerados pelos pacotes UDP no modo pró-ativo na topologia 3 x 4.


Tx. deTransmissão



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.


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












Tx. deTransmissão




2 X X X X




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



Tabela 12: Resultados dos tráfegos gerados pelos pacotes TCP no modo pró-ativo na topologia 3 x3.


1 1.05 Mbytes (1075,2 Kbytes) 144 Kbits/sec



4 952 KBytes 124 Kbits/sec




Tabela 13: Resultados dos tráfegos gerados pelos pacotes UDP no modo pró-ativo na topologia 3 x3.


Tx. deTransmissão




2 X X X X

3 X X X X


5 X X X X

Média 45.2 KBytes 5.95 Kbits/sec 7.577 ms 67%


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




1 1.54 MBytes 207 Kbits/sec





Média 1.784 Mbytes (1826.81Kbytes)

244.2 Kbits/sec


Tabela 15: Resultados dos tráfegos gerados pelos pacotes UDP no modo reativo na topologia 2 X 2.


Tx. deTransmissão








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



Tabela 16: Resultados dos tráfegos gerados pelos pacotes TCP no modo pró-ativo na topologia 2 x2.








233.6 Kbits/sec


Tabela 17: Resultados dos tráfegos gerados pelos pacotes UDP no modo pró-ativo na topologia 2 X2.


Tx. deTransmissão








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


Tabela 18: Resultados dos tráfegos gerados pelos pacotes TCP no modo reativo na topologia emlinha.








221 Kbits/sec


Tabela 19: Resultados dos tráfegos gerados pelos pacotes UDP no modo reativo na topologia emlinha.


Tx. deTransmissão



1 111 KBytes 15.3 Kbits/sec 3.847 ms 18/ 95 (19%)





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


Tabela 20: Resultados dos tráfegos gerados pelos pacotes TCP no modo pró-ativo na topologia emlinha.







Média 1.696 Mbytes (1736.7Kilobytes)

232.6 Kbits/sec


Tabela 21: Resultados dos tráfegos gerados pelos pacotes UDP no modo pró-ativo na topologia emlinha.


Tx. deTransmissão






4 126 KBytes 17.0 Kbits/sec 4.942 ms 7/ 95 (7.4%)


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









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.









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 .









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.









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.









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

Documents

AIGA: Um Ambiente Integrado de Gerência para Redes em