Universidade Federal do Rio Grande do Norte
Centro de Ciências Exatas e da Terra
Departmento de Informática e Matemática Aplicada
Programa de Pós-Graduação em Sistemas e Computação
Mestrado Acadêmico em Sistemas e Computação
Extensões ao Projeto LVWNet: Mobilidade,
interação com equipamentos reais,
comunicação direta, e registro dinâmico de nós
Leonardo Dantas de Oliveira
Natal-RN
Junho de 2014
Leonardo Dantas de Oliveira
Extensões ao Projeto LVWNet: Mobilidade, interação
com equipamentos reais, comunicação direta, e registro
dinâmico de nós
Dissertação de Mestrado apresentada ao 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 como requisito parcial para a obtenção do grau de
Mestre em Sistemas e Computação.
Linha de pesquisa:
Sistemas Distribuídos
Orientador
Dr. Marcos César Madruga Alves 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-RN
Junho de 2014
Dissertação de Mestrado sob o título Extensões ao Projeto LVWNet: Mobilidade, interação com equipamentos reais, comunicação direta, e registro dinâmico de nós apresentada
por Leonardo Dantas de Oliveira 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:
Dr. Marcos César Madruga Alves Pinheiro
Presidente
DIMAp – Departamento de Informática e Matemática Aplicada
UFRN – Universidade Federal do Rio Grande do Norte
Dr. Augusto José Venâncio Neto
Examinador
DIMAp – Departamento de Informática e Matemática Aplicada
UFRN – Universidade Federal do Rio Grande do Norte
Dr. Flávio de Oliveira Silva
Examinador Externo à Instituição
FACOM – Faculdade de Computação
UFU – Universidade Federal de Uberlândia
Natal-RN, 05 de Junho de 2014.
UFRN / Biblioteca Central Zila Mamede
Catalogação da Publicação na Fonte
Oliveira, Leonardo Dantas de.
Extensões ao projeto LVWNet: mobilidade, interação com
equipamentos reais, comunicação direta, e registro dinâmico de nós. /
Leonardo Dantas de Oliveira. – Natal, RN, 2014.
80 f.: il.
Orientador: Prof. Dr. Marcos César Madruga Alves Pinheiro.
Dissertação (Mestrado) – Universidade Federal do Rio Grande do
Norte. Centro de Ciências Exatas e da Terra. Programa de Pós -Graduação
em Sistemas e Computação.
1. Wireless – Dissertação. 2. Posicionamento - Dissertação. 3. IEEE
802.11 - Dissertação. 4. LVWNet – Dissertação. 5. Free-space –
Dissertação. 6. Path Loss – Dissertação. 7. Linux – Dissertação. 8.
Testbed – Dissertação. 9. Prototipação – Dissertação. I. Pinheiro, Marcos
César Madruga Alves. II. Universidade Federal do Rio Grande do Norte.
III. Título.
RN/UF/BCZM
CDU 004.7
A minha esposa Karla e minha filha Rebecca, pela compreensão nesses dias de ausência.
Agradecimentos
Primeiro a Deus, por ter me dado saúde e força para superar as dificuldades.
Ao meu orientador, Dr. Marcos Madruga, pelo empenho ímpar dedicado à elaboração
deste trabalho.
Aos professores Dr. Augusto Venâncio e Dr. Flávio de Oliveira pelo paciente trabalho
de revisão e avaliação e por suas importantíssimas sugestões.
A Marcos Luporini e Juliano Prado, pelos mecanismos que foram essenciais para a
elaboração desse trabalho.
Também à comunidade ao redor do Linux, que com sua excelente organização, provê
toda a documentação e ferramental necessário para o seu uso.
O medo não é algo ruim, ele lhe mostra suas fraquezas.
Gildarts Clive
Extensões ao Projeto LVWNet: Mobilidade, interação
com equipamentos reais, comunicação direta, e registro
dinâmico de nós
Autor: Leonardo Dantas de Oliveira
Orientador: Prof. Dr. Marcos César Madruga Alves Pinheiro
Resumo
Com o crescimento constante da utilização de redes sem fio em ambientes domésticos,
empresariais e até industriais, aparecem novos desafios. A prototipação de novos protocolos nesses ambientes tipicamente é restrita a ambientes de simulação, onde existe a
necessidade de uma dupla implementação, uma no ambiente de simulação, onde se realiza
uma prova de conceito inicial e outra em um ambiente real. Além disso, uma vez que se
parta para ambientes reais, não é trivial a criação de um testbed para redes sem fio de
alta densidade, dada a necessidade de uso de vários equipamentos reais, e uso de atenuadores, redutores de potência, para tentar reduzir o espaço físico necessário para criação
desses laboratórios. Nessa lacuna, o projeto LVWNet (Linux Virtual Wireless Network)
foi inicialmente concebido para criação de testbeds completamente virtuais para redes
IEEE 802.11 sobre o sistema operacional Linux. Este trabalho tem como objetivo extender o atual projeto LVWNet adicionando a ele os recursos de possibilitar a interação com
hardwares wireless reais, dar um suporte inicial à mobilidade através do posicionamento
dos nós em um ambiente de coordenadas no espaço baseado em metros, já com cálculos de
perda decorrente da atenuação em espaço livre, aumentar a escalabilidade com a criação
de um mecanismo que permita a comunicação direta entre os nós sem necessidade de um
host intermediário além do registro dinâmico de nós, de modo que novos nós podem ser
inseridos na rede com a mesma já em operação.
Palavras-chave: Posicionamento, IEEE 802.11, LVWNet, Free-space Path Loss, Wireless,
Linux, Testbed, prototipação.
Extensions of LVWNet project: mobility, interaction
with real hardware, direct communication and dynamic
registration of nodes
Author: Leonardo Dantas de Oliveira
Supervisor: Dr. Marcos César Madruga Alves Pinheiro
Abstract
Due to the constantly increasing use of wireless networks in domestic, business and industrial environments, new challenges have emerged. The prototyping of new protocols
in these environments is typically restricted to simulation environments, where there is
the need of double implementation, one in the simulation environment where an initial
proof of concept is performed and the other one in a real environment. Also, if real environments are used, it is not trivial to create a testbed for high density wireless networks
given the need to use various real equipment as well as attenuators and power reducers
to try to reduce the physical space required to create these laboratories. In this context,
LVWNet (Linux Virtual Wireless Network) project was originally designed to create completely virtual testbeds for IEEE 802.11 networks on the Linux operating system. This
paper aims to extend the current project LVWNet, adding to it the features like the ability to interact with real wireless hardware, provides a initial mobility ability using the
positioning of the nodes in a space coordinates environment based on meters, with loss
calculations due to attenuation in free space, enables some scalability increase by creating
an own protocol that allows the communication between nodes without an intermediate
host and dynamic registration of nodes, allowing new nodes to be inserted into in already
in operation network.
Keywords: IEEE 802.11, LVWNet, LFS, Wireless, Linux, Testbed, Prototyping.
Lista de figuras
1
IEEE 802.11 e o modelo de referência OSI de 7 camadas. . . . . . . . .
p. 24
2
Problema do hidden terminal em redes CSMA/CA. . . . . . . . . . . .
p. 28
3
Conexões de uma rede mesh 3 x 3 conforme visto pelas máquinas virtuais. p. 37
4
Conexões reais de uma rede mesh 3 x 3 criada pelo LVWNet. . . . . . .
p. 38
5
Cabeçalho LVWNet usado para registro do nó.
p. 43
6
Cabeçalho LVWNet usado para informar um nó das configurações dos
. . . . . . . . . . . . .
seus vizinhos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 45
7
Disposição dos nós do diagrama de troca de mensagens da figura 8. . .
p. 45
8
Diagrama de troca de mensagens com os nós 01, 02 e 03 alcançáveis entre
si.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Disposição dos nós do diagrama de troca de mensagens da figura 10.
.
10
Diagrama de troca de mensagens com os nós 01, 02 alcançáveis entre si,
nós 03 e 04 também, mas não entre eles. . . . . . . . . . . . . . . . . .
11
p. 46
p. 47
p. 47
Diagrama de sequência de chamadas de funções entre os módulos mac80211
e lvwnet_node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 58
12
Amostra de tráfego do tipo data capturado na ethernet. . . . . . . . .
p. 59
13
Definindo a interface real como sendo do tipo mesh.
. . . . . . . . . .
p. 65
14
Peer links do host real com as máquinas virtuais. . . . . . . . . . . . .
p. 66
15
Teste básico de conectividade e tabela de encaminhamento layer 2. . .
p. 66
16
Estado do nó 03 no milestone 01 (sem nenhum peer link ). . . . . . . .
p. 68
17
Estado do nó 03 no milestone 02 (peer link com o nó 01).
. . . . . . .
p. 69
18
Estado do nó 03 no milestone 04 (peer link com o nó 01 e nó 02). . . .
p. 70
19
Estado do nó 03 no milestone 05 (peer link com o nó 01 e nó 02). O peer
link com o nó 01 está aguardando ser excluído.
20
p. 70
Estado do nó 03 no milestone 05 (peer link com o nó 02). O peer link
com o nó 01 foi excluído após 1800 segundos.
21
. . . . . . . . . . . . .
. . . . . . . . . . . . . .
p. 70
Caminho percorrido pelo nó 03 entre os 6 milestones. . . . . . . . . . .
p. 71
Lista de tabelas
1
Endereços MAC Ethernet e WLAN dos nós para teste de inserção de um
nó real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 64
2
Posições iniciais dos nós virtuais e do real
. . . . . . . . . . . . . . . .
p. 65
3
IPs e endereços MAC ethernet e WLAN dos nós . . . . . . . . . . . . .
p. 66
4
Posições iniciais dos nós . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 68
5
Posições de cada um dos milestones do nó 03 . . . . . . . . . . . . . . .
p. 68
Lista de abreviaturas e siglas
ARP – Address Resolution Protocol
IEEE – Institute of Electrical and Electronics Engineers
LVWNet – Linux Virtual Wireless Network
MAC – Media Access Control
PHY – Physical Layer
STA – Station
LLC – Logical Link Control
ISM – Industrial, Scientific and Medical
ITU-R – International Telecommunication Union - Radiocommunication Sector
DSS – Digital Spread Spectrum
OFDM – Orthogonal Frequency Division Multiplexing
MIMO – Multiple-Input Multiple-Output
BSA – Basic Service Area
BSS – Basic Service Set
AP – Access Point
DS – Distribution System
ESA – Extended Service Area
ESS – Extended Service Set
WPA – WiFi Protected Access
WEP – Wired Equivalent Privacy
CSMA/CA – Carrier Sense Multiple Access/Collision Avoid
CSMA/CD – Carrier Sense Multiple Access/Collision Detect
NAV – Network Allocation Vector
ESS-Mesh – Extended Service Set Mesh
BSS – Basic Service Set
AP – Access Point
MP – Mesh Point
MBSS – Mesh Basic Service Set
HWMP – Hybrid Wireless Mesh Protocol
PREQ – Path Request
PREQ – Path Reply
RANN – Root Announcement
MLME – Media Access Control Sublayer Management Entity
TSF – Timing Synchronization Function
KVM – Kernel Virtual Machine
KSM – Kernel SamePage Merging
FSL – Free Space Loss
ACK – Acknowledgement
Lista de Códigos
5.1
Struct da mensagem de registro do LVWNet . . . . . . . . . . . . . . .
p. 54
5.2
Apontador do payload do skb para o struct da mensagem de registro . .
p. 55
5.3
Struct da mensagem de informações de vizinhos do LVWNet . . . . . .
p. 56
5.4
Registro do ethertype 0x0808 e sua função manipuladora . . . . .
p. 59
5.5
Exemplo de como carregar o módulo lvwnet_node . . . . . . . . . . . .
p. 61
A.1 git clone do projeto LVWNet . . . . . . . . . . . . . . . . . . . . . . .
p. 78
A.2 Executando o make do projeto LVWNet . . . . . . . . . . . . . . . . .
p. 79
A.3 Executando o make da versão modificada do mac80211 . . . . . . . .
p. 79
Sumário
1 Introdução
1.1
p. 18
Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 19
1.1.1
A importância de implementar o posicionamento dos nós no espaço p. 21
1.1.2
A importância de integrar uma rede IEEE 802.11 real com uma
virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 21
1.2
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 22
1.3
Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 23
2 Fundamentação Teórica
2.1
2.2
p. 24
O protocolo IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 24
2.1.1
Camada Física . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 25
2.1.2
Definições do IEEE 802.11 . . . . . . . . . . . . . . . . . . . . .
p. 25
2.1.3
Camada MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 28
O protocolo IEEE 802.11s . . . . . . . . . . . . . . . . . . . . . . . . .
p. 29
2.2.1
p. 30
O Módulo mac80211 . . . . . . . . . . . . . . . . . . . . . . . .
3 Trabalhos Relacionados
p. 32
3.1
Network Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 32
3.2
Projeto NCTUns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 32
3.3
Projeto mac80211_hwsim . . . . . . . . . . . . . . . . . . . . . . . . .
p. 33
3.4
Projeto Wmediumd . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 33
4 Visão Geral do Projeto LVWNet
p. 35
4.1
4.2
LVWNet original . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 36
4.1.1
Máquina controladora de topologia . . . . . . . . . . . . . . . .
p. 36
4.1.2
Nó participante da rede . . . . . . . . . . . . . . . . . . . . . .
p. 37
4.1.3
Hypervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 38
Componentes Modificados do LVWNet . . . . . . . . . . . . . . . . . .
p. 39
4.2.1
Posicionamento dos nós no espaço . . . . . . . . . . . . . . . . .
p. 40
4.2.2
Protocolo de Registro e Informações dos Nós . . . . . . . . . . .
p. 42
4.2.2.1
Mensagem de registro de nós . . . . . . . . . . . . . .
p. 42
4.2.2.2
Mensagem de informações de nós . . . . . . . . . . . .
p. 43
Diagramas de trocas de mensagens . . . . . . . . . . . . . . . .
p. 44
4.2.3.1
Caso 1: 3 nós são alcançáveis entre si . . . . . . . . . .
p. 45
4.2.3.2
Caso 2: Nó 01 e 02 são alcançáveis entre si, nós 03 e 04
4.2.3
4.2.4
também, mas não entre eles . . . . . . . . . . . . . . .
p. 46
Interação da rede LVWNet Virtual com hardwares reais . . . . .
p. 48
5 Detalhes de Implementação
5.1
5.2
5.3
5.4
p. 50
Ingresso de máquinas com hardware sem fio real em uma rede LVWNet
p. 50
5.1.1
Tomadas de decisões para o projeto . . . . . . . . . . . . . . . .
p. 50
Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 52
5.2.1
A pilha de rede do Linux . . . . . . . . . . . . . . . . . . . . . .
p. 52
5.2.2
Módulo mac80211 modificado . . . . . . . . . . . . . . . . . . .
p. 52
5.2.3
Módulo lvwnet_node . . . . . . . . . . . . . . . . . . . . . . . .
p. 53
5.2.4
Módulo lvwnet_controller . . . . . . . . . . . . . . . . . . . . .
p. 53
O protocolo de registro e informações de nós na rede . . . . . . . . . .
p. 54
5.3.1
O processo de registro dos nós . . . . . . . . . . . . . . . . . . .
p. 54
5.3.2
O protocolo de informações sobre vizinhos . . . . . . . . . . . .
p. 55
Comunicação direta entre os nós . . . . . . . . . . . . . . . . . . . . . .
p. 57
5.5
Uso dos Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 60
5.5.1
Carga dos módulos . . . . . . . . . . . . . . . . . . . . . . . . .
p. 60
5.5.2
Informações disponbilizadas via sysfs . . . . . . . . . . . . . . .
p. 62
6 Análise do LVWNet
p. 64
6.1
Criação automática de peer links com dispositivos reais . . . . . . . . .
p. 64
6.2
Simulação de mobilidade de um nó . . . . . . . . . . . . . . . . . . . .
p. 66
7 Considerações finais
p. 72
7.1
Principais contribuições
. . . . . . . . . . . . . . . . . . . . . . . . . .
p. 72
7.2
Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 73
7.3
Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 73
7.3.1
Mobilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 73
7.3.2
Modificação do radiotap no quadro IEEE 802.11 . . . . . . . . .
p. 74
7.3.3
Uso de erro e latência na transmissão de quadros . . . . . . . .
p. 74
7.3.4
Uso de replay de quadros para uso de máquinas sem modificação
p. 74
Referências
p. 75
Apêndice A -- Download e Compilação do Projeto LVWNet
p. 78
18
1
Introdução
Iniciada em 1997, a especificação do protocolo IEEE 802.11 permitiu uma inovação
até então reservada a protocolos fechados: a mobilidade à uma razoável largura de banda.
Desde então, o seu uso cresceu de forma que hoje não é mais possível imaginar um mundo
sem um protocolo aberto de comunicação sem fio.
Contudo, junto com novas facilidades surgem novos desafios. Hoje temos adendos ao
IEEE 802.11 que permitem velocidades acima de até 1 Gbp/s em redes sem fio (NOJIMA et
al.,
2012), além de protocolos que permitam extender a rede além do controle centralizado,
utilizando técnicas Ad-Hoc auto organizáveis, como por exemplo o IEEE 802.11s, que será
visto com um pouco mais de detalhes no próximo capítulo. Testes de validação e robustez
destes protocolos são razoavelmente fáceis de se realizar para uma pequena quantidade de
nós, contudo, como pode-se imaginar, essa dificuldade cresce a medida que é necessário
realizar testes em escala maior.
Atualmente, para testarmos novos protocolos, podemos recorrer a sistemas de simulação, onde é possível criar sua implementação nesse mesmo ambiente, e realizar testes em
escalas maiores. Contudo, quando precisamos testar as implementações desses protocolos
em ambientes reais, ou seja, fora da simulação, ainda caimos no problema anterior de
custo e espaço. Além disso, o código escrito para um simulador dificilmente é totalmente
aproveitado para um equipamento real, havendo a necessidade de sua reescrita. Existem
alguns trabalhos que permitem a emulação de protocolos, embora quase todos em ambientes muito controlados, com várias limitações sob este ambiente. No capítulo de trabalhos
relacionados serão mostrados alguns desses trabalhos e como eles se relacionam com o
LVWNet.
Hoje, com a facilidade de criação de máquinas virtuais através de hypervisors e hardwares já prontos e preparados para virtualização, entendemos que uma boa estratégia é utilizar esse poder computacional para criar um ambiente de testes. Desse modo, pode-se
utilizar máquinas virtuais para realizar os testes de protocolos e suas implementações em
19
ambientes o mais próximos possível da realidade.
Com essa proposta, em 2011 surgiu o projeto LVWNet, que tinha como objetivo inicial
o uso de redes IEEE 802.11s em máquinas virtuais. O LVWNet cria uma placa de rede
sem fio virtual IEEE 802.11s e emula o comportamento do meio físico sem fio, de modo
que para toda a pilha IEEE 802.11 é como se existisse de fato uma interface real na
máquina. Para isso, é definido um esquema de comunicação para encaminhar os quadros
entre as máquinas virtuais que encapsula os quadros IEEE 802.11 em quadros Ethernet.
Os quadros transmitidos por cada placa sem fio virtual são de fato primeiro encaminhados
para uma máquina especial (também virtual) que controla quem deve receber o quadro, e
o reencaminha para as devidas máquinas, levando em consideração as definições do nível
físico dessa rede.
Embora evidentemente não permita uma avaliação completa dos protocolos, uma vez
que existem diversas questões do nível físico que impactam no funcionamento dos protocolos, e só podem ser testadas em ambientes reais, o LVWNet permite que diversas
outras questões sejam analisadas. Em especial é possível, por exemplo, analisar diversas questões referentes aos protocolos de encaminhamento de quadros do IEEE 802.11s,
como a corretude do seu mecanismo de descoberta de rotas, sua adaptação quando nós
ou enlaces falham, volume de mensagens transmitidas, entre outras. Vale ressaltar, que
embora algumas questões possam ser analisadas por simuação, com o LVWNet pode-se
testar a implementação real do código executado pelos sistemas operacionais. Isso é especialmente importante quando novos protocolos estão sendo desenvolvidos, pois o código
escrito durante a fase de análise e testes é totalmente aproveitado.
1.1
Motivação
Na sua versão original o LVWNet apresenta algumas limitações que restringem os
cenários nos quais ele pode ser utilizado. Nessa seção apresentaremos as quatro principais
limitações que motivaram o desenvolvimento desse trabalho.
A primeira limitacão é que todos os nós da rede precisam ser conhecidos e cadastrados
na máquina de topologia previamente, ou seja, antes do início da execução das máquinas
virtuais. A máquina de topologia é responsável por realizar os cálculos de distância entre
nós e eventualmente encaminhar os quadros para os outros nós, dependendo do seu modo
de operação, que será explicado durante este trabalho.
Portanto, apesar de suportar a emulação de falhas nos links ou nós, o LVWNet não
20
suporta uma rede dinâmica onde os nós entrem ou deixem a rede ao longo do tempo. Fazse necessário portanto, um mecanismo que permita que novos nós entrem (ou deixem) a
rede a qualquer momento.
A segunda limitação é que no LVWNet existe uma máquina, chamada de Máquina
de Topologia que é a responsável por emular o comportamento do meio físico, e por onde
todos os quadros enviados pelós nós devem passar de modo a serem reencaminhados aos
seus destinos. Tal fato gera uma sobrecarga que limita a escalabilidade da rede, uma vez
que se existir um número muito elevado de nós isso pode gerar problemas de desempenho.
É interessante portanto, criar um mecanismo que limite as informações encaminhadas
para a máquina de topologia, apenas às informações de controle da rede virtual, deixando
o tráfego de dados propriamente dito ser encaminhado diretamente entre as máquinas.
A terceira limitação se refere a forma como alcance do sinal de um nó é definida no
LVWNet. O alcance do sinal define para cada nó quais outros nós da rede devem receber
seus quadros, e no LVWNet isso é feito de modo estático, através da especificação dos
endereços MAC dos nós. Desse modo, para cada nó é mantida uma lista com um ou mais
endereços MAC dos nós que estão no alcance de sinal do referido nó. Vale ressaltar, que
essa lista é uma estrutura interna do LVWNet e não é vista pela pilha IEEE 802.11.
Embora esse modelo de definição do alcance do sinal permita a criação das topologias
desejadas, ele possui duas principais limitações. A primeira é que todos os nós que participam da rede devem ser conhecidos previamente, dificultando, por exemplo, a inserção
de novos nós com a rede já em operação. O segundo ponto, é a dificuldade para inserir
suporte à mobilidade dos nós. É necessário usar um modelo de alcance do sinal mais próximo da realidade, ou seja, que considere questões como potência de sinal, sensitividade
do receptor e posicionalmento dos nós no espaço. Além disso, esse mecanismo deve ser
dinâmico de modo que novos nós possam ser inseridos na rede a qualquer momento.
A quarta limitação do LVWNet é que mesmo que ele possa ser utilizado com máquinas
reais ao invés das virtuais, as interfaces de rede wifi continuariam a ser virtuais. Desse
modo, não é possível integrar um equipamento real, que possui uma interface de rede wifi
real, na rede virtual criada pelo LVWNet.
Esse trabalho propõe soluções para essas quatro limitações, e as duas seções seguintes
discutem em mais detalhes a importância de se abordar a terceira e a quarta limitação.
21
1.1.1
A importância de implementar o posicionamento dos nós
no espaço
Embora comunicação sem fio e mobilidade não sejam a mesma coisa, uma vez que
podemos ter equipamentos sem fio que não possuem mobilidade, nas redes atuais suporte
à mobilidade é uma característica cada vez mais desejada nesses ambientes, onde dispositivos como smartphones, notebooks e qualquer outro equipamento que faça uso do
protocolo IEEE 802.11 normalmente estão em movimento. Fogem a essa regra equipamentos como pontos de acesso que estão em lugares fixos. Contudo, já temos pontos de
acesso móveis com baterias e celulares que também funcionam como ponto de acesso, que
faz com que não possamos afirmar que todos os pontos de acesso são fixos.
Desse modo, para iniciar um mecanismo de suporte à mobilidade no LVWNet é preciso
substituir seu mecanismo de controle do alcance de sinal dos nós (baseado no endereço
MAC) por um que se aproxime mais da realidade e considere a posição física dos nós.
Em redes sem fio reais, o posicionamento de um nó ou de um ponto de acesso sem fio é
muito importante para a boa recepção, seja para fugir de uma possível área de sombra,
seja por causa da distância, ou seja por causa de obstáculos existentes entre dois pontos
que desejem se comunicar. Contudo na proposta de solução para esse problema, que será
apresentada posteriormente, foram considerados apenas aspectos referentes a potência
de transmissão, sensitividade de recepção e distância entre dois nós, não levando em
consideração posssíveis obstáculos e interferências.
Com a mobilidade de nós implementada em redes virtuais é possível verificar por
exemplo como um protocolo ou aplicação sem comporta no caso de uma reconfiguração
da rede advinda de uma movimentação dos nós participantes da rede. Dada a natureza
virual da rede, é possível fazer isso em uma centena de nós, sem um esforço excessivo.
1.1.2
A importância de integrar uma rede IEEE 802.11 real com
uma virtual
Uma vez que o projeto LVWNet está funcional, um questionamento comum seria:
“Por que é importante integrar uma rede virtual com uma rede real”, sabendo-se que hoje
com virtualização pode-se resolver uma quantidade muito vasta de problemas.
A resposta pode parecer simples, mas é justamente para testar equipamentos reais,
incluindo neste teste o software e hardware. Principalmente quando é necessário simular
a conexão de um (ou vários) equipamentos reais com dezenas ou centenas de máquinas
22
virtuais.
Como exemplos práticos de uma aplicação temos a análise do consumo de bateria de
um dispositivo móvel quando conectado a uma rede com outras 100 estações. Como a
autonomia desse dispositivo será impactada sendo necessária a análise e eventual reposta
à mensagens de broadcast dessa centena de máquinas? Sendo o consumo de bateria algo
crítico em dispositivos móveis, tais testes poderiam ajudar a determinar limites para
implementação do firmware desses equipamentos, ou até mesmo subsidiar alterações no
próprio hardware.
Outro exemplo é a análise da capacidade de processamento e memória necessária para
um dispositivo (por exemplo, um roteador ou um access point) atender a uma quantidade
determinada de clientes. Esses recursos podem ser facilmente esvaídos quando temos uma
tabela de rotas ou até mesmo uma grande tabela ARP para gerenciar. Também podem ser
gastos facilmente com pedidos constantes de mensagens de broadcast geradas por centenas
de máquinas que façam parte de uma mesma rede mesh ou em infraestrutura.
A interligação entre laboratórios de testes reais é algo possível com as modificações
realizadas. Dois laboratórios separados, onde não exista a possibilidade de chegada de um
sinal de rádio entre eles, poderiam ser facilmente interligados utilizando duas máquinas
como gateways, permitindo que se forme um único domínio de broadcast em uma rede
IEEE 802.11. Isso é especialmente interessante para redes IEEE 802.11s, uma vez que
diversos laboratórios (testbeds) reais fisicamente distantes uns dos outos, podem ser interligados de modo a criar uma grande rede em malha sem fio que possui apenas alguns
poucos enlaces virtuais.
Ainda nessa linha de interligar equipamentos reais através de nós virtuais é possível
testar a compatibilidade da implementação do software de equipamentos diferentes. Supondo que só se dispõe de um modelo de equipamento pode-se criar uma rede virtual para
conectá-lo a outro equipamento que se encontra em um lugar remoto.
1.2
Objetivos
De acordo com o que foi exposto na seção de motivação, o objetivo desse trabalho é
extender a versão original do LVWNet incorporando os seguintes recursos:
• Definir um protocolo para o registro dinâmico dos nós na rede;
• implementar a comunicação direta entre os nós;
23
• definir um novo mecanismo para o cálculo do alcance do sinal dos nós de modo a
suportar mobilidade;
• permitir a integração de equipamentos IEEE 802.11 reais com a rede virtual.
1.3
Organização do trabalho
Neste capítulo inicial, foi apresentada uma introdução ao trabalho, mostrando como
ele está organizado, a motivação que levou ao desenvolvimento do mesmo e os objetivos
que procuramos alcançar.
No capítulo dois, é apresentada uma fundamentação teórica sobre o protocolo IEEE
802.11 e o protocolo IEEE 802.11s, necessária para um bom entendimento do trabalho
realizado.
Uma breve lista de trabalhos relacionados ao nosso projeto é apresentada no terceiro
capítulo, discutindo como eles contribuíram ou ainda podem contribuir para o amadurecimento da solução.
No quarto capítulo é fornecida inicialmente uma visão geral do projeto LVWNet,
apresentando como funciona seu mecanismo de encapsulamento de quadros IEEE 802.11
em quadros Ethernet, e apresentando todos os componentes necessários para a criação de
uma rede virtual. Após isso, são apresentadas todas as modificações realizadas no projeto
original, incluindo o novo esquema de posicionamento dos nós no espaço e alcance do sinal,
bem como uma descrição completa do mecanismo criado para a utilização de interfaces
de rede reais no projeto LVWNet .
O quinto capítulo apresenta as questões relacionadas a implementação de todos os
novos recursos.
No sexto capítulo são apresentados os testes realizados para para validar a solução,
bem como as metodologias adotadas nesses testes e seus consequentes resultados.
Finalmente no sétimo e último capítulo, temos a conclusão sobre o que foi apresentado
no trabalho, e são relacionadas questões em aberto para serem tratadas por trabalhos
futuros.
24
2
Fundamentação Teórica
2.1
O protocolo IEEE 802.11
Definido pelo IEEE através do padrão Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications (SOCIETY, 2012), ele traz em seu escopo a necessidade de definir uma estrutura para controle de acesso ao meio, MAC , e toda a camada
física ( PHY ) wireless para equipamentos fixos e móveis, estes últimos chamados pelo
padrão como Station (STA ) dentro de uma área de cobertura.
Além disso, também está dentro dos objetivos do padrão regulamentar e padronizar
o acesso a frequências e bandas dentro dessas frequências.
Dentro do modelo de referência OSI de 7 camadas, o protocolo IEEE 802.11 esta na
camada de enlace de dados, conforme ilustra a figura 1.
Figura 1: IEEE 802.11 e o modelo de referência OSI de 7 camadas.
25
2.1.1
Camada Física
A camada física do IEEE 802.11 corresponde bem à camada física do modelo de
referência OSI de 7 camadas, contudo a camada de enlace é dividida em duas subcamadas,
como visto na figura 1. Na primeira subcamada temos o Logical Link Control (LLC ), que
é o responsável por abstrair as diferenças entre as diferentes variações do IEEE 802.11,
como por exemplo 802.11b, 802.11n, 802.11ac etc (TANENBAUM; WETHERALL, 2011).
Na camada física, temos várias técnicas utilizadas para modulação do sinal, conforme
iremos observar adiante. O IEEE 802.11 utiliza frequências da banda Industrial, Scientific
and Medical (ISM ), definida pela ITU-R normalmente como sendo na faixa de 900 MHz,
2.4 GHz e 5.8GHz, contudo de forma mais precisa usando as frequências de 902-928 MHz,
2.4-2.5GHz e 5.725-5.825GHz(TANENBAUM; WETHERALL, 2011), que são frequências que
podem ser usar sem qualquer necessidade de regulamentação prévia.
Entre essas técnicas de modulação, o IEEE 802.11b, que tem taxas de transferência entre 1 e 11 Mbp/s utiliza Digital Spread Spectrum (DSS ), ou sequência direta de
espalhamento espectral, que espalha a potência do sinal sobre várias frequências simultaneamente. Já o IEEE 802.11a utiliza Orthogonal Frequency Division Multiplexing (OFDM
), onde múltiplos sinais são enviados em diferentes frequências, em diferentes modulações.
Finalmente, o IEEE 802.11n, que chega a taxas de 600 Mbp/s e o IEEE 802.11ac, que pode
chegar em taxas agregadas PHY de até 6.7 Gbp/s, utilizam o Multiple-Input MultipleOutput (MIMO ), que é um conjunto de técnicas de transmissão que utiliza múltiplas
antenas para transmissão e recepção, aproveitando inclusive sinais gerados por reflexão,
que antes eram considerados interferências, para melhorar a qualidade de transmissão e
recepção.
2.1.2
Definições do IEEE 802.11
O IEEE 802.11 tem uma abordagem de corbetura de áreas baseadas em células, onde
cada célula é chamada de Basic Service Area (BSA ). Quem irá determinar o tamanho
de uma célula (BSA) é a potência dos transmissores, sensitividade dos receptores das
estações, além de agentes externos que possam causar interferência, como por exemplo
outros transmissores concorrendo na mesma frequência, ou até mesmo barreiras físicas,
como prédios ou árvores (FILHO LUIZ FERNANDO SOARES, 2007). Podemos simplificar o
signifcado de uma BSA como sendo a cobertura da célula.
Além do BSA, temos algumas outras definições que valem ser mencionadas, como o
26
Basic Service Set (BSS ), que podemos definir como sendo um conjunto de estações (STA)
associadas a um ponto de acesso. O ponto de acesso, ou access point é quem atua como
controlador da infraestrutura e da comunicação das estações. A mais básica BSS possível
é composta por uma STA e um AP (Access Point).
Também temos no IEEE 802.11 o Distribution System (DS ), que é a representação
de uma infraestrutura de comunicação que interliga várias BSAs, de forma que possa
permitir uma comunicação entre várias células (SIRUFO, 2005).
Usando o conceito de DS previamente estabelecido, temos a definição de Extended
Service Area (ESA ) e Extended Service Set (ESS ). Na primeira, temos a interligação de
várias BSAs, usando justamente o DS previamente criado através de APs. Já no segundo,
repsenta um conjunto de STAs formado pela união de vários BSSs, conectados por um
mesmo DS.
Além dessas definições, o IEEE 802.11 prevê o conceito de services(SOCIETY, 2012).
Entres esses serviços, os principais são:
1. Association
É usado por estações móveis para conectá-las a um Ponto de Acesso. Quando uma
estação entra no raio de cobertura de um ponto de acesso (AP ), ela analisa a identidade e os recursos do ponto de acesso através dos beacon frames, ou realizando
consultas direto ao ponto de acesso.
2. Reassociation
A reassociação faz uma estação sair de um AP para outro. Usada para facilitar a
movimentação das STAs dentro de áreas de cobertura de diferentes pontos de acesso,
permitindo a mobilidade dessa STA.
3. Disassociation
A disassociação interrompe um relacionamento entre um AP e uma STA. Uma STA
deve utilizar esse serviço antes de desligar-se ou deixar a rede. Um AP também
pode usar esse serviço antes de entrar em manutenção.
4. Authentication
Antes de começar a enviar frames por um AP, as STA devem autenticar-se. Nesse
momento é que entra o conceito de uma rede “aberta”, onde qualquer usuário pode
autenticar-se sem restrição, ou uma rede fechada, onde temos mecanismos para
27
restringir os usuários tipicamente através de autenticação. Exemplos de esquemas
de autenticação é o WiFi Protected Access (WPA ), implementado no IEEE 802.11i,
ou ainda Wired Equivalent Privacy (WEP ), usado bem antes do WPA e já superado.
Vale mencionar que como será visto no service privacy, os protocolos WPA e WEP
também provêm criptografia além da autenticação.
5. Distribution
Uma vez que quadros comecem a chegar em um AP, temos o serviço de distribuição,
que determina como os quadros irão chegar em outras STAs ou no próprio AP.
6. Integration
Completamente relacionado ao serviço de distribuição, ele é o responsável por encaminhar os quadros para redes que não sejam IEEE 802.11. Normalmente, isso
significa a entrega de quadros IEEE 802.11 em Ethernet, claro realizando-se as modificações necessárias no quadro.
7. Data delivery
Este serviço é o responsável por fazer as STAs transmitir e receber quadros, utilizando os quadros definidos no IEEE 802.11.
8. QoS traffic scheduling
De forma a podermos manipular os quadros quanto a diferentes prioridades, usamos
o serviço de QoS. Presumidamente, o IEEE 802.11 é um protocolo do tipo besteffort, ou seja, entrega baseada em melhor esforço. Contudo, com o serviço de QoS,
podemos criar prioridades para determinados protocolos que precisem de tratamento
diferenciado, como por exemplo tráfego de voz ou vídeo.
9. Privacy
O serviço de privacidade é responsável pela criptografia dos dados. Eventualmente
confunde-se com o serviço de autenticação, pois os protocolos tipicamente usados
para ambos os serviços, normalmente são os mesmos. Como exemplos de protocolos
que trabalham nesse service estão WPA e WEP.
10. Transmit power control
O serviço de controle de potência de transmissão impede que as estações excedam
os limites regulatórios do país ou região. Por exemplo, no Brasil, para a faixa de
frequência ISM, usada pelo IEEE 802.11, a potência máxima prevista em lei é de 1
Watt (ANATEL, 2008).
28
11. Dynamic frequency selection
Finalmente, o último serviço é o de seleção de frequência dinâmica. Ele é responsável
por ajudar a STA a evitar frequências de uso específico, como por exemplo a de
5GHz, usada por radares (IEEE, 2007).
2.1.3
Camada MAC
O método de controle de acesso ao meio utilizado pelo IEEE 802.11 é o Carrier Sense
Multiple Access/Collision Avoid, ou CSMA/CA , que conceitualmente é semelhante ao
Carrier Sense Multiple Access/Collision Detect, ou CSMA/CD utilizado no ethernet. No
CSMA/CA a estação antes de transmitir verifica se o meio está ocupado (de forma análoga
ao CSMA/CD), e caso o meio não esteja livre espera por um tempo aleatório, definido no
protocolo. Caso o transmissor não receba o ACK do receptor, ele dobra o tempo de espera
e envia novamente. Essa característica do CSMA/CA é chamada de exponential backoff.
Uma das situações que gera possíveis problemas ao CSMA/CA é o hidden terminal,
ou estação oculta. Para comparação, o CSMA/CD foi desenvolvido de forma que todas as
estações possam “escutar” umas as outras (além da atenuação, esse é o principal motivo
da distância máxima de 100 metros do ethernet). Já em ambientes wireless, isso não é
completamente possível. No hidden terminal, como nem todas as estações estão no alcance
uma das outras, uma transmissão vinda de parte de uma célula, pode não ser “escutada”
por outra parte dessa mesma céula. A figura 2 exemplifica esse problema. Quando a STA
1 tenta enviar para a STA 2, ela verifica o meio para analisar se existem transmissões ao
alcance. Contudo, a STA 3 que já estava transmitindo, estava fora de alcance da STA 1.
Figura 2: Problema do hidden terminal em redes CSMA/CA.
Uma técnica que minimiza o problema do hidden terminal é a utilização combinada
de escuta do canal virtual e física juntamente com os quadros RTS e CTS. A física é a
escuta descrita anteriormente no CSMA/CA. Já a virtual, descrita como virtual sensing
29
em (TANENBAUM; WETHERALL, 2011), acontece quando cada estação mantém um registro
de quando o canal está em uso através da análise dos campos NAV (Network Allocation
Vector ). Cada quadro trás um campo NAV, que diz quão longa a sequência de que esse
quadro faz parte irá demorar. Com isso, a estação tem como estimar quanto tempo o
canal irá ficar ocupado.
2.2
O protocolo IEEE 802.11s
O grupo de estudos para criação do IEEE 802.11s foi iniciado em setembro de 2003
(IEEE, Setembro de 2003) com o nome de ESS-Mesh , e o grupo de trabalho com o objetivo
de criar os primeiros Drafts do protocolo foi formado em Maio de 2004 (IEEE, Maio de
2004). Em junho de 2011, o último Draft foi fechado (IEEE, Julho de 2011), e o padrão foi
incorporado ao IEEE 802.11 em sua versão 802.11-2012 (nesse momento, a mais recente).
O principal objetivo do IEEE 802.11s é permitir a criação de um mecanismo de comunicação utilizando múltiplos saltos, que é conhecido como uma rede em malha. Na
infraestrutura convencional do IEEE 802.11 as estações (STA) se comunicam com um
dispositivo central chamado ponto de acesso, que provê um BSS (Basic Service Set). No
IEEE 802.11s não existe a função de AP . Cada nó da rede, ou mesh STA, que é chamado
de Mesh Point, ou MP , pode se conectar a qualquer outro MP.
Desse modo, em uma rede mesh, temos a formação de um BSS diferente, chamado de
MBSS (Mesh Basic Service Set). Conforme citado, nesse Basic Service Set específico, não
há a presença de access points, e sim somente STAs mesh. Logo, fica claro que uma estação
mesh IEEE 802.11s não pode comunicar-se com uma STA baseada em infraestrutura (AP)
de forma direta. Para existir essa interação entre BSS e MBSS, temos a necessidade de
um componente adicional, chamado Mesh Gate. Um Mesh Gate nada mais é do que uma
STA mesh que tenha acesso a mais de um distribution system(DS), uma delas sendo pelo
menos uma MBSS e outra BSS (HENRY, 2011).
Em (NWUP; AKANDE, 2009), temos uma larga definição de alguns detalhes do IEEE
802.11s que iremos tratar nesse documento de forma resumida.
Em redes mesh, algo que normalmente tem uma complexidade razoável para os nós
participantes da rede é o cálculo de caminhos para os outros participantes da rede. O IEEE
802.11s utiliza por padrão o Hybrid Wireless Mesh Protocol (HWMP ) como protocolo de
roteamento em layer 2 para nós que não são seus vizinhos imediatos.
30
O HWMP pode trabalhar de duas formas distintas. No primeiro modo, chamado de sob
demanda, sempre que um nó precisa se comunicar com outro, e este não está na sua tabela
de vizinhos, e tampouco tem algum caminho conhecido na sua tabela de roteamento layer
2, ele envia uma mensagem em broadcast com um pedido chamado Path Request (PREQ
). Todos os nós que não conhecem o endereço MAC para quem está sendo solicitado o path
reenviam essa mensagem. Uma vez que algum nó tenha em sua tabela de vizinhos esse
endereço MAC, ele prepara uma outra mensagem, chamada de Path Reply (PREP ) com
a informação solicitada. Em todo nó que passe essa mensagem PREP, é incrementado um
contador de quantidade de nós, de forma que o solicitante saiba qual a distância até o nó
solicitado. Isso é importante, pois é provável que mais de um nó responda a mensagem, e
ele deverá determinar qual o caminho mais curto.
Já no segundo modo, chamado de modo proativo, temos a figura de um nó central
chamado root, responsável por manter caminhos para todos os nós. Esse nó root envia
periodicamente uma mensagem chamada de Root Announcement (RANN ), de forma que
todos os nós que recebam essa mensagem são capazes de construir um caminho até o nó
root, de forma análoga ao que acontece no PREP. Quando outros nós quaisquer que não
sejam root desejem comunicar-se, e ambos não tem caminhos conhecidos, eles enviam o
primeiro quadro diretamente para o nó root, e este encaminha para o nó correto, pois já
deve ter a lista de todos os MACs participantes da rede, uma vez que recebeu respostas
do RANN enviado anteriormente. Quando nó recebe do root uma mensagem de dados de
outro nó, eles podem opcionalmente trocar mensagens de PREP e PREQ para criar um
caminho mais eficiente (BARI; ANWAR; MASUD, 2012) que através do nó raiz.
É possível ver na prática esses caminhos criados através do comando no Linux
iw dev mesh0 mpath dump, onde ele mostrará uma lista de endereços conhecidos, e
o caminho (endereço MAC de vizinhos) para chegar até eles. Pode-se notar que no ponto
de vista do cliente essa é uma estratégia gulosa, ou míope, pois ele só precisa conhecer
seus vizinhos imediatos, não precisando conhecer todo o caminho até determinado nó.
Embora existam diversos outros detalhes a respeito do IEEE 802.11 (incluindo o
adendo IEEE 802.11s), nessa seção foram apresentados apenas os pontos principais para
compreensão de como essas redes podem ser emuladas usando o trabalho aqui proposto.
2.2.1
O Módulo mac80211
No Linux, temos dois tipos de implementações possíveis para hardwares baseados em
IEEE 802.11. A primeira e mais antiga é chamada de FullMAC. Nesse tipo de implemen-
31
tação, a Media Access Control Sublayer Management Entity, ou MLME é completamente
implementada na camada PHY, ou seja, no firmware da placa de rede sem fio. Nesses
casos, o fabricante é quem normalmente disponibiliza o firmware e tem o trabalho de
implementar toda a camada MAC (ROSEN, 2009).
Entre as funções normalmente executadas pela MLME, temos:
• Autenticação,
• Associação,
• Envio e recebimento de beacons,
• Timing Synchronization Function (TSF ).
Já nas implementações baseadas em SoftMAC, temos o uso do módulo mac80211 para
realizar essas funções da MLME. O mac80211 começou a ser desenvolvido em 2001 e foi
incorporado à mainline 1 do Kernel do Linux em sua versão 2.6.22, em Julho de 2007.
Como é percebido, no caso de se usar SoftMAC, o fabricante só precisa se preocupar
com a camada PHY, e quando existir interação entre a camada MAC e a PHY, realizar
chamadas para o mac80211. Tal modelo simplifica bastante o desenvolvimento de drivers
para interfaces de rede wireless além de garantir uma melhor implementação da camada
MAC.
Outra vantagem da utilização do SoftMAC ao invés do FullMAC é a padronização.
Uma vez que todas as interfaces de rede sem fio usem esse módulo para implementação
do MLME, alterações e novas funções adicionadas nesse módulo estarão disponíveis para
todos os hardwares que façam uso desse módulo. Nesse caso em especial, será visto mais a
frente que utilizamos exatamente dessa vantagem para realizar as modificações necessárias
somente no módulo mac80211, permitindo o uso de uma vasta quantidade de interfaces
que o usam, inclusive virtuais.
No caso do SoftMAC, além de interfaces físicas, temos a possibilidade de uso do
mac80211_hwsim, que é um módulo que cria interfaces sem fio virtuais, mas por concepção, dentro de uma mesma máquina. Como ele também faz uso do SoftMAC para
implementação da MLME, também foi possível usá-lo como base para esse trabalho, como
será visto adiante.
1
mainline é como é chamada a árvore principal de desenvolvimento do kernel do Linux, que é mantida
pelos principais desenvolvedores
32
3
Trabalhos Relacionados
Neste capítulo temos como objetivo relatar todos os trabalhos relacionados ao nosso
atual projeto, bem como sua influência e importância na implementação e definição do
nosso trabalho.
3.1
Network Simulator
Network Simulator é um simulador de redes baseado em eventos discretos desenvolvido primariamente para uso educacional e em pesquisas. NS-3 é um software livre,
licenciado sob a licença GNU GPLv2, e está disponível para pesquisa, desenvolvimento e
uso (ANDREEV; BOYKO, 2010).
O NS-3 (versão 3 do Network Simulator ) tem uma abordagem estritamente de simulação, ou seja, não existe emulação do meio para fora do ambiente do NS-3 no que se
refere a comunicação sem fio.
Ele possui um conjunto próprio de classes desenvolvido em C++. Um objetivo alcançado pelo NS é o grande conjunto de protocolos incorporados por suas classes, permitindo
a simulação por exemplo, desde redes ethernet até redes WiMax (IEEE 802.16)(IEEE,
2012b).
Ele não se relaciona diretamente com o LVWNet pois como já mencionado, não oferece
emulação do meio físico sem fio para máquinas virtuais ou reais, que é o principal objetivo
do LVWNet.
3.2
Projeto NCTUns
Com uma grande quantidade de definições em (WANG; HUANG, 2012), o projeto NCTuns tem uma abordagem distinta tanto do LVWNet como do NS. Como o NS, ele é
um simulador de redes, onde os quadros ou pacotes percorrem somente dentro do seu
33
ambiente interno. Contudo, ele também trabalha como emulador de redes, uma vez que é
possível interagir com o ambiente criado internamente no próprio NCTuns com máquinas
reais ou virtuais.
Além do ambiente de emulação provido pelo NCTuns, ele tem a possibilidade de uma
abordagem distribuída, de forma a dividir o processamento de uma grande simulação em
vários hosts.
Entretanto, apesar de também ser um emulador de redes, sua principal diferença para
o LVWNet, é que ele tende a gerar tráfego de forma artificial, sem utilizar máquinas
virtuais, nem tampouco permite o uso de hardwares reais.
3.3
Projeto mac80211_hwsim
O módulo mac80211_hwsim é um simulador de interfaces de rádio que utilizem o
protocolo IEEE 802.11 sob a camada MLME do mac80211. Com ele é possível gerar
uma grande quantidade de interfaces de radio IEEE 802.11 em uma mesma máquina de
modo que se possa testar uma grande variedade de funcionalidades e ferramentas em
user space. Pode-se, por exemplo, criar duas interfaces de rede para testar o hostapd e o
wpa_supplicant, que seriam utilizadas para criar um ponto de acesso sem fio e um cliente
para esse ponto de acesso, respectivamente.
O principal objetivo do mac80211_hwsim é facilitar o trabalho dos desenvolvedores
na hora de testar novas implementações do mac80211, hostapd e wpa_supplicant. Os
radios simulados não têm limitações do hardware real, então é simples gerar ambientes
de testes que sempre reproduzam o mesmo resultado. Ainda aproveitando que a operação
dos rádios é simulada, qualquer canal pode ser usado para testes, independente de regras
regulatórias do país (WIRELESS, 2014).
Contudo, esse projeto trás lacunas relativas justamente à interação com equipamentos
e hardwares reais, e também ao seu uso de forma distribuída (em vários computadores).
Tais lacunas pretendem ser preechidas pelo LVWNet.
3.4
Projeto Wmediumd
Uma vez que o módulo mac80211_hwsim não provê nenhuma técnica de simulação de atraso, perda ou erros no meio até o momento, o projeto wmediumd se encaixa
34
justamente nessa lacuna.
O wmediumd foi criado para possibilitar a emulação de ambientes sem fio especificamente para o mac80211_hwsim. Com essa emulação do meio, o projeto busca permitir
a programadores de drivers para dispositivos IEEE 802.11 criarem um ambiente de desenvolvimento e testes em um único computador, economizando tempo e dinheiro (ILLáN,
2013). A versão atual somente emula o comportamento do meio criando perdas dependendo de probabilidades, mas não permite o uso de padrões de mobilidade entre os rádios,
sendo mencionado no documento (ILLáN, 2013) como sugestões para trabalhos futuros.
Ele utiliza a interface Netlink para inserir atrasos e erros inerentes a comunicações no
mac80211_hwsim. Contudo, ele faz isso para todas as interfaces dentro do mesmo host.
O projeto LVWNet elimina essa restrição permitindo o uso de várias máquinas, cada uma
com sua interface de rede.
35
4
Visão Geral do Projeto LVWNet
Como já brevemente mencionado na introdução, o projeto Linux Virtual Wireless
Network (LVWNet), que este trabalho utilizou como base e estendeu suas funcionalidades,
tem como objetivo inicial a criação de uma rede mesh utilizando uma infraestrutura de
máquinas virtuais, de forma a permitir testes utilizando qualquer protocolo que possa
fazer uso da pilha de rede dessas máquinas, facilitando o estudo e desenvolvimento de
novos protocolos e aplicações.
Ele pode ser encontrado no github, no endereço https://github.com/lvwnet/main, na
forma de um projeto aberto (público), contudo com commits controlados.
O LVWNet original tem em sua arquitetura duas peças principais, que são o controlador de topologia e o nó participante da rede. O controlador de topologia é o responsável
pela emulação do meio físico (no caso, o ar), e o nó participante da rede é uma máquina
virtual que executa uma versão modificada do mac80211_hwsim (módulo que permite
a criação de interfaces wireless compatíveis com IEEE 802.11), versão essa que encaminha
todos os quadros que deveriam ir para a camada PHY para o controlador de topologia.
Isso é feito encapsulado os quadros IEEE 802.11 em quadros ethernet. Foi utilizado um
código de tipo (campo Tipo do quadro Ethernet) específico para identificar esses quadros.
Já a máquina controladora de topologia, ao receber um quadro de um nó, verifica que
outros nós estão na vizinhança dele (ou seja, no alcance do sinal), e encaminha o quadro
para todos eles, novamente encapsulados em um quadro ethernet. Quando o nó recebe um
quadro ethernet com o código do LVWNet no campo de Tipo, ele verifica se veio do nó
controlador de topologia, desencapsula o quadro, e o envia novamente para a pilha IEEE
802.11, como se tivesse sido recebido pela camada PHY.
O objetivo inicial dessas modificações era permitir a criação de uma rede em malha
para testes do IEEE 802.11s, onde teríamos uma configuração em grade x, y, para criação
de uma rede de por exemplo 3x3 (com 9 nós), ou 4x4 (com 16 nós).
Para permitir a criação de uma malha em mesh de alta densidade, o LVWNet utiliza
36
técnicas de virtualização de máquinas, onde o hardware real é compartilhado, permitindo
a execução de diversas máquinas virtuais no mesmo hardware. A peça principal dessa
infraestrutura é o hypervisor, que faz o controle de acesso ao hardware (quando existe
hardware já pronto para virtualização que permita tais funções) ou até mesmo a emulação
de itens quando não há hardware pronto para virtualização.
Apesar de inicialmente ser focado em redes mesh, não há nenhum impedimento na
utilização dessa infraestrutura para qualquer protocolo derivado do IEEE 802.11, que seja
implementado pelo módulo mac80211 do Linux.
Conforme já citado no capítulo 1, este trabalho estendeu as funcionalidades do projeto
original do LVWNet inserindo novos recursos. Na próxima seção são apresentados maiores
detalhes do funcionamento do LVWNet original e na seção 4.2 os novos recursos propostos
nesse trabalho são apresentados em detalhes.
4.1
LVWNet original
Nesta seção serão descritos os componentes de uma rede LVWNet que segue o modelo original, ou seja, sem modificações, bem como a interação entre eles. Também serão
tratados aqui as lacunas e suas possíveis melhorias a serem implementadas.
4.1.1
Máquina controladora de topologia
A máquina controladora de topologia é a responsável por simular o meio físico sem fio.
Os nós participantes da rede não tem conhecimento da existência dela (na perspectiva da
pilha IEEE 802.11), uma vez que somente o módulo LVWNet que está carregado nessas
máquinas sabe de sua existência. Para isso, na carga desse módulo deve-se informar o parâmetro ctrladdr=xx:xx:xx:xx:xx:xx, onde xx:xx:xx:xx:xx:xx é o endereço
MAC ethernet da máquina de controle de topologia.
Essa máquina controladora de topologia host tem uma tabela onde guarda os endereços MAC das interfaces ethernet e sua posição no formato de um grid (X,Y ). A definição
do alcance de sinal de cada nó é feita utilizando os endereços Ethernet. Desse modo, e
com a configuração em grid que é suportada, ela somente encaminha os quadros entre os
vizinhos de acordo com a posição no grid. Na figura 3 temos um exemplo de uma rede em
grid de tamanho 3 x 3.
Uma vez o módulo LVWNet dessa máquina recebe um quadro ethernet identificado
37
como sendo de um nó participante, ele verifica o endereço MAC ethernet da origem, e
busca em sua tabela quais os vizinhos desse nó. Depois disso, ele modifica o cabeçalho
ethernet, coloca seu próprio endereço MAC como origem, e cria uma cópia do quadro para
cada nó de destino, de modo a simular o alcance entre os nós em uma rede IEEE 802.11.
Um possível problema nessa abordagem é a saturação da máquina de controle de
topologia, pois todos os quadros IEEE 802.11 necessariamente serão encaminhados para
ela.
4.1.2
Nó participante da rede
Uma estação ou nó se torna participante dessa rede através do encaminhamento dos
quadros para a máquina de topologia. Ela só “conhece” seus vizinhos, pois como já mencionado, a máquina controladora de topologia só encaminha os quadros para os vizinhos.
Ela não tem conhecimento direto da existência do controlador de topologia, pois o
módulo LVWNet deixa isso completamente transparente para o restante da pilha IEEE
802.11. Observa-se que na imagem 3 não existe a figura da máquina controladora de
topologia, contudo na figura 4, que é a representação em camada de enlace ethernet, layer
2 quando usado como referência o modelo OSI de 7 camadas, vemos a existência do
controlador de topologia, e como ele está conectado a uma rede com o mesmo domínio de
broadcast dos demais nós participantes.
Figura 3: Conexões de uma rede mesh 3 x 3 conforme visto pelas máquinas virtuais.
38
Todo quadro que deveria ser enviado através da interface wlan0 é redirecionado e
encapsulado em um quadro ethernet, de ethertype 1 0x0808, uma vez que esse é o valor
utilizado para indicar quadros do LVWNet.
No payload do quadro ethernet enviado é adicionado um pequeno cabeçalho, antes
do quadro IEEE 802.11 encapsulado. Esse cabeçalho nessa versão original do LVWNet
serviu apenas como um campo de reserva para uso futuro. Portanto, não era de fato
utilizado. Como será mostrado mais adiante nesse texto, ele passou a ser fundamental
para a implementação dos novos recursos.
Figura 4: Conexões reais de uma rede mesh 3 x 3 criada pelo LVWNet.
Quando o quadro Ethernet reencaminhado pela máquina controladora de topologia
chega ao nó de destino, o LVWNet retira o quadro IEEE 802.11 que está encapsulado
dentro do quadro ethernet e o envia para a pilha IEEE 802.11 como se tivesse sido recebido
por um dispositivo wireless real.
4.1.3
Hypervisor
Embora o LVWNet possa ser utilizado em computadores reais, dada a grande facilidade proporcionada pela virtualização é recomendado que sejam utilizadas máquinas
virtuais para a criação das redes. Isso facilita inclusive a criação de uma rede com uma
grande densidade de nós.
1
Ethertype: campo do quadro ethernet IEEE 802.3 que sinaliza o tipo do protocolo encapsulado dentro
do payload do quadro ethernet
39
Estamos utilizando para nossos testes máquinas virtuais criadas com o KVM . Contudo, provavelmente qualquer outro hypervisor pode ser utilizado, apesar dessa afirmação
carecer de testes mais profundos.
Em nossos testes, utilizamos uma máquina virtual com recursos bem reduzidos, pois o
objetivo era testar somente a pilha de rede, com aplicações simples baseadas em console.
Nessa nossa configuração, utilizamos máquinas com 256 Mb de RAM e um processador com 1 core. Além da configuração reduzida de memória, também utilizamos o KSM
(MACHINE, 2014), que permite o compartilhamento de páginas de memória de processos
que estejam sendo executados em um host. Isso nos permitiu a execução de pouco mais
de 20 máquinas virtuais em um host com apenas 4Gb de RAM.
4.2
Componentes Modificados do LVWNet
Tendo como objetivo eliminar as limitações do LVWNet, foram realizadas diversas
modificações no projeto original que serão detalhadas nas sub-seções a seguir.
De modo resumido, as alterações foram: i) Criar um protocolo que permita o registro
dinâmico dos nós na rede; ii) Permitir a interação da rede virtual com nós com hardware
real de modo a possibilitar a utilização de nós com interfaces de rede reais em uma rede
LVWNet; iii) Definir um esquema de posicionamento dos nós no espaço utilizando coordenadas x, y e z para permitir que se obtenha liberdade no posicionamento dos nós, antes
limitados a uma grade x, y. Tal esquema é fundamental para a implementação de suporte
a mobilidade; iii) Melhorar a comunicação entre os nós, uma vez que a forma de emulação
do meio físico original faz com que todos os quadros passem pelo controlador de topologia.
Nessa configuração, é de se esperar que uma grande quantidade de nós gere uma limitação
decorrente da largura de banda ou até mesmo da capacidade de processamento da máquina de topologia. Para isso foi criado um mecanismo de comunicação descentralizado,
mais semelhante a um meio real, onde cada nó envia os quadros diretamente para os seus
vizinhos alcançáveis, que são identificados através de uma tabela local de vizinhos. Essa
tabela é mantida através do protocolo de registro e de envio de informações (citado no
item i).
Nesse novo modelo proposto para o LVWNet (OLIVEIRA; PINHEIRO, 2014) ainda será
utilizada uma máquina de controle de topologia, porém ela terá um uso mais restrito. Sua
função será calcular o alcance de sinal de cada nó e, desse modo, informar ao respectivo
nó quem deve receber seus quadros. Esse cálculo considera diversos parâmetros, como o
40
posicionamento do nó no espaço, e questões referentes a potência de transmissão, entre
outras. Cada nó da rede ao ter o módulo LVWNet carregado se registra na máquina de
topologia informando esses parâmetros. A comunicação entre os nós se dará de forma
direta, sem passar pela máquina de controle de topologia.
4.2.1
Posicionamento dos nós no espaço
O projeto orinalmente tratava o posicionamento dos nós como uma grade X, Y , onde
os quadros só eram encaminhados para seus respectivos vizinhos. Exemplificando, o nó
posicionado em x = 1 e y = 1, em uma rede de tamanho 3x3, seria capaz de transmitir
quadros somente para os nós localizados em x = 1,y = 2 e x = 2,y = 1.
Agora para o posicionamento dos nós não existe mais uma grade 2D, e sim um espaço
em 3D (X, Y e Z) onde o nó está, e não existe mais a figura do vizinho direto. Para o
encaminhamento dos quadros, a máquina de controle de topologia calcula quais máquinas
são alcançáveis pelo nó, usando para esse cálculo a potência do transmissor, a sensitividade do receptor e a perda em espaço livre. As questões relativas às antenas (ganhos,
características de transmissão como lóbulo) não foram levadas em consideração.
O valor padrão da sensitividade dos receptores foram definidos como -75 dBm, que é
um valor comum encontrado na maioria dos receptores fisicos. Como padrão na potência
de envio, utilizamos 20 dBm, que seria equivalente a 100 mWatts, que também é um valor
comum encontrados em transmissores físicos. Ambos os valores podem ser facilmente
alterados através de parâmetros na inicialização do módulo.
Perda em espaço livre, ou Free Space Loss (FSL ), é uma função que leva em consideração a frequência de transmissão e a distância (RACKLEY, 1995).
O cálculo da perda em espaço livre é feito através da equação 4.1, onde D é a distância
entre os nós em metros, e λ é a largura da onda de acorcom com a frequência.
LF S = 20log10
4πD
λ
(4.1)
λ também pode ser dada pela equação 4.2 onde c é a velocidade da luz no váculo em
metros por segundo e f é a frequência em Hertz. Assumimos c como uma constante de
valor 3x108 m/s.
41
λ=
c
f
(4.2)
Podemos simplificar ambas as equações 4.2 e 4.1, e já usando c como constante de
3x108 m/s, temos uma equação resultante simplificada como mostrada em 4.3. Nessa equação, a frequência é dada em M Hz e D em quilômetros.
LF S = 32.45 + 20log10 (f ) + 20log10 (D)
(4.3)
Exemplificando, em uma transmissão a 2.4GHz no primeiro canal disponível que tem
frequência de exatamente 2412M Hz, à uma distância de 80 metros, temos o valor de
78dB, como visto na equação 4.4.
LF S = 32.45 + 20log10 (2412) + 20log10 (0.08)
= 32.45 + 67.6480 + (−21.9382)
(4.4)
= 78.1598
De forma à demonstrar a influência da frequência na perda em espaço livre, está
exemplificado a seguir também em 5.8GHz, usando a mesma distância, no canal 165, que
tem a frequência de exatamente 5825M Hz.
LF S = 32.45 + 20log10 (5825) + 20log10 (0.08)
= 32.45 + 75.3059 + (−21.9382)
(4.5)
= 85.8177
Como visto em 4.5, temos uma atenuação de 85dBm para a mesma distância, em uma
frequência bem superior. Essa diferença de quase 8dBm é bastante alta, tendo em vista
que a cada 3dBm temos um aumento ou diminuição equivalente ao dobro da potência em
miliwatts.
Já o cálculo da distância no espaço é feito através da equação da distância em linha
reta entre dois pontos, dada por 4.6.
D=
p
x2 + y 2 + z 2
(4.6)
42
Onde temos que x, y e z são dados pela relação 4.7.
x = x1 − x2
y = y1 − y2
(4.7)
z = z1 − z2
O cálculo para verificação se um nó consegue “enxergar” outro é a simples relação
dada por 4.8 que deve ser verdadeira.
Srecep ≥ Ptrans − LF S
(4.8)
Na relação 4.8, Srecep é a sensitividade de recepção da interface de rede, Ptrans é a
potência de transmissão do parceiro, e LF S é a perda em espaço livre inerente a frequência
e distância da transmissão.
Contudo, existe uma proposta de melhoria do cálculo do LF S , que leva em consideração outras varíaveis, como mostrado em (LAU et al., 2011). Em trabalhos futuros,
principalmente no caso da implementação de padrões de mobilidade para os nós, o uso
dessas novas propostas de cálculos deverão ser levadas em consideração.
4.2.2
Protocolo de Registro e Informações dos Nós
Nesta sub-seção será tratado o protocolo de registro e informacões dos nós que permite
a adição de novos nós na rede de forma dinâmica. Vale ressaltar é que por causa das
informações trasmitidas por esse protocolo que também é possível realizar a comunicação
direta entre os nós e os cáculos referentes a alcance de sinal. As mensagens de registro de
nós e de informações vizinhos serão especificadas abaixo.
4.2.2.1
Mensagem de registro de nós
A primeira mensagem que um nó envia ao iniciar é a de registro, que é enviada para o
host controlador de topologia. Ela serve para informar ao controlador de topologia sobre
a existência do nó e todas as suas características.
O primeiro campo dessa mensagem, chamado de TdM, é relativo ao tipo da mensagem,
que tem valor em hexadecimal 0x02. Os campos seguintes, pos_x, pos_y e pos_z são
relativos à posição do nó no espaço, na suas coordenadas x, y e z respectivamente. Essas
coordenadas deverão ser dadas em metros, e necessariamente deverão ter valores positivos.
43
Após os campos relativos às posições do nó, o campo power_tx_dbm é responsável
por informar a potência de transmissão do nó. Esse valor deverá ser informado em dBm,
e poderá ser positivo ou negativo. Um valor comum encontrado em adaptadores para
desktops ou notebooks é 20dBm, o que seria equivalente a 100 miliWatts. O próximo
campo, o sens_rx_dbm tem como função informar qual a sensitividade do receptor
que está se registrando, em dBm. Esse campo também pode receber valores positivos ou
negativos, apesar dos valores encontrados em interfaces são comumente negativos (por
volta de -70dBm, em interfaces sem fio para desktops ou notebook por exemplo).
O último campo dessa mensagem aqui definida é o channel, que representa o canal
em seu id de acordo com o IEEE 802.11. Isso significa que nesse campo não deve ser
informada a frequência. Por exemplo, no caso de se usar a frequência de 2412 MHz,
deverá ser informado o canal IEEE 802.11 correspondente, que nesse caso é 1. Apesar de
estar sendo enviado, ainda não está implementado completamente no código como será
visto na seção de implementação.
Figura 5: Cabeçalho LVWNet usado para registro do nó.
O nó envia a primeira mensagem de envio tão logo o módulo esteja carregado. Depois
disso, ele periodicamente (definida através do #define LVWNET_REG_TIMER) reenvia
mensagens de registro. Tais transmissões apesar de redundantes, são importantes pois não
são realizados procedimentos de confirmação de recebimento de mensagens (ACK ).
4.2.2.2
Mensagem de informações de nós
Uma vez que o controlador de topologia já tenha ao menos dois nós que sejam comunicáveis entre si em sua lista, ele começa o envio de mensagens de informações dos
vizinhos. Por vizinhos, entenda-se como os nós que estão no alcance de sinal do referido
nó.
44
Essa mensagem, como pode ser vista na figura 6, utiliza o tipo 0x06 como identificador
de mensagem LVWNet. Esse TdM, assim como na mensgem de registro identifica o tipo
de mensagem que está logo após esse campo.
Após o TdM, o campo peer_mac traz o endereço MAC ethernet do vizinho a qual
essa mensagem corresponde. Tal endereço é aprendido pelo controlador de topologia ao nó
se registrar pela primeira vez usando o campo de endereço de origem do quadro ethernet.
O terceiro campo power_rx_dbm, informa com que potência o nó consegue receber o
sinal do vizinho. Essa potência é calculada através da sensitividade do receptor do nó
que está recebendo esta mensagem, a potência de transmissão do nó vizinho e a perda
decorrente da distância (perda em espaço livre).
O último campo, aqui chamado de delay informa o atraso inerente ao meio e à
eletrônica. Essa última funcionalidade de atraso está prevista na mensagem, contudo
ainda não implementada, não havendo diferença na transmissão, independente do tempo
de atraso enviado.
No campo de potência de recepção, dada a unidade de potência dBm poder ser positiva
ou negativa, foi necessário usar dois bytes, do contrário estaríamos limitados a -127 a +127
dBm, que apesar de ser um range bem elástico, possível de se alcançável dependendo da
sensitividade e potência do transmissor. Já no caso do atraso, é do tipo unsigned, o que
nos dá um range entre 0 e 65535. Tendo em vista que a unidade aqui são milissegundos,
teríamos um tempo máximo de atraso de 65 segundos para uma possível transmissão.
As mensagens são enviadas em cada inclusão de novos nós na infraestrutura. Também
são enviadas periodicamente informações sobre todos os vizinhos de todos os nós. O tempo
em que isso ocorre é definido no #define LVWNET_INFO_TIMER. Um estado especial
dentro da mensagem de informação sobre vizinhos é quando a potência de RX enviada é
menor ou igual a -256dBm. Nesse caso, o nó entende que esse vizinho agora é inalcançável,
e é removido de sua lista local de vizinhos.
4.2.3
Diagramas de trocas de mensagens
De forma a facilitar o entendimento e documentar a implementação de forma adequada, temos 2 diagramas de trocas de mensagens entre os nós e o controlador, com uma
visão de sequência entre cada uma das mensagens.
45
Figura 6: Cabeçalho LVWNet usado para informar um nó das configurações dos seus vizinhos.
4.2.3.1
Caso 1: 3 nós são alcançáveis entre si
No primeiro diagrama da figura 7, temos 3 nós e um controlador. Nesses três nós,
a potência de transmissão, diminuida da perda em espaço livre ainda é maior que a
sensitividade de transmissão para todos os nós, ou seja, todos os 3 nós são alcançáveis
entre si.
Figura 7: Disposição dos nós do diagrama de troca de mensagens da figura 8.
Assumimos que os 3 nós são ligados sucessivamente, de forma a exemplificar de forma
mais detalhada o processo de registro, envio de informações sobre vizinhos e troca de
dados entre todos os nós.
Quando o nó 01 envia uma mensagem de registro, nenhum outro nó está registrado
no controlador, o que faz com que ele somente armazene a informação de registro, sem
nenhuma ação imediata. A ação de registro iniciada pela mensagem de registro do nó
02 faz com que o controlador realize os cálculos de distância entre os nós existentes,
nesse caso somente 2, e de alcance de potência. Uma vez determinado que os nós 01 e 02
são alcançáveis entre si, ele envia uma mensagem para cada um informando sobre seus
vizinhos, e detalhes como possíveis atrasos inerentes a distância ou à interface de rede
sem fio e a potência de recepção calculada mais cedo.
46
Figura 8: Diagrama de troca de mensagens com os nós 01, 02 e 03 alcançáveis entre si.
Uma vez que os nós 02 e 01 se conhecem, começam a trocar dados de forma direta,
sem participação ativa da máquina de controle de topologia.
Após o nó 03 se registrar no controlador de topologia, é calculada a distância e potência
de alcance dos nós já existentes, e como nesse exemplo pressupomos que todos os nós são
alcançáveis entre si, esta é suficiente para que os nós 1, 2 e 3 façam parte de uma mesma
rede. Após esse cálculo, é enviado para o nó 01 e 02 uma mensagem com informações
sobre o novo vizinho, o nó 03. E para o nó 03 são enviadas 2 mensagens, uma contendo
informações sobre o nó 01, e outra contendo informações sobre o nó 02.
Uma vez que todos os nós são alcançáveis, podem realizar trocas de quadros 802.11
encapsulados em quadros ethernet.
4.2.3.2
Caso 2: Nó 01 e 02 são alcançáveis entre si, nós 03 e 04 também, mas
não entre eles
Nesse caso em específico, temos dois clusters, cada um com 2 nós, isolados entre si.
No primeiro temos o nó 01 e 02, e no segundo cluster temos o nó 03 e 04.
47
Na figura 9 temos a uma possível representação de como esses nós poderiam estar
dispostos, deixando clara a não comunicação entre os dois agrupamentos de nós. Já na
figura 10, temos o diagrama completo de troca de mensagens de todos os nós.
Figura 9: Disposição dos nós do diagrama de troca de mensagens da figura 10.
No início, temos o registro dos nós 01, 02 e 03 no controlador de topologia. Contudo,
nesse momento ao calcular a distância entre os nós, é verificado pelo controlador que os
nós 01 e 02 não tem potência ou sensitividade suficiente para comunicar-se com o nó
03, e vice-versa. Dessa forma, o nó 03 não recebe nenhuma mensagem de informação de
vizinhos nesse momento, e o nó 01 recebe informações sobre o nó 02, e o nó 02 recebe
informações sobre o nó 01, como esperado.
Figura 10: Diagrama de troca de mensagens com os nós 01, 02 alcançáveis entre si, nós 03 e
04 também, mas não entre eles.
48
Uma vez que o nó 04 registra-se no controlador de topologia, este ao realizar os
cálculos de potência e verificar que os nós 03 e 04 estão próximos o suficiente para poder
comunicar-se, envia uma mensagem para o nó 03, contendo informações sobre o nó 04, e
outra mensagem ao nó 04, contendo informações sobre o nó 03. Em nenhum momento o
nó 03 e 04 recebem qualquer mensagem de informações do nó 01 ou 02 e vice-versa.
4.2.4
Interação da rede LVWNet Virtual com hardwares reais
A interação com equipamentos reais permite que diversas máquinas reais que possuem
apenas interfaces Wifi físicas, ou seja reais, participem da rede virtual. Para isso, uma
(ou mais) máquina que possui uma interface Wifi real, e uma interface Ethernet, deve
executar o software LVWNet de modo a fazer a interligação da rede real com a virtual.
Pode existir diversas outras máquinas reais (e que não usam o LVWNet) interconectadas a esse host que faz a ligação com a rede virtual, formando, por exemplo, uma rede
em malha sem fio. Nessa situação, o host real estabelece peer-links tanto com os guests
virtuais que estão executando o módulo do LVWNet como com os outros hosts reais que
não tem qualquer modificação.
A máquina controladora de topologia não sabe da existência dessas máquinas, mas
elas conseguem se comunicar com as máquinas virtuais, sem saber que elas são de fato
virtuais.
Essa máquina que faz a interligação das duas redes aparecerá para a rede virtual
como se fosse também uma máquina virtual. Ou seja, para a máquina controladora de
topologia não existe diferenca entre essa máquina real ou uma máquina virtual. Desse
modo, quando a máquina real é inicializada ela se registra na máquina de topologia do
mesmo modo que qualquer outra máquina virtual faz, e sua interface Wifi real não é vista
por ela. É importante observar que nesse caso não será criada um interface Wifi virtual
quando o módulo LVWNet é carregado na máquina real, uma vez que será utilizada a
interface Wifi real.
Pode-se observar que existem três situações para tratamento de quadros, que são
descritas a seguir.
A primeira situação se refere ao caso onde a máquina real recebe um quadro em sua
interface Ethernet vindo da rede virtual. Nesse caso, o quadro IEEE 802.11 encapsulado
no Ethernet deve ser encaminhado para processamento pelo mac80211 da máquina como
se tivesse sido recebido pela sua interface Wifi real.
49
A segunda situação se refere ao caso onde a máquina real recebe um quadro em sua
interface Wifi real, vindo portanto, de alguma máquina da rede sem fio real onde ele está
conectado. Nesse caso, não existe nenhum procedimento especial a ser feito, de modo que
o quadro IEEE 802.11 é encaminhado para processamento pelo mac80211 da máquina
local.
A terceira situação é a mais interessante e se refere ao caso onde a máquina real
gera um quadro IEEE 802.11 para ser retrasnmitido. Nesse caso além de enviar o quadro
normalmente pela sua interface Wifi real, deve-se também gerar uma cópia do mesmo,
encapsular esse quadro em um quadro LVWNet e transmití-lo pela interface Ethernet.
Naturalmente, esse quadro encapsulado será transmitido para todos os nós que são alcancáveis por essa máquina na rede virtual
50
5
Detalhes de Implementação
Nesse capítulo serão apresentados os detalhes de implementação de todas as propostas
de alteração no LVWNet, como a parte relativa ao ingresso de máquinas com interfaces de
rede sem fio reais em uma rede virtual LVWNet, a implementação do protocolo de registro
e suas mensagens. Protocolo esse que permitiu o posicionamento de nós no espaço além da
comunicação direta entre nós, elimitando a necessidade de encaminhamento de quadros
para o host de topologia.
5.1
Ingresso de máquinas com hardware sem fio real
em uma rede LVWNet
Nessa seção serão apresentados os detalhes de implementação relativos a porção do
código destinada a realizar a inserção do host com interfaces sem fio reais em uma rede
com várias máquinas virtuais.
5.1.1
Tomadas de decisões para o projeto
Como já mencionado no capítulo introdutório, o projeto tem como um de seus objetivos permitir a interação de uma rede mesh IEEE 802.11 real, com uma rede criada pelo
LVWNet, para que com isso possamos aumentar a funcionalidade do projeto, permitindo
testes mais extensos e com hardwares reais.
Para atender tal objetivo, duas estratégias poderiam ser adotadas. A primeira seria
a criação de uma interface do tipo monitor, que funciona de forma promíscua, ou seja,
ela encaminha para a camada superior da pilha de protocolos todos os quadros recebidos,
mesmo que não tenham como destino a própria interface ou endereços de broadcast.
Nessa abordagem, teríamos um processo em espaço de usuário que seria encarregado
de analisar essa interface, e encaminhar para uma interface real os quadros recebidos. De
51
forma análoga, teríamos que utilizar a mesma estratégia também na interface real, sendo
necessário na verdade a criação de duas interfaces do tipo monitor.
Sua principal vantagem seria a facilidade de implementação, pois toda a programação seria feita em espaço de usuário, podendo inclusive se utilizar de linguagens de
alto nível de abstração, como Phyton, onde temos um conjunto de módulos chamado
Scapy(COMMUNITY, Abril 2010), que permite a manipulação de quadros IEEE 802.11.
Por outro lado, a principal desvantagem dessa abordagem é justamente a redução
do desempenho decorrente da utilização do espaço de usuário para o desenvolvimento.
Desse modo, poderíamos ter problemas de escalabilidade em redes de grande porte. Outra
desvantagem seria a dificuldade de embarcar tal solução em equipamentos com poder de
processamento e armazenamento limitados, como pontos de acesso ou roteadores. Tais
equipamentos normalmente não trazem nenhuma ou quase nenhuma implementação do
python dentro deles, impossibilitando ou dificultando muito seu uso de forma embarcada.
A outra estratégia possível de ser utilizada seria a programação em kernel space,
criando-se um módulo para o kernel e realizando-se modificações onde fossem necessário
dentro de sua árvore principal. Essa foi a estratégia adotada para o projeto pois resolve
as duas limitações existentes na estratégia anterior.
Desse modo, o módulo LVWNet se registra como manipulador do protocolo tipo
0x0808, desencapsula o quadro IEEE 802.11 e o injeta na interface wireless real. Vale
ressaltar que 0x0808 foi o valor escolhido para indicar a presença de um quadro LVWNet
no payload do Ethernet. Para o recebimento através da rede ethernet do quadro, foi
somente necessária a criação de um módulo para tal.
Já no envio de um quadro através da interface de rede real wireless, seria necessário
realizar uma interceptação desse quadro antes dele ser enviado e liberado, encapsulá-lo
dentro de um quadro ethernet de ethertype 0x0808, e dependendo da versão do
LVWNet, encaminhá-lo para o controlador de topologia, ou diretamente para os vizinhos
e posteriormente permitir que esse quadro prossiga seu caminho natural, sendo enviado
para a camada MLME da interface de rede sem fio.
Para tal procedimento, foi necessária a modificação do módulo mac80211 original,
sendo inseridos algumas funções que nos permitissem a criação da cópia do quadro e
encaminhamento para outro módulo. Como será visto, tentamos realizar o mínimo de
alterações dentro do módulo original, concentrando o desenvolvimento em nosso próprio
módulo.
52
5.2
Implementação
Como utilizamos a estratégia de programação em espaço de kernel, foi criado um
módulo, chamado de lvwnet_node, em referência a ser um nó, e não um controlador
para o projeto LVWNet.
Ele tem como dependência somente o módulo mac80211 em sua versão modificada,
pois faz referência a chamadas externas exportadas pelo mac80211.
5.2.1
A pilha de rede do Linux
Pode-se afirmar que uma das estruturas mais importantes da pilha de rede do linux
são os socket buffers, ou simplesmente skb (MILLER, 2000).
skb é a estrutura mais básica da pilha de rede no Linux, todos os quadros1 , pacotes2 ,
e TPDUs, ou Transport PDU 3 são manipulados através dessa estrutura.
Quando um quadro é recebido por uma interface rede, ele é colocado dentro dessa
estrutura chamada skbuffer, e então passada para as camadas superiores, sempre a mesma
estrutura e o mesmo ponteiro (WELTE, 2000). Então cada camada só usa a parte que “lhe
cabe”, percorrendo no ponteiro a área que é de sua responsabilidade.
Esse tipo de estratégia evita que o quadro seja repetidamente copiado podendo gerar problemas de performance ou até mesmo memory leak, e quando isso é realmente
necessário (uma cópia), a implementação da pilha de rede do Linux dá as ferramentas
apropriadas, como a função skb_copy, que permite a cópia de forma atômica do skb para
outra variável.
5.2.2
Módulo mac80211 modificado
Como base para desenvolvimento, inicialmente usamos o kernel 3.12.8 que já trouxe
algumas modificações em relação ao último kernel marcado como long term 4 no módulo mac80211. As principais modificações foram nas funções que liberam o skb. Contudo atualmente já estamos utilizando o último kernel disponível no fedora, que é o
1
quadro é a PDU da camada de enlace (TANENBAUM; WETHERALL, 2011)
pacotes é a PDU da camada de rede (TANENBAUM; WETHERALL, 2011)
3
TPDU é a PDU da camada de transporte (TANENBAUM; WETHERALL, 2011)
4
kernels marcados como long term são aqueles que além de estáveis, são lançados somente 1 long term
por ano, e tem seu desenvolvimento com correções e garantidas por pelo menos dois anos (ORGANIZATION,
2014)
2
53
3.14.4 para todos os projetos, tanto o LVWNet em si, como para o mac80211 e para o
mac80211_hwsim.
Para permitir a comunicação entre máquinas virtuais com interfaces também virtuais com hosts reais utilizando interfaces reais, foram feitas alterações nas funções do
mac80211. Essa abordagem, como já mencionado, tem uma pequena limitação, que é
restringir seu uso a somente hardwares compatíveis com a implementação SoftMAC, onde
a camada MLME é toda implementada no módulo mac80211. Contudo, hoje já existem
muitas interfaces compatíveis com esse padrão, como por exemplo as baseadas em chipset
Atheros, Richtec (linha RT8XXX e acima) etc.
No mac80211, foi modificada a função ieee80211_tx(), que é responsável pelo
envio do sk_buff para a camada PHY. Antes do envio efetivo para a camada PHY,
o sk_buff é copiado e enviado para o módulo lvwnet_node através de apontadores
de memória, encapsulado em um quadro ethernet e enviado para os seus nós vizinhos.
Detalhes desses procedimentos serão vistos adiante, onde temos um diagrama de sequência
com as chamadas de funções envolvidas na transmissão.
Já no recebimento do quadro IEEE 802.11, não existe a necessidade de modificação do
módulo mac80211 diretamente, e sim a chamada da função ieee80211_rx_irqsafe(),
que insere o quadro recebido via ethernet diretamente na pilha IEEE 802.11. Também
serão tratados detalhes maiores sobre isso no diagrama de sequência adiante.
5.2.3
Módulo lvwnet_node
O módulo lvwnet_node é o que fica carregado no host, seja real ou virtual. Ele é
responsável tanto por receber os quadros encaminhados via ethernet e injetá-los na pilha
IEEE 802.11, como por receber os sk_buff do mac80211 modificado, encapsulá-los em
um quadro ethernet e enviá-lo para os hosts vizinhos. Também é sua função receber as
mensagens de informações sobre nós, atualizando a sua tabela interna de vizinhos, como
também enviar as informações de registros e de modificação de posição do nó. Como base
para o seu desenvolvimento foi tomado o módulo mac80211_hwsim modificado pela
versão inicial do projeto LVWNet.
5.2.4
Módulo lvwnet_controller
O módulo lvwnet_controller é o responsável por coordenar a comunicação entre os nós, atualizando suas tabelas de vizinhos, ou até mesmo encaminhando quadros,
54
dependendo do seu modo de operação.
É sua responsabilidade o envio de mensagens com informações sobre vizinhos para
os nós participantes da rede, e também a manipulação das mensagens de registro recebidas, realizando os cálculos de proximidade entre os nós determinando se existe ou não
comunicação entre eles.
5.3
O protocolo de registro e informações de nós na
rede
Nessão seção serão apresentados os detalhes de implementação do protocolo desenvolvido para o projeto LVWNet. Iremos abordar as estruturas de dados utilizadas e as
funções que são chamadas durante o processo de registro e envio de informações para os
nós. Como citado anteriormente, o protocolo desempenha duas funções separadas, sendo
utilizado pelas máquinas para se registrarem no controlador de topologia, e pela máquina
de topologia para transmitir para os nós as informações sobre quem são seus vizinhos.
5.3.1
O processo de registro dos nós
Como já abordado com mais detalhes anteriormente, o protocolo de registro é utilizado
por cada nó para transmitir ao controlador informações sobre o nó, como sua posição no
espaço (dada em coordenadas x, y e z), a potência de transmissão e sensibilidade de
recepção da interface sem fio.
De forma a aproveitar a utilização da estrutuda de dados sk_buff da pilha de rede
do Linux, criamos um struct com os campos da mensagem (código 5.1), exatamente na
ordem em que são enviados os dados na rede. Além da ordem, é importante o uso do
atributo packed no final do struct, de forma a orientar o compilador a não tentar otimizar
a alocação de memória do struct, e sim fazer sua alocação linear. Isso é importante para
que quando formos apontar o struct para o começo do payload do sk_buff (código 5.2),
a ordem dos dados seja preservada, da forma como está no código 5.2.
1
2
3
4
5
6
7
8
struct lvwnet_reg_omni_header
{
uint8_t message_code;
//1
uint32_t pos_x;
//4
uint32_t pos_y;
//4
uint32_t pos_z;
//4
int16_t power_tx_dbm;
//2
int16_t sens_rx_dbm;
//2
byte
bytes
bytes
bytes
bytes
bytes
55
9
10
uint16_t channel;
} __attribute__ ((packed));
//2 bytes
Código 5.1: Struct da mensagem de registro do LVWNet
No struct mostrado no código 5.1, pode-se observar que algumas variáveis como message_code, as variáveis reponsáveis pelas coorenadas x, y e z, e o canal são todas do tipo
unsigned, o que significa que nenhum bit do do tipo (por exemplo, o tipo uint8_t tem
1 byte) é utilizado para alocação do sinal, e por definição todos os valores são positivos. Contudo, informações como potência em dBm, necessariamente tem que ser tratadas
usando valores tanto negativos como positivos.
1
2
3
4
struct lvwnet_reg_omni_header* lh_reg_omni=NULL;
//...
lh_reg_omni = (struct lvwnet_reg_omni_header *) skb_recv->data;
//...
Código 5.2: Apontador do payload do skb para o struct da mensagem de registro
Ao se carregar o módulo, o timer inicia com um tempo de 5 segundos, o que significa
que depois de iniciado, ele irá esperar 5 segundos para enviar a primeira mensagem de
registro para o controlador de topologia. Depois do primeiro timer, ele é redefinido de
forma que a próxima mensagem de registro seja enviada depois de TIMER_SEND_REG
5
segundos.
5.3.2
O protocolo de informações sobre vizinhos
Inicialmente o projeto LVWNet previa que toda comunicação entre os nós necessariamente deveriam passar pelo host controlador de topologia. Contudo, isso pode gerar
problemas de escalabilidade em redes com grandes quantidades de nós.
Um dos motivos da criação do protocolo para registro de nós e de envio de informações
sobre vizinhos foi justamente a retirada dessa limitação, permitindo que os nós possam
comunicar-se entre si diretamente. Desse modo, o controlador de topologia age apenas
como um supervisor, que informa aos nós o alcance do seu sinal, para que os quadros
possam ser encaminhados diretamente para os seus vizinhos.
Temos uma função no controlador de topologia responsável por calcular os vizinhos
de cada nó. Essa função é chamada em duas ocasiões. Na primeira, quando um novo nó
é inserido na lista de nós do controlador de topologia, ou seja, quando existe um novo
pedido de registro, e na segunda, quando o timer é disparado, que tem o tempo definido
5
valor definido no arquivo lvwnet_proto.h em com o valor de 120
56
em LVWNET_SEND_INFO_NODES
6
em segundos, é alcançado. Após esse tempo, uma
mensagem informando quem são os vizinhos do nó é enviada (para cada nó da rede).
O struct que representa a mensagem da figura 6 está no código 5.3. Pelo mesmo
motivo do struct do código 5.1, ele tem a propriedade packed, de forma a orientar ao
compilador não tentar otimizar a organização das variáveis na memória (FOUNDATION,
2002), ocupando o mínimo de memória possível.
Um detalhe de implementação que vale ser mencionado, foi a impossibilidade de chamadas da biblioteca math.h dentro do módulo. Chamadas para essa biblioteca não são
possíveis em kernel space. Isso dificultou de forma razoável o cálculo dos vizinhos dos
nós, tendo em vista que os cálculos de LF S envolvem funções de log, que não são simples
de ser realizadas somente com operações básicas, como as disponíveis kernel space.
Uma estratégia utilizada foi o cálculo prévio da perda em espaço livre de todas as
frequências em uma faixa de distância entre 1 metro a 100 Km. Dada a característica
logarítima do dBm, para cada frequência, tivemos por volta de 120 valores possíveis de
perda em espaço livre. Esse cálculo foi realizado também para cada uma das frequências
reguladas pelo IEEE 802.11, indexada pelo número do canal da frequência, de forma a
facilitar a busca, evitando percorrer o vetor de frequências sempre.
Uma vez explicado esse detalhe de implementação, fica claro que nosso módulo só
pode realizar simulações para uma distância máxima de 100 Km. Contudo, em situações
reais isso já é bem aceitável, dado que em grandes distâncias a comunicação sem fio
em frequências da ordem da utilizada pelo IEEE 802.11 (entre 2.4 e 5.8 GHz) é muito
suscetível a interferências e a atenuações decorrentes da característica concêntricas das
zonas de Fresnel.
O resultado desses cálculos foram todos encapsulados no arquivo lvwnet_lfs.h.
Lá também estão as funções de cálculo de distância e de busca desses valores nos vetores
e estruturas definidas.
1
2
3
4
5
6
7
struct lvwnet_peers_info_header
{
uint8_t message_code;
unsigned char peer_mac[ETH_ALEN];
int16_t power_rx_dbm;
uint16_t delay;
} __attribute__ ((packed));
//1
//6
//2
//2
byte
bytes
bytes
bytes - in ms
Código 5.3: Struct da mensagem de informações de vizinhos do LVWNet
6
valor definido no arquivo lvwnet_proto.h em com o valor de 60
57
5.4
Comunicação direta entre os nós
Anteriormente, já tratamos como os nós realizam seus registros no controlador de
topologia, detalhando as mensagens envolvidas e seus procedimentos internos no módulo
lvwnet_controller e lvwnet_node.
Também foi tratado com detalhes como o controlador de topologia envia informações
sobre os vizinhos de cada nó, de forma que o nó possa enviar os dados diretamente para
as interfaces ethernet dos seus vizinhos, sem passar mais pelo controlador de topologia.
Nesse momento serão observadas as chamadas de funções realizadas pelos módulos
para que seja concretizada a troca de dados entre dois vizinhos.
Na figura 11, temos um diagrama de sequência que mostra as chamadas das funções
mais importantes quando é realizado um envio de dados entre dois vizinhos. Assumimos
que os dois nós já se conhecem (sabem que são vizinhos), de modo que não existe mais a
necessidade de nenhuma outra intervenção por parte do controlador de topologia. Além
disso, é assumido que se trata de uma mensagem partindo do nó 01 para o 02.
Quando uma aplicação em user space envia um pedido de envio de dados para a pilha
de rede do Linux, e uma vez verificado que o módulo adequado para manipulação do pedido
é o mac80211, a função ieee80211_tx() é chamada. Essa função é responsável por
fazer algumas verificações básicas no skb, como o tamanho, por exemplo, e inicializar as
estruturas de transmissão. Depois disso, a função faz uma chamada a uma outra função
cujo nome é ___ieee80211_tx(), que não é exportada, ou seja, só pode ser vista
internamente no módulo. Essa função é quem realmente faz as chamadas à camada PHY.
Imediatamente antes da chamada da função ___ieee80211_tx(), onde há a liberação
e modificação do skb, é chamada a função lvwnet_send_skb_from_mac80211().
Essa função lvwnet_send_skb_from_mac80211() é responsável por enviar o
quadro skb do módulo mac80211 para o módulo lvwnet_node. Esta função envia o
apontador do começo do endereço de memória do skb para o módulo lvwnet_node, não
antes de verificar se o módulo já está carregado. Uma vez que isso é sempre feito através
de apontadores, o atraso gerado por esses procedimentos são mínimos. O que poderá
gerar um maior atraso na verdade é a transmissão via ethernet, apesar desta também ser
assíncrona.
Uma vez que o quadro já está disponível no módulo lvwnet_node, o nó verifica
seus vizinhos, e envia o quadro para os que forem alcançáveis. Esse envio é feito através
58
Figura 11: Diagrama de sequência de chamadas de funções entre os módulos mac80211 e
lvwnet_node.
da função ethernic_send(). Como parâmetros ele recebe o skb, o endereço MAC de
destino, e o dispositivo de rede por onde ele deve ser enviado, que deve ser a interface
ethernet usada para transmissão dos quadros IEEE 802.11 encapsulados.
Algumas verificações básicas são realizadas na função ethernic_send(). Uma delas é verificar se o skb tem espaço reservado disponível para agregação do cabeçalho
ethernet. Vale lembrar que esse cabeçalho, que tem 14 bytes, é composto por 6 bytes do
endereço MAC de origem, mais 6 bytes do endereço MAC de destino (recebido como parâmetro da função) e mais 2 bytes reservados ao ethertype/length, que é responsável
por informar que tipo de protocolo está encapsulado no quadro ethernet ou o tamanho
do payload/data do quadro. Caso esse número seja menor ou igual a 1500 (representação
hexadecimal 0x05DC), esse campo será considerado como tamanho do campo data do
quadro, caso seja maior ou igual a 1536 (representação hexadecimal 0x600), o campo
será considerado como ethertype. Em (IEEE, 2012c) a partir da página 56, temos mais
detalhes sobre esse campo.
No caso do projeto LVWNet, estamos usando o ethertype de número 0x0808, que
atualmente não está em uso por nenhum protocolo, apesar de reservado para a Xerox
(IEEE, 2012a). A título de exemplo, todo quadro que tiver o ethertype definido como
0x0800 é um quadro com o protocolo IP encapsulado.
Uma vez que o skb tenha tido o cabeçalho ethernet adicionado com as informações
para o novo host, é feita a chamada à função dev_queue_xmit(), que é responsável
por colocar o quadro na fila de transmissão.
59
1
2
3
4
5
6
7
8
9
10
11
static struct packet_type pkt_type_lvwnet = {
.type = htons(0x0808),
.func = ethernic_recv,
};
/** (...)
*/
static int __init init_lvwnet(void)
{
/** (...)
*/
dev_add_pack(&pkt_type_lvwnet);
/** (...)
*/
}
Código 5.4: Registro do ethertype 0x0808 e sua função manipuladora
Nesse ponto, o quadro efetivamente deixa o nó 01 com destino ao nó 02. A função
responsável pela recepção de quadros de ethertype 0x0808 é a ethernic_recv().
Essa função é registrada através da inicialização dos valores da estrutura packet_type,
que é definida no arquivo netdevice.h. Uma vez que os valores são colocados na iniciação da estrutura, ela deve ser registrada através da função dev_add_pack(), que é
chamada junto com a inicialização do módulo, realizada pela função interna do LVWNet
init_lvwnet(). A forma como essas funções são usadas dentro do nosso projeto pode
ser vista no código 5.4.
Dentro da função ethernic_recv(), são realizadas verificações, de forma a analisar
a consistência do quadro. Após essas verificações, é feita a identificação do quadro, ou seja,
se ele é um quadro de registro, de informações ou de dados. Isso é feito ao inspecionar-se
o primeiro byte do campo data do skb. No nosso caso em específico, estamos analisando a troca de mensagens de dados, logo o primeiro byte é o que está no #define
LVWNET_CODE_DATA. Isso pode ser observado na figura 12.
Figura 12: Amostra de tráfego do tipo data capturado na ethernet.
Nessa figura 12, temos uma comunicação entre o host aa:aa:aa:00:01:01 enviando um quadro de dados para o host aa:aa:aa:11:00:00. O payload do quadro
60
Ethernet consiste do quadro IEEE 802.11 precedido pelo cabeçalho LVWNet. Desse modo,
pode-se observar que se trata de uma mensagem de broadcast, pois o primeiro endereço
definido no quadro IEEE 802.11 é o ff:ff:ff:ff:ff:ff, e o segundo endereço é o
ea:aa:aa:00:01:01, que é o endereço MAC da interface wireless desse host.
Uma vez que o módulo lvwnet_node já analisou o quadro e o classificou como do
tipo data, sabe-se que o cabeçalho LVWNet é composto apenas por um byte no começo
do payload. Para obter o quadro IEEE 802.11 encapsulado deve-se então retirar esse byte.
Para isso, o skb tem seu campo data, que aponta para o início do payload, decrementado
em um byte. Isso é feito através da função skb_pull(). Após isso, o campo data é
uma representação fiel do quadro IEEE 802.11 transmitido pelo nó 01, e que chegou no
nó 02.
Para injetá-lo novamente na pilha de rede, de modo que possa ser processado pelo
mac80211, usamos a função ieee80211_rx_irqsafe(), que é a mesma usada pela
camada PHY do driver para injetar quadros que chegaram através do hardware comum.
Como pode-se observar, não há diferenciação de quadros que chegaram via a camada PHY
comum, e quadros que chegaram através do LVWNet, via rede ethernet.
Uma vez que o quadro é injetado na pilha de rede o próprio módulo mac80211 agora
é o responsável por tratar os quadros, e enviá-los às aplicações adequadas, com a análise
da estrutura skb nas camadas superiores.
5.5
Uso dos Módulos
Nessa seção será apresentada a forma como os usuários devem utilizar os módulos do
LVWNet, ressaltando os parâmetros que podem ser definidos e como obter informações
dos módulos através do sysfs.
Detalhes de como baixar e compilar o código atual podem ser vistos no Apêndice A.
5.5.1
Carga dos módulos
Uma vez que as dependências já foram resolvidas, para carregar utiliza-se os parâmetros a seguir. Naturalmente, os diversos módulos do LVWNet não utilizam os mesmos parâmetros. Abaixo são mostrados os parâmetros suportados pelo módulo lvwnet_node.
• x_pos=int define a posição x do nó (em metros);
61
• y_pos=int define a posição y do nó (em metros);
• z_pos=int define a posição z do nó (em metros);
• power_tx_dbm=int define a potência de transmissão do nó (em dBm);
• sens_rx_dbm=int define a sensitividade de recepção do nó (em dBm);
• channel=int define o canal em que o nó opera (deve-se usar o número do canal, não
a frequência);
• ethernic_name=string informa qual o nome da interface de rede ethernet que o
host deve usar para comunicação e encapsulamento dos quadros IEEE 802.11 (ex.:
eth0, ens9 etc);
• send_all_to_controller=(1|0) informa ao módulo se ele ao invés de enviar as mensagens diretamente para os vizinhos, deve enviar para o controlador de topologia.
Essa configuração é útil quando se deseja ter um ponto central para inspecionar
todas as mensagens trafegadas, ou se deseja comunicação entre as versões anteriores
do LVWNet, que tinham esse comportamento por padrão;
• ctrl_host_addr=mac_address informa o endereço MAC ethernet do controlador.
Não deve-se usar ponto, dois pontos ou espaços para dividir os octetos do endereço
MAC.
Desses parâmetros, o único que não é obrigatório é o channel. Por padrão, este é
definido como 1. Contudo, apesar de aceitar esses parâmetros, o cabeçalho radiotap ainda
não é formado usando essas informações.
Um exemplo de uma carga do lvwnet_node é dada no código 5.5.
1
2
3
4
[leo@nabucodonosor ~]\$ sudo insmod lvwnet_node.ko ethernic_name=ens9 \
ctrl_host_addr=aaaaaa110000 \
x_pos=100 y_pos=200 z_pos=300 \
power_tx_dbm=20 sens_rx_dbm=-75
Código 5.5: Exemplo de como carregar o módulo lvwnet_node
Nessa linha de comando, o endereço MAC do controlador é o AA:AA:AA:11:00:00,
a posiçao x do nó é 100 (metros), a y é 200 e a z é 300 (metros). A potência de transmissão
assumida é de 20 dBm e a de sensitividade de recepção é de -75 dBm.
O módulo lvwnet_controller não tem nenhum parâmetro por padrão, e também
não tem nenhuma dependência de outros módulos, pois ele realiza um trabalho somente
62
de coordenação dos nós, realizando cálculos e enviando mensagens de posicionamento de
nós.
5.5.2
Informações disponbilizadas via sysfs
O sysfs é um sistema de arquivos em memória que é muito utilizado pelo kernel
para disponibilizar informações do kernel space para o user space de modo simples. Seu
modo de operação é bastante simples. Ao se ler um arquivo do sysfs se consegue obter
informações do kernel, e ao se gravar um dada informação em um arquivo do sysfs se está
enviando a referida informação para o kernel.
Os módulos do LVWNet utilizam o sysfs para disponibilizar acesso à informações
sobre os seus estados, fornecendo alguns dados, como por exemplo os vizinhos recebidos,
quantidade de mensagens por tipo etc.
O raiz dos arquvos do sysfs do LVWNet é /sys/kernel/lvwnet. Temos alguns
arquivos diferentes dependendo se o host opera como um nó ou como controlador.
No caso do módulo lvwnet_node, ou seja, o host operando como nó, temos a lista
de arquivos abaixo e o que cada um representa.
• qtd_peers: informa quantos vizinhos o nó tem;
• oper_mode: informa se o host trabalha como nó (saída do arquivo node) ou como
controlador (saída do arquivo controller);
• peers_list: tem como saída uma lista de todos os vizinhos do nó, com a potência;
• qtd_data_msg: quantidade de mensagens de dados recebida pelo nó;
• qtd_info_msg: quantidade de mensagens de informações sobre vizinhos recebida
pelo nó;
• qtd_all_msg: quantidade de mensagens recebidas, independente do tipo.
Já no caso do host estar trabalhando como um controlador, os arquivos são os seguintes:
• qtd_nodes informa quantos nós estão registrados no controlador;
63
• oper_mode informa se o host trabalha como nó (saída node) ou como controlador
(saída controller);
• nodes_list tem como saída uma lista de todos os nós que se registraram no controlador com a potência de transmissão, sensitividade de recepção, e posição x, y e
z;
• nodes_gnu_plot tem como saída todos os nós em formato pronto para plotagem do
gnuplot, de forma a dar uma idéia de posicionamento em 3D dos nós registrados
neste controlador;
• qtd_reg_omni_msg quantidade de mensagens de registro de nós usando a mensagem de registro de nó omnidirecional;
64
6
Análise do LVWNet
Este capítulo tem como objetivo relatar as abordagens e metodologias utilizadas para
realização de testes, com objetivo de validar a construção do projeto concebido e detalhado
nos capítulos anteriores.
6.1
Criação automática de peer links com dispositivos
reais
Para os testes de inserção de um nó com hardware real em uma rede LVWNet, utilizamos uma interface wireless USB compatível com SoftMAC. O modelo escolhido foi o
WBN900 da Intelbras. Ele é compatível com IEEE 802.11s (mesh), que foi o tipo de rede
escolhida para a realização dos testes.
Foi criada uma rede com 3 nós virtuais e 1 real. A tabela 1 traz a lista de todos os
endereços MAC e dos endereços IP dos nós envolvidos.
Tabela 1: Endereços MAC Ethernet e WLAN dos nós para teste de inserção de um nó real
Nó
Ethernet(ens9)
WLAN (wlan0)
IPv4
nó 01
aa:aa:aa:00:01:01 02:00:00:00:01:01 10.1.1.11/8
nó 02
aa:aa:aa:00:01:02 02:00:00:00:01:02 10.1.1.12/8
nó 03
aa:aa:aa:00:01:03 02:00:00:00:01:03 10.1.1.13/8
nó real
fe:54:00:32:2d:dc 00:1a:3f:a5:74:e7 10.1.1.99/8
A posição inicial dos 4 nós (3 virtuais e 1 real) no espaço é especificada na tabela 2.
O nó real foi propositalmente colocado em um espaço de interseção dos nós 01 e 02, de
forma que ele deva estabelecer dois peer links individuais com cada um desses hosts. O
nó 03 não tem comunicação com nenhum outro nó.
Para os testes, utilizaremos uma rede IEEE 802.11s simples, mas que permite constatar
a criação dos peer links e realizar testes básicos de conectividade.
65
Tabela 2: Posições iniciais dos nós virtuais e
Nó
x
y
nó 01
500m
500m
nó 02
600m 1300m
1200m 500m
nó 03
700m
800m
nó real
do real
z
10m
10m
10m
10m
Na máquina real, uma vez carregados o módulo mac80211 modificado, o lvwnet_node
e inserida a interface de rede USB (que realiza a carga dos módulos necessários automaticamente), é preciso definir a interface como sendo do tipo mesh. Tal tarefa está mostrada
na figura 13, onde deve-se observar que a interface Wifi dessa máquina, que havíamos
citado como wlan0, é de fato chamada de wlp0s26f7ulu3.
Figura 13: Definindo a interface real como sendo do tipo mesh.
Uma vez que a interface está definida corretamente e é realizado o scan inicial, é
possível observar os peer links criados com os nós virtuais na figura 14.
Finalmente, pode-se realizar um teste de conectividade básico com ping, e verificar a
tabela de encaminhamento de layer 2 do mesh na figura 15.
66
Figura 14: Peer links do host real com as máquinas virtuais.
Figura 15: Teste básico de conectividade e tabela de encaminhamento layer 2.
6.2
Simulação de mobilidade de um nó
O objetivo desse teste é verificar o estabelecimento e o cancelamento de peer links a
medida que um nó (virtual) se movimenta. A alteração das coordenadas que indicam a
posição do nó será feita utilizando o sysfs.
Nesse experimento, temos apenas 3 nós de forma a facilitar a visualização dos links
estabelecidos entre eles decorrentes da mobilidade. Os endereços dos nós são mostrados
na Tabela 3.
Nó
nó 01
nó 02
nó 03
Tabela 3: IPs e endereços MAC ethernet e WLAN dos
Ethernet(ens9)
WLAN (wlan0)
aa:aa:aa:00:01:01 02:00:00:00:01:01
aa:aa:aa:00:01:02 02:00:00:00:01:02
aa:aa:aa:00:01:03 02:00:00:00:01:03
nós
IPv4
10.1.1.11/8
10.1.1.12/8
10.1.1.13/8
Todos os nós estão com a mesma coordenada z, o que implica em um deslocamento
2D, como em um espaço plano.
Serão realizados alguns cálculos para encontrar o alcance máximo de um nó, assumindo
que todos eles tem uma potência de transmissão de 20dBm e sensitividade de recepção
de −75dBm.
67
Como já visto no capítulo 4, a equação de cálculo de perda no espaço livre, já simplificada é dada por 6.1.
LF S = 32.45 + 20log10 (f ) + 20log10 (D)
(6.1)
Uma vez que sabe-se tanto a potência de transmissão como sensitividade de recepção,
e se quer encontrar o alcance de um determinado nó, pode-se modificar a equação de
forma como está apresentada na equação 6.2.
LF S = 32.45 + 20log10 (f ) + 20log10 (d)
(6.2)
20log10 (d) = LF S − 32.45 − 20log10 (f )
Como já é conhecida a potência de transmissão (20dBm) e a sensitividade de recepção
é de −75dBm, logo a maior perda no espaço livre possível para essas duas características
será de −95dBm. Para a frequência de 2412 MHz, temos a equação dada em 6.3.
LF S = 32.45 + 20log10 (f ) + 20log10 (d)
20log10 (d) = 95 − 32.45 − 20log10 (2412)
20log10 (d) = 62.55 − 20(3.38237730347)
(6.3)
20log10 (d) = 62.55 − 67.6475460694
d = 556.06133m
Vê-se na equação 6.3 que a distância onde se tem uma perda de exatamente 95dBm é
de aproximadamente 556 metros. Em um ambiente real esse valor seria bem menor, pois
teríamos outros fatores de interferência, como objetos no caminho, outras transmissões
em frequências próximas etc. Além disso, isso seria um valor limítrofe entre um estado
de comunicação e não comunicação. Contudo, em transmissores reais quanto menor a
potência do sinal, menor também a taxa de transmissão, que no pior caso de se estar
muito próximos do limite de 556 metros, também se estaria na menor taxa de transferência
possível. Entretanto, nenhum desses fatores é levado em consideração nesse ambiente.
Em nosso teste, o primeiro nó está localizado na posição x = 500, y = 500 e z = 10
metros. Já o segundo nó está na posição x = 600, y = 1300 e z = 10 metros. Eles estão
propositalmente afastados o suficiente para que se possa observar como um nó estabelece
os peer links a medida que se movimenta no espaço. Ambos os nós 01 e 02 estão fixos
e localizados à 806 metros um do outro, e tem uma perda em espaço livre entre eles de
98dBm. Já o terceiro nó, irá iniciar na posição x = 1200, y = 500 e z = 10 metros. Ele está
68
na mesma coordenadad y do nó 01, mas afastado exatamente 700 metros na coordenada
x (LF S = 97dBm) o que torna ele inalcançável pelo nó 01 neste momento. Na tabela 4
temos as coordenadas de todos os nós antes do nó 03 começar a se movimentar.
Tabela 4: Posições iniciais
Nó
x
nó 01 (fixo)
500m
nó 02 (fixo)
600m
1200m
nó 03 (móvel)
dos nós
y
500m
1300m
500m
z
10m
10m
10m
Nessa configuração, não há nehuma comunicação entre os nós. Definimos as posições
para análise do nó 03 como milestones. No milestone 01, ele está na posição x, y, z =
1200, 500, 10 metros. Na tabela 5, temos uma lista de todos as posições do nó 03.
Milestone
milestone 01
milestone 02
milestone 03
milestone 04
milestone 05
milestone 06
Tabela 5: Posições de cada um dos milestones do nó 03
x
y
z
Sinal nó 01
Sinal nó 02
1200m 500m 10m -97dBm (700m) -100dBm (1000m)
700m
500m 10m -86dBm (200m)
-98dBm (806m)
900m
700m 10m -93dBm (447m)
-96dBm (670m)
700m
800m 10m -91dBm (360m)
-94dBm (509m)
900m 1300m 10m -99dBm (894m)
-89dBm (300m)
900m 1800m 10m -99dBm (894m)
-89dBm (300m)
Figura 16: Estado do nó 03 no milestone 01 (sem nenhum peer link).
A Figura 21, que aparece no final dessa seção, mostra o movimento realizado pelo nó
03.
Analisando a partir do milestone 01, temos que neste primeiro, o nó 03 não tinha
comunicação com nenhum dos outros 2 nós. A perda em espaço livre para ambos os
69
nós a partir do nó 03 era de 97dBm e 100dBm para os nós 01 e 02 respectivamente.
Como já mencionado antes, para haver comunicação a atenuação máxima gerada pela
perda em espaço livre deve ser de 95dBm, dada as características definidas de potência
de transmissão e sensitividade de recepção definidas na carga do módulo. O estado do nó
03 enquanto ainda não está estabelecido nenhum peer link pode ser visto no screen do
host da figura 16.
Já no segundo momento do milestone 02, o nó 03 entrou na área de cobertura do nó
01, com uma perda em espaço livre de 86dBm, bem menor que os 95dBm necessários
para que exista comunicação. Ainda no milestone 02, não existe comunicação entre o
nó 03 e o 02, pois a atenuação é de 98dBm. Os peer links criados podem ser vistos na
figura 17. O milestone 03 é somente uma continuação do segundo, tendo em vista que
não há mudanças dos links estabelecidos, somente uma atenuação maior dada a distância
também maior. Por isso, não será mostrada nenhuma figura para esse caso.
Figura 17: Estado do nó 03 no milestone 02 (peer link com o nó 01).
No quarto milestone, o nó 03 entra em uma pequena zona de interseção entre a área
de cobertura do nó 01 e do nó 02. Nesse momento, ele consegue estabelecer um peer link
tanto com o nó 01 como com o nó 02, como mostra a figura 18. Nessa zona de interseção,
a atenuação é de 93dBm e de 94dBm (muito próxima do limite de 95dBm) para os nós
01 e 02 partindo do nó 03 respectivamente.
No próximo milestone, o nó 03 saiu da área de cobertura do nó 01. Apesar disso, para
o nó 03, o nó 01 ainda está com um peer link estabelecido, como pode ser visto na figura
70
Figura 18: Estado do nó 03 no milestone 04 (peer link com o nó 01 e nó 02).
19.
Figura 19: Estado do nó 03 no milestone 05 (peer link com o nó 01 e nó 02). O peer link
com o nó 01 está aguardando ser excluído.
Figura 20: Estado do nó 03 no milestone 05 (peer link com o nó 02). O peer link com o nó
01 foi excluído após 1800 segundos.
Isso se deve à implementação do mesh do módulo mac80211. Nessa implementação, a função responsável por realizar possíveis limpezas de links não mais disponíveis é a
ieee80211_mesh_housekeeping. Ela é chamada por um timer com tempo de expiração de 60 segundos (através do define IEEE80211_MESH_HOUSEKEEPING_INTERVAL
(60 * HZ)). Contudo, essa função só “limpa” peer links com tempo de inatividade maior
que 1800 segundos (30 minutos). Esse tempo está informado no módulo mac80211 através
do define IEEE80211_MESH_PEER_INACTIVITY_LIMIT (1800 * HZ). Ou seja, o
71
peer link só será removido entre 1800 e 1860 segundos depois do nó não estar mais disponível. Essa operação pode ser vista na figura 20.
Na esquerda da figura, temos o link ainda estabelecido com o peer 02:00:00:00:01:01,
mas com o tempo já de pouco mais de 1800 segundos. Após alguns segundos, o peer link
desaparece, e resta somente o com o nó 02:00:00:00:01:02, que está ao alcance do
host.
Figura 21: Caminho percorrido pelo nó 03 entre os 6 milestones.
No sexto e último milestone, temos o nó saindo do alcance dos nós 01 e 02. Existe a
mesma característica do milestone 5, onde é necessário esperar o tempo de 1800 segundos
para que o peer link não esteja mais disponível. Contudo da mesma forma do caso anterior,
a comunicação já não é mais possível a partir do momento que ocorre a mobilidade.
Na figura 21 é possível observar todo o caminho percorrido pelo nó 03, bem como uma
disposição aproximada de como os 3 nós estão no espaço. Também é possível observar
através da linha tracejada o caminho percorrido pelo nó 03.
72
7
Considerações finais
O presente trabalho propôs modificações ao LVWNet que é um projeto que permite
a emulação de redes Wifi virtuais. Inicialmente foram apresentadas as limitações do projeto LVWNet original que motivaram o desenvolvimento desse trabalho. Foram propostas
quatro novas funcionalidades para o LVWNet, que são: i) permitir a inserção e remoção
de novos nós na rede durante sua operação; ii) permitir a integração de dispositivos Wifi
reais na rede virtual; iii) fornecer um suporte inicial a mobilidade de nós, baseado no
cálculo do alcance do sinal; iv) permitir a comunicação direta entre os nós.
Após se discutir os benefícios desses novos recursos, mostrando que eles permitirão
a utilização do LVWNet para analisar um número muito mais amplo de situações, foi
apresentado como se deu a implementação da nova versão do LVWNet. Após tudo isso,
foi mostrado como os novos recursos foram avaliados em um ambiente de testes, e como
os resultados comprovaram o correto funcionamento de todos eles. Foi criada um rede em
malha sem fio IEEE 802.11s e pode-se observar que todos os protocolos envolvidos, como
é o caso do protocolo de Peer Link e o protocolo HWMP, funcionaram sem nenhuma
modificação sobre o LVWNet.
7.1
Principais contribuições
As mudanças propostas nesse trabalho conferem ao projeto LVWNet uma implementação mais completa e mais escalável, que pode utilizar uma quantidade maior de nós,
sem preocupações relativas saturação de interfaces ou máquinas por excesso de banda
(com a comunicação direta entre os nós).
Com o novo protocolo de registro de nós passa a ser possível emular redes dinâmicas,
permitindo assim, analisar melhor questões como tolerância a falhas e auto-organização,
que são inerentes, por exemplo aos procolos de encamihamento de quadros da redes IEEE
802.11s, como é o caso do HWMP.
73
O mecanismo de cálculo do alcance do sinal, além de tornar a forma de trabalhar
com a rede mais próxima da utilizada em ambientes reais, fornece o suporte inicial a um
mecanismo de mobilidade para o LVWNet. Mesmo que o mecanismo proposto ainda seja
muito básico, ele fornece o alicerce necessário para mecanismos mais complexos sejam
construídos futuramente.
Finalmente, a capacidade de integrar hardwares Wifi reais abre novas possibilidades
de uso para o LVWNet, viabilizando, por exemplo, a interligação de redes Wifi reais
geograficamente distantes, bem como a análise da implementação de hardware e software
(principalmente) de dispositivos reais quando inseridos em redes com um elevado número
de nós.
7.2
Limitações
Entre as principais limitações do LVWNet temos um suporte a mobilidade bastante
limitado, onde não é possível utilizar a informação de qualidade do sinal para iniciar
o processo de handover. Além disso, a ausência de parâmetros de erro e latência nas
transmissões tornam os enlaces mais distantes de seus equivalentes reais.
7.3
Trabalhos futuros
A seguir são citados pontos importantes que não foram abordados nesse trabalho, mas
que se tratados adequadamente podem contribuir muito para uma melhor utilização do
LVWNet.
7.3.1
Mobilidade
Dada a natureza instríscicamente móvel de redes sem fio, a implementação mais completa de suporte mobilidade é uma característica bastante necessária. Tal suporte se refere
tanto as questões já citadas relacionadas ao handover, como a implementações de modelos de mobilidade. Tais modelos permitiriam criar padrões para mudança de posições dos
nós, por exemplo permitindo que movimentem-se à velocidades variáveis, ou constante,
por um trajeto pré-definido ou aleatório, entre outros pontos.
74
7.3.2
Modificação do radiotap no quadro IEEE 802.11
A presente implementação do LVNet não utiliza o cabeçalho radiotap nas suas comunicações com o mac80211. Estudos relativos à como esse cabeçalho influencia na
transmissão, como ele pode ser inserido no quadro IEEE 802.11 e suas opções de flags
e campos são possíveis trabalhos futuros que também permitiriam uma utilização mais
adequada e próxima da realidade do LVWNet.
7.3.3
Uso de erro e latência na transmissão de quadros
Não há hoje nenhum atraso nem tampouco interferência nas transmissões de uma rede
LVWNet. A inserção de modelos de atrasos e inteferências também deixariam o projeto
mais próximo da realidade. Um possível ponto de início seria o projeto wmediumd, que
insere alguns desses parâmetros no módulo mac80211_hwsim.
7.3.4
Uso de replay de quadros para uso de máquinas sem modificação
Com o uso de replay dos quadros de máquinas específicas não modificadas, será possível “ingressar” de forma indireta um host ou dispositivo sem modificação em uma rede
LVWNet.
Nessa implementação, os quadros seriam capturados por um determinado host em
modo promíscuo e encaminhados para os outros hosts que estivessem em seu raio de
alcance. Além disso, todos os quadros que fossem enviados para dnetro do ambiente virtual, também seriam encaminhados em uma interface física real de forma que pudessem
ser recebidos pelo dispositivo sem modificação.
75
Referências
ANATEL. Resolução no 506, de 1o de julho de 2008 - Republica o Regulamento sobre Equipamentos de Radiocomunicação de Radiação Restrita. jul. 2008. Disponível em: <http:
//legislacao.anatel.gov.br/resolucoes/2008/104-resolucao-506>.
Acesso em Abril 30, 2014.
ANDREEV, K.; BOYKO, P. Ieee 802.11s mesh networking ns-3 model. In: Workshop on
ns-3 - 2010. [S.l.]: NS-3 Workshop, 2010.
BARI, S.; ANWAR, F.; MASUD, M. Performance study of hybrid wireless mesh protocol
(hwmp) for ieee 802.11s wlan mesh networks. Computer and Communication Engineering
(ICCCE), 2012 International Conference on, IEEE Press, p. 712–716, 2012.
COMMUNITY, P. B. S. The linux kernel module programming guide.
Http://www.secdev.org/projects/scapy/doc/ Visitada em Janeiro 2014. Abril
2010.
FILHO LUIZ FERNANDO SOARES, S. C. Guido Lemos de S. Redes de Computadores.
Das LANs, MANs e WANs as Redes ATM. 1. ed. [S.l.]: Campus, 2007.
FOUNDATION, F. S. A GNU Manual. 2002. Disponível em: <http://gcc.gnu.
org/onlinedocs/gcc-3.1/gcc/Type-Attributes.html>. Acesso em Março,
15, 2014.
HENRY, J. Certified Wireless Network Professional - 802.11s Mesh Networking. nov.
2011. Disponível em: <http://www.cwnp.com/cmsAdmin/uploads/802-11s_
mesh_networking_v1-0.pdf>. Acesso em Maio 1, 2014.
IEEE. Spectrum sharing in the 5 ghz band dfs best practices.
Http://www.ieee802.org/18/Meeting_documents/2007_Nov/WFA-DFS-Best
20Practices.pdf. 2007.
IEEE. Ieee public ethertype list.
Http://standards.ieee.org/develop/regauth/ethertype/eth.txt Visitada em
Maio de 2014. 2012.
IEEE. IEEE Standard for Air Interface for Broadband Wireless Access Systems.
802.16-2012. ed. [S.l.]: IEEE, 2012.
IEEE. IEEE Standard for Ethernet. 802.3-2008. ed. [S.l.]: IEEE, 2012.
IEEE. Ieee p802.11 - task group s - meetings update.
Http://grouper.ieee.org/groups/802/11/Reports/tgs_update.htm Visitada em
Dezembro 2013. Julho de 2011.
76
IEEE. Summary report of the may 2004 meeting of ieee 802.11.
Http://grouper.ieee.org/groups/802/11/Reports/Summary-report-04-May-meeting.html
Visitada em Dezembro 2013. Maio de 2004.
IEEE. Summary report of the september 2003 meeting of ieee 802.11.
Http://grouper.ieee.org/groups/802/11/Reports/Summary-report-03-Sept-meeting.html
Visitada em Dezembro 2013. Setembro de 2003.
ILLáN, A. M. Master Thesis, Medium and mobility behaviour insertion for 802.11
emulated networks. Barcelona, Espanha: [s.n.], set. 2013.
LAU, L.-C. et al. Design and implementation of a more realistic radio propagation
model for wireless vehicular networks over the nctuns network simulator. In: Wireless
Communications and Networking Conference (WCNC), 2011 IEEE. [S.l.]: IEEE Press,
2011. p. 1937–1942.
MACHINE, K. B. V. Kernel Samepage Merging. fev. 2014. Disponível em:
<http://www.linux-kvm.org/page/KSM>. Acesso em Março, 21, 2014.
MILLER, D. S. How SKBs work. 2000. Disponível em: <http://vger.kernel.
org/~davem/skb.html>. Acesso em Fevereiro 19, 2014.
NOJIMA, D. et al. Performance evaluation for multi-user mimo ieee 802.11ac wireless
lan system. Advanced Communication Technology (ICACT), 2012 14th International
Conference on, IEEE Press, p. 804–808, 2012.
NWUP, E. K. O.; AKANDE, I. A. Evalution of the pre IEEE 802.11s RFC: Aspects
of the Design and Implementation of the Mesh Station with RA-OLSR in the C-Core.
Blekinge, Suécia: [s.n.], jun. 2009.
OLIVEIRA, L. D. de; PINHEIRO, M. C. M. A. Linux Virtual Wireless Network Project.
2014. Disponível em: <https://github.com/lvwnet/main>.
ORGANIZATION, T. L. K. The Linux Kernel Archives - Active kernel releases. fev.
2014. 11, February, 2014. Disponível em: <https://www.kernel.org/releases.
html>. Acesso em Fevereiro, 19, 2014.
RACKLEY, S. Wireless Network Technology, From Principles to Successful
Implementation. 2. ed. [S.l.]: Elsevier, 1995.
ROSEN, R. Linux Wireless - Linux Kernel Networking (4)- advanced topics. out.
2009. March, 2009. Disponível em: <http://www.haifux.org/lectures/206/
wirelessLec.pdf>. Acesso em Janeiro 20, 2014.
SIRUFO, S. H. Dissertação de Mestrado, Análise de Desempenho de Redes IEEE 802.11b
Utilizando Mecanismos de Segurança. Rio de Janiro, RJ, Brasil: [s.n.], maio 2005.
SOCIETY, L. S. C. of the I. C. Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications. 802.11-2012. ed. [S.l.]: IEEE-SA Standards Board,
2012.
TANENBAUM, A. S.; WETHERALL, D. J. Computer Networks. 5th. ed. [S.l.]: Prentice
Hall, 2011.
77
WANG, S.-Y.; HUANG, Y.-M. Nctuns distributed network emulator. Internet Journal,
Nova Science Publishers Inc, v. 4, n. 2, p. 61–94, 2012.
WELTE, H. skb - Linux networks buffers. out. 2000. October, 2000. Disponível em:
<http://ftp.gnumonks.org/pub/doc/skb-doc.html>. Acesso em Fevereiro
19, 2014.
WIRELESS, L. mac80211_hwsim - Linux Wireless. 2014. 11, February, 2014. Disponível
em: <http://wireless.kernel.org/en/users/Drivers/mac80211_
hwsim>. Acesso em Maio, 10, 2014.
78
APÊNDICE A -- Download e Compilação do
Projeto LVWNet
Utilizamos para hospedagem do projeto o http://github.com, que utiliza o git
como protocolo padrão para controle de versão. Para que possa baixar o projeto completo,
pode-se usar a linha de comando exibido no código A.1.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
[lodantas@garfield mygit]$ git clone https://github.com/lvwnet/main
Cloning into ’main’...
remote: Counting objects: 151, done.
remote: Total 151 (delta 0), reused 151 (delta 0)
Unpacking objects: 100% (15/15), done.
Checking connectivity... done.
[lodantas@garfield mygit]$ cd main; ls -l
total 360
-rw-rw-r--. 1 loliveira loliveira 18031 Jun 5 02:22 LICENSE
-rw-rw-r--. 1 loliveira loliveira 14863 Mai 20 17:32 lvwnet_controller.c
-rw-rw-r--. 1 loliveira loliveira
8621 Jun 5 01:38 lvwnet_ethernet.h
-rw-rw-r--. 1 loliveira loliveira 180338 Ago 16 18:13 lvwnet_lfs.h
-rw-rw-r--. 1 loliveira loliveira
2726 Mai 17 22:12 lvwnet_netlink.h
-rw-rw-r--. 1 loliveira loliveira 20915 Jun 5 01:33 lvwnet_node.c
-rw-rw-r--. 1 loliveira loliveira
4295 Mai 18 13:27 lvwnet_params.h
-rw-rw-r--. 1 loliveira loliveira 16921 Mai 20 14:58 lvwnet_proto.h
-rw-rw-r--. 1 loliveira loliveira 10313 Mai 19 15:45 lvwnet_sysfs.h
-rw-rw-r--. 1 loliveira loliveira
3133 Mai 17 22:12 lvwnet_timers.h
drwxrwxr-x. 2 loliveira loliveira
4096 Mai 18 15:22 mac80211_3.13
drwxrwxr-x. 3 loliveira loliveira
4096 Ago 16 18:09 mac80211_3.14
drwxrwxr-x. 3 loliveira loliveira
4096 Ago 16 18:09 mac80211_3.15
-rw-rw-r--. 1 loliveira loliveira
1009 Ago 16 18:12 mac_strtoh.h
-rw-rw-r--. 1 loliveira loliveira
940 Mai 18 14:44 Makefile
-rw-rw-r--. 1 loliveira loliveira
50 Mai 17 22:12 README.md
drwxrwxr-x. 2 loliveira loliveira
4096 Ago 16 18:09 wireless_v3.13
drwxrwxr-x. 3 loliveira loliveira
4096 Ago 16 18:09 wireless_v3.14
drwxrwxr-x. 3 loliveira loliveira
4096 Ago 16 18:09 wireless_v3.15
[lodantas@garfield mygit]$
Código A.1: git clone do projeto LVWNet
Uma vez que o clone esteja disponível, podemos observar na estrutura de diretórios,
além dos arquivos do próprio LVWNet, também diretórios relativos a projetos que são
usados e modificados. Os principais até o momento são o módulo do kernel mac80211 e
79
o mac80211_hwsim. O último foi modificado de forma a enviar os SKBs para o módulo
lvwnet e permitindo modificar o endereço MAC da interface através de um argumento.
Esse módulo está dentro do diretório wireless.
Já a alteração do mac80211 foi realizada para permitir o uso de interfaces de rede
sem fio reais na infraestrutura do LVWNet.
Tanto os diretórios mac80211 como wireless, são seguidos pela identificação da
versão do kernel que corresponde o módulo em questão.
1
2
3
4
5
6
7
8
9
10
11
[lodantas@garfield lvwnet]$ make
make -C /lib/modules/‘uname -r‘/build M=/home/lodantas/Dropbox/master/
lvwnet/lvwnet modules
make[1]: Entering directory ‘/usr/src/kernels/3.13.9-200.fc20.x86_64’
CC [M] /home/lodantas/Dropbox/master/lvwnet/lvwnet/lvwnet.o
In file included from /home/lodantas/Dropbox/master/lvwnet/lvwnet/lvwnet.c
:21:0:
Building modules, stage 2.
MODPOST 1 modules
CC
/home/lodantas/Dropbox/master/lvwnet/lvwnet/lvwnet.mod.o
LD [M] /home/lodantas/Dropbox/master/lvwnet/lvwnet/lvwnet.ko
make[1]: Leaving directory ‘/usr/src/kernels/3.13.9-200.fc20.x86_64’
[lodantas@garfield lvwnet]$
Código A.2: Executando o make do projeto LVWNet
Para compilar o projeto, deve-se digitar make no diretório corrente. Ele irá realizar
a compilação de acordo com o conteúdo do arquivo Makefile existente no diretório. A
saída de um make com sucesso pode ser visto no código A.2.
Como já mencionado anteriormente, o LVWNet utiliza uma versão modificada do
mac80211. Logo, para carregar o lvwnet.ko, faz-se necessário antes carregar o mac80211.ko
modificado, que fica no diretório do próprio projeto. A compilação do módulo mac80211
se faz de forma idêntica aos outros módulos do kernel. Para compilá-lo individualmente,
deve-se executar o make -C /lib/modules/‘uname -r‘/build M=‘pwd‘ modules
dentro do diretório do mac80211 modificado.
1
2
3
4
5
6
7
8
[lodantas@garfield mac80211_3.13]$ make -C /lib/modules/‘uname -r‘/build M
=‘pwd‘ modules
make: Entering directory ‘/usr/src/kernels/3.13.9-200.fc20.x86_64’
CC [M] /home/lodantas/Dropbox/master/lvwnet/lvwnet/mac80211_3.13/main.o
CC [M] /home/lodantas/Dropbox/master/lvwnet/lvwnet/mac80211_3.13/status.
o
(...)
LD [M] /home/lodantas/Dropbox/master/lvwnet/lvwnet/mac80211_3.13/
mac80211.o
Building modules, stage 2.
MODPOST 1 modules
80
9
10
11
12
CC
/home/lodantas/Dropbox/master/lvwnet/lvwnet/mac80211_3.13/
mac80211.mod.o
LD [M] /home/lodantas/Dropbox/master/lvwnet/lvwnet/mac80211_3.13/
mac80211.ko
make: Leaving directory ‘/usr/src/kernels/3.13.9-200.fc20.x86_64’
[lodantas@garfield mac80211_3.13]$
Código A.3: Executando o make da versão modificada do mac80211