Upload
truongkhue
View
218
Download
0
Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DA BAHIAINSTITUTO DE MATEMÁTICA
DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO
Ibirisol Fontes Ferreira
Esquema de roteamento multicaminho em redes
MESH sem fio com OpenFlow para suporte a
aplicações VoIP
Salvador
2013
Ibirisol Fontes Ferreira
Esquema de roteamento multicaminho emredes MESH sem fio com OpenFlow para
suporte a aplicações VoIP
Monografia apresentada ao Curso degraduação em Ciência da Computação,Departamento de Ciência da Computação,Instituto de Matemática, Universidade Fe-deral da Bahia, como requisito parcial paraobtenção do grau de Bacharel em Ciência daComputação.
Orientador: Profo . Dr. Gustavo Bittencourt Fi-gueiredo
Salvador
2013
RESUMO
Alguns tipos de tráfego rede, como é o caso do tráfego originado por aplicações VoIP,precisam que garantias de QoS sejam dadas pela rede. Essa necessidade torna-se ainda maisacentuada em redes sem fio, onde há enormes desafios para disponibilização de serviços dequalidade, seja pelas próprias limitações do meio de transmissão ou pelas tecnologias de su-porte ainda muito incipientes, se comparadas às redes de meio de transmissão guiados. Nestecontexto, diversas abordagens são tomadas para prover priorização de tráfego em redes semfio, entre elas existe o roteamento multicaminhos, que dado um tráfego de rede, ele permitedividi-lo por vários caminhos distintos entre um destino e uma origem. Com isto, é esperadauma distribuição da carga na rede e um aproveitamento global da capacidade dos enlaces. Masapenas a técnica de roteamento multicaminhos não garante que um tráfego terá o desempenhodesejado, apenas pela sua segmentação, por isto, abordagens como duplicação de fluxo podemser agregadas para uma maior eficiência da técnica.
Palavras-chave: mvoip, voip, redes mesh, sdn, openflow, multicaminho, roteamento, trá-fego splitting,
AGRADECIMENTOS
Começo agradecendo ao meu orientador Profo . Dr. Gustavo Bittencourt Figueiredo por ter
me dado a oportunidade de iniciar os estudos científicos na área de redes de computadores, e
também por me ajudar na escolha e elaboração do objeto de estudo que utilizei nesse trabalho.
À minha chefe Claudete Mary e Souza Alves e ao meu chefe Luiz Cláudio de A. Mendonça
agradeço a oportunidade que me deram de trabalhar no PoP-BA, permitindo-me apreender mui-
tas das coisas que contribuíram para minha formação. Também agradeço por me incentivarem
a participar do grupo de pesquisa SPACES onde pude desenvolver esse presente trabalho.
Na universidade tive a oportunidade de encontrar pessoas de bom coração e que me fizeram
acreditar ainda mais nas pessoas e no espírito colaborativo. Primeiro como calouro e um pouco a
parte da realidade da universidade, encontrei nos professores e professoras pessoas exemplares,
muitos deles me ensinaram não só a competência na área de computação, como também lições
valiosas para a vida em sociedade as quais agradeço imensamente.
Em um segundo convívio na universidade, conheci o GRACO (Gestores da Rede Acadêmica
de Computação) onde me senti em casa e aprendi muito do que sei hoje. Agradeço a todos os
amigos que fiz por lá, e em especial a Bruno Ramos, Carlos Novais, Eduardo Júnior, Fábio
Machado, Humberto Galiza, Italo Valcy, Jundaí Abdon, Leandro Andrade, Madson Araújo,
Péricles Souza, Rogerio Bastos.
Aos meus atuais e ex-colegas de trabalho, que pude conhecer no PoP-BA, Jerônimo Aguiar,
Lucas Borges, Luiz Barreto, Ronaldo Almeida e Thiago Bomfim, e também aos demais colegas
da STI (antigo CPD) deixo meus sinceros agradecimentos pela cooperação e amizade em vários
momentos da minha vida acadêmica e profissional.
Agradeço aos funcionários do IM/UFBA e as pessoas da comunidade circunvizinha, que
me ajudaram em algum momento dessa jornada.
Também agradeço muitíssimo a minha mãe Veralucia Fontes e ao meu pai Valter Ferreira,
a minha irmã Thiara Fontes, a minha namorada Lilian Rau, pelo apoio que me deram nesse
momento final da minha graduação, tendo paciência e compreensão nesse momento tão difícil
e ao mesmo tempo especial.
Aos meus familiares e amigos(as), da Bahia, do Pará e dos outros lugares por onde passei,
agradeço pela atenção e carinho que depositaram em mim, mesmo me ausentando do convívio
próximo por estar trilhando meu caminho na universidade. Em especial as minhas tias Maria
José Fontes e Conceição Fontes, que tanto me ajudaram.
Agradeço a Carlos Chalegre e Família, Pedro Fontes, Luzianio Freire e a Alexandre Britto
por me darem os primeiros incentivos a continuar minha vocação na área de computação.
Por fim, agradeço a todos aqueles que me ajudaram e que por algum motivo não foram
citados diretamente nesse espaço.
Dedico esse trabalho à minha Mãe.
LISTA DE FIGURAS
2.1 Exemplo simplificado de uma arquitetura mVoIP . . . . . . . . . . . . . . . . 16
2.2 Exemplo do fluxo de uma sessão SIP/SDP entre dois agentes SIP . . . . . . . . 20
2.3 Pilha de procolos e dados usados para envio de mídia . . . . . . . . . . . . . . 22
3.1 Arquitetura Backbone Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1 Arquitetura Software-Defined Networking . . . . . . . . . . . . . . . . . . . . 32
4.2 Arquitetura do OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Entrada em uma tabela de regras de um switch OpenFlow . . . . . . . . . . . . 35
4.4 Etapas no tratamento de pacotes no switch OpenFlow . . . . . . . . . . . . . . 36
4.5 Fluxo de um pacote através do pipe em um switch OpenFlow . . . . . . . . . . 38
4.6 Exemplo de cenário contendo equipamento com suporte a OpenFlow . . . . . . 41
5.1 Roteamento multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Técnicas de Traffic Splitting . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3 Tipo de duplicação fluxo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1 Arquitetura do CORE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2 Fluxo de execução do CORE . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3 Funcionamento do framework do grupo SPACES . . . . . . . . . . . . . . . . 54
6.4 Funcionamento do componente Splitter . . . . . . . . . . . . . . . . . . . . . 57
6.5 Elementos de um nó Mesh no CORE . . . . . . . . . . . . . . . . . . . . . . . 58
6.6 Regras OpenFlow em um nó de origem do streaming . . . . . . . . . . . . . . 61
6.7 Topologia usada nos experimentos . . . . . . . . . . . . . . . . . . . . . . . . 62
6.8 Comportamento das políticas de splitting . . . . . . . . . . . . . . . . . . . . . 63
6.9 Funcionamento do teste de QoE . . . . . . . . . . . . . . . . . . . . . . . . . 65
LISTA DE TABELAS
2.1 Métodos e Repostas SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Padrões de codificação de áudio . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Características dos padrões IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . 28
3.2 Métricas de roteamento em redes Mesh . . . . . . . . . . . . . . . . . . . . . . 30
4.1 Sumário das principais mensagens especificadas no OpenFlow . . . . . . . . . 40
6.1 Índice de qualidade MOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
C.1 Medidas de Avaliação das Politícas de Splitting . . . . . . . . . . . . . . . . . 74
C.2 Índice PESQ e MOS-LQO das técnicas de splitting R.R. e B.C. para o áudio de
referencia ITU P862 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
C.3 Desvio padrão do índice PESQ e MOS-LQO das técnicas de splitting R.R. e
B.C. para o áudio de referencia ITU P862 . . . . . . . . . . . . . . . . . . . . 78
LISTA DE ABREVIATURAS E SIGLAS
IEEE Institute of Electrical and Electronics Engineers, p. 21
IETF Internet Engineering Task Force, p. 16
ISP Internet Service Provider, p. 12
LTE Long Term Evolution, p. 15
LXC Linux Containers, p. 49
MOS Mean Opinion Score, p. 64
MOS-LQO Mean Opinion Score - Listening Quality Objective , p. 64
mVoIP Mobile VoIP, p. 12
OVS Open vSwitch, p. 53
PESQ Perceptual Evaluation of Speech Quality, p. 63
QoE Quality of experience, p. 21
QoS Quality of Service, p. 21
RTCP Real-Time Transport Control Protocol, p. 17
RTP Real-time Transport Protocol, p. 17
SDP Session Description Protocol, p. 17
R.R. Round-Robin, p. 42
VLAN Virtual LAN, p. 39
VoIP Voice over IP, p. 12
VoWLAN Voice over Wireless LAN, p. 12
AODV Ad hoc On-Demand Distance Vector, p. 27
AODV-ST AODV-Spanning Tree, p. 27
API Application Programming Interface, p. 50
avtext Audio/Video Transport Extension, p. 45
Codec coder/decoder, p. 19
DCF Distributed Coordination Function, p. 21
DSDV Destination-Sequenced Distance Vector, p. 27
DSR Dynamic Source Routing, p. 27
GPS Global Position System, p. 12
GSM Global System for Mobile Communications, p. 13
GSR Global State Routing, p. 27
GUI Graphical User Interface, p. 50
HTTP Hypertext Transfer Protocol, p. 16
IPv6 Internet Protocol version 6, p. 29
LAN Local Area Network, p. 12
MAC Medium Access Control, p. 25
MOS Mean Opinion Score, p. 19
MR-LQSR Multi-Radio - Link Quality Source Routing, p. 27
MSC Message Sequence Chart, p. 18
MTU Maximum Transmission Unit, p. 43
MUP Multi-Radio Unification Protocol, p. 27
NAT Network Address Translation, p. 46
OLSR Optimized Link State Routing Protocol, p. 27
SIP Session Initiation Protocol, p. 13
, p. 16
TCP Transmission Control Protocol, p. 16
URI Uniform Resource Identifier, p. 15
WLAN Wireless LAN, p. 12
SUMÁRIO
1 Introdução 12
2 VoIP Móvel 14
2.1 Arquitetura mVoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Protocolos envolvidos em uma chamada mVoIP . . . . . . . . . . . . . . . . . 17
2.2.1 Inicialização de uma Sessão . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2 Transmissão de áudio . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Desafios na adoção do mVoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Redes Mesh Sem Fios 25
3.1 Arquitetura de uma Wireless Mesh Network . . . . . . . . . . . . . . . . . . . 26
3.2 Tecnologias Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Roteamento em Wireless Mesh Network . . . . . . . . . . . . . . . . . . . . . 28
4 Redes Definidas por Software 31
4.1 Arquitetura Software-Defined Networking . . . . . . . . . . . . . . . . . . . . 32
4.2 OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1 Arquitetura do OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.2 switch OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.3 Canal de comunicação Seguro . . . . . . . . . . . . . . . . . . . . . . 39
4.2.4 Protocolo OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.5 Controlador OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 Roteamento Multicaminhos 43
5.1 Especificidades do roteamento multicaminhos . . . . . . . . . . . . . . . . . . 43
5.2 Split de tráfego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6 Roteamento multicaminhos em redes Mesh 50
6.1 Ambiente de emulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Framework para o plano de controle e de encaminhamento . . . . . . . . . . . 53
6.3 Cenário inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.4 Plano de controle para roteamento multicaminhos . . . . . . . . . . . . . . . . 56
6.5 Cenário de experimentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.6 Análise das técnicas de split de tráfego . . . . . . . . . . . . . . . . . . . . . . 62
6.7 Qualidade de experiência das técnicas de split . . . . . . . . . . . . . . . . . . 64
7 Conclusão 67
7.1 Dificuldades encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Apêndice A -- Serviço de traffic splitting para o CORE 69
A.1 Módulo Splitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.2 script de inicialização do serviço de Splitter . . . . . . . . . . . . . . . . . . . 70
A.3 script de parada do serviço de Splitter . . . . . . . . . . . . . . . . . . . . . . 71
Apêndice B -- patch aplicado no iperf 73
Apêndice C -- Resultados experimentais 74
Referências Bibliográficas 79
12
1 INTRODUÇÃO
Vários eventos de rede podem acarretar em problemas que prejudicam aplicações VoIP,
sejam problemas ligados as características do meio físico ou resultantes de anomalias no fun-
cionamento dos equipamentos de rede. Entre os principais problemas é possível destacar alta
latência, perda de pacotes e jitter, que podem resultar em atraso de voz ou até fechamento de
chamadas estabelecidas. Os problemas são ainda mais agravantes em redes sem fios, que pos-
suem diversas peculiaridades oriundas do meio de transmissão compartilhado. Tendo em vista
que a nova geração de aplicações de telefonia IP, como é o caso do mVoIP são inerentes a am-
bientes de rede sem fio, e dada a proliferação das redes Mesh sem fio em ambientes robustos
de organizações, instituições de ensino e pesquisa, entre outras, é inevitável buscar maneiras de
mitigar os problemas relacionados ao tráfego VoIP nesse tipo de ambiente sem fio.
Nesse trabalho montou-se um esquema de roteamento multicaminhos e divisão de tráfego,
que permite a priorização de tráfego VoIP em redes Mesh sem fio. Nesta proposta usou-se o
cenário de uma rede Mesh sem fio trabalhando no paradigma de Software-Defined Networking.
Além do esquema de roteamento, avaliou-se duas formas de particionamento de tráfego, uma
baseada em duplicação de fluxo e a outra na distribuição do tráfego entre os caminhos da origem
ao destino na rede. Também mostrou-se uma forma de avaliar o desempenho da proposta de
roteamento multicaminhos em relação ao tráfego VoIP na perspectiva do usuário da rede. Foram
usados critérios de avaliação baseado no ITU P862 e nas amostras de conversas disponibilizadas
junto ao padrão.
É esperado que com as técnicas de split de tráfego do roteamento multicaminhos, obtenha-
se uma maior tolerância a atrasos, a perda de pacotes, permitindo também, a distribuição da
carga do tráfego ao longo dos caminhos disponíveis na rede. Dessa forma, é possível contribuir
para a manutenção da qualidade das chamadas VoIP em redes Mesh sem fio.
Neste presente capítulo é feita a organização do trabalho, mostrando os temas que serão
abordados e a ordem dos tópicos que serão descritos. No capítulo 2 é feita uma revisão bibli-
ográfica sobre as problemáticas que envolvem as aplicações mVoIP, enfatizando a necessidade
13
de garantias de QoS no serviço de entrega de pacotes em uma rede sem fio. O capítulo 3 traz
uma discussão a respeito das tecnologias de rede sem fio, enfatizando as redes Mesh sem fio,
seu funcionamento e suas problemáticas. A seguir, no capítulo 4 aborda-se a utilização do pa-
radigma Software-Defined Networking e as motivações para o seu uso, mostra-se os benefícios
que podem ser alcançados com essa tecnologia, também traz-se uma breve abordagem sobre
o funcionamento do OpenFlow, que serviu como base para o desenvolvimento do esquema de
roteamento multicaminhos. No capítulo 5 discute-se as técnicas de roteamento multicaminhos
e as formas de split de tráfego, focando os questionamentos nas vantagens e desvantagens de se
utilizar essa forma de roteamento. Por fim, o esquema proposto de roteamento multicaminhos
em redes Mesh é mostrado no capítulo 6, esse capítulo também traz o ambiente de emulação
utilizado nos experimentos, as ferramentas usadas, o cenário de teste e os resultados obtidos.
14
2 VOIP MÓVEL
A utilização de dispositivos eletrônicos como celulares, tablets e smartphones é um hábito
geral nos dias atuais (RIBEIRO; LEITE; SOUSA, 2009), (GOOGLE, 2013). O aumento do con-
sumo e utilização desses aparelhos é fortemente motivado pelo crescimento dos recursos com-
putacionais neles disponibilizados. É comum, por exemplo, a realização de consultas ao sistema
global de posicionamento (GPS), do inglês Global Position System partir de um smartphone,
para saber onde o portador do aparelho se localiza. Também são muito usadas as câmeras inte-
gradas a esses dispositivos para realizar chamadas de vídeo. Outro recurso fortemente difundido
nessa geração de dispositivos móveis é a conectividade a redes sem fio. Esse recurso possibilita
que cada vez mais usuários façam uso de serviços avançados que geralmente necessitam de co-
nexão à Internet. A exemplo, podemos citar os serviços Google Maps (GOOGLE.COM, 2005)
ofertado pela empresa Google, o serviço de telefonia IP Skype (SKYPE.COM, 2003), o fring
(FRING.COM, 2007), entre outros.
Para conectar-se a Internet os usuários desses aparelhos móveis utilizam na maioria dos
casos dois tipos de conexão (STALLINGS, 2004), o primeiro tipo de conexão se dá através
da rede das operadoras de celulares, que fornecem através de sua infraestrutura acesso a rede
mundial de computadores. A segunda forma de conexão à Internet, usada por esses aparelhos,
se dá por meio do padrão IEEE 802.11 (IEEE. . . , 2012). E por meio dessa conexão, é possível
acessar redes domésticas conectadas a rede mundial de computadores através de um ISP .
Dentro desse impulso crescente do uso de serviços de Internet em dispositivos móveis,
popularizam-se diversas formas de comunicação de voz, que usam redes de comutação de pa-
cotes, entre elas destacam-se o VoIP, do inglês Voice over IP (VoIP), VoWLAN (ULSETH;
ENGELSTAD, 2006) e mVoIP , do inglês Mobile VoIP, (MILLS-TETTEY; KOTZ, 2002). Esta
última tem tido, nos dias atuais, uma crescente adesão, poia permite que a comunicação por
voz entre dispositivos móveis, tanto por conexões através de uma WLAN como pela rede de
telefonia, seja realizada pela rede mundial de computadores. Em contraste com a telefonia VoIP
padrão, no mVoIP, o foco não só está na telefonia IP, mas também nas tecnologias de acesso sem
fio e nas problemáticas envolvidas no estabelecimento de uma chamada a partir de dispositivos
15
móveis.
Entre os benefícios de realizar uma chamada telefônica mVoIP a partir de um dispositivo
móvel, assim como no VoIP tradicional, pode-se destacar a redução dos custos financeiros,
como é apontado por Geer (2009), pois nos dias de hoje as empresas, organizações e pessoas
físicas já possuem conexão a Internet e, além disso, também possuem infraestrutura sem fio
dentro dos ambientes de trabalho e moradia. Dessa forma um portador de aparelho móvel
pode se beneficiar das redes já existentes, tanto em ambientes corporativos como no ambiente
doméstico para a realização de chamadas. Para justificar ainda mais o beneficio da redução
de custos nas ligações com mVoIP, pode-se evidenciar na diferença no preço entre os serviços
de dados e voz ofertados pelas operadoras de celulares. Geralmente, os custos para que um
cliente obtenha um plano de dados ao invés de um plano de voz são menores, isto permite que
esse usuário, ao realizar uma chamada mVoIP pelo plano de dados, economize mais do que ao
fazer uma chamada convencional. Ainda é necessário levar em consideração, que no mVoIP as
ligações são direcionadas prioritariamente pela conexão a uma rede WLAN, pois o intuito é que
a infraestrutura da operadora somente seja utilizada quando a qualidade de uma conexão WLAN
esteja ruim ou quando não houver a disposição uma rede sem fio com acesso à Internet.
Outras das vantagens do mVoIP é tolerância a falhas e a mobilidade, desde que, os dis-
positivos são portáteis e possuem duas conexões distintas a Internet, possibilitando assim, que
chamadas em andamento sejam mantidas mesmo com o termino imediato de uma conexão sem
fio. Isso é claro, é um dos desafios do mVoIP, já que, as conexões sem fio são de domínios
completamente diferentes, tanto administrativo como tecnológico.
2.1 ARQUITETURA MVOIP
Os aparelhos móveis com suporte a mVoIP caracterizam-se pela utilização de duas tecnolo-
gias sem fio para realização de chamadas VoIP, fazendo-as através da rede que estiver disponível
ou que for selecionada pelo usuário do aparelho. Na Figura 2.1 é possível entender um cená-
rio típico mVoIP, a linha tracejada - em azul - representa a conectividade do dispositivo móvel
à torre GSM , do inglês Global System for Mobile Communications (STALLINGS, 2004) da
operadora de celular, já a linha pontilhada - em vermelho - mostra a conexão à uma WLAN, po-
dendo ser através de um roteador sem fio ou mesmo Hot Spot. Quando conectado a uma dessas
duas redes, para a realização de uma ligação, o dispositivo móvel faz uma chamada usando um
protocolo de sinalização, como por exemplo o SIP , do inglês Session Initiation Protocol (RO-
SENBERG et al., 2002), (vide seção 2.2) ou H.323 (ITU-T, 1998) - que junto ao SIP formam
16
as duas maiores pilhas de protocolos para comunicação VoIP na Internet- que buscará outro dis-
positivo compatível com mVoIP no mesmo seguimento de rede ou em uma localidade remota,
como é mostrado pela linhas em preto passando pela nuvem que representa a Internet, chegando
a um outro aparelho compatível com mVoIP.
WLAN
Figura 2.1: Exemplo simplificado de uma arquitetura mVoIP
O fluxo de uma ligação mVoIP, em uma arquitetura desse tipo, obedece os seguintes passos,
para estabelecimento de uma chamada VoIP:
1. O dispositivo móvel conecta-se a uma WLAN ou a uma rede de uma operadora de celular.
(a) Caso seja à rede da operadora de celular, o aparelho terá de ativar o plano de dados.
2. Estabelecerá uma chamada com um destinatário VoIP, pertencente a rede local ou remota.
(a) Caso o destinatário da chamada seja pertencente a rede local, ele fará uma ligação
direta para o endereço de rede conhecido do dispositivo usando um dos protocolo
de sinalização de telefonia para redes IP.
(b) Caso o destinatário esteja em uma rede remota, e o endereço seja conhecido, a liga-
ção será efetuada como no passo anterior.
17
(c) Caso o destinatário pertença a um domínio administrativo distinto e seu endereço
de rede não seja conhecido, o dispositivo móvel de origem deverá estabelecer a
chamada usando o identificador do usuário VoIP no servidor VoIP responsável pela
rede de destino.
(d) Do contrário, o dispositivo móvel de origem irá realizar uma conexão com o Ga-
teway VoIP1 da prestadora do serviço mVoIP.
3. Escolherá o codec mais adequado para o tipo de rede utilizada, levando em consideração
largura de banda e outros requisitos do serviço.
4. Trocará dados de voz entre os dispositivos.
5. Terminará a chamada.
Os passos acima citados não são indispensáveis, podem variar de acordo com a aplicação
que implementa o mVoIP. Em Hwang et al. (2010) propõe-se uma arquitetura mais detalhada
para o mVoIP, também inclui-se uma discussão sobre tecnologias sem fio para dispositivos
móveis, como o sistema LTE , do inglês Long Term Evolution 2 e os padrões usados nas WLANs
(ver discussão na seção 3.2).
2.2 PROTOCOLOS ENVOLVIDOS EM UMA CHAMADAMVOIP
Para realizar uma ligação mVoIP, as aplicações embarcadas para VoIP nos dispositivos mó-
veis, ou também chamadas softphones3, utilizam os protocolos já usados em uma chamada
VoIP comum, com a diferença de que agora precisam de garantias mais específicas da rede para
manter o bom estado de uma chamada como será descrito na seção 2.3, ou seja, a qualidade do
áudio e a estabilidade da transmissão e recepção dos dados.
1 Equipamento que faz o estabelecimento da comunicação entre dispositivos de diferentes tecnologias, no casodo mVoIP ele faz o papel de intermediador entre os aparelhos mVoIP e os telefones comuns, incluindo os aparelhoscelulares.
2 É um sistema para comunicação móvel que objetiva altas taxas de transmissão de dados. O LTE foi concebidopara ser adotado pelas operadoras de celulares em paralelo a descontinuação de sistemas existentes, a exemplo doGSM.
3 São assim chamados os programas de computador usados para estabelecer uma chamada de voz sobre a redeIP.
18
2.2.1 INICIALIZAÇÃO DE UMA SESSÃO
Quando o usuário de dispositivo móvel quer realizar uma ligação ele deverá possuir o iden-
tificador, seja um número telefônico, o nome de usuário associado a um domínio ou até mesmo
um IP de uma máquina - normalmente essa forma de identificar a entidade remota é uma URI,
do inglês Uniform Resource Identifier 4 válida, no caso do SIP uma SIP URI - para o qual ele
quer telefonar. Depois disso ele irá discar para acessar o destino usando uma aplicação VoIP,
essa aplicação poderá usar um protocolo próprio, como é o caso do Skype, ou protocolos pa-
dronizados. Entre os protocolos padronizados, um dos mais usados é o SIP , do inglês Session
Initiation Protocol (ROSENBERG et al., 2002), elaborado e padronizado pelo IETF . O SIP é
um protocolo da camada de aplicação que foi criado para estabelecer sessões multimídias na
Internet, responsabilizando-se principalmente pela criação, modificação e término de uma ses-
são. O seu uso é difundido em diversos tipos de aplicações, que fazem chamadas telefônicas,
conferência multimídia ou até mesmo uma distribuição de streaming por uma rede IP.
No SIP os dispositivos finais, telefones IPs, dispositivos móveis e computadores pessoais,
são entidades denominadas agentes, que podem atuar como cliente ou servidor. Essas entidades
utilizam mensagens de texto, similares às usadas nas transações do protocolo HTTP5, para
realizarem a requisição ou resposta de uma determinada função ou determinado método. Em
algumas situações, em que os agentes estão em domínios administrativos distintos e não sabem
ou não podem fazer chamadas diretamente a outros agentes, pode ocorrer, se estiverem em ISP
distintos, que outros elementos extras entrem em cena na arquitetura do SIP. Um dos novos
elementos é o Servidor Proxy que faz o encaminhamento de requisições a outros agente SIP
ou a outro Servidor Proxy se passando pelo cliente, também aparece o chamado Servidor de
Registro que é acionado quando um cliente se torna acessível para ligações destinadas a um
identificador SIP, ele registra o agente SIP gravando sua localização, endereço de rede, porta
TCP/UDP6 e usuário.
Há dois tipos de mensagens no SIP, uma para requisições feitas pelo cliente e outra para as
respostas envias pelo servidor. As mensagens de requisição possuem em seu corpo o nome de
um método ou função solicitada, já a de resposta contém o estado e resultado da requisição. A
tabela 2.1 mostra os métodos e códigos de respostas mais básicos, contidos no protocolo SIP.
4 É um padrão que define a forma de identificação do protocolo e local para acesso a um serviço ou recurso naInternet, esse padrão pode ser consultado no documento WEB <http://tools.ietf.org/rfc/rfc3986.txt>.
5 O protocolo HTTP, do inglês Hypertext Transfer Protocol , é o protocolo por trás do funcionamento daWEB.
6 TCP, do inglês Transmission Control Protocol , e UDP, do inglês User Datagram Protocol, são protoco-los da camada de transporte, uma explanação sobre o funcionamento de cada um deles pode ser encontrada em(KUROSE; ROSS, 2009).
19
Métodos SIP
INVITE Usado para requisitar o estabelecimento de uma sessão.
ACK Para confirmar a resposta de uma solicitação INVITE.
BYE Usado para finalizar a sessão através de um dos agentes SIP.
OPTIONS Para perguntar as funcionalidades suportadas.
REGISTER Utilizada para associar um agente SIP a URI SIP no Servidor de Regis-
tro.
CANCEL Pode cancelar a sessão ou a requisição de um método.
Respostas SIP
1xx Para confirmar a recepção de um método ou informar que uma solicita-
ção está sendo encaminhada.
2xx Remete ao sucesso, entendimento ou realização de um método solici-
tado.
3xx Indica ao cliente que alguma ação será tomada antes de proceder com
uma solicitação, geralmente usada para informar encaminhamentos.
4xx Resposta de erro à solicitação do cliente.
5xx Problema encontrado pelo servidor ao tentar atender uma função supli-
cada.
6xx Falhas consideradas globais, pois não poderão ser atendidas por nenhum
servidor.
Tabela 2.1: Métodos e Repostas SIP
Nem todos os métodos e todas as respostas são usados no estabelecimento de uma sessão
SIP simples entre dois agentes, mas alguns deles são mandatórios, e são mostradas mais a
frente. As mensagens utilizadas no SIP, para criar uma sessão permitem que as partes entrem
em acordo, quanto ao tipo de mídias que serão usados. Isso possibilita que um cliente SIP,
mesmo sem saber sobre os tipos de formatos suportados pelo outro agente, consiga entrar em
acordo e estabelecer a comunicação. O protocolo que permite o acordo entre os agentes sobre as
mídias suportadas e que serão usadas na comunicação é o SDP , do inglês Session Description
Protocol (HANDLEY; JACOBSON; PERKINS, 2006). Ele provê uma maneira de descrever as
codificações usadas em uma sessão com mídias. No SIP ele é usado com o fim de estabelecer
entre as partes envolvidas um acordo quando ao tipo da mídia, o formato da mídia e o protocolo
de transmissão.
O SDP deve ser anunciado no cabeçalho da mensagem SIP e é usado apenas nas mensagens
onde as funcionalidades são trocadas. No SDP são transmitidas as informações do protocolo de
20
transmissão da mídia, no caso do VoIP é informado na maiorias das aplicações o protocolo RTP
, do inglês Real-time Transport Protocol (SCHULZRINNE et al., 2003). O áudio e vídeo pro-
priamente ditos, são enviados através do RTP, que reserva duas portas UDP, uma para a mídia
em sim (o streaming) e outra para o controle do fluxo, que é realizado com o RTCP , do inglês
Real-Time Transport Control Protocol 7. O RTP, embora o nome muitas vezes confunda os seus
utilizadores sobre sua real utilidade, não prove nenhum mecanismo para aplicações de tempo
real (não foi produzido para garante restrições temporais no envio e entrega de informações), é
uma forma de referência temporal na adição de campos com o identificador do pacote, número
de sequência, marca temporal (timestamp8) e informações de monitoramento do fluxo de mídia.
A Figura 2.2 mostra através de um diagrama de sequência de mensagens (MSC9) o fluxo
das mensagens trocadas entre as entidades SIP e alguns dos conteúdos que carregam durante
uma chamada. Nela o "Agente A "é o cliente enquanto o "Agente B "é o servidor. Para iniciar a
comunicação o "Agente A "envia uma mensagem de requisição contendo o método "INVITE",
o "Agente B "envia uma mensagem de resposta com o estado "100 - Trying". Após conseguir
entregar a solicitação à aplicação do servidor, por exemplo um softphone, ele responde com es-
tado "180 - Ringing". Quando a ligação é atendida, o servidor envia uma resposta "200 - OK",
o cliente então envia uma mensagem de requisição com um "OK". A partir desse momento,
através dos parâmetros predeterminados no SDP nas mensagens SIP anteriores, são estabeleci-
das duas conexões com o protocolo RTP/RTCP, uma direciona o áudio do cliente ao servidor e
outra faz o contrário. Por fim, ao término da chamada, um dos agentes envia uma mensagem de
"BYE"e o outro uma resposta com o estado "200 - OK"e assim a chamada é encerrada.
7 O RTCP é definido no mesmo documento que descreve o protocolo RTP, para mais detalhes consultar odocumento (SCHULZRINNE et al., 2003)
8 Termo usado para denotar a utilização de informações que permitem associar o tempo de ocorrência de umevento ao horário corrente.
9 Diagrama de Sequência de Mensagens, do inglês Message Sequence Chart, é um tipo de diagrama usadopara representar interações sequenciais entre entidades, geralmente usado para representar as trocas de men-sagens feitas na execução de um protocolo. A linguagem para descrever esse tipo diagrama foi padroni-zada pelo International Telecommunication Union, mais informações podem ser encontradas na página WEB<http://www.itu.int/rec/T-REC-Z.120>
21
Agente A Agente B
INVITE
100 Trying
180 Ringing
200 OK
ACK
RTP/RTCPRTP/RTCP
BYE
200 OK
Figura 2.2: Exemplo do fluxo de uma sessão SIP/SDP entre dois agentes SIP
2.2.2 TRANSMISSÃO DE ÁUDIO
No envio do áudio de uma chamada VoIP, as ondas sonoras captadas pelo microfone do
aparelho VoIP deverão ser convertidas em dados, para então serem transmitidas como informa-
ção pela rede de computadores. Na conversão e recuperação dessas ondas sonoras, e dos dados,
são usadas técnicas de amostragem e quantização10, que a depender de como e com qual dura-
ção é feita, pode prejudicar ou melhorar a qualidade e necessidade de banda na transmissão do
áudio. O que definir os parâmetros na conversão entre ondas sonoras e dados e vice-versa são os
codecs11. Estes por sua vez podem exigir uma largura de banda alta ao fornecer uma qualidade
ótima da transmissão da mídia, ou podem usar pouca largura de banda da rede e fornecer uma
mídia de qualidade inferior.
Na telefonia IP existem diversos codecs padronizados, comerciais e de domínio público,
mas alguns deles foram criados para redes de dados específicas e não são usados em larga escala
na Internet. Entre aqueles que possuem maior destaque é possível citar o padrão G.729 (ITU-T,
1996a) e o G.711 (ITU-T, 1988), ambos padronizados pelo International Telecommunication
Union e adotados por várias aplicações de VoIP e mVoIP. Ao estabelecer a chamada VoIP com
o protocolo SIP e selecionar o formato de mídia, que será transmitido com o protocolo SDP,
a transmissão do áudio é feita com um dos codecs citados acima, e para que a chamada tenha
uma boa qualidade a taxa de transmissão e banda disponível exigida por eles deve ser garantida.
A Tabela 2.2 mostra algumas informações sobre os dois codecs. Informações disponíveis em
(BORDIM, 2010) e (PER. . . , ).10 Uma introdução a esse tema pode ser encontrada em (BORDIM, 2010).11 Codec, do inglês coder/decoder , é uma abreviação para Codificador e Decodificador.
22
Padrão de
codificação
Tamanho das
amostras de voz a
serem enviadas
Taxa de geração de
amostras do codec
Taxa de transmis-
são necessária na
rede
Qualidade (de
acordo com
MOS12)
G.711 160 Bytes 64 Kbps 87.2 Kbps Excelente
G.729 20 Bytes 8 Kbps 31.2 Kbps Boa
Tabela 2.2: Padrões de codificação de áudio
O protocolo RTP tem um cabeçalho de 12 Bytes, o UDP 8 Bytes, o IP possui mais 20 Bytes.
Somando aos dados do áudio coletado pelos respectivos codecs G.711 e G.729, tem-se o custo
de transmissão na rede, por pacote, que é mostrado na Figura 2.3.
Figura 2.3: Pilha de procolos e dados usados para envio de mídia
Apesar de haver maior utilização de recursos de rede pelo padrão G.711 comparado ao
G.729, ele ainda é muito utilizado em cenários em que a largura de banda não é problema e sua
utilização é justificada pelo ganho na qualidade da transmissão de voz.
2.3 DESAFIOS NA ADOÇÃO DO MVOIP
Diversas empresas, organizações e pesquisadores estão demonstrando interesse nos estudos
das tecnologias e problemáticas envolvidas na comunicação mVoIP. Nesse aspecto, alguns dos
estudos na área comprovam o crescimento da utilização de mVoIP, prospectam o seu avanço e
listam os problemas encontrados na sua aplicação. A pesquisa de mercado feita pela empresa
Point Topic (VOIP. . . , 2012) em 2012, mostra que aplicações mVoIP tem favorecido o cresci-
mento VoIP de um modo geral. Shin (2012), mostra alguns fatores que levam aos usuários de12 MOS, do inglês Mean Opinion Score , é um método para qualificação da voz humana, usado para medir a
qualidade de uma transmissão de áudio.
23
dispositivos móveis a adotarem a telefonia mVoIP, em substituição da telefonia padrão das ope-
radoras de celulares. Nesse estudo verificou-se que tecnologias sem fio e móveis tem tido um
crescimento considerável nos últimos anos. Além disso, diversos mercados no mundo inteiro
estão estimulando maiores investimentos na área, permitindo assim, que aplicações e equipa-
mentos com suportes que permitam o funcionamento nesse modelo de telefonia móvel sejam
desenvolvidos.
Além de Shin (2012), os estudos desenvolvidos por Geer (2009) revelam que a economia na
comunicação é um fator crucial na adoção de mVoIP. Tanto para empresas quanto para usuários
domésticos de dispositivos móveis. Esses estudos também revelam que as empresas de telefo-
nia consideram o mVoIP um concorrente indesejável, e acabam aplicando restrições políticas
no tipo de tráfego permitido em suas redes de dados, ou seja, algumas empresas de telefonia
bloqueiam o tráfego de mVoIP. Essa prática cria um conceito negativo sobre as operadoras.
Contra essas tendências Shin (2012) e também Kim, Park e Ko (2013), mostram que novas for-
mas de cobranças devem ser empregadas pelas operadoras, para que medidas retaliativas não
prejudiquem a utilização de serviços mVoIP pelos assinantes.
Embora as tecnologias de redes WLAN tenham tido um rápido desenvolvimento nos últimos
anos, tanto no âmbito das redes sem fio domésticas, que geralmente possuem equipamentos sem
suporte a tecnologias de priorização de tráfego, quanto nas redes de grandes organizações, que
geralmente possuem equipamentos com tecnologias mais incipientes. O mVoIP ainda não pos-
sui seus requisitos de largura de banda, cadência de entrega do áudio e qualidade de transmissão
garantidos - nesse caso os requisitos de QoS13- nesse tipo de redes, o que afeta diretamente a
qualidade da experiência (QoE14) dos usuários.
Com o intuito de resolver problemas de priorização de tráfegos em redes sem fio no padrão
IEEE 802.11, o IEEE15 lançou a padrão IEEE 802.11e (IEEE. . . , 2005), complementar ao IEEE
802.11. Esse padrão ataca alguns problemas na transmissão de pacotes ao nível da camada
física, que precisam de garantias de QoS. No geral, esse padrão fez modificações ao nível da
camada de enlace, acrescentando novos mecanismos para acesso ao meio sem fio, que permitem
13 Qualidade de serviço, do inglês Quality of Service (QoS), são conjuntos de garantias asseguradas a certostipos de tráfego para que ele seja priorizado em detrimento de outros em uma rede IP. Uma discussão sobre osfundamentos de QoS pode ser encontrada em Kurose e Ross (2009).
14 Qualidade de experiência, do inglês Quality of experience (QoE), é uma medida que estabelece a qualidadeda experiência de uso de um serviço. Para medir essa qualidade, usa-se critérios subjetivos, a exemplo, a opiniãode usuários, que avaliam o quanto uma chamada telefônica foi audível, ou se apresentou lapsos de interferências,e etc.
15 IEEE, do inglês Institute of Electrical and Electronics Engineers , é uma organização que promove padro-nizações de tecnologias no âmbito da engenharia, eletrônica e computação. Atualmente, é responsável por váriospadrões utilizados em equipamentos de comunicação sem fio como o IEEE 802.11, o IEEE 802.15 e IEEE 802.16.A página oficial o IEEE pode ser acessada em <http://www.ieee.org/index.html>.
24
aos equipamentos com tráfego prioritário à transmissão preferencial, em detrimento dos outros
dispositivos da rede. Trabalhos com o propósito de melhoraria do desempenho do IEEE 802.11
foram propostos por outros pesquisadores, como é o caso de Raptis, Vitsas e Paparrizos (2009),
que propuseram métricas para calcular o atraso, nível de perda de pacotes, na função DCF16 do
IEEE 802.11.
Todas essas medidas de melhoramento do IEEE 802.11, para aplicações com necessidade
de QoS, não resolvem todos os problemas encontrados em redes sem fios que operam nesse
padrão. Em redes de múltiplos saltos, como é o caso das Wireless Mesh Network (consultar a
seção 3), outras medidas devem ser tomadas. Técnicas de agregação de pacotes são utilizadas
para diminuir o custo de retransmissão dos pacotes de voz por essas redes, já que normalmente
há vários nós para o fluxo de informação ser retransmitido e a transmissão de um único pacote
por vez não compensa, em relação a probabilidade de que haja a perda. Em (MAJEED; ABU-
GHAZALEH, 2012) e (CASTRO et al., 2007) abordagens para implementar essa técnica são
propostas e analisadas.
Conclui-se que estudo de técnicas, para priorização de tráfego em redes sem fio é uma ne-
cessidade, principalmente quando se considera as especificidades de aplicações de transmissão
de voz pela rede IP.
16 Função Coordenação Distribuída, do inglês Distributed Coordination Function (DCF), é um técnica empre-gada no IEEE 802.11, para controlar o momento da transmissões das estações.
25
3 REDES MESH SEM FIOS
Para a construção de uma rede sem fio, que não esteja atrelada a uma topologia estática e em
que os nós da rede possam utilizar outros nós subjacentes para o envio do tráfego, considera-se
ideal uma rede em malha sem fio, comumente chamada Wireless Mesh Network (WMN). Em
uma rede Mesh, os nós são responsáveis por manter a conectividade da rede de forma dinâ-
mica. Esta funcionalidade é proporcionada por mecanismos que permitem autoconfiguração,
auto organização e crescimento não previsível de equipamentos participantes da rede (HOS-
SAIN; LEUNG, 2008). Ao contrário de outros tipos de rede sem fio, os nós de uma rede Mesh
encaminham dados que não são originados e destinados a eles, de maneira que, há roteamento
entre os nós, mais especificamente roteamento dinâmico, justamente pela imprevisibilidade dos
elementos que a compõe.
Por ter a característica de adaptabilidade topológica, as redes Mesh tem chamado a atenção
de pesquisadores e organizações, geralmente em estudos que tratam problemas relacionados
a redes para situações de desastre e emergência, sistema de socorro e atendimento médico,
sistema para transporte inteligente, redes temporárias, sistemas de vigilância e policiamento,
redes comunitárias e metropolitanas (MISRA; MISRA; WOUNGANG, 2008). Para estruturas
de grandes cidades, as redes Mesh são tidas como solução para problemas de acessibilidade
à Internet, como é apresentado por Siris, Tragos e Petroulakis (2012). As WMN podem ser
empregadas como redes de acesso aos mais variados tipos de dispositivos, isto porque redes
Mesh foram concebidas para possibilitarem a coexistência heterogênea de múltiplas tecnologias
sem fio.
Uma das maiores vantagens de uma rede WMN é sua rapidez, custo de construção e ma-
nutenção, essas características a torna de fácil configuração e montagem (HOSSAIN; LEUNG,
2008). Com o intuito de prover essa funcionalidade, diversas empresas já vendem soluções
prontas para Wireless Mesh Network comunitárias e corporativas, como é o caso da empresa
open-mesh1, que vende uma solução de rede Mesh para compartilhamento de Internet banda
1 Para informações sobre a empresa open-mesh e seus produtos consulte o site <http://www.open-mesh.com/>,outras empresas que também tem produtos similares são Aruba Networks <http://www.arubanetworks.com/products/mesh-routers/> e Cisco <http://www.cisco.com/en/US/netsol/ns621/index.html>.
26
larga.
3.1 ARQUITETURA DE UMA WIRELESS MESH NETWORK
Uma WMN pode servir para diferentes fins, seja redes de acesso, para que pessoas de um
bairro se unam e façam uma rede colaborativa para compartilharem suas conexões à Internet
e ampliarem sua área de cobertura sem fio. A esse tipo de provimento, na maioria das vezes,
os elementos da rede Mesh são arranjados como na Imagem 3.1, nesse exemplo, os nós estão
dispostos na chamada arquitetura de backbone2. Os equipamentos de borda são os cliente Mesh,
representam os dispositivos finais da rede, que fazem o papel de clientes e originam o tráfego
para ser encaminhado pelos roteador Mesh, que por sua vez encaminham o tráfego entre si até
chegar a um dos gateway Mesh. A função dos gateway Mesh é escoar o tráfego, na maioria dos
casos por uma conexão com fio, para a Internet.
Figura 3.1: Arquitetura Backbone Mesh
As redes WMN podem ser empregadas com suporte com mais de uma tecnologia sem fio,
podendo por exemplo, ter uma rede de telefonia, usando 3G, 4G ou GSM e ligada a estrutura
Mesh. Nesse caso, uma torre de telefonia estaria ligada a um roteador Mesh e escoaria todo
2 Essa palavra refere-se aos equipamentos que fazem ,exclusivamente, encaminhamento na parte central deuma rede. Muitas vezes, são equipamentos com alto poder computacional.
27
o tráfego gerado pelos telefones daquela rede, para a rede Mesh. Esta não é a única forma de
heterogeneidade tecnológica nas redes Mesh, na próxima seção serão discutidas algumas delas.
3.2 TECNOLOGIAS WIRELESS
Redes Mesh são normalmente constituídas por nós cuja comunicação, no nível físico, é feita
através de variantes dos padrões IEEE 802.11 (WLAN/Wi-Fi), IEEE 802.15 (WPAN), IEEE
802.16 (WiMAX). No entanto, esse não é o único tipo de tecnologia possível, elementos das
redes de telefonia, de redes de sensores, entre outras também podem ser colocados. Podem
ser formados com essa diversidade de elementos os mais variados cenários, tanto com equi-
pamentos simples como com equipamentos mais robustos. Mas um elemento presente nessa
diversidade de tecnologias são os equipamentos de intermediação, esses dispositivos são em-
pregados como nós comuns, fazem roteamento, podem ter cliente Mesh em sua custódia, mas
existem recursos especiais que os tornam únicos, um desses componentes extras é um outro
rádio (tornando-o um nó com múltiplos rádios) para uma outra rede. Um dos rádios é usado
para trabalhar na tecnologia do backbone Mesh e outro para trabalhar na tecnologia de acesso,
por exemplo, um roteador Mesh conectado a uma estação base de telefonia possuiriam uma in-
terface IEEE 802.16 para comunicação entre si, no backbone mesh o roteador Mesh teria uma
interface de comunicação no padrão IEEE 802.11.
As redes Mesh implementadas em padrões como IEEE 802.11a/b/g/n se limitam a operar
em padrões feitos para redes de infraestrutura, que foram pensados ao nível da camada física e
camada de acesso ao meio (MAC3) para redes de apenas um salto (MISRA; MISRA; WOUN-
GANG, 2008). A depender de onde e para que fim uma rede Mesh está sendo montada, se
os equipamentos forem de padrões derivados do IEEE 802.11, essa rede operará nas taxas de
transferências máximas mostradas na Tabela 3.1. Os equipamentos ainda podem ter sua área
de cobertura variável, a depender do ambiente em que está sendo empregada. Em um ambiente
organizacional, onde os equipamentos podem possuir obstáculos físicos na transmissão, a área
de cobertura pode ser influenciada diretamente, reduzindo drasticamente a vazão possível dos
equipamentos.
Características IEEE 802.11a IEEE 802.11b IEEE 802.11g IEEE 802.11n
Taxa de transferência 54 Mbps 11 Mbps 54 Mbps 248 Mbps
3 MAC, do inglês Medium Access Control , é uma subcamada do IEEE 802.11 responsável por controlar amaneira em que a transmissão dos dados é feita entre as estações.
28
Área de cobertura (am-
bientes internos)
35 metros 38 metros 38 metros 70 metros
Área de cobertura (am-
bientes externos)
120 metros 140 metros 140 metros 250 metros
Publicação 1999 1999 2003 2009
Tabela 3.1: Características dos padrões IEEE 802.11
Para resolver problemas de degradação da banda nas WMN, pensando em sua característica
de crescimento, o IEEE lançou o padrão IEEE 802.11s (IEEE. . . , 2011). Nesse padrão são
estabelecidos mecanismos de controle de congestionamento, de acesso ao meio e para haja
eficiência na escolha do canal de transmissão, tudo isso é propiciado através do monitoramento
da vizinhança pelos nós das redes, observando os canais mais utilizados para transmissão e a
taxa máxima de transferência possível no momento.
3.3 ROTEAMENTO EM WIRELESS MESH NETWORK
Embora tenha sido produzido o padrão IEEE 802.11s para operação em uma rede Mesh,
ainda há diversos aspectos que são tema de pesquisas, tanto ao nível da camada física, com
protocolos de acesso ao meio, ainda mais eficientes, e garantias de transmissão para serviços
que necessitem de QoS, por exemplo.
No roteamento do tráfego nas WMN, são feitos diversos estudos para prover algoritmos
e métricas eficientes para os diversos cenários possíveis nessas redes. Yang, Wang e Kravets
(2005), analisaram duas formas de roteamento, a forma pró-ativa e a reativa. A primeira se dá
quando os nós da rede procuram conhecer um destino específico, sem que haja uma necessidade
explícita de roteamento até este. Já a reativa é um pouco mais moderada, e um roteador Mesh
só irá procurar por uma rota quando houver a necessidade de transmitir uma informação até ele.
Nesse estudo também foram discutidos os tipos de roteamento na Origem (Source Routing4),
salto-a-salto (Hop-by-Hop5) sob demanda (On-Demand6). E ao final do estudo Yang, Wang
4 É uma técnica de roteamento em que o encaminhamento dos pacotes de uma determinada origem é definidapela própria origem. Essa abordagem permite que o nó de origem do tráfego escolha por onde quer que seu tráfegoseja roteado, sem depender do algoritmo de roteamento dos nós intermediários. Normalmente são colocados emcada pacote, o caminho completo por onde o pacote deve ser encaminhado, o que pode causar um consumo extrapara a rede.
5 Nesse modelo de roteamento, cada nó é responsável por manter suas rotas com informações de próximossaltos para um determinado destino de rede, dessa forma, o roteador de origem não precisa conhecer todo ocaminho até um destino e cada roteador da rede pode escolher com critérios locais a maneira de encaminhar ospacotes.
6 Os nós não procuram, de forma pró-ativa, conhecer rotas para determinados destinos de redes. Só é feita
29
e Kravets (2005), mostraram que o roteamento salto-a-salto é o mais apropriado para redes
Mesh. Eles também avaliaram algumas métricas de roteamento em redes sem fio, e avaliaram
sua eficácia e impacto em uma rede Mesh. Também foram propostas métricas exclusivamente
pensadas para uma rede Mesh, levando em consideração que os nós centrais são normalmente
estacionários e que existe muita interferência eletromagnética entre estes equipamentos. Outro
trabalho, relacionado a métricas de roteamento em WMN, mas focado em redes Mesh com
múltiplos rádios sem fio, foi feito por Guerin, Portmann e Pirzada (2007).
Métrica Descrição Protocolos que
utilizam
Número de
saltos
É a métrica mais simples, é usada para encontrar o
menor, e livre de loops, caminho entre uma roteador
de origem e um outro destino. Essa métrica não leva
em consideração nenhum aspecto de perda de pacote
e diferença de largura de banda entre enlaces em um
caminho.
DSR7, AODV8,
DSDV9, GSR10 e
OLSR11
ETX Uma abreviação para Expected Transmission Count,
essa métrica contabiliza a quantidade de retransmis-
sões necessárias para encaminhar um pacote de uma
origem a um destino. Essa métrica não considera in-
terferência entre os equipamento
OLSR
ETT É um acrônimo para Expected Transmission Time, pa-
recida com a métrica ETX, leva em consideração as
diferentes bandas nos enlaces intermediários a uma
origem e destino na rede.
OLSR, AODV-
ST13
uma pesquisa na vizinhança, para saber como encaminhar até uma rede, quando um pacote, com essa demandachega ao roteador. Esta técnica de roteamento pode causar bastante atraso nos momentos iniciais, pois o roteadordeverá apreender a rota até o destino, no instante em que o pacote lhe é entregue.
7 DSR, do inglês Dynamic Source Routing , é um protocolo para rede Mesh de roteamento na origem e sobdemanda.
8 AODV, do inglês Ad hoc On-Demand Distance Vector , foi originalmente feito para redes ad-hoc12, caracte-rizado por ser reativo e com roteamento sob demanda.
9 DSDV, do inglês Destination-Sequenced Distance Vector , é um protocolo também projetado para redesad-hoc, mas que tem seu uso estudado em redes Mesh.
10 GSR, do inglês Global State Routing , é um protocolo baseado no estado de enlace, pró-ativo e destinado aextinguir mensagens de flood na rede.
11 OLSR, do inglês Optimized Link State Routing Protocol , é um protocolo de roteamento para redes ad-hocinicialmente focado em tratar a mobilidade de nós.
13 AODV-ST, do inglês AODV-Spanning Tree , é uma expansão do protocolo AODV.
30
WCEET É uma métrica que tenta reduzir o número de nós no
mesmo canal de transmissão sem fio, que estejam em
um mesmo caminho.
MR-LQSR14
RTT Per-hop Round Trip Time, é uma métrica de custo de
enlace, focada em medir o round trip time (RTT) entre
nós vizinhos.
MUP15
Tabela 3.2: Métricas de roteamento em redes Mesh
A compilação de algumas métricas usadas nas redes Mesh e os protocolos de roteamento
que a utilizam é mostrada na Tabela 3.2. Uma discussão mais aprofundada sobre protocolos
e métricas de roteamento em redes Mesh pode ser encontrada em Misra, Misra e Woungang
(2008) e Hossain e Leung (2008).
14 MR-LQSR, do inglês Multi-Radio - Link Quality Source Routing , é um protocolo de roteamento na origempensado para ambientes com equipamentos multi rádios.
15 MUP, do inglês Multi-Radio Unification Protocol , é um protocolo para otimização, local, de congestiona-mento de canais de transmissão.
31
4 REDES DEFINIDAS PORSOFTWARE
Diversos especialistas e pesquisadores evidenciam as falhas da arquitetura atual da Internet,
além disso, apontam soluções alcançáveis para as respectivas falhas. Porém, realizar modifica-
ções ou até mesmo adição de funcionalidades em protocolos em operação na rede não é tarefa
das mais simples. Um exemplo, é o protocolo IP, que ainda é o mesmo desde a criação da
Internet. Mesmo que propostas de mudanças, padronizadas, tenham sido feitas, não foram to-
talmente implementadas na prática, como é o caso do protocolo IPv61, que foi proposto para
solucionar o problema de escassez de endereços IPv42. Mas ainda hoje, sua implantação é
dificultada por motivos técnicos e culturais, os motivos técnicos são facilmente justificados
pela complexidade e inflexibilidade dessa arquitetura ossificada da Internet (SPYROPOULOS;
FDIDA; KIRKPATRICK, 2007).
Há algum tempo, tem havido discussões na comunidade científica sobre o que deve ser feito
na Internet para que ela seja mais flexível e permita que novas funcionalidades sejam agregadas,
sem oferecer riscos ao seu funcionamento. Embora não haja consenso geral, a maioria dos pes-
quisadores defende que uma arquitetura mais robusta e extensível seja alcançada para Internet.
E em meio às discussões, para facilitar as transformações e implementações de propostas inova-
doras na Internet, surgem as redes definidas por software, do inglês Software-Defined Networ-
king (SDN). Nesse sentido, com SDN, as dificuldades em transformar as propostas inovadoras
da academia em tecnologias para efetiva utilização na Internet são reduzidas. As dificuldades
existentes em ambientes sem SDN vão desde a experimentação, com ambientes pouco adequa-
dos para a validação das propostas e garantia do funcionamento prático, até no que se refere
ao tempo necessário na implantação de novas funcionalidades nos equipamentos comerciais,
que na maioria dos casos passam por processos de controle interno nas empresas, para serem
colocados à venda depois de muito tempo.
1 IPv6, do inglês Internet Protocol version 6 , a RFC que descreve esse protocolo pode ser consultada em<http://www.ietf.org/rfc/rfc1752.txt>.
2 IP versão 4, a RFC que especifica esse protocolo pode ser encontrada em <http://www.ietf.org/rfc/rfc791.txt>.
32
4.1 ARQUITETURA SOFTWARE-DEFINED NETWORKING
Com SDN é definida uma arquitetura para os componentes de rede, de maneira a torná-la
mais dinâmica e adaptável. Nessa arquitetura, objetiva-se a dissociação do plano de controle e
de dados, deixando a inteligência da rede centralizada e os equipamentos de comutação apenas
com a responsabilidade de encaminhamento.
O plano de controle é o centro da arquitetura, sendo o responsável por coordenar os equi-
pamentos de rede de acordo com as políticas de alto nível definidas pelas aplicações. Com
o plano de controle separado do plano de dados, a tarefa de gerenciar as redes torna-se mais
fácil, pois os dispositivos de rede podem ser programados de acordo com o plano de controle
sem precisarem de intervenções ao nível mais baixo para que seu comportamento mude. Dessa
forma é possível, por exemplo, que um protocolo de roteamento seja implantado na rede sem
necessitar de uma intervenção em cada um dos equipamentos que a compõe, ou seja, a mudança
só seria realizada nos dispositivos que implementam o plano de controle. Já o plano de dados é
composto apenas pelos equipamentos de comutação e os programas que fazem a interface com
o plano de controle, sendo assim, são componentes simples, tirando assim dos fabricantes de
equipamentos de rede a necessidade de embarcarem sistemas operacionais inteiros em cada um
dos dispositivos.
Camada de aplicação
Camada de Controle
Camada de Infraestrutura
Dispositivos de Rede
Dispositivos de Rede
Dispositivos de Rede
Controlador de redeServiços de RedeServiços de Rede
Regras de NegócioRegras de Negócio
Interface de Comunicação
Interface de Com o Plano de Dados
Figura 4.1: Arquitetura Software-Defined Networking
Na Imagem 4.1 é mostrada a arquitetura SDN, os dispositivos de redes são dotados apenas
da funcionalidade de comutação de pacotes, enquanto que são gerenciados a partir de uma
33
interface programável pelos controladores de rede. Os controladores de redes por sua vez,
podem implementar os mais variados tipos de serviços, desde os já conhecidos como DNS e
DHCP, aos mais inovadores e complexos. Isso permite que novas funcionalidades e propostas
de protocolos sejam implementados em uma rede, sem passar pelo processo de serem agregados
aos programas disponíveis pelos fabricantes de dispositivos de redes.
Com SDN uma série de limitações encontradas nas arquiteturas das redes tradicionais
tornam-se solucionáveis, motivo pelo qual diversas organizações, empresas e pesquisadores,
que atuam na área de redes vem realizando esforços para incentivar a criação de ferramentas
que implementem esse paradigma.
4.2 OPENFLOW
Diretamente ligado a SDN surge o OpenFlow, que é um padrão aberto, que define uma
arquitetura padronizada para execução de testes com protocolos de rede experimentais (MC-
KEOWN et al., 2008). O OpenFlow fornece uma interface para programação dos dispositivos
de rede, juntamente com um protocolo para realizar a comunicação com o plano de controle.
Com o OpenFlow, os equipamentos de redes tais como switches, roteadores e pontos de acesso
sem fio podem ser programados de acordo com as políticas implementadas em um controlador
de rede.
A depender de como é projetada a implementação do OpenFlow no equipamento de rede,
este pode ser classificado em dois tipos de equipamento. O primeiro é OpenFlow-only, nessa
implementação, o dispositivo funciona apenas como comutador de fluxo OpenFlow e não trata
fluxos de rede comum. Se implementado como um OpenFlow-hybrid, o equipamento é consti-
tuído por uma arquitetura para o tratamento do fluxo de rede comum, mas possui o recurso extra
que o propicia operar seguindo a arquitetura OpenFlow. Dessa última forma, o dispositivo de
rede pode tanto tratar o fluxo de rede comum quanto o OpenFlow.
4.2.1 ARQUITETURA DO OPENFLOW
O OpenFlow é divido em alguns componentes de rede, o switch como equipamento comu-
tador e responsável pelo plano de dados, o controlador como centralizador da estrutura no plano
de controle, o canal de transporte seguro que possibilita a comunicação, de forma segura, entre
o controlador e os dispositivos de rede e por fim o próprio protocolo OpenFlow. E a depender
da versão do OpenFlow implementada, os equipamentos terão alguns recursos extras - como
34
tabelas de grupos, vide Figura 4.2 - , nessa caso serão abordados aqui, apenas os principais
aspectos da arquitetura OpenFlow baseados nas versões 1.0 (CONSORTIUM et al., 2009) e 1.1
(CONSORTIUM et al., 2011).
Canal Seguro Tabela de Grupo
Tabela de FluxoTabela de Fluxo
Controlador
Protocolo OpenFlow
Divisão interna do equipamento com
OpenFlow
Dispositivo de rede
Entidades externas
Fluxo das interações imediatas
Figura 4.2: Arquitetura do OpenFlow
Embora a estrutura da arquitetura OpenFlow seja tratada separadamente, todos os compo-
nentes tem um papel imprescindível no funcionamento de uma rede que implemente a arqui-
tetura OpenFlow. Todos os componentes devem estar disponíveis em qualquer cenário básico.
Na Figura 4.2 é mostrado a disposição dos elementos na arquitetura do OpenFlow. Os switches
estão conectados ao controlador por um canal de transmissão seguro, e essa comunicação entre
eles é regida pelas mensagens do protocolo OpenFlow.
4.2.2 SWITCH OPENFLOW
O switch OpenFlow trata unidades do fluxo de rede, que serão chamados de pacotes para
simplificar a linguagem. Os pacotes recebidos pelo switch são processados seguindo etapas bem
definidas, primeiramente os pacotes são acrescidos com a informação de porta de origem (porta
de ingresso do pacote no switch) para um posterior processamento, que é feito comparando os
dados dos pacotes com as regras de encaminhamento em tabelas.
Um switch OpenFlow pode ter várias tabelas, estas tabelas são uma estrutura de dados com
35
informações a serem usadas no processamento dos pacotes recebidos, cada tabela contém um
conjunto de entradas contendo regras, que possuem a função de informar as ações que devem
ser executadas para encaminhar o pacote ao seu destino.
A especificação das entradas as divide em três segmentos, os quais podem ser visualizados
na ilustração da Figura 4.3. O primeiro campo ou Match Fields tem as informações necessárias
para averiguar se um pacote pertence a um fluxo de dados ou não, ou seja, permite comparar o
um padrão com os campos no cabeçalho dos pacotes. O segundo campo ou Counters possuem
informações estatísticas e informativas para comunicação entre as tabelas3, já o terceiro campo,
chamados de Actions, possuem as instruções a serem aplicadas no pacote que combinam com o
padrão descrito no campo de comparação (o primeiro campo da figura).
Campos de comparação Contadores Ações
Figura 4.3: Entrada em uma tabela de regras de um switch OpenFlow
O fluxo do pacote no switches começa a partir da primeira tabela4 do switch OpenFlow, que
usa as informações do pacote para saber se esse corresponde a um padrão de fluxo registrado
nas entradas na tabela. Caso nenhuma entrada na tabela reflita o padrão do pacote, que está
sendo processado, o pacote poderá ser descartado, enviado ao controlador OpenFlow ou pode
até sofrer uma outra ação arbitrária. Ao coincidir com uma entrada na tabela o pacote pode
ser encaminhado para uma outra tabela, caso exista uma instrução no conjunto de ações que
designe esse encaminhamento, esse desvio pode ser ocasionado pela necessidade de tratar certos
pacotes de múltiplas maneiras (combinando com uma regra em cada tabela). A única limitação
que ocorre nesse desvio é de que o índice da tabela corrente seja menor que o índice da tabela
para onde o pacote será enviado. Por fim, se o pacote não sofre nenhum encaminhamento
com destino à outra tabela e se seu conjunto de ações tiver ao menos uma ação, ele a executa,
encaminhando assim o pacote por uma porta de saída no switch OpenFlow.
A forma como o switch OpenFlow encaminha os pacotes entre as tabelas é chamado de pipe,
isto é, o fluxo de transição que o pacote sofre desde a entrada no switches até sua saída em uma
das portas. Na Figura 4.4 é mostrado o processo ao longo do pipe. Inicialmente ao ser recebido
3 O OpenFlow atualmente está na versão 1.4, mas a depender da versão que um equipamento implementaalgumas funcionalidades podem ou não estarem disponíveis. Mais detalhes sobre a especificação do OpenFlowsão encontrados na página da Open Networking Foundation <https://www.opennetworking.org/>.
4 Na versão 1.0.0 do OpenFlow, a qual é a única implementada em vários dos switch OpenFlow disponíveis,só existe uma tabela, embora o comportamento descrito no texto seja o mesmo. Em outras versões existe o conceitode tabela de grupos, que no escopo de trabalho não será abordada.
36
pelo switches, o pacote é encaminhado ao processamento, seus campos serão comparados as
entradas da Tabela 0, posteriormente caso ocorra o encaminhamento entre as tabelas, o pacote
irá percorrer cada umas das tabelas do pipe em ordem crescente do índice. Ao final, todas as
ações armazenadas ao longo do percurso no pipe serão executadas, e a depender do resultado o
pacote é encaminhado a uma porta de saída.
Tabela 0 Tabela 1 Tabela n
Executa o conjunto de ações
Switch OpenFlow
Saída do pacote
Entrada do pacote
Figura 4.4: Etapas no tratamento de pacotes no switch OpenFlow
CAMPOS DE COMPARAÇÃO
Para saber quais regras serão aplicadas em um pacote são usados os campos de comparação
(Match Fields). Estes campos são oriundos da estrutura de próprio pacote na rede. Abaixo
segue uma lista desses campos usados no tratamento dos pacotes no pipe do switch OpenFlow.
1. Porta de entrada
2. Metadados
3. Endereço Ethernet de origem
4. Endereço Ethernet de destino
5. Tipo de endereço Ethernet
6. Identificado de VLAN
7. Prioridade da VLAN
8. Rótulo MPLS (a depender da versão do OpenFlow)
9. Classe de tráfego MPLS (a depender da versão do OpenFlow)
10. Endereço IP de origem
11. Endereço IP de destino
37
12. Protocolo IP
13. IP ToS
14. Porta de origem do protocolo de transporte ou tipo ICMP
15. Porta de destino do protocolo de transporte ou código ICMP
É possível, utilizando os campos mostrados acima, definir maneiras de tratar o fluxo basea-
dos nas informações já existentes em uma rede operacional. Sendo que os protocolos podem ser
implementados com as informações de qualquer uma das camadas de rede tratada pelo switch
OpenFlow.
O trajeto feito feito por um pacote, ao passar pelo pipe de um switch OpenFlow, é detalhado
na Figura 4.5. O fluxo começa com a entrada do pacote no pipe do switch OpenFlow (etapa
representada na figura pela estrutura no ponto 1), iniciando pela tabela 0, é verificada em cada
entrada da tabela se o pacote combina com alguma das entradas na tabela (essa etapa é repre-
sentada no ponto de decisão sinalizado pelo número 2). Caso combine com alguma ação, são
atualizados os campos de informações e de ações do pacote, além dos contadores da entrada na
tabela (na figura essa etapa é sinalizada pelo número 3). Depois o pacote é encaminhado para
um ponto de decisão (o ponto de número 4), onde é verificado se o pacote contém alguma ação
de encaminhamento para uma outra tabela, se tiver ele é encaminhado. Caso não possua, as
ações relacionadas ao pacote analisado são executadas (essa etapa é representada na figura no
ponto de número 5) e o pacote é encaminhado ao seu destino encontrado (porta de saída). Como
é mostrado na figura (na etapa de número 2), caso o pacote não coincida com nenhuma regra na
tabela, o pacote pode ser encaminhado para umas das ações mostradas na etapa de número 6.
38
Atualização dos contadoresExecução das ações:
Atualizar o conjunto de açõesAtualizar o conjunto de campo de comparaçãoAtualizar os metadados
Execute oconjunto de ações
Execute uma das ações abaixo baseado na configuração da tabela:
Enviar ao controladorDescartarContinuar para próxima tabela
Entrada do pacote
Inicio na tabela 0
Casa com algumEntrada
na tabela n?
Ir paratabela n+1
Sim
Sim
NãoNão
1
2
3
4
5
6
Figura 4.5: Fluxo de um pacote através do pipe em um switch OpenFlow
Após o pacote ter completado sua passagem por todas as tabelas indicadas, este irá possuir
um conjunto de instruções a serem aplicadas de forma a modificar o pacote e a encaminhá-lo.
Com essas instruções o pacote é alterado de maneira a ter seu destino traçado por uma porta de
saída. Caso não exista nenhuma entrada na tabela que coincida com as informações extraídas do
pacote, ele é enviado ao controlador. Uma outra possível ação para pacotes que não coincidam
com nenhuma entrada na tabela do switch OpenFlow é o descarte do pacote, ou seja, o switches
pode estar configurado para descartar os pacotes que não coincidam com nenhum dos padrões
ao invés de enviá-los ao controlador. Dessa forma entre as ações definidas para um pacote ao
final de sua passagem pelo processamento do switch OpenFlow, estão o envio da informação ao
controlador, o descarte do pacote, o envio do pacote para o processamento na próxima tabela de
índice numericamente maior ou caso tenham encontrado um destino correto o encaminhamento
a uma das portas de saída do switches.
CONTADORES
Os contadores podem ser usados para manter informações sobre os pacotes que passaram
por uma determinada entrada, seja em uma tabela, fluxo ou porta.
Nos contadores de uma tabela por exemplo, são armazenadas informações de quantos paco-
tes foram processados, quantos casaram com o padrão. Já em contadores de fluxo são guardadas
informações de quantos pacotes foram recebidos, quantos bytes foram recebidos, qual a dura-
39
ção do fluxo em segundos e milissegundos. Para uma porta é essencial manter informações de
quantos pacotes foram recebidos e transmitidos, quantos bytes foram recebidos e transmitidos,
pacotes que foram descartados, quantidade de erros, seja de transmissão ou recepção de pacotes
ou quadros, mas podem ser armazenadas as quantidades de colisões, etc.
Todos esses campos podem ser usados pelo controlador para tomar decisões quanto a regras
que serão modificadas no switch OpenFlow, dessa maneira é possível projetar protocolos que
funcionem de maneira dinâmica.
4.2.3 CANAL DE COMUNICAÇÃO SEGURO
Quando o switch OpenFlow não sabe como tratar um pacote, ele o envia ao controlador,
que tem a responsabilidade de decidir qual será o tratamento dado aos pacotes que coincidam
com o padrão encontrado, após esse tratamento, o controlador pode enviar ao switches as regras
que devem ser aplicadas nesse fluxo identificado a partir do próximo pacote que chegar no swit-
ches. As informações em todo esse processo é realizada através de um canal de comunicação
estabelecido entre o switches e o controlador, chamado de canal de seguro.
Prioritariamente, o canal seguro, é estabelecido acima por uma conexão TCP/IP com uso
de criptografia, mas em alguns casos, também é possível não utilizar criptografia (a depender
da implementação da arquitetura OpenFlow).
4.2.4 PROTOCOLO OPENFLOW
O protocolo OpenFlow define as mensagens e o formato adequado destas, na comunicação
entre o controlador e os switch OpenFlow. Existem 3 categorias de mensagens que podem ser
trocadas uma para as mensagens oriundas do controlador e destinadas ao switches (controller-
to-switch). Essas mensagens são enviadas pelo controlador e podem ter confirmação de recebi-
mento ou não. Outro tipo de mensagem chamada de assíncrona (asynchronous), é enviada pelo
switches ao controlador para notificações, são disparadas a partir de ocorrências no switches que
podem ser aleatórias. Enfim, as mensagens do tipo simétrica (symmetric), podem ser envidas
nas duas direções e normalmente necessitam de respostas de recebimento.
Cada uma das categorias citadas acima são divididas em outras subcategorias que descre-
vem os tipos de mensagens a serem trocadas entre o switches e o controlador. Existem men-
sagens para envio de parâmetros, para envio de regras ao switches, entre outras. Na Tabela
4.1 mostra-se onde são sumarizadas as mensagens pertencentes a cada categoria descrita nessa
seção.
40
Mensagens do controlador para o switches
Features Requisita informações de recursos implementados pelo switches.
Configuration Enviada para modificar configurações do switches.
Modify-State Modifica entradas na tabela do switches ou na configuração das
portas.
Read-State Requisita as informações estatísticas do switches.
Packet-Out Usada pelo controlador para especificar as ações a serem efetiva-
das para um pacote enviado previamente pelo switches.
Barrier Mensagem utilizada pelo controlador para verificar se uma men-
sagem enviada foi tratada corretamente, ou se um pedido anterior
terminou.
Mensagens Assíncronas
Packet-In Usada pelo switches para informar ao controlador sobre um novo
tipo de fluxo, em que não existe regra apropriada para tratá-lo.
Flow-Removed Notifica o controlador, caso este tenha solicitado, sobre o término
do tempo de vida de uma regra na tabela.
Port-Status Enviada quando há uma mudança no estado de alguma porta no
sswitches, que pode ter sido ocasionada, por exemplo, pela queda
de um enlace.
Error Somente enviada ao controlador na ocorrência de algum pro-
blema.
Mensagens Simétricas
Hello Usada para iniciar a comunicação entre o controlador e o switches
Echo-Request Pode ser usada pelo switches ou pelo controlador, se houver a
necessidade de verificar latência, largura de banda ou até mesmo
manter a conexão entre eles funcional.
Echo-Reply Resposta a mensagem de Echo-Request.
Experimenter É uma mensagem para implementação de funcionalidades extras
nos switch OpenFlow.
Tabela 4.1: Sumário das principais mensagens especificadas
no OpenFlow
41
4.2.5 CONTROLADOR OPENFLOW
O controlador OpenFlow é responsável por informar e regular a maneira como o switch
OpenFlow opera. Isto é feito através da manipulação dos pacotes sem regra definida ou pelo
tratamento de novos fluxos de pacotes identificados pelo switches. Um controlador pode remo-
ver e adicionar entradas em uma tabela de fluxo através de mensagens do protocolo OpenFlow.
Na Figura 4.6 é possível visualizar o trajeto realizador por um fluxo que ainda não tem um
tratamento definido nos equipamentos switch OpenFlow. Primeiramente o ponto de acesso sem
fio, ao receber o fluxo vindo de uma estação de trabalho, verifica se há entrada em sua tabela,
mas depois, como o fluxo é desconhecido, o switch OpenFlow envia ao controlador o pacote, o
controlador processa e então envia de volta ao switches a regra a ser acrescentada na tabela e o
pacote a ser processado, após isso o switches encaminha para a porta de destino. Se existir uma
regra colocada pró-ativamente pelo controlador quando o fluxo chegar ao segundo switches,
este irá entregar a estação de trabalho de destino, mas caso não tenha sido feito essa ação pelo
controlador, o mesmo será feito para o tratamento do pacote desconhecido.
Figura 4.6: Exemplo de cenário contendo equipamento com suporte a OpenFlow
Um controlador pode identificar um padrão de fluxo, e com isso realizar, por exemplo, o
isolamento dele através de identificadores como VLAN , porta TCP ou UDP, entre outros tipos
suportados. Além disso é possível isolar tráfegos experimentais do tráfego de produção, através
do uso de restrições no processamento de alguns tipos de pacotes pelo pipe do OpenFlow.
42
Desse modo, pacotes podem ser tratados pelo fluxo de operação padrão do switches ao invés
dos experimentais.
Dessa forma a arquitetura OpenFlow possibilita desenvolver testes necessários para validar
novos protocolos, realizar à analise do comportamento de uma rede mista, por exemplo, para
transição entre tecnologias, e mensurar a capacidade necessária para uma rede comportar certos
tipos de tráfegos.
43
5 ROTEAMENTOMULTICAMINHOS
Dentre os diversos paradigmas de comunicação em redes de computadores unicast1, mul-
ticast2, manycast3, entre outras, o roteamento multicaminhos , do inglês Multipath Routing,
é uma forma de permitir caminhos alternativos, quando há roteamento na comunicação, entre
uma origem e um destino na rede.
5.1 ESPECIFICIDADES DO ROTEAMENTO MULTICA-MINHOS
Este tipo de roteamento possui diversas vantagens no que se refere ao roteamento tradicio-
nal, tolerância a falhas é uma delas, pois caso um dos caminhos seja comprometido, o destino
das mensagens ainda será alcançável pelos caminhos alternativos imediatamente disponíveis, a
depender é claro, de como é implementado o roteamento multipath, pois em algumas estraté-
gias os roteadores apenas utilizam os caminhos alternativos em caso de falha, já em outras os
múltiplos caminhos são sempre usados em um esquema de revezamento, baseado em alguma
política de alternação. Essa estratégia permite que os caminhos sejam sempre usados, possibili-
tando que um caminho não mais existente ou com características prejudiciais ao funcionamento
da rede não cessem uma comunicação. Outro ponto positivo no roteamento multipath é a possi-
bilidade de aumentar a vasão efetiva do tráfego de uma rede, permitindo que uma origem envie
seu tráfego de maneira distribuída entre os caminhos disponíveis. Nesse modelo, os caminhos
alternativos, muitas vezes menos utilizados, tem função especial. Possibilitando que o tráfego
que antes sobrecarregaria um conjunto de enlaces no caminho principal, tendam a homogenei-
1 É o tipo de transmissão em uma rede onde um pacote destina-se a um único host, que responde unicamentepelo endereço.
2 Em uma rede, é o tipo de transmissão que destina-se a um grupo de hosts, que respondem pelo mesmoendereço de rede.
3 É um paradigma de comunicação em grupo, onde um cliente comunica-se simultaneamente com parcelas deum grupo de servidores conhecidos.
44
zar a distribuição da carga pelos caminhos. Esta última vantagem ainda acarreta em um maior
aproveitamento da rede, pois a subutilização pode ser minimizada, espalhando o tráfego pelos
caminhos disponíveis para que a rede, como um todo, não sofra com o congestionamento cau-
sado pelo uso de um caminho único. O estudo feito por Cidon, Rom e Shavitt (1999) mostra,
por exemplo, os benefícios do roteamento multicaminhos, em relação ao roteamento com um
único caminho.
No funcionamento do multipath, como é mostrado na Figura 5.1, um nó de origem N1 ao
receber um tráfego pode encaminhá-lo através de um dos caminhos disponíveis até o destino
do tráfego. No exemplo da imagem temos o destino N5, que poderá receber o tráfego oriundo
de N1 tanto pelo seu vizinho N4 quanto pelo N3. Supondo que um conjunto de pacotes de uma
mesma origem, que tenha como destino as redes sob a responsabilidade de N5 e que cheguem
em N1 para que eles sejam encaminhados. Ao verificar sua tabela de roteamento o roteador N1
irá encaminha o pacote para o roteador N2 ou N3, essa escolha irá depender da política usada
para variar os pacotes entre os caminho disponíveis, usando como exemplo o escalonamento
Round-Robin (R.R.)4 (R.R.), ao encaminhar o primeiro pacote o roteador escolheria, por exem-
plo, o caminho por N2, que encaminharia diretamente ao nó N5. Ao receber o segundo pacote
o nó N1 encaminharia para o segundo caminho selecionado, que no caso tem como próximo
salto o roteador N3, que por sua vez encaminharia para o nó N4, que por último enviaria ao
N5. Os próximos pacotes seguiriam a mesma política até que o tráfego cessasse ou os melhores
caminhos até o nó N5 mudassem. Neste cenário exemplificado não é levado em consideração
outros padrões de agregação dos pacotes, pois o Round-Robin está sendo feito por unidade de
pacote, mas vários pacotes com cabeçalhos similares poderiam ser transmitidos por um mesmo
caminho, o que pode minimizar o custo computacional de variar o encaminhamento do pacote
com base em informações muito granulares.
4 O Round-Robin é uma política de escalonamento, que proporciona a escolha alternada de uma determinadatarefa em um conjunto de tarefas. A idéia é que se um conjunto de tarefas tiver cardinalidade n, ao se escolher umadessas tarefas ela só será selecionada novamente após outras (n-1) escolhas.
45
Figura 5.1: Roteamento multipath
5.2 SPLIT DE TRÁFEGO
A técnica de distribuição do tráfego por vários caminhos recebe o nome Traffic Splitting, ela
possui diversas abordagens que podem variar a depender do objetivo prospectado com o multi-
path. Uma forma muito comum de fazer o split é baseado em pacotes, do inglês Packet-based
traffic splitting. Porém, esta maneira pode acarretar alguns problemas clássicos (THALER;
HOPPS, 2000), o primeiro deles é a diferença de MTU5 entre os enlaces dos caminhos, usando
como exemplo da Figura 5.1 o caminho em verde poderia ter entre o nós a MTU de 1500 By-
tes, enquanto que o caminho em vermelho poderia passar com enlaces com tamanho de MTU
menor. Nesse caso, é possível que alguns protocolos que usam fragmentação, como é o caso
do IPv4 não funcionem corretamente. Outro problema que pode ocorrer é diferença de atraso,
um caminho pode oferecer um atraso maior que o outro, seja por congestionamento ou pela
tecnologia de transmissão usada. Nesse caso, ocasionará no evento chamado entrega fora de or-
dem, do inglês Packet Reordering. Na Figura 5.2(a) é mostrado um exemplo de Traffic Splitting
baseado em pacotes, cada um dos pacotes é distribuído entre os caminhos possíveis seguindo
uma política de escalonamento definida, não é levado em consideração a origem do tráfego e
destino de tráfego, os protocolos de camadas superiores que são utilizados, e muito menos o
5 MTU, do inglês Maximum Transmission Unit, é o tamanho da unidade máxima de dados que pode ser enviadaao equipamento vizinho em uma única transmissão. Para mais informações a respeito ver: Kurose e Ross (2009).
46
serviço que está sendo provido ao nível da aplicação.
Um problema que pode ser encontrado no Traffic Splitting, caso não seja levado em conside-
ração que pacotes com mesma origem e destino podem tomar caminhos distintos, é a ineficácia
de algumas ferramentas de depuração de rede, como é o caso do traceroute6, que poderá retor-
nar resultados diferentes para cada salto que for consultado, o que elevará a construção de rotas
errôneas.
Figura 5.2: Técnicas de Traffic Splitting
Uma outra forma de fazer a técnica de split é com base em fluxos, do inglês Flow Based,
nessa abordagem os pacotes são agrupados em critérios mais elaborados, baseando-se em cam-
pos do cabeçalho de cada pacote para encaminhá-lo a um dos enlaces disponíveis. Pode-se
nessa técnica agrupar os pacotes baseado na origem e destino, permitindo resolver o problema
das ferramentas de depuração de rede. Porém, são inseridas novas dificuldades. Primeiro é
quanto ao números de fluxos que serão armazenados, pois para cada origem e destino um novo
registro com essa informação deve ser armazenado. Caso campos mais específicos sejam uti-
lizados para tratar o fluxo o problema em algumas ferramentas de depuração continuará. Pois
um fluxo, que por exemplo, for agrupado com base na porta de destino TCP e seja enviado
6 traceroute é uma ferramenta de depuração de rede que utiliza o tempo de vida do IP para descobrir osroteadores que intermediam uma rota.
47
por um determinado caminho, poderá não coincidir com o caminho utilizado pela ferramenta
traceroute. Uma amostra do funcionamento dessa técnica, distribuindo fluxos por caminho dis-
tintos, é mostrado na Figura 5.2(b), os pacotes de cores distintas representam fluxos distintos
identificados.
Um outro problema que pode ocorrer utilizando split baseado em fluxos é a sobrecarga de
determinados enlaces, impactando diretamente no desempenho de uma aplicação que esteja ca-
racterizada por um fluxo e precise de maior garantias, por exemplo, entrega com menor atraso
dos seus pacotes. Nesse sentido foi desenvolvida a técnica Flowlet Based, que permite revezar
o caminho de um determinado fluxo pelos vários caminhos disponíveis para minimizar o atraso
de um fluxo ou o congestionamento de um caminho. O revezamento dos fluxo é possibilitado a
partir do monitoramento ativo dos caminhos e do tempo de entrega dos pacotes. Ainda é possí-
vel ter problemas com as ferramentas de depuração de rede, caso a granularidade dos fluxos seja
muito alta. Na Figura 5.2(c) é mostrado um exemplo de roteamento multicaminhos utilizando
a técnica de split Flowlet Based, o fluxo de pacotes na cor verde é atribuído novamente a um
outro caminho sem que haja perda da continuidade do fluxo e desordenação dos pacotes.
As técnicas baseadas em fluxo geralmente desconsideram as aplicações que estão utilizando
o roteamento multicaminhos, permitindo assim, que alguns benefícios oriundos da técnica não
sejam aproveitados. Um exemplo de característica do multicaminhos, que poderia ser aprovei-
tada é a entrega distribuída, que permite que pacotes de um determinado serviço tenha garantia
de entrega da informação mesmo com falha de um dos caminhos.
Para aplicações multimídias não tolerantes a atraso, a perda de pacotes pode ser totalmente
prejudicial e para contornar esse problema, originado por congestionamentos ou falhas de en-
laces, pode-se utilizar a duplicação de fluxos, que atualmente, possui diversos estudos sendo
desenvolvidos para tratar da sua utilização nos mais variados tipos de aplicações. Um desses
estudos é abrigado no grupo de trabalho avtext7 do IETF. Ali e Perkins (2013), por exemplo,
propõe um padrão que descreve um processo para duplicação de streaming RTP, focado em
garantir maior confiabilidade na entrega de áudio e vídeo, evitando que este tipo de tráfego seja
afetado por problemas de perda de pacotes e congestionamento de enlaces. Em conjunto com
esse trabalho de Ali e Perkins (2013), surge também algumas outras propostas para tratar a es-
pecificação da sessão multimídia (ALI; YUN; HEIDI, ) e sessão de controle do próprio RTCP
(ALI; YUN; HEIDI, ). É possível aplicar a duplicação de fluxo de pelo menos duas formas,
a primeira mostrada na Figura 5.3(a), é através da duplicação na origem, o nó onde origina-se
o tráfego possui um componente split, que cria para cada pacote do fluxo de dados um outro
7 É uma abreviação para Audio/Video Transport Extensions , referindo-se a um grupo de trabalho do IETF quevisa padronizar extensões para melhorar os protocolos de transporte de mídias.
48
pacote com o mesmo conteúdo, porém contendo informações de cabeçalho distintas, como por
exemplo, o número da porta UDP ou TCP de destino diferente. Isto porque, quando os pacotes
chegarem ao roteador, que é o gateway do cliente, eles deverão possuir uma copia encaminhada
por um outro caminho. Essa abordagem nem sempre garante uma independência dos roteadores,
pois é necessário o conhecimento do relacionamento do fluxo duplicado com o fluxo original,
para poder encaminhá-lo por um caminho distinto, muitas vezes será necessário um mecanismo
de rastreamento, similar ao existente em firewall com suporte a NAT8. Outra maneira do ro-
teador identificar o fluxo duplicado e encaminhá-lo por um caminho distinto é ofertando um
serviço de encaminhamento ao cliente, esse por sua vez, deverá conhecer o formato que rela-
ciona um fluxo duplicado ao original na linguagem do roteador. A segunda maneira de fazer a
duplicação do tráfego, mostrada na 5.3(b), é fazendo a duplicação do fluxo no roteador. Nesse
formato, o roteador deve identificar que o tráfego necessita desse tipo de serviço e então esta-
belecer uma regra no componente de split interno para duplicar o fluxo e encaminhá-lo por um
caminho distinto. Utilizando esse método não é necessário nenhuma modificação no cliente, o
que possibilita um serviço homogêneo e independente da plataforma do cliente. Só será neces-
sário uma inteligência no roteador para reconhecer o tráfego e encaminhá-lo ao módulo de split
com as devidas informações.
8 NAT , do inglês Network Address Translation, é uma técnica que permite reescrever os cabeçalhos de umpacote IP oriundo de uma rede interna para torná-lo roteavél na Internet. Uma discussão mais elaborada e apro-fundada sobre o tema pode ser encontrada em Kurose e Ross (2009).
49
Figura 5.3: Tipo de duplicação fluxo
No roteamento multicaminhos é possível objetivar, a depender é claro da técnica utilizada,
a separação total entre os nós que estão no meio do caminho. Para fazer isso, é necessário es-
colher caminhos disjuntos, onde não há enlaces em comum e também, de preferência, nós em
comum. No estudo feito por Lee e Gerla (2001) é proposto um esquema de roteamento mul-
ticaminhos para redes ad-hoc, que estabelece e usa várias rotas com caminhos maximamente
disjuntos. Embora o foco do estudo fosse minimizar o processo de recuperação de rotas e so-
brecarga das mensagens de controle, foi utilizado no esquema a alocação baseada em pacotes
para distribui-los nos vários caminhos encontrados. Lee e Gerla (2001) notaram que a aborda-
gem propiciou utilizar de forma eficiente os recursos disponíveis na rede e evitar que os nós no
caminho ficassem sobrecarregados com o tráfego.
Devido às suas vantagens, o roteamento multipath tem sido empregado em redes sensores
sem fios, redes ad-hoc, redes Mesh e diversos outros tipos de redes sem fio. Existem muitas
pesquisas e trabalhos, sendo publicados, que exploram esse tipo de roteamento, como é o caso
Zhang et al. (2011), Le (2011), Zhang et al. (2010), Cetinkaya e Knightly (2004).
50
6 ROTEAMENTOMULTICAMINHOS EM REDESMESH
Existem diversas formas de priorização de tráfego em redes, embora muitas delas não se-
jam indicadas para aplicações com restrições temporais, como é o caso do VoIP. Objetivando
montar um esquema para priorização de tráfego VoIP em redes Mesh sem fio, montou-se para
elaboração deste trabalho uma solução utilizando como base o roteamento multicaminhos em
conjunto com técnicas de split de tráfego.
Para avaliar o roteamento multicaminhos em uma WMN, poder-se-ia seguir por três cami-
nhos distintos. Fazendo uma modelagem analítica1, técnica que poderia não dar resultados que
expressassem o beneficio ou malefício da técnica de roteamento, pois muitas variáveis seriam
necessárias para mapear o comportamento de uma rede real sob as condições de multicaminhos.
Uma outra forma seria através da simulação do sistema2, para isto seria necessário implementar
o ambiente de uma rede sem fio, posteriormente o comportamento de uma WMN e por último
a própria estratégia de roteamento multicaminhos e split do tráfego. Essa técnica poderia ser
muito custosa para representar uma rede Mesh e também acarretaria em simplificações do mo-
delo, o que foge um pouco da proposta deste trabalho. Por último, abordaremos a técnica de
medição, que é a mais importante para este trabalho. Esta por sua vez, necessita de um ambiente
funcional ou ao menos um protótipo, que represente o sistema a ser avaliado. Essa técnica tem
alguns prós importantes, a similaridade do objeto avaliado com o ambiente real, que torna os
resultados mais próximos do estado dos equipamentos e da rede estudada e a possibilidade de
replicar o estudo em um ambiente real sem necessitar de muitas modificações no modelo.
1 A modelagem analítica é uma técnica computacional para representar a abstração de um sistema, com o fimde avaliar o comportamento do sistema a determinadas condições.
2 A Simulação é uma técnica que visa modelar certas características de um ambiente real, para que seja pos-sível uma avaliação, sendo que é uma técnica que aproxima ao máximo as partes estudadas de um sistema ao seucomportamento real.
51
6.1 AMBIENTE DE EMULAÇÃO
Para testar e medir o esquema de roteamento multicaminhos foi implementado uma rede
Mesh em um ambiente emulado, a ferramenta utilizada para isto foi CORE (AHRENHOLZ,
2010).
O CORE é um emulador de rede em tempo real, que permite a instanciação de topologias
virtuais com os mais variados equipamentos. Ele possibilita emular, desde equipamentos que
operam na camada de enlace, incluindo nestes as propriedades de funcionamento no nível da
camada de física, até dispositivos que funcionam na camada de rede. Como o cenário mon-
tado foi emulado no sistema operacional GNU/Linux, a versão utilizada do CORE foi a que é
destinada a esta plataforma3. Nessa implementação o esquema de emulação para os enlaces
e dispositivos de redes utiliza espaço de nomes do núcleo do sistema operacional e da pilha
de rede. Cada nó de rede no CORE, quando instanciado, possui os seus próprios processos e
variáveis de ambiente, formando assim, um ambiente totalmente isolado entre os nós de rede.
Isto permite, que serviços idênticos ou completamente distintos sejam executados em cada um
dos nós da topologia, sem que haja interferência nos serviços dos outros nós. De modo geral,
os nós do CORE são máquinas virtuais bem leves, executadas no núcleo do sistema operacional
GNU/Linux. O CORE utiliza o espaço de nomes de rede do Linux para criar os nós; para emular
as ligações entre os nós é usada as bridges de rede do Linux.
O espaço de nomes de rede do Linux, conhecido com netns, ou LXC , do inglês Linux Con-
tainers , é a técnica de virtualização primária usada pelo CORE e é implementada dentro do
kernel do Linux. Um espaço de nomes é criado usando uma chamada de sistema de clonagem,
que funciona de forma semelhante a jaulas de ambientes de execução. Cada espaço de nomes
tem seu próprio ambiente de processo e pilha rede, porém, os espaços de nomes compartilham
o mesmo sistema de arquivos que o resto do sistema. O CORE combina os espaços de nomes
as bridges de rede do Linux para formar as redes. As características dos enlaces são aplicadas
com o uso das chamadas disciplinas de filas do Linux (netem), que fornecem a funcionalidade
de emulação de rede, permitindo testar protocolos ao emular as propriedades de redes como
variação de atraso, perda, duplicação e reordenação. A parte de contenção dos pacotes transmi-
tidos e a limitação de quais interfaces de rede finais eles irão alcançar é feita com o componente
ebtables4 do Linux. De forma prática, o ebtables permite controlar quais interfaces podem en-
viar e receber quadros em uma bridge, possibilitando que, durante a emulação de uma rede sem
3 Foi usada a versão 4.5 do CORE para GNU/Linux, compilada para processadores 64 bits.4 ebtables é uma ferramenta de filtragem de tráfego, que funciona de forma transparente. É possível com o
ebtables filtrar e controlar o tráfego através de uma bridge do Linux com as informações do nível da camada deenlace.
52
fio, seja implementado um mecanismo de alcançabilidade e controle de acesso ao meio entre
os nós da rede e criando assim um ambiente próximo do meio de transmissão sem fio, que é
intrinsecamente um meio compartilhado.
GUI linha de comando
daemon do CORE
módulos Python
scripts(python)
virtualizaçãono nível do
kernel
bridge&
Manipulação de pacotes
Nós Redes
Figura 6.1: Arquitetura do CORE
Na Figura 6.1 é mostrada a arquitetura do CORE, os componentes na parte superior da ima-
gem representam a interface gráfica (GUI) e a linha de comando. A partir desses componentes é
possível realizar uma comunicação de forma assíncrona com o núcleo do CORE, que é um da-
emon executando em plano de fundo no sistema operacional. A comunicação é feita através de
mensagens no formato da API do CORE. Para cada sessão de emulação iniciada pelos usuários
do sistema, o daemon do CORE cria as topologias configuradas utilizando os módulos internos,
que implementam de fato no sistema operacional as funcionalidade de enlace, equipamento de
rede, etc. Também é possível instanciar uma sessão de emulação usando diretamente os módu-
los internos do CORE. Para isto são usados scripts na linguagem de programação Python5, que
permitem uma maior customização dos componentes de rede usados e facilita a automatização
da emulação.
Por fim, é mostrado na parte inferior da Figura 6.1, separada por uma linha pontilhada, as
interfaces de rede e os hosts virtualizados no núcleo do Linux são gerenciados pelos próprios
módulos internos do CORE. Quando executa-se uma emulação no CORE, os passos seguidos
são os mesmos mostrados na Figura 6.2.
5 Uma linguagem de programação de alto nível do tipo interpretada. Informações mais detalhadas sobre seufuncionamento pode ser encontrada no site oficial <http://www.python.org/>.
53
enlaces, nós,interfaces de
rede definidaspelo usuário
Definição
configuraçãodos scripts deinicialização,daemons, eparâmetrosde enlace
Configuração
criação dos nósvirtuais, dasinterfaces e
redes configuração
dos componentesexternos
Instanciação
scripts de tráfegoe mobilidade,
registro deeventos, console
de interação
Execução
coleta de dadosda execução
e finalização doambiente
de emulação
Coleta de dados
Figura 6.2: Fluxo de execução do CORE
De um modo muito simples foi possível no CORE instanciar roteadores sem fio e controlar
a conectividade entre eles. O emulador permitiu, inclusive, manipular a banda, a taxa de perda
e o atraso do enlace sem fio pelo qual era estabelecido a comunicação entre os nós.
Outros recursos do CORE são os módulos de serviços, que permitiram instanciar dentro
dos roteadores sem fio emulados um switch OpenFlow, além disso, também tornou-se possível
adicionar o componente de split de tráfego. Esses componentes serão apresentados e discutidos
nas seções seguintes.
6.2 FRAMEWORK PARA O PLANO DE CONTROLE E DEENCAMINHAMENTO
Para implementar a técnica de roteamento multicaminhos no plano de controle de uma rede
Mesh sem fio sob OpenFlow, é necessário controlar os eventos mais básicos da rede, desde a
conexão iniciar entre os nós e o controlador, até o envio de informações sobre o estado da rede
para que o controlador possa tomar decisões de roteamento. Esses desafios são ainda maiores
quando é utilizada pelos switch OpenFlow uma comunicação in-band6 com o controlador. Esse
tipo de comunicação, embora mais difícil de ser implementada, é a que mais se aproxima dos
cenários de rede reais. Onde, muitas das vezes, como é o caso das redes sem fio, só existe um
rádio transmissor para estabelecer a comunicação com os outros equipamentos da rede, pois ter
um segundo rádio ou uma rede de infraestrutura cabeada para o gerenciamento é inviável.
Com o fim de prover um framework baseado em Software-Defined Networking para enge-
nharia de tráfego em redes Mesh sem fios, foi produzido pelos membros do grupo de pesquisa
em redes de computadores SPACES, que é sediado no próprio departamento de ciência da com-
putação da UFBA (DCC/UFBA), uma série de ferramentas que permitem tanto instanciar um
6 É uma forma de estabelecer a comunicação de gerencia, utilizando a própria estrutura de rede primária aoinvés de uma estrutura alternativa só para comunicação de gerencia.
54
ambiente emulado de rede, como também a própria estrutura de suporte ao gerenciamento cen-
tralizado do paradigma Software-Defined Networking. O framework foi concebido pensando na
comunicação in-band com o controlador OpenFlow, dessa forma o comportamento de alguns
componentes externos foram customizados para permitir essa forma de transmissão.
N1
N2
N3
N4
switchopenflow
graphclient
eth0 ofsw0switch
openflowgraphclient Controlador
eth0 ofsw0
spaces
Roteador Mesh controlador Roteador Mesh simples
Figura 6.3: Funcionamento do framework do grupo SPACES
Na figura 6.3 é mostrado um cenário usando o framework, com dois tipos de elementos na
rede. Os nós Mesh simples, que possuem apenas os componentes do plano de encaminhamento,
e o nó Mesh controlador, que manipula a tabela de encaminhamento de todos os nós da rede com
o intuito de estabelecer as lógicas especificadas no plano de controle. O roteador Mesh simples
possui um switch OpenFlow, junto a um componente de descoberta de topologia e estatísticas
da interface de rede, que é chamado de graphclient. O switch OpenFlow controla a interface
de rede que dá acesso ao meio de transmissão compartilhado, no exemplo mostrado são as
interfaces eth0. Já a interface ofsw0 é uma bridge onde todas as outras interfaces controladas
pelo switch OpenFlow são adicionadas. O papel de roteador Mesh controlador é atribuído a
apenas um dos nós da rede, que na Figura 6.3 é desempenhado pelo nó N1. Este nó trabalha
com mais outros dois módulos, o controlador propriamente dito e aplicação executada por ele,
que no caso do framework é o módulo spaces.
A módulo spaces do framework foi feito para o controlador OpenFlow POX (NOXREPO.ORG,
2013), que é escrito em Python, permitindo que modificações sejam realizadas mais facilmente
sem a necessidade de compilação de código. O spaces possui vários componentes, cada um res-
ponsável pela manutenção de uma funcionalidade para a rede. Um dos componentes mantêm
um dígrafo que representa o estado da topologia, esse dígrafo é alimentado por informações
55
oriundas do graphclient e de eventos detectados pelo controlador. Existe um componente para
tratar os fluxos de redes desconhecidos, que ainda não possuem regras de encaminhamento no
switch OpenFlow, permitindo estabelecer as regras de roteamento para um determinado tipo de
tráfego. Este componente é ativado a partir de mensagens de Packet-In enviadas ao controlador.
Um outro componente realiza a checagem de conectividade e instalação de um caminho na rede
para atender a um novo fluxo identificado pelo componente de tratamento de fluxos. Porém,
para instalar o caminho é acionado um outro componente para encontrá-lo, que usa as informa-
ções armazenados no dígrafo para montar o caminho de encaminhamento de um fluxo. É usado
como critério para escolha do caminho qualquer atributo contido no dígrafo, que pode variar a
depender das informações enviadas pelo graphclient. Exemplos de atributos são a velocidade
do enlace, taxa de perda de pacote, banda disponível, entre outras. Existem outro componentes
no módulo spaces, porém não serão discutidos nesse trabalho por não serem fundamentais para
o funcionamento do framework.
Com todos esses componentes do framework, é possível montar uma rede Mesh sem fio
com sinalização de controle in-band. Contendo informações sobre a topologia em um elemento
central, permitindo assim, que diversos serviços para essa rede sejam implementados com a
elaboração de novos componentes no módulospaces.
6.3 CENÁRIO INICIAL
O emulador mostrado na seção 6.1 e o framework descrito na seção 6.2, juntos proporci-
onam a capacidade de instanciar uma rede Mesh sem fio com suporte a OpenFlow. Porém,
alguns outros detalhes são necessário, o switch OpenFlow é um deles, que no caso desse traba-
lho foi utilizado Open vSwitch (OVS ) (OPENVSWITCH.ORG, 2013). O Open vSwitch é um
switch virtual multicamadas de propósito geral e código aberto, que implementa, na sua versão
estável, a especificação 1.0 do OpenFlow. O Open vSwitch possui diversos utilitários de linha
de comando para controlar as regras de fluxos no switch, controlar e depurar a conexão com
o controlador OpenFlow, entre outras funcionalidades. Para serem acoplados aos roteadores
Mesh emulados no CORE e conseguirem comunicação com o controlador de forma in-band,
o OVS precisa de regras OpenFlow customizadas, previamente instaladas, que permitam o es-
tabelecimento da conexão segura entre o nó e o controlador. Estas regras iniciais e algumas
modificações na configuração do OVS para compatibilização com o ambiente de emulação com
o CORE, foram feitas e mescladas em um único módulo de serviço para o CORE pelos mem-
bros do grupo SPACES.
56
Com esta combinação de ferramentas foi montado um cenário básico, onde os nós Mesh
com um switch OpenFlow habilitado são emulados no CORE, a comunicação inicial é esta-
belecida entre os nós da rede e o controlador POX rodando o framework do SPACES. Todo o
tratamento de fluxos desconhecidos na rede é feito pelo controlador, que ao receber um Packet-
In estabelece uma regra de encaminhamento entre os roteadores Mesh. As informações da
topologia oriundas da interface de rede dos nós Mesh não puderam ser obtidas usando o mó-
dulo graphclient do framework, pois o ambiente emulado pelo CORE não implementa todas as
funcionalidade de uma interface de rede sem fio real. Isto não tornou-se um problema para a
implementação do componente de roteamento multicaminhos, pois como será mostrado mais a
frente, foi montada uma topologia fixa para elaboração da implementação e dos testes.
6.4 PLANO DE CONTROLE PARA ROTEAMENTO MUL-TICAMINHOS
O roteamento multicaminhos para um rede com OpenFlow pode ser baseado em fluxos, já
que o próprio paradigma suporta esse tipo de diferenciação de tráfego. Porém, nas versões atuais
da especificação do OpenFlow implementadas na maioria dos switches não permite aplicar
técnicas de split para um mesmo tráfego. Isto porque, o próprio fluxo é a unidade mais básica
de agregação usada pelo switch OpenFlow. Então supondo, por exemplo, uma chamada VoIP
sendo iniciada a partir de um dos nós da rede, é necessário estabelecer o caminho para aquele
fluxo da origem ao destino, mas se as regras de encaminhamento do fluxo for feita com a
estratégia de roteamento multicaminhos ativo, mais de um caminho deverá ser colocado em
produção. Pela existência de mais de um caminho para o switch OpenFlow de origem variar
o encaminhamento de um mesmo fluxo, por exemplo variando o próximo roteador Mesh de
destino para efetivar a política de roteamento, é necessário uma estratégia que atribua um pacote
ou um conjunto deles a caminhos distintos.
Para solucionar o problema citado acima, foi elaborado um componente de split de tráfego,
que permite aplicar políticas de distribuição de pacotes por um conjunto de portas de saída.
O componente foi nomeado Splitter e foi feito usando o recurso de agregação de enlaces e de
bridge do Linux. Na figura 6.4 é mostrado o funcionamento Splitter, que ao receber um tráfego
na porta de entrada (bond0), formada pela agregação de um número conhecido de interfaces,
utiliza um política de distribuição dos pacotes pertencentes ao em torno dos enlaces conectados
as portas internas ao bond0 (spli1,splin), que nesse caso são bridges. Os pacotes são atribuídos
as portas de saída conforme a política utilizada na agregação das portas. Por padrão no Linux
é usada a política de Round-Robin entre as portas de saída, mas para realizar a técnica de
57
duplicação de fluxo citada no capítulo 5, o componente de split deve ser capaz de realizar a
atribuição de um mesmo pacote por todas as portas de saída do componente Splitter. Este
comportamento é possível na agregação de enlaces do Linux ao utilizar a política de Broadcast
(B.C.).
Componentesplitter
splo1 splon
bond0
spli1 splin
Bridges
Faz split do tráfegoconforme a políticausada na agregaçãode enlaces
Tráfegode
entrada
Tráfegode saída
distribuído pelas
interfaces
......
Figura 6.4: Funcionamento do componente Splitter
O escalonamento do tráfego nas interfaces de saída feito pelo Splitter pode ser ampliado,
podendo variar para inúmeras políticas, desde que esteja implementada no Linux7. Para este
trabalho, apenas as políticas de R.R. e B.C. foram usadas.
O componente Splitter é necessário em cada um dos roteadores Mesh da rede, para que o
tráfego, não importando o roteador de origem, possa ser escalonado conforme as políticas de
splitting. Com este fim, foi desenvolvido um serviço de instanciação do componente Splitter
para o CORE, o qual encontra-se juntamente aos scripts de inicialização no Apêndice A.
Ao final da adição desse novo componente ao cenário descrito na seção 6.3, os roteadores
Mesh emulados no CORE ficaram com os elementos evidenciados na Figura 6.5.
7 É possível encontrar todas as políticas disponíveis na documentação do módulo bonding do Linux
58
switchopenflow
graphclient
eth0
Componentesplitter
splo1 splo2ofsw0
bond0
spli1 spli2
Nó virtual
Nó Mesh
Controlador*Módulos de serviços
Associação do switch com as interfaces de rede virtuais
*Componente adicional
Figura 6.5: Elementos de um nó Mesh no CORE
De posse de roteadores plenamente capazes de realizar split de tráfego para um fluxo Open-
Flow estabelecido, foi necessário adicionar um componente de roteamento multicaminhos ao
framework do SPACES. Com este fim, uma função para calcular os caminhos possíveis a partir
da informação da rede armazenada no dígrafo foi desenvolvida, a lógica da função encontra-se
no pseudo algoritmo mostrado no Código 1. A função recebe como entrada o número de cami-
nhos a serem encontrados (n), o atributo das arestas do dígrafo que será levado em consideração
na busca do menor caminho (attr), o nó de origem e destino do tráfego (src e dst) e o dígrafo
da rede, computa o menor caminho8 e armazena-o em uma estrutura apropriada e remove ele
do dígrafo, e computa o próximo caminhos possível a partir do dígrafo derivado. Esse processo
é executado até que os caminhos existentes esgotem-se ou o número de caminhos necessários
sejam encontrados. Esta abordagem, embora tenha o objetivo parecido com Lee e Gerla (2001),
visa não sobrepor caminhos distintos devido a uma aresta em comum. Após o calculo de todos
os n caminhos possíveis, a função os retorna em imediato.
8 O dígrafo de rede foi elaborado utilizando a biblioteca NetworkX <http://networkx.github.io/>, que forneceuma função para calculo de menor caminhos com base em um atributo nas arestas do dígrafo.
59
1 Function multipath(n, src, dst, graph, attr):
2 for npath in n:
3 paths[npath] = shortest_path(src, dst, graph, attr)
4
5 if not paths[npath]:
6 return False
7
8 remove_path(paths[npath], graph)
9
10 return paths
Código 1: Função de descoberta dos multicaminhos
Caso existam caminhos, deverão ser instaladas regras de encaminhamento nos roteadores
pertencentes aos caminhos. Desse modo, todos os caminhos são percorridos pelo controlador
para inserir regras nos roteadores Mesh. No bloco Código 2 é evidenciada a lógica de instalação
de regras usadas no plano de controle para que o encaminhamento seja configurado. A função
recebe como entrada o número de multicaminhos a serem tratados (n), o atributo que será usado
na função de menor caminho (att), que para os experimentos realizado foi o peso constante
da velocidade do enlace, outro parâmetro da função foi as informações extraídas do pacote
(flow_match_fields), que iniciou o processo de instalação de novo fluxo no plano de controle, e
por último o as informações de configuração do módulo Splitter (splitter). Todos os switches de
todos os caminhos encontrados são percorridos para instalação das regras de encaminhamento,
as informações usadas para o encaminhamento baseiam-se na porta de entrada (in_port) e no
endereço de camada de enlace do switch anterior (previous(sw)), isto para evitar que um outro
pacote pertencente ao mesmo fluxo e que tenha outros nós como destino não sejam tratados
pelos switches pertencentes a caminhos distintos. Também são adicionadas ações switch Open-
Flow para que os pacotes ao serem encaminhados tenham o endereço de origem e destino na
camada de enlace modificados (set_datalink_src e set_datalink_dst), essa abordagem também
permite a diferenciação entre os pacotes do mesmo streaming, mas que pertencem a caminhos
distintos, solucionando assim o problema oriundo do meio de transmissão compartilhado. Ao
final da instalação das regras nos switch OpenFlow, o roteador Mesh onde originou-se o trá-
fego é configurado para redirecionar o fluxo para o componente Splitter e então liberar para o
encaminhamento o pacote inicial na fila de retenção (buffer local no switch OpenFlow).
60
1 Function install_multipath(n = 2, attr = weight, flow_match_fields, splitter):
2 paths = multipath(n, src, dst, graph, attr)
3
4 if not paths:
5 return False
6
7 for path in paths:
8 for sw in path:
9 new_src = sw
10
11 if sw == last(path):
12 new_dst = sw
13 else:
14 new_dst = next(sw)
15
16 if sw == first(path):
17 in_port = splitter_out_port
18 flow_match_fields['in_port'] = in_port
19 else:
20 in_port = port(sw, previous(sw))
21
22 out_port = next(sw)
23
24 actions = [['set_datalink_src', new_src], ['set_datalink_dst', new_dst]]
25
26 install_flow_entry(sw, match_fields, actions)
27
28 src_actions['out_port'] = splitter_bond_port
29 src_match_fields['in_port'] = in_port
30 install_flow_entry(first(path), src_match_fields, src_actions, priority -= 1)
31
32 send_packet_out(src)
Código 2: Lógica do algoritmo de roteamento multicaminhos
O pseudo código acima é executado apenas quando um fluxo desconhecido é identificado
no roteador de origem do tráfego. Mas para o fim desse projeto, apenas os fluxos que foram
discriminados pelo controlador como um streaming RTP foram configurados para usar a função
de estabelecimento de multicaminhos. As informações usadas para distinguir esse tráfego dos
outros, foram a porta de destino e o protocolo de camada de transporte.
As regras de encaminhamento instaladas nos roteadores Mesh seguem a mesma lógica do
encaminhamento dos outros tráfegos, com exceção da regra usada no roteador de origem do
tráfego, que necessita redirecionar o tráfego para o componente de split para então encami-
nhar aos próximos nós. A Figura 6.6 mostra a tabela de fluxos de um nó de origem de um
streaming, existem regras mais prioritárias para encaminhar o tráfego aos próximos nós do ca-
minhos, quando o tráfego for oriundo da interface de saída do componente split e regras menos
61
prioritárias para encaminhar o fluxo recebido no nó para a interface de entrada do do compo-
nente de split (bond0).
Fluxo voip x e porta de entrada spli1 Contadores Encaminhar ao nó n2
switchopenflow
graphclient Controlador
eth0 ofsw0
spaces
Estrutura interna do nó
Fluxo voip x e porta de entrada splin Contadores Encaminhar ao nó n3
Fluxo voip x e porta de entrada y Contadores Encaminhar pela porta bond0
N1
N2
N3
N4
Componentesplitter
splo1 splon
bond0
spli1 splin...
...
... ... ...
Roteador Mesh de origem
Regras OpenFlow para o fluxo multicaminhos
Roteador Mesh de destino
Figura 6.6: Regras OpenFlow em um nó de origem do streaming
6.5 CENÁRIO DE EXPERIMENTAÇÃO
Usando a implementação de roteamento multicaminhos descrita na seção 6.4 com as po-
líticas de split de tráfego R.R. e B.C., é possível montar dois tipos de serviços de roteamento
distintos. O primeiro usando a política R.R., permite distribuir a carga de tráfego pelos multica-
minhos para que um streaming não sobrecarregue um único caminho, ou não sofra tanto com
sobrecargas momentâneas em uma única rota pelas transmissões de caminho único. Já a política
B.C. permite maior resiliência ao streaming, permitindo que mesmo em cenários com perdas
altas, um mesmo pacote pertencente a um fluxo possa ser escoado ao destino por ao menos um
caminho.
Para analisar o comportamento dessa duas políticas de split, foi montado uma topologia de
sete nós arranjados da maneira mostrada na Figura 6.7. Cada nó foi configurado no CORE como
um roteador Mesh sem fio com suporte a OpenFlow, utilizando a estrutura discutida nas seções
6.4 e 6.2. Os enlaces foram configurados com uma velocidade de 54 Mbps, similar as taxas de
transmissão mais populares das emendas derivadas do IEEE 802.11, que foram mostradas na
Tabela 3.1. Além disso, o atraso utilizado para os enlaces foi de 20ms.
62
N1
N2
N3
N4
N5
N6
N7
OrigemDestino
Roteador Nó controlador Direção do tráfego Enlace sem fio
Figura 6.7: Topologia usada nos experimentos
Para alimentar o dígrafo da aplicação SPACES no controlador com as informações de vi-
zinhança, que fornece as informações ao módulo de multicaminhos, foi feita uma versão sim-
plificada do graphclient, chamada graphclientlight, que apenas envia informações predefinidas
sobre a topologia. Isto porque, como dito na seção 6.3, o ambiente emulado não possui todas
as funcionalidades de um dispositivo de rede real reproduzidas. Porém, como a topologia usada
era estática e as informações de enlace foram definidas, isto não tornou-se um problema. O
módulo graphclientlight foi iniciado junto aos outros serviços usados no CORE e persistiu em
execução durante todo o período de experimentação.
Ao final, o cenário foi instanciado de duas formas não concorrentes, uma usando a polí-
tica R.R. e outra usando a política B.C.. E para cada um dos cenários foram executados os
experimentos descritos nas seções 6.6 e 6.7
6.6 ANÁLISE DAS TÉCNICAS DE SPLIT DE TRÁFEGO
Para cada instanciação da topologia descrita na seção 6.5 foram feitos testes de tráfego
UDP com destino a porta de um streaming RTP a partir do nó N1 e com destino ao nó N7. A
ferramenta utilizada para gerar o streaming foi iperf (TIRUMALA et al., 2006), porém devido
a forma como é implementado no iperf o calculo da variação do atraso (jitter) dos datagramas
UDP, não é levada totalmente em consideração a lógica existente nos streaming RTP, que por
padrão não utilizam pacotes duplicados ou fora de ordem na composição do streaming. Assim,
63
para modificar o comportamento do iperf , para que os datagramas UDP fosse tratados de forma
similar aos pacotes RTP no calculo do jitter, possibilitando uma maior eficácia na analise das
políticas de split, foi gerado o patch9 de atualização (vide anexo no Apêndice B).
Para simular o streaming RTP, foi executo no nó N1 o iperf no modo cliente e no nó N7
no modo servidor. A cadencia de envio do streaming baseou-se nas informações da taxa de
transmissão do codec G.711 na Tabela 2.2, que leva em consideração o tamanho dos cabeçalhos
dos protocolos RTP e UDP, possibilitando assim, definir uma taxa de transmissão de dados
similar a usada tipicamente em uma chamada VoIP.
O relatório técnico feito por (GUHA; DASWANI, 2005) mostra um valor média par a liga-
ções VoIP com Skype em torno de 4 minutos. Enquanto que o estudo feito por (BIRKE et al.,
2010) revelou chamadas em torno de 106 segundos. Porém, nesse trabalho foi considerado que
um streaming dura um valor intermediário de 200 segundos, e sendo assim, o iperf foi confi-
gurado para gerar o streaming de forma direcional - em apenas um sentido da comunicação -
durante esse intervalo de tempo.
Foram feitas 10 execuções do teste para cada instância do cenário, cada uma replicada 5
vezes. Os resultados dos testes foram compilados na Tabela C.1 localizada no Apêndice C.
A partir dos resultados gerou-se a Figura 6.8, que mostra de forma estimativa o impacto de
utilizar as políticas de split de tráfego para realizar o roteamento multicaminhos, levando em
consideração os quesitos perda de pacotes, largura de banda, variação do atraso (jitter) e pacotes
entregues fora de ordem.
Figura 6.8: Comportamento das políticas de splitting
A partir da figura 6.8 é possível observar, que mesmo usando o dobro de banda para espalhar
o tráfego pela rede Mesh, a política B.C. não prove um menor jitter. Outro detalhe do experi-
9 É um termo em inglês, que refere-se a um arquivo contendo a atualização ou correção de parte do código deum programa computacional.
64
mento, é que não houve perda de pacotes para ambas as políticas, mas quase toda a metade dos
pacotes enviados pela política B.C. chegaram, e contabilizaram pacotes fora de ordem. De um
modo geral, observa-se que não muitas vantagens em utilizar a política B.C. neste cenário.
6.7 QUALIDADE DE EXPERIÊNCIA DAS TÉCNICAS DESPLIT
Comparar de forma prática o impacto de uma política de split de tráfego em uma aplica-
ção real pode demandar inúmeros experimentos, que podem variar desde a utilização efetiva de
uma aplicação por usuários reais, até a utilização de metodologias sem interação humana. Nesse
aspecto, o modelo de avaliação padronizado pelo International Telecommunication Union e tor-
nado público pelo nome ITU P862 (ITU-T, 2001), disponibiliza um conjunto de métricas, al-
goritmos e amostras de áudio para serem usadas em testes de QoE. Os algoritmos de avaliação,
na implementação disponibilizada no próprio padrão ITU P862, levam em consideração duas
amostras de um mesmo áudio, uma é considerada a original e representa de forma integra uma
captura de um som usando algum codec, já a segunda uma amostra degrada, que tenha passado
através de um sistema, como por exemplo uma rede de dados, e apresente algum tipo de ruído
ou perda de informação. As duas amostras são comparadas pelos algoritmos, levando em consi-
deração às métricas estabelecidas para analise da qualidade de uma amostra de áudio que tenha
sofrido degradação. Em especial, os algoritmos disponibilizados no padrão ITU P862 foram
desenvolvidos para analise de degradações oriundas de redes de comutação de dados, focando
em áudios de conversações típicas de chamadas de telefonia.
Para poder capturar e analisar as amostras de uma chamadas VoIP, foi montado um es-
quema, similar ao feito por Huntgeburth, Schumann e Londak (2010), para realizar a conversão
do fluxo de áudio na saída do roteador de origem da ligação, antes mesmo da chamada ser
transmitida na rede, e depois na chegada do fluxo no roteador de destino da chamada. O es-
quema feito é exibido na Figura 6.9. No ponto 1 da imagem, são convertidas as amostras de
áudio fornecidas no ITU P862 para os respectivos streaming RTP, usando para esta conversão
a ferramenta wav2rtp10 configurada para gerar o streaming com o codec G.711. O streaming
RTP é então enviado ao nó Mesh de destino na rede, usando o programa sipp11 no nó de origem
10 O wav2rtp é uma ferramenta usada para conversão de arquivos de áudio no formato wav (WAVEform audioformat) em streaming RTP, que permite utilizar os codecs G.711, GSM, etc. A ferramenta está disponível napágina WEB <http://wav2rtp.sourceforge.net/>.
11 sipp é uma ferramenta de teste, que permite gerar tráfego SIP de forma customizada, possibilitando indicarquais e com qual ordem as mensagens do protocolo deverão ser trocadas entre duas entidades SIP. O programa e adocumentação são disponibilizados na página WEB <http://sipp.sourceforge.net/>.
65
(cliente) e destino (servidor) para estabelecer a comunicação sipp. A comunicação montada
com a aplicação sipp segue os passos descritos no diagrama da Figura 2.2. Antes do streaming
seguir pela rede Mesh, é capturada uma copia do tráfego com a ferramenta tcpdump12, então o
streaming segue seu caminho pela rede (ponto 2 da imagem), escalonado pelos multicaminhos
por uma das duas políticas de split. Ao chegar ao destino, no ponto 3, outra amostra do tráfego é
captura por uma instância distinta do tcpdump. Esse processo é repetido com todas as amostras
de áudio, até que por fim - a partir do ponto 4 da figura - todos os dados brutos do streaming
sejam extraídos dos arquivos gerados pelo tcpdump utilizando a ferramenta rtpbreak13, logo em
seguida os dados brutos são convertidos em arquivos de áudio usando o programa sox14.
Roteador de destino
rede
Roteador de origem
1
2
3
4
Arquivos de áudio
Streaming
Interfacede
rede
Ferramentade
dump
conversor
Arquivos de áudio
Streamings
Interfacede
redeconversor
ClienteSIP
ServidorSIP
Figura 6.9: Funcionamento do teste de QoE
Em posse dos pares de amostras do áudio oriundos das chamadas VoIP realizadas, usou-se
a implementação do algoritmo PESQ , denominada pesqmain, que é distribuída junto ao padrão
ITU P862 para estimar a qualidade das amostras de áudio degradadas em relação a o áudio
original, que nesse experimento foram os arquivos de áudio oriundos das capturas no rotea-
dor de destino e no de origem respectivamente. O algoritmo PESQ foi desenvolvido para ser
12 É uma ferramenta para analise e captura de tráfego. A ferramenta e o manual podem ser encontrados napágina WEB oficial <http://www.tcpdump.org/>.
13 rtpbreak é um ferramenta para identificação, analise e reconstrução de sessões RTP. É possível coletar maisinformações sobre a aplicação na página WEB <http://rtpbreak.sourceforge.net/>.
14 sox, ou Sound eXchange, é uma aplicação usada para conversão de áudio. Mais informações podem serencontradas na página <http://sox.sourceforge.net/>.
66
aplicado em comunicações fim-a-fim, justamente em testes de qualidade de voz para condições
de degradação em rede real. A qualificação no PESQ é feita no intervalo de -0,5 (ruim) a 4,5
(excelente). Na sua implementação pela ferramenta pesqmain é fornecida uma conversão da
escala de qualidade do PESQ para uma aproximação do índice de qualidade MOS15 (ITU-T,
1996b) denominada MOS-LQO16 (ITU-T, 2003). A escala de qualidade do MOS vai de 1 a 5
com incrementos uma unidade, a qualificação dos valores é mostrada na Tabela 6.1. Como o
índice MOS-LQO é uma aproximação, ele apenas mapeia o PESQ no intervalo de 1,02 a 4,56
do MOS.
Significado Excelente Bom Razoável Ruim Péssimo
Índice 5 4 3 2 1
Tabela 6.1: Índice de qualidade MOS
Para realizar os testes foram usadas 43 amostras de áudio (contendo falas humanas) do
ITU P862, para cada amostra foi realizada a transmissão de um streaming 10 vezes, com 5
replicações do ciclo. O experimento foi realizado para as duas instâncias das políticas de split.
Os valores dos índices PESQ e MOS-LQO foram calculados utilizando a aplicação pesqmain e
para cada uma das 10 transmissões foi feito uma média, que posteriormente foi comparada com
as replicações e seus respectivos intervalos de confiança, para então serem documentadas nas
Tabelas C.2 (Média entre as replicações) e C.3 (Desvio padrão das médias) do Apêndice C.
Com esse experimento notou-se que para um cenário idealizado, sem perdas ocasionadas
pelo meio de transmissão, as políticas de split usadas no roteamento multicaminhos tem prati-
camente os mesmos índices de QoE. Não havendo diferenças significativas, que venham a com-
provar que o mecanismo de duplicação de fluxo seja realmente efetivo para aplicações VoIP em
redes sem fio.
15 MOS , do inglês Mean opinion score, é um tipo de avaliação subjetiva, feita por humanos, para qualificaruma transmissão de áudio recebida a partir de uma rede.
16 MOS-LQO , do inglês Mean Opinion Score - Listening Quality Objective, é uma aproximação do índiceMOS, que mapeia os resultados entre o PESQ e o MOS de forma linear.
67
7 CONCLUSÃO
Nesse trabalho notou-se as várias abordagens de realizar roteamento multicaminhos em
uma rede Mesh sem fio, levou-se em consideração nos estudos as diferentes formas de split
de tráfego em relação a fluxos de dados de aplicações VoIP, mostrou-se um modelo misto entre
split baseado em pacotes e fluxos planejado para ser utilizado em Software-Defined Networking.
Foi evidenciado um esquema para teste de QoE para aplicações de VoIP, provendo assim, um
mecanismo de avaliação mais eficiente para os pontos positivos de realizar modificações no
plano de controle de uma rede.
7.1 DIFICULDADES ENCONTRADAS
O fato dos switch OpenFlow mais populares não possuírem um método para manipular
os fluxos com maior granularidade, tornou necessário o desenvolvimento do módulo Splitter
exposto na seção 6.4. Outro problema relacionados aos switches OpenFlow e que limitou a
realização dos testes com maior mais variações de parâmetros de entrada, foi os poucos modos
de operação dos switches na ausência de controladores. No Open vSwitch por exemplo, existem
apenas dois modos de operação o seguro, que faz o switch parar de encaminhar todos fluxo
que estavam configurados, e o modo de operação padrão, que o torna o switch OpenFlow um
switch comum. Esse problema impactou diretamente nos experimentos, pois tornou a rede Mesh
instável na existência de uma grade quantidade de tráfego concorrente e quando havia perda de
pacotes na camada de enlace (configurada propositalmente no ambiente de emulação).
As limitações do ambiente de emulação em relação a algumas funcionalidades dos dis-
positivos de rede, dificultou a utilização de métricas de roteamento que fossem baseadas nas
informações da interface de rede. O CORE, não permite, na versão mais atual, emular de ma-
neira realística a interface de rede sem fio, não permitindo utilizar recursos de checagem de
vizinhança, nível de sinal, entre outras.
68
7.2 TRABALHOS FUTUROS
Os experimentos propostos servirão como base para os próximos estudos, pois revelam as
técnicas mais atuais para realização de experimentos de QoE para aplicações VoIP em redes de
comutação de pacotes. No futuro, será possível melhorar a analise de desempenho das políticas
de split de tráfego, podendo-se seguir por dois caminhos distintos, um modificando o Open
vSwitch para continuar tratando os fluxos previamente instalados, mesmo quando a conexão
com o controlador for perdida, mantendo o comportamento até que a sessão seja restabelecida
com o controlador. Outra abordagem, alternativa, é modificar o framework do grupo SPACES
para funcionar no modo out-of-band. Essa ultima abordagem permitiria que mesmo com o meio
de transmissão no backbone Mesh estivesse sobrecarregado, as conexões de controle seriam
mantidas entre os nós da rede e o controlador.
Outra melhoria ao trabalho, seria a implementação de políticas de split baseadas nas in-
formações oriundas do plano de controle, permitindo por exemplo, redistribuição do tráfego
ao longo dos caminhos com base em critérios de largura de banda, taxa de perda, ou mesmo
variação do atraso, tornado o split um pouco mais parecido com a estratégia Flowlet Based.
Com as novas versões da especificação do OpenFlow é possível aplicar mais de uma ação
a um mesmo pacote pertencente a um fluxo, isso pode possibilitar a duplicação de fluxo ou
distribuição de pacotes ao longo dos múltiplos caminhos. Assim, pode ser possível a migração
do componente Splitter para a lógica do próprio switch OpenFlow.
69
APÊNDICE A -- SERVIÇO DE TRAFFICSPLITTING PARA O CORE
A.1 MÓDULO SPLITTER
1 ''' OpenVSwitch splitter service.
2 '''
3
4 import os
5
6 from core.service import CoreService, addservice
7 from core.misc.ipaddr import IPv4Prefix, IPv6Prefix
8
9 class Splitter(CoreService):
10 ''' This is a user-defined service for openflow splitter node
11 '''
12 # a unique name is required, without spaces
13 _name = "Splitter"
14 # you can create your own group here
15 _group = "Utility"
16 # list of other services this service depends on
17 _depends = ("OFNode",)
18 # per-node directories
19 _dirs = ('/var/log',)
20 # configuration file to this service in the node
21 _configs = ('splitter.conf', )
22 # this controls the starting order vs other enabled services
23 _startindex = 60
24 # number of links to split traffic
25 _links = 2
26 # max wait time
27 _waittime = 30
28 # file to wait
29 _filetowait = "ofnode.done"
30 # splitter mode
31 # 0 - round-robin, 3 - broadcast
32 _splmode = 0
33 # splitter input interfaces prefix name
34 _spliprefix = "spli"
35 # splitter output interfaces prefix name
36 _sploprefix = "splo"
70
37 # list of startup commands, also may be generated during startup
38 _startup = (os.path.join(os.path.dirname(os.path.abspath(__file__)), '../bin/start-splitter.sh'),)
39 # list of shutdown commands
40 _shutdown = (os.path.join(os.path.dirname(os.path.abspath(__file__)), '../bin/stop-splitter.sh'),)
41
42 @classmethod
43 def generateconfig(cls, node, filename, services):
44 ''' Return a string that will be written to filename, or sent to
45 the GUI for user customization.
46 '''
47 cfg = "# start-splitter.sh\n\n"
48
49 cfg += 'for time in $(seq 1 %d);do sleep 1; if [ -f %s ];then break;fi;\
50 echo " -> splitter dont find ofnode done file" ;done\n' % (cls._waittime,cls._filetowait)
51 cfg += 'OFBONDPREFIX="%s"\n' % cls._spliprefix
52 cfg += 'OFSPLPREFIX="%s"\n' % cls._sploprefix
53 cfg += 'OFBONDIF=""\n'
54 cfg += 'OFSPLIF=""\n'
55 cfg += 'BONDMODE=%d\n' % cls._splmode
56 cfg += 'BONDLINKS="%s"\n\n' % cls._links
57 return cfg
58
59 # list this file in available services
60 addservice(Splitter)
A.2 SCRIPT DE INICIALIZAÇÃO DO SERVIÇO DE SPLIT-TER
1 #!/bin/bash
2
3 # read default config
4 . ./splitter.conf
5
6 # only continue if we have interfaces to put in BOND
7 [ -n "$OFBONDPREFIX" ] || exit 0
8 [ -n "$OFSPLPREFIX" ] || exit 0
9
10
11 #################################
12 echo "Configuring OpenVSwitch Splitter"
13
14 echo "-> Create interfaces"
15 for count in `seq 1 $BONDLINKS`
16 do
17 OFBONDIF="$OFBONDIF $OFBONDPREFIX$count"
18 OFSPLIF="$OFSPLIF $OFSPLPREFIX$count"
19 ip link add name $OFBONDPREFIX$count type veth peer name $OFSPLPREFIX$count
20 ip link set $OFSPLPREFIX$count up
21 done
22
71
23 echo "-> Charge modules"
24 modprobe bonding
25 modprobe e1000
26
27 echo "-> Create a bond"
28 echo +bond0 > /sys/class/net/bonding_masters
29
30 echo "-> Select bond mode"
31 echo $BONDMODE > /sys/class/net/bond0/bonding/mode
32
33 echo "-> Upping the bond interface"
34 ifconfig bond0 up
35
36 echo "-> Adding interface to bond"
37 for iface in $OFBONDIF
38 do
39 echo " -> Adding $iface"
40 ifconfig $iface down
41 echo +$iface > /sys/class/net/bond0/bonding/slaves
42 done
43
44 echo "-> Adding bond port to openvswitch bridge"
45 ovs-vsctl add-port ofsw0 bond0
46
47 echo "-> Adding ports to openvswitch bridge"
48 for iface in $OFSPLIF
49 do
50 echo " -> Adding $iface"
51 ovs-vsctl add-port ofsw0 $iface
52 done
53
54 IFACES="bond0 $(echo $OFSPLIF | sed '/ $/d')"
55 echo "-> cleanup IP addresses from splitter interfaces ($IFACES)"
56 for iface in $IFACES; do
57 ip addr flush dev $iface
58 ip -6 addr flush dev $iface
59 done
A.3 SCRIPT DE PARADA DO SERVIÇO DE SPLITTER
1 #!/bin/bash
2
3 # read default config
4 . ./splitter.conf
5
6 # only continue if we have interfaces to put in BOND
7 [ -n "$OFBONDIF" ] || exit 0
8 [ -n "$OFSPLIF" ] || exit 0
9
10 #################################
11 echo "Unconfiguring OpenVSwitch Splitter"
72
12
13 echo "-> Charge modules"
14 rmmod bonding
15 rmmod e1000
16
17 echo "-> Removing interface from bond"
18 for iface in $OFBONDIF
19 do
20 echo " -> Removing $iface"
21 echo -$iface > /sys/class/net/bond0/bonding/slaves
22 done
23
24 echo "-> Deleting ports from openvswitch bridge"
25 for iface in $OFSPLIF
26 do
27 echo " -> Deleting $iface"
28 ovs-vsctl del-port ofsw0 $iface
29 done
30
31 echo "-> Deleting bond port from openvswitch bridge"
32 ovs-vsctl del-port ofsw0 bond0
33
34 echo "-> Downing the bond interface"
35 ifconfig bond0 down
36
37 echo "-> Delete bond"
38 echo -bond0 > /sys/class/net/bonding_masters
73
APÊNDICE B -- PATCH APLICADO NO IPERF
1 diff --git a/src/Reporter.c b/src/Reporter.c
2 index 7d9263b..b28ad13 100644
3 --- a/src/Reporter.c
4 +++ b/src/Reporter.c
5 @@ -692,15 +692,17 @@ int reporter_handle_packet( ReportHeader *reporthdr ) {
6
7 // from RFC 1889, Real Time Protocol (RTP)
8 // J = J + ( | D(i-1,i) | - J ) / 16
9 - transit = TimeDifference( packet->packetTime, packet->sentTime );
10 - if ( data->lastTransit != 0.0 ) {
11 - deltaTransit = transit - data->lastTransit;
12 - if ( deltaTransit < 0.0 ) {
13 - deltaTransit = -deltaTransit;
14 + if ( packet->packetID > data->PacketID ) {
15 + transit = TimeDifference( packet->packetTime, packet->sentTime );
16 + if ( data->lastTransit != 0.0 ) {
17 + deltaTransit = transit - data->lastTransit;
18 + if ( deltaTransit < 0.0 ) {
19 + deltaTransit = -deltaTransit;
20 + }
21 + stats->jitter += (deltaTransit - stats->jitter) / (16.0);
22 }
23 - stats->jitter += (deltaTransit - stats->jitter) / (16.0);
24 + data->lastTransit = transit;
25 }
26 - data->lastTransit = transit;
27
28 // packet loss occured if the datagram numbers aren't sequential
29 if ( packet->packetID != data->PacketID + 1 ) {
74
APÊNDICE C -- RESULTADOSEXPERIMENTAIS
Politíca Medida Média Desvio Padrão
B.C.
Dados Transferidos (Mb) 3.91 0.0
Largura de Banda Utilizada (Kbps) 164.0 0.0
jitter (ms) 0.136 0.013
Perda de Pacotes (%) 0.0 0.0
Pacotes Fora de Ordem (%) 0.9 0.0
R.R.
Dados Transferidos (Mb) 1.96 0.0
Largura de Banda Utilizada (Kbps) 82.0 0.0
jitter (ms) 0.131 0.022
Perda de Pacotes (%) 0.0 0.0
Pacotes Fora de Ordem (%) 0.0 0.0
Tabela C.1: Medidas de Avaliação das Politícas de Splitting
75
Amostra B.C. PESQ B.C. MOS-LQO R.R. PESQ R.R. MOS-LQO
1 3.7 3.8 3.7 3.8
2 3.7 3.9 3.7 3.9
3 4.0 4.1 4.0 4.1
4 3.8 3.9 3.8 3.9
5 3.7 3.8 3.7 3.9
6 3.9 4.0 3.9 4.0
7 3.7 3.8 3.7 3.8
8 3.7 3.9 3.7 3.9
9 3.8 4.0 3.8 4.0
10 3.7 3.9 3.7 3.9
11 3.8 3.9 3.8 3.9
12 3.7 3.8 3.7 3.8
13 3.9 4.0 3.9 4.0
14 3.9 4.1 3.9 4.1
15 3.9 4.0 3.9 4.0
16 3.9 4.0 3.9 4.0
17 3.9 4.1 3.9 4.1
18 4.0 4.1 4.0 4.1
19 3.7 3.9 3.7 3.9
20 3.7 3.9 3.7 3.9
21 3.7 3.9 3.7 3.9
22 4.0 4.1 4.0 4.1
23 3.9 4.1 3.9 4.1
24 4.2 4.3 4.2 4.3
25 3.7 3.9 3.7 3.9
26 3.9 4.1 3.9 4.1
27 3.9 4.0 3.9 4.0
28 3.9 4.0 3.9 4.0
29 3.9 4.1 3.9 4.1
30 3.7 3.8 3.7 3.8
31 3.8 3.9 3.8 3.9
32 3.7 3.8 3.7 3.8
33 3.7 3.8 3.7 3.8
76
34 3.9 4.1 3.9 4.1
35 3.8 3.9 3.8 3.9
36 3.7 3.8 3.7 3.8
37 3.8 3.9 3.8 3.9
38 3.7 3.9 3.7 3.9
39 3.9 4.0 3.9 4.0
40 3.8 3.9 3.8 3.9
41 3.9 4.0 3.9 4.0
42 3.9 4.0 3.9 4.0
43 3.8 3.9 3.8 3.9
Tabela C.2: Índice PESQ e MOS-LQO das técnicas de split-
ting R.R. e B.C. para o áudio de referencia ITU P862
77
Amostra B.C. PESQ B.C. MOS-LQO R.R. PESQ R.R. MOS-LQO
1 0.0 0.0 0.0 0.0
2 0.0 0.1 0.0 0.0
3 0.0 0.0 0.1 0.1
4 0.0 0.0 0.0 0.0
5 0.1 0.1 0.0 0.1
6 0.0 0.0 0.0 0.0
7 0.0 0.1 0.0 0.0
8 0.0 0.0 0.0 0.1
9 0.0 0.0 0.0 0.0
10 0.0 0.1 0.0 0.1
11 0.1 0.1 0.1 0.1
12 0.0 0.0 0.0 0.0
13 0.0 0.0 0.0 0.0
14 0.0 0.0 0.0 0.0
15 0.0 0.0 0.0 0.0
16 0.0 0.0 0.0 0.0
17 0.0 0.0 0.0 0.0
18 0.0 0.0 0.1 0.1
19 0.0 0.0 0.0 0.0
20 0.0 0.0 0.0 0.1
21 0.1 0.1 0.0 0.0
22 0.1 0.1 0.0 0.0
23 0.0 0.1 0.0 0.1
24 0.0 0.0 0.0 0.0
25 0.0 0.0 0.0 0.1
26 0.0 0.1 0.0 0.0
27 0.0 0.0 0.0 0.0
28 0.1 0.1 0.0 0.0
29 0.0 0.0 0.0 0.0
30 0.0 0.0 0.0 0.0
31 0.0 0.0 0.1 0.1
32 0.0 0.1 0.0 0.1
33 0.0 0.0 0.0 0.0
78
34 0.1 0.1 0.0 0.0
35 0.0 0.0 0.0 0.0
36 0.0 0.1 0.0 0.0
37 0.0 0.0 0.0 0.0
38 0.0 0.1 0.0 0.1
39 0.0 0.0 0.0 0.0
40 0.0 0.0 0.0 0.0
41 0.0 0.0 0.0 0.0
42 0.0 0.0 0.0 0.0
43 0.1 0.1 0.0 0.0
Tabela C.3: Desvio padrão do índice PESQ e MOS-LQO das
técnicas de splitting R.R. e B.C. para o áudio de referencia
ITU P862
79
REFERÊNCIAS BIBLIOGRÁFICAS
AHRENHOLZ, J. Comparison of core network emulation platforms. In: MILITARYCOMMUNICATIONS CONFERENCE, 2010 - MILCOM 2010. [S.l.: s.n.], 2010. p. 166–171.ISSN 2155-7578.
ALI, C. B.; PERKINS, C. Duplicating rtp streams draft-ietf-avtext-rtp-duplication-02.IETF, Tech. Rep., 2013.[Online]. Available: http://tools.ietf.org/html/draft-ietf-avtext-rtp-duplication-02, 2013.
ALI, C. B.; YUN, C.; HEIDI, O. uplication grouping semantics in the session descriptionprotocol draft-ietf-mmusic-duplication-grouping-02. IETF, Tech. Rep., 2013.[Online].Available: http://tools.ietf.org/html/draft-ietf-mmusic-duplication-grouping-02.
BIRKE, R. et al. Experiences of voip traffic monitoring in a commercial isp. InternationalJournal of Network Management, Wiley Online Library, v. 20, n. 5, p. 339–359, 2010.
BORDIM, J. L. Introdução à Voz sobre IP e Asterisk. 1.1. ed. Brasil: Escola Superior de RedesRNP, 2010.
CASTRO, M. C. et al. Capacity increase for voice over ip traffic through packet aggregationin wireless multihop mesh networks. In: . [s.n.], 2007. v. 2, p. 350–355. Disponível em:<http://dx.doi.org/10.1109/FGCN.2007.81>.
CETINKAYA, C.; KNIGHTLY, E. W. Opportunistic traffic scheduling over mul-tiple network paths. In: . [s.n.], 2004. v. 3, p. 1928–1937. Disponível em:<http://dx.doi.org/10.1109/INFCOM.2004.1354602>.
CIDON, I.; ROM, R.; SHAVITT, Y. Analysis of multi-path routing. IEEE/ACMTrans. Netw., Piscataway, NJ, USA, v. 7, n. 6, p. 885–896, Jan 1999. Disponível em:<http://dx.doi.org/10.1109/90.811453>.
CONSORTIUM, O. S. et al. OpenFlow Switch Specification Version 1.0.0. [S.l.]: December,2009.
CONSORTIUM, O. S. et al. OpenFlow Switch Specification Version 1.1.0. 2011.
FRING.COM. what is fring. 2007. http://www.fring.com/what-is-fring. Accessado: .
GEER, D. The future of mobile voip in the enterprise. Computer, v. 42, n. 6, p. 15–18, 2009.Disponível em: <http://dx.doi.org/10.1109/MC.2009.202>.
GOOGLE. Nosso Planeta Mobile: Brasil. Maio 2013. http://services.google.com/fh/files/misc/omp-2013-br-local.pdf. Accessed: .
GOOGLE.COM. O que é o novo Google Maps? 2005. https://support.google.com/maps/answer/3092426?hl=pt-BR&ref_topic=1687350. Accessado: .
80
GUERIN, J.; PORTMANN, M.; PIRZADA, A. Routing metrics for multi-radio wireless meshnetworks. In: Telecommunication Networks and Applications Conference, 2007. ATNAC 2007.Australasian. [S.l.: s.n.], 2007. p. 343–348.
GUHA, S.; DASWANI, N. An experimental study of the skype peer-to-peer voip system. [S.l.],2005.
HANDLEY, M.; JACOBSON, V.; PERKINS, C. RFC 4566: SDP: Session DescriptionProtocol. [S.l.], 2006.
HOSSAIN, E.; LEUNG, K. K. Wireless mesh networks: architectures and protocols. [S.l.]:Springer Publishing Company, Incorporated, 2008.
HUNTGEBURTH, B.; SCHUMANN, S.; LONDAK, J. Voice over ip (voip) speech qualitymeasurement with open-source software components. In: . [S.l.: s.n.], 2010. p. 215–218.
HWANG, J. et al. A mobile voip architecture over lte & wlan networks. In: . [S.l.: s.n.], 2010.v. 1, p. 729–732.
IEEE Standard for Information Technology - Telecommunications and Information ExchangeBetween Systems - Local and Metropolitan Area Networks - Specific Requirements Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) SpecificationsAmendment 8: Medium Access Control (MAC) Quality of Service Enhancements. IEEE Std802.11e-2005 (Amendment to IEEE Std 802.11, 1999 Edition (Reaff 2003), p. 0_1–189, 2005.
IEEE Standard for Information Technology–Telecommunications and information exchangebetween systems–Local and metropolitan area networks–Specific requirements Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specificationsAmendment 10: Mesh Networking. IEEE Std 802.11s-2011 (Amendment to IEEE Std802.11-2007 as amended by IEEE 802.11k-2008, IEEE 802.11r-2008, IEEE 802.11y-2008,IEEE 802.11w-2009, IEEE 802.11n-2009, IEEE 802.11p-2010, IEEE 802.11z-2010, IEEE802.11v-2011, and IEEE 802.11u-2011), p. 1–372, 2011.
IEEE Standard for Information technology–Telecommunications and information exchangebetween systems Local and metropolitan area networks–Specific requirements Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.IEEE Std 802.11-2012 (Revision of IEEE Std 802.11-2007), p. 1, Mar 2012. Disponível em:<http://dx.doi.org/10.1109/IEEESTD.2012.6178212>.
ITU-T, R. G. 711: Pulse code modulation (pcm) of voice frequencies. InternationalTelecommunication Union, 1988.
ITU-T, R. G. 729: Coding of speech at 8 kbit/s using conjugate structure algebraic-code-excitedlinear-prediction (cs-acelp). International Telecommunication Union, 1996.
ITU-T, R. P. 800: Methods for subjective determination of transmission quality. InternationalTelecommunication Union, 1996.
ITU-T, R. H. 323: Packet-based multimedia communication systems. InternationalTelecommunication Union, 1998.
81
ITU-T, R. P. 862: Perceptual evaluation of speech quality (pesq): An objective method forend-to-end speech quality assessment of narrow-band telephone networks and speech codecs.International Telecommunication Union, 2001.
ITU-T, R. P. 862.1: Mapping function for transforming p. 862 raw result scores to mos-lqo.International Telecommunication Union, 2003.
KIM, B. W.; PARK, J.; KO, C. Y. Cost allocation of wcdma and wholesale pricing for mvoipand data services. Telecommunications Policy, v. 37, n. 1, p. 35–47, 2013. Disponível em:<http://www.sciencedirect.com/science/article/pii/S0308596112001607>.
KUROSE, J. F.; ROSS, K. W. Computer Networking: A Top-Down Approach. USA:Addison-Wesley Publishing Company, 2009.
LE, L. Multipath routing design for wireless mesh networks. In: . [s.n.], 2011. p. 1–6.Disponível em: <http://dx.doi.org/10.1109/GLOCOM.2011.6133896>.
LEE, S.-J.; GERLA, M. Split multipath routing with maximally disjoint pathsin ad hoc networks. In: . [s.n.], 2001. v. 10, p. 3201–3205. Disponível em:<http://dx.doi.org/10.1109/ICC.2001.937262>.
MAJEED, A.; ABU-GHAZALEH, N. B. Packet aggregation in multi-rate wireless lans. In: .[s.n.], 2012. p. 452–460. Disponível em: <http://dx.doi.org/10.1109/SECON.2012.6275811>.
MCKEOWN, N. et al. Openflow: enabling innovation in campus networks. SIGCOMMComput. Commun. Rev., New York, NY, USA, v. 38, n. 2, p. 69–74, 2008. Disponível em:<http://doi.acm.org/10.1145/1355734.1355746>.
MILLS-TETTEY, G. A.; KOTZ, D. Mobile voice over ip (mvoip): an application-levelprotocol for call hand-off in real time applications. In: . [s.n.], 2002. p. 271–279. Disponívelem: <http://dx.doi.org/10.1109/IPCCC.2002.995160>.
MISRA, S.; MISRA, S. C.; WOUNGANG, I. Guide to Wireless Mesh Networks. [S.l.]:Springer Publishing Company, Incorporated, 2008.
NOXREPO.ORG. About POX. Setembro 2013. http://www.noxrepo.org/pox/about-pox/.Accessado: 2013-09-23.
OPENVSWITCH.ORG. Open vSwitch. Setembro 2013. http://openvswitch.org/. Accessed:2013-09-23.
PER Call Bandwidth Consumption. [S.l.]: CISCO, Voice Over IP, 2013.[Online]. Available:http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml.
RAPTIS, P.; VITSAS, V.; PAPARRIZOS, K. Packet delay metrics for ieee 802.11 distributedcoordination function. Mobile Networks and Applications, Springer US, v. 14, n. 6, p. 772–781,2009. Disponível em: <http://dx.doi.org/10.1007/s11036-008-0124-7>.
RIBEIRO, J. C.; LEITE, L.; SOUSA, S. Notas sobre aspectos sociais presentes no uso dastecnologias comunicacionais móveis contemporâneas. Educação e Contemporaneidade:Pesquisas científicas e tecnológicas. Salvador: Edufba, p. 185–201, 2009.
ROSENBERG, J. et al. RFC 3261: SIP: Session initiation protocol. [S.l.], 2002.
82
SCHULZRINNE, H. et al. RFC 3550 RTP: A Transport Protocol for Real-Time Applications.[S.l.], 2003.
SHIN, D.-H. What makes consumers use voip over mobile phones?: Free riding orconsumerization of new service. Telecommunications Policy, v. 36, n. 4, p. 311–323, Jan 2012.
SIRIS, V.; TRAGOS, E.; PETROULAKIS, N. Experiences with a metropolitan multiradiowireless mesh network: design, performance, and application. Communications Magazine,IEEE, v. 50, n. 7, p. 128–136, 2012. ISSN 0163-6804.
SKYPE.COM. O que é o Skype? 2003. http://www.skype.com/pt-br/what-is-skype/.Accessado: .
SPYROPOULOS, T.; FDIDA, S.; KIRKPATRICK, S. Future internet: fundamen-tals and measurement. SIGCOMM Comput. Commun. Rev., ACM, New York,NY, USA, v. 37, n. 2, p. 101–106, mar. 2007. ISSN 0146-4833. Disponível em:<http://doi.acm.org/10.1145/1232919.1232934>.
STALLINGS, W. Wireless Communications & Networks (2nd Edition). [S.l.]: Upper SaddleRiver, NJ, USA, 2004.
THALER, D.; HOPPS, C. Multipath issues in unicast and multicast next-hop selection. [S.l.],2000.
TIRUMALA, A. et al. Iperf. 2006.
ULSETH, T.; ENGELSTAD, P. Voice over wlan (vowlan)-a wireless voice alternative.TELEKTRONIKK, TELEDIREKTORATET, v. 102, n. 1, p. 82, 2006.
VOIP Statistics – Market Analysis. [S.l.], 2012.
YANG, Y.; WANG, J.; KRAVETS, R. Designing routing metrics for mesh networks. IEEEWorkshop on Wireless Mesh Networks (WiMesh), 2005.
ZHANG, S. et al. Fell: A flexible virtual network embedding algorithmwith guaranteed load balancing. In: . [s.n.], 2011. p. 1–5. Disponível em:<http://dx.doi.org/10.1109/icc.2011.5962960>.
ZHANG, W. et al. Reliable adaptive multipath provisioning with bandwidthand differential delay constraints. In: . [s.n.], 2010. p. 1–9. Disponível em:<http://dx.doi.org/10.1109/INFCOM.2010.5462042>.