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

Transcrição

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
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.
i
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)
ii
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)
iii
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.
iv
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
v
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)
vi
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
vii
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
viii
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)
ix
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
x
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
xi
32º Simpósio Brasileiro de Redes de Computadores e
Florianópolis - SC
(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)
Mestrado e Doutorado em Ciência da Computação (MDCC)
2
Grupo de Redes de Computadores, Engenharia de Software e Sistemas (GREat)
3
Instituto Federal de Educação, Ciência e Tecnologia do Ceará (IFCE)
1
[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
b
Bolsista de produtividade D-1 do CNPq
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
nodesTable
pathTable
Nome do objeto
nodeId
timeAwake
lastSeq
lastTimestamp
sendPacketNode
recvPacketNode
sendDataPacket
recvDataPacket
sendBytesNode
recvBytesNode
pathId
srcNode
dstNode
sendPacketPath
sendBytesPath
timeBeginning
timeEnding
Descrição do objeto
Endereço do nó da rede alvo
Tempo (segundos) em que o nó está ativo
DSN do último pacote enviado pelo nó
Marca de tempo do último pacote enviado pelo nó
Quantidade de pacotes enviados pelo nó
Quantidade de pacotes recebidos pelo nó
Quantidade de pacotes de dados enviados pelo nó
Quantidade de pacotes de dados recebidos pelo nó
Quantidade de bytes enviados pelo nó
Quantidade de bytes recebidos pelo nó
Path no formato origem→destino
Endereço do nó de origem do path
Endereço do nó de destino do path
Quantidade de pacotes enviados no path
Quantidade de bytes enviados no path
Marca de tempo do primeiro pacote enviado no path
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://wwwdb.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
http://www.manageengine.com/free-snmp-mibbrowser-android, Novembro.
Tool",
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
http://www.webnms.com/javaagent, Outubro.
Toolkit
Java
Edition“,
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
ACRoMa - An Architecture of Cooperative Routing
Management in Wireless Mesh Networks
Vinicius C. M. Borges1 , Marilia Curado2 , Edmundo Monteiro2
1
Institute of Informatic (INF)
Federal University of Goiás (UFG)
Goiânia – Brazil
2
Laboratory 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 ubiquitous 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 scalable 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 balancing mechanism with a cross-layer routing metric aware of link quality, ACRoMa 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 gerenciamento para suportar vários tipos de aplicações multimídia de forma escalável. Este trabalho apresenta um arquitetura de gerenciamento chamada Architecture of Cooperative Routing Management (ACRoMa) para serviços triple
play em RMSF. Um estudo de simulação foi realizado para avaliar o desempenho 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 crosslayer 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 wireless 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 applications 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 effectively, 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 growing 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 delaysensitive 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. cognitive radio, Multiple-Input Multiple-Output (MIMO) and Long Term Evolution (LTE))
and thus support the requirements of multimedia applications. The routing process comprises 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 undertaken by means of an architecture for cooperative routing management, called Architecture 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 interactions 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 architecture. 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 routing 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 routing 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 allocated 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 balancing 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 lightlyloaded 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 cooperation 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 Balancing (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 introducing 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 information 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 different 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 routing algorithms, and a cross-layer routing metric. When clustering routing scheme, crosslayer 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 clustering 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 follows: 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] combines 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 measurements 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 migration: 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 routing structures which cooperate with each other to improve the overall network performance. First, the spanning tree structure (solid line) is used to communicate with the gateway (i.e. intra-cluster load balancing routing scheme). The Inner Domain Load Balancing (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. Afterwards, the nodes calculate the routes to every neighbor (specially for relay and boundary 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 degree 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 ACRoMa architecture conceptually by combining all the components. In this section, the
performance evaluation within the NS2 simulator will examine a mixed traffic comprising 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 different 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 varying 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 simulations 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 deployments. 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 typical 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 increase.
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. Furthermore, 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
Network Size
Network Size
1200
Average Flow Throughput (Kb/s)
1200
FTP
1000
800
600
400
VoIP
Video
200
1000
800
600
400
VoIP
FTP
200
0
0
A
D
A
D
Load Configurations
RAILoB-50nn
A
D
A
RAILoB-100nn
D
PLB-50nn
Figure 8.
Average
Throughput of RAILoB
Flow
A
D
Load Configurations
A
D
PLB-100nn
Figure 9.
Average
Throughput of PLB
Network Size
Flow
Network Size
2
Average Flow Delay (s)
2
Video
1.5
1
VoIP
Video
FTP
0.5
0
1.5
1
VoIP
Video
FTP
0.5
0
A
D
A
D
A
D
A
Load Configurations
RAILoB-50nn
D
A
D
A
D
Load Configurations
RAILoB-100nn
PLB-50nn
Figure 10. Average Flow Delay
of RAILoB
PLB-100nn
of 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 capacity 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 subsection where a triple play service configuration is employed. This sub-section is structured 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
Topology
Topology
1200
1200
1000
FTP
800
600
400
VoIP
Video
200
1000
800
600
400
VoIP
Video
200
0
0
A
D
A
D
Load Configurations
RAILoB-Grid
A
D
A
RAILoB-Random
D
PLB-Grid
Figure 12.
Average Flow
Throughput of RAILoB
A
D
Load Configurations
A
D
PLB-Random
Figure 13.
Average Flow
Throughput of PLB
Topology
Topology
2
2
FTP
1.5
1
VoIP
0.5
Video
FTP
0
1.5
1
VoIP
Video
FTP
0.5
0
A
D
A
D
A
D
A
Load Configurations
RAILoB-Grid
D
A
D
A
D
Load Configurations
RAILoB-Random
PLB-Grid
of RAILoB
PLB-Random
of 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 proposed 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 synergies 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 scalable 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 solution.
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-ST24FEDER-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., Robitzsch, 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 algorithms 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 migration for wireless mesh networks. Elsevier Journal of Parallel and Distributed Computing, 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 Autoconfiguração de
Redes de Subestação IEC 61850 Baseada em OpenFlow
Yona Lopes1 , Natalia Castro Fernandes2 , Carlos Alberto Malcher1
1
Laboratório GTECCOM, 2 Laboratório MidiaCom
Dep. de Telecomunicações - Universidade Federal Fluminense (UFF)
Abstract. Smart grids depend on a solid foundation of communications.
Although standards like IEC 61850 proposes solutions to achieve
interoperability, the auto configuration and the automatic control of the
communication network are still an open problem. This work proposes an
efficient solution for autonomic management and control of communication
networks for substations based on IEC 61850. The proposed solution, called
SMARTFlow, uses OpenFlow in order to achieve granularity and flexibility
in the treatment of data flows. SMARTFlow proactively calculates Layer
2 multicast trees to forward GOOSE and Sampled Values messages and
reconfigures all flow entries in case of network failures. Also, the proposed
system monitors the network and defines on-demand the configuration of
client-server flows. The proposal was implemented and tested using Mininet
and showed a total load up to 44 % lower than the load using typical switches.
The proposal also showed advantages when compared to other multicast
solutions, such as GMRP(GARP Multicast Registration Protocol)
Resumo. As Smart Grids dependem de uma base sólida de comunicação.
Apesar de normas como a IEC 61850 apresentarem soluções para alcançar
a interoperabilidade, ainda existem problemas em aberto com relação à
autoconfiguração e ao controle automatizado da rede de comunicação. Esse
trabalho propõe uma solução eficiente de controle e gerenciamento autônomo
de redes de comunicação para subestações baseadas na norma IEC 61850. A
solução proposta, chamada de SMARTFlow, é baseada no uso do OpenFlow
para obter granularidade e flexibilidade no tratamento dos fluxos de dados. O
SMARTFlow, pró-ativamente, calcula as árvores multicast de camada 2 para
encaminhamento de mensagens GOOSE e Sampled Values e reconfigura todas
as entradas de fluxos em caso de falhas, além de monitorar a rede, definindo
sob demanda a configuração de fluxos cliente-servidor. A proposta foi implementada e testada utilizando o emulador Mininet e apresentou uma carga total
até 44% menor do que a de switches tı́picos. A proposta também demostrou vantagens quando comparada com outras soluções de multicast, como o GMRP.
1. Introdução
A energia elétrica 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 além de danos causados pela falta de serviços essenciais. Por exemplo, no Brasil, uma auditoria
do Tribunal de Contas da União mostrou que os apagões de 2001 e 2002 causaram um
prejuı́zo de R$ 45,2 bilhões para os brasileiros1. O responsável por prover a qualidade
do serviço elétrico oferecido aos consumidores, controlando e direcionando o fluxo de
energia e fornecendo energia durante o maior tempo possı́vel aos consumidores finais é o
1
http://www.correiobraziliense.com.br e http://epocaestadobrasil.wordpress.com
31
Sistema Elétrico de Potência (SEP), que possui uma infraestrutura complexa para gerar,
transmitir e distribuir essa energia. Contudo, o SEP está sujeito a anormalidades e defeitos em sua operação. Para que o impacto das falhas seja reduzido, sistemas de proteção e
supervisão são indispensáveis.
Apesar da importância do SEP, pouca inovação tem sido feita nos últimos
anos, e, consequentemente, os equipamentos utilizados e as tecnologias, algumas vezes, são os mesmos de 40 anos atrás [Gungor et al. 2011]. Da necessidade inevitável de
modernização dos sistemas de automação do SEP, surgiram as Smart Grids, tornando
imprescindı́vel a implantação de um sistema de comunicação mais “inteligente” interligando os sistemas de proteção e supervisão e os centros de controle [Lopes et al. 2012].
Uma das principais normas que especificam essa comunicação inteligente é a norma IEC
61850 [IEC 61850 ]. Apesar da norma IEC 61850 apresentar soluções para modelagem
da comunicação dentro do SEP e interoperabilidade dos equipamentos, ainda existem
problemas em aberto. A comunicação de mensagens prioritárias da norma, Sampled Values(SV) e GOOSE, é feita em camada 2 e com o uso de multicast [IEC 61850 ]. Contudo,
devido ao comportamento padrão dos switches para multicast de camada 2, essas mensagens são enviadas em broadcast. Esse comportamento traz uma sobrecarga tanto para
rede quanto para os dispositivos finais que recebem mensagens mesmo não estando no
grupo [Sivanthi and Goerlitz 2013]. Existem protocolos dinâmicos para encaminhamento
multicast de camada 2, como o GMRP (GARP Multicast Registration Protocol), padronizado pelo IEEE 802.1D. Porém, essa solução exige que o protocolo seja implementado
nos dispositivos finais, o que ainda não ocorre em redes IEC 61850.
Outra questão importante é relativa aos sistemas de recuperação de falhas para redes de subestação recomendados pela norma. Esses sistemas garantem a entrega do pacote
duplicando o tráfego, ou duplicando todos os dispositivos na rede. Com isso, o tráfego na
rede aumenta, o que pode sobrecarregar os nós da rede , aumentando inclusive o processamento dos dispositivos finais, que tem baixo poder de processamento, e passam a processar o dobro de pacotes. Além disso, esses sistemas só podem ser usados em topologias
especı́ficas e necessitam de implementação nos dispositivos finais [Tan and Luan 2011].
Esse trabalho visa melhorar o desempenho na comunicação dentro de subestações
utilizando de forma eficiente os recursos de rede de comunicação, além de autoconfigurar
as redes de subestação IEC 61850. A proposta, chamada de SisteMa Autoconfigurável
para Redes de Telecomunicações IEC 61850 com arcabouço OpenFlow (SMARTFlow),
utiliza o OpenFlow [McKeown et al. 2008] para fazer um melhor controle dos dados em
tráfego dentro de uma subestação. Inicialmente, as entradas de fluxos de alta prioridade
definidos na norma IEC 61850 são configuradas com base no arquivo de configuração
de subestação, definido na norma. Essa configuração é feita pró-ativamente para garantir que não serão inseridos atrasos para as mensagens sensı́veis. Para tanto, o SMARTFlow possui um componente que calcula e configura as árvores multicast para encaminhamento das mensagens de camada 2, evitando o uso do broadcast e sem a necessidade de
implementação de protocolos nos dispositivos finais. Foi desenvolvido também, um componente para tratamento de falhas, que recalcula as árvores dinamicamente sempre que
houver falhas na rede. Além disso, o SMARTFlow define um modelo para aplicação de
prioridade 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 a
todos os requisitos das mensagens da norma IEC 61850. O sistema proposto reduziu em
até 20 vezes o atraso gerado pelas aplicações de controle padrão do POX e apresentou
uma carga total até 44% menor do que a de switches tı́picos. Os testes foram realizados
considerando diferentes configurações tı́picas de subestação, de forma a validar a proposta
em termos de atraso e carga de controle.
O restante deste artigo está organizado da seguinte forma. A Seção 2 apresenta
uma visão geral da norma IEC 61850 e da comunicação multicast de camada 2. Os trabalhos relacionados são apresentados na Seção 3. A proposta é apresentada no Capitulo 4 e a
Seção 5 apresenta a análise dos resultados experimentais. As conclusões são apresentadas
na Seção 6.
2. Redes IEC 61850
A norma IEC 61850 modela os sistemas e a comunicação da rede para a automação no
SEP. Seu principal objetivo é garantir interoperabilidade entre dispositivos eletrônicos
inteligentes (Intelligent Electronic Device (IEDs)) de diferentes fabricantes que permitem,
dentre outros, a supervisão, o controle e a proteção em tempo real do SEP.
O modelo de comunicação da IEC 61850 usa três diferentes tipos de mensagem:
GOOSE e SV com alta restrição temporal, chegando a 3 ms, e MMS (Manufacturing
Message Specification) variando de 100ms até 1000ms [IEC 61850 ]. As mensagens são
encaminhadas de duas formas, no modelo publicador/assinante com os endereços multicast padronizados pela norma, e no modelo cliente-servidor. A norma define o modelo
publicador/assinante para mensagens GOOSE, e o modelo cliente-servidor para mensagens MMS. A SV pode ser enviada nos dois modelos. As mensagens GOOSE e SV são
usadas para serviços crı́ticos na subestação, por esse motivo são mapeadas diretamente na
camada 2 a fim de prover um tempo de resposta mais rápido. Com isso, estas mensagens
são diretamente encapsuladas em camada Ethernet e transmitidas com um endereço de
destino MAC multicast [McGhee and Goraj 2010].
A norma padroniza uma linguagem de descrição, chamada de Linguagem de
Configuração de Subestação (Substation Configuration Language - SCL), que norteia a
configuração do sistema. Isto significa dizer que são configurados desde os canais de
comunicação até a alocação de funções para os sistemas de automação [IEC 61850 ]. A
SCL é baseada em XML (eXtensible Markup Language) e seu objetivo principal é padronizar os atributos de configuração, ou seja, criar uma nomenclatura uniformizada, de
maneira a permitir configurações de IEDs com maior segurança e confiabilidade. O intuito é manter a interoperabilidade, garantindo a troca de dados entre IEDs independente
do fabricante. Dentre os arquivos de configuração que compõe a SCL, este artigo ressalta
o SCD, pois é este arquivo que descreve detalhadamente a subestação no que tange à
comunicação. O arquivo SCD contém uma seção de configuração de comunicação e uma
seção de descrição da subestação. Desta maneira, este arquivo pode conter, por exemplo,
aonde está alocado cada nó lógico do sistema, endereços de rede, endereços de grupos
multicast, etc.
2.1. Comunicação multicast de camada 2 em redes IEC 61850
A norma define o uso de grupos multicast de camada 2 para mensagens GOOSE e SV.
Switches, por padrão, quando recebem um pacote endereçado a um destino multicast de
33
camada 2, enviam este pacote por todas as portas. É esse método que garante que o pacote
vai chegar ao destino qualquer que seja o destinatário2 . Porém, esse método consome
banda no enlace, aumenta o atraso nos switches e introduz uma sobrecarga significativa
nos IEDs. Para contornar este problema, os fluxos de dados multicast devem ser restritos
apenas ao grupo em questão, ou seja, à árvore multicast [McGhee and Goraj 2010].
As árvores multicast podem ser configuradas de forma estática ou dinâmica. Na
configuração estática, o endereço multicast é mapeado para a porta, ou mais de uma se
for o caso, por onde os pacotes daquele grupo especı́fico devem ser encaminhados. Se
o estado da rede muda, não existe uma atualização automática na tabela de encaminhamento. Qualquer configuração ou alteração deve ser feita manualmente, por esse motivo
não é muito utilizada. Na configuração dinâmica, o gerenciamento do multicast é feito
com o uso de protocolos, que se encarregam do tráfego multicast encaminhando-o para
os dispositivos que manifestaram interesse em recebê-lo. A árvore multicast é construı́da
dinamicamente, e, em caso de atualização na rede, o algoritmo deve recalcular a árvore.
Nesse caso, os IEDs deveriam implementar protocolos para serem capazes de entrar ou
sair de um grupo. Atualmente, o protocolo multicast de camada 2 usado em redes IEC
61850 é o GMRP. Seu principio básico de funcionamento é baseado em mensagens intituladas join e leave, as quais o host deve ser capaz de enviar quando quiser entrar ou sair
de um grupo. O switch registra a porta pela qual recebeu a mensagem join e associa essa
porta ao grupo multicast da mensagem, montando a sua tabela de encaminhamento. Em
seguida, o switch envia a mensagem join via broadcast para toda a rede, garantindo que o
novo membro do grupo multicast passe a ser conhecido por toda a rede. Todos os switches
que suportam GMRP podem receber essa informação de outros switches para atualizar seu
registro local. Com a tabela configurada e atualizada, quando o publicador envia mensagens multicast, o switch envia essas mensagens apenas para as portas necessárias para que
a mensagem chegue a todos os membros do grupo [Yong-hui et al. 2011].
Existem trabalhos que mostram que o uso de multicast em redes de subestação simplifica o
controle do tráfego e diminui os atrasos [Ingram et al. 2011, Sivanthi and Goerlitz 2013,
Moore et al. 2010, McGhee and Goraj 2010], além de reduzir o volume de dados recebidos por dispositivos [XiCai et al. 2011].
Yong-hui et al. mostram as vantagens do uso do GMRP em redes de subestação.
Os autores exploram as vantagens do GMRP com aplicações em laboratório e aplicações
práticas. Nesse mesmo contexto, XiCai et al. apresentam um exemplo do uso do
GMRP em subestações Chinesas para reduzir o volume de dados recebidos por dispositivos [XiCai et al. 2011]. Muitas vezes, o GMRP é usado em conjunto com as VLANs
(Virtual Local Area Network) para restringir o tráfego [Ingram et al. 2011]. Ingram et
al. combinam o uso de VLANs e filtro multicast para separar o tráfego por aplicação
e por grupos de interesse, de forma que o tráfego multicast fique restrito a ser distribuı́do apenas dentro de determinada VLAN [Ingram et al. 2011]. Sivanthi e Goerlitz
propõem uma abordagem sistemática para melhorar o uso de filtros multicast e VLANs
agrupando caminhos comuns [Sivanthi and Goerlitz 2013]. Os autores apresentam um
algoritmo que agrupa destinos que seguem o mesmo caminho na rede, ou seja, se dois
2
Nesse artigo, entende-se por switch tı́pico o comportamento padrão de swiches.
34
grupos multicast têm a mesma árvore, o algoritmo coloca os dois no mesmo grupo multicast [Sivanthi and Goerlitz 2013]. As propostas de uso do GMRP em redes de subestação,
demandam que os fabricantes de IEDs implementem o protocolo em seus dispositivos [Yong-hui et al. 2011]. Contudo, os IEDs, até o momento, não possuem a capacidade
de implementar o protocolo e enviar mensagens join e leave para a rede. Com isso, parte
da configuração tem que ser feita manualmente, na tabela multicast estática dos switches.
Assim, a configuração da rede se torna trabalhosa e a maioria dos fabricantes recomenda
a utilização de VLANs para limitar os domı́nios de broadcast [Ingram et al. 2011]. Portanto, o multicast acaba não sendo utilizado na prática, o que reduz o desempenho da rede
[McGhee and Goraj 2010].
A proposta deste artigo dinamicamente cria árvores multicast, sem a necessidade
de implementação nos IEDs e configura os fluxos unicast e multicast no contexto de sistemas de automação de subestação usando o OpenFlow. O trabalho leva em consideração
os requisitos temporais rı́gidos da norma IEC 61850 e a confiabilidade requerida em redes
de subestação. Além disso, reconfigura dinamicamente toda a rede em caso de falha ou
de mudança na rede.
Com relação ao uso de OpenFlow em Smart Grids, Sydney et al.
propõem o uso de OpenFlow para prover recursos de MPLS em redes de longa
distância [Sydney et al. 2014]. Cahn et al. propõem o SDECN (Software-Defined Energy
Communication Network), que usa redes definidas por software (SDN) como solução
para as smart grids [Cahn et al. 2013]. Os autores sugerem o uso do openflow em redes
de subestação e fazem uma implementação simples com base no controlador Ryu. Poucos
detalhes são apresentados sobre algoritmos e lógicas de controle e os cenários de teste são
muito restritos.
Existem, ainda, alguns trabalhos que utilizam o OpenFlow para gerenciamento de
rede e encaminhamento multicast [Marcondes et al. 2012, Silva et al. 2012], porém fora
do contexto de subestações.
4. A proposta SMARTFlow
Para aumentar o desempenho das redes de subestação, é proposto o SMARTFlow, que
é um sistema autoconfigurável para redes de telecomunicações IEC 61850 baseado no
arcabouço OpenFlow. Seus objetivos principais são o desenvolvimento de um encaminhamento apropriado de mensagens IEC 61850 e o controle eficiente de redes de
dados de subestações elétricas. Além disso, com o SMARTFlow, é possı́vel fazer a
autoconfiguração dos grupos multicast de forma automática, toda vez que for inserido ou
retirado um IED da rede, sem a necessidade de implementação no IED. Como a proposta
é facilitar o planejamento e a configuração da rede, é possı́vel configurar automaticamente
a rede de telecomunicações com a solução adequada aos requisitos da rede. Dessa forma,
os principais módulos do SMARTFlow são:
• autoconfiguração inicial da rede de telecomunicações com base nos dados obtidos
pelos arquivos de configuração da subestação providos pela norma IEC 61850;
• criação automática de árvores multicast de camada 2 para o envio de mensagens
GOOSE e SV;
• recuperação de falhas através do recálculo e atualização automática 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 arcabouço, pois possibilita um controle mais flexı́vel e orientado às necessidades de cada sistema de comunicação, como é
o caso das smart grids e da Norma IEC 61850. Com isso, torna-se possı́vel experimentar
novos métodos e novos algoritmos que garantam uma boa solução e aumentem o desempenho das redes. De fato, essa tecnologia traz ganhos por permitir a implementação
de todas as recomendações da norma e de recursos para otimizar a rede. Além disso,
por existir um controlador centralizado, as redes OpenFlow oferecem flexibilidade de
programação e uma visão unificada da rede, facilitando a implementação de novos algoritmos, a configuração e a gestão da rede. Além disso, a manutenção preventiva da rede
é realizada de uma maneira simples, uma vez que a migração de fluxos é simples em redes OpenFlow. Como o uso do arcabouço OpenFlow simplifica a virtualização da rede,
diferentes fabricantes podem implementar polı́ticas para controlar a sua rede no mesmo
switch sem interromper ou interferir com outros serviços.
4.2. Arquitetura do SMARTFlow
A arquitetura detalhada do SMARTFlow é ilustrada na Figura 1. O SMARTFlow é executado sobre um elemento central da rede, chamado controlador, que se comunica com
todos os switches para configurar as tabelas de fluxo via um canal seguro. O SMARTFlow
pode ser implementado em qualquer controlador OpenFlow.
Figura 1. Estrutura do SMARTFlow, o qual é composto por um conjunto de
aplicações de controle para redes de subestações baseadas em IEC 61850.
No SMARTFlow, o plano de controle da rede de telecomunicações é responsável
por monitorar e configurar a rede automaticamente a partir de parâmetros do arquivo
SCD da Norma. Os algoritmos de controle do SMARTFlow [Lopes 2013], usam como
base informações contidas nesse arquivo, que pode conter, dentre outras informações, a
que grupo multicast cada IED pertence e os endereços de rede do mesmo. Dessa forma,
torna-se possı́vel fazer um mapeamento dos grupos multicast existentes na rede para o
algoritmo que calcula as árvores, gerando uma lista de grupos multicast.
36
Propõe-se o uso de sete componentes, os quais todos foram desenvolvidos para
o SMARTFlow, com exceção do Descoberta de Topologia e do Spanning
Tree, que são componentes geralmente encontrados nos controladores OpenFlow:
Descoberta de Topologia: Este componente é essencial para o funcionamento dos outros componentes do SMARTFlow. O componente Descoberta de
Topologia instrui cada um dos switches da rede a enviar mensagens Link Layer Discovery Protocol (LLDP) para seus vizinhos, de modo que o controlador possa descobrir a
topologia da rede. Quando um switch recebe um pacote LLDP, ele encaminha o cabeçalho
do pacote para o controlador, já que não existe regra de encaminhamento para esse fluxo.
Com isso, o controlador pode inferir a conectividade dos enlaces combinando os dados
de cada pacote LLDP recebido.
Spanning Tree: Já conhecendo a visão geral da topologia da rede, pelo componente Descoberta de Topologia, pode-se, então, construir a spanning tree. O
objetivo do componente Spanning Tree é calcular a árvore de cobertura da rede e, de
acordo com os dados obtidos, desativar a primitiva de inundação em alguns enlaces especı́ficos. Isso faz com que topologias que formem ciclos evitem loops infinitos no envio
de mensagens broadcast.
Tráfego Comum: Este componente encaminha, sob demanda, o tráfego unicast
de baixa prioridade das redes baseadas em IEC 61850, como por exemplo, mensagens
MMS. O componente Tráfego Comum é uma versão do componente do Openflow que
funciona como um switch de aprendizagem de forma reativa. Isso significa dizer que,
sempre que um novo fluxo chegar a um switch, este dispositivo encaminha o cabeçalho
do primeiro pacote para o controlador, o qual aciona o módulo Tráfego Comum para
calcular e definir as entradas de fluxo correspondentes com base no estado atual da rede.
Descoberta de Clientes: Este componente captura os pacotes da rede e
faz o mapeamento dos endereços MAC de todos os IEDS na rede automaticamente, armazenando em um dicionário todos os endereços MAC dos IEDs, a qual portas e switches
estão ligados. Esse dicionário é intitulado mac map. Cada vez que um IED é acrescentado ou retirado da rede, esse componente atualiza esse dicionário. Os endereços MAC
dos IEDs e servidores, na prática, podem ser obtidos do arquivo SCD da norma IEC
61850. Contudo, essa configuração inicial não é suficiente para detectar erros de ligação,
ou ainda, mudanças na topologia geradas durante o funcionamento da rede. Assim, optouse pelo uso de uma solução mais genérica. O componente proposto monitora os eventos
da rede e mantém atualizado o dicionário que correlaciona o MAC e a porta de saı́da de
cada switch.
Balanceamento de carga: Esse componente observa o estado da rede e
distribui a carga dos fluxos unicast menos prioritários entre os enlaces, através do uso de
migrações ao vivo. Com isso, sempre que se observa que um enlace está próximo de um
certo limiar de uso, alguns fluxos são migrados para outros enlaces menos sobrecarregados. Essa migração é feita criando-se uma nova rota a partir do destino até a origem. A
rota original é apagada apenas quando a nova rota já está pronta para uso, garantindo,
assim, que não serão perdidos pacotes. Isso ajuda a melhorar o desempenho da rede
e a minimizar a latência de resposta, o que é essencial para redes de comunicação que
auxiliam mecanismos de proteção do SEP.
37
Multicast L2: Este componente implementa o Algoritmo 1 para calcular as
árvores de distribuição para os grupos multicast de camada dois, necessários para as mensagens GOOSE e SV. Utilizando como entrada o arquivo SCD, esse componente identifica
os grupos multicast e, em seguida, com base nos dados das aplicações Descoberta de
Topologia e Descoberta de Clientes, calcula as árvores multicast para cada
grupo na rede IEC 61850 da subestação e configura pró-ativamente os respectivos switches. Essa configuração pró-ativa é importante porque os grupos multicast são utilizados
por mensagens de alta sensibilidade a atrasos no IEC 61850. A configuração pró-ativa
impede que a entrega das mensagens seja atrasada pela consulta reativa ao controlador, o
que seria o comportamento padrão do OpenFlow.
O Algoritmo 1, baseado nos dados do componente Descoberta de
Topologia, é capaz de ter uma visão completa da rede, podendo armazenar em uma
lista, todos os enlaces e nós da rede. A lista de enlaces (E), a lista de nós (N), a lista
de grupos multicast (gruposmulticastgerados) e o dicionário mac map são as entradas desse algoritmo. A saı́da é o caminho completo da árvore multicast, intitulado
caminho completo, que o próprio algoritmo usa para configurar os fluxos em cada switch
da rede. A lista de grupos multicast é percorrida para criação e configuração de cada
Algoritmo 1: Algoritmo de cálculo de árvores multicast e estabelecimento de
rotas
Input: E, N, mac map, gruposmulticastgerados
Output: caminhosc ompletos
1 for grupo in gruposmulticastgerados do
2
end GM = descobre end(grupo)
3
raiz = descobre raiz(mac map, grupo)
4
sws destino = descobre dst(mac map, grupo)
5
melhores rotas = SP F multicast(raiz, N, E)
6
for rota in melhores rotas do
7
if rota[dst] in sws destino then
8
caminhos arvore.append(rota)
9
end
10
end
11
arvore multicast = remove redundancias(caminhos arvore)
12
caminhos completos =
acrescenta portas(mac map, arvore multicast)
instala f luxos(caminhos completos, end GM, raiz)
return caminhos completos
13 end
árvore multicast, como mostrado na linha 1. A função descobre end, na linha 2, descobre
qual o endereço MAC do grupo multicast. A função descobre raiz, na linha 3, com base
no map mac descobre qual o endereço MAC do nó raiz do grupo multicast e em qual
switch está conectado. É importante observar que serão considerados como raiz todos
os nós que possam emitir mensagens para o grupo multicast. A função descobre dst, na
linha 4, retorna uma lista com os switches que estão conectados a pelo menos um dos
membros do grupo, com as respectivas portas. Com os nós, os enlaces e a raiz do grupo
38
multicast, a função SP F multicast calcula todas as rotas mais curtas da raiz para cada
outro nó restante da rede, possı́veis nós receptores do grupo. Com isso, é criada uma lista
de caminhos mais curtos, intitulada melhores rotas. Conforme descrito na linha 6, as
rotas da lista melhores rotas que tiverem como destino os nós receptores do grupo são
armazenadas na lista caminhos arvore que, ao final, contém os melhores caminhos do
IED publicador até os IEDs receptores do grupo multicast. A lista caminhos arvore é
processada para remoção de redundâncias com a função remove redundancias. Essa
função gera a lista arvore multicast, contendo o caminho por qual os pacotes deverão
passar para alcançar todos os destinos daquele grupo, conforme linha 11. Para que as
tabelas dos switches possam ser configuradas, além do caminho é necessário o acréscimo
das portas por qual esse caminho está conectado. Essa tarefa é realizada pela função
acrescenta portas, que gera como saı́da a lista intitulada caminhos completos, contendo uma lista para cada switch com o seu número de identificação e as portas por onde
os pacotes serão encaminhados, ou seja, a tabela de fluxos que deverá ser configurada.
Por fim, o controlador pode configurar as tabelas de fluxos nos switches pertencentes à
lista caminhos completos criando assim a árvoremulticast do grupo em questão.
Cabe observar que o algoritmo proposto não busca a melhor árvore de cobertura,
mas a entrega mais rápida dos pacotes, tendo como métrica o número de saltos. Devido às
fortes restrições de atraso das mensagens GOOSE e SV, a proposta prioriza a velocidade
da entrega.
Detecção de Falhas: Este componente é chamado sempre que ocorre
mudanças na topologia da rede. Desta forma, sempre que um enlace cai, o componente
Detecção de Falhas chama o componente Multicast L2, o qual recalcula as árvores3 .
O componente e seu algoritmo são detalhados no Algoritmo 2. É importante notar que,
Algoritmo 2: Algoritmo de detecção de falhas e restauração da rede
Input: evento,E, N, mac map, gruposmulticastgerados,
caminhos completos
Output: caminhos completos
1 enlaces af etados = busca f alhas(evento,E,N)
2 grupos af etados, grupos nao af etados =
busca grupos(enlaces af etados, caminhos completos, gruposmulticastgerados)
3 novos grupos = multi tree(E, N, mac map, grupos af etados)
4 caminhos completos = novos grupos + grupos nao af etados
5 return caminhos completos
se a versão do OpenFlow suportar o Fast Failover, então existem pequenas alterações
nos Algoritmos 1 e 2. O Algoritmo 1, após calcular a árvore de distribuição para um
par (endereço MAC multicast, raiz), irá aumentar os custos de todos os enlaces utilizados
nessa árvore de cobertura e irá buscar uma nova árvore de distribuição na rede. Em seguida, essa nova árvore é adicionada como caminho para casos de falha na tabela de grupo
dos switches OpenFlow. É importante observar que o aumento do custo garante que uma
segunda árvore será encontrada, mesmo que não existam caminhos totalmente disjuntos.
3
Cabe observar que o comportamento desse componente varia de acordo com a versão do OpenFlow em
uso, de acordo com a disponibilidade ou não da tabela de grupo e do mecanismo de fast failover.
39
As modificações no Algoritmo 2 ocorrem apenas para apagar a rota original que está com
uma falha, de forma que a segunda opção se torne a rota principal. O Algoritmo, naturalmente, já buscará uma terceira opção de árvore de distribuição, para prevenir novas
falhas na rede. Ressalta-se que a rede deverá prover mais de um caminho, caso a rede só
tenha um caminho possı́vel, esse componente não se aplica. Maiores detalhes sobre os
algoritmos podem ser encontrados em [Lopes 2013].
5. Experimentos com ferramentas de emulação e Análise dos Resultados
Os componentes do SMARTFlow foram desenvolvido em Python e implementados no
controlador POX 0.1.0 na versão 1.0.0 do OpenFlow. Os experimentos foram emulados
usando o Mininet [Lantz et al. 2010] versão 2. O Mininet é uma plataforma flexı́vel para
emulação de redes OpenFlow que provê um ambiente de experimentação bem próximo do
real. Foi criado um módulo no Mininet que constrói topologias LAN de subestações, todas
distribuindo os IED uniformemente na rede. Este módulo também contém a classe que
chama os componentes do SMARTFlow para controlar a rede. Para esses experimentos,
focou-se na entrega do tráfego de mensagens GOOSE, que tem grande restrição de atrasos
nas redes das subestação. Para tanto, foi desenvolvido um gerador de mensagens GOOSE
na ferramenta Scapy para simular o tráfego dos IEDs. A duração dos experimentos foi
de 100 segundos para cada rodada, incluindo, neste tempo, a estabilização da rede, a
configuração dos fluxos, a troca de mensagens e o tempo da simulação. Foram variados
parâmetros como quantidade de IEDs na rede, quantidades de switches, tipo de topologia
e quantidade de IED por grupo multicast.
O ambiente foi emulado por meio de virtualização em um notebook com processador Intel Core i5-3210M, e 4GB de memória RAM. Os testes foram realizados com
três instâncias de máquinas virtuais simultâneas, cada uma delas com uma CPU virtual,
1024 MB de memória e executando o sistema operacional Ubuntu 11.10. Todos os resultados apresentam um intervalo de confiança de 95%. Para os experimentos, levou-se
em consideração os cenários tı́picos de subestação descritos na parte 1 da norma IEC
61850 [IEC 61850 ] onde é descrito o tamanho da subestação e sua importância no sistema. Em todos os casos, a quantidade de IEDs depende muito do projeto e funções
que serão utilizadas na subestação. Assumindo uma quantidade de 3 até 12 IEDs podese assumir que os testes englobam, senão todos, a maior parte dos cenários tı́picos em
subestações. Além disso, para todos os experimentos foram testadas topologias em anel
e estrela pois são as topologias encontradas em subestação. Os gráficos da Figura 2 apresentam o resultado para topologia em anel, já que esta apresentou uma carga de controle
um pouco mais alta do que a topologia em estrela. O cenário é composto por cinco grupos
multicast distintos e nove IEDs, distribuı́dos uniformemente entre os switches. A quantidade de switches variou de um a nove. Foram estimulados dez eventos na rede, gerando
tráfego GOOSE. A ideia consiste em criar cenários que representam desde pequenas até
grandes subestações.
Na Figura 2(a), nota-se que o atraso na rede controlada pelo SMARTFlow não
passou de 1,5 ms. Isso mostra que o SMARTFlow atende bem aos requisitos rı́gidos
de tempo da norma, que determinam atraso máximo de 3 ms para mensagens GOOSE,
mesmo em redes de subestação com grande número de switches. Além disso, verifica-se
que, na rede controlada pelos componentes reativos do controlador OpenFlow, o atraso
é muito superior, chegando a ser até 20 vezes maior que o atraso do SMARTFlow. Esse
40
1.0
1.5
2.0
Componente OpenFlow Reativo
Componente SMARTFlow
0
0.0
0.5
Carga de Controle (KB/s)
20
15
5
10
Atraso(ms)
25
30
Limiar temporal
Componente Smart Flow
1
3
5
7
9
1
Quantidade de switches
(a) Atraso na rede.
3
5
7
9
Quantidade de switches
(b) Carga de controle na rede após
estabilização.
Figura 2. Comparação ao se utilizar o SMARTFlow e o OpenFlow Nativo em uma
topologia em anel.
comportamento era esperado pela caracterı́stica reativa desses componentes, no qual cada
pacote de um novo fluxo que chega ao switch é enviado ao controlador. Quando o controlador identifica que é um pacote multicast, configura uma entrada de fluxo para enviar
o pacote para todas as portas de saı́da, já que o comportamento padrão dos switches é
tratar o multicast como broadcast. Todo esse processo, naturalmente, sobrecarrega a rede
e aumenta o atraso dos pacotes. Com isso, conclui-se que o componente padrão de encaminhamento do controlador OpenFlow não é adequado para o controle de mensangens
GOOSE, pois não garante os requisitos mı́nimos de atraso. A Figura 2(b), analisa a carga
de controle gerada na rede, assumindo um sistema estabilizado, ou seja, durante o comportamento padrão da subestação. Para isso, calculou-se toda a carga de pacotes de controle
na rede, como pacotes LLDP, packet in, packet out, etc. Em uma rede estabilizada, o
SMARTFlow apresenta uma carga de controle muito baixa, com valores muito próximos
de 0, pois a carga de controle da proposta se concentra, principalmente, na inicialização
da rede. Isso é importante, pois a rede não é sobrecarregada durante o seu funcionamento
normal, evitando o aumento dos atrasos para mensagens GOOSE e SV. Os valores mais
altos do OpenFlow se devem à troca de mensagens entre controlador e switches durante
todo o tempo.
Por fim, a Figura 3, apresenta os resultados da avaliação da carga total na rede,
incluindo a carga de controle no caso dos componentes OpenFlow. Além dos sistemas
anteriores, OpenFlow Nativo e SMARTFlow, acrescenta-se um sistema baseado em switches tı́picos. Para emular os switches tı́picos, criou-se um componente apenas para instalar proativamente regras que tratam o tráfego multicast como broadcast configurando os
fluxos proativamente. Desta forma, simula-se um switch comum, onde os fluxos já se encontram definidos encaminhando o pacote por todas as portas. O cenário considerou uma
LAN com 5 switches e uma quantidade de IEDs variando entre 3 e 12. Emulou-se dois
tipos de topologia, anel e estrela, cinco grupos multicast e dez eventos na rede elétrica,
em momentos aleatórios, que refletem em um aumento do tráfego GOOSE. Observa-se,
na Figura 3, que a carga total de dados no OpenFlow Nativo é um pouco mais alta do
41
200
150
100
50
Carga Total na Rede(KB/s)
Switch Típico
0
50
100
150
Switch Típico
0
Carga Total na Rede(KB/s)
200
3
6
9
12
3
Quantidade de IEDs
6
9
12
Quantidade de IEDs
(a) Topologia em Anel.
(b) Topologia em Estrela.
Figura 3. Carga total de dados na rede em função do aumento do número de
IEDs.
que a carga do switch tı́pico. Isso acontece pois, quando o componente reativo do OpenFlow emula switches tı́picos é acrescida à carga da inundação na rede a carga de controle
para setar o fluxo. Ressalta-se que, a carga de controle para este cenário é muito pequena
quando comparada a quantidade total de dados na rede e, com isso, o comportamento
das duas curvas é muito próximo. Além disso, verifica-se que o SMARTFlow diminui
a carga total na rede em até 44% para 12 IEDs na topologia em Anel. Isso acontece,
pois o SMARTFlow calcula uma árvore multicast para encaminhar os pacotes evitando a
inundação natural de switches tı́picos. Quando o pacote chega ao switch, ao invés de ser
encaminhado por todas as portas, é enviado apenas para a porta relativa a árvore multicast.
O tempo para recuperação de falha, mesmo sem a implementação do fast failover ficou em torno de 8ms. Esse experimento e outros resultados como os tempos para
configuração da rede, descoberta da rede, etc, são encontrados em [Lopes 2013].
Realizou-se também uma análise qualitativa comparando as caracterı́sticas das
soluções multicast de camada 2 com as caracterı́sticas da solução SMARTFlow. Os resulTabela 1. Comparação entre as atuais soluções multicast de camada 2 e a proposta SMARTFlow
Caracterı́sticas
Multicast Multicast GMRP SF 1.0
SF
tı́pico
Estático
Complexidade de configuração
Baixa
Alta
Média Baixa Baixa
Dependência de mensagens Join e leave
Não
Não
Sim
Não
Não
Consumo de Banda pelo tráfego de dados
Alto
Baixo
Baixo Baixo Baixo
Carga de Controle
Baixa
Baixa
Alta
Baixa Baixa
Inundação da Rede
Sim
Não
Não
Não
Não
Controle aprimorado do tráfego
Não
Não
Não
Sim
Sim
Simplicidade e Flexibilidade
Baixa
Baixa
Baixa
Alta
Alta
Convergência Rápida
Sim
Não
Não
Sim
Sim
Tempos de atraso na rede
Alto
Baixo
Baixo Baixo Baixo
42
tados são mostrados na Tabela 1, onde SF 1.0 refere-se ao SMARTFlow implementado no
arcabouço do OpenFlow versão 1.0, SF refere-se a implementação em versões superiores,
Multicast Tı́pico refere-se ao comportamento padrão de switches e Multicast Estático a
configuração da árvore de forma manual. Uma vantagem do SMARTFlow sobre o GMRP
é a ausência de mensagens de controle entre os switches. No GMRP, os switches são responsáveis por encaminhar pacotes e trocar mensagens de controle para montar a árvore
multicast. Isto cria uma sobrecarga extra em termos de consumo de banda, pois o controle de mensagens, como join e leave ou atualizações de árvores, são enviadas através
dos mesmos enlaces que o tráfego de dados. Além disso, no SMARTFlow, os IEDs são
automaticamente incluı́dos na árvore multicast com base no arquivo SCD, de modo que
não é necessário que os IED implementem protocolos multicast cliente ou que mensagens
de atualização da árvore sejam enviadas frequentemente. Mudanças na topologia de rede
são automaticamente detectadas no SMARTFlow, que desencadeia a reconfiguração das
árvores multicast.
6. Conclusões
A norma IEC 61850 tem ganhado cada vez mais espaço, sendo implantada em novas
subestações trazendo inúmeros benefı́cios como redução de custos e de erros humanos,
automação, implementação de novas capacidade, dentre outros. Contudo, mesmo com a
inovação, ainda existem problemas a serem resolvidos. Esse trabalho identificou e abordou alguns desses problemas, assim como propôs, desenvolveu e avaliou um serviço de
gerenciamento e encaminhamento autoconfigurável para redes IEC 61850 baseada em
uma técnica promissora que tem possibilitado um controle mais flexı́vel, o OpenFlow. A
proposta, chamada SMARTFlow, diminuiu a carga total da rede gerada pelo OpenFlow
Nativo e pelo switch de camada 2 tı́pico em até 44% no cenário apresentado. Os testes
mostraram, também, que o atraso na rede controlada pelo OpenFlow em sua forma habitual chegou a ser até 20 vezes maior do que a rede controlada pelo SmartFlow, passando
de 20ms. Contudo, o atraso na rede controlada pela proposta SMARTFLow não ultrapassou 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 requisitos
impostos pela norma IEC 61850 ao usar as aplicações desenvolvidas como uma prova
de conceito. Além disso, o uso de multicast com um controle centralizado e com dados
oriundos do arquivo SCD permitem que sejam usados IEDs mais simples e também reduz
o tráfego de controle, o tempo de convergência dos algoritmos de controle e o atraso de
entrega de dados, quando comparado com os protocolos habituais.
Como trabalhos futuros, pretende-se implantar a proposta em uma rede real OpenFlow, e em uma rede tradicional para uma análise mais profunda. Uma outra questão é o
estudo, desenvolvimento e implementação do SMARTFlow nos IEDs que possuem switches embarcados para a construção de topologias em anel. Portanto, seria necessária a
implementação do OpenFlow nesses switches embarcados e a realização de testes de desempenho utilizando o SMARTFlow. Pode-se também investigar, implementar e avaliar
a proposta em um contexto entre subestações, podendo inclusive estender a pesquisa para
às Smart Grids como um todo. Além disso, pretende-se validar a recuperação de falhas
do SMARTFlow implantando também o fast failover.
Referências
[Cahn et al. 2013] Cahn, A., Hoyos, J., Hulse, M., and Keller, E. (2013). Software-defined energy
communication networks: From substation automation to future smart grids. In Smart Grid
Communications (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., and
Hancke, G. (2011). Smart grid technologies: Communication technologies and standards. IEEE
Transactions on Industrial Informatics, 7(4):529–539.
[IEC 61850 ] IEC 61850. Communication networks and systems for power utility automation. Technical report, International Electrotechnical Commission (IEC).
[Ingram et al. 2011] Ingram, D., Schaub, P., and Campbell, D. (2011). Multicast traffic filtering
for sampled value process bus networks. In IECON 2011 - 37th Annual Conference on IEEE
Industrial Electronics Society, pages 4710–4715.
[Lantz et al. 2010] Lantz, B., Heller, B., and McKeown, N. (2010). A network in a laptop. In
Proceedings 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 Autoconfigurável para Redes de
Telecomunicaçőes IEC 61850 com arcabouço OpenFlow. Mestrado em Engenharia de
Telecomunicaçőes, Universidade Federal Fluminense, UFF.
[Lopes et al. 2012] Lopes, Y., Frazão, 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 Telecomunicações para o Sistema Elétrico. In Minicursos do
XXX Simpósio Brasileiro de Telecomunicaçőes, pages 1–44. (SBrT), Sociedade Brasileira de
Telecomunicações, 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 programmable
networks. In 2012 IEEE Symposium on Computers and Communications (ISCC), pages 94–
101.
[McGhee and Goraj 2010] McGhee, J. and Goraj, M. (2010). Smart High Voltage Substation Based
on IEC 61850 Process Bus and IEEE 1588 Time Synchronization. In Smart Grid Communications (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 campus
networks. SIGCOMM Computer Communication Review, 38(2):69–74.
[Moore et al. 2010] Moore, R., Midence, R., and Goraj, M. (2010). Practical experience with IEEE
1588 high Precision Time Synchronization in electrical substation based on IEC 61850 Process
Bus. In Power 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 segmentation in substation automation systems. In Emerging 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. In
Computer Networks.
[Tan and Luan 2011] Tan, J. C. and Luan, W. (2011). IEC 61850 based substation automation system
architecture design. In Power 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 of
DSAS in China. In Advanced Power System Automation and Protection (APAP), 2011 International 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 network
transmission of process bus based upon IEC 61850. In Advanced Power System Automation
and 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: DViNE 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 podese 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
E7300 @ 2.66GH; Placa de
configurações: CPU Intel(R) Core(TM)2 Duo CPU
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 Modificação da VMM-MIB para o
Gerenciamento de Roteadores Virtuais
Paulo R. P. Ferraz S.1 , Rafael P. Esteves1 , Lisandro Z. Granville1
1
Instituto de Informática – Universidade Federal do Rio Grande do Sul (UFRGS)
Av. Bento Gonçalves, 9500 – Porto Alegre, RS – Brasil
{paulo.ferraz, rpesteves, granville}@inf.ufrgs.br
Abstract. In network virtualization environments (NVEs), the physical infrastructure is shared among different users (or service providers), which create
multiple virtual networks. Virtual Routers (VRs) are created inside physical
routers supporting virtualization. The management of NVEs is currently deficient because of the lack of standard management solutions for heterogeneous
substrates. Thus, the most natural choice is to use SNMP, the de facto network
management protocol. The first approach to manage VRs using SNMP, the VRMIB, did not progress in the standardization path, leaving the area with no
SNMP-based solution. Recently, IETF has proposed a VMM-MIB for virtual
machine 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 propose
a VR management interface based on the extended VMM-MIB that can be used
to instantiate software-based VRs inside a virtualization plataform. We evaluate
the proposed management interface in terms of response time and CPU/memory
consumption.
Resumo. Em ambientes de virtualização de redes (NVEs), a infraestrutura
fı́sica é compartilhada entre diferentes usuários (ou prestadores de serviços),
que criam múltiplas redes virtuais. O gerenciamento de NVEs é atualmente deficiente, devido à falta de soluções padrões para substratos heterogêneos. Assim,
a escolha mais natural é a utilização do SNMP, o protocolo de gerenciamento de
rede de fato. A primeira abordagem para o gerenciamento de VRs, a VR-MIB,
não progrediu no caminho da padronização, deixando a área sem solução baseada em SNMP. Recentemente, o IETF propôs a VMM-MIB para gerenciamento
de máquina virtual, que pode ser estendida a fim de dar suporte ao gerenciamento de VRs. Neste artigo, propomos extensões para VMM-MIB para permitir
o gerenciamento de VRs. Estas extensões permitem a configuração completa de
VRs. Além disso, propomos uma interface de gerenciamento de VRs baseada
na VMM-MIB estendida que pode ser usada para instanciar VRs baseados em
software dentro de uma plataforma de virtualização. Nós avaliamos a interface
de gerenciamento proposta em termos do tempo de resposta e do consumo de
CPU/memória.
61
1. Introdução
A virtualização de redes surgiu como alternativa viável para auxiliar no desenvolvimento
de novas arquiteturas de rede e para ajudar a superar a ossificação da Internet [Anderson
et al. 2005]. Em um ambiente de virtualização de redes (em inglês, Network Virtualization Environment – NVE) as infraestruturas fı́sicas, chamadas de substrato, são compartilhadas entre diferentes usuários (ou provedores de serviço) que criam múltiplas redes
virtuais, cada uma delas utilizando protocolos, esquemas de endereçamento e polı́ticas
independentes. Ao contrário da virtualização de servidores, que normalmente está localizada nos nós de borda de um ambiente de rede, a virtualização de redes ocorre principalmente no núcleo. Dessa forma, roteadores virtuais são criados e hospedados dentro de
roteadores fı́sicos, possibilitando que várias redes independentes funcionem simultaneamente, de forma isolada, sobre uma única infraestrutura fı́sica [Chowdhury and Boutaba
2009].
Atualmente, NVEs são gerenciados por meio de interfaces de linha de comando
não padronizadas (em inglês, Command Line Interface -– CLI) ou através de ferramentas de gerenciamento proprietárias. Sendo assim, o gerenciamento de NVEs construı́dos
sobre substratos fı́sicos heterogêneos (i.e., com equipamentos e tecnologias diferentes)
fica prejudicado, pois várias ferramentas independentes são necessárias para realizar uma
tarefa de gerenciamento, como por exemplo, criar uma rede virtual. Para minimizar a dificuldade de gerenciar um conjunto diversificado de recursos fı́sicos, interfaces de gerenciamento padronizadas devem ser definidas e avaliadas para permitir a interoperabilidade
das diferentes plataformas de virtualização com as ferramentas de gerenciamento. Além
disso, redes virtuais podem ser construı́das a partir de substratos localizados em domı́nios
administrativos distintos [Chowdhury and Boutaba 2010] e precisam ser gerenciadas adequadamente. Assim, neste contexto, a escolha de um protocolo de gerenciamento capaz
de operar de forma eficiente e escalável roteadores fı́sicos que hospedam roteadores virtuais é essencial.
Interfaces de gerenciamento apropriadas devem permitir que os provedores de
infraestrutura (InPs – Infraestructure Providers) e de serviços (SPs – Service Providers)
possam acessar, operar, manter e administrar os nós e enlaces fı́sicos e virtuais [Esteves
et al. 2013]. Em se tratando de interfaces baseadas em SNMP, existe a necessidade
de 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 de
Roteadores Virtuais (VRs – Virtual Routers), denominada VR-MIB [Stelzer et al. 2003].
Apesar de diversas atualizações, a VR-MIB não se tornou um padrão e está expirada
desde 2006. No entanto, recentemente, foi proposta uma MIB para o gerenciamento de
Máquinas Virtuais (VMs), denominada VMM-MIB, mas sua proposta original não prevê
o suporte necessário à configuração de VRs.
O objetivo deste artigo é propor um conjunto de extensões à VMM-MIB para que
esta possa suportar o gerenciamento pleno de roteadores virtuais. Nossa abordagem é
baseada na utilização de roteadores virtuais baseados em software que podem ser emulados em máquinas virtuais. Sendo assim, as extensões propostas consistem de objetos da
VR-MIB adaptados para a VMM-MIB que permitem a configuração de VRs. Além disso,
definimos um modelo de gerenciamento para NVEs baseado no SNMP e na plataforma
de gerenciamento XenServer [XenServer 2013].
62
O restante deste artigo está organizado da seguinte forma. Na Seção 2, são descritas as MIBs VR-MIB e VMM-MIB, seus objetos e suas funcionalidades. Na Seção 3,
apresentamos a proposta de modificação da VMM-MIB, mostrando os objetos incluı́dos
e os alterados. Nas Seção 4, é feita a avaliação da principal funcionalidade agregada à
VMM-MIB, a criação de VRs. Finalmente, na Seção 5, concluı́mos o artigo e apresentamos direções para trabalhos futuros.
2.1. VR-MIB
Uma das primeiras iniciativas para o gerenciamento de redes com roteadores virtuais foi
a Virtual Router Management Information Base (VR-MIB) [Stelzer et al. 2005]. A VRMIB foi proposta em 2001, originalmente para a gerência de VPNs (Virtual Privated
Networks) de camada 3, mas foi descontinuada em 2006 e não chegou a ser padronizada.
A VR-MIB define objetos para armazenar estatı́sticas e permitir a configuração
de alto nı́vel de roteadores virtuais, como criação, remoção e o mapeamento entre os
roteadores virtuais e suas interfaces de rede virtuais.
O gerenciamento de roteadores virtuais necessita de objetos para possibilitar a
configuração de VRs, a coleta de estatı́sticas de VRs e a associação de interfaces de rede
virtuais com as fı́sicas [Daitx et al. 2011]. Na VR-MIB mais atual (L3VPN-VR-MIB
versão 4), esses 3 grupos de informações foram definidos, respectivamente, como: vrConfig, vrStat e vrIfConfig.
O grupo vrConfig, mostrado na Figura 1(a), contém informações sobre indexação,
criação e exclusão de VRs. Para ajudar a estação de gerenciamento na atribuição de um
novo VR sem conflito, o próximo identificador de VR disponı́vel pode ser recuperado
acessando o objeto escalar vrConfigNextAvailableVrId do dispositivo gerenciado. Cada
configuração de roteador virtual é armazenada em uma linha da tabela vrConfigTable,
que contém um identificador único (vrId), o nome do VR (vrName) e o status da linha
(vrRowStatus), sendo este último usado para criar e excluir os roteadores virtuais. Além
disso, essa tabela contém informações sobre configurações internas de cada dispositivo
virtual, como o identificador de VPN (vrVpnId), o número máximo de rotas virtuais suportadas (vrMaxRoutes) e um gatilho para ligar ou desligar os protocolos de roteamento
(vrRpTrigger).
O grupo vrStat, mostrado na Figura 1(b), contém 2 objetos escalares com
informações globais de dispositivos, como o número de VRs configurados em cada nó
(vrConfiguredVRs) e o número de VRs ativos na rede (vrActiveVRs). Além disso, este
grupo contém uma tabela chamada vrStatTable, que possui os status administrativo e
operacional de cada VR. Essa tabela contém diversas estatı́sticas como: o número atual
de entradas de rota (vrStatRouteEntries), o número de entradas na FIB (Forwarding Information Base) (vrStatFIBEntries), o tempo decorrido após o VR entrar em operação
(vrStatUpTime), o status operacional do VR (vrOperStatus), o tipo e o endereço IP de
uma das interfaces do VR (vrRouterAddressType e vrRouterAddress).
O grupo vrIfConfig, mostrado na Figura 1(c), é composto por uma tabela usada
para a configuração de interfaces de VRs (vrIfConfigTable). Esta tabela contém todas
as associações 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 vrConfigTable, interfaces de roteadores virtuais podem ser criadas, excluı́das ou modificadas editando-se a variável vrIfConfigRowStatus. Este objeto é usado para acionar as
operações de criação e remoção ou para definir o estado de operação de cada uma das
interfaces virtuais de VRs. A fim de definir uma nova interface de VR, o agente SNMP
primeiro verifica se o VR está disponı́vel e, em seguida, verifica se a interface de rede
escolhida está disponı́vel.
(a) Grupo vrConfig
(b) Grupo vrStat
(c) Grupo vrIfConfig
(d) Grupo vrNotificationsPrefix
Figura 1. Grupos de informações da VR-MIB
Além dos três grupos supracitados, o grupo vrNotificationsPrefix (Figura 1(d))
permite que o gerente ative ou desative traps manipulando a variável vrTrapEnable da
tabela vrConfigTable. Esse grupo é formado pelas traps: vrUp, vrDown e vrMaxRoutesExceeded.
A principal desvantagem da VR-MIB é que ela deixou de ser atualizada em 2006,
fato que desencoraja sua utilização em projetos atuais. Também não há MIB que substitua
suas funcionalidades no que diz respeito à configuração de roteadores virtuais. Sendo
assim, a solução mais rápida para este problema é procurar uma MIB atual que possa
absorver as funcionalidades da VR-MIB.
2.2. VMM-MIB
Em julho de 2012, foi proposta no IETF, como Internet Draft, uma MIB voltada para o
gerenciamento de Máquinas Virtuais (VMs – Virtual Machines) controladas por um hy-
64
pervisor, com o tı́tulo de Management Information Base for Virtual Machines Controlled
by a Hypervisor, ou simplesmente VMM-MIB [Asai et al. 2013].
Um hypervisor, também conhecido como monitor de máquina virtual, controla
várias máquinas virtuais em uma única máquina fı́sica, alocando recursos para cada VM
usando tecnologias de virtualização. Portanto, este módulo MIB contém informações
sobre as máquinas virtuais e seus recursos controlados por um hypervisor, bem como
informações de hardware e software do mesmo.
O projeto desta MIB foi derivado de módulos MIB especı́ficos de empresas, como
Xen e VMWare, e de um módulo MIB que usava a interface de programação libvirt para
acessar diferentes hypervisors. No entanto, esta MIB tenta generalizar os objetos gerenciados para suportar outros hypervisors.
A VMM-MIB possui informações relativas ao sistema e software de um hypervisor, a lista de máquinas virtuais controladas, e recursos virtuais alocados para máquinas
virtuais. Sobre este último, são especificados nessa MIB quatro tipos especı́ficos de recursos virtuais comuns a todos os hypervisors: CPUs (processadores), memória, interfaces
de rede e dispositivos de armazenamento. A Figura 2 esquematiza os recursos fı́sicos e
virtuais dentro do hypervisor, e destaca o agente SNMP, que é responsável por manter a
MIB informada.
Figura 2. Alocação de recursos virtuais
A VMM-MIB está organizada em um grupo de nove escalares e cinco tabelas. Os
escalares organizados sob vmHypervisor (Figura 3) fornecem informações básicas sobre
o hypervisor, como a descrição do software (vmHvSofteare), a versão (vmHvVersion),
o identificador (vmHvObjectID) e o tempo desde que o hypervisor foi reinicializado
(vmHvUpTime). Os demais objetos escalares são: o vmNumber, que contém o número
de VMs no hypervisor; o vmTableLastChange, que é valor do vmHvUpTime da última
criação ou exclusão de entrada na vmTable; o vmPerVMNotificationsEnable, que habilita a geração de notificações por VMs; o vmBulkNotificationsEnable, que é semelhante
ao anterior, mas para conjuntos de VMs; e o vmAffectedVMs, que contém a lista de VMs
que tiveram seu estado alterado.
Em relação às tabelas, temos: a vmTable (Figura 4(a)), que lista as VMs que
são 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 (Figura
4(b)), que fornece a lista de dispositivos de armazenamento virtual e seu mapeamento
com máquinas virtuais; a vmCpuTable (Figura 4(c)), que fornece o mapeamento entre
CPUs virtuais para máquinas virtuais; e a vmNetworkTable (Figura 4(d)), que fornece
a lista de interfaces de rede virtuais e seu mapeamento para máquinas virtuais. As tabelas vmTable e vmNetworkTable, por serem mais relevantes para este trabalho, serão
descritas com mais detalhes.
A tabela vmTable, mostrada na Figura 4(a), contém diversas informações sobre
as VMs, sendo que as principais para este trabalho são: um identificador único da VM
(vmIndex), o nome da VM (vmName), o estado administrativo (vmAdminState), o estado operacional da VM (vmOperState), o número atual, mı́nimo e máximo de CPUs
atribuı́das à VM (vmCurCpuNumber, vmMinCpuNumber e vmMaxCpuNumber) e o
tamanho atual, mı́nimo e máximo de memória alocada para a VM (vmCurMem, vmMinMem e vmMaxMem). O objeto vmAdminState é um parâmetro que define o modelo
de estado administrativo da VM e, por isso, tem permissão read-write. Da mesma forma,
por serem parâmetros de configuração, também possuem permissão de acesso read-write
os objetos supracitados relacionados com CPU e memória. Os demais objetos da tabela
têm acesso read-only.
A tabela vmNetworkTable, mostrada na Figura 4(d), contém informações de interfaces de redes virtuais, como um identificador único (vmNetworkIndex), um ponteiro
para 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 interface de rede fı́sica pai correspondente (vmNetworkParent), o modelo de interface
emulado pela interface de rede virtual (vmNetworkModel), e o endereço fı́sico (MAC
Address) (vmNetworkPhysAddress).
Eventos que causam transições entre os principais estados operacionais geram
notificações (traps). A VMM-MIB define dois tipos de notificações: as notificações individuais (per-VM) e as notificações em massa (bulk). As per-VM levam informações
mais detalhadas, contudo a escalabilidade pode ser um problema. Já o mecanismo de
notificação em massa tem o objetivo de reduzir o número de notificações que são capturadas por um gerente SNMP. As notificações per-VM, definidas pelos objetos listados
na Figura 5(a), são geradas se vmPerVMNotificationsEnable for verdadeiro. De modo
análogo, as notificações em massa, definidas pelos objetos da Figura 5(b), são geradas se
vmBulkNotificationsEnabled for verdadeiro.
3. Proposta de modificação da VMM-MIB
A idéia da proposta é agregar à VMM-MIB todas as funcionalidades da VR-MIB, sem que
a primeira perca suas funcionalidades originais. Inicialmente, percebe-se que os escopos
66
(a) Tabela vrTable
(b) Tabela vmStorageTable
(c) Tabelas vmCpuTable e vmCpuAffinityTable
(d) Tabela vmNetworkTable
Figura 4. Tabelas da VMM-MIB
das MIBs supracitadas são diferentes, pois uma se refere a máquinas virtuais e a outra a
roteadores virtuais. Felizmente, roteadores podem ser emulados por softwares, como por
exemplo, o Vyatta [Vyatta 2013]. Sendo assim, máquinas virtuais executando o Vyatta
podem ser consideradas, para todos os efeitos, um roteador virtual. Para isso, basta que
o hypervisor seja executado dentro do roteador fı́sico. Desse modo, não há problema
em utilizar a VMM-MIB como base para uma MIB que possua as funcionalidades de
gerenciamento de VRs desejadas.
Inspirada na VR-MIB, esta proposta acrescenta à VMM-MIB duas tabelas para
configuração de VMs (ou VRs): a vmConfigTable, que permitirá a criação/remoção de
VMs; e a vmNetworkConfigTable, que permitirá a criação/remoção de interfaces de rede
virtais e a associação com as fı́sicas (binding). Além disso, três objetos escalares, para
fins de controle, são incluı́dos: vmConfigNextAvailableVmIndex, vmConfiguredVMs
e vmActiveVMs, com as mesmas funções dos objetos da VR-MIB vrConfigNextAvailableVrId, vrConfiguredVRs e vrActiveVRs, respectivamente. A Figura 6 mostra, em
67
(a) Notificações per-VM
(b) Notificações em massa
Figura 5. Objetos de notificação 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 contém objetos com as mesmas funcionalidades dos objetos da tabela vrConfigTable da VR-MIB. Além disso, nesta proposta, os
objetos da tabela vmTable da VMM-MIB que possuı́am permissões read-write são migrados para a vmConfigTable, pois esta tabela deve conter todos os objetos de configuração
de uma nova VM. Nesta migração, as permissões de acesso read-write são trocadas
para read-create, de forma a permitir a criação de novas entradas na tabela. Para evitar duplicação, os objetos vmIndex e vmName são retirados da tabela vmTable, posto
que agora eles pertencem à vmConfigTable. A Figura 7 mostra a tabela vmConfigTable
proposta e a origem de seus objetos.
A tabela vmNetworkConfigTable proposta contém objetos com as mesmas funcionalidades dos objetos da tabela vrIfConfigTable da VR-MIB. Só com esses objetos
já é possı́vel agregar as funcionalidades de criação e remoção de interfaces de rede virtuais, porém 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 interface
virtual à fı́sica (binding). Para permitir a criação de entradas na tabela, seus objetos têm
permissão read-create. A Figura 8 mostra a tabela vmNetworkConfigTable proposta e a
origem de seus objetos.
Figura 8. Objetos da tabela vmNetworkConfigTable proposta
Com a inclusão das tabelas vmConfigTable e vmNetworkConfigTable na VMMMIB, já é possı́vel obter as funcionalidades de configuração de alto-nı́vel de roteadores
virtuais oferecidas pela VR-MIB, porém, para abranger todas as informações estatı́sticas
de roteadores virtuais, faz-se necessário, ainda, incluir na proposta objetos equivalentes
aos da tabela vrStatTable da VR-MIB. Sendo assim, a tabela vmTable da nova VMMMIB deve conter os objetos originais, exceto aqueles migrados para a tabela vmConfigTable, e os novos objetos vmRouteEntries, vmFIBEntries, vmRpState, vmLoopbaclAddressType e vmLoopbackAddress, com as mesmas funções dos objetos da VR-MIB
vrStatRouteEntries, vrStatFIBEntries, vrRpStatus, vrRouterAddressType e vrRouerAddress, respectivamente. A Figura 9 mostra a tabela vmTable proposta e a origem de
seus novos objetos.
Com relação às notificações (traps), temos que a VMM-MIB possui uma grande
quantidade de objetos referentes aos estados operacionais das VMs. Sendo assim, as
notificações vrUp e vrDown da VR-MIB já são abrangidas pela VMM-MIB, ainda que
de forma mais detalhada. O único objeto de notificação 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 notificação especı́fica de roteadores, onde é informado que o número
máximo de rotas foi excedido.
Nesta proposta, a tabela vmNetworkTable teve dois objetos migrados para a vmNetworkConfigTable, portanto agora, esta tabela tem apenas os objetos vmNetworkModel e vmNetworkPhysAddress, conforme mostrado na Figura 10. As tabelas vmCpuTable, vmCpuAffinityTable e vmStorageTable permanecem inalteradas.
Figura 10. Objetos da tabela
4. Avaliação
Das diversas funcionalidades agregadas à VMM-MIB com as modificações propostas, a
criação de VRs é a mais significativa, pois a mesma não é atualmente contemplada pela
VMM-MIB original. Sendo assim, esta seção, apresentada a avaliação desta operação em
uma interface de gerenciamento baseada no SNMP.
4.1. Interface de Gerenciamento
A interface de gerenciamento implementada utiliza a comunicação gerente-agente
do SNMPv2, conforme ilustrado na Figura 11. Para a criação de um VR, o gerente SNMP envia uma mensagem set-request (T1) carregando as informações necessárias para o agente criar o VR (i.e., vmRowState, vmName, vmContextName,
vmTrapEnable, vmAdminState). Como reação, o agente emite uma requisição CLI
(T2) ao hypervisor que efetivamente cria o roteador virtual (e.g., xe vm-install
new-name-label=<vm-name> template=vyatta, no caso do XenServer).
70
Como a ação do lado do roteador pode durar um tempo indefinido, o set-request é imediatamente respondido com uma mensagem get-response (T3). Quando a operação solicitada termina, uma mensagem de trap é emitida (T5), por um gerador de traps em execução
dentro 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. Descrição do Ambiente
Os experimentos foram executados em um computador com processador Intel Core 2
Quad 2,4GHz com 4GB de memória RAM. Este computador foi configurado de modo
a emular, para fins de avaliação, um roteador fı́sico. A plataforma de virtualização (hypervisor) utilizada foi o Citrix XenServer 5.6 [XenServer 2013]. O template utilizado na
criação de roteadores virtuais foi o Vyatta [Vyatta 2013].
O módulo VMM-MIB proposto, discutido na seção 3, foi compilado, instrumentado e adicionado ao agente disponibilizado no pacote NET-SNMP 5.5 (snmpd) [NETSNMP 2013]. Operações SNMP são materializadas através de aplicações do pacote NETSNMP correspondentes as mensagens do protocolo, e.g., snmpset, snmpget e snmpgetbulk. Estas aplicações foram utilizadas para implementar o gerente SNMP. Além disso, a
interface de gerenciamento foi avaliada utilizando-se a versão 2 do SNMP que é a versão
mais popular do protocolo.
4.3. Resultados
O componente em estudo é a interface de gerenciamento descrita na seção 4.1, que
tem como principal serviço a criação de VRs. Foram escolhidas duas métricas para a
avaliação: tempo de resposta e consumo de recursos pelo agente SNMP (CPU e memória).
O tempo de resposta reflete o tempo médio da criação de VRs na solução de gerenciamento proposta. A utilização de CPU e de memória RAM do roteador fı́sico ilustra o
impacto das operações de gerenciamento nos recursos do roteador fı́sico.
A carga de trabalho consiste na criação de um VR adicional quando um número de
VRs previamente criados está ativo (i.e., em operação). O sistema começa sem nenhum
VR e a cada nova requisição é criado um novo VR que permanece ativo, até que se atinja
o total de 10 VRs ativos. A restrição de 10 VRs ativos se dá pelo fato de que esse foi o
limite máximo suportado pela máquina utilizada nos testes.
Para esta avaliação foram conduzidos experimentos no ambiente de teste descrito,
utilizando a medição como técnica de avaliação. Cada experimento foi repetido 30 ve-
71
zes sob as mesmas condições, a fim de se obter as médias populacionais com os seus
respectivos intervalos de confiança. Para isto, foi utilizado um nı́vel de confiança de 95%.
A Figura 12 ilustra o tempo de resposta (em segundos) na criação de 1 VR quando
um número variável de VRs (0 até 10) está ativo.
3.65
XenServer
3.6
Tempo de resposta [segundos]
3.55
3.5
3.45
3.4
3.35
3.3
3.25
3.2
3.15
1
2
3
4
5
6
7
8
9
10
Número de Roteadores Virtuais ativos
Figura 12. Criação de Roteador Virtual
É possı́vel observar que, de uma maneira geral, o tempo de resposta cresce quando
o número de VRs ativos aumenta. Isso acontece pelo fato de que os VRs ativos compartilham e consomem recursos da máquina fı́sica (CPU e memória), que estarão disponı́veis
em menor quantidade nas próximas requisições, o que influencia no aumento do tempo
de resposta na criação de um novo VR. A exceção ocorre para quando 10 VRs estão
ativos. O que ocorre aqui é que a máquina fı́sica não consegue suportar a carga de 10
VRs ativos simultaneamente (por falta de memória) e o hypervisor suspende alguns VRs
arbitrariamente.
Em seguida, foi avaliado o consumo de CPU e memória pelo agente SNMP
(snmpd). Verificou-se que o tempo de CPU do agente SNMP não apresenta mudanças
significativas quando o número de VRs ativos aumenta até 10 VRs, permanecendo na ordem de 40 millissegundos, o que indica que o agente é capaz de armazenar dados de 10
VRs sem prejuı́zo significativo. A Figura 13 mostra o consumo de memória do agente
SNMP na criação de VRs.
Os resultados da Figura 13 mostram o percentual de consumo de memória do
agente SNMP em relação ao total disponı́vel na máquina fı́sica quando um novo VR criado, variando o número de VRs ativos. Novamente, o consumo de memória do agente
cresce quando o número de VRs ativo cresce. A primeira razão é que a quantidade de
memória disponı́vel na máquina fı́sica diminui a cada novo VR criado, e, consequentemente, a relação entre a memória requerida pra processar uma mesma mensagem setrequest em relação ao total disponı́vel também diminui. A segunda razão se deve ao fato
de que o agente precisa armazenar uma quantidade de informações cada vez maior a cada
novo VR, o que exige mais memória do agente SNMP.
72
0.909
XenServer
0.908
0.907
Memória consumida [%]
0.906
0.905
0.904
0.903
0.902
0.901
0.9
0.899
1
2
3
4
5
6
7
8
9
10
Número de Roteadores Virtuais ativos
Figura 13. Consumo de Memória RAM
5. Conclusão
Neste trabalho foi apresentada uma proposta de modificação da VMM-MIB para tornar esta MIB funcional para o gerenciamento de roteadores virtuais em ambientes de
virtualização de redes (NVEs). A VMM-MIB é uma proposta recente, que vem sido atualizada desde 2012. Sendo assim, optou-se por agregar funcionalidades propostas para a
VR-MIB à VMM-MIB e, assim, permitir a criação de roteadores virtuais.
Todos os objetos da vrConfigTable da VR-MIB foram incluı́dos na nova tabela
vmConfigTable da VMM-MIB, com os nomes devidamente adaptados para o padrão da
VMM-MIB, mas mantendo-se as permissões originais (read-create). Da mesma forma,
todos os objetos da tabela vrIfConfigTable da VR-MIB foram adicionados à nova tabela
vmNetworkConfigTable da VMM-MIB. Além disso, todos os objetos escalares da VRMIB foram incluı́dos na nova VMM-MIB, de forma a permitir o controle dessas tabelas
da mesma maneira que na VR-MIB. Para não perder as informações estatı́sticas dos roteadores virtuais criados, também foram incluı́dos na tabela vmTable da proposta todos os
objetos da tabela vrStatTable, apesar de alguns deles já existirem na VMM-MIB original.
Uma interface de gerenciamento baseada nas extensões propostas para a VMMMIB foi implementada e avaliada. Os resultados mostram que a memória é o recurso
que exerce maior influência sobre o tempo de resposta de uma operação de criação de
VRs. Quando o número de VRs aumenta, o agente SNMP consome mais memória, o que
impacta no tempo necessário para a criação de novos VR. O consumo de CPU do agente
SNMP não se mostrou significativo e não tem grande influência no tempo de resposta.
Como trabalhos futuros, pretende-se avaliar outras operações de gerenciamento
como recuperação do estado de VRs, remoção e cópia de VRs, além de adaptar a VMMMIB estendida para outros protocolos de gerenciamento como NETCONF e Web services.
Referências
Anderson, T., Peterson, L., Shenker, S., and Turner, J. (2005). Overcoming the internet
impasse 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 Controlled
by 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 art
and 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 interface for virtual networks. In Integrated Network Management (IM), 2011 IFIP/IEEE
International Symposium on, pages 177–184.
Esteves, R., Granville, L., and Boutaba, R. (2013). On the management of virtual
networks. Communications Magazine, IEEE, 51(7).
McCloghrie, K. and Kastenholz, F. (2000). The Interfaces Group MIB. RFC 2863 (Draft
Standard).
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 Management
Information 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 Management
Information 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 de
2013.
XenServer (2013). Open source virtualization. http://www.xenserver.org/. Acessado em
outrubro de 2013.
74
Uma Análise Quantitativa do Tráfego de Controle
em Redes OpenFlow
Pedro Heleno Isolani, Juliano Araujo Wickboldt, Cristiano Bonato Both,
Juergen Rochol, Lisandro Zambenedetti Granville
1
Instituto 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 permite
facilmente projetar, desenvolver e implantar inovações de rede, pois fornece
agilidade e flexibilidade na incorporação de novos serviços e tecnologias. As
redes baseadas nesse paradigma ganharam destaque a partir da especificação
do protocolo OpenFlow, que define uma simples interface de programação para
controlar dispositivos de encaminhamento a partir de um controlador. Apesar da rápida disseminação desse protocolo, os trabalhos relacionados sobre
OpenFlow não analisam em profundidade os reais impactos das mensagens de
controle e monitoramento gerado por esse protocolo. Desta forma, a principal
contribuição deste artigo é uma análise quantitativa do tráfego de controle e
monitoramento em redes OpenFlow. Os resultados revelam que variações do
tempo limite de ociosidade das regras de encaminhamento, da frequência de
monitoramento e da topologia da rede, impactam na taxa de transferência e na
quantidade de mensagens geradas no canal de controle.
1. Introdução
Software-Defined Networking (SDN) é um paradigma de redes baseado em três aspectos fundamentais: (i) os planos de controle e encaminhamento são claramente desacoplados, (ii) a lógica da rede é abstraída de uma implementação em hardware para uma
camada de software programável e (iii) é introduzido um elemento controlador de rede
que coordena as decisões de encaminhamento dos demais dispositivos [Kim e Feamster
2013,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 e
implantadas, pois possibilita a agilidade e flexibilidade na incorporação de novos serviços
e tecnologias, sem que os fabricantes precisem expor o funcionamento interno de seus
equipamentos [McKeown et al. 2008].
As redes baseadas no paradigma SDN ganharam considerável destaque a partir da
especificação do protocolo OpenFlow, que define uma simples interface de programação
para controlar dispositivos de encaminhamento a partir de um controlador. Desta forma, a
lógica da rede é concentrada no controlador que troca mensagens para o estabelecimento
de conexões, monitoramento de estatísticas, manutenção e configuração do comportamento dos dispositivos da rede [Bari et al. 2013]. Sendo assim, o gerenciamento de rede
baseadas na especificação OpenFlow reduz, ou até mesmo elimina, problemas de gerenciamento 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 dispositivos precisam ser registrados no controlador para pertencerem à rede efetivamente.
75
Devido a abordagem centralizada da lógica da rede, utilizada pelo protocolo OpenFlow, muito tem sido discutido na literatura especializada acerca do posicionamento e
proporção de controladores em contraponto aos dispositivos de encaminhamento. Alternativas para distribuir a lógica da rede sobre os dispositivos de encaminhamento são
desenvolvidas visando evitar um possível gargalo de mensagens de controle no controlador [Roy et al. 2014,Curtis et al. 2011,Yu et al. 2010]. Entretanto, não são analisados em
profundidade os reais impactos das mensagens de controle e monitoramento gerado pelo
protocolo OpenFlow. A especificação desse protocolo apenas define quais e como são as
mensagens de controle (e.g. instalação de regras, coleta de estatísticas), mas não especifica como essas mensagens devem ser utilizadas para controlar e monitorar a rede sem
comprometer seu desempenho. Assim, as informações referentes a frequência em que
podem ser realizados o controle e monitoramento de estatísticas dos dispositivos da rede
não são especificadas. Desta forma, se torna fundamental a realização de uma análise para
identificar quais mensagens de controle e monitoramento mais impactam na sobrecarga
do 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 controle e monitoramento em redes OpenFlow. Essa análise é extremamente importante, pois
fornece subsídios para mensurar o uso efetivo do canal de controle e, a partir disso, melhor compreender e gerenciar o impacto real da utilização do protocolo OpenFlow. Essa
compreensão é fundamental para o projeto e desenvolvimento de novos sistemas de gerenciamento de redes baseadas no paradigma SDN. Para a obtenção dos resultados, foi
realizada uma experimentação considerando aspectos de instalação de regras, além da
obtenção de estatísticas através do monitoramento do controlador Floodlight [Big Switch
Networks 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 diferentes topologias de rede, estrela e árvore. Os resultados apresentam como a frequência
de monitoramento, as variações das topologias e configurações do controlador impactam
na 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 apresenta
a fundamentação teórica sobre SDN bem como sobre o protocolo OpenFlow. Na Seção
3 é descrito o cenário de experimentação e a metodologia de avaliação seguida como
prova de conceito. Na Seção 4 são discutidas e analisadas as informações abstraídas
da modelagem analítica e dos resultados da experimentação. Por fim, na Seção 5 são
apresentadas as conclusões e as perspectivas para trabalhos futuros.
2. Fundamentação Teórica
Nesta Seção são abordados os elementos que definem os principais conceitos de SDN
e OpenFlow, assim como é apresentada uma breve discussão da literatura em SDN. Na
Subseção 2.1 são descritos as principais entidades presentes em SDN e OpenFlow considerando a versão 1.0 do protocolo. Posteriormente, na Subseção 2.2 são abordados os
trabalhos relacionados sobre gerenciamento e, principalmente, distribuição do plano de
controle em SDN.
2.1. Software-Defined Networking e OpenFlow
SDN introduz uma perspectiva flexível para programar e manter a operacionalidade da
rede. 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 um
ou mais elementos controladores da rede [Kim e Feamster 2013, Tootoonchian e Ganjali
2010]. A arquitetura definida para SDN é dividida em camadas de aplicação, controle
e encaminhamento. A comunicação entre as camadas acontece através de Application
Programming Interfaces (APIs) de comunicação padrão. Redes que seguem o paradigma
SDN 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 serviços. Outro aspecto que também contribui para a larga adoção desse paradigma é a
liberdade de implementação e experimentação de novos protocolos sem se ater a detalhes
de implementações proprietárias dos dispositivos. SDN foi largamente utilizado após a
especificação do protocolo OpenFlow [McKeown et al. 2008] e, devido a flexibilidade e
interface simples de programação, surgiram diversas soluções tanto na academia como na
indústria.
O OpenFlow é um protocolo Open Source que utiliza uma tabela para armazenamento de regras de encaminhamento e uma interface padronizada para adicionar e remover 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 ou
parte dele, i.e. uma conexão lógica, normalmente, bidirecional entre duas máquinas terminais da rede. OpenFlow oferece programabilidade padronizada aos dispositivos de encaminhamento, permitindo desenvolver novos protocolos, e.g., protocolos de roteamento,
módulos de segurança, esquemas de endereçamento, alternativas ao protocolo IP, sem a
necessidade de ser exposto os funcionamentos internos dos equipamentos. Um switch
com suporte OpenFlow consiste basicamente em pelo menos três partes: uma tabela de
fluxos, onde são associadas actions para cada match; um canal seguro, por exemplo Secure Socket Layer (SSL); e o protocolo OpenFlow para comunicação entre controlador e
os switches.
O protocolo OpenFlow versão 1.0, abordado na análise deste trabalho e amplamente implementado pelos dispositivos com suporte a SDN, considera três tipos de mensagens 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 dos
dispositivos de encaminhamento (e.g., ler informações de estatísticas das tabelas de encaminhamento). As mensagens assíncronas são iniciadas pelos switches utilizadas para
informar 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 correspondente). Por fim, as mensagens simétricas podem ser iniciadas tanto pelo controlador
como pelos switches e são enviadas sem solicitação (e.g., echo request e reply para certificar que um dispositivo da rede está ativo). O detalhamento das mensagens é apresentado
na 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 encaminhamento Packet-In/Out e Modify-State são consideradas as mais relevantes, pois são mais
frequentemente 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 de
granularidade de um possível monitoramento periódico da rede.
77
Tipos
Mensagens
Features
Configuration
Modify-State
Controlador para o switch
Read-State
Send-Packet
Barrier
Packet-In
Assíncrona
Simétrica
Flow-Removed
Port-Status
Hello
Echo
Barrier
Descrição
Enviadas para obter conhecimento sobre as capacidades dos switches
Específicas para parâmetros de configuração dos switches
Gerenciam o estado dos switches, comumente utilizadas para adicionar,
remover e modificar fluxos nas tabelas e alterar propriedades de portas
Utilizadas para coletar estatísticas sobre as tabelas, portas, fluxos e filas dos
switches
Utilizadas pelo controlador para enviar pacotes por uma porta específica
Obtenção de conhecimento se as dependências das mensagens foram
alcançadas ou para receber notificações sobre tarefas concluídas
Enviadas ao controlador toda vez que o switch não tenha regra instalada para
determinado pacote ou quando a regra for para enviar o pacote ao controlador
Relativas a remoção de regras dos switches
Obtenção de status das portas dos switches
Para início de conexão entre switch e controlador
Estabelecimento de conexão entre switch e controlador e podem ser utilizadas
para obter conhecimento de latência, banda ou conectividade
Utilizadas para obter conhecimento se as dependências das mensagens foram
alcanç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 entre
o 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 comportamento da rede, sem que seja necessário recorrer a um único elemento controlador [Tootoonchian e Ganjali 2010]. Entretanto, ainda existem discussões sobre o gerenciamento
centralizado e distribuído do controle da rede, visto que, pode influenciar e comprometer
a disponibilidade do canal de controle [Levin et al. 2012]. Devido a esse fato, a análise realizada neste trabalho foi inspirada pela ausência de informação referente ao impacto das
mensagens de controle na configuração, manutenção e monitoramento dos dispositivos de
encaminhamento.
A solução apresentada por DevoFlow visa manter os fluxos no plano de encaminhamento, ou seja, faz com que os switches encaminhem os pacotes com o mínimo de
solicitações possíveis ao controlador [Curtis et al. 2011]. Quando uma regra não se encontra na tabela de regras de um switch, o comportamento padrão do OpenFlow é invocar
o 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 clonagem de regras, acionamento de actions locais e pela coleta de estatísticas. Para justificar
o propósito do trabalho, foram apresentadas estimativas de sobrecargas da utilização do
OpenFlow. Entretanto, o trabalho apresenta somente estimativas médias o que pode variar
dependendo do tipo da rede.
Uma solução semelhante ao DevoFlow é a apresentado por DIFANE, que visa
manter a lógica de controle próxima ao plano de encaminhamento, de forma a atribuir o
controle aos switches próximos ao controlador, chamados de switches de autoridade [Yu
et al. 2010]. Quando uma regra não se encontra na tabela de regras de um switch o
comportamento é invocar um switch de autoridade mais próximo. Ambos os trabalhos,
DevoFlow e DIFANE, apresentam informações relativas a sobrecargas geradas no controlador, mas não detalham sobre o impacto específico das mensagens trafegadas no canal
de controle.
78
A solução de Heller et al. [Heller et al. 2012] investiga o posicionamento e proporção de controladores necessários para atender ao plano de encaminhamento sem comprometer o desempenho da rede. Para estimar o consumo de banda utilizada no canal de
controle, foram estabelecidas as métricas de latência média e latência para o pior caso
para comunicação entre controlador e dispositivos de encaminhamento. Entretanto, o cálculo realizado para essa estimativa é aproximado conforme a distância dos nodos em um
grafo 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 a
quantidade de controladores necessários para determinada demanda da rede. Para realizar
essa adaptação é calculado um valor aproximado do tempo mínimo para instalação de
regras 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 gerenciamento
no contexto de OpenFlow versão 1.0. Portanto, a definição da quantidade de controladores necessários, posicionamento em relação aos dispositivos de encaminhamento e
granularidade de monitoramento aceitável podem ser estimadas e melhor abordadas pelos
sistemas de gerenciamento. Assim, pretende-se estimar o tráfego de controle para que não
comprometa o desempenho e a disponibilidade do canal de controle e, consequentemente,
o desempenho da rede.
3. Cenário e Metodologia de Avaliação
Nesta Seção é apresentado em detalhes o cenário de experimentação e a metodologia
utilizada para a análise quantitativa do tráfego de controle e monitoramento em redes
OpenFlow versão 1.0. As características sobre o cenário e as duas topologias utilizadas
na experimentação (estrela e árvore) são apresentadas na Subseção 3.1. Em seguida, na
Subseção 3.2, a metodologia utilizada para obtenção dos resultados da análise é apresentada, incluindo métricas, parâmetros e fatores utilizados na experimentação.
3.1. Cenário
O cenário de experimentação inclui uma rede emulada no Mininet [Lantz et al. 2010] com
Open vSwitches operando em modo kernel e um controlador Floodlight versão 0.90 [Big
Switch Networks 2014] gerenciando a rede como um elemento externo. Tanto a rede
emulada como o controlador Floodlight se encontram na mesma máquina física em que
foram realizadas as experimentações. As experimentações foram realizadas dessa forma
para que não haja uma latência adicional entre o controlador e os switches emulados no
Mininet. Cada experimento foi realizado em duas topologias: (i) uma em estrela com
um switch, seis máquinas, um servidor de arquivos e um servidor de stream e (ii) uma
em árvore com profundidade três e largura dois, constituída por sete switches. Assim
como a topologia estrela, a topologia em árvore é constituída por seis máquinas, um
servidor de arquivos e um servidor de stream de vídeo. O posicionamento dos servidores
estão localizados nas extremidades da rede. Na Figura 1 pode-se observar as topologias
utilizadas para as experimentações.
Para a realização da coleta das informações relativas ao tráfego de controle e monitoramento, foram necessárias modificações no módulo gerenciador de estatísticas existente no controlador Floodlight. Essas modificações foram realizadas, pois esse controlador 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 coletar
informações a respeito do tráfego de dados como a respeito do tráfego de controle gerado
na rede. A partir disso, foram analisadas informações referentes a regras instaladas nos
dispositivos, bem como o monitoramento de estatísticas nos switches da rede.
3.2. Metodologia de Avaliação
A análise quantitativa do tráfego de controle e monitoramento em redes OpenFlow versão
1.0 é realizada considerando as métricas: (i) taxa de transferência média das mensagens de
monitoramento para regras instaladas nos switches (Read-State), (ii) taxa de mensagens
do tipo Packet-In processadas por segundo pelo controlador e (iii) taxa de mensagens do
tipo Packet-Out/Modify-State processadas pela rede. Essas métricas foram escolhidas com
o intuito de avaliar a quantidade de mensagens enviadas em função do tempo, tanto para
mensagens enviadas para o controlador como para os dispositivos da rede. Os parâmetros
de experimentação são fixados para todos os experimentos realizados e estão dispostos na
Tabela 2. Utilizando sempre os mesmos parâmetros nos experimentos, é possível elaborar
variações de cenários e gerar resultados que sejam comparáveis.
Toda a experimentação foi realizada em uma única máquina com sistema operaTM
R
cional Linux Ubuntu 12.10 64-bit com processador Intel
Core 2 Duo CPU E8400 @
3,00GHz x 2 e 2Gb de memória RAM. O ambiente experimental foi emulado no Mininet
versão 2.0.0. O software Apache versão 2.2.20 foi utilizado como servidor de arquivos. O
tamanho médio dos arquivos transferidos foi configurado em 54 KB (conforme definição
do tamanho médio de uma página Web [3GPP2 2004]). O software VLC media player
2.0.8 Twoflower foi utilizado como servidor de stream de vídeo utilizando os Codecs
Advanced Systems Format (ASF) e Windows Media Video (WMV) para uma duração do
vídeo fixada em 2 minutos [Cheng et al. 2007]. Em ambos servidores foram utilizados
o protocolo HTTP. A largura de banda de todos os enlaces da rede foi fixada em 100
Mb e as requisições dos arquivos e vídeos foram baseadas em uma função exponencial
apresentada 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 de
tempo entre monitoramentos que varia em 1, 5 e 10 segundos, (ii) tempo de ociosidade
de regras de encaminhamento (tempo que uma regra fica instalada em um switch antes de
ser 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
Valores
Tamanho médio do arquivo
54 KB
Codec de vídeo
ASF/WMV
Duração do vídeo
2 minutos
Protocolo de transmissão
HTTP
Largura 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 podem
influenciar a precisão das informações obtidas da rede e o impacto dessas mensagens irão
gerar no canal de controle. Nos experimentos realizados para instalação de regras de encaminhamento (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 do
comportamento das mensagens de controle Read-State, Packet-In/Out e Modify-State e
experimentação para as mesmas mensagens. Para validar as experimentações realizadas
a modelagem analítica foi conduzida inicialmente como forma de identificar a frequência
e impactos das mensagens no canal de controle, a fim de, inferir o comportamento da
rede de acordo com as topologias e tamanho das mensagens. A experimentação foi realizada em duas topologias com o mesmo número de hosts, porém variando a disposição
e 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 tempo
de ociosidade da regra e topologias e, (ii) para as mensagens de Read-State os fatores a
serem variados foram a frequência de monitoramento e as topologias. A realização dessas
variações foram utilizadas, pois apresentam diferentes níveis de granularidade de monitoramento e expiração das regras instaladas nos switches. Os experimentos realizados
seguiram 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 Resultados
Esta seção apresenta os detalhes sobre as experimentações realizadas para avaliar o comportamento 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 maneira 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 e
implementação do controlador. Posteriormente, os resultados obtidos por experimentação
são apresentados e discutidos.
4.1. Modelagem Analítica
Em 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. As
mensagens enviadas do controlador para os switches são chamadas de Stats Request e as
enviadas dos switches de volta para o controlador são chamadas de Stats Reply. Com base
na 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 encaminhamento instaladas nos mesmos.
Todas as mensagens do tipo Read-State possuem um mesmo cabeçalho de tamanho fixo de 12 bytes e uma parte variável (corpo da mensagem) cujo tamanho depende
do tipo de estatística requisitada ou dos dados coletados na resposta. Mensagens do tipo
Stats Request possuem tamanho previsível correspondente ao tipo de estatística requisitada, isto é, mensagens dos tipos Individual-Flow-Request, Aggregate-Flow-Request,
Port-Request e Queue-Request incluem um corpo adicional correspondente a 44, 44, 8 e
8 bytes, respectivamente. Mensagens de Description-Request e Table-Request não requerem mais informações para serem enviadas aos switches, portanto não adicionam bytes ao
pacote.
Já o tamanho do frame OpenFlow das mensagens Stats Reply varia tanto pelo tipo
de estatística coletada e quanto pela quantidade de informações retornadas. Mensagens
de resposta de estatísticas por porta, por exemplo, incluem um corpo adicional de 104
bytes para cada porta de cada switch da rede. Assumindo que um switch não varia a
sua 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 porta
de 2058 bytes. No entanto, para estatísticas individuais por regras de encaminhamento
(Individual-Flow-Stats), por exemplo, é significativamente mais complexo prever o tamanho das mensagens, uma vez que a quantidade de regras instaladas em cada switch
depende 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 bidirecional e unicast, entre dois endpoints/hosts da rede que passa por um conjunto de dispositivos de encaminhamento (caminho do fluxo) e que pelo menos duas regras de encaminhamento 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 de
monitoramento (SM ) gerada por mensagens de Stats Reply em relação a quantidade de
fluxos ativos em uma rede.
SM = SMF + SMV
(1)
SMF = Nswitches ∗ (HOF + HSR )
(2)

SMV =
X

X

f ∈F
(BodyIF S ∗ 2)
(3)
s∈P athf
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ão
do OpenFlow (HOF ) mais o cabeçalho específico das mensagens Stats Reply (HSR ), totalizando 12 bytes. Esse valor é ainda multiplicado pela quantidade de switches na rede,
uma vez que cada dispositivo responderá individualmente sobre as suas estatísticas de
regras 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 que
esses fluxos percorrem ao longo da rede (conjunto P athf ). Sendo assim, para cada fluxo
f ativo na rede e para cada switch s no caminho de cada fluxo são somados os dados referentes às informações das regras de encaminhamento Individual-Flow-Stats (BodyIF S )
para ida e volta. O tamanho de BodyIF S é de 88 bytes mais 8 bytes por action totalizando
96 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 controle de redes OpenFlow são as mensagens utilizadas para instalação de regras de encaminhamento: Packet-In, Packet-Out e Modify-State. A forma como essas mensagens
são utilizadas depende da implementação das aplicações no controlador, mas basicamente
para imitar o comportamento de redes Ethernet, existem pelo menos três implementações
possíveis [Klein e Jarschel 2013]. A primeira seria o que os autores Klein e Jarschel
chamam de Hub behavior, onde para cada Packet-In gerado por um switch é gerado um
Packet-Out que faz flood do pacote para todas as interfaces (o que é obviamente ineficiente). A segunda implementação é chamada Switch behavior, onde o controlador aprende
a localização dos hosts conforme recebe mensagens Packet-In, instala uma regra de encaminhamento com Modify-State e envia o pacote recebido seguindo essa regra para cada
Packet-In recebido de cada switch do caminho do fluxo. A terceira e mais otimizada
implementação é chamada Forwarding behavior. Nesta última, ao receber o primeiro
Packet-In para estabelecimento de um fluxo o controlador primeiramente instala as regras com mensagens Modify-State nos demais switches do caminho, para depois instalar
a última regra no switch que gerou o Packet-In enviando o pacote com uma mensagem
Packet-Out. Obviamente, o controlador somente conseguirá operar nesse modo depois de
conhecer a localização dos hosts, o que deve acontecer depois que estes enviarem tráfego
para a rede, até então o controlador terá que utilizar, por exemplo, uma implementação
Hub behavior.
Mensagens do tipo Packet-In são enviadas pelos switches ao controlador sempre
que 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 inteiro recebido que é encapsulado na mensagem. Geralmente, os pacotes enviados nesse
tipo de mensagem serão ARP ou TCP-SYN, por exemplo, que incrementarão em 42 ou
74 bytes, respectivamente no tamanho do Packet-In. A frequência com que novos fluxos aparecerão na rede pode ser estimada estatisticamente através de modelos como os
apresentados na Tabela 2. Além disso, a geração de mensagens Packet-In é influenciada
pelo tempo de ociosidade das regras de encaminhamento, o que é uma configuração feita
pelo controlador. Quanto mais longo o tempo de ociosidade das regras, menos mensagens
Packet-In devem ser enviadas ao controlador.
Mensagens dos tipos Packet-Out e Modify-State são geralmente utilizadas em resposta do controlador às mensagens Packet-In enviadas pelos switches. Considerando a
implementaçã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

se host desconhecido

Nswitches ∗ (HOF + HP O!+ MOriginal )
P
SF =

(HOF + HM S ) + (HOF + HP O + MOriginal ) se host conhecido

s∈P athf
(4)
SF é calculada diferentemente em duas situações. Primeiro, no caso da posição do
host destino do fluxo na rede seja desconhecido pelo controlador, este irá enviar apenas
mensagens de Packet-Out (HOF + HP O + MOriginal ) para todas as portas de todos os
switches da rede (Nswitches ) (isso acontece assim que forem recebidas no controlador todas
as mensagens de Packet-In correspondentes), como um Hub behavior. Segundo, quando a
posição do host é conhecida, o controlador envia mensagens Modify-State (HOF + HM S )
para cada switch s no caminho do fluxo P athf e envia apenas uma mensagem Packet-Out
(HOF + HP O + MOriginal ) de volta ao switch que originou o primeiro Packet-In. Em
geral, esse procedimento ocorrerá uma vez para o estabelecimento do caminho de ida do
fluxo. No caminho de volta o host destino já será conhecido pelo controlador (já que ele
originou o primeiro pacote), sendo assim, será necessário apenas mais uma execução do
caso onde o host é conhecido.
Vale ressaltar que o custo das mensagens Packet-In não está incluído no cálculo
de SF – assim como os custos das mensagens Stats Request não estavam em SM – uma
vez 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 da
posição do host destino do fluxo na rede seja desconhecido pelo controlador, serão geradas
uma 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 foram
considerados nos cálculos apresentados a sobrecarga adicional de transporte. O canal de
controle OpenFlow possui diversas configurações possíveis de transferir dados, incluindo
TCP, UDP, SSL, o que ocasiona ainda mais sobrecarga tanto de tráfego de rede quanto de
processamento 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 mensagens de instalação de regras de encaminhamento (etapa (i), mensagens de Packet-In/Out e
Modify-State) como para as mensagens de monitoramento de estatíticas (etapa (ii), mensagens de Read-State). Para fins comparativos, a modelagem analítica foi utilizada como
baseline para a situação onde existe a maior sobrecarga de mensagens na rede, dado os
parâmetros da experimentação em cada uma das duas topologias.
As Figuras 2(a) e 2(b) apresentam o comportamento das mensagens Packet-In/Out
e Modify-State para as topologias de estrela e árvore respectivamente. O comportamento
das mensagens Packet-In/Out e Modify-State apresentam grandes variações durante o período do experimento. Variação que acontece pelo fato dessas mensagens só ocorrem
na rede quando os fluxos são iniciados e os switches não possuem regras instaladas ou
quando as regras para um determinado fluxo expiram baseadas em um tempo limite de
ociosidade 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 significativamente conforme aumenta o tempo limite de ociosidade da regra instalada expirar. Isso
indica que em redes onde as regras são acionadas mais frequentemente, por exemplo com
intervalo de menos de 30 ou 60 segundos, não é necessária a desinstalação imediata das
regras de encaminhamento quando o fluxo fica inativo por 1 segundo.
As mensagens de Packet-Out e Modify-State obedecem a mesma variação das
mensagens Packet-In, porém, são enviadas em direção dos dispositivos de encaminhamento ao invés do controlador. De acordo com a experimentação, ’é possível afirmar com
90% de confiança para ambas as topologias a taxa de mensagens do tipo Packet-Out e
Modify-State ocorrem com mais frequência de acordo com o tempo limite de ociosidade
da regra instalada no switch. Isso indica que em ambientes onde as regras são acionadas
com frequência não é necessária a desinstalação da regra imediatamente, podendo causar
sobrecarga de mensagens de controle desnecessárias no canal de controle.
3500
Pkt-in (Experimental)
Pkt-in (Analítico)
Pkt-out+Mod-St (Experimental)
Pkt-out+Mod-St (Analítico)
350
Taxa de transferência (bits/s)
400
300
250
200
150
100
50
0
1
30
2500
2000
1500
1000
500
0
60
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)
3000
1
30
60
Tempo limite de ociosidade da regra (segundos)
Figura 2. Taxa de transferência das mensagens Packet-It e Packet-Out/Modify-State de acordo com o
tempo limite de ociosidade das regras para as topologias de estrela e árvore
Uma vez compreendido o comportamento dos usuários na rede e conhecendo a
topologia pode se estimar o caso onde existe a maior sobrecarga de mensagens Packet-In
para o controlador. A partir da modelagem analítica pode ser mensurado o impacto das
mensagens no canal de controle para o caso onde tempo limite de ociosidade das regras
seja quase que imediato (1 segundo). Nas Figuras 2(a) e 2(b) é possível perceber que as taxas de transferência para os resultados analíticos se mantém estáveis para todos os tempos
de 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 entre
dois hosts. A partir desses resultados, é possível afirmar que é necessário o conhecimento
a respeito do comportamento dos fluxos gerados na rede para não gerar pacotes desnecessários ao controlador nem manter regras inativas instaladas desnecessariamente nos
dispositivos de encaminhamento.
A Figura 3 apresenta o comportamento da taxa de pacotes por segundo das mensagens do tipo Packet-In/Out para as topologias de estrela e árvore. Foram calculadas também as taxas de 0.17, 0.113, 0.005 e 0.33, 0.22 e 0.008 pacotes por segundo de mensagens
Packet-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 topologias 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 pacotes por segundo processados pelo controlador aumenta em 51,5%, 51,4% e 62,5% para
as mensagens do tipo Packet-In nas três variações do experimento. Para as mensagens
Packet-Out e Modify-State as variações ficam em torno de 33.3%, 41.2% e 51,1% de aumento, devido a topologia com maior número de switches. Assim, pode-se afirmar que o
número de switches impacta diretamente na sobrecarga de mensagens Packet-In enviadas
ao controlador, ainda que, a modelagem analítica não tenha como prever problemas como
pacotes fora de ordem e retransmissões, os quais podem ocasionar em mais chegadas de
mensagens Packet-In no controlador.
Pacotes processados por segundo
1.6
Pkt-in (Estrela)
Pkt-in (Árvore)
Pkt-out+Mod-St (Estrela)
Pkt-out+Mod-St (Árvore)
1.4
1.2
1
0.8
0.6
0.4
0.2
0
1
30
60
Tempo limite de ociosidade das regra (segundos)
Figura 3. Taxa de pacotes processados por segundo de mensagens Packet-In, Packet-Out/ModifyState de acordo com o tempo limite de ociosidade das regras para as topologias de estrela e árvore
Stats-Reply (Experimental)
Stats-Reply (Analítico)
5000
A Figura 4(a) e 4(b) apresentam os resultados para a taxa de transferência de mensagens Stats-Reply para as topologias de estrela e árvore, respectivamente. Se tratando das
mensagens para monitoramento de estatísticas (Read-State), os resultados apresentaram
que para 95% de confiança existe pouca variabilidade na taxa de transferência média dos
pacotes de estatísticas coletados. As mensagens de request não foram exibidas em gráficos, 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 regras
instaladas nos switches da rede e essa variabilidade impacta no tamanho das mensagens
recebidas pelo controlador.
4000
3000
2000
1000
0
1
5
Stats-Reply (Experimental)
Stats-Reply (Analítico)
20000
15000
10000
5000
0
10
Frequência de monitoramento (segundos)
1
5
10
Frequência de monitoramento (segundos)
Figura 4. Taxa de transferência para mensagens de Stats-Reply de acordo com a frequência de
monitoramento para as topologias de estrela e árvore
86
Além do número de regras instaladas nos switches da rede, que impacta no tamanho das mensagens, o número de switches a serem consultados também influencia no
desempenho do controlador. Para a topologia em árvore por exemplo, o envio e recebimento 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 cada
switch da rede. Escalando para topologias maiores como de data centers por exemplo, o
impacto e frequência do monitoramento pode ser maior, comprometendo a comunicação
entre controlador e dispositivos de encaminhamento. A partir desse estudo pode se afirmar que a frequência do monitoramento pode afetar significativamente dependendo do
número de dispositivos de encaminhamento na rede. Além disso, deve-se avaliar a possibilidade de realizar o monitoramento direcionado ao um conjunto menor de dispositivos
de mais interesse, evitando uma possível coleta desnecessária.
5. Conclusões e Trabalhos Futuros
Neste trabalho foi discutido acerca da centralização e distribuição da lógica de controle
no contexto de SDN e OpenFlow. Partindo dessa discussão, foram apresentadas soluções
que resolvem problemas relacionados aos gargalos gerados pela centralização do controle
da rede proposta no contexto do protocolo OpenFlow. Porém, não são quantificados o
custo e nem a frequência em que tais gargalos podem ocorrer. Portanto, devido a ausência
de um estudo quantitativo acerca das mensagens de controle utilizadas nesse contexto,
foi proposta uma análise para as mensagens que aparecem mais frequentemente no canal
de 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 e
Read-State) trocadas entre controlador e switches na rede e; (ii) a experimentação em duas
topologias distintas, variando frequência de monitoramento e tempo limite de ociosidade
das regras instaladas nos dispositivos de encaminhamento.
Os resultados da análise realizada mostram que as mensagens de instalação de
regras de encaminhamento Packet-In/Out e Modify-State possuem um comportamento
dependente da implementação das aplicações realizadas no controlador, por exemplo, do
tempo limite de ociosidade das regras. Já as mensagens de coleta de estatísticas (ReadState) são influenciadas principalmente devido a quantidade de dispositivos monitorados
e pela frequência em que são monitorados. A modelagem analítica apresenta as equações
para estimar a sobrecarga gerada pela transmissão das mensagens de controle assumindo
que a rede não possui atrasos nem retransmissões. Fato que explica os resultados apresentados, onde todos os valores calculados analiticamente são superiores aos experimentais.
Com base na análise apresentada, espera-se contribuir para o projeto e desenvolvimento
de novos sistemas de gerenciamento de redes baseadas no paradigma SDN e OpenFlow.
Como trabalhos futuros pretende-se expandir os experimentos acerca das topologias 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, a
fim de estabelecer uma relação entre a sobrecarga gerada na rede e a precisão dos dados
obtidos sobre os fluxos monitorados. Também pode ser expandida a análise para outras
versões do protocolo OpenFlow utilizando níveis de prioridades, além de instalação de
regras mais genéricas ou mais específicas. Por fim, além desses aspectos pretende-se realizar novos experimentos em uma rede com switches reais a fim de que se possa analisar o
limite de processamento das regras instaladas e monitoradas através do canal de controle.
87
Referências
3GPP2 (2004).
CDMA2000 Evaluation Methodology.
Disponível em:
<http://www.3gpp2.org/Public_html/specs/C.R1002-0_v1.0_041221.pdf>. Acesso
em: 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 Proceedings of the 9th IEEE/ACM/IFIP International Conference on Network and Service
Management 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 short
video 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. In
Proceedings 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 defined
networking. 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 Techniques, SimuTools ’13, pp. 322–329, Brussels, Belgium.
Lantz, B., Heller, B., e McKeown, N. (2010). A network in a laptop: rapid prototyping
for software-defined networks. In Proceedings of the 9th ACM SIGCOMM Workshop
on 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). Logically
centralized?: state distribution trade-offs in software defined networks. In Proceedings
of 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 management of dot: A distributed openflow testbed. In Preceedings of the 14th IEEE/IFIP
Network Operations and Management Symposium (NOMS 2014)(To appear).
Tootoonchian, A. e Ganjali, Y. (2010). Hyperflow: a distributed control plane for openflow. In Proceedings of the 2010 internet network management conference on Research
on enterprise networking, pp. 3–3. USENIX Association.
Yu, M., Rexford, J., Freedman, M. J., e Wang, J. (2010). Scalable flow-based networking
with difane. ACM SIGCOMM Computer Communication Review, 40(4):351–362.
88
Migração de máquinas virtuais para economia de energia∗
Leonardo Pais Cardoso, Lyno Henrique G. Ferraz, Otto Carlos M. B. Duarte
1
Grupo de Teleinformática e Automação
Universidade Federal do Rio de Janeiro (UFRJ)
Rio de Janeiro – RJ – Brasil
{cardoso, lyno, otto}@gta.ufrj.br
Resumo. A computação em nuvem oferece um novo modelo de negócios que
provê serviços de infraestrutura flexı́veis por demanda. O cliente paga apenas pelo que realmente necessita ou usa recursos de processamento, memória
e banda sob demanda, podendo crescer ou retrair sem custos extras. Logo, os
provedores de infraestrutura devem prover recursos de forma dinâmica, a custo
reduzido e também com baixo consumo de energia elétrica, para diminuir a
emissão de carbono e melhorar a sua imagem junto a seus clientes. Este artigo propõe um mecanismo que emprega técnicas de otimização para gerenciar
a migração de máquinas virtuais entre máquinas fı́sicas com o objetivo de reduzir os recursos ociosos e também obter menor consumo energético através
do desligamento de máquinas fı́sicas. O estado das máquinas e as decisões
são baseadas no monitoramento dos perfis de uso de recursos. A heurı́stica
implementada procura minimizar o número de máquinas fı́sicas em funcionamento ao realocar máquinas virtuais. Foram realizados experimentos em um
protótipo desenvolvido e implantado no Future Internet Testbed with Security
(FITS). Os resultados obtidos mostram a eficácia da proposta na redução do
consumo energético.
Abstract. Cloud computing introduced a new business model that offers flexible
on demand infrastructure services. The client gets resources on demand such
as processing, memory and bandwidth, which can grow or shrink without extra
costs and he pays just for what he needs or uses. Therefore, the infrastructure
providers must offer resources dynamically with low costs and low energy consumption in order to decrease carbon emission levels and improve the image
of the company in the consumer marketplace. This paper proposes a virtual
machine management mechanism that implements optimization techniques to
manage the migration of virtual machines between physical machines. The mechanism aims to decrease power consumption and idle resources by turning off
physical machines. The machine state and the decisions taken are based on the
monitoring of the resource usage profiles. The developed heuristic tries to minimize the number of active physical machines by redistributing virtual machines.
A prototype was developed and deployed in Future Internet Testbed with Security (FITS). The results show the effectiveness of the mechanism reducing power
consumption.
∗
Este trabalho foi realizado com recursos do CNPq, CAPES, FINEP, FAPERJ e FUNTTEL.
89
1. Introdução
A computação em nuvem permite que o provedor de infraestrutura ofereça recursos computacionais como processamento, memória e rede de forma flexı́vel e dinâmica
de acordo com a demanda de seus clientes. Além de serem evitados custos operacionais de manutenção, configuração e reparo, o cliente também pode obter os recursos que
necessita naquele momento, evitando sobre ou sub valores investidos em infraestrutura.
Uma técnica utilizada para isto é a virtualização [Fernandes et al. 2010] que amplia a
flexibilidade em alocar recursos ao abstrair o hardware, possibilitando que mais de um
usuário compartilhe recursos de uma mesma máquina sem interferir nos processos de outro usuário. Para evitar sobrecarga, é comum distribuir os recursos pelas máquinas fı́sicas
interconectadas em rede ou em aglomerados. A migração de máquinas virtuais é uma
forma eficaz de redistribuir dinamicamente os recursos pelas máquinas fı́sicas existentes. A migração ao vivo [Clark et al. 2005] permite que as máquinas virtuais continuem
em funcionamento durante o processo de migração, garantindo alta disponibilidade do
serviço.
Alocar recursos computacionais é um importante desafio em computação em nuvem, pois determina se o provedor consegue atender aos Acordos de Nı́vel de Serviço
(Service Level Agreements - SLAs) sem comprometer os seus lucros. Uma alocação eficiente de recursos deve atender a todos os clientes com a qualidade de serviço por eles
requerida e com o menor uso de recursos fı́sicos para diminuir o número de computadores ativos, reduzindo assim o consumo de energia elétrica. No entanto, as plataformas
de virtualização como o Xen [Egi et al. 2008] não possuem nativamente um mecanismo
de gerência que possibilite alocar os recursos de forma eficiente. Além disso, alocar
diferentes recursos em máquinas que possuem restrições de capacidade é um Problema
Generalizado de Atribuição (Generalized Assignment Problem - GAP) e portanto NPDifı́cil [Kundakcioglu e Alizamir 2009]. A medida que o número de recursos e máquinas
aumenta, o tempo para calcular a solução cresce exponencialmente. Assim, encontrar
uma solução exata não é escalável.
Este artigo propõe um mecanismo automático de gerência baseado na migração
de máquinas virtuais para minimizar o consumo de energia elétrica e reduzir a ociosidade
de recursos. A minimização do consumo de energia e da ociosidade é feita com base no
monitoramento e análise dos perfis de uso de recursos das máquinas fı́sicas e virtuais. A
partir dessa análise é aplicada uma heurı́stica que realoca recursos através da funcionalidade de migração de máquinas virtuais de forma a minimizar o número de máquinas
fı́sicas em funcionamento. O algoritmo provê um mapeamento das máquinas virtuais em
máquinas fı́sicas que objetiva um número reduzido de máquinas fı́sicas. O mecanismo
considera ainda a quantidade de memória a ser transferida pela rede. As máquinas virtuais são então migradas uma a uma para evitar violações dos Acordos de Nı́vel de Serviço
que poderiam ser causadas pela sobrecarga no tráfego na rede que as transferências de
dados da migração requerem. As máquinas fı́sicas em estado inativo são então desligadas
com a finalidade de reduzir os recursos ociosos e o consumo de energia. As máquinas são
mantidas desligadas até que a demanda dos clientes seja superior a quantidade de recursos
oferecidos e, neste caso, novas máquinas fı́sicas são ativadas para atender a demanda.
O mecanismo de gerência foi implementado e testado no FITS. Dois testes foram
realizados: Um experimento para comprovar o funcionamento do mecanismo e um estudo
90
do algoritmo de otimização. Os resultados mostram que o mecanismo é capaz de encontrar soluções de menor custo, migrar as máquinas para essa solução, desligar máquinas
ociosas e ligar máquinas quando a demanda é maior que a oferta. O estudo mostra que o
Arrefecimento Simulado é capaz de melhorar a solução de outras heurı́sticas.
O restante deste artigo está organizado da seguinte forma. Na Seção 2 os trabalhos
relacionados são descritos e comparados com o mecanismo proposto. A Seção 3 apresenta
a solução proposta, descrevendo a coleta de dados, a heurı́stica utilizada e a arquitetura do
mecanismo. Os resultados são apresentados na Seção 4. A Seção 5 apresenta a conclusão
e direções futuras deste trabalho.
O desenvolvimento de mecanismos que visem a minimização do consumo de energia é um tema atual e também um desafio tecnológico. Diversos trabalhos abordam a
alocação de elementos virtuais sem levar em conta o consumo de energia elétrica.
Esta seção se restringe aos trabalhos de alocação de recursos para redução de
consumo de energia elétrica. Uma forma de resolução do problema de otimização é o
uso de heurı́sticas como o First Fit Decreasing (FFD) [Johnson et al. 1974] e de metaheurı́sticas como o Arrefecimento Simulado. O FFD é um algoritmo guloso que ordena
as máquinas virtuais de forma decrescente de demanda e tenta alocar a máquina virtual
na máquina fı́sica de menor ı́ndice com capacidade disponı́vel. Caso não consiga alocar a
quantidade de recursos demandados em nenhuma máquina fı́sica ativa, uma nova máquina
fı́sica é ativada com um ı́ndice maior que o da última ativada. A técnica de Arrefecimento
Simulado é uma meta-heurı́stica capaz de encontrar uma solução ótima para o problema
de alocação através de uma função de aceitação. Essa função permite a aceitação de
estados de maior custo, e assim possibilita a exploração de diferentes soluções para fugir
de mı́nimos locais.
Wu et al. comparam as heurı́sticas FFD e Arrefecimento Simulado para a
realocação de máquinas virtuais e economia de energia [Wu et al. 2012]. Wu et al. realizam simulações variando o número de máquinas fı́sicas e virtuais bem como a capacidade e o uso de recursos de cada uma delas. A minimização é feita sobre uma função de
consumo de energia elétrica dependente de parâmetros como o uso de processamento e
memória e do hardware utilizado. Eles concluı́ram que o uso em conjunto do Arrefecimento Simulado e do FFD encontra soluções que podem economizar mais energia que o
uso somente do FFD ou do Arrefecimento Simulado. Porém, os autores focam na proposta e simulação do algoritmo, assim o trabalho carece de um desenvolvimento prático
que lide com os problemas relacionados de gerenciamento efetivo de um ambiente virtualizado. Apenas verificou-se a possibilidade de alocar as máquinas virtuais e o tempo que o
algoritmo leva para atingir a solução, não considerando o tempo necessário para o sistema
convergir após as requisições de migração, o que pode ser crı́tico em uma aplicação real.
Rodriguez et al. implementam uma heurı́stica de branch and cut [Mitchell 2002]
baseada em um algoritmo de programação linear 0-1 cujo objetivo é encontrar um
mapeamento de roteadores e enlaces virtuais em roteadores e enlaces fı́sicos. O
artigo avalia o compromisso entre minimizar o consumo de energia e o uso de
banda [Rodriguez et al. 2013]. Os autores definem pesos para o uso de banda e consumo
de energia e executam duas formulações de programação linear 0-1 de forma sequencial.
91
A primeira formulação mapeia as redes virtuais no substrato a fim de minimizar o consumo de energia e a largura de banda por requisição da nova rede, a segunda visa encontrar
um caminho que minimize o tempo necessário para transferir a imagem do roteador virtual e carregar o sistema operacional. Os autores apresentam melhores resultados quando
aplicam o mesmo peso para banda e economia de energia, apresentando uma diminuição
de 30% da largura de banda e um aumento de 10% do consumo quando comparado a
minimização apenas do consumo de energia. A proposta de Rodriguez et al. não é orientada a computação em nuvem e considera apenas o problema de chegada de redes virtuais
em uma plataforma pluralista para prover infraestrutura de rede. Em um cenário de nuvem não se pode limitar a instanciação de redes, sendo necessário manter a economia de
energia dos servidores que entregam recursos sob demanda para as máquinas virtuais.
Este artigo, ao contrário dos trabalhos acima relacionados, propõe a solução de um
mecanismo de gerência capaz de reduzir o número de máquinas em funcionamento utilizando heurı́sticas que levam em conta parâmetros que influem substancialmente no tempo
de migração. O mecanismo proposto utiliza a técnica de migração ao vivo para reduzir
a inatividade das máquinas virtuais enquanto são migradas. Com isto, quando ocorre a
migração, apenas a memória da máquina virtual é copiada pela rede. Essa técnica permite que a máquina virtual permaneça em operação durante a migração e entre em estado
suspenso por um curto perı́odo de tempo. O mecanismo também evita a sobrecarga da
rede causada pela migração e a sobrecarga dos recursos de memória e processamento das
máquinas fı́sicas. A sobrecarga da rede é tratada através da escolha de soluções que migrem máquinas virtuais com menor quantidade de memória. A sobrecarga de memória e
processamento é evitada pela utilização do protocolo Wake on Lan que liga máquinas pela
rede. No mecanismo, o Wake on Lan é acionado quando a demanda por recursos é maior
que a disponı́vel, ligando uma das máquina fı́sicas ociosas para satisfazer a necessidade
dos clientes. Os autores Rodriguez et al. procuram otimizar a instanciação de roteadores
virtuais na criação da rede. Em contrapartida, este artigo aborda a migração de máquinas
virtuais já instanciadas e em uso por clientes que possuem acordos de nı́vel de serviço
pré-definidos com o provedor de infraestrutura.
A verificação do comportamento do mecanismo proposto foi realizada no testbed
FITS, que provê um ambiente virtualizado em que se pode testar soluções para a Internet
do Futuro [Mattos et al. 2012, Moraes et al. 2014]. O FITS é uma rede de testes interuniversitária baseada nas tecnologias Xen e OpenFlow, contando com parceiros no Brasil
e na Europa. O FITS adota o paradigma pluralista e permite a execução de sistemas
operacionais e aplicações distintas nas redes virtuais. Dessa forma, o FITS provê um
ambiente propı́cio a avaliação do desempenho e da viabilidade de novas tecnologias para
a Internet do Futuro. A arquitetura do FITS pode ser vista na Figura 1.
A implementação desta proposta se serve de módulos desenvolvidos anteriormente no Grupo de Teleinformática e Automação referentes ao VOLTAIC [Carvalho e Duarte 2012] e ao sistema de gerência AMAS proposto por Bezerra
et al. [Bezerra et al. 2014]. O VOLTAIC é um sistema de gerência de recursos para a
computação em nuvem que provê qualidade de serviço e evita desperdı́cio de recursos.
Bezerra et al. propuseram uma ferramenta de gerência que evita a sobrecarga dos nós
fı́sicos e violações de acordo de nı́vel de serviço. Este trabalho, assim como o VOLTAIC, se baseia na técnica de perfis de uso de recursos das máquinas fı́sicas para analisar
92
Figura 1. Arquitetura do FITS destacando a migração de uma máquina virtual.
Adaptado de [Figueiredo et al. 2013] [Mattos et al. 2012, Moraes et al. 2014].
as capacidades e, assim como a ferramenta de gerência desenvolvida, redistribui a carga
de trabalho através da migração de máquinas virtuais caso um limiar de consumo seja
atingido.
3. O Esquema Proposto
A proposta deste artigo visa minimizar o consumo de energia elétrica e os recursos
ociosos. Fan et al. afirmam que um servidor em modo inativo não consome menos
que 50% da energia elétrica que consumiria em fase de pico [Fan et al. 2007]. Portanto,
para reduzir de forma significativa o consumo de energia deve-se desligar por completo
a máquina fı́sica. Assim, a ideia-chave é migrar as máquinas virtuais para um número
reduzido de máquinas fı́sicas e desligar as máquinas fı́sicas que não possuem máquinas
virtuais ativas. O mecanismo desenvolvido possui quatro módulos principais: o Monitor
de Recursos, o Otimizador, o Orquestrador de Migração e o Gerenciador de Energia,
que são detalhados na Seção 3.3. Esses módulos geram perfis, calculam um estado que
economize energia, migram máquinas virtuais e desligam e ligam as máquinas fı́sicas.
A quantidade de memória de cada máquina virtual a ser migrada influencia no
tempo de convergência do sistema, porque ao migrar uma máquina virtual é necessário
transferir a sua memória pela rede para a máquina fı́sica que a hospedará. Para reduzir o tempo de migração, o algoritmo de Arrefecimento Simulado implementado considera, na condição de duas ou mais soluções de mesmo custo em termos de máquinas
fı́sicas, escolher a solução que transfere menor quantidade de memória. Logo, sempre
que uma solução de mesmo custo que a última armazenada é encontrada, verifica-se quais
máquinas virtuais precisam migrar, ou seja, trocaram de posição em relação a disposição
inicial, e também se verifica o quanto de memória essas máquinas possuem. Após o
cálculo escolhe-se e armazena-se o plano de migração com menor quantidade de memória
para que o procedimento de migração provoque a menor sobrecarga possı́vel na rede.
3.1. Formulação para minimização do número de máquinas em funcionamento
Para a otimização são definidos os seguintes parâmetros:
• V - conjunto de máquinas virtuais instanciadas;
• F - conjunto de máquinas fı́sicas ativas;
93
•
•
•
•
•
•
•
•
•
Cv , v ∈ V - processamento utilizado pela máquina virtual v;
Cf , f ∈ F - processamento utilizado pelo Domı́nio-0 da máquina fı́sica f ;
TC|f , f ∈ F - limiar de uso de processamento da máquina fı́sica f ;
Mv , v ∈ V - memória da máquina virtual v;
Mf , f ∈ F - memória utilizada pelo Domı́nio-0 da máquina fı́sica f ;
TM |f , f ∈ F - limiar de uso de memória da máquina fı́sica f ;
Nv , v ∈ V - consumo de rede da máquina virtual v;
Nf , f ∈ F - rede utilizada pelo Domı́nio-0 da máquina fı́sica f ;
TN |f , f ∈ F- limiar de uso de rede da máquina fı́sica f ;
1, se v ∈ V está instanciada na máquina fı́sica f ∈ F
• X(f, v) =
0,
senão
P
1, se v∈V X(f, v) ≥ 1
• X(f ) =
0,
senão
O algoritmo de minimização segue o procedimento de
Minimizar
X
X(f )
(1)
f ∈F
sujeito às restrições:
∀f ∈ F, (
X
Cv ∗ X(f, v)) + Cf ≤ TC|f
(R1)
X
∀f ∈ F, (
Mv ∗ X(f, v)) + Mf ≤ TM |f
(R2)
v∈V
v∈V
X
Nv ∗ X(f, v)) + Nf ≤ TN |f
∀f ∈ F, (
(R3)
v∈V
∀v ∈ V,
X
X(f, v) = 1
(R4)
f ∈F
{V, F } ⊂ Z>0
(R5)
A Equação 1 é a função objetivo do problema que nesse artigo é a minimização do
número de máquinas fı́sicas em funcionamento X(f ), ou seja, o número total de máquinas
fı́sicas ativas.
As restrições R1, R2 e R3 garantem que o uso de recursos não ultrapasse um limiar. Assim, o uso de recursos para qualquer máquina fı́sica f ∈ F em funcionamento,
é necessariamente menor ou igual ao somatório dos recursos utilizados pelas máquina
virtuais v ∈ V pertencentes a máquina f , o que é representado por X(f, v), e pelo uso de
recursos do Domı́nio-0 da máquina f . A Equação R4 restringe uma máquina virtual v pertencer a apenas uma máquina fı́sica f . Dessa maneira, o somatório das máquinas fı́sicas
f as quais possuem a máquina virtual v deve ser igual a 1. Essa restrição impede que uma
mesma máquina virtual pertencente ao conjunto de máquinas virtuais instanciadas V seja
instanciada em duas máquinas fı́sicas ao mesmo tempo e garante que a máquina virtual
v terá uma máquina fı́sica f como destino. A restrição R5 limita o conjunto de máquinas
virtuais V e o de máquinas fı́sicas F ao domı́nio dos inteiros maiores que zero.
94
3.2. Arrefecimento Simulado
A meta-heurı́stica de Arrefecimento Simulado implementada considera um estado
que evidencia a distribuição das máquinas virtuais sobre as máquinas fı́sicas. Inicialmente
fixa-se uma temperatura inicial, gera-se aleatoriamente um estado inicial e calcula-se o
custo associado definido pelo número de máquinas fı́sicas ligadas. Em seguida, gera-se
um novo estado a partir de uma perturbação do estado inicial. Essa perturbação consiste
em escolher uma das máquinas virtuais e instanciá-la em uma máquina fı́sica diferente,
aleatoriamente. Caso o novo estado possua um custo menor que o anterior ele é aceito.
Do contrário, a aceitação dependerá dos custos do estado anterior e do gerado, e da temperatura. A função de aceitação é expressa por
ji − ji−1
P = exp(−
),
(3)
τi
τ0
onde ji e τi são custo e temperatura na iteração i, respectivamente.
A Equação 3 representa a probabilidade de considerar uma solução de maior custo,
para isso geralmente compara-se o valor da função com um valor aleatório no intervalo
[0, 1]. Se o custo diminui ou se mantém a expressão é sempre igual a 1 e o estado é aceito.
Para temperaturas elevadas o valor da função de aceitação tem maior probabilidade de
ser maior que o valor aleatório. Dessa forma, o algoritmo tem maior probabilidade de
sair de um mı́nimo local. As soluções aceitas são utilizadas para gerar novos estados. O
algoritmo armazena a solução aceita como a solução candidata se o custo diminuir ou o
custo se mantiver e a memória das máquinas a migrar diminuir. A escolha da solução de
menor memória é feita para evitar sobrecarregar a rede com a transferência das máquinas
virtuais. A medida que a temperatura diminui a função de aceitação retorna valores menores e o algoritmo converge para uma solução. Ao final, a solução do problema será a
última solução candidata. O pseudocódigo do algoritmo está em Algoritmo 1.
Dados: τ ; distribuicao, menor custo, ultimo custo,
ultimo estado, custo memoria
enquanto τ > 0 faça
nova distribuicao = gerar estado(ultimo estado)
novo custo = custo(nova distribuicao)
se aceitacao(ultimo custo, novo custo, tau) ≥ random() então
ultimo estado = nova distribuicao
se novo custo < menor custo ou (novo custo = menor custo e
custo memoria(nova distribuicao) < custo memoria) então
distribuicao = nova distribuicao
menor custo = novo custo
custo memoria = custo memoria(nova distribuicao)
fim
ultimo custo = novo custo
fim
τ =τ −1
fim
retorna distribuicao
Algoritmo 1: Arrefecimento Simulado
95
3.3. Arquitetura do Mecanismo
O mecanismo possui quatro módulos principais como pode ser visto na Figura 2.
O Monitor de Recursos é responsável por coletar o uso de recursos das máquinas fı́sicas e
virtuais, o Otimizador executa a heurı́stica para minimizar o número de máquinas fı́sicas
em funcionamento, o Orquestrador de Migração faz a redistribuição das máquinas virtuais entre as máquinas fı́sicas e o Gerenciador de Energia desliga e liga máquinas fı́sicas
de acordo com a demanda. O Monitor de Recursos e o Orquestrador de Migração foram desenvolvidos no trabalho de Bezerra et al. [Bezerra et al. 2014] e integrados aos
módulos Otimizador e Gerenciador de Energia desenvolvidos nesse artigo. O mecanismo
foi desenvolvido em Python para facilitar a integração com o Monitor de Recursos e o
Orquestrador de Migração que foram desenvolvidos nessa linguagem.
Figura 2. Arquitetura do mecanismo de gerência proposto e do esquema
de migração automática de máquinas virtuais.
O Monitor de Recursos coleta o uso de CPU, memória e banda passante das
máquinas fı́sicas e virtuais através da biblioteca libvirt para se comunicar com os hipervisores de cada máquina fı́sica. O uso de CPU das máquinas virtuais é obtido diretamente
pela libvirt. O processamento das máquinas fı́sicas é calculado com a soma do processamento das máquinas virtuais. O perfil de uso de memória é obtido através da quantidade
de memória alocada nas máquinas fı́sicas e virtuais. O uso de rede das máquinas virtuais
é coletado a partir da quantidade de dados que trafegam pelas interfaces virtuais. Como
a solução atual não considera a topologia da rede, o uso de banda das máquinas virtuais
contribui apenas no processamento do Domı́nio-0. O perfil de uso de recursos é gerado
através do monitoramento das máquinas fı́sicas e virtuais a cada segundo.
O Otimizador recebe os perfis de uso do Monitor de Recursos e executa a metaheurı́stica de Arrefecimento Simulado para minimizar o número de máquinas fı́sicas ativas. Ao final, o Otimizador gera uma nova distribuição de máquinas fı́sicas e virtuais. Os
dados das máquinas virtuais que serão migradas e os dados das máquinas fı́sicas e virtuais
são então enviados para o Orquestrador de Migração.
O Orquestrador de Migração é responsável por gerenciar a migração das máquinas
virtuais para a distribuição gerada pelo módulo de otimização. O Orquestrador usa a
migração ao vivo do Xen com pré-cópia que se dá em duas fases. Na primeira fase as
páginas de memória da máquina virtual são copiadas para a máquina de destino, se uma
página é modificada ela é reenviada. A segunda fase inicia quando a taxa de reenvio é
menor que a taxa de modificação. A máquina virtual é suspensa na origem e o restante
das páginas modificadas é copiado para a máquina de destino. Ao final, a execução da
96
máquina virtual é retomada na máquina de destino. Dessa forma, o tempo de migração
dependerá do tamanho da memória a ser transferida, da taxa de atualização dos dados na
memória e do uso de recursos das máquinas fı́sicas envolvidas na migração. Para evitar a
sobrecarga do uso de rede devido a migração, uma máquina virtual só pode ser migrada
quando a migração da máquina virtual anterior terminar.
O Gerenciador de Energia desliga as máquinas fı́sicas que após a execução das
migrações não apresentam máquinas virtuais instanciadas. Esse módulo também liga as
máquinas fı́sicas quando não é mais possı́vel atender a todos os clientes devido a um aumento da demanda de recursos. Esse aumento pode ser observado quando o consumo de
recursos de uma máquina fı́sica atinge determinado limiar em um determinado número de
medições, o que caracteriza uma sobrecarga. Caso o algoritmo de otimização não encontre uma solução de menor custo, uma máquina fı́sica é religada através do protocolo Wake
on Lan e as máquinas virtuais são redistribuı́das após uma nova execução do algoritmo.
O pseudocódigo desse módulo está em Algoritmo 2.
Entrada: HostsOciosos, M aquinasDesligadas,
M aquinasF isicas
se sobrecarga(M aquinasF isicas) e HostsOciosos = 0 então
acordar(M aquinasDesligadas.pop())
Otimizador(M aquinasF isicas)
fim
senão
para M aquina em M aquinasF isicas faça
se M aquinasV irtuais(M aquina) = 0 então
desligar(M aquina)
M aquinasDesligadas.append(M aquina)
fim
fim
fim
Algoritmo 2: Gerenciador de Energia
Uma máquina virtual é migrada para uma máquina fı́sica apenas se a máquina
fı́sica possui recursos suficientes para alocar a máquina virtual. Do contrário, outra
máquina é escolhida como destino. Se antes da migração o uso de recursos da máquina
virtual é superior ao da máquina fı́sica de destino, a máquina virtual não migra para esse
destino. Caso a máquina virtual oscile após a migração e ultrapasse um determinado limiar, a sobrecarga é detectada com base no histórico dos perfis de uso. As máquinas
virtuais são então redistribuı́das. O mecanismo não considera a topologia da rede para
efetuar as migrações. Porém, o escopo de máquinas fı́sicas participantes do processo
de migração é configurável pelo administrador que pode estabelecer um grupo máquinas
fı́sicas geograficamente próximas. Assim, a latência da máquina virtual em relação ao
cliente no novo destino pode ser reduzida.
A coleta dos perfis de uso e a migração é realizada pela biblioteca multiplataforma libvirt. Dessa forma, o mecanismo de gerência pode ser usado em plataformas de
virtualização como o Xen e o KVM. Além disso, as medidas para a geração de perfis são
97
obtidas através da libvirt, o que não requer a modificação de nenhuma máquina virtual,
nem a instalação de softwares. Assim, preserva o isolamento das máquinas virtuais. O
agendamento de execução do mecanismo depende da polı́tica do administrador podendo
ser mantido em execução contı́nua ou apenas quando um evento ocorre. Nesse caso, deve
ser levado em conta o tempo que o algoritmo leva para encontrar uma solução, o que varia
com a quantidade de máquinas fı́sicas e virtuais.
4. Resultados
Dois testes foram realizados: um experimento para a verificação do bom comportamento do mecanismo proposto em migrar as máquinas virtuais e desligar as máquinas
fı́sicas e um estudo para a verificação da escalabilidade da solução de otimização.
Para o primeiro teste que verifica o funcionamento do mecanismo proposto foram
monitoradas três máquinas da plataforma FITS, a Leblon, Pão de Açúcar e Itanhangá.
As máquinas Leblon e Pão de Açúcar possuem processador Intel i7 de 3.2 GHz e 16 GB
de RAM, a máquina Itanhangá possui processador Intel i7 de 3.1 GHz e 8 GB de RAM.
As máquinas possuem sistema operacional Debian Wheezy e executam a versão 4.1.3
do Xen. As imagens das máquinas virtuais encontram-se em um nó central do FITS, não
sendo necessário copiar o disco pela rede. O mecanismo de gerência proposto é executado
em uma máquina Intel Core 2 Quad de 2.4 GHz com 3 GB de RAM que é externa à
plataforma FITS para não interferir no experimento. O Domı́nio-0 está configurado para
consumir 2 GB de memória.
As máquinas virtuais possuem configurações heterogêneas de memória e processamento para avaliar a eficácia do mecanismo proposto. A máquina virtual lpcvm1 foi
configurada com 2 processadores virtuais e 2 GB de memória RAM. As máquinas virtuais lpcvm2 e lpcvm3 foram configuradas com 1 processador virtual e com 4 GB e 3
GB de memória respectivamente. O processamento nas máquinas virtuais foi gerado com
o programa Stress [Waterland 2003], um programa que permite gerar cargas de processamento de forma controlada. Para evitar problemas de escalonamento nas migrações,
foram escolhidas máquinas fı́sicas com configurações semelhantes de processamento.
A Figura 3 mostra a migração da máquina virtual lpcvm1 da máquina fı́sica Itanhangá para a máquina fı́sica Pão de Açúcar, Figura 3(a), Figura 3(b), Figura 3(c) e
Figura 3(d). Em sequência ocorre a migração da máquina virtual lpcvm3 que é transferida da máquina fı́sica Leblon para a Pão de Açúcar, Figura 4 e, finalmente, as máquinas
Itanhangá e Leblon são desligadas. Esse resultado mostra que o mecanismo é capaz de
executar o algoritmo de otimização, fazer as migrações necessárias e desligar as máquinas
fı́sicas ociosas, atingindo o objetivo de reduzir o consumo de energia elétrica. Além disso,
as máquinas migradas são as que possuem a menor quantidade de memória o que reduz a
carga na rede durante a migração. Após esse experimento é feito um teste de sobrecarga
de recursos. Nesse teste uma quarta máquina virtual é instanciada na máquina Pão de
Açúcar. A Pão de Açúcar atinge o limiar de uso de memória e o mecanismo detecta a
sobrecarga. Como a oferta de recursos é menor que a demanda o Gerenciador de Energia liga uma máquina fı́sica, nesse caso, a Itanhangá. Assim que a máquina é ligada o
Otimizador calcula uma nova solução e a máquina virtual lpcvm1 é transferida para a
Itanhangá.
Para o teste do módulo de otimização foram comparadas três técnicas para
98
Inı́cio da migração
da máquina lpcvm1
Memória (%)
Processamento (%)
de processamento
} Aumento
devido a migração
Memória (%)
Processamento (%)
-Memória não se altera pois
ainda está migrando.
Janela de tempo(s)
Janela de tempo(s)
(c) Uso de CPU em função do tempo.
(d) Uso de memória em função do tempo.
Memória (%)
Processamento (%)
- Uso de memória
(b) Uso de memória em função do tempo.
do processamento
} Aumento
devido a migração
lpcvm3 continua operando normalmente
enquanto lpcvm1 é migrada
da carga devido
}Redução
ao inı́cio da migração
Janela de tempo(s)
Janela de tempo(s)
@
R
@
do Domı́nio 0
(a) Uso de CPU em função do tempo.
Inı́cio da migração
Uso de memória
da máquina lpcvm1
Janela de tempo(s)
lpcvm3 continua operando normalmente
enquanto lpcvm1 é migrada
Janela de tempo(s)
(e) Uso de CPU em função do tempo.
(f) Uso de memória em função do tempo.
Carga total de processamento
Término da migração de lpcvm3
@
R
@
Término da migração de lpcvm3
Memória (%)
Processamento (%)
Figura 3. Inı́cio da execução do plano de ação de migração das máquinas virtuais determinado como resultado da meta-heurı́stica de Arrefecimento Simulado.
Assim que o programa inicia, a meta-heurı́stica calcula uma solução e redistribui as máquinas virtuais. Na figura o mecanismo transfere a máquina lpcvm1 da
máquina Itanhangá para a Pão de Açúcar que contém a máquina virtual lpcvm2.
A figura também mostra a máquina lpcvm3 instanciada na máquina Leblon.
Janela de tempo(s)
@
R
@
Janela de tempo(s)
(a) Uso de CPU na máquina Pão de Açúcar em (b) Uso de memória na máquina Pão de Açúcar em
função do tempo.
função do tempo.
Figura 4. Após a migração da máquina lpcvm1 a máquina virtual lpcvm3 é migrada para a Pão de Açúcar e as máquinas fı́sicas Itanhangá e Leblon são desligadas.
99
alocação de máquinas virtuais. A meta-heurı́stica de Arrefecimento descrita na Seção 3.2,
e as heurı́sticas First Fit (FF) e First Fit Decreasing (FF). A heurı́stica First Fit tenta alocar as máquinas virtuais na máquina fı́sica de menor ı́ndice e caso não seja possı́vel aloca
na próxima máquina. A First Fit Decreasing se diferencia da FF por ordenar as máquinas
virtuais de forma decrescente de uso de recursos antes de iniciar a minimização. Para
esse teste foi o utilizado o FFD padrão que considera as máquinas fı́sicas com a mesma
capacidade. O critério de ordenação para a técnica FFD foi estabelecido como o uso
de processamento, memória e rede, nessa ordem. Foram utilizadas 50, 100, 500 e 1000
máquinas virtuais inicialmente instanciadas em 50, 100, 500 e 1000 máquinas fı́sicas,
respectivamente. Foram consideradas máquinas fı́sicas com capacidade de 100% de processamento e 16 GB de memória.
Para criar um ambiente heterogêneo de máquinas virtuais foram gerados recursos
de processamento, memória e rede para cada máquina virtual seguindo uma distribuição
normal. Os recursos de memória foram gerados entre 0 e 16 GB com média de 8 GB e
desvio padrão de 4 GB. Os de CPU e rede entre 0 a 100% da capacidade das máquinas
fı́sicas com média e desvio padrão de 50%. Os testes consistiram de 10 rodadas limitadas
a 320 segundos de execução e a temperatura do algoritmo de Arrefecimento Simulado
foi inicializada em 1 milhão. Assim, o algoritmo para quando a temperatura ou o tempo
chega a zero, o que ocorrer primeiro. Esses parâmetros foram configurados para simular
um ambiente em que o tempo de reação do algoritmo é limitado.
50
100
SA
FFDSA
FFSA
45
SA
FFDSA
FFSA
95
90
Custo
Custo
85
40
35
80
75
70
65
30
60
25
55
0
5
10
15
20
25
Tempo (s)
30
35
40
0
10
20
30
40
Tempo (s)
50
60
70
(a) Desempenho dos algoritmos para 50 (b) Desempenho dos algoritmos para 100
máquinas virtuais.
500
1000
SA
FFDSA
FFSA
450
SA
FFDSA
FFSA
950
900
Custo
Custo
850
400
350
800
750
700
650
300
600
250
550
0
20
40
60
80
Tempo (s)
100
120
140
0
50
100
150
200
Tempo (s)
250
300
350
(c) Desempenho dos algoritmos para 500 (d) Desempenho dos algoritmos para 1000
Figura 5. Gráficos Custo x Tempo para os testes de otimização com 50, 100, 500
e 1000 máquinas fı́sicas e virtuais.
100
Os gráficos da Figura 5 representam o tempo médio para o Arrefecimento Simulado encontrar soluções e melhorar as soluções das heurı́sticas. As figuras mostram a
execução do Arrefecimento Simulado independente de heurı́sticas (SA), e a partir das
soluções obtidas pelas heurı́sticas First Fit (FFSA) e First Fit Decreasing (FFDSA). O
tempo de cálculo da solução inicial gerada pelo FF e pelo FFD para todos os testes foi
menor que 1 segundo e foi desconsiderado do gráfico. Cada ponto representa a média
e o desvio padrão para 10 rodadas. Os dados foram tomados sempre que o algoritmo
encontrava uma solução de menor custo ou mesmo custo em termos de máquinas fı́sicas.
Independentemente do estado inicial, o algoritmo de Arrefecimento Simulado é capaz
de reduzir a função custo. Consequentemente, o algoritmo reduz o número de máquinas
fı́sicas para cerca de 60% em todas configurações, economizando energia ao desligá-las.
5. Conclusão
Este artigo propôs um mecanismo de gerência de máquinas virtuais que minimiza
o consumo de energia elétrica ao reduzir o número de máquinas fı́sicas em funcionamento.
O mecanismo utiliza técnicas de otimização baseadas em Arrefecimento Simulado para
obter as soluções de menor custo, desligando as máquinas ociosas. O mecanismo também
ativa máquinas fı́sicas quando a demanda por recursos é maior que a oferta disponibilizada
pelas máquinas ligadas.
Uma importante contribuição é o teste e a implementação do mecanismo na plataforma FITS, mostrando que o mecanismo funciona e é capaz de minimizar o consumo
de energia em um ambiente real. Foi realizado um experimento para comprovar o funcionamento do mecanismo e um estudo do algoritmo de otimização. Os resultados mostram
que o mecanismo é capaz de encontrar soluções de menor custo e migrar as máquinas
virtuais para essas soluções, desligando as máquinas fı́sicas que se tornam ociosas nesse
processo. Por sua vez, o estudo dos algoritmos de otimização mostrou que o uso do Algoritmo de Arrefecimento Simulado melhora os resultados, sendo a melhor solução aquela
que faz uso desse algoritmo com a heurı́stica First Fit.
Futuramente pretende-se aprimorar o mecanismo através de um estudo dos principais parâmetros a serem utilizados em diferentes distribuições de máquinas virtuais e
também em diferentes topologias de rede. Variáveis tais como número de saltos entre
as máquinas fı́sicas, origem e destino da migração e capacidades dos enlaces envolvidos
na migração poderiam ser inseridas. Assim, seria possı́vel determinar qual a solução de
distribuição de máquinas é a menos custosa em termos de tempo de migração e distância
do cliente a sua máquina virtual.
Referências
[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 gerência de recursos para ambientes virtualizados. Em a ser publicado em XXXII Simpósio Brasileiro de Redes de Computadores
e Sistemas Distribuı́dos - SBRC’2014.
[Carvalho e Duarte 2012] Carvalho, H. E. T. e Duarte, O. C. M. B. (2012). Voltaic: volume
optimization layer to assign cloud resources. Em Proceedings of the 3rd International
Conference on Information and Communication Systems, ICICS ’12, páginas 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 of
the 2Nd Conference on Symposium on Networked Systems Design & Implementation Volume 2, NSDI’05, páginas 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 Proceedings of the 2008 ACM CoNEXT Conference, páginas 1–12. ACM.
[Fan et al. 2007] Fan, X., Weber, W.-D. e Barroso, L. A. (2007). Power provisioning for
a warehouse-sized computer. Em Proceedings of the 34th Annual International Symposium on Computer Architecture, ISCA ’07, páginas 13–23, New York, NY, USA.
ACM.
[Fernandes et al. 2010] Fernandes, N., Moreira, M., Moraes, I., Ferraz, L., Couto, R., Carvalho, 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). Análise de desempenho de mecanismos de
encaminhamento de pacotes em redes virtuais. Em XXXI Workshop de Gerência e
Operação de Redes e Serviços - (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. SIAM
Journal on Computing, 3(4):299–325.
[Kundakcioglu e Alizamir 2009] Kundakcioglu, O. E. e Alizamir, S. (2009). Generalized
assignment problem. Em Floudas, C. A. e Pardalos, P. M., editors, Encyclopedia of
Optimization, páginas 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 interuniversitária
com técnicas de virtualização hı́bridas. Em XXX Simpósio Brasileiro de Redes de
Computadores e Sistemas Distribuı́dos - SBRC’2012.
[Mitchell 2002] Mitchell, J. E. (2002). Branch-and-cut algorithms for combinatorial optimization problems. Handbook of Applied Optimization, páginas 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. Computer
Networks, 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 da
Fonseca, N. (2013). Trade-off between bandwidth and energy consumption minimization in virtual network mapping. Latin America Transactions, IEEE (Revista IEEE
America Latina), 11(3):983–988.
[Waterland 2003] Waterland, A. (2003). Stress. Disponı́vel em: http://people.
seas.harvard.edu/ãpw/stress/. Acessado em: Março de 2014.
[Wu et al. 2012] Wu, Y., Tang, M. e Fraser, W. (2012). A simulated annealing algorithm
for energy efficient virtual machine placement. Em Systems, Man, and Cybernetics
(SMC), 2012 IEEE International Conference on, páginas 1245–1250.
102
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 de
Gerenciamento de Identidades
Ricardo Macedo1 , Aldri Santos1 , André Luiz Pires Guedes1 ,
Michele Nogueira1 , Yacine Ghamri-Doudane2
1
2
Universidade Federal do Paraná – Curitiba – PR – Brasil
University 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 identity management system. However, these systems are cascading failures prone,
that is, failures arosed by the coordinated exploitation of common vulnerabilities among identities providers to manipulate the authentication operations.
Although there are theoretical models to analyze cascading failures resulted
from nodes overload, cascading failures effects from the coordinated exploitation of vulnerabilities in authentication operations remains no investigated.
This paper presents an analytical cascading failure model for identity management systems, enabling the investigation these failures. Results from a case
study indicate that failure dissemination in biggest sets of identities providers
can compromise a identity management system in about 100%.
Resumo. A explosão do número de dispositivos portáteis conectados tem demandado sistemas de gerenciamento de identidades globais. Entretanto, esses
sistemas são propensos a falhas em cascata, as quais são oriundas da exploração coordenada de vulnerabilidades em comum entre provedores de identidades para manipular as operações de autenticação. Apesar de existirem modelos
teóricos para analisar falhas em cascata resultantes da sobrecarga da capacidade de nós, o efeito de falhas em cascata decorrente da exploração de vulnerabilidades nas operações de autenticações em sistemas de gerenciamento de
identidades permanece em sua maioria desconhecidos. Este trabalho apresenta
um modelo analítico de falhas em cascata para sistemas de gerenciamento de
identidades, possibilitando a investigação dessas falhas. Resultados de um estudo de caso indicam que a disseminação de falhas nos conjuntos maiores de
provedores de identidades pode comprometer até 100% do sistema.
1. Introdução
Atualmente, a explosão do número de dispositivos portáteis conectados tem demandado um Sistema de Gerenciamento de Identidades (SGI) global. Recentemente, a
Cisco 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 excederá o número de pessoas no planeta e que em 2018 existirão em média 1.4 dispositivos 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 consumir serviços disponibilizados em sistemas distribuídos, tais como nuvens, arquiteturas orientadas a serviços (Service-oriented Architectures - SOA) ou Internet das coisas
[Lampropoulos and Denazis 2011, Lynch 2011, Angulo and Wästlund 2013]. Neste cenário, será necessário um SGI capaz de garantir as operações de autenticação, gestão de
autorizações e controle de acesso em escala global.
No entanto, em um SGI há a possibilidade de uma falha em cascata. Uma falha
em cascata consiste em um tipo de falha capaz de ser disseminada através da interdependência de elementos de um sistema [Crucitti et al. 2004]. Nos SGIs uma falha em cascata
surge em decorrência de um ataque coordenado visando explorar as vulnerabilidades em
comum entre provedores de identidades para manipular grande parte das respostas das autenticaçõ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 operações de autenticação, gestão de autorizações e controle de acesso é comprometida nos
provedores de serviço. Atualmente, um método eficaz para eliminar os efeitos de uma
falha em cascata é desconhecido.
Na literatura, a caracterização de falhas surge como o passo inicial para criação
de medidas de contenção e mitigação de falhas em cascata [Kinney et al. 2005]. Nas
redes de distribuição de energia elétrica e na Internet a ocorrência de colapsos de funcionamento impulsionou a consolidação de modelos teóricos que permitem a análise do
efeito 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 em
cascata ocorre em virtude da sobrecarga da capacidade dos nós. Em um SGI essa premissa não é válida, pois uma falha em cascata dá-se em função da exploração coordenada
de vulnerabilidades em comum entre provedores de identidades para manipular as respostas de autenticações e não em decorrência da sobrecarga de nós, impedindo a mera
utilização dos modelos existentes. Consequentemente, os efeitos de uma falha em cascata
dessa natureza permanecem desconhecidos nos SGIs, reforçando a necessidade de meios
para analisá-los.
Este trabalho apresenta um modelo analítico de falhas em cascata em SGIs, possibilitando a investigação dessas falhas nesse tipo de sistema. A abstração do SGI é realizada 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 os
provedores de serviços. As arestas representam a interdependência entre os elementos do
SGI, descrevendo os diferentes tipos de relações entre estes tipos de entidades. A disseminação da falha em cascata oriunda da exploração de vulnerabilidades no processo de
autenticação entre provedores de identidades é representada através de um caminho entre
esses provedores. A falha em cascata é demonstrada através de uma prova por indução no
número de provedores de identidades presentes neste caminho.
Um estudo de caso do modelo envolvendo dados reais do sistema Shibboleth da
Universidade de Buffalo mostra que as falhas em cascata podem resultar em danos catastró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. Uma
aná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 da
Falha em Cascata (IFC). O IFC é obtido através da divisão do número de provedores de
identidades falhos pelo número total de provedores de identidades. Os resultados indicam que o IFC nos conjuntos maiores atinge 100% dos provedores de identidades com
probabilidade de presença de vulnerabilidades de 0.45 e que em conjuntos de tamanho
aleatório o IFC chega a atingir 70% dos provedores de identidades. Esse resultado mostra
que mesmo com baixa probabilidade de vulnerabilidade entre provedores de identidades
os 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 apresentados os trabalhos relacionados. A Seção 3 detalha o modelo de falhas em cascata para
SGIs. A Seção 4 explica um estudo de caso envolvendo dados reais de gerenciamento de
identidades coletadas do sistema Shibboleth. Na Seção 5 são apresentadas as conclusões.
Na 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ítulo
de exemplo, um modelo temporal para caracterizar falhas intermitentes em dispositivos elétricos foi proposto [Correcher et al. 2012]. Além disso, também as falhas leves
de datacenters foram caracterizadas visando incrementar a disponibilidade dos serviços
prestados [Sankar and Gurumurthi 2013]. Atualmente, a presença de colapsos de funcionamento em diversos sistemas de larga escala, tais como a Internet e os sistemas Smart
Grid, impulsionou investigações para caracterizar falhas em cascata.
Em [Huang et al. 2013] um modelo para caracterizar falhas em cascata em Smart
Grid foi apresentado. Nele, a caracterização de falhas considera a relação entre a rede
de distribuição de energia e a rede de comunicação. Assumiu-se que a falha em uma
dessas redes implica diretamente na outra. Outra premissa consiste na existência de interdependê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 capacidade de caracterizar de modo prático falhas em cascata em Smart Grids, mas salientam
as limitações do modelo.
O trabalho de [Wang et al. 2014] apresentou um modelo empregando grafos dinâmicos para caracterizar falhas em cascata e seus comportamentos na Internet. O diferencial desse modelo foi assumir diferentes tipos de vértices para representar os hosts e
roteadores da Internet. Essa abordagem possibilitou uma análise mais criteriosa da falha
em cascata e seus efeitos. A caracterização dessas falhas foi realizada assumindo que as
falhas em cascatas são disparadas por ataques intencionais a uma única aresta, representando a conexão entre os vértices do grafo.
Apesar da existência de modelos para caracterizar falhas em cascata em vários sistemas, nos SGIs esses modelos representam apenas falhas em cascata oriunda da sobrecarga dos serviços prestados. Na literatura há diversos modelos consolidados para caracterizar 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 é desencadeado através da sobrecarga dos nós ativos. Em um SGI esses modelos representam
apenas falhas em cascata oriundas da sobrecarga dos serviços prestados, enquanto que os
efeitos 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. O
principal diferencial deste modelo consiste em tratar de falhas em função da exploração de
vulnerabilidades no processo de autenticação de provedores de identidades. Assim como
modelos de falhas em cascata em Smart Grids, assumimos como premissa a interdependência entre elementos do sistema. No SGI, a interdependência ocorre entre diferentes
federações, indicando que a falha em uma federação implicará em falhas em outras federações. Além disso, tal como na caracterização de falhas em cascata na Internet, usamos
diferentes tipos de vértices para diferentes elementos do SGI. Em nosso modelo usamos
três diferentes tipos de vértices para representar as IDs, provedores de identidades e provedores de serviços de um SGI.
3. Modelo de Falhas em Cascata para Sistemas de Gerenciamento de
Identidades
Esta seção detalha o modelo proposto para representar falhas em cascata em um SGI. A
subseção 3.1 detalha a modelagem do SGI através de um grafo. A subseção 3.2 descreve
o comportamento do sistema através da teoria dos conjuntos; e a subseção 3.3 demonstra
o 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, identificador
e credencial. Uma entidade pode ser uma pessoa, um serviço de rede ou um dispositivo [Torres et al. 2013]. Uma ID consiste na representação digital de uma entidade em
interações eletrônicas [Phiri and Agbinya 2006]. Uma entidade pode assumir várias identidades com diferentes objetivos, por exemplo, em um sistema um usuário pode ter uma
conta de usuário comum e outra como super usuário. O identificador consiste em um índice único usado para referenciar uma ID no SGI. Uma credencial trata-se de informações
confidenciais das IDs usadas para provar sua autenticidade em um SGI, podendo ser uma
senha ou informações biométricas [Smedinghoff 2012]. A Figura 1 demonstra a relação
entre 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 cada
identidade possui um identificador único e uma credencial. Os conceitos de identificador
e credencial podem parecer confusos, mas a principal diferença entre eles é o fato de que
um identificador deve ser único em um SGI e a credencial não. No SGI, os provedores 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, onde
cada 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 ambiente
cooperativo formado pela associação de diversas federações.
As principais operações de um SGI consistem na identificação, autenticação, autorização e auditoria. A identificação consiste na operação inicial de reconhecimento de
uma ID no SGI com base em seu identificador, esta operação não apresenta validação. A
autenticação consiste no ato de verificação da legitimidade de uma ID por meio da verificação de credenciais. A autorização compreende a concessão de privilégios a uma ID
após autenticação. A auditoria consiste no registro das ações realizadas por uma entidade
em um SGI. Essas operações são críticas para o funcionamento correto de um SGI. O
modelo 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 de
autorizaçã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 de
vértices, A, B e C. Esses conjuntos caracterizam respectivamente as IDs, os provedores
de identidades e os provedores de serviços do sistema, logo o conjunto de vértices de G é a
uniã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}, podendo
também existir arestas entre os elementos de cada conjunto, E3 = {(a1 , a2 )|a1 ∈ A, a2 ∈
5
S
A}, E4 = {(b1 , b2 )|b1 ∈ B, b2 ∈ B}, E5 = {(c1 , c2 )|c1 ∈ C, c2 ∈ C}, logo E =
Ei .
i=1
Cada conjunto de arestas representa um tipo específico de Relação (Re). O conjunto de arestas E1 representa quais provedores de identidades b ∈ B uma ID a ∈ A
pode usar para se autenticar. E2 descreve quais provedores de serviço c ∈ C confiam
nas autenticações de um provedor de identidades b ∈ B. E3 retrata a composição de IDs
parciais de um usuário. E4 expõe a relação dos provedores de identidades que apresentam propriedades em comum. E5 representa a composição de provedores de serviços, ou
seja, situações onde serviços podem ser consumidos por outros serviços, tal como ocorre
em SOAs. Em outras palavras, em G qualquer tipo de relação pode existir, exceto as associações de IDs com provedores de serviços, pois essa relação não é fiel a forma como
os recursos são compartilhados em um SGI.
As direções das arestas em G representam as características do SGI. As arestas
entre os conjuntos seguem a direção A → B → C. A direção A → B representa a
associação das IDs com seus respectivos provedores de identidades. B → C indica de
quais provedores de identidades os provedores de serviços aceitam autenticações. Dentro
de 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ções
não importam para caracterizar as falhas em cascata. Além disso, o grafo G não considera
peso nas arestas, retratando a indiferença de qual provedor de identidades irá autenticar
uma ID, contanto que o provedor de serviços desejado aceite essa autenticação. Como
també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 cor
cinza representam os provedores de identidades do conjunto B e os de cor preta, os provedores de serviços do conjunto C. As arestas de G apresentam a direção A → B → C
e não possuem peso. Também se observa que G é conexo, pois não existem vértices sem
arestas. Além disso, nota-se que podem existir ciclos em G entre elementos do mesmo
conjunto. Sendo Cn um ciclo onde n vértices são adjacentes, o centro do grafo apresenta um C4 entre elementos de C, representado uma composição de quatro provedores
de serviço. Logo abaixo do C4, um C5 entre elementos do conjunto B é encontrado,
caracterizando cinco provedores de identidades com vulnerabilidades em comum no mecanismo 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 Cascata
Nesta subseção o modelo de falhas em cascata para um SGI global é descrito usando a
teoria 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 0 o conjunto de subconjuntos de C,
ou seja, C 0 = 2|C| , logo os elementos de C 0 representam todas as combinações possíveis
dos elementos de C. Em outras palavras, cada elemento de C 0 é um subconjunto de
provedores de serviço que confiam na autenticação de uma ID a ∈ A por um provedor
de 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 contra
domínio formado pelas arestas que saem de A para B. Da mesma forma, o conjunto B
como domínio de uma função e C 0 como seu contradomínio.
Seja f : A → B a função bijetora que descreve as arestas do conjunto A para B e
g : B → C 0 a função sobrejetora que descreve as arestas do conjunto B para C 0 . 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 ilustra
a 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, f also} a função bijetora de autenticação cujo retorno é um
valor 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 ∈ B
para acessar um provedor de serviços c ∈ C. Se as credenciais apresentadas para a ID
a forem verdadeiras, esta será autenticada com sucesso e auth(a) retornará verdadeiro,
caso contrário retornará f also. Seja b ∈ B o provedor de identidades escolhido pelo
usuário para autenticar a ID a, logo a função g(b) pode ser usada para extrair a quantidade
de 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ó do
SGI é apresentado. Assumimos uma falha como a exploração de uma vulnerabilidade
no processo de autenticação de um provedor de identidades que resulta na violação das
medidas de monitoramento e controle das IDs. O modelo da falha é realizado provando o
seguinte lema.
Lema 1 Se existe uma vulnerabilidade vul em um provedor de identidades b ∈ B que
quando explorada possibilita burlar as credenciais de uma ID, então existem falhas de
autorizaçã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, de
modo que vul possibilita manipular a resposta da função auth retornando verdadeiro
para um atacante que objetiva passar-se indevidamente por uma ID a ∈ A. Seja f ault
a função que representa esta falha de segurança no SGI. Logo, podemos denotar f ault
como uma função composta f (g(x)), onde f ault(a) = f ◦ g(a) = f (g(a)). Como
auth, 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 afetados
por essa falha também será no mínimo um e no máximo |C|. Portanto, se existe uma
vulnerabilidade vul em um provedor de identidades b ∈ B que se explorada possibilita
burlar as credenciais de uma ID, então existem falhas de autorização em no mínimo um e
no máximo |C| provedores de serviços c ∈ C. 3.3. Prova por Indução da Falha em Cascata
Esta subseção demonstra como ocorre a falha em cascata em um SGI. Através do Lema 1
provamos 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 provedor de identidades concederão acesso indevido ao atacante para a ID com a autenticação
burlada.
Agora, a ocorrência da falha em cascata em um SGI é demonstrada através de uma
prova por indução. Este tipo de prova oferece iteratividade, pois através dela podemos
representar os estágios da disseminação da falha de segurança e seus efeitos. A ideia
base desta prova consiste em mostrar a existência de um caminho entre os provedores de
identidades que apresentam a mesma vulnerabilidade.
Prova. Por indução no número de provedores de identidades compondo um caminho entre
esses provedores com a mesma vulnerabilidade.
Hipótese. Existe um caminho entre os provedores de identidades que representa o efeito
de uma falha em cascata.
Base. Queremos demonstrar o efeito de uma falha em cascata quando o caminho entre os
provedores de identidades tem apenas dois vértices.
Seja b1 ∈ B o provedor de identidades cuja a vulnerabilidade vul foi explorada para
burlar 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 identidades
com propriedades em comum. Logo, as arestas incidentes à b1 ∈ E4 descrevem quais
provedores de identidades a vulnerabilidade vul pode ser explorada. Logo, exitem dois
vértices b1 , b2 conectados por arestas pertencentes à E4. Seja um caminho em um grafo
uma sequência de vértices, onde cada vértice apresenta uma aresta para o próximo vértice
da sequência. Logo, existe um caminho P a somente com dois elementos do conjunto de
vértices B, onde b1 é o vértice inicial e b2 o elemento final. Este caminho representa por
quais vértices a falha em cascata pode ser disseminada pelo SGI. Considerando o Lema
1, a falha de cada provedores de identidades deste caminho afetará no mínimo um e no
máximo |C| provedores de serviços. Passo. Queremos provar que existe um caminho com i + 1 provedores de identidades que
representam uma falha em cascata em um SGI.
Suponha a existência de i provedores de identidades em um caminho P a.
Logo, existe um caminho P a = {b1 , b2 ..., bi }, onde cada provedor de identidades possui
a vulnerabilidade vul.
Logo, aplicando o Lema 1, existe um caminho P a = {b1 , b2 ..., bi+1 }.
Portanto, sabemos que cada um destes vértices pode comprometer no mínimo um e no
máximo |C| provedores de serviço.
Note que através do modelo de falha em cascata proposto, o funcionamento do
provedor de identidades sob ataque não é falha em decorrência da sobrecarga, pois para
autenticações de IDs legítimas, o SGI funcionará normalmente, inclusive com provedores
de identidades falhos. Neste ponto o modelo proposto se diferencia dos modelos de falha
em cascata da literatura, pois a disseminação da falha não ocorre com base na sobrecarga
dos nós e sim na exploração de vulnerabilidades presentes em um conjunto de provedores
de identidades.
112
4. Estudo de Caso
Esta seção descreve um estudo de caso aplicando o modelo proposto. A Subseção 4.1
detalha informações da base de dados coletada de um SGI. A Subseção 4.2 apresenta a
abstração do sistema através do modelo proposto. A Subseção 4.3 explica a análise do
efeito da falha em cascata na abstração do SGI.
4.1. Descrição da Base de Dados Shibboleth
O estudo de caso é realizado sobre dados coletados do sistema Shibboleth. O Shibboleth
consiste no framework de gerenciamento de identidades federado mais utilizado no meio
acadêmico para Web Single Sign-on [Watt et al. 2011]. A técnica de Single Sign-on permite que uma autenticação bem sucedida em um provedor de identidades de um domínio
seja aceita em outros domínios da federação, sem a exigência de novas autenticações a
cada nova sessão e minimizando a necessidade do usuário memorizar um grande número
de senhas. Esta solução federada vem sendo projetada para suprir a necessidade de garantir o acesso seguro a recursos compartilhados entre diferentes domínios de maneira
descentralizada.
Uma base de dados composta por logs de autenticação de um sistema Shibboleth
real foi empregada para criação de um cenário de análise. Os dados foram coletados
pelo SGI da Universidade de Buffalo, localizada em Nova York. O período de coleta
compreendeu 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 por
serviço. Esses dados utilizados podem ser encontrados no sítio Web da Universidade de
Buffalo [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ço
contabilizam 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ão
obtidos dois arquivos, um contendo as requisições de autorização por domínio e outro
com as requisições de autenticação por serviço. Para evitar a análise de uma grande
quantidade 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 de
um mês com maior número de provedores de identidades, provedores de serviços e o mais
recente possível. Com base nestes critérios, o mês de Setembro de 2013 foi selecionado
para análise. Neste mês a infra-estrutura de gerenciamento de identidades analisada conta
com seis provedores de identidades s e dez principais provedores de serviços, totalizando
mais de dois milhões de autorizações.
4.2. Abstração do sistema Shibboleth Através do Modelo Proposto
A abordagem utilizada para representar o sistema Shibboleth através do grafo proposto
como modelo consiste em separar os provedores de serviços, os provedores de identidades
e as IDs em diferentes conjuntos de vértices e em seguida relacioná-los. Denotamos uma
instância desse grafo como H = (V, E), onde V é o particionamento de três conjuntos
de vértices, A, B e C, caracterizando IDs, provedores de identidades e provedores de
serviç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úmero
exato de IDs para o conjunto A, pois somente as requisições originadas por cada domí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, entendese que esse fato não compromete os objetivos da análise, pois podemos considerar as
IDs como um único conjunto e investigar a disseminação da falha entre os provedores de
identidades. 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 elementos. O conjunto B, responsável por agregar os provedores de identidades, apresenta seis elementos, sendo eles: download.acsu.buffalo.edu, myub.buffalo.edu, ublearns.buffalo.edu, ubsis.buffalo.edu, myaccount.myubcard.com e ubmail.buffalo.edu. Enquanto que o conjunto C, incumbido de representar os provedores de serviços, totaliza
dez elementos, sendo eles: messagesystems.com, rr.com, optonline.net, level3.net, pavlovmedia.com, mycingular.net, verizon.net, com.sg, myvzw.com e buffalo.edu. A Figura
4 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 respectivamente
os conjuntos A, B e C pertencentes a H e suas respectivas arestas. O único vértice branco
da figura foi usado para representar o conjunto identidades que agrega todas as IDs do
SGI. Os vértices de cor preta representam seis provedores de identidades da Universidade
de Buffalo, constituindo o conjunto B. Aqueles de cor cinza representam os provedores de
identidades e consequentemente o conjunto C. O conjunto de arestas E1 é representado
pelas linhas do conjunto A para cada elemento do conjunto B. O conjunto de arestas
E2 é caracterizado pelas linhas contínuas que partem de cada elemento do conjunto B
para todos os elementos do conjunto C. Os conjuntos de arestas E3, E4 e E5 não foram
representadas nesta figura, pois os dados analisados não descreviam essas relações. Mais
detalhes 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 vulnerabilidade vul em comum. Dessa forma, existe um caminho P a contendo os seis provedores de
identidades pertencentes ao conjunto de vértices B que demonstra uma possível sequência de falhas decorrentes da exploração de vul. Tendo como base o Lema 1, então cada
um destes provedores de identidades afetará no mínimo um e no máximo |C| provedores
de serviços c ∈ C. Como todos os provedores de identidades foram afetados, logo |C|
provedores de serviços serão comprometidos. Dessa forma, P a representa o caminho de
114
uma falha em cascata no sistema Web Single Sign-on Shibboleth utilizado como estudo de
caso, embasando a aplicabilidade do modelo neste sistema.
É possível perceber que ao realizar essa demonstração da falha em cascata tevese o cuidado para não realizá-la de maneira exaustiva e repetitiva. Outra questão que
pode chamar atenção é que o estudo de caso apresentado baseia-se em dados coletados
de apenas uma federação de identidades, mas o modelo proposto visa representar um
SGI composto por diversas federações. Essa decisão é justificada pela capacidade do
modelo proposto em representar tanto federações, quanto um SGI composto por diversas
federações. O modelo proposto representa as entidades do SGI e as relações entre essas
entidades, 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 Universidade
de Buffalo. A análise do efeito da falha em cascata compõe três etapas. A primeira etapa
consiste em representar o subgrafo de provedores de identidades através de uma matriz
de adjacência. A segunda aplica diferentes probabilidades da distribuição binomial para
variar a presença de vulnerabilidades em comum nos mecanismos de autenticação destes
provedores de identidades. A terceira mensura o efeito da disseminação de falhas nas
componentes conexas através da definição da métrica impacto da falha em cascata.
Seja H 0 o subgrafo com seis vértices que descreve as relações entre os provedores de identidades do grafo H e M como a matriz de adjacência para representá-lo, logo
M (H 0 ) = M6,6 . Para denotar o conjunto de arestas E4, responsáveis por descrever vulnerabilidades 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 adjacentes
e 0 caso contrário. A Figura 5 apresenta a matriz de adjacência M .
índices
1
2
M6,6 =
3
4
5
6








1
2
3
4
5
6
m1,1
m2,1
m3,1
m4,1
m5,1
m6,1
m1,2
m2,2
m3,2
m4,2
m5,2
m6,2
m1,3
m2,3
m3,3
m4,3
m5,3
m6,3
m1,4
m2,4
m3,4
m4,4
m5,4
m6,4
m1,5
m2,5
m3,5
m4,5
m5,5
m6,5
m1,6
m2,6
m3,6
m4,6
m5,6
m6,6








Figura 5. Matriz de Adjacência M
Na Figura 5, os índices de 1 à 6 representam os vértices que especificam mecanismos de autenticação dos provedores de identidades do subgrafo H 0 . O conjunto de
elementos em vermelho (estilo de fonte em negrito) representa o triângulo superior da
matriz. O conjunto de elementos em azul (estilo normal de fonte) caracteriza o triângulo
inferior. 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ângulo
superior e inferior variam entre zero e um de forma simétrica ao longo da diagonal principal 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 o
triângulo inferior mais sua transposta, ou seja, M = T (M ).
A distribuição binomial é aplicada com diferentes probabilidades para obtenção
dos valores da matriz de adjacência, gerando um espaço amostral da presença de vulnerabilidades. Para representar as arestas entre os seis vértices são necessários quinze valores
distribuídos de forma simétrica entre o triângulo superior e inferior, variando entre zero e
um. O total de combinações de zeros e uns para quinze valores é igual a 215 , resultando
em 32768 combinações. Considerando a presença de um grande número de provedores
de identidades em um SGI global, percebe-se que analisar todas as possibilidades pode
ser uma tarefa exaustiva, justificando a análise de amostras.
Ao todo dez variações de probabilidades são analisadas, para cada uma delas 35
amostras foram colhidas. O intervalo de variação de probabilidade para caracterizar a
presença de vulnerabilidades em comum entre os mecanismos de autenticação do SGI
Shibboleth 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 do
subgrafo H 0 apresenta n componentes conexas de provedores de identidades.
A análise para mensurar o impacto da falha em cascata dá-se através da comparação da disseminação de falhas nas componentes conexas gigante em detrimento às
componentes conexas aleatórias. Assumimos que a descoberta de uma vulnerabilidade
de uma componente conexa sempre será disseminada para todos os demais provedores de
identidades. Além disso, definimos como provedores de identidades falhos aqueles que
tiveram as vulnerabilidades de seus mecanismos de autenticação exploradas. Para menP IF
surar o efeito da falha em cascata a métrica IF C, denotada pela equação IF C = N
,
NT P I
é definida. Onde NPIF consiste no número de provedores de identidades falhos e NTPI
representa o número total de provedores de identidades.
Os resultados da análise mostram que uma falha em cascata em um SGI real pode
resultar em danos catastróficos. A comparação entre a disseminação de falhas na Componente Conexa Gigante (CCG) e em Componente Conexa Aleatória (CCA) aponta que a
disseminaçã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 pode
comprometer um SGI em cerca de 70%. A Figura 6 ilustra esses resultados.
Impacto da Falha em Cascata (%)
100
90
CCG
CCA
80
70
60
50
40
30
20
10
0
0.05
0.1
0.15 0.2 0.25 0.3 0.35 0.4
Probabilidade de Vulnerabilidade
0.45
0.5
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 CCG
em detrimento a CCA de provedores de identidades do SGI Shibboleth da Universidade
de Buffalo com intervalo de confiança de 95%. A análise deste gráfico aponta que o IFC
na maior componente conexa apresenta um crescimento exponencial próximo a 100%
dos provedores de identidades com 0.45 de probabilidade da presença de vulnerabilidades. Em contraste, o ápice do IFC nas componentes conexas aleatórias compreendeu um
valor inferior a 70% de provedores de identidades com 0.4 de probabilidade da presença
de vulnerabilidade. Esse resultado mostra que mesmo com baixa probabilidade de vulnerabilidade entre provedores de identidades os efeitos de uma falha em cascata em um SGI
global são catastróficos.
5. Conclusões
Este trabalho apresentou um modelo analítico de falhas em cascata em um SGI e analisar seu efeito. O SGI foi modelado através de um grafo e seus comportamentos com
a teoria dos conjuntos. A disseminação da falha em cascata foi representada através de
um caminho entre provedores de identidades com vulnerabilidades em comum no processo de autenticação. Um estudo de caso foi realizado para demonstrar a aplicabilidade
do modelo proposto considerando dados reais de gerenciamento de identidades coletados
do Web Single Sign-On Shibboleth da Universidade de Buffalo. No estudo de caso, a presença de vulnerabilidades em comum entre os provedores de identidades foi caracterizada
através de variações de probabilidades da distribuição binomial, resultando em diferentes
conjuntos de vértices conectados entre si. Os resultados indicam que a disseminação de
falhas com probabilidade de vulnerabilidades de 0.45 nos conjuntos maiores impacta em
100% dos provedores de identidades e a disseminação de falhas em conjuntos de tamanho
aleató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”: Prototyping
an online information segregation service. In Kurosu, M., editor, Human-Computer
Interaction. Users and Contexts of Use, volume 8006 of Lecture Notes in Computer
Science, 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 IEEE
International 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). Intermittent
failure dynamics characterization. IEEE Transactions on Reliability, 61(3):649–658.
Crucitti, P., Latora, V., and Marchiori, M. (2004). Model for cascading failures in complex
networks. 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., and
Stanley, H. E. (2010). Catastrophic cascade of failures in interdependent networks.
Nature.
Huang, Z., Wang, C., Ruj, S., Stojmenovic, M., and Nayak, A. (2013). Modeling cascading failures in smart power grid using interdependent complex networks and percolation theory. In IEEE Conference on Industrial Electronics and Applications, pages
1023–1028.
Kinney, R., Crucitti, P., Albert, R., and Latora, V. (2005). Modeling cascading failures in
the north american power grid. The European Physical Journal B - Condensed Matter
and Complex Systems, 46(1):101–107.
Lampropoulos, K. and Denazis, S. G. (2011). Identity management directions in future
internet. 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 identity
management systems. In Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies, page
181.
Sankar, S. and Gurumurthi, S. (2013). Soft failures in large datacenters. IEEE Computer
Architecture 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 for
the 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 facebook and google: A traffic-guided security study of commercially deployed singlesign-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 and
authorisation in the social science domain. In International Conference on Availability,
Reliability and Security, pages 541 –548.
118
Análise Sistemática do Fenômeno Bufferbloat
Thiago B. Cardozo1 , Alex B. Vieira2 , Artur Ziviani1 , Ana Paula C. Silva3
1
Laboratório Nacional de Computação Científica (LNCC)
Petrópolis – RJ – Brasil
2
Departamento de Ciência da Computação
Universidade Federal de Juiz de Fora (UFJF)
Juiz de Fora – MG – Brasil
3
Universidade 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 possible
explanation for the increased network latency observed in the Internet. The
bufferbloat phenomenon is related to the excessive packet queueing in over-sized
buffers inside the network that may lead to network performance degradation. In
this context, we observe a lack of experimental results considering the practical
aspects of off-the-shelf network devices. Therefore, in this paper, we present a
systematic analysis of the bufferbloat phenomenon considering the microscopic
view of the insides in the buffer architecture of typical network devices. Our
experimental results show that bufferbloat might not be a significant problem
in practice. First, the phenomenon is only observed in specific cases. Second,
changes made to the queues under the control of the operating system have
negligible effects. Finally, recent proposals that are commonly implemented in
recent versions of the Linux kernel avoid bufferbloat, even in the specific cases
in which it was observed.
Resumo. Há um interesse recente no fenômeno chamado bufferbloat como uma
possível explicação para o aumento de latência observado na Internet. O fenômeno bufferbloat está relacionado ao armazenamento excessivo de pacotes em
buffers superdimensionados nos dispositivos de redes que pode levar a uma degradação do desempenho da rede. Neste contexto, observamos a falta de resultados experimentais considerando os aspectos práticos de dispositivos de rede
existentes comercialmente. Assim, neste artigo, apresentamos uma análise sistemática do fenômeno bufferbloat considerando a visão microscópica da arquitetura de filas de um dispositivo de rede típico. Nossos resultados experimentais
mostram 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 sistemas operacionais como Linux evitam o bufferbloat, até mesmo nos cenários
específicos em que se observou tal fenômeno.
119
1. Introdução
O aumento na latência fim-a-fim é um dos problemas que afetam a Internet nos dias
atuais [Lee et al., 2010]. A literatura recente identifica o fenômeno do bufferbloat
como uma das possíveis causas para este aumento. O bufferbloat ocorre como consequência das filas com excessivo espaço de armazenamento que estão presentes nos
roteadores da rede. Esta grande quantidade de armazenamento gera um atraso significativo, que persiste por longos intervalos de tempo, degradando o desempenho da
rede [Gettys e Nichols, 2012]. Assim, os últimos anos têm testemunhado uma grande atividade na comunidade científica de redes de computadores envolvendo estudos a respeito
do 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, a
perda de dados, sendo seu dimensionamento, entretanto, um desafio recorrente na
área [Appenzeller et al., 2004]. Filas com tamanhos excessivamente grandes podem impactar no funcionamento do controle de congestionamento do TCP (Transmission Control
Protocol), o protocolo de transporte mais comum na Internet. Dado que o TCP detecta
o congestionamento na rede mediante a perda de pacotes [Jacobson, 1988], o armazenamento excessivo nas filas faz com que os atrasos aumentem significativamente, sem que
o TCP diminua a taxa de envio de dados. Este comportamento acarreta em sobrecarga
ainda maior na rede, potencializando a emergência de latência fim-a-fim excessiva.
Apesar da capacidade excessiva de enfileiramento nos dispositivos de rede e
a consequente possibilidade do aumento na latência fim-a-fim, a maioria dos estudos existentes no assunto apenas discute o potencial impacto negativo do bufferbloat [Gettys e Nichols, 2012, Nichols e Jacobson, 2012], sem apresentar uma análise
sistemática avaliando o fenômeno em si. Allman [Allman, 2013] apresentou um primeiro
estudo sistemático do bufferbloat, investigando o problema de um ponto de vista macroscó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 com
tráfego real é pequeno.
Neste artigo, apresentamos uma análise sistemática dos efeitos do bufferbloat considerando uma visão microscópica das filas internas de uma arquitetura típica de dispositivos de rede. Avaliamos as principais métricas de rede, como a latência fim-a-fim e a
vazão, em cenários que variamos o tamanho das principais filas dos roteadores. Nossos
experimentos foram conduzidos em um testbed controlado, usando hardware comercial e
software gratuito. Nossa investigação analisa os efeitos causados pelo aumento do tamanho das filas nos dispositivos de rede comumente encontrados no mercado. Em tais dispositivos, há duas filas principais: (i) uma fila circular ligada ao hardware da interface de
rede (ring buffer); e (ii) outra fila ligada ao sistema operacional (qdisc). A visão microscópica do problema apresentada em nosso estudo experimental complementa o trabalho
de Allman [Allman, 2013] que considerou uma visão macroscópica do problema, através
de 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 trabalhos 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 pouco
efeito 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 principais métricas de rede em cenários onde variamos apenas o tamanho do ring buffer (fila
circular relacionada à interface de rede). Neste caso, o aumento dessa fila específica resulta em um aumento excessivo na latência, caracterizando o fenômeno bufferbloat. Por
exemplo, comparando-se o cenário com valores padrões das filas com o cenário onde
incrementa-se o tamanho do ring buffer para 4096 pacotes, observamos até 585% a mais
no atraso fim-a-fim. Em contraste, alterações no qdisc (fila relacionada ao sistema operacional) não apresentam impactos significativos em métricas como atraso fim-a-fim e taxa
de transferência. Finalmente, também apresentamos uma análise considerando mecanismos disponíveis em versões recentes do kernel de sistemas operacionais Linux que foram
incorporados visando o combate aos efeitos do bufferbloat.
Este artigo está organizado como se segue. Na Seção 2, apresentamos em mais
detalhes 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 algumas
das possíveis soluções encontradas na literatura. Finalmente, a Seção 6 resume nossos
principais 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 chegada de pacotes que podem variar significativamente em um pequeno intervalo de
tempo [Nichols e Jacobson, 2012]. Atualmente, devido ao baixo custo da memória presente nos roteadores, não é raro encontrar uma grande capacidade de armazenamento
nestes equipamentos, inclusive nas versões mais simples. A premissa dos fabricantes é
que uma quantidade maior de capacidade de armazenamento evita perda de pacotes, melhorando 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 uma
latência fim-a-fim elevada, bem como na degradação da vazão dos dados. De fato, filas
grandes em roteadores não é um problema recente [Nagle, 1985]. Em uma rede com filas
infinitas e pacotes com tempo de vida limitado, a vazão tende a zero. Isso ocorre porque
pacotes são enfileirados por longos períodos e seu tempo de vida expira antes (ou logo
após) dos mesmos serem reencaminhados pelos roteadores.
Um importante efeito colateral do fenômeno bufferbloat é a degradação na eficiência do algoritmo de controle de congestionamento do TCP. O algoritmo de controle
de congestionamento do TCP ajusta a sua taxa de transferência face a um aumento de
latência que resulta em perda de pacotes, evitando assim uma saturação desnecessária
do caminho [Jacobson, 1988]. Esse algoritmo considera, portanto, o descarte de pacotes
como uma indicação implícita de congestionamento na rede. Com o aumento da capacidade de armazenamento dos roteadores, e a consequente disponibilidade de maiores filas
de pacotes, o congestionamento do caminho ocorre sem o descarte de pacotes. Desta
forma, o algoritmo de controle de congestionamento do TCP não ajusta a sua janela de
transmissão adequadamente, degradando o desempenho da rede.
121
Em resumo, o fenômeno bufferbloat pode ser a causa chave para o aumento da
latência fim-a-fim observado na Internet atual. O enfileiramento excessivo nos roteadores
pode reduzir o desempenho do TCP, que por sua vez impacta na qualidade da maioria das
aplicações que utilizam a Internet. O possível impacto negativo no desempenho da rede
e suas implicações práticas são os principais pontos de motivação para uma investigação
mais detalhada do bufferbloat.
3. Ambiente de teste
3.1. Testbed
Nosso testbed é configurado de maneira a possibilitar a análise sistemática do fenômeno
bufferbloat através do controle de importantes parâmetros, tais como o tamanho das filas
dos dispositivos de rede envolvidos no experimento. A experimentação proposta permite
a avaliação de métricas de rede relevantes, como a latência fim-a-fim e a vazão. Neste artigo, consideramos diferentes cenários onde variamos o tamanho das filas dos dispositivos
de redes pertencentes ao testbed.
A Figura 1 mostra a topologia do testbed utilizado nos experimentos. A rede
consiste 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 hosts
estão conectados através de duas VLANs, uma contendo os nós A, B, C e D e a outra os
nós D e E.
Figura 1. Configuração do testbed.
No testbed configurado, o nó D atua como um roteador doméstico, sendo
este o principal equipamento de rede com problemas de excesso de enfileiramento [Gettys e Nichols, 2012]. Note que a conexão entre D e E é o gargalo da rede
configurada. Toda a comunicação entre 2 nós finais precisa passar pelo roteador no centro
da 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 .
1
www.apple.com
www.debian.org
3
www.nongnu.org/quagga/
2
122
Quagga é um software de código aberto que implementa os algoritmos de roteamento
mais importantes.
Sem perda de generalidade, nosso testbed representa um cenário típico. Normalmente, entre um roteador doméstico e a rede de um ISP, e até mesmo entre pequenas redes
de escritório, observamos um gargalo em apenas um enlace. Em outras palavras, os pontos finais da rede possuem uma grande quantidade de recursos. No entanto, estes pontos
são geralmente conectados por um enlace de capacidade limitada. Dessa forma, durante
nossos 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 é a
configuração das filas no testbed. As filas estão por todo o caminho na rede, incluindo
nos hosts finais, nos roteadores e nos switches. Desta forma, é importante ter em mente
o quadro geral que descreve o fluxo de pacotes da camada de aplicação até a camada de
enlace.
Em nosso trabalho focamos em dispositivos baseados em Unix, dado que a maioria 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ão
desenvolvidos 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 em
dispositivos baseados em Unix. Estamos particularmente interessados no comportamento
do sistema quando as filas qdisc e ring buffer tem seu tamanho variado.4 Estas filas são
responsáveis pelo armazenamento de pacotes nas camadas de rede e enlace, respectivamente. Além disso, focamos nossa análise nas filas de saída uma vez que as filas de
entrada possuem capacidade suficiente para o processamento dos pacotes.
A fila de saída qdisc está localizada entre as camadas de rede e enlace. Em sistemas Unix, o qdisc possui 1000 pacotes como capacidade padrão. Contudo, é possível
configurar 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 outras
palavras, pacotes são enfileirados na ordem em que chegam e são reencaminhados para a
camada de enlace na mesma ordem.
O ring buffer, ao contrário, é uma fila de saída colocada entre as camadas de enlace
e física. Ela recebe os pacotes que chegam do qdisc e os entrega para a camada física do
NIC (Network Interface Card). O tamanho padrão e os limites inferior e superior do ring
buffer são definidos pelo driver do NIC, que é geralmente configurado, por padrão, em
torno de 512 pacotes. A possibilidade de mudar a capacidade do ring buffer usando o
comando ethtool depende da disponibilidade de tal funcionalidade no driver do NIC.
4
Tipicamente, refere-se ao tamanho das filas qdisc e ring buffer como a capacidade de armazenamento
de pacotes que estas possuem. Em uma implementação prática, entretanto, essas filas na verdade armazenam descritores que apontam para a região de memória onde o conteúdo de cada pacote se encontra.
5
Figura simplificada baseada na Figura 6-3 de [Wehrle et al., 2004].
123
Aplicação
Espaço de
usuário
Espaço de
Kernel
Buffer de envio
do TCP (tcp_wmem)
Processo TCP
Camada IP
qdisc
(txqueuelen)
Driver do NIC
Ring
Buffer
Transmissão de
Pacote
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, seguindo a metodologia apresentada por [Jiang et al., 2012b]. O principal objetivo é buscar
induzir 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ós
A, B e C) usando o nó D com roteador. Em cada experimento, usamos um arquivo de
conteúdo aleatório com tamanho aproximado de 32 MB, suficiente para garantir que os
mecanismos 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 concorrentes e cerca de 1 GB de dados transferidos no total, para garantir que o enlace de
gargalo seja estressado.
Para cada experimento, monitoramos o tempo de ida e volta (RTT) pelo uso da
ferramenta ping como um fluxo de sonda para coleta de dados e a vazão obtida entre
os nós servidores e o nó cliente do testbed. Também monitoramos o número de pacotes
descartados. Os resultados apresentados são a média dos valores de 10 experimentos
com
√
barras 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], assumimos
que o RTT varia pela variação de ocupação das filas. Outras flutuações de atraso não
causadas pela ocupação da fila são consideradas negligenciáveis.
124
4.1. Experimentos variando o tamanho do ring buffer
Nesta seção, analisamos o impacto da variação do tamanho do ring buffer no fenômeno
bufferbloat, mantendo o tamanho padrão do qdisc (1000 pacotes). Este cenário é equivalente ao cenário analisado no estudo original que descreveu o fenômeno bufferbloat
proposto em [Gettys e Nichols, 2012]. A Figura 3(a) mostra a média do RTT para diversos tamanhos de ring buffer. Pelos resultados, podemos claramente notar que o RTT
aumenta 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. No
entanto, 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 e
retransmissõ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 no
roteador da rede diminui após um ring buffer de 80 pacotes. Isso ocorre, pois os roteadores
param de descartar pacotes por falta de espaço, enquanto o algoritmo de retransmissão
rápida do TCP inicia equivocadamente a retransmissão de pacotes que ainda estão presos
na fila de gargalo.
Os resultados experimentais mostrados nesta seção corroboram o conjunto 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é o
momento consideram a variação de apenas um parâmetro (tamanho do ring buffer) envolvido no fluxo de pacotes sobre uma pilha de protocolos de rede em equipamentos
baseados em Unix (Figura 2). É interessante observar o que acontece no caso onde mantemos o tamanho padrão do ring buffer e variamos o tamanho do qdisc. Considerando
essa nova perspectiva, o comportamento do sistema muda e alguns resultados interessantes aparecem, conforme discutiremos na Seção 4.2.
4.2. Experimentos variando o tamanho do qdisc
Para o conjunto de experimentos descritos a seguir, o valor do ring buffer foi mantido
em seu valor padrão (512 pacotes definido pelo driver da placa de rede) e o tamanho do
qdisc foi variado. A Figura 4(a) mostra que com o aumento do tamanho do qdisc, o RTT
se mantém razoavelmente estável. E em contraste com os resultados na Seção 4.1, não
ocorre 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 retransmitidos
aumentam até uma fila qdisc de 512 pacotes. Após esse ponto, ambos os valores de descartes e retransmissões caem para valores negligenciáveis. Esse comportamento ocorre
dado 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 qdisc
A Figura 5 mostra o impacto no valor do RTT com a variação conjunta do tamanho do
ring buffer e do qdisc. Conforme mostrado na Figura 4, filas maiores que 4K pacotes são
capazes 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 contraste, a variação do tamanho do ring buffer leva a um alto RTT e, consequentemente, à
ocorrência do fenômeno bufferbloat.
125
RTT Médio (ms)
14000
12000
10000
8000
6000
4000
2000
0
96
40
48
20
24
10
2
51
6
25
80
Tamanho do ring buffer (pacotes)
180000
150000
120000
90000
60000
30000
0
96
40
48
20
24
10
2
51
6
25
80
Número de pacotes
descartados
(a) RTT médio x tamanho do ring buffer.
Número de
retransmissões
(b) Média de pacotes descartados x tamanho do ring buffer.
90000
75000
60000
45000
30000
15000
0
96
40
48
20
24
10
2
51
6
25
80
(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 e
qdisc na vazão do sistema. A Figura 6 mostra que a vazão média tende a ser razoavelmente
estável com o aumento do tamanho do ring buffer. Por exemplo, considerando a faixa
de tamanhos de fila associados ao qdisc (0, 80, 28 , 29 , 210 , 211 , 212 ), a diferença entre a
vazão alcançada pelo menor tamanho de ring buffer (80 pacotes) e a alcançada pelo maior
tamanho 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 tamanho de ambas as filas, ring buffer e qdisc, causa efeitos independentes no desempenho
do 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ó receptor
não fosse um fator limitante durante as transferências, foi observado a evolução do tamanho da janela de recepção anunciada durante a sequência de transmissão do TCP. Como
pode ser verificado na Figura 7, com o aumento do número de sequência de transmissão,
126
RTT Médio (ms)
2100
1800
1500
1200
900
600
300
0
96
40
48
20
24
10
2
51
6
25
80
0
Tamanho do qdisc (pacotes)
150000
120000
90000
60000
30000
0
96
40
48
20
24
10
2
51
6
25
80
0
Número de pacotes
descartados
(a) RTT médio x tamanho do qdisc.
Número de
retransmissões
(b) Média de pacotes descartados x tamanho do qdisc.
80000
60000
40000
20000
0
96
40
48
20
24
10
2
51
6
25
80
0
(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 consideravelmente a capacidade de armazenamento de pacotes no receptor, permitindo que os
transmissores mantenham uma alta vazão durante o experimento. Assim, durante os experimentos, podemos supor que as transmissões TCP não são limitadas pela janela de
recepçã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 quantos bytes a interface de rede é capaz de transmitir. Através deste mecanismo, a quantidade
de pacotes enviada ao ring buffer é reduzida, deslocando o enfileiramento para as camadas
acima da camada de enlace. Assim, o enfileiramento pode ser tratado com a utilização de
6
O window scaling é uma opção disponível em implementações mais recentes do TCP que possibilita
que a janela anunciada pelo receptor exceda o limite padrão de 65,535 bytes.
127
RTT médio (ms)
14000
12000
10000
Tamanho do
Ring Buffer
(pacotes)
8000
80
256
512
1024
2048
4096
6000
4000
2000
0
96
40
48
20
24
10
2
51
6
25
80
0
Figura 5. Impacto dos tamanhos de buffer (ring buffer e qdisc) no RTT.
100
Vazão (kbps)
80
Tamanho do
Ring Buffer
(pacotes)
60
80
256
512
1024
2048
4096
40
20
0
96
40
48
20
24
10
2
51
6
25
80
0
Figura 6. Impacto dos tamanhos de fila na vazão.
disciplinas de fila eficientes implementadas no qdisc, permitindo um gerenciamento de
fila mais sofisticado e possibilitando a redução da latência.
A seguir descrevemos os experimentos realizados que visam avaliar o impacto da
utilização BQL em um roteador suscetível ao fenômeno bufferbloat. Esses experimentos
sã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 tamanho
total de 5.000 pacotes. O tamanho do ring buffer será reduzido ao mesmo tempo em que
o tamanho do qdisc será incrementado do mesmo montante, mantendo o tamanho total
da fila “virtual” inalterado. Por exemplo, com um ring buffer de tamanho igual a 4096
pacotes, o qdisc terá tamanho igual a 904 pacotes. Dessa forma podemos observar como
o 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 bufferbloat
nos casos onde o tamanho do ring buffer é configurado com valores muito elevados. A utilizaçã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
Janela de recepção
Tamanho da janela
anunciada (MB)
5
4
3
2
1
Janela anunciada
0
0
50000
100000 150000
Sequência
200000
Figura 7. Tamanho da janela de recepção anunciada pelo TCP.
1
P(RTT ≤ h)
0.8
Tamanho do
Ring Buffer/qdisc
(pacotes)
0.6
80 4920
128 4872
0.4
256 4744
512 4488
1024 3976
0.2
2048 2952
4096 904
0
0
5000
10000
15000
RTT h (ms)
20000
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 do
ring buffer para o qdisc com o BQL, podemos verificar uma diferença expressiva de 20 ms
entre o RTT no 95-percentil do qdisc com tamanho pequeno (904 pacotes) e do qdisc com
tamanho grande (4920 pacotes). Nos casos em que o tamanho do qdisc é determinante no
aumento da latência, disciplinas de fila como o CoDel7 [Nichols e Jacobson, 2012] podem ser utilizadas, solucionando o problema do bufferbloat induzido pela utilização do
BQL.
5. Discussão sobre soluções existentes
Existem algumas propostas recentes na literatura para reduzir o impacto do fenômeno bufferbloat. Tipicamente, tais soluções são implementadas na camada de transporte ou
na camada de rede. Considerando a camada de transporte, podemos citar os controles de congestionamento que se baseiam em atraso, tais como protocolos de Con7
O CoDel é um algoritmo recente de gerenciamento ativo de fila (AQM) motivado pelo bufferbloat.
129
1
P(RTT ≤ h)
0.8
Tamanho do
Ring Buffer/qdisc
(pacotes)
0.6
80 4920
128 4872
0.4
256 4744
512 4488
1024 3976
0.2
2048 2952
4096 904
0
40 50
60 70 80 90 100 110 120 130
RTT h (ms)
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 diferentes 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, como
sistemas operacionais ou firmware de roteadores domésticos. Um dos LPCCs mais populares é o Low Extra Delay Background Transport (LEDBAT), que é um protocolo alternativo ao TCP criado originalmente para as redes Peer-to-Peer Bittorrent e apresentado
em [Chirichella e Rossi, 2013]. Os autores em [Chirichella e Rossi, 2013] mostraram que
o LEDBAT impede o aumento da latência causado por enfileiramento para a maioria dos
usuários de Bittorrent. Um problema recorrente encontrado nos controles de congestionamento 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 em
uma distribuição irregular da banda disponível entre as aplicações, reduzindo, consequentemente, a qualidade de experiência do usuário.
Os algoritmos de gerenciamento ativo de fila, como o Random Early Detection (RED) [Floyd e Jacobson, 1993] e suas variantes, precisam ser implementados nos roteadores e são difíceis de serem configurados e adaptados para as constantes mudanças na rede [Gettys e Nichols, 2012]. Para combater o bufferbloat,
[Nichols e Jacobson, 2012] propuseram o algoritmo de gerenciamento de fila CoDel em
resposta direta a [Gettys e Nichols, 2012]. Esse algoritmo essencialmente busca detectar
uma fila “ruim”, que é uma fila que cresce de forma nociva sem demonstrar sinais de
esvaziamento. Frente a uma fila “ruim”, o algoritmo intencionalmente inicia uma fase de
descarte de pacotes para induzir a ativação do controle de congestionamento do TCP. A
grande vantagem do CoDel face aos demais algoritmos baseados em AQM anteriores é o
fato 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 coexistir de forma transparente e isolada. Entretanto, em [Gong et al., 2014] foi evidenciado
que 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 excessivo 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 fluxos, tendo uma prioridade reduzida. Consequentemente, os LPCCs sobre a influência dos
AQMs tem sua baixa prioridade ignorada e os fluxos se tornam tão agressivos quanto os
fluxos TCP originais, reduzindo a vantagem no uso de LPCCs para evitar a sobrecarga da
rede.
6. Conclusão e visão geral
Neste artigo, apresentamos uma avaliação sistemática do fenômeno bufferbloat considerando uma visão microscópica do interior de uma arquitetura de dispositivos de rede
típicos. No geral, nós podemos destacar três resultados de nossos experimentos: (i) tamanhos menores do ring buffer permitem que o sistema operacional sinalize corretamente a
presença de filas “ruins” (i.e., um fila persistentemente cheia) e, como consequência, os
controles internos do TCP continuam operando corretamente; (ii) valores maiores para
o 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, o
fenômeno bufferbloat só é percebido quando o tamanho padrão do ring buffer (ou o equivalente em outras arquiteturas) é inadvertidamente modificado. De fato, limitar o tamanho
do ring buffer foi sugerido anteriormente como uma possível forma de mitigar os efeitos
do fenômeno bufferbloat [Corbet, 2011]. Também foi analisado o impacto que o mecanismo BQL, presente em versões recentes do Kernel do Linux, tem em um roteador com
um tamanho de ring buffer elevado. O algoritmo BQL remove o problema do bufferbloat
associado ao dimensionamento inadvertido do tamanho do ring buffer. Em nossos experimentos, a latência em um sistema com BQL foi reduzida em 2 ordens de magnitude
quando 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 possivelmente 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 para
o recente aumento de latência fim-a-fim observado na Internet, começamos a considerar
outras questões que podem potencialmente incrementar atrasos na rede. Estamos considerando possibilidades como o aumento da adoção de hardware emulado por software e
virtualização da rede. Investigar tais questões e seus efeitos particulares no atraso fim-afim observado na rede é o alvo de nosso trabalho futuro.
Agradecimentos
Este trabalho é parcialmente financiado pelas agências de fomento CNPq, FAPERJ e FAPEMIG bem como pelo Ministério da Ciência, Tecnologia e Inovação (MCTI).
Referências
Allman, M. (2013). Comments on Bufferbloat. ACM SIGCOMM Computer Communication Review, 43(1):31–37.
131
Appenzeller, G., Keslassy, I., e McKeown, N. (2004). Sizing router buffers. In Proceedings of ACM SIGCOMM, pages 281–292.
Brakmo, L. S., O’Malley, S. W., e Peterson, L. L. (1994). TCP Vegas: New techniques
for congestion detection and avoidance. In Proceedings of ACM SIGCOMM.
Chirichella, C. e Rossi, D. (2013). To the Moon and back: are Internet bufferbloat delays
really 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 avoidance. IEEE/ACM Transactions on Networking, 1(4):397–413.
Gettys, J. e Nichols, K. (2012). Bufferbloat: Dark Buffers in the Internet. Communications of the ACM, 55(1):57–65.
Gong, Y., Rossi, D., Testa, C., Valenti, S., e Täht, M. (2014). Fighting the bufferbloat: on
the 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, Technische
Universität Berlin.
Jacobson, V. (1988). Congestion avoidance and control. ACM SIGCOMM Computer
Communication Review, 18(4):314–329.
Jiang, H., Liu, Z., Wang, Y., Lee, K., e Rhee, I. (2012a). Understanding Bufferbloat in
Cellular Networks. In Proceedings of the 2012 ACM SIGCOMM Workshop on Cellular
Networks: 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 or
Worse? 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 the
ACM, 55(7):42–50.
Wehrle, K., Pahlke, F., Ritter, H., Muller, D., e Bechler, M. (2004). Linux Networking
Architecture. Prentice Hall.
132
Distribuição de Vídeo sob Demanda Baseada em
Redes 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
1
Grupo 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 content
delivery. The recent increase in content demand aggravates the management
and performance issues faced by these networks, based on the end-to-end communication model. This paper evaluates the performance of a prototype that delivers video on demand using a Content Oriented Network. In Content Oriented
Networks, efficient content delivery becomes a network task and main objective.
The performance of the implemented prototype was compared with the TCP/IP
protocol stack. The results show that the proposed prototype delivers content efficiently and decreases network overhead by 83%, while maintaining the quality
of service perceived by the end consumer. Furthermore, mobility experiments
performed verify that the prototype supports mobility of clients, which also allows the reduction of the bandwidth on the physical network while avoiding
video stream interruption during network transition.
Resumo. As Redes de Distribuição de Conteúdo foram concebidas para entregar conteúdo de forma eficiente. No entanto, o aumento da demanda por
conteú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ídeo
sob demanda utilizando uma Rede Orientada a Conteúdo. Em Redes Orientadas 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 comparada
com a pilha de protocolos TCP/IP. Os resultados comprovam que o protótipo
proposto 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ço
percebida pelo consumidor final. Além disso, foram realizados experimentos de
mobilidade que comprovam que o protótipo suporta mobilidade de consumidores de conteúdo, de modo a reduzir o uso de banda total na rede física e evitar
a 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 acesso
a 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 demanda
atual é caracterizada por acesso a serviços online e busca, produção e distribuição de
conteúdo [Schulze and Mochalski 2009]. Os usuários buscam cada vez mais acesso a
conteúdo de forma rápida e com qualidade, sem se importar com a origem do mesmo. A
pilha TCP/IP não possui mecanismos naturais capazes de garantir qualidade de serviço
na entrega de conteúdo através da Internet. Por essa razão, novas alternativas para entrega
eficiente de conteúdo como as Redes de Distribuição de Conteúdo (Content Distribution
Networks - 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 dos
conteúdos a serem distribuídos, a fim de reduzir a latência de entrega. Contudo, escolha da localização dos servidores, o redirecionamento de clientes para os servidores de
réplicas e a distribuição eficiente de cópias de conteúdo entre servidores são problemas
complexos. Os sistemas P2P criam redes ad hoc de usuários que compartilham fragmentos de conteúdo. Devido à natureza mutável da solução, a disponibilidade dos conteúdos
não é garantida. Além disso, sistemas P2P dependem da instalação de aplicações pelo
consumidor final e sobrecarregam a rede com mensagens de controle e a abertura de múltiplas conexões. Nesse contexto, surge a ideia de Redes Orientadas a Conteúdo. Nas
Redes Orientadas a Conteúdo, o conteúdo é o elemento fundamental, e a entrega eficiente
de conteúdo passa a ser uma tarefa de rede.
Este artigo propõe distribuir vídeo sob demanda utilizando Redes Orientadas a
Conteú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 cache distribuído para obter ganhos de desempenho. A proposta prevê a implementação de
uma rede CCN sobreposta à rede dos Provedores de Serviços de Internet (Internet Service
Providers - ISPs). A rede CCN trabalha em cooperação com as CDNs. Os conteúdos de
vídeo disponibilizados pelas CDNs nas interfaces entre as redes dos ISPs e o núcleo da
Internet são redistribuídos pela rede CCN até as bordas das redes dos ISPs para o consumidor final, onde pontos de conversão CCN/IP permitem obter o conteúdo demandado via
IP. A existência dos pontos de conversão permite que o sistema seja transparente para os
consumidores, não exigindo instalação de nenhuma aplicação além de um reprodutor de
vídeo convencional. O protótipo da proposta foi implementado e avaliado em uma rede
no FITS (Future Internet Testbed with Security) 1 , uma plataforma de testes para propostas 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 a
conteúdo reduz a carga na rede dos ISPs devido à capacidade da CCN de agregar fluxos
de dados, ao mesmo tempo que mantém a taxa de entrega de conteúdo aos clientes. Os resultados comprovam que o esquema proposto suporta mobilidade de clientes, o que pode
ser utilizado para promover redução adicional do tráfego na rede física e para melhorar a
qualidade de serviço de distribuição de vídeo ao se disponibilizar o conteúdo a partir de
pontos de conversão próximos aos consumidores.
A distribuição de vídeo sob demanda (Video on Demand - VoD) vai ao encontro
das novas tendências de uso da Internet. O serviço Netflix, que disponibiliza conteúdo de
vídeo sob demanda é responsável por 30% do tráfego de rede na América do Norte durante
1
http://www.gta.ufrj.br/fits
134
o horário de pico [Frank et al. 2013]. Além disso, as atividades de distribuição contínua
de vídeo consomem banda intensamente e a agregação de Dados e Interesses realizada
pela 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 uma
análise do custo-benefício do uso de memória a fim de se obter economia de banda em
redes CCN. Segundo o estudo, a quantidade de cache necessária se obter economias de
banda consideráveis na distribuição de vídeo sob demanda é várias vezes menor que a
quantidade necessária para se obter o mesmo efeito com outros tipos de tráfego, como
compartilhando arquivos acessando sites na web.
A questão da colaboração entre ISPs e CDNs é abordada por Frank et al., que propõem o protocolo de comunicação NetPaas [Frank et al. 2013]. A proposta foca apenas
na 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 requisiçõ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 desempenho da distribuição de réplicas de conteúdo nas CDNs e estudos sobre cache cooperativo de conteúdo de vídeo em CCN mostram uma significativa redução de tráfego inter
ISPs [Li and Simon 2011]. Essas propostas tem como foco a questão do aumento de eficiência das CDNs ou estratégias de cacheamento para redução de tráfego inter ISPs, e
podem ser consideradas complementares à proposta desse artigo, visto que não abordam
a 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 apresentados 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 nas
Seções 6 e 7, respectivamente. Finalmente, a Seção 8 conclui o artigo.
Jiang 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]. A
introdução da orientação a conteúdo nas CDNs permite utilizar múltiplas fontes e múltiplos destinos e facilita o gerenciamento da distribuição de conteúdo, o que melhora o
desempenho das CDNs. Para avaliar o desempenho da proposta nCDN, foi feita uma série
de 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 sua
eficiência em diversos aspectos, como rendimento máximo em situação de sobrecarga, latê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ão
trata o problema de sobrecarga da rede dos ISPs ou a questão do acesso dos clientes aos
conteú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 da
nCDN, promove redução do tráfego interno à rede dos ISPs e entrega conteúdo de vídeo
aos clientes de forma transparente. Além disso, a proposta nCDN foi avaliada apenas mediante simulações e os autores deixaram a implementação de um protótipo como trabalho
futuro. Este artigo preenche esta lacuna ao avaliar o desempenho do sistema proposto
135
a partir de dados reais coletados de uma rede experimental implementada especialmente
para esse fim.
Frank et al. realizam um estudo sobre a colaboração entre ISPs e
CDNs [Frank et al. 2013]. Frank et al. defendem que muitas vezes a eficiência da distribuição de conteúdo é prejudicada porque o sistema de distribuição de conteúdo se vale
de informações equivocadas sobre a localização dos consumidores ou informações deficientes 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 permitir uma comunicação efetiva entre ambos os agentes. O NetPaaS permite que as CDNs
peçam aos ISPs indicações dos melhores servidores para encaminhar os consumidores e
també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 NetPaaS 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 disponibilizado. Cabe às CDNs gerenciar esse processo. No esquema de distribuição apresentado, a
rede orientada a conteúdo gerencia a distribuição de conteúdo, o que, conforme apresentado 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ão
apenas resolve o problema de comunicação entre ISPs e CDNs, como também distribui o
conteúdo disponibilizado pelas CDNs e permite acesso dos clientes aos conteúdos através
dos 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údo
a fim de reduzir o tráfego inter ISPs é abordada por Li e Simon [Li and Simon 2011]. O
artigo propõe uma estratégia de cache cooperativo projetada para o tratamento de vídeos
longos oferecidos sob demanda. O artigo defende que a política utilizada nas CCNs, em
que 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 de
conteúdo cujo módulo k corresponde a seu identificador. Os autores mostram através de
uma série de simulações que a proposta pode reduzir em até 60% o tráfego inter ISPs sem
comprometer a eficiência da CCN na distribuição de conteúdo. Embora também trate da
questão da distribuição de vídeo, o trabalho de Li e Simon se foca na redução de tráfego
inter ISP e negligencia a questão da entrega de conteúdo aos consumidores finais que não
possuem aplicações compatíveis com a pilha CCN. Por esse motivo, a proposta de cache
cooperativo apresentada poderia complementar à proposta apresentada nesse artigo, cujo
objetivo é 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és
do uso de redes orientadas a conteúdo [Zhu et al. 2013]. Nenhuma das atuais propostas
de mobilidade IP foi amplamente aplicada, entre os motivos podem ser citados a inflexibilidade do modelo de comunicação e medidas fracas de segurança diante de um ambiente
dinâmico. Nesse cenário, a segurança está dependente de ambos os extremos da comunicaçã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 localização. São utilizados dados nomeados ao invés de endereços de destino para entrega
de 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ão
significante. 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údo
A 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ão
dos usuários, que passaram a ser também produtores de conteúdo, e a disseminação do
uso de serviços vorazes em termos de consumo de banda, como o caso da distribuição
contínua de vídeos.
As CDNs buscam disponibilizar os recursos necessários para garantia de qualidade de serviço (Quality of Service - QoS) continuamente, independentemente de flutuações da demanda. Normalmente, a escalabilidade das soluções adotadas nas CDNs é
garantida pela distribuição de servidores próximos aos consumidores contendo réplicas
dos conteúdos a serem distribuídos [Saroiu et al. 2002]. Essa solução, no entanto, recai
em problemas complexos de posicionamento de servidores, replicação de conteúdos e
gerenciamento das requisições dos clientes.
Os servidores de réplicas devem ser posicionados tão próximos dos consumidores
finais 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 quantas
ré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 devem ser levados em consideração. Existem abordagens teóricas para a resolução desses
problemas, mas elas são extremamente custosas em termos computacionais. Normalmente 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 ainda
apresentam custos computacionais elevados [Peng 2004]. No entanto, como a demanda
por conteúdos é irregular e mutável, nada garante que o posicionamento dos servidores e
réplicas será satisfatório ao longo do tempo, o que incorre em novos custos de instalação
de servidores.
Uma vez posicionados servidores de réplicas, é necessário encaminhar cada cliente ao conteúdo desejado. Ao se utilizar a Internet, baseada no modelo de identificação
de hospedeiros, para buscar conteúdo, se faz necessário um mapeamento entre “o que se
busca” 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 reencaminhar
as 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ão
complexas e incorrem em problemas de sobrecarga, como no caso da multiplexação de
clientes e roteamento P2P, ou dependem de modificações em estruturas da Internet, como
no caso do redirecionamento de DNS ou anycasting3 [Peng 2004].
2
Problemas em que não há garantias de que a solução possa ser encontrada dentro de um tempo polinomial da ordem do problema.
3
Um 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 atravé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 orientadas
a 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, para
a dinâmica de entrega de conteúdo ser eficiente, a nomeação de hospedeiros deve ser
substituída pela nomeação de conteúdo. A identificação única de cada conteúdo através
de um nome desacopla o conteúdo de sua localização, o que permite buscar diretamente
os 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 nome
formado 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 propostas de redes de dados nomeados (Named Data Networking - NDN) foram criadas ao longo do tempo, todas apresentando soluções para problemas da Internet
atual. Entre elas figuram DONA [Koponen et al. 2007], LIPSIN [Jokela et al. 2009] e
TRIAD [Cheriton and Gritter 2000]. Contudo, a CCN é a mais atual delas e desponta
como uma das mais promissoras propostas de Internet do Futuro. Além disso, a CCN
possui uma implementação experimental que roda sobre IP, a CCNx [CCNx 2011], que
foi utilizada na rede de testes implementada neste artigo.
Em uma CCN, todos os nós podem ser considerados roteadores, uma vez que podem tanto enviar e encaminhar requisições quanto receber e encaminhar conteúdo. Existem apenas dois tipos de pacotes: Interesse e Dados. Um pacote de Interesse é enviado
sempre que um nó deseja acessar determinado conteúdo. Pacotes de Dados só são transmitidos 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 consumidores. A rede CCN encaminha os Interesses no sentido dos produtores de conteúdo, o
primeiro nó que possui o conteúdo requisitado responde com os Dados correspondentes
pelo caminho inverso seguido pelos Interesses.
Os roteadores CCN possuem três estruturas de dados principais: a Base de Informações de Encaminhamento (Forwarding Information Base - FIB), o Armazém de
Conteú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 respondidas localmente. A FIB da CCN é similar à FIB no IP, armazenando regras baseadas em
prefixos de nomes, um mapa das interfaces de saída correspondentes e outras regras mais
específicas relacionadas a prefixos. Contudo, na CCN a FIB pode relacionar diversas
interfaces de saída a um mesmo prefixo, ordenando-as por prioridade. A PIT guarda as
interfaces de entrada e saída pelas quais Interesses ainda não respondidos chegaram e foanycast são respondidas pelo receptor mais próximo. A escolha do receptor está sujeita ao critério de
proximidade adotado.
138
ram encaminhados. Interesses referentes a um mesmo dado são agregados e apenas uma
requisição é enviada a cada interface de saída. Dessa maneira, apenas um dado é recebido
e reencaminhado a todas as interfaces por onde foram recebidos Interesses.
A possibilidade de resposta local de requisições, propiciada pelo armazenamento
de conteúdo em cada roteador, e a agregação de fluxos acarretada pelo envio de apenas 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 Dados. Essas características aliadas aos mecanismos de balanceamento de carga, controle
de fluxo ponto-a-ponto e de verificação de recebimento de dados inerentes à arquitetura [Jacobson et al. 2009, Guimaraes et al. 2013], tornam a CCN ideal para aplicações
como transmissão contínua (streaming) de vídeo.
5. Arquitetura da solução proposta
Este artigo propõe a implementação de uma rede CCN superposta à rede IP dos provedores de serviço de Internet para a distribuição conteúdo. Na solução proposta, a CCN
trabalha 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ção
trabalha cooperativamente com as CDNs, distribuindo conteúdo através da rede
dos 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 de
dados são armazenadas nos roteadores que os encaminham. A rede CCN distribui os
conteúdos até pontos de conversão existentes nas bordas da rede dos ISPs, aos quais os
consumidores se conectam via IP a fim de acessar os conteúdos disponibilizados. Essa
configuraçã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 o
consumidor final.
Os pontos de conversão situados nas bordas da rede são roteadores capazes de traduzir requisições de conteúdo via IP em requisições de conteúdo via CCN. Eles reconstroem o conteúdo a partir dos pedaços de conteúdo nomeado recebidos e o disponibilizam
aos clientes via IP, utilizando quaisquer métodos comumente utilizados para distribuição
de vídeo, tais como HTTP, RTSP, UDP ou TCP. Esses pontos de conversão concentram
todos os pedidos dos consumidores e geram os pedidos de Interesse pelos conteúdos buscados. Os roteadores agregam esses Interesses antes de enviá-los, o que reduz a carga no
núcleo da rede dos ISPs. Adicionalmente, a agregação de fluxos de Interesses e Dados
isola o núcleo da rede das flutuações na demanda percebidas em suas bordas, pois dispositivos podem se conectar aos pontos de conversão até que sua capacidade de conexão se
esgote, sem que fluxos duplicados sejam repassados para o núcleo da rede. No entanto, a
distribuição dos conteúdos aos consumidores a partir dos pontos de conversão pressupõe a
duplicação de fluxos, pois é feita via IP, em unicast. Por esse motivo, os pontos de conversão devem ser instalados próximos às bordas da rede a fim de minimizar o número saltos
necessário para se alcançar os consumidores e com isso reduzir o número de enlaces com
fluxos duplicados.
Quanto mais roteadores CCN existirem na rede do ISP, maior esse efeito de agregação de pacotes e menor o número de pacotes duplicados que circulam pelos roteadores
funcionando puramente com IP [Guimaraes et al. 2013]. Isso cria um incentivo adicional
para a expansão da rede CCN implementada e constitui uma grande vantagem quando
considerado o crescimento do número de dispositivos móveis, como smartphones e tablets verificado nos últimos anos.
A rede CCN também pode ser utilizada para prover conteúdo a consumidores
que possuam suporte à comunicação com CCNs disponível em seus dispositivos pessoais. Nesse caso, a eficiência da distribuição aumentará, pois a rede CCN formada pelos
roteadores da rede dos ISPs será complementada por uma rede peer to peer formada pelos dispositivos móveis. A dinâmica da CCN prevê a busca por pedaços de conteúdo no
cache de quaisquer dispositivos CCN próximos e suporta mobilidade de consumidores.
A rede CCN detecta automaticamente esses recursos adicionais e com isso aumenta sua
abrangência e eficiência. Dispositivos que possuem recursos limitados, como smartphones, podem optar por continuar a usar os pontos de conversão e acessar os conteúdos
via conexão IP a fim de economizar recursos como memória e bateria. Ao utilizar uma
aplicação IP em vez de uma aplicação CCN para obter conteúdo, os dispositivos ficam
isentos de difundir os nomes dos conteúdos que possuem e de enviar pacotes de Dados
para 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 beneficiar da mobilidade de consumidores inerente à arquitetura CCN. Enquanto que o suporte
a 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 de
consumidores de forma direta [Zhu et al. 2013]. Um consumidor pode requisitar dados
diretamente da rede sem prévia configuração de endereço ou da conexão. Quando um
pacote 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 encaminhados 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 de
ponto de acesso implica apenas na criação de outro caminho reverso. No entanto, quando
um dispositivo muda de rede, as insformaçoes na FIB local precisam ser atualizadas, o
que, para o caso da mobilidade de consumidores, pode ser resolvido pela retransmissão
dos pacotes de interesse [Wang et al. 2013].
6. Cenário de testes
Os testes foram realizados no Future Internet Testbed with Security
(FITS) [Moraes et al. 2014], uma plataforma de testes interuniversitária para propostas de Internet do Futuro. O FITS é mantido pelo Grupo de Teleinformática e
Automação (GTA) da Universidade Federal do Rio de Janeiro (UFRJ), e possui nós em
universidades 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 experimentaçã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 estrutura física, de forma segura e isolada. O ambiente é flexível e agnóstico aos sistemas
operacionais, aplicações e protocolos utilizados na rede virtual, minimizando restrições e
trazendo maiores possibilidades de experimentação, quando comparado a outras redes de
teste mais restritas.
A distribuição de conteúdo via CCN foi testada em uma rede protótipo criada
especialmente para esse fim. A rede protótipo foi concebida com o objetivo de reproduzir
em menor escala a dinâmica de uma rede de distribuição sobreposta à rede de um ISP
representada na Figura 1. Os experimentos mantém seu foco na rede CCN sobre a rede
do ISP, para tanto o servidor de réplicas na borda da rede de testes já possui a cópia dos
conteúdos requisitados e passa a atuar como provedor de conteúdo da rede de testes. A
Figura 2 apresenta a arquitetura da rede de testes.
A rede é formada por quatro roteadores, um provedor de conteúdo e nove consumidores. Os Roteadores 1, 2 e 3 representam os pontos de conversão e por isso estão
ligados diretamente aos clientes. Cada ponto de conversão está ligado a três clientes. O
Roteador 0 está ligado ao provedor de conteúdo e possui conexões redundantes, formando
uma 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 criada
pelo Centro de Pesquisa de Palo Alto (Palo Alto Research Center - PARC), da Xerox, para
o desenvolvimento da arquitetura CCN. Os roteadores CCN possuem a CCNx versão 0.8.1
instalada. Nos pontos de conversão, além da CCNx, foi instalado o VLC media player
versão 2.0.3 e um plugin que o torna capaz de converter CCNx para IP. Para realização
dos testes, os roteadores foram hospedados em diferentes nós físicos do FITS.
7. Resultados e discussão
As principais vantagens da distribuição de conteúdo utilizando CCN são a redução do
consumo 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, roteadores
CCN 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 ambos
os casos.
7.1. Análise de tráfego
(a) Consumo de banda no enlace entre o servidor (b) Consumo de banda de um dos clientes ligados
e a rede de distribuição.
ao Roteador 3.
Figura 3. O consumo de banda na distribuição via CCN é claramente menor
nas proximidades do provedor de conteúdo. A taxa de entrega de conteúdo aos
clientes, 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ídeo
de aproximadamente 100 MB dentro de uma janela de dois minutos utilizando-se TCP/IP
e a rede CCN. Um vídeo longo foi escolhido para que, dentro de uma janela de tempo
longa o suficiente para se ter medidas confiáveis, o vídeo não tivesse sido inteiramente
baixado, independente do método utilizado. Essa medida foi escolhida em detrimento
da alternativa de se limitar a banda nos enlaces, de modo que todos os enlaces foram
mantidos com taxa de transmissão padrão de 1 Gb/s.
Nos testes utilizando CCN, o vídeo foi disponibilizado no servidor como conteúdo
nomeado. 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 foi
disponibilizado em HTTP diretamente no servidor. A avaliação de desempenho foi feita
mediante comparação do uso de banda total em cada enlace, expressado como uma função
cumulativa da quantidade de bytes trafegados.
A Figura 3 mostra um comparativo da quantidade de bytes trafegados nas extremidades do sistema na distribuição via IP e via CCN. A Figura 3(a) apresenta o tráfego
nas imediações do servidor de conteúdo, enquanto a Figura 3(b) apresenta o tráfego que
chega a um cliente.
Os resultados mostram que o sistema formado pela rede CCN e os pontos de conversão é capaz de reduzir significativamente o tráfego de rede decorrente da distribuição
de vídeo, enquanto mantém a taxa de entrega de conteúdo aos clientes. Esse efeito é mais
significativo nas imediações do provedor de conteúdo. Os resultados referentes ao tráfego
no núcleo da rede são mostrados na Figura 4. Observa-se que o tráfego total na distribuição via CCN é 83% menor que o tráfego gerado na distribuição via IP para o cenário
testado.
Figura 4. Tráfego cumulativo na rede do ISP. A distribuição via CCN reduz consideravelmente 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 mobilidade, foi construída uma rede de testes que possui três roteadores CCN que em escala
reduzida representam a rede CCN interna de um ISP, um provedor de conteúdo, dois
pontos de acesso sem fio e um dispositivo móvel que representa o cliente. O dispositivo
móvel com a CCNx versão 0.8.1 instalado foi conectado a um desses pontos de acesso
e buscou reproduzir um vídeo recebido via transmissão contínua utilizando distribuição
via IP e via CCN. A ligação entre o Roteador 0 e o provedor de conteúdo representa a
conexão do ISP com a rede CDN que contém o vídeo sob demanda. Os pontos de acceso
sem fio estão conectados aos Roteadores 1 e 2 que por sua vez estão conectados a rede
CCN interna do ISP. Durante a transmissão, o dispositivo foi trocado de rede e conectado
ao outro ponto de acesso. A Figura 5 ilustra o procedimento.
O dispositivo móvel foi mudado de rede algumas vezes durante a transmissão do
ví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óvel
se 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ção
continuou 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 dos
pontos 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 para
Rede Sem Fio 2 no instante 15s e retorna à Rede Sem Fio 1 no instante 56s. A
entrega de conteúdo continua, apesar do cliente mudar de rede.
O experimento demonstra que a qualidade de serviço na mobilidade em CCNs
prevista por Zhu [Zhu et al. 2013] é garantida. Quando o cliente solicita o vídeo a partir
de 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 pedido
de interesse. Dessa forma, enquanto o cliente muda de ponto de acesso, o conteúdo de
pedidos anteriores vai estar sendo atendido pelo provedor de conteúdo e residirá no cache
da rede CCN interna do ISP. Quando o cliente reenviar os interesses no outro ponto de
acesso, agora conectado ao Roteador CCN 2, esses serão atendidos prontamente pelos
Roteadores CCN 0 e 1 que já possuem o conteúdo no cache. Logo, não é necessário o
reenvio 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ão
Este artigo analisa a distribuição de conteúdo utilizando uma rede CCN sobreposta às
redes dos ISPs para distribuir conteúdo de vídeo sob demanda. A rede CCN trabalha em
cooperação com CDNs, de modo que um provedor de conteúdo, ou seja, um servidor de
réplicas de uma CDN, se conecta à rede CCN. A utilização de conteúdo nomeado desacopla os dados da localização geográfica de seus provedores, o que facilita a distribuição
de conteúdo e aumenta sua eficiência.
A distribuição de conteúdo através da rede CCN é transparente para os consumidores na solução proposta, dado que o acesso aos conteúdos é disponibilizado através de
pontos de conversão localizados nas extremidades da rede. Quanto mais próximos aos
usuários se localizarem os pontos de conversão, mais eficiente a entrega de conteúdo e
maior a economia de banda alcançada. Como a distribuição na última milha é feita via
IP, 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 obtido
diretamente via CCN, o que proporciona suporte à mobilidade de usuários.
Os testes realizados na rede do protótipo desenvolvido demonstram que a utilização da CCN melhora significativamente o desempenho da distribuição de vídeo sob
demanda em relação ao uso de banda total na rede. A CCN é especialmente eficiente na
redução da carga na rede nas imediações dos servidores, o que propicia o isolamento entre
a carga no núcleo da rede e a demanda percebida em suas extremidades. Além disso, os
resultados comprovam que o sistema dá suporte à mobilidade de usuários, reproduzindo
ví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 nextgeneration internet architecture. Technical report, Stanford Computer Science Technical 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 traffic mix on caching performance in a content-centric network. In Computer Communications 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-centric
networks in the future internet testbed environment. In Workshop on Cloud Convergence, 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
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. Technical
report, Tsinghua University.
[Jokela et al. 2009] Jokela, P., Zahemszky, A., Esteve Rothenberg, C., Arianfar, S., and Nikander, P. (2009). Lipsin: line speed publish/subscribe inter-networking. In ACM
SIGCOMM 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 content centric networking (ccn) for resource-limited mobile consumer devices. Consumer
Electronics, IEEE Transactions on, 57(2):477–483.
[Li and Simon 2011] Li, Z. and Simon, G. (2011). Time-shifted tv in content centric
networks: 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/ (Acessado
em 15/03/2014).
[Peng 2004] Peng, G. (2004).
cs/0411069.
Cdn: Content distribution network.
arXiv preprint
[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 Operating
Systems Review, 36(SI):315–327.
[Schulze and Mochalski 2009] Schulze, H. and Mochalski, K. (2009).
2008/2009. IPOQUE Report, 37:351–362.
Internet study
[Wang et al. 2013] Wang, L., Waltari, O., and Kangasharju, J. (2013). Mobiccn: Mobility support with greedy routing in content-centric networks. In GLOBECOM. IEEE
Global 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 data
networking (ndn) project. Technical Report NDN-0001, Xerox Palo Alto Research
Center-PARC.
[Zhu et al. 2013] Zhu, Z., Afanasyev, A., and Zhang, L. (2013). A new perspective on
mobility support.
146
Florianópolis - SC
(WGRS)
Sessão Técnica 4
Gerenciamento de VANETs e VANTs
Um Mecanismo para Realçar a Conectividade de Roteamento
Geográfico na Transmissão Multimídia em VANTs
Rodrigo Costa1 , Denis Rosário1 , Aldri Santos2 , Eduardo Cerqueira1
1
GERCOM – Grupo de Redes de Computadores e Comunicação Multimídia – UFPA
2
NR2 – 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 usage
of multimedia applications due to its the high mobility degree and versatility.
The transmission data on UAVs using geographic protocols enables a better
data 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 during
the transmission. Those broken links damage the connectivity and cause delay
and packet loss. This paper proposes a mechanism, called RCRV, based on the
mobility prediction techniques to enhance the routing decision making on geographic protocols, and thus improving the connectivity of UAV networks. RCRV
can support the strategies of geographic routing protocols to forward packets.
Further, RCRV was added to GPSR protocol and evaluated by simulation. Results 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 potencializado o uso de aplicações multimídia devido ao seu elevado grau de mobilidade
e versatilidade. A transmissão de dados em VANTs por meio de protocolos geográ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 elevado grau de mobilidade dos VANTs que ocasiona quebras de enlace durante
a transmissão, prejudicando a conectividade e levando a perdas de pacotes e
atrasos. Este trabalho propõe um mecanismo, chamado RCRV, com base em
técnicas de predição de mobilidade em termos de posicionamento e tempo do
enlace para realçar a tomada de decisão de roteamento em protocolos geográficos, e assim prolongar a conectividade em redes VANTs. RCRV complementa as
estratégias de roteamento dos protocolos geográficos, sendo adicionado ao protocolo GPSR para a avaliação por meio de simulação. Os resultados mostram
que o RCRV aumenta a conectividade da transmissão, melhorando a entrega do
conteúdo multimídia e a qualidade do vídeo observado pelo usuário.
1. Introdução
O uso de aplicações multimídia em cenários de monitoramento ambientais, segurança
e 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 tipos
de dados [Ehsan and Hamdaoui 2012]. O emprego de redes VANTs (Veículos Aéreos
Não Tripulados) tem potencializado o uso de aplicações multimídia, visto que um VANT
pode 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 e
sensores, possuem elevado grau de liberdade de mobilidade e versatilidade, isto é, podem
ser empregados em diferentes ambientes.
Porém, o grau de mobilidade dos VANTs do tipo quadricoptero ocasiona diversas
quebras de enlace de comunicação, prejudicando o encaminhamento dos dados e levando
a muitas perdas ou atraso de pacotes transmitidos [Sahingoz 2013]. Assim, um dos desafios das redes VANTs é a mitigação da influência do impacto da mobilidade durante a
transmissão de dados multimídia de modo a auxiliar no gerenciamento da conectividade
entre os VANTs, e assim evitar falhas de comunicação. A manutenção da conectividade
ajuda a reduzir os atrasos e as perdas de pacotes durante a transmissão, proporcionando
certo 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 camadas
MAC (Media Access Control) e de Rede. Na camada MAC, protocolos adaptativos têm
buscado 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 complexidade de hardware, devido à necessidade de prover os arranjos de antenas. Na camada de
Rede, os protocolos de roteamento focam em encaminhar os dados por rotas robustas a
quebras de conexão por mobilidade, estabelecidas por critérios baseados em informações
de 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 de
mobilidade de um VANT em ambientes 3D e assumem mobilidade em ambientes 2D.
Os protocolos de roteamento geográfico normalmente usam qualificadores de conectividade 2D para a seleção de rotas mais robustas e confiáveis. A predição de mobilidade é uma dessas abordagens, onde é possível a estimativa das futuras localizações de
um dispositivo em um ambiente. Entretanto, há diversas categorias de predição de mobilidade [Gavalas et al. 2010], como a predição de posicionamento e o tempo de expiração
do enlace que é baseado na velocidade e direção dos dispositivos [Uddin et al. 2013]. O
tempo de expiração do enlace pode beneficiar as aplicações multimídia quanto à garantia
da transmissão dos dados por rotas mais persistentes. Logo, a predição de posicionamento
e o tempo de expiração do enlace, integrados ao serviço de roteamento, nas redes VANTs
realçariam a qualidade dos vídeos sobre a percepção do usuário, por exemplo um centro
de operações de emergências [Bürkle et al. 2011].
Este artigo propõe um mecanismo, chamado RCRV (Realce de Conectividade em
Redes Vants), para realçar a conectividade em protocolos de roteamento geográfico nas
redes VANTs em ambiente 3D, oferecendo uma maior entrega de pacotes e uma melhor
qualidade do vídeo recebido. O RCRV possibilita um VANT que tenha um pacote a ser
encaminhado estime o posicionamento futuro dos seus VANTs vizinhos e, a partir de
critérios de tempo de expiração do enlace, direção e distância de interceptação desses
vizinhos, calcule seus índices de conectividade. A estimativa de posicionamento futuro
ajuda a monitorar uma possível quebra de enlace de um VANT por afastamento da área
de 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 ao
qual um pacote deveria ser encaminhado.
150
O RCRV foi implementado no protocolo GPSR e avaliado no simulador NS-3 sobre cenários com diferentes mobilidades e densidades de VANTs. A avaliação do RCRV
considera o desempenho da rede e a qualidade do vídeo transmitido por meio de métricas
de 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 os
trabalhos relacionados. A Seção 3 detalha a arquitetura do RCRV e sua integração com os
protocolos 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 nas
camadas MAC e de Rede. Na camada MAC, a grande variação da distância e a alta
mobilidade 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 de
tempo real [Bekmezci et al. 2013]. Em [Alshbatat and Dong 2010], os autores propuseram um protocolo MAC adaptativo em que a transmissão de mensagens RTS/CTS ocorre
por antenas omnidirecionais e a transmissão dos dados por meio de antenas direcionais.
Em [Temel and Bekmezci 2013], os autores desenvolveram um protocolo MAC direcional aliado a três antenas direcionais para a descoberta de vizinhos, a troca de mensagens
RTS/CTS e para a transmissão de dados. No entanto, o uso de arranjos de antenas e de
hardwares adicionais eleva os custos de implantação dos VANTs.
Na camada de Rede, algumas estratégias de roteamento adotam a predição de mobilidade 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óximo
salto. A permanência da transmissão de dados ou sua interrupção é influenciada pelo
distanciamento entre os pares de nós. Entretanto, esta proposta considera que os VANTs
agem sobre um cenário 2D com altura constante. Além disso, a garantia de conectividade
apenas pelo monitoramento da distância é uma solução ineficiente devido à elevada mobilidade dos VANTs. Em [Lin et al. 2012], os autores propuseram um protocolo roteamento
para VANTs em um cenário 2D, onde cada nó prediz a localização dos seus vizinhos por
meio de uma função de distribuição de probabilidade Gaussiana. Além disso, a tarefa de
seleção de rotas considera a distância entre os nós e o destino, bem como a diferença do
tempo de predição para selecionar o próximo salto, mas ignora o uso da estimativa do
tempo de expiração do enlace.
Outros trabalhos tentam garantir a conectividade através do tempo estimado para
um nó alcançar o destino. Em [Zhou et al. 2012], os autores propuseram uma estratégia
de roteamento baseada no uso do sistema ADS-B (Automatic Dependent SurveillanceBroadcast) em conjunto com um protocolo geográfico. A informação de mobilidade fornecida pelo sistema ADS-B ajuda a definir o próximo salto sem a transmissão de localização. Esta proposta melhora a taxa de entrega de pacotes, reduzindo a sobrecarga na
rede. Além disso, a velocidade e a localização do nó permitem a seleção do próximo salto
mais rápido a alcançar o destino. Porém, este trabalho ignora a influência da direção para
estimar quando uma conectividade está quebrada. Em [Rohrer et al. 2011], é proposto
um 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ção
dos melhores próximos saltos em direção ao destino. Contudo, este trabalho assume que
os nós estão em uma altura constante. Além disso, ele considera apenas a direção de um
nó ao nó destino.
3. Mecanismo para Realçar a Conectividade em Redes VANTs
Esta seção descreve o mecanismo RCRV para realçar a conectividade entre nós na transmissão multimídia em protocolos de roteamento geográficos para redes VANTs. O RCRV
considera informações sobre a mobilidade, como a localização, a velocidade e o tempo
para calcular tanto a predição de posicionamento quanto o índice de conectividade. O uso
de um serviço de localização, como o GPS (Global Position System), fornece ao RCRV
informações sobre o posicionamento do nó que realiza o processo de seleção de rota. Vale
ressaltar 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 mecanismo
independente de protocolo de roteamento.
3.1. Arquitetura do RCRV
A Figura 1 mostra a arquitetura de RCRV e sua interação com um determinado protocolo
de roteamento geográfico. O RCRV é composto por dois módulos: Predição de Posicionamento e Classificador de Rota. O módulo de predição de posicionamento monitora a
distâ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 posicionamento
atual dos nós vizinhos de um nó.
O módulo classificador de rota é responsável por calcular um índice de conectividade (IC) com base nos critérios de tempo de expiração do enlace, direção e distância de
interceptação para cada nó vizinho. O valor de IC pode ser aplicado pelas estratégias de
encaminhamento 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 de
um nó nj . Esta estimativa ocorre por meio de informações de coordenadas no plano 3D
(x0j ,yj0 ,zj0 ), 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 = x0j + ∆t(vj sinθj × cosφj )
ypred = yj0 + ∆t(vj sinθj × sinφj )
zpred =
zj0
(1)
+ ∆t(vj cosθj )
Onde, ∆t é a diferença entre o tempo atual tc e o tempo do último pacote de posição para cada nó vizinho nj , ou seja, ∆t = tc − tl . Por outro lado, θj e φj representam
as direções de deslocamento de nj . Em redes VANTs, existe a possibilidade de um nó nj
sair da área de transmissão de um outro nó ni . Neste caso, a predição de posicionamento
permite o monitoramento da distância entre um nó ni e seu próximo salto durante a transmissão multimídia. Portanto, o RCRV garante que um nó ni selecione um novo próximo
salto 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á suporte
as estratégias de encaminhamento para a tomada de decisão sobre o próximo salto. O
IC tem como objetivo ajudar na seleção de um próximo salto com menor influência da
mobilidade na transmissão multimídia. Dessa forma, cada nó computa o IC dos seus
vizinhos (nj ) com base na Equação 2, considerando o tempo de expiração do enlace, a
direção e a distância de interceptação.
IC = minNj ∈Ni ICi,j = α × T ExLi,j + β × DirIj,D (cj , vj , D) + γ × DisIi,j (D) (2)
O cálculo de IC considera pesos (α, β, γ) para cada um dos critérios: T ExLi,j
(tempo de expiração do enlace), DirIj,D (cj , vj , D) (direção de interceptação) e DisIi,j (D)
(distância de interceptação), com a soma dos pesos igual a 1. Assim, é possível atribuir
diferentes 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 essenciais para assegurar uma seleção eficiente e robusta de próximos saltos. Mais especificamente, o T ExLi,j garante a seleção de um próximo salto que possui poucas variações nas
velocidades e direções. Além disso, ele permite o prolongamento da conexão entre os pares de nós participantes da transmissão multimídia. O DirIj,D (cj , vj , D) provê a seleção
dos 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 o
próximo salto mais próximo ao destino, porém não muito próximo ao limite da sua área
de 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 estimar a mobilidade de um nó e garantir que o serviço de roteamento estabeleça rotas mais
robustas [Gavalas et al. 2010]. O tempo de expiração do enlace (T ExLi,j ) é um critério
que estima a duração de um enlace entre dois nós. O RCRV calcula o T ExLi,j por meio
do modelo proposto por [Uddin et al. 2013]. Este modelo utiliza as informações de posicionamento no plano 3D, a velocidade e a direção dos nós. Dessa forma, o modelo estima
o T ExLi,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ós
ni 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 vj
m/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 = (vi sinθi cosφi − vj sinθj cosφj )
f = (vi sinθi sinφi − vj sinθj sinφj )
g = (vi cosφi − vj cosφj )
(3)
O T ExLi,j entre dois nós ni e nj em uma rede 3D é calculado de acordo com uma
equação quadrática, a qual considera que ambos os nós possuem áreas de transmissão
esféricas com um determinado raio T R. Dessa forma, o T ExLi,j é obtido por meio da
Equação 4.
T ExLi,j =
−(2ae + 2bf + 2cg) ±
p
(2ae + 2bf + 2cg)2 − 4(e2 + f 2 + g 2 )(a2 + b2 + c2 − T R2 )
2(e2 + f 2 + g 2 )
(4)
De acordo com a equação proposta, o T ExLi,j é mais influenciado por grandes
variações nas diferenças da direção e da velocidade dos nós, do que pela distância entre
eles. Assim, valores altos de T ExLi,j indicam uma movimentação com trajetórias contrárias ou com velocidades diferentes entre os nós ni e nj . Este comportamento sugere que
tal enlace é mais suscetível a quebra em decorrência da mobilidade, diminuindo assim a
robustez do sistema. Entretanto, valores baixos de T ExLi,j significam que o enlace entre
os 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ós
presentes 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ção
oposta ao destino aumenta o número de saltos. Com isso, ocorre a redução da robustez
e o acréscimo da quantidade de pacotes perdidos. Por consequência, há a diminuição da
qualidade do vídeo. Dessa forma, é preferível que o protocolo de roteamento selecione
pró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 calculado
conforme a Equação 5. Porém, o cálculo do DirIj,D (cj , vj , D) utiliza apenas informações
de 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 ao
destino. Sejam, cj = (xj , yj ) e vj = (vjx , vjy ) as coordenadas e as componentes da
velocidade de um nó nj . Além disso, todos os nós da rede têm o conhecimento sobre
as coordenadas (xd , yd ) do destino. Então, a Equação 5 indica o nó com direção mais
próxima ao destino.
154
DirIj,D (cj , vj , D) =
|θ1 − θ2 |
angleT h
(5)
Onde, θ1 = atan2(vjy , vjx ) 180
representa o ângulo em graus∗ entre o eixo x
π
positivo 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ó nj
π
e a linha imaginária que o interliga ao destino. Por fim, o limiar angleT h é um limiar em
graus 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 um
nó ni . Ambos n1 e n2 podem estabelecer uma rota com ni . Porém, há a necessidade da
verificação das suas direções, a fim de evitar a seleção de um nó com direção oposta ao
destino. De acordo com o exemplo da Figura 2, o nó n1 apresenta uma mobilidade oposta
ao 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 deslocamento
opostas ao destino. Este comportamento pode ocasionar rotas com longos saltos ou a
perda 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, o
limiar angleT h permite a seleção de um nó com melhor direção em relação aos demais
presentes 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 utilizadas em protocolos de roteamento geográficos. Contudo, esta estratégia é ineficiente em
redes composta por nós moveis, como em redes VANTs. A seleção de nós mais próximos
ao destino aumenta a possibilidade de quebra da conexão, devido o afastamento da área
de transmissão dos nós. Portanto, uma seleção de próximo salto eficiente deve atentar aos
efeitos da mobilidade.
∗
atan2(x, y): É uma função presente em várias linguagens de programação e que retorna o quadrante
apropriado 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 entre
um nó ni e um outro nó nj . A obtenção da distância é facilitada pelo conhecimento
sobre o posicionamento de ambos os nós. Desta forma, a Equação 6 permite o cálculo da
distância euclidiana entre os nós ni e nj .
q
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 selecionar
seu próximo salto. Além disso, assumindo (xj , yj , zj ) e (xd , yd , zd ) como as coordenadas
do candidato à próximo salto nj e do destino, respectivamente. Assim, a distância de
interceptação é obtida pela Equação 7.
di,D − dj,D DisIi,j (D) = (7)
di,D
Onde, dni ,D é a distância entre o um nó ni que deseja selecionar seu próximo salto
e o destino. Além disso, dnj ,D é a distância entre o candidato à próximo salto nj e o
destino. Como resultado da equação proposta, a distância DisIi,j (D) privilegia a seleção
dos 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 qualquer protocolo de roteamento geográfico para redes VANTs. Para mostrar os impactos e
benefí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 para
roteamento geográfico e também é empregado em redes VANTs. O GPSR possui dois
modos de operação para o encaminhamento de pacotes. O modo greedy permite a seleção
dos 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 menor
das distâncias entre os demais possíveis nós candidatos presentes na tabela de roteamento
do 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 da
regra da mão direita.
Contudo, as estratégias de roteamento adotadas pelo GPSR não garantem uma
formação eficiente e confiável destas rotas. Isso ocorre porque a seleção dos nós considerando apenas a distância é uma abordagem ineficiente, visto que há a possibilidade
de 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ção
de 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 RCRV
ao GPSR, chamado de GPSR-RCRV, de modo a garantir uma eficiente transmissão multimídia em redes VANTs. Isso ocorre porque o RCRV considera múltiplos critérios para
seleção de próximo salto, e assim ele provê uma melhoria na redução da influência da
mobilidade 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 no
plano 3D e as componentes da velocidade dos seus nós vizinhos. Assim, os nós calculam
o índice de conectividade e a predição de posicionamento, como descrito na Seção 3.
ICQ = 1.06
ICR = 0.89
ICO = 0.39
ICP = 1.59
ICM = 0.44
ICN = 0.56
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 acordo
com o RCRV. O nó M tem IC = 0.44 devido aos três critérios de seleção vistos na
Seção 3. Assim, M segue na mesma direção que F . Logo, o enlace entre F e M permanece ativo por um maior período. Além disso, M segue em direção ao destino, e assim
há um baixo risco de perda de pacotes pelo isolamento deste nó em uma área afastada e
sem vizinhos. Por fim, M tem a menor distância em relação ao nó de destino D. Em
seguida, M seleciona o nó O devido ao seu baixo IC em relação ao nó P . No entanto, o
GPSR selecionaria P , pois tal nó tem a menor distância ao destino. Contudo, P apresenta
uma trajetória oposta ao destino. O processo de seleção continua até que um nó possua o
destino como um dos seus vizinhos.
A rota estabelecida entre os nós F e D permanece inalterada até a ocorrência de
dois eventos. O primeiro evento é a quebra de enlace devido à mobilidade dos nós. Neste
caso, o esquema de predição de posicionamento auxilia no monitoramento periódico da
distância entre pares de nós. Assim, é possível detectar quando um dado próximo salto
pode sair da área de transmissão do seu último salto. O segundo evento é a exclusão de
um nó vizinho devido à expiração do seu registro na tabela de vizinhos. Em ambos os
casos, o GPSR-RCRV reestabelece a rota.
5. Avaliação
O RCRV foi implementado e avaliado no simulador NS-3 versão 3.17. O ambiente de
avaliação considera um cenário de monitoramento urbano para uma situação emergencial
ou de segurança. Este ambiente possui nós VANTs dispostos numa área, onde a unidade
de controle está no centro da área. A mobilidade de um VANT numa rede 3D é representada pelo modelo de mobilidade Gauss-Markov-3D [Broyles et al. 2010], pois ele oferece
um 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 cada
combinação, 33 simulações foram realizadas e os resultados consideram um intervalo de
confiança de 95%. Desta forma, 36, 44 e 56 VANTs foram dispostos aleatoriamente em
uma área de 1000x1000 m, com uma altura uniforme entre 40 e 50 m. As velocidades dos
VANTs 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 mais
próxima a uma rede VANT. Por fim, foram atribuídos os valores de 0.2, 0.3 e 0.5 para os
pesos do índice de conectividade (α, β , γ), e um angleT h 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 comunicam por meio do padrão IEEE 802.11b com uma taxa de transmissão de 11 Mb/s. Cada
VANT também possui um área de transmissão de 250 m definida por uma potência de
transmissã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 Evaluation Tool-Set no simulador. Foram escolhidos os vídeos U AV1 e U AV2 [GERCOM 2013]
na transmissão, pois eles representam a cobertura de um VANT em um ambiente urbano.
No entanto, o vídeo U AV2 possui uma maior região de movimentação do que o U AV1 ,
indicando uma situação de instabilidade de voo. Ambos os vídeos têm 10s de duração, e
são codificados no padrão H.264 em 300 kbps, 18 de tamanho de GoP (Group Of Pictures), formato 352x288 pixels, e uma amostragem igual a 30 quadros por segundo, como
esperado para vídeos em VANTs.
As simulações objetivam avaliar o comportamento do GPSR e do GPSR-RCRV
quanto ao desempenho da rede e da qualidade do vídeo transmitido do ponto de vista dos
usuá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 enviados
na camada de aplicação, e o Atraso médio fim-a-fim (E2E), que significa o tempo médio
entre a transmissão de um dado pacote e sua chegada ao destino. No entanto, tais métricas
apenas refletem o desempenho de um sistema do ponto de vista da rede. Assim, elas não
mostram 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 mais
eficiente do que as métricas de QoS. Nesse contexto, há as métricas de QoE objetivas e
subjetivas, 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 apresente falhas. O SSIM é definido como um valor decimal entre 0 e 1, onde 0 significa que o
ví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 qualidade
de vídeo). Foi utilizado o MSU Video Quality Measurement Tool (VQMT) para medir o
valor 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 e
QoE. Percebe-se que para todas as quantidades de VANTs em 1 m/s, o GPSR apresentou
uma baixa taxa de entrega e um elevado atraso fim-a-fim. Para 36 e 44 VANTs, as taxas de
PDR e E2E foram de aproximadamente 83% e 0.12s, respectivamente. Para 56 VANTs, as
taxas 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 ao
uso do IC para escolher o melhor VANT a encaminhar os pacotes. Assim, GPSR-RCRV
garante 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 de
possíveis quebras de conectividade pelo afastamento da área de transmissão de VANTs
vizinhos. 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 outro
lado, para 56 VANTs esse ganho foi de 60% em relação ao GPSR. Isto ocorre devido ao
GPSR-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 proveu
uma disseminação de vídeo com qualidade assegurada do ponto de vista do usuário em
comparaçã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ção
ao GPSR. Além disso, o GPSR-RCRV utiliza o IC para avaliar o comportamento de mobilidade de um possível VANT candidato a próximo salto. Isso foi refletido em um SSIM
em torno de 0.93 e um ganho de até 7% para 36, 44 e 56 VANTs a 1 m/s. Por outro lado, o
GPSR-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, que
provê o monitoramento de possíveis quebras de conectividade pelo afastamento da área
de transmissão de VANTs vizinhos. Portanto, o GPSR-RCRV garante um melhor nível
de qualidade do vídeo diante de perda de pacotes por colisões devido à alta densidade da
rede ou pela quebra de conectividade. Além disso, é importante ressaltar que o processo
de codificação e decodificação de vídeo também deteriora a qualidade do vídeo na perspectiva do usuário, mesmo na ausência de perda de pacotes. Dessa forma, o vídeo U AV1
apresenta um SSIM máximo de 0.97. Assim, para 36, 44 e 56 VANTs a 1 m/s, o GPSRRCRV apresentou um desempenho 4% inferior ao máximo para este vídeo. Por outro
lado, ele apresentou um desempenho de SSIM inferior a 7% para 36,44 e 56 VANTs a 4
m/s. Logo, o GPSR-RCRV garante uma melhor integridade do vídeo transmitido, sendo
importante 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 voo
devido às influências do vento. Assim, o vídeo U AV2 possui uma maior região de movimentação causada pelo movimento dos VANTs. Em [Aguiar et al. 2012], argumenta-se
que 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ídeo
U AV2 . 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 mais
robustas à mobilidade. Entretanto, para 44 VANTs, o GPSR-RCRV teve uma taxa de
PDR 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 de
PDR e E2E foram em torno de 80% e 0.14s. Isto porque o GPSR-RCRV não usa o modo
de recuperação presente no GPSR. Portanto, o GPSR-RCRV proporciona uma entrega de
pacote 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 de
vista do usuário em comparação ao GPSR. Para 36 e 56 VANTs a 1 m/s, obteve-se um
SSIM em torno de 0.85 e um ganho de até 7%. Para 44 VANTs, obteve-se um SSIM de
0.82 e um ganho de 3%. Por outro lado, para 4 m/s, o GPSR-RCRV proporcionou um
SSIM de pelo menos 0.80 e um ganho de 10% para 44 e 56 VANTs. Para 36 VANTs, este
SSIM foi de 0.85 com um ganho de 13% em relação ao GPSR. Estes resultados devemse a predição de posicionamento, que fornece o monitoramento de possíveis quebras de
conectividade 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 de
vídeo do tipo I e P, onde tais perdas prejudicam a qualidade do vídeo do ponto de vista do
usuário. Logo, o GPSR-RCRV garante um melhor nível de qualidade sobre a perspectiva
do usuário.
6. Conclusão
Este trabalho propôs o mecanismo RCRV para realçar a conectividade do roteamento em
redes VANTs. O RCRV aplica critérios de tempo de expiração do enlace, direção e distância de interceptação num ambiente 3D para indicar os comportamentos de mobilidade
dos VANTs. Através de um índice de conectividade, o RCRV auxilia o protocolo de roteamento 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 de
possí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 taxa
de entrega de pacotes e um menor atraso fim-a-fim para os dois vídeos testados. O RCRV
proporcionou para diversas quantidades de VANTs um PDR acima de 10% e o E2E abaixo
de 70%, e garantiu um SSIM acima de 8%, possibilitando um melhor nível da qualidade
do vídeo entregue. Como trabalhos futuros, pretende-se avaliar a eficiência do RCRV
em relação a um protocolo de roteamento para VANTs. Além disso, pretende-se aplicar
o RCRV em um protocolo de roteamento geográfico baseado em múltiplos fluxos, bem
como aplicá-lo em um protocolo de roteamento oportunístico.
Agradecimento
Este trabalho foi parcialmente financiado com recursos do Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq).
161
Referências
Aguiar, 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 neighbor
wireless link breaks in gpsr protocol and enhancement using mobility prediction model. EURASIP
Journal on Wireless Communications and Networking, 2012(1):1–15.
Alshbatat, A. I. and Dong, L. (2010). Adaptive MAC protocol for UAV communication networks using directional 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. Ad
Hoc Networks, 11(3):1254–1270.
Broyles, D., Jabbar, A., and Sterbenz, J. P. (2010). Design and analysis of a 3–d gauss-markov mobility model 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 of
intelligent & robotic systems, 61(1-4):339–353.
Ehsan, S. and Hamdaoui, B. (2012). A survey on energy-efficient routing techniques with qos assurances
for 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 Hoc
Networks. Next Generation Mobile Networks and Ubiquitous Computing, pages 226–240.
GERCOM (2013). Source Videos Used for Simulations. https://plus.google.com/117765468529449487870/videos. Acessado em 10 de Setembro de 2013.
Karp, B. and Kung, H.-T. (2000). GPSR: Greedy perimeter stateless routing for wireless networks. In
Proceedings 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 flooding
and 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 Ad
Hoc UAV Network. In 3rd International Workshop on Wireless Networking and Control for Unmanned
Autonomous 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). AeroRP
performance in highly-dynamic airborne networks using 3D Gauss-Markov mobility model. In Military
Communications Conference (MILCOM’11), pages 834–841, Baltimore, USA. IEEE.
Sahingoz, O. K. (2013). Mobile networking with uavs: opportunities and challenges. In 2013 International
Conference 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) utilizing
near space high altitude platforms (HAPs). In Proceedings of the 6th International Conference on Recent
Advances 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-B
System for Aeronautical Ad Hoc Networks. In 8th International Conference on Wireless Communications, Networking and Mobile Computing (WiCOM’12), pages 1–4, Shanghai, China. IEEE.
162
Investigação sobre o Uso de VANTs em Redes DTN para
Cenários de Emergência
José Carlos de Albuquerque, Sidney C. de Lucena, Carlos Alberto V. Campos
1
Universidade 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 geographical obstacles, making it not effective. One way to overcome such problems is to
use unmanned aerial vehicles (UAV) as mobile nodes of a delay tolerant network
(DTN), that gives support to communications. This paper evaluates the performance of different DTN routing protocols through simulations based on real
flight traces of an UAV over a scenario of natural disaster. Obtained results allow the verification of proper routing protocols and the cost/benefit relationship
between number of UAVs and performance of the DTN.
Resumo. A comunicação entre equipes de resgate e o centro de comando (CC)
de operações de busca em áreas de catástrofe é frequentemente afetada por
obstáculos geográficos, tornando-a ineficaz. Uma forma de superar tais problemas é utilizando veı́culos aéreos não tripulados (VANTs) como nós móveis
de uma rede tolerante a atrasos e desconexões (DTN), servindo de apoio às
comunicações. Este artigo analisa o desempenho de diferentes protocolos de
roteamento DTN através de simulações baseadas em traços reais de voo de um
VANT sobre um cenário de desastre natural. Os resultados obtidos permitem verificar os protocolos mais adequados e a relação custo/benefı́cio entre o número
de VANTs e o desempenho da DTN.
1. Introdução
No Brasil, de acordo com a base de dados internacional de desastres, encontrada em
[EM-DAT 2012], os desastres mais recorrentes desde 1900 são as inundações, causadas
principalmente por fortes chuvas, e em seguida os deslizamentos de terra, geralmente
decorrentes dessas inundações. Especificamente no Estado do Rio de Janeiro, principalmente no perı́odo compreendido entre os meses de Janeiro e Fevereiro, existem diversas
áreas com nı́veis pluviométricos altos, o que invariavelmente leva a situações de enchente
e alagamento. Estradas interditadas, pontes destruı́das, casas parcial ou integralmente soterradas ou inundadas - esses são alguns dos resultados decorrentes do cenário catastrófico
que se abate sobre essa região nesta época do ano. Em meio a este cenário caótico, existem as equipes de socorro e resgate que precisam estar em constante comunicação com as
bases de comando que coordenam estas operações.
Tradicionalmente, toda a comunicação entre as equipes de resgate e o centro de
comando, assim como entre as equipes em si, ocorre de forma verbal com o auxı́lio de
equipamentos de rádiocomunicação nas faixas de VHF e UHF. Entretanto, na ocorrência
163
de obstáculos geográficos ou por dificuldades na instalação de antenas para a transmissão
do sinal de rádio, nem sempre esta comunicação é eficaz. Nestes cenários, a utilização
de uma rede tolerante a atrasos e desconexões (delay/disruption tolerant network - DTN)
[Warthman 2003, Venkataraman et al. 2009], adaptada para trabalhar com nós móveis,
pode ser uma importante estrutura de apoio às equipes de socorro. Uma DTN é um tipo
de rede sem fio na qual não se exige conectividade fim-a-fim e que são caracterizadas
por atrasos, longos ou variáveis, no encaminhamento das mensagens, ou ainda pela intermitência das conexões. Como a superação de obstáculos geográficos pela via aérea é
claramente uma forma mais rápida de se atingir locais isolados por desastres naturais, os
Veı́culos Aéreos Não-Tripuláveis (VANTs) surgem como uma vantajosa opção para uso
como nós móveis desta DTN.
Os VANTs, como o próprio nome diz, são veı́culos aéreos que podem ser controlados de forma remota, por um operador, ou terem seu percurso pré-programado. Esses
veı́culos podem ser classificados em 5 categorias básicas [Sarris 2001], as quais englobam tanto as aeronaves de asa fixa (aviões e planadores) quanto as de asas rotativas (helicópteros e girocópteros), e as que não se enquadram exatamente em nenhuma dessas
categorias (quadricópteros, foguetes e balões). Equipando-se os VANTs para que estes se
comportem como nós móveis de uma DTN, conquista-se uma ampla capacidade de mobilidade que propicia o estabelecimento de uma comunicação de dados entre os VANTs
e entre estes e os nós terrestres, como as equipes de busca e/ou resgate e o centro de comando. Além disso, este tipo de comunicação potencializa a troca de informações entre
equipes e centro de comando, uma vez que permite o envio de imagens e outros tipos de
dados.
Devido às caracterı́sticas de intermitência nas conexões entre os nós de uma DTN,
juntamente com a posssı́vel mobilidade dos mesmos, foram propostos diversos protocolos de roteamento que contemplam as necessidades genéricas de uma DTN. Estes protocolos são baseados no envio, armazenamento e repasse de mensagens, com diferentes
estratégias para cada etapa. Estas estratégias almejam melhorar diferentes aspectos relacionados ao desempenho e à eficiência na entrega de mensagens, sendo que estes fatores
podem variar bastante de acordo com o cenário de uso e a rede em si.
Assim sendo, o objetivo deste artigo é investigar o desempenho dos principais
protocolos de roteamento DTN quando aplicados a uma rede formada por VANTs e nós
terrestres, com finalidade de apoiar as operações de socorro em cenários de desastres naturais. Para tal, foram coletados dados reais de voos realizados com um VANT do tipo asa
voadora numa trajetória pré-programada para cobrir quatro zonas de interesse e o local
do centro de comando das operações de socorro relativas a uma enchente em Janeiro de
2013 no distrito de Xerém, municı́pio de Duque de Caxias (RJ). A partir destes dados,
foram realizadas simulações variando o número de equipes nas zonas de interesse e o
número de VANTs. Os protocolos utilizados nas análises foram o Epidemic, o Prophet,
o Spray and Wait e o Maxprop, por serem os mais popularmente adotados em trabalhos
ligados a DTN. O desempenho dos mesmos foi analisado com base na fração de mensagens entregues, latência e overhead na entrega de mensagens. Pelos resultados obtidos,
é possı́vel verificar os protocolos mais adequados para este tipo de cenário e a relação
custo/benefı́cio entre número de VANTs e a melhora no desempenho da DTN.
O restante do texto está organizado da seguinte forma: a Seção 2 apresenta os
164
trabalhos relacionados; a Seção 3 descreve brevemente os protocolos de roteamento DTN
a serem analisados; a Seção 4 descreve o protótipo e o cenário utilizado para a coleta de
dados; a Seção 5 detalha as simulações realizadas; a Seção 6 apresenta os resultados; for
fim, a Seção 7 traz a conclusão e trabalhos futuros.
2. Trabalhos relacionados
Historicamente a comunicação entre as equipes de socorro e destas com o centro de
controle se dá pela utilização de rádios na faixa de VHF/UHF, que operam no sistema
half-duplex, ou seja, apenas um fala de cada vez enquanto o(s) outro(s) escuta(m). No
entanto, novas tecnologias de comunicação para auxiliar nesses cenários vêm sendo propostas, como em [Dilmaghani and Rao 2008], onde uma infraestrutura de comunicação
baseada em redes mesh é proposta para ser implementada nesse tipo de cenário. Em
[Braunstein et al. 2006] é proposta uma nova arquitetura de rede sem fio hı́brida e distribuı́da para auxiliar as equipes de emergência de forma escalável. Baseia-se em uma
estrutura do tipo mesh para prover conectividade entre os nós e dos nós para o mundo
(Internet). Um dos problemas dessas soluções é a necessidade de instalação de pontos
infraestruturados, o que nem sempre é possı́vel em virtude das limitações da área do desastre.
Uma solução interessante apresentada em [Dilmaghani and Rao 2008] é a
utilização de tiers, ou nı́veis, para separar os diversos tipos de conexões entre dispositivos. Em um nı́vel temos clientes utilizando PDAs, notebooks e iTAGs (por exemplo,
etiquetas RFID). Em outro nı́vel temos nós mesh e um terceiro nı́vel links provê conexão
à Internet. Embora essa solução também precise de nós infraestruturados no segundo
nı́vel, uma vez que a solução é separada em nı́veis existe a possibilidade de substituir
a tecnologia utilizada neste nı́vel por uma solução mais adequada para um ambiente de
desastre. O trabalho em [Yarali et al. 2009] também propõe redes mesh como solução
de conectividade em cenários de emergência. No entanto, se os roteadores e gateways
não puderem contar com fontes de energia capazes de alimentá-los por longos perı́odos,
eventualmente alguns desses equipamentos poderão ficar inoperantes, comprometendo a
conectividade.
Um algoritmo hierárquico para DTN é proposto em [Mota et al. 2009] com o intuito de suprir eventuais carências de infraestrutura numa rede de comunicação. Esse
algoritmo objetiva aumentar a taxa de entrega de dados em redes intermitentes sem afetar
o overhead de comunicação da rede. Em [Jiang et al. 2011] é proposta uma forma de utilizar DTNs para auxiliar vı́timas numa situação de emergência. A proposta é a de que os
celulares das vı́timas sejam utilizados como nós em uma rede oportunı́stica que se vale de
um protocolo Epidemic modificado para este fim. Neste contexto, um cenário hipotético
de incêndio em um prédio de três andares é explorado em [Gelenbe and Gorbil 2012],
onde é verificada a resiliência em caso de falhas de alguns dos nós móveis.
Durante um desastre, a percepção da situação ou o entendimento da gravidade e
extensão da situação de emergência é um fator critico para minimizar o número de feridos,
mortos e danos a propriedades. Em [Fall et al. 2010] é proposta uma arquitetura tolerante
a desconexões na qual as pessoas comuns, envolvidas diretamente com a situação de
desastre ou não, possam fornecer informações como texto, imagens etc às equipes de
apoio e resgate. Para isso, basta que essas pessoas estejam próximas de um outro nó da
165
rede capaz de encaminhar as mensagens, o que nem sempre é viável.
Em [Sivakumar and Tan 2010] é proposto um mecanismo de controle para permitir o voo em formação de vários VANTs, com o objetivo de utilizar esses VANTs como
backbone para conectar eventuais nós móveis em terra ao redor de uma área especı́fica
onde haja equipes de resgate ou sobreviventes. Entretanto, neste trabalho não é investigado 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 cenários
de emergência. O estudo considera que os nós estarão se deslocando da área do incidente
para a área onde será feita a triagem das vı́timas, trocando mensagens entre si nessas
regiões e no caminho de uma região para outra. Entretanto, não é considerado o uso de
VANTs.
3. Protocolos de Roteamento DTN
A DTN é um tipo de rede que funciona diferentemente das redes ad hoc, pois não necessita que exista um caminho ou rota fim-a-fim para a entrega de mensagens. Essas redes
aproveitam-se de contatos oportunı́sticos para tentar prover conectividade, mesmo que
com atrasos ou interrupções, a outros nós que, de outra forma, estariam completamente
desconectados do restante da rede. Para isso elas utilizam-se de uma técnica denominada
armazena-transporta-encaminha (store-carry-forward), onde os nós da rede podem armazenar a mensagem e a transportar até que esta possa ser entregue ao seu destinatário ou
encaminhada para outro nó com o mesmo objetivo. Os protocolos convencionais de redes
ad hoc, focados em situações onde os nós agem como roteadores, falham ao estabelecer
rotas em DTNs. Portanto, as redes DTN precisam de protocolos especı́ficos para o seu
modo de funcionamento. Dentre os mais conhecidos, estão o Epidemic, o Maxprop, o
Spray and Wait e o Prophet. Estes são os protocolos usados nas simulações realizadas no
contexto deste trabalho.
O protocolo Epidemic[Vahdat and Becker 2000] tenta disseminar cópias das mensagens por toda a rede, ou seja, todos os nós podem estar transportando a mensagem e
cada nó, ao encontrar com o outro nó da rede, apenas troca as mensagens que eles não têm
em seus buffers de memória. Essa técnica de disseminação garante uma alta tolerância
a falhas de nós na rede, garantindo um número suficiente de trocas de mensagens entre
todos os nós da rede e, eventualmente, recebendo as mensagens em um curto perı́odo de
tempo. Esta abordagem não requer informações sobre topologia da rede, entretanto os
recursos da rede podem ser consumidos de forma bastante voraz.
O Protocolo Maxprop[Burgess et al. 2006] foi desenvolvido na universidade de
Massachusetts e define uma ordem de prioridade na fila dos pacotes. Os pacotes que
precisam ser descartados e aqueles que precisam ser transmitidos são então classificados
de acordo com essa prioridade. A prioridade dos pacotes é baseada na probabilidade de
entrega ao nó de destino de acordo com dados históricos e outros mecanismos auxiliares,
tais como uma lista de nós intermediários, notificações de recebimento e novos pacotes,
que são priorizados em detrimento de pacotes mais antigos. Diversos métodos podem
ser utilizados para definir essa prioridade, incluindo a taxa de sucesso na definição de um
determinado caminho para um determinado nó ou a quantidade de tentativas bem sucedidas de entrega de mensagem de um determinado nó para outro. Essa técnica melhora, de
maneira geral, a taxa de entrega de mensagens.
166
O protocolo Spray and Wait[Spyropoulos et al. 2005] combina a rapidez do roteamento Epidemic com a simplicidade da entrega direta. De forma a utilizar eficientemente
os recursos da rede, este protocolo define um limite N, dado pelo parâmetro L de ajuste do
protocolo, para o número de cópias de mensagens sendo replicadas na rede. O protocolo
opera em duas fases distintas: a fase disseminar (spray) e a fase de espera (wait). Junto
com cada mensagem é enviado um indicador do número máximo de cópias desta mensagem. Durante a fase disseminar, N cópias são disseminadas na rede de forma epidêmica
e, quando um número suficiente de cópias foi disseminado para garantir que pelo menos
um deles irá chegar ao destino, de forma rápida esta fase é encerrada. Os nós que tenham
recebido uma cópia da mensagem a mantêm armazenada e passam para a fase de espera,
na qual cada nó carregando uma cópia da mensagem irá tentar entregar a mensagem de
forma direta.
O protocolo Prophet[Lindgren et al. 2003] parte da premissa de que o encontro
dos nós de uma rede raramente ocorre de forma totalmente aleatória. Operando de forma
probabilı́stica, este protocolo estima uma métrica chamada previsão de entrega. Essa
métrica indica a probabilidade de sucesso em entregar uma mensagem a um determinado
nó de destino a partir de um outro nó de origem. O protocolo Prophet trabalha de forma
que, quando dois nós se encontram, eles trocam um vetor de informação contendo uma
previsão probabilı́stica de entrega. Teoricamente, se dois nós se encontram frequentemente eles têm alta probabilidade de entrega entre eles, entretanto, se um determinado
par de nós não se encontram por um longo tempo, eles não são bons para encaminhar
mensagem entre eles, ou seja, a probabilidade de entrega entre eles tende a ser menor. Ao
apresentar um comportamento probabilı́stico de encontros entre nós encaminhando mensagens somente para os nós que têm mais probabilidade de encontrar com o nó de destino,
este protocolo consegue diminuir a inundação de pacotes de mensagens na rede e, consequentemente, diminuir o consumo de recursos, como buffer de mensagens e banda.
4. Cenário Investigado e Obtenção de Dados Reais
Em Janeiro de 2013, uma sobrecarga de chuvas causou enchentes e deslizamentos na
região do distrito de Xerém, em Duque de Caxias (RJ). Após a relativa normalização do
acesso a esta região, o local foi visitado com a finalidade de se obter dados realı́sticos
para apoiar o estudo sobre o uso de VANTs numa DTN de apoio às atividades de busca e
resgate realizadas neste cenário.
A coleta de dados se deu a partir do sobrevoo de um VANT sobre um circuito
definido com base nas áreas 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 zonas
de interesse e o local do centro de comando, enquanto a linha tracejada indica a região
limı́trofe usada na definição da trajetória do VANT. O traçado de voo envolve um cirtuito
onde o VANT sai do centro de comando (CC), atinge os pontos de interesse na sequência
A, B, C e D, e retorna diretamente para o CC, quando então o ciclo é reiniciado. A partir
deste voo, foram obtidas as informações utilizadas na simulação.
A peculiaridade deste cenário é que os pontos de interesse encontram-se distribuı́dos de forma tal que um VANT tem contato com cada ponto apenas uma vez durante o percurso do circuito. Devido a isto, equipes localizadas nestes pontos tendem a
apresentar um tempo maior de desconexão com os VANTs, o que influencia diretamente
167
Figura 1. Cenário de Xerém.
na conectividade e no desempenho da DTN a ser simulada.
Durante o perı́odo do desastre, os pontos de interesse apresentaram acesso muito
restrito, pois se tratavam de áreas que ficaram inundadas e sob forte correnteza. Assim
sendo, as equipes e as vitimas encontraram-se ilhadas nestes pontos, necessitando do
auxilio de botes para se locomoverem entre regiões. O acesso ao centro de comando
também ficou difı́cil a partir destes pontos. As equipes de resgate que estiveram atendendo
vitimas em cada um dos pontos de interesse tiveram sua mobilidade restrita a poucas ruas
dentro dessas respectivas áreas. Os VANTs, portanto, teriam sido os únicos nós que
conseguiriam atingir todos os pontos de interesse e o centro de comando, mesmo após a
estiagem das chuvas fortes.
Sobre cada ponto de interesse apontados no mapa, e também sobre o CC, o VANT
usado para coleta de dados realizou três voltas de cerca de 50 metros de raio, dando assim
tempo para que mensagens pudessem ser enviadas ou recebidas do VANT.
4.1. Protótipo de VANT utilizado
Os VANTs do tipo asa voadora, ou Zagi, e os planadores, pelas suas caracterı́sticas de
grande autonomia, facilidade de manuseio e velocidade de voo, dentre outras, são os
mais indicados para uso em cenários de desastre. Em especial, as asas voadoras, por
não necessitarem de pista para sua decolagem e aterrissagem, tornam-se extremamente
versáteis e práticas para serem utilizadas nestes ambientes. Por este motivo, fez-se uso
deste tipo de VANT para a obtenção dos dados a serem inseridos no simulador.
Foi montado um protótipo composto por uma asa Zagi contendo bússola digital,
acelerômetros, controle de altitude, GPS e sistema de piloto automático. A Figura 2 mostra o protótipo desenvolvido. A asa foi idealizada tomando como referência o manual
de construção de asas voadoras[Nogueira 2008] e utilizou um perfil MH5, com comprimento total de 1,60 metros e chapas de madeira balsa, que é um tipo de madeira
bastante resistente e extremamente leve. As superfı́cies de comando da asa têm sua
atuação efetivada por dois servo-comandos, um em cada lado da asa, da marca Towerpro. Como propulsão foi utilizado um motor elétrico sem escovas da marca Turnigy
de 750 KV. O revestimento foi realizado com fita de empacotamento comum nas cores
preto, amarelo e branco. Este tipo de construção torna o VANT extremamente estável
em voo, facilmente controlável e bastante resistente a impactos. Como sistema de pi-
168
loto automático, para permitir voos programados, foi utilizado o sistema de código aberto
Ardupilot [Sivakumar and Tan 2010] em sua configuração básica, sem alterações em seu
firmware. A energia necessária para o funcionamento de todo esse equipamento é fornecida por uma bateria de Lithium-Polı́mero de 2200 mAh, que permite uma autonomia
de voo de cerca de 30 minutos. Baterias de maior capacidade podem ser utilizadas para
autonomias maiores, podendo ser conseguido tempos de voo de 2 horas ou mais.
Este protótipo VANT foi concebido para suportar ventos fortes em regiões litorâneas e, impermeabilizando as partes eletrônicas, pode ser usado com chuvas. VANTs
de asa rotativa são úteis p/restrição de mobilidade, mas os de asa fixa têm mais robustez
e autonomia, e estabilizadores de imagem melhoram a qualidade do que é filmado. Este
VANT pode atingir 1000 metros de altura, mas acima de 500 metros há perigo para a
aviação civil. Vale notar que consideramos usar o VANT após estiagem ou redução da
chuva, momento no qual se costumam iniciar as buscas.
Figura 2. O Protótipo de VANT desenvolvido.
As rotas de voo a serem realizadas pelo VANT são programadas através do aplicativo desenvolvido pela equipe de desenvolvimento do Ardupilot, rodando em um notebook convencional. A conexão entre o notebook e o sistema de piloto automático é
realizada através de um link de telemetria composto de rádios Xbee, operando na faixa
de 900MHz, e antenas omnidirecionais de 3 dbi o que, segundo o fabricante, garantem
um alcance em campo aberto de cerca de 1,6 km. Esta distância é para leitura de telemetria e reprogramação em tempo real, porém o VANT realizará o percurso programado
independente de alcance.
5. Etapa de Simulação
Para simular o cenário pretendido, foi utilizado o simulador THE ONE [Keranen 2008].
Os mapas da região estudada foram importados para o simulador no formato WKT. Para
cada elemento da simulação, ou seja, nós terrestres e nós VANT, foi necessária a criação
de um mapa especı́fico uma vez que cada um possui suas próprias caracteristicas de mobilidade. Os nós terrestres ficam agrupados em torno dos pontos de interesse, onde cada
ponto de interesse apresenta limites de mobilidade correspondentes às estradas da região
que estavam desobstruı́das. Portanto, para cada ponto de interesse foi criado um mapa
composto apenas por estas ruas e estradas. Os mapas criados para os VANTs definem
o trajeto percorrido por eles, porém cada VANT tem sua própria posição inicial de voo.
Para a geração desses mapas foi utilizado o sofware Openjump, que permite a importação
169
de mapas reais como camada de fundo, o que facilita a criação de mapas de mobilidade
na ferramenta.
Observou-se durante os testes de campo que a velocidade do VANT variou de 34 a
38 km/h. Nas simulações, os VANTs voam a uma velocidade constante de 36 km/h, que é
a velocidade média mı́nima na qual um VANT real, do tipo que foi construı́do, consegue
manter-se em voo constante sem que haja perda de altitude ou tempos de parada. O
número de VANTs variou de zero, para que tivéssemos um controle de como a rede se
comporta sem o auxı́lio dos nós móveis, até o valor de seis VANTs. A partir do momento
que temos dois VANTs no cenário, estes partem de posições iniciais distintas, de maneira
que um VANT esteja metade do percurso à frente do outro. Com três VANTs, o mesmo
procedimento é adotado, porém dividindo-se o percurso total em três partes. Com quatro,
cinco e seis VANTs a mesma lógica é estabelecida, porém estes novos VANTs realizarão
o percurso no sentido inverso, o que propiciará conexões entre VANTs durante o voo.
O deslocamento das equipes ocorre de forma aleatória ao longo das estradas e
ruas, porém restrito aos caminhos possı́veis dentro do ponto de interesse a que estão confinados. A velocidade média vai de 0,5 a 1,5 m/s, para simular as dificuldades encontradas
no deslocamento das equipes. Foram incorporados também momentos aleatórios de parada com tempo variando de 30 a 360 segundos, simulando buscas mais minuciosas em
determinado momento ou o efetivo resgate de algum sobrevivente. O número de nós representando as equipes ou pessoas nas zonas de interesse foi variado em 12, 20 e 32 nós,
sendo que cada ponto de interesse possui um mesmo número de nós. O CC foi mantido
numa mesma posição fixa em todas as rodadas de simulação realizadas.
Com relação ao ambiente de rede sem fio, para todos os nós foram utilizados
enlaces de rádio WiFi configurados para um alcance de 100 metros e capacidade de transmissão de 5 Mbps.
As mensagens que circulam na rede foram geradas a intervalos de 30 segundos
com tamanho fixo de 200 KB, o que pode representar uma troca de mensagens contendo
arquivos de texto ou imagens. As mensagens podem ser geradas em qualquer nó com destino para qualquer outro nó, exceto os VANTs, os quais não geram nem recebem mensagens, apenas as encaminham. As mensagens geradas foram agrupadas da seguinte forma:
(i) mensagens geradas de um nó qualquer com destino a outro nó qualquer, incluindo
o centro de comando; (ii) mensagens geradas de um nó qualquer com destino a outro
nó qualquer, exceto o centro de comando; e (iii) mensagens geradas de um nó qualquer
exclusivamente com destino ao centro de comando.
Como citado antes, os protocolos de roteamento DTN escolhidos para análise
foram o Epidemic, o Prophet, o Spray and Wait e o Maxprop. No caso do Spray and
Wait, o número de cópias usado foi 6, que é um valor padrão. Estes protocolos foram
escolhidos por serem os mais populares dentre aqueles que priorizam rapidez na entrega
de mensagens. Foram efetuadas 10 rodadas de simulação para cada protocolo em cada
cenário de simulação, com tempo simulado de 7200 segundos para cada rodada, o que
representa a autonomia de voo do VANT. Para cada caso, foram coletadas as seguintes
medidas: atraso médio para entrega das mensagens, fração de mensagens entregues e
overhead do número de mensagens. O intervalo de confiança adotado foi de 95%, obtido
a partir da tabela de referência t-student, considerando 10 rodadas.
170
O atraso médio para entrega corresponde à média dos tempos de entrega de todas
as mensagens que tenham chegado a seu destino. A fração de mensagens entregues corresponde à razão entre o total de mensagens entregues e o total de mensagens geradas.
Já o overhead do número de mensagens corresponde ao número adicional de mensagens
geradas por mensagem entregue. Seja T M T o total de mensagens transmitidas e T M E
−T M E
o total de mensagens entregues, o overhead é calculado por T MTTM
.
E
É interessante notar que, em um cenário de emergência, o overhead de mensagens,
ou seja, a quantidade de cópias de mensagens geradas numa DTN, pode ser considerada
uma métrica de menor importância uma vez que é mais urgente que as mensagens sejam
entregues em seus destinos no menor tempo possı́vel. Entretanto, para entender o desempenho geral dos protocolos nos cenários simulados, o overhead foi também analisado.
Os buffers dos nós foram superdimensionados de forma a evitar a perda de mensagens, pois entende-se que isto seria inadequado num cenário de emergência.
6. Resultados Obtidos
Figura 3. Fração de mensagens entregues.
(a)
(b)
(c)
A Figura 3 apresenta a fração de mensagens entregues no cenário com 20 nós
terrestres para cada agrupamento de mensagens: (a) mensagens entre todos os nós, inclusive CC; (b) mensagens entre todos os nós, menos CC; e (c) mensagens entre os nós e o
CC. Como podemos observar, a fração de mensagens entregues na rede, para a maioria
dos protocolos, tende a 100% desde que haja pelo menos um VANT circulando. Esse
resultado pode ser explicado pela forma cı́clica com que os VANTs percorrem a região e
pelo tamanho do buffer utilizado nos nós, tendendo a infinito. Os resultados referentes a
cada protocolo apresentam muito pouca ou nenhuma variação entre si, independente do
número de nós, excetuando o caso do protocolo spray and wait. Para este protocolo, a
fração de entrega tende a um valor mais baixo, em torno de 95%. Este comportamento
pode ser explicado pela forma com que o protocolo trabalha. Com o objetivo de diminuir o overhead na rede, o Spray and Wait limita o número máximo de cópias de uma
mesma mensagem na rede. Uma vez que a escolha dos nós que receberão essas cópias
não considera a existência de VANTs, é possı́vel que algumas mensagens não consigam
ser entregues a um VANT.
No caso de quando as mensagens são geradas tendo o CC exclusivamente como
origem ou destino, verifica-se que a fração de pacotes entregues é zero quando não há
VANTs circulando, uma vez que somente os VANTs conseguem alcançar o CC (Figura
3).
171
Os resultados para a fração de mensagens entregues nos cenários com 12 e 32
foram muito similares ao do cenário com 20 nós e tiveram seus gráficos omitidos para
poupar espaço.
Figura 4. Atraso médio para entrega de mensagens entre todos os nós.
(a)
(b)
(c)
Figura 5. Atraso médio para entrega de mensagens entre todos os nós, exceto CC.
(a)
(b)
(c)
Figura 6. Atraso médio para entrega de mensagens entre CC e qualquer outro nó.
(a)
(b)
(c)
As Figuras 4, 5 e 6 apresentam o atraso médio na entrega de mensagens respectivamente para os casos de mensagens entre todos os nós, mensagens entre todos os nós
exceto o CC, e mensagens entre o CC e demais nós. Para cada caso, são mostrados os
cenários com 12, 20 e 32 nós terrestres. De uma forma geral, é possı́vel verificar uma
redução do atraso a medida que aumenta o número de VANTs, sendo que esta redução
fica percentualmente menor quanto maior o número de VANTs, sugerindo que ela tenderá
a um valor limite. No caso de zero VANTs, este valor destoa da tendência encontrada no
restante da curva, sendo valores menores quanto maior o número de nós terrestres. Isto se
explica pelo fato da medida considerar apenas as mensagens entregues, incluindo aquelas
172
entregues entre os nós terrestres em um mesmo ponto de interesse, caso onde o atraso se
torna bem pequeno. Quanto o maior o número de nós terrestres, maior a quantidade de
mensagens entregues nestes pontos de interesse. No caso da Figura 6, com zero VANTs
não há mensagem entregue, portanto não há valor associado a este número.
Com relação ao comportamento por protocolo, o atraso médio do Prophet e do
Spray and Wait são os maiores, com resultado pior no caso do Spray and Wait devido
aos mesmos motivos anteriormente expostos, ou seja, uma vez que existem menos nós
capazes de realizar a entrega de determinada mensagem, um tempo maior na entrega é
esperado. Mesmo no caso da Figura 6, que considera apenas mensagens entre o CC e
demais nós, o Spray and Wait teve um atraso médio um pouco maior, enquanto que todos
os demais tiveram resultados muito próximos, inclusive o Prophet. No caso do Prophet,
este protocolo possui uma métrica que calcula a probabilidade do encontro entre dois
nós e, como os VANTs são os únicos que se encontram constantemente com o centro de
comando, esses passam a ser os nós preferidos para encaminhar mensagens ao CC.
Tanto o protocolo Maxprop quanto o Epidemic apresentaram os menores atrasos
médios em todos os casos. Uma vez que esses protocolos trabalham disseminando mensagens para quantos nós forem possiveis, essa baixa latência é esperada.
Figura 7. Overhead de mensagens entre todos os nós.
(a)
(b)
(c)
Figura 8. Overhead de mensagens entre todos os nós, exceto CC.
(a)
(b)
(c)
As Figuras 7, 9 e 8 apresentam o overhead médio de mensagens respectivamente
para os casos de mensagens entre todos os nós, mensagens entre todos os nós exceto o CC,
e mensagens entre o CC e demais nós. Assim como antes, para cada caso, são mostrados
os cenários com 12, 20 e 32 nós terrestres. É possı́vel verificar que o Spray and Wait
teve 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 nós.
(a)
(b)
(c)
controle de mensagens na rede. Entretanto, deve-se recordar que a fração de mensagens
entregues e o atraso médio ficam comprometidos por conta deste mecanismo.
Em situação oposta, o protocolo Maxprop apresentou os maiores valores de
overhead, crescendo substancialmente com o aumento do número de nós terrestres. Isto
ocorre porque este protocolo gera uma certa quantidade de mensagens de controle juntamente com a mensagem que está tentando entregar, o que torna seu overhead maior que
o do próprio Epidemic. Os protocolos Epidemic e Prophet têm 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 conforme aumenta o número de VANTs, se comparado com o Epidemic.
Tabela 1. Tabela comparativa de resultado dos protocolos.
1: Pior caso, 2: Intermediário, 3: Melhor caso
Epidemic
Maxprop
Prophet
Spray and Wait
Fração de mensagens entregues
3
3
3
1
Overhead
Atraso
médio
Total
2
1
2
3
3
3
1
1
8
7
6
5
A Tabela 1 apresenta um sumário dos resultados de cada métrica para cada protocolo. De maneira a auxiliar na comparação, foi atribuı́da uma pontuação de 1, 2 e 3 para
os casos onde a métrica associada a determinado protocolo apresenta o pior desempenho,
um desempenho intermediário ou o melhor desempenho, respectivamente. Somando-se
todos os pontos, espera-se visualizar qual protocolo apresentou o melhor desempenho
no aspecto geral. Podemos observar que o protocolo Epidemic apresentou os melhores
resultados para o cenário aqui analisado, seguido de perto pelo protocolo Maxprop que
recebeu uma pontuação pior devido ao seu overhead. Desconsiderando-se esta métrica,
que pode ter pouca relevância no contexto de cenários de emergência, ambos têm desempenho equivalente.
Outra observação relevante é quanto ao número de VANTs e sua relação com a
melhora do desempenho na entrega de mensagens para o cenário estudado. Pelos resultados apresentados, fica claro que a métrica mais determinante para esta análise é o atraso
médio, já que a fração 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 variou pouco com o aumento do número 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 redução
do atraso passa a ser muito pequena, o que também é verificado nos demais protocolos.
Conclui-se portanto que, para o cenário estudado, bastam dois VANTs para se obter um
desempenho relativamente próximo do ótimo na entrega de mensagens pela DTN.
7. Conclusão
Os cenários de desastre podem apresentar caracterı́sticas que dificultam o uso de tecnologias tradicionais de comunicação pelas equipes de resgate. Além disso, dependendo do
cenário, a mobilidade das equipes também pode ficar comprometida, a ponto de não ser
possı́vel a locomoção dessas equipes até o centro de comando. Neste contexto, o uso de
VANTS se apresenta como uma opção vantajosa para cenários de emergência, podendo
servir como nós móveis na composição de uma DTN para apoio na comunicação com as
equipes de resgate.
Este trabalho analisou o desempenho de uma rede DTN formada por nós móveis,
dentre os quais VANTs, para uso em cenários de emergência. As simulações realizadas se
basearam em dados realistas coletados a partir de um protótipo de VANT que sobrevoou as
áreas crı́ticas que foram afetadas por uma enchente ocorrida em Janeiro de 2013 no distrito
de Xerém, em Duque de Caxias (RJ). Foram comparados quatro conhecidos protocolos de
roteamento DTN segundo as métricas de fração de entrega de mensagens, atraso médio da
entrega e overhead de mensagens. Constatou-se que o protocolo Epidemic se apresentou
como melhor opção e que bastam dois VANTs circulando para se obter um desempenho
próximo do ótimo no cenário estudado.
Como trabalho futuro, pretende-se utilizar os conhecimentos adquiridos no desenvolvimento de um protocolo de roteamento DTN usando nós móveis que seja otimizado
para cenários de emergência, privilegiando os VANTs como nós de encaminhamento de
mensagens. Além disso, outros tipos de VANTs deverão ser experimentados de forma
conjunta, como por exemplo, balões.
Referências
Braunstein, B., Trimble, T., Mishra, R., Manoj, B., Lenert, L., and Rao, R. (2006). Challenges in using distributed wireless mesh networks in emergency response. In Proceedings of the 3rd International ISCRAM Conference, pages 30–38.
Burgess, J., Gallagher, B., Jensen, D., and Levine, B. N. (2006). Maxprop: Routing for
vehicle-based disruption-tolerant networks. In Proc. ieee infocom, volume 6, pages
1–11. Barcelona, Spain.
Dilmaghani, R. B. and Rao, R. R. (2008). A wireless mesh infrastructure deployment
with application for emergency scenarios. In 5th International ISCRAM Conference.
EM-DAT (2012). International disaster database. http://www.emdat.be/database/. Acessado em: 14 dez. 2013.
Fall, K., Iannaccone, G., Kannan, J., Silveira, F., and Taft, N. (2010). A disruption-tolerant
architecture for secure and efficient disaster response communications. Proceedings of
ISCRAM.
175
Gelenbe, E. and Gorbil, G. (2012). Wireless networks in emergency management. In Proceedings of the first ACM international workshop on Practical issues and applications
in next generation wireless networks, pages 1–6. ACM.
Jiang, P., Bigham, J., and Bodanese, E. (2011). Adaptive service provisioning for emergency communications with dtn. In Wireless Communications and Networking Conference (WCNC), 2011 IEEE, pages 2125–2130. IEEE.
Keranen, A. (2008). Opportunistic network environment simulator. Special Assignment report, Helsinki University of Technology, Department of Communications and
Networking.
Lindgren, A., Doria, A., and Schelen, O. (2003). Probabilistic routing in intermittently connected networks. ACM SIGMOBILE Mobile Computing and Communications
Review, 7(3):19–20.
Martin Campillo, A., Crowcroft, J., Yoneki, E., and Marti, R. (2012). Evaluating opportunistic networks in disaster scenarios. Journal of Network and Computer Applications.
Mota, V. F., Silva, T. H., and Nogueira, J. M. S. (2009). Introduzindo tolerância a
interrupção em redes ad hoc móveis para cenários de emergência. Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuidos (SBRC), Recife, PE, Brasil.
Nogueira, R. (2008). Manual básico para construção 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 9
th IEEE Mediterranean Conference on Control and Automation (MED’01).
Sivakumar, A. and Tan, C. K.-Y. (2010). Uav swarm coordination using cooperative
control for establishing a wireless communications backbone. In Proceedings of the
9th International Conference on Autonomous Agents and Multiagent Systems: volume
3-Volume 3, pages 1157–1164. International Foundation for Autonomous Agents and
Multiagent Systems.
Spyropoulos, T., Psounis, K., and Raghavendra, C. S. (2005). Spray and wait: an efficient routing scheme for intermittently connected mobile networks. In Proceedings of
the 2005 ACM SIGCOMM workshop on Delay-tolerant networking, pages 252–259.
ACM.
Vahdat, A. and Becker, D. (2000). Epidemic routing for partially-connected ad hoc
networks. Technical Report CS-2000-06, Duke University.
Venkataraman, V., Acharya, H. B., Shah, H., and Lam, S. (2009). Delay tolerant
networking-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 solution
for emergency and rural applications. In Advances in Mesh Networks, 2009. MESH
2009. 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 RBGP é 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
Adaptabilidade
Retransmissor
Nagaraj (2011)
Não Utiliza
Não
Sim
Direção
Não
Ros (2009)
Periódicos
Sim
Sim
Não
Kamoltham (2011)
Periódicos
Não
Sim
Chuan (2012)
Periódicos
Não
Sim
Protocolo Proposto
Aperiódicos
Não
Sim
Prioridade
Densidade
Local
Distância e
Densidade
Densidade
Local e
Distância
Não
Não
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 Drj 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 ri 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, tik e Dsk. na qual Emi é a sequência de bits que representa o endereço MAC da máquina
que criou o alerta; tik é 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]
183
(4)
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).
100,0%
100,0%
98,0%
95,0%
100,0%
99,0%
97,8%
100,0%
99,0%
94,5%
93,0%
100,0%
99,5%
100,0%
99,6%
99,3%
100,0% 100,0%
99,5%
99,0% 99,0%
98,8%
92,5%
92,3%
92,0%
95,0%
Total de nós atendidos
90,0%
91,2%
89,7%
91,6%
86,6%
85,0%
83,0%
82,0%
80,0%
80,0%
78,0%
75,0%
500
600
800
1000
2000
3000
4000
5000
Densidade (Veículos/Hora)
Broadcast Puro
AFR
APR
DECA
Protocolo Proposto
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
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 vehicletovehicle communications”, In: The Fourth International Workshop on Vehicle-toVehicle 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 de
Congestionamento de Veículos em VANET
Mariana Ramos de Brito1 , Anna Izabel J. Tostes1 , Fátima de L.P. Duarte-Figueiredo1 ,
Antonio A. F. Loureiro2
1
Pontifícia Universidade Católica de Minas Gerais - Belo Horizonte, MG – Brasil
2
Universidade 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. Vehicular
network management allows through communication between vehicles and infrastructure the congestion detection and the information dissemination to help
drivers changing their route to a less congested one. This paper proposes a congestion detection method and compares it with one from the literature. Simulations with real traffic data from Belo Horizonte were performed. The results show
that the method proposed in this paper presents reductions of up to 17% on the
mean time for the vehicles to detect congestion, despite sending approximately
5% 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 entre
veículos e de veículos com a infraestrutura, a detecção de congestionamento e
a disseminação dessa informação para ajudar os motoristas a trocarem seu caminho para uma rota mais livre de trânsito. Este trabalho propõe um método de
detecção de congestionamento e compara com um método da literatura. Simulações com dados reais do trânsito de Belo Horizonte foram realizadas. Os resultados demonstram que o método proposto neste trabalho apresenta reduções
de 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 afeta
seu desempenho.
1. Introdução
O interesse na área de redes veiculares vem aumentando com o passar do tempo. Redes
veiculares são formadas por veículos e equipamentos físicos, geralmente localizados às
margens das vias de trânsito. Essas redes são caracterizadas por topologias altamente
dinâmicas, enlaces intermitentes, o fato de o movimento dos nós (veículos) ser restringido
pelos limites das vias, entre outras características [Alves et al. 2009]. Estas características
levam a desafios como, por exemplo, a disseminação de dados, o compartilhamento de
dados 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ção
de congestionamentos.
O congestionamento de veículos é um grande problema dos centros urbanos hoje
em dia. As pessoas perdem muito tempo presas em congestionamentos, uma grande
quantidade de combustível é gasta e a poluição ambiental sofre um aumento por causa
dos agentes poluentes liberados pelos veículos [Bauza et al. 2010]. Descobrir um congestionamento e disseminar essa informação pode ajudar os motoristas a se decidirem
por rotas mais vazias, reduzindo congestionamentos existentes.
Neste trabalho, uma rede simulada que segue dados reais do trânsito de Belo Horizonte foi implementada e um novo método de detecção de congestionamento através
da rede veicular foi proposto e comparado com um método da literatura, no qual ele foi
baseado. 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 troca
mensagens (beacons) com todos os vizinhos para descobrir se está ou não em congestionamento. Entretanto, esse método apresenta algumas desvantagens, sendo elas: precisar
da confirmação de todos os vizinhos na área para que um novo veículo passe a indicar congestionamento; continuar executando o algoritmo para descoberta do congestionamento
quando os veículos já sabem que se encontram em um; e não levar em consideração se um
veículo indica congestionamento antes de inseri-lo na árvore. O método proposto neste
artigo utiliza apenas a maioria dos veículos para detectar o congestionamento, o algoritmo
para descoberta do congestionamento só é executado enquanto o veículo sabe que não se
encontra em um congestionamento e novos veículos só são anexados à árvore se indicam
que estão em um congestionamento.
Os dois métodos foram simulados. Os resultados foram comparados em termos
de quanto tempo o último veículo que chegou à área do congestionamento levou para
começar a indicá-lo; o tempo médio que os veículos, em geral, levaram para detectar o
congestionamento; o tempo que levou para calcular a quantidade de veículos no congestionamento; a quantidade enviada de beacons; e o número de chamadas realizadas ao
algoritmo para detecção do congestionamento. O método proposto se mostrou mais eficiente que o método original. Foram obtidas reduções de 25% no tempo que o último
veículo descobriu o congestionamento; 17% no tempo médio para os veículos em geral
perceberem o congestionamento; 82% no tempo que a raiz da árvore levou para somar o
total de veículos no congestionamento; e até 4% menos chamadas ao algoritmo de verificar a existência de congestionamento foram feitas por cada veículo da rede. O método
proposto neste artigo envia 5% mais pacotes pela rede. Entretanto, como os pacotes são
todos 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 relacionados. A seção 3 descreve o método original, encontrado na literatura e usado como
base para o método proposto, que está descrito na seção 4. A seção 5 traz detalhes das
simulações realizadas, enquanto na seção 6 estão os resultados obtidos e as comparações
realizadas. Na seção 7 estão as conclusões tiradas deste trabalho.
Na estratégia proposta em [Knorr and Schreckenberg 2011], os veículos serão equipados
com 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 comportamento de condução. De acordo com as análises dos autores, mesmo com uma taxa de
apenas 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 recebidas
do 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 Orientada 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. Um
veículo detecta, a partir das informações de densidade do tráfego de determinado local
recebidas, situações de congestionamento, comparando as estimativas de densidade do
tráfego da estrada com os valores de densidade média para esse mesmo trecho da estrada. Os autores mostraram, através de simulação, que os veículos conseguem detectar e
localizar 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 fuzzy
para detectar situações de congestionamento, sendo capaz de informar sua localização, extensão e intensidade. A CoTEC monitora as condições do tráfego como um todo através
das mensagens (beacons) que os nós da rede (veículos) enviam randomicamente uns para
os 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 congestionamento local é detectada, ou seja, algum veículo estima um nível de congestionamento
que ultrapassa um limiar predefinido, a CoTEC utiliza as informações locais coletadas
por cada veículo para caracterizar o congestionamento como um todo. Outro trabalho que
utiliza 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 congestionamentos através da disseminação de informações da estrada. Essas informações são
obtidas de cada veículo, que estima um índice de congestionamento para cada trecho da
estrada por onde ele passa, e compartilhadas com os outros veículos da rede. Um algoritmo de Dijkstra dinâmico é usado para computar rotas menos congestionadas para as
quais desviar os veículos. As simulações dos autores mostraram que a comunicação entre
os veículos pode contribuir bastante para dissipar os congestionamentos nas cidades de
hoje em dia.
O trabalho [Terroso-Saenz et al. 2012] é diferente dos outros. Os autores criaram
uma arquitetura movida por eventos (Event-Driven Architecture - EDA) que funciona
com base no processamento de eventos complexos (Complex Event Processing - CEP). A
EDA fica nos veículos da rede e também em estações centrais e fica analisando a situação
do tráfego. Quando ela encontra grupos de veículos com velocidades baixas, ela infere
se 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 da
tecnologia. Os autores pretendem, futuramente, melhorar o sistema para que ele seja
eficaz mesmo com uma baixa penetração.
193
Usando as características das VANETs, os autores de [Mohandas et al. 2009] propõem uma abordagem inovadora para lidar com o congestionamento. Os autores notaram
uma semelhança entre redes veiculares e redes de comunicação de dados, pois o congestionamento acontece quando a demanda supera a capacidade do caminho, e esse fato
motivou-os a gerenciar o congestionamento de veículos usando um algoritmo de controle
de 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 da
via. Os resultados obtidos pelos autores, através de simulações, mostram que o algoritmo é capaz de lidar com o congestionamento de veículos controlando o tamanho da
fila, quando o congestionamento é causado por tráfego que excede a capacidade da via.
Os autores de [Fahmy and Ranasinghe 2008] propuseram uma alternativa aos sistemas existentes baseados em GPS, já que os mesmos não funcionam em todas as situações. Em vez do GPS, supõe-se que todos os veículos estarão equipados com aparelhos wireless e que cada nó (veículo) da rede tem um número id único. Cada nó envia
mensagens (beacons) em intervalos randômicos e, a partir das mensagens recebidas dos
vizinhos, o nó decide se está congestionado ou não. Assim que um nó decide que está em
um congestionamento, o algoritmo de contagem é executado. Uma árvore onde os nós
sã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ção
da 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 ser
usada em situações reais para descobrir um congestionamento em formação e também
para calcular o número de veículos envolvidos.
Este trabalho é diferente dos citados, pois propõe um método de identificar
um 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 no
mé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 que
monta 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 que
estã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 que
um beacon é recebido, o veículo emissor é inserido nas listas de vizinhos do veículo. Um
contador de congestionamento é acrescido de 1 sempre que, no intervalo de enviar um
beacon, os vizinhos antigos do veículo estão na lista de atuais. Quando esse contador
ultrapassa o limite de 40 intervalos de tempo, ou todos os vizinhos do veículo indicam
congestionamento e o contador ultrapassa 2 intervalos de tempo, o veículo muda seu
estado para congestionamento e o algoritmo de montar a árvore e somar os nós começa a
ser 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 árvore
Fonte: Elaborado pelos autores
Quando o veículo recebe um beacon de um veículo com uma id maior que a dele
para a raiz da árvore, ele muda seu parâmetro do id da raiz(rId) da árvore para o recebido
e 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 de
um filho, ele atualiza seu parâmetro de total, somando o total recebido do filho. Assim vai
até chegar na raiz da árvore, que saberá, então, o total de veículos no congestionamento.
4. Método Proposto: Método da Árvore Melhorado
Algumas alterações no método original foram propostas para tentar melhorar sua eficiência e o resultado dessas alterações resultou no método proposto. A primeira alteração foi
só chamar o algoritmo de descobrir o congestionamento se o veículo não está em um congestionamento. 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 os
veículos se decidam pelo estado de congestionamento mais rapidamente, pois pode ser
que 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 de
tempo antes de aceitarem o congestionamento, pois o veículo que chegou junto ainda não
estaria indicando o congestionamento e, portanto, nem todos os vizinhos concordam, o
que não permite que um veículo indique o congestionamento em apenas 2 intervalos de
tempo. Com a alteração proposta, os dois veículos novos consideram as informações recebidas 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 indicar
o congestionamento em apenas 2 intervalos de tempo.
A última alteração proposta foi só considerar as informações de um beacon recebido quando seu veículo emissor também indica congestionamento. Essa alteração foi
proposta 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 passam
a indicar congestionamento. Entretanto, não há uma preocupação se os veículos que o
veículo atual está anexando à árvore estão realmente no congestionamento, o que leva os
veículos executando o algoritmo de montar a árvore a ficarem enganados com um veículo
de id alto que apenas passa perto da via congestionada. A alteração proposta evita esse
problema, 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 a
raiz da árvore quando os veículos seguem o método proposto.
5. Simulações Realizadas
Para este trabalho foi criada uma rede simulada que segue dados reais do trânsito do
centro de Belo Horizonte. A Figura 2 exibe o mapa usado para criar a rede. Os dados
utilizados 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 rede
Fonte: OpenStreetMap, 2013
Simulação foi a forma escolhida para testar os métodos implementados porque
testes 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 de
mobilidade; o OMNeT++ [OMNeT++ 2012], simulador de rede; e o Veins (Vehicle in
network simulation) [Veins 2012], que é a plataforma de integração entre os dois simuladores.
Como o fluxo de veículos segue dados reais do trânsito, os tempos de simulação
foram variados para obter tamanhos diferentes de rede. Para uma rede com 61 veículos
no total e 54 no congestionamento, o tempo de simulação foi de 10 minutos. A rede de 62
veículos ao todo e 54 no congestionamento também foram 10 minutos de simulação, com
a adição de um veículo especialmente modificado que será explicado. Para 86 veículos ao
todo, 75 no congestionamento, as simulações foram de 15 minutos. Com 20 minutos de
simulaçã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 congestionamento, apenas passa em uma rua lateral a qual ele acontece e se conecta brevemente com
os veículos no congestionamento. Esse veículo foi modificado para ter o maior número id
da rede e foi inserido para testar os efeitos que uma “raiz falsa”, ou seja, um veículo com
id 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 e
10 execuções do método proposto, ambos nas mesmas redes. Todos os resultados seguem
um 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 congestionamento
Fonte: 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 congestionamento e percebê-lo. Pelo gráfico, é possível ver que, dos veículos que chegaram
por último à área congestionada, os que seguiam o método melhorado conseguiram perceber o congestionamento até 25% mais rapidamente que os veículos seguindo o método
original. Isso se deve à alteração de considerar as informações apenas da maioria dos vizinhos, ou seja, os últimos veículos conseguem perceber o congestionamento em apenas
2 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, de
fato, para perceber o congestionamento. Como é possível perceber, o método proposto
foi novamente mais eficiente que o método original, devido à alteração de considerar as
informações apenas da maioria dos vizinhos.
Figura 4. Tempo médio para os veículos indicarem congestionamento
A Figura 5 traz o gráfico com os instantes no tempo que a raiz verdadeira da árvore
somou o total de veículos no congestionamento. Os veículos raiz seguindo o método
proposto conseguem somar o total de veículos mais rapidamente, pois os veículos em
geral descobriram o congestionamento de forma mais rápida e a raiz só pode somar os
nós que indicam congestionamento. No caso da rede especial, a de 62 veículos, o veículo
raiz seguindo o método original demorou consideravelmente mais tempo para somar o
total 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 envia
mais beacons que o original, mas isso se deve ao fato de os veículos seguindo o método
modificado 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 mais
tempo para perceber que era a raiz da árvore e somar os veículos, portanto o algoritmo de
montar a árvore foi mais executado e a quantidade de beacons foi maior, visto que esse
algoritmo 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ículos
Figura 6. Quantidade de beacons enviados
No gráfico da Figura 7 estão as chamadas que foram feitas ao algoritmo de descobrir o congestionamento. Devido à alteração de parar de chamar esse algoritmo quando
o veículo já indica congestionamento, os veículos seguindo o método proposto realizaram muito menos chamadas. Os veículos que seguiam o método original continuaram as
chamadas a esse algoritmo mesmo quando já indicam congestionamento, o que torna seu
processamento maior.
199
Figura 7. Chamadas ao algoritmo de descobrir congestionamento
7. Conclusões
Neste trabalho foi apresentado um novo método de detecção de congestionamento
atravé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 alterações que visavam melhorar sua eficiência. Como foi possível perceber, este objetivo
foi alcançado e o método resultante, o Método da Árvore Melhorado, obteve melhoras
de 25% no tempo que o último veículo descobriu o congestionamento; 17% no tempo
médio para os veículos em geral perceberem o congestionamento; 82% no tempo que a
raiz da árvore levou para somar o total de veículos no congestionamento; e até 4% menos
chamadas ao algoritmo de verificar a existência de congestionamento foram feitas por
veículo.
Com o método proposto, aproximadamente 26% mais pacotes foram enviados
pela rede no pior caso. Entretanto, como isso se deve ao fato de que os veículos seguindo
o método proposto descobrem o congestionamento mais cedo e que todos os pacotes
enviados pelo método são de controle, que não congestionam muito a rede, o desempenho
do Método da Árvore Melhorado não é afetado.
Possíveis trabalhos futuros a este incluem: otimização no envio dos beacons, integração com técnicas de minimização de congestionamentos e avaliação de outros algoritmos.
Referências
Alves, R. S., Campbell, I. V., Couto, R. S., Campista, M. E. M., Moraes, I. M., Rubinstein, M. G., Costa, L. H. M. K., Duarte, O. C. M. B., and Abdalla, M. (2009). Redes
veiculares: 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 detection
through 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 and
volume using vanet’s. In ITS Telecommunications, 2008. ITST 2008. 8th International
Conference 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 communications in vanet. In Telecommunications, 2007. ITST ’07. 7th International Conference
on ITS, pages 1 –6.
Knorr, F. and Schreckenberg, M. (2011). Influence of inter-vehicle communication on
peak hour traffic flow. PHYSICA A-STATISTICAL MECHANICS AND ITS APPLICATIONS, 391(6):2225–2231.
Lakas, A. and Cheqfah, M. (2009). Detection and dissipation of road traffic congestion
using vehicular communication. In Microwave Symposium (MMS), 2009 Mediterrannean, pages 1 –6.
Liu, Y., Bi, J., and Yang, J. (2009). Research on Vehicular Ad Hoc Networks. In CCDC
2009: 21ST CHINESE CONTROL AND DECISION CONFERENCE, VOLS 1-6, PROCEEDINGS, pages 4430–4435. NE Univ; IEEE Ind Elect Singapore Chapter; Guilin
Univ Elect Technol; IEEE Control Syst Soc; IEEE Ind Elect Soc. 21st Chinese Control
and Decision Conference, Guilin, PEOPLES R CHINA, JUN 17-19, 2009.
Mohandas, B. K., Liscano, R., and Yang, O. W. W. (2009). Vehicle Traffic Congestion Management in Vehicular ad-hoc networks. In 2009 IEEE 34TH CONFERENCE
ON LOCAL COMPUTER NETWORKS (LCN 2009), Conference on Local Computer
Networks, pages 655–660. BBN Technologies; Stadt Zurich; Kanton Zurich; Commun 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., and
Gomez-Skarmeta, A. F. (2012). A Cooperative Approach to Traffic Congestion Detection With Complex Event Processing and VANET. IEEE TRANSACTIONS ON
INTELLIGENT TRANSPORTATION SYSTEMS, 13(2):914–929.
Veins (2012). Veins - vehicles in network simulation.
//veins.car2x.org>. Acesso em: 08 set. 2012.
201
Disponível em: <http:
Í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
202

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

Transcrição

Documentos relacionados

Circular 28 - Sindicato dos Bancários do Norte

workshop “elabore um traje medieval”

DANILO SIQUEIRA

Jornal da UBQ Nº 61 – Ano 15 – Dezembro 2014/Janeiro de 2015

Habbo e comercio de bens virtuais por criancas

Plano de Negócios e as Novas Fontes de Riqueza na

Descarregar programa completo - Forum of ISCTE

WORKSHOP NOME EM GRAFFITI

Worshop Nacional – Dublin, 23 Abril 2013

Gerência de Recursos Humanos para uma Fábrica de Software de