XIX Workshop de Gerência e Operação de Redes e Serviços WGRS 2014 · 2014-04-21 · Anais do XIX Workshop de Gerência e Operação de Redes e Serviços– WGRS 2014 ii ... UnB,

Anais XIX Workshop de Gerência e

Operação de Redes e Serviços WGRS 2014

XXXII Simpósio Brasileiro de Redes de Computadores e

Sistemas Distribuídos

5 a 9 de Maio de 2014

Florianópolis - SC

Anais

XIX Workshop de Gerência e Operação de

Redes e Serviços (WGRS)

Editora

Sociedade Brasileira de Computação (SBC)

Organizadores

Eduardo Cerqueira (UFPA)

Carlos André Guimarães Ferraz (UFPE)

Joni da Silva Fraga (UFSC)

Frank Siqueira (UFSC)

Realização

Universidade Federal de Santa Catarina (UFSC)

Promoção


Laboratório Nacional de Redes de Computadores (LARC)

Anais do XIX Workshop de Gerência e Operação de Redes e Serviços– WGRS 2014

i

Copyright ©2014 da Sociedade Brasileira de Computação

Todos os direitos reservados

Capa: Vanessa Umbelino (PostMix)

Produção Editorial: Roberto Willrich (UFSC)

Cópias Adicionais:


Av. Bento Gonçalves, 9500- Setor 4 - Prédio 43.412 - Sala 219

Bairro Agronomia - CEP 91.509-900 -Porto Alegre- RS

Fone: (51) 3308-6835

E-mail: [email protected]

Workshop de Gerência e Operação de Redes e Serviços (19: 2014:

Florianópolis, SC)

Anais / XIX Workshop de Gerência e Operação de Redes e Serviços; organizado

por Eduardo Cerqueira... [et al.] - Porto Alegre: SBC, c2014

215 p.

WGRS 2014

Realização: Universidade Federal de Santa Catarina

ISSN: 2177-496X

1. Redes de Computadores - Congressos. 2. Sistemas Distribuídos Congressos.

I. Cerqueira, Eduardo. II. Sociedade Brasileira de Computação. III. Título.


ii

Promoção


Diretoria

Presidente

Paulo Roberto Freire Cunha (UFPE)

Vice-Presidente

Lisandro Zambenedetti Granville (UFRGS)

Diretora Administrativa

Renata de Matos Galante (UFRGS)

Diretor de Finanças


Diretor de Eventos e Comissões Especiais

Altigran Soares da Silva (UFAM)

Diretora de Educação

Mirella Moura Moro (UFMG)

Diretor de Publicações

José Viterbo Filho (UFF)

Diretora de Planejamento e Programas Especiais

Claudia Lage Rebello da Motta (UFRJ)

Diretor de Secretarias Regionais

Marcelo Duduchi Feitosa (CEETEPS)

Diretor de Divulgação e Marketing

Edson Norberto Caceres (UFMS)

Diretor de Relações Profissionais

Roberto da Silva Bigonha (UFMG)

Diretor de Competições Científicas

Ricardo de Oliveira Anido (UNICAMP)

Diretor de Cooperação com Sociedades Científicas

Raimundo José de Araujo Macêdo (UFBA)

Diretor de Articulação de Empresas

Avelino Francisco Zorzo (PUC-RS)


iii

Promoção


Conselho

Mandato 2013-2017

Alfredo Goldman (IME/USP)

José Palazzo Moreira de Oliveira (UFRGS)

Maria Cristina Ferreira de Oliveira (ICMC/USP)

Thais Vasconcelos Batista (UFRN)

Wagner Meira Junior (UFMG)

Mandato 2011-2015

Ariadne Carvalho (UNICAMP)

Carlos Eduardo Ferreira (IME - USP)

Jose Carlos Maldonado (ICMC - USP)

Luiz Fernando Gomes Soares (PUC-Rio)

Marcelo Walter (UFRGS)

Suplentes - 2013-2015

Alessandro Fabrício Garcia (PUC-Rio)

Aline Maria Santos Andrade (UFBA)

Daltro José Nunes (UFRGS)

Karin Koogan Breitman (PUC-Rio)

Rodolfo Jardim de Azevedo (UNICAMP-IC)


iv

Promoção

Laboratório Nacional de Redes de Computadores (LARC)

Diretoria 2012-2014

Diretor do Conselho Técnico-Científico

Elias P. Duarte Jr. (UFPR)

Diretor Executivo

Luciano Paschoal Gaspary (UFRGS)

Vice-Diretora do Conselho Técnico-Científico

Rossana Maria de C. Andrade (UFC)

Vice-Diretor Executivo

Paulo André da Silva Gonçalves (UFPE)

Membros Institucionais

SESU/MEC, INPE/MCT, UFRGS, UFMG, UFPE, UFCG (ex-UFPB Campus Campina

Grande), UFRJ, USP, PUC-Rio, UNICAMP, LNCC, IME, UFSC, UTFPR, UFC, UFF,

UFSCar, CEFET-CE, UFRN, UFES, UFBA, UNIFACS, UECE, UFPR, UFPA,

UFAM, UFABC, PUCPR, UFMS, UnB, PUC-RS, UNIRIO, UFS e UFU.


v

Realização

Comitê de Organização

Coordenação Geral

Joni da Silva Fraga (UFSC) Frank Augusto Siqueira (UFSC)

Coordenação do WGRS


Coordenação de Workshops



vi

Realização

Organização Local

Carlos Barros Montez (UFSC)

Edison Tadeu Lopes Melo (UFSC)

Guilherme Eliseu Rhoden (PoP-SC)

Leandro Becker (UFSC)

Mário A. R. Dantas (UFSC)

Michelle Wangham (Univali)

Ricardo Felipe Custódio (UFSC)

Roberto Willrich (UFSC)

Rodrigo Pescador (PoP-SC)

Rômulo Silva de Oliveira (UFSC)

Secretaria do SBRC 2014

Juliana Clasen (UFSC)

Jade Zart (UFSC)


vii

Mensagem do Coordenador de Workshops do SBRC 2014

Confirmando a consolidação nos últimos anos, este ano o Simpósio Brasileiro de Redes

de Computadores e Sistemas Distribuídos (SBRC 2014) apresenta mais uma série de

workshops, visando a discussão de temas novos e/ou específicos, como Internet do

Futuro e Tolerância a Falhas. Os workshops envolvem comunidades focadas e oferecem

oportunidades para discussões mais profundas e ampliação de conhecimentos,

envolvendo pesquisadores e muitos estudantes em fase de desenvolvimento de seus

trabalhos em andamento. Neste ano tivemos novas submissões, além dos workshops já

considerados tradicionais parceiros do SBRC, o que representa o dinamismo da

comunidade de Redes de Computadores e Sistemas Distribuídos no Brasil. Infelizmente,

estas novas submissões não puderam ainda ser acomodadas, mas certamente serão

consideradas para próximas edições do SBRC.

Neste SBRC 2014, temos a realização de workshops já consolidados no circuito

nacional de divulgação científica nas várias subáreas de Redes de Computadores e

Sistemas Distribuídos, como o WGRS (Workshop de Gerência e Operação de Redes e

Serviços), o WTF (Workshop de Testes e Tolerância a Falhas), o WCGA (Workshop de

Computação em Clouds e Aplicações), o WP2P+ (Workshop de Redes P2P, Dinâmicas,

Sociais e Orientadas a Conteúdo), o WRA (Workshop de Redes de Acesso em Banda

Larga), o WoCCES (Workshop of Communication in Critical Embedded Systems), o

WoSiDA (Workshop on Autonomic Distributed Systems) e o WPEIF (Workshop de

Pesquisa Experimental da Internet do Futuro). Há que se mencionar a importante

parceria com o WRNP (Workshop da Rede Nacional de Ensino e Pesquisa), que em sua

15a edição, cumpre o importante papel de fazer a ponte entre as comunidades técnica e

científica da área. Não tenho dúvida que a qualidade técnica e científica dos workshops

se manterá em alta compatível com o SBRC.

Agradeço aos Coordenadores Gerais, Joni da Silva Fraga e Frank Siqueira (UFSC), pelo

convite para coordenar os workshops do SBRC 2014 e por todo o apoio recebido.

Desejo muito sucesso e excelente participação nos Workshops do SBRC 2014!

Carlos André Guimarães Ferraz

Coordenador de Workshops do SBRC 2014


viii

Mensagem do Coordenador do WGRS 2014

O Workshop de Gerência e Operação de Redes e Serviços (WGRS) é um evento

promovido pela Sociedade Brasileira de Computação (SBC) e tem como objetivo

oferecer um espaço para a apresentação de pesquisas e atividades relevantes na área de

gerenciamento e operação de redes e serviços. Dessa forma, o evento contribui para a

integração da comunidade brasileira de pesquisadores e profissionais atuantes nessa

área. Além disso, o WGRS visa promover um fórum para a apresentação e discussão de

soluções utilizadas por provedores e usuários de sistemas de gerenciamento de redes.

A 19a edição do WGRS 2014, realizada durante o 32a Simpósio Brasileiro de Redes de

Computadores e Sistemas Distribuídos (SBRC 2014), no dia 05 de maio de 2014, em

Florianópolis, SC, recebeu 42 submissões provando que a comunidade continuou a

prestigiar o WGRS 2014. O Comitê de Programa foi constituído por 33 pesquisadores.

Esse comitê contou, ainda, com o apoio de avaliadores externos para a condução do

processo de avaliação de artigos. Cada artigo recebeu, no mínimo, 3 avaliações

independentes e, ao final do processo de avaliação dos artigos submetidos, tivemos ao

todo 144 revisões. Dentre os artigos submetidos, o Comitê de Programa optou por

indicar os 14 melhores classificados para publicação e apresentação no evento,

representando uma taxa de aceitação de aproximadamente 33%.

Cada artigo aceito será apresentado em uma das quatro sessões técnicas da programação

do evento: (i) Gerenciamento de redes sem fio, de sensores e Smart Grids; (ii)

Virtualização e Redes Definidas por Software; (iii) Segurança, privacidade e qualidade

de serviço na Internet; e (iv) Gerenciamento de VANETs e VANTs

Gostaria de expressar o meu agradecimento aos membros do Comitê de Programa e aos

revisores por terem aceitado participar voluntariamente dessa empreitada. Agradeço-os

também pela competência e dedicação na realização do processo de avaliação e seleção

dos artigos. Gostaria de expressar também os meus agradecimentos aos coordenadores

gerais do SBRC 2014, Joni da Silva Fraga (UFSC) e Frank Siqueira (UFSC), e ao

coordenador de Workshops do SBRC 2014, Carlos André Guimarães Ferraz (UFPE),

pela disponibilidade e orientações providas ao longo do processo. Agradeço também aos

ex-coordenadores do WGRS, Michele Nogueira (UFPR), Fátima Duarte-Figueiredo

(PUC Minas) e Paulo André da Silva Gonçalves (UFPE) pela oportunidade e confiança

ao me convidarem para coordenar o workshop. Finalmente, não poderia de deixar de

expressar os meus agradecimentos aos autores que submeteram os seus trabalhos e que

nos motivam a realizar anualmente este evento de interesse, visibilidade e sucesso

crescentes.

Saúdo a todos os participantes do XIX Workshop de Gerência e Operação de Redes e

Serviços com os votos de um excelente workshop e de uma excelente estadia em

Florianópolis!

Eduardo Cerqueira

Coordenador do WGRS 2014


ix

Comitê de Programa do WGRS 2014

Alberto Schaeffer Filho (UFRGS)

Aldri Luiz dos Santos (UFPR)

André Cardoso (UECE)

Anelise Munaretto (UTFPR)

Artur Ziviani (LNCC)

Augusto Neto (UFRN)

Carlos Westphall (UFSC)

Célio Vinicius Neves de Albuquerque (UFF)

Daniel Fernandes de Macedo (UFMG)

Danielo Gonçalves Gomes (UFC)

Edmundo Madeira (UNICAMP)


Fátima Duarte-Figueiredo (PUC Minas)

Flávia Delicato (UFRJ)

Horácio Oliveira (UFAM)

Igor Moraes (UFF)

Joaquim Celestino Júnior (UECE)

José Neuman de Souza (UFC)

José Marcos Nogueira (UFMG)

Jussara Almeida (UFMG)

Leandro Villas (UNICAMP)

Lisandro Zambenedetti Granville (UFRGS)

Luciano Paschoal Gaspary (UFRGS)

Luis Henrique Costa (UFRJ)

Luiz Fernando Bittencourt (UNICAMP)

Luiz Henrique Correia (UFLA)

Manoel Camillo de Oliveira Penna Neto (PUCPR)

Marcelo Pellenz (PUCPR)

Marcelo Rubinstein (UERJ)

Marcia Pasim (UFSM)

Mauro Fonseca (PUCPR)

Michele Nogueira (UFPR)

Miguel Elias Mitre Campista (UFRJ)

Nazareno Andrade (UFCG)

Paulo André da Silva Gonçalves (UFPE)

Pedro Veloso (UFF)

Raimir Holanda (UNIFOR)

Ronaldo Ferreira (UFMS)


x

Sumário

Sessão Técnica 1 – Gerenciamento de redes sem fio, de sensores e Smart Grids... 1

Evoluindo um Sistema de Monitoramento Passivo Energeticamente Eficiente

para Redes de Sensores Sem Fio

Fernando Garcia (IFCE), Rossana Andrade (UFC), Carina T. de Oliveira (UFC)

e José Neuman de Souza (UFC)............................................................................ 3

ACRoMa - An Architecture of Cooperative Routing Management in Wireless

Mesh Networks

Vinicius C. M. Borges (UFG), Edmundo Monteiro (Universidade de Coimbra,

Portugal) e Marilia Curado (Universidade de Coimbra, Portugal)........................ 17

SMARTFlow: Uma Proposta para a Autoconfiguração de Redes de Subestação

IEC Baseada em OpenFlow

Yona Lopes (UFF), Natalia C. Fernandes (UFF) e Carlos A. M. Bastos (UFF)... 31

Sessão Técnica 2 – Virtualização e Redes definidas por software............................ 45

Dependabilidade na Alocação de Recursos em Redes Virtuais: Uma Heurística

Aleatória com Busca Adaptativa

Marcelo Santos (UFPE), Matheus Santana (UFPE), Djamel Sadok (UFPE) e

Stenio Fernandes (UFPE)...................................................................................... 47

Proposta de Modificação da VMM-MIB para o Gerenciamento de Roteadores

Virtuais

Paulo Ferraz (UFRGS), Rafael Esteves (UFRGS),

Lisandro Z. Granville (UFRGS)............................................................................ 61

Um análise quantitativa do tráfego de controle em redes OpenFlow

Pedro H. Isolani (UFRGS), Juliano Wickboldt (UFRGS),

Cristiano Both (UFRGS), Juergen Rochol (UFRGS) e

Lisandro Z. Granville (UFRGS)............................................................................ 75

Migração de máquinas virtuais para economia de energia

Leonardo Cardoso (UFRJ), Lyno Ferraz (UFRJ) e

Otto C. M. B. Duarte (UFRJ)................................................................................ 89


xi

Sumário

Sessão Técnica 3 – Segurança, privacidade e qualidade de serviço na Internet... 103

Um Modelo de Falhas em Cascata para Sistemas Globais de Gerenciamento de

Identidades

Ricardo T. Macedo (UFPR), Aldri dos Santos (UFPR), André Guedes (UFPR),

Michele Nogueira (UFPR) e Yacine Ghamri-Doudane (University of La Rochelle,

França)................................................................................................................. 105

Análise Sistemática do Fenômeno Bufferbloat

Thiago B. Cardozo (LNCC), Alex Borges Vieira (UFJF), Artur Ziviani (LNCC),

Ana Paula Couto da Silva (UFMG).................................................................... 119

Distribuição de Vídeo sob Demanda Baseada em Redes de Distribuição de

Conteúdo utilizando Redes Orientadas a Conteúdo

Felipe Ramos (UFRJ), Igor Alvarenga (UFRJ), Pedro Caldas (UFRJ) e

Otto C. M. B. Duarte (UFRJ).............................................................................. 133

Sessão Técnica 4 – Gerenciamento de VANETs e VANTs..................................... 147

Um Mecanismo para Realçar a Conectividade de Roteamento Geográfico na

Transmissão Multimídia em VANTs

Rodrigo Costa (UFPA), Denis Rosário (UFPA), Eduardo Cerqueira (UFPA) e

Aldri dos Santos (UFPR).................................................................................... 149

Investigação sobre o Uso de VANTs em Redes DTN para Cenários de

Emergência

João Carlos Albuquerque (UNIRIO), Sidney Lucena (UNIRIO),

Carlos Alberto V. Campos (UNIRIO)................................................................. 163

Protocolo Adaptativo de Disseminação de Dados para Aplicações de Segurança

no Trânsito em Rodovias

Renê Oliveira (UFSC ), Michelle Wangham (UNIVALI) e

Carlos Montez (UFSC)........................................................................................ 177

Simulação e Análise de Métodos de Detecção de Congestionamento de Veículos

em VANET

Mariana R. de Brito (PUC Minas), Anna Izabel Tostes (UFMG),

Fatima Duarte-Figueiredo (PUC Minas), Antônio A. F. Loureiro (UFMG)....... 191

Índice por Autor.......................................................................................................... 202

32º Simpósio Brasileiro de Redes de Computadores e


Florianópolis - SC

XIX Workshop de Gerência e

Operação de Redes e Serviços

(WGRS)

Sessão Técnica 1

Gerenciamento de redes sem fio, de

sensores e Smart Grids

Evoluindo um Sistema de Monitoramento Passivo

Energeticamente Eficiente para Redes de Sensores Sem Fio

Fernando P. Garcia1,2,3

, Rossana M. C. Andrade1,2,b

, Carina T. de Oliveira2, José

Neuman de Souza1,2,a

Universidade Federal do Ceará (UFC) 1Mestrado e Doutorado em Ciência da Computação (MDCC)

2Grupo de Redes de Computadores, Engenharia de Software e Sistemas (GREat)

3Instituto Federal de Educação, Ciência e Tecnologia do Ceará (IFCE)

[email protected], [email protected], [email protected],

[email protected]

Resumo. Um sistema de monitoramento passivo permite depurar e analisar o

funcionamento de uma RSSF (Rede de Sensores Sem Fio). Neste caso, uma

rede de monitoramento adicional é implantada com o intuito de capturar e

analisar os pacotes transmitidos pela rede a ser monitorada (a rede alvo).

Quando se deseja monitorar uma RSSF em um ambiente real, é necessário um

sistema de monitoramento passivo energeticamente eficiente, pois o tempo de

vida da rede de monitoramento é prolongado e, consequentemente, a rede

alvo é beneficiada pelo monitoramento por mais tempo. Apenas um trabalho

na literatura apresenta este tipo de solução, entretanto, os seus módulos são

descritos de forma simplificada, o que dificulta a implementação em

ambientes reais. Neste artigo, é proposta uma evolução desta solução, onde

todos os módulos são especificados em detalhe e é adicionado um agente

SNMP (Simple Network Management Protocol) a fim de integrar o sistema

com ferramentas de gerência SNMP, facilitando a administração da rede

alvo. Experimentos com sensores reais foram realizados em vários cenários e

os resultados comprovam a eficiência energética do sistema proposto, assim

como a viabilidade de utilizá-lo para monitorar RSSF em ambientes reais.

Abstract. A passive monitoring system enables debugging and analysis of the

operation of a WSN (Wireless Sensor Network). In this case, a monitoring

network is deployed in order to capture and analyze packets sent by the

network to be monitored (target network). An energy-efficient passive

monitoring system is necessary when we need to monitor a WSN in a real

scenario because the lifetime of the monitoring network is extended and,

consequently, the target network is benefited by the monitoring for longer.

Only one work in the literature approaches this type of solution, however, the

modules are described in a simplified manner what makes it difficult to

implement the system in real scenarios. In this paper, we propose an evolution

of this solution, in which all modules are specified in details and an SNMP

(Simple Network Management Protocol) agent is developed to integrate the

system with SNMP management tools and facilitate the administration of the

target network. Experiments with real sensors are performed on several

scenarios. The results obtained show the energy efficiency of the monitoring

system proposed and the viability of using it to monitor WSN in real scenarios.

a Bolsista de produtividade D-1 do CNPq b Bolsista de produtividade DT-2 do CNPq


3

1. Introdução

Os avanços recentes nas áreas de microeletrônica, sensoriamento e comunicação sem fio

propiciaram o surgimento e a evolução das RSSF (Redes de Sensores Sem Fio).

Aplicações propostas para RSSF incluem detecção sísmica, monitoramento ambiental,

casas inteligentes, entre outras. Em geral, as RSSF são compostas por nós sensores de

tamanho reduzido operados por baterias e que utilizam comunicação sem fio de

pequeno alcance. Além disso, estas redes possuem severas restrições de energia,

processamento, memória e largura de banda [Borges Neto et al. 2010].

É importante destacar que o tempo de vida de uma RSSF pode ser de até vários

anos, de forma que nem todos os problemas aparecem durante as primeiras semanas

após a implantação da rede. Portanto, o monitoramento é importante para depurar e

analisar o funcionamento de uma RSSF durante sua operação. Por exemplo, utilizando

um sistema de monitoramento é possível obter várias informações sobre o

funcionamento da RSSF, tais como descoberta de topologia, morte e reinicialização de

nós, perda de pacotes e latência da rede [Ringwald and Romer 2007].

O monitoramento da rede pode ser dividido em ativo e passivo. No

monitoramento ativo são inseridas linhas de código na aplicação executada pelos nós

sensores para obter informações sobre o funcionamento da rede, consumindo os

recursos da rede monitorada. No monitoramento passivo, uma rede de monitoramento

adicional é implantada juntamente com a rede que deve ser monitorada (rede alvo). A

rede de monitoramento captura e analisa os pacotes transmitidos pela rede alvo, não

consumindo nenhum recurso da rede alvo. Sendo assim, um sistema de monitoramento

energeticamente eficiente é necessário quando se deseja monitorar uma RSSF em um

cenário real, pois o tempo de vida da rede de monitoramento é prolongado e,

consequentemente, a rede alvo é beneficiada pelo monitoramento por mais tempo.

Diante deste contexto, nós propusemos um sistema de monitoramento passivo

para RSSF [Garcia et al. 2013], cujo principal objetivo foi reduzir o consumo de energia

da rede de monitoramento e, consequentemente, prolongar o tempo de vida desta rede.

Neste trabalho, nós descrevemos de forma simplificada alguns módulos do sistema de

monitoramento passivo e apresentamos alguns resultados preliminares.

No presente artigo, nós evoluímos o sistema de monitoramento proposto em

[Garcia et al. 2013], o qual é denominado aqui de EPMOSt (Energy-efficient Passive

MOnitoring System). Todos os módulos do EPMOSt são descritos de forma detalhada e

são realizados novos experimentos em diversos cenários. Além destas contribuições, o

EPMOSt disponibiliza as informações obtidas com o monitoramento através de um

agente SNMP (Simple Network Management Protocol). O agente SNMP permite

integrar o EPMOSt com qualquer ferramenta de gerência que suporte tal protocolo,

facilitando a administração da RSSF monitorada.

O restante deste artigo está organizado da seguinte forma: A Seção 2 apresenta o

sistema de monitoramento EPMOSt. A Seção 3 descreve os experimentos realizados

para avaliar o EPMOSt e discute os resultados alcançados. A Seção 4 aborda alguns

trabalhos relacionados. Por fim, as conclusões e trabalhos futuros são apresentados na

Seção 5.


4

2. O EPMOSt

Conforme mencionado na Seção 1, um sistema de monitoramento passivo

energeticamente eficiente é importante caso se deseje monitorar continuamente uma

RSSF em um cenário real, pois, caso contrário, a rede de monitoramento pode ter um

tempo de vida bem menor do que a rede alvo devido à má utilização da energia dos

sniffers (nós da rede de monitoramento). Em [Garcia et al. 2013], propusemos então

uma primeira versão simplificada de um sistema de monitoramento passivo para RSSF

que está sendo evoluído neste artigo e é aqui denominado de EPMOSt, o qual reduz o

consumo de energia da rede de monitoramento.

A Figura 1 mostra a visão geral do EPMOSt. Um sniffer captura em modo

promíscuo os pacotes enviados por um ou mais nós da rede alvo, insere um timestamp

em cada pacote capturado e envia este pacote para o monitor local. O monitor local

recebe as mensagens de monitoramento de vários sniffers e insere as informações dos

pacotes capturados em um arquivo de trace (banco de dados) localizado no servidor. O

servidor, por sua vez, executa uma aplicação que analisa o trace gerado por um ou mais

monitores locais para extrair diversas informações sobre a rede alvo (e.g., tempo em que

cada nó está ativo, perda de pacotes, morte e reinicialização de nós, quantidade de

pacotes enviados e recebidos por cada nó, etc.). Estas informações são disponibilizadas

para o usuário e são também armazenadas em uma MIB (Management Information

Base) para serem acessadas por um agente SNMP.

Figura 1. Visão geral do sistema de monitoramento EPMOSt.

A Figura 2 mostra a arquitetura do sistema de monitoramento EPMOSt. Os

detalhes de cada uma das camadas do sistema são apresentados nas subseções seguintes.

Figura 2. Arquitetura do EPMOSt.


5

2.1. Eleição de Sniffers

Após a implantação da rede de monitoramento, os sniffers e o monitor local iniciam um

mecanismo para eleger quais nós da rede alvo terão seus pacotes capturados por quais

sniffers. Este mecanismo de eleição é executado quando um sniffer captura pela

primeira vez um pacote de um determinado nó da rede alvo e leva em consideração o

RSSI (Received Signal Strength Indicator), que indica o nível de potência do sinal

recebido.

Quando um sniffer SX captura pela primeira vez um pacote de um nó A da rede

alvo, ele envia uma mensagem de inclusão de um novo nó para o monitor local

informando o endereço deste nó (A) e o RSSI correspondente. Caso nenhum outro

sniffer esteja capturando pacotes do nó A, o monitor local envia uma mensagem para SX

iniciar a captura dos pacotes enviados por A. O sniffer SX envia então um pacote de

confirmação (ACK) para o monitor local e inicia a captura dos pacotes enviados por A.

No entanto, se já houver outro sniffer SY capturando pacotes do nó A, o monitor

local analisa qual dos dois sniffers está recebendo os pacotes de A com maior RSSI,

pois, em geral, quanto maior o valor do RSSI, melhor é a qualidade do sinal. Caso SY

esteja recebendo o sinal de A com RSSI maior ou igual do que SX, o monitor local envia

uma mensagem para SX informando que ele não deve capturar os pacotes de A. Porém,

se SY estiver recebendo o sinal de A com RSSI menor do que SX, o monitor local envia

uma mensagem para SX capturar os pacotes de A e envia uma mensagem para SY parar

de capturar os pacotes de A.

Com a utilização do mecanismo de eleição proposto, apenas um sniffer captura

os pacotes enviados por um determinado nó da rede alvo, reduzindo assim a transmissão

de pacotes capturados através da rede de monitoramento e, consequentemente,

reduzindo o consumo de energia desta rede. Conforme demonstrado nos resultados

(Seção 3.2), o mecanismo proposto, embora simples, reduz consideravelmente o

consumo de energia da rede de monitoramento.

Neste trabalho, a rede de monitoramento utiliza como sniffers nós da plataforma

MicaZ, desenvolvida pela Crossbow Technology. Esta plataforma foi escolhida por ser

muito utilizada em aplicações de RSSF de uma maneira geral e por ser utilizada em

outros trabalhos de RSSF [Cavalcante et al. 2012, Garcia et al. 2013] do grupo de

pesquisa ao qual este trabalho está vinculado. A aplicação embarcada nos sniffers foi

desenvolvida utilizando a linguagem de programação nesC (network embedded system

C) e executa sobre o sistema operacional TinyOS.

2.2. Captura de Pacotes

Após a execução do mecanismo de eleição detalhado na Seção 2.1, os sniffers iniciam a

captura de pacotes, onde cada sniffer captura em modo promíscuo os pacotes enviados

pelos nós da rede alvo que ele monitora, e que foram selecionados pelo mecanismo de

eleição. Para cada pacote capturado, o sniffer gera uma mensagem de monitoramento

contendo o seu endereço (sniffer address), uma marca de tempo (timestamp) e os bytes

do pacote capturado. Esta mensagem de monitoramento é enviada para o monitor local

através da rede de monitoramento utilizando roteamento em múltiplos saltos.


6

O formato do pacote enviado pelo sniffer é mostrado na Figura 3. O cabeçalho

(header) é inserido pelo protocolo da camada de enlace da plataforma MicaZ e tem

tamanho fixo de 05 bytes, e a área de dados (payload) transporta a mensagem de

monitoramento. O tamanho máximo do payload na plataforma MicaZ é de 29 bytes e,

portanto, caso a quantidade de bytes da mensagem de monitoramento seja maior do que

este valor, é necessário que o sniffer envie mais de um pacote para o monitor local.

Figura 3. Formato do pacote enviado pelos sniffers.

2.3. Geração e Análise do Trace

A camada geração do trace é executada pelos monitores locais e foi implementada

utilizando a linguagem de programação Java, por ser uma tecnologia multiplataforma e

possibilitar que o mesmo código execute em diferentes sistemas operacionais (Linux,

Windows, etc.). Os monitores locais recebem as mensagens de monitoramento enviadas

pelos sniffers contendo os pacotes capturados da rede alvo e inserem os pacotes

capturados em um arquivo de trace (banco de dados) localizado no Servidor. O servidor

de banco de dados “MySQL Server 5.5” [MySQL 2013] é utilizado neste trabalho por

ser um sistema de gerenciamento de banco de dados bastante difundido e ser um

software livre com licença GPL (General Public License).

A camada análise do trace executa no servidor (vide Figura 2) e tem como

principal função extrair informações sobre a rede alvo a partir do trace gerado pelos

monitores locais. Para tanto, inicialmente, os pacotes redundantes que existem no trace

são excluídos. Na plataforma MicaZ, os pacotes redundantes podem ser detectados

analisando-se o campo DSN (Destination Sequence Number) presente no header

(cabeçalho) dos pacotes enviados pelos nós sensores. O DSN possui tamanho de oito

bits e é incrementado pelo nó de origem a cada pacote enviado. Quando o DSN atinge o

valor de 255, o DSN do próximo pacote enviado pelo nó sensor terá valor zero

[Crossbow 2013]. Portanto, se dois ou mais pacotes possuem o mesmo endereço de

origem, o mesmo DSN e a diferença entre seus timestamps é menor do que Δt, significa

que se trata do mesmo pacote. Neste trabalho, estamos considerando Δt igual a 10

segundos, pois na nossa implementação um determinado nó sensor não envia mais do

que 255 pacotes neste intervalo de tempo. Após a exclusão dos pacotes redundantes, o

trace é analisado para se extrair diversas informações sobre os nós e sobre os paths da

rede alvo. Em seguida, estas informações são gravadas na MIB. As informações que

podem ser obtidas a partir do monitoramento da rede alvo são descritas na Seção 2.4.

Esta camada foi implementada utilizando a linguagem de programação Java.

2.4. Agente SNMP

O agente SNMP é responsável por acessar as informações de monitoramento

armazenadas na MIB e repassá-las para a ferramenta de gerência através de mensagens

do protocolo SNMP. Desta forma, qualquer ferramenta de gerência que utilize o

protocolo SNMP, como, por exemplo, Nagios [Nagios 2013] e SNMP MIB Browser

Android Tool [Manage Engine 2013], pode se comunicar com o agente SNMP e exibir

as informações obtidas a partir do monitoramento da rede alvo.


7

Um agente SNMP lê e armazena as informações de gerenciamento em uma

MIB, que é uma estrutura de dados que armazena objetos gerenciados cujos valores,

coletivamente, refletem o estado atual dos dispositivos que estão sendo gerenciados.

Esses valores podem ser consultados e/ou alterados por uma ferramenta de gerência

através do envio de mensagens SNMP ao agente. Na MIB os objetos são nomeados

hierarquicamente, de modo que qualquer nó da árvore pode ser identificado pela

sequência de nomes (ou números) que especificam o trajeto da raiz até o nó.

A MIB mais utilizada é definida pela RFC 1213 [McCloghrie and Rose 1991].

Conforme mostrado na Figura 4, sob o nó Internet desta MIB destacam-se as subárvores

management, private e experimental. Sob o nó management encontra-se a definição dos

módulos MIB padronizados pela IETF (Internet Engineering Task Force). Sob o nó

private encontram-se a definição de objetos de empresas registradas na IETF. Sob o nó

experimental poderão ser nomeados objetos que estão em fase de desenvolvimento e

testes. Portanto, a MIB do EPMOSt foi definida sob o nó experimental.

Figura 4. MIB do EPMOSt.

A MIB do EPMOSt possui quatro tabelas: nodesTable, que armazena

informações sobre os nós da rede alvo; pathTable, que armazena informações sobre os

paths da rede alvo; monitorNetworkTable armazena informações estatísticas sobre a

rede de monitoramento; e snifferTable para armazenamento de informações sobre cada

um dos sniffers. Esta MIB possui também dois objetos escalares: nodeCount, que

representa a quantidade de nós da rede alvo; e snifferCount, que representa a quantidade

de sniffers. Os objetos gerenciados definidos em nodesTable e pathTable são descritos

na Tabela 1 e foram capturados em trabalhos que descrevem MIBs para RSSF [Jacquot

et al. 2009, Zhang and Li 2009, Xu et al. 2011, Ye et al. 2011].

O agente SNMP foi desenvolvido utilizando o framework “WebNMS SNMP

Agent Toolkit Java Edition” [WebNMS 2013]. Este framework possibilita o

desenvolvimento rápido de agentes SNMP baseados em Java. Para testar e validar o

agente foi utilizada a ferramenta de gerência "SNMP MIB Browser Android Tool"

[Manage Engine 2013], cuja principal funcionalidade é prover a comunicação com os

agentes, através do envio de mensagens do protocolo SNMP, para consultar e/ou alterar

os objetos de uma MIB. Esta ferramenta foi instalada em um smartphone com sistema

operacional Android e foram realizadas consultas em todos os objetos da MIB do

EPMOSt. Todas as consultas foram realizadas com sucesso.


8

Tabela 1. Objetos representados nas tabelas nodesTable e pathTable.

Tabela da MIB Nome do objeto Descrição do objeto

nodesTable

nodeId Endereço do nó da rede alvo timeAwake Tempo (segundos) em que o nó está ativo

lastSeq DSN do último pacote enviado pelo nó

lastTimestamp Marca de tempo do último pacote enviado pelo nó

sendPacketNode Quantidade de pacotes enviados pelo nó

recvPacketNode Quantidade de pacotes recebidos pelo nó

sendDataPacket Quantidade de pacotes de dados enviados pelo nó

recvDataPacket Quantidade de pacotes de dados recebidos pelo nó

sendBytesNode Quantidade de bytes enviados pelo nó

recvBytesNode Quantidade de bytes recebidos pelo nó

pathTable

pathId Path no formato origem→destino

srcNode Endereço do nó de origem do path

dstNode Endereço do nó de destino do path sendPacketPath Quantidade de pacotes enviados no path

sendBytesPath Quantidade de bytes enviados no path

timeBeginning Marca de tempo do primeiro pacote enviado no path

timeEnding Marca de tempo do último pacote enviado no path

As Figuras 5, 6 e 7 exemplificam o funcionamento desta ferramenta de gerência.

A Figura 5 mostra a estrutura da MIB do EPMOSt. Ao clicar em nodesTable na tela

mostrada na Figura 5, o usuário visualiza os nós da rede alvo (Figura 6). Ao clicar sobre

um determinado nó na tela mostrada na Figura 6, o usuário visualiza as informações

referentes a este nó (Figura 7).

Figura 5. Exibição da MIB do EPMOSt.

Figura 6. Exibição dos nós da rede alvo.

Figura 7. Exibição das informações do nó 0.

3. Novos Experimentos

Os experimentos foram realizados utilizando nós MicaZ com sistema operacional

TinyOS. A plataforma MicaZ possui como principais características: microprocessador

ATMEGA128L, 4KB de memória RAM, 128KB de memória ROM e transceptor de

rádio frequência CC2420. O rádio CC2420 opera na faixa de frequência de 2,4 GHz

com taxa de transmissão de 250 Kbps [Crossbow 2013].


9

3.1. Descrição

A Figura 8 ilustra um exemplo de cenário utilizado para a realização dos experimentos.

A rede alvo é composta por 22 nós, sendo 21 nós sensores e 01 nó sorvedouro. Os nós

sensores executam uma aplicação que a cada minuto mede a temperatura do ambiente e

envia a informação para o nó sorvedouro. A área de dados (payload) dos pacotes

enviados pelo nó sensor contém a temperatura medida e um contador que é

incrementado a cada medição de temperatura. A rede de monitoramento é composta por

N sniffers e uma estação base. Os sniffers capturam os pacotes enviados pelos nós da

rede alvo e enviam para a estação base. A estação base envia os pacotes recebidos dos

sniffers, através de um cabo USB, para um computador. Neste cenário, o computador

desempenha as funções do monitor local (geração do trace) e do servidor mostrados na

Figura 1.

Figura 8. Cenário utilizado nos experimentos.

Foram realizados experimentos com N sniffers distribuídos na área monitorada.

Para cada valor de N (3, 5, 7, 9 e 11), dois tipos de experimentos foram realizados:

“com eleição" e “sem eleição”. No experimento “com eleição”, os sniffers executam o

mecanismo de eleição proposto na Seção 2.1. No experimento “sem eleição”, os

sniffers não possuem nenhum mecanismo de eleição e capturam todos os pacotes dos

nós da rede alvo que estão na área de cobertura dos seus rádios. Vale ressaltar que esta é

a estratégia de captura utilizada por todos os sistemas de monitoramento descritos na

Seção 4 (SNTS, SNIF, Pimoto, LiveNet e PMSW).

Para a avaliação dos experimentos foram definidas as seguintes métricas:

porcentagem de pacotes distintos capturados pela rede de monitoramento

(%PCapturados), energia consumida pela rede de monitoramento na transmissão dos

pacotes capturados (Et), e energia média consumida por cada sniffer na transmissão dos

pacotes capturados (EtSniffer).

A quantidade total de pacotes enviados pelos nós sensores da rede alvo

(PenvAlvo) é obtida através da Equação 1, onde contMediçãoIniciali e

contMediçãoFinali são, respectivamente, o número da primeira e da última medição de

temperatura realizada pelo nó i, e k representa a quantidade de nós da rede alvo. No

cenário utilizado nestes experimentos, o valor de k é 21.

(1)


10

A quantidade de pacotes distintos do nó i capturados pela rede de

monitoramento (Pcapturadosi) é determinada verificando-se quais pacotes do nó i

existem no intervalo [contMediçãoIniciali, contMediçãoFinali]. Logo, a quantidade total

de pacotes distintos capturados (Pcapturados) é obtida através da Equação 2 e a

porcentagem de pacotes distintos capturados pela rede de monitoramento

(%PCapturados) é determinada pela Equação 3.

(2)

(3)

Conforme explicado na Seção 2.3, a quantidade de pacotes redundantes do nó i

(Predundantesi) é determinada analisando-se o campo DSN e o timestamp dos pacotes

enviados pelo nó. Logo, a quantidade total de pacotes redundantes capturados pela rede

de monitoramento (Predundantes) é obtida através da Equação 4.

(4)

Para calcular a energia consumida pela rede de monitoramento na transmissão

dos pacotes foi utilizado o modelo de energia para sensores MicaZ definido em [Jurdak

et al. 2008] e utilizado em [Garcia et al. 2013]. Neste modelo, a energia consumida na

transmissão (Et) é determinada pela Equação 5, onde Psent é a quantidade de pacotes

enviados, Plength é o tamanho do pacote em bytes, TB é o tempo gasto na transmissão

de um byte, It é o valor da corrente elétrica no modo de transmissão e V é a tensão

elétrica da bateria.

(5)

A quantidade de pacotes enviados pelos sniffers é determinada pela Equação 6.

Os valores utilizados para TB, It e V foram 32 µS, 17.4 mA e 3 Volts, respectivamente.

Estes valores foram obtidos no documento de especificação da plataforma MicaZ

[Crossbow 2013]. Nos experimentos realizados, cada pacote enviado pelos sniffers tem

tamanho (Plength) de 23 bytes, sendo 05 bytes de header e 18 bytes da mensagem de

monitoramento (vide Figura 3). Substituindo-se estes valores e a Equação 6 na Equação

5, obtém-se a Equação 7.

(6)

(7)

A energia média consumida por cada sniffer na transmissão dos pacotes

capturados (EtSniffer) é determinada pela Equação 8, onde N é a quantidade de sniffers.

(8)

3.2. Resultados e Discussão

Para cada valor de N (quantidade de sniffers) e para cada tipo de experimento (“com

eleição” e “sem eleição”) foram realizados 10 experimentos com duração de 15

minutos. Todos os experimentos foram realizados no mesmo ambiente e sob as mesmas


11

condições. Os resultados mostrados nos gráficos das Figuras 9 a 11 referem-se aos

valores médios dos 10 experimentos realizados com intervalo de confiança de 95%.

Figura 9. Energia consumida pela rede de monitoramento X quantidade de sniffers.

Figura 10. Energia consumida por cada sniffer X quantidade de sniffers.

Figura 11. Pacotes capturados pela rede de monitoramento X quantidade de sniffers.

A Figura 9 mostra a energia consumida pela rede de monitoramento em função

da quantidade de sniffers. Pode-se observar que quando o mecanismo de eleição não é

utilizado, a energia consumida pela rede de monitoramento aumenta quando a

quantidade de sniffers aumenta. Isto acontece porque os pacotes enviados por um

determinado nó da rede alvo são capturados por uma quantidade maior de sniffers,


12

aumentando assim a quantidade de pacotes redundantes capturados e,

consequentemente, aumentando o consumo de energia da rede de monitoramento na

transmissão destes pacotes. Quando o mecanismo de eleição é utilizado, o consumo de

energia da rede de monitoramento permanece quase constante, pois quando a

quantidade de sniffers aumenta cada sniffer captura pacotes de uma quantidade menor

de nós da rede alvo, mas a quantidade total de pacotes enviados pela rede de

monitoramento quase não sofre alterações. Pode-se perceber ainda na Figura 9 que, para

11 sniffers, a energia consumida pela rede de monitoramento é de 38,4 mJ quando o

mecanismo de eleição não é utilizado. Ao utilizar o mecanismo de eleição, o consumo

de energia é de apenas 11,8 mJ, que corresponde a uma redução de 69,3%. Esta redução

no consumo de energia deve-se ao fato de que a utilização do mecanismo de eleição

reduz significativamente a quantidade de pacotes redundantes transmitidos pelos

sniffers. Estes resultados comprovam a eficiência energética do EPMOSt.

A Figura 10 mostra a energia média consumida por cada sniffer na transmissão

dos pacotes capturados em função da quantidade de sniffers. Pode-se observar que, para

os dois tipos de experimentos, quando a quantidade de sniffers aumenta ocorre uma

redução da energia consumida por cada sniffer. Isto acontece porque cada sniffer

captura pacotes de uma quantidade menor de nós da rede alvo. Pode-se observar

também que a utilização do mecanismo de eleição reduz consideravelmente o consumo

de energia dos sniffers.

A Figura 11 mostra a porcentagem de pacotes distintos capturados pela rede de

monitoramento em função da quantidade de sniffers. Pode-se observar que, para os dois

tipos de experimentos, quando a quantidade de sniffers aumenta, a porcentagem de

pacotes capturados também aumenta. Isto acontece porque os sniffers ficam mais

próximos dos nós da rede alvo e, portanto, recebem os sinais de rádio com maior nível

de potência (RSSI). Pode-se perceber ainda que quando não é utilizado o mecanismo de

eleição, a porcentagem de pacotes capturados é um pouco maior do que nos

experimentos que utilizam o mecanismo de eleição, pois o mesmo pacote pode ser

capturado por mais de um sniffer, aumentando assim a probabilidade de capturá-lo. No

entanto, esta diferença entre os pacotes capturados reduz com o aumento da quantidade

de sniffers e é de apenas 0,62% com 11 sniffers.

Os resultados apresentados nesta seção demonstram que o EPMOSt, quando

comparado com os sistemas de monitoramento descritos na Seção 4 (que não utilizam

nenhum mecanismo de eleição de sniffers), reduz consideravelmente o consumo de

energia da rede de monitoramento e mantém a porcentagem de pacotes capturados

próxima aos valores obtidos sem a utilização do mecanismo de eleição. Estes resultados

comprovam a viabilidade de se utilizar o EPMOSt quando se deseja monitorar

continuamente uma RSSF em um cenário real.

4. Trabalhos Relacionados

No SNTS (Sensor Network Troubleshooting Suite) [Khan et al. 2007], os

pacotes capturados pelos sniffers são armazenados em uma memória flash. Após o

período de captura dos dados, os sniffers são manualmente recolhidos e os registros dos

pacotes capturados são transferidos para um computador, onde são analisados. As

informações obtidas a partir dos pacotes capturados são exibidas em uma ferramenta


13

desenvolvida pelos autores. Entretanto, torna-se inviável utilizar o SNTS para monitorar

RSSF implantadas em cenários reais em que seja impraticável recolher os sniffers,

como, por exemplo, aplicações militares ou aplicações para monitoramento ambiental.

No SNIF (Sensor Network Inspection Framework) [Ringwald and Romer 2007],

cada sniffer possui duas interfaces de rádio, sendo uma usada para capturar os pacotes

enviados pelos nós da rede alvo e outra para enviar os pacotes capturados para o nó

sorvedouro (e.g., um computador) através da rede de monitoramento. Os pacotes

capturados pelos sniffers são marcados com uma marca de tempo (timestamp) e

encaminhados até o sorvedouro, onde os pacotes redundantes são removidos. Em

seguida, os pacotes são analisados e as informações obtidas a partir do monitoramento

são mostradas em uma ferramenta desenvolvida pelos autores.

No Pimoto [Awad et al. 2008], a rede alvo é subdividida em ilhas de

monitoramento. Em cada ilha é implantado um sniffer, que é responsável por capturar

os pacotes enviados pelos nós da rede alvo da sua ilha e enviá-los para seu gateway

(computador) usando um rádio Bluetooth. O gateway inclui em cada pacote capturado o

timestamp e o endereço do sniffer e, em seguida, envia os pacotes capturados para um

servidor. O servidor analisa e mostra os pacotes capturados na ferramenta de análise de

tráfego Wireshark utilizando um plugin desenvolvido pelos autores. No Pimoto, os

pacotes capturados podem ser visualizados no Wireshark, porém toda a análise dos

pacotes deve ser realizada pelo usuário. Além disso, a utilização do Pimoto pode ser

inviável para RSSF com muitos nós distribuídos em uma área geográfica grande, pois é

necessária uma infraestrutura composta por vários gateways interligados ao servidor.

No LiveNet [Chen et al. 2008], os pacotes capturados pelos sniffers podem ser

armazenados em uma memória flash ou enviados para um computador através da porta

serial para futuras análises. No computador, os pacotes capturados são analisados para

obter informações sobre o comportamento da rede alvo. No entanto, torna-se inviável

utilizar o LiveNet para monitorar RSSF implantadas em cenários em que seja

impraticável recolher os dados armazenados nas memórias flash dos sniffers ou enviar

os dados coletados pelos sniffers através de uma rede cabeada, como, por exemplo,

aplicações militares ou aplicações para monitoramento ambiental.

No PMSW (a Passive Monitoring System in Wireless sensor networks) [Xu et al.

2011], cada sniffer captura em modo promíscuo os pacotes de dados e ACK dos nós da

rede alvo que estão na sua área de cobertura e envia os pacotes capturados para o seu

gateway (computador). Ao receber os pacotes capturados por seus sniffers, o gateway

cria um arquivo de trace local. Cada registro deste trace contém as informações de um

pacote e um timestamp baseado no relógio do gateway. Em seguida, cada gateway envia

o trace gerado para o servidor. O servidor recebe os traces gerados por todos os

gateways e gera um trace global sem os registros redundantes. Em seguida, é realizada a

análise do trace com o intuito de avaliar o desempenho e detectar eventuais falhas da

rede alvo. As informações obtidas a partir desta análise são exibidas em uma ferramenta

desenvolvida pelos autores. No PMSW, pacotes de controle, tais como pacotes de

roteamento e de eleição de cluster, não são capturados nem analisados.

Em [Garcia et al. 2013], nós propusemos uma versão simplificada do sistema de

monitoramento passivo para RSSF que está sendo evoluído neste artigo. Além disso,

nós realizamos uma análise comparativa entre os sistemas de monitoramento SNTS,


14

SNIF, Pimoto, LiveNet e PMSW, e constatamos que nenhum destes sistemas é

energeticamente eficiente, ou seja, preocupa-se em minimizar o consumo de energia dos

sniffers. Verificamos ainda que nenhum destes sistemas disponibiliza as informações

obtidas com o monitoramento através de um agente SNMP.

5. Conclusões e Trabalhos Futuros

Neste trabalho, é evoluído um sistema de monitoramento passivo para RSSF,

denominado EPMOSt, que reduz o consumo de energia da rede de monitoramento e

disponibiliza as informações obtidas com o monitoramento através de um agente

SNMP. Todos os módulos do EPMOSt foram descritos e validados. Experimentos reais

foram realizados na plataforma MicaZ e os resultados demonstraram que o mecanismo

de eleição utilizado no nosso sistema reduz em até 69,3% (11 sniffers) a energia

consumida pelos sniffers para a transmissão dos pacotes capturados. Entretanto, apesar

do mecanismo de eleição proposto alcançar uma taxa de pacotes capturados

ligeiramente menor, esta taxa aumenta com o aumento da quantidade de sniffers e

apresenta uma redução de apenas 0,62% quando a rede de monitoramento possui 11

sniffers. Portanto, os resultados dos experimentos realizados comprovam a viabilidade

de se utilizar o EPMOSt para monitorar RSSF em cenários reais, pois a redução do

consumo de energia da rede de monitoramento contribui para prolongar o tempo de vida

desta rede. Foi demonstrado também que o agente SNMP desenvolvido neste trabalho

permite integrar o EPMOSt com ferramentas de gerência que suportem o protocolo

SNMP, facilitando a administração da RSSF monitorada.

As contribuições apresentadas neste trabalho trazem perspectivas interessantes

para futuras pesquisas. Destacamos três direções principais. Primeiramente, nós

pretendemos alterar o mecanismo de eleição para levar em consideração, além da

potência do sinal recebido (RSSI), a qualidade do enlace (LQI - Link Quality Indicator),

o nível de energia da bateria dos sniffers e a quantidade de nós monitorados por cada

sniffer, com o objetivo de balancear o consumo de energia dos sniffers e evitar que

alguns sniffers tenham sua energia esgotada bem antes de outros. Em seguida, nós

pretendemos realizar novos experimentos para avaliar os tempos de vida da rede de

monitoramento e da rede alvo. Finalmente, nós utilizaremos um simulador de rede para

simular o funcionamento do sistema proposto em uma rede com uma maior densidade,

com o intuito de avaliar sua escalabilidade.

Agradecimentos

Este trabalho é um resultado parcial do projeto UbiStructure financiado pelo CNPq

(MCT / CNPq 14/2011 - Universal) sob o número de protocolo 481417/2011-7.

Referências

Awad, A., Nebel, R., German, R. and Dressler, F. (2008) “On the need for passive

monitoring in sensor networks” In: IEEE Euromicro Conference on Digital System

Design Architectures, Methods and Tools.

Borges Neto, J. B., Ribeiro Neto, P. F., Andrade, R. M. C. (2010) “Wireless Sensor

Networks Advances for Ubiquitous Computing” In: Designing Solutions-Based

Ubiquitous and Pervasive Computing: IGI Global, pp. 175–189.


15

Cavalcante, M. T., Garcia, F. P., Andrade, R. M. C. (2012) “Avaliação de Desempenho de

Mecanismos de Segurança para Redes de Sensores Sem Fio” In: XXX Simpósio

Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC), pp. 277-290.

Chen, B. R., Peterson, G., Mainland, G. and Welsh, M. (2008) “LiveNet: using passive

monitoring to reconstruct sensor network dynamics” In: Distributed Computing in

Sensor Systems, pp. 79-98.

Crossbow (2013) “MPR-MIB Users Manual - Crossbow Technology“, http://www-

db.ics.uci.edu/pages/research/quasar/MPR-MIB%20Series%20User%20Manual%

207430-0021-06_A.pdf, Novembro.

Garcia, F. P., Souza, J. N., Andrade, R. M. C. (2013) "Sistemas de monitoramento passivo

para RSSF – soluções existentes e uma nova proposta energeticamente eficiente" In:

XXXI Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC),

pp. 179–192.

Jacquot, A., Chanet, J., Mean Hou, K., Diao, X. and Li, Jian-Jin. (2009) “LiveNCM : A new

wireless management tool” In: 9th IEEE AFRICON, pp. 1–6.

Jurdak, R., Ruzzelli, A. G. and O'Hare, G. (2008) “Adaptive radio modes in sensor

networks: How deep to sleep?” In: IEEE Communications Society Conference on Ad

Hoc and Sensor Networks, pp. 386-394.

Khan. M. M. H., Luo, L., Huang, C. and Abdelzaher, T. (2007) “SNTS: sensor network

troubleshooting suite” In: 3rd IEEE International Conference on Distributed Computing

in Sensor Systems, Springer, Berlin.

Manage Engine (2013) "SNMP MIB Browser Android Tool",

http://www.manageengine.com/free-snmp-mibbrowser-android, Novembro.

McCloghrie, K., Rose, M. (1991) “Management Information Base for Network

Management of TCP/IP-based internets: MIB-II. RFC 1213”, pp. 1–70.

MySQL (2013) “MySQL”, http://mysql.org. Novembro.

Nagios (2013) "Nagios", http://www.nagios.org, Novembro.

Ringwald, M. and Romer, K. (2007) “Deployment of sensor networks: problems and

passive Inspection” In: Proceedings of the 5th Workshop on Intelligent Solutions in

Embedded Systems, IEEE, New York.

WebNMS (2013) “WebNMS SNMP Agent Toolkit Java Edition“,

http://www.webnms.com/javaagent, Outubro.

Xu, X., Wan, J., Zhang, W., Tong, C. and Wu C. (2011) “PMSW: a passive monitoring

system in wireless sensor networks” In: International Journal of Network Management,

vol. 21, pp. 300-325.

Ye, J., Zhao, Z., Li, H. and Chen, H. (2011) “Hierachical heterogeneous wireless sensor

network management system” In: IEEE Conference on Wireless Communications and

Signal Processing (WCSP), pp. 1–5.

Zhang, B. and Li, G. (2009) “Survey of network management protocols in wireless sensor

network” In: IEEE Conference on E-Business and Information System Security, pp. 1–5.


16

http://mysql.org/

ACRoMa - An Architecture of Cooperative Routing

Management in Wireless Mesh Networks

Vinicius C. M. Borges1, Marilia Curado2, Edmundo Monteiro2

1Institute of Informatic (INF)

Federal University of Goiás (UFG)

Goiânia – Brazil

2Laboratory of Communications and Telematics, Center for Informatics and Systems

University of Coimbra

Polo II, 3030-290 Coimbra, Portugal

{vinicius}@inf.ufg.br, {marilia,edmundo}@dei.uc.pt

Abstract. Wireless Mesh Networks (WMN) provide a wireless backbone for ubi-

quitous Internet access and are being challenged to improve their management

to support various kinds of scalable multimedia applications. This paper sets

out an Architecture of Cooperative Routing Management (ACRoMa) for scal-

able triple play service in WMN. A simulation study has been carried out to

assess the performance of ACRoMA with different configuration matrices. The

results provide evidence that by combining an efficient clustering and load bal-

ancing mechanism with a cross-layer routing metric aware of link quality, AC-

RoMa improves the traffic performance in the presence of challenging traffic

patterns, such as triple play services.

Resumo. Redes em Malha Sem Fio (RMSF) fornecem um backbone sem fio

para acesso ubíquo à Internet e estão sendo desafiados a melhorar seu geren-

ciamento para suportar vários tipos de aplicações multimídia de forma escal-

ável. Este trabalho apresenta um arquitetura de gerenciamento chamada Ar-

chitecture of Cooperative Routing Management (ACRoMa) para serviços triple

play em RMSF. Um estudo de simulação foi realizado para avaliar o desem-

penho dos ACRoMa com diferentes matrizes de configuração. Os resultados

fornecem evidência de que através da combinação de um agrupamento eficiente,

um mecanismo de balanceamento de carga e uma métrica de roteamento cross-

layer ciente da qualidade do link, ACRoMa melhora o desempenho do tráfego

na presença de padrões de tráfego desafiadores, tais como serviços triple play.

1. Introduction

Although Wireless Mesh Networks (WMN) [Akyldiz et al. 2005] are not subject to the

traditional restrictions of more traditional ad hoc networks (e.g. energy and processing

capacity), they have mainly employed the IEEE 802.11a/b/g standards as a form of wire-

less technology which results in a restricted wireless link capacity (e.g. a limited number

of non-overlapping channels). The wireless backbone constitutes the main component of

the WMN structure, as it comprises mesh routers and gateways and multi-hop paths are


17

formed through the mesh routers towards the gateways. Access to and from the Internet is

processed through the gateways, which can become bottlenecks. Moreover, WMN seeks

to support services that requires suitable Quality of Service (QoS) levels, e.g. triple play

services. Triple play services [Ekling et al. 2007] combines voice, video and data applic-

ations in a single access subscription (service providers). The provision of these services

is a challenging task for WMN, since it is difficult to manage the limited resources effect-

ively, so that they can support the service assurance needed by these kinds of services.

Scalability is a critical management issue in WMN, as it seeks to handle grow-

ing amounts of traffic load, as well as an increasing number of network elements, while

providing suitable QoS levels. In this context, setting up a routing path in a large wireless

network may take a long time, and the end-to-end delay may be unsuitable for delay-

sensitive applications. Furthermore, it should be pointed out that the low-cost solutions

provided by these networks make it easier to increase the size of the WMN and enable

it to cover larger areas. In light of this, the dynamic routing process has become one of

the most useful mechanisms to complement the current wireless technologies (e.g. cog-

nitive radio, Multiple-Input Multiple-Output (MIMO) and Long Term Evolution (LTE))

and thus support the requirements of multimedia applications. The routing process com-

prises routing algorithms, protocols and metrics that allow computation of the best routes

in the network. Moreover, it offers a more complete performance optimization of the

wireless medium without additional deployment costs and thus results in an autonomic

and synergetic management of WMN.

The main purpose of this paper is to present a research work which has been un-

dertaken by means of an architecture for cooperative routing management, called Archi-

tecture of Cooperative Routing Management (ACRoMa), that can address the scalability

issue of the application traffic in WMN; it comprises a clustering load balancing routing

schema and a cross-layer routing metric. The specific goals of this paper are twofold.

First, the paper outlines the main components of the architecture as well as their interac-

tions and synergies. Second, there is an analysis of the performance evaluation results of

the different mechanisms described, which takes account of tangible scenarios where the

configuration matrix is composed of triple play applications in WMN. To the best of our

knowledge, this paper is the first example of a triple play services performance where the

different load balancing routing methods are compared with different network size and

topologies.

The remainder of the paper is structured as follows: Section 2 discusses the main

open issues to provide a scalable solution in WMN. Section 3 sets out the proposed ar-

chitecture. Section 4 presents the performance evaluation of the main component of the

architecture. Finally, Section 5 describes the conclusions and makes recommendations

for further studies.

2. Open Issues

There has been considerable discussion about ways to improve scalability through the

routing process in emerging network management architectures [Azcorra et al. 2009,

Zhu et al. 2011, Ashraf et al. 2011]. Usually these approaches combine the rout-

ing process with spectrum management [Azcorra et al. 2009], channel assignment

[Zhu et al. 2011] and link breakage assessment [Ashraf et al. 2011]. In other words, most


18

of the solutions found in the literature cause a large overhead and delay in large wireless

networks. To tackle this recognized problem, clustering schemes have been employed

in WMN [Langar et al. 2009, Wu et al. 2014] to improve the management of the routing

decision making process. This is because they increase the scalability of the current rout-

ing protocols in large wireless networks by reducing the routing overhead. This type of

scheme divides the WMN into different kinds of virtual groups, where the nodes are alloc-

ated geographically so that they are adjacent to the same cluster and conform to specific

rules. This means that WMN become self-organized in a modular and virtual topology,

where a cluster consists of a gateway (i.e. clusterhead) and a set of mesh routers in WMN.

Although the clustering schemes improve the performance of routing protocols

in WMN and make easy the WMN management, clustering is not sufficient to achieve

a truly scalable solution when the traffic load increases in the network. This means

that routing decisions that focus on load balancing, play an important role in WMN,

both at the intra-cluster and inter-cluster levels. Intra-cluster load balancing schemes

[Hsiao et al. 2001, Dai and Han 2003, Gálvez and Ruiz 2013] handle the load balancing

locally (i.e. inside a single cluster), by distributing the traffic load among the routing

sub-trees in which the gateway is the root. Nevertheless, intra-cluster routing load balan-

cing can not distribute the traffic load uniformly throughout the whole network, since the

intra-cluster load balancing is restricted by the capacity of the gateway.

The inter-cluster load-balancing deals with load balancing by reducing the cluster

congestion in a holistic perspective, and directing the mesh router traffic towards lightly-

loaded gateways. It thus, improves the overall capacity of the network by cooperating

with each other. Hence, inter-cluster load balancing routing between multiple gateways

is a necessary mechanism to manage the traffic load in WMN in a scalable way. The

inter-cluster load balancing routing is an efficient solution to provide a horizontal cooper-

ation in the network layer between all the mesh nodes that improve the traffic scalability,

where these nodes must have a collective awareness of the traffic load in the adjacent

clusters (i.e. the nodes share the information about the cluster traffic load with each

other). There are some proposed approaches that have been established for the mesh

router migration method, where the Load-Balancing Approach (LBA) [Xie et al. 2008],

Partition-based Load Balancing (PLB) [Choi and Han 2010] and DIffusion Load Balan-

cing (DILB) [He et al. 2009] are the most widely accepted.

LBA, PLB and DILB are based on a load threshold that enables them to decide

whether the inter-cluster routing will occur or not and also to select the lightest adjacent

cluster. LBA is primarily based on the hop count metric to make an inter-cluster decision,

and it does not consider intra-cluster load-balancing. On the other hand, PLB and DILB

take into account a more accurate load metric than LBA, i.e. the number of flows for

each mesh router. Moreover, PLB and DILB perform both intra-cluster and inter-cluster

load balancing routing. DILB extends PLB by taking into account nodes with different

number of wireless interfaces. However, the mesh router migration results in a very slow

traffic migration.

Since the wireless medium is shared, the interference and traffic load are the main

factors that influence the link quality in the wireless links. It is also worth noting that the

traffic load also causes interference (i.e. self-interference) and increases the congestion

in the wireless links. For these reasons, network layer routing awareness of interfer-


19

ence and traffic load is a key enabling tool to optimize the wireless resource, since it

avoids paths with a high interference level and traffic load. In view of this, cross-layer

routing metrics play a key role in measuring interference levels and traffic load using

local information to make a routing decision in a distributed way, while avoiding in-

troducing the excessive overhead that is caused by the measurement and distribution of

this information. The cross-layer design has been employed in WMN to exchange in-

formation between different layers; for instance interference and traffic load are picked

up from the MAC and physical layers to support the routing decision. In this way, the

cross-layer design enables a vertical cooperation in WMN where information from dif-

ferent layers is combined. On the basis of an extensive state-of-the-art analysis, it was

pointed out that the accuracy of the existing cross-layer routing metrics is not sufficiently

accurate to depict the interference and traffic load precisely [Borges et al. 2011], such as

Interference-Load Aware (ILA) [Manikantan Shila and Anjali 2008], Contention-Aware

Transmission Time (CATT) [Genetzakis and Siris 2008] and Contention Window Based

(CWB) [Nguyen et al. 2008].

It is important to stress that, in attempting to improve the scalability of the traffic

applications for WMN without additional costs, previous work has failed to take account

of the integration of a clustering scheme, load balancing routing and cross-layer routing

metrics. This integration improves the overall network performance through the routing

process, by achieving a greater degree of traffic scalability and hence, enabling paths to

be selected that can satisfy the requirements of applications such as VoIP and video, as

well as more complex configuration matrixes including triple play services.

3. ACRoMa - An Architecture of Cooperative Routing Management

ACRoMa integrates the most significant means of managing the routing process in order

to improve the scalability of WMN, allowing a higher degree of traffic performance to be

achieved. Figure 1 describes the architectural model that combines the three components

and allows them to cooperate.

Figure 1. ACRoMa - Architectural Model

It combines the following components: a clustering scheme, load balancing rout-

ing algorithms, and a cross-layer routing metric. When clustering routing scheme, cross-

layer routing metrics and load balancing routing are combined, they can collaborate to

support features such as self-configuration, self-healing and self-optimization and this re-


20

duces the need for human intervention in network management. The specific goals of the

architecture are as follows:

• to enable the best paths to be selected by depicting accurate measures of the link

quality through a cross-layer routing metric.

• to reduce the routing overhead of the traditional routing protocols by using a clus-

tering scheme.

• to avoid overload situations in the gateways through an inter-cluster load balancing

routing algorithm.

ACRoMa employs a bottom-up approach which involves integration and testing;

the components were integrated in an incremental way from lowest level components to

highest level components. In the light of this, each component was tested separately and

then aggregated incrementally. The main synergies between the components are as fol-

lows: the cross-layer routing metric provides information which helps to make link state

routing decisions, the clustering scheme provides a virtual structure that allows an efficent

load balancing, while reducing the routing overhead. Furthermore, each component seeks

to overcome any limitations found in its respective related work. The components and

their interactions will be discussed in the next sub-sections.

3.1. MIND - Cross-layer Routing Metric

The Metric for INterference and channel Diversity (MIND) [Borges et al. 2011] com-

bines measurement that take into account interference and traffic load through accurate

and passive measurements. To reach this, MIND employs a relation between Signal Noise

Ratio (SNR) and Signal to Interference plus Noise Ratio (SINR) as well Channel Busy

Time (CBT) to depict interference and traffic load, respectively. These measurements

can be obtained from MAC and physical layers. MIND regards Channel Busy Time as

a smooth function of multiple weighting through measurement of interference. For this

reason, MIND strikes a combination between interference and load, in which interference

has a higher weight than traffic load. MIND also uses smoothing out functions to avoid

routing instability. For instance, the SINR and CBT measurements are smoothed out

through their respective averages of a set of packets. In addition, they are passive meas-

urements and thus, no additional overhead of the active monitoring mechanisms (e.g.

AdHoc Probing) are required to obtain them. As a result, it cooperates with the clustering

scheme to mitigate the routing overhead and to improve the load balancing. Furthermore,

as was made clear in [Borges et al. 2010], MIND improves the traffic performance of

triple play services in WMN.

3.2. Collaborative Clustering Scheme

The main purpose of the proposed clustering scheme, called Collaborative Clustering

Scheme (CoCluS) [Borges et al. 2010] is to provide a clustering structure that enables

more efficient inter-cluster load balancing routing than mesh router migration method in

PLB [Choi and Han 2010]. In view of this, the drawback in PLB is demonstrated first

and after that, CoCluS is described. Moreover, with clustering, routing decisions become

more precise, due to the smaller scale where cross-layer routing metrics are employed.

CoCluS is described in the next paragraphs.

Figure 2 shows the network model used in the clustering scheme that has been set

out. Mesh routers form a tree-like structure that is used to communicate with the gateway.


21

In this way, the network is partitioned into clusters in which the root is a gateway. Each

mesh router is characterized by its weight which depicts the load level and is usually

represented by the number of active flows. These flows are derived from mesh clients

who attach themselves to the mesh router. The Cumulative Load (CL) is the sum of the

weights of all the nodes in the sub-tree, including the weight of the root. Thus, the CL of

a node is the amount of uplink traffic present on the node. The links between a gateway

and its neighbor nodes are called Top Sub-Links (TSL), and the neighbors that are one

hop from the gateways are called Top Sub-Nodes (TSN). A TSN of an adjacent cluster is

called an adjacent TSN. The overload condition occurs when the CL of TSN exceeds the

defined maximum load threshold. The network is indicated as a matrix m(x, y), where x

is the x-axis index and y is the y-axis index. The numbers in the squares correspond to the

weight of each node. The numbers which are alongside the TSL are the CL in the TSN

sub-tree.

Figure 2. CoCLuS Network Model

First, m(4,4) is migrated (Figure 3), since it is a border node and has one of the

smallest CL. Next, m(4,3) is also migrated (Figure 4) since it is the next border node which

has one of the smallest CL. However, they do not help to improve the load balancing of

the network, since it actually has no traffic load. It should be noted that m(3,4) is a better

candidate to make the load balancing more efficient, but is not yet a border node in Figure

3. Hence, m(3,4) has to wait to become a border node with smallest CL, which occurs

when m(4,4) and m(4,3) migrate to the adjacent cluster (Figure 5). Figure 6 shows the

balanced clusters G1 and G2 after the migration of three mesh routers. It is important to

point out that the clustering structure was modified by the migration process.

It is also important to take note of the messages required by this method. The

messages required by this method are illustrated in Figure 3. The G1 gateway sends the

defection request message (blue arrow) to m(4,4) which then forwards it to m(7,3), the

adjacent TSN. When m(7,3) receives this message, it sends back a defection response

message (red arrow) to the G1 gateway and m(4,4) to confirm the acceptance status of

m(4,4). The defection decision could have been made locally at m(4,4), if the nodes had

had the information about the CL of the TSN in the adjacent clusters. In this case, m(4,4)

would not need to forward the defection request message to m(7,3) and thus, could reduce

the time needed to make the inter-cluster routing decision.

The relay and boundary nodes are new elements of the proposed clustering scheme

which enable an exchange of information (e.g. CL of adjacent clusters) to occur with

the mesh routers belonging to the adjacent clusters, since they are within each other’s

transmission range. As a result, the relay and boundary nodes provide information that

can support the inter-cluster routing decision. Even though the boundary and relay nodes


22

Figure 3. Mesh router migra-tion: Step 1




play a similar role in the traffic migration process, they are described in distinct ways,

depending on the cluster in which the mesh routers are found. For instance, m(4,4) is a

relay node for all the mesh routers in the G1 cluster and a boundary node for all the mesh

routers in the G2 cluster. In other words, a boundary node does not belong to the cluster,

whereas a relay node does.

Although the relay node and its respective boundary node are not in the same

cluster, the relay node receives the CL of the adjacent TSN because the boundary nodes

disseminate this information to their neighbors inside the cluster, as well to the relay

nodes. In this way, the candidate is able to select the lighter adjacent cluster locally.

Hence, the candidate nodes do not need to send a defection request to the adjacent TSN,

since the clustering scheme allows a more proactive migration strategy to start the traffic

migration, which further reduces the time required to start the traffic migration.

CoCluS employs a new hybrid routing scheme which combines two different rout-

ing structures which cooperate with each other to improve the overall network perform-

ance. First, the spanning tree structure (solid line) is used to communicate with the gate-

way (i.e. intra-cluster load balancing routing scheme). The Inner Domain Load Balan-

cing (IDLB) algorithm, proposed in [Choi and Han 2010], is employed as the intra-cluster

load balancing routing algorithm to form the spanning trees rooted at the gateways. Af-

terwards, the nodes calculate the routes to every neighbor (specially for relay and bound-

ary nodes) inside the cluster by means of the Dijkstra routing algorithm and the MIND

cross-layer routing metric (i.e. the link state routing scheme). This latter routing scheme

(dotted line) is necessary to forward data from the defected traffic to the selected relay

nodes (intra-cluster path).


23

3.3. RAILoB - Inter-cluster Load Balancing Routing

The Routing Algorithm for Inter-cluster Load Balancing (RAILoB) [Borges et al. 2012]

approach employs a new traffic migration method, called mesh traffic migration, that

enables the main limitation of the mesh router migration method [Choi and Han 2010] to

be overcome, which is its slowness.

The mesh traffic migration method allows the traffic migration of the selected

mesh routers without the need for mesh router migration (i.e. only traffic application

is migrated). This new method enables candidate nodes to be selected for the traffic

migration in which the candidate is not required to be a border node. The main purpose

of this method is to find a flexible means of reducing the traffic load in the nodes which

are close to the TSN, while keeping control of the number of hops required to reach the

destination. As a result, it is better if the criteria for selecting the candidate nodes are

based on the nodes which are farther away from the gateway in the sub-tree of the TSN

overload. This method has two advantages. First, it avoids links close to the congested

gateway. Second, it increases the likelihood that nodes will be selected that are closer to

the adjacent cluster. By adopting this flexible method, RAILoB can provide agility to the

process of traffic migration and thus, reduce the time needed to carry out the inter-cluster

traffic routing. The mesh traffic migration requires a more complex clustering structure

which is provided by the clustering scheme explained in the previous sub-section.

The complete path consists in the mesh traffic migration of two main sub-paths,

namely, intra-path (the path between the selected node and the relay node, using the link

state routing with MIND) and inter-path (the path between the relay node and the lighter

gateway, using the spanning tree). Figure 7 also shows an example of traffic migration

when RAILoB is employed for the same case.

Figure 7. Mesh traffic migration - Example

There is an overload condition in m(3,2) in Figure 7 (CL with a value of 5), the

G1 gateway chooses m(3,4) for traffic migration and sends it a defection request message

(blue dotted arrow). Next, m(3,4) checks in its routing database and finds m(7,3) (i.e.

TSN that can accept the traffic in m(3,4) without overloading it). Then, m(3,4) sends back

a defection response message (red dotted arrow) and starts to allow the traffic to migrate

(dotted gray arrow) using m(4,4) and m(5,4) as relay and boundary nodes, respectively.

ACRoMa seeks solutions for each of the open issues previously discussed, such

as a clustering solution to reduce the routing overhead, a load balancing routing algorithm

to avoid overload situations at the gateways, and a cross-layer routing metric to improve

the accuracy of the route selection process. It should be pointed out that these solutions


24

are coordinated to increase network scalability (e.g., greater degree of traffic performance

and greater number of nodes) and thus, improve the overall capacity of WMN.

4. Simulation Study

The simulation study outlined in this section aims at throwing light on the ability of

ACRoMa to confirm the hypothesis that it has the potential to achieve a greater de-

gree of traffic performance when a more efficient routing solution is used. For this

reason, a comparison was drawn between RAILoB and the most effective inter-cluster

load balancing routing (i.e. Partition Load Balancing (PLB) [Choi and Han 2010]), since

PLB is the most effective related work on routing and RAILoB represents the AC-

RoMa architecture conceptually by combining all the components. In this section, the

performance evaluation within the NS2 simulator will examine a mixed traffic com-

prising the VoIP, video and FTP applications which configure triple play services. In

this way, we will be able to evaluate the impact of load balancing methods on each

application of these services. Particularly in this paper, we investigate the impact of

the routing approaches on different aspects of WMN, such as network size and dif-

ferent types of network topology. Such evaluation was not taken into consideration in

[Choi and Han 2010, Borges et al. 2010, Borges et al. 2011, Borges et al. 2012].

4.1. Effects of Network Size

The performance evaluation will also assess a triple play service configuration when vary-

ing the network size and the impact of the inter-cluster routing methods on this factor will

be analysed. The scenario configuration and traffic model are outlined in sub-section

4.1.1. The simulation results are examined in sub-section 4.1.2.

4.1.1. Simulation Configuration

Each data point in the graphical results is computed as the average of 10 different simu-

lations and the graphs also show the confidence intervals of the performance parameters

which have a confidence level of 95%. The inter-cluster load-balancing approaches were

implemented in an extended version of the OLSR routing protocol [Ros and Ruiz 2007]

by means of the NS-2, which supports the clustering. All of the nodes have the same

physical configuration. Table 1 shows the configuration of both scenarios used in this

sub-section.

The traffic combination of each application was based on

[Quintero et al. 2004][Kim et al. 2008]. That is, the percentage of flows for VoIP,

FTP and video are 60%, 30% and 10% of the total load, respectively. Thus, a set of

four combinations (two for each network size) of mixed traffic were formed, as shown

in Table 2. Both scenarios have the same traffic proportion by gateway, which makes it

possible to analyze the impact of the network and cluster size on the inter-cluster routing

methods.

The scenario consists of gateway (one for each cluster) and static mesh routers

with multi-channel multi-radio capability, which is typical of outdoor city-wide deploy-

ments. There are two channels and two network interfaces. On each node, one particular

channel is combined with one particular network interface, and no channel assignment


25

Table 1. Scenario Setup

Parameter Value

Simulation Time 300s

Flow Lifetime 275s

Network Sizes 50 and 100

Cluster Sizes 17 and 20

Number of Gateways 3 and 5

Grid Topology Sizes 2000m x 2000m, 2500m x 2500m

Transmission Range 250m

Interference Range 550m

Propagation Model TwoRayGround

Network Interface Cards 2

MAC/PHY Specification IEEE 802.11 b/g

Antenna Omnidirectional

Table 2. Traffic Combination for Triple Play Services for Different Network Sizes

Combinations of Number of Flows Video FTP VoIP

A for 50 Nodes (Low load) 1 4 12

D for 50 Nodes (High load) 4 12 24

A for 100 Nodes (Low load) 3 8 20

D for 100 Nodes (High load) 10 20 40

algorithm has been employed. Furthermore, grid topology is used to limit the maximum

number of neighbours of a mesh router (i.e. four at maximum). The scenario uses a typ-

ical WMN backbone traffic pattern feature, where several flows originated from the source

nodes (i.e. mesh routers) to a destination node (i.e., gateway), and the source nodes were

chosen at random. The gateway is located in the central position [Bejerano et al. 2007].

4.1.2. Simulation Results

Figures 8 and 9 show that the network size has little impact on throughput of video and

VoIP applications, whereas these factors have a signifcant effect on FTP application. For

example, FTP achieves 408,78 Kb/s and 263,84 Kb/s in the highest load D in a network

size of 50 and 100 nodes respectively, when using RAILoB. This can be explained by the

fact that an increase of the network size tends to raise the interference level and traffic

load. The transmission rate control policy of the TCP protocol is very sensitive to the

packet loss rate which rises to the same extent that the interference and traffic load in-

crease.

As expected, figures 10 and 11 shows that network size has greater impact on

delay than throughput for all aplications. The reason being that increasing the network

size also increase the average path length which increases delay in wireless networks.

Nevertheless, the impact is smaller when RAILoB is used for distinct network sizes. Fur-

thermore, when comparing throughput and delay for all load configurations and network

sizes, RAILoB achieves better results. This can be explained by the fact that RAILoB is

more agile and fexible than PLB, while keeping the same cluster structure and therefore,


26

0

200

400

600

800

1000

1200

A D A D A D

Ave

rag

e F

low

Th

rou

gh

pu

t (K

b/s

)

Load Configurations

Network Size

VoIP Video

FTP

RAILoB-50nn RAILoB-100nn

Figure 8. Average FlowThroughput of RAILoB

0

200

400

600

800

1000

1200

A D A D A D

Ave

rag

e F

low

Th

rou

gh

pu

t (K

b/s

)

Load Configurations

Network Size

VoIP Video FTP

PLB-50nn PLB-100nn

Figure 9. Average FlowThroughput of PLB

0

0.5

1

1.5

2

A D A D A D

Ave

rag

e F

low

De

lay (

s)

Load Configurations

Network Size

VoIP Video FTP

RAILoB-50nn RAILoB-100nn

Figure 10. Average Flow Delayof RAILoB

0

0.5

1

1.5

2

A D A D A D

Ave

rag

e F

low

De

lay (

s)

Load Configurations

Network Size

VoIP Video FTP

PLB-50nn PLB-100nn

Figure 11. Average Flow Delayof PLB

the triple play services are able to reach lighter adjacent clusters more quickly and the

overloaded gateways are lightened at a faster rate. As a result, the overall network ca-

pacity is improved since RAILoB deals with growing amounts of traffic load and nodes

better than PLB.

4.2. Effects of Topology Scenario

The effects of topology types on the routing approaches will be investigated in this sub-

section where a triple play service configuration is employed. This sub-section is struc-

tured as follows sub-section 4.2.1 shows the scenario configuration and traffic model. The

simulation results are described in sub-section 4.2.2.

4.2.1. Simulation Configuration

The scenario configuration is very similar to subsection 4.1.1. In addition, the traffic

model is equivalent to that used in subsection 4.1.1. These tests are also used here to

compare random and grid topologies. The amount of traffic is the same for both topology

types. The network parameters of network size, topology size and number of gateways

used from the previous scenario are 50, 2000m x 2000m and 3, respectively.


27

0

200

400

600

800

1000

1200

A D A D A D

Ave

rag

e F

low

Th

rou

gh

pu

t (K

b/s

)

Load Configurations

Topology

VoIP Video

FTP

RAILoB-Grid RAILoB-Random

Figure 12. Average FlowThroughput of RAILoB

0

200

400

600

800

1000

1200

A D A D A D

Ave

rag

e F

low

Th

rou

gh

pu

t (K

b/s

)

Load Configurations

Topology

VoIP Video FTP

PLB-Grid PLB-Random

Figure 13. Average FlowThroughput of PLB

0

0.5

1

1.5

2

A D A D A D

Ave

rag

e F

low

De

lay (

s)

Load Configurations

Topology

VoIP Video FTP

RAILoB-Grid RAILoB-Random

Figure 14. Average Flow Delayof RAILoB

0

0.5

1

1.5

2

A D A D A D

Ave

rag

e F

low

De

lay (

s)

Load Configurations

Topology

VoIP Video FTP

PLB-Grid PLB-Random

Figure 15. Average Flow Delayof PLB

4.2.2. Simulation Results

Figures 12 to 15 show that the topology type does not have a significant effect on the triple

play service. Nevertheless, there are some cases where the traffic performance slightly

increases or decreases in a random topology that depends on the inter-cluster routing

approach. For example, RAILoB achieves a higher improvement of throughput than PLB

for FTP application in low loads, FTP achieves 962,70 Kb/s and 1023,75 Kb/s for grid

and random topologies respectively when RAILoB is used, whereas FTP achieves 337,55

Kb/s and 362,93 Kb/s for grid and random topologies respectively, when PLB is used. The

reason for this is that the random topology can have a varied number of border nodes for

the mesh router migration method (i.e. PLB), including no single border node, since the

node placement is not regular. This means that the traffic performance can be affected by

slow and inflexible load balancing approaches in this specific case. Nonetheless, RAILoB

results in the best traffic performance for most cases, as well as for both of the topology

types.

5. Conclusions and Comments on Future Work

In this article, we have outlined an architecture of cooperative routing management called

ACRoMa, which is mainly concerned with scalability for triple play services. This pro-

posed architecture is able to handle the scalability issue arising from the most relevant

routing approaches by combining a cross-layer routing metric, which proved to improve


28

the performance of the triple play service when making the routing decision, and an

inter-cluster routing method for load balancing that enables the traffic migration to occur

between multiple gateways in a more efficient way. In other words, ACRoMa integrates

solutions to provide traffic scalability in a collaborative fashion for WMN, which are the

cross-layer design metrics, clustering scheme and load balancing routing. Furthermore, it

was evidenced by the results that the chosen approaches for each solution and their syn-

ergies result in a better scalability for triple play services than the concorrent approaches.

For instance, ACRoMa speeds up the load balancing procedure by employing a proactive

and flexible strategy of traffic migration for inter-cluster routing decision-making. Hence,

it was confirmed that the proposed architecture lays down mechanisms that provide scal-

able triple play service in WMN with multiple gateways. As a means of advancing this

research, it is expected that ACRoMa will extend by integrating a cognitive radio solu-

tion.

Acknowledgement

This work was partially funded by the Portuguese Ministry of Science (scholarship

contract SFRH/BD/44378/2008), supported by the iCIS project (CENTRO-07-ST24-

FEDER-002003), co-financed by QREN, in the scope of the Mais Centro Program and

European Union’s FEDER.

References

Akyldiz, I. F., Wang, X., and Wang, W. (2005). Wireless mesh networks: a survey.

Computer Networks, 47(4):445–487.

Ashraf, U., Abdellatif, S., and Juanole, G. (2011). Route maintenance in ieee 802.11

wireless mesh networks. Computer Communications, 34(13):1604 – 1621.

Azcorra, A., Banniza, T., Chieng, D., Fitzpatrick, J., Von-Hugo, D., Natkaniec, M., Rob-

itzsch, S., and Zdarsky, F. (2009). Supporting carrier grade services over wireless mesh

networks: the approach of the european fp-7 strep carmen. Communications Magazine,

IEEE, 47(4):14–16.

Bejerano, Y., Han, S.-J., and Kumar, A. (2007). Efficient load-balancing routing for

wireless mesh networks. Computer Networks, 51(10):2450–2466.

Borges, V. C. M., Curado, M., and Monteiro, E. (2010). A Cross-Layer Routing Scheme

for Scalable Triple Play Service in Wireless Mesh Networks. In Proceedings of the

19th IEEE ICCCN 2010, Zürich, Switzerland, August 2-5, 2010, pages 1–6.

Borges, V. C. M., Curado, M., and Monteiro, E. (2011). Cross-Layer Routing Metrics for

Mesh Networks: Current Status and Research Directions. Computer Communications

Elsevier, 34(6):681 – 703.

Borges, V. C. M., Dimitrov, E., Curado, M., and Monteiro, E. (2012). Performance

Assessment of Cluster Load Balancing Routing Methods for Triple Play Services in

Wireless Mesh Networks. In Proceedings of the 13th IEEE/IFIP NOMS 2012, pages

974–980.

Choi, H.-G. and Han, S.-J. (2010). Domain load balancing routing for multi-gateway

wireless mesh networks. Journal of Wireless Networks. Springer Kluwer Academic

Publishers, 16:2105–2122.


29

Dai, H. and Han, R. (2003). A node-centric load balancing algorithm for wireless sensor

networks. In Global Telecommunications Conference, 2003. GLOBECOM ’03. IEEE,

volume 1, pages 548 – 552 Vol.1.

Ekling, J., Gidlund, M., and Flodin, R. (2007). Performance of triple play services in

wireless meshed networks. ieee isce. pages 1 –5.

Gálvez, J. J. and Ruiz, P. M. (2013). Efficient Rate allocation, Routing and Channel

Assignment in Wireless Mesh Networks supporting Dynamic Traffic Flows. Ad Hoc

Networks, 11(6):1765–1781.

Genetzakis, M. and Siris, V. (2008). A contention-aware routing metric for multi-rate

multi-radio mesh networks. In 5th IEEE SECON ’08, pages 242–250.

He, B., Sun, D., and Agrawal, D. (2009). Diffusion based distributed internet gateway

load balancing in a wireless mesh network. In GLOBECOM 2009. IEEE, pages 1 –6.

Hsiao, P.-H., Hwang, A., Kung, H., and Vlah, D. (2001). Load-balancing routing for

wireless access networks. In INFOCOM 2001. Twentieth Annual Joint Conference

of the IEEE Computer and Communications Societies. Proceedings. IEEE, volume 2,

pages 986 –995 vol.2.

Kim, H., Claffy, K., Fomenkov, M., Barman, D., Faloutsos, M., and Lee, K. (2008).

Internet traffic classification demystified: myths, caveats, and the best practices. In

CONEXT ’08: Proceedings of the 2008 ACM CoNEXT Conference, pages 1–12, New

York, NY, USA. ACM.

Langar, R., Bouabdallah, N., and Boutaba, R. (2009). Mobility-aware clustering al-

gorithms with interference constraints in wireless mesh networks. Comput. Netw.,

53(1):25–44.

Manikantan Shila, D. and Anjali, T. (2008). Load aware traffic engineering for mesh

networks. Comput. Commun., 31(7):1460–1469.

Nguyen, L. T., Beuran, R., and Shinoda, Y. (2008). A load-aware routing metric for

wireless mesh networks. In Computers and Communications, 2008. ISCC 2008. IEEE

Symposium on, pages 429–435.

Quintero, A., Elalamy, Y., and Pierre, S. (2004). Performance evaluation of a broadband

wireless access system subjected to heavy load. Computer Communications, 27(9):781

– 791.

Ros, F. J. and Ruiz, P. M. (2007). Cluster-based olsr extensions to reduce control overhead

in mobile ad hoc networks. In Proceedings of IWCMC, pages 202–207, New York, NY,

USA. ACM.

Wu, D., Yang, S.-H., Bao, L., and Liu, C. H. (2014). Joint Multi-radio Multi-channel

Assignment, Scheduling, and Routing in Wireless Mesh Networks. Journal of Wireless

Networks (Springer), 20(1):11 – 24.

Xie, B., Yu, Y., Kumar, A., and Agrawal, D. P. (2008). Load-balanced mesh router mi-

gration for wireless mesh networks. Elsevier Journal of Parallel and Distributed Com-

puting, 68(6):825 – 839.

Zhu, Y., Ma, Q., Bisdikian, C., and Ying, C. (2011). User-centric management of wireless

lans. Network and Service Management, IEEE Transactions on, 8(3):165–175.


30

SMARTFlow: Uma Proposta para a Autoconfiguracao deRedes de Subestacao IEC 61850 Baseada em OpenFlow

Yona Lopes1, Natalia Castro Fernandes2, Carlos Alberto Malcher1

1Laboratorio GTECCOM,2Laboratorio MidiaComDep. de Telecomunicacoes - Universidade Federal Fluminense (UFF)

Abstract. Smart grids depend on a solid foundation of communications.Although standards like IEC 61850 proposes solutions to achieveinteroperability, the auto configuration and the automatic control of thecommunication network are still an open problem. This work proposes anefficient solution for autonomic management and control of communicationnetworks for substations based on IEC 61850. The proposed solution, calledSMARTFlow, uses OpenFlow in order to achieve granularity and flexibilityin the treatment of data flows. SMARTFlow proactively calculates Layer2 multicast trees to forward GOOSE and Sampled Values messages andreconfigures all flow entries in case of network failures. Also, the proposedsystem monitors the network and defines on-demand the configuration ofclient-server flows. The proposal was implemented and tested using Mininetand showed a total load up to 44 % lower than the load using typical switches.The proposal also showed advantages when compared to other multicastsolutions, such as GMRP(GARP Multicast Registration Protocol)

Resumo. As Smart Grids dependem de uma base solida de comunicacao.Apesar de normas como a IEC 61850 apresentarem solucoes para alcancara interoperabilidade, ainda existem problemas em aberto com relacao aautoconfiguracao e ao controle automatizado da rede de comunicacao. Essetrabalho propoe uma solucao eficiente de controle e gerenciamento autonomode redes de comunicacao para subestacoes baseadas na norma IEC 61850. Asolucao proposta, chamada de SMARTFlow,e baseada no uso do OpenFlowpara obter granularidade e flexibilidade no tratamento dos fluxos de dados. OSMARTFlow, pro-ativamente, calcula asarvores multicast de camada 2 paraencaminhamento de mensagens GOOSE e Sampled Values e reconfigura todasas entradas de fluxos em caso de falhas, alem de monitorar a rede, definindosob demanda a configuracao de fluxos cliente-servidor. A proposta foi imple-mentada e testada utilizando o emulador Mininet e apresentou uma carga totalate 44% menor do que a de switches tıpicos. A proposta tambem demostrou van-tagens quando comparada com outras solucoes de multicast, como o GMRP.

1. Introducao

A energia eletrica e essencial para o desenvolvimento da sociedade. A falta de energia,mesmo que por um perıodo curto de tempo, acarreta em prejuızos enormes alem de da-nos causados pela falta de servicos essenciais. Por exemplo, no Brasil, uma auditoriado Tribunal de Contas da Uniao mostrou que os apagoes de 2001 e 2002 causaram umprejuızo de R$ 45,2 bilhoes para os brasileiros1. O responsavel por prover a qualidadedo servico eletrico oferecido aos consumidores, controlando e direcionando o fluxo deenergia e fornecendo energia durante o maior tempo possıvel aos consumidores finais e o

1http://www.correiobraziliense.com.br e http://epocaestadobrasil.wordpress.com


31

Sistema Eletrico de Potencia (SEP), que possui uma infraestrutura complexa para gerar,transmitir e distribuir essa energia. Contudo, o SEP esta sujeito a anormalidades e defei-tos em sua operacao. Para que o impacto das falhas seja reduzido, sistemas de protecao esupervisao sao indispensaveis.

Apesar da importancia do SEP, pouca inovacao tem sido feita nos ultimosanos, e, consequentemente, os equipamentos utilizados e as tecnologias, algumas ve-zes, sao os mesmos de 40 anos atras [Gungor et al. 2011]. Da necessidade inevitavel demodernizacao dos sistemas de automacao do SEP, surgiram asSmart Grids, tornandoimprescindıvel a implantacao de um sistema de comunicacao mais “inteligente” interli-gando os sistemas de protecao e supervisao e os centros de controle [Lopes et al. 2012].Uma das principais normas que especificam essa comunicacao inteligente e a norma IEC61850 [IEC 61850 ]. Apesar da norma IEC 61850 apresentar solucoes para modelagemda comunicacao dentro do SEP e interoperabilidade dos equipamentos, ainda existemproblemas em aberto. A comunicacao de mensagens prioritarias da norma,Sampled Va-lues(SV) e GOOSE, e feita em camada 2 e com o uso demulticast[IEC 61850 ]. Contudo,devido ao comportamento padrao dosswitchesparamulticastde camada 2, essas men-sagens sao enviadas embroadcast. Esse comportamento traz uma sobrecarga tanto pararede quanto para os dispositivos finais que recebem mensagens mesmo nao estando nogrupo [Sivanthi and Goerlitz 2013]. Existem protocolos dinamicos para encaminhamentomulticastde camada 2, como o GMRP (GARP Multicast Registration Protocol), padro-nizado pelo IEEE 802.1D. Porem, essa solucao exige que o protocolo seja implementadonos dispositivos finais, o que ainda nao ocorre em redes IEC 61850.

Outra questao importante e relativa aos sistemas de recuperacao de falhas para re-des de subestacao recomendados pela norma. Esses sistemas garantem a entrega do pacoteduplicando o trafego, ou duplicando todos os dispositivos na rede. Com isso, o trafego narede aumenta, o que pode sobrecarregar os nos da rede , aumentando inclusive o proces-samento dos dispositivos finais, que tem baixo poder de processamento, e passam a pro-cessar o dobro de pacotes. Alem disso, esses sistemas so podem ser usados em topologiasespecıficas e necessitam de implementacao nos dispositivos finais [Tan and Luan 2011].

Esse trabalho visa melhorar o desempenho na comunicacao dentro de subestacoesutilizando de forma eficiente os recursos de rede de comunicacao, alem de autoconfiguraras redes de subestacao IEC 61850. A proposta, chamada de SisteMa Autoconfiguravelpara Redes de Telecomunicacoes IEC 61850 com arcabouco OpenFlow (SMARTFlow),utiliza o OpenFlow [McKeown et al. 2008] para fazer um melhor controle dos dados emtrafego dentro de uma subestacao. Inicialmente, as entradas de fluxos de alta prioridadedefinidos na norma IEC 61850 sao configuradas com base no arquivo de configuracaode subestacao, definido na norma. Essa configuracao e feita pro-ativamente para garan-tir que nao serao inseridos atrasos para as mensagens sensıveis. Para tanto, o SMART-Flow possui um componente que calcula e configura as arvoresmulticastpara encaminha-mento das mensagens de camada 2, evitando o uso dobroadcaste sem a necessidade deimplementacao de protocolos nos dispositivos finais. Foi desenvolvido tambem, um com-ponente para tratamento de falhas, que recalcula as arvores dinamicamente sempre quehouver falhas na rede. Alem disso, o SMARTFlow define um modelo para aplicacao deprioridade nos diferentes tipos de mensagens na rede, garantindo os requisitos de atraso.

O SMARTFlow foi implementado e testado utilizando o controlador POX e o


32

emulador de redes Mininet [Lantz et al. 2010] e se mostrou muito eficiente, atendendo atodos os requisitos das mensagens da norma IEC 61850. O sistema proposto reduziu emate 20 vezes o atraso gerado pelas aplicacoes de controle padrao do POX e apresentouuma carga total ate 44% menor do que a deswitchestıpicos. Os testes foram realizadosconsiderando diferentes configuracoes tıpicas de subestacao, de forma a validar a propostaem termos de atraso e carga de controle.

O restante deste artigo esta organizado da seguinte forma. A Secao 2 apresentauma visao geral da norma IEC 61850 e da comunicacaomulticastde camada 2. Os traba-lhos relacionados sao apresentados na Secao 3. A proposta e apresentada no Capitulo 4 e aSecao 5 apresenta a analise dos resultados experimentais. As conclusoes sao apresentadasna Secao 6.

2. Redes IEC 61850A norma IEC 61850 modela os sistemas e a comunicacao da rede para a automacao noSEP. Seu principal objetivo e garantir interoperabilidade entre dispositivos eletronicosinteligentes (Intelligent Electronic Device(IEDs)) de diferentes fabricantes que permitem,dentre outros, a supervisao, o controle e a protecao em tempo real do SEP.

O modelo de comunicacao da IEC 61850 usa tres diferentes tipos de mensagem:GOOSE e SV com alta restricao temporal, chegando a 3 ms, e MMS (ManufacturingMessage Specification) variando de 100ms ate 1000ms [IEC 61850 ]. As mensagens saoencaminhadas de duas formas, no modelo publicador/assinante com os enderecosmulti-castpadronizados pela norma, e no modelo cliente-servidor. A norma define o modelopublicador/assinante para mensagens GOOSE, e o modelo cliente-servidor para mensa-gens MMS. A SV pode ser enviada nos dois modelos. As mensagens GOOSE e SV saousadas para servicos crıticos na subestacao, por esse motivo sao mapeadas diretamente nacamada 2 a fim de prover um tempo de resposta mais rapido. Com isso, estas mensagenssao diretamente encapsuladas em camada Ethernet e transmitidas com um endereco dedestino MACmulticast[McGhee and Goraj 2010].

A norma padroniza uma linguagem de descricao, chamada de Linguagem deConfiguracao de Subestacao (Substation Configuration Language- SCL), que norteia aconfiguracao do sistema. Isto significa dizer que sao configurados desde os canais decomunicacao ate a alocacao de funcoes para os sistemas de automacao [IEC 61850 ]. ASCL e baseada em XML (eXtensible Markup Language) e seu objetivo principal e pa-dronizar os atributos de configuracao, ou seja, criar uma nomenclatura uniformizada, demaneira a permitir configuracoes de IEDs com maior seguranca e confiabilidade. O in-tuito e manter a interoperabilidade, garantindo a troca de dados entre IEDs independentedo fabricante. Dentre os arquivos de configuracao que compoe a SCL, este artigo ressaltao SCD, pois e este arquivo que descreve detalhadamente a subestacao no que tange acomunicacao. O arquivo SCD contem uma secao de configuracao de comunicacao e umasecao de descricao da subestacao. Desta maneira, este arquivo pode conter, por exemplo,aonde esta alocado cada no logico do sistema, enderecos de rede, enderecos de gruposmulticast, etc.

2.1. Comunicacaomulticast de camada 2 em redes IEC 61850A norma define o uso de gruposmulticastde camada 2 para mensagens GOOSE e SV.Switches, por padrao, quando recebem um pacote enderecado a um destinomulticastde


33

camada 2, enviam este pacote por todas as portas.E esse metodo que garante que o pacotevai chegar ao destino qualquer que seja o destinatario2. Porem, esse metodo consomebanda no enlace, aumenta o atraso nosswitchese introduz uma sobrecarga significativanos IEDs. Para contornar este problema, os fluxos de dadosmulticastdevem ser restritosapenas ao grupo em questao, ou seja, a arvore multicast [McGhee and Goraj 2010].

As arvoresmulticastpodem ser configuradas de forma estatica ou dinamica. Naconfiguracao estatica, o enderecomulticaste mapeado para a porta, ou mais de uma sefor o caso, por onde os pacotes daquele grupo especıfico devem ser encaminhados. Seo estado da rede muda, nao existe uma atualizacao automatica na tabela de encaminha-mento. Qualquer configuracao ou alteracao deve ser feita manualmente, por esse motivonao e muito utilizada. Na configuracao dinamica, o gerenciamento domulticaste feitocom o uso de protocolos, que se encarregam do trafegomulticastencaminhando-o paraos dispositivos que manifestaram interesse em recebe-lo. A arvoremulticaste construıdadinamicamente, e, em caso de atualizacao na rede, o algoritmo deve recalcular a arvore.Nesse caso, os IEDs deveriam implementar protocolos para serem capazes de entrar ousair de um grupo. Atualmente, o protocolomulticastde camada 2 usado em redes IEC61850 e o GMRP. Seu principio basico de funcionamento e baseado em mensagens inti-tuladasjoin e leave, as quais ohostdeve ser capaz de enviar quando quiser entrar ou sairde um grupo. Oswitchregistra a porta pela qual recebeu a mensagemjoin e associa essaporta ao grupomulticastda mensagem, montando a sua tabela de encaminhamento. Emseguida, o switch envia a mensagemjoin via broadcastpara toda a rede, garantindo que onovo membro do grupomulticastpasse a ser conhecido por toda a rede. Todos osswitchesque suportam GMRP podem receber essa informacao de outrosswitchespara atualizar seuregistro local. Com a tabela configurada e atualizada, quando o publicador envia mensa-gensmulticast, oswitchenvia essas mensagens apenas para as portas necessarias para quea mensagem chegue a todos os membros do grupo [Yong-hui et al. 2011].


Existem trabalhos que mostram que o uso demulticastem redes de subestacao simplifica ocontrole do trafego e diminui os atrasos [Ingram et al. 2011, Sivanthi and Goerlitz 2013,Moore et al. 2010, McGhee and Goraj 2010], alem de reduzir o volume de dados recebi-dos por dispositivos [XiCai et al. 2011].

Yong-hui et al. mostram as vantagens do uso do GMRP em redes de subestacao.Os autores exploram as vantagens do GMRP com aplicacoes em laboratorio e aplicacoespraticas. Nesse mesmo contexto, XiCai et al. apresentam um exemplo do uso doGMRP em subestacoes Chinesas para reduzir o volume de dados recebidos por dispo-sitivos [XiCai et al. 2011]. Muitas vezes, o GMRP e usado em conjunto com as VLANs(Virtual Local Area Network) para restringir o trafego [Ingram et al. 2011]. Ingram etal. combinam o uso de VLANs e filtromulticastpara separar o trafego por aplicacaoe por grupos de interesse, de forma que o trafegomulticast fique restrito a ser dis-tribuıdo apenas dentro de determinada VLAN [Ingram et al. 2011]. Sivanthi e Goerlitzpropoem uma abordagem sistematica para melhorar o uso de filtrosmulticaste VLANsagrupando caminhos comuns [Sivanthi and Goerlitz 2013]. Os autores apresentam umalgoritmo que agrupa destinos que seguem o mesmo caminho na rede, ou seja, se dois

2Nesse artigo, entende-se porswitchtıpico o comportamento padrao deswiches.


34

gruposmulticast tem a mesma arvore, o algoritmo coloca os dois no mesmo grupomulti-cast[Sivanthi and Goerlitz 2013]. As propostas de uso do GMRP em redes de subestacao,demandam que os fabricantes de IEDs implementem o protocolo em seus dispositi-vos [Yong-hui et al. 2011]. Contudo, os IEDs, ate o momento, nao possuem a capacidadede implementar o protocolo e enviar mensagensjoin e leavepara a rede. Com isso, parteda configuracao tem que ser feita manualmente, na tabelamulticastestatica dosswitches.Assim, a configuracao da rede se torna trabalhosa e a maioria dos fabricantes recomendaa utilizacao de VLANs para limitar os domınios debroadcast [Ingram et al. 2011]. Por-tanto, omulticastacaba nao sendo utilizado na pratica, o que reduz o desempenho da rede[McGhee and Goraj 2010].

A proposta deste artigo dinamicamente cria arvoresmulticast, sem a necessidadede implementacao nos IEDs e configura os fluxosunicaste multicastno contexto de sis-temas de automacao de subestacao usando o OpenFlow. O trabalho leva em consideracaoos requisitos temporais rıgidos da norma IEC 61850 e a confiabilidade requerida em redesde subestacao. Alem disso, reconfigura dinamicamente toda a rede em caso de falha oude mudanca na rede.

Com relacao ao uso de OpenFlow emSmart Grids, Sydney et al.propoem o uso de OpenFlow para prover recursos de MPLS em redes de longadistancia [Sydney et al. 2014]. Cahn et al. propoem o SDECN (Software-Defined EnergyCommunication Network), que usa redes definidas por software (SDN) como solucaopara assmart grids[Cahn et al. 2013]. Os autores sugerem o uso do openflow em redesde subestacao e fazem uma implementacao simples com base no controlador Ryu. Poucosdetalhes sao apresentados sobre algoritmos e logicas de controle e os cenarios de teste saomuito restritos.

Existem, ainda, alguns trabalhos que utilizam o OpenFlow para gerenciamento derede e encaminhamentomulticast [Marcondes et al. 2012, Silva et al. 2012], porem forado contexto de subestacoes.

4. A proposta SMARTFlow

Para aumentar o desempenho das redes de subestacao, e proposto o SMARTFlow, quee um sistema autoconfiguravel para redes de telecomunicacoes IEC 61850 baseado noarcabouco OpenFlow. Seus objetivos principais sao o desenvolvimento de um enca-minhamento apropriado de mensagens IEC 61850 e o controle eficiente de redes dedados de subestacoes eletricas. Alem disso, com o SMARTFlow, e possıvel fazer aautoconfiguracao dos gruposmulticastde forma automatica, toda vez que for inserido ouretirado um IED da rede, sem a necessidade de implementacao no IED. Como a propostae facilitar o planejamento e a configuracao da rede, e possıvel configurar automaticamentea rede de telecomunicacoes com a solucao adequada aos requisitos da rede. Dessa forma,os principais modulos do SMARTFlow sao:

• autoconfiguracao inicial da rede de telecomunicacoes com base nos dados obtidospelos arquivos de configuracao da subestacao providos pela norma IEC 61850;

• criacao automatica de arvoresmulticastde camada 2 para o envio de mensagensGOOSE e SV;

• recuperacao de falhas atraves do recalculo e atualizacao automatica das rotas pro-ativamente sempre que um dos enlaces da rede falhar;


35

4.1. O IEC 61850 e o OpenFlow

Nesse trabalho, o OpenFlow foi escolhido como arcabouco, pois possibilita um con-trole mais flexıvel e orientado as necessidades de cada sistema de comunicacao, como eo caso dassmart gridse da Norma IEC 61850. Com isso, torna-se possıvel experimentarnovos metodos e novos algoritmos que garantam uma boa solucao e aumentem o de-sempenho das redes. De fato, essa tecnologia traz ganhos por permitir a implementacaode todas as recomendacoes da norma e de recursos para otimizar a rede. Alem disso,por existir um controlador centralizado, as redes OpenFlow oferecem flexibilidade deprogramacao e uma visao unificada da rede, facilitando a implementacao de novos algo-ritmos, a configuracao e a gestao da rede. Alem disso, a manutencao preventiva da redee realizada de uma maneira simples, uma vez que a migracao de fluxos e simples em re-des OpenFlow. Como o uso do arcabouco OpenFlow simplifica a virtualizacao da rede,diferentes fabricantes podem implementar polıticas para controlar a sua rede no mesmoswitchsem interromper ou interferir com outros servicos.

4.2. Arquitetura do SMARTFlow

A arquitetura detalhada do SMARTFlow e ilustrada na Figura 1. O SMARTFlow e exe-cutado sobre um elemento central da rede, chamado controlador, que se comunica comtodos osswitchespara configurar as tabelas de fluxo via um canal seguro. O SMARTFlowpode ser implementado em qualquer controlador OpenFlow.

Figura 1. Estrutura do SMARTFlow, o qual e composto por um conjunto deaplicac oes de controle para redes de subestac oes baseadas em IEC 61850.

No SMARTFlow, o plano de controle da rede de telecomunicacoes e responsavelpor monitorar e configurar a rede automaticamente a partir de parametros do arquivoSCD da Norma. Os algoritmos de controle do SMARTFlow [Lopes 2013], usam comobase informacoes contidas nesse arquivo, que pode conter, dentre outras informacoes, aque grupomulticastcada IED pertence e os enderecos de rede do mesmo. Dessa forma,torna-se possıvel fazer um mapeamento dos gruposmulticastexistentes na rede para oalgoritmo que calcula as arvores, gerando uma lista de gruposmulticast.


36

Propoe-se o uso de sete componentes, os quais todos foram desenvolvidos parao SMARTFlow, com excecao doDescoberta de Topologia e do SpanningTree , que sao componentes geralmente encontrados nos controladores OpenFlow:

Descoberta de Topologia : Este componente e essencial para o funcio-namento dos outros componentes do SMARTFlow. O componenteDescoberta deTopologia instrui cada um dosswitchesda rede a enviar mensagensLink Layer Dis-covery Protocol(LLDP) para seus vizinhos, de modo que o controlador possa descobrir atopologia da rede. Quando umswitchrecebe um pacote LLDP, ele encaminha o cabecalhodo pacote para o controlador, ja que nao existe regra de encaminhamento para esse fluxo.Com isso, o controlador pode inferir a conectividade dos enlaces combinando os dadosde cada pacote LLDP recebido.

Spanning Tree : Ja conhecendo a visao geral da topologia da rede, pelo com-ponenteDescoberta de Topologia , pode-se, entao, construir aspanning tree. Oobjetivo do componenteSpanning Treee calcular a arvore de cobertura da rede e, deacordo com os dados obtidos, desativar a primitiva de inundacao em alguns enlaces es-pecıficos. Isso faz com que topologias que formem ciclos evitemloopsinfinitos no enviode mensagensbroadcast.

Tr afego Comum: Este componente encaminha, sob demanda, o trafego unicastde baixa prioridade das redes baseadas em IEC 61850, como por exemplo,mensagensMMS. O componenteTr afego Comum e uma versao do componente do Openflow quefunciona como umswitchde aprendizagem de forma reativa. Isso significa dizer que,sempre que um novo fluxo chegar a umswitch, este dispositivo encaminha o cabecalhodo primeiro pacote para o controlador, o qual aciona o moduloTr afego Comum paracalcular e definir as entradas de fluxo correspondentes com base no estado atual da rede.

Descoberta de Clientes : Este componente captura os pacotes da rede efaz o mapeamento dos enderecos MAC de todos os IEDS na rede automaticamente, arma-zenando em um dicionario todos os enderecos MAC dos IEDs, a qual portas eswitchesestao ligados. Esse dicionario e intituladomac map. Cada vez que um IED e acrescen-tado ou retirado da rede, esse componente atualiza esse dicionario. Os enderecos MACdos IEDs e servidores, na pratica, podem ser obtidos do arquivo SCD da norma IEC61850. Contudo, essa configuracao inicial nao e suficiente para detectar erros de ligacao,ou ainda, mudancas na topologia geradas durante o funcionamento da rede. Assim, optou-se pelo uso de uma solucao mais generica. O componente proposto monitora os eventosda rede e mantem atualizado o dicionario que correlaciona o MAC e a porta de saıda decadaswitch.

Balanceamento de carga : Esse componente observa o estado da rede edistribui a carga dos fluxosunicastmenos prioritarios entre os enlaces, atraves do uso demigracoes ao vivo. Com isso, sempre que se observa que um enlace esta proximo de umcerto limiar de uso, alguns fluxos sao migrados para outros enlaces menos sobrecarrega-dos. Essa migracao e feita criando-se uma nova rota a partir do destino ate a origem. Arota original e apagada apenas quando a nova rota ja esta pronta para uso, garantindo,assim, que nao serao perdidos pacotes. Isso ajuda a melhorar o desempenho da redee a minimizar a latencia de resposta, o que e essencial para redes de comunicacao queauxiliam mecanismos de protecao do SEP.


37

Multicast L2 : Este componente implementa o Algoritmo 1 para calcular asarvores de distribuicao para os gruposmulticastde camada dois, necessarios para as men-sagens GOOSE e SV. Utilizando como entrada o arquivo SCD, esse componente identificaos gruposmulticaste, em seguida, com base nos dados das aplicacoesDescoberta deTopologia e Descoberta de Clientes , calcula as arvoresmulticastpara cadagrupo na rede IEC 61850 da subestacao e configura pro-ativamente os respectivosswit-ches. Essa configuracao pro-ativa e importante porque os gruposmulticastsao utilizadospor mensagens de alta sensibilidade a atrasos no IEC 61850. A configuracao pro-ativaimpede que a entrega das mensagens seja atrasada pela consulta reativa ao controlador, oque seria o comportamento padrao do OpenFlow.

O Algoritmo 1, baseado nos dados do componenteDescoberta deTopologia , e capaz de ter uma visao completa da rede, podendo armazenar em umalista, todos os enlaces e nos da rede. A lista de enlaces (E), a lista de nos (N), a listade gruposmulticast(gruposmulticastgerados) e o dicionariomac map sao as entra-das desse algoritmo. A saıda e o caminho completo da arvoremulticast, intituladocaminho completo, que o proprio algoritmo usa para configurar os fluxos em cadaswitchda rede. A lista de gruposmulticaste percorrida para criacao e configuracao de cada

Algoritmo 1: Algoritmo de calculo de arvoresmulticaste estabelecimento derotas

Input : E, N , mac map, gruposmulticastgerados

Output : caminhoscompletos

1 for grupo in gruposmulticastgerados do2 end GM = descobre end(grupo)3 raiz = descobre raiz(mac map, grupo)4 sws destino = descobre dst(mac map, grupo)5 melhores rotas = SPF multicast(raiz, N,E)6 for rota in melhores rotas do7 if rota[dst] in sws destino then8 caminhos arvore.append(rota)9 end

10 end11 arvore multicast = remove redundancias(caminhos arvore)12 caminhos completos =

acrescenta portas(mac map, arvore multicast)instala fluxos(caminhos completos, end GM, raiz)return caminhos completos

13 end

arvoremulticast, como mostrado na linha 1. A funcaodescobre end, na linha 2, descobrequal o endereco MAC do grupomulticast. A funcaodescobre raiz, na linha 3, com baseno map mac descobre qual o endereco MAC do no raiz do grupomulticaste em qualswitchesta conectado.E importante observar que serao considerados como raiz todosos nos que possam emitir mensagens para o grupomulticast. A funcaodescobre dst, nalinha 4, retorna uma lista com osswitchesque estao conectados a pelo menos um dosmembros do grupo, com as respectivas portas. Com os nos, os enlaces e a raiz do grupo


38

multicast, a funcaoSPF multicast calcula todas as rotas mais curtas da raiz para cadaoutro no restante da rede, possıveis nos receptores do grupo. Com isso, e criada uma listade caminhos mais curtos, intituladamelhores rotas. Conforme descrito na linha 6, asrotas da listamelhores rotas que tiverem como destino os nos receptores do grupo saoarmazenadas na listacaminhos arvore que, ao final, contem os melhores caminhos doIED publicador ate os IEDs receptores do grupomulticast. A lista caminhos arvore eprocessada para remocao de redundancias com a funcaoremove redundancias. Essafuncao gera a listaarvore multicast, contendo o caminho por qual os pacotes deveraopassar para alcancar todos os destinos daquele grupo, conforme linha 11. Para que astabelas dosswitchespossam ser configuradas, alem do caminho e necessario o acrescimodas portas por qual esse caminho esta conectado. Essa tarefa e realizada pela funcaoacrescenta portas, que gera como saıda a lista intituladacaminhos completos, con-tendo uma lista para cadaswitchcom o seu numero de identificacao e as portas por ondeos pacotes serao encaminhados, ou seja, a tabela de fluxos que devera ser configurada.Por fim, o controlador pode configurar as tabelas de fluxos nosswitchespertencentes alista caminhos completos criando assim a arvoremulticastdo grupo em questao.

Cabe observar que o algoritmo proposto nao busca a melhor arvore de cobertura,mas a entrega mais rapida dos pacotes, tendo como metrica o numero de saltos. Devido asfortes restricoes de atraso das mensagens GOOSE e SV, a proposta prioriza a velocidadeda entrega.

Detecc ao de Falhas : Este componente e chamado sempre que ocorremudancas na topologia da rede. Desta forma, sempre que um enlace cai, o componenteDeteccao de Falhas chama o componenteMulticast L2 , o qual recalcula as arvores3.O componente e seu algoritmo sao detalhados no Algoritmo 2.E importante notar que,

Algoritmo 2: Algoritmo de deteccao de falhas e restauracao da redeInput : evento,E, N , mac map, gruposmulticastgerados,

caminhos completos

Output : caminhos completos

1 enlaces afetados = busca falhas(evento,E,N)2 grupos afetados, grupos nao afetados =busca grupos(enlaces afetados, caminhos completos, gruposmulticastgerados)

3 novos grupos = multi tree(E,N,mac map, grupos afetados)4 caminhos completos = novos grupos+ grupos nao afetados

5 return caminhos completos

se a versao do OpenFlow suportar oFast Failover, entao existem pequenas alteracoesnos Algoritmos 1 e 2. O Algoritmo 1, apos calcular a arvore de distribuicao para umpar (endereco MAC multicast, raiz), ira aumentar os custos de todos os enlaces utilizadosnessa arvore de cobertura e ira buscar uma nova arvore de distribuicao na rede. Em se-guida, essa nova arvore e adicionada como caminho para casos de falha na tabela de grupodosswitchesOpenFlow.E importante observar que o aumento do custo garante que umasegunda arvore sera encontrada, mesmo que nao existam caminhos totalmente disjuntos.

3Cabe observar que o comportamento desse componente varia de acordo com a versao do OpenFlow emuso, de acordo com a disponibilidade ou nao da tabela de grupo e do mecanismo defast failover.


39

As modificacoes no Algoritmo 2 ocorrem apenas para apagar a rota original que esta comuma falha, de forma que a segunda opcao se torne a rota principal. O Algoritmo, natu-ralmente, ja buscara uma terceira opcao de arvore de distribuicao, para prevenir novasfalhas na rede. Ressalta-se que a rede devera prover mais de um caminho, caso a rede sotenha um caminho possıvel, esse componente nao se aplica. Maiores detalhes sobre osalgoritmos podem ser encontrados em [Lopes 2013].

5. Experimentos com ferramentas de emulacao e Analise dos ResultadosOs componentes do SMARTFlow foram desenvolvido em Python e implementados nocontrolador POX 0.1.0 na versao 1.0.0 do OpenFlow. Os experimentos foram emuladosusando o Mininet [Lantz et al. 2010] versao 2. O Mininet e uma plataforma flexıvel paraemulacao de redes OpenFlow que prove um ambiente de experimentacao bem proximo doreal. Foi criado um modulo no Mininet que constroi topologias LAN de subestacoes, todasdistribuindo os IED uniformemente na rede. Este modulo tambem contem a classe quechama os componentes do SMARTFlow para controlar a rede. Para esses experimentos,focou-se na entrega do trafego de mensagens GOOSE, que tem grande restricao de atrasosnas redes das subestacao. Para tanto, foi desenvolvido um gerador de mensagens GOOSEna ferramenta Scapy para simular o trafego dos IEDs. A duracao dos experimentos foide 100 segundos para cada rodada, incluindo, neste tempo, a estabilizacao da rede, aconfiguracao dos fluxos, a troca de mensagens e o tempo da simulacao. Foram variadosparametros como quantidade de IEDs na rede, quantidades deswitches, tipo de topologiae quantidade de IED por grupomulticast.

O ambiente foi emulado por meio de virtualizacao em um notebook com proces-sador Intel Core i5-3210M, e 4GB de memoria RAM. Os testes foram realizados comtres instancias de maquinas virtuais simultaneas, cada uma delas com uma CPU virtual,1024 MB de memoria e executando o sistema operacional Ubuntu 11.10. Todos os re-sultados apresentam um intervalo de confianca de 95%. Para os experimentos, levou-seem consideracao os cenarios tıpicos de subestacao descritos na parte 1 da norma IEC61850 [IEC 61850 ] onde e descrito o tamanho da subestacao e sua importancia no sis-tema. Em todos os casos, a quantidade de IEDs depende muito do projeto e funcoesque serao utilizadas na subestacao. Assumindo uma quantidade de 3 ate 12 IEDs pode-se assumir que os testes englobam, senao todos, a maior parte dos cenarios tıpicos emsubestacoes. Alem disso, para todos os experimentos foram testadas topologias em anele estrela pois sao as topologias encontradas em subestacao. Os graficos da Figura 2 apre-sentam o resultado para topologia em anel, ja que esta apresentou uma carga de controleum pouco mais alta do que a topologia em estrela. O cenario e composto por cinco gruposmulticastdistintos e nove IEDs, distribuıdos uniformemente entre osswitches. A quanti-dade deswitchesvariou de um a nove. Foram estimulados dez eventos na rede, gerandotrafego GOOSE. A ideia consiste em criar cenarios que representam desde pequenas ategrandes subestacoes.

Na Figura 2(a), nota-se que o atraso na rede controlada pelo SMARTFlow naopassou de 1,5 ms. Isso mostra que o SMARTFlow atende bem aos requisitos rıgidosde tempo da norma, que determinam atraso maximo de 3 ms para mensagens GOOSE,mesmo em redes de subestacao com grande numero de switches. Alem disso, verifica-seque, na rede controlada pelos componentes reativos do controlador OpenFlow, o atrasoe muito superior, chegando a ser ate 20 vezes maior que o atraso do SMARTFlow. Esse


40

05

1015

2025

30

Quantidade de switches

Atr

aso(

ms)

1 3 5 7 9

Limiar temporalComponente OpenFlow ReativoComponente Smart Flow

(a) Atraso na rede.

0.0

0.5

1.0

1.5

2.0

Quantidade de switches

Car

ga d

e C

ontr

ole

(KB

/s)

1 3 5 7 9

Componente OpenFlow ReativoComponente SMARTFlow

(b) Carga de controle na rede aposestabilizacao.

Figura 2. Comparac ao ao se utilizar o SMARTFlow e o OpenFlow Nativo em umatopologia em anel.

comportamento era esperado pela caracterıstica reativa desses componentes, no qual cadapacote de um novo fluxo que chega aoswitche enviado ao controlador. Quando o con-trolador identifica que e um pacotemulticast, configura uma entrada de fluxo para enviaro pacote para todas as portas de saıda, ja que o comportamento padrao dosswitchesetratar omulticastcomobroadcast. Todo esse processo, naturalmente, sobrecarrega a redee aumenta o atraso dos pacotes. Com isso, conclui-se que o componente padrao de en-caminhamento do controlador OpenFlow nao e adequado para o controle de mensangensGOOSE, pois nao garante os requisitos mınimos de atraso. A Figura 2(b), analisa a cargade controle gerada na rede, assumindo um sistema estabilizado, ou seja, durante o compor-tamento padrao da subestacao. Para isso, calculou-se toda a carga de pacotes de controlena rede, como pacotes LLDP,packetin, packetout, etc. Em uma rede estabilizada, oSMARTFlow apresenta uma carga de controle muito baixa, com valores muito proximosde 0, pois a carga de controle da proposta se concentra, principalmente, na inicializacaoda rede. Isso e importante, pois a rede nao e sobrecarregada durante o seu funcionamentonormal, evitando o aumento dos atrasos para mensagens GOOSE e SV. Os valores maisaltos do OpenFlow se devem a troca de mensagens entre controlador eswitchesdurantetodo o tempo.

Por fim, a Figura 3, apresenta os resultados da avaliacao da carga total na rede,incluindo a carga de controle no caso dos componentes OpenFlow. Alem dos sistemasanteriores, OpenFlow Nativo e SMARTFlow, acrescenta-se um sistema baseado emswit-chestıpicos. Para emular osswitchestıpicos, criou-se um componente apenas para insta-lar proativamente regras que tratam o trafegomulticastcomobroadcastconfigurando osfluxos proativamente. Desta forma, simula-se umswitchcomum, onde os fluxos ja se en-contram definidos encaminhando o pacote por todas as portas. O cenario considerou umaLAN com 5 switchese uma quantidade de IEDs variando entre 3 e 12. Emulou-se doistipos de topologia, anel e estrela, cinco gruposmulticaste dez eventos na rede eletrica,em momentos aleatorios, que refletem em um aumento do trafego GOOSE. Observa-se,na Figura 3, que a carga total de dados no OpenFlow Nativo e um pouco mais alta do


41

050

100

150

200

Quantidade de IEDs

Car

ga T

otal

na

Red

e(K

B/s

)

3 6 9 12

Switch TípicoComponente OpenFlow ReativoComponente SMARTFlow

(a) Topologia em Anel.

050

100

150

200

Quantidade de IEDs

Car

ga T

otal

na

Red

e(K

B/s

)

3 6 9 12

Switch TípicoComponente OpenFlow ReativoComponente SMARTFlow

(b) Topologia em Estrela.

Figura 3. Carga total de dados na rede em func ao do aumento do numero deIEDs.

que a carga doswitchtıpico. Isso acontece pois, quando o componente reativo do Open-Flow emulaswitchestıpicos e acrescida a carga da inundacao na rede a carga de controlepara setar o fluxo. Ressalta-se que, a carga de controle para este cenario e muito pequenaquando comparada a quantidade total de dados na rede e, com isso, o comportamentodas duas curvas e muito proximo. Alem disso, verifica-se que o SMARTFlow diminuia carga total na rede em ate 44% para 12 IEDs na topologia em Anel. Isso acontece,pois o SMARTFlow calcula uma arvoremulticastpara encaminhar os pacotes evitando ainundacao natural deswitchestıpicos. Quando o pacote chega aoswitch, ao inves de serencaminhado por todas as portas, e enviado apenas para a porta relativa a arvoremulticast.

O tempo para recuperacao de falha, mesmo sem a implementacao dofast failo-ver ficou em torno de 8ms. Esse experimento e outros resultados como os tempos paraconfiguracao da rede, descoberta da rede, etc, sao encontrados em [Lopes 2013].

Realizou-se tambem uma analise qualitativa comparando as caracterısticas dassolucoesmulticastde camada 2 com as caracterısticas da solucao SMARTFlow. Os resul-

Tabela 1. Comparac ao entre as atuais soluc oes multicast de camada 2 e a pro-posta SMARTFlow

Caracterısticas Multicast Multicast GMRP SF 1.0 SFtıpico Estatico

Complexidade de configuracao Baixa Alta Media Baixa BaixaDependencia de mensagensJoin e leave Nao Nao Sim Nao NaoConsumo de Banda pelo trafego de dadosAlto Baixo Baixo Baixo BaixoCarga de Controle Baixa Baixa Alta Baixa BaixaInundacao da Rede Sim Nao Nao Nao NaoControle aprimorado do trafego Nao Nao Nao Sim SimSimplicidade e Flexibilidade Baixa Baixa Baixa Alta AltaConvergencia Rapida Sim Nao Nao Sim SimTempos de atraso na rede Alto Baixo Baixo Baixo Baixo


42

tados sao mostrados na Tabela 1, onde SF 1.0 refere-se ao SMARTFlow implementado noarcabouco do OpenFlow versao 1.0, SF refere-se a implementacao em versoes superiores,Multicast Tıpico refere-se ao comportamento padrao deswitchese Multicast Estatico aconfiguracao da arvore de forma manual. Uma vantagem do SMARTFlow sobre o GMRPe a ausencia de mensagens de controle entre osswitches. No GMRP, osswitchessao res-ponsaveis por encaminhar pacotes e trocar mensagens de controle para montar a arvoremulticast. Isto cria uma sobrecarga extra em termos de consumo de banda, pois o con-trole de mensagens, comojoin e leaveou atualizacoes de arvores, sao enviadas atravesdos mesmos enlaces que o trafego de dados. Alem disso, no SMARTFlow, os IEDs saoautomaticamente incluıdos na arvoremulticastcom base no arquivo SCD, de modo quenao e necessario que os IED implementem protocolosmulticastcliente ou que mensagensde atualizacao da arvore sejam enviadas frequentemente. Mudancas na topologia de redesao automaticamente detectadas no SMARTFlow, que desencadeia a reconfiguracao dasarvoresmulticast.

6. Conclusoes

A norma IEC 61850 tem ganhado cada vez mais espaco, sendo implantada em novassubestacoes trazendo inumeros benefıcios como reducao de custos e de erros humanos,automacao, implementacao de novas capacidade, dentre outros. Contudo, mesmo com ainovacao, ainda existem problemas a serem resolvidos. Esse trabalho identificou e abor-dou alguns desses problemas, assim como propos, desenvolveu e avaliou um servico degerenciamento e encaminhamento autoconfiguravel para redes IEC 61850 baseada emuma tecnica promissora que tem possibilitado um controle mais flexıvel, o OpenFlow. Aproposta, chamada SMARTFlow, diminuiu a carga total da rede gerada pelo OpenFlowNativo e peloswitchde camada 2 tıpico em ate 44% no cenario apresentado. Os testesmostraram, tambem, que o atraso na rede controlada pelo OpenFlow em sua forma habi-tual chegou a ser ate 20 vezes maior do que a rede controlada pelo SmartFlow, passandode 20ms. Contudo, o atraso na rede controlada pela proposta SMARTFLow nao ultrapas-sou 1,5ms, que e metade do valor mais rıgido de tempo estabelecido pela norma (3ms).Com isso, esse trabalho verificou que o SMARTFlow e capaz de cumprir os requisitosimpostos pela norma IEC 61850 ao usar as aplicacoes desenvolvidas como uma provade conceito. Alem disso, o uso demulticastcom um controle centralizado e com dadosoriundos do arquivo SCD permitem que sejam usados IEDs mais simples e tambem reduzo trafego de controle, o tempo de convergencia dos algoritmos de controle e o atraso deentrega de dados, quando comparado com os protocolos habituais.

Como trabalhos futuros, pretende-se implantar a proposta em uma rede real Open-Flow, e em uma rede tradicional para uma analise mais profunda. Uma outra questao e oestudo, desenvolvimento e implementacao do SMARTFlow nos IEDs que possuemswit-chesembarcados para a construcao de topologias em anel. Portanto, seria necessaria aimplementacao do OpenFlow nessesswitchesembarcados e a realizacao de testes de de-sempenho utilizando o SMARTFlow. Pode-se tambem investigar, implementar e avaliara proposta em um contexto entre subestacoes, podendo inclusive estender a pesquisa paraas Smart Grids como um todo. Alem disso, pretende-se validar a recuperacao de falhasdo SMARTFlow implantando tambem ofast failover.

Referencias

[Cahn et al. 2013] Cahn, A., Hoyos, J., Hulse, M., and Keller, E. (2013). Software-defined energycommunication networks: From substation automation to future smart grids. InSmart GridCommunications (SmartGridComm), 2013 IEEE International Conference on, pages 558–563.


43

[Gungor et al. 2011] Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C., Cecati, C., andHancke, G. (2011). Smart grid technologies: Communication technologies and standards.IEEETransactions on Industrial Informatics, 7(4):529–539.

[IEC 61850 ] IEC 61850. Communication networks and systems for power utility automation. Te-chnical report, International Electrotechnical Commission (IEC).

[Ingram et al. 2011] Ingram, D., Schaub, P., and Campbell, D. (2011). Multicast traffic filteringfor sampled value process bus networks. InIECON 2011 - 37th Annual Conference on IEEEIndustrial Electronics Society, pages 4710–4715.

[Lantz et al. 2010] Lantz, B., Heller, B., and McKeown, N. (2010). A network in a laptop. InProceedings of the Ninth ACM SIGCOMM Workshop on Hot Topics in Networks - Hotnets ’10,pages 1–6. ACM Press.

[Lopes 2013] Lopes, Y. (2013). SMARTFlow: Sitema Autoconfiguravel para Redes deTelecomunicacoes IEC 61850 com arcabouco OpenFlow. Mestrado em Engenharia deTelecomunicacoes, Universidade Federal Fluminense, UFF.

[Lopes et al. 2012] Lopes, Y., Frazao, R. H., Molano, D. A., dos Santos, M. A., Calhau, F. G. a.,Bastos, C. A. M., Martins, J. S. B., and Fernandes, N. C. (2012). Smart Grid e IEC 61850:Novos Desafios em Redes e Telecomunicacoes para o Sistema Eletrico. InMinicursos doXXX Simposio Brasileiro de Telecomunicacoes, pages 1–44. (SBrT), Sociedade Brasileira deTelecomunicacoes, 1 edition.

[Marcondes et al. 2012] Marcondes, C., Santos, T., Godoy, A., Viel, C., and Teixeira, C. (2012).CastFlow: Clean-slate multicast approach using in-advance path processing in programmablenetworks. In2012 IEEE Symposium on Computers and Communications (ISCC), pages 94–101.

[McGhee and Goraj 2010] McGhee, J. and Goraj, M. (2010). Smart High Voltage Substation Basedon IEC 61850 Process Bus and IEEE 1588 Time Synchronization. InSmart Grid Communica-tions (SmartGridComm), 2010 First IEEE International Conference on, pages 489–494.

[McKeown et al. 2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L.,Rexford, J., Shenker, S., and Turner, J. (2008). Openflow: enabling innovation in campusnetworks.SIGCOMM Computer Communication Review, 38(2):69–74.

[Moore et al. 2010] Moore, R., Midence, R., and Goraj, M. (2010). Practical experience with IEEE1588 high Precision Time Synchronization in electrical substation based on IEC 61850 ProcessBus. InPower and Energy Society General Meeting, 2010 IEEE, pages 1–4.

[Silva et al. 2012] Silva, F. d. O., Goncalves, M. A., de Souza Pereira, J. H., Pasquini, R., Rosa, P. F.,and Kofuji, S. T. (2012). On the analysis of multicast traffic over the entity title architecture.In Networks (ICON), 2012 18th IEEE International Conference on, pages 30–35.

[Sivanthi and Goerlitz 2013] Sivanthi, T. and Goerlitz, O. (2013). Systematic real-time traffic seg-mentation in substation automation systems. InEmerging Technologies Factory Automation(ETFA), 2013 IEEE 18th Conference on, pages 1–4.

[Sydney et al. 2014] Sydney, A., Ochs, D. S., Scoglio, C., Gruenbacher, D., and Miller, R. (2014).Using GENI for experimental evaluation of Software Defined Networking in smart grids. InComputer Networks.

[Tan and Luan 2011] Tan, J. C. and Luan, W. (2011). IEC 61850 based substation automation systemarchitecture design. InPower and Energy Society General Meeting, 2011 IEEE, pages 1–6.

[XiCai et al. 2011] XiCai, Z., ShuChao, W., Lei, X., and YaDong, F. (2011). Practice and trend ofDSAS in China. InAdvanced Power System Automation and Protection (APAP), 2011 Interna-tional Conference on, volume 3, pages 1762–1766.

[Yong-hui et al. 2011] Yong-hui, Y., Lei-tao, W., and Yong-jian, T. (2011). Research of networktransmission of process bus based upon IEC 61850. InAdvanced Power System Automationand Protection (APAP), 2011 International Conference on, volume 2, pages 1578–1582.


44



Florianópolis - SC



(WGRS)

Sessão Técnica 2

Virtualização e Redes definidas por

software

Dependabilidade na Alocação de Recursos em Redes Virtuais:

Uma Heurística Aleatória com Busca Adaptativa

Marcelo Santos, Matheus Santana, Djamel Sadok, Stênio Fernandes

Centro de Informática – Universidade Federal de Pernambuco (UFPE)

Recife – PE – Brasil

{mabs, embs, jamel, sflf}@cin.ufpe.br

Abstract. Network Virtualization has become a central matter for the Future

Internet. Nevertheless, mapping virtual networks on the top of physical

infrastructure topology represents a NP-Hard problem due to its numerous

combinations and many node and link allocation constraints. Virtualized

structures are as failure-prone as its underlying physical infrastructure.

Hence, dependability attributes constitute relevant metrics for virtual network

allocation decision. This work proposes and evaluates a dynamic and random

networks allocation heuristic that takes into account of nodes and links

capacity attributes maximizing availability. Results show that the proposed

heuristic achieves an average availability of 95% while others algorithm

allocation techniques achieve an average of 60% for same dependability

metric.

Resumo. Virtualização de redes vem sendo um dos pilares da Internet do

Futuro. No entanto, mapear redes virtuais em uma topologia física é um

problema NP-difícil devido ao grande número de combinações e às diversas

restrições envolvidas na alocação de nós e enlaces virtuais. Falhas são

inerentes a estas estruturas virtualizadas, uma vez que a infraestrutura física é

propensa a falhas. Portanto, atributos de dependabilidade são importantes

para a decisão de alocação de uma rede virtual. Assim, este trabalho propõe e

avalia uma heurística aleatória adaptativa para alocação de redes virtuais

levando em consideração características de capacidade dos nós e enlaces

juntamente com atributos de dependabilidade buscando maximizar a

disponibilidade. Os resultados mostram que a heurística proposta alcança

uma disponibilidade média nas requisições de 95% contra 60% nas outras

estratégias.

1. Introdução

Redes Virtuais têm recebido grande atenção da comunidade de pesquisa nos últimos

anos. Tratada como umas das tecnologias para a Internet do Futuro, possibilita um meio

de avaliar novos protocolos e serviços figurando como uma importante tecnologia para

superar a barreira da ossificação da Internet. Uma de suas características chave é a

dinamicidade. Redes virtuais permitem a operadores de redes terem negociação em

tempo real sobre uma variedade de serviços entre seus usuários, operadores de serviços

virtuais (Virtual Network Operators -VNO) e provedores de redes virtuais (Virtual

Network Providers - VNP) [Schaffrath et al. (2009)].

As estratégias de gerenciamento de rede dependem de mecanismos de alocação

dinâmica dos recursos para a alocação das redes virtuais de forma eficiente e com alto


47

grau de desempenho. Para este fim, uma série de heurísticas foram propostas na

literatura [Zhu et al. (2006)] [Guo et al. (2011)] [Zhou et al. (2010)] [Chowdhury et al.

(2012)] para alcançar utilização eficiente dos recursos dos elementos de rede, como

enlaces, nós e roteadores, uma vez que a alocação ótima não é possível devido à

natureza NP-Difícil do problema.

Embora a alocação eficiente dos recursos de rede seja uma questão fundamental

a ser abordada, há ainda um ponto importante a ser discutido, originado pelo seguinte

questionamento: quais são os riscos associados a uma determinada rede virtual? É

normal que os riscos sejam inerentes às infraestruturas físicas utilizadas (nós e enlaces),

uma vez que os componentes de rede física subjacente são propensos a falhas. Podemos

citar, por exemplo, o recente acidente na nuvem da Amazon como um alerta de que

falhas técnicas ou de intervenção humana é uma realidade e não devem ser

negligenciadas [Gill et al. (2011)] [Benson et al. (2010)]. A avaliação e análise de risco

dos atributos de dependabilidade são de suma importância, uma vez que se pode

quantificar e dar medidas concretas para serem usadas como fator de decisão no

gerenciamento e controle da rede. Em poucas palavras, a dependabilidade pode ser vista

como um conceito geral que engloba a disponibilidade, confiabilidade, segurança,

confidencialidade, integridade e capacidade de manutenção [Maciel et al. (2011)]

[Laprie et al. 1985]. Dessa forma, expandido outros trabalhos, este artigo propõe e

avalia uma heurística aleatória adaptativa para alocação de redes virtuais levando em

consideração capacidades de nós e enlaces juntamente com atributos de

dependabilidade.

Através da utilização da modelagem baseada em Diagrama de Blocos de

Confiabilidade (RBD) [Guimarães et al. (2011)], nós fornecemos uma heurística para o

problema de mapeamento de redes virtuais (Virtual Networking Mapping Problem -

VNMP) que leva em consideração os riscos na virtualização de rede por meio de

métricas de dependabilidade. As principais Contribuições deste trabalho são duas: (i)

propomos uma heurística para VNMP que leva em consideração dependabilidade para

tomada de decisão da alocação; e (ii) uma base metodológica que permite o

desenvolvimento da análise de riscos na alocação de redes virtuais.

O restante do artigo é organizado da maneira descrita a seguir. Na seção 2 são

citados os trabalhos relacionados. Na seção 3 há uma breve discussão sobre conceitos de

Dependabilidade. Na seção 4 é dada uma definição sobre VNMP e é exibida a

modelagem do problema. A seção 5 apresenta a heurística desenvolvida. A seção 6

discute a metodologia. Na seção 7 são apresentados os resultados. Na seção 8

discutimos os resultados. Apresentamos as conclusões na seção 9. Por fim são citadas as

referências.


Em Sun et al. (2010) é proposto um modelo de dependabilidade para ambientes de

computação em nuvem, usando virtualização de nível de sistema (CDSV) que adota

várias métricas quantitativas para avaliar a dependabilidade. O foco é uma análise sobre

aspectos de segurança e a avaliação do impacto das propriedades de dependabilidade

dos componentes virtualizados em nível de sistema (por exemplo, máquinas virtuais,

hypervisor e afins). Da mesma forma, Saripalli et al. (2010) apresentam um impacto

quantitativo e uma metodologia de avaliação de risco a fim de avaliar riscos de


48

segurança em ambientes de computação em nuvem. Esses trabalhos dão uma visão de

como abordar a avaliação da dependabilidade em cenários com virtualização, porém

possuem um escopo mais simples quando comparados com um cenário de redes

virtualizadas.

Em Fernandes et al. (2012) é proposto um método para análise da

dependabilidade em ambientes de redes virtualizadas com o uso de diagrama de bloco

de confiabilidade (RBD) e Redes de Petri Estocásticas (SPN). Este é o primeiro trabalho

a analisar o impacto da dependabilidade em ambientes dinâmicos de virtualização de

redes. No entanto, este trabalho utiliza como entrada para análise da dependabilidade o

resultado da heurística R-ViNE [Chowdhury et al. (2012)]. É importante destacar que a

heurística R-ViNE não leva em consideração dependabilidade para realizar a alocação

de requisições virtuais. Sendo assim, a relevância se dá pelo vislumbre de uma primeira

avaliação sobre os aspectos de dependabilidade num cenário de redes virtualizadas.

O trabalho mais semelhante encontrado na literatura é realizado por Lira et al.

(2013). Neste trabalho é apresentada uma heurística baseada no GRASP para alocação

de redes virtuais considerando dependabilidade. No entanto, a meta-heurística utilizada

não tem como objetivo a maximização da dependabilidade. A dependabilidade

apresenta-se apenas como uma restrição informada pelo usuário. Ou seja, o objetivo da

alocação é minimizar o custo estabelecido pelos autores que não leva em consideração

atributos de dependabilidade na sua função objetivo, não sendo assim justa uma

comparação com a heurística proposta. Além disso, o trabalho apresenta resultados

preliminares, pois não apresentam dados em relação à carga de recursos físicos

utilizados e à taxa de aceitação das requisições. Dessa forma podemos afirmar que os

trabalhos embrionários de Fernandes et al (2012) e Lira et al (2013) serviram como

motivação para uma análise mais extensa e aprofundada apresentada neste artigo.

Com relação às heurísticas de alocação de redes virtuais, focamos - nos

próximos parágrafos - em dois trabalhos que foram utilizados para comparação de

nossos resultados. Deve-se notar que os trabalhos abaixo não levam em consideração

características de falha em suas soluções de mapeamento de redes virtuais. No entanto,

esta comparação é importante para mensurar o quanto a dependabilidade varia quando é

negligenciada durante o processo de alocação.

Zhu e Ammar (2006) propõem um algoritmo ganancioso cujo objetivo é

balancear a carga sobre os enlaces e nós físicos. No entanto, sua abordagem não

considera aspectos de capacidade, o balanceamento é realizado levando em

consideração apenas a quantidade de nós e enlaces virtuais mapeados sobre a rede

substrato. A ideia principal da estratégia utilizada é mapear um novo nó virtual em um

nó físico considerando a quantidade de nós virtuais nesse nó físico e a carga nos nós e

enlaces físicos vizinhos.

Em Chowdhury et al. (2012) o problema de alocação de redes virtuais é

modelado em função dos custos de receita do servidor com restrições de nós, enlaces e

geo-localização. O problema resultante é NP-difícil e, para resolvê-lo, é realizada uma

redução para um problema de otimização inteira mista e posteriormente há o

relaxamento sobre as restrições, culminando em dois algoritmos de aproximação: D-

ViNE e R-ViNE. D-ViNE possui uma abordagem determinística para mapeamento dos

nós baseada em uma solução linear relaxada. R-ViNE é similar, mas usa um

mapeamento de nós aleatório. Ambos os algoritmos possuem versões em que o enlace


49

virtual é mapeado através do menor caminho ou do particionamento do fluxo virtual em

mais de um caminho físico. É importante destacar que neste trabalho, os autores não

levam em consideração atraso dos enlaces como restrição de alocação. Na prática, tais

restrições são importantes para requisitos de aplicações que executam, por exemplo, na

Internet. Além disso, assume-se que uma mesma máquina física não pode receber mais

de uma máquina virtual de uma mesma requisição, tornando a busca por uma solução de

mapeamento mais difícil. Outra desvantagem é o fato de algumas variações do D-ViNE

e R-ViNE realizarem divisão de caminhos virtuais (mapeamento de um caminho virtual

em dois ou mais caminhos físicos). Na prática isso é difícil de ser realizado, não sendo

comum sua adoção. Por isso, decidimos comparar apenas a abordagem que utiliza a

alocação de enlaces pelo menor caminho chamada D-ViNE-SP.

Este levantamento não tem o objetivo de ser extensivo, dado que apenas os

artigos que consideramos mais similares ao nosso trabalho são citados. Para uma

extensa literatura sobre o problema de alocação de redes virtuais pode-se destacar o

trabalho de Fischer et al. (2013). É importante ressaltar que os autores desconhecem

qualquer trabalho que leve em consideração a dependabilidade como fator durante uma

alocação de uma rede virtual. Desta forma, não há trabalhos que possam ser analisados

diretamente com a heurística proposta, por isso, como no trabalho de análise de

dependabilidade realizado por Fernandes et al. (2012), comparamos nosso trabalho com

heurísticas bem conhecidas na literatura.

3. Dependabilidade

A dependabilidade de um sistema, de maneira simplificada, pode ser entendida como a

sua capacidade de fornecer um conjunto de serviços de forma justificadamente

confiável. Trata-se, em termos mais abrangentes, de um conceito guarda-chuva que

contempla vários atributos como, por exemplo, tolerância a falhas, disponibilidade e

confiabilidade [Laprie (1985)] [Ebeling (1997)]. Métricas de dependabilidade podem

ser calculadas por modelos combinatórios, como os Diagramas de Bloco de

Confiabilidade (Reliability Block Diagram - RBD) e árvores de falha ou por meio de

modelos estocásticos baseados em estado - cadeias de Markov (Markov Chains) e redes

estocásticas de Petri (Stochastics Petri Nets - SPN), por exemplo [Maciel et al. 2011]

[Nicol et al. 2004]. Para uma melhor compreensão dos modelos de confiabilidade pode-

se utilizar as referências [Maciel et al. 2011] e [Nicol et al. 2004].

Uma das principais características utilizadas para a avaliação da dependabilidade

de sistemas é a disponibilidade. A dependabilidade de um sistema pode ser calculada -

com os supracitados modelos combinatórios, por exemplo - através do cálculo das

disponibilidades dos dispositivos que o compõem. A maneira de se obter a

disponibilidade (A) de um determinado dispositivo é lançar mão das suas características

de tempo até a ocorrência de falha (TTF) e tempo até o reparo de uma falha ocorrida

(TTR). Considerando que essas medidas exatas não estão disponíveis, suas médias são

utilizadas. Valendo-se dos valores de tempo médio para falha (MTTF) e tempo médio

de reparo (MTTR) de um dispositivo, a disponibilidade de estado estacionário (A) pode

ser representada como:

(1)


50

O MTTF pode ser computado considerando a confiabilidade do sistema (R)

como segue:

∫ ( ) ∫ ( )

(2)

Este trabalho adota a disponibilidade como métrica de dependabilidade,

modelada por RBD. Diagramas de bloco de confiabilidade fornecem método para

avaliação de disponibilidade ou confiabilidade através do mapeamento de sistemas (e

seus subsistemas / dispositivos) em blocos que se configuram em série ou paralelo.

Depois de modelado o sistema, a avaliação é feita de acordo com as regras de cálculo

para cada uma das possíveis configurações. Para melhor entendimento da modelagem

com diagramas de bloco de confiabilidade, a referência [Trivedi et al. (2008)] pode ser

consultada.

Neste trabalho o modelo RBD utilizado tem o objetivo de calcular a

dependabilidade de uma requisição virtual alocada sobre uma topologia física. Como

explicado na próxima seção, os blocos que modelam uma requisição são dispostos

totalmente em série, sendo a dependabilidade de uma requisição virtual calculada

através da multiplicação da disponibilidade de todos os nós e enlaces físicos utilizados

no mapeamento da requisição virtual.

4. VNMP e Modelagem do Problema

Com o intuito de deixar o problema atacado neste artigo bem definido, vamos nesta

seção descrever e caracterizar formalmente o problema e sua respectiva modelagem

matemática através da extensão do trabalho de Infuhr et al. (2013). O problema de

alocação de redes virtuais é conhecido na literatura como VNMP (Virtual Network

Mapping Problem). Algumas informações são necessárias para especificar um VNMP:

rede de substrato com seus recursos disponíveis e redes virtuais que precisam ser

alocadas de acordo com seus requisitos e restrições específicas sobre os recursos

virtuais e físicos.

Para modelar a rede de substrato utilizamos um grafo não direcionado com

( ) onde representa o conjunto de nós e o conjunto de enlaces. Cada nó

da rede substrato tem uma capacidade de CPU . O recurso de CPU

disponível é utilizado por um nó virtual que é mapeado para um nó físico . Enlaces

da rede substrato tem uma capacidade de banda e um atraso .

Outro grafo não direcionado ( ) modela a rede virtual. Cada nó requer uma capacidade de CPU . Cada enlace virtual tem um requisito

de banda e um atraso máximo permitido . A soma do atraso de todos

os enlaces físicos para qual um enlace virtual foi mapeado não pode exceder . A

capacidade de banda de cada enlace físico deve ser respeitada, dessa forma a banda

exigida por cada enlace virtual mapeado em um mesmo enlace físico não deve

ultrapassar Por fim, a soma da capacidade requerida de CPU de cada máquina

virtual alocada em um nó não pode exceder a capacidade deste nó físico.

Os nós físicos da rede substrato em que um nó virtual pode ser alocado são

definidos pelo conjunto , cujo enlace virtual ( ), onde são nós

virtuais é definido por ( ) e ( ) , que representam

respectivamente fonte e destino. Dois componentes são então requeridos para solucionar


51

o problema VNMP: Um mapeamento tal que ( ( )) e um

caminho na rede substrato iniciando em ( ( )) até ( ( )) para cada

cujo o atraso não exceda .

Em nosso caso, o objetivo é maximizar a disponibilidade da requisição virtual a

ser alocada. A disponibilidade do nó físico é dada por para todo . Os

enlaces da rede substrato utilizados no mapeamento de um enlace virtual

possuem disponibilidade . Com base no modelo RBD definido para modelar a

disponibilidade das requisições virtuais, a disponibilidade de cada requisição é dada

pela multiplicação da disponibilidade de cada nó e enlace físico usados no mapeamento

da rede virtual. Assim, a função objetivo é maximizar a disponibilidade das requisições

virtuais.

5. Heurística

Esta seção descreve a principal contribuição deste trabalho: uma heurística aleatória

adaptativa (intitulada HRA) utilizada para alocação de redes virtuais em uma topologia

física. A heurística proposta é fortemente inspirada na metaheurística conhecida como

GRASP (Greedy Randomized Adaptive Search Procedure) [Infuhr et al. (2013)]. No

entanto, difere em alguma de suas características, por exemplo, não apresenta nenhum

método de busca local. Sua função objetivo é maximizar a dependabilidade de cada

requisição no momento de sua alocação. A descrição por meio de um pseudocódigo é

importante para que outros pesquisadores consigam replicar os experimentos realizados.

Notem que, devido a questões de espaço, a representação aqui fornecida trata de uma

simplificação do algoritmo implementado de fato.

O seu funcionamento geral é dado pelo algoritmo da Figura 1:

Entrada: SN = grafo da rede substrato,

VNS = coleção de grafos de requisições virtuais,

LIMITE_TENTATIVAS = número inteiro que limita a quantidade de iterações

possíveis quando não se encontra solução

1. início

2. para i ← 1, .., |VNS| faça

3. allocated ← false

4. tentativas ← 0

5. enquanto (tentativas < LIMITE_TENTATIVAS) e (allocated == false) faça

6. allocated ← alocar_requisição(VNS[i], SN, LIMITE_TENTATIVAS)

7. tentativas ← tentativas + 1

8. fim-enquanto

9. fim-faça

10. fim

Figura 1 – Método principal

O passo-a-passo é bastante direto e deve ser autoexplicativo. Um ponto de

destaque é a chamada à subrotina alocar_requisição (Figura 1), na linha 6. Essa, por sua

vez, funciona de acordo com o seguinte algoritmo:

Entrada: VNR = grafo da requisição virtual a ser alocada, SN, LIMITE_TENTATIVAS

1 início

2. alocado ← true


52

3. nó_virtual ← escolher_nó_aleatoriamente(VNR)

4. alocado ← alocar_primeiro_nó(nó_virtual)

5. se (alocado == false) faça

6. retorne false

7. fim-se

8. nó_virtual_base ← nó_virtual

9. nós_pendentes ← []

10. faça

11. para i ← 1, .., |vizinhos(nó_virtual_base)| faça

12. nó_virtual_destino ← vizinhos(nó_virtual_base)[i]

13. alocado ← alocar_nós(nó_virtual_base, nó_virtual_destino, SN, LIMITE_TENTATIVAS)

14. se (alocado == false) faça

15. retorne false

16. fim-se

17. nós_pendentes ← adicionar_elemento(nós_pendentes, nó_virtual_destino)

18. nós_pendentes ← remover_elemento(nós_pendentes, nó_virtual_base)

19. nó_virtual_base ← escolher_nó_aleatoriamente(nós_pendentes)

20. fim-faça

20. enquanto (|nós_pendentes| > 0)

21. retorne true

22. fim

Figura 2 – Método alocar_requisição

O método alocar_requisição (Figura 2) é chamado para alocação de uma

requisição específica. Ela escolhe, de maneira aleatória, um nó virtual inicial para dar

prosseguimento à alocação dos nós restantes. Após a alocação do primeiro nó virtual em

um nó físico, é realizada uma busca em largura para alocação dos nós virtuais vizinhos

(linhas 11 a 20). É importante salientar que a alocação é feita em pares pela subrotina

alocar_nós (linha 13).

O pseudocódigo da Figura 3 descreve alocar_nós, que usa uma lista de nós

físicos que podem acomodar uma possível alocação do nó virtual recebido na entrada. A

partir dessa lista é realizada uma busca adaptativa aleatória na tentativa de maximizar a

dependabilidade para o segmento da rede a ser alocado (linhas 17 a 29). Vale salientar

que, ao maximizar a disponibilidade da alocação de dois nós virtuais e seus respectivos

enlaces, estamos também maximizando a disponibilidade da requisição -- dado que a

disponibilidade total é calculada através do produto das disponibilidades de todos os

componentes. Isso se dá primacialmente devido à utilização do modelo RBD em série

para o cálculo da dependabilidade.

Entrada: nó_virtual_base, nó_virtual_destino, SN, LIMITE_TENTATIVAS

1. início

2. nó_físico_origem ← nó_físico_subjacente(nó_virtual_base)

3. solução ← []

4. se (está_alocado(nó_virtual_destino) == false) faça

5. para i ← 1, .., |nós_físicos(SN)| faça

6. nó_físico ← nós_físicos(SN)[i]

7. se (pode_alocar(nó_físico, nó_virtual_destino)) faça

8. ok ← checar_caminho_mais_curto(nó_físico_origem, nó_físico, nó_virtual_destino)

9. se (ok) faça

10. solução ← adicionar_elemento(solução, nó_físico)

11. fim-se


53

12. fim-se

13. // Filtra a lista com os nós físicos que possuem a maior disponibilidade

14. solução ← melhores_nós_físicos(solução)

15. melhor_solução ← 0

16. tentativas ← 0

17. enquanto (tentativas < LIMITE_TENTATIVAS) faça

18. nó_físico ← escolher_nó_aleatoriamente(solução)

19. disponibilidade ← calcular_disponibilidade(nó_físico_origem, nó_físico, nó_virtual_destino)

20. se (disponibilidade > melhor_solução) faça

21. melhor_solução ← disponibilidade

22. nó_solução ← nó_físico

23. fim-se

24. tentativas ← tentativas + 1

25. solução ← remover_elemento(solução, nó_físico)

26. fim-enquanto

27. se (está_definido(nó_solução)) faça

28. alocado ← alocar_nó_e_caminho(nó_físico_origem, nó_solução, nó_virtual_destino)

29. fim-se

30. retorne alocado

31. fim-se

32. retorne true

33. fim

Figura 3 – Método alocar_nós

6. Metodologia

6.1. Estratégias de Mapeamento

Foram selecionadas as estratégias D-ViNE-SP [Chowdhury et al. (2012)] e G-SP [Zhu e

Ammar (2006)] para comparação com a heurística proposta. D-ViNE-SP e G-SP foram

escolhidos por utilizarem um algoritmo de alocação baseada em um único caminho na

rede de substrato - ao contrário das outras variações do D-ViNE que particionam um

único enlace virtual em caminhos físicos diferentes. Tais trabalhos foram discutidos

mais detalhadamente na seção de trabalhos relacionados. Uma vez que nenhuma dessas

estratégias considera restrição de atraso, nós simulamos uma versão modificada de

nossa heurística para desconsiderar o atraso e quantificar o impacto desta restrição, no

entanto não houve diferença estatística entre as simulações, por isso apenas um caso é

exibido na seção de resultados.

6.2. Parâmetros de Dependabilidade

Dependendo do tamanho e complexidade do sistema (dependências complexas), o

sistema pode ser representado por um modelo ou particionado em modelos menores,

que representam partes do sistema (i.e., subsistemas), que fornecem métricas para a

avaliação de todo o sistema. Dessa forma, podemos considerar a rede virtual como

vários subsistemas. Modelando as relações entre os componentes de rede, os

subsistemas tiveram a disponibilidade calculada usando RBD.

Consideramos que um nó físico é composto por três componentes: CPU, disco

rígido e memória RAM. Assumimos um sistema RBD em série para estes componentes,

dessa forma, obtemos a disponibilidade do nó físico através do produto da

disponibilidade dos componentes que o compõem. A rede virtual formada é também

modelada em um sistema RBD em série, sendo a disponibilidade da requisição virtual


54

dada pela multiplicação da disponibilidade dos nós físicos, nos quais os nós virtuais

foram mapeados, pela multiplicação da disponibilidade dos enlaces físicos - utilizados

para mapear os enlaces virtuais que conectam os nós virtuais. Seus MTTFs e MTTRs

são baseados em [Kim et al. (2009)][ Fernandes et al. (2012)] e são exibidos na Tabela

1 (em horas). Semelhante a Fernandes et al. (2012), números aleatórios foram gerados

uniformemente no intervalo [35,100] para cada componente da rede física a fim de

determinar o seu MTTF de forma aleatória. Este número representa o percentual a ser

considerado para o MTTF. Os MTTRs são mantidos os mesmos para todos os

componentes.

Tabela 1. MMTF e MTTR para componentes do nó e enlace físico

CPU Disco Rígido Memória RAM Enlace

MTTF (h) 2500000 200000 480000 19996

MTTR (h) 1 1 1 12

6.3. Simulação e Métricas

Para executar as estratégias D-ViNE-SP e G-SP utilizamos o simulador desenvolvido no

trabalho de Chowdhury et al. (2012). Para a nossa heurística desenvolvemos um

simulador próprio. As entradas contendo as redes de substrato e requisições físicas

foram retiradas de Infuhr et al. (2012). O benchmark utilizado como entrada é público e

possibilita fácil replicação dos experimentos realizados neste artigo, necessitando de

apenas algumas modificações: transformação do grafo direcionado em não direcionado

e acréscimo dos atributos de dependabilidade na topologia física. Foi necessário ainda

realizar a adaptação do simulador de Chowdhury et al. (2012) para adicionar atributos

de dependabilidade e computar a dependabilidade das requisições alocadas.

As requisições são alocadas de maneira sequencial sem que haja tempo de vida,

ou seja, a última requisição alocada leva a rede ao estresse máximo de utilização de

recursos. Realizamos 30 simulações para cada estratégia de alocação considerando

tamanhos de rede substrato com 20, 30, 50 e 100 nós. Para cada simulação houve 40

requisições com tamanho variável, de acordo com o crescimento da rede física. Notem

que estas características estão definidas nos arquivo de entrada do benchmark utilizado

disponível em Infuhr et al. (2013). As métricas coletadas são descritas na Tabela 2. Para

cada métrica foi calculado o intervalo de confiança com 95% de nível de confiança

podendo ser visualizado em cada gráfico exibido na seção de resultados.

Tabela 2. Métricas coletadas durante as simulações

Métrica Descrição

Média da disponibilidade por requisição Média da disponibilidade de um conjunto de

requisições virtuais

Taxa de aceitação Quantidade de requisições de redes virtuais aceitas

dividida pelo número total de requisições

Utilização dos nós físicos Média da carga de cada nó físico dividida por sua

respectiva capacidade

Utilização dos enlaces físicos Média da carga de cada enlace físico dividida por sua

respectiva capacidade


55

Tempo de simulação Quantidade de tempo de execução de cada simulação

As simulações foram executadas na máquina com as seguintes

configurações: CPU Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GH; Placa de

vídeo nVidia GTX 550 TI Memória DDR5 de 2GB; Memória RAM de 2GB DDR2;

Disco rígido de 250GB 5400rpm e sistema operacional LinuxMint Release 14 (nadia).

7. Resultados

Nos gráficos de resultados vamos nos referir à heurística proposta neste artigo como

HRA (Heurística Randômica Adaptativa). Como explicado na seção 6.1, executamos a

heurística HRA com e sem restrição de atraso e não obtivemos resultado

estatisticamente diferente em nenhuma métrica coletada. Por esse motivo, os gráficos de

resultados exibem apenas a abordagem que leva em consideração o atraso por ser mais

próxima de um cenário real.

7.1. Disponibilidade

Retirando a média de cada estratégia de alocação de acordo com o tamanho da

topologia física, podemos ver na Figura 4 que a heurística HRA obtém resultados

estatisticamente bastantes superiores em relação às estratégias G-SP e D-ViNE-SP. A

disponibilidade média de uma requisição em uma rede de 20 nós, utilizando a heurística

HRA, obteve disponibilidade média de 0.9895 e 0.9593 para uma rede com 100 nós. As

demais estratégias obtiveram disponibilidade em torno de 0.6 ou menos.

Figura 4. Disponibilidade média de uma requisição por estratégia de alocação de rede virtual

7.2. Taxa de Aceitação

Outra métrica importante a ser analisada diz respeito à capacidade de a estratégia

utilizada conseguir alocar o máximo possível de requisições recebidas. Analisando a

Figura 5, vemos que a estratégia HRA possui grande eficiência em conseguir alocar

todas as requisições virtuais recebidas. Mesmo com a variação do tamanho da topologia,

a probabilidade da taxa de aceitação com uma rede física de tamanho 100 foi de 0.9875.

O resultado da heurística HRA tem como um dos seus pilares a simples

estratégia de alocar, em um mesmo nó físico, um ou mais nós virtuais de uma mesma

requisição. Diferentemente de outras estratégias que restringem a alocação de nós

virtuais de uma requisição em nós físicos distintos. Dessa forma, analisando mais


56

detalhadamente em nosso simulador (heurística HRA) o comportamento do

mapeamento dos nós e enlaces virtuais, chegamos ao resultado de nenhuma rejeição por

falta de recurso em nós físicos da rede substrato. As poucas rejeições que ocorreram se

deram pela impossibilidade de formar um caminho que conectasse um dos nós da rede

virtual devido às restrições da requisição (banda ou atraso).

Figura 5. Taxa de aceitação

7.3. Utilização dos Nós

Analisando a utilização (carga/capacidade) média dos nós da rede substrato (Figura 6), a

heurística HRA obteve uma alta utilização dos nós quando comparada a outras

estratégias de alocação. Esse resultado é justificável devido a grande taxa de aceitação

das requisições pela heurística HRA e pelo fato de haver concentração de nós virtuais de

uma mesma requisição em um mesmo nó físico, fazendo com que haja uma utilização

maior nesse nó físico.

Figura 6. Utilização dos Nós físicos da rede substrato

7.4. Utilização dos Enlaces

Quando analisamos a utilização dos enlaces da rede substrato (Figura 7), vemos que

aparentemente a heurística HRA estressa menos os enlaces, mas devido ao intervalo de

confiança sobrepostos, temos resultados estatisticamente equivalentes. Um ponto a ser

destacado é que por alocar mais nós virtuais, a heurística HRA deveria ocupar mais

enlaces físicos após o mapeamento, e consequentemente aumentar a utilização média

dos enlaces físicos. No entanto, quando dois ou mais nós virtuais são alocados num

mesmo nó físico temos, provavelmente, a redução de um enlace virtual que ocuparia

recursos de enlaces físicos. Diferentemente das outras estratégias que não fazem uso

dessa abordagem de alocação.


57

Figura 7. Utilização dos Enlaces da rede substrato

7.5. Tempo de Execução

O tempo de execução médio de cada simulação pode ser visto na Figura 8 utilizando

uma escala medida em segundos. Pode-se observar que a heurística HRA resolve o

problema mais rapidamente na maioria das comparações, não sendo nunca mais lenta.

Note que o tempo de execução para a estratégia D-ViNe com 30 replicações numa

topologia de 100 nós o tempo de execução é de cerca de 10 horas, enquanto a heurística

HRA executa em aproximadamente 3 minutos.

Figura 8. Tempo médio de execução (segundos)

8. Discussão

A heurística HRA obteve resultados expressivos com bons índices de disponibilidade

quando comparada a outras estratégias de alocação bem referenciadas na literatura. Com

requisitos cada vez maiores por parte de clientes para utilização de serviços confiáveis e

acordos mais rígidos de SLAs (Service Level Agreement) a serem cumpridos pelos

provedores de infraestrutura, negligenciar atributos de dependabilidade não é uma

alternativa viável, dados os resultados apresentados neste trabalho.

Um ponto importante a ser destacado é que a heurística HRA possui uma nuance

em relação às outras estratégias comparadas: HRA permite a alocação de um ou mais

nós virtuais de uma mesma requisição virtual num mesmo nó físico. Embora simples

essa diferença mostrou-se significativa, dado que o objetivo da heurística HRA é

maximizar a dependabilidade. Não obstante, a heurística obteve resultados superiores na

taxa de aceitação de requisições e mesmo assim não produziu mais sobrecarga nos

enlaces da rede substrato quando comparada a outras estratégias.


58

Outro aspecto relevante é que ao simularmos os mapeamentos das requisições

ignorando a restrição de atraso não obtivemos diferenças significativas em nenhuma

métrica coletada quando comparamos o HRA com e sem restrição de atraso. Tal

resultado indica uma perspectiva de adaptação da heurística HRA mesmo neste tipo de

cenário. Por fim, por ser uma estratégia que pode ser considerada como gananciosa, a

heurística HRA foi mais rápida em encontrar soluções em praticamente todas as

comparações realizadas, não sendo em nenhum momento mais lenta que as estratégias

comparadas.

9. Conclusão

Este artigo apresentou uma heurística aleatória adaptativa para alocação de redes

virtuais considerando atributos de dependabilidade, requisitos e restrições de atraso,

CPU e banda. O objetivo da heurística é maximizar a disponibilidade de cada requisição

alocada.

A heurística proposta apresentou melhores resultados com as abordagens

comparadas em métricas importantes como taxa de aceitação e carga nos enlaces da

rede. A dependabilidade com o uso da heurística variou entre 95,93% e 98,95% de

acordo com o tamanho da topologia da rede substrato, enquanto outras abordagens se

mantiveram em 60% ou menos, demonstrando que ignorar esta característica torna a

alocação de uma requisição muito mais propensa à falha. Ou seja, comparando outras

estratégias com a heurística HRA, fica claro que o impacto sobre a dependabilidade

quando não se leva em consideração atributos de dependabilidade no processo de

alocação pode consequentemente ocasionar uma grande queda na confiabilidade das

redes virtuais alocadas.

Em trabalhos futuros pretendemos levar em consideração variação da

probabilidade de falha de um nó físico quando a carga desse nó aumenta, inserindo

ainda na modelagem do problema restrição de dependabilidade do cliente e/ou servidor.

Pretendemos utilizar ainda outras métricas de dependabilidade em experimentos futuros,

analisando o problema mais detalhadamente.

Referências

Benson, T., Sahu, S., Akella, A., & Shaikh, A. (2010) “A first look at problems in the

cloud”. 2nd USENIX conference on Hot topics in cloud computing (HotCloud'10)

Chowdhury, M., Rahman, M. R., & Boutaba, R. (2012). “ViNEYard: Virtual network

embedding algorithms with coordinated node and link mapping”. IEEE/ACM

Transactions on Networking (TON), 20(1), 206-219.

Ebeling, C. E. (1997) “An introduction to reliability and maintainability engineering”

(pp. 58-69). New York, NY: McGraw Hill.

Fernandes, S., Tavares, E., Santos, M., Lira, V., & Maciel, P. (2012) “Dependability

assessment of virtualized networks”. In Communications (ICC), 2012 IEEE

International Conference on (pp. 2711-2716). IEEE.

Fischer, A., Botero, J., Beck, M., De Meer, H., & Hesselbach, X. (2013) "Virtual

network embedding: A survey", in IEEE Communications Surveys & Tutorials.


59

Gill, P., Jain, N., & Nagappan, N. (2011) “Understanding network failures in data

centers: measurement, analysis, and implications”. In ACM SIGCOMM Computer

Communication Review (Vol. 41, No. 4, pp. 350-361). ACM.

Guimarães, A., Maciel, P., Matos Jr, R., & Camboim, K. (2011). Dependability analysis

in redundant communication networks using reliability importance. In The 2011

International Conference on Information and Network Technology.

Guo, T., Wang, N., Moessner, K., & Tafazolli, R. (2011) "Shared Backup Network

Provision for Virtual Network Embedding," Communications (ICC), IEEE International

Conference on, pp.1-5, 5-9

Infuhr, J., Raidl, G.R. (2012) "The Virtual Network Mapping Problem benchmark set",:

https://www.ads.tuwien.ac.at/projects/optFI/, acessado em Dezembro de 2012.

Infuhr, J., Raidl, G.R. (2013) "GRASP and Variable Neighborhood Search for the

Virtual Network Mapping Problem.", Hybrid Metaheuristics. Springer Berlin

Heidelberg, 2013. 159-173.

Lira, V. et al., "Virtual Network Resource Allocation Considering Dependability

Issues", In: IEEE 13th International Conference on Computer and Information

Technology (CIT2013), Sidney, 2013

Kim, D. S., Machida, F., & Trivedi, K. S. (2009) “Availability modeling and analysis of

a virtualized system”. In Dependable Computing, 2009. PRDC'09. 15th IEEE Pacific

Rim International Symposium on (pp. 365-371). IEEE.

Laprie, J. C. (1985). “Dependable computing and fault-tolerance”. Digest of Papers

FTCS-15, 2-11.

Maciel, P., Trivedi, K. S., Matias, R., & Kim, D. S. (2011). Performance and

Dependability in Service Computing: Concepts, Techniques and Research Directions,

ser. Premier Reference Source. Igi Global.

Nicol, D. M., Sanders, W. H., & Trivedi, K. S. (2004) “Model-based evaluation: from

dependability to security”. Dependable and Secure Computing, IEEE Transactions.

Saripalli, P., & Walters, B. (2010) “QUIRC: A Quantitative Impact and Risk

Assessment Framework for Cloud Security”. In Cloud Computing (CLOUD), 2010

IEEE 3rd International Conference on (pp. 280-288). IEEE.

Schaffrath, G., Werle, C., Papadimitriou, P., Feldmann, A., Bless, R., Greenhalgh, A.,

& Mathy, L. (2009) “Network virtualization architecture: proposal and initial

prototype”. (VISA '09). ACM, New York, NY, USA, 63-72.

Sun, D., et al. (2010) “A Dependability Model to Enhance Security of Cloud

Environment Using System-Level Virtualization Techniques”. In Pervasive Computing

Signal Processing and Applications (PCSPA), IEEE.

Trivedi, K. S. (2008) “Probability & statistics with reliability, queuing and computer

science applications”. John Wiley & Sons.

Zhou, Y., Li, Y., Sun, G., Jin, D., Su, L., & Zeng, L. (2010) "Game Theory Based

Bandwidth Allocation Scheme for Network Virtualization," IEEE GLOBECOM.

Zhu, Y., & Ammar, M. H. (2006) “Algorithms for Assigning Substrate Network

Resources to Virtual Network Components”. In INFOCOM (pp. 1-12).


60

Proposta de Modificacao da VMM-MIB para oGerenciamento de Roteadores Virtuais

Paulo R. P. Ferraz S.1, Rafael P. Esteves1, Lisandro Z. Granville1

1Instituto de Informatica – Universidade Federal do Rio Grande do Sul (UFRGS)Av. Bento Goncalves, 9500 – Porto Alegre, RS – Brasil

{paulo.ferraz, rpesteves, granville}@inf.ufrgs.br

Abstract. In network virtualization environments (NVEs), the physical infras-tructure is shared among different users (or service providers), which createmultiple virtual networks. Virtual Routers (VRs) are created inside physicalrouters supporting virtualization. The management of NVEs is currently defi-cient because of the lack of standard management solutions for heterogeneoussubstrates. Thus, the most natural choice is to use SNMP, the de facto networkmanagement protocol. The first approach to manage VRs using SNMP, the VR-MIB, did not progress in the standardization path, leaving the area with noSNMP-based solution. Recently, IETF has proposed a VMM-MIB for virtualmachine management that can be extended in order to support VR management.In this paper, we propose extensions to VMM-MIB to allow full VR management.These extensions enable complete configuration of VRs. In addition, we proposea VR management interface based on the extended VMM-MIB that can be usedto instantiate software-based VRs inside a virtualization plataform. We evaluatethe proposed management interface in terms of response time and CPU/memoryconsumption.

Resumo. Em ambientes de virtualizacao de redes (NVEs), a infraestruturafısica e compartilhada entre diferentes usuarios (ou prestadores de servicos),que criam multiplas redes virtuais. O gerenciamento de NVEs e atualmente defi-ciente, devido a falta de solucoes padroes para substratos heterogeneos. Assim,a escolha mais natural e a utilizacao do SNMP, o protocolo de gerenciamento derede de fato. A primeira abordagem para o gerenciamento de VRs, a VR-MIB,nao progrediu no caminho da padronizacao, deixando a area sem solucao base-ada em SNMP. Recentemente, o IETF propos a VMM-MIB para gerenciamentode maquina virtual, que pode ser estendida a fim de dar suporte ao gerencia-mento de VRs. Neste artigo, propomos extensoes para VMM-MIB para permitiro gerenciamento de VRs. Estas extensoes permitem a configuracao completa deVRs. Alem disso, propomos uma interface de gerenciamento de VRs baseadana VMM-MIB estendida que pode ser usada para instanciar VRs baseados emsoftware dentro de uma plataforma de virtualizacao. Nos avaliamos a interfacede gerenciamento proposta em termos do tempo de resposta e do consumo deCPU/memoria.


61

1. Introducao

A virtualizacao de redes surgiu como alternativa viavel para auxiliar no desenvolvimentode novas arquiteturas de rede e para ajudar a superar a ossificacao da Internet [Andersonet al. 2005]. Em um ambiente de virtualizacao de redes (em ingles, Network Virtualiza-tion Environment – NVE) as infraestruturas fısicas, chamadas de substrato, sao compar-tilhadas entre diferentes usuarios (ou provedores de servico) que criam multiplas redesvirtuais, cada uma delas utilizando protocolos, esquemas de enderecamento e polıticasindependentes. Ao contrario da virtualizacao de servidores, que normalmente esta loca-lizada nos nos de borda de um ambiente de rede, a virtualizacao de redes ocorre princi-palmente no nucleo. Dessa forma, roteadores virtuais sao criados e hospedados dentro deroteadores fısicos, possibilitando que varias redes independentes funcionem simultanea-mente, de forma isolada, sobre uma unica infraestrutura fısica [Chowdhury and Boutaba2009].

Atualmente, NVEs sao gerenciados por meio de interfaces de linha de comandonao padronizadas (em ingles, Command Line Interface -– CLI) ou atraves de ferramen-tas de gerenciamento proprietarias. Sendo assim, o gerenciamento de NVEs construıdossobre substratos fısicos heterogeneos (i.e., com equipamentos e tecnologias diferentes)fica prejudicado, pois varias ferramentas independentes sao necessarias para realizar umatarefa de gerenciamento, como por exemplo, criar uma rede virtual. Para minimizar a di-ficuldade de gerenciar um conjunto diversificado de recursos fısicos, interfaces de geren-ciamento padronizadas devem ser definidas e avaliadas para permitir a interoperabilidadedas diferentes plataformas de virtualizacao com as ferramentas de gerenciamento. Alemdisso, redes virtuais podem ser construıdas a partir de substratos localizados em domıniosadministrativos distintos [Chowdhury and Boutaba 2010] e precisam ser gerenciadas ade-quadamente. Assim, neste contexto, a escolha de um protocolo de gerenciamento capazde operar de forma eficiente e escalavel roteadores fısicos que hospedam roteadores vir-tuais e essencial.

Interfaces de gerenciamento apropriadas devem permitir que os provedores deinfraestrutura (InPs – Infraestructure Providers) e de servicos (SPs – Service Providers)possam acessar, operar, manter e administrar os nos e enlaces fısicos e virtuais [Esteveset al. 2013]. Em se tratando de interfaces baseadas em SNMP, existe a necessidadede MIBs Management Interface Base que suportem esses requisitos. No ano de 2001,foi proposta no IETF (como Internet Draft), uma MIB voltada para o gerenciamento deRoteadores Virtuais (VRs – Virtual Routers), denominada VR-MIB [Stelzer et al. 2003].Apesar de diversas atualizacoes, a VR-MIB nao se tornou um padrao e esta expiradadesde 2006. No entanto, recentemente, foi proposta uma MIB para o gerenciamento deMaquinas Virtuais (VMs), denominada VMM-MIB, mas sua proposta original nao preveo suporte necessario a configuracao de VRs.

O objetivo deste artigo e propor um conjunto de extensoes a VMM-MIB para queesta possa suportar o gerenciamento pleno de roteadores virtuais. Nossa abordagem ebaseada na utilizacao de roteadores virtuais baseados em software que podem ser emula-dos em maquinas virtuais. Sendo assim, as extensoes propostas consistem de objetos daVR-MIB adaptados para a VMM-MIB que permitem a configuracao de VRs. Alem disso,definimos um modelo de gerenciamento para NVEs baseado no SNMP e na plataformade gerenciamento XenServer [XenServer 2013].


62

O restante deste artigo esta organizado da seguinte forma. Na Secao 2, sao des-critas as MIBs VR-MIB e VMM-MIB, seus objetos e suas funcionalidades. Na Secao 3,apresentamos a proposta de modificacao da VMM-MIB, mostrando os objetos incluıdose os alterados. Nas Secao 4, e feita a avaliacao da principal funcionalidade agregada aVMM-MIB, a criacao de VRs. Finalmente, na Secao 5, concluımos o artigo e apresenta-mos direcoes para trabalhos futuros.


2.1. VR-MIB

Uma das primeiras iniciativas para o gerenciamento de redes com roteadores virtuais foia Virtual Router Management Information Base (VR-MIB) [Stelzer et al. 2005]. A VR-MIB foi proposta em 2001, originalmente para a gerencia de VPNs (Virtual PrivatedNetworks) de camada 3, mas foi descontinuada em 2006 e nao chegou a ser padronizada.

A VR-MIB define objetos para armazenar estatısticas e permitir a configuracaode alto nıvel de roteadores virtuais, como criacao, remocao e o mapeamento entre osroteadores virtuais e suas interfaces de rede virtuais.

O gerenciamento de roteadores virtuais necessita de objetos para possibilitar aconfiguracao de VRs, a coleta de estatısticas de VRs e a associacao de interfaces de redevirtuais com as fısicas [Daitx et al. 2011]. Na VR-MIB mais atual (L3VPN-VR-MIBversao 4), esses 3 grupos de informacoes foram definidos, respectivamente, como: vr-Config, vrStat e vrIfConfig.

O grupo vrConfig, mostrado na Figura 1(a), contem informacoes sobre indexacao,criacao e exclusao de VRs. Para ajudar a estacao de gerenciamento na atribuicao de umnovo VR sem conflito, o proximo identificador de VR disponıvel pode ser recuperadoacessando o objeto escalar vrConfigNextAvailableVrId do dispositivo gerenciado. Cadaconfiguracao de roteador virtual e armazenada em uma linha da tabela vrConfigTable,que contem um identificador unico (vrId), o nome do VR (vrName) e o status da linha(vrRowStatus), sendo este ultimo usado para criar e excluir os roteadores virtuais. Alemdisso, essa tabela contem informacoes sobre configuracoes internas de cada dispositivovirtual, como o identificador de VPN (vrVpnId), o numero maximo de rotas virtuais su-portadas (vrMaxRoutes) e um gatilho para ligar ou desligar os protocolos de roteamento(vrRpTrigger).

O grupo vrStat, mostrado na Figura 1(b), contem 2 objetos escalares cominformacoes globais de dispositivos, como o numero de VRs configurados em cada no(vrConfiguredVRs) e o numero de VRs ativos na rede (vrActiveVRs). Alem disso, estegrupo contem uma tabela chamada vrStatTable, que possui os status administrativo eoperacional de cada VR. Essa tabela contem diversas estatısticas como: o numero atualde entradas de rota (vrStatRouteEntries), o numero de entradas na FIB (Forwarding In-formation Base) (vrStatFIBEntries), o tempo decorrido apos o VR entrar em operacao(vrStatUpTime), o status operacional do VR (vrOperStatus), o tipo e o endereco IP deuma das interfaces do VR (vrRouterAddressType e vrRouterAddress).

O grupo vrIfConfig, mostrado na Figura 1(c), e composto por uma tabela usadapara a configuracao de interfaces de VRs (vrIfConfigTable). Esta tabela contem todasas associacoes entre os roteadores virtuais e as interfaces de rede fısicas, pois possui


63

como ındices da vrIfConfigEntry os identificadores vrId e vrIfId. Assim como na vr-ConfigTable, interfaces de roteadores virtuais podem ser criadas, excluıdas ou modifi-cadas editando-se a variavel vrIfConfigRowStatus. Este objeto e usado para acionar asoperacoes de criacao e remocao ou para definir o estado de operacao de cada uma dasinterfaces virtuais de VRs. A fim de definir uma nova interface de VR, o agente SNMPprimeiro verifica se o VR esta disponıvel e, em seguida, verifica se a interface de redeescolhida esta disponıvel.

(a) Grupo vrConfig (b) Grupo vrStat

(c) Grupo vrIfConfig (d) Grupo vrNotificationsPrefix

Figura 1. Grupos de informacoes da VR-MIB

Alem dos tres grupos supracitados, o grupo vrNotificationsPrefix (Figura 1(d))permite que o gerente ative ou desative traps manipulando a variavel vrTrapEnable databela vrConfigTable. Esse grupo e formado pelas traps: vrUp, vrDown e vrMaxRou-tesExceeded.

A principal desvantagem da VR-MIB e que ela deixou de ser atualizada em 2006,fato que desencoraja sua utilizacao em projetos atuais. Tambem nao ha MIB que substituasuas funcionalidades no que diz respeito a configuracao de roteadores virtuais. Sendoassim, a solucao mais rapida para este problema e procurar uma MIB atual que possaabsorver as funcionalidades da VR-MIB.

2.2. VMM-MIB

Em julho de 2012, foi proposta no IETF, como Internet Draft, uma MIB voltada para ogerenciamento de Maquinas Virtuais (VMs – Virtual Machines) controladas por um hy-


64

pervisor, com o tıtulo de Management Information Base for Virtual Machines Controlledby a Hypervisor, ou simplesmente VMM-MIB [Asai et al. 2013].

Um hypervisor, tambem conhecido como monitor de maquina virtual, controlavarias maquinas virtuais em uma unica maquina fısica, alocando recursos para cada VMusando tecnologias de virtualizacao. Portanto, este modulo MIB contem informacoessobre as maquinas virtuais e seus recursos controlados por um hypervisor, bem comoinformacoes de hardware e software do mesmo.

O projeto desta MIB foi derivado de modulos MIB especıficos de empresas, comoXen e VMWare, e de um modulo MIB que usava a interface de programacao libvirt paraacessar diferentes hypervisors. No entanto, esta MIB tenta generalizar os objetos geren-ciados para suportar outros hypervisors.

A VMM-MIB possui informacoes relativas ao sistema e software de um hypervi-sor, a lista de maquinas virtuais controladas, e recursos virtuais alocados para maquinasvirtuais. Sobre este ultimo, sao especificados nessa MIB quatro tipos especıficos de recur-sos virtuais comuns a todos os hypervisors: CPUs (processadores), memoria, interfacesde rede e dispositivos de armazenamento. A Figura 2 esquematiza os recursos fısicos evirtuais dentro do hypervisor, e destaca o agente SNMP, que e responsavel por manter aMIB informada.

Figura 2. Alocacao de recursos virtuais

A VMM-MIB esta organizada em um grupo de nove escalares e cinco tabelas. Osescalares organizados sob vmHypervisor (Figura 3) fornecem informacoes basicas sobreo hypervisor, como a descricao do software (vmHvSofteare), a versao (vmHvVersion),o identificador (vmHvObjectID) e o tempo desde que o hypervisor foi reinicializado(vmHvUpTime). Os demais objetos escalares sao: o vmNumber, que contem o numerode VMs no hypervisor; o vmTableLastChange, que e valor do vmHvUpTime da ultimacriacao ou exclusao de entrada na vmTable; o vmPerVMNotificationsEnable, que habi-lita a geracao de notificacoes por VMs; o vmBulkNotificationsEnable, que e semelhanteao anterior, mas para conjuntos de VMs; e o vmAffectedVMs, que contem a lista de VMsque tiveram seu estado alterado.

Em relacao as tabelas, temos: a vmTable (Figura 4(a)), que lista as VMs quesao conhecidas pelo hypervisor; a vmCpuAffinityTable (Figura 4(c)), que fornece a


65

Figura 3. Escalares do grupo vmHvSoftware da VMM-MIB

afinidade de cada processador virtual com uma CPU fısica; a vmStorageTable (Figura4(b)), que fornece a lista de dispositivos de armazenamento virtual e seu mapeamentocom maquinas virtuais; a vmCpuTable (Figura 4(c)), que fornece o mapeamento entreCPUs virtuais para maquinas virtuais; e a vmNetworkTable (Figura 4(d)), que fornecea lista de interfaces de rede virtuais e seu mapeamento para maquinas virtuais. As ta-belas vmTable e vmNetworkTable, por serem mais relevantes para este trabalho, seraodescritas com mais detalhes.

A tabela vmTable, mostrada na Figura 4(a), contem diversas informacoes sobreas VMs, sendo que as principais para este trabalho sao: um identificador unico da VM(vmIndex), o nome da VM (vmName), o estado administrativo (vmAdminState), o es-tado operacional da VM (vmOperState), o numero atual, mınimo e maximo de CPUsatribuıdas a VM (vmCurCpuNumber, vmMinCpuNumber e vmMaxCpuNumber) e otamanho atual, mınimo e maximo de memoria alocada para a VM (vmCurMem, vmMin-Mem e vmMaxMem). O objeto vmAdminState e um parametro que define o modelode estado administrativo da VM e, por isso, tem permissao read-write. Da mesma forma,por serem parametros de configuracao, tambem possuem permissao de acesso read-writeos objetos supracitados relacionados com CPU e memoria. Os demais objetos da tabelatem acesso read-only.

A tabela vmNetworkTable, mostrada na Figura 4(d), contem informacoes de in-terfaces de redes virtuais, como um identificador unico (vmNetworkIndex), um ponteiropara a interface corresponde na ifTable da IF-MIB [McCloghrie and Kastenholz 2000](vmNetworkIfIndex), outro ponteiro para ifTable da IF-MIB no caso de haver uma in-terface de rede fısica pai correspondente (vmNetworkParent), o modelo de interfaceemulado pela interface de rede virtual (vmNetworkModel), e o endereco fısico (MACAddress) (vmNetworkPhysAddress).

Eventos que causam transicoes entre os principais estados operacionais geramnotificacoes (traps). A VMM-MIB define dois tipos de notificacoes: as notificacoes in-dividuais (per-VM) e as notificacoes em massa (bulk). As per-VM levam informacoesmais detalhadas, contudo a escalabilidade pode ser um problema. Ja o mecanismo denotificacao em massa tem o objetivo de reduzir o numero de notificacoes que sao cap-turadas por um gerente SNMP. As notificacoes per-VM, definidas pelos objetos listadosna Figura 5(a), sao geradas se vmPerVMNotificationsEnable for verdadeiro. De modoanalogo, as notificacoes em massa, definidas pelos objetos da Figura 5(b), sao geradas sevmBulkNotificationsEnabled for verdadeiro.

3. Proposta de modificacao da VMM-MIBA ideia da proposta e agregar a VMM-MIB todas as funcionalidades da VR-MIB, sem quea primeira perca suas funcionalidades originais. Inicialmente, percebe-se que os escopos


66

(a) Tabela vrTable (b) Tabela vmStorageTable

(c) Tabelas vmCpuTable e vmC-puAffinityTable

(d) Tabela vmNetworkTable

Figura 4. Tabelas da VMM-MIB

das MIBs supracitadas sao diferentes, pois uma se refere a maquinas virtuais e a outra aroteadores virtuais. Felizmente, roteadores podem ser emulados por softwares, como porexemplo, o Vyatta [Vyatta 2013]. Sendo assim, maquinas virtuais executando o Vyattapodem ser consideradas, para todos os efeitos, um roteador virtual. Para isso, basta queo hypervisor seja executado dentro do roteador fısico. Desse modo, nao ha problemaem utilizar a VMM-MIB como base para uma MIB que possua as funcionalidades degerenciamento de VRs desejadas.

Inspirada na VR-MIB, esta proposta acrescenta a VMM-MIB duas tabelas paraconfiguracao de VMs (ou VRs): a vmConfigTable, que permitira a criacao/remocao deVMs; e a vmNetworkConfigTable, que permitira a criacao/remocao de interfaces de redevirtais e a associacao com as fısicas (binding). Alem disso, tres objetos escalares, parafins de controle, sao incluıdos: vmConfigNextAvailableVmIndex, vmConfiguredVMse vmActiveVMs, com as mesmas funcoes dos objetos da VR-MIB vrConfigNextAvai-lableVrId, vrConfiguredVRs e vrActiveVRs, respectivamente. A Figura 6 mostra, em


67

(a) Notificacoes per-VM (b) Notificacoes em massa

Figura 5. Objetos de notificacao da VMM-MIB

destaque, as tabelas e os objetos escalares incluıdos na nova VMM-MIB.

Figura 6. Objetos incluıdos na nova VMM-MIB

A tabela vmConfigTable proposta contem objetos com as mesmas funcionali-dades dos objetos da tabela vrConfigTable da VR-MIB. Alem disso, nesta proposta, osobjetos da tabela vmTable da VMM-MIB que possuıam permissoes read-write sao migra-dos para a vmConfigTable, pois esta tabela deve conter todos os objetos de configuracaode uma nova VM. Nesta migracao, as permissoes de acesso read-write sao trocadaspara read-create, de forma a permitir a criacao de novas entradas na tabela. Para evi-tar duplicacao, os objetos vmIndex e vmName sao retirados da tabela vmTable, postoque agora eles pertencem a vmConfigTable. A Figura 7 mostra a tabela vmConfigTableproposta e a origem de seus objetos.

A tabela vmNetworkConfigTable proposta contem objetos com as mesmas fun-cionalidades dos objetos da tabela vrIfConfigTable da VR-MIB. So com esses objetosja e possıvel agregar as funcionalidades de criacao e remocao de interfaces de rede vir-tuais, porem migrando-se os objetos vmNetworkIfIndex e vmNetworkParent da tabela


68

Figura 7. Objetos da tabela vmConfigTable proposta

vmNetworkTable da VMM-MIB para esta nova tabela, e possıvel associar a interfacevirtual a fısica (binding). Para permitir a criacao de entradas na tabela, seus objetos tempermissao read-create. A Figura 8 mostra a tabela vmNetworkConfigTable proposta e aorigem de seus objetos.

Figura 8. Objetos da tabela vmNetworkConfigTable proposta

Com a inclusao das tabelas vmConfigTable e vmNetworkConfigTable na VMM-MIB, ja e possıvel obter as funcionalidades de configuracao de alto-nıvel de roteadoresvirtuais oferecidas pela VR-MIB, porem, para abranger todas as informacoes estatısticasde roteadores virtuais, faz-se necessario, ainda, incluir na proposta objetos equivalentesaos da tabela vrStatTable da VR-MIB. Sendo assim, a tabela vmTable da nova VMM-MIB deve conter os objetos originais, exceto aqueles migrados para a tabela vmConfigTa-ble, e os novos objetos vmRouteEntries, vmFIBEntries, vmRpState, vmLoopbaclAd-dressType e vmLoopbackAddress, com as mesmas funcoes dos objetos da VR-MIBvrStatRouteEntries, vrStatFIBEntries, vrRpStatus, vrRouterAddressType e vrRou-erAddress, respectivamente. A Figura 9 mostra a tabela vmTable proposta e a origem deseus novos objetos.

Com relacao as notificacoes (traps), temos que a VMM-MIB possui uma grandequantidade de objetos referentes aos estados operacionais das VMs. Sendo assim, asnotificacoes vrUp e vrDown da VR-MIB ja sao abrangidas pela VMM-MIB, ainda quede forma mais detalhada. O unico objeto de notificacao que necessita ser incluıdo na pro-


69

Figura 9. Objetos da tabela vmTable proposta

posta e o vmMaxRoutesExceeded, equivalente ao vrMaxRoutesExceed da VR-MIB,pois trata-se de uma notificacao especıfica de roteadores, onde e informado que o numeromaximo de rotas foi excedido.

Nesta proposta, a tabela vmNetworkTable teve dois objetos migrados para a vm-NetworkConfigTable, portanto agora, esta tabela tem apenas os objetos vmNetwork-Model e vmNetworkPhysAddress, conforme mostrado na Figura 10. As tabelas vmC-puTable, vmCpuAffinityTable e vmStorageTable permanecem inalteradas.

Figura 10. Objetos da tabela

4. AvaliacaoDas diversas funcionalidades agregadas a VMM-MIB com as modificacoes propostas, acriacao de VRs e a mais significativa, pois a mesma nao e atualmente contemplada pelaVMM-MIB original. Sendo assim, esta secao, apresentada a avaliacao desta operacao emuma interface de gerenciamento baseada no SNMP.

4.1. Interface de Gerenciamento

A interface de gerenciamento implementada utiliza a comunicacao gerente-agentedo SNMPv2, conforme ilustrado na Figura 11. Para a criacao de um VR, o ge-rente SNMP envia uma mensagem set-request (T1) carregando as informacoes ne-cessarias para o agente criar o VR (i.e., vmRowState, vmName, vmContextName,vmTrapEnable, vmAdminState). Como reacao, o agente emite uma requisicao CLI(T2) ao hypervisor que efetivamente cria o roteador virtual (e.g., xe vm-installnew-name-label=<vm-name> template=vyatta, no caso do XenServer).


70

Como a acao do lado do roteador pode durar um tempo indefinido, o set-request e imedi-atamente respondido com uma mensagem get-response (T3). Quando a operacao solici-tada termina, uma mensagem de trap e emitida (T5), por um gerador de traps em execucaodentro do roteador fısico, informando que o roteador virtual foi criado com sucesso (T6).

Figura 11. Fluxo de mensagens da interface de gerenciamento baseada no SNMP

4.2. Descricao do AmbienteOs experimentos foram executados em um computador com processador Intel Core 2Quad 2,4GHz com 4GB de memoria RAM. Este computador foi configurado de modoa emular, para fins de avaliacao, um roteador fısico. A plataforma de virtualizacao (hy-pervisor) utilizada foi o Citrix XenServer 5.6 [XenServer 2013]. O template utilizado nacriacao de roteadores virtuais foi o Vyatta [Vyatta 2013].

O modulo VMM-MIB proposto, discutido na secao 3, foi compilado, instrumen-tado e adicionado ao agente disponibilizado no pacote NET-SNMP 5.5 (snmpd) [NET-SNMP 2013]. Operacoes SNMP sao materializadas atraves de aplicacoes do pacote NET-SNMP correspondentes as mensagens do protocolo, e.g., snmpset, snmpget e snmpget-bulk. Estas aplicacoes foram utilizadas para implementar o gerente SNMP. Alem disso, ainterface de gerenciamento foi avaliada utilizando-se a versao 2 do SNMP que e a versaomais popular do protocolo.

4.3. ResultadosO componente em estudo e a interface de gerenciamento descrita na secao 4.1, quetem como principal servico a criacao de VRs. Foram escolhidas duas metricas para aavaliacao: tempo de resposta e consumo de recursos pelo agente SNMP (CPU e memoria).O tempo de resposta reflete o tempo medio da criacao de VRs na solucao de gerencia-mento proposta. A utilizacao de CPU e de memoria RAM do roteador fısico ilustra oimpacto das operacoes de gerenciamento nos recursos do roteador fısico.

A carga de trabalho consiste na criacao de um VR adicional quando um numero deVRs previamente criados esta ativo (i.e., em operacao). O sistema comeca sem nenhumVR e a cada nova requisicao e criado um novo VR que permanece ativo, ate que se atinjao total de 10 VRs ativos. A restricao de 10 VRs ativos se da pelo fato de que esse foi olimite maximo suportado pela maquina utilizada nos testes.

Para esta avaliacao foram conduzidos experimentos no ambiente de teste descrito,utilizando a medicao como tecnica de avaliacao. Cada experimento foi repetido 30 ve-


71

zes sob as mesmas condicoes, a fim de se obter as medias populacionais com os seusrespectivos intervalos de confianca. Para isto, foi utilizado um nıvel de confianca de 95%.

A Figura 12 ilustra o tempo de resposta (em segundos) na criacao de 1 VR quandoum numero variavel de VRs (0 ate 10) esta ativo.

3.15

3.2

3.25

3.3

3.35

3.4

3.45

3.5

3.55

3.6

3.65

1 2 3 4 5 6 7 8 9 10

Tem

po d

e re

spos

ta [

segu

ndos

]

Número de Roteadores Virtuais ativos

XenServer

Figura 12. Criacao de Roteador Virtual

E possıvel observar que, de uma maneira geral, o tempo de resposta cresce quandoo numero de VRs ativos aumenta. Isso acontece pelo fato de que os VRs ativos comparti-lham e consomem recursos da maquina fısica (CPU e memoria), que estarao disponıveisem menor quantidade nas proximas requisicoes, o que influencia no aumento do tempode resposta na criacao de um novo VR. A excecao ocorre para quando 10 VRs estaoativos. O que ocorre aqui e que a maquina fısica nao consegue suportar a carga de 10VRs ativos simultaneamente (por falta de memoria) e o hypervisor suspende alguns VRsarbitrariamente.

Em seguida, foi avaliado o consumo de CPU e memoria pelo agente SNMP(snmpd). Verificou-se que o tempo de CPU do agente SNMP nao apresenta mudancassignificativas quando o numero de VRs ativos aumenta ate 10 VRs, permanecendo na or-dem de 40 millissegundos, o que indica que o agente e capaz de armazenar dados de 10VRs sem prejuızo significativo. A Figura 13 mostra o consumo de memoria do agenteSNMP na criacao de VRs.

Os resultados da Figura 13 mostram o percentual de consumo de memoria doagente SNMP em relacao ao total disponıvel na maquina fısica quando um novo VR cri-ado, variando o numero de VRs ativos. Novamente, o consumo de memoria do agentecresce quando o numero de VRs ativo cresce. A primeira razao e que a quantidade dememoria disponıvel na maquina fısica diminui a cada novo VR criado, e, consequente-mente, a relacao entre a memoria requerida pra processar uma mesma mensagem set-request em relacao ao total disponıvel tambem diminui. A segunda razao se deve ao fatode que o agente precisa armazenar uma quantidade de informacoes cada vez maior a cadanovo VR, o que exige mais memoria do agente SNMP.


72

0.899

0.9

0.901

0.902

0.903

0.904

0.905

0.906

0.907

0.908

0.909

1 2 3 4 5 6 7 8 9 10

Mem

ória

con

sum

ida

[%]

Número de Roteadores Virtuais ativos

XenServer

Figura 13. Consumo de Memoria RAM

5. Conclusao

Neste trabalho foi apresentada uma proposta de modificacao da VMM-MIB para tor-nar esta MIB funcional para o gerenciamento de roteadores virtuais em ambientes devirtualizacao de redes (NVEs). A VMM-MIB e uma proposta recente, que vem sido atu-alizada desde 2012. Sendo assim, optou-se por agregar funcionalidades propostas para aVR-MIB a VMM-MIB e, assim, permitir a criacao de roteadores virtuais.

Todos os objetos da vrConfigTable da VR-MIB foram incluıdos na nova tabelavmConfigTable da VMM-MIB, com os nomes devidamente adaptados para o padrao daVMM-MIB, mas mantendo-se as permissoes originais (read-create). Da mesma forma,todos os objetos da tabela vrIfConfigTable da VR-MIB foram adicionados a nova tabelavmNetworkConfigTable da VMM-MIB. Alem disso, todos os objetos escalares da VR-MIB foram incluıdos na nova VMM-MIB, de forma a permitir o controle dessas tabelasda mesma maneira que na VR-MIB. Para nao perder as informacoes estatısticas dos rote-adores virtuais criados, tambem foram incluıdos na tabela vmTable da proposta todos osobjetos da tabela vrStatTable, apesar de alguns deles ja existirem na VMM-MIB original.

Uma interface de gerenciamento baseada nas extensoes propostas para a VMM-MIB foi implementada e avaliada. Os resultados mostram que a memoria e o recursoque exerce maior influencia sobre o tempo de resposta de uma operacao de criacao deVRs. Quando o numero de VRs aumenta, o agente SNMP consome mais memoria, o queimpacta no tempo necessario para a criacao de novos VR. O consumo de CPU do agenteSNMP nao se mostrou significativo e nao tem grande influencia no tempo de resposta.

Como trabalhos futuros, pretende-se avaliar outras operacoes de gerenciamentocomo recuperacao do estado de VRs, remocao e copia de VRs, alem de adaptar a VMM-MIB estendida para outros protocolos de gerenciamento como NETCONF e Web services.

Referencias

Anderson, T., Peterson, L., Shenker, S., and Turner, J. (2005). Overcoming the internetimpasse through virtualization. Computer, 38(4):34–41.


73

Asai, H., MacFaden, M., Schoenwaelder, J., Sekiya, Y., Shima, K., Tsou, T., Zhou, C.,and Esaki, H. (2013). Management Information Base for Virtual Machines Controlledby a Hypervisor. http://tools.ietf.org/html/draft-asai-vmm-mib-05. Internet draft.

Chowdhury, N. M. M. K. and Boutaba, R. (2009). Network virtualization: state of the artand research challenges. Communications Magazine, 47(7):20–26.

Chowdhury, N. M. M. K. and Boutaba, R. (2010). A survey of network virtualization.Computer Network, 54(5):862–876.

Daitx, F., Esteves, R., and Granville, L. (2011). On the use of SNMP as a management in-terface for virtual networks. In Integrated Network Management (IM), 2011 IFIP/IEEEInternational Symposium on, pages 177–184.

Esteves, R., Granville, L., and Boutaba, R. (2013). On the management of virtualnetworks. Communications Magazine, IEEE, 51(7).

McCloghrie, K. and Kastenholz, F. (2000). The Interfaces Group MIB. RFC 2863 (DraftStandard).

NET-SNMP (2013). http://www.net-snmp.org/. Acessado em novembro de 2013.

Stelzer, E., Hancock, S., Schliesser, B., and Laria, J. (2003). Virtual Router ManagementInformation Base Using SMIv2. http://tools.ietf.org/html/draft-ietf-ppvpn-vr-mib-05.Internet draft.

Stelzer, E., Hancock, S., Schliesser, B., and Laria, J. (2005). Virtual Router ManagementInformation Base Using SMIv2. http://tools.ietf.org/html/draft-ietf-l3vpn-vr-mib-04.Internet draft.

Vyatta (2013). Vyatta.org community. http://www.vyatta.org/. Acessado em outubro de2013.

XenServer (2013). Open source virtualization. http://www.xenserver.org/. Acessado emoutrubro de 2013.


74

Uma Análise Quantitativa do Tráfego de Controleem Redes OpenFlow

Pedro Heleno Isolani, Juliano Araujo Wickboldt, Cristiano Bonato Both,Juergen Rochol, Lisandro Zambenedetti Granville

1Instituto de Informática – Universidade Federal do Rio Grande do Sul (UFRGS)Caixa Postal 15.064 – 91.501-970 – Porto Alegre – RS – Brazil

{phisolani, jwickboldt, cbboth, juergen, granville}@inf.ufrgs.br

Resumo. Software-Defined Networking é um paradigma de redes que permitefacilmente projetar, desenvolver e implantar inovações de rede, pois forneceagilidade e flexibilidade na incorporação de novos serviços e tecnologias. Asredes baseadas nesse paradigma ganharam destaque a partir da especificaçãodo protocolo OpenFlow, que define uma simples interface de programação paracontrolar dispositivos de encaminhamento a partir de um controlador. Ape-sar da rápida disseminação desse protocolo, os trabalhos relacionados sobreOpenFlow não analisam em profundidade os reais impactos das mensagens decontrole e monitoramento gerado por esse protocolo. Desta forma, a principalcontribuição deste artigo é uma análise quantitativa do tráfego de controle emonitoramento em redes OpenFlow. Os resultados revelam que variações dotempo limite de ociosidade das regras de encaminhamento, da frequência demonitoramento e da topologia da rede, impactam na taxa de transferência e naquantidade de mensagens geradas no canal de controle.

1. IntroduçãoSoftware-Defined Networking (SDN) é um paradigma de redes baseado em três aspec-tos fundamentais: (i) os planos de controle e encaminhamento são claramente desaco-plados, (ii) a lógica da rede é abstraída de uma implementação em hardware para umacamada de software programável e (iii) é introduzido um elemento controlador de redeque coordena as decisões de encaminhamento dos demais dispositivos [Kim e Feamster2013,Tootoonchian e Ganjali 2010]. A utilização desses três aspectos de forma integrada,permite que inovações de redes possam ser mais facilmente projetadas, desenvolvidas eimplantadas, pois possibilita a agilidade e flexibilidade na incorporação de novos serviçose tecnologias, sem que os fabricantes precisem expor o funcionamento interno de seusequipamentos [McKeown et al. 2008].

As redes baseadas no paradigma SDN ganharam considerável destaque a partir daespecificação do protocolo OpenFlow, que define uma simples interface de programaçãopara controlar dispositivos de encaminhamento a partir de um controlador. Desta forma, alógica da rede é concentrada no controlador que troca mensagens para o estabelecimentode conexões, monitoramento de estatísticas, manutenção e configuração do comporta-mento dos dispositivos da rede [Bari et al. 2013]. Sendo assim, o gerenciamento de redebaseadas na especificação OpenFlow reduz, ou até mesmo elimina, problemas de geren-ciamento de redes tradicionais intrinsecamente [Kim e Feamster 2013]. Por exemplo,tarefas como a descoberta de rede são resolvidas simplesmente pelo fato de que os dispo-sitivos precisam ser registrados no controlador para pertencerem à rede efetivamente.


75

Devido a abordagem centralizada da lógica da rede, utilizada pelo protocolo Open-Flow, muito tem sido discutido na literatura especializada acerca do posicionamento eproporção de controladores em contraponto aos dispositivos de encaminhamento. Al-ternativas para distribuir a lógica da rede sobre os dispositivos de encaminhamento sãodesenvolvidas visando evitar um possível gargalo de mensagens de controle no controla-dor [Roy et al. 2014,Curtis et al. 2011,Yu et al. 2010]. Entretanto, não são analisados emprofundidade os reais impactos das mensagens de controle e monitoramento gerado peloprotocolo OpenFlow. A especificação desse protocolo apenas define quais e como são asmensagens de controle (e.g. instalação de regras, coleta de estatísticas), mas não espe-cifica como essas mensagens devem ser utilizadas para controlar e monitorar a rede semcomprometer seu desempenho. Assim, as informações referentes a frequência em quepodem ser realizados o controle e monitoramento de estatísticas dos dispositivos da redenão são especificadas. Desta forma, se torna fundamental a realização de uma análise paraidentificar quais mensagens de controle e monitoramento mais impactam na sobrecargado canal de controle em uma rede baseada em SDN e OpenFlow.

A principal contribuição deste artigo é uma análise quantitativa do tráfego de con-trole e monitoramento em redes OpenFlow. Essa análise é extremamente importante, poisfornece subsídios para mensurar o uso efetivo do canal de controle e, a partir disso, me-lhor compreender e gerenciar o impacto real da utilização do protocolo OpenFlow. Essacompreensão é fundamental para o projeto e desenvolvimento de novos sistemas de ge-renciamento de redes baseadas no paradigma SDN. Para a obtenção dos resultados, foirealizada uma experimentação considerando aspectos de instalação de regras, além daobtenção de estatísticas através do monitoramento do controlador Floodlight [Big SwitchNetworks 2014]. O ambiente experimental foi emulado no Mininet [Lantz et al. 2010],simulando o tráfego de streamming de vídeo e requisições de páginas Web em duas dife-rentes topologias de rede, estrela e árvore. Os resultados apresentam como a frequênciade monitoramento, as variações das topologias e configurações do controlador impactamna taxa de transferência e na quantidade de mensagens geradas no canal de controle.

O restante deste trabalho está organizado da seguinte forma. A Seção 2 apresentaa fundamentação teórica sobre SDN bem como sobre o protocolo OpenFlow. Na Seção3 é descrito o cenário de experimentação e a metodologia de avaliação seguida comoprova de conceito. Na Seção 4 são discutidas e analisadas as informações abstraídasda modelagem analítica e dos resultados da experimentação. Por fim, na Seção 5 sãoapresentadas as conclusões e as perspectivas para trabalhos futuros.

2. Fundamentação TeóricaNesta Seção são abordados os elementos que definem os principais conceitos de SDNe OpenFlow, assim como é apresentada uma breve discussão da literatura em SDN. NaSubseção 2.1 são descritos as principais entidades presentes em SDN e OpenFlow con-siderando a versão 1.0 do protocolo. Posteriormente, na Subseção 2.2 são abordados ostrabalhos relacionados sobre gerenciamento e, principalmente, distribuição do plano decontrole em SDN.

2.1. Software-Defined Networking e OpenFlowSDN introduz uma perspectiva flexível para programar e manter a operacionalidade darede. Em SDN, existe uma clara separação entre os planos de controle e encaminha-


76

mento. Além disso, a lógica é abstraída dos dispositivos de encaminhamento para umou mais elementos controladores da rede [Kim e Feamster 2013, Tootoonchian e Ganjali2010]. A arquitetura definida para SDN é dividida em camadas de aplicação, controlee encaminhamento. A comunicação entre as camadas acontece através de ApplicationProgramming Interfaces (APIs) de comunicação padrão. Redes que seguem o paradigmaSDN proporcionam vantagens em termos de gerência e controle da rede, principalmente,pela visão global da rede e pela flexibilidade e agilidade na incorporação de novos ser-viços. Outro aspecto que também contribui para a larga adoção desse paradigma é aliberdade de implementação e experimentação de novos protocolos sem se ater a detalhesde implementações proprietárias dos dispositivos. SDN foi largamente utilizado após aespecificação do protocolo OpenFlow [McKeown et al. 2008] e, devido a flexibilidade einterface simples de programação, surgiram diversas soluções tanto na academia como naindústria.

O OpenFlow é um protocolo Open Source que utiliza uma tabela para armazena-mento de regras de encaminhamento e uma interface padronizada para adicionar e remo-ver essas regras [McKeown et al. 2008]. Neste contexto, uma regra de encaminhamento éum conjunto de matches e actions instalados em um switch para implementar um fluxo ouparte dele, i.e. uma conexão lógica, normalmente, bidirecional entre duas máquinas ter-minais da rede. OpenFlow oferece programabilidade padronizada aos dispositivos de en-caminhamento, permitindo desenvolver novos protocolos, e.g., protocolos de roteamento,módulos de segurança, esquemas de endereçamento, alternativas ao protocolo IP, sem anecessidade de ser exposto os funcionamentos internos dos equipamentos. Um switchcom suporte OpenFlow consiste basicamente em pelo menos três partes: uma tabela defluxos, onde são associadas actions para cada match; um canal seguro, por exemplo Se-cure Socket Layer (SSL); e o protocolo OpenFlow para comunicação entre controlador eos switches.

O protocolo OpenFlow versão 1.0, abordado na análise deste trabalho e ampla-mente implementado pelos dispositivos com suporte a SDN, considera três tipos de men-sagens de controle: (i) do controlador para o switch, (ii) assíncronas e (iii) simétricas.As mensagens do controlador para o switch são utilizadas para gerenciar o estado dosdispositivos de encaminhamento (e.g., ler informações de estatísticas das tabelas de en-caminhamento). As mensagens assíncronas são iniciadas pelos switches utilizadas parainformar ao controlador sobre as modificações na rede e no estado desses dispositivos(e.g., chegada de novos fluxos na rede para o qual o switch não possui um match corres-pondente). Por fim, as mensagens simétricas podem ser iniciadas tanto pelo controladorcomo pelos switches e são enviadas sem solicitação (e.g., echo request e reply para certifi-car que um dispositivo da rede está ativo). O detalhamento das mensagens é apresentadona Tabela 1.

Apesar de todas as mensagens impactarem no tráfego gerado no canal de controle,as mensagens de coleta de estatísticas Read-State e de instalação de regras de encaminha-mento Packet-In/Out e Modify-State são consideradas as mais relevantes, pois são maisfrequentemente utilizadas pelo controlador e dispositivos de encaminhamento. Portanto,a partir da análise dessas mensagens, é possível identificar o impacto e definir o nível degranularidade de um possível monitoramento periódico da rede.


77

Tipos Mensagens Descrição

Controlador para o switch

Features Enviadas para obter conhecimento sobre as capacidades dos switchesConfiguration Específicas para parâmetros de configuração dos switches

Modify-StateGerenciam o estado dos switches, comumente utilizadas para adicionar,remover e modificar fluxos nas tabelas e alterar propriedades de portas

Read-StateUtilizadas para coletar estatísticas sobre as tabelas, portas, fluxos e filas dosswitches

Send-Packet Utilizadas pelo controlador para enviar pacotes por uma porta específica

BarrierObtenção de conhecimento se as dependências das mensagens foramalcançadas ou para receber notificações sobre tarefas concluídas

Assíncrona

Packet-In Enviadas ao controlador toda vez que o switch não tenha regra instalada paradeterminado pacote ou quando a regra for para enviar o pacote ao controlador

Flow-Removed Relativas a remoção de regras dos switchesPort-Status Obtenção de status das portas dos switches

Simétrica

Hello Para início de conexão entre switch e controlador

EchoEstabelecimento de conexão entre switch e controlador e podem ser utilizadaspara obter conhecimento de latência, banda ou conectividade

BarrierUtilizadas para obter conhecimento se as dependências das mensagens foramalcançadas ou para receber notificações sobre tarefas concluídas

Tabela 1. Mensagens de controle do protocolo OpenFlow versão 1.0

2.2. Trabalhos Relacionados

Existem pesquisas que investigam o problema de gargalos no canal de controle entreo controlador e os dispositivos de encaminhamento. A solução amplamente adotada édescentralizar o controle para a rápida e ágil reação a possíveis modificações no compor-tamento da rede, sem que seja necessário recorrer a um único elemento controlador [To-otoonchian e Ganjali 2010]. Entretanto, ainda existem discussões sobre o gerenciamentocentralizado e distribuído do controle da rede, visto que, pode influenciar e comprometera disponibilidade do canal de controle [Levin et al. 2012]. Devido a esse fato, a análise re-alizada neste trabalho foi inspirada pela ausência de informação referente ao impacto dasmensagens de controle na configuração, manutenção e monitoramento dos dispositivos deencaminhamento.

A solução apresentada por DevoFlow visa manter os fluxos no plano de encami-nhamento, ou seja, faz com que os switches encaminhem os pacotes com o mínimo desolicitações possíveis ao controlador [Curtis et al. 2011]. Quando uma regra não se en-contra na tabela de regras de um switch, o comportamento padrão do OpenFlow é invocaro controlador, encapsulando o pacote e o enviando para descoberta da regra apropriada.DevoFlow evita esse processo através da delegação de controle aos switches na clona-gem de regras, acionamento de actions locais e pela coleta de estatísticas. Para justificaro propósito do trabalho, foram apresentadas estimativas de sobrecargas da utilização doOpenFlow. Entretanto, o trabalho apresenta somente estimativas médias o que pode variardependendo do tipo da rede.

Uma solução semelhante ao DevoFlow é a apresentado por DIFANE, que visamanter a lógica de controle próxima ao plano de encaminhamento, de forma a atribuir ocontrole aos switches próximos ao controlador, chamados de switches de autoridade [Yuet al. 2010]. Quando uma regra não se encontra na tabela de regras de um switch ocomportamento é invocar um switch de autoridade mais próximo. Ambos os trabalhos,DevoFlow e DIFANE, apresentam informações relativas a sobrecargas geradas no contro-lador, mas não detalham sobre o impacto específico das mensagens trafegadas no canalde controle.


78

A solução de Heller et al. [Heller et al. 2012] investiga o posicionamento e pro-porção de controladores necessários para atender ao plano de encaminhamento sem com-prometer o desempenho da rede. Para estimar o consumo de banda utilizada no canal decontrole, foram estabelecidas as métricas de latência média e latência para o pior casopara comunicação entre controlador e dispositivos de encaminhamento. Entretanto, o cál-culo realizado para essa estimativa é aproximado conforme a distância dos nodos em umgrafo e não proporcional ao uso ou ao tipo das mensagens trafegadas no canal de controle.Nesse contexto, Bari et al. [Bari et al. 2013] propuseram uma ferramenta que adapta aquantidade de controladores necessários para determinada demanda da rede. Para realizaressa adaptação é calculado um valor aproximado do tempo mínimo para instalação deregras nos dispositivos de encaminhamento.

A análise realizada neste trabalho visa fornecer subsídios sobre o impacto do trá-fego de controle e monitoramento para futuros projetos de ferramentas de gerenciamentono contexto de OpenFlow versão 1.0. Portanto, a definição da quantidade de contro-ladores necessários, posicionamento em relação aos dispositivos de encaminhamento egranularidade de monitoramento aceitável podem ser estimadas e melhor abordadas pelossistemas de gerenciamento. Assim, pretende-se estimar o tráfego de controle para que nãocomprometa o desempenho e a disponibilidade do canal de controle e, consequentemente,o desempenho da rede.

3. Cenário e Metodologia de AvaliaçãoNesta Seção é apresentado em detalhes o cenário de experimentação e a metodologiautilizada para a análise quantitativa do tráfego de controle e monitoramento em redesOpenFlow versão 1.0. As características sobre o cenário e as duas topologias utilizadasna experimentação (estrela e árvore) são apresentadas na Subseção 3.1. Em seguida, naSubseção 3.2, a metodologia utilizada para obtenção dos resultados da análise é apresen-tada, incluindo métricas, parâmetros e fatores utilizados na experimentação.

3.1. CenárioO cenário de experimentação inclui uma rede emulada no Mininet [Lantz et al. 2010] comOpen vSwitches operando em modo kernel e um controlador Floodlight versão 0.90 [BigSwitch Networks 2014] gerenciando a rede como um elemento externo. Tanto a redeemulada como o controlador Floodlight se encontram na mesma máquina física em queforam realizadas as experimentações. As experimentações foram realizadas dessa formapara que não haja uma latência adicional entre o controlador e os switches emulados noMininet. Cada experimento foi realizado em duas topologias: (i) uma em estrela comum switch, seis máquinas, um servidor de arquivos e um servidor de stream e (ii) umaem árvore com profundidade três e largura dois, constituída por sete switches. Assimcomo a topologia estrela, a topologia em árvore é constituída por seis máquinas, umservidor de arquivos e um servidor de stream de vídeo. O posicionamento dos servidoresestão localizados nas extremidades da rede. Na Figura 1 pode-se observar as topologiasutilizadas para as experimentações.

Para a realização da coleta das informações relativas ao tráfego de controle e mo-nitoramento, foram necessárias modificações no módulo gerenciador de estatísticas exis-tente no controlador Floodlight. Essas modificações foram realizadas, pois esse controla-dor não possui uma maneira padrão de adquirir as informações relativas a estatísticas de


79

(a) Topologia em estrela (b) Topologia em árvore

Figura 1. Topologias de rede

uso do canal de controle. Uma vez realizadas tais modificações, é possível tanto coletarinformações a respeito do tráfego de dados como a respeito do tráfego de controle geradona rede. A partir disso, foram analisadas informações referentes a regras instaladas nosdispositivos, bem como o monitoramento de estatísticas nos switches da rede.

3.2. Metodologia de AvaliaçãoA análise quantitativa do tráfego de controle e monitoramento em redes OpenFlow versão1.0 é realizada considerando as métricas: (i) taxa de transferência média das mensagens demonitoramento para regras instaladas nos switches (Read-State), (ii) taxa de mensagensdo tipo Packet-In processadas por segundo pelo controlador e (iii) taxa de mensagens dotipo Packet-Out/Modify-State processadas pela rede. Essas métricas foram escolhidas como intuito de avaliar a quantidade de mensagens enviadas em função do tempo, tanto paramensagens enviadas para o controlador como para os dispositivos da rede. Os parâmetrosde experimentação são fixados para todos os experimentos realizados e estão dispostos naTabela 2. Utilizando sempre os mesmos parâmetros nos experimentos, é possível elaborarvariações de cenários e gerar resultados que sejam comparáveis.

Toda a experimentação foi realizada em uma única máquina com sistema opera-cional Linux Ubuntu 12.10 64-bit com processador Intel R© CoreTM 2 Duo CPU E8400 @3,00GHz x 2 e 2Gb de memória RAM. O ambiente experimental foi emulado no Mininetversão 2.0.0. O software Apache versão 2.2.20 foi utilizado como servidor de arquivos. Otamanho médio dos arquivos transferidos foi configurado em 54 KB (conforme definiçãodo tamanho médio de uma página Web [3GPP2 2004]). O software VLC media player2.0.8 Twoflower foi utilizado como servidor de stream de vídeo utilizando os CodecsAdvanced Systems Format (ASF) e Windows Media Video (WMV) para uma duração dovídeo fixada em 2 minutos [Cheng et al. 2007]. Em ambos servidores foram utilizadoso protocolo HTTP. A largura de banda de todos os enlaces da rede foi fixada em 100Mb e as requisições dos arquivos e vídeos foram baseadas em uma função exponencialapresentada em mais detalhes na Tabela 2 (também com base em [3GPP2 2004]).

Já os fatores a serem variados nos experimentos compreendem: (i) o intervalo detempo entre monitoramentos que varia em 1, 5 e 10 segundos, (ii) tempo de ociosidadede regras de encaminhamento (tempo que uma regra fica instalada em um switch antes deser descartada por inatividade) em 1, 30 e 60 segundos e (iii) as respectivas topologias (a)e (b) apresentadas na Subseção 3.1. Para os experimentos relativos ao monitoramento de


80

Parâmetros de configuração ValoresTamanho médio do arquivo 54 KB

Codec de vídeo ASF/WMVDuração do vídeo 2 minutos

Protocolo de transmissão HTTPLargura de banda 100 Mb

Tempo entre requisições Função exponencial µ = 30 segundos, λ = 0.033

Tabela 2. Parâmetros de configuração dos servidores de arquivo e vídeo

estatísticas (mensagens Read-State) o tempo de ociosidade da regra foi fixado 5 segundos.Com isso, se pretende mostrar como variações do intervalo entre monitoramentos podeminfluenciar a precisão das informações obtidas da rede e o impacto dessas mensagens irãogerar no canal de controle. Nos experimentos realizados para instalação de regras de en-caminhamento (mensagens Packet-In/Out e Modify-State) o tempo entre monitoramentosé fixado em 1 segundo para obter os resultados no menor tempo possível.

As técnicas de avaliação utilizadas neste trabalho são a modelagem analítica docomportamento das mensagens de controle Read-State, Packet-In/Out e Modify-State eexperimentação para as mesmas mensagens. Para validar as experimentações realizadasa modelagem analítica foi conduzida inicialmente como forma de identificar a frequênciae impactos das mensagens no canal de controle, a fim de, inferir o comportamento darede de acordo com as topologias e tamanho das mensagens. A experimentação foi rea-lizada em duas topologias com o mesmo número de hosts, porém variando a disposiçãoe o número de switches da rede. Além disso, o estudo foi conduzido em duas etapas: (i)para as mensagens de Packet-In/Out e Modify-State foram variados os fatores de tempode ociosidade da regra e topologias e, (ii) para as mensagens de Read-State os fatores aserem variados foram a frequência de monitoramento e as topologias. A realização dessasvariações foram utilizadas, pois apresentam diferentes níveis de granularidade de moni-toramento e expiração das regras instaladas nos switches. Os experimentos realizadosseguiram o design fatorial completo [Jain 2008], onde são realizadas todas as combina-ções possíveis de fatores dentre os estabelecidos nas etapas (i) e (ii).

4. Análise dos ResultadosEsta seção apresenta os detalhes sobre as experimentações realizadas para avaliar o com-portamento do canal de controle para as mensagens de coleta de estatísticas (Read-State)e de instalação de regras de encaminhamento (Packet-In/Out e Modify-State). Como ma-neira de validação da experimentação foi realizada primeiramente uma modelagem analí-tica sobre o comportamento esperado dos experimentos em relação à atividade da rede eimplementação do controlador. Posteriormente, os resultados obtidos por experimentaçãosão apresentados e discutidos.

4.1. Modelagem AnalíticaEm relação às mensagens do tipo Read-State, existem duas variações que correspondem(i) as mensagens encaminhadas do controlador para o switch, requisitando por estatísticas,e (ii) as mensagens do switch para o controlador, informando as estatísticas coletadas. Asmensagens enviadas do controlador para os switches são chamadas de Stats Request e asenviadas dos switches de volta para o controlador são chamadas de Stats Reply. Com basena análise da especificação do protocolo OpenFlow é possível estabelecer o tamanho das


81

mensagens de Stats Request e Stats Reply baseado em características dos switches (e.g.,número de portas ou quantidade de tabelas) ou na quantidade de regras de encaminha-mento instaladas nos mesmos.

Todas as mensagens do tipo Read-State possuem um mesmo cabeçalho de tama-nho fixo de 12 bytes e uma parte variável (corpo da mensagem) cujo tamanho dependedo tipo de estatística requisitada ou dos dados coletados na resposta. Mensagens do tipoStats Request possuem tamanho previsível correspondente ao tipo de estatística requi-sitada, isto é, mensagens dos tipos Individual-Flow-Request, Aggregate-Flow-Request,Port-Request e Queue-Request incluem um corpo adicional correspondente a 44, 44, 8 e8 bytes, respectivamente. Mensagens de Description-Request e Table-Request não reque-rem mais informações para serem enviadas aos switches, portanto não adicionam bytes aopacote.

Já o tamanho do frame OpenFlow das mensagens Stats Reply varia tanto pelo tipode estatística coletada e quanto pela quantidade de informações retornadas. Mensagensde resposta de estatísticas por porta, por exemplo, incluem um corpo adicional de 104bytes para cada porta de cada switch da rede. Assumindo que um switch não varia asua quantidade de portas ao longo do tempo (em switches virtuais isso seria possível),um switch de 24 portas gera sempre mensagens de Stats Reply para estatísticas de portade 2058 bytes. No entanto, para estatísticas individuais por regras de encaminhamento(Individual-Flow-Stats), por exemplo, é significativamente mais complexo prever o ta-manho das mensagens, uma vez que a quantidade de regras instaladas em cada switchdepende do tráfego gerado na rede e da lógica de funcionamento do controlador.

Assumindo que cada fluxo de dados é uma conexão lógica, normalmente bidire-cional e unicast, entre dois endpoints/hosts da rede que passa por um conjunto de dis-positivos de encaminhamento (caminho do fluxo) e que pelo menos duas regras de en-caminhamento precisam ser instaladas em cada switch para estabelecer o fluxo de dados(regras de ida e de volta), a Equação 1, 2 e 3 representam genericamente a sobrecarga demonitoramento (SM ) gerada por mensagens de Stats Reply em relação a quantidade defluxos ativos em uma rede.

SM = SMF + SMV (1)

SMF = Nswitches ∗ (HOF +HSR) (2)

SMV =∑f∈F

∑s∈Pathf

(BodyIFS ∗ 2)

(3)

A sobrecarga de monitoramento SM é dada por uma parte fixa SMF (Equação 2)e uma parte variável SMV (Equação 3). A parte fixa corresponde ao cabeçalho padrãodo OpenFlow (HOF ) mais o cabeçalho específico das mensagens Stats Reply (HSR), to-talizando 12 bytes. Esse valor é ainda multiplicado pela quantidade de switches na rede,uma vez que cada dispositivo responderá individualmente sobre as suas estatísticas deregras de encaminhamento (tendo ou não regras instaladas). A parte variável depende da


82

quantidade de fluxos ativos (conjunto F ) e da quantidade de dispositivos no caminho queesses fluxos percorrem ao longo da rede (conjunto Pathf ). Sendo assim, para cada fluxof ativo na rede e para cada switch s no caminho de cada fluxo são somados os dados re-ferentes às informações das regras de encaminhamento Individual-Flow-Stats (BodyIFS)para ida e volta. O tamanho de BodyIFS é de 88 bytes mais 8 bytes por action totalizando96 bytes, considerando que os fluxos unicast terão sempre apenas uma action associada.

Outro tipo de mensagem que aparece em quantidade significativa no canal de con-trole de redes OpenFlow são as mensagens utilizadas para instalação de regras de en-caminhamento: Packet-In, Packet-Out e Modify-State. A forma como essas mensagenssão utilizadas depende da implementação das aplicações no controlador, mas basicamentepara imitar o comportamento de redes Ethernet, existem pelo menos três implementaçõespossíveis [Klein e Jarschel 2013]. A primeira seria o que os autores Klein e Jarschelchamam de Hub behavior, onde para cada Packet-In gerado por um switch é gerado umPacket-Out que faz flood do pacote para todas as interfaces (o que é obviamente inefici-ente). A segunda implementação é chamada Switch behavior, onde o controlador aprendea localização dos hosts conforme recebe mensagens Packet-In, instala uma regra de enca-minhamento com Modify-State e envia o pacote recebido seguindo essa regra para cadaPacket-In recebido de cada switch do caminho do fluxo. A terceira e mais otimizadaimplementação é chamada Forwarding behavior. Nesta última, ao receber o primeiroPacket-In para estabelecimento de um fluxo o controlador primeiramente instala as re-gras com mensagens Modify-State nos demais switches do caminho, para depois instalara última regra no switch que gerou o Packet-In enviando o pacote com uma mensagemPacket-Out. Obviamente, o controlador somente conseguirá operar nesse modo depois deconhecer a localização dos hosts, o que deve acontecer depois que estes enviarem tráfegopara a rede, até então o controlador terá que utilizar, por exemplo, uma implementaçãoHub behavior.

Mensagens do tipo Packet-In são enviadas pelos switches ao controlador sempreque estes não encontram uma regra na tabela local para encaminhar um pacote recebido.Essas mensagens são compostas de um cabeçalho padrão de 20 bytes mais o pacote in-teiro recebido que é encapsulado na mensagem. Geralmente, os pacotes enviados nessetipo de mensagem serão ARP ou TCP-SYN, por exemplo, que incrementarão em 42 ou74 bytes, respectivamente no tamanho do Packet-In. A frequência com que novos flu-xos aparecerão na rede pode ser estimada estatisticamente através de modelos como osapresentados na Tabela 2. Além disso, a geração de mensagens Packet-In é influenciadapelo tempo de ociosidade das regras de encaminhamento, o que é uma configuração feitapelo controlador. Quanto mais longo o tempo de ociosidade das regras, menos mensagensPacket-In devem ser enviadas ao controlador.

Mensagens dos tipos Packet-Out e Modify-State são geralmente utilizadas em res-posta do controlador às mensagens Packet-In enviadas pelos switches. Considerando aimplementação Forwarding behavior que é utilizada pelo controlador Floodlight, a Equa-ção 4 expressa a sobrecarga de instalação de fluxos (SF ) gerada em uma rede OpenFlow.


83

SF =

Nswitches ∗ (HOF +HPO +MOriginal) se host desconhecido( ∑

s∈Pathf

(HOF +HMS)

)+ (HOF +HPO +MOriginal) se host conhecido

(4)

SF é calculada diferentemente em duas situações. Primeiro, no caso da posição dohost destino do fluxo na rede seja desconhecido pelo controlador, este irá enviar apenasmensagens de Packet-Out (HOF + HPO + MOriginal) para todas as portas de todos osswitches da rede (Nswitches) (isso acontece assim que forem recebidas no controlador todasas mensagens de Packet-In correspondentes), como um Hub behavior. Segundo, quando aposição do host é conhecida, o controlador envia mensagens Modify-State (HOF +HMS)para cada switch s no caminho do fluxo Pathf e envia apenas uma mensagem Packet-Out(HOF + HPO + MOriginal) de volta ao switch que originou o primeiro Packet-In. Emgeral, esse procedimento ocorrerá uma vez para o estabelecimento do caminho de ida dofluxo. No caminho de volta o host destino já será conhecido pelo controlador (já que eleoriginou o primeiro pacote), sendo assim, será necessário apenas mais uma execução docaso onde o host é conhecido.

Vale ressaltar que o custo das mensagens Packet-In não está incluído no cálculode SF – assim como os custos das mensagens Stats Request não estavam em SM – umavez que representam tráfego em sentidos diferentes no canal de controle. No entanto,estimar os valores de sobrecarga de Packet-In para as duas situações é trivial. No caso daposição do host destino do fluxo na rede seja desconhecido pelo controlador, serão geradasuma mensagem Packet-In para cada switch e já quando a posição do host é conhecida, éenviada uma mensagem Packet-In apenas. Também é importante salientar que não foramconsiderados nos cálculos apresentados a sobrecarga adicional de transporte. O canal decontrole OpenFlow possui diversas configurações possíveis de transferir dados, incluindoTCP, UDP, SSL, o que ocasiona ainda mais sobrecarga tanto de tráfego de rede quanto deprocessamento por parte do controlador e dos demais dispositivos da rede.

4.2. Resultados Experimentais

Os resultados da experimentação apresentam informações relevantes tanto para as mensa-gens de instalação de regras de encaminhamento (etapa (i), mensagens de Packet-In/Out eModify-State) como para as mensagens de monitoramento de estatíticas (etapa (ii), men-sagens de Read-State). Para fins comparativos, a modelagem analítica foi utilizada comobaseline para a situação onde existe a maior sobrecarga de mensagens na rede, dado osparâmetros da experimentação em cada uma das duas topologias.

As Figuras 2(a) e 2(b) apresentam o comportamento das mensagens Packet-In/Oute Modify-State para as topologias de estrela e árvore respectivamente. O comportamentodas mensagens Packet-In/Out e Modify-State apresentam grandes variações durante o pe-ríodo do experimento. Variação que acontece pelo fato dessas mensagens só ocorremna rede quando os fluxos são iniciados e os switches não possuem regras instaladas ouquando as regras para um determinado fluxo expiram baseadas em um tempo limite deociosidade da regra instalada no switch. Devido a essas variações, com 90% de confiançaé possível afirmar que para ambas as topologias a taxa de transferência das mensagens


84

do tipo Packet-In enviadas para serem processadas no controlador diminuiu significativa-mente conforme aumenta o tempo limite de ociosidade da regra instalada expirar. Issoindica que em redes onde as regras são acionadas mais frequentemente, por exemplo comintervalo de menos de 30 ou 60 segundos, não é necessária a desinstalação imediata dasregras de encaminhamento quando o fluxo fica inativo por 1 segundo.

As mensagens de Packet-Out e Modify-State obedecem a mesma variação dasmensagens Packet-In, porém, são enviadas em direção dos dispositivos de encaminha-mento ao invés do controlador. De acordo com a experimentação, ’é possível afirmar com90% de confiança para ambas as topologias a taxa de mensagens do tipo Packet-Out eModify-State ocorrem com mais frequência de acordo com o tempo limite de ociosidadeda regra instalada no switch. Isso indica que em ambientes onde as regras são acionadascom frequência não é necessária a desinstalação da regra imediatamente, podendo causarsobrecarga de mensagens de controle desnecessárias no canal de controle.

0

50

100

150

200

250

300

350

400

1 30 60

Taxa d

e t

ransf

erê

nci

a (

bit

s/s)

Tempo limite de ociosidade da regra (segundos)

Pkt-in (Experimental)Pkt-in (Analítico)

Pkt-out+Mod-St (Experimental)Pkt-out+Mod-St (Analítico)

(a) Topologia em estrela

0

500

1000

1500

2000

2500

3000

3500

1 30 60

Taxa d

e t

ransf

erê

nci

a (

bit

s/s)

Tempo limite de ociosidade da regra (segundos)

Pkt-in (Experimental)Pkt-in (Analítico)

Pkt-out+Mod-St (Experimental)Pkt-out+Mod-St (Analítico)

(b) Topologia em árvore

Figura 2. Taxa de transferência das mensagens Packet-It e Packet-Out/Modify-State de acordo com otempo limite de ociosidade das regras para as topologias de estrela e árvore

Uma vez compreendido o comportamento dos usuários na rede e conhecendo atopologia pode se estimar o caso onde existe a maior sobrecarga de mensagens Packet-Inpara o controlador. A partir da modelagem analítica pode ser mensurado o impacto dasmensagens no canal de controle para o caso onde tempo limite de ociosidade das regrasseja quase que imediato (1 segundo). Nas Figuras 2(a) e 2(b) é possível perceber que as ta-xas de transferência para os resultados analíticos se mantém estáveis para todos os temposde ociosidade. Isso ocorre pois a modelagem não levou em consideração esses tempos,estimando um caso onde as regras sempre expiram antes da próxima comunicação entredois hosts. A partir desses resultados, é possível afirmar que é necessário o conhecimentoa respeito do comportamento dos fluxos gerados na rede para não gerar pacotes desne-cessários ao controlador nem manter regras inativas instaladas desnecessariamente nosdispositivos de encaminhamento.

A Figura 3 apresenta o comportamento da taxa de pacotes por segundo das mensa-gens do tipo Packet-In/Out para as topologias de estrela e árvore. Foram calculadas tam-bém as taxas de 0.17, 0.113, 0.005 e 0.33, 0.22 e 0.008 pacotes por segundo de mensagensPacket-In processadas no controlador nas topologias de estrela e árvore respectivamente.Para as mensagens de Packet-Out e Modify-State foram calculados 0.5, 0.3, 0.17 e 1.5,0.728, 0.33 pacotes por segundo enviados em direção dos switches também para as topo-logias de estrela e árvore. Valores que em primeiro momento não demonstram relevância,


85

porém, devido aos 6 switches mais que a topologia em árvore apresenta, a taxa de paco-tes por segundo processados pelo controlador aumenta em 51,5%, 51,4% e 62,5% paraas mensagens do tipo Packet-In nas três variações do experimento. Para as mensagensPacket-Out e Modify-State as variações ficam em torno de 33.3%, 41.2% e 51,1% de au-mento, devido a topologia com maior número de switches. Assim, pode-se afirmar que onúmero de switches impacta diretamente na sobrecarga de mensagens Packet-In enviadasao controlador, ainda que, a modelagem analítica não tenha como prever problemas comopacotes fora de ordem e retransmissões, os quais podem ocasionar em mais chegadas demensagens Packet-In no controlador.

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1 30 60

Paco

tes

pro

cess

ad

os

por

seg

und

o

Tempo limite de ociosidade das regra (segundos)

Pkt-in (Estrela)Pkt-in (Árvore)

Pkt-out+Mod-St (Estrela)Pkt-out+Mod-St (Árvore)

Figura 3. Taxa de pacotes processados por segundo de mensagens Packet-In, Packet-Out/Modify-State de acordo com o tempo limite de ociosidade das regras para as topologias de estrela e árvore

A Figura 4(a) e 4(b) apresentam os resultados para a taxa de transferência de men-sagens Stats-Reply para as topologias de estrela e árvore, respectivamente. Se tratando dasmensagens para monitoramento de estatísticas (Read-State), os resultados apresentaramque para 95% de confiança existe pouca variabilidade na taxa de transferência média dospacotes de estatísticas coletados. As mensagens de request não foram exibidas em gráfi-cos, pois são fixas e podem ser facilmente calculadas de forma similar ao cálculo de SMF

já explicadas pela Equação 1. As mensagens de reply dependem do número de regrasinstaladas nos switches da rede e essa variabilidade impacta no tamanho das mensagensrecebidas pelo controlador.

0

1000

2000

3000

4000

5000

1 5 10

Taxa d

e t

ransf

erê

nci

a (

bit

s/s)

Frequência de monitoramento (segundos)

Stats-Reply (Experimental)Stats-Reply (Analítico)

(a) Topologia em estrela

0

5000

10000

15000

20000

1 5 10

Taxa d

e t

ransf

erê

nci

a (

bit

s/s)

Frequência de monitoramento (segundos)

Stats-Reply (Experimental)Stats-Reply (Analítico)

(b) Topologia em árvore

Figura 4. Taxa de transferência para mensagens de Stats-Reply de acordo com a frequência demonitoramento para as topologias de estrela e árvore


86

Além do número de regras instaladas nos switches da rede, que impacta no ta-manho das mensagens, o número de switches a serem consultados também influencia nodesempenho do controlador. Para a topologia em árvore por exemplo, o envio e rece-bimento de mensagens de monitoramento é 6 vezes maior do que na topologia estrela,pois o controlador precisa enviar uma mensagem de request e recebe uma reply de cadaswitch da rede. Escalando para topologias maiores como de data centers por exemplo, oimpacto e frequência do monitoramento pode ser maior, comprometendo a comunicaçãoentre controlador e dispositivos de encaminhamento. A partir desse estudo pode se afir-mar que a frequência do monitoramento pode afetar significativamente dependendo donúmero de dispositivos de encaminhamento na rede. Além disso, deve-se avaliar a possi-bilidade de realizar o monitoramento direcionado ao um conjunto menor de dispositivosde mais interesse, evitando uma possível coleta desnecessária.

5. Conclusões e Trabalhos FuturosNeste trabalho foi discutido acerca da centralização e distribuição da lógica de controleno contexto de SDN e OpenFlow. Partindo dessa discussão, foram apresentadas soluçõesque resolvem problemas relacionados aos gargalos gerados pela centralização do controleda rede proposta no contexto do protocolo OpenFlow. Porém, não são quantificados ocusto e nem a frequência em que tais gargalos podem ocorrer. Portanto, devido a ausênciade um estudo quantitativo acerca das mensagens de controle utilizadas nesse contexto,foi proposta uma análise para as mensagens que aparecem mais frequentemente no canalde controle em redes OpenFlow. A análise foi constituída de (i) uma modelagem analí-tica, para identificação do comportamento das mensagens (Packet-In/Out, Modify-State eRead-State) trocadas entre controlador e switches na rede e; (ii) a experimentação em duastopologias distintas, variando frequência de monitoramento e tempo limite de ociosidadedas regras instaladas nos dispositivos de encaminhamento.

Os resultados da análise realizada mostram que as mensagens de instalação deregras de encaminhamento Packet-In/Out e Modify-State possuem um comportamentodependente da implementação das aplicações realizadas no controlador, por exemplo, dotempo limite de ociosidade das regras. Já as mensagens de coleta de estatísticas (Read-State) são influenciadas principalmente devido a quantidade de dispositivos monitoradose pela frequência em que são monitorados. A modelagem analítica apresenta as equaçõespara estimar a sobrecarga gerada pela transmissão das mensagens de controle assumindoque a rede não possui atrasos nem retransmissões. Fato que explica os resultados apresen-tados, onde todos os valores calculados analiticamente são superiores aos experimentais.Com base na análise apresentada, espera-se contribuir para o projeto e desenvolvimentode novos sistemas de gerenciamento de redes baseadas no paradigma SDN e OpenFlow.

Como trabalhos futuros pretende-se expandir os experimentos acerca das topolo-gias abordadas, variando tanto o número de switches da rede como o número de hosts.Fatores como a frequência de monitoramento podem ser explorados em maior escala, afim de estabelecer uma relação entre a sobrecarga gerada na rede e a precisão dos dadosobtidos sobre os fluxos monitorados. Também pode ser expandida a análise para outrasversões do protocolo OpenFlow utilizando níveis de prioridades, além de instalação deregras mais genéricas ou mais específicas. Por fim, além desses aspectos pretende-se rea-lizar novos experimentos em uma rede com switches reais a fim de que se possa analisar olimite de processamento das regras instaladas e monitoradas através do canal de controle.


87

Referências3GPP2 (2004). CDMA2000 Evaluation Methodology. Disponível em:

<http://www.3gpp2.org/Public_html/specs/C.R1002-0_v1.0_041221.pdf>. Acessoem: Março 2014.

Bari, M. F., Roy, A. R., Chowdhury, S. R., Zhang, Q., Zhani, M. F., Ahmed, R., e Boutaba,R. (2013). Dynamic controller provisioning in software defined networks. In Proce-edings of the 9th IEEE/ACM/IFIP International Conference on Network and ServiceManagement 2013 (CNSM 2013).

Big Switch Networks (2014). Floodlight an Open SDN Controller. Disponível em:<https://www.projectfloodlight.org/floodlight/>. Acesso em: Março 2014.

Cheng, X., Dale, C., e Liu, J. (2007). Understanding the characteristics of internet shortvideo sharing: Youtube as a case study. arXiv preprint arXiv:0707.3670.

Curtis, A. R., Mogul, J. C., Tourrilhes, J., Yalagandula, P., Sharma, P., e Banerjee,S. (2011). Devoflow: scaling flow management for high-performance networks.SIGCOMM-Computer Communication Review, 41(4):254.

Heller, B., Sherwood, R., e McKeown, N. (2012). The controller placement problem. InProceedings of the first workshop on Hot topics in software defined networks, pp. 7–12.ACM.

Jain, R. (2008). The art of computer systems performance analysis. John Wiley & Sons.

Kim, H. e Feamster, N. (2013). Improving network management with software definednetworking. IEEE Communications Magazine, 51(2):114–119.

Klein, D. e Jarschel, M. (2013). An openflow extension for the omnet++ inet framework.In Proceedings of the 6th International ICST Conference on Simulation Tools and Te-chniques, SimuTools ’13, pp. 322–329, Brussels, Belgium.

Lantz, B., Heller, B., e McKeown, N. (2010). A network in a laptop: rapid prototypingfor software-defined networks. In Proceedings of the 9th ACM SIGCOMM Workshopon Hot Topics in Networks, Hotnets-IX, pp. 19:1–19:6, New York, NY, USA. ACM.

Levin, D., Wundsam, A., Heller, B., Handigol, N., e Feldmann, A. (2012). Logicallycentralized?: state distribution trade-offs in software defined networks. In Proceedingsof the first workshop on Hot topics in software defined networks, pp. 1–6. ACM.

McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J.,Shenker, S., e Turner, J. (2008). Openflow: enabling innovation in campus networks.ACM SIGCOMM Computer Communication Review, 38(2):69–74.

Roy, A. R., Bari, M. F., Zhani, M. F., Ahmed, R., e Boutaba, R. (2014). Design and mana-gement of dot: A distributed openflow testbed. In Preceedings of the 14th IEEE/IFIPNetwork Operations and Management Symposium (NOMS 2014)(To appear).

Tootoonchian, A. e Ganjali, Y. (2010). Hyperflow: a distributed control plane for open-flow. In Proceedings of the 2010 internet network management conference on Researchon enterprise networking, pp. 3–3. USENIX Association.

Yu, M., Rexford, J., Freedman, M. J., e Wang, J. (2010). Scalable flow-based networkingwith difane. ACM SIGCOMM Computer Communication Review, 40(4):351–362.


88

Migracao de maquinas virtuais para economia de energia∗

Leonardo Pais Cardoso, Lyno Henrique G. Ferraz, Otto Carlos M. B. Duarte

1Grupo de Teleinformatica e AutomacaoUniversidade Federal do Rio de Janeiro (UFRJ)

Rio de Janeiro – RJ – Brasil

{cardoso, lyno, otto}@gta.ufrj.br

Resumo. A computacao em nuvem oferece um novo modelo de negocios queprove servicos de infraestrutura flexıveis por demanda. O cliente paga ape-nas pelo que realmente necessita ou usa recursos de processamento, memoriae banda sob demanda, podendo crescer ou retrair sem custos extras. Logo, osprovedores de infraestrutura devem prover recursos de forma dinamica, a custoreduzido e tambem com baixo consumo de energia eletrica, para diminuir aemissao de carbono e melhorar a sua imagem junto a seus clientes. Este ar-tigo propoe um mecanismo que emprega tecnicas de otimizacao para gerenciara migracao de maquinas virtuais entre maquinas fısicas com o objetivo de re-duzir os recursos ociosos e tambem obter menor consumo energetico atravesdo desligamento de maquinas fısicas. O estado das maquinas e as decisoessao baseadas no monitoramento dos perfis de uso de recursos. A heurısticaimplementada procura minimizar o numero de maquinas fısicas em funciona-mento ao realocar maquinas virtuais. Foram realizados experimentos em umprototipo desenvolvido e implantado no Future Internet Testbed with Security(FITS). Os resultados obtidos mostram a eficacia da proposta na reducao doconsumo energetico.

Abstract. Cloud computing introduced a new business model that offers flexibleon demand infrastructure services. The client gets resources on demand suchas processing, memory and bandwidth, which can grow or shrink without extracosts and he pays just for what he needs or uses. Therefore, the infrastructureproviders must offer resources dynamically with low costs and low energy con-sumption in order to decrease carbon emission levels and improve the imageof the company in the consumer marketplace. This paper proposes a virtualmachine management mechanism that implements optimization techniques tomanage the migration of virtual machines between physical machines. The me-chanism aims to decrease power consumption and idle resources by turning offphysical machines. The machine state and the decisions taken are based on themonitoring of the resource usage profiles. The developed heuristic tries to mini-mize the number of active physical machines by redistributing virtual machines.A prototype was developed and deployed in Future Internet Testbed with Secu-rity (FITS). The results show the effectiveness of the mechanism reducing powerconsumption.

∗Este trabalho foi realizado com recursos do CNPq, CAPES, FINEP, FAPERJ e FUNTTEL.


89

1. Introducao

A computacao em nuvem permite que o provedor de infraestrutura ofereca recur-sos computacionais como processamento, memoria e rede de forma flexıvel e dinamicade acordo com a demanda de seus clientes. Alem de serem evitados custos operacio-nais de manutencao, configuracao e reparo, o cliente tambem pode obter os recursos quenecessita naquele momento, evitando sobre ou sub valores investidos em infraestrutura.Uma tecnica utilizada para isto e a virtualizacao [Fernandes et al. 2010] que amplia aflexibilidade em alocar recursos ao abstrair o hardware, possibilitando que mais de umusuario compartilhe recursos de uma mesma maquina sem interferir nos processos de ou-tro usuario. Para evitar sobrecarga, e comum distribuir os recursos pelas maquinas fısicasinterconectadas em rede ou em aglomerados. A migracao de maquinas virtuais e umaforma eficaz de redistribuir dinamicamente os recursos pelas maquinas fısicas existen-tes. A migracao ao vivo [Clark et al. 2005] permite que as maquinas virtuais continuemem funcionamento durante o processo de migracao, garantindo alta disponibilidade doservico.

Alocar recursos computacionais e um importante desafio em computacao em nu-vem, pois determina se o provedor consegue atender aos Acordos de Nıvel de Servico(Service Level Agreements - SLAs) sem comprometer os seus lucros. Uma alocacao efi-ciente de recursos deve atender a todos os clientes com a qualidade de servico por elesrequerida e com o menor uso de recursos fısicos para diminuir o numero de computado-res ativos, reduzindo assim o consumo de energia eletrica. No entanto, as plataformasde virtualizacao como o Xen [Egi et al. 2008] nao possuem nativamente um mecanismode gerencia que possibilite alocar os recursos de forma eficiente. Alem disso, alocardiferentes recursos em maquinas que possuem restricoes de capacidade e um ProblemaGeneralizado de Atribuicao (Generalized Assignment Problem - GAP) e portanto NP-Difıcil [Kundakcioglu e Alizamir 2009]. A medida que o numero de recursos e maquinasaumenta, o tempo para calcular a solucao cresce exponencialmente. Assim, encontraruma solucao exata nao e escalavel.

Este artigo propoe um mecanismo automatico de gerencia baseado na migracaode maquinas virtuais para minimizar o consumo de energia eletrica e reduzir a ociosidadede recursos. A minimizacao do consumo de energia e da ociosidade e feita com base nomonitoramento e analise dos perfis de uso de recursos das maquinas fısicas e virtuais. Apartir dessa analise e aplicada uma heurıstica que realoca recursos atraves da funciona-lidade de migracao de maquinas virtuais de forma a minimizar o numero de maquinasfısicas em funcionamento. O algoritmo prove um mapeamento das maquinas virtuais emmaquinas fısicas que objetiva um numero reduzido de maquinas fısicas. O mecanismoconsidera ainda a quantidade de memoria a ser transferida pela rede. As maquinas virtu-ais sao entao migradas uma a uma para evitar violacoes dos Acordos de Nıvel de Servicoque poderiam ser causadas pela sobrecarga no trafego na rede que as transferencias dedados da migracao requerem. As maquinas fısicas em estado inativo sao entao desligadascom a finalidade de reduzir os recursos ociosos e o consumo de energia. As maquinas saomantidas desligadas ate que a demanda dos clientes seja superior a quantidade de recursosoferecidos e, neste caso, novas maquinas fısicas sao ativadas para atender a demanda.

O mecanismo de gerencia foi implementado e testado no FITS. Dois testes foramrealizados: Um experimento para comprovar o funcionamento do mecanismo e um estudo


90

do algoritmo de otimizacao. Os resultados mostram que o mecanismo e capaz de encon-trar solucoes de menor custo, migrar as maquinas para essa solucao, desligar maquinasociosas e ligar maquinas quando a demanda e maior que a oferta. O estudo mostra que oArrefecimento Simulado e capaz de melhorar a solucao de outras heurısticas.

O restante deste artigo esta organizado da seguinte forma. Na Secao 2 os trabalhosrelacionados sao descritos e comparados com o mecanismo proposto. A Secao 3 apresentaa solucao proposta, descrevendo a coleta de dados, a heurıstica utilizada e a arquitetura domecanismo. Os resultados sao apresentados na Secao 4. A Secao 5 apresenta a conclusaoe direcoes futuras deste trabalho.

2. Trabalhos RelacionadosO desenvolvimento de mecanismos que visem a minimizacao do consumo de ener-

gia e um tema atual e tambem um desafio tecnologico. Diversos trabalhos abordam aalocacao de elementos virtuais sem levar em conta o consumo de energia eletrica.

Esta secao se restringe aos trabalhos de alocacao de recursos para reducao deconsumo de energia eletrica. Uma forma de resolucao do problema de otimizacao e ouso de heurısticas como o First Fit Decreasing (FFD) [Johnson et al. 1974] e de meta-heurısticas como o Arrefecimento Simulado. O FFD e um algoritmo guloso que ordenaas maquinas virtuais de forma decrescente de demanda e tenta alocar a maquina virtualna maquina fısica de menor ındice com capacidade disponıvel. Caso nao consiga alocar aquantidade de recursos demandados em nenhuma maquina fısica ativa, uma nova maquinafısica e ativada com um ındice maior que o da ultima ativada. A tecnica de ArrefecimentoSimulado e uma meta-heurıstica capaz de encontrar uma solucao otima para o problemade alocacao atraves de uma funcao de aceitacao. Essa funcao permite a aceitacao deestados de maior custo, e assim possibilita a exploracao de diferentes solucoes para fugirde mınimos locais.

Wu et al. comparam as heurısticas FFD e Arrefecimento Simulado para arealocacao de maquinas virtuais e economia de energia [Wu et al. 2012]. Wu et al. rea-lizam simulacoes variando o numero de maquinas fısicas e virtuais bem como a capaci-dade e o uso de recursos de cada uma delas. A minimizacao e feita sobre uma funcao deconsumo de energia eletrica dependente de parametros como o uso de processamento ememoria e do hardware utilizado. Eles concluıram que o uso em conjunto do Arrefeci-mento Simulado e do FFD encontra solucoes que podem economizar mais energia que ouso somente do FFD ou do Arrefecimento Simulado. Porem, os autores focam na pro-posta e simulacao do algoritmo, assim o trabalho carece de um desenvolvimento praticoque lide com os problemas relacionados de gerenciamento efetivo de um ambiente virtua-lizado. Apenas verificou-se a possibilidade de alocar as maquinas virtuais e o tempo que oalgoritmo leva para atingir a solucao, nao considerando o tempo necessario para o sistemaconvergir apos as requisicoes de migracao, o que pode ser crıtico em uma aplicacao real.

Rodriguez et al. implementam uma heurıstica de branch and cut [Mitchell 2002]baseada em um algoritmo de programacao linear 0-1 cujo objetivo e encontrar ummapeamento de roteadores e enlaces virtuais em roteadores e enlaces fısicos. Oartigo avalia o compromisso entre minimizar o consumo de energia e o uso debanda [Rodriguez et al. 2013]. Os autores definem pesos para o uso de banda e consumode energia e executam duas formulacoes de programacao linear 0-1 de forma sequencial.


91

A primeira formulacao mapeia as redes virtuais no substrato a fim de minimizar o con-sumo de energia e a largura de banda por requisicao da nova rede, a segunda visa encontrarum caminho que minimize o tempo necessario para transferir a imagem do roteador vir-tual e carregar o sistema operacional. Os autores apresentam melhores resultados quandoaplicam o mesmo peso para banda e economia de energia, apresentando uma diminuicaode 30% da largura de banda e um aumento de 10% do consumo quando comparado aminimizacao apenas do consumo de energia. A proposta de Rodriguez et al. nao e orien-tada a computacao em nuvem e considera apenas o problema de chegada de redes virtuaisem uma plataforma pluralista para prover infraestrutura de rede. Em um cenario de nu-vem nao se pode limitar a instanciacao de redes, sendo necessario manter a economia deenergia dos servidores que entregam recursos sob demanda para as maquinas virtuais.

Este artigo, ao contrario dos trabalhos acima relacionados, propoe a solucao de ummecanismo de gerencia capaz de reduzir o numero de maquinas em funcionamento utili-zando heurısticas que levam em conta parametros que influem substancialmente no tempode migracao. O mecanismo proposto utiliza a tecnica de migracao ao vivo para reduzira inatividade das maquinas virtuais enquanto sao migradas. Com isto, quando ocorre amigracao, apenas a memoria da maquina virtual e copiada pela rede. Essa tecnica per-mite que a maquina virtual permaneca em operacao durante a migracao e entre em estadosuspenso por um curto perıodo de tempo. O mecanismo tambem evita a sobrecarga darede causada pela migracao e a sobrecarga dos recursos de memoria e processamento dasmaquinas fısicas. A sobrecarga da rede e tratada atraves da escolha de solucoes que mi-grem maquinas virtuais com menor quantidade de memoria. A sobrecarga de memoria eprocessamento e evitada pela utilizacao do protocolo Wake on Lan que liga maquinas pelarede. No mecanismo, o Wake on Lan e acionado quando a demanda por recursos e maiorque a disponıvel, ligando uma das maquina fısicas ociosas para satisfazer a necessidadedos clientes. Os autores Rodriguez et al. procuram otimizar a instanciacao de roteadoresvirtuais na criacao da rede. Em contrapartida, este artigo aborda a migracao de maquinasvirtuais ja instanciadas e em uso por clientes que possuem acordos de nıvel de servicopre-definidos com o provedor de infraestrutura.

A verificacao do comportamento do mecanismo proposto foi realizada no testbedFITS, que prove um ambiente virtualizado em que se pode testar solucoes para a Internetdo Futuro [Mattos et al. 2012, Moraes et al. 2014]. O FITS e uma rede de testes inter-universitaria baseada nas tecnologias Xen e OpenFlow, contando com parceiros no Brasile na Europa. O FITS adota o paradigma pluralista e permite a execucao de sistemasoperacionais e aplicacoes distintas nas redes virtuais. Dessa forma, o FITS prove umambiente propıcio a avaliacao do desempenho e da viabilidade de novas tecnologias paraa Internet do Futuro. A arquitetura do FITS pode ser vista na Figura 1.

A implementacao desta proposta se serve de modulos desenvolvidos an-teriormente no Grupo de Teleinformatica e Automacao referentes ao VOL-TAIC [Carvalho e Duarte 2012] e ao sistema de gerencia AMAS proposto por Bezerraet al. [Bezerra et al. 2014]. O VOLTAIC e um sistema de gerencia de recursos para acomputacao em nuvem que prove qualidade de servico e evita desperdıcio de recursos.Bezerra et al. propuseram uma ferramenta de gerencia que evita a sobrecarga dos nosfısicos e violacoes de acordo de nıvel de servico. Este trabalho, assim como o VOL-TAIC, se baseia na tecnica de perfis de uso de recursos das maquinas fısicas para analisar


92

Figura 1. Arquitetura do FITS destacando a migracao de uma maquina virtual.Adaptado de [Figueiredo et al. 2013] [Mattos et al. 2012, Moraes et al. 2014].

as capacidades e, assim como a ferramenta de gerencia desenvolvida, redistribui a cargade trabalho atraves da migracao de maquinas virtuais caso um limiar de consumo sejaatingido.

3. O Esquema PropostoA proposta deste artigo visa minimizar o consumo de energia eletrica e os recursos

ociosos. Fan et al. afirmam que um servidor em modo inativo nao consome menosque 50% da energia eletrica que consumiria em fase de pico [Fan et al. 2007]. Portanto,para reduzir de forma significativa o consumo de energia deve-se desligar por completoa maquina fısica. Assim, a ideia-chave e migrar as maquinas virtuais para um numeroreduzido de maquinas fısicas e desligar as maquinas fısicas que nao possuem maquinasvirtuais ativas. O mecanismo desenvolvido possui quatro modulos principais: o Monitorde Recursos, o Otimizador, o Orquestrador de Migracao e o Gerenciador de Energia,que sao detalhados na Secao 3.3. Esses modulos geram perfis, calculam um estado queeconomize energia, migram maquinas virtuais e desligam e ligam as maquinas fısicas.

A quantidade de memoria de cada maquina virtual a ser migrada influencia notempo de convergencia do sistema, porque ao migrar uma maquina virtual e necessariotransferir a sua memoria pela rede para a maquina fısica que a hospedara. Para redu-zir o tempo de migracao, o algoritmo de Arrefecimento Simulado implementado con-sidera, na condicao de duas ou mais solucoes de mesmo custo em termos de maquinasfısicas, escolher a solucao que transfere menor quantidade de memoria. Logo, sempreque uma solucao de mesmo custo que a ultima armazenada e encontrada, verifica-se quaismaquinas virtuais precisam migrar, ou seja, trocaram de posicao em relacao a disposicaoinicial, e tambem se verifica o quanto de memoria essas maquinas possuem. Apos ocalculo escolhe-se e armazena-se o plano de migracao com menor quantidade de memoriapara que o procedimento de migracao provoque a menor sobrecarga possıvel na rede.

3.1. Formulacao para minimizacao do numero de maquinas em funcionamento

Para a otimizacao sao definidos os seguintes parametros:

• V - conjunto de maquinas virtuais instanciadas;• F - conjunto de maquinas fısicas ativas;


93

• Cv, v ∈ V - processamento utilizado pela maquina virtual v;• Cf , f ∈ F - processamento utilizado pelo Domınio-0 da maquina fısica f ;• TC|f , f ∈ F - limiar de uso de processamento da maquina fısica f ;• Mv, v ∈ V - memoria da maquina virtual v;• Mf , f ∈ F - memoria utilizada pelo Domınio-0 da maquina fısica f ;• TM |f , f ∈ F - limiar de uso de memoria da maquina fısica f ;• Nv, v ∈ V - consumo de rede da maquina virtual v;• Nf , f ∈ F - rede utilizada pelo Domınio-0 da maquina fısica f ;• TN |f , f ∈ F - limiar de uso de rede da maquina fısica f ;

• X(f, v) =

{1, se v ∈ V esta instanciada na maquina fısica f ∈ F0, senao

• X(f) =

{1, se

∑v∈V X(f, v) ≥ 1

0, senaoO algoritmo de minimizacao segue o procedimento de

Minimizar

∑f∈F

X(f) (1)

sujeito as restricoes:

∀f ∈ F, (∑v∈V

Cv ∗X(f, v)) + Cf ≤ TC|f (R1)

∀f ∈ F, (∑v∈V

Mv ∗X(f, v)) +Mf ≤ TM |f (R2)

∀f ∈ F, (∑v∈V

Nv ∗X(f, v)) +Nf ≤ TN |f (R3)

∀v ∈ V,∑f∈F

X(f, v) = 1 (R4)

{V, F} ⊂ Z>0 (R5)

A Equacao 1 e a funcao objetivo do problema que nesse artigo e a minimizacao donumero de maquinas fısicas em funcionamentoX(f), ou seja, o numero total de maquinasfısicas ativas.

As restricoes R1, R2 e R3 garantem que o uso de recursos nao ultrapasse um li-miar. Assim, o uso de recursos para qualquer maquina fısica f ∈ F em funcionamento,e necessariamente menor ou igual ao somatorio dos recursos utilizados pelas maquinavirtuais v ∈ V pertencentes a maquina f , o que e representado por X(f, v), e pelo uso derecursos do Domınio-0 da maquina f . A Equacao R4 restringe uma maquina virtual v per-tencer a apenas uma maquina fısica f . Dessa maneira, o somatorio das maquinas fısicasf as quais possuem a maquina virtual v deve ser igual a 1. Essa restricao impede que umamesma maquina virtual pertencente ao conjunto de maquinas virtuais instanciadas V sejainstanciada em duas maquinas fısicas ao mesmo tempo e garante que a maquina virtualv tera uma maquina fısica f como destino. A restricao R5 limita o conjunto de maquinasvirtuais V e o de maquinas fısicas F ao domınio dos inteiros maiores que zero.


94

3.2. Arrefecimento SimuladoA meta-heurıstica de Arrefecimento Simulado implementada considera um estado

que evidencia a distribuicao das maquinas virtuais sobre as maquinas fısicas. Inicialmentefixa-se uma temperatura inicial, gera-se aleatoriamente um estado inicial e calcula-se ocusto associado definido pelo numero de maquinas fısicas ligadas. Em seguida, gera-seum novo estado a partir de uma perturbacao do estado inicial. Essa perturbacao consisteem escolher uma das maquinas virtuais e instancia-la em uma maquina fısica diferente,aleatoriamente. Caso o novo estado possua um custo menor que o anterior ele e aceito.Do contrario, a aceitacao dependera dos custos do estado anterior e do gerado, e da tem-peratura. A funcao de aceitacao e expressa por

P = exp(−ji − ji−1τiτ0

), (3)

onde ji e τi sao custo e temperatura na iteracao i, respectivamente.

A Equacao 3 representa a probabilidade de considerar uma solucao de maior custo,para isso geralmente compara-se o valor da funcao com um valor aleatorio no intervalo[0, 1]. Se o custo diminui ou se mantem a expressao e sempre igual a 1 e o estado e aceito.Para temperaturas elevadas o valor da funcao de aceitacao tem maior probabilidade deser maior que o valor aleatorio. Dessa forma, o algoritmo tem maior probabilidade desair de um mınimo local. As solucoes aceitas sao utilizadas para gerar novos estados. Oalgoritmo armazena a solucao aceita como a solucao candidata se o custo diminuir ou ocusto se mantiver e a memoria das maquinas a migrar diminuir. A escolha da solucao demenor memoria e feita para evitar sobrecarregar a rede com a transferencia das maquinasvirtuais. A medida que a temperatura diminui a funcao de aceitacao retorna valores me-nores e o algoritmo converge para uma solucao. Ao final, a solucao do problema sera aultima solucao candidata. O pseudocodigo do algoritmo esta em Algoritmo 1.

Dados: τ ; distribuicao,menor custo, ultimo custo,ultimo estado, custo memoriaenquanto τ > 0 faca

nova distribuicao = gerar estado(ultimo estado)novo custo = custo(nova distribuicao)se aceitacao(ultimo custo, novo custo, tau) ≥ random() entao

ultimo estado = nova distribuicaose novo custo < menor custo ou (novo custo = menor custo ecusto memoria(nova distribuicao) < custo memoria) entao

distribuicao = nova distribuicaomenor custo = novo custocusto memoria = custo memoria(nova distribuicao)

fimultimo custo = novo custo

fimτ = τ − 1

fimretorna distribuicao

Algoritmo 1: Arrefecimento Simulado


95

3.3. Arquitetura do MecanismoO mecanismo possui quatro modulos principais como pode ser visto na Figura 2.

O Monitor de Recursos e responsavel por coletar o uso de recursos das maquinas fısicas evirtuais, o Otimizador executa a heurıstica para minimizar o numero de maquinas fısicasem funcionamento, o Orquestrador de Migracao faz a redistribuicao das maquinas virtu-ais entre as maquinas fısicas e o Gerenciador de Energia desliga e liga maquinas fısicasde acordo com a demanda. O Monitor de Recursos e o Orquestrador de Migracao fo-ram desenvolvidos no trabalho de Bezerra et al. [Bezerra et al. 2014] e integrados aosmodulos Otimizador e Gerenciador de Energia desenvolvidos nesse artigo. O mecanismofoi desenvolvido em Python para facilitar a integracao com o Monitor de Recursos e oOrquestrador de Migracao que foram desenvolvidos nessa linguagem.

Figura 2. Arquitetura do mecanismo de gerencia proposto e do esquemade migracao automatica de maquinas virtuais.

O Monitor de Recursos coleta o uso de CPU, memoria e banda passante dasmaquinas fısicas e virtuais atraves da biblioteca libvirt para se comunicar com os hipervi-sores de cada maquina fısica. O uso de CPU das maquinas virtuais e obtido diretamentepela libvirt. O processamento das maquinas fısicas e calculado com a soma do processa-mento das maquinas virtuais. O perfil de uso de memoria e obtido atraves da quantidadede memoria alocada nas maquinas fısicas e virtuais. O uso de rede das maquinas virtuaise coletado a partir da quantidade de dados que trafegam pelas interfaces virtuais. Comoa solucao atual nao considera a topologia da rede, o uso de banda das maquinas virtuaiscontribui apenas no processamento do Domınio-0. O perfil de uso de recursos e geradoatraves do monitoramento das maquinas fısicas e virtuais a cada segundo.

O Otimizador recebe os perfis de uso do Monitor de Recursos e executa a meta-heurıstica de Arrefecimento Simulado para minimizar o numero de maquinas fısicas ati-vas. Ao final, o Otimizador gera uma nova distribuicao de maquinas fısicas e virtuais. Osdados das maquinas virtuais que serao migradas e os dados das maquinas fısicas e virtuaissao entao enviados para o Orquestrador de Migracao.

O Orquestrador de Migracao e responsavel por gerenciar a migracao das maquinasvirtuais para a distribuicao gerada pelo modulo de otimizacao. O Orquestrador usa amigracao ao vivo do Xen com pre-copia que se da em duas fases. Na primeira fase aspaginas de memoria da maquina virtual sao copiadas para a maquina de destino, se umapagina e modificada ela e reenviada. A segunda fase inicia quando a taxa de reenvio emenor que a taxa de modificacao. A maquina virtual e suspensa na origem e o restantedas paginas modificadas e copiado para a maquina de destino. Ao final, a execucao da


96

maquina virtual e retomada na maquina de destino. Dessa forma, o tempo de migracaodependera do tamanho da memoria a ser transferida, da taxa de atualizacao dos dados namemoria e do uso de recursos das maquinas fısicas envolvidas na migracao. Para evitar asobrecarga do uso de rede devido a migracao, uma maquina virtual so pode ser migradaquando a migracao da maquina virtual anterior terminar.

O Gerenciador de Energia desliga as maquinas fısicas que apos a execucao dasmigracoes nao apresentam maquinas virtuais instanciadas. Esse modulo tambem liga asmaquinas fısicas quando nao e mais possıvel atender a todos os clientes devido a um au-mento da demanda de recursos. Esse aumento pode ser observado quando o consumo derecursos de uma maquina fısica atinge determinado limiar em um determinado numero demedicoes, o que caracteriza uma sobrecarga. Caso o algoritmo de otimizacao nao encon-tre uma solucao de menor custo, uma maquina fısica e religada atraves do protocolo Wakeon Lan e as maquinas virtuais sao redistribuıdas apos uma nova execucao do algoritmo.O pseudocodigo desse modulo esta em Algoritmo 2.

Entrada: HostsOciosos,MaquinasDesligadas,MaquinasF isicasse sobrecarga(MaquinasF isicas) e HostsOciosos = 0 entao

acordar(MaquinasDesligadas.pop())Otimizador(MaquinasF isicas)

fimsenao

para Maquina em MaquinasF isicas facase MaquinasV irtuais(Maquina) = 0 entao

desligar(Maquina)MaquinasDesligadas.append(Maquina)

fimfim

fimAlgoritmo 2: Gerenciador de Energia

Uma maquina virtual e migrada para uma maquina fısica apenas se a maquinafısica possui recursos suficientes para alocar a maquina virtual. Do contrario, outramaquina e escolhida como destino. Se antes da migracao o uso de recursos da maquinavirtual e superior ao da maquina fısica de destino, a maquina virtual nao migra para essedestino. Caso a maquina virtual oscile apos a migracao e ultrapasse um determinado li-miar, a sobrecarga e detectada com base no historico dos perfis de uso. As maquinasvirtuais sao entao redistribuıdas. O mecanismo nao considera a topologia da rede paraefetuar as migracoes. Porem, o escopo de maquinas fısicas participantes do processode migracao e configuravel pelo administrador que pode estabelecer um grupo maquinasfısicas geograficamente proximas. Assim, a latencia da maquina virtual em relacao aocliente no novo destino pode ser reduzida.

A coleta dos perfis de uso e a migracao e realizada pela biblioteca multiplata-forma libvirt. Dessa forma, o mecanismo de gerencia pode ser usado em plataformas devirtualizacao como o Xen e o KVM. Alem disso, as medidas para a geracao de perfis sao


97

obtidas atraves da libvirt, o que nao requer a modificacao de nenhuma maquina virtual,nem a instalacao de softwares. Assim, preserva o isolamento das maquinas virtuais. Oagendamento de execucao do mecanismo depende da polıtica do administrador podendoser mantido em execucao contınua ou apenas quando um evento ocorre. Nesse caso, deveser levado em conta o tempo que o algoritmo leva para encontrar uma solucao, o que variacom a quantidade de maquinas fısicas e virtuais.

4. ResultadosDois testes foram realizados: um experimento para a verificacao do bom compor-

tamento do mecanismo proposto em migrar as maquinas virtuais e desligar as maquinasfısicas e um estudo para a verificacao da escalabilidade da solucao de otimizacao.

Para o primeiro teste que verifica o funcionamento do mecanismo proposto forammonitoradas tres maquinas da plataforma FITS, a Leblon, Pao de Acucar e Itanhanga.As maquinas Leblon e Pao de Acucar possuem processador Intel i7 de 3.2 GHz e 16 GBde RAM, a maquina Itanhanga possui processador Intel i7 de 3.1 GHz e 8 GB de RAM.As maquinas possuem sistema operacional Debian Wheezy e executam a versao 4.1.3do Xen. As imagens das maquinas virtuais encontram-se em um no central do FITS, naosendo necessario copiar o disco pela rede. O mecanismo de gerencia proposto e executadoem uma maquina Intel Core 2 Quad de 2.4 GHz com 3 GB de RAM que e externa aplataforma FITS para nao interferir no experimento. O Domınio-0 esta configurado paraconsumir 2 GB de memoria.

As maquinas virtuais possuem configuracoes heterogeneas de memoria e proces-samento para avaliar a eficacia do mecanismo proposto. A maquina virtual lpcvm1 foiconfigurada com 2 processadores virtuais e 2 GB de memoria RAM. As maquinas vir-tuais lpcvm2 e lpcvm3 foram configuradas com 1 processador virtual e com 4 GB e 3GB de memoria respectivamente. O processamento nas maquinas virtuais foi gerado como programa Stress [Waterland 2003], um programa que permite gerar cargas de proces-samento de forma controlada. Para evitar problemas de escalonamento nas migracoes,foram escolhidas maquinas fısicas com configuracoes semelhantes de processamento.

A Figura 3 mostra a migracao da maquina virtual lpcvm1 da maquina fısica Ita-nhanga para a maquina fısica Pao de Acucar, Figura 3(a), Figura 3(b), Figura 3(c) eFigura 3(d). Em sequencia ocorre a migracao da maquina virtual lpcvm3 que e transfe-rida da maquina fısica Leblon para a Pao de Acucar, Figura 4 e, finalmente, as maquinasItanhanga e Leblon sao desligadas. Esse resultado mostra que o mecanismo e capaz deexecutar o algoritmo de otimizacao, fazer as migracoes necessarias e desligar as maquinasfısicas ociosas, atingindo o objetivo de reduzir o consumo de energia eletrica. Alem disso,as maquinas migradas sao as que possuem a menor quantidade de memoria o que reduz acarga na rede durante a migracao. Apos esse experimento e feito um teste de sobrecargade recursos. Nesse teste uma quarta maquina virtual e instanciada na maquina Pao deAcucar. A Pao de Acucar atinge o limiar de uso de memoria e o mecanismo detecta asobrecarga. Como a oferta de recursos e menor que a demanda o Gerenciador de Ener-gia liga uma maquina fısica, nesse caso, a Itanhanga. Assim que a maquina e ligada oOtimizador calcula uma nova solucao e a maquina virtual lpcvm1 e transferida para aItanhanga.

Para o teste do modulo de otimizacao foram comparadas tres tecnicas para


98

Proc

essa

men

to(%

)

��

Inıcio da migracaoda maquina lpcvm1

}Aumento de processamentodevido a migracao

Janela de tempo(s)(a) Uso de CPU em funcao do tempo.

Mem

oria

(%)

}Reducao da carga devidoao inıcio da migracao

��

Uso de memoriada maquina lpcvm1

Uso de memoriado Domınio 0

-

Janela de tempo(s)(b) Uso de memoria em funcao do tempo.

Proc

essa

men

to(%

)

@@R

Inıcio da migracao

}Aumento do processamentodevido a migracao

Janela de tempo(s)(c) Uso de CPU em funcao do tempo.

Mem

oria

(%)

Memoria nao se altera poisainda esta migrando.

-

Janela de tempo(s)(d) Uso de memoria em funcao do tempo.

Proc

essa

men

to(%

)

lpcvm3 continua operando normalmenteenquanto lpcvm1 e migrada

Janela de tempo(s)(e) Uso de CPU em funcao do tempo.

Mem

oria

(%)

lpcvm3 continua operando normalmenteenquanto lpcvm1 e migrada

Janela de tempo(s)(f) Uso de memoria em funcao do tempo.

Figura 3. Inıcio da execucao do plano de acao de migracao das maquinas virtu-ais determinado como resultado da meta-heurıstica de Arrefecimento Simulado.Assim que o programa inicia, a meta-heurıstica calcula uma solucao e redistri-bui as maquinas virtuais. Na figura o mecanismo transfere a maquina lpcvm1 damaquina Itanhanga para a Pao de Acucar que contem a maquina virtual lpcvm2.A figura tambem mostra a maquina lpcvm3 instanciada na maquina Leblon.

Proc

essa

men

to(%

) Carga total de processamento��

Termino da migracao de lpcvm3@@R

Janela de tempo(s)(a) Uso de CPU na maquina Pao de Acucar emfuncao do tempo.

Mem

oria

(%)

Termino da migracao de lpcvm3@@R

Janela de tempo(s)(b) Uso de memoria na maquina Pao de Acucar emfuncao do tempo.

Figura 4. Apos a migracao da maquina lpcvm1 a maquina virtual lpcvm3 e mi-grada para a Pao de Acucar e as maquinas fısicas Itanhanga e Leblon sao desli-gadas.


99

alocacao de maquinas virtuais. A meta-heurıstica de Arrefecimento descrita na Secao 3.2,e as heurısticas First Fit (FF) e First Fit Decreasing (FF). A heurıstica First Fit tenta alo-car as maquinas virtuais na maquina fısica de menor ındice e caso nao seja possıvel alocana proxima maquina. A First Fit Decreasing se diferencia da FF por ordenar as maquinasvirtuais de forma decrescente de uso de recursos antes de iniciar a minimizacao. Paraesse teste foi o utilizado o FFD padrao que considera as maquinas fısicas com a mesmacapacidade. O criterio de ordenacao para a tecnica FFD foi estabelecido como o usode processamento, memoria e rede, nessa ordem. Foram utilizadas 50, 100, 500 e 1000maquinas virtuais inicialmente instanciadas em 50, 100, 500 e 1000 maquinas fısicas,respectivamente. Foram consideradas maquinas fısicas com capacidade de 100% de pro-cessamento e 16 GB de memoria.

Para criar um ambiente heterogeneo de maquinas virtuais foram gerados recursosde processamento, memoria e rede para cada maquina virtual seguindo uma distribuicaonormal. Os recursos de memoria foram gerados entre 0 e 16 GB com media de 8 GB edesvio padrao de 4 GB. Os de CPU e rede entre 0 a 100% da capacidade das maquinasfısicas com media e desvio padrao de 50%. Os testes consistiram de 10 rodadas limitadasa 320 segundos de execucao e a temperatura do algoritmo de Arrefecimento Simuladofoi inicializada em 1 milhao. Assim, o algoritmo para quando a temperatura ou o tempochega a zero, o que ocorrer primeiro. Esses parametros foram configurados para simularum ambiente em que o tempo de reacao do algoritmo e limitado.

25

30

35

40

45

50

0 5 10 15 20 25 30 35 40

Custo

Tempo (s)

SAFFDSA

FFSA

(a) Desempenho dos algoritmos para 50maquinas virtuais.

55

60

65

70

75

80

85

90

95

100

0 10 20 30 40 50 60 70

Custo

Tempo (s)

SAFFDSA

FFSA

(b) Desempenho dos algoritmos para 100maquinas virtuais.

250

300

350

400

450

500

0 20 40 60 80 100 120 140

Custo

Tempo (s)

SAFFDSA

FFSA

(c) Desempenho dos algoritmos para 500maquinas virtuais.

550

600

650

700

750

800

850

900

950

1000

0 50 100 150 200 250 300 350

Custo

Tempo (s)

SAFFDSA

FFSA

(d) Desempenho dos algoritmos para 1000maquinas virtuais.

Figura 5. Graficos Custo x Tempo para os testes de otimizacao com 50, 100, 500e 1000 maquinas fısicas e virtuais.


100

Os graficos da Figura 5 representam o tempo medio para o Arrefecimento Simu-lado encontrar solucoes e melhorar as solucoes das heurısticas. As figuras mostram aexecucao do Arrefecimento Simulado independente de heurısticas (SA), e a partir dassolucoes obtidas pelas heurısticas First Fit (FFSA) e First Fit Decreasing (FFDSA). Otempo de calculo da solucao inicial gerada pelo FF e pelo FFD para todos os testes foimenor que 1 segundo e foi desconsiderado do grafico. Cada ponto representa a mediae o desvio padrao para 10 rodadas. Os dados foram tomados sempre que o algoritmoencontrava uma solucao de menor custo ou mesmo custo em termos de maquinas fısicas.Independentemente do estado inicial, o algoritmo de Arrefecimento Simulado e capazde reduzir a funcao custo. Consequentemente, o algoritmo reduz o numero de maquinasfısicas para cerca de 60% em todas configuracoes, economizando energia ao desliga-las.

5. ConclusaoEste artigo propos um mecanismo de gerencia de maquinas virtuais que minimiza

o consumo de energia eletrica ao reduzir o numero de maquinas fısicas em funcionamento.O mecanismo utiliza tecnicas de otimizacao baseadas em Arrefecimento Simulado paraobter as solucoes de menor custo, desligando as maquinas ociosas. O mecanismo tambemativa maquinas fısicas quando a demanda por recursos e maior que a oferta disponibilizadapelas maquinas ligadas.

Uma importante contribuicao e o teste e a implementacao do mecanismo na pla-taforma FITS, mostrando que o mecanismo funciona e e capaz de minimizar o consumode energia em um ambiente real. Foi realizado um experimento para comprovar o funcio-namento do mecanismo e um estudo do algoritmo de otimizacao. Os resultados mostramque o mecanismo e capaz de encontrar solucoes de menor custo e migrar as maquinasvirtuais para essas solucoes, desligando as maquinas fısicas que se tornam ociosas nesseprocesso. Por sua vez, o estudo dos algoritmos de otimizacao mostrou que o uso do Algo-ritmo de Arrefecimento Simulado melhora os resultados, sendo a melhor solucao aquelaque faz uso desse algoritmo com a heurıstica First Fit.

Futuramente pretende-se aprimorar o mecanismo atraves de um estudo dos prin-cipais parametros a serem utilizados em diferentes distribuicoes de maquinas virtuais etambem em diferentes topologias de rede. Variaveis tais como numero de saltos entreas maquinas fısicas, origem e destino da migracao e capacidades dos enlaces envolvidosna migracao poderiam ser inseridas. Assim, seria possıvel determinar qual a solucao dedistribuicao de maquinas e a menos custosa em termos de tempo de migracao e distanciado cliente a sua maquina virtual.

Referencias[Bezerra et al. 2014] Bezerra, G. M. G., Mattos, D. M. F., Ferraz, L. H. G. e Duarte, O. C.

M. B. (2014). Sistema automatizado de gerencia de recursos para ambientes virtuali-zados. Em a ser publicado em XXXII Simposio Brasileiro de Redes de Computadorese Sistemas Distribuıdos - SBRC’2014.

[Carvalho e Duarte 2012] Carvalho, H. E. T. e Duarte, O. C. M. B. (2012). Voltaic: volumeoptimization layer to assign cloud resources. Em Proceedings of the 3rd InternationalConference on Information and Communication Systems, ICICS ’12, paginas 3:1–3:7,New York, NY, USA. ACM.


101

[Clark et al. 2005] Clark, C., Fraser, K., Hand, S., Hansen, J. G., Jul, E., Limpach, C., Pratt,I. e Warfield, A. (2005). Live migration of virtual machines. Em Proceedings ofthe 2Nd Conference on Symposium on Networked Systems Design & Implementation -Volume 2, NSDI’05, paginas 273–286, Berkeley, CA, USA. USENIX Association.

[Egi et al. 2008] Egi, N., Greenhalgh, A., Handley, M., Hoerdt, M., Huici, F. e Mathy, L.(2008). Towards high performance virtual routers on commodity hardware. Em Pro-ceedings of the 2008 ACM CoNEXT Conference, paginas 1–12. ACM.

[Fan et al. 2007] Fan, X., Weber, W.-D. e Barroso, L. A. (2007). Power provisioning fora warehouse-sized computer. Em Proceedings of the 34th Annual International Sym-posium on Computer Architecture, ISCA ’07, paginas 13–23, New York, NY, USA.ACM.

[Fernandes et al. 2010] Fernandes, N., Moreira, M., Moraes, I., Ferraz, L., Couto, R., Car-valho, H., Campista, M., Costa, L. e Duarte, O. (2010). Virtual networks: Isolation,performance, and trends. Annals of Telecommunications, 66:339–355.

[Figueiredo et al. 2013] Figueiredo, U. d. R., Lobato, A. G. P., Mattos, D. M. F., Ferraz,L. H. G. e Duarte, O. C. M. B. (2013). Analise de desempenho de mecanismos deencaminhamento de pacotes em redes virtuais. Em XXXI Workshop de Gerencia eOperacao de Redes e Servicos - (WGRS’2013) - SBRC’2013.

[Johnson et al. 1974] Johnson, D., Demers, A., Ullman, J., Garey, M. e Graham, R. (1974).Worst-case performance bounds for simple one-dimensional packing algorithms. SIAMJournal on Computing, 3(4):299–325.

[Kundakcioglu e Alizamir 2009] Kundakcioglu, O. E. e Alizamir, S. (2009). Generalizedassignment problem. Em Floudas, C. A. e Pardalos, P. M., editors, Encyclopedia ofOptimization, paginas 1153–1162. Springer.

[Mattos et al. 2012] Mattos, D. M. F., Mauricio, L. H., Cardoso, L. P., Alvarenga, I. D.,Ferraz, L. H. G. e Duarte, O. C. M. B. (2012). Uma rede de testes interuniversitariacom tecnicas de virtualizacao hıbridas. Em XXX Simposio Brasileiro de Redes deComputadores e Sistemas Distribuıdos - SBRC’2012.

[Mitchell 2002] Mitchell, J. E. (2002). Branch-and-cut algorithms for combinatorial opti-mization problems. Handbook of Applied Optimization, paginas 65–77.

[Moraes et al. 2014] Moraes, I. M., Mattos, D. M., Ferraz, L. H. G., Campista, M. E. M.,Rubinstein, M. G., Costa, L. H. M., de Amorim, M. D., Velloso, P. B., Duarte, O. C. M.e Pujolle, G. (2014). Fits: A flexible virtual network testbed architecture. ComputerNetworks, 63:221–237. Special Issue on Future Internet Testbeds - Part {II}.

[Rodriguez et al. 2013] Rodriguez, E., Prado Alkmim, G., Macedo Batista, D. e Saldanha daFonseca, N. (2013). Trade-off between bandwidth and energy consumption minimi-zation in virtual network mapping. Latin America Transactions, IEEE (Revista IEEEAmerica Latina), 11(3):983–988.

[Waterland 2003] Waterland, A. (2003). Stress. Disponıvel em: http://people.seas.harvard.edu/˜apw/stress/. Acessado em: Marco de 2014.

[Wu et al. 2012] Wu, Y., Tang, M. e Fraser, W. (2012). A simulated annealing algorithmfor energy efficient virtual machine placement. Em Systems, Man, and Cybernetics(SMC), 2012 IEEE International Conference on, paginas 1245–1250.


102

http://people.seas.harvard.edu/~apw/stress/

http://people.seas.harvard.edu/~apw/stress/



Florianópolis - SC



(WGRS)

Sessão Técnica 3

Segurança, privacidade e qualidade de

serviço na Internet

Um Modelo de Falhas em Cascata para Sistemas Globais deGerenciamento de Identidades

Ricardo Macedo1, Aldri Santos1, André Luiz Pires Guedes1,Michele Nogueira1, Yacine Ghamri-Doudane2

1Universidade Federal do Paraná – Curitiba – PR – Brasil

2University of La Rochelle – La Rochelle CEDEX 1 – France

{rtmacedo,aldri,andre,michele}@inf.ufpr.br, [email protected]

Abstract. The increasing number of portable devices requires a global iden-tity management system. However, these systems are cascading failures prone,that is, failures arosed by the coordinated exploitation of common vulnerabi-lities among identities providers to manipulate the authentication operations.Although there are theoretical models to analyze cascading failures resultedfrom nodes overload, cascading failures effects from the coordinated exploi-tation of vulnerabilities in authentication operations remains no investigated.This paper presents an analytical cascading failure model for identity mana-gement systems, enabling the investigation these failures. Results from a casestudy indicate that failure dissemination in biggest sets of identities providerscan compromise a identity management system in about 100%.

Resumo. A explosão do número de dispositivos portáteis conectados tem de-mandado sistemas de gerenciamento de identidades globais. Entretanto, essessistemas são propensos a falhas em cascata, as quais são oriundas da explora-ção coordenada de vulnerabilidades em comum entre provedores de identida-des para manipular as operações de autenticação. Apesar de existirem modelosteóricos para analisar falhas em cascata resultantes da sobrecarga da capaci-dade de nós, o efeito de falhas em cascata decorrente da exploração de vulne-rabilidades nas operações de autenticações em sistemas de gerenciamento deidentidades permanece em sua maioria desconhecidos. Este trabalho apresentaum modelo analítico de falhas em cascata para sistemas de gerenciamento deidentidades, possibilitando a investigação dessas falhas. Resultados de um es-tudo de caso indicam que a disseminação de falhas nos conjuntos maiores deprovedores de identidades pode comprometer até 100% do sistema.

1. Introdução

Atualmente, a explosão do número de dispositivos portáteis conectados tem deman-dado um Sistema de Gerenciamento de Identidades (SGI) global. Recentemente, aCisco Systems, empresa líder no oferecimento de soluções para redes e comunica-ções, previu que no final de 2014 o número de dispositivos portáteis conectados ex-cederá o número de pessoas no planeta e que em 2018 existirão em média 1.4 dispo-sitivos móveis por pessoa [Cisco 2014]. Uma das consequências desta explosão será


105

que cada dispositivo demandará pelos menos uma identidade (ID) para prestar e con-sumir serviços disponibilizados em sistemas distribuídos, tais como nuvens, arquitetu-ras orientadas a serviços (Service-oriented Architectures - SOA) ou Internet das coisas[Lampropoulos and Denazis 2011, Lynch 2011, Angulo and Wästlund 2013]. Neste ce-nário, será necessário um SGI capaz de garantir as operações de autenticação, gestão deautorizações e controle de acesso em escala global.

No entanto, em um SGI há a possibilidade de uma falha em cascata. Uma falhaem cascata consiste em um tipo de falha capaz de ser disseminada através da interdepen-dência de elementos de um sistema [Crucitti et al. 2004]. Nos SGIs uma falha em cascatasurge em decorrência de um ataque coordenado visando explorar as vulnerabilidades emcomum entre provedores de identidades para manipular grande parte das respostas das au-tenticações com intuito de personificar IDs [Camp 2010, Wang et al. 2012, Bertino 2012].A ocorrência desse tipo de falha gera um estado de caos no SGI, pois a garantia das ope-rações de autenticação, gestão de autorizações e controle de acesso é comprometida nosprovedores de serviço. Atualmente, um método eficaz para eliminar os efeitos de umafalha em cascata é desconhecido.

Na literatura, a caracterização de falhas surge como o passo inicial para criaçãode medidas de contenção e mitigação de falhas em cascata [Kinney et al. 2005]. Nasredes de distribuição de energia elétrica e na Internet a ocorrência de colapsos de fun-cionamento impulsionou a consolidação de modelos teóricos que permitem a análise doefeito das falhas em cascata nesses sistemas [Motter and Lai 2002, Crucitti et al. 2004,Havlin et al. 2010]. Todavia, esses modelos assumem como premissa que uma falha emcascata ocorre em virtude da sobrecarga da capacidade dos nós. Em um SGI essa pre-missa não é válida, pois uma falha em cascata dá-se em função da exploração coordenadade vulnerabilidades em comum entre provedores de identidades para manipular as res-postas de autenticações e não em decorrência da sobrecarga de nós, impedindo a merautilização dos modelos existentes. Consequentemente, os efeitos de uma falha em cascatadessa natureza permanecem desconhecidos nos SGIs, reforçando a necessidade de meiospara analisá-los.

Este trabalho apresenta um modelo analítico de falhas em cascata em SGIs, pos-sibilitando a investigação dessas falhas nesse tipo de sistema. A abstração do SGI é rea-lizada através de um grafo. Os vértices desse grafo são particionados em três conjuntos,representando as entidades do sistema, como as IDs, os provedores de identidades e osprovedores de serviços. As arestas representam a interdependência entre os elementos doSGI, descrevendo os diferentes tipos de relações entre estes tipos de entidades. A disse-minação da falha em cascata oriunda da exploração de vulnerabilidades no processo deautenticação entre provedores de identidades é representada através de um caminho entreesses provedores. A falha em cascata é demonstrada através de uma prova por indução nonúmero de provedores de identidades presentes neste caminho.

Um estudo de caso do modelo envolvendo dados reais do sistema Shibboleth daUniversidade de Buffalo mostra que as falhas em cascata podem resultar em danos catas-tróficos. A presença de vulnerabilidades em comum entre os provedores de identidadesé caracterizada pelo modelo proposto através da variação de probabilidades da distribui-ção binomial, resultando em diferentes conjuntos de vértices conectados entre si. Umaanálise do efeito da falha em cascata no maior conjunto de provedores de identidades em


106

detrimento de conjuntos de tamanho aleatório é realizada através da métrica Impacto daFalha em Cascata (IFC). O IFC é obtido através da divisão do número de provedores deidentidades falhos pelo número total de provedores de identidades. Os resultados indi-cam que o IFC nos conjuntos maiores atinge 100% dos provedores de identidades comprobabilidade de presença de vulnerabilidades de 0.45 e que em conjuntos de tamanhoaleatório o IFC chega a atingir 70% dos provedores de identidades. Esse resultado mostraque mesmo com baixa probabilidade de vulnerabilidade entre provedores de identidadesos efeitos de uma falha em cascata em um SGI global são catastróficos.

O restante do trabalho está organizado como segue. Na Seção 2 são apresenta-dos os trabalhos relacionados. A Seção 3 detalha o modelo de falhas em cascata paraSGIs. A Seção 4 explica um estudo de caso envolvendo dados reais de gerenciamento deidentidades coletadas do sistema Shibboleth. Na Seção 5 são apresentadas as conclusões.

2. Trabalhos RelacionadosNa literatura, existem diversas iniciativas para caracterizar falhas em sistemas distribuí-dos, destacando-se a forte análise do comportamento das falhas em cascata. A títulode exemplo, um modelo temporal para caracterizar falhas intermitentes em dispositi-vos elétricos foi proposto [Correcher et al. 2012]. Além disso, também as falhas levesde datacenters foram caracterizadas visando incrementar a disponibilidade dos serviçosprestados [Sankar and Gurumurthi 2013]. Atualmente, a presença de colapsos de funci-onamento em diversos sistemas de larga escala, tais como a Internet e os sistemas SmartGrid, impulsionou investigações para caracterizar falhas em cascata.

Em [Huang et al. 2013] um modelo para caracterizar falhas em cascata em SmartGrid foi apresentado. Nele, a caracterização de falhas considera a relação entre a redede distribuição de energia e a rede de comunicação. Assumiu-se que a falha em umadessas redes implica diretamente na outra. Outra premissa consiste na existência de in-terdependência entre as redes resultantes de uma relação de um para muitos, pois cada nóobtém energia de uma estação de abastecimento específica. Os autores advogam a capa-cidade de caracterizar de modo prático falhas em cascata em Smart Grids, mas salientamas limitações do modelo.

O trabalho de [Wang et al. 2014] apresentou um modelo empregando grafos di-nâmicos para caracterizar falhas em cascata e seus comportamentos na Internet. O dife-rencial desse modelo foi assumir diferentes tipos de vértices para representar os hosts eroteadores da Internet. Essa abordagem possibilitou uma análise mais criteriosa da falhaem cascata e seus efeitos. A caracterização dessas falhas foi realizada assumindo que asfalhas em cascatas são disparadas por ataques intencionais a uma única aresta, represen-tando a conexão entre os vértices do grafo.

Apesar da existência de modelos para caracterizar falhas em cascata em vários sis-temas, nos SGIs esses modelos representam apenas falhas em cascata oriunda da sobre-carga dos serviços prestados. Na literatura há diversos modelos consolidados para carac-terizar falhas em cascata [Motter and Lai 2002, Crucitti et al. 2004, Havlin et al. 2010].Entre esses modelos, uma característica em comum é que o efeito em cascata é desen-cadeado através da sobrecarga dos nós ativos. Em um SGI esses modelos representamapenas falhas em cascata oriundas da sobrecarga dos serviços prestados, enquanto que osefeitos das falhas em cascatas em função da exploração de vulnerabilidades em comum


107

no processo de autenticação entre provedores de identidades continuam desconhecidos.

Este trabalho apresenta um modelo analítico de falhas em cascata para SGIs. Oprincipal diferencial deste modelo consiste em tratar de falhas em função da exploração devulnerabilidades no processo de autenticação de provedores de identidades. Assim comomodelos de falhas em cascata em Smart Grids, assumimos como premissa a interdepen-dência entre elementos do sistema. No SGI, a interdependência ocorre entre diferentesfederações, indicando que a falha em uma federação implicará em falhas em outras fede-rações. Além disso, tal como na caracterização de falhas em cascata na Internet, usamosdiferentes tipos de vértices para diferentes elementos do SGI. Em nosso modelo usamostrês diferentes tipos de vértices para representar as IDs, provedores de identidades e pro-vedores de serviços de um SGI.

3. Modelo de Falhas em Cascata para Sistemas de Gerenciamento deIdentidades

Esta seção detalha o modelo proposto para representar falhas em cascata em um SGI. Asubseção 3.1 detalha a modelagem do SGI através de um grafo. A subseção 3.2 descreveo comportamento do sistema através da teoria dos conjuntos; e a subseção 3.3 demonstrao efeito de falhas em cascata por meio de uma prova por indução.

3.1. Modelo do Sistema de Gerenciamento de Identidades

Os principais conceitos envolvidos em um SGI consistem na entidade, ID, identificadore credencial. Uma entidade pode ser uma pessoa, um serviço de rede ou um disposi-tivo [Torres et al. 2013]. Uma ID consiste na representação digital de uma entidade eminterações eletrônicas [Phiri and Agbinya 2006]. Uma entidade pode assumir várias iden-tidades com diferentes objetivos, por exemplo, em um sistema um usuário pode ter umaconta de usuário comum e outra como super usuário. O identificador consiste em um ín-dice único usado para referenciar uma ID no SGI. Uma credencial trata-se de informaçõesconfidenciais das IDs usadas para provar sua autenticidade em um SGI, podendo ser umasenha ou informações biométricas [Smedinghoff 2012]. A Figura 1 demonstra a relaçãoentre entidade, ID, identificador e credencial.

Figura 1. Relação entre Entidade, Identidade, Identificador e Credencial

Na Figura 1, é ilustrado que uma entidade pode ter várias identidades e que cadaidentidade possui um identificador único e uma credencial. Os conceitos de identificadore credencial podem parecer confusos, mas a principal diferença entre eles é o fato de queum identificador deve ser único em um SGI e a credencial não. No SGI, os provedo-res de identidades consistem nas entidades responsáveis por controlar as credenciais das


108

IDs e prover serviços de autenticação. As entidades incumbidas de disponibilizar servi-ços especificamente para as IDs consistem nos provedores de identidades. Uma federa-ção é um ambiente cooperativo formado pela união de um conjunto de domínios, ondecada domínio agrega diferentes IDs, provedores de identidades e provedores de serviços[Cao and Yang 2010]. Para fins de modelagem, o SGI é considerado como um ambientecooperativo formado pela associação de diversas federações.

As principais operações de um SGI consistem na identificação, autenticação, au-torização e auditoria. A identificação consiste na operação inicial de reconhecimento deuma ID no SGI com base em seu identificador, esta operação não apresenta validação. Aautenticação consiste no ato de verificação da legitimidade de uma ID por meio da veri-ficação de credenciais. A autorização compreende a concessão de privilégios a uma IDapós autenticação. A auditoria consiste no registro das ações realizadas por uma entidadeem um SGI. Essas operações são críticas para o funcionamento correto de um SGI. Omodelo proposto contempla a exploração de vulnerabilidades nas operações de autentica-ção, pois o comprometimento dessa operação pode implicar em falhas nos processos deautorização e de auditoria.

Com este objetivo um SGI é representado por um grafo direcionado G = (V,E),sendo V composto por vértices provenientes do particionamento de três conjuntos devértices, A, B e C. Esses conjuntos caracterizam respectivamente as IDs, os provedoresde identidades e os provedores de serviços do sistema, logo o conjunto de vértices de G é aunião dos conjuntos A, B e C. As arestas de G são representadas pelos conjuntos E1, E2,E3, E4, E5, onde E1 = {(a, b)|a ∈ A, b ∈ B}, E2 = {(b, c)|b ∈ B, c ∈ C}, podendotambém existir arestas entre os elementos de cada conjunto, E3 = {(a1, a2)|a1 ∈ A, a2 ∈

A}, E4 = {(b1, b2)|b1 ∈ B, b2 ∈ B}, E5 = {(c1, c2)|c1 ∈ C, c2 ∈ C}, logo E =5⋃

i=1

Ei.

Cada conjunto de arestas representa um tipo específico de Relação (Re). O con-junto de arestas E1 representa quais provedores de identidades b ∈ B uma ID a ∈ Apode usar para se autenticar. E2 descreve quais provedores de serviço c ∈ C confiamnas autenticações de um provedor de identidades b ∈ B. E3 retrata a composição de IDsparciais de um usuário. E4 expõe a relação dos provedores de identidades que apresen-tam propriedades em comum. E5 representa a composição de provedores de serviços, ouseja, situações onde serviços podem ser consumidos por outros serviços, tal como ocorreem SOAs. Em outras palavras, em G qualquer tipo de relação pode existir, exceto as as-sociações de IDs com provedores de serviços, pois essa relação não é fiel a forma comoos recursos são compartilhados em um SGI.

As direções das arestas em G representam as características do SGI. As arestasentre os conjuntos seguem a direção A → B → C. A direção A → B representa aassociação das IDs com seus respectivos provedores de identidades. B → C indica dequais provedores de identidades os provedores de serviços aceitam autenticações. Dentrode cada conjunto (A, B, C) existem arestas com direção dupla. A análise vai usar a dire-ção das arestas, mas no caso destas, se coloca direção dupla justamente porque as direçõesnão importam para caracterizar as falhas em cascata. Além disso, o grafo G não considerapeso nas arestas, retratando a indiferença de qual provedor de identidades irá autenticaruma ID, contanto que o provedor de serviços desejado aceite essa autenticação. Comotambém, através da perspectiva do provedor de serviços, é indiferente qual provedor de


109

identidades que ele confia autenticou uma ID. A Figura 2 ilustra um exemplo de grafo G.

Figura 2. Exemplo de Grafo de um Sistema Gerenciamento de Identidades Global

Na Figura 2, os vértices de cor branca representam IDs (conjunto A), os de corcinza representam os provedores de identidades do conjunto B e os de cor preta, os pro-vedores de serviços do conjunto C. As arestas de G apresentam a direção A → B → Ce não possuem peso. Também se observa que G é conexo, pois não existem vértices semarestas. Além disso, nota-se que podem existir ciclos em G entre elementos do mesmoconjunto. Sendo Cn um ciclo onde n vértices são adjacentes, o centro do grafo apre-senta um C4 entre elementos de C, representado uma composição de quatro provedoresde serviço. Logo abaixo do C4, um C5 entre elementos do conjunto B é encontrado,caracterizando cinco provedores de identidades com vulnerabilidades em comum no me-canismo de autenticação. A esquerda do centro do grafo, um C6 entre os elementos de A,descrevendo a composição de uma ID através de seis identidades parciais.

3.2. Modelo de Falhas em CascataNesta subseção o modelo de falhas em cascata para um SGI global é descrito usando ateoria dos conjuntos. Na sequência, o modelo de autenticação e da falha em um único nóé apresentado. Considere o particionamento de três conjuntos não vazios de vértices A,B e C de um grafo G, onde V = A ∪ B ∪ C. Seja C ′ o conjunto de subconjuntos de C,ou seja, C ′ = 2|C|, logo os elementos de C ′ representam todas as combinações possíveisdos elementos de C. Em outras palavras, cada elemento de C ′ é um subconjunto deprovedores de serviço que confiam na autenticação de uma ID a ∈ A por um provedorde identidades b ∈ B. Como não existem arestas entre o conjunto de vértices A e C,podemos denotar o conjunto A como o domínio de uma função e B como seu contradomínio formado pelas arestas que saem de A para B. Da mesma forma, o conjunto Bcomo domínio de uma função e C ′ como seu contradomínio.

Seja f : A→ B a função bijetora que descreve as arestas do conjunto A para B eg : B → C ′ a função sobrejetora que descreve as arestas do conjunto B para C ′. Onde,


110

A é o domínio da função f , B é o contra domínio e a imagem é o subconjunto de B.Considerando a função g, o conjunto B é o domínio e C é o contra domínio e a imagem éo subconjunto de C. A Figura 3 ilustra a relação entre esses conjuntos. A Figura 3 ilustraa relação entre esses conjuntos.

Figura 3. Modelo de representação das arestas entre os conjuntos de vértices

Com base nas funções f e g uma função para autenticação é modelada. Seja auth :A× B × C → {verdadeiro, falso} a função bijetora de autenticação cujo retorno é umvalor booleano verdadeiro ou falso. Dessa forma, seja a uma ID do SGI, a função auth(a)descreve uma requisição de acesso da ID a ∈ A para um provedor de identidades b ∈ Bpara acessar um provedor de serviços c ∈ C. Se as credenciais apresentadas para a IDa forem verdadeiras, esta será autenticada com sucesso e auth(a) retornará verdadeiro,caso contrário retornará falso. Seja b ∈ B o provedor de identidades escolhido pelousuário para autenticar a ID a, logo a função g(b) pode ser usada para extrair a quantidadede provedor de serviços que auth nos proporcionará acesso, o resultado desta função seráum valor de no mínimo um e no máximo |C|.

Tendo definido a função de autenticação, o modelo da falha em um único nó doSGI é apresentado. Assumimos uma falha como a exploração de uma vulnerabilidadeno processo de autenticação de um provedor de identidades que resulta na violação dasmedidas de monitoramento e controle das IDs. O modelo da falha é realizado provando oseguinte lema.

Lema 1 Se existe uma vulnerabilidade vul em um provedor de identidades b ∈ B quequando explorada possibilita burlar as credenciais de uma ID, então existem falhas deautorização em no mínimo um e no máximo |C| provedores de serviços c ∈ C.

Prova. Direta. Seja vul uma vulnerabilidade de um provedor de identidades b ∈ B, demodo que vul possibilita manipular a resposta da função auth retornando verdadeiropara um atacante que objetiva passar-se indevidamente por uma ID a ∈ A. Seja faulta função que representa esta falha de segurança no SGI. Logo, podemos denotar faultcomo uma função composta f(g(x)), onde fault(a) = f ◦ g(a) = f(g(a)). Comoauth, possibilita acesso para no mínimo um e no máximo |C| provedor de serviços, logo,se auth for manipulada por um atacante, o número de provedores de serviços afetadospor essa falha também será no mínimo um e no máximo |C|. Portanto, se existe umavulnerabilidade vul em um provedor de identidades b ∈ B que se explorada possibilitaburlar as credenciais de uma ID, então existem falhas de autorização em no mínimo um eno máximo |C| provedores de serviços c ∈ C. �

3.3. Prova por Indução da Falha em CascataEsta subseção demonstra como ocorre a falha em cascata em um SGI. Através do Lema 1provamos que quando um atacante obtém sucesso ao explorar uma vulnerabilidade vul de


111

um provedor de identidades que o possibilita burlar uma credencial de uma ID qualquer,automaticamente todos os provedores de serviços que confiam na autenticação deste pro-vedor de identidades concederão acesso indevido ao atacante para a ID com a autenticaçãoburlada.

Agora, a ocorrência da falha em cascata em um SGI é demonstrada através de umaprova por indução. Este tipo de prova oferece iteratividade, pois através dela podemosrepresentar os estágios da disseminação da falha de segurança e seus efeitos. A ideiabase desta prova consiste em mostrar a existência de um caminho entre os provedores deidentidades que apresentam a mesma vulnerabilidade.

Prova. Por indução no número de provedores de identidades compondo um caminho entreesses provedores com a mesma vulnerabilidade.

Hipótese. Existe um caminho entre os provedores de identidades que representa o efeitode uma falha em cascata.

Base. Queremos demonstrar o efeito de uma falha em cascata quando o caminho entre osprovedores de identidades tem apenas dois vértices.

Seja b1 ∈ B o provedor de identidades cuja a vulnerabilidade vul foi explorada paraburlar o acesso da ID a ∈ B. Seja b2 ∈ B o provedor de identidades adjacente à b1.Seja E4 o conjunto de arestas que representa a relação dos provedores de identidadescom propriedades em comum. Logo, as arestas incidentes à b1 ∈ E4 descrevem quaisprovedores de identidades a vulnerabilidade vul pode ser explorada. Logo, exitem doisvértices b1, b2 conectados por arestas pertencentes à E4. Seja um caminho em um grafouma sequência de vértices, onde cada vértice apresenta uma aresta para o próximo vérticeda sequência. Logo, existe um caminho Pa somente com dois elementos do conjunto devértices B, onde b1 é o vértice inicial e b2 o elemento final. Este caminho representa porquais vértices a falha em cascata pode ser disseminada pelo SGI. Considerando o Lema1, a falha de cada provedores de identidades deste caminho afetará no mínimo um e nomáximo |C| provedores de serviços. �

Passo. Queremos provar que existe um caminho com i+1 provedores de identidades querepresentam uma falha em cascata em um SGI.

Suponha a existência de i provedores de identidades em um caminho Pa.

Logo, existe um caminho Pa = {b1, b2..., bi}, onde cada provedor de identidades possuia vulnerabilidade vul.

Logo, aplicando o Lema 1, existe um caminho Pa = {b1, b2..., bi+1}.Portanto, sabemos que cada um destes vértices pode comprometer no mínimo um e nomáximo |C| provedores de serviço.

Note que através do modelo de falha em cascata proposto, o funcionamento doprovedor de identidades sob ataque não é falha em decorrência da sobrecarga, pois paraautenticações de IDs legítimas, o SGI funcionará normalmente, inclusive com provedoresde identidades falhos. Neste ponto o modelo proposto se diferencia dos modelos de falhaem cascata da literatura, pois a disseminação da falha não ocorre com base na sobrecargados nós e sim na exploração de vulnerabilidades presentes em um conjunto de provedoresde identidades.


112

4. Estudo de CasoEsta seção descreve um estudo de caso aplicando o modelo proposto. A Subseção 4.1detalha informações da base de dados coletada de um SGI. A Subseção 4.2 apresenta aabstração do sistema através do modelo proposto. A Subseção 4.3 explica a análise doefeito da falha em cascata na abstração do SGI.

4.1. Descrição da Base de Dados ShibbolethO estudo de caso é realizado sobre dados coletados do sistema Shibboleth. O Shibbolethconsiste no framework de gerenciamento de identidades federado mais utilizado no meioacadêmico para Web Single Sign-on [Watt et al. 2011]. A técnica de Single Sign-on per-mite que uma autenticação bem sucedida em um provedor de identidades de um domínioseja aceita em outros domínios da federação, sem a exigência de novas autenticações acada nova sessão e minimizando a necessidade do usuário memorizar um grande númerode senhas. Esta solução federada vem sendo projetada para suprir a necessidade de ga-rantir o acesso seguro a recursos compartilhados entre diferentes domínios de maneiradescentralizada.

Uma base de dados composta por logs de autenticação de um sistema Shibbolethreal foi empregada para criação de um cenário de análise. Os dados foram coletadospelo SGI da Universidade de Buffalo, localizada em Nova York. O período de coletacompreendeu os meses de Abril de 2009 até Setembro de 2013. Os logs de autentica-ção são categorizados por mês e ano representando as autenticações por domínio e porserviço. Esses dados utilizados podem ser encontrados no sítio Web da Universidade deBuffalo [UBI ]. As autenticações por domínio contabilizam as requisições de autentica-ção originadas por navegadores do domínio interno da rede. As autenticações por serviçocontabilizam e categorizam as requisições pelo serviço Web destino.

Ao todo, 110 arquivos categorizados por mês são extraídos. Para cada mês sãoobtidos dois arquivos, um contendo as requisições de autorização por domínio e outrocom as requisições de autenticação por serviço. Para evitar a análise de uma grandequantidade de dados, um arquivo com maior representatividade para análise foi escolhido,sem a perda de generalidade. Desta forma, são escolhidos os dados de autenticação deum mês com maior número de provedores de identidades, provedores de serviços e o maisrecente possível. Com base nestes critérios, o mês de Setembro de 2013 foi selecionadopara análise. Neste mês a infra-estrutura de gerenciamento de identidades analisada contacom seis provedores de identidades s e dez principais provedores de serviços, totalizandomais de dois milhões de autorizações.

4.2. Abstração do sistema Shibboleth Através do Modelo PropostoA abordagem utilizada para representar o sistema Shibboleth através do grafo propostocomo modelo consiste em separar os provedores de serviços, os provedores de identidadese as IDs em diferentes conjuntos de vértices e em seguida relacioná-los. Denotamos umainstância desse grafo como H = (V,E), onde V é o particionamento de três conjuntosde vértices, A, B e C, caracterizando IDs, provedores de identidades e provedores deserviços, respectivamente, logo V = A ∪B ∪ C, conforme definido no modelo.

Com base nas informações disponibilizadas não foi possível extrair o númeroexato de IDs para o conjunto A, pois somente as requisições originadas por cada do-mínio foram disponibilizadas. Isto impossibilitou a identificação da existência de ciclos


113

entre IDs e das associações entre IDs e provedores de identidades. Entretanto, entende-se que esse fato não compromete os objetivos da análise, pois podemos considerar asIDs como um único conjunto e investigar a disseminação da falha entre os provedores deidentidades. Com esse fim o vértice denominado identidades foi criado.

Para definição dos conjuntos B e C foi possível extrair o número exato de ele-mentos. O conjunto B, responsável por agregar os provedores de identidades, apre-senta seis elementos, sendo eles: download.acsu.buffalo.edu, myub.buffalo.edu, uble-arns.buffalo.edu, ubsis.buffalo.edu, myaccount.myubcard.com e ubmail.buffalo.edu. En-quanto que o conjunto C, incumbido de representar os provedores de serviços, totalizadez elementos, sendo eles: messagesystems.com, rr.com, optonline.net, level3.net, pa-vlovmedia.com, mycingular.net, verizon.net, com.sg, myvzw.com e buffalo.edu. A Figura4 ilustra o grafo H .

Figura 4. Grafo do Sistema de Gerenciamento de Identidades Shibboleth

Na Figura 4, os vértices de cor branca, cinza e preta, representam respectivamenteos conjuntos A, B e C pertencentes a H e suas respectivas arestas. O único vértice brancoda figura foi usado para representar o conjunto identidades que agrega todas as IDs doSGI. Os vértices de cor preta representam seis provedores de identidades da Universidadede Buffalo, constituindo o conjunto B. Aqueles de cor cinza representam os provedores deidentidades e consequentemente o conjunto C. O conjunto de arestas E1 é representadopelas linhas do conjunto A para cada elemento do conjunto B. O conjunto de arestasE2 é caracterizado pelas linhas contínuas que partem de cada elemento do conjunto Bpara todos os elementos do conjunto C. Os conjuntos de arestas E3, E4 e E5 não foramrepresentadas nesta figura, pois os dados analisados não descreviam essas relações. Maisdetalhes sobre o conjunto de arestas E4 são descritos na Subseção 4.3.

Tendo definido o grafo a ocorrência da falha em cascata neste sistema é analisada.Considere que os seis provedores de identidades do grafo H apresentam uma vulnerabili-dade vul em comum. Dessa forma, existe um caminho Pa contendo os seis provedores deidentidades pertencentes ao conjunto de vértices B que demonstra uma possível sequên-cia de falhas decorrentes da exploração de vul. Tendo como base o Lema 1, então cadaum destes provedores de identidades afetará no mínimo um e no máximo |C| provedoresde serviços c ∈ C. Como todos os provedores de identidades foram afetados, logo |C|provedores de serviços serão comprometidos. Dessa forma, Pa representa o caminho de


114

uma falha em cascata no sistema Web Single Sign-on Shibboleth utilizado como estudo decaso, embasando a aplicabilidade do modelo neste sistema.

É possível perceber que ao realizar essa demonstração da falha em cascata teve-se o cuidado para não realizá-la de maneira exaustiva e repetitiva. Outra questão quepode chamar atenção é que o estudo de caso apresentado baseia-se em dados coletadosde apenas uma federação de identidades, mas o modelo proposto visa representar umSGI composto por diversas federações. Essa decisão é justificada pela capacidade domodelo proposto em representar tanto federações, quanto um SGI composto por diversasfederações. O modelo proposto representa as entidades do SGI e as relações entre essasentidades, não distinguindo a qual federação a entidade pertence.

4.3. Análise do Efeito da Falha em Cascata

Esta subseção apresenta a análise da falha em cascata no SGI Shibboleth da Universidadede Buffalo. A análise do efeito da falha em cascata compõe três etapas. A primeira etapaconsiste em representar o subgrafo de provedores de identidades através de uma matrizde adjacência. A segunda aplica diferentes probabilidades da distribuição binomial paravariar a presença de vulnerabilidades em comum nos mecanismos de autenticação destesprovedores de identidades. A terceira mensura o efeito da disseminação de falhas nascomponentes conexas através da definição da métrica impacto da falha em cascata.

Seja H ′ o subgrafo com seis vértices que descreve as relações entre os provedo-res de identidades do grafo H e M como a matriz de adjacência para representá-lo, logoM(H ′) = M6,6 . Para denotar o conjunto de arestas E4, responsáveis por descrever vul-nerabilidades em comum entre mecanismos de autorização de provedores de identidades,é necessário que as entradas mi,j da matriz M contenham 1 se mi,j e mj, i são adjacentese 0 caso contrário. A Figura 5 apresenta a matriz de adjacência M .

M6,6 =

índices 1 2 3 4 5 6

1 m1,1 m1,2 m1,3 m1,4 m1,5 m1,6

2 m2,1 m2,2 m2,3 m2,4 m2,5 m2,6

3 m3,1 m3,2 m3,3 m3,4 m3,5 m3,6

4 m4,1 m4,2 m4,3 m4,4 m4,5 m4,6

5 m5,1 m5,2 m5,3 m5,4 m5,5 m5,6

6 m6,1 m6,2 m6,3 m6,4 m6,5 m6,6

Figura 5. Matriz de Adjacência M

Na Figura 5, os índices de 1 à 6 representam os vértices que especificam meca-nismos de autenticação dos provedores de identidades do subgrafo H ′. O conjunto deelementos em vermelho (estilo de fonte em negrito) representa o triângulo superior damatriz. O conjunto de elementos em azul (estilo normal de fonte) caracteriza o triânguloinferior. Enquanto que o conjunto de elementos em verde (estilo de fonte em itálico)descreve a diagonal principal. A diagonal principal da matriz m é preenchida com zeros,indicando a inexistência de arestas de um vértice para si mesmo. Os valores do triângulosuperior e inferior variam entre zero e um de forma simétrica ao longo da diagonal prin-cipal para compor o conjunto de arestas E4. A garantia da simetria da matriz ao longo


115

da diagonal principal é garantida através da soma da matriz com a diagonal principal e otriângulo inferior mais sua transposta, ou seja, M = T (M).

A distribuição binomial é aplicada com diferentes probabilidades para obtençãodos valores da matriz de adjacência, gerando um espaço amostral da presença de vulnera-bilidades. Para representar as arestas entre os seis vértices são necessários quinze valoresdistribuídos de forma simétrica entre o triângulo superior e inferior, variando entre zero eum. O total de combinações de zeros e uns para quinze valores é igual a 215, resultandoem 32768 combinações. Considerando a presença de um grande número de provedoresde identidades em um SGI global, percebe-se que analisar todas as possibilidades podeser uma tarefa exaustiva, justificando a análise de amostras.

Ao todo dez variações de probabilidades são analisadas, para cada uma delas 35amostras foram colhidas. O intervalo de variação de probabilidade para caracterizar apresença de vulnerabilidades em comum entre os mecanismos de autenticação do SGIShibboleth compreende os valores 0.05, 0.1, 0.15, 0.2, 0.25, 0.3, 0.35, 0.4, 0.45 e 0.5.Como resultado da aplicação destes valores na matriz de adjacência, cada amostra dosubgrafo H ′ apresenta n componentes conexas de provedores de identidades.

A análise para mensurar o impacto da falha em cascata dá-se através da com-paração da disseminação de falhas nas componentes conexas gigante em detrimento àscomponentes conexas aleatórias. Assumimos que a descoberta de uma vulnerabilidadede uma componente conexa sempre será disseminada para todos os demais provedores deidentidades. Além disso, definimos como provedores de identidades falhos aqueles quetiveram as vulnerabilidades de seus mecanismos de autenticação exploradas. Para men-surar o efeito da falha em cascata a métrica IFC, denotada pela equação IFC = NPIF

NTPI,

é definida. Onde NPIF consiste no número de provedores de identidades falhos e NTPIrepresenta o número total de provedores de identidades.

Os resultados da análise mostram que uma falha em cascata em um SGI real poderesultar em danos catastróficos. A comparação entre a disseminação de falhas na Compo-nente Conexa Gigante (CCG) e em Componente Conexa Aleatória (CCA) aponta que adisseminação de falhas na componente conexa gigante são mais prejudiciais. No entanto,mesmo a disseminação de falhas em componentes conexas de tamanho aleatório podecomprometer um SGI em cerca de 70%. A Figura 6 ilustra esses resultados.

10

20

30

40

50

60

70

80

90

100

00.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5

Impac

to d

a F

alha

em C

asca

ta (

%)

Probabilidade de Vulnerabilidade

CCG CCA

Figura 6. Comparação da Disseminação de Falhas na CCG e em CCAs


116

Na Figura 6 é ilustrada a média da comparação da disseminação de falhas na CCGem detrimento a CCA de provedores de identidades do SGI Shibboleth da Universidadede Buffalo com intervalo de confiança de 95%. A análise deste gráfico aponta que o IFCna maior componente conexa apresenta um crescimento exponencial próximo a 100%dos provedores de identidades com 0.45 de probabilidade da presença de vulnerabilida-des. Em contraste, o ápice do IFC nas componentes conexas aleatórias compreendeu umvalor inferior a 70% de provedores de identidades com 0.4 de probabilidade da presençade vulnerabilidade. Esse resultado mostra que mesmo com baixa probabilidade de vulne-rabilidade entre provedores de identidades os efeitos de uma falha em cascata em um SGIglobal são catastróficos.

5. Conclusões

Este trabalho apresentou um modelo analítico de falhas em cascata em um SGI e ana-lisar seu efeito. O SGI foi modelado através de um grafo e seus comportamentos coma teoria dos conjuntos. A disseminação da falha em cascata foi representada através deum caminho entre provedores de identidades com vulnerabilidades em comum no pro-cesso de autenticação. Um estudo de caso foi realizado para demonstrar a aplicabilidadedo modelo proposto considerando dados reais de gerenciamento de identidades coletadosdo Web Single Sign-On Shibboleth da Universidade de Buffalo. No estudo de caso, a pre-sença de vulnerabilidades em comum entre os provedores de identidades foi caracterizadaatravés de variações de probabilidades da distribuição binomial, resultando em diferentesconjuntos de vértices conectados entre si. Os resultados indicam que a disseminação defalhas com probabilidade de vulnerabilidades de 0.45 nos conjuntos maiores impacta em100% dos provedores de identidades e a disseminação de falhas em conjuntos de tamanhoaleatório pode comprometer até 70% desses provedores.

Referências

UB Identity Management and Authentication Metrics. https://ubidm.buffalo.edu/stats/. Último Acesso em Outubro de 2013.

Angulo, J. and Wästlund, E. (2013). Identity management through “profiles”: Prototypingan online information segregation service. In Kurosu, M., editor, Human-ComputerInteraction. Users and Contexts of Use, volume 8006 of Lecture Notes in ComputerScience, pages 10–19. Springer Berlin Heidelberg.

Bertino, E. (2012). Trusted identities in cyberspace. IEEE Internet Computing, 16(1):3–6.

Camp, J. (2010). Identity management’s misaligned incentives. IEEE Security Privacy,8(6):90 –94.

Cao, Y. and Yang, L. (2010). A survey of identity management technology. In IEEEInternational Conference on Information Theory and Information Security (ICITIS),2010, pages 287 –293.

Cisco (2014). Cisco Visual Networking Index. http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/white_paper_c11-520862.pdf.Último Acesso em Fevereiro de 2014.


117

Correcher, A., Garcia, E., Morant, F., Quiles, E., and Rodriguez, L. (2012). Intermittentfailure dynamics characterization. IEEE Transactions on Reliability, 61(3):649–658.

Crucitti, P., Latora, V., and Marchiori, M. (2004). Model for cascading failures in complexnetworks. Phys Rev E Stat Nonlin Soft Matter Phys, 69(4 Pt 2):045104.

Havlin, S., Araujo, N. A. M., Buldyrev, S. V., Dias, C. S., Parshani, R., Paul, G., andStanley, H. E. (2010). Catastrophic cascade of failures in interdependent networks.Nature.

Huang, Z., Wang, C., Ruj, S., Stojmenovic, M., and Nayak, A. (2013). Modeling casca-ding failures in smart power grid using interdependent complex networks and perco-lation theory. In IEEE Conference on Industrial Electronics and Applications, pages1023–1028.

Kinney, R., Crucitti, P., Albert, R., and Latora, V. (2005). Modeling cascading failures inthe north american power grid. The European Physical Journal B - Condensed Matterand Complex Systems, 46(1):101–107.

Lampropoulos, K. and Denazis, S. G. (2011). Identity management directions in futureinternet. IEEE Communications Magazine, 49(12):74–83.

Lynch, L. (2011). Inside the identity management game. IEEE Internet Computing,15(5):78–82.

Motter, A. E. and Lai, Y.-C. (2002). Cascade-based attacks on complex networks. Phys.Rev. E, 66:065102.

Phiri, J. and Agbinya, J. (2006). Modelling and information fusion in digital identitymanagement systems. In Networking, International Conference on Systems and In-ternational Conference on Mobile Communications and Learning Technologies, page181.

Sankar, S. and Gurumurthi, S. (2013). Soft failures in large datacenters. IEEE ComputerArchitecture Letters, 99(RapidPosts):1.

Smedinghoff, T. J. (2012). Solving the legal challenges of trustworthy online identity.Computer Law & Security Review, 28(5):532 – 541.

Torres, J., Nogueira, M., and Pujolle, G. (2013). A survey on identity management forthe future network. IEEE Communications and Surveys Tutorials, 15(2):787–802.

Wang, J., Jiang, C., and Qian, J. (2014). Robustness of internet under targeted attack:A cascading failure perspective. Journal of Network and Computer Applications,40(0):97 – 104.

Wang, R., Chen, S., and Wang, X. (2012). Signing me onto your accounts through fa-cebook and google: A traffic-guided security study of commercially deployed single-sign-on web services. In IEEE Symposium on Security and Privacy, pages 365 –379.

Watt, J., Sinnott, R., Inman, G., and Chadwick, D. (2011). Federated authentication andauthorisation in the social science domain. In International Conference on Availability,Reliability and Security, pages 541 –548.


118

Análise Sistemática do Fenômeno BufferbloatThiago B. Cardozo1, Alex B. Vieira2, Artur Ziviani1, Ana Paula C. Silva3

1Laboratório Nacional de Computação Científica (LNCC)Petrópolis – RJ – Brasil

2Departamento de Ciência da ComputaçãoUniversidade Federal de Juiz de Fora (UFJF)

Juiz de Fora – MG – Brasil

3Departamento de Ciência da ComputaçãoUniversidade Federal de Minas Gerais (UFMG)

Belo Horizonte – MG – Brasil

[email protected],[email protected],

[email protected],[email protected]

Abstract. There is a recent interest in the bufferbloat phenomenon as a possibleexplanation for the increased network latency observed in the Internet. Thebufferbloat phenomenon is related to the excessive packet queueing in over-sizedbuffers inside the network that may lead to network performance degradation. Inthis context, we observe a lack of experimental results considering the practicalaspects of off-the-shelf network devices. Therefore, in this paper, we present asystematic analysis of the bufferbloat phenomenon considering the microscopicview of the insides in the buffer architecture of typical network devices. Ourexperimental results show that bufferbloat might not be a significant problemin practice. First, the phenomenon is only observed in specific cases. Second,changes made to the queues under the control of the operating system havenegligible effects. Finally, recent proposals that are commonly implemented inrecent versions of the Linux kernel avoid bufferbloat, even in the specific casesin which it was observed.

Resumo. Há um interesse recente no fenômeno chamado bufferbloat como umapossível explicação para o aumento de latência observado na Internet. O fenô-meno bufferbloat está relacionado ao armazenamento excessivo de pacotes embuffers superdimensionados nos dispositivos de redes que pode levar a uma de-gradação do desempenho da rede. Neste contexto, observamos a falta de resul-tados experimentais considerando os aspectos práticos de dispositivos de redeexistentes comercialmente. Assim, neste artigo, apresentamos uma análise sis-temática do fenômeno bufferbloat considerando a visão microscópica da arqui-tetura de filas de um dispositivo de rede típico. Nossos resultados experimentaismostram que o bufferbloat pode não ser um problema significativo na prática.Primeiro, o fenômeno só é observado em casos específicos. Segundo, altera-ções nas filas sob controle do sistema operacional têm efeitos negligenciáveis.Finalmente, propostas comumente implementadas em versões recentes de sis-temas operacionais como Linux evitam o bufferbloat, até mesmo nos cenáriosespecíficos em que se observou tal fenômeno.


119

1. IntroduçãoO aumento na latência fim-a-fim é um dos problemas que afetam a Internet nos diasatuais [Lee et al., 2010]. A literatura recente identifica o fenômeno do bufferbloatcomo uma das possíveis causas para este aumento. O bufferbloat ocorre como con-sequência das filas com excessivo espaço de armazenamento que estão presentes nosroteadores da rede. Esta grande quantidade de armazenamento gera um atraso sig-nificativo, que persiste por longos intervalos de tempo, degradando o desempenho darede [Gettys e Nichols, 2012]. Assim, os últimos anos têm testemunhado uma grande ati-vidade na comunidade científica de redes de computadores envolvendo estudos a respeitodo bufferbloat [Nichols e Jacobson, 2012, Jiang et al., 2012a, Chirichella e Rossi, 2013,Hohlfeld et al., 2012, Allman, 2013].

Filas nos roteadores absorvem rajadas de tráfego, evitando, portanto, aperda de dados, sendo seu dimensionamento, entretanto, um desafio recorrente naárea [Appenzeller et al., 2004]. Filas com tamanhos excessivamente grandes podem im-pactar no funcionamento do controle de congestionamento do TCP (Transmission ControlProtocol), o protocolo de transporte mais comum na Internet. Dado que o TCP detectao congestionamento na rede mediante a perda de pacotes [Jacobson, 1988], o armazena-mento excessivo nas filas faz com que os atrasos aumentem significativamente, sem queo TCP diminua a taxa de envio de dados. Este comportamento acarreta em sobrecargaainda maior na rede, potencializando a emergência de latência fim-a-fim excessiva.

Apesar da capacidade excessiva de enfileiramento nos dispositivos de rede ea consequente possibilidade do aumento na latência fim-a-fim, a maioria dos estu-dos existentes no assunto apenas discute o potencial impacto negativo do buffer-bloat [Gettys e Nichols, 2012, Nichols e Jacobson, 2012], sem apresentar uma análisesistemática avaliando o fenômeno em si. Allman [Allman, 2013] apresentou um primeiroestudo sistemático do bufferbloat, investigando o problema de um ponto de vista ma-croscópico através de medições em uma rede de larga escala. Sua principal conclusão é:apesar de o fenômeno do bufferbloat possivelmente acontecer, o impacto em redes comtráfego real é pequeno.

Neste artigo, apresentamos uma análise sistemática dos efeitos do bufferbloat con-siderando uma visão microscópica das filas internas de uma arquitetura típica de dispo-sitivos de rede. Avaliamos as principais métricas de rede, como a latência fim-a-fim e avazão, em cenários que variamos o tamanho das principais filas dos roteadores. Nossosexperimentos foram conduzidos em um testbed controlado, usando hardware comercial esoftware gratuito. Nossa investigação analisa os efeitos causados pelo aumento do tama-nho das filas nos dispositivos de rede comumente encontrados no mercado. Em tais dis-positivos, há duas filas principais: (i) uma fila circular ligada ao hardware da interface derede (ring buffer); e (ii) outra fila ligada ao sistema operacional (qdisc). A visão micros-cópica do problema apresentada em nosso estudo experimental complementa o trabalhode Allman [Allman, 2013] que considerou uma visão macroscópica do problema, atravésde medições em uma rede de larga escala e em somente uma das filas que consideramos.

Nossos resultados experimentais mostram que, ao contrário do indicado em tra-balhos anteriores [Gettys e Nichols, 2012, Nichols e Jacobson, 2012, Jiang et al., 2012a,Chirichella e Rossi, 2013], o bufferbloat pode não ser um problema significativo,uma vez que este somente é observado em casos específicos. De fato, Hohl-


120

feld et al. [Hohlfeld et al., 2012] sugeriram recentemente que o bufferbloat tem poucoefeito na Qualidade de Experiência (QoE) de aplicações multimídia para o usuário final.Considerando nosso estudo, somente percebemos um impacto considerável nas princi-pais métricas de rede em cenários onde variamos apenas o tamanho do ring buffer (filacircular relacionada à interface de rede). Neste caso, o aumento dessa fila específica re-sulta em um aumento excessivo na latência, caracterizando o fenômeno bufferbloat. Porexemplo, comparando-se o cenário com valores padrões das filas com o cenário ondeincrementa-se o tamanho do ring buffer para 4096 pacotes, observamos até 585% a maisno atraso fim-a-fim. Em contraste, alterações no qdisc (fila relacionada ao sistema opera-cional) não apresentam impactos significativos em métricas como atraso fim-a-fim e taxade transferência. Finalmente, também apresentamos uma análise considerando mecanis-mos disponíveis em versões recentes do kernel de sistemas operacionais Linux que foramincorporados visando o combate aos efeitos do bufferbloat.

Este artigo está organizado como se segue. Na Seção 2, apresentamos em maisdetalhes o fenômeno bufferbloat. A Seção 3 descreve o ambiente de testes que utilizamos.Apresentamos os experimentos e análises na Seção 4. Na seção 5, revisamos algumasdas possíveis soluções encontradas na literatura. Finalmente, a Seção 6 resume nossosprincipais resultados e discute possíveis trabalhos futuros.

2. O fenômeno bufferbloat

Filas em redes de comutação de pacotes são utilizadas para absorver taxas de che-gada de pacotes que podem variar significativamente em um pequeno intervalo detempo [Nichols e Jacobson, 2012]. Atualmente, devido ao baixo custo da memória pre-sente nos roteadores, não é raro encontrar uma grande capacidade de armazenamentonestes equipamentos, inclusive nas versões mais simples. A premissa dos fabricantes éque uma quantidade maior de capacidade de armazenamento evita perda de pacotes, me-lhorando a qualidade do serviço prestado pela rede ao usuário.

No entanto, o cenário descrito introduz um problema de desempenho,recentemente identificado como o fenômeno bufferbloat [Gettys e Nichols, 2012,Nichols e Jacobson, 2012], em que o enfileiramento excessivo de pacotes resulta em umalatência fim-a-fim elevada, bem como na degradação da vazão dos dados. De fato, filasgrandes em roteadores não é um problema recente [Nagle, 1985]. Em uma rede com filasinfinitas e pacotes com tempo de vida limitado, a vazão tende a zero. Isso ocorre porquepacotes são enfileirados por longos períodos e seu tempo de vida expira antes (ou logoapós) dos mesmos serem reencaminhados pelos roteadores.

Um importante efeito colateral do fenômeno bufferbloat é a degradação na efi-ciência do algoritmo de controle de congestionamento do TCP. O algoritmo de controlede congestionamento do TCP ajusta a sua taxa de transferência face a um aumento delatência que resulta em perda de pacotes, evitando assim uma saturação desnecessáriado caminho [Jacobson, 1988]. Esse algoritmo considera, portanto, o descarte de pacotescomo uma indicação implícita de congestionamento na rede. Com o aumento da capaci-dade de armazenamento dos roteadores, e a consequente disponibilidade de maiores filasde pacotes, o congestionamento do caminho ocorre sem o descarte de pacotes. Destaforma, o algoritmo de controle de congestionamento do TCP não ajusta a sua janela detransmissão adequadamente, degradando o desempenho da rede.


121

Em resumo, o fenômeno bufferbloat pode ser a causa chave para o aumento dalatência fim-a-fim observado na Internet atual. O enfileiramento excessivo nos roteadorespode reduzir o desempenho do TCP, que por sua vez impacta na qualidade da maioria dasaplicações que utilizam a Internet. O possível impacto negativo no desempenho da redee suas implicações práticas são os principais pontos de motivação para uma investigaçãomais detalhada do bufferbloat.

3. Ambiente de teste

3.1. Testbed

Nosso testbed é configurado de maneira a possibilitar a análise sistemática do fenômenobufferbloat através do controle de importantes parâmetros, tais como o tamanho das filasdos dispositivos de rede envolvidos no experimento. A experimentação proposta permitea avaliação de métricas de rede relevantes, como a latência fim-a-fim e a vazão. Neste ar-tigo, consideramos diferentes cenários onde variamos o tamanho das filas dos dispositivosde redes pertencentes ao testbed.

A Figura 1 mostra a topologia do testbed utilizado nos experimentos. A redeconsiste de 5 MacMinis1 executando GNU/Debian 6.02 com kernel Linux 3.2 e 3.11.Cada host possui 1 GB de RAM e uma interface de rede Ethernet Gibabit. Os cinco hostsestão conectados através de duas VLANs, uma contendo os nós A, B, C e D e a outra osnós D e E.

Figura 1. Configuração do testbed.

No testbed configurado, o nó D atua como um roteador doméstico, sendoeste o principal equipamento de rede com problemas de excesso de enfileira-mento [Gettys e Nichols, 2012]. Note que a conexão entre D e E é o gargalo da redeconfigurada. Toda a comunicação entre 2 nós finais precisa passar pelo roteador no centroda topologia. Por exemplo, dados que o nó A envia para o nó E passam através do nó D,formando um caminho de 2 saltos. O nó D executa o software de roteamento Quagga3.

1www.apple.com2www.debian.org3www.nongnu.org/quagga/


122

Quagga é um software de código aberto que implementa os algoritmos de roteamentomais importantes.

Sem perda de generalidade, nosso testbed representa um cenário típico. Normal-mente, entre um roteador doméstico e a rede de um ISP, e até mesmo entre pequenas redesde escritório, observamos um gargalo em apenas um enlace. Em outras palavras, os pon-tos finais da rede possuem uma grande quantidade de recursos. No entanto, estes pontossão geralmente conectados por um enlace de capacidade limitada. Dessa forma, durantenossos experimentos, assumimos que a maioria dos fluxos passa por este único gargalo.

3.2. Configuração das filas

O elemento principal da análise microscópica do bufferbloat proposta neste artigo é aconfiguração das filas no testbed. As filas estão por todo o caminho na rede, incluindonos hosts finais, nos roteadores e nos switches. Desta forma, é importante ter em menteo quadro geral que descreve o fluxo de pacotes da camada de aplicação até a camada deenlace.

Em nosso trabalho focamos em dispositivos baseados em Unix, dado que a maio-ria dos equipamentos comerciais são desenvolvidos com base neste sistema operacional.Além disso, há muitos hosts finais, servidores e até mesmo dispositivos móveis que sãodesenvolvidos com seu kernel ou seus módulos baseados em Unix. Alguns exemplos são:pontos de acesso, roteadores domésticos, Macs e dispositivos Android.

A Figura 2 mostra a arquitetura de filas de uma pilha de protocolos de rede emdispositivos baseados em Unix. Estamos particularmente interessados no comportamentodo sistema quando as filas qdisc e ring buffer tem seu tamanho variado.4 Estas filas sãoresponsáveis pelo armazenamento de pacotes nas camadas de rede e enlace, respectiva-mente. Além disso, focamos nossa análise nas filas de saída uma vez que as filas deentrada possuem capacidade suficiente para o processamento dos pacotes.

A fila de saída qdisc está localizada entre as camadas de rede e enlace. Em sis-temas Unix, o qdisc possui 1000 pacotes como capacidade padrão. Contudo, é possívelconfigurar essa capacidade usando o comando ifconfig, através do parâmetro txqueuelen.O qdisc apresenta por padrão uma política de enfileiramento baseada em FIFO. Em outraspalavras, pacotes são enfileirados na ordem em que chegam e são reencaminhados para acamada de enlace na mesma ordem.

O ring buffer, ao contrário, é uma fila de saída colocada entre as camadas de enlacee física. Ela recebe os pacotes que chegam do qdisc e os entrega para a camada física doNIC (Network Interface Card). O tamanho padrão e os limites inferior e superior do ringbuffer são definidos pelo driver do NIC, que é geralmente configurado, por padrão, emtorno de 512 pacotes. A possibilidade de mudar a capacidade do ring buffer usando ocomando ethtool depende da disponibilidade de tal funcionalidade no driver do NIC.

4Tipicamente, refere-se ao tamanho das filas qdisc e ring buffer como a capacidade de armazenamentode pacotes que estas possuem. Em uma implementação prática, entretanto, essas filas na verdade armaze-nam descritores que apontam para a região de memória onde o conteúdo de cada pacote se encontra.

5Figura simplificada baseada na Figura 6-3 de [Wehrle et al., 2004].


123

AplicaçãoEspaço deusuário

Buffer de enviodo TCP (tcp_wmem)

Espaço deKernel

Processo TCP

Camada IP

qdisc(txqueuelen)

RingBuffer

Driver do NIC

Transmissão dePacote

Figura 2. Arquitetura de filas em sistemas baseados em Unix.5

4. Resultados experimentais e análises

Em nossos experimentos, realizamos transmissões de um fluxo TCP de longa duração, se-guindo a metodologia apresentada por [Jiang et al., 2012b]. O principal objetivo é buscarinduzir a ocorrência do fenômeno bufferbloat no testbed (Figura 1).

O nó E, definido como cliente, realiza downloads de arquivos de 3 servidores (nósA, B e C) usando o nó D com roteador. Em cada experimento, usamos um arquivo deconteúdo aleatório com tamanho aproximado de 32 MB, suficiente para garantir que osmecanismos de controle de congestionamento do TCP fossem acionados. Este arquivoé copiado dos servidores para o cliente E, simulando um fluxo TCP de longa duração.São realizadas 10 transferências de cada um dos três servidores, somando 30 cópias con-correntes e cerca de 1 GB de dados transferidos no total, para garantir que o enlace degargalo seja estressado.

Para cada experimento, monitoramos o tempo de ida e volta (RTT) pelo uso daferramenta ping como um fluxo de sonda para coleta de dados e a vazão obtida entreos nós servidores e o nó cliente do testbed. Também monitoramos o número de pacotesdescartados. Os resultados apresentados são a média dos valores de 10 experimentos combarras entorno da média mostrando o erro padrão da média (SEM = σ/

√n), onde σ é o

desvio padrão e n o número de amostras. De forma similar a [Allman, 2013], assumimosque o RTT varia pela variação de ocupação das filas. Outras flutuações de atraso nãocausadas pela ocupação da fila são consideradas negligenciáveis.


124

4.1. Experimentos variando o tamanho do ring bufferNesta seção, analisamos o impacto da variação do tamanho do ring buffer no fenômenobufferbloat, mantendo o tamanho padrão do qdisc (1000 pacotes). Este cenário é equi-valente ao cenário analisado no estudo original que descreveu o fenômeno bufferbloatproposto em [Gettys e Nichols, 2012]. A Figura 3(a) mostra a média do RTT para di-versos tamanhos de ring buffer. Pelos resultados, podemos claramente notar que o RTTaumenta de acordo com aumento do tamanho do ring buffer. Durante os experimentos,observamos também um RTT negligenciável para tamanhos de ring buffer pequenos. Noentanto, o valor do RTT cresce a cada vez que o tamanho do ring buffer é incrementado,com o RTT ultrapassando 10 segundos em um ring buffer com mais de 4.000 pacotes.

As Figuras 3(b) e 3(c) mostram, respectivamente, que o descarte de pacotes eretransmissões também são impactados pelo aumento no tamanho do ring buffer. De fato,observamos um aumento no número de retransmissões enquanto o número de descartes noroteador da rede diminui após um ring buffer de 80 pacotes. Isso ocorre, pois os roteadoresparam de descartar pacotes por falta de espaço, enquanto o algoritmo de retransmissãorápida do TCP inicia equivocadamente a retransmissão de pacotes que ainda estão presosna fila de gargalo.

Os resultados experimentais mostrados nesta seção corroboram o con-junto de resultados discutidos em [Gettys e Nichols, 2012, Nichols e Jacobson, 2012,Jiang et al., 2012a, Chirichella e Rossi, 2013]. No entanto, os resultados descritos até omomento consideram a variação de apenas um parâmetro (tamanho do ring buffer) en-volvido no fluxo de pacotes sobre uma pilha de protocolos de rede em equipamentosbaseados em Unix (Figura 2). É interessante observar o que acontece no caso onde man-temos o tamanho padrão do ring buffer e variamos o tamanho do qdisc. Considerandoessa nova perspectiva, o comportamento do sistema muda e alguns resultados interessan-tes aparecem, conforme discutiremos na Seção 4.2.

4.2. Experimentos variando o tamanho do qdiscPara o conjunto de experimentos descritos a seguir, o valor do ring buffer foi mantidoem seu valor padrão (512 pacotes definido pelo driver da placa de rede) e o tamanho doqdisc foi variado. A Figura 4(a) mostra que com o aumento do tamanho do qdisc, o RTTse mantém razoavelmente estável. E em contraste com os resultados na Seção 4.1, nãoocorre bufferbloat, com o RTT sendo uma ordem de magnitude menor. As Figuras 4(b)e 4(c) mostram, respectivamente, que o número de pacotes descartados e retransmitidosaumentam até uma fila qdisc de 512 pacotes. Após esse ponto, ambos os valores de des-cartes e retransmissões caem para valores negligenciáveis. Esse comportamento ocorredado que o qdisc absorve o tráfego na taxa em que o mesmo é gerado e enviado ao testbed.

4.3. Experimentos variando os tamanhos do ring buffer e do qdiscA Figura 5 mostra o impacto no valor do RTT com a variação conjunta do tamanho doring buffer e do qdisc. Conforme mostrado na Figura 4, filas maiores que 4K pacotes sãocapazes de absorver todo o tráfego gerado. Os resultados da Figura 5 são, em realidade,muito similares aos resultados apresentados na Figura 4. Como mostrado previamente,a variação do tamanho do qdisc apresenta um impacto negligenciável no RTT. Em con-traste, a variação do tamanho do ring buffer leva a um alto RTT e, consequentemente, àocorrência do fenômeno bufferbloat.


125

0 2000 4000 6000 8000

10000 12000 14000

80 256512

10242048

4096

RT

T M

édio

(m

s)

Tamanho do ring buffer (pacotes)

(a) RTT médio x tamanho do ring buffer.

0 30000 60000 90000

120000 150000 180000

80 256512

10242048

4096

Núm

ero

de p

acote

sdescart

ados


(b) Média de pacotes descartados x tamanho do ring buffer.

0 15000 30000 45000 60000 75000 90000

80 256512

10242048

4096

Núm

ero

de

retr

ansm

issões


(c) Média de retransmissões x tamanho do ring buffer.

Figura 3. Impacto do tamanho do ring buffer nas métricas de rede.

Também avaliamos o impacto da variação dos tamanhos das filas ring buffer eqdisc na vazão do sistema. A Figura 6 mostra que a vazão média tende a ser razoavelmenteestável com o aumento do tamanho do ring buffer. Por exemplo, considerando a faixade tamanhos de fila associados ao qdisc (0, 80, 28, 29, 210, 211, 212), a diferença entre avazão alcançada pelo menor tamanho de ring buffer (80 pacotes) e a alcançada pelo maiortamanho de ring buffer (4096 pacotes) é de menos de 20%. De forma semelhante ao RTT,a variação no tamanho do qdisc não afeta significativamente a vazão dos fluxos TCP.

Em resumo, nossos resultados experimentais mostram claramente que variar o ta-manho de ambas as filas, ring buffer e qdisc, causa efeitos independentes no desempenhodo sistema.

4.4. Verificação da janela de recepção anunciada pelo TCP

Para garantir que a capacidade de armazenamento no buffer de recepção do nó receptornão fosse um fator limitante durante as transferências, foi observado a evolução do tama-nho da janela de recepção anunciada durante a sequência de transmissão do TCP. Comopode ser verificado na Figura 7, com o aumento do número de sequência de transmissão,


126

0 300 600 900

1200 1500 1800 2100

0 80 256512

10242048

4096

RT

T M

édio

(m

s)

Tamanho do qdisc (pacotes)

(a) RTT médio x tamanho do qdisc.

0

30000

60000

90000

120000

150000

0 80 256512

10242048

4096

Núm

ero

de p

acote

sdescart

ados


(b) Média de pacotes descartados x tamanho do qdisc.

0

20000

40000

60000

80000

0 80 256512

10242048

4096

Núm

ero

de

retr

ansm

issões


(c) Média de retransmissões x tamanho do qdisc.

Figura 4. Impacto do tamanho do qdisc nas métricas de rede.

a janela anunciada aumenta até atingir um valor máximo de 4 MB.

Esse aumento, efetuado pelo recurso window scaling6 do TCP, eleva conside-ravelmente a capacidade de armazenamento de pacotes no receptor, permitindo que ostransmissores mantenham uma alta vazão durante o experimento. Assim, durante os ex-perimentos, podemos supor que as transmissões TCP não são limitadas pela janela derecepção anunciada.

4.5. Impacto da funcionalidade Byte Queue Limits (BQL)

A partir do kernel Linux 3.3, uma nova funcionalidade chamada Byte Queue Limits(BQL) foi introduzida. O BQL é um algoritmo auto-configurável que tenta estimar quan-tos bytes a interface de rede é capaz de transmitir. Através deste mecanismo, a quantidadede pacotes enviada ao ring buffer é reduzida, deslocando o enfileiramento para as camadasacima da camada de enlace. Assim, o enfileiramento pode ser tratado com a utilização de

6O window scaling é uma opção disponível em implementações mais recentes do TCP que possibilitaque a janela anunciada pelo receptor exceda o limite padrão de 65,535 bytes.


127

0

2000

4000

6000

8000

10000

12000

14000

0 80 256512

10242048

4096

RT

T m

édio

(m

s)


Tamanho doRing Buffer(pacotes)

80

256

512

1024

2048

4096

Figura 5. Impacto dos tamanhos de buffer (ring buffer e qdisc) no RTT.

0

20

40

60

80

100

0 80 256512

10242048

4096

Vazão (

kbps)


Tamanho doRing Buffer(pacotes)

80

256

512

1024

2048

4096

Figura 6. Impacto dos tamanhos de fila na vazão.

disciplinas de fila eficientes implementadas no qdisc, permitindo um gerenciamento defila mais sofisticado e possibilitando a redução da latência.

A seguir descrevemos os experimentos realizados que visam avaliar o impacto dautilização BQL em um roteador suscetível ao fenômeno bufferbloat. Esses experimentossão realizados no mesmo ambiente descrito na Seção 3.1, utilizando o kernel Linux 3.2(sem BLQ) e o kernel Linux 3.11 (com BQL). Para analisar o impacto do BQL no qdisc,definimos que o qdisc e o ring buffer formarão juntos uma fila “virtual” com tamanhototal de 5.000 pacotes. O tamanho do ring buffer será reduzido ao mesmo tempo em queo tamanho do qdisc será incrementado do mesmo montante, mantendo o tamanho totalda fila “virtual” inalterado. Por exemplo, com um ring buffer de tamanho igual a 4096pacotes, o qdisc terá tamanho igual a 904 pacotes. Dessa forma podemos observar comoo tamanho das duas filas influencia na dinâmica entre as mesmas.

As Figuras 8 e 9 mostram que o BQL reduz drasticamente os efeitos do bufferbloatnos casos onde o tamanho do ring buffer é configurado com valores muito elevados. A uti-lização do BQL reduz o RTT em até duas ordens de magnitude. Por exemplo, na Figura 8,um ring buffer de tamanho 2048 pacotes e um qdisc de 2952 pacotes, tem o percentil 95%do RTT de 13 s. Enquanto na Figura 9 a mesma configuração de filas com BQL tem o


128

0

1

2

3

4

5

0 50000 100000 150000 200000

Ta

ma

nh

o d

a ja

ne

laa

nu

ncia

da

(M

B)

Sequência

Janela de recepção

Janela anunciada

Figura 7. Tamanho da janela de recepção anunciada pelo TCP.

0

0.2

0.4

0.6

0.8

1

0 5000 10000 15000 20000

P(R

TT

≤ h

)

RTT h (ms)

Tamanho doRing Buffer/qdisc(pacotes)

80 4920

128 4872

256 4744

512 4488

1024 3976

2048 2952

4096 904

Figura 8. Distribuição acumulada do RTT em um roteador sem BQL.

percentil 95% do RTT de 106 ms. No entanto, como o congestionamento é deslocado doring buffer para o qdisc com o BQL, podemos verificar uma diferença expressiva de 20 msentre o RTT no 95-percentil do qdisc com tamanho pequeno (904 pacotes) e do qdisc comtamanho grande (4920 pacotes). Nos casos em que o tamanho do qdisc é determinante noaumento da latência, disciplinas de fila como o CoDel7 [Nichols e Jacobson, 2012] po-dem ser utilizadas, solucionando o problema do bufferbloat induzido pela utilização doBQL.

5. Discussão sobre soluções existentesExistem algumas propostas recentes na literatura para reduzir o impacto do fenômeno buf-ferbloat. Tipicamente, tais soluções são implementadas na camada de transporte ouna camada de rede. Considerando a camada de transporte, podemos citar os con-troles de congestionamento que se baseiam em atraso, tais como protocolos de Con-

7O CoDel é um algoritmo recente de gerenciamento ativo de fila (AQM) motivado pelo bufferbloat.


129

0

0.2

0.4

0.6

0.8

1

40 50 60 70 80 90 100 110 120 130

P(R

TT

≤ h

)

RTT h (ms)

Tamanho doRing Buffer/qdisc(pacotes)

80 4920

128 4872

256 4744

512 4488

1024 3976

2048 2952

4096 904

Figura 9. Distribuição acumulada do RTT em um roteador com BQL.

trole de Congestionamento de Baixa Prioridade (LPCC) [Chirichella e Rossi, 2013].Na camada de rede, podemos citar os algoritmos de Gerenciamento Ativo de Fila(AQM) [Nichols e Jacobson, 2012]. A seguir descreveremos brevemente estas diferen-tes propostas.

Soluções na camada de transporte mantém o núcleo da rede inalterado. A ado-ção dessas soluções ficam limitadas apenas pela atualização dos sistemas finais, comosistemas operacionais ou firmware de roteadores domésticos. Um dos LPCCs mais popu-lares é o Low Extra Delay Background Transport (LEDBAT), que é um protocolo alter-nativo ao TCP criado originalmente para as redes Peer-to-Peer Bittorrent e apresentadoem [Chirichella e Rossi, 2013]. Os autores em [Chirichella e Rossi, 2013] mostraram queo LEDBAT impede o aumento da latência causado por enfileiramento para a maioria dosusuários de Bittorrent. Um problema recorrente encontrado nos controles de conges-tionamento orientados a atraso, como o LEDBAT ou mesmo o tradicional TCP Vegas[Brakmo et al., 1994], é o tratamento não justo de fluxos concorrentes. Isso resulta emuma distribuição irregular da banda disponível entre as aplicações, reduzindo, consequen-temente, a qualidade de experiência do usuário.

Os algoritmos de gerenciamento ativo de fila, como o Random Early De-tection (RED) [Floyd e Jacobson, 1993] e suas variantes, precisam ser implementa-dos nos roteadores e são difíceis de serem configurados e adaptados para as cons-tantes mudanças na rede [Gettys e Nichols, 2012]. Para combater o bufferbloat,[Nichols e Jacobson, 2012] propuseram o algoritmo de gerenciamento de fila CoDel emresposta direta a [Gettys e Nichols, 2012]. Esse algoritmo essencialmente busca detectaruma fila “ruim”, que é uma fila que cresce de forma nociva sem demonstrar sinais deesvaziamento. Frente a uma fila “ruim”, o algoritmo intencionalmente inicia uma fase dedescarte de pacotes para induzir a ativação do controle de congestionamento do TCP. Agrande vantagem do CoDel face aos demais algoritmos baseados em AQM anteriores é ofato do CoDel ser auto-configurável.

A coexistência entre soluções baseadas em AQMs e LPCCs foi alvo do estudo


130

recente realizado por [Gong et al., 2014]. Idealmente, as duas abordagens deveriam coe-xistir de forma transparente e isolada. Entretanto, em [Gong et al., 2014] foi evidenciadoque a coexistência das soluções pode causar um problema chamado de “repriorização”.O problema de “repriorização” ocorre pois as filas com AQM tendem a limitar o uso ex-cessivo da banda para proteger os novos fluxos e os fluxos de curta duração. Os LPCCs,em contrapartida, procuram utilizar a capacidade disponível sem interferir nos outros flu-xos, tendo uma prioridade reduzida. Consequentemente, os LPCCs sobre a influência dosAQMs tem sua baixa prioridade ignorada e os fluxos se tornam tão agressivos quanto osfluxos TCP originais, reduzindo a vantagem no uso de LPCCs para evitar a sobrecarga darede.

6. Conclusão e visão geralNeste artigo, apresentamos uma avaliação sistemática do fenômeno bufferbloat consi-derando uma visão microscópica do interior de uma arquitetura de dispositivos de redetípicos. No geral, nós podemos destacar três resultados de nossos experimentos: (i) tama-nhos menores do ring buffer permitem que o sistema operacional sinalize corretamente apresença de filas “ruins” (i.e., um fila persistentemente cheia) e, como consequência, oscontroles internos do TCP continuam operando corretamente; (ii) valores maiores parao tamanho do qdisc permitem que o sistema absorva rajadas de tráfego (e.g., uma fila“boa”), ainda minimizando o descarte de pacotes e retransmissões; e (iii) finalmente, ofenômeno bufferbloat só é percebido quando o tamanho padrão do ring buffer (ou o equi-valente em outras arquiteturas) é inadvertidamente modificado. De fato, limitar o tamanhodo ring buffer foi sugerido anteriormente como uma possível forma de mitigar os efeitosdo fenômeno bufferbloat [Corbet, 2011]. Também foi analisado o impacto que o meca-nismo BQL, presente em versões recentes do Kernel do Linux, tem em um roteador comum tamanho de ring buffer elevado. O algoritmo BQL remove o problema do bufferbloatassociado ao dimensionamento inadvertido do tamanho do ring buffer. Em nossos ex-perimentos, a latência em um sistema com BQL foi reduzida em 2 ordens de magnitudequando comparada a um sistema semelhante sem o BQL ativo.

Resumidamente, apesar de haver uma recente polêmica a respeito do fenô-meno bufferbloat, nossos resultados experimentais indicam que o bufferbloat possivel-mente só aconteça em configurações de filas na rede muito específicas e incomuns.

Como mostramos que o bufferbloat pode não ser a explicação mais plausível parao recente aumento de latência fim-a-fim observado na Internet, começamos a consideraroutras questões que podem potencialmente incrementar atrasos na rede. Estamos consi-derando possibilidades como o aumento da adoção de hardware emulado por software evirtualização da rede. Investigar tais questões e seus efeitos particulares no atraso fim-a-fim observado na rede é o alvo de nosso trabalho futuro.

AgradecimentosEste trabalho é parcialmente financiado pelas agências de fomento CNPq, FAPERJ e FA-PEMIG bem como pelo Ministério da Ciência, Tecnologia e Inovação (MCTI).

ReferênciasAllman, M. (2013). Comments on Bufferbloat. ACM SIGCOMM Computer Communica-

tion Review, 43(1):31–37.


131

Appenzeller, G., Keslassy, I., e McKeown, N. (2004). Sizing router buffers. In Procee-dings of ACM SIGCOMM, pages 281–292.

Brakmo, L. S., O’Malley, S. W., e Peterson, L. L. (1994). TCP Vegas: New techniquesfor congestion detection and avoidance. In Proceedings of ACM SIGCOMM.

Chirichella, C. e Rossi, D. (2013). To the Moon and back: are Internet bufferbloat delaysreally that large? In IEEE INFOCOM Workshop on Traffic Measurement and Analysis,pages 14–19.

Corbet, J. (2011). Linux Plumbers Conference: An Update on Bufferbloat. http://lwn.net/Articles/458625/.

Floyd, S. e Jacobson, V. (1993). Random early detection gateways for congestion avoi-dance. IEEE/ACM Transactions on Networking, 1(4):397–413.

Gettys, J. e Nichols, K. (2012). Bufferbloat: Dark Buffers in the Internet. Communicati-ons of the ACM, 55(1):57–65.

Gong, Y., Rossi, D., Testa, C., Valenti, S., e Täht, M. (2014). Fighting the bufferbloat: onthe coexistence of AQM and low priority congestion control. Computer Networks.

Hohlfeld, O., Pujol, E., Ciucu, F., Feldmann, A., e Barford, P. (2012). BufferBloat:How Relevant? A QoE Perspective on Buffer Sizing. Technical report, TechnischeUniversität Berlin.

Jacobson, V. (1988). Congestion avoidance and control. ACM SIGCOMM ComputerCommunication Review, 18(4):314–329.

Jiang, H., Liu, Z., Wang, Y., Lee, K., e Rhee, I. (2012a). Understanding Bufferbloat inCellular Networks. In Proceedings of the 2012 ACM SIGCOMM Workshop on CellularNetworks: Operations, Challenges, and Future Design, pages 1–6.

Jiang, H., Wang, Y., Lee, K., e Rhee, I. (2012b). Tackling Bufferbloat in 3G/4G Networks.In Proceedings of the 2012 ACM Conference on Internet Measurement Conference,pages 329–342.

Lee, D., Cho, K., Iannaccone, G., e Moon, S. (2010). Has Internet Delay gotten Better orWorse? In Proc. of the 5th International Conference on Future Internet Technologies(CFI), Seoul, Korea.

Nagle, J. (1985). On Packet Switches With Infinite Storage. RFC 970.

Nichols, K. e Jacobson, V. (2012). Controlling Queue Delay. Communications of theACM, 55(7):42–50.

Wehrle, K., Pahlke, F., Ritter, H., Muller, D., e Bechler, M. (2004). Linux NetworkingArchitecture. Prentice Hall.


132

Distribuição de Vídeo sob Demanda Baseada emRedes de Distribuição de Conteúdo utilizando

Redes Orientadas a Conteúdo ∗

Felipe B. Ramos, Igor D. Alvarenga, Pedro M. Caldas, Otto Carlos M. B. Duarte

1Grupo de Teleinformática e Automação (GTA)Universidade Federal do Rio de Janeiro (UFRJ)

{brasilramos,alvarenga,pedro,otto}@gta.ufrj.br

Abstract. The Content Distribution Networks were created for efficient contentdelivery. The recent increase in content demand aggravates the managementand performance issues faced by these networks, based on the end-to-end com-munication model. This paper evaluates the performance of a prototype that de-livers video on demand using a Content Oriented Network. In Content OrientedNetworks, efficient content delivery becomes a network task and main objective.The performance of the implemented prototype was compared with the TCP/IPprotocol stack. The results show that the proposed prototype delivers content ef-ficiently and decreases network overhead by 83%, while maintaining the qualityof service perceived by the end consumer. Furthermore, mobility experimentsperformed verify that the prototype supports mobility of clients, which also al-lows the reduction of the bandwidth on the physical network while avoidingvideo stream interruption during network transition.

Resumo. As Redes de Distribuição de Conteúdo foram concebidas para en-tregar conteúdo de forma eficiente. No entanto, o aumento da demanda porconteúdo agrava os problemas de gerenciamento e desempenho dessas redes,que se baseiam no modelo convencional de comunicação fim-a-fim da Internet.Este artigo descreve e avalia o desempenho de um protótipo de entrega vídeosob demanda utilizando uma Rede Orientada a Conteúdo. Em Redes Orienta-das a Conteúdo, a entrega eficiente de conteúdo passa a ser uma tarefa da rede,bem como seu principal objetivo. A proposta foi implementada e comparadacom a pilha de protocolos TCP/IP. Os resultados comprovam que o protótipoproposto apresenta maior eficiência na entrega de conteúdo, promovendo redu-ção de 83% na sobrecarga da rede, enquanto mantém a qualidade de serviçopercebida pelo consumidor final. Além disso, foram realizados experimentos demobilidade que comprovam que o protótipo suporta mobilidade de consumido-res de conteúdo, de modo a reduzir o uso de banda total na rede física e evitara interrupção do fluxo de vídeo durante a transição de redes.

1. Introdução

A Internet atual é baseada no modelo de comunicação fim-a-fim, adequado ao acessoa recursos remotos, ideia sob a qual foi concebida a Internet. No entanto, o padrão de

∗Este trabalho foi realizado com recursos da FINEP, FUNTTEL, CNPq, CAPES, FAPERJ e UOL.


133

uso da Internet não é mais caracterizado por compartilhamento de recursos. A demandaatual é caracterizada por acesso a serviços online e busca, produção e distribuição deconteúdo [Schulze and Mochalski 2009]. Os usuários buscam cada vez mais acesso aconteúdo de forma rápida e com qualidade, sem se importar com a origem do mesmo. Apilha TCP/IP não possui mecanismos naturais capazes de garantir qualidade de serviçona entrega de conteúdo através da Internet. Por essa razão, novas alternativas para entregaeficiente de conteúdo como as Redes de Distribuição de Conteúdo (Content DistributionNetworks - CDNs) e as redes peer to peer (P2P) foram criadas. As CDNs e as redes P2P,no entanto, apresentam uma série de problemas de gerenciamento e desempenho.

As CDNs disponibilizam servidores próximos aos consumidores com réplicas dosconteúdos a serem distribuídos, a fim de reduzir a latência de entrega. Contudo, esco-lha da localização dos servidores, o redirecionamento de clientes para os servidores deréplicas e a distribuição eficiente de cópias de conteúdo entre servidores são problemascomplexos. Os sistemas P2P criam redes ad hoc de usuários que compartilham fragmen-tos de conteúdo. Devido à natureza mutável da solução, a disponibilidade dos conteúdosnão é garantida. Além disso, sistemas P2P dependem da instalação de aplicações peloconsumidor final e sobrecarregam a rede com mensagens de controle e a abertura de múl-tiplas conexões. Nesse contexto, surge a ideia de Redes Orientadas a Conteúdo. NasRedes Orientadas a Conteúdo, o conteúdo é o elemento fundamental, e a entrega eficientede conteúdo passa a ser uma tarefa de rede.

Este artigo propõe distribuir vídeo sob demanda utilizando Redes Orientadas aConteúdo (Content Centric Networking - CCN) [Jacobson et al. 2009, Zhang et al. 2010].A CCN é uma rede orientada a conteúdo que se baseia no uso de dados nomeados e ca-che distribuído para obter ganhos de desempenho. A proposta prevê a implementação deuma rede CCN sobreposta à rede dos Provedores de Serviços de Internet (Internet ServiceProviders - ISPs). A rede CCN trabalha em cooperação com as CDNs. Os conteúdos devídeo disponibilizados pelas CDNs nas interfaces entre as redes dos ISPs e o núcleo daInternet são redistribuídos pela rede CCN até as bordas das redes dos ISPs para o consu-midor final, onde pontos de conversão CCN/IP permitem obter o conteúdo demandado viaIP. A existência dos pontos de conversão permite que o sistema seja transparente para osconsumidores, não exigindo instalação de nenhuma aplicação além de um reprodutor devídeo convencional. O protótipo da proposta foi implementado e avaliado em uma redeno FITS (Future Internet Testbed with Security) 1, uma plataforma de testes para pro-postas de Internet do Futuro desenvolvida pelo Grupo de Teleinformática e Automação(GTA) [Moraes et al. 2014]. Os resultados mostram que a utilização da rede orientada aconteúdo reduz a carga na rede dos ISPs devido à capacidade da CCN de agregar fluxosde dados, ao mesmo tempo que mantém a taxa de entrega de conteúdo aos clientes. Os re-sultados comprovam que o esquema proposto suporta mobilidade de clientes, o que podeser utilizado para promover redução adicional do tráfego na rede física e para melhorar aqualidade de serviço de distribuição de vídeo ao se disponibilizar o conteúdo a partir depontos de conversão próximos aos consumidores.

A distribuição de vídeo sob demanda (Video on Demand - VoD) vai ao encontrodas novas tendências de uso da Internet. O serviço Netflix, que disponibiliza conteúdo devídeo sob demanda é responsável por 30% do tráfego de rede na América do Norte durante

1http://www.gta.ufrj.br/fits


134

o horário de pico [Frank et al. 2013]. Além disso, as atividades de distribuição contínuade vídeo consomem banda intensamente e a agregação de Dados e Interesses realizadapela CCN proporciona economia do uso de banda. Na distribuição de VoD, esse impactoé potencializado, como mostrado por Fricker et al. [Fricker et al. 2012], que fazem umaanálise do custo-benefício do uso de memória a fim de se obter economia de banda emredes CCN. Segundo o estudo, a quantidade de cache necessária se obter economias debanda consideráveis na distribuição de vídeo sob demanda é várias vezes menor que aquantidade necessária para se obter o mesmo efeito com outros tipos de tráfego, comocompartilhando arquivos acessando sites na web.

A questão da colaboração entre ISPs e CDNs é abordada por Frank et al., que pro-põem o protocolo de comunicação NetPaas [Frank et al. 2013]. A proposta foca apenasna questão da comunicação entre ISPs e CDNs, mas não aborda questões importantes,como a redução dos volumes de tráfego nas redes dos ISPs ou o gerenciamento das requi-sições por conteúdo e alocação de réplicas nas CDNs. Em nCDN [Jiang and Bi 2012],mostra-se através de simulações que o uso de dados nomeados aumenta o desempe-nho da distribuição de réplicas de conteúdo nas CDNs e estudos sobre cache coopera-tivo de conteúdo de vídeo em CCN mostram uma significativa redução de tráfego interISPs [Li and Simon 2011]. Essas propostas tem como foco a questão do aumento de efi-ciência das CDNs ou estratégias de cacheamento para redução de tráfego inter ISPs, epodem ser consideradas complementares à proposta desse artigo, visto que não abordama questão da entrega de conteúdo ao consumidor final ou a relação entre CDNs e ISPs.

O restante do artigo está organizado da seguinte forma. Os trabalhos relacionadosà proposta de distribuição de conteúdo utilizando redes orientadas a conteúdo são apresen-tados mais detalhadamente na Seção 2. As Seções 3 e 4 apresentam as CDNs e as CCNs,enquanto que a proposta de distribuição utilizando a rede CCN é apresentada na Seção 5.O cenário de testes e os resultados das avaliações de desempenho serão apresentados nasSeções 6 e 7, respectivamente. Finalmente, a Seção 8 conclui o artigo.

2. Trabalhos RelacionadosJiang e Bi propõem a utilização de dados nomeados em redes de distribuição de conteúdo,criando uma rede de distribuição de conteúdo nomeado (nCDN) [Jiang and Bi 2012]. Aintrodução da orientação a conteúdo nas CDNs permite utilizar múltiplas fontes e múl-tiplos destinos e facilita o gerenciamento da distribuição de conteúdo, o que melhora odesempenho das CDNs. Para avaliar o desempenho da proposta nCDN, foi feita uma sériede simulações utilizando ndnSIM, um simulador de NDN baseado no NS-3 [NS-3 2014].Os resultados mostram que o uso de CCNs em CDNs melhora consideravelmente suaeficiência em diversos aspectos, como rendimento máximo em situação de sobrecarga, la-tência, recuperação de falhas de nós ou queda de enlaces (links), entre outros. O trabalho,no entanto, privilegia a questão da eficiência da distribuição de conteúdo nas CDNs e nãotrata o problema de sobrecarga da rede dos ISPs ou a questão do acesso dos clientes aosconteúdos nomeados. A distribuição de conteúdo nas redes dos ISPs utilizando CCN é,portanto, complementar à proposta nCDN, uma vez que distribui o conteúdo nomeado danCDN, promove redução do tráfego interno à rede dos ISPs e entrega conteúdo de vídeoaos clientes de forma transparente. Além disso, a proposta nCDN foi avaliada apenas me-diante simulações e os autores deixaram a implementação de um protótipo como trabalhofuturo. Este artigo preenche esta lacuna ao avaliar o desempenho do sistema proposto


135

a partir de dados reais coletados de uma rede experimental implementada especialmentepara esse fim.

Frank et al. realizam um estudo sobre a colaboração entre ISPs eCDNs [Frank et al. 2013]. Frank et al. defendem que muitas vezes a eficiência da dis-tribuição de conteúdo é prejudicada porque o sistema de distribuição de conteúdo se valede informações equivocadas sobre a localização dos consumidores ou informações defi-cientes sobre o estado da rede. O protocolo NetPaaS (Network Platform as a Service) éproposto como uma solução capaz de facilitar essa colaboração entre ISPs e CDNs ao per-mitir uma comunicação efetiva entre ambos os agentes. O NetPaaS permite que as CDNspeçam aos ISPs indicações dos melhores servidores para encaminhar os consumidores etambém permite aos ISPs informar sobre recursos disponíveis que possam ser oferecidosàs CDNs para expansão da rede de distribuição. Os resultados obtidos indicam que o Net-PaaS possibilita uma redução do consumo de banda e do atraso na recepção de conteúdo.Contudo, o NetPaas não tange o que diz respeito à distribuição do conteúdo disponibili-zado. Cabe às CDNs gerenciar esse processo. No esquema de distribuição apresentado, arede orientada a conteúdo gerencia a distribuição de conteúdo, o que, conforme apresen-tado por Jiang e Bi, produz uma distribuição mais eficiente do que numa CDN padrão.O esquema apresentado é, portanto, mais abrangente que o NetPaas, no sentido em nãoapenas resolve o problema de comunicação entre ISPs e CDNs, como também distribui oconteúdo disponibilizado pelas CDNs e permite acesso dos clientes aos conteúdos atravésdos pontos de conversão CCN/IP situados nas bordas das redes dos ISPs.

A questão da distribuição de conteúdo dentro de uma rede orientada a conteúdoa fim de reduzir o tráfego inter ISPs é abordada por Li e Simon [Li and Simon 2011]. Oartigo propõe uma estratégia de cache cooperativo projetada para o tratamento de vídeoslongos oferecidos sob demanda. O artigo defende que a política utilizada nas CCNs, emque cada roteador armazena todo o conteúdo que encaminha é ineficiente. Na proposta,cada roteador CCN é identificado por um inteiro menor que um determinado valor k.Os roteadores encaminham pacotes normalmente, mas armazenam apenas pedaços deconteúdo cujo módulo k corresponde a seu identificador. Os autores mostram através deuma série de simulações que a proposta pode reduzir em até 60% o tráfego inter ISPs semcomprometer a eficiência da CCN na distribuição de conteúdo. Embora também trate daquestão da distribuição de vídeo, o trabalho de Li e Simon se foca na redução de tráfegointer ISP e negligencia a questão da entrega de conteúdo aos consumidores finais que nãopossuem aplicações compatíveis com a pilha CCN. Por esse motivo, a proposta de cachecooperativo apresentada poderia complementar à proposta apresentada nesse artigo, cujoobjetivo é entregar conteúdo de vídeo de forma transparente para o consumidor final.

Zhu et al. apresentam uma nova perspectiva para soluções de mobilidade atravésdo uso de redes orientadas a conteúdo [Zhu et al. 2013]. Nenhuma das atuais propostasde mobilidade IP foi amplamente aplicada, entre os motivos podem ser citados a inflexibi-lidade do modelo de comunicação e medidas fracas de segurança diante de um ambientedinâmico. Nesse cenário, a segurança está dependente de ambos os extremos da comu-nicação, o que se torna extremamente frágil quando essas extremidades se movimentam.A rede orientada a conteúdo traz novas possibilidades ao desatrelar o conteúdo da loca-lização. São utilizados dados nomeados ao invés de endereços de destino para entregade informações. Esse novo modelo de comunicação se mostra adequado à mobilidade,


136

uma vez que a mudança no posicionamento de um elemento de rede não será mais tãosignificante. Na rede orientada a conteúdo, todo nó da rede pode vir a fornecer conteúdo.Nosso protótipo implementa o modelo de conectividade móvel proposto por Zhu et al.,utilizando a rede orientada a conteúdo para a entrega de vídeo sob demanda.

3. Redes de Distribuição de ConteúdoA arquitetura atual da Internet tem dificuldades em acompanhar a sua rápida populariza-ção [Jacobson et al. 2009]. Essa situação vem se agravando com a mudança no padrãodos usuários, que passaram a ser também produtores de conteúdo, e a disseminação douso de serviços vorazes em termos de consumo de banda, como o caso da distribuiçãocontínua de vídeos.

As CDNs buscam disponibilizar os recursos necessários para garantia de quali-dade de serviço (Quality of Service - QoS) continuamente, independentemente de flutu-ações da demanda. Normalmente, a escalabilidade das soluções adotadas nas CDNs égarantida pela distribuição de servidores próximos aos consumidores contendo réplicasdos conteúdos a serem distribuídos [Saroiu et al. 2002]. Essa solução, no entanto, recaiem problemas complexos de posicionamento de servidores, replicação de conteúdos egerenciamento das requisições dos clientes.

Os servidores de réplicas devem ser posicionados tão próximos dos consumidoresfinais quanto possível, de modo a minimizar a latência e o uso de banda. No entanto, o nú-mero de servidores a serem distribuídos é restrito, a distribuição geográfica dos usuáriosé irregular e o servidor de origem tem um posicionamento fixo. É preciso decidir quantasréplicas de determinado conteúdo devem existir e em quais servidores serão hospedadas.Além disso, fatores como a carga de cada servidor de réplicas e a carga total na rede de-vem ser levados em consideração. Existem abordagens teóricas para a resolução dessesproblemas, mas elas são extremamente custosas em termos computacionais. Normal-mente essas abordagens implicam na resolução de problemas de otimização NP-difíceis2

e mesmo soluções aproximadas que reduzem o nível de complexidade do problema aindaapresentam custos computacionais elevados [Peng 2004]. No entanto, como a demandapor conteúdos é irregular e mutável, nada garante que o posicionamento dos servidores eréplicas será satisfatório ao longo do tempo, o que incorre em novos custos de instalaçãode servidores.

Uma vez posicionados servidores de réplicas, é necessário encaminhar cada cli-ente ao conteúdo desejado. Ao se utilizar a Internet, baseada no modelo de identificaçãode hospedeiros, para buscar conteúdo, se faz necessário um mapeamento entre “o que sebusca” e “onde buscar”. Desse modo, as CDNs necessitam de uma variedade de aplica-ções inteligentes para administrar a distribuição de cópias de conteúdos e reencaminharas requisições dos clientes baseado em diversos fatores, como carga dos servidores de ré-plicas, localização dos conteúdos e dos consumidores. Normalmente, essas soluções sãocomplexas e incorrem em problemas de sobrecarga, como no caso da multiplexação declientes e roteamento P2P, ou dependem de modificações em estruturas da Internet, comono caso do redirecionamento de DNS ou anycasting3 [Peng 2004].

2Problemas em que não há garantias de que a solução possa ser encontrada dentro de um tempo polino-mial da ordem do problema.

3Um endereço IP anycast identifica um conjunto de receptores. Requisições enviadas para um endereço


137

4. Redes Orientadas a Conteúdo

A Internet foi concebida originalmente como um meio de acesso à recursos remotos atra-vés de um modelo de comunicação fim-a-fim. No entanto a demanda de uso atual écaracterizada por acesso a serviços online e busca, produção e distribuição de conteúdo.À vista disso, a comunicação fim-a-fim deixa de representar o modelo ideal de comunica-ção. Uma das principais propostas de substituto para esse modelo são as redes orientadasa conteúdo. Nas redes orientadas a conteúdo, o foco passa a ser o conteúdo que se deseja,e sua entrega eficiente passa a ser uma tarefa de rede.

Jacobson [Jacobson et al. 2009] e Zhang [Zhang et al. 2010] defendem que, paraa dinâmica de entrega de conteúdo ser eficiente, a nomeação de hospedeiros deve sersubstituída pela nomeação de conteúdo. A identificação única de cada conteúdo atravésde um nome desacopla o conteúdo de sua localização, o que permite buscar diretamenteos dados sem que haja necessidade de se conhecer seus hospedeiros. A rede CCN éuma rede de dados nomeados baseada nessa primitiva. Cada conteúdo possui um nomeformado por prefixos agregáveis, utilizados para facilitar o roteamento de requisições.

A ideia de nomeação de conteúdo não é exclusiva da rede CCN. Outras pro-postas de redes de dados nomeados (Named Data Networking - NDN) foram cri-adas ao longo do tempo, todas apresentando soluções para problemas da Internetatual. Entre elas figuram DONA [Koponen et al. 2007], LIPSIN [Jokela et al. 2009] eTRIAD [Cheriton and Gritter 2000]. Contudo, a CCN é a mais atual delas e despontacomo uma das mais promissoras propostas de Internet do Futuro. Além disso, a CCNpossui uma implementação experimental que roda sobre IP, a CCNx [CCNx 2011], quefoi utilizada na rede de testes implementada neste artigo.

Em uma CCN, todos os nós podem ser considerados roteadores, uma vez que po-dem tanto enviar e encaminhar requisições quanto receber e encaminhar conteúdo. Exis-tem apenas dois tipos de pacotes: Interesse e Dados. Um pacote de Interesse é enviadosempre que um nó deseja acessar determinado conteúdo. Pacotes de Dados só são trans-mitidos em resposta a Interesses. Existe uma paridade entre Interesses e Dados, e a dinâ-mica do fluxo de informações é regida segundo o envio de Interesses por parte dos consu-midores. A rede CCN encaminha os Interesses no sentido dos produtores de conteúdo, oprimeiro nó que possui o conteúdo requisitado responde com os Dados correspondentespelo caminho inverso seguido pelos Interesses.

Os roteadores CCN possuem três estruturas de dados principais: a Base de In-formações de Encaminhamento (Forwarding Information Base - FIB), o Armazém deConteúdo (Content Store - CS) e a Lista de Interesses Pendentes (Pending Interest Table- PIT). O CS armazena temporariamente conteúdo que foi encaminhado pelo roteador,de modo que requisições frequentes de um determinado conteúdo possam ser respondi-das localmente. A FIB da CCN é similar à FIB no IP, armazenando regras baseadas emprefixos de nomes, um mapa das interfaces de saída correspondentes e outras regras maisespecíficas relacionadas a prefixos. Contudo, na CCN a FIB pode relacionar diversasinterfaces de saída a um mesmo prefixo, ordenando-as por prioridade. A PIT guarda asinterfaces de entrada e saída pelas quais Interesses ainda não respondidos chegaram e fo-

anycast são respondidas pelo receptor mais próximo. A escolha do receptor está sujeita ao critério deproximidade adotado.


138

ram encaminhados. Interesses referentes a um mesmo dado são agregados e apenas umarequisição é enviada a cada interface de saída. Dessa maneira, apenas um dado é recebidoe reencaminhado a todas as interfaces por onde foram recebidos Interesses.

A possibilidade de resposta local de requisições, propiciada pelo armazenamentode conteúdo em cada roteador, e a agregação de fluxos acarretada pelo envio de ape-nas um Interesse por interface de saída possibilitam reduzir substancialmente o trá-fego de rede. Além disso, a natureza dos nomes CCN permite o sequenciamento ló-gico dos pedaços de conteúdo e uma independência entre envio de Interesses e Da-dos. Essas características aliadas aos mecanismos de balanceamento de carga, controlede fluxo ponto-a-ponto e de verificação de recebimento de dados inerentes à arquite-tura [Jacobson et al. 2009, Guimaraes et al. 2013], tornam a CCN ideal para aplicaçõescomo transmissão contínua (streaming) de vídeo.

5. Arquitetura da solução propostaEste artigo propõe a implementação de uma rede CCN superposta à rede IP dos prove-dores de serviço de Internet para a distribuição conteúdo. Na solução proposta, a CCNtrabalha em cooperação com as CDNs para distribuir VoD. A arquitetura da solução éilustrada na Figura 1.

Figura 1. Rede de distribuição CCN sobreposta à rede IP. A rede de distribuiçãotrabalha cooperativamente com as CDNs, distribuindo conteúdo através da rededos ISPs.

A distribuição do conteúdo na solução proposta é gerenciada pela própria dinâ-mica da rede CCN: os conteúdos são enviados sob demanda e cópias dos pacotes dedados são armazenadas nos roteadores que os encaminham. A rede CCN distribui osconteúdos até pontos de conversão existentes nas bordas da rede dos ISPs, aos quais osconsumidores se conectam via IP a fim de acessar os conteúdos disponibilizados. Essaconfiguração permite utilizar todas as vantagens da CCN frente ao IP no que diz respeito


139

à distribuição de conteúdo, ao mesmo tempo em que a distribuição é transparente para oconsumidor final.

Os pontos de conversão situados nas bordas da rede são roteadores capazes de tra-duzir requisições de conteúdo via IP em requisições de conteúdo via CCN. Eles recons-troem o conteúdo a partir dos pedaços de conteúdo nomeado recebidos e o disponibilizamaos clientes via IP, utilizando quaisquer métodos comumente utilizados para distribuiçãode vídeo, tais como HTTP, RTSP, UDP ou TCP. Esses pontos de conversão concentramtodos os pedidos dos consumidores e geram os pedidos de Interesse pelos conteúdos bus-cados. Os roteadores agregam esses Interesses antes de enviá-los, o que reduz a carga nonúcleo da rede dos ISPs. Adicionalmente, a agregação de fluxos de Interesses e Dadosisola o núcleo da rede das flutuações na demanda percebidas em suas bordas, pois dispo-sitivos podem se conectar aos pontos de conversão até que sua capacidade de conexão seesgote, sem que fluxos duplicados sejam repassados para o núcleo da rede. No entanto, adistribuição dos conteúdos aos consumidores a partir dos pontos de conversão pressupõe aduplicação de fluxos, pois é feita via IP, em unicast. Por esse motivo, os pontos de conver-são devem ser instalados próximos às bordas da rede a fim de minimizar o número saltosnecessário para se alcançar os consumidores e com isso reduzir o número de enlaces comfluxos duplicados.

Quanto mais roteadores CCN existirem na rede do ISP, maior esse efeito de agre-gação de pacotes e menor o número de pacotes duplicados que circulam pelos roteadoresfuncionando puramente com IP [Guimaraes et al. 2013]. Isso cria um incentivo adicionalpara a expansão da rede CCN implementada e constitui uma grande vantagem quandoconsiderado o crescimento do número de dispositivos móveis, como smartphones e ta-blets verificado nos últimos anos.

A rede CCN também pode ser utilizada para prover conteúdo a consumidoresque possuam suporte à comunicação com CCNs disponível em seus dispositivos pesso-ais. Nesse caso, a eficiência da distribuição aumentará, pois a rede CCN formada pelosroteadores da rede dos ISPs será complementada por uma rede peer to peer formada pe-los dispositivos móveis. A dinâmica da CCN prevê a busca por pedaços de conteúdo nocache de quaisquer dispositivos CCN próximos e suporta mobilidade de consumidores.A rede CCN detecta automaticamente esses recursos adicionais e com isso aumenta suaabrangência e eficiência. Dispositivos que possuem recursos limitados, como smartpho-nes, podem optar por continuar a usar os pontos de conversão e acessar os conteúdosvia conexão IP a fim de economizar recursos como memória e bateria. Ao utilizar umaaplicação IP em vez de uma aplicação CCN para obter conteúdo, os dispositivos ficamisentos de difundir os nomes dos conteúdos que possuem e de enviar pacotes de Dadospara responder a Interesse, o que proporciona economias de bateria [Lee and Kim 2011]devido à redução do tráfego de dados.

Dispositivos que possuam suporte à comunicação com CCNs passam a se benefi-ciar da mobilidade de consumidores inerente à arquitetura CCN. Enquanto que o suportea mobilidade IP não é trivial devido ao forte acoplamento entre identidade e localização,o modelo de comunicação CCN orientado ao receptor oferece suporte a mobilidade deconsumidores de forma direta [Zhu et al. 2013]. Um consumidor pode requisitar dadosdiretamente da rede sem prévia configuração de endereço ou da conexão. Quando umpacote de interesse é transmitido do consumidor ao produtor de conteúdo, é criado sob


140

demanda um caminho reverso temporário entre produtor e consumidor, pelo qual são en-caminhados os pacotes de dados correspondentes. A duração deste caminho reverso épróxima a duração de intervalo de envio e recebimento no IP, de forma que a mudança deponto de acesso implica apenas na criação de outro caminho reverso. No entanto, quandoum dispositivo muda de rede, as insformaçoes na FIB local precisam ser atualizadas, oque, para o caso da mobilidade de consumidores, pode ser resolvido pela retransmissãodos pacotes de interesse [Wang et al. 2013].

6. Cenário de testesOs testes foram realizados no Future Internet Testbed with Security(FITS) [Moraes et al. 2014], uma plataforma de testes interuniversitária para pro-postas de Internet do Futuro. O FITS é mantido pelo Grupo de Teleinformática eAutomação (GTA) da Universidade Federal do Rio de Janeiro (UFRJ), e possui nós emuniversidades de vários estados do Brasil e em países da Europa.

O FITS possibilita um ambiente de teste pluralista de larga escala para a experi-mentação de propostas para Internet do Futuro com condições reais de tráfego da Internet.O FITS permite a criação de múltiplas redes virtuais em paralelo sobre a mesma estru-tura física, de forma segura e isolada. O ambiente é flexível e agnóstico aos sistemasoperacionais, aplicações e protocolos utilizados na rede virtual, minimizando restrições etrazendo maiores possibilidades de experimentação, quando comparado a outras redes deteste mais restritas.

A distribuição de conteúdo via CCN foi testada em uma rede protótipo criadaespecialmente para esse fim. A rede protótipo foi concebida com o objetivo de reproduzirem menor escala a dinâmica de uma rede de distribuição sobreposta à rede de um ISPrepresentada na Figura 1. Os experimentos mantém seu foco na rede CCN sobre a rededo ISP, para tanto o servidor de réplicas na borda da rede de testes já possui a cópia dosconteúdos requisitados e passa a atuar como provedor de conteúdo da rede de testes. AFigura 2 apresenta a arquitetura da rede de testes.

A rede é formada por quatro roteadores, um provedor de conteúdo e nove con-sumidores. Os Roteadores 1, 2 e 3 representam os pontos de conversão e por isso estãoligados diretamente aos clientes. Cada ponto de conversão está ligado a três clientes. ORoteador 0 está ligado ao provedor de conteúdo e possui conexões redundantes, formandouma malha com os Roteadores 1, 2 e 3.

Cada nó da rede CCN é uma máquina virtual hospedada no FITS rodando CCNx.A CCNx [CCNx 2011] é uma implementação da arquitetura CCN que roda sobre IP criadapelo Centro de Pesquisa de Palo Alto (Palo Alto Research Center - PARC), da Xerox, parao desenvolvimento da arquitetura CCN. Os roteadores CCN possuem a CCNx versão 0.8.1instalada. Nos pontos de conversão, além da CCNx, foi instalado o VLC media playerversão 2.0.3 e um plugin que o torna capaz de converter CCNx para IP. Para realizaçãodos testes, os roteadores foram hospedados em diferentes nós físicos do FITS.

7. Resultados e discussãoAs principais vantagens da distribuição de conteúdo utilizando CCN são a redução doconsumo de banda gerado pela distribuição de vídeo, o gerenciamento automático de ré-plicas através do cache e o suporte à mobilidade. Foram realizados testes para se comparar


141

Figura 2. Arquitetura da rede de testes usada: servidor de conteúdo, roteadoresCCN atuando como pontos de conversão e consumidores de conteúdo.

o desempenho de uma distribuição via CCN frente a uma distribuição TCP/IP em ambosos casos.

7.1. Análise de tráfego

(a) Consumo de banda no enlace entre o servidore a rede de distribuição.

(b) Consumo de banda de um dos clientes ligadosao Roteador 3.

Figura 3. O consumo de banda na distribuição via CCN é claramente menornas proximidades do provedor de conteúdo. A taxa de entrega de conteúdo aosclientes, no entanto, é igual na distribuição via CCN e TCP/IP, .

Para se comparar o uso de banda na distribuição de vídeo foi enviado um vídeode aproximadamente 100 MB dentro de uma janela de dois minutos utilizando-se TCP/IPe a rede CCN. Um vídeo longo foi escolhido para que, dentro de uma janela de tempolonga o suficiente para se ter medidas confiáveis, o vídeo não tivesse sido inteiramentebaixado, independente do método utilizado. Essa medida foi escolhida em detrimentoda alternativa de se limitar a banda nos enlaces, de modo que todos os enlaces forammantidos com taxa de transmissão padrão de 1 Gb/s.

Nos testes utilizando CCN, o vídeo foi disponibilizado no servidor como conteúdonomeado. Durante o teste, o vídeo foi distribuído via CCN até os nós de borda e então


142

convertido para formato HTTP em tempo real. Nos testes utilizando TCP/IP, o vídeo foidisponibilizado em HTTP diretamente no servidor. A avaliação de desempenho foi feitamediante comparação do uso de banda total em cada enlace, expressado como uma funçãocumulativa da quantidade de bytes trafegados.

A Figura 3 mostra um comparativo da quantidade de bytes trafegados nas extre-midades do sistema na distribuição via IP e via CCN. A Figura 3(a) apresenta o tráfegonas imediações do servidor de conteúdo, enquanto a Figura 3(b) apresenta o tráfego quechega a um cliente.

Os resultados mostram que o sistema formado pela rede CCN e os pontos de con-versão é capaz de reduzir significativamente o tráfego de rede decorrente da distribuiçãode vídeo, enquanto mantém a taxa de entrega de conteúdo aos clientes. Esse efeito é maissignificativo nas imediações do provedor de conteúdo. Os resultados referentes ao tráfegono núcleo da rede são mostrados na Figura 4. Observa-se que o tráfego total na distri-buição via CCN é 83% menor que o tráfego gerado na distribuição via IP para o cenáriotestado.

Figura 4. Tráfego cumulativo na rede do ISP. A distribuição via CCN reduz consi-deravelmente a carga da rede.

7.2. Análise de mobilidade

Para a comparação do desempenho da CCN e de uma rede TCP/IP em termos de mobi-lidade, foi construída uma rede de testes que possui três roteadores CCN que em escalareduzida representam a rede CCN interna de um ISP, um provedor de conteúdo, doispontos de acesso sem fio e um dispositivo móvel que representa o cliente. O dispositivomóvel com a CCNx versão 0.8.1 instalado foi conectado a um desses pontos de acessoe buscou reproduzir um vídeo recebido via transmissão contínua utilizando distribuiçãovia IP e via CCN. A ligação entre o Roteador 0 e o provedor de conteúdo representa aconexão do ISP com a rede CDN que contém o vídeo sob demanda. Os pontos de accesosem fio estão conectados aos Roteadores 1 e 2 que por sua vez estão conectados a redeCCN interna do ISP. Durante a transmissão, o dispositivo foi trocado de rede e conectadoao outro ponto de acesso. A Figura 5 ilustra o procedimento.

O dispositivo móvel foi mudado de rede algumas vezes durante a transmissão dovídeo. Durante a transmissão via TCP/IP, a conexão foi perdida na primeira mudança e a


143

Figura 5. Estrutura da rede utilizada nos testes de mobilidade. Um cliente móvelse conecta à rede CCN através de pontos de acesso sem fio.

reprodução do vídeo foi terminada. Quando o vídeo foi pedido via CCN, sua reproduçãocontinuou ininterruptamente apesar das mudanças de rede, o que mostra o suporte da redeà mobilidade de clientes. A Figura 6 mostra o comportamento das interfaces de rede dospontos de acesso conectados ao dispositivo móvel durante a transmissão via CCN.

Figura 6. Mobilidade de clientes CCN. O cliente muda da Rede Sem Fio 1 paraRede Sem Fio 2 no instante 15s e retorna à Rede Sem Fio 1 no instante 56s. Aentrega de conteúdo continua, apesar do cliente mudar de rede.

O experimento demonstra que a qualidade de serviço na mobilidade em CCNsprevista por Zhu [Zhu et al. 2013] é garantida. Quando o cliente solicita o vídeo a partirde um ponto de acesso que se conecta ao Roteador CCN 1, o interesse é propagado nóa nó até o provedor de conteúdo e o conteúdo é cacheado no sentindo inverso do pedidode interesse. Dessa forma, enquanto o cliente muda de ponto de acesso, o conteúdo depedidos anteriores vai estar sendo atendido pelo provedor de conteúdo e residirá no cacheda rede CCN interna do ISP. Quando o cliente reenviar os interesses no outro ponto deacesso, agora conectado ao Roteador CCN 2, esses serão atendidos prontamente pelosRoteadores CCN 0 e 1 que já possuem o conteúdo no cache. Logo, não é necessário oreenvio de pacotes de interesses já requisitados ao provedor de conteúdo, o que evita o


144

disperdiço de banda entre a CDN e o ISP.

8. ConclusãoEste artigo analisa a distribuição de conteúdo utilizando uma rede CCN sobreposta àsredes dos ISPs para distribuir conteúdo de vídeo sob demanda. A rede CCN trabalha emcooperação com CDNs, de modo que um provedor de conteúdo, ou seja, um servidor deréplicas de uma CDN, se conecta à rede CCN. A utilização de conteúdo nomeado desa-copla os dados da localização geográfica de seus provedores, o que facilita a distribuiçãode conteúdo e aumenta sua eficiência.

A distribuição de conteúdo através da rede CCN é transparente para os consumi-dores na solução proposta, dado que o acesso aos conteúdos é disponibilizado através depontos de conversão localizados nas extremidades da rede. Quanto mais próximos aosusuários se localizarem os pontos de conversão, mais eficiente a entrega de conteúdo emaior a economia de banda alcançada. Como a distribuição na última milha é feita viaIP, não é necessária instalação de nenhuma aplicação específica, modificação ou adapta-ção dos dispositivos dos usuários finais. O conteúdo distribuído também pode ser obtidodiretamente via CCN, o que proporciona suporte à mobilidade de usuários.

Os testes realizados na rede do protótipo desenvolvido demonstram que a utili-zação da CCN melhora significativamente o desempenho da distribuição de vídeo sobdemanda em relação ao uso de banda total na rede. A CCN é especialmente eficiente naredução da carga na rede nas imediações dos servidores, o que propicia o isolamento entrea carga no núcleo da rede e a demanda percebida em suas extremidades. Além disso, osresultados comprovam que o sistema dá suporte à mobilidade de usuários, reproduzindovídeo continuamente independentemente de mudança de rede.

Referências[CCNx 2011] CCNx (2011). Ccnx project. Disponível em http://www.ccnx.org/

(Acessado em 15/03/2014).

[Cheriton and Gritter 2000] Cheriton, D. and Gritter, M. (2000). Triad: A new next-generation internet architecture. Technical report, Stanford Computer Science Techni-cal Report.

[Frank et al. 2013] Frank, B., Poese, I., Lin, Y., Smaragdakis, G., Feldmann, A., Maggs, B.,Rake, J., Uhlig, S., and Weber, R. (2013). Pushing cdn-isp collaboration to the limit.ACM SIGCOMM CCR, 43(3).

[Fricker et al. 2012] Fricker, C., Robert, P., Roberts, J., and Sbihi, N. (2012). Impact of traf-fic mix on caching performance in a content-centric network. In Computer Communi-cations Workshops (INFOCOM WKSHPS), 2012 IEEE Conference on, pages 310–315.IEEE.

[Guimaraes et al. 2013] Guimaraes, P. H. V., Ferraz, L. H. G., Torres, J. V., Alvarenga,I. D., Rodrigues, C. S., and Duarte, O. C. M. (2013). Experimenting content-centricnetworks in the future internet testbed environment. In Workshop on Cloud Conver-gence, ICC.

[Jacobson et al. 2009] Jacobson, V., Smetters, D. K., Thornton, J. D., Plass, M. F., Briggs,N. H., and Braynard, R. L. (2009). Networking named content. In Proceedings of the


145

http://www.ccnx.org/

5th international conference on Emerging networking experiments and technologies,pages 1–12. ACM.

[Jiang and Bi 2012] Jiang, X. and Bi, J. (2012). Named content delivery network. Technicalreport, Tsinghua University.

[Jokela et al. 2009] Jokela, P., Zahemszky, A., Esteve Rothenberg, C., Arianfar, S., and Ni-kander, P. (2009). Lipsin: line speed publish/subscribe inter-networking. In ACMSIGCOMM Computer Communication Review, volume 39, pages 195–206. ACM.

[Koponen et al. 2007] Koponen, T., Chawla, M., Chun, B.-G., Ermolinskiy, A., Kim, K. H.,Shenker, S., and Stoica, I. (2007). A data-oriented (and beyond) network architecture.In ACM SIGCOMM Computer Communication Review, volume 37, pages 181–192.ACM.

[Lee and Kim 2011] Lee, J. and Kim, D. (2011). Proxy-assisted content sharing using con-tent centric networking (ccn) for resource-limited mobile consumer devices. ConsumerElectronics, IEEE Transactions on, 57(2):477–483.

[Li and Simon 2011] Li, Z. and Simon, G. (2011). Time-shifted tv in content centricnetworks: the case for cooperative in-network caching. In Communications (ICC),2011 IEEE International Conference on, pages 1–6. IEEE.

[Moraes et al. 2014] Moraes, I. M., Mattos, D. M., Ferraz, L. H. G., Campista, M. E. M.,Rubinstein, M. G., Costa, L. H. M., de Amorim, M. D., Velloso, P. B., Duarte, O.C. M., and Pujolle, G. (2014). Fits: A flexible virtual network testbed architecture.Computer Networks. DOI: http://dx.doi.org/10.1016/j.bjp.2014.01.002.

[NS-3 2014] NS-3 (2014). Ns-3. Disponível em http://www.nsnam.org/ (Acessadoem 15/03/2014).

[Peng 2004] Peng, G. (2004). Cdn: Content distribution network. arXiv preprintcs/0411069.

[Saroiu et al. 2002] Saroiu, S., Gummadi, K. P., Dunn, R. J., Gribble, S. D., and Levy, H. M.(2002). An analysis of internet content delivery systems. ACM SIGOPS OperatingSystems Review, 36(SI):315–327.

[Schulze and Mochalski 2009] Schulze, H. and Mochalski, K. (2009). Internet study2008/2009. IPOQUE Report, 37:351–362.

[Wang et al. 2013] Wang, L., Waltari, O., and Kangasharju, J. (2013). Mobiccn: Mobi-lity support with greedy routing in content-centric networks. In GLOBECOM. IEEEGlobal Communications Conference 2013 : NGN - Next Generation Network. IEEE.

[Zhang et al. 2010] Zhang, L., Estrin, D., Burke, J., Jacobson, V., Thornton, J. D., Smetters,D. K., Zhang, B., Tsudik, G., Massey, D., Papadopoulos, C., et al. (2010). Named datanetworking (ndn) project. Technical Report NDN-0001, Xerox Palo Alto ResearchCenter-PARC.

[Zhu et al. 2013] Zhu, Z., Afanasyev, A., and Zhang, L. (2013). A new perspective onmobility support.


146

http://www.nsnam.org/



Florianópolis - SC



(WGRS)

Sessão Técnica 4

Gerenciamento de VANETs e VANTs

Um Mecanismo para Realçar a Conectividade de RoteamentoGeográfico na Transmissão Multimídia em VANTsRodrigo Costa1, Denis Rosário1, Aldri Santos2, Eduardo Cerqueira1

1GERCOM – Grupo de Redes de Computadores e Comunicação Multimídia – UFPA

2NR2 – Núcleo de Redes sem Fio e Redes Avançadas – DINF – UFPR

{rodrigomc,denis,cerqueira}@ufpa.br,[email protected]

Abstract. Networks of Unmanned Aerial Vehicles (UAVs) have allowed the usageof multimedia applications due to its the high mobility degree and versatility.The transmission data on UAVs using geographic protocols enables a betterdata delivery rate, but it is not enough to provide quality of experience (QoE).This is because the high mobility degree of UAVs, occurring broken links duringthe transmission. Those broken links damage the connectivity and cause delayand packet loss. This paper proposes a mechanism, called RCRV, based on themobility prediction techniques to enhance the routing decision making on geo-graphic protocols, and thus improving the connectivity of UAV networks. RCRVcan support the strategies of geographic routing protocols to forward packets.Further, RCRV was added to GPSR protocol and evaluated by simulation. Re-sults show the gains of transmission and the multimedia delivery with RCRV.

Resumo. As redes de Veículos Aéreos Não Tripulados (VANTs) têm potenciali-zado o uso de aplicações multimídia devido ao seu elevado grau de mobilidadee versatilidade. A transmissão de dados em VANTs por meio de protocolos ge-ográficos possibilita uma melhor taxa de entrega de dados, porém ainda nãoé suficiente para prover qualidade de experiência (QoE). Isso ocorre pelo ele-vado grau de mobilidade dos VANTs que ocasiona quebras de enlace durantea transmissão, prejudicando a conectividade e levando a perdas de pacotes eatrasos. Este trabalho propõe um mecanismo, chamado RCRV, com base emtécnicas de predição de mobilidade em termos de posicionamento e tempo doenlace para realçar a tomada de decisão de roteamento em protocolos geográfi-cos, e assim prolongar a conectividade em redes VANTs. RCRV complementa asestratégias de roteamento dos protocolos geográficos, sendo adicionado ao pro-tocolo GPSR para a avaliação por meio de simulação. Os resultados mostramque o RCRV aumenta a conectividade da transmissão, melhorando a entrega doconteúdo multimídia e a qualidade do vídeo observado pelo usuário.

1. IntroduçãoO uso de aplicações multimídia em cenários de monitoramento ambientais, segurançae controle de tráfego possibilita o aperfeiçoamento de vários serviços para a sociedade,na qual os dados multimídias oferecem uma perspectiva visual diferentes de outros tiposde dados [Ehsan and Hamdaoui 2012]. O emprego de redes VANTs (Veículos AéreosNão Tripulados) tem potencializado o uso de aplicações multimídia, visto que um VANTpode operar em situações perigosas e repetitivas, em regiões hostis ou de difícil acesso,


149

em diferentes altitudes ou velocidades. Esses dispositivos, equipados com câmeras esensores, possuem elevado grau de liberdade de mobilidade e versatilidade, isto é, podemser empregados em diferentes ambientes.

Porém, o grau de mobilidade dos VANTs do tipo quadricoptero ocasiona diversasquebras de enlace de comunicação, prejudicando o encaminhamento dos dados e levandoa muitas perdas ou atraso de pacotes transmitidos [Sahingoz 2013]. Assim, um dos de-safios das redes VANTs é a mitigação da influência do impacto da mobilidade durante atransmissão de dados multimídia de modo a auxiliar no gerenciamento da conectividadeentre os VANTs, e assim evitar falhas de comunicação. A manutenção da conectividadeajuda a reduzir os atrasos e as perdas de pacotes durante a transmissão, proporcionandocerto nível de robustez, bem como a disseminação de vídeo com qualidade.

O gerenciamento da conectividade em redes VANTs tem sido tratado nas camadasMAC (Media Access Control) e de Rede. Na camada MAC, protocolos adaptativos têmbuscado garantir a transmissão por meio do uso de antenas [Alshbatat and Dong 2010,Temel and Bekmezci 2013]. Entretanto, essa solução possui elevado custo e complexi-dade de hardware, devido à necessidade de prover os arranjos de antenas. Na camada deRede, os protocolos de roteamento focam em encaminhar os dados por rotas robustas aquebras de conexão por mobilidade, estabelecidas por critérios baseados em informaçõesde posicionamento [Li et al. 2012, Lin et al. 2012, Zhou et al. 2012, Rohrer et al. 2011].Contudo, esses protocolos de roteamento em geral desconsideram o comportamento demobilidade de um VANT em ambientes 3D e assumem mobilidade em ambientes 2D.

Os protocolos de roteamento geográfico normalmente usam qualificadores de co-nectividade 2D para a seleção de rotas mais robustas e confiáveis. A predição de mobi-lidade é uma dessas abordagens, onde é possível a estimativa das futuras localizações deum dispositivo em um ambiente. Entretanto, há diversas categorias de predição de mobi-lidade [Gavalas et al. 2010], como a predição de posicionamento e o tempo de expiraçãodo enlace que é baseado na velocidade e direção dos dispositivos [Uddin et al. 2013]. Otempo de expiração do enlace pode beneficiar as aplicações multimídia quanto à garantiada transmissão dos dados por rotas mais persistentes. Logo, a predição de posicionamentoe o tempo de expiração do enlace, integrados ao serviço de roteamento, nas redes VANTsrealçariam a qualidade dos vídeos sobre a percepção do usuário, por exemplo um centrode operações de emergências [Bürkle et al. 2011].

Este artigo propõe um mecanismo, chamado RCRV (Realce de Conectividade emRedes Vants), para realçar a conectividade em protocolos de roteamento geográfico nasredes VANTs em ambiente 3D, oferecendo uma maior entrega de pacotes e uma melhorqualidade do vídeo recebido. O RCRV possibilita um VANT que tenha um pacote a serencaminhado estime o posicionamento futuro dos seus VANTs vizinhos e, a partir decritérios de tempo de expiração do enlace, direção e distância de interceptação dessesvizinhos, calcule seus índices de conectividade. A estimativa de posicionamento futuroajuda a monitorar uma possível quebra de enlace de um VANT por afastamento da áreade transmissão e os critérios permitem a determinação do comportamento de mobilidade.Assim, um protocolo de roteamento utilizaria esse índice para definir o melhor VANT aoqual um pacote deveria ser encaminhado.


150

O RCRV foi implementado no protocolo GPSR e avaliado no simulador NS-3 so-bre cenários com diferentes mobilidades e densidades de VANTs. A avaliação do RCRVconsidera o desempenho da rede e a qualidade do vídeo transmitido por meio de métricasde Qualidade de Serviço (QoS) e Qualidade de Experiência (QoE) .

O restante do trabalho está organizado da seguinte maneira: A Seção 2 discute ostrabalhos relacionados. A Seção 3 detalha a arquitetura do RCRV e sua integração com osprotocolos de roteamento. A Seção 4 descreve o emprego do RCRV ao protocolo GPSR.A Seção 5 apresenta uma avaliação do do RCRV, e a Seção 6 apresenta as conclusões.


A garantia da conectividade em redes de dispositivos aéreos tem sido investigada nascamadas MAC e de Rede. Na camada MAC, a grande variação da distância e a altamobilidade dos nós conduzem a muitas flutuações na qualidade do enlace. Além disso,altas latências de pacotes podem ocorrer e afetar a qualidade dos dados em aplicações detempo real [Bekmezci et al. 2013]. Em [Alshbatat and Dong 2010], os autores propuse-ram um protocolo MAC adaptativo em que a transmissão de mensagens RTS/CTS ocorrepor antenas omnidirecionais e a transmissão dos dados por meio de antenas direcionais.Em [Temel and Bekmezci 2013], os autores desenvolveram um protocolo MAC direcio-nal aliado a três antenas direcionais para a descoberta de vizinhos, a troca de mensagensRTS/CTS e para a transmissão de dados. No entanto, o uso de arranjos de antenas e dehardwares adicionais eleva os custos de implantação dos VANTs.

Na camada de Rede, algumas estratégias de roteamento adotam a predição de mo-bilidade para garantir a transmissão dos dados por rotas mais estáveis à mobilidade. Em[Li et al. 2012], os autores desenvolveram um protocolo de roteamento em que a predi-ção de mobilidade auxilia no monitoramento da distância entre um nó atual e o próximosalto. A permanência da transmissão de dados ou sua interrupção é influenciada pelodistanciamento entre os pares de nós. Entretanto, esta proposta considera que os VANTsagem sobre um cenário 2D com altura constante. Além disso, a garantia de conectividadeapenas pelo monitoramento da distância é uma solução ineficiente devido à elevada mobi-lidade dos VANTs. Em [Lin et al. 2012], os autores propuseram um protocolo roteamentopara VANTs em um cenário 2D, onde cada nó prediz a localização dos seus vizinhos pormeio de uma função de distribuição de probabilidade Gaussiana. Além disso, a tarefa deseleção de rotas considera a distância entre os nós e o destino, bem como a diferença dotempo de predição para selecionar o próximo salto, mas ignora o uso da estimativa dotempo de expiração do enlace.

Outros trabalhos tentam garantir a conectividade através do tempo estimado paraum nó alcançar o destino. Em [Zhou et al. 2012], os autores propuseram uma estratégiade roteamento baseada no uso do sistema ADS-B (Automatic Dependent Surveillance-Broadcast) em conjunto com um protocolo geográfico. A informação de mobilidade for-necida pelo sistema ADS-B ajuda a definir o próximo salto sem a transmissão de loca-lização. Esta proposta melhora a taxa de entrega de pacotes, reduzindo a sobrecarga narede. Além disso, a velocidade e a localização do nó permitem a seleção do próximo saltomais rápido a alcançar o destino. Porém, este trabalho ignora a influência da direção paraestimar quando uma conectividade está quebrada. Em [Rohrer et al. 2011], é propostoum protocolo de roteamento em que a predição de mobilidade permite a obtenção da dis-


151

tância entre o destino e os demais nós. Essa distância e a velocidade garantem a seleçãodos melhores próximos saltos em direção ao destino. Contudo, este trabalho assume queos nós estão em uma altura constante. Além disso, ele considera apenas a direção de umnó ao nó destino.

3. Mecanismo para Realçar a Conectividade em Redes VANTsEsta seção descreve o mecanismo RCRV para realçar a conectividade entre nós na trans-missão multimídia em protocolos de roteamento geográficos para redes VANTs. O RCRVconsidera informações sobre a mobilidade, como a localização, a velocidade e o tempopara calcular tanto a predição de posicionamento quanto o índice de conectividade. O usode um serviço de localização, como o GPS (Global Position System), fornece ao RCRVinformações sobre o posicionamento do nó que realiza o processo de seleção de rota. Valeressaltar que a maioria dos protocolos de roteamento geográficos armazena as informa-ções de mobilidade dos nós nas tabelas de vizinhos. Portanto, o RCRV é um mecanismoindependente de protocolo de roteamento.

3.1. Arquitetura do RCRV

A Figura 1 mostra a arquitetura de RCRV e sua interação com um determinado protocolode roteamento geográfico. O RCRV é composto por dois módulos: Predição de Posici-onamento e Classificador de Rota. O módulo de predição de posicionamento monitora adistância entre um nó atual e o nó selecionado para enviar os seus pacotes. Além disso,este módulo é responsável por fornecer ao módulo classificador de rota o posicionamentoatual dos nós vizinhos de um nó.

O módulo classificador de rota é responsável por calcular um índice de conectivi-dade (IC) com base nos critérios de tempo de expiração do enlace, direção e distância deinterceptação para cada nó vizinho. O valor de IC pode ser aplicado pelas estratégias deencaminhamento presentes nos protocolos de roteamento para decidir qual o melhor nó,ou seja, próximo salto, a encaminhar pacotes.

Figura 1. RCRV e sua interação com um protocolo de roteamento

3.2. Predição de Posicionamento

O módulo de predição de posicionamento possibilita a estimativa do posicionamento deum nó nj . Esta estimativa ocorre por meio de informações de coordenadas no plano 3D(x′j ,y

′j ,z′j), da velocidade (vj) e do tempo (t) de nj . Portanto, o posicionamento estimado

(xpred, ypred, zpred) de nj é calculado de acordo com a Equação 1.


152

xpred = x′j + ∆t(vjsinθj × cosφj)ypred = y′j + ∆t(vjsinθj × sinφj)zpred = z′j + ∆t(vjcosθj)

(1)

Onde, ∆t é a diferença entre o tempo atual tc e o tempo do último pacote de po-sição para cada nó vizinho nj , ou seja, ∆t = tc − tl. Por outro lado, θj e φj representamas direções de deslocamento de nj . Em redes VANTs, existe a possibilidade de um nó njsair da área de transmissão de um outro nó ni. Neste caso, a predição de posicionamentopermite o monitoramento da distância entre um nó ni e seu próximo salto durante a trans-missão multimídia. Portanto, o RCRV garante que um nó ni selecione um novo próximosalto antes da ocorrência da quebra do enlace.

3.3. Índice de Conectividade

O Índice de Conectividade (IC), encontrado no módulo classificador de rota, dá suporteas estratégias de encaminhamento para a tomada de decisão sobre o próximo salto. OIC tem como objetivo ajudar na seleção de um próximo salto com menor influência damobilidade na transmissão multimídia. Dessa forma, cada nó computa o IC dos seusvizinhos (nj) com base na Equação 2, considerando o tempo de expiração do enlace, adireção e a distância de interceptação.

IC = minNj∈NiICi,j = α× TExLi,j + β ×DirIj,D(cj, vj, D) + γ ×DisIi,j(D) (2)

O cálculo de IC considera pesos (α, β, γ) para cada um dos critérios: TExLi,j(tempo de expiração do enlace),DirIj,D(cj, vj, D) (direção de interceptação) eDisIi,j(D)(distância de interceptação), com a soma dos pesos igual a 1. Assim, é possível atribuirdiferentes níveis de importância para cada um dos critérios que compõem o IC. Por fim,o melhor nó candidato à próximo salto é o nó com o menor valor de IC.

Cada um dos três critérios que compõem o IC, apresentam características essen-ciais para assegurar uma seleção eficiente e robusta de próximos saltos. Mais especifica-mente, o TExLi,j garante a seleção de um próximo salto que possui poucas variações nasvelocidades e direções. Além disso, ele permite o prolongamento da conexão entre os pa-res de nós participantes da transmissão multimídia. O DirIj,D(cj, vj, D) provê a seleçãodos nós que não estejam em movimentações opostas ao destino. Por fim, o DisIi,j(D)permite a seleção dos nós com base em suas distâncias. Portanto, um nó ni seleciona opróximo salto mais próximo ao destino, porém não muito próximo ao limite da sua áreade transmissão. A seguir é detalhado o cálculo do valor de cada um dos três critérios.

3.3.1. Estimativa do Tempo de Expiração do Enlace

A estimativa do tempo de duração de um enlace é um dos métodos utilizados para esti-mar a mobilidade de um nó e garantir que o serviço de roteamento estabeleça rotas maisrobustas [Gavalas et al. 2010]. O tempo de expiração do enlace (TExLi,j) é um critérioque estima a duração de um enlace entre dois nós. O RCRV calcula o TExLi,j por meiodo modelo proposto por [Uddin et al. 2013]. Este modelo utiliza as informações de posi-cionamento no plano 3D, a velocidade e a direção dos nós. Dessa forma, o modelo estimao TExLi,j de acordo com a variação da velocidade, da direção e da distância entre os nós.


153

Para explicar o cálculo do tempo de expiração de um enlace, assumem-se dois nósni e nj , os quais permanecem dentro da área de transmissão de ambos. Sejam (xi, yi, zi) e(xj, yj, zj) as coordenas de ni e nj ∈ R3, respectivamente. Além disso, sejam θi, φi e θj ,φj as direções de mobilidade. Por fim, supondo que eles têm uma velocidade de vi e vjm/s. Então, as operações da Equação 3 indicam a distância entre os nós e suas direções.

a = (xi − xj)b = (yi − yj)c = (zi − zj)e = (visinθicosφi − vjsinθjcosφj)f = (visinθisinφi − vjsinθjsinφj)g = (vicosφi − vjcosφj)

(3)

O TExLi,j entre dois nós ni e nj em uma rede 3D é calculado de acordo com umaequação quadrática, a qual considera que ambos os nós possuem áreas de transmissãoesféricas com um determinado raio TR. Dessa forma, o TExLi,j é obtido por meio daEquação 4.

TExLi,j =−(2ae+ 2bf + 2cg)±

√(2ae+ 2bf + 2cg)2 − 4(e2 + f2 + g2)(a2 + b2 + c2 − TR2)

2(e2 + f2 + g2)(4)

De acordo com a equação proposta, o TExLi,j é mais influenciado por grandesvariações nas diferenças da direção e da velocidade dos nós, do que pela distância entreeles. Assim, valores altos de TExLi,j indicam uma movimentação com trajetórias contrá-rias ou com velocidades diferentes entre os nós ni e nj . Este comportamento sugere quetal enlace é mais suscetível a quebra em decorrência da mobilidade, diminuindo assim arobustez do sistema. Entretanto, valores baixos de TExLi,j significam que o enlace entreos nós ni e nj é mais duradouro e robusto a quebra devido a mobilidade.

3.3.2. Direção de Interceptação

A direção de interceptação (DirIj,D(cj, vj, D)) é um critério que indica qual dos nóspresentes na tabela de vizinhos têm a melhor possibilidade de alcançar o destino. Issoé devido ao fato de que a seleção de um próximo salto que esteja em movimentaçãooposta ao destino aumenta o número de saltos. Com isso, ocorre a redução da robusteze o acréscimo da quantidade de pacotes perdidos. Por consequência, há a diminuição daqualidade do vídeo. Dessa forma, é preferível que o protocolo de roteamento selecionepróximos saltos com trajetórias mais próximas ao destino.

O DirIj,D(cj, vj, D) é obtido por meio de operações trigonométricas e calculadoconforme a Equação 5. Porém, o cálculo doDirIj,D(cj, vj, D) utiliza apenas informaçõesde mobilidade no espaço 2D (R2), para priorizar a direção, independentemente da altura.Assim, é possível verificar a direção de um candidato à próximo salto em relação aodestino. Sejam, cj = (xj, yj) e vj = (vjx, vjy) as coordenadas e as componentes davelocidade de um nó nj . Além disso, todos os nós da rede têm o conhecimento sobreas coordenadas (xd, yd) do destino. Então, a Equação 5 indica o nó com direção maispróxima ao destino.


154

DirIj,D(cj, vj, D) =|θ1 − θ2|angleTh

(5)

Onde, θ1 = atan2(vjy, vjx)180π

representa o ângulo em graus∗ entre o eixo xpositivo e as componentes da velocidade vjy e vjx de um nó nj . Além disso, θ2 =atan2(yd − yj, xd − xj)

180π

é o ângulo em graus entre o eixo x positivo de um nó nje a linha imaginária que o interliga ao destino. Por fim, o limiar angleTh é um limiar emgraus para auxiliar na seleção de um nó dentro de um uma área predefinida.

Figura 2. Direção dos nós em relação ao destino

A Figura 2 ilustra dois nós (n1 e n2) presentes na tabela de nós vizinhos de umnó ni. Ambos n1 e n2 podem estabelecer uma rota com ni. Porém, há a necessidade daverificação das suas direções, a fim de evitar a seleção de um nó com direção oposta aodestino. De acordo com o exemplo da Figura 2, o nó n1 apresenta uma mobilidade opostaao destino. Este comportamento de mobilidade resulta em um alto valor de ∆θ. Portanto,ele não é um candidato adequado para atuar como um nó próximo salto. Por outro lado,o pequeno valor para ∆θ indica que o nó n2 é o melhor candidato na tabela de ni.

A tabela de vizinhos do ni pode conter apenas nós com direções de deslocamentoopostas ao destino. Este comportamento pode ocasionar rotas com longos saltos ou aperda de pacotes pelo isolamento destes nós em uma região sem outros nós. No entanto,o nó ni não deve desconsiderar o uso desses vizinhos presentes em sua tabela. Assim, olimiar angleTh permite a seleção de um nó com melhor direção em relação aos demaispresentes na tabela de vizinhos do ni.

3.3.3. Distância de Interceptação

A seleção de próximos saltos mais próximos ao destino é uma das estratégias mais utili-zadas em protocolos de roteamento geográficos. Contudo, esta estratégia é ineficiente emredes composta por nós moveis, como em redes VANTs. A seleção de nós mais próximosao destino aumenta a possibilidade de quebra da conexão, devido o afastamento da áreade transmissão dos nós. Portanto, uma seleção de próximo salto eficiente deve atentar aosefeitos da mobilidade.

∗atan2(x, y): É uma função presente em várias linguagens de programação e que retorna o quadranteapropriado para um dado ângulo entre x e y.


155

A distância de interceptação (DisIi,j(D)) é um critério baseado na distância entreum nó ni e um outro nó nj . A obtenção da distância é facilitada pelo conhecimentosobre o posicionamento de ambos os nós. Desta forma, a Equação 6 permite o cálculo dadistância euclidiana entre os nós ni e nj .

dni,nj=√

(xj − xi)2 + (yj − yi)2 + (zj − zi)2 (6)

Considerando (xi, yi, zi) como as coordenadas de um nó ni que deseja selecionarseu próximo salto. Além disso, assumindo (xj, yj, zj) e (xd, yd, zd) como as coordenadasdo candidato à próximo salto nj e do destino, respectivamente. Assim, a distância deinterceptação é obtida pela Equação 7.

DisIi,j(D) =

∣∣∣∣di,D − dj,Ddi,D

∣∣∣∣ (7)

Onde, dni,D é a distância entre o um nó ni que deseja selecionar seu próximo saltoe o destino. Além disso, dnj ,D é a distância entre o candidato à próximo salto nj e odestino. Como resultado da equação proposta, a distância DisIi,j(D) privilegia a seleçãodos nós com baixa diferença de distância em relação ao seu antecessor e ao destino.

4. Estudo de Caso

O mecanismo RCRV é independente de protocolo de roteamento, e pode atuar em qual-quer protocolo de roteamento geográfico para redes VANTs. Para mostrar os impactos ebenefícios do RCRV, ele foi integrado ao protocolo Greedy Perimeter Stateless Routing(GPSR) [Karp and Kung 2000], visto que o GPSR tem sido usado como referência pararoteamento geográfico e também é empregado em redes VANTs. O GPSR possui doismodos de operação para o encaminhamento de pacotes. O modo greedy permite a seleçãodos nós mais próximos ao destino. Assim, o GPSR estabelece rotas com poucos saltos.Entretanto, esta abordagem falha quando a distância entre o emissor e o destino é a menordas distâncias entre os demais possíveis nós candidatos presentes na tabela de roteamentodo emissor. Para resolver essa falha, o GPSR usa o modo perímetro (perimeter mode),que consiste de uma estratégia de recuperação ao encaminhamento dos pacotes através daregra da mão direita.

Contudo, as estratégias de roteamento adotadas pelo GPSR não garantem umaformação eficiente e confiável destas rotas. Isso ocorre porque a seleção dos nós con-siderando apenas a distância é uma abordagem ineficiente, visto que há a possibilidadede quebra de enlace em razão da saída de um nó da área de transmissão de outro nó[Alsaqour et al. 2012]. Portanto, é necessária a adoção de um mecanismo para a seleçãode rotas mais robustas e confiáveis, e que mitigue os problemas da mobilidade dos nós.Nesse contexto, esse trabalho apresenta, como um estudo de caso, a inclusão do RCRVao GPSR, chamado de GPSR-RCRV, de modo a garantir uma eficiente transmissão mul-timídia em redes VANTs. Isso ocorre porque o RCRV considera múltiplos critérios paraseleção de próximo salto, e assim ele provê uma melhoria na redução da influência damobilidade em redes VANTs comparado as propostas existentes.

A Figura 3 ilustra o processo de formação de uma rota robusta, eficiente e confiá-vel por meio do GPSR-RCRV entre um nó Fonte F e um nó de Destino D, com possíveis


156

nós vizinhos M , N , O, P , Q e R. A tabela de vizinhos de cada nó guarda as posições noplano 3D e as componentes da velocidade dos seus nós vizinhos. Assim, os nós calculamo índice de conectividade e a predição de posicionamento, como descrito na Seção 3.

IC = 0.44M

IC = 0.56N

IC = 1.06Q

IC = 0.89R

IC = 0.39O

IC = 1.59P

Figura 3. Formação de um caminho entre um nó fonte F e o destino D

No exemplo da Figura 3, o nó F seleciona o nó M como próximo salto de acordocom o RCRV. O nó M tem IC = 0.44 devido aos três critérios de seleção vistos naSeção 3. Assim, M segue na mesma direção que F . Logo, o enlace entre F e M perma-nece ativo por um maior período. Além disso, M segue em direção ao destino, e assimhá um baixo risco de perda de pacotes pelo isolamento deste nó em uma área afastada esem vizinhos. Por fim, M tem a menor distância em relação ao nó de destino D. Emseguida, M seleciona o nó O devido ao seu baixo IC em relação ao nó P . No entanto, oGPSR selecionaria P , pois tal nó tem a menor distância ao destino. Contudo, P apresentauma trajetória oposta ao destino. O processo de seleção continua até que um nó possua odestino como um dos seus vizinhos.

A rota estabelecida entre os nós F e D permanece inalterada até a ocorrência dedois eventos. O primeiro evento é a quebra de enlace devido à mobilidade dos nós. Nestecaso, o esquema de predição de posicionamento auxilia no monitoramento periódico dadistância entre pares de nós. Assim, é possível detectar quando um dado próximo saltopode sair da área de transmissão do seu último salto. O segundo evento é a exclusão deum nó vizinho devido à expiração do seu registro na tabela de vizinhos. Em ambos oscasos, o GPSR-RCRV reestabelece a rota.

5. AvaliaçãoO RCRV foi implementado e avaliado no simulador NS-3 versão 3.17. O ambiente deavaliação considera um cenário de monitoramento urbano para uma situação emergencialou de segurança. Este ambiente possui nós VANTs dispostos numa área, onde a unidadede controle está no centro da área. A mobilidade de um VANT numa rede 3D é represen-tada pelo modelo de mobilidade Gauss-Markov-3D [Broyles et al. 2010], pois ele ofereceum comportamento de mobilidade mais próximo ao de um VANT em um cenário real.

Nas simulações a quantidade e a velocidade dos VANTs foram variadas. Para cadacombinação, 33 simulações foram realizadas e os resultados consideram um intervalo deconfiança de 95%. Desta forma, 36, 44 e 56 VANTs foram dispostos aleatoriamente emuma área de 1000x1000 m, com uma altura uniforme entre 40 e 50 m. As velocidades dosVANTs variaram de 1 a 4 m/s com um tempo de atualização de 1s. O posicionamento do


157

destino é o centro da área (500, 500, 5). Esta configuração visa uma representação maispróxima a uma rede VANT. Por fim, foram atribuídos os valores de 0.2, 0.3 e 0.5 para ospesos do índice de conectividade (α, β , γ), e um angleTh de 30◦.

Assume-se que os VANTs não apresentam falhas pela falta de recurso energético,tendo energia suficiente para voar pela área durante as simulações. Os VANTs se comu-nicam por meio do padrão IEEE 802.11b com uma taxa de transmissão de 11 Mb/s. CadaVANT também possui um área de transmissão de 250 m definida por uma potência detransmissão de 33 dBm. Eles têm a capacidade de capturar fluxos de vídeo em tempo real,e transmití-los por meio de extensões do framework EvalVid - A Video Quality Evalua-tion Tool-Set no simulador. Foram escolhidos os vídeos UAV1 e UAV2 [GERCOM 2013]na transmissão, pois eles representam a cobertura de um VANT em um ambiente urbano.No entanto, o vídeo UAV2 possui uma maior região de movimentação do que o UAV1,indicando uma situação de instabilidade de voo. Ambos os vídeos têm 10s de duração, esão codificados no padrão H.264 em 300 kbps, 18 de tamanho de GoP (Group Of Pictu-res), formato 352x288 pixels, e uma amostragem igual a 30 quadros por segundo, comoesperado para vídeos em VANTs.

As simulações objetivam avaliar o comportamento do GPSR e do GPSR-RCRVquanto ao desempenho da rede e da qualidade do vídeo transmitido do ponto de vista dosusuários. Assim, são verificadas as métricas de QoS: Taxa de entrega de pacotes (PDR),que significa o número de pacotes recebidos dividido pelo número de pacotes enviadosna camada de aplicação, e o Atraso médio fim-a-fim (E2E), que significa o tempo médioentre a transmissão de um dado pacote e sua chegada ao destino. No entanto, tais métricasapenas refletem o desempenho de um sistema do ponto de vista da rede. Assim, elas nãomostram a qualidade do vídeo da perspectiva do usuário.

As métricas de QoE provêm a avaliação da qualidade do vídeo de forma maiseficiente do que as métricas de QoS. Nesse contexto, há as métricas de QoE objetivas esubjetivas, que medem o nível de qualidade dos vídeos transmitidos [Aguiar et al. 2012].Nesse trabalho, no entanto, é utilizada apenas a métrica objetiva de QoE, chamada SSIM(Structural Similarity), que mede a similaridade entre duas imagens. O índice SSIM éaplicado como uma medida de qualidade entre imagens, desde que uma delas não apre-sente falhas. O SSIM é definido como um valor decimal entre 0 e 1, onde 0 significa que ovídeo transmitido não tem correlação com a imagem original (baixa qualidade do vídeo),e 1 significa que o vídeo transmitido tem exatamente a mesma imagem (alta qualidadede vídeo). Foi utilizado o MSU Video Quality Measurement Tool (VQMT) para medir ovalor de SSIM para cada vídeo transmitido.

5.1. Resultados de QoS e QoE para UAV1

A Figura 4 ilustra o desempenho do GPSR e do GPSR-RCRV sobre as métricas de QoS eQoE. Percebe-se que para todas as quantidades de VANTs em 1 m/s, o GPSR apresentouuma baixa taxa de entrega e um elevado atraso fim-a-fim. Para 36 e 44 VANTs, as taxas dePDR e E2E foram de aproximadamente 83% e 0.12s, respectivamente. Para 56 VANTs, astaxas de PDR e E2E foram em torno de 80% e 0.10s, respectivamente. Isto ocorre devidoà ausência de uma estratégia de encaminhamento orientada à mobilidade dos VANTs.Além disso, o GPSR entra constantemente no modo de recuperação e, portanto há a gera-ção de longos atrasos durante a transmissão multimídia. Por outro lado, o GPSR-RCRV


158

proporcionou um ganho de pelo menos 13% no PDR e 70% no E2E em 36 e 44 VANTs,e um ganho de pelo menos 10% no PDR e 60% no E2E em 56 VANTs. Isso é devido aouso do IC para escolher o melhor VANT a encaminhar os pacotes. Assim, GPSR-RCRVgarante uma transmissão multimídia com poucas perdas de pacotes e atrasos. Além disso,o GPSR-RCRV obteve um ganho de até 30% de PDR para 36, 44 e 56 VANTs a 4 m/s.Isto ocorre em razão da predição de posicionamento, a qual provê o monitoramento depossíveis quebras de conectividade pelo afastamento da área de transmissão de VANTsvizinhos. Por fim, o aumento da velocidade influencia no atraso fim-a-fim. Dessa forma,o GPSR-RCRV proporcionou um ganho de 70% no E2E para 36 e 44 VANTs. Por outrolado, para 56 VANTs esse ganho foi de 60% em relação ao GPSR. Isto ocorre devido aoGPSR-RCRV não utilizar o modo de recuperação do GPSR.

Figura 4. PDR, E2E e SSIM para 36, 44 e 56 VANTs - UAV1

Em relação à QoE, para todas as quantidades de VANTs o GPSR-RCRV proveuuma disseminação de vídeo com qualidade assegurada do ponto de vista do usuário emcomparação ao GPSR. Isto ocorre porque o GPSR-RCRV escolhe rotas robustas e confiá-veis em um plano 3D para transmitir o vídeo com uma menor perda de pacotes em relaçãoao GPSR. Além disso, o GPSR-RCRV utiliza o IC para avaliar o comportamento de mo-bilidade de um possível VANT candidato a próximo salto. Isso foi refletido em um SSIMem torno de 0.93 e um ganho de até 7% para 36, 44 e 56 VANTs a 1 m/s. Por outro lado, oGPSR-RCRV proporcionou um SSIM de 0.88 e um ganho de até 8% de SSIM para 36, 44


159

e 56 VANTs a 4 m/s. Este resultado deve-se ao uso da predição de posicionamento, queprovê o monitoramento de possíveis quebras de conectividade pelo afastamento da áreade transmissão de VANTs vizinhos. Portanto, o GPSR-RCRV garante um melhor nívelde qualidade do vídeo diante de perda de pacotes por colisões devido à alta densidade darede ou pela quebra de conectividade. Além disso, é importante ressaltar que o processode codificação e decodificação de vídeo também deteriora a qualidade do vídeo na pers-pectiva do usuário, mesmo na ausência de perda de pacotes. Dessa forma, o vídeo UAV1apresenta um SSIM máximo de 0.97. Assim, para 36, 44 e 56 VANTs a 1 m/s, o GPSR-RCRV apresentou um desempenho 4% inferior ao máximo para este vídeo. Por outrolado, ele apresentou um desempenho de SSIM inferior a 7% para 36,44 e 56 VANTs a 4m/s. Logo, o GPSR-RCRV garante uma melhor integridade do vídeo transmitido, sendoimportante em ambientes de monitoramento urbano.

5.2. Resultados de QoS e QoE para UAV2

Em um ambiente real, grande parte dos VANTs apresentam oscilações durante o voodevido às influências do vento. Assim, o vídeo UAV2 possui uma maior região de movi-mentação causada pelo movimento dos VANTs. Em [Aguiar et al. 2012], argumenta-seque esse tipo de vídeo é mais afetado pela perda de frames.

Figura 5. PDR, E2E e SSIM para 36, 44 e 56 VANTs - UAV2


160

A Figura 5 mostra o desempenho dos protocolos diante da transmissão do vídeoUAV2. Em 36 e 56 VANTs a 1 m/s, o GPSR-RCRV garantiu taxas de pelo menos 90%e 0.10s para PDR e E2E. Isto ocorre porque o IC proporciona a formação de rotas maisrobustas à mobilidade. Entretanto, para 44 VANTs, o GPSR-RCRV teve uma taxa dePDR próxima ao GPSR e um E2E de 0.03s. Por outro lado, em 36 e 44 VANTs a 4 m/s,as taxas de PDR e E2E foram de no mínimo 85% e 0.10s. Para 56 VANTs, as taxas dePDR e E2E foram em torno de 80% e 0.14s. Isto porque o GPSR-RCRV não usa o modode recuperação presente no GPSR. Portanto, o GPSR-RCRV proporciona uma entrega depacote com baixo atraso diante da alta densidade ou mobilidade da rede.

No que diz respeito aos resultados de QoE, para todas as quantidades de VANTs,o GPSR-RCRV assegurou uma disseminação de vídeo com qualidade sobre o ponto devista do usuário em comparação ao GPSR. Para 36 e 56 VANTs a 1 m/s, obteve-se umSSIM em torno de 0.85 e um ganho de até 7%. Para 44 VANTs, obteve-se um SSIM de0.82 e um ganho de 3%. Por outro lado, para 4 m/s, o GPSR-RCRV proporcionou umSSIM de pelo menos 0.80 e um ganho de 10% para 44 e 56 VANTs. Para 36 VANTs, esteSSIM foi de 0.85 com um ganho de 13% em relação ao GPSR. Estes resultados devem-se a predição de posicionamento, que fornece o monitoramento de possíveis quebras deconectividade pelo afastamento da área de transmissão de VANTs vizinhos. Além disso,a formação de rotas mais robustas e confiáveis pelo uso do IC reduz a perda de frames devídeo do tipo I e P, onde tais perdas prejudicam a qualidade do vídeo do ponto de vista dousuário. Logo, o GPSR-RCRV garante um melhor nível de qualidade sobre a perspectivado usuário.

6. Conclusão

Este trabalho propôs o mecanismo RCRV para realçar a conectividade do roteamento emredes VANTs. O RCRV aplica critérios de tempo de expiração do enlace, direção e dis-tância de interceptação num ambiente 3D para indicar os comportamentos de mobilidadedos VANTs. Através de um índice de conectividade, o RCRV auxilia o protocolo de ro-teamento geográfico a detectar o melhor VANT a ser encaminhado um fluxo de pacotes.O RCRV também obtém uma estimativa de posicionamento futuro ao monitoramento depossíveis quebras de enlace de um VANT por afastamento da área de transmissão.

Resultados mostraram que o GPSR usando o RCRV apresentou uma maior taxade entrega de pacotes e um menor atraso fim-a-fim para os dois vídeos testados. O RCRVproporcionou para diversas quantidades de VANTs um PDR acima de 10% e o E2E abaixode 70%, e garantiu um SSIM acima de 8%, possibilitando um melhor nível da qualidadedo vídeo entregue. Como trabalhos futuros, pretende-se avaliar a eficiência do RCRVem relação a um protocolo de roteamento para VANTs. Além disso, pretende-se aplicaro RCRV em um protocolo de roteamento geográfico baseado em múltiplos fluxos, bemcomo aplicá-lo em um protocolo de roteamento oportunístico.

Agradecimento

Este trabalho foi parcialmente financiado com recursos do Conselho Nacional de Desen-volvimento Científico e Tecnológico (CNPq).


161

ReferênciasAguiar, E., Riker, A., Abelém, A., Cerqueira, E., and Mu, M. (2012). Video quality estimator for wireless

mesh networks. In IEEE 20th International Workshop on Quality of Service (IWQoS ’12), pages 1–9,Coimbra,POR. IEEE.

Alsaqour, R. A., Abdelhaq, M. S., and Alsukour, O. A. (2012). Effect of network parameters on neighborwireless link breaks in gpsr protocol and enhancement using mobility prediction model. EURASIPJournal on Wireless Communications and Networking, 2012(1):1–15.

Alshbatat, A. I. and Dong, L. (2010). Adaptive MAC protocol for UAV communication networks using di-rectional antennas. In Proceedings of the International Conference on Networking, Sensing and Control(ICNSC’10), pages 598–603, Chicago, USA. IEEE.

Bekmezci, I., Sahingoz, O. K., and Temel, S. (2013). Flying Ad-Hoc Networks (FANET): A Survey. AdHoc Networks, 11(3):1254–1270.

Broyles, D., Jabbar, A., and Sterbenz, J. P. (2010). Design and analysis of a 3–d gauss-markov mobility mo-del for highly-dynamic airborne networks. In Proceedings of the International Telemetering Conference(ITC ’10), pages 1–20, San Diego, CA.

Bürkle, A., Segor, F., and Kollmann, M. (2011). Towards autonomous micro uav swarms. Journal ofintelligent & robotic systems, 61(1-4):339–353.

Ehsan, S. and Hamdaoui, B. (2012). A survey on energy-efficient routing techniques with qos assurancesfor wireless multimedia sensor networks. IEEE Communications Surveys & Tutorials, 14(2):265–278.

Gavalas, D., Konstantopoulos, C., and Pantziou, G. (2010). Mobility Prediction in Mobile Ad HocNetworks. Next Generation Mobile Networks and Ubiquitous Computing, pages 226–240.

GERCOM (2013). Source Videos Used for Simulations. https://plus.google.com/1177654685294494878-70/videos. Acessado em 10 de Setembro de 2013.

Karp, B. and Kung, H.-T. (2000). GPSR: Greedy perimeter stateless routing for wireless networks. InProceedings of the 6th annual international conference on Mobile computing and networking (MobiCom’00), pages 243–254, Boston, USA. ACM.

Li, Y., St-Hilaire, M., and Kunz, T. (2012). Improving routing in networks of UAVs via scoped floodingand mobility prediction. In IFIP Wireless Days (WD’12), pages 1–6, Dublin, Irland. IEEE.

Lin, L., Sun, Q., Wang, S., and Yang, F. (2012). A geographic mobility prediction routing protocol for AdHoc UAV Network. In 3rd International Workshop on Wireless Networking and Control for UnmannedAutonomous Vehicles (Wi-UAV’12), pages 1597–1602, Anaheim, USA. IEEE.

Rohrer, J. P., Cetinkaya, E. K., Narra, H., Broyles, D., Peters, K., and Sterbenz, J. P. (2011). AeroRPperformance in highly-dynamic airborne networks using 3D Gauss-Markov mobility model. In MilitaryCommunications Conference (MILCOM’11), pages 834–841, Baltimore, USA. IEEE.

Sahingoz, O. K. (2013). Mobile networking with uavs: opportunities and challenges. In 2013 InternationalConference on Unmanned Aircraft Systems (ICUAS ’13), pages 933–941, Atlanta,USA. IEEE.

Temel, S. and Bekmezci, I. (2013). On the performance of Flying Ad Hoc Networks (FANETs) utilizingnear space high altitude platforms (HAPs). In Proceedings of the 6th International Conference on RecentAdvances in Space Technologies (RAST’13), pages 461–465, Istanbul, Turkey. IEEE.

Uddin, M. A., Mamun, M., and Rashid (2013). Link Expiration Time-Aware Routing Protocol for UWSNs.Journal of Sensors, 2013(625274):9.

Zhou, Q., Gu, W., Li, J., Sun, Q., and Yang, F. (2012). A Topology Aware Routing Protocol Based ADS-BSystem for Aeronautical Ad Hoc Networks. In 8th International Conference on Wireless Communicati-ons, Networking and Mobile Computing (WiCOM’12), pages 1–4, Shanghai, China. IEEE.


162

Investigacao sobre o Uso de VANTs em Redes DTN paraCenarios de Emergencia

Jose Carlos de Albuquerque, Sidney C. de Lucena, Carlos Alberto V. Campos

1Universidade Federal do Estado do Rio de Janeiro (UNIRIO)Avenida Pasteur, 584 – Rio de Janeiro – RJ – Brazil

{jose.albuquerque, sidney, beto}@uniriotec.br

Abstract. The communication between rescue teams and the command center(CC) of search operations in disaster areas is frequently affected by geographi-cal obstacles, making it not effective. One way to overcome such problems is touse unmanned aerial vehicles (UAV) as mobile nodes of a delay tolerant network(DTN), that gives support to communications. This paper evaluates the perfor-mance of different DTN routing protocols through simulations based on realflight traces of an UAV over a scenario of natural disaster. Obtained results al-low the verification of proper routing protocols and the cost/benefit relationshipbetween number of UAVs and performance of the DTN.

Resumo. A comunicacao entre equipes de resgate e o centro de comando (CC)de operacoes de busca em areas de catastrofe e frequentemente afetada porobstaculos geograficos, tornando-a ineficaz. Uma forma de superar tais pro-blemas e utilizando veıculos aereos nao tripulados (VANTs) como nos moveisde uma rede tolerante a atrasos e desconexoes (DTN), servindo de apoio ascomunicacoes. Este artigo analisa o desempenho de diferentes protocolos deroteamento DTN atraves de simulacoes baseadas em tracos reais de voo de umVANT sobre um cenario de desastre natural. Os resultados obtidos permitem ve-rificar os protocolos mais adequados e a relacao custo/benefıcio entre o numerode VANTs e o desempenho da DTN.

1. IntroducaoNo Brasil, de acordo com a base de dados internacional de desastres, encontrada em[EM-DAT 2012], os desastres mais recorrentes desde 1900 sao as inundacoes, causadasprincipalmente por fortes chuvas, e em seguida os deslizamentos de terra, geralmentedecorrentes dessas inundacoes. Especificamente no Estado do Rio de Janeiro, principal-mente no perıodo compreendido entre os meses de Janeiro e Fevereiro, existem diversasareas com nıveis pluviometricos altos, o que invariavelmente leva a situacoes de enchentee alagamento. Estradas interditadas, pontes destruıdas, casas parcial ou integralmente so-terradas ou inundadas - esses sao alguns dos resultados decorrentes do cenario catastroficoque se abate sobre essa regiao nesta epoca do ano. Em meio a este cenario caotico, exis-tem as equipes de socorro e resgate que precisam estar em constante comunicacao com asbases de comando que coordenam estas operacoes.

Tradicionalmente, toda a comunicacao entre as equipes de resgate e o centro decomando, assim como entre as equipes em si, ocorre de forma verbal com o auxılio deequipamentos de radiocomunicacao nas faixas de VHF e UHF. Entretanto, na ocorrencia


163

de obstaculos geograficos ou por dificuldades na instalacao de antenas para a transmissaodo sinal de radio, nem sempre esta comunicacao e eficaz. Nestes cenarios, a utilizacaode uma rede tolerante a atrasos e desconexoes (delay/disruption tolerant network - DTN)[Warthman 2003, Venkataraman et al. 2009], adaptada para trabalhar com nos moveis,pode ser uma importante estrutura de apoio as equipes de socorro. Uma DTN e um tipode rede sem fio na qual nao se exige conectividade fim-a-fim e que sao caracterizadaspor atrasos, longos ou variaveis, no encaminhamento das mensagens, ou ainda pela in-termitencia das conexoes. Como a superacao de obstaculos geograficos pela via aerea eclaramente uma forma mais rapida de se atingir locais isolados por desastres naturais, osVeıculos Aereos Nao-Tripulaveis (VANTs) surgem como uma vantajosa opcao para usocomo nos moveis desta DTN.

Os VANTs, como o proprio nome diz, sao veıculos aereos que podem ser contro-lados de forma remota, por um operador, ou terem seu percurso pre-programado. Essesveıculos podem ser classificados em 5 categorias basicas [Sarris 2001], as quais englo-bam tanto as aeronaves de asa fixa (avioes e planadores) quanto as de asas rotativas (he-licopteros e girocopteros), e as que nao se enquadram exatamente em nenhuma dessascategorias (quadricopteros, foguetes e baloes). Equipando-se os VANTs para que estes secomportem como nos moveis de uma DTN, conquista-se uma ampla capacidade de mo-bilidade que propicia o estabelecimento de uma comunicacao de dados entre os VANTse entre estes e os nos terrestres, como as equipes de busca e/ou resgate e o centro de co-mando. Alem disso, este tipo de comunicacao potencializa a troca de informacoes entreequipes e centro de comando, uma vez que permite o envio de imagens e outros tipos dedados.

Devido as caracterısticas de intermitencia nas conexoes entre os nos de uma DTN,juntamente com a posssıvel mobilidade dos mesmos, foram propostos diversos protoco-los de roteamento que contemplam as necessidades genericas de uma DTN. Estes pro-tocolos sao baseados no envio, armazenamento e repasse de mensagens, com diferentesestrategias para cada etapa. Estas estrategias almejam melhorar diferentes aspectos rela-cionados ao desempenho e a eficiencia na entrega de mensagens, sendo que estes fatorespodem variar bastante de acordo com o cenario de uso e a rede em si.

Assim sendo, o objetivo deste artigo e investigar o desempenho dos principaisprotocolos de roteamento DTN quando aplicados a uma rede formada por VANTs e nosterrestres, com finalidade de apoiar as operacoes de socorro em cenarios de desastres na-turais. Para tal, foram coletados dados reais de voos realizados com um VANT do tipo asavoadora numa trajetoria pre-programada para cobrir quatro zonas de interesse e o localdo centro de comando das operacoes de socorro relativas a uma enchente em Janeiro de2013 no distrito de Xerem, municıpio de Duque de Caxias (RJ). A partir destes dados,foram realizadas simulacoes variando o numero de equipes nas zonas de interesse e onumero de VANTs. Os protocolos utilizados nas analises foram o Epidemic, o Prophet,o Spray and Wait e o Maxprop, por serem os mais popularmente adotados em trabalhosligados a DTN. O desempenho dos mesmos foi analisado com base na fracao de mensa-gens entregues, latencia e overhead na entrega de mensagens. Pelos resultados obtidos,e possıvel verificar os protocolos mais adequados para este tipo de cenario e a relacaocusto/benefıcio entre numero de VANTs e a melhora no desempenho da DTN.

O restante do texto esta organizado da seguinte forma: a Secao 2 apresenta os


164

trabalhos relacionados; a Secao 3 descreve brevemente os protocolos de roteamento DTNa serem analisados; a Secao 4 descreve o prototipo e o cenario utilizado para a coleta dedados; a Secao 5 detalha as simulacoes realizadas; a Secao 6 apresenta os resultados; forfim, a Secao 7 traz a conclusao e trabalhos futuros.

2. Trabalhos relacionados

Historicamente a comunicacao entre as equipes de socorro e destas com o centro decontrole se da pela utilizacao de radios na faixa de VHF/UHF, que operam no sistemahalf-duplex, ou seja, apenas um fala de cada vez enquanto o(s) outro(s) escuta(m). Noentanto, novas tecnologias de comunicacao para auxiliar nesses cenarios vem sendo pro-postas, como em [Dilmaghani and Rao 2008], onde uma infraestrutura de comunicacaobaseada em redes mesh e proposta para ser implementada nesse tipo de cenario. Em[Braunstein et al. 2006] e proposta uma nova arquitetura de rede sem fio hıbrida e dis-tribuıda para auxiliar as equipes de emergencia de forma escalavel. Baseia-se em umaestrutura do tipo mesh para prover conectividade entre os nos e dos nos para o mundo(Internet). Um dos problemas dessas solucoes e a necessidade de instalacao de pontosinfraestruturados, o que nem sempre e possıvel em virtude das limitacoes da area do de-sastre.

Uma solucao interessante apresentada em [Dilmaghani and Rao 2008] e autilizacao de tiers, ou nıveis, para separar os diversos tipos de conexoes entre disposi-tivos. Em um nıvel temos clientes utilizando PDAs, notebooks e iTAGs (por exemplo,etiquetas RFID). Em outro nıvel temos nos mesh e um terceiro nıvel links prove conexaoa Internet. Embora essa solucao tambem precise de nos infraestruturados no segundonıvel, uma vez que a solucao e separada em nıveis existe a possibilidade de substituira tecnologia utilizada neste nıvel por uma solucao mais adequada para um ambiente dedesastre. O trabalho em [Yarali et al. 2009] tambem propoe redes mesh como solucaode conectividade em cenarios de emergencia. No entanto, se os roteadores e gatewaysnao puderem contar com fontes de energia capazes de alimenta-los por longos perıodos,eventualmente alguns desses equipamentos poderao ficar inoperantes, comprometendo aconectividade.

Um algoritmo hierarquico para DTN e proposto em [Mota et al. 2009] com o in-tuito de suprir eventuais carencias de infraestrutura numa rede de comunicacao. Essealgoritmo objetiva aumentar a taxa de entrega de dados em redes intermitentes sem afetaro overhead de comunicacao da rede. Em [Jiang et al. 2011] e proposta uma forma de uti-lizar DTNs para auxiliar vıtimas numa situacao de emergencia. A proposta e a de que oscelulares das vıtimas sejam utilizados como nos em uma rede oportunıstica que se vale deum protocolo Epidemic modificado para este fim. Neste contexto, um cenario hipoteticode incendio em um predio de tres andares e explorado em [Gelenbe and Gorbil 2012],onde e verificada a resiliencia em caso de falhas de alguns dos nos moveis.

Durante um desastre, a percepcao da situacao ou o entendimento da gravidade eextensao da situacao de emergencia e um fator critico para minimizar o numero de feridos,mortos e danos a propriedades. Em [Fall et al. 2010] e proposta uma arquitetura tolerantea desconexoes na qual as pessoas comuns, envolvidas diretamente com a situacao dedesastre ou nao, possam fornecer informacoes como texto, imagens etc as equipes deapoio e resgate. Para isso, basta que essas pessoas estejam proximas de um outro no da


165

rede capaz de encaminhar as mensagens, o que nem sempre e viavel.

Em [Sivakumar and Tan 2010] e proposto um mecanismo de controle para permi-tir o voo em formacao de varios VANTs, com o objetivo de utilizar esses VANTs comobackbone para conectar eventuais nos moveis em terra ao redor de uma area especıficaonde haja equipes de resgate ou sobreviventes. Entretanto, neste trabalho nao e inves-tigado o desempenho dos protocolos de roteamento. Em [Martin Campillo et al. 2012]apresenta-se um estudo do desempenho de alguns protocolos de redes DTN para cenariosde emergencia. O estudo considera que os nos estarao se deslocando da area do incidentepara a area onde sera feita a triagem das vıtimas, trocando mensagens entre si nessasregioes e no caminho de uma regiao para outra. Entretanto, nao e considerado o uso deVANTs.

3. Protocolos de Roteamento DTN

A DTN e um tipo de rede que funciona diferentemente das redes ad hoc, pois nao neces-sita que exista um caminho ou rota fim-a-fim para a entrega de mensagens. Essas redesaproveitam-se de contatos oportunısticos para tentar prover conectividade, mesmo quecom atrasos ou interrupcoes, a outros nos que, de outra forma, estariam completamentedesconectados do restante da rede. Para isso elas utilizam-se de uma tecnica denominadaarmazena-transporta-encaminha (store-carry-forward), onde os nos da rede podem arma-zenar a mensagem e a transportar ate que esta possa ser entregue ao seu destinatario ouencaminhada para outro no com o mesmo objetivo. Os protocolos convencionais de redesad hoc, focados em situacoes onde os nos agem como roteadores, falham ao estabelecerrotas em DTNs. Portanto, as redes DTN precisam de protocolos especıficos para o seumodo de funcionamento. Dentre os mais conhecidos, estao o Epidemic, o Maxprop, oSpray and Wait e o Prophet. Estes sao os protocolos usados nas simulacoes realizadas nocontexto deste trabalho.

O protocolo Epidemic[Vahdat and Becker 2000] tenta disseminar copias das men-sagens por toda a rede, ou seja, todos os nos podem estar transportando a mensagem ecada no, ao encontrar com o outro no da rede, apenas troca as mensagens que eles nao temem seus buffers de memoria. Essa tecnica de disseminacao garante uma alta toleranciaa falhas de nos na rede, garantindo um numero suficiente de trocas de mensagens entretodos os nos da rede e, eventualmente, recebendo as mensagens em um curto perıodo detempo. Esta abordagem nao requer informacoes sobre topologia da rede, entretanto osrecursos da rede podem ser consumidos de forma bastante voraz.

O Protocolo Maxprop[Burgess et al. 2006] foi desenvolvido na universidade deMassachusetts e define uma ordem de prioridade na fila dos pacotes. Os pacotes queprecisam ser descartados e aqueles que precisam ser transmitidos sao entao classificadosde acordo com essa prioridade. A prioridade dos pacotes e baseada na probabilidade deentrega ao no de destino de acordo com dados historicos e outros mecanismos auxiliares,tais como uma lista de nos intermediarios, notificacoes de recebimento e novos pacotes,que sao priorizados em detrimento de pacotes mais antigos. Diversos metodos podemser utilizados para definir essa prioridade, incluindo a taxa de sucesso na definicao de umdeterminado caminho para um determinado no ou a quantidade de tentativas bem sucedi-das de entrega de mensagem de um determinado no para outro. Essa tecnica melhora, demaneira geral, a taxa de entrega de mensagens.


166

O protocolo Spray and Wait[Spyropoulos et al. 2005] combina a rapidez do rote-amento Epidemic com a simplicidade da entrega direta. De forma a utilizar eficientementeos recursos da rede, este protocolo define um limite N, dado pelo parametro L de ajuste doprotocolo, para o numero de copias de mensagens sendo replicadas na rede. O protocoloopera em duas fases distintas: a fase disseminar (spray) e a fase de espera (wait). Juntocom cada mensagem e enviado um indicador do numero maximo de copias desta mensa-gem. Durante a fase disseminar, N copias sao disseminadas na rede de forma epidemicae, quando um numero suficiente de copias foi disseminado para garantir que pelo menosum deles ira chegar ao destino, de forma rapida esta fase e encerrada. Os nos que tenhamrecebido uma copia da mensagem a mantem armazenada e passam para a fase de espera,na qual cada no carregando uma copia da mensagem ira tentar entregar a mensagem deforma direta.

O protocolo Prophet[Lindgren et al. 2003] parte da premissa de que o encontrodos nos de uma rede raramente ocorre de forma totalmente aleatoria. Operando de formaprobabilıstica, este protocolo estima uma metrica chamada previsao de entrega. Essametrica indica a probabilidade de sucesso em entregar uma mensagem a um determinadono de destino a partir de um outro no de origem. O protocolo Prophet trabalha de formaque, quando dois nos se encontram, eles trocam um vetor de informacao contendo umaprevisao probabilıstica de entrega. Teoricamente, se dois nos se encontram frequente-mente eles tem alta probabilidade de entrega entre eles, entretanto, se um determinadopar de nos nao se encontram por um longo tempo, eles nao sao bons para encaminharmensagem entre eles, ou seja, a probabilidade de entrega entre eles tende a ser menor. Aoapresentar um comportamento probabilıstico de encontros entre nos encaminhando men-sagens somente para os nos que tem mais probabilidade de encontrar com o no de destino,este protocolo consegue diminuir a inundacao de pacotes de mensagens na rede e, conse-quentemente, diminuir o consumo de recursos, como buffer de mensagens e banda.

4. Cenario Investigado e Obtencao de Dados Reais

Em Janeiro de 2013, uma sobrecarga de chuvas causou enchentes e deslizamentos naregiao do distrito de Xerem, em Duque de Caxias (RJ). Apos a relativa normalizacao doacesso a esta regiao, o local foi visitado com a finalidade de se obter dados realısticospara apoiar o estudo sobre o uso de VANTs numa DTN de apoio as atividades de busca eresgate realizadas neste cenario.

A coleta de dados se deu a partir do sobrevoo de um VANT sobre um circuitodefinido com base nas areas crıticas apontadas pela defesa civil. Com base nesses dados,foi possivel elaborar o mapa da Figura 1, onde as linhas circulares cheias indicam as zonasde interesse e o local do centro de comando, enquanto a linha tracejada indica a regiaolimıtrofe usada na definicao da trajetoria do VANT. O tracado de voo envolve um cirtuitoonde o VANT sai do centro de comando (CC), atinge os pontos de interesse na sequenciaA, B, C e D, e retorna diretamente para o CC, quando entao o ciclo e reiniciado. A partirdeste voo, foram obtidas as informacoes utilizadas na simulacao.

A peculiaridade deste cenario e que os pontos de interesse encontram-se dis-tribuıdos de forma tal que um VANT tem contato com cada ponto apenas uma vez du-rante o percurso do circuito. Devido a isto, equipes localizadas nestes pontos tendem aapresentar um tempo maior de desconexao com os VANTs, o que influencia diretamente


167

Figura 1. Cenario de Xerem.

na conectividade e no desempenho da DTN a ser simulada.

Durante o perıodo do desastre, os pontos de interesse apresentaram acesso muitorestrito, pois se tratavam de areas que ficaram inundadas e sob forte correnteza. Assimsendo, as equipes e as vitimas encontraram-se ilhadas nestes pontos, necessitando doauxilio de botes para se locomoverem entre regioes. O acesso ao centro de comandotambem ficou difıcil a partir destes pontos. As equipes de resgate que estiveram atendendovitimas em cada um dos pontos de interesse tiveram sua mobilidade restrita a poucas ruasdentro dessas respectivas areas. Os VANTs, portanto, teriam sido os unicos nos queconseguiriam atingir todos os pontos de interesse e o centro de comando, mesmo apos aestiagem das chuvas fortes.

Sobre cada ponto de interesse apontados no mapa, e tambem sobre o CC, o VANTusado para coleta de dados realizou tres voltas de cerca de 50 metros de raio, dando assimtempo para que mensagens pudessem ser enviadas ou recebidas do VANT.

4.1. Prototipo de VANT utilizado

Os VANTs do tipo asa voadora, ou Zagi, e os planadores, pelas suas caracterısticas degrande autonomia, facilidade de manuseio e velocidade de voo, dentre outras, sao osmais indicados para uso em cenarios de desastre. Em especial, as asas voadoras, pornao necessitarem de pista para sua decolagem e aterrissagem, tornam-se extremamenteversateis e praticas para serem utilizadas nestes ambientes. Por este motivo, fez-se usodeste tipo de VANT para a obtencao dos dados a serem inseridos no simulador.

Foi montado um prototipo composto por uma asa Zagi contendo bussola digital,acelerometros, controle de altitude, GPS e sistema de piloto automatico. A Figura 2 mos-tra o prototipo desenvolvido. A asa foi idealizada tomando como referencia o manualde construcao de asas voadoras[Nogueira 2008] e utilizou um perfil MH5, com com-primento total de 1,60 metros e chapas de madeira balsa, que e um tipo de madeirabastante resistente e extremamente leve. As superfıcies de comando da asa tem suaatuacao efetivada por dois servo-comandos, um em cada lado da asa, da marca Tower-pro. Como propulsao foi utilizado um motor eletrico sem escovas da marca Turnigyde 750 KV. O revestimento foi realizado com fita de empacotamento comum nas corespreto, amarelo e branco. Este tipo de construcao torna o VANT extremamente estavelem voo, facilmente controlavel e bastante resistente a impactos. Como sistema de pi-


168

loto automatico, para permitir voos programados, foi utilizado o sistema de codigo abertoArdupilot [Sivakumar and Tan 2010] em sua configuracao basica, sem alteracoes em seufirmware. A energia necessaria para o funcionamento de todo esse equipamento e for-necida por uma bateria de Lithium-Polımero de 2200 mAh, que permite uma autonomiade voo de cerca de 30 minutos. Baterias de maior capacidade podem ser utilizadas paraautonomias maiores, podendo ser conseguido tempos de voo de 2 horas ou mais.

Este prototipo VANT foi concebido para suportar ventos fortes em regioes li-toraneas e, impermeabilizando as partes eletronicas, pode ser usado com chuvas. VANTsde asa rotativa sao uteis p/restricao de mobilidade, mas os de asa fixa tem mais robusteze autonomia, e estabilizadores de imagem melhoram a qualidade do que e filmado. EsteVANT pode atingir 1000 metros de altura, mas acima de 500 metros ha perigo para aaviacao civil. Vale notar que consideramos usar o VANT apos estiagem ou reducao dachuva, momento no qual se costumam iniciar as buscas.

Figura 2. O Prototipo de VANT desenvolvido.

As rotas de voo a serem realizadas pelo VANT sao programadas atraves do apli-cativo desenvolvido pela equipe de desenvolvimento do Ardupilot, rodando em um no-tebook convencional. A conexao entre o notebook e o sistema de piloto automatico erealizada atraves de um link de telemetria composto de radios Xbee, operando na faixade 900MHz, e antenas omnidirecionais de 3 dbi o que, segundo o fabricante, garantemum alcance em campo aberto de cerca de 1,6 km. Esta distancia e para leitura de tele-metria e reprogramacao em tempo real, porem o VANT realizara o percurso programadoindependente de alcance.

5. Etapa de SimulacaoPara simular o cenario pretendido, foi utilizado o simulador THE ONE [Keranen 2008].Os mapas da regiao estudada foram importados para o simulador no formato WKT. Paracada elemento da simulacao, ou seja, nos terrestres e nos VANT, foi necessaria a criacaode um mapa especıfico uma vez que cada um possui suas proprias caracteristicas de mo-bilidade. Os nos terrestres ficam agrupados em torno dos pontos de interesse, onde cadaponto de interesse apresenta limites de mobilidade correspondentes as estradas da regiaoque estavam desobstruıdas. Portanto, para cada ponto de interesse foi criado um mapacomposto apenas por estas ruas e estradas. Os mapas criados para os VANTs definemo trajeto percorrido por eles, porem cada VANT tem sua propria posicao inicial de voo.Para a geracao desses mapas foi utilizado o sofware Openjump, que permite a importacao


169

de mapas reais como camada de fundo, o que facilita a criacao de mapas de mobilidadena ferramenta.

Observou-se durante os testes de campo que a velocidade do VANT variou de 34 a38 km/h. Nas simulacoes, os VANTs voam a uma velocidade constante de 36 km/h, que ea velocidade media mınima na qual um VANT real, do tipo que foi construıdo, conseguemanter-se em voo constante sem que haja perda de altitude ou tempos de parada. Onumero de VANTs variou de zero, para que tivessemos um controle de como a rede secomporta sem o auxılio dos nos moveis, ate o valor de seis VANTs. A partir do momentoque temos dois VANTs no cenario, estes partem de posicoes iniciais distintas, de maneiraque um VANT esteja metade do percurso a frente do outro. Com tres VANTs, o mesmoprocedimento e adotado, porem dividindo-se o percurso total em tres partes. Com quatro,cinco e seis VANTs a mesma logica e estabelecida, porem estes novos VANTs realizaraoo percurso no sentido inverso, o que propiciara conexoes entre VANTs durante o voo.

O deslocamento das equipes ocorre de forma aleatoria ao longo das estradas eruas, porem restrito aos caminhos possıveis dentro do ponto de interesse a que estao con-finados. A velocidade media vai de 0,5 a 1,5 m/s, para simular as dificuldades encontradasno deslocamento das equipes. Foram incorporados tambem momentos aleatorios de pa-rada com tempo variando de 30 a 360 segundos, simulando buscas mais minuciosas emdeterminado momento ou o efetivo resgate de algum sobrevivente. O numero de nos re-presentando as equipes ou pessoas nas zonas de interesse foi variado em 12, 20 e 32 nos,sendo que cada ponto de interesse possui um mesmo numero de nos. O CC foi mantidonuma mesma posicao fixa em todas as rodadas de simulacao realizadas.

Com relacao ao ambiente de rede sem fio, para todos os nos foram utilizadosenlaces de radio WiFi configurados para um alcance de 100 metros e capacidade de trans-missao de 5 Mbps.

As mensagens que circulam na rede foram geradas a intervalos de 30 segundoscom tamanho fixo de 200 KB, o que pode representar uma troca de mensagens contendoarquivos de texto ou imagens. As mensagens podem ser geradas em qualquer no com des-tino para qualquer outro no, exceto os VANTs, os quais nao geram nem recebem mensa-gens, apenas as encaminham. As mensagens geradas foram agrupadas da seguinte forma:(i) mensagens geradas de um no qualquer com destino a outro no qualquer, incluindoo centro de comando; (ii) mensagens geradas de um no qualquer com destino a outrono qualquer, exceto o centro de comando; e (iii) mensagens geradas de um no qualquerexclusivamente com destino ao centro de comando.

Como citado antes, os protocolos de roteamento DTN escolhidos para analiseforam o Epidemic, o Prophet, o Spray and Wait e o Maxprop. No caso do Spray andWait, o numero de copias usado foi 6, que e um valor padrao. Estes protocolos foramescolhidos por serem os mais populares dentre aqueles que priorizam rapidez na entregade mensagens. Foram efetuadas 10 rodadas de simulacao para cada protocolo em cadacenario de simulacao, com tempo simulado de 7200 segundos para cada rodada, o querepresenta a autonomia de voo do VANT. Para cada caso, foram coletadas as seguintesmedidas: atraso medio para entrega das mensagens, fracao de mensagens entregues eoverhead do numero de mensagens. O intervalo de confianca adotado foi de 95%, obtidoa partir da tabela de referencia t-student, considerando 10 rodadas.


170

O atraso medio para entrega corresponde a media dos tempos de entrega de todasas mensagens que tenham chegado a seu destino. A fracao de mensagens entregues cor-responde a razao entre o total de mensagens entregues e o total de mensagens geradas.Ja o overhead do numero de mensagens corresponde ao numero adicional de mensagensgeradas por mensagem entregue. Seja TMT o total de mensagens transmitidas e TMEo total de mensagens entregues, o overhead e calculado por TMT−TME

TME.

E interessante notar que, em um cenario de emergencia, o overhead de mensagens,ou seja, a quantidade de copias de mensagens geradas numa DTN, pode ser consideradauma metrica de menor importancia uma vez que e mais urgente que as mensagens sejamentregues em seus destinos no menor tempo possıvel. Entretanto, para entender o desem-penho geral dos protocolos nos cenarios simulados, o overhead foi tambem analisado.

Os buffers dos nos foram superdimensionados de forma a evitar a perda de men-sagens, pois entende-se que isto seria inadequado num cenario de emergencia.

6. Resultados Obtidos

Figura 3. Fracao de mensagens entregues.

(a) (b) (c)

A Figura 3 apresenta a fracao de mensagens entregues no cenario com 20 nosterrestres para cada agrupamento de mensagens: (a) mensagens entre todos os nos, inclu-sive CC; (b) mensagens entre todos os nos, menos CC; e (c) mensagens entre os nos e oCC. Como podemos observar, a fracao de mensagens entregues na rede, para a maioriados protocolos, tende a 100% desde que haja pelo menos um VANT circulando. Esseresultado pode ser explicado pela forma cıclica com que os VANTs percorrem a regiao epelo tamanho do buffer utilizado nos nos, tendendo a infinito. Os resultados referentes acada protocolo apresentam muito pouca ou nenhuma variacao entre si, independente donumero de nos, excetuando o caso do protocolo spray and wait. Para este protocolo, afracao de entrega tende a um valor mais baixo, em torno de 95%. Este comportamentopode ser explicado pela forma com que o protocolo trabalha. Com o objetivo de dimi-nuir o overhead na rede, o Spray and Wait limita o numero maximo de copias de umamesma mensagem na rede. Uma vez que a escolha dos nos que receberao essas copiasnao considera a existencia de VANTs, e possıvel que algumas mensagens nao consigamser entregues a um VANT.

No caso de quando as mensagens sao geradas tendo o CC exclusivamente comoorigem ou destino, verifica-se que a fracao de pacotes entregues e zero quando nao haVANTs circulando, uma vez que somente os VANTs conseguem alcancar o CC (Figura3).


171

Os resultados para a fracao de mensagens entregues nos cenarios com 12 e 32foram muito similares ao do cenario com 20 nos e tiveram seus graficos omitidos parapoupar espaco.

Figura 4. Atraso medio para entrega de mensagens entre todos os nos.

(a) (b) (c)

Figura 5. Atraso medio para entrega de mensagens entre todos os nos, exceto CC.

(a) (b) (c)

Figura 6. Atraso medio para entrega de mensagens entre CC e qualquer outro no.

(a) (b) (c)

As Figuras 4, 5 e 6 apresentam o atraso medio na entrega de mensagens respec-tivamente para os casos de mensagens entre todos os nos, mensagens entre todos os nosexceto o CC, e mensagens entre o CC e demais nos. Para cada caso, sao mostrados oscenarios com 12, 20 e 32 nos terrestres. De uma forma geral, e possıvel verificar umareducao do atraso a medida que aumenta o numero de VANTs, sendo que esta reducaofica percentualmente menor quanto maior o numero de VANTs, sugerindo que ela tenderaa um valor limite. No caso de zero VANTs, este valor destoa da tendencia encontrada norestante da curva, sendo valores menores quanto maior o numero de nos terrestres. Isto seexplica pelo fato da medida considerar apenas as mensagens entregues, incluindo aquelas


172

entregues entre os nos terrestres em um mesmo ponto de interesse, caso onde o atraso setorna bem pequeno. Quanto o maior o numero de nos terrestres, maior a quantidade demensagens entregues nestes pontos de interesse. No caso da Figura 6, com zero VANTsnao ha mensagem entregue, portanto nao ha valor associado a este numero.

Com relacao ao comportamento por protocolo, o atraso medio do Prophet e doSpray and Wait sao os maiores, com resultado pior no caso do Spray and Wait devidoaos mesmos motivos anteriormente expostos, ou seja, uma vez que existem menos noscapazes de realizar a entrega de determinada mensagem, um tempo maior na entrega eesperado. Mesmo no caso da Figura 6, que considera apenas mensagens entre o CC edemais nos, o Spray and Wait teve um atraso medio um pouco maior, enquanto que todosos demais tiveram resultados muito proximos, inclusive o Prophet. No caso do Prophet,este protocolo possui uma metrica que calcula a probabilidade do encontro entre doisnos e, como os VANTs sao os unicos que se encontram constantemente com o centro decomando, esses passam a ser os nos preferidos para encaminhar mensagens ao CC.

Tanto o protocolo Maxprop quanto o Epidemic apresentaram os menores atrasosmedios em todos os casos. Uma vez que esses protocolos trabalham disseminando men-sagens para quantos nos forem possiveis, essa baixa latencia e esperada.

Figura 7. Overhead de mensagens entre todos os nos.

(a) (b) (c)

Figura 8. Overhead de mensagens entre todos os nos, exceto CC.

(a) (b) (c)

As Figuras 7, 9 e 8 apresentam o overhead medio de mensagens respectivamentepara os casos de mensagens entre todos os nos, mensagens entre todos os nos exceto o CC,e mensagens entre o CC e demais nos. Assim como antes, para cada caso, sao mostradosos cenarios com 12, 20 e 32 nos terrestres. E possıvel verificar que o Spray and Waitteve o menor valor em todos os casos, o que era de se esperar devido a seu mecanismo de


173

Figura 9. Overhead de mensagens entre CC e demais nos.

(a) (b) (c)

controle de mensagens na rede. Entretanto, deve-se recordar que a fracao de mensagensentregues e o atraso medio ficam comprometidos por conta deste mecanismo.

Em situacao oposta, o protocolo Maxprop apresentou os maiores valores deoverhead, crescendo substancialmente com o aumento do numero de nos terrestres. Istoocorre porque este protocolo gera uma certa quantidade de mensagens de controle junta-mente com a mensagem que esta tentando entregar, o que torna seu overhead maior queo do proprio Epidemic. Os protocolos Epidemic e Prophet tem resultados semelhantes,com o Epidemic apresentando valores de overhead levemente maiores que os do Prophet.Entretanto, pode-se verificar que o overhead do Prophet cresce mais acentuadamente con-forme aumenta o numero de VANTs, se comparado com o Epidemic.

Tabela 1. Tabela comparativa de resultado dos protocolos.

1: Pior caso, 2: Inter-mediario, 3: Melhor caso

Fracao de mensa-gens entregues

Overhead Atrasomedio

Total

Epidemic 3 2 3 8Maxprop 3 1 3 7Prophet 3 2 1 6Spray and Wait 1 3 1 5

A Tabela 1 apresenta um sumario dos resultados de cada metrica para cada proto-colo. De maneira a auxiliar na comparacao, foi atribuıda uma pontuacao de 1, 2 e 3 paraos casos onde a metrica associada a determinado protocolo apresenta o pior desempenho,um desempenho intermediario ou o melhor desempenho, respectivamente. Somando-setodos os pontos, espera-se visualizar qual protocolo apresentou o melhor desempenhono aspecto geral. Podemos observar que o protocolo Epidemic apresentou os melhoresresultados para o cenario aqui analisado, seguido de perto pelo protocolo Maxprop querecebeu uma pontuacao pior devido ao seu overhead. Desconsiderando-se esta metrica,que pode ter pouca relevancia no contexto de cenarios de emergencia, ambos tem desem-penho equivalente.

Outra observacao relevante e quanto ao numero de VANTs e sua relacao com amelhora do desempenho na entrega de mensagens para o cenario estudado. Pelos resulta-dos apresentados, fica claro que a metrica mais determinante para esta analise e o atrasomedio, ja que a fracao de mensagens entregues e praticamente 100% para quase todos


174

os casos, uma vez que se tenha ao menos um VANT circulando, e que o overhead va-riou pouco com o aumento do numero de VANTs no caso do Epidemic. Sendo assim,e possıvel verificar que, no caso do Epidemic, a partir do uso de dois VANTs a reducaodo atraso passa a ser muito pequena, o que tambem e verificado nos demais protocolos.Conclui-se portanto que, para o cenario estudado, bastam dois VANTs para se obter umdesempenho relativamente proximo do otimo na entrega de mensagens pela DTN.

7. ConclusaoOs cenarios de desastre podem apresentar caracterısticas que dificultam o uso de tecno-logias tradicionais de comunicacao pelas equipes de resgate. Alem disso, dependendo docenario, a mobilidade das equipes tambem pode ficar comprometida, a ponto de nao serpossıvel a locomocao dessas equipes ate o centro de comando. Neste contexto, o uso deVANTS se apresenta como uma opcao vantajosa para cenarios de emergencia, podendoservir como nos moveis na composicao de uma DTN para apoio na comunicacao com asequipes de resgate.

Este trabalho analisou o desempenho de uma rede DTN formada por nos moveis,dentre os quais VANTs, para uso em cenarios de emergencia. As simulacoes realizadas sebasearam em dados realistas coletados a partir de um prototipo de VANT que sobrevoou asareas crıticas que foram afetadas por uma enchente ocorrida em Janeiro de 2013 no distritode Xerem, em Duque de Caxias (RJ). Foram comparados quatro conhecidos protocolos deroteamento DTN segundo as metricas de fracao de entrega de mensagens, atraso medio daentrega e overhead de mensagens. Constatou-se que o protocolo Epidemic se apresentoucomo melhor opcao e que bastam dois VANTs circulando para se obter um desempenhoproximo do otimo no cenario estudado.

Como trabalho futuro, pretende-se utilizar os conhecimentos adquiridos no desen-volvimento de um protocolo de roteamento DTN usando nos moveis que seja otimizadopara cenarios de emergencia, privilegiando os VANTs como nos de encaminhamento demensagens. Alem disso, outros tipos de VANTs deverao ser experimentados de formaconjunta, como por exemplo, baloes.

ReferenciasBraunstein, B., Trimble, T., Mishra, R., Manoj, B., Lenert, L., and Rao, R. (2006). Chal-

lenges in using distributed wireless mesh networks in emergency response. In Procee-dings of the 3rd International ISCRAM Conference, pages 30–38.

Burgess, J., Gallagher, B., Jensen, D., and Levine, B. N. (2006). Maxprop: Routing forvehicle-based disruption-tolerant networks. In Proc. ieee infocom, volume 6, pages1–11. Barcelona, Spain.

Dilmaghani, R. B. and Rao, R. R. (2008). A wireless mesh infrastructure deploymentwith application for emergency scenarios. In 5th International ISCRAM Conference.

EM-DAT (2012). International disaster database. http://www.emdat.be/database/. Aces-sado em: 14 dez. 2013.

Fall, K., Iannaccone, G., Kannan, J., Silveira, F., and Taft, N. (2010). A disruption-tolerantarchitecture for secure and efficient disaster response communications. Proceedings ofISCRAM.


175

Gelenbe, E. and Gorbil, G. (2012). Wireless networks in emergency management. In Pro-ceedings of the first ACM international workshop on Practical issues and applicationsin next generation wireless networks, pages 1–6. ACM.

Jiang, P., Bigham, J., and Bodanese, E. (2011). Adaptive service provisioning for emer-gency communications with dtn. In Wireless Communications and Networking Confe-rence (WCNC), 2011 IEEE, pages 2125–2130. IEEE.

Keranen, A. (2008). Opportunistic network environment simulator. Special Assign-ment report, Helsinki University of Technology, Department of Communications andNetworking.

Lindgren, A., Doria, A., and Schelen, O. (2003). Probabilistic routing in intermitten-tly connected networks. ACM SIGMOBILE Mobile Computing and CommunicationsReview, 7(3):19–20.

Martin Campillo, A., Crowcroft, J., Yoneki, E., and Marti, R. (2012). Evaluating opportu-nistic networks in disaster scenarios. Journal of Network and Computer Applications.

Mota, V. F., Silva, T. H., and Nogueira, J. M. S. (2009). Introduzindo tolerancia ainterrupcao em redes ad hoc moveis para cenarios de emergencia. Simposio Brasi-leiro de Redes de Computadores e Sistemas Distribuidos (SBRC), Recife, PE, Brasil.

Nogueira, R. (2008). Manual basico para construcao de zagis (asas voadoras).http://www.spsafe.com.br/downloads/manualzagi.pdf. Acessado em: 14 dez. 2013.

Sarris, Zak, S. (2001). Survey of uav applications in civil markets (june 2001). In The 9th IEEE Mediterranean Conference on Control and Automation (MED’01).

Sivakumar, A. and Tan, C. K.-Y. (2010). Uav swarm coordination using cooperativecontrol for establishing a wireless communications backbone. In Proceedings of the9th International Conference on Autonomous Agents and Multiagent Systems: volume3-Volume 3, pages 1157–1164. International Foundation for Autonomous Agents andMultiagent Systems.

Spyropoulos, T., Psounis, K., and Raghavendra, C. S. (2005). Spray and wait: an effici-ent routing scheme for intermittently connected mobile networks. In Proceedings ofthe 2005 ACM SIGCOMM workshop on Delay-tolerant networking, pages 252–259.ACM.

Vahdat, A. and Becker, D. (2000). Epidemic routing for partially-connected ad hocnetworks. Technical Report CS-2000-06, Duke University.

Venkataraman, V., Acharya, H. B., Shah, H., and Lam, S. (2009). Delay tolerantnetworking-a tutorial. Department of Computer Science, The University of Texas.

Warthman, F. (2003). Delay tolerant networks (dtns): A tutorial, dtn research group.Technical report, Internet Draft.

Yarali, A., Ahsant, B., and Rahman, S. (2009). Wireless mesh networking: A key solutionfor emergency and rural applications. In Advances in Mesh Networks, 2009. MESH2009. Second International Conference on, pages 143–149. IEEE.


176

Protocolo Adaptativo de Disseminação de Dados para Aplicações de Segurança no Trânsito em Rodovias

Renê Oliveira1, Carlos Montez1, Michelle Wangham2

1 Programa de Pós-Graduação em Engenharia de Automação e Sistemas (UFSC) 2 Programa de Mestrado em Computação Aplicada – Universidade do Vale do

Itajaí (UNIVALI)

[email protected], [email protected], [email protected]

Abstract. In vehicular networks, cooperation between nodes is needed for proper performance of traffic applications. This work aims to provide reliability to message transmission in safety traffic applications through an adaptive protocol. The effectiveness and the efficiency of the proposed protocol and the impacts of the use of the protocol by a LDW (Local Danger Warnings) application for highways were evaluated through experiments with network and traffic simulators.

Resumo. Nas redes veiculares, a cooperação entre os nós se faz necessária para um desempenho adequado das aplicações de segurança no trânsito. Este trabalho tem por objetivo prover confiabilidade na disseminação de mensagens em aplicações voltadas à segurança no trânsito por meio de um protocolo adaptativo. A eficácia e eficiência do protocolo proposto e os impactos decorrentes do uso do protocolo por uma aplicação LDW (Local Danger Warnings) para rodovias foram avaliados por meio de experimentos realizados com simuladores de rede e de tráfego.

1. Introdução

As VANETs (Vehicular Ad Hoc Networks) têm como objetivo melhorar as condições de circulação dos tráfegos urbanos e rodoviários de forma segura e eficiente e garantir a comunicação entre os diversos usuários móveis inseridos na rede. Este cenário consiste de veículos atuando como roteadores móveis, com o objetivo de enviar, receber, armazenar e encaminhar os pacotes pela rede [Ostermaier et al. 2007]. Segundo Lee et al. (2008), um dos principais estímulos para as redes veiculares é o desejo de aumentar ainda mais a segurança em ruas e rodovias melhorando também a eficiência do tráfego, utilizando-se da comunicação entre os veículos. Dentre as aplicações, destacam-se as de alerta de perigo local (LDW – Local Danger Warnings) devido ao significativo benefício coletivo trazido pela disseminação de mensagens que informam situações de risco nas vias, como por exemplo, a presença de óleo na pista.

Em uma aplicação LDW, a cada evento detectado é gerado um alerta informando sua condição. Cada receptor desses dados atua como roteador da mensagem, aumentando assim o alcance deste aviso. Além disso, em uma aplicação LDW, os nós avaliam o conteúdo dos alertas recebidos. Toda vez que a aplicação considerar suficiente as evidências de um evento, esta fará uso da interface com o motorista para comunicá-lo da existência do problema [Kosch 2004]. Neste contexto, um problema descrito em trabalhos sobre aplicações voltadas a segurança no trânsito que utilizam redes veiculares é a falta de garantias da entrega de mensagens de uma única fonte para cada nó em seu raio de cobertura (confiabilidade) com atraso mínimo [Bernsen 2009].


177

Para prover confiabilidade da entrega de mensagens em VANETs, deve-se mitigar problemas encontrados em protocolos de disseminação confiável [Nagaraj 2011], [Kamoltham 2011], [Chuan 2012] e [Ros 2009]. Dentre estes problemas, destacam-se: nó oculto, broadcast storm, alta latência e adaptabilidade diante de cenários com densidade de veículos variada. Este artigo tem por objetivo descrever um protocolo adaptativo que provê confiabilidade na disseminação de mensagens em aplicações voltadas a segurança no trânsito. Para avaliar a eficácia e eficiência do protocolo proposto e os possíveis impactos do seu uso em uma aplicação LDW para rodovias, foram realizados experimentos com simuladores de rede e tráfego bidirecionalmente acoplados.

Este artigo está organizado em cinco seções. A Seção 2 analisa os trabalhos relacionados selecionados a partir de uma revisão sistemática. Na Seção 3, são apresentadas a visão geral e as premissas do protocolo proposto, o detalhamento do funcionamento do protocolo, bem como a integração deste à aplicação LDW desenvolvida. A Seção 4 apresenta a avaliação do protocolo proposto e os resultados de simulação obtidos em relação à eficácia do protocolo e aos impactos deste sobre a aplicação (eficiência). Por fim, a Seção 5 apresenta as considerações finais e a indicação de trabalhos futuros.


A abordagem tradicional para a difusão de informações é usar protocolos de inundação. Após a recepção de uma mensagem transmitida, o nó retransmite a mensagem imediatamente [Nakorn 2010]. Esta abordagem pode fornecer rapidez à difusão de dados e é simples por não precisar obter informações dos nós vizinhos. No entanto, esta abordagem não funciona bem em áreas densas e em redes esparsas. Áreas que possuem densidade elevada de nós fazem com que o uso da inundação acarrete uma alta quantidade de colisões de pacotes e uma baixa confiabilidade [Koubek 2010]. Em um cenário esparso como as rodovias durante a noite, os veículos movem-se em alta velocidade e, possivelmente, não possuem vizinhos em sua faixa de transmissão. Partindo deste cenário, a inundação pode não atender de forma adequada a rede, pois não existem vizinhos suficientes para que a mensagem seja difundida [Tonguz et al. 2007]. Diante deste contexto, surgem protocolos de difusão, denominados confiáveis, que devem prover uma elevada cobertura, independentemente da densidade da rede, da alta taxa de desconexões ou da velocidade dos veículos (veículos parados ou em alta velocidade) [Nakorn 2010].

No âmbito das redes veiculares, alguns protocolos de difusão foram propostos. Após a execução de um protocolo de busca (revisão sistemática), foram identificados quatro trabalhos que descrevem protocolos de difusão com o objetivo de garantir a entrega confiável de mensagens em VANETs.

O protocolo Edge-Aware Epidemic Protocol (EAEP) [Nagaraj 2011] tem como objetivo tratar o problema da conectividade intermitente existente em protocolos epidêmicos anteriores. Neste protocolo, assume-se que cada veículo conhece sua própria localização geográfica. Cada mensagem contém a posição do veículo fonte e pode também conter um parâmetro que determina se a mensagem deve ser propagada em uma direção específica ou se a propagação é omnidirecional. Esse protocolo supera a técnica de inundação simples em termos de confiabilidade e menor sobrecarga. No entanto, o protocolo acarreta elevado atraso na disseminação das mensagens. De acordo com os autores, em cenários simulados foram preciso mais de 30 segundos para entregar uma única mensagem para a maioria dos veículos presentes na rede.

O protocolo Acknowledged Parameterless Broadcast in Static to Highly Mobile (ackPBSM) [Ros 2009] tem por objetivo controlar a quantidade de mensagens geradas na rede por meio da escolha de grupos com maior prioridade para retransmissão das mensagens (chamados Connected Dominating Set - CDS). Fazem parte destes grupos, veículos de emergência como, por exemplo, ambulâncias. Ao utilizar estes grupos


178

prioritários a disputa do canal é minimizada, desta forma o protocolo não sofre tanto com as colisões em cenários de alta densidade e também evita retransmissões desnecessárias. Ao utilizar o protocolo ackPBSM, os veículos emitem beacons periódicos, a fim de adquirir conhecimento sobre a topologia da rede local. Depois de cada troca, esta informação é utilizada para determinar se o próprio veículo faz ou não parte do CDS. Além disso, os beacons contêm os identificadores das mensagens que tenham sido recebidos recentemente. O protocolo é capaz de alcançar alta confiabilidade, minimizando o número de retransmissões. Porém, por utilizar beacons periódicos em cenários com maiores densidades, o protocolo pode atrasar a entrega das mensagens e também gerar sobrecarga com a utilização das mensagens de confirmação.

O protocolo Density-aware Reliable Broadcasting Protocol (DECA) [Kamoltham 2011] faz uso do método store-and-forward e utiliza beacons periódicos. Veículos que trafegam em vias podem formar grupos, fazendo com que algumas faixas de rodagem tenham maior densidade do que outras faixas da mesma pista. Escolher um veículo que está na área de maior densidade para retransmitir uma mensagem pode maximizar o número de vizinhos que receberão a mensagem por meio de uma única transmissão. Portanto, o protocolo DECA usa informações referentes a densidade local para selecionar o nó que fará a retransmissão seguinte. De acordo com os autores, o protocolo DECA consegue alcançar seu objetivo que é prover confiabilidade e eficiência na transmissão de dados em redes de conectividade intermitente. Porém, o protocolo não se adapta de acordo com a densidade de veículos no cenário, desta forma sobrecarrega a largura de banda utilizada na troca de informações. O DECA pode superar outros protocolos, porém sofre com a utilização de beacons periódicos, que geram sobrecarga na rede em cenários com alta densidade.

No modelo Reliable Broadcast routing based on Gain Prediction (RB-GP) [Chuan 2012], as informações de cada nó que integra a rede estão disponíveis por meio de trocas de beacons ou mensagens curtas periódicos. O principal objetivo do modelo RB-GP é maximizar o raio de cobertura em cada difusão e diminuir os atrasos nas transmissões, que é obtido por meio da seleção do próximo salto mais adequado (maior ganho), considerando todas as direções. Em cenários com baixa e média densidade, o protocolo garante que o nó selecionado pode receber os pacotes com sucesso e, com isso, diminuir o conflito nos canais e as informações retransmitidas de forma desnecessária. Os resultados mostram que o RB-GP é mais eficaz, no que diz respeito a taxa de entrega dos pacotes, e possui atraso médio menor quando comparado a outros modelos que utilizam inundação. Porém, este sofre com o excesso de beacons periódicos em cenários com alta densidade. Os autores deixam claro este problema e o definem como ponto chave a ser resolvido em trabalhos futuros [Chuan 2012].

Tabela1: Comparação dos Trabalhos Relacionados

Trabalhos Beacons Confirmação Lista de Vizinhos

Seleção do Retransmissor

Adaptabilidade

Nagaraj (2011) Não Utiliza Não Sim Direção Não

Ros (2009) Periódicos Sim Sim Prioridade Não

Kamoltham (2011) Periódicos Não Sim Densidade

Local Não

Chuan (2012) Periódicos Não Sim Distância e Densidade

Não

Protocolo Proposto Aperiódicos Não Sim Densidade

Local e Distância

Sim

A Tabela 1 apresenta uma comparação destes protocolos confiáveis, considerando as seguintes características: (1) se utilizam mensagens de controle (beacons) e qual o tipo, periódicas ou aperiódicas; (2) se fazem uso de mensagens de confirmação (ack); (3) se


179

armazenam informações sobre a vizinhança por meio de listas de vizinhos; (4) qual a forma utilizada para selecionar o nó retransmissor a cada salto; e (5) se a abordagem se adapta às condições dos cenários. O protocolo proposto neste trabalho e o seu diferencial diante das soluções apresentadas estão descritos nas próximas seções.

3. Protocolo de Difusão Confiável Proposto

O uso das redes veiculares visa aumentar a segurança do tráfego, porém, a transmissão confiável de mensagens é um dos seus principais desafios para concretização deste objetivo [Dotzer, 2005]. O protocolo descrito neste trabalho se adapta ao ambiente de comunicação encontrado em cenários de tráfego rodoviário e provê confiabilidade na disseminação de informação de aplicações voltadas a segurança no trânsito em rodovias.

Os elementos fundamentais de uma rede ad hoc veicular são seus nós e nesta proposta assume-se que existem dois tipos de nós, os fixos e os móveis. Consideram-se como premissas que cada veículo (nó) tem sua identidade definida de forma única na rede e que tal identificação será baseada no endereço MAC do módulo de rede do nó. Os veículos participantes da rede possuem componentes que possibilitam a comunicação e a execução dos aplicativos, tais como: sensores, unidades de armazenamento, unidade de comunicação sem fio, sistema de posicionamento (GPS) e uma interface com o usuário para mostrar ao condutor os alertas e a localização dos eventos relatados.

Conforme ilustrado na Figura 1, o protocolo proposto é composto de três módulos, a saber: Módulo de Seleção do Retransmissor, Módulo de Comunicação e Módulo de Determinação de Vizinhança.

Figura 1: Arquitetura do Protocolo Proposto

O Módulo de Seleção é responsável por determinar o nó que terá o papel de retransmitir a mensagem de dados a cada salto. O Módulo de Comunicação define os tipos de mensagens existentes no protocolo, bem como a estrutura da lista de mensagens utilizada na abordagem. Neste módulo, também são definidos os mecanismos de adaptação de período entre mensagens de controle e codificação de rede. Por fim, o Módulo de Determinação de Vizinhança define a lista de vizinhos e é responsável pelos mecanismos de adaptação dos tempos de espera e detecção de conectividade.


180

No protocolo proposto, os nós móveis, ou seja, os veículos que trafegam sobre cada pista, trocam informações entre si, geram alertas, transmitem e retransmitem os alertas presentes na rede. Já os nós fixos, atuam como pontos de coleta para os dados enviados pelos veículos e têm como principal papel armazenar e retransmitir mensagens de dados quando solicitados. Desta forma, estes permitem que os nós verifiquem se receberam ou não a última mensagem vigente na rede. O protocolo, de forma a minimizar o impacto que a difusão tem sobre a comunicação, faz uso de mecanismos que diminuem a quantidade de mensagens desnecessárias na rede, inclusive as mensagens de controle, definindo períodos entre retransmissões que se adaptam de acordo com a densidade de veículos na via. Estas mensagens de controle permitem que os nós verifiquem se seus vizinhos já receberam um alerta vigente na rede, com o objetivo de mitigar o problema do nó oculto.

Para diminuir a quantidade de mensagens na rede, o nó móvel possui uma lista de vizinhos e uma lista de mensagens de dados (alertas) já recebidos. Uma vez que um nó reconheça seus vizinhos, esse deve determinar qual deles vai retransmitir o alerta que o transmissor deve difundir. Esta escolha se dá por meio da troca de beacons feitas anteriormente. Nestes beacons, estão contidas a identificação, a densidade local, a velocidade no instante e outras informações pertinentes do nó vizinho. De acordo com as informações dos nós vizinhos, o nó transmissor calcula o ganho W referente a cada vizinho, assim o nó que prover maior ganho será escolhido para retransmitir a mensagem de dados.

Os nós, ao receberem o alerta, devem verificar se foram, ou não, indicados como nó retransmissor. Caso o nó seja o indicado, este irá retransmitir a mensagem aos seus vizinhos. Segundo Paula et al.(2010), existem casos nos quais a disseminação direcionada pode trazer benefícios para aplicações voltadas à segurança no trânsito, desta forma, o protocolo proposto também permite que a disseminação de uma mensagem seja tanto, omnidirecional, quanto direcional. Para diminuir a quantidade de mensagens de dados retransmitidas pela rede, o protocolo proposto implementa ainda uma técnica de codificação de rede simples, baseada em operação lógica XOR. Em cenários com mais de uma mensagem de dados na rede, o protocolo realiza a operação XOR entre as mensagens existentes e faz uso de apenas uma retransmissão, ao invés de uma retransmissão para cada mensagem da rede. Todos estes processos e mecanismos serão detalhados a seguir.

3.1 Módulo de Seleção

A seleção do nó retransmissor ocorre quando um nó deseja transmitir ou retransmitir uma mensagem de dados na rede. Assim que um nó transmissor reconhece seus vizinhos, este calcula o peso Wj de cada vizinho da sua lista, que contém as informações dos vizinhos a um salto de comunicação. Este peso Wj é utilizado para determinar qual a qualificação que cada nó tem para ocupar a função de retransmissor da mensagem. Assumirá o estado de retransmissor, o nó que possuir o maior ganho. A Equação 1 indica como o nó i, no estado transmissor, calcula o ganho de cada vizinho por meio de:

�� = �. ��ℎ + (1 − �). ��ℎ� (1)

A componente Bj indica a distância de um veículo j em relação ao veículo transmissor i. O protocolo prioriza os nós mais próximos das bordas do raio de comunicação. A componente Dj indica a densidade local de cada nó (veículos por hora). Tem-se que, quanto maior a densidade local de um nó, maior é a chance de que este nó difunda a mensagem ao maior número de nós da rede. As componentes ThB e ThD determinam o limiar para cada uma das componentes Bj e Dj, respectivamente.

A constante w está entre o intervalo [0,1] e determina a influência de cada uma das componentes no cálculo do peso Wj, de modo que, é possível priorizar um fator em relação ao outro. Em cenários com grande densidade, por exemplo, é interessante priorizar a distância entre o transmissor e o retransmissor, assim a mensagem atinge as bordas do raio


181

de comunicação e é difundida o mais distante possível. Para calcular a distância Bj de um nó j em relação ao nó i, utiliza-se a equação da distância euclidiana bidimensional, que leva em consideração as coordenadas x e y de cada veículo. O calculo de Bj é dado por:

�� = �(�� − ��)� − (�� − ��)� (2)

na qual, xi e yi representam as coordenadas do veiculo i, e as componentes xj e yj representam as coordenadas do veiculo j. De posse da função Bj, cada veículo calcula sua distância em relação a cada vizinho presente em sua lista, sendo que quanto maior valor de Bj, mais próximo à borda do círculo de comunicação o veículo está. Portanto, melhor será a difusão da mensagem aos demais nós da rede. Para Bj, define-se um limiar referente à distância, neste caso, este limiar é definido pelo raio de cobertura do nó i.

A componente Dj da Equação 1 determina a densidade local do nó j. Quanto maior a densidade, maior será seu valor. Para o valor Dj, também é definido um limiar. Por meio do estudo do cenário a ser utilizado, pode-se definir o valor máximo de veículos ao redor de i que irão realmente auxiliar na retransmissão da mensagem.

Este protocolo também apresenta a possibilidade de retransmitir a mensagem em uma única direção. Segundo Paula et al.(2010), em cenários rodoviários, muitas vezes ocorrem acidentes e o mais certo a se fazer é informar os nós que vêm em direção ao acidente, no caso, deve-se direcionar a retransmissão da mensagem, assim atendendo todos os nós que vão de encontro ao acidente. Para realizar esta função, a Equação 1 sofre a seguinte mudança:

�� = (�. ��ℎ + (1 − �). ��ℎ�). �� (3)

sendo que Dr j define o sentido de direção do nó j e pode ter o valor +1 ou -1. Após obter o valor de Wj, o nó com maior peso W será selecionado para ser o retransmissor. Este processo se repete sempre que for necessário transmitir ou retransmitir uma mensagem de dado na rede.

3.2 Módulo de Comunicação

Para permitir que dois nós se comuniquem, assume-se que cada um deles tem capacidade de comunicação e processamento embarcado. A comunicação entre os nós da rede veicular ocorre por difusão de mensagens. Dois nós que estejam dentro do mesmo raio de comunicação podem se comunicar diretamente, ou seja, receber e enviar mensagens um ao outro. O raio de comunicação de um nó i é denominado r i e define uma área de cobertura de comunicação descrita por um círculo, no qual i encontra-se no centro e todos os nós que estejam dentro deste círculo são denominados vizinhos ou membros da vizinhança do nó i. Os vizinhos dentro do raio de comunicação de um nó são ditos vizinhos a um salto de comunicação deste nó; e aqueles que estão dentro 2ri são denominados vizinhos a dois saltos, e assim sucessivamente. Neste trabalho, são utilizadas apenas as informações dos vizinhos a um salto de distância, com o objetivo de diminuir a quantidade de mensagens de controle utilizadas para obtenção de informações sobre a vizinhança.

O módulo de comunicação é responsável pela difusão e recepção de dois tipos distintos de mensagens: mensagens de controle beacons e mensagens de dados que representam os alertas. Cada nó difunde mensagens de controle de forma aperiódica. O tipo de mensagem de controle a ser enviada depende do recebimento de outras mensagens de controle ou da necessidade de enviar uma mensagem de alerta. Toda mensagem de controle é composta por uma tupla de dados e contém informações do nó que a está difundindo e/ou sobre sua vizinhança. Esta mensagem é utilizada pelos nós para determinar suas próprias ações, por exemplo, definir o nó responsável pela retransmissão de uma mensagem a ser


182

difundida. Os alertas são difundidos pelo nó que tem a necessidade de gerar um alerta e esta mensagem é retransmitida somente pelo nó escolhido pelo transmissor.

Neste protocolo são utilizadas três mensagens de controle, que são: CM, RQ e MR. A mensagem CM encapsula informações do nó e permite que sejam criadas listas de vizinhos. Esta é trocada de forma aperiódica e, de acordo com a densidade da rede, as trocas de CMs acontecem em menor quantidade quando a lista de vizinhos não é atualizada com frequência, assim evitando mensagens de controle desnecessárias.

A mensagem de controle RQ é utilizada para forçar a troca de informações entre os nós próximos a um nó que pretende difundir um alerta na rodovia pela primeira vez. O nó i, ao perceber que deve enviar um alerta, gera a mensagem de controle RQ e a difunde na rede. Ao receber essa mensagem, o nó j é forçado a difundir a mensagem de controle CM; desta forma, o nó i recebe novas informações sobre sua vizinhança e pode definir o nó que será o retransmissor do alerta.

A mensagem de controle MR é utilizada para sinalizar aos nós que um alerta difundido teve seu tempo de vida expirado. O nó transmissor, ao perceber que o tempo de vida do alerta k expirou, difunde essa mensagem pela rede para que os nós presentes na rede retirem de circulação o alerta k. Os nós, ao receberem essa sinalização, retiram o alerta k da lista de alertas, evitando que a mesma seja difundida novamente.

A mensagem de dados existente neste protocolo é chamada de alerta e é utilizada para sinalizar problemas presentes na rodovia, como acidentes, congestionamentos, etc. Cada alerta gerado tem um identificador único definido pela aplicação. Este identificador é armazenado no campo Idk e é gerado através da utilização de uma função hash (o algoritmo SHA1 - Secure Hash Algorithm). Esta função produz uma sequência de bits de tamanho fixo a partir do mapeamento dos bits pertencentes às informações armazenadas nos campos Emi, ti

k e Dsk. na qual Emi é a sequência de bits que representa o endereço MAC da máquina que criou o alerta; ti

k é a sequência de bits que representa a data e hora em que o alerta foi enviado; e Dsk é a sequência de bits que representa as informações adicionais sobre o alerta.

O identificador único da mensagem é utilizado na comparação de alertas. Esta comparação é feita pela aplicação com o objetivo de evitar o envio de alertas já emitidos e a repetição de alertas disponibilizados aos condutores. O segundo campo da mensagem de dados, chamado de Emi, é responsável por armazenar o endereço MAC do nó que criou o alerta e tem seu tamanho estipulado em 48 bits.

3.2.1 Envio adaptativo de Mensagens de Controle

Conforme visto anteriormente, a mensagem de controle utilizada pelo nó i para obter informações de sua vizinhança é a mensagem CM. Nos trabalhos citados na Seção2, esta mensagem também é usada, porém, de forma periódica. Esta característica interfere no funcionamento da rede, já que em determinados cenários, por exemplo, os com alta densidade de veículos, a troca de mensagens de controle de forma periódica pode causar uma quantidade elevada de colisões de pacotes. Para diminuir a quantidade de mensagens de controle em cenários densos, utilizam-se mensagens de controle aperiódicas. Estas mensagens têm como base um período mínimo entre retransmissões, sendo que este período se adapta de acordo com a densidade local do nó. Quanto maior a densidade local do nó, maior será o período entre retransmissões da mensagem de controle, desta forma em cenários de congestionamento, os nós deixarão o canal de comunicação livre mais tempo para que este possa ser utilizado por uma transmissão de alerta.

Para que o nó i calcule este período, a cada mudança de densidade local, utiliza-se a seguinte equação:

�� = (�� +(�� . ��)) − �� !"[0,0.002] (4)


183

na qual, a componente Pf representa um período fixo mínimo igual a todos os nós pertencentes na rede (ex. 150 ms), já a componente Di determina a densidade local do nó j (veículos na vizinhança de j); TpV define o tempo que cada veículo acrescenta ao cenário e, por fim, a componente Random[0,0.002] tem papel de gerar um offset com valor entre 0 e 2 ms no período αi. O offset é criado para diminuir a chance de dois ou mais nós terem o mesmo período entre retransmissões e acabar por gerar colisões de pacotes na rede.

O período αi é calculado sempre que a densidade local do nó i for alterada. Caso tenha sido inserido novo vizinho, o nó i irá calcular seu período αi por meio da Equação 4, caso contrário, o nó i mantém seu período αi anterior ao recebimento da mensagem de controle, já que não houve mudança em sua lista de vizinhos.

3.2.2 Mecanismo de Codificação de Rede

Segundo Ahlswede et al. (2000), em uma rede unicast, o roteamento é suficiente para atingir o fluxo máximo da rede. Porém, em redes broadcast, a codificação de rede pode ser necessária. Trabalhos como [Oliveira et al. 2011] e [Cruz et al. 2012] mostram que a utilização da codificação de rede pode melhorar o roteamento de mensagens em VANETs.

No protocolo proposto, a operação XOR é utilizada em cenários nos quais existem mais de uma mensagem de dados na rede. Desta forma, os nós podem armazenar estas mensagens em suas listas de alertas. Por exemplo, o nó i tem em sua posse duas mensagens existentes na rede Alerta 1 e Alerta 2; em um determinado momento este nó i recebe uma primeira mensagem de controle CM de um nó j vizinho. Então, o nó i dispara um tempo de espera relativamente pequeno, porém, suficiente para receber mais mensagens de controle de outros vizinhos a sua volta. Este tempo de espera é chamado de TeCMmax. Durante este tempo de espera, o nó i recebe um conjunto de mensagens de controle (CM) de outros vizinhos e, ao expirar TeCMmax, i verifica que um grupo de nós vizinhos não recebeu a mensagem Alerta 1 e um segundo grupo de vizinhos não recebeu a mensagem Alerta 2. Ao verificar esta situação, o nó i calcula a porcentagem de nós vizinhos que requisitaram o Alerta 1, por meio da seguinte equação:

��!� = �!(�)*)+�(�1��",-� (5)

na qual, TotalAlerta1 representa a quantidade de nós que requisitaram o Alerta 1 e TamMCi

é o tamanho da lista de mensagens de controle recebidas durante o período TeCMmax.

O limiar [Intinicial, Intfinal] é configurável. Ao calcular Pxor, é obtida a porcentagem de veículos que requisitaram Alerta 1. Por exemplo, caso o limiar definido seja [40%, 60%] e, além disso, 50% dos vizinhos tenham requisitado o Alerta 1, será realizada a operação XOR entre as mensagens; caso contrário, as mensagens serão difundidas separadamente. A operação XOR é realizada bit a bit em cada mensagem.

3.3 Módulo de Determinação da Vizinhança

O módulo de Determinação da Vizinhança é responsável pela atualização da lista de vizinhos. Cada nó i armazena os dados dos vizinhos que enviaram mensagens de controle CM. Uma vez que um nó j faz parte da lista de vizinhos de um nó i, esse permanece na lista até que uma das estratégias do mecanismo de determinação de vizinhança o remova.

As estratégias deste módulo procuram minimizar o impacto que a mobilidade e a comunicação têm sobre a manutenção da vizinhança de um nó. Na primeira estratégia, um mecanismo de detecção de conectividade avalia se os vizinhos de um nó i ainda estão dentro de sua da área de cobertura de comunicação. Na segunda, um mecanismo de adaptação de tempo de espera (adaptative timeout) procura evitar que atrasos e perda de sinalizações levem a frequentes remoções e reinserções de nós na lista de vizinhos.


184

A correta determinação de quais vizinhos estão ativos dentro da área de cobertura de comunicação de um nó, reduz o número de atrasos e perda de mensagens entre os processos, além de auxiliar no processo da determinação do nó retransmissor.

3.3.1 Mecanismo de Adaptação dos Tempos de Espera

No protocolo proposto, a difusão de dados de controle é aperiódica e adaptativa de acordo com a densidade existente ao redor do nó transmissor. O timeout βj, calculado em cada nó i, define um tempo de espera para que cada um de seus vizinhos j entregue a próxima mensagem de controle. Assume-se, inicialmente, que existe um período fixo entre as retransmissões da mensagem CM e que este período é modificado de acordo com a Equação 4. Por meio da obtenção da densidade local Dj, é possível determinar o tempo de espera de uma mensagem de controle que será enviada por j, conforme

.� = �� + (�� . ��) (6)

na qual, Pf é o período (entre retransmissões) fixo e igual para todos os nós pertencentes a rede. Já a componente Dj determina a densidade local do nó j e TpV define o tempo que cada veículo representa no cenário. Quando um nó adapta seu tempo de espera por uma sinalização de um vizinho, este lida melhor com as mudanças nas condições de comunicação da rede e reduz o número de enlaces perdidos.

3.3.2 Detector de Conectividade

Além de adaptar o tempo de espera às condições do meio físico das redes veiculares, o protocolo desenvolvido propõe um mecanismo para detectar a conectividade entre os nós. O detector de conectividade busca estimar a posição dos vizinhos, dos quais se tenha perdido alguma mensagem de controle e determinar se o nó vizinho ainda se encontra em sua área de cobertura de comunicação. Para estimar se um enlace de comunicação permanece válido entre dois vizinhos, o nó i utiliza informações deste e as que já estão armazenadas na lista Ni. As informações utilizadas são: a última posição e velocidade conhecidas do vizinho j, além de sua posição anterior no instante tk-1, o raio de comunicação ri e o timestamp da última sinalização deste vizinho que foi recebido pelo nó i. Caso o timestamp das informações do nó j respeite o limite de tempo NSth, no qual se considera as informações deste válida, realiza-se o processo que define a posição estimada de j.

A estimava da posição do nó j é mensurada por meio da função CalculaPosicaoE(). Se a diferença entre as posições de i e j for menor que o raio de comunicação de i, este considera o enlace válido, caso contrário o enlace será inválido.

4. Avaliação do Protocolo Proposto

Com o objetivo de avaliar o protocolo proposto, foram realizadas simulações para verificar a eficácia do protocolo e o impacto do uso deste protocolo na eficiência da aplicação LDW. Nos experimentos, foram utilizados o simulador de redes OMNeT++ (Objective Modular Network Tested in C++) e o módulo INET framework para implementação da aplicação e do protocolo proposto. Com o objetivo de tornar as simulações mais realistas, foi utilizada a ferramenta geradora de cenários de mobilidade SUMO (Simulation of Urban Mobility) acoplada bidirecionalmente com o OMNeT++.

Os parâmetros do simulador de redes (OMNeT++/INET) foram definidos de acordo com o padrão IEEE 802.11g e com o datasheet do equipamento Access Point Cisco Aironet 1260. Tendo como base o trabalho de Ostermaier et al. (2007) e, após algumas análises empíricas, definiu-se como sendo de 300 metros o raio de alcance dos rádios dos veículos.


185

Nos experimentos, para a criação da via de circulação rodoviária, foi considerado um trecho real da rodovia BR-101. O trecho é composto por dois sentidos e duas faixas para cada sentido, tendo quatro faixas de rodagem no total, com uma velocidade máxima estipulada em 110 km/h para automóveis. Foram definidos cinco cenários de densidade de veículos (1000, 2000, 3000, 4000 e 5000 veículos/hora). Estes fluxos simulam os tráfegos esparso, médio e denso. Cabe ressaltar que em todos os cenários, o tamanho da autoestrada é mantido em 5 km. Para a configuração dos veículos que circulam no trecho, foram definidas quatro classes: automóveis, caminhões, motocicletas e ônibus.

Em relação aos parâmetros da aplicação, existem duas RSUs responsáveis pela propagação da lista de reputação. Uma está posicionada no quilômetro um e a outra no quilômetro três. Já as distâncias das áreas das regiões geográficas de reconhecimento, decisão e disseminação, são 50m, 300m e 3000m, respectivamente. Foi considerado para fins de simulação um evento dentro da área de reconhecimento (1.500m). Este evento indica a existência de um acidente na pista.

Os parâmetros definidos para o protocolo proposto foram: limiar ThB (300 metros); limiar ThD (50 veículos); TeCMmax (150 milisegundos); Pf (300 milisegundos); e TpV (20 milisegundos). Para obtenção dos resultados, foram realizadas cinco simulações para cada cenário de densidade e uma média aritmética simples dos resultados de cada cenário foi calculada. Todos os resultados obtidos nos experimentos possuem 95% de intervalo de confiança.

Para avaliar os impactos decorrentes do uso do protocolo proposto na eficiência da aplicação, foram consideradas as seguintes métricas: o total de veículos que receberam a mensagem de alerta, o número de colisões de pacotes na rede e a quantidade de retransmissões realizadas pelo protocolo, com e sem o mecanismo de codificação de rede. O protocolo proposto foi simulado juntamente com as abordagens Asynchronous Fixed Repetition (AFR), Asynchronous p-persistent Repetition (APR), Density-aware Reliable Broadcasting Protocol (DECA) e Broadcast Puro.

Tabela 2: Proporção de Colisões - Broadcast Puro, AFR, APR, DECA e Protocolo Proposto

Densidade (v/h) Broadcast Puro

APR AFR Protocolo Proposto

DECA

1000 9,1 % 10,2 % 11,5 % 8,4 % 9,8 %

2000 15,2 % 16,5 % 17,4 % 13,2 % 16,2 %

3000 18,8 % 19,7 % 20,1 % 16,2 % 19,1 %

4000 21,2 % 21,2 % 23,4 % 18,7 % 20,5 %

5000 27,8 % 30,8 % 31,1 % 21,3 % 24,9 %

Na Tabela 2, dentre todas as abordagens comparadas, apenas o protocolo DECA utiliza beacons. Fica claro que a utilização de beacons periódicos por parte da abordagem DECA acaba por degradar a rede, gera uma quantidade alta de mensagens de controle na rede, consequentemente, uma quantidade maior de colisões. Ainda sim, o DECA obteve uma proporção menor de colisões que outras abordagens que buscam prover confiabilidade como, por exemplo, AFR e APR.

Nas simulações do Protocolo Proposto no cenário com densidade de 5000 veículos/hora, apenas 21,3% das mensagens geradas sofrem colisão, ao comparar com a abordagem AFR. Pode-se verificar que a proporção de colisões diminui 9,8% em um ambiente com alta densidade de veículos. Os mecanismos implementados no Protocolo Proposto tinham como objetivo diminuir as mensagens de controle em cenários com alta densidade, por meio da adaptabilidade. Quando são analisados os cenários simulados, verifica-se que quanto maior a densidade, maior é a diferença na proporção de colisões,


186

quando comparadas com as abordagens Protocolo Proposto, Broadcast Puro, AFR, APR e DECA. Todavia, mesmo com o acréscimo de mensagens geradas e colisões, os mecanismos implementados no Protocolo Proposto não prejudicam significativamente o desempenho do protocolo, visto que os veículos recebem a mensagem de alerta, independentemente da densidade existente no cenário (Figura 2).

Figura 2: Taxa de Veículos que receberam o Alerta

Após obter todos os resultados referentes a confiabilidade de cada uma das abordagens, pode-se verificar que as abordagens DECA e Protocolo Proposto mantêm a entrega das mensagens de dados em 100% em todos os cenários simulados. Para efeito de comparação, buscou-se um cenário específico com uma configuração de carga na qual as abordagens deixam de entregar 100% das mensagens.

Na Figura 2, pode-se observar que, no cenário de 800 veículos/hora, a abordagem DECA não entrega 100% das mensagens de dados. Neste cenário, o Protocolo Proposto ainda consegue manter a confiabilidade, porém, no cenário com densidade de 500 veículos/hora, o Protocolo Proposto degrada sua confiabilidade em 2%, já o protocolo DECA degrada ainda mais sua confiabilidade ao compararmos com o Protocolo Proposto. Conforme dados obtidos pela Polícia Rodoviária, estes dois cenários são improváveis de ocorrer na rodovia considerada neste trabalho. O Protocolo Proposto faz uso de RSUs e, por este motivo, obtém resultados melhores que os do protocolo DECA. Em cenários com densidades muito baixas, a possibilidade de que esses cenários gerem situações como, por exemplo, o nó oculto, é alta. Desta forma, ao utilizar os nós fixos (RSU) ao longo da via, o Protocolo Proposto mitiga este problema em boa parte dos cenários com baixa densidade, ao contrário das outras abordagens que não fazem uso dos nós fixos.

Para verificar o funcionamento do Protocolo Proposto, utilizando o mecanismo de codificação de rede, a operação lógica XOR, foram definidos cinco novos cenários, nos quais foi utilizada a densidade de 3000 veículos/hora. Foram mantidas as estruturas das vias e parâmetros de simulação. A principal função deste mecanismo é diminuir a quantidade de retransmissões das mensagens de dados existentes na rede veicular sem degradar a confiabilidade do protocolo. O Cenário 1 teve 45 % dos nós inicializados com o Alerta 1 em

78,0%

86,6%

89,7%

93,0%92,5% 92,3% 92,0%

91,2%

80,0%

91,6%

94,5%

99,0%99,5% 99,3% 99,0% 98,8%

82,0%

91,6%

97,8%

100,0% 99,5% 99,6% 99,5% 99,0%

83,0%

95,0%

99,0%100,0% 100,0% 100,0% 100,0% 100,0%

98,0%

100,0% 100,0% 100,0% 100,0% 100,0% 100,0% 100,0%

75,0%

80,0%

85,0%

90,0%

95,0%

100,0%

500 600 800 1000 2000 3000 4000 5000

Broadcast Puro AFR APR DECA Protocolo Proposto

Densidade (Veículos/Hora)

To

tal d

e n

ós a

ten

did

os


187

suas listas de alertas, 45 % foram inicializados com o Alerta 2 e 10% com ambos os alertas em suas listas. No Cenário 2, 30 % dos nós foram inicializados com o Alerta 1, 30 % com o Alerta 2 e 30 % com ambos os alertas. O Cenário 3 teve 20 % com o Alerta 1, 20 % com o Alerta 2 e 60 % com ambos os alertas. Já no Cenário 4, apenas 5% dos nós foram inicializados com o Alerta 1, 5% com o Alerta 2 e 90% com ambos os alertas. Por fim, o Cenário 5 teve 100 % dos seus nós inicializados com os dois alertas em suas listas.

Na Tabela 3, pode-se observar a comparação entre o Protocolo Proposto com e sem o mecanismo. Também pode-se observar que o mecanismo de codificação de rede prove menor quantidade de retransmissões de mensagens em comparação ao Protocolo Proposto sem o mecanismo: ao gerar o XOR de duas mensagens, o nó não precisou retransmitir os alertas 1 e 2, separadamente, ao receber solicitações de ambas as mensagens no mesmo período de tempo. No Cenário 4, o mecanismo obteve melhor resultado. Isso acontece porque a porcentagem de nós com as duas mensagens em suas listas é de 90 %. Desta forma, são realizadas mais operações lógicas XOR neste cenário, o que diminui a quantidade de retransmissões. Fica claro que, quanto maior for o número de nós com as duas mensagens em suas listas, menor será a quantidade de retransmissões no cenário. No Cenário 5, não há retransmissões de mensagens, já que todos os nós possuem ambas as mensagens e, desta forma, não há necessidade de retransmissões.

Tabela 3: Quantidade de retransmissões de Mensagens de Dados (Alerta) - Sem e Com Codificação de Rede

Cenários Sem Codificação de Redes Com Codificação de Redes Redução de Mensagens

Cenário 1 735 452 38,5 %

Cenário 2 512 301 41,2 %

Cenário 3 351 191 45,5 %

Cenário 4 93 41 55,9 %

Cenário 5 0 0 0 %

Portanto, ao analisar a Tabela 3, pode-se verificar que a abordagem sem o mecanismo realiza mais que o dobro (55,9%) de retransmissões que a abordagem com o mecanismo. Desta forma, o mecanismo atendeu seu objetivo, que é diminuir a quantidade de retransmissões geradas na rede em cenários que possuem mais de um alerta a serem disseminados.

Neste trabalho buscou-se determinar se o atraso gerado pelos mecanismos implementados no Protocolo Proposto podem ou não influenciar no tempo para que o condutor possa tomar uma decisão com segurança. Foram simuladas as abordagens DECA, Broadcast Puro, AFR e APR afim de comparar com o Protocolo Proposto. Pode-se perceber na Tabela 4 que o maior atraso proporcionado pelo Protocolo Proposto em todos os cenários foi 2,73 segundos e o veículo que recebeu a mensagem estava a 2891 metros da ocorrência, caso o veículo tenha velocidade máxima de 110 km/h, então o condutor do veículo terá até um minuto e meio para realizar uma mudança em sua trajetória ou frear o veículo.

Tabela 4: Tempo de recebimento Mensagem de Dados (Atraso Máximo x Distância) - Cenário 1000 (veículos/hora)

Protocolo Atraso Máximo (s) Distância (m)

Broadcast Puro 2,58 2808

DECA 2,73 2867

Protocolo Proposto 2,73 2891

AFR 3,41 1635

APR 4,13 815


188

Ao comparar o Protocolo Proposto com as abordagens simuladas, o atraso máximo gerado pelo Protocolo Proposto é igual ao atraso máximo gerado pela abordagem DECA e superior apenas à abordagem Broadcast Puro. As abordagens AFR e APR obtiveram atrasos maiores em todos os cenários simulados.

Também fica claro que, quanto maior a quantidade de veículos, menor é o atraso. Isso corre pois em cenários mais densos existem menos espaços livres nas vias, desta maneira, é formado um canal de comunicação mais estável. Já em cenários mais esparsos, a comunicação fica dependente da técnica store-and-forward que consiste em armazenar as mensagens para uma retransmissão posterior, o que aumenta o atraso em cenários com pouca densidade.

Pode-se concluir que o Protocolo Proposto gera atraso na retransmissão das mensagens de sinalização, porém, este atraso não prejudica a tomada de decisão do condutor, tendo em vista que o protocolo desenvolvido obteve o segundo menor atraso e a maior distância entre todas as abordagens estudadas.

5. Conclusão

Um dos desafios em redes veiculares é a inserção de novos mecanismos que possam torná-las mais seguras e confiáveis, sem adicionar riscos no comprometimento de seu desempenho. Com a necessidade de prover confiabilidade às redes veiculares surgem os protocolos confiáveis que buscam oferecer um serviço de entrega de mensagens garantida.

O protocolo proposto inova em relação aos trabalhos relacionados por ser um protocolo adaptativo que busca diminuir a quantidade de mensagens desnecessárias na rede, atrasos na entrega de mensagens e também problemas presentes em outras abordagens, como por exemplo, o do nó oculto. O protocolo proposto seleciona o nó retransmissor por meio do cálculo do ganho. Este cálculo leva em consideração a densidade local do nó e a sua proximidade da borda de comunicação. O nó com maior ganho retransmite a mensagem e também escolhe o próximo retransmissor. Na abordagem proposta, faz-se uso de mecanismos que tornam o protocolo adaptável ao cenário rodoviário, desta forma, a quantidade de mensagens de controle é diminuída. Em cenários com mais de uma mensagem de dados vigente na rede, o protocolo proposto realiza a técnica de codificação de rede baseada na operação XOR para diminuir a quantidade de retransmissões.

Com os resultados obtidos nas simulações, foi possível comprovar a eficácia do protocolo proposto. Os resultados demonstram também que os impactos na eficácia da aplicação diante do uso do protocolo não prejudicam os seus objetivos, uma vez que todos dos veículos, independente da densidade, receberam a mensagem de alerta. Com as simulações, foi possível também comprovar a eficiência da protocolo, uma vez que mesmo com o acréscimo das colisões com o uso das mensagens de controle, todos os veículos receberam o alerta em tempo hábil para tomar decisões.

Referências

Ahlswede, R. et al. (2000), "Network information flow. IEEE Transactions on Information Theory, v. 46, n. 4, p. 1204?1216, 2000.

Bernsen, J. e Manivannan, D. (2009), “Review: Unicast routing protocols for vehicular ad hoc networks: A critical comparison and classication”, Pervasive Mob. Comput., v. 5, n. 1, p. 1-18, feb. 2009. ISSN 1574-1192.

Chuan, D. e Jian, W. (2012), "A reliable and efficient highway multihop vehicular broadcast model. Communications and Networking", ISRN, v. 2012, n. 185472, p. 8, quarter 2012.


189

Cruz, E. et al. (2012), "Performance analysis of xor-based routing in urban vehicular ad hoc networks" In: Wireless Communications and Networking Conference (WCNC), 2012 IEEE. [S.l.: s.n.], 2012. p. 2521-2525. ISSN 1525-3511.

Kamoltham, N., Nakorn, K. e Rojviboonchai, K. (2011), "Improving reliable broadcast over asymmetric vanets based on a rssi-voting algorithm", In: Intelligent Signal Processing and Communications Systems (ISPACS), 2011 International Symposium on. [S.l.: s.n.], 2011. p. 1-6.

Kosch, T. (2004), “Local danger warning based on vehicle ad hoc networks: Prototype and simulation”, In: Proceedings of 1st International Workshop on Intelligent Transportation (WIT 2004).

Koubek, M., Rea, S. e Pesch, D. (2010), "Reliable broadcasting for active safety applications in vehicular highway networks" In: Vehicular Technology Conference (VTC 2010-Spring), 2010 IEEE 71st. [S.l.:s.n.], 2010. p. 1 {5. ISSN 1550-2252.

Lee J. et al. (2008), “Vehicle local peer group based multicasting protocol for vehicle-tovehicle communications”, In: The Fourth International Workshop on Vehicle-to-Vehicle Communications.

Nagaraj, U. e Dhamal, P. (2011), "Broadcasting routing protocols in vanet. Network and Complex Systems", IISTE, v. 1, n. 2, p. 13-19, 2011. ISSN 2225-0603.

Nakorn, K. N. e Rojviboochai, K. (2010), "Comparison of reliable broadcasting protocols for vehicular ad-hoc networks", In: Communication Technology (ICCT), 2010 12th IEEE International Conference on. [S.l.: s.n.], 2010. p. 1168-1171.

Oliveira, R. et al. (2011), "Towards the use of xor-based routing protocols in vehicular ad hoc networks" In: Vehicular Technology Conference (VTC Spring), 2011 IEEE 73rd. [S.l.: s.n.], 2011. p. 1-6. ISSN 1550-2252.

Ostermaier B. et al. (2007), “Enhancing the security of local danger warnings in VANETs - a simulative analysis of voting schemes”, In: Proceedings of ARES’07.

Paula, W.P. et al. (2010), “Um mecanismo de reputação para redes veiculares tolerantes a atrasos e desconexões”, In: Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos, 2010. Gramado. SBRC, p. 545-550.

Ros, F., Ruiz, P. e Stojmenovic, I. (2009), "Reliable and efficient broadcasting in vehicular ad hoc networks", In: Vehicular Technology Conference, 2009. VTC Spring 2009. IEEE 69th. [S.l.: s.n.], 2009. p. 1-5. ISSN 1550-2252.

Tonguz, O. et al. (2007), "Broadcasting in vanet" In: 2007 Mobile Networking for Vehicular Environments. [S.l.: s.n.], 2007. p. 7-12.


190

Simulação e Análise de Métodos de Detecção deCongestionamento de Veículos em VANET

Mariana Ramos de Brito1, Anna Izabel J. Tostes1, Fátima de L.P. Duarte-Figueiredo1,Antonio A. F. Loureiro2

1Departamento de Ciência da ComputaçãoPontifícia Universidade Católica de Minas Gerais - Belo Horizonte, MG – Brasil

2Departamento de Ciência da ComputaçãoUniversidade Federal de Minas Gerais (UFMG) - Belo Horizonte, MG – Brasil

[email protected], [email protected]

[email protected], [email protected]

Abstract. Vehicular congestion is a problem in urban centers. Vehicularnetwork management allows through communication between vehicles and in-frastructure the congestion detection and the information dissemination to helpdrivers changing their route to a less congested one. This paper proposes a con-gestion detection method and compares it with one from the literature. Simulati-ons with real traffic data from Belo Horizonte were performed. The results showthat the method proposed in this paper presents reductions of up to 17% on themean time for the vehicles to detect congestion, despite sending approximately5% more packets through the network, what does not affect its performance.

Resumo. O congestionamento de veículos é um problema dos centros urbanos.O gerenciamento de redes veiculares permite, através da comunicação entreveículos e de veículos com a infraestrutura, a detecção de congestionamento ea disseminação dessa informação para ajudar os motoristas a trocarem seu ca-minho para uma rota mais livre de trânsito. Este trabalho propõe um método dedetecção de congestionamento e compara com um método da literatura. Simu-lações com dados reais do trânsito de Belo Horizonte foram realizadas. Os re-sultados demonstram que o método proposto neste trabalho apresenta reduçõesde até 17% no tempo médio para os veículos detectarem o congestionamento,apesar de enviar aproximadamente 5% mais pacotes pela rede, o que não afetaseu desempenho.

1. IntroduçãoO interesse na área de redes veiculares vem aumentando com o passar do tempo. Redesveiculares são formadas por veículos e equipamentos físicos, geralmente localizados àsmargens das vias de trânsito. Essas redes são caracterizadas por topologias altamentedinâmicas, enlaces intermitentes, o fato de o movimento dos nós (veículos) ser restringidopelos limites das vias, entre outras características [Alves et al. 2009]. Estas característicaslevam a desafios como, por exemplo, a disseminação de dados, o compartilhamento dedados e questões de segurança [Liu et al. 2009]. Algumas das aplicações para as redes


191

veiculares incluem a monitoração cooperativa do tráfego, o acesso à Internet e a detecçãode congestionamentos.

O congestionamento de veículos é um grande problema dos centros urbanos hojeem dia. As pessoas perdem muito tempo presas em congestionamentos, uma grandequantidade de combustível é gasta e a poluição ambiental sofre um aumento por causados agentes poluentes liberados pelos veículos [Bauza et al. 2010]. Descobrir um con-gestionamento e disseminar essa informação pode ajudar os motoristas a se decidirempor rotas mais vazias, reduzindo congestionamentos existentes.

Neste trabalho, uma rede simulada que segue dados reais do trânsito de Belo Ho-rizonte foi implementada e um novo método de detecção de congestionamento atravésda rede veicular foi proposto e comparado com um método da literatura, no qual ele foibaseado. O Método da Árvore, descrito em [Fahmy and Ranasinghe 2008], utiliza umaárvore para contar o número de veículos em um congestionamento. Cada veículo trocamensagens (beacons) com todos os vizinhos para descobrir se está ou não em congestio-namento. Entretanto, esse método apresenta algumas desvantagens, sendo elas: precisarda confirmação de todos os vizinhos na área para que um novo veículo passe a indicar con-gestionamento; continuar executando o algoritmo para descoberta do congestionamentoquando os veículos já sabem que se encontram em um; e não levar em consideração se umveículo indica congestionamento antes de inseri-lo na árvore. O método proposto nesteartigo utiliza apenas a maioria dos veículos para detectar o congestionamento, o algoritmopara descoberta do congestionamento só é executado enquanto o veículo sabe que não seencontra em um congestionamento e novos veículos só são anexados à árvore se indicamque estão em um congestionamento.

Os dois métodos foram simulados. Os resultados foram comparados em termosde quanto tempo o último veículo que chegou à área do congestionamento levou paracomeçar a indicá-lo; o tempo médio que os veículos, em geral, levaram para detectar ocongestionamento; o tempo que levou para calcular a quantidade de veículos no conges-tionamento; a quantidade enviada de beacons; e o número de chamadas realizadas aoalgoritmo para detecção do congestionamento. O método proposto se mostrou mais efi-ciente que o método original. Foram obtidas reduções de 25% no tempo que o últimoveículo descobriu o congestionamento; 17% no tempo médio para os veículos em geralperceberem o congestionamento; 82% no tempo que a raiz da árvore levou para somar ototal de veículos no congestionamento; e até 4% menos chamadas ao algoritmo de veri-ficar a existência de congestionamento foram feitas por cada veículo da rede. O métodoproposto neste artigo envia 5% mais pacotes pela rede. Entretanto, como os pacotes sãotodos de controle e não congestionam muito a rede, seu desempenho não foi afetado.

Este trabalho está dividido em 7 seções. A seção 2 apresenta os trabalhos rela-cionados. A seção 3 descreve o método original, encontrado na literatura e usado comobase para o método proposto, que está descrito na seção 4. A seção 5 traz detalhes dassimulações realizadas, enquanto na seção 6 estão os resultados obtidos e as comparaçõesrealizadas. Na seção 7 estão as conclusões tiradas deste trabalho.

2. Trabalhos RelacionadosNa estratégia proposta em [Knorr and Schreckenberg 2011], os veículos serão equipadoscom um aparelho de rádio e passarão a enviar mensagens (beacons) para os outros nós da


192

rede periodicamente, com informações sobre o veículo. A partir das mensagens recebidas,um veículo calcula e analisa quando e como é preciso que o motorista mude seu compor-tamento de condução. De acordo com as análises dos autores, mesmo com uma taxa deapenas 30% de penetração da tecnologia, o congestionamento praticamente desaparece.O sucesso da estratégia proposta, entretanto, depende das escolhas feitas pelos motoristas,que decidem se vão ou não mudar seu comportamento a partir das informações recebidasdo sistema.

Um trabalho que se assemelha ao [Knorr and Schreckenberg 2011] é o[Fukumoto et al. 2007], no qual os autores propõem um sistema de Comunicação Ori-entada a Conteúdos (Contents Oriented Communication - COCs). Neste sistema, os veí-culos estimam a densidade do tráfego com base em mensagens de consciência cooperativa(Cooperative Awareness Messages - CAMs), recebidas dos outros veículos da rede. Umveículo detecta, a partir das informações de densidade do tráfego de determinado localrecebidas, situações de congestionamento, comparando as estimativas de densidade dotráfego da estrada com os valores de densidade média para esse mesmo trecho da es-trada. Os autores mostraram, através de simulação, que os veículos conseguem detectar elocalizar o congestionamento de forma acurada.

COoperative Traffic congestion detECtion - CoTEC é a técnica proposta em[Bauza et al. 2010] e se baseia em comunicação V2V (Vehicle-to-Vehicle) e lógica fuzzypara detectar situações de congestionamento, sendo capaz de informar sua localização, ex-tensão e intensidade. A CoTEC monitora as condições do tráfego como um todo atravésdas mensagens (beacons) que os nós da rede (veículos) enviam randomicamente uns paraos outros. Cada veículo monitora as condições locais do tráfego, e, através de lógica fuzzy,detecta uma condição de congestionamento local. Assim que uma condição de congesti-onamento local é detectada, ou seja, algum veículo estima um nível de congestionamentoque ultrapassa um limiar predefinido, a CoTEC utiliza as informações locais coletadaspor cada veículo para caracterizar o congestionamento como um todo. Outro trabalho queutiliza a troca de mensagens de estado entre os veículos é o [Lakas and Cheqfah 2009],no qual é proposto um sistema de comunicação veicular para detectar e dissipar conges-tionamentos através da disseminação de informações da estrada. Essas informações sãoobtidas de cada veículo, que estima um índice de congestionamento para cada trecho daestrada por onde ele passa, e compartilhadas com os outros veículos da rede. Um algo-ritmo de Dijkstra dinâmico é usado para computar rotas menos congestionadas para asquais desviar os veículos. As simulações dos autores mostraram que a comunicação entreos veículos pode contribuir bastante para dissipar os congestionamentos nas cidades dehoje em dia.

O trabalho [Terroso-Saenz et al. 2012] é diferente dos outros. Os autores criaramuma arquitetura movida por eventos (Event-Driven Architecture - EDA) que funcionacom base no processamento de eventos complexos (Complex Event Processing - CEP). AEDA fica nos veículos da rede e também em estações centrais e fica analisando a situaçãodo tráfego. Quando ela encontra grupos de veículos com velocidades baixas, ela inferese aquilo é um congestionamento e, se sim, informa aos veículos da rede. Entretanto,esse sistema proposto não é tão bom, pois sua eficácia depende muito da penetração datecnologia. Os autores pretendem, futuramente, melhorar o sistema para que ele sejaeficaz mesmo com uma baixa penetração.


193

Usando as características das VANETs, os autores de [Mohandas et al. 2009] pro-põem uma abordagem inovadora para lidar com o congestionamento. Os autores notaramuma semelhança entre redes veiculares e redes de comunicação de dados, pois o con-gestionamento acontece quando a demanda supera a capacidade do caminho, e esse fatomotivou-os a gerenciar o congestionamento de veículos usando um algoritmo de controlede congestionamento feito para o tráfego da Internet. Com o uso desse algoritmo, o nú-mero de veículos em uma via pode ser controlado para que não exceda a capacidade davia. Os resultados obtidos pelos autores, através de simulações, mostram que o algo-ritmo é capaz de lidar com o congestionamento de veículos controlando o tamanho dafila, quando o congestionamento é causado por tráfego que excede a capacidade da via.

Os autores de [Fahmy and Ranasinghe 2008] propuseram uma alternativa aos sis-temas existentes baseados em GPS, já que os mesmos não funcionam em todas as situ-ações. Em vez do GPS, supõe-se que todos os veículos estarão equipados com apare-lhos wireless e que cada nó (veículo) da rede tem um número id único. Cada nó enviamensagens (beacons) em intervalos randômicos e, a partir das mensagens recebidas dosvizinhos, o nó decide se está congestionado ou não. Assim que um nó decide que está emum congestionamento, o algoritmo de contagem é executado. Uma árvore onde os nóssão os veículos no congestionamento é montada, mas, como na rede veicular a raiz nãoé conhecida, o algoritmo vai selecionar o nó com o maior id para ser a raiz. A seleçãoda raiz e a contagem são feitas ao mesmo tempo. Cada nó terá o total da sua subárvore,ou seja, as folhas terão contagem 1 e a raiz terá a contagem total. O congestionamento éinferido com base nas taxas de tempo de chegada e saída dos nós em determinada área.Com os resultados das simulações, os autores mostraram que a ideia proposta pode serusada em situações reais para descobrir um congestionamento em formação e tambémpara calcular o número de veículos envolvidos.

Este trabalho é diferente dos citados, pois propõe um método de identificarum congestionamento de forma simples e mais eficiente que o método proposto em[Fahmy and Ranasinghe 2008], usado para comparação. Com pequenas alterações nométodo da literatura, foi possível obter melhoras significativas.

3. Método Original: Método da Árvore

O método de detecção de congestionamento proposto em [Fahmy and Ranasinghe 2008]foi usado como base para este trabalho. Nele, os autores propuseram um método quemonta uma árvore com os veículos envolvidos no congestionamento e consegue contá-los. Considerando que todos os veículos têm um número de identificação único (id) e queestão equipados com aparelhos wireless, eles enviam beacons (mensagens de controle)em intervalos randômicos de 3 a 6 segundos.

Cada veículo contém listas para guardar os vizinhos antigos e atuais. Sempre queum beacon é recebido, o veículo emissor é inserido nas listas de vizinhos do veículo. Umcontador de congestionamento é acrescido de 1 sempre que, no intervalo de enviar umbeacon, os vizinhos antigos do veículo estão na lista de atuais. Quando esse contadorultrapassa o limite de 40 intervalos de tempo, ou todos os vizinhos do veículo indicamcongestionamento e o contador ultrapassa 2 intervalos de tempo, o veículo muda seuestado para congestionamento e o algoritmo de montar a árvore e somar os nós começa aser executado. Os 40 ou 2 intervalos de tempo foram definidos pelos autores do trabalho


194

original como os mais adequados para identificar o congestionamento.

Figura 1. Montagem da árvoreFonte: Elaborado pelos autores

Quando o veículo recebe um beacon de um veículo com uma id maior que a delepara a raiz da árvore, ele muda seu parâmetro do id da raiz(rId) da árvore para o recebidoe o seu parâmetro de id do pai(pId) para o id do veículo do qual ele recebeu o beacon.Dessa forma o veículo é anexado à árvore. Quando o veículo recebe um beacon vindo deum filho, ele atualiza seu parâmetro de total, somando o total recebido do filho. Assim vaiaté chegar na raiz da árvore, que saberá, então, o total de veículos no congestionamento.

4. Método Proposto: Método da Árvore MelhoradoAlgumas alterações no método original foram propostas para tentar melhorar sua eficiên-cia e o resultado dessas alterações resultou no método proposto. A primeira alteração foisó chamar o algoritmo de descobrir o congestionamento se o veículo não está em um con-gestionamento. No método original, os veículos continuam executando esse algoritmo,mesmo quando já sabem que estão em um, o que leva a um processamento desnecessário.Com a alteração proposta, esse algoritmo só é executado quando necessário.

Outra alteração proposta foi considerar as informações da maioria dos vizinhos,não de todos, para um veículo decidir seu estado. Essa alteração torna possível que osveículos se decidam pelo estado de congestionamento mais rapidamente, pois pode serque dois veículos chegaram juntos a uma área congestionada, por exemplo. Os dois veí-culos novos, seguindo o método original, teriam que esperar todos os 40 intervalos detempo antes de aceitarem o congestionamento, pois o veículo que chegou junto ainda nãoestaria indicando o congestionamento e, portanto, nem todos os vizinhos concordam, oque não permite que um veículo indique o congestionamento em apenas 2 intervalos detempo. Com a alteração proposta, os dois veículos novos consideram as informações re-cebidas da maioria dos vizinhos, que indicam congestionamento, e, portanto, um vizinho


195

que não concorde não vai afetá-lo, o que torna possível que o veículo novo passe a indicaro congestionamento em apenas 2 intervalos de tempo.

A última alteração proposta foi só considerar as informações de um beacon re-cebido quando seu veículo emissor também indica congestionamento. Essa alteração foiproposta para evitar o problema causado por uma “raiz falsa”. No método original, os veí-culos começam a executar o algoritmo de montar a árvore e somar os nós quando passama indicar congestionamento. Entretanto, não há uma preocupação se os veículos que oveículo atual está anexando à árvore estão realmente no congestionamento, o que leva osveículos executando o algoritmo de montar a árvore a ficarem enganados com um veículode id alto que apenas passa perto da via congestionada. A alteração proposta evita esseproblema, pois se, e apenas se, um veículo indica congestionamento, ele é adicionado àárvore. Portanto, a raiz falsa (veículo de id alto que não participa do congestionamento,mas que entra no alcance de algum veículo no congestionamento) nunca é considerada araiz da árvore quando os veículos seguem o método proposto.

5. Simulações RealizadasPara este trabalho foi criada uma rede simulada que segue dados reais do trânsito docentro de Belo Horizonte. A Figura 2 exibe o mapa usado para criar a rede. Os dadosutilizados para criar o fluxo de veículos foram cedidos pela BH Trans [BHTrans 2013],que é a empresa responsável pelos transportes e pelo trânsito de Belo Horizonte.

Figura 2. Mapa de Belo Horizonte utilizado para a redeFonte: OpenStreetMap, 2013

Simulação foi a forma escolhida para testar os métodos implementados porquetestes reais são caros e podem ser perigosos. Os simuladores usados para este trabalho


196

foram o SUMO (Simulation of Urban MObility) [SUMO 2012], que é o simulador demobilidade; o OMNeT++ [OMNeT++ 2012], simulador de rede; e o Veins (Vehicle innetwork simulation) [Veins 2012], que é a plataforma de integração entre os dois simula-dores.

Como o fluxo de veículos segue dados reais do trânsito, os tempos de simulaçãoforam variados para obter tamanhos diferentes de rede. Para uma rede com 61 veículosno total e 54 no congestionamento, o tempo de simulação foi de 10 minutos. A rede de 62veículos ao todo e 54 no congestionamento também foram 10 minutos de simulação, coma adição de um veículo especialmente modificado que será explicado. Para 86 veículos aotodo, 75 no congestionamento, as simulações foram de 15 minutos. Com 20 minutos desimulação, a rede foi composta por 111 veículos ao todo, sendo 99 no congestionamento.

O veículo especial inserido na rede de 62 veículos não participa do congestiona-mento, apenas passa em uma rua lateral a qual ele acontece e se conecta brevemente comos veículos no congestionamento. Esse veículo foi modificado para ter o maior número idda rede e foi inserido para testar os efeitos que uma “raiz falsa”, ou seja, um veículo comid alto suficiente para ser a raiz da árvore, mas que não participa do congestionamento,tem nos dois métodos testados.

6. Resultados

Todos os resultados exibidos são os valores médios de 10 execuções do método original e10 execuções do método proposto, ambos nas mesmas redes. Todos os resultados seguemum intervalo de 95% de confiança, sendo que o desvio padrão é apresentado nos gráficos.

Figura 3. Instante no tempo que o último veículo percebeu o congestionamentoFonte: Dados da pesquisa

O gráfico da Figura 3 exibe os instantes no tempo da simulação que o último veí-culo de cada tamanho de rede/método percebeu que estava em um congestionamento. O


197

tempo exibido no gráfico é o tempo desde que o veículo saiu da origem até chegar ao con-gestionamento e percebê-lo. Pelo gráfico, é possível ver que, dos veículos que chegarampor último à área congestionada, os que seguiam o método melhorado conseguiram per-ceber o congestionamento até 25% mais rapidamente que os veículos seguindo o métodooriginal. Isso se deve à alteração de considerar as informações apenas da maioria dos vi-zinhos, ou seja, os últimos veículos conseguem perceber o congestionamento em apenas2 intervalos de tempo, enquanto que no método original isso nem sempre acontece.

No gráfico da Figura 4 estão os tempos médios que os veículos precisaram, defato, para perceber o congestionamento. Como é possível perceber, o método propostofoi novamente mais eficiente que o método original, devido à alteração de considerar asinformações apenas da maioria dos vizinhos.

Figura 4. Tempo médio para os veículos indicarem congestionamentoFonte: Dados da pesquisa

A Figura 5 traz o gráfico com os instantes no tempo que a raiz verdadeira da árvoresomou o total de veículos no congestionamento. Os veículos raiz seguindo o métodoproposto conseguem somar o total de veículos mais rapidamente, pois os veículos emgeral descobriram o congestionamento de forma mais rápida e a raiz só pode somar osnós que indicam congestionamento. No caso da rede especial, a de 62 veículos, o veículoraiz seguindo o método original demorou consideravelmente mais tempo para somar ototal de veículos, pois ele perdeu tempo acreditando que a raiz falsa era a verdadeira.

Na Figura 6 estão as quantidades de beacons enviados. O método proposto enviamais beacons que o original, mas isso se deve ao fato de os veículos seguindo o métodomodificado perceberem o congestionamento mais cedo. No caso da rede de 62 veículos,no método original foram enviados mais beacons, pois a raiz verdadeira demorou maistempo para perceber que era a raiz da árvore e somar os veículos, portanto o algoritmo demontar a árvore foi mais executado e a quantidade de beacons foi maior, visto que essealgoritmo faz o veículo enviar mais beacons de mudança de estado.


198

Figura 5. Instante no tempo que a raiz somou o total de veículosFonte: Dados da pesquisa

Figura 6. Quantidade de beacons enviadosFonte: Dados da pesquisa

No gráfico da Figura 7 estão as chamadas que foram feitas ao algoritmo de desco-brir o congestionamento. Devido à alteração de parar de chamar esse algoritmo quandoo veículo já indica congestionamento, os veículos seguindo o método proposto realiza-ram muito menos chamadas. Os veículos que seguiam o método original continuaram aschamadas a esse algoritmo mesmo quando já indicam congestionamento, o que torna seuprocessamento maior.


199

Figura 7. Chamadas ao algoritmo de descobrir congestionamentoFonte: Dados da pesquisa

7. Conclusões

Neste trabalho foi apresentado um novo método de detecção de congestionamentoatravés de redes veiculares. Este método foi baseado no método proposto em[Fahmy and Ranasinghe 2008], o Método da Árvore, sendo que foram propostas alte-rações que visavam melhorar sua eficiência. Como foi possível perceber, este objetivofoi alcançado e o método resultante, o Método da Árvore Melhorado, obteve melhorasde 25% no tempo que o último veículo descobriu o congestionamento; 17% no tempomédio para os veículos em geral perceberem o congestionamento; 82% no tempo que araiz da árvore levou para somar o total de veículos no congestionamento; e até 4% menoschamadas ao algoritmo de verificar a existência de congestionamento foram feitas porveículo.

Com o método proposto, aproximadamente 26% mais pacotes foram enviadospela rede no pior caso. Entretanto, como isso se deve ao fato de que os veículos seguindoo método proposto descobrem o congestionamento mais cedo e que todos os pacotesenviados pelo método são de controle, que não congestionam muito a rede, o desempenhodo Método da Árvore Melhorado não é afetado.

Possíveis trabalhos futuros a este incluem: otimização no envio dos beacons, in-tegração com técnicas de minimização de congestionamentos e avaliação de outros algo-ritmos.

Referências

Alves, R. S., Campbell, I. V., Couto, R. S., Campista, M. E. M., Moraes, I. M., Rubins-tein, M. G., Costa, L. H. M. K., Duarte, O. C. M. B., and Abdalla, M. (2009). Redesveiculares: Princípios, aplicações e desafios. In 270 Simpósio Brasileiro de Redes de


200

Computadores e Sistemas Distribuídos, pages 199–254, Recife. Minicurso do Simpó-sio Brasileiro de Redes de Computadores – SBRC’2009.

Bauza, R., Gozalvez, J., and Sanchez-Soriano, J. (2010). Road traffic congestion detectionthrough cooperative vehicle-to-vehicle communications. In Local Computer Networks(LCN), 2010 IEEE 35th Conference on, pages 606 –612.

BHTrans (2013). Bhtrans. Disponível em: <http://www.bhtrans.pbh.gov.br/portal/page/portal/portalpublico>. Acesso em: 21 nov. 2013.

Fahmy, M. F. and Ranasinghe, D. N. (2008). Discovering automobile congestion andvolume using vanet’s. In ITS Telecommunications, 2008. ITST 2008. 8th InternationalConference on, pages 367 –372.

Fukumoto, J., Sirokane, N., Ishikawa, Y., Wada, T., Ohtsuki, K., and Okada, H. (2007).Analytic method for real-time traffic problems by using contents oriented communica-tions in vanet. In Telecommunications, 2007. ITST ’07. 7th International Conferenceon ITS, pages 1 –6.

Knorr, F. and Schreckenberg, M. (2011). Influence of inter-vehicle communication onpeak hour traffic flow. PHYSICA A-STATISTICAL MECHANICS AND ITS APPLICA-TIONS, 391(6):2225–2231.

Lakas, A. and Cheqfah, M. (2009). Detection and dissipation of road traffic congestionusing vehicular communication. In Microwave Symposium (MMS), 2009 Mediterran-nean, pages 1 –6.

Liu, Y., Bi, J., and Yang, J. (2009). Research on Vehicular Ad Hoc Networks. In CCDC2009: 21ST CHINESE CONTROL AND DECISION CONFERENCE, VOLS 1-6, PRO-CEEDINGS, pages 4430–4435. NE Univ; IEEE Ind Elect Singapore Chapter; GuilinUniv Elect Technol; IEEE Control Syst Soc; IEEE Ind Elect Soc. 21st Chinese Controland Decision Conference, Guilin, PEOPLES R CHINA, JUN 17-19, 2009.

Mohandas, B. K., Liscano, R., and Yang, O. W. W. (2009). Vehicle Traffic Conges-tion Management in Vehicular ad-hoc networks. In 2009 IEEE 34TH CONFERENCEON LOCAL COMPUTER NETWORKS (LCN 2009), Conference on Local ComputerNetworks, pages 655–660. BBN Technologies; Stadt Zurich; Kanton Zurich; Com-mun Syst Grp; Univ Turicensis. IEEE 34th Conference on Local Computer Networks,Zurich, SWITZERLAND, OCT 20-23, 2009.

OMNeT++ (2012). Omnet++. Disponível em: <http://www.omnetpp.org>.Acesso em: 08 set. 2012.

SUMO (2012). Sumo - simulation of urban mobility. Disponível em: <http://sumo.sourceforge.net>. Acesso em: 08 set. 2012.

Terroso-Saenz, F., Valdes-Vela, M., Sotomayor-Martinez, C., Toledo-Moreo, R., andGomez-Skarmeta, A. F. (2012). A Cooperative Approach to Traffic Congestion De-tection With Complex Event Processing and VANET. IEEE TRANSACTIONS ONINTELLIGENT TRANSPORTATION SYSTEMS, 13(2):914–929.

Veins (2012). Veins - vehicles in network simulation. Disponível em: <http://veins.car2x.org>. Acesso em: 08 set. 2012.


201


202

Índice por Autor

A

Albuquerque, J.C. ............................163

Alvarenga, I. ....................................133

Andrade, R. ..........................................3

B

Bastos, C.A.M. ...................................31

Borges, V.C.M. ..................................17

Both, C. ..............................................75

Brito, M.R. .......................................191

C

Caldas, P. .........................................133

Campos, C.A.V. ...............................163

Cardoso, L. .........................................89

Cardozo, T.B. ...................................119

Cerqueira, E. ....................................149

Costa, R. ...........................................149

Curado, M. .........................................17

D

Duarte, O.C.M.B. .......................89, 133

Duarte-Figueiredo, F. .......................191

E

Esteves, R. ..........................................61

F

Fernandes, N.C. .................................31

Fernandes, S. ......................................47

Ferraz, L. ............................................89

Ferraz, P. ............................................61

G

Garcia, F. ..............................................3

Ghamri-Doudane, Y. ........................105

Granville, L.Z. .............................61, 75

Guedes, A. ........................................105

I

Isolani, P.H. .......................................75

L

Lopes, Y. ............................................31

Loureiro, A.A.F. ..............................191

Lucena, S. ........................................163

M

Macedo, R.T. ...................................105

Monteiro, E. .......................................17

Montez, C. ........................................177

N

Nogueira, M. ....................................105

O

Oliveira, C.T. .......................................3

Oliveira, R. .......................................177

R

Ramos, F. .........................................133

Rochol, J. ...........................................75

Rosário, D. .......................................149

S

Sadok, D. ............................................47

Santana, M. ........................................47

Santos, A. .................................105, 149

Santos, M. ..........................................47

Silva, A.P.C. ....................................119

Souza, J.N. ...........................................3

T

Tostes, A.I. .......................................191

V

Vieira, A.B. ......................................119

W

Wangham, M. ..................................177

Wickboldt, J. ......................................75

Z

Ziviani, A. ........................................119

Documents

XIX Workshop de Gerência e Operação de Redes e Serviços WGRS 2014 · 2014-04-21 · Anais do XIX Workshop de Gerência e Operação de Redes e Serviços– WGRS 2014 ii ... UnB,