UNIVERSIDADE FEDERAL DA BAHIAibirisol/monografia.pdf · acentuada em redes sem ﬁo, onde há...

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



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

UNIVERSIDADE FEDERAL DA BAHIAibirisol/monografia.pdf · acentuada em redes sem ﬁo, onde há...

Documents

Transcript of UNIVERSIDADE FEDERAL DA BAHIAibirisol/monografia.pdf · acentuada em redes sem ﬁo, onde há...