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

Transcrição

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

2 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 Sociedade Brasileira de Computação (SBC) Laboratório Nacional de Redes de Computadores (LARC)

3 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: Sociedade Brasileira de Computação (SBC) Av. Bento Gonçalves, Setor 4 - Prédio Sala 219 Bairro Agronomia - CEP Porto Alegre- RS Fone: (51) sbc@sbc.org.br 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, c p. WGRS 2014 Realização: Universidade Federal de Santa Catarina ISSN: X 1. Redes de Computadores - Congressos. 2. Sistemas Distribuídos Congressos. I. Cerqueira, Eduardo. II. Sociedade Brasileira de Computação. III. Título. i

4 Promoção Sociedade Brasileira de Computação (SBC) Diretoria Presidente Paulo Roberto Freire Cunha (UFPE) Vice-Presidente Lisandro Zambenedetti Granville (UFRGS) Diretora Administrativa Renata de Matos Galante (UFRGS) Diretor de Finanças Carlos André Guimarães Ferraz (UFPE) 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

5 Promoção Sociedade Brasileira de Computação (SBC) Conselho Mandato 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 Ariadne Carvalho (UNICAMP) Carlos Eduardo Ferreira (IME - USP) Jose Carlos Maldonado (ICMC - USP) Luiz Fernando Gomes Soares (PUC-Rio) Marcelo Walter (UFRGS) Suplentes 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

6 Promoção Laboratório Nacional de Redes de Computadores (LARC) Diretoria 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

7 Realização Comitê de Organização Coordenação Geral Joni da Silva Fraga (UFSC) Frank Augusto Siqueira (UFSC) Coordenação do WGRS Eduardo Cerqueira (UFPA) Coordenação de Workshops Carlos André Guimarães Ferraz (UFPE) v

8 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

9 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

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

11 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) Eduardo Cerqueira (UFPA) 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

12 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) 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) 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 (UFPE), Matheus Santana (UFPE), Djamel Sadok (UFPE) e Stenio Fernandes (UFPE) Proposta de Modificação da VMM-MIB para o Gerenciamento de Roteadores Virtuais Paulo Ferraz (UFRGS), Rafael Esteves (UFRGS), Lisandro Z. Granville (UFRGS) 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) Migração de máquinas virtuais para economia de energia Leonardo Cardoso (UFRJ), Lyno Ferraz (UFRJ) e Otto C. M. B. Duarte (UFRJ) x

13 Sumário 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 T. Macedo (UFPR), Aldri dos Santos (UFPR), André Guedes (UFPR), Michele Nogueira (UFPR) e Yacine Ghamri-Doudane (University of La Rochelle, França) 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) 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) 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 Costa (UFPA), Denis Rosário (UFPA), Eduardo Cerqueira (UFPA) e Aldri dos Santos (UFPR) 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) 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) 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) Índice por Autor xi

14

15 32º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Florianópolis - SC XIX Workshop de Gerência e Operação de Redes e Serviços (WGRS) Sessão Técnica 1 Gerenciamento de redes sem fio, de sensores e Smart Grids

16

17 Evoluindo um Sistema de Monitoramento Passivo Energeticamente Eficiente para Redes de Sensores Sem Fio Fernando P. Garcia 1,2,3, Rossana M. C. Andrade 1,2,b, Carina T. de Oliveira 2, José Neuman de Souza 1,2,a Universidade Federal do Ceará (UFC) 1 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) fernandoparente@ifce.edu.br, rossana@ufc.br, carina@great.ufc.br, neuman@ufc.br Resumo. Um sistema de monitoramento passivo permite depurar e analisar o funcionamento de uma RSSF (Rede de Sensores Sem Fio). Neste caso, uma rede de monitoramento adicional é implantada com o intuito de capturar e analisar os pacotes transmitidos pela rede a ser monitorada (a rede alvo). Quando se deseja monitorar uma RSSF em um ambiente real, é necessário um sistema de monitoramento passivo energeticamente eficiente, pois o tempo de vida da rede de monitoramento é prolongado e, consequentemente, a rede alvo é beneficiada pelo monitoramento por mais tempo. Apenas um trabalho na literatura apresenta este tipo de solução, entretanto, os seus módulos são descritos de forma simplificada, o que dificulta a implementação em ambientes reais. Neste artigo, é proposta uma evolução desta solução, onde todos os módulos são especificados em detalhe e é adicionado um agente SNMP (Simple Network Management Protocol) a fim de integrar o sistema com ferramentas de gerência SNMP, facilitando a administração da rede alvo. Experimentos com sensores reais foram realizados em vários cenários e os resultados comprovam a eficiência energética do sistema proposto, assim como a viabilidade de utilizá-lo para monitorar RSSF em ambientes reais. Abstract. A passive monitoring system enables debugging and analysis of the operation of a WSN (Wireless Sensor Network). In this case, a monitoring network is deployed in order to capture and analyze packets sent by the network to be monitored (target network). An energy-efficient passive monitoring system is necessary when we need to monitor a WSN in a real scenario because the lifetime of the monitoring network is extended and, consequently, the target network is benefited by the monitoring for longer. Only one work in the literature approaches this type of solution, however, the modules are described in a simplified manner what makes it difficult to implement the system in real scenarios. In this paper, we propose an evolution of this solution, in which all modules are specified in details and an SNMP (Simple Network Management Protocol) agent is developed to integrate the system with SNMP management tools and facilitate the administration of the target network. Experiments with real sensors are performed on several scenarios. The results obtained show the energy efficiency of the monitoring system proposed and the viability of using it to monitor WSN in real scenarios. a Bolsista de produtividade D-1 do CNPq b Bolsista de produtividade DT-2 do CNPq 3

18 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

19 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

20 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 S X 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 S X iniciar a captura dos pacotes enviados por A. O sniffer S X 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 S Y 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 S Y esteja recebendo o sinal de A com RSSI maior ou igual do que S X, o monitor local envia uma mensagem para S X informando que ele não deve capturar os pacotes de A. Porém, se S Y estiver recebendo o sinal de A com RSSI menor do que S X, o monitor local envia uma mensagem para S X capturar os pacotes de A e envia uma mensagem para S Y 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 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

21 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 Geração e Análise do Trace Figura 3. Formato do pacote enviado pelos sniffers. 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 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

22 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

23 Tabela 1. Objetos representados nas tabelas nodestable e pathtable. Tabela da MIB Nome do objeto Descrição do objeto nodeid Endereço do nó da rede alvo timeawake Tempo (segundos) em que o nó está ativo lastseq DSN do último pacote enviado pelo nó lasttimestamp Marca de tempo do último pacote enviado pelo nó nodestable sendpacketnode Quantidade de pacotes enviados pelo nó recvpacketnode Quantidade de pacotes recebidos pelo nó senddatapacket Quantidade de pacotes de dados enviados pelo nó recvdatapacket Quantidade de pacotes de dados recebidos pelo nó sendbytesnode Quantidade de bytes enviados pelo nó recvbytesnode Quantidade de bytes recebidos pelo nó pathid Path no formato origem destino srcnode Endereço do nó de origem do path dstnode Endereço do nó de destino do path pathtable sendpacketpath Quantidade de pacotes enviados no path sendbytespath Quantidade de bytes enviados no path timebeginning Marca de tempo do primeiro pacote enviado no path timeending Marca de tempo do último pacote enviado no path As Figuras 5, 6 e 7 exemplificam o funcionamento desta ferramenta de gerência. A Figura 5 mostra a estrutura da MIB do EPMOSt. Ao clicar em nodestable na tela mostrada na Figura 5, o usuário visualiza os nós da rede alvo (Figura 6). Ao clicar sobre um determinado nó na tela mostrada na Figura 6, o usuário visualiza as informações referentes a este nó (Figura 7). Figura 5. Exibição da MIB do EPMOSt. 3. Novos Experimentos Figura 6. Exibição dos nós da rede alvo. Figura 7. Exibição das informações do nó 0. 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

24 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çãoinicial i e contmediçãofinal i 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

25 A quantidade de pacotes distintos do nó i capturados pela rede de monitoramento (Pcapturados i ) é determinada verificando-se quais pacotes do nó i existem no intervalo [contmediçãoinicial i, contmediçãofinal i ]. 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. Conforme explicado na Seção 2.3, a quantidade de pacotes redundantes do nó i (Predundantes i ) é 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. 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. 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 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 (2) (3) (4) (6) (7) (8) 11

26 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

27 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

28 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

29 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/ Universal) sob o número de protocolo / 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

30 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 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 Crossbow (2013) MPR-MIB Users Manual - Crossbow Technology, _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 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 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 Khan. M. M. H., Luo, L., Huang, C. and Abdelzaher, T. (2007) SNTS: sensor network troubleshooting suite In: 3rd IEEE International Conference on Distributed Computing in Sensor Systems, Springer, Berlin. Manage Engine (2013) "SNMP MIB Browser Android Tool", Novembro. McCloghrie, K., Rose, M. (1991) Management Information Base for Network Management of TCP/IP-based internets: MIB-II. RFC 1213, pp MySQL (2013) MySQL, Novembro. Nagios (2013) "Nagios", Novembro. Ringwald, M. and Romer, K. (2007) Deployment of sensor networks: problems and passive Inspection In: Proceedings of the 5 th Workshop on Intelligent Solutions in Embedded Systems, IEEE, New York. WebNMS (2013) WebNMS SNMP Agent Toolkit Java Edition, Outubro. Xu, X., Wan, J., Zhang, W., Tong, C. and Wu C. (2011) PMSW: a passive monitoring system in wireless sensor networks In: International Journal of Network Management, vol. 21, pp 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 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

31 ACRoMa - An Architecture of Cooperative Routing Management in Wireless Mesh Networks Vinicius C. M. Borges 1, Marilia Curado 2, Edmundo Monteiro 2 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, 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, AC- RoMa improves the traffic performance in the presence of challenging traffic patterns, such as triple play services. Resumo. Redes em Malha Sem Fio (RMSF) fornecem um backbone sem fio para acesso ubíquo à Internet e estão sendo desafiados a melhorar seu 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 a/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

32 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 Anais do XIX Workshop de Gerência e Operação de Redes e Serviços WGRS 2014 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

33 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

34 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

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

36 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

37 Figure 3. Mesh router migration: Step 1 Figure 4. Mesh router migration: Step 2 Figure 5. Mesh router migration: Step 3 Figure 6. Mesh router migration: Step 4 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

38 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

39 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 AC- RoMa 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] 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 The simulation results are examined in sub-section 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

40 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 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) D for 50 Nodes (High load) A for 100 Nodes (Low load) D for 100 Nodes (High load) 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] 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

41 1200 Network Size 1200 Network Size Average Flow Throughput (Kb/s) VoIP Video FTP Average Flow Throughput (Kb/s) VoIP Video FTP 0 A D A D A D RAILoB-50nn Load Configurations RAILoB-100nn Figure 8. Average Flow Throughput of RAILoB Network Size 0 A D A D A D PLB-50nn Load Configurations PLB-100nn Figure 9. Average Flow Throughput of PLB Network Size 2 2 Average Flow Delay (s) VoIP Video FTP Average Flow Delay (s) VoIP Video FTP 0 A D A D A D RAILoB-50nn Load Configurations RAILoB-100nn Figure 10. Average Flow Delay of RAILoB 0 A D A D A D PLB-50nn Load Configurations PLB-100nn Figure 11. Average Flow Delay 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 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 shows the scenario configuration and traffic model. The simulation results are described in sub-section Simulation Configuration The scenario configuration is very similar to subsection In addition, the traffic model is equivalent to that used in subsection 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

42 1200 Topology 1200 Topology Average Flow Throughput (Kb/s) VoIP Video FTP Average Flow Throughput (Kb/s) VoIP Video FTP 0 A D A D A D RAILoB-Grid Load Configurations RAILoB-Random Figure 12. Average Flow Throughput of RAILoB Topology 0 A D A D A D PLB-Grid Load Configurations PLB-Random Figure 13. Average Flow Throughput of PLB Topology 2 2 Average Flow Delay (s) VoIP Video FTP Average Flow Delay (s) VoIP Video FTP 0 A D A D A D RAILoB-Grid Load Configurations RAILoB-Random Figure 14. Average Flow Delay of RAILoB 0 A D A D A D PLB-Grid Load Configurations PLB-Random Figure 15. Average Flow Delay of PLB 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

43 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-ST24- FEDER ), co-financed by QREN, in the scope of the Mais Centro Program and European Union s FEDER. References Anais do XIX Workshop de Gerência e Operação de Redes e Serviços WGRS 2014 Akyldiz, I. F., Wang, X., and Wang, W. (2005). Computer Networks, 47(4): Wireless mesh networks: a survey. Ashraf, U., Abdellatif, S., and Juanole, G. (2011). Route maintenance in ieee wireless mesh networks. Computer Communications, 34(13): 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): Bejerano, Y., Han, S.-J., and Kumar, A. (2007). Efficient load-balancing routing for wireless mesh networks. Computer Networks, 51(10): 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): 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 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:

44 Dai, H. and Han, R. (2003). A node-centric load balancing algorithm for wireless sensor networks. In Global Telecommunications Conference, GLOBECOM 03. IEEE, volume 1, pages 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): Genetzakis, M. and Siris, V. (2008). A contention-aware routing metric for multi-rate multi-radio mesh networks. In 5th IEEE SECON 08, pages He, B., Sun, D., and Agrawal, D. (2009). Diffusion based distributed internet gateway load balancing in a wireless mesh network. In GLOBECOM IEEE, pages 1 6. Hsiao, P.-H., Hwang, A., Kung, H., and Vlah, D. (2001). Load-balancing routing for wireless access networks. In INFOCOM Twentieth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, volume 2, pages 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): Manikantan Shila, D. and Anjali, T. (2008). Load aware traffic engineering for mesh networks. Comput. Commun., 31(7): Nguyen, L. T., Beuran, R., and Shinoda, Y. (2008). A load-aware routing metric for wireless mesh networks. In Computers and Communications, ISCC IEEE Symposium on, pages Quintero, A., Elalamy, Y., and Pierre, S. (2004). Performance evaluation of a broadband wireless access system subjected to heavy load. Computer Communications, 27(9): 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 , 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): 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): 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):

45 SMARTFlow: Uma Proposta para a Autoconfiguração de Redes de Subestação IEC Baseada em OpenFlow Yona Lopes 1, Natalia Castro Fernandes 2, Carlos Alberto Malcher 1 1 Laboratório GTECCOM, 2 Laboratório MidiaCom Dep. de Telecomunicações - Universidade Federal Fluminense (UFF) Abstract. Smart grids depend on a solid foundation of communications. Although standards like IEC 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 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 sólida de comunicação. Apesar de normas como a IEC apresentarem soluções para alcançar a interoperabilidade, ainda existem problemas em aberto com relação à autoconfiguração e ao controle automatizado da rede de comunicação. Esse trabalho propõe uma solução eficiente de controle e gerenciamento autˆonomo de redes de comunicação para subestações baseadas na norma IEC A solução proposta, chamada de SMARTFlow, é baseada no uso do OpenFlow para obter granularidade e flexibilidade no tratamento dos fluxos de dados. O SMARTFlow, pró-ativamente, calcula as árvores multicast de camada 2 para encaminhamento de mensagens GOOSE e Sampled Values e reconfigura todas as entradas de fluxos em caso de falhas, além de monitorar a rede, definindo sob demanda a configuração de fluxos cliente-servidor. A proposta foi implementada e testada utilizando o emulador Mininet e apresentou uma carga total até 44% menor do que a de switches típicos. A proposta também demostrou vantagens quando comparada com outras soluções de multicast, como o GMRP. 1. Introdução A energia elétrica é essencial para o desenvolvimento da sociedade. A falta de energia, mesmo que por um período curto de tempo, acarreta em prejuízos enormes além de danos causados pela falta de serviços essenciais. Por exemplo, no Brasil, uma auditoria do Tribunal de Contas da União mostrou que os apagões de 2001 e 2002 causaram um prejuízo de R$ 45,2 bilhões para os brasileiros 1. O responsável por prover a qualidade do serviço elétrico oferecido aos consumidores, controlando e direcionando o fluxo de energia e fornecendo energia durante o maior tempo possível aos consumidores finais é o 1 e 31

46 Sistema Elétrico de Potência (SEP), que possui uma infraestrutura complexa para gerar, transmitir e distribuir essa energia. Contudo, o SEP está sujeito a anormalidades e defeitos em sua operação. Para que o impacto das falhas seja reduzido, sistemas de proteção e supervisão são indispensáveis. Apesar da importância do SEP, pouca inovação tem sido feita nos últimos anos, e, consequentemente, os equipamentos utilizados e as tecnologias, algumas vezes, são os mesmos de 40 anos atrás [Gungor et al. 2011]. Da necessidade inevitável de modernização dos sistemas de automação do SEP, surgiram as Smart Grids, tornando imprescindível a implantação de um sistema de comunicação mais inteligente interligando os sistemas de proteção e supervisão e os centros de controle [Lopes et al. 2012]. Uma das principais normas que especificam essa comunicação inteligente é a norma IEC [IEC ]. Apesar da norma IEC apresentar soluções para modelagem da comunicação dentro do SEP e interoperabilidade dos equipamentos, ainda existem problemas em aberto. A comunicação de mensagens prioritárias da norma, Sampled Values(SV) e GOOSE, é feita em camada 2 e com o uso de multicast [IEC ]. Contudo, devido ao comportamento padrão dos switches para multicast de camada 2, essas mensagens são enviadas em broadcast. Esse comportamento traz uma sobrecarga tanto para rede quanto para os dispositivos finais que recebem mensagens mesmo não estando no grupo [Sivanthi and Goerlitz 2013]. Existem protocolos dinâmicos para encaminhamento multicast de camada 2, como o GMRP (GARP Multicast Registration Protocol), padronizado pelo IEEE 802.1D. Porém, essa solução exige que o protocolo seja implementado nos dispositivos finais, o que ainda não ocorre em redes IEC Outra questão importante é relativa aos sistemas de recuperação de falhas para redes de subestação recomendados pela norma. Esses sistemas garantem a entrega do pacote duplicando o tráfego, ou duplicando todos os dispositivos na rede. Com isso, o tráfego na rede aumenta, o que pode sobrecarregar os nós da rede, aumentando inclusive o processamento dos dispositivos finais, que tem baixo poder de processamento, e passam a processar o dobro de pacotes. Além disso, esses sistemas só podem ser usados em topologias específicas e necessitam de implementação nos dispositivos finais [Tan and Luan 2011]. Esse trabalho visa melhorar o desempenho na comunicação dentro de subestações utilizando de forma eficiente os recursos de rede de comunicação, além de autoconfigurar as redes de subestação IEC A proposta, chamada de SisteMa Autoconfigurável para Redes de Telecomunicações IEC com arcabouço OpenFlow (SMARTFlow), utiliza o OpenFlow [McKeown et al. 2008] para fazer um melhor controle dos dados em tráfego dentro de uma subestação. Inicialmente, as entradas de fluxos de alta prioridade definidos na norma IEC são configuradas com base no arquivo de configuração de subestação, definido na norma. Essa configuração é feita pró-ativamente para garantir que não serão inseridos atrasos para as mensagens sensíveis. Para tanto, o SMART- Flow possui um componente que calcula e configura as árvores multicast para encaminhamento das mensagens de camada 2, evitando o uso do broadcast e sem a necessidade de implementação de protocolos nos dispositivos finais. Foi desenvolvido também, um componente para tratamento de falhas, que recalcula as árvores dinamicamente sempre que houver falhas na rede. Além disso, o SMARTFlow define um modelo para aplicaçã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

47 emulador de redes Mininet [Lantz et al. 2010] e se mostrou muito eficiente, atendendo a todos os requisitos das mensagens da norma IEC O sistema proposto reduziu em até 20 vezes o atraso gerado pelas aplicações de controle padrão do POX e apresentou uma carga total até 44% menor do que a de switches típicos. Os testes foram realizados considerando diferentes configurações típicas de subestação, de forma a validar a proposta em termos de atraso e carga de controle. O restante deste artigo está organizado da seguinte forma. A Seção 2 apresenta uma visão geral da norma IEC e da comunicação multicast de camada 2. Os trabalhos relacionados são apresentados na Seção 3. A proposta é apresentada no Capitulo 4 e a Seção 5 apresenta a análise dos resultados experimentais. As conclusões são apresentadas na Seção Redes IEC A norma IEC modela os sistemas e a comunicação da rede para a automação no SEP. Seu principal objetivo é garantir interoperabilidade entre dispositivos eletrônicos inteligentes (Intelligent Electronic Device (IEDs)) de diferentes fabricantes que permitem, dentre outros, a supervisão, o controle e a proteção em tempo real do SEP. O modelo de comunicação da IEC usa três diferentes tipos de mensagem: GOOSE e SV com alta restrição temporal, chegando a 3 ms, e MMS (Manufacturing Message Specification) variando de 100ms até 1000ms [IEC ]. As mensagens são encaminhadas de duas formas, no modelo publicador/assinante com os endereç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 são usadas para serviços críticos na subestação, por esse motivo são mapeadas diretamente na camada 2 a fim de prover um tempo de resposta mais rápido. Com isso, estas mensagens são diretamente encapsuladas em camada Ethernet e transmitidas com um endereço de destino MAC multicast [McGhee and Goraj 2010]. A norma padroniza uma linguagem de descrição, chamada de Linguagem de Configuração de Subestação (Substation Configuration Language - SCL), que norteia a configuração do sistema. Isto significa dizer que são configurados desde os canais de comunicação até a alocação de funções para os sistemas de automação [IEC ]. A SCL é baseada em XML (extensible Markup Language) e seu objetivo principal é padronizar os atributos de configuração, ou seja, criar uma nomenclatura uniformizada, de maneira a permitir configurações de IEDs com maior segurança e confiabilidade. O intuito é manter a interoperabilidade, garantindo a troca de dados entre IEDs independente do fabricante. Dentre os arquivos de configuração que compõe a SCL, este artigo ressalta o SCD, pois é este arquivo que descreve detalhadamente a subestação no que tange à comunicação. O arquivo SCD contém uma seção de configuração de comunicação e uma seção de descrição da subestação. Desta maneira, este arquivo pode conter, por exemplo, aonde está alocado cada nó lógico do sistema, endereços de rede, endereços de grupos multicast, etc Comunicação multicast de camada 2 em redes IEC A norma define o uso de grupos multicast de camada 2 para mensagens GOOSE e SV. Switches, por padrão, quando recebem um pacote endereçado a um destino multicast de 33

48 camada 2, enviam este pacote por todas as portas. É esse método que garante que o pacote vai chegar ao destino qualquer que seja o destinatário 2. Porém, esse mé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 questão, ou seja, à árvore multicast [McGhee and Goraj 2010]. As árvores multicast podem ser configuradas de forma estática ou dinâmica. Na configuração estática, o endereço multicast é 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, não existe uma atualização automática na tabela de encaminhamento. Qualquer configuração ou alteração deve ser feita manualmente, por esse motivo não é muito utilizada. Na configuração dinâmica, o gerenciamento do multicast é feito com o uso de protocolos, que se encarregam do tráfego multicast encaminhando-o para os dispositivos que manifestaram interesse em recebê-lo. A árvore multicast é construída dinamicamente, e, em caso de atualização na rede, o algoritmo deve recalcular 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 é o GMRP. Seu principio básico de funcionamento é 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 informaçã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 necessárias para que a mensagem chegue a todos os membros do grupo [Yong-hui et al. 2011]. 3. Trabalhos Relacionados Existem trabalhos que mostram que o uso de multicast em redes de subestação simplifica o controle do tráfego e diminui os atrasos [Ingram et al. 2011, Sivanthi and Goerlitz 2013, Moore et al. 2010, McGhee and Goraj 2010], alé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 subestação. Os autores exploram as vantagens do GMRP com aplicações em laboratório e aplicações práticas. Nesse mesmo contexto, XiCai et al. apresentam um exemplo do uso do GMRP em subestações Chinesas para reduzir o volume de dados recebidos por dispositivos [XiCai et al. 2011]. Muitas vezes, o GMRP é usado em conjunto com as VLANs (Virtual Local Area Network) para restringir o tráfego [Ingram et al. 2011]. Ingram et al. combinam o uso de VLANs e filtro multicast para separar o tráfego por aplicação e por grupos de interesse, de forma que o tráfego multicast fique restrito a ser distribuído apenas dentro de determinada VLAN [Ingram et al. 2011]. Sivanthi e Goerlitz propõem uma abordagem sistemá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 padrão de swiches. 34

49 grupos multicast têm a mesma árvore, o algoritmo coloca os dois no mesmo grupo multicast [Sivanthi and Goerlitz 2013]. As propostas de uso do GMRP em redes de subestação, demandam que os fabricantes de IEDs implementem o protocolo em seus dispositivos [Yong-hui et al. 2011]. Contudo, os IEDs, até o momento, não possuem a capacidade de implementar o protocolo e enviar mensagens join e leave para a rede. Com isso, parte da configuração tem que ser feita manualmente, na tabela multicast estática dos switches. Assim, a configuração da rede se torna trabalhosa e a maioria dos fabricantes recomenda a utilização de VLANs para limitar os domínios de broadcast [Ingram et al. 2011]. Portanto, o multicast acaba não sendo utilizado na prática, o que reduz o desempenho da rede [McGhee and Goraj 2010]. A proposta deste artigo dinamicamente cria árvores multicast, sem a necessidade de implementação nos IEDs e configura os fluxos unicast e multicast no contexto de sistemas de automação de subestação usando o OpenFlow. O trabalho leva em consideração os requisitos temporais rígidos da norma IEC e a confiabilidade requerida em redes de subestação. Além disso, reconfigura dinamicamente toda a rede em caso de falha ou de mudança na rede. Com relação ao uso de OpenFlow em Smart Grids, Sydney et al. propõem o uso de OpenFlow para prover recursos de MPLS em redes de longa distância [Sydney et al. 2014]. Cahn et al. propõem o SDECN (Software-Defined Energy Communication Network), que usa redes definidas por software (SDN) como solução para as smart grids [Cahn et al. 2013]. Os autores sugerem o uso do openflow em redes de subestação e fazem uma implementação simples com base no controlador Ryu. Poucos detalhes são apresentados sobre algoritmos e lógicas de controle e os cenários de teste sã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], porém fora do contexto de subestações. 4. A proposta SMARTFlow Para aumentar o desempenho das redes de subestação, é proposto o SMARTFlow, que é um sistema autoconfigurável para redes de telecomunicações IEC baseado no arcabouço OpenFlow. Seus objetivos principais são o desenvolvimento de um encaminhamento apropriado de mensagens IEC e o controle eficiente de redes de dados de subestações elétricas. Além disso, com o SMARTFlow, é possível fazer a autoconfiguração dos grupos multicast de forma automática, toda vez que for inserido ou retirado um IED da rede, sem a necessidade de implementação no IED. Como a proposta é facilitar o planejamento e a configuração da rede, é possível configurar automaticamente a rede de telecomunicações com a solução adequada aos requisitos da rede. Dessa forma, os principais módulos do SMARTFlow são: autoconfiguração inicial da rede de telecomunicações com base nos dados obtidos pelos arquivos de configuração da subestação providos pela norma IEC 61850; criação automática de árvores multicast de camada 2 para o envio de mensagens GOOSE e SV; recuperação de falhas através do recálculo e atualização automática das rotas próativamente sempre que um dos enlaces da rede falhar; 35

50 Anais do XIX Workshop de Gerência e Operação de Redes e Serviços WGRS O IEC 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 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 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 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

51 Propõe-se o uso de sete componentes, os quais todos foram desenvolvidos para o SMARTFlow, com exceção do Descoberta de Topologia e do Spanning Tree, que são componentes geralmente encontrados nos controladores OpenFlow: Descoberta de Topologia: Este componente é 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 cabeçalho do pacote para o controlador, já que nã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: Já conhecendo a visão geral da topologia da rede, pelo componente Descoberta de Topologia, pode-se, então, construir a spanning tree. O objetivo do componente Spanning Tree é calcular a árvore de cobertura da rede e, de acordo com os dados obtidos, desativar a primitiva de inundação em alguns enlaces específicos. Isso faz com que topologias que formem ciclos evitem loops infinitos no envio de mensagens broadcast. Tráfego Comum: Este componente encaminha, sob demanda, o tráfego unicast de baixa prioridade das redes baseadas em IEC 61850, como por exemplo, mensagens MMS. O componente Tráfego Comum é uma versã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 cabeçalho do primeiro pacote para o controlador, o qual aciona o módulo Trá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 endereços MAC de todos os IEDS na rede automaticamente, armazenando em um dicionário todos os endereços MAC dos IEDs, a qual portas e switches estão ligados. Esse dicionário é intitulado mac map. Cada vez que um IED é acrescentado ou retirado da rede, esse componente atualiza esse dicionário. Os endereços MAC dos IEDs e servidores, na prática, podem ser obtidos do arquivo SCD da norma IEC Contudo, essa configuração inicial não é suficiente para detectar erros de ligação, ou ainda, mudanças na topologia geradas durante o funcionamento da rede. Assim, optouse pelo uso de uma solução mais genérica. O componente proposto monitora os eventos da rede e mantém atualizado o dicioná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 prioritários entre os enlaces, através do uso de migrações ao vivo. Com isso, sempre que se observa que um enlace está próximo de um certo limiar de uso, alguns fluxos são migrados para outros enlaces menos sobrecarregados. Essa migração é feita criando-se uma nova rota a partir do destino até a origem. A rota original é apagada apenas quando a nova rota já está pronta para uso, garantindo, assim, que não serão perdidos pacotes. Isso ajuda a melhorar o desempenho da rede e a minimizar a latência de resposta, o que é essencial para redes de comunicação que auxiliam mecanismos de proteção do SEP. 37

52 Multicast L2: Este componente implementa o Algoritmo 1 para calcular as árvores de distribuição para os grupos multicast de camada dois, necessá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 aplicações Descoberta de Topologia e Descoberta de Clientes, calcula as árvores multicast para cada grupo na rede IEC da subestação e configura pró-ativamente os respectivos switches. Essa configuração pró-ativa é importante porque os grupos multicast são utilizados por mensagens de alta sensibilidade a atrasos no IEC A configuração pró-ativa impede que a entrega das mensagens seja atrasada pela consulta reativa ao controlador, o que seria o comportamento padrão do OpenFlow. O Algoritmo 1, baseado nos dados do componente Descoberta de Topologia, é capaz de ter uma visão completa da rede, podendo armazenar em uma lista, todos os enlaces e nós da rede. A lista de enlaces (E), a lista de nós (N), a lista de grupos multicast (gruposmulticastgerados) e o dicionário mac map são as entradas desse algoritmo. A saída é o caminho completo da árvore multicast, intitulado caminho completo, que o próprio algoritmo usa para configurar os fluxos em cada switch da rede. A lista de grupos multicast é percorrida para criação e configuração de cada Algoritmo 1: Algoritmo de cálculo de árvores multicast e estabelecimento de rotas Input: E, N, mac map, gruposmulticastgerados Output: caminhos c ompletos 1 forgrupo ingruposmulticastgerados 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 árvore multicast, como mostrado na linha 1. A função descobre end, na linha 2, descobre qual o endereço MAC do grupo multicast. A função descobre raiz, na linha 3, com base no map mac descobre qual o endereço MAC do nó raiz do grupo multicast e em qual switch está conectado. É importante observar que serão considerados como raiz todos os nós que possam emitir mensagens para o grupo multicast. A função descobre dst, na linha 4, retorna uma lista com os switches que estão conectados a pelo menos um dos membros do grupo, com as respectivas portas. Com os nós, os enlaces e a raiz do grupo 38

53 multicast, a função SP F multicast calcula todas as rotas mais curtas da raiz para cada outro nó restante da rede, possíveis nós receptores do grupo. Com isso, é 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 nós receptores do grupo são armazenadas na lista caminhos arvore que, ao final, contém os melhores caminhos do IED publicador até os IEDs receptores do grupo multicast. A lista caminhos arvore é processada para remoção de redundâncias com a função remove redundancias. Essa função gera a lista arvore multicast, contendo o caminho por qual os pacotes deverão passar para alcançar todos os destinos daquele grupo, conforme linha 11. Para que as tabelas dos switches possam ser configuradas, além do caminho é necessário o acréscimo das portas por qual esse caminho está conectado. Essa tarefa é realizada pela função acrescenta portas, que gera como saída a lista intitulada caminhos completos, contendo uma lista para cada switch com o seu número de identificação e as portas por onde os pacotes serão encaminhados, ou seja, a tabela de fluxos que deverá ser configurada. Por fim, o controlador pode configurar as tabelas de fluxos nos switches pertencentes à listacaminhos completos criando assim a árvoremulticast do grupo em questão. Cabe observar que o algoritmo proposto não busca a melhor árvore de cobertura, mas a entrega mais rápida dos pacotes, tendo como métrica o número de saltos. Devido às fortes restrições de atraso das mensagens GOOSE e SV, a proposta prioriza a velocidade da entrega. Detecção de Falhas: Este componente é chamado sempre que ocorre mudanças na topologia da rede. Desta forma, sempre que um enlace cai, o componente Detecção de Falhas chama o componente Multicast L2, o qual recalcula as árvores 3. O componente e seu algoritmo são detalhados no Algoritmo 2. É importante notar que, Algoritmo 2: Algoritmo de detecção de falhas e restauraçã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 afetados,grupos nao afetados = busca grupos(enlaces af etados, caminhos completos, gruposmulticastgerados) 3 novos grupos = multi tree(e,n,mac map,grupos afetados) 4 caminhos completos = novos grupos + grupos nao af etados 5 return caminhos completos se a versão do OpenFlow suportar o Fast Failover, então existem pequenas alterações nos Algoritmos 1 e 2. O Algoritmo 1, após calcular a árvore de distribuição para um par (endereço MAC multicast, raiz), irá aumentar os custos de todos os enlaces utilizados nessa árvore de cobertura e irá buscar uma nova árvore de distribuição na rede. Em seguida, essa nova árvore é adicionada como caminho para casos de falha na tabela de grupo dos switches OpenFlow. É importante observar que o aumento do custo garante que uma segunda árvore será encontrada, mesmo que não existam caminhos totalmente disjuntos. 3 Cabe observar que o comportamento desse componente varia de acordo com a versão do OpenFlow em uso, de acordo com a disponibilidade ou não da tabela de grupo e do mecanismo de fast failover. 39

54 As modificações no Algoritmo 2 ocorrem apenas para apagar a rota original que está com uma falha, de forma que a segunda opção se torne a rota principal. O Algoritmo, naturalmente, já buscará uma terceira opção de árvore de distribuição, para prevenir novas falhas na rede. Ressalta-se que a rede deverá prover mais de um caminho, caso a rede só tenha um caminho possível, esse componente não se aplica. Maiores detalhes sobre os algoritmos podem ser encontrados em [Lopes 2013]. 5. Experimentos com ferramentas de emulação e Análise dos Resultados Os componentes do SMARTFlow foram desenvolvido em Python e implementados no controlador POX na versão do OpenFlow. Os experimentos foram emulados usando o Mininet [Lantz et al. 2010] versão 2. O Mininet é uma plataforma flexível para emulação de redes OpenFlow que provê um ambiente de experimentação bem próximo do real. Foi criado um módulo no Mininet que constrói topologias LAN de subestações, todas distribuindo os IED uniformemente na rede. Este módulo também contém a classe que chama os componentes do SMARTFlow para controlar a rede. Para esses experimentos, focou-se na entrega do tráfego de mensagens GOOSE, que tem grande restrição de atrasos nas redes das subestação. Para tanto, foi desenvolvido um gerador de mensagens GOOSE na ferramenta Scapy para simular o tráfego dos IEDs. A duração dos experimentos foi de 100 segundos para cada rodada, incluindo, neste tempo, a estabilização da rede, a configuração dos fluxos, a troca de mensagens e o tempo da simulação. Foram variados parâ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 virtualização em um notebook com processador Intel Core i5-3210m, e 4GB de memória RAM. Os testes foram realizados com três instâncias de máquinas virtuais simultâneas, cada uma delas com uma CPU virtual, 1024 MB de memória e executando o sistema operacional Ubuntu Todos os resultados apresentam um intervalo de confiança de 95%. Para os experimentos, levou-se em consideração os cenários típicos de subestação descritos na parte 1 da norma IEC [IEC ] onde é descrito o tamanho da subestação e sua importância no sistema. Em todos os casos, a quantidade de IEDs depende muito do projeto e funções que serão utilizadas na subestação. Assumindo uma quantidade de 3 até 12 IEDs podese assumir que os testes englobam, senão todos, a maior parte dos cenários típicos em subestações. Além disso, para todos os experimentos foram testadas topologias em anel e estrela pois são as topologias encontradas em subestação. Os gráficos da Figura 2 apresentam o resultado para topologia em anel, já que esta apresentou uma carga de controle um pouco mais alta do que a topologia em estrela. O cenário é 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 tráfego GOOSE. A ideia consiste em criar cenários que representam desde pequenas até grandes subestações. Na Figura 2(a), nota-se que o atraso na rede controlada pelo SMARTFlow não passou de 1,5 ms. Isso mostra que o SMARTFlow atende bem aos requisitos rígidos de tempo da norma, que determinam atraso máximo de 3 ms para mensagens GOOSE, mesmo em redes de subestação com grande número de switches. Além disso, verifica-se que, na rede controlada pelos componentes reativos do controlador OpenFlow, o atraso é muito superior, chegando a ser até 20 vezes maior que o atraso do SMARTFlow. Esse 40

55 Atraso(ms) Limiar temporal Componente OpenFlow Reativo Componente Smart Flow Carga de Controle (KB/s) Componente OpenFlow Reativo Componente SMARTFlow Quantidade de switches Quantidade de switches (a) Atraso na rede. (b) Carga de controle na rede após estabilização. Figura 2. Comparaçã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 é enviado ao controlador. Quando o controlador identifica que é um pacote multicast, configura uma entrada de fluxo para enviar o pacote para todas as portas de saída, já que o comportamento padrão dos switches é 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 padrão de encaminhamento do controlador OpenFlow não é adequado para o controle de mensangens GOOSE, pois nã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 padrão da subestaçã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 próximos de 0, pois a carga de controle da proposta se concentra, principalmente, na inicialização da rede. Isso é importante, pois a rede não é sobrecarregada durante o seu funcionamento normal, evitando o aumento dos atrasos para mensagens GOOSE e SV. Os valores mais altos do OpenFlow se devem à troca de mensagens entre controlador e switches durante todo o tempo. Por fim, a Figura 3, apresenta os resultados da avaliação da carga total na rede, incluindo a carga de controle no caso dos componentes OpenFlow. Alé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 tráfego multicast como broadcast configurando os fluxos proativamente. Desta forma, simula-se um switch comum, onde os fluxos já se encontram definidos encaminhando o pacote por todas as portas. O cená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 elétrica, em momentos aleatórios, que refletem em um aumento do tráfego GOOSE. Observa-se, na Figura 3, que a carga total de dados no OpenFlow Nativo é um pouco mais alta do 41

56 Carga Total na Rede(KB/s) Switch Típico Componente OpenFlow Reativo Componente SMARTFlow Carga Total na Rede(KB/s) Switch Típico Componente OpenFlow Reativo Componente SMARTFlow Quantidade de IEDs Quantidade de IEDs (a) Topologia em Anel. (b) Topologia em Estrela. Figura 3. Carga total de dados na rede em função do aumento do número de IEDs. que a carga do switch típico. Isso acontece pois, quando o componente reativo do Open- Flow emula switches típicos é acrescida à carga da inundação na rede a carga de controle para setar o fluxo. Ressalta-se que, a carga de controle para este cenário é muito pequena quando comparada a quantidade total de dados na rede e, com isso, o comportamento das duas curvas é muito próximo. Além disso, verifica-se que o SMARTFlow diminui a carga total na rede em até 44% para 12 IEDs na topologia em Anel. Isso acontece, pois o SMARTFlow calcula uma árvore multicast para encaminhar os pacotes evitando a inundação natural de switches típicos. Quando o pacote chega ao switch, ao invés de ser encaminhado por todas as portas, é enviado apenas para a porta relativa a árvore multicast. O tempo para recuperação de falha, mesmo sem a implementação do fast failover ficou em torno de 8ms. Esse experimento e outros resultados como os tempos para configuração da rede, descoberta da rede, etc, são encontrados em [Lopes 2013]. Realizou-se também uma análise qualitativa comparando as características das soluções multicast de camada 2 com as características da solução SMARTFlow. Os resul- Tabela 1. Comparação entre as atuais soluções multicast de camada 2 e a proposta SMARTFlow Características Multicast Multicast GMRP SF 1.0 SF típico Estático Complexidade de configuração Baixa Alta Média Baixa Baixa Dependência de mensagens Join e leave Não Não Sim Não Não Consumo de Banda pelo tráfego de dados Alto Baixo Baixo Baixo Baixo Carga de Controle Baixa Baixa Alta Baixa Baixa Inundação da Rede Sim Não Não Não Não Controle aprimorado do tráfego Não Não Não Sim Sim Simplicidade e Flexibilidade Baixa Baixa Baixa Alta Alta Convergência Rápida Sim Não Não Sim Sim Tempos de atraso na rede Alto Baixo Baixo Baixo Baixo 42

57 tados são mostrados na Tabela 1, onde SF 1.0 refere-se ao SMARTFlow implementado no arcabouço do OpenFlow versão 1.0, SF refere-se a implementação em versões superiores, Multicast Típico refere-se ao comportamento padrão de switches e Multicast Estático a configuração da árvore de forma manual. Uma vantagem do SMARTFlow sobre o GMRP é a ausência de mensagens de controle entre os switches. No GMRP, os switches são responsáveis por encaminhar pacotes e trocar mensagens de controle para montar a árvore multicast. Isto cria uma sobrecarga extra em termos de consumo de banda, pois o controle de mensagens, como join e leave ou atualizações de árvores, são enviadas através dos mesmos enlaces que o tráfego de dados. Além disso, no SMARTFlow, os IEDs são automaticamente incluídos na árvore multicast com base no arquivo SCD, de modo que não é necessário que os IED implementem protocolos multicast cliente ou que mensagens de atualização da árvore sejam enviadas frequentemente. Mudanças na topologia de rede são automaticamente detectadas no SMARTFlow, que desencadeia a reconfiguração das árvores multicast. 6. Conclusões A norma IEC tem ganhado cada vez mais espaço, sendo implantada em novas subestações trazendo inúmeros benefícios como redução de custos e de erros humanos, automação, implementação de novas capacidade, dentre outros. Contudo, mesmo com a inovação, ainda existem problemas a serem resolvidos. Esse trabalho identificou e abordou alguns desses problemas, assim como propôs, desenvolveu e avaliou um serviço de gerenciamento e encaminhamento autoconfigurável para redes IEC baseada em uma té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 até 44% no cenário apresentado. Os testes mostraram, também, que o atraso na rede controlada pelo OpenFlow em sua forma habitual chegou a ser até 20 vezes maior do que a rede controlada pelo SmartFlow, passando de 20ms. Contudo, o atraso na rede controlada pela proposta SMARTFLow não ultrapassou 1,5ms, que é metade do valor mais rígido de tempo estabelecido pela norma (3ms). Com isso, esse trabalho verificou que o SMARTFlow é capaz de cumprir os requisitos impostos pela norma IEC ao usar as aplicações desenvolvidas como uma prova de conceito. Alé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 também reduz o tráfego de controle, o tempo de convergê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 Open- Flow, e em uma rede tradicional para uma análise mais profunda. Uma outra questão é o estudo, desenvolvimento e implementação do SMARTFlow nos IEDs que possuem switches embarcados para a construção de topologias em anel. Portanto, seria necessária a implementação do OpenFlow nesses switches embarcados e a realização de testes de desempenho utilizando o SMARTFlow. Pode-se também investigar, implementar e avaliar a proposta em um contexto entre subestações, podendo inclusive estender a pesquisa para às Smart Grids como um todo. Além disso, pretende-se validar a recuperação de falhas do SMARTFlow implantando também o fast failover. Referê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

58 [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): [IEC ] IEC 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 th Annual Conference on IEEE Industrial Electronics Society, pages [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 Autoconfigurável para Redes de Telecomunicaçőes IEC com arcabouço OpenFlow. Mestrado em Engenharia de Telecomunicaçőes, Universidade Federal Fluminense, UFF. [Lopes et al. 2012] Lopes, Y., Frazã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 Telecomunicações para o Sistema Elétrico. In Minicursos do XXX Simpósio Brasileiro de Telecomunicaçőes, pages (SBrT), Sociedade Brasileira de Telecomunicaçõ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 [McGhee and Goraj 2010] McGhee, J. and Goraj, M. (2010). Smart High Voltage Substation Based on IEC Process Bus and IEEE 1588 Time Synchronization. In Smart Grid Communications (SmartGridComm), 2010 First IEEE International Conference on, pages [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): [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 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), th IEEE International Conference on, pages [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 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 [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 In Advanced Power System Automation and Protection (APAP), 2011 International Conference on, volume 2, pages

59 32º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Florianópolis - SC XIX Workshop de Gerência e Operação de Redes e Serviços (WGRS) Sessão Técnica 2 Virtualização e Redes definidas por software

60

61 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, 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

62 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. 2. Trabalhos Relacionados 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

63 segurança em ambientes de computação em nuvem. Esses trabalhos dão uma visão de como abordar a avaliação da dependabilidade em cenários com virtualização, porém possuem um escopo mais simples quando comparados com um cenário de redes virtualizadas. Em Fernandes et al. (2012) é proposto um método para análise da dependabilidade em ambientes de redes virtualizadas com o uso de diagrama de bloco de confiabilidade (RBD) e Redes de Petri Estocásticas (SPN). Este é o primeiro trabalho a analisar o impacto da dependabilidade em ambientes dinâmicos de virtualização de redes. No entanto, este trabalho utiliza como entrada para análise da dependabilidade o resultado da heurística R-ViNE [Chowdhury et al. (2012)]. É importante destacar que a heurística R-ViNE não leva em consideração dependabilidade para realizar a alocação de requisições virtuais. Sendo assim, a relevância se dá pelo vislumbre de uma primeira avaliação sobre os aspectos de dependabilidade num cenário de redes virtualizadas. O trabalho mais semelhante encontrado na literatura é realizado por Lira et al. (2013). Neste trabalho é apresentada uma heurística baseada no GRASP para alocação de redes virtuais considerando dependabilidade. No entanto, a meta-heurística utilizada não tem como objetivo a maximização da dependabilidade. A dependabilidade apresenta-se apenas como uma restrição informada pelo usuário. Ou seja, o objetivo da alocação é minimizar o custo estabelecido pelos autores que não leva em consideração atributos de dependabilidade na sua função objetivo, não sendo assim justa uma comparação com a heurística proposta. Além disso, o trabalho apresenta resultados preliminares, pois não apresentam dados em relação à carga de recursos físicos utilizados e à taxa de aceitação das requisições. Dessa forma podemos afirmar que os trabalhos embrionários de Fernandes et al (2012) e Lira et al (2013) serviram como motivação para uma análise mais extensa e aprofundada apresentada neste artigo. Com relação às heurísticas de alocação de redes virtuais, focamos - nos próximos parágrafos - em dois trabalhos que foram utilizados para comparação de nossos resultados. Deve-se notar que os trabalhos abaixo não levam em consideração características de falha em suas soluções de mapeamento de redes virtuais. No entanto, esta comparação é importante para mensurar o quanto a dependabilidade varia quando é negligenciada durante o processo de alocação. Zhu e Ammar (2006) propõem um algoritmo ganancioso cujo objetivo é balancear a carga sobre os enlaces e nós físicos. No entanto, sua abordagem não considera aspectos de capacidade, o balanceamento é realizado levando em consideração apenas a quantidade de nós e enlaces virtuais mapeados sobre a rede substrato. A ideia principal da estratégia utilizada é mapear um novo nó virtual em um nó físico considerando a quantidade de nós virtuais nesse nó físico e a carga nos nós e enlaces físicos vizinhos. Em Chowdhury et al. (2012) o problema de alocação de redes virtuais é modelado em função dos custos de receita do servidor com restrições de nós, enlaces e geo-localização. O problema resultante é NP-difícil e, para resolvê-lo, é realizada uma redução para um problema de otimização inteira mista e posteriormente há o relaxamento sobre as restrições, culminando em dois algoritmos de aproximação: D- ViNE e R-ViNE. D-ViNE possui uma abordagem determinística para mapeamento dos nós baseada em uma solução linear relaxada. R-ViNE é similar, mas usa um mapeamento de nós aleatório. Ambos os algoritmos possuem versões em que o enlace 49

64 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

65 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

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

67 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

68 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 tentativas 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 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 6. Metodologia Figura 3 Método alocar_nós 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 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

69 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) MTTR (h) 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 Média da disponibilidade por requisição Taxa de aceitação Utilização dos nós físicos Utilização dos enlaces físicos Descrição Média da disponibilidade de um conjunto de requisições virtuais Quantidade de requisições de redes virtuais aceitas dividida pelo número total de requisições Média da carga de cada nó físico dividida por sua respectiva capacidade Média da carga de cada enlace físico dividida por sua respectiva capacidade 55

70 Tempo de simulação Quantidade de tempo de execução de cada simulação As simulações foram executadas na máquina com as seguintes configurações: CPU Intel(R) Core(TM)2 Duo CPU 2.66GH; Placa de vídeo nvidia GTX 550 TI Memória DDR5 de 2GB; Memória RAM de 2GB DDR2; Disco rígido de 250GB 5400rpm e sistema operacional LinuxMint Release 14 (nadia). 7. Resultados Nos gráficos de resultados vamos nos referir à heurística proposta neste artigo como HRA (Heurística Randômica Adaptativa). Como explicado na seção 6.1, executamos a heurística HRA com e sem restrição de atraso e não obtivemos resultado estatisticamente diferente em nenhuma métrica coletada. Por esse motivo, os gráficos de resultados exibem apenas a abordagem que leva em consideração o atraso por ser mais próxima de um cenário real 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 e 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 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

71 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) Utilização dos Nós Figura 5. Taxa de aceitação 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 Utilização dos Enlaces Figura 6. Utilização dos Nós físicos da rede substrato 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

72 7.5. Tempo de Execução Figura 7. Utilização dos Enlaces da rede substrato 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. 8. Discussão Figura 8. Tempo médio de execução (segundos) 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

73 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), Ebeling, C. E. (1997) An introduction to reliability and maintainability engineering (pp ). 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 ). IEEE. Fischer, A., Botero, J., Beck, M., De Meer, H., & Hesselbach, X. (2013) "Virtual network embedding: A survey", in IEEE Communications Surveys & Tutorials. 59

74 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 ). 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",: acessado em Dezembro de Infuhr, J., Raidl, G.R. (2013) "GRASP and Variable Neighborhood Search for the Virtual Network Mapping Problem.", Hybrid Metaheuristics. Springer Berlin Heidelberg, 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, PRDC'09. 15th IEEE Pacific Rim International Symposium on (pp ). IEEE. Laprie, J. C. (1985). Dependable computing and fault-tolerance. Digest of Papers FTCS-15, 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 ). 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, 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

75 Proposta de Modificação da VMM-MIB para o Gerenciamento de Roteadores Virtuais Paulo R. P. Ferraz S. 1, Rafael P. Esteves 1, Lisandro Z. Granville 1 1 Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Av. Bento Gonç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 VR- MIB, 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 virtualização de redes (NVEs), a infraestrutura física é compartilhada entre diferentes usuários (ou prestadores de serviços), que criam múltiplas redes virtuais. O gerenciamento de NVEs é atualmente deficiente, devido à falta de soluções padrões para substratos heterogêneos. Assim, a escolha mais natural é a utilização do SNMP, o protocolo de gerenciamento de rede de fato. A primeira abordagem para o gerenciamento de VRs, a VR-MIB, não progrediu no caminho da padronização, deixando a área sem solução baseada em SNMP. Recentemente, o IETF propôs a VMM-MIB para gerenciamento de máquina virtual, que pode ser estendida a fim de dar suporte ao gerenciamento de VRs. Neste artigo, propomos extensões para VMM-MIB para permitir o gerenciamento de VRs. Estas extensões permitem a configuração completa de VRs. Alé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 virtualização. Nós avaliamos a interface de gerenciamento proposta em termos do tempo de resposta e do consumo de CPU/memória. 61

76 1. Introdução A virtualização de redes surgiu como alternativa viável para auxiliar no desenvolvimento de novas arquiteturas de rede e para ajudar a superar a ossificação da Internet [Anderson et al. 2005]. Em um ambiente de virtualização de redes (em inglês, Network Virtualization Environment NVE) as infraestruturas físicas, chamadas de substrato, são compartilhadas entre diferentes usuários (ou provedores de serviço) que criam múltiplas redes virtuais, cada uma delas utilizando protocolos, esquemas de endereçamento e políticas independentes. Ao contrário da virtualização de servidores, que normalmente está localizada nos nós de borda de um ambiente de rede, a virtualização de redes ocorre principalmente no núcleo. Dessa forma, roteadores virtuais são criados e hospedados dentro de roteadores físicos, possibilitando que várias redes independentes funcionem simultaneamente, de forma isolada, sobre uma única infraestrutura física [Chowdhury and Boutaba 2009]. Atualmente, NVEs são gerenciados por meio de interfaces de linha de comando não padronizadas (em inglês, Command Line Interface - CLI) ou através de ferramentas de gerenciamento proprietárias. Sendo assim, o gerenciamento de NVEs construídos sobre substratos físicos heterogêneos (i.e., com equipamentos e tecnologias diferentes) fica prejudicado, pois várias ferramentas independentes são necessá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 virtualização com as ferramentas de gerenciamento. Alé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 escalável roteadores físicos que hospedam roteadores virtuais é essencial. Interfaces de gerenciamento apropriadas devem permitir que os provedores de infraestrutura (InPs Infraestructure Providers) e de serviços (SPs Service Providers) possam acessar, operar, manter e administrar os nó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 atualizações, a VR-MIB não se tornou um padrão e está expirada desde No entanto, recentemente, foi proposta uma MIB para o gerenciamento de Máquinas Virtuais (VMs), denominada VMM-MIB, mas sua proposta original não prevê o suporte necessário à configuração de VRs. O objetivo deste artigo é propor um conjunto de extensões à VMM-MIB para que esta possa suportar o gerenciamento pleno de roteadores virtuais. Nossa abordagem é baseada na utilização de roteadores virtuais baseados em software que podem ser emulados em máquinas virtuais. Sendo assim, as extensões propostas consistem de objetos da VR-MIB adaptados para a VMM-MIB que permitem a configuração de VRs. Além disso, definimos um modelo de gerenciamento para NVEs baseado no SNMP e na plataforma de gerenciamento XenServer [XenServer 2013]. 62

77 O restante deste artigo está organizado da seguinte forma. Na Seção 2, são descritas as MIBs VR-MIB e VMM-MIB, seus objetos e suas funcionalidades. Na Seção 3, apresentamos a proposta de modificação da VMM-MIB, mostrando os objetos incluídos e os alterados. Nas Seção 4, é feita a avaliação da principal funcionalidade agregada à VMM-MIB, a criação de VRs. Finalmente, na Seção 5, concluímos o artigo e apresentamos direções para trabalhos futuros. 2. Trabalhos Relacionados 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 VR- MIB foi proposta em 2001, originalmente para a gerência de VPNs (Virtual Privated Networks) de camada 3, mas foi descontinuada em 2006 e não chegou a ser padronizada. A VR-MIB define objetos para armazenar estatísticas e permitir a configuração de alto nível de roteadores virtuais, como criação, remoçã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 configuração de VRs, a coleta de estatísticas de VRs e a associação de interfaces de rede virtuais com as físicas [Daitx et al. 2011]. Na VR-MIB mais atual (L3VPN-VR-MIB versão 4), esses 3 grupos de informações foram definidos, respectivamente, como: vr- Config, vrstat e vrifconfig. O grupo vrconfig, mostrado na Figura 1(a), contém informações sobre indexação, criação e exclusão de VRs. Para ajudar a estação de gerenciamento na atribuição de um novo VR sem conflito, o próximo identificador de VR disponível pode ser recuperado acessando o objeto escalar vrconfignextavailablevrid do dispositivo gerenciado. Cada configuração de roteador virtual é armazenada em uma linha da tabela vrconfigtable, que contém um identificador único (vrid), o nome do VR (vrname) e o status da linha (vrrowstatus), sendo este último usado para criar e excluir os roteadores virtuais. Além disso, essa tabela contém informações sobre configurações internas de cada dispositivo virtual, como o identificador de VPN (vrvpnid), o número má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), contém 2 objetos escalares com informações globais de dispositivos, como o número de VRs configurados em cada nó (vrconfiguredvrs) e o número de VRs ativos na rede (vractivevrs). Além disso, este grupo contém uma tabela chamada vrstattable, que possui os status administrativo e operacional de cada VR. Essa tabela contém diversas estatísticas como: o número atual de entradas de rota (vrstatrouteentries), o número de entradas na FIB (Forwarding Information Base) (vrstatfibentries), o tempo decorrido após o VR entrar em operação (vrstatuptime), o status operacional do VR (vroperstatus), o tipo e o endereço IP de uma das interfaces do VR (vrrouteraddresstype e vrrouteraddress). O grupo vrifconfig, mostrado na Figura 1(c), é composto por uma tabela usada para a configuração de interfaces de VRs (vrifconfigtable). Esta tabela contém todas as associações entre os roteadores virtuais e as interfaces de rede físicas, pois possui 63

78 como índices da vrifconfigentry os identificadores vrid e vrifid. Assim como na vr- ConfigTable, interfaces de roteadores virtuais podem ser criadas, excluídas ou modificadas editando-se a variável vrifconfigrowstatus. Este objeto é usado para acionar as operações de criação e remoção ou para definir o estado de operaçã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 está disponível e, em seguida, verifica se a interface de rede escolhida está disponível. (a) Grupo vrconfig (b) Grupo vrstat (c) Grupo vrifconfig (d) Grupo vrnotificationsprefix Figura 1. Grupos de informações da VR-MIB Além dos três grupos supracitados, o grupo vrnotificationsprefix (Figura 1(d)) permite que o gerente ative ou desative traps manipulando a variável vrtrapenable da tabela vrconfigtable. Esse grupo é formado pelas traps: vrup, vrdown e vrmaxroutesexceeded. A principal desvantagem da VR-MIB é que ela deixou de ser atualizada em 2006, fato que desencoraja sua utilização em projetos atuais. Também não há MIB que substitua suas funcionalidades no que diz respeito à configuração de roteadores virtuais. Sendo assim, a solução mais rápida para este problema é procurar uma MIB atual que possa absorver as funcionalidades da VR-MIB VMM-MIB Em julho de 2012, foi proposta no IETF, como Internet Draft, uma MIB voltada para o gerenciamento de Máquinas Virtuais (VMs Virtual Machines) controladas por um hy- 64

79 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, também conhecido como monitor de máquina virtual, controla várias máquinas virtuais em uma única máquina física, alocando recursos para cada VM usando tecnologias de virtualização. Portanto, este módulo MIB contém informações sobre as máquinas virtuais e seus recursos controlados por um hypervisor, bem como informações de hardware e software do mesmo. O projeto desta MIB foi derivado de módulos MIB específicos de empresas, como Xen e VMWare, e de um módulo MIB que usava a interface de programação libvirt para acessar diferentes hypervisors. No entanto, esta MIB tenta generalizar os objetos gerenciados para suportar outros hypervisors. A VMM-MIB possui informações relativas ao sistema e software de um hypervisor, a lista de máquinas virtuais controladas, e recursos virtuais alocados para máquinas virtuais. Sobre este último, são especificados nessa MIB quatro tipos específicos de recursos virtuais comuns a todos os hypervisors: CPUs (processadores), memó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 é responsável por manter a MIB informada. Figura 2. Alocação de recursos virtuais A VMM-MIB está organizada em um grupo de nove escalares e cinco tabelas. Os escalares organizados sob vmhypervisor (Figura 3) fornecem informações básicas sobre o hypervisor, como a descrição do software (vmhvsofteare), a versão (vmhvversion), o identificador (vmhvobjectid) e o tempo desde que o hypervisor foi reinicializado (vmhvuptime). Os demais objetos escalares são: o vmnumber, que contém o número de VMs no hypervisor; o vmtablelastchange, que é valor do vmhvuptime da última criação ou exclusão de entrada na vmtable; o vmpervmnotificationsenable, que habilita a geração de notificações por VMs; o vmbulknotificationsenable, que é semelhante ao anterior, mas para conjuntos de VMs; e o vmaffectedvms, que contém a lista de VMs que tiveram seu estado alterado. Em relação às tabelas, temos: a vmtable (Figura 4(a)), que lista as VMs que são conhecidas pelo hypervisor; a vmcpuaffinitytable (Figura 4(c)), que fornece a 65

80 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 máquinas virtuais; a vmcputable (Figura 4(c)), que fornece o mapeamento entre CPUs virtuais para máquinas virtuais; e a vmnetworktable (Figura 4(d)), que fornece a lista de interfaces de rede virtuais e seu mapeamento para máquinas virtuais. As tabelas vmtable e vmnetworktable, por serem mais relevantes para este trabalho, serão descritas com mais detalhes. A tabela vmtable, mostrada na Figura 4(a), contém diversas informações sobre as VMs, sendo que as principais para este trabalho são: um identificador único da VM (vmindex), o nome da VM (vmname), o estado administrativo (vmadminstate), o estado operacional da VM (vmoperstate), o número atual, mínimo e máximo de CPUs atribuídas à VM (vmcurcpunumber, vmmincpunumber e vmmaxcpunumber) e o tamanho atual, mínimo e máximo de memória alocada para a VM (vmcurmem, vmmin- Mem e vmmaxmem). O objeto vmadminstate é um parâmetro que define o modelo de estado administrativo da VM e, por isso, tem permissão read-write. Da mesma forma, por serem parâmetros de configuração, também possuem permissão de acesso read-write os objetos supracitados relacionados com CPU e memória. Os demais objetos da tabela têm acesso read-only. A tabela vmnetworktable, mostrada na Figura 4(d), contém informações de interfaces de redes virtuais, como um identificador ú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 endereço físico (MAC Address) (vmnetworkphysaddress). Eventos que causam transições entre os principais estados operacionais geram notificações (traps). A VMM-MIB define dois tipos de notificações: as notificações individuais (per-vm) e as notificações em massa (bulk). As per-vm levam informações mais detalhadas, contudo a escalabilidade pode ser um problema. Já o mecanismo de notificação em massa tem o objetivo de reduzir o número de notificações que são capturadas por um gerente SNMP. As notificações per-vm, definidas pelos objetos listados na Figura 5(a), são geradas se vmpervmnotificationsenable for verdadeiro. De modo análogo, as notificações em massa, definidas pelos objetos da Figura 5(b), são geradas se vmbulknotificationsenabled for verdadeiro. 3. Proposta de modificação da VMM-MIB A idéia da proposta é agregar à VMM-MIB todas as funcionalidades da VR-MIB, sem que a primeira perca suas funcionalidades originais. Inicialmente, percebe-se que os escopos 66

81 (a) Tabela vrtable (b) Tabela vmstoragetable (c) Tabelas vmcputable e vmcpuaffinitytable (d) Tabela vmnetworktable Figura 4. Tabelas da VMM-MIB das MIBs supracitadas são diferentes, pois uma se refere a máquinas virtuais e a outra a roteadores virtuais. Felizmente, roteadores podem ser emulados por softwares, como por exemplo, o Vyatta [Vyatta 2013]. Sendo assim, má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, não há 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 à VMM-MIB duas tabelas para configuração de VMs (ou VRs): a vmconfigtable, que permitirá a criação/remoção de VMs; e a vmnetworkconfigtable, que permitirá a criação/remoção de interfaces de rede virtais e a associação com as físicas (binding). Além disso, três objetos escalares, para fins de controle, são incluídos: vmconfignextavailablevmindex, vmconfiguredvms e vmactivevms, com as mesmas funções dos objetos da VR-MIB vrconfignextavailablevrid, vrconfiguredvrs e vractivevrs, respectivamente. A Figura 6 mostra, em 67

82 (a) Notificações per-vm (b) Notificações em massa Figura 5. Objetos de notificaçã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 contém objetos com as mesmas funcionalidades dos objetos da tabela vrconfigtable da VR-MIB. Além disso, nesta proposta, os objetos da tabela vmtable da VMM-MIB que possuíam permissões read-write são migrados para a vmconfigtable, pois esta tabela deve conter todos os objetos de configuração de uma nova VM. Nesta migração, as permissões de acesso read-write são trocadas para read-create, de forma a permitir a criação de novas entradas na tabela. Para evitar duplicação, os objetos vmindex e vmname são retirados da tabela vmtable, posto que agora eles pertencem à vmconfigtable. A Figura 7 mostra a tabela vmconfigtable proposta e a origem de seus objetos. A tabela vmnetworkconfigtable proposta contém objetos com as mesmas funcionalidades dos objetos da tabela vrifconfigtable da VR-MIB. Só com esses objetos já é possível agregar as funcionalidades de criação e remoção de interfaces de rede virtuais, porém migrando-se os objetos vmnetworkifindex e vmnetworkparent da tabela 68

83 Figura 7. Objetos da tabela vmconfigtable proposta vmnetworktable da VMM-MIB para esta nova tabela, é possível associar a interface virtual à física (binding). Para permitir a criação de entradas na tabela, seus objetos têm permissã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 inclusão das tabelas vmconfigtable e vmnetworkconfigtable na VMM- MIB, já é possível obter as funcionalidades de configuração de alto-nível de roteadores virtuais oferecidas pela VR-MIB, porém, para abranger todas as informações estatísticas de roteadores virtuais, faz-se necessário, ainda, incluir na proposta objetos equivalentes aos da tabela vrstattable da VR-MIB. Sendo assim, a tabela vmtable da nova VMM- MIB deve conter os objetos originais, exceto aqueles migrados para a tabela vmconfigtable, e os novos objetos vmrouteentries, vmfibentries, vmrpstate, vmloopbacladdresstype e vmloopbackaddress, com as mesmas funçõ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 relação às notificações (traps), temos que a VMM-MIB possui uma grande quantidade de objetos referentes aos estados operacionais das VMs. Sendo assim, as notificações vrup e vrdown da VR-MIB já são abrangidas pela VMM-MIB, ainda que de forma mais detalhada. O único objeto de notificação que necessita ser incluído na pro- 69

84 Figura 9. Objetos da tabela vmtable proposta posta é o vmmaxroutesexceeded, equivalente ao vrmaxroutesexceed da VR-MIB, pois trata-se de uma notificação específica de roteadores, onde é informado que o número máximo de rotas foi excedido. Nesta proposta, a tabela vmnetworktable teve dois objetos migrados para a vm- NetworkConfigTable, portanto agora, esta tabela tem apenas os objetos vmnetwork- Model e vmnetworkphysaddress, conforme mostrado na Figura 10. As tabelas vmcputable, vmcpuaffinitytable e vmstoragetable permanecem inalteradas. Figura 10. Objetos da tabela 4. Avaliação Das diversas funcionalidades agregadas à VMM-MIB com as modificações propostas, a criação de VRs é a mais significativa, pois a mesma não é atualmente contemplada pela VMM-MIB original. Sendo assim, esta seção, apresentada a avaliação desta operação em uma interface de gerenciamento baseada no SNMP Interface de Gerenciamento A interface de gerenciamento implementada utiliza a comunicação gerente-agente do SNMPv2, conforme ilustrado na Figura 11. Para a criação de um VR, o gerente SNMP envia uma mensagem set-request (T1) carregando as informações necessárias para o agente criar o VR (i.e., vmrowstate, vmname, vmcontextname, vmtrapenable, vmadminstate). Como reação, o agente emite uma requisiçã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

85 Como a ação do lado do roteador pode durar um tempo indefinido, o set-request é imediatamente respondido com uma mensagem get-response (T3). Quando a operação solicitada termina, uma mensagem de trap é emitida (T5), por um gerador de traps em execuçã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. Descrição do Ambiente Os experimentos foram executados em um computador com processador Intel Core 2 Quad 2,4GHz com 4GB de memória RAM. Este computador foi configurado de modo a emular, para fins de avaliação, um roteador físico. A plataforma de virtualização (hypervisor) utilizada foi o Citrix XenServer 5.6 [XenServer 2013]. O template utilizado na criação de roteadores virtuais foi o Vyatta [Vyatta 2013]. O módulo VMM-MIB proposto, discutido na seção 3, foi compilado, instrumentado e adicionado ao agente disponibilizado no pacote NET-SNMP 5.5 (snmpd) [NET- SNMP 2013]. Operações SNMP são materializadas através de aplicações do pacote NET- SNMP correspondentes as mensagens do protocolo, e.g., snmpset, snmpget e snmpgetbulk. Estas aplicações foram utilizadas para implementar o gerente SNMP. Além disso, a interface de gerenciamento foi avaliada utilizando-se a versão 2 do SNMP que é a versão mais popular do protocolo Resultados O componente em estudo é a interface de gerenciamento descrita na seção 4.1, que tem como principal serviço a criação de VRs. Foram escolhidas duas métricas para a avaliação: tempo de resposta e consumo de recursos pelo agente SNMP (CPU e memória). O tempo de resposta reflete o tempo médio da criação de VRs na solução de gerenciamento proposta. A utilização de CPU e de memória RAM do roteador físico ilustra o impacto das operações de gerenciamento nos recursos do roteador físico. A carga de trabalho consiste na criação de um VR adicional quando um número de VRs previamente criados está ativo (i.e., em operação). O sistema começa sem nenhum VR e a cada nova requisição é criado um novo VR que permanece ativo, até que se atinja o total de 10 VRs ativos. A restrição de 10 VRs ativos se dá pelo fato de que esse foi o limite máximo suportado pela máquina utilizada nos testes. Para esta avaliação foram conduzidos experimentos no ambiente de teste descrito, utilizando a medição como técnica de avaliação. Cada experimento foi repetido 30 ve- 71

86 zes sob as mesmas condições, a fim de se obter as médias populacionais com os seus respectivos intervalos de confiança. Para isto, foi utilizado um nível de confiança de 95%. A Figura 12 ilustra o tempo de resposta (em segundos) na criação de 1 VR quando um número variável de VRs (0 até 10) está ativo XenServer Tempo de resposta [segundos] Número de Roteadores Virtuais ativos Figura 12. Criação de Roteador Virtual É possível observar que, de uma maneira geral, o tempo de resposta cresce quando o número de VRs ativos aumenta. Isso acontece pelo fato de que os VRs ativos compartilham e consomem recursos da máquina física (CPU e memória), que estarão disponíveis em menor quantidade nas próximas requisições, o que influencia no aumento do tempo de resposta na criação de um novo VR. A exceção ocorre para quando 10 VRs estão ativos. O que ocorre aqui é que a máquina física não consegue suportar a carga de 10 VRs ativos simultaneamente (por falta de memória) e o hypervisor suspende alguns VRs arbitrariamente. Em seguida, foi avaliado o consumo de CPU e memória pelo agente SNMP (snmpd). Verificou-se que o tempo de CPU do agente SNMP não apresenta mudanças significativas quando o número de VRs ativos aumenta até 10 VRs, permanecendo na ordem de 40 millissegundos, o que indica que o agente é capaz de armazenar dados de 10 VRs sem prejuízo significativo. A Figura 13 mostra o consumo de memória do agente SNMP na criação de VRs. Os resultados da Figura 13 mostram o percentual de consumo de memória do agente SNMP em relação ao total disponível na máquina física quando um novo VR criado, variando o número de VRs ativos. Novamente, o consumo de memória do agente cresce quando o número de VRs ativo cresce. A primeira razão é que a quantidade de memória disponível na máquina física diminui a cada novo VR criado, e, consequentemente, a relação entre a memória requerida pra processar uma mesma mensagem setrequest em relação ao total disponível também diminui. A segunda razão se deve ao fato de que o agente precisa armazenar uma quantidade de informações cada vez maior a cada novo VR, o que exige mais memória do agente SNMP. 72

87 0.909 XenServer Memória consumida [%] Número de Roteadores Virtuais ativos Figura 13. Consumo de Memória RAM 5. Conclusão Neste trabalho foi apresentada uma proposta de modificação da VMM-MIB para tornar esta MIB funcional para o gerenciamento de roteadores virtuais em ambientes de virtualização de redes (NVEs). A VMM-MIB é uma proposta recente, que vem sido atualizada desde Sendo assim, optou-se por agregar funcionalidades propostas para a VR-MIB à VMM-MIB e, assim, permitir a criaçã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 padrão da VMM-MIB, mas mantendo-se as permissões originais (read-create). Da mesma forma, todos os objetos da tabela vrifconfigtable da VR-MIB foram adicionados à nova tabela vmnetworkconfigtable da VMM-MIB. Além disso, todos os objetos escalares da VR- MIB foram incluídos na nova VMM-MIB, de forma a permitir o controle dessas tabelas da mesma maneira que na VR-MIB. Para não perder as informações estatísticas dos roteadores virtuais criados, também foram incluídos na tabela vmtable da proposta todos os objetos da tabela vrstattable, apesar de alguns deles já existirem na VMM-MIB original. Uma interface de gerenciamento baseada nas extensões propostas para a VMM- MIB foi implementada e avaliada. Os resultados mostram que a memória é o recurso que exerce maior influência sobre o tempo de resposta de uma operação de criação de VRs. Quando o número de VRs aumenta, o agente SNMP consome mais memória, o que impacta no tempo necessário para a criação de novos VR. O consumo de CPU do agente SNMP não se mostrou significativo e não tem grande influência no tempo de resposta. Como trabalhos futuros, pretende-se avaliar outras operações de gerenciamento como recuperação do estado de VRs, remoção e cópia de VRs, além de adaptar a VMM- MIB estendida para outros protocolos de gerenciamento como NETCONF e Web services. Referências Anderson, T., Peterson, L., Shenker, S., and Turner, J. (2005). Overcoming the internet impasse through virtualization. Computer, 38(4):

88 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. Internet draft. Chowdhury, N. M. M. K. and Boutaba, R. (2009). Network virtualization: state of the art and research challenges. Communications Magazine, 47(7): Chowdhury, N. M. M. K. and Boutaba, R. (2010). A survey of network virtualization. Computer Network, 54(5): 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 Esteves, R., Granville, L., and Boutaba, R. (2013). networks. Communications Magazine, IEEE, 51(7). On the management of virtual McCloghrie, K. and Kastenholz, F. (2000). The Interfaces Group MIB. RFC 2863 (Draft Standard). NET-SNMP (2013). Acessado em novembro de Stelzer, E., Hancock, S., Schliesser, B., and Laria, J. (2003). Virtual Router Management Information Base Using SMIv2. Internet draft. Stelzer, E., Hancock, S., Schliesser, B., and Laria, J. (2005). Virtual Router Management Information Base Using SMIv2. Internet draft. Vyatta (2013). Vyatta.org community. Acessado em outubro de XenServer (2013). Open source virtualization. Acessado em outrubro de

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

90 Devido a abordagem centralizada da lógica da rede, utilizada pelo protocolo Open- Flow, 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 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

91 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

92 Tipos Mensagens Descrição Features Enviadas para obter conhecimento sobre as capacidades dos switches Configuration Específicas para parâmetros de configuração dos switches Controlador para o switch Modify-State Gerenciam o estado dos switches, comumente utilizadas para adicionar, remover e modificar fluxos nas tabelas e alterar propriedades de portas Read-State Utilizadas para coletar estatísticas sobre as tabelas, portas, fluxos e filas dos switches Send-Packet Utilizadas pelo controlador para enviar pacotes por uma porta específica Barrier Obtenção de conhecimento se as dependências das mensagens foram alcançadas ou para receber notificações sobre tarefas concluídas Packet-In 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 Assíncrona Flow-Removed Relativas a remoção de regras dos switches Port-Status Obtenção de status das portas dos switches Hello Para início de conexão entre switch e controlador Estabelecimento de conexão entre switch e controlador e podem ser utilizadas Echo Simétrica para obter conhecimento de latência, banda ou conectividade Barrier 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 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

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

94 (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 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 operacional Linux Ubuntu bit com processador Intel R Core TM 2 Duo CPU 3,00GHz x 2 e 2Gb de memória RAM. O ambiente experimental foi emulado no Mininet versão O software Apache versão 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 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

95 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, λ = 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 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

96 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 = SM F + SM V (1) SM F = N switches (H OF + H SR ) (2) SM V = (Body IF S 2) (3) f F s P ath f A sobrecarga de monitoramento SM é dada por uma parte fixa SM F (Equação 2) e uma parte variável SM V (Equação 3). A parte fixa corresponde ao cabeçalho padrão do OpenFlow (H OF ) mais o cabeçalho específico das mensagens Stats Reply (H SR ), 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

97 quantidade de fluxos ativos (conjunto F ) e da quantidade de dispositivos no caminho que esses fluxos percorrem ao longo da rede (conjunto P ath f ). 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 (Body IF S ) para ida e volta. O tamanho de Body IF 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

98 N ( switches (H OF + H P O ) + M Original ) se host desconhecido SF = (H OF + H MS ) + (H OF + H P O + M Original ) se host conhecido s P ath f 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 (H OF + H P O + M Original ) para todas as portas de todos os switches da rede (N switches ) (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 (H OF + H MS ) para cada switch s no caminho do fluxo P ath f e envia apenas uma mensagem Packet-Out (H OF + H P O + M Original ) 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 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 (4) 84

99 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. Taxa de transferência (bits/s) Pkt-in (Experimental) Pkt-in (Analítico) Pkt-out+Mod-St (Experimental) Pkt-out+Mod-St (Analítico) Taxa de transferência (bits/s) Pkt-in (Experimental) Pkt-in (Analítico) Pkt-out+Mod-St (Experimental) Pkt-out+Mod-St (Analítico) Tempo limite de ociosidade da regra (segundos) Tempo limite de ociosidade da regra (segundos) (a) Topologia em estrela (b) Topologia em árvore 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, e 0.33, 0.22 e 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

100 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 Pkt-in (Estrela) Pkt-in (Árvore) Pkt-out+Mod-St (Estrela) Pkt-out+Mod-St (Árvore) Tempo limite de ociosidade das regra (segundos) Figura 3. Taxa de pacotes processados por segundo de mensagens Packet-In, Packet-Out/Modify- State de acordo com o tempo limite de ociosidade das regras para as topologias de estrela e árvore A Figura 4(a) e 4(b) apresentam os resultados para a taxa de transferência de 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 SM F 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. Taxa de transferência (bits/s) Stats-Reply (Experimental) Stats-Reply (Analítico) Taxa de transferência (bits/s) Stats-Reply (Experimental) Stats-Reply (Analítico) Frequência de monitoramento (segundos) Frequência de monitoramento (segundos) (a) Topologia em estrela (b) Topologia em árvore 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

101 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 (Read- State) 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

102 Referências 3GPP2 (2004). CDMA2000 Evaluation Methodology. Disponível em: < Acesso em: Março 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: < Acesso em: Março Cheng, X., Dale, C., e Liu, J. (2007). Understanding the characteristics of internet short video sharing: Youtube as a case study. arxiv preprint arxiv: 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 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): 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 , 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 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): 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 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):

103 Migração de máquinas virtuais para economia de energia Leonardo Pais Cardoso, Lyno Henrique G. Ferraz, Otto Carlos M. B. Duarte 1 Grupo de Teleinformática e Automação Universidade Federal do Rio de Janeiro (UFRJ) Rio de Janeiro RJ Brasil {cardoso, lyno, otto}@gta.ufrj.br Resumo. A computação em nuvem oferece um novo modelo de negócios que provê serviços de infraestrutura flexíveis por demanda. O cliente paga apenas pelo que realmente necessita ou usa recursos de processamento, memória e banda sob demanda, podendo crescer ou retrair sem custos extras. Logo, os provedores de infraestrutura devem prover recursos de forma dinâmica, a custo reduzido e também com baixo consumo de energia elétrica, para diminuir a emissão de carbono e melhorar a sua imagem junto a seus clientes. Este artigo propõe um mecanismo que emprega técnicas de otimização para gerenciar a migração de máquinas virtuais entre máquinas físicas com o objetivo de reduzir os recursos ociosos e também obter menor consumo energético através do desligamento de máquinas físicas. O estado das máquinas e as decisões são baseadas no monitoramento dos perfis de uso de recursos. A heurística implementada procura minimizar o número de máquinas físicas em funcionamento ao realocar máquinas virtuais. Foram realizados experimentos em um protótipo desenvolvido e implantado no Future Internet Testbed with Security (FITS). Os resultados obtidos mostram a eficácia da proposta na redução do consumo energé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

104 1. Introdução A computação em nuvem permite que o provedor de infraestrutura ofereça recursos computacionais como processamento, memória e rede de forma flexível e dinâmica de acordo com a demanda de seus clientes. Além de serem evitados custos operacionais de manutenção, configuração e reparo, o cliente também pode obter os recursos que necessita naquele momento, evitando sobre ou sub valores investidos em infraestrutura. Uma técnica utilizada para isto é a virtualização [Fernandes et al. 2010] que amplia a flexibilidade em alocar recursos ao abstrair o hardware, possibilitando que mais de um usuário compartilhe recursos de uma mesma máquina sem interferir nos processos de outro usuário. Para evitar sobrecarga, é comum distribuir os recursos pelas máquinas físicas interconectadas em rede ou em aglomerados. A migração de máquinas virtuais é uma forma eficaz de redistribuir dinamicamente os recursos pelas máquinas físicas existentes. A migração ao vivo [Clark et al. 2005] permite que as máquinas virtuais continuem em funcionamento durante o processo de migração, garantindo alta disponibilidade do serviço. Alocar recursos computacionais é um importante desafio em computação em nuvem, pois determina se o provedor consegue atender aos Acordos de Nível de Serviço (Service Level Agreements - SLAs) sem comprometer os seus lucros. Uma alocação eficiente de recursos deve atender a todos os clientes com a qualidade de serviço por eles requerida e com o menor uso de recursos físicos para diminuir o número de computadores ativos, reduzindo assim o consumo de energia elétrica. No entanto, as plataformas de virtualização como o Xen [Egi et al. 2008] não possuem nativamente um mecanismo de gerência que possibilite alocar os recursos de forma eficiente. Além disso, alocar diferentes recursos em máquinas que possuem restrições de capacidade é um Problema Generalizado de Atribuição (Generalized Assignment Problem - GAP) e portanto NP- Difícil [Kundakcioglu e Alizamir 2009]. A medida que o número de recursos e máquinas aumenta, o tempo para calcular a solução cresce exponencialmente. Assim, encontrar uma solução exata não é escalável. Este artigo propõe um mecanismo automático de gerência baseado na migração de máquinas virtuais para minimizar o consumo de energia elétrica e reduzir a ociosidade de recursos. A minimização do consumo de energia e da ociosidade é feita com base no monitoramento e análise dos perfis de uso de recursos das máquinas físicas e virtuais. A partir dessa análise é aplicada uma heurística que realoca recursos através da funcionalidade de migração de máquinas virtuais de forma a minimizar o número de máquinas físicas em funcionamento. O algoritmo provê um mapeamento das máquinas virtuais em máquinas físicas que objetiva um número reduzido de máquinas físicas. O mecanismo considera ainda a quantidade de memória a ser transferida pela rede. As máquinas virtuais são então migradas uma a uma para evitar violações dos Acordos de Nível de Serviço que poderiam ser causadas pela sobrecarga no tráfego na rede que as transferências de dados da migração requerem. As máquinas físicas em estado inativo são então desligadas com a finalidade de reduzir os recursos ociosos e o consumo de energia. As máquinas são mantidas desligadas até que a demanda dos clientes seja superior a quantidade de recursos oferecidos e, neste caso, novas máquinas físicas são ativadas para atender a demanda. O mecanismo de gerência foi implementado e testado no FITS. Dois testes foram realizados: Um experimento para comprovar o funcionamento do mecanismo e um estudo 90

105 do algoritmo de otimização. Os resultados mostram que o mecanismo é capaz de encontrar soluções de menor custo, migrar as máquinas para essa solução, desligar máquinas ociosas e ligar máquinas quando a demanda é maior que a oferta. O estudo mostra que o Arrefecimento Simulado é capaz de melhorar a solução de outras heurísticas. O restante deste artigo está organizado da seguinte forma. Na Seção 2 os trabalhos relacionados são descritos e comparados com o mecanismo proposto. A Seção 3 apresenta a solução proposta, descrevendo a coleta de dados, a heurística utilizada e a arquitetura do mecanismo. Os resultados são apresentados na Seção 4. A Seção 5 apresenta a conclusão e direções futuras deste trabalho. 2. Trabalhos Relacionados O desenvolvimento de mecanismos que visem a minimização do consumo de energia é um tema atual e também um desafio tecnológico. Diversos trabalhos abordam a alocação de elementos virtuais sem levar em conta o consumo de energia elétrica. Esta seção se restringe aos trabalhos de alocação de recursos para redução de consumo de energia elétrica. Uma forma de resolução do problema de otimização é 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 é um algoritmo guloso que ordena as máquinas virtuais de forma decrescente de demanda e tenta alocar a máquina virtual na máquina física de menor índice com capacidade disponível. Caso não consiga alocar a quantidade de recursos demandados em nenhuma máquina física ativa, uma nova máquina física é ativada com um índice maior que o da última ativada. A técnica de Arrefecimento Simulado é uma meta-heurística capaz de encontrar uma solução ótima para o problema de alocação através de uma função de aceitação. Essa função permite a aceitação de estados de maior custo, e assim possibilita a exploração de diferentes soluções para fugir de mínimos locais. Wu et al. comparam as heurísticas FFD e Arrefecimento Simulado para a realocação de máquinas virtuais e economia de energia [Wu et al. 2012]. Wu et al. realizam simulações variando o número de máquinas físicas e virtuais bem como a capacidade e o uso de recursos de cada uma delas. A minimização é feita sobre uma função de consumo de energia elétrica dependente de parâmetros como o uso de processamento e memória e do hardware utilizado. Eles concluíram que o uso em conjunto do Arrefecimento Simulado e do FFD encontra soluções que podem economizar mais energia que o uso somente do FFD ou do Arrefecimento Simulado. Porém, os autores focam na proposta e simulação do algoritmo, assim o trabalho carece de um desenvolvimento prático que lide com os problemas relacionados de gerenciamento efetivo de um ambiente virtualizado. Apenas verificou-se a possibilidade de alocar as máquinas virtuais e o tempo que o algoritmo leva para atingir a solução, não considerando o tempo necessário para o sistema convergir após as requisições de migração, o que pode ser crítico em uma aplicação real. Rodriguez et al. implementam uma heurística de branch and cut [Mitchell 2002] baseada em um algoritmo de programação linear 0-1 cujo objetivo é 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 formulações de programação linear 0-1 de forma sequencial. 91

106 A primeira formulação mapeia as redes virtuais no substrato a fim de minimizar o consumo de energia e a largura de banda por requisição da nova rede, a segunda visa encontrar um caminho que minimize o tempo necessá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 diminuição de 30% da largura de banda e um aumento de 10% do consumo quando comparado a minimização apenas do consumo de energia. A proposta de Rodriguez et al. não é orientada a computação em nuvem e considera apenas o problema de chegada de redes virtuais em uma plataforma pluralista para prover infraestrutura de rede. Em um cenário de nuvem não se pode limitar a instanciação de redes, sendo necessário manter a economia de energia dos servidores que entregam recursos sob demanda para as máquinas virtuais. Este artigo, ao contrário dos trabalhos acima relacionados, propõe a solução de um mecanismo de gerência capaz de reduzir o número de máquinas em funcionamento utilizando heurísticas que levam em conta parâmetros que influem substancialmente no tempo de migração. O mecanismo proposto utiliza a técnica de migração ao vivo para reduzir a inatividade das máquinas virtuais enquanto são migradas. Com isto, quando ocorre a migração, apenas a memória da máquina virtual é copiada pela rede. Essa técnica permite que a máquina virtual permaneça em operação durante a migração e entre em estado suspenso por um curto período de tempo. O mecanismo também evita a sobrecarga da rede causada pela migração e a sobrecarga dos recursos de memória e processamento das máquinas físicas. A sobrecarga da rede é tratada através da escolha de soluções que migrem máquinas virtuais com menor quantidade de memória. A sobrecarga de memória e processamento é evitada pela utilização do protocolo Wake on Lan que liga máquinas pela rede. No mecanismo, o Wake on Lan é acionado quando a demanda por recursos é maior que a disponível, ligando uma das máquina físicas ociosas para satisfazer a necessidade dos clientes. Os autores Rodriguez et al. procuram otimizar a instanciação de roteadores virtuais na criação da rede. Em contrapartida, este artigo aborda a migração de máquinas virtuais já instanciadas e em uso por clientes que possuem acordos de nível de serviço pré-definidos com o provedor de infraestrutura. A verificação do comportamento do mecanismo proposto foi realizada no testbed FITS, que provê um ambiente virtualizado em que se pode testar soluções para a Internet do Futuro [Mattos et al. 2012, Moraes et al. 2014]. O FITS é uma rede de testes interuniversitária baseada nas tecnologias Xen e OpenFlow, contando com parceiros no Brasil e na Europa. O FITS adota o paradigma pluralista e permite a execução de sistemas operacionais e aplicações distintas nas redes virtuais. Dessa forma, o FITS provê um ambiente propício a avaliaçã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 implementação desta proposta se serve de módulos desenvolvidos anteriormente no Grupo de Teleinformática e Automação referentes ao VOL- TAIC [Carvalho e Duarte 2012] e ao sistema de gerência AMAS proposto por Bezerra et al. [Bezerra et al. 2014]. O VOLTAIC é um sistema de gerência de recursos para a computação em nuvem que provê qualidade de serviço e evita desperdício de recursos. Bezerra et al. propuseram uma ferramenta de gerência que evita a sobrecarga dos nós físicos e violações de acordo de nível de serviço. Este trabalho, assim como o VOL- TAIC, se baseia na técnica de perfis de uso de recursos das máquinas físicas para analisar 92

107 Figura 1. Arquitetura do FITS destacando a migração de uma máquina virtual. Adaptado de [Figueiredo et al. 2013] [Mattos et al. 2012, Moraes et al. 2014]. as capacidades e, assim como a ferramenta de gerência desenvolvida, redistribui a carga de trabalho através da migração de máquinas virtuais caso um limiar de consumo seja atingido. 3. O Esquema Proposto A proposta deste artigo visa minimizar o consumo de energia elétrica e os recursos ociosos. Fan et al. afirmam que um servidor em modo inativo não consome menos que 50% da energia elé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 máquina física. Assim, a ideia-chave é migrar as máquinas virtuais para um número reduzido de máquinas físicas e desligar as máquinas físicas que não possuem máquinas virtuais ativas. O mecanismo desenvolvido possui quatro módulos principais: o Monitor de Recursos, o Otimizador, o Orquestrador de Migração e o Gerenciador de Energia, que são detalhados na Seção 3.3. Esses módulos geram perfis, calculam um estado que economize energia, migram máquinas virtuais e desligam e ligam as máquinas físicas. A quantidade de memória de cada máquina virtual a ser migrada influencia no tempo de convergência do sistema, porque ao migrar uma máquina virtual é necessário transferir a sua memória pela rede para a máquina física que a hospedará. Para reduzir o tempo de migração, o algoritmo de Arrefecimento Simulado implementado considera, na condição de duas ou mais soluções de mesmo custo em termos de máquinas físicas, escolher a solução que transfere menor quantidade de memória. Logo, sempre que uma solução de mesmo custo que a última armazenada é encontrada, verifica-se quais máquinas virtuais precisam migrar, ou seja, trocaram de posição em relação a disposição inicial, e também se verifica o quanto de memória essas máquinas possuem. Após o cálculo escolhe-se e armazena-se o plano de migração com menor quantidade de memória para que o procedimento de migração provoque a menor sobrecarga possível na rede Formulação para minimização do número de máquinas em funcionamento Para a otimização são definidos os seguintes parâmetros: V - conjunto de máquinas virtuais instanciadas; F - conjunto de máquinas físicas ativas; 93

108 C v, v V - processamento utilizado pela máquina virtual v; C f, f F - processamento utilizado pelo Domínio-0 da máquina física f; T C f, f F - limiar de uso de processamento da máquina física f; M v, v V - memória da máquina virtual v; M f, f F - memória utilizada pelo Domínio-0 da máquina física f; T M f, f F - limiar de uso de memória da máquina física f; N v, v V - consumo de rede da máquina virtual v; N f, f F - rede utilizada pelo Domínio-0 da máquina física f; T N f, f F{ - limiar de uso de rede da máquina física f; 1, se v V está instanciada na máquina física f F X(f, v) = { 0, senão 1, se X(f) = v V X(f, v) 1 0, senão O algoritmo de minimização segue o procedimento de Minimizar sujeito às restrições: X(f) (1) f F f F, ( C v X(f, v)) + C f T C f (R1) v V f F, ( M v X(f, v)) + M f T M f (R2) v V f F, ( N v X(f, v)) + N f T N f (R3) v V v V, X(f, v) = 1 (R4) f F {V, F } Z >0 (R5) A Equação 1 é a função objetivo do problema que nesse artigo é a minimização do número de máquinas físicas em funcionamento X(f), ou seja, o número total de máquinas físicas ativas. As restrições R1, R2 e R3 garantem que o uso de recursos não ultrapasse um limiar. Assim, o uso de recursos para qualquer máquina física f F em funcionamento, é necessariamente menor ou igual ao somatório dos recursos utilizados pelas máquina virtuais v V pertencentes a máquina f, o que é representado por X(f, v), e pelo uso de recursos do Domínio-0 da máquina f. A Equação R4 restringe uma máquina virtual v pertencer a apenas uma máquina física f. Dessa maneira, o somatório das máquinas físicas f as quais possuem a máquina virtual v deve ser igual a 1. Essa restrição impede que uma mesma máquina virtual pertencente ao conjunto de máquinas virtuais instanciadas V seja instanciada em duas máquinas físicas ao mesmo tempo e garante que a máquina virtual v terá uma máquina física f como destino. A restrição R5 limita o conjunto de máquinas virtuais V e o de máquinas físicas F ao domínio dos inteiros maiores que zero. 94

109 3.2. Arrefecimento Simulado A meta-heurística de Arrefecimento Simulado implementada considera um estado que evidencia a distribuição das máquinas virtuais sobre as máquinas físicas. Inicialmente fixa-se uma temperatura inicial, gera-se aleatoriamente um estado inicial e calcula-se o custo associado definido pelo número de máquinas físicas ligadas. Em seguida, gera-se um novo estado a partir de uma perturbação do estado inicial. Essa perturbação consiste em escolher uma das máquinas virtuais e instanciá-la em uma máquina física diferente, aleatoriamente. Caso o novo estado possua um custo menor que o anterior ele é aceito. Do contrário, a aceitação dependerá dos custos do estado anterior e do gerado, e da temperatura. A função de aceitação é expressa por P = exp( j i j i 1 τ i ), (3) τ 0 onde j i e τ i são custo e temperatura na iteração i, respectivamente. A Equação 3 representa a probabilidade de considerar uma solução de maior custo, para isso geralmente compara-se o valor da função com um valor aleatório no intervalo [0, 1]. Se o custo diminui ou se mantém a expressão é sempre igual a 1 e o estado é aceito. Para temperaturas elevadas o valor da função de aceitação tem maior probabilidade de ser maior que o valor aleatório. Dessa forma, o algoritmo tem maior probabilidade de sair de um mínimo local. As soluções aceitas são utilizadas para gerar novos estados. O algoritmo armazena a solução aceita como a solução candidata se o custo diminuir ou o custo se mantiver e a memória das máquinas a migrar diminuir. A escolha da solução de menor memória é feita para evitar sobrecarregar a rede com a transferência das máquinas virtuais. A medida que a temperatura diminui a função de aceitação retorna valores menores e o algoritmo converge para uma solução. Ao final, a solução do problema será a última solução candidata. O pseudocódigo do algoritmo está em Algoritmo 1. Dados: τ; distribuicao, menor custo, ultimo custo, ultimo estado, custo memoria enquanto τ > 0 faça nova distribuicao = gerar estado(ultimo estado) novo custo = custo(nova distribuicao) se aceitacao(ultimo custo, novo custo, tau) random() então ultimo estado = nova distribuicao se novo custo < menor custo ou (novo custo = menor custo e custo memoria(nova distribuicao) < custo memoria) entã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

110 3.3. Arquitetura do Mecanismo O mecanismo possui quatro módulos principais como pode ser visto na Figura 2. O Monitor de Recursos é responsável por coletar o uso de recursos das máquinas físicas e virtuais, o Otimizador executa a heurística para minimizar o número de máquinas físicas em funcionamento, o Orquestrador de Migração faz a redistribuição das máquinas virtuais entre as máquinas físicas e o Gerenciador de Energia desliga e liga máquinas físicas de acordo com a demanda. O Monitor de Recursos e o Orquestrador de Migração foram desenvolvidos no trabalho de Bezerra et al. [Bezerra et al. 2014] e integrados aos módulos Otimizador e Gerenciador de Energia desenvolvidos nesse artigo. O mecanismo foi desenvolvido em Python para facilitar a integração com o Monitor de Recursos e o Orquestrador de Migração que foram desenvolvidos nessa linguagem. Figura 2. Arquitetura do mecanismo de gerência proposto e do esquema de migração automática de máquinas virtuais. O Monitor de Recursos coleta o uso de CPU, memória e banda passante das máquinas físicas e virtuais através da biblioteca libvirt para se comunicar com os hipervisores de cada máquina física. O uso de CPU das máquinas virtuais é obtido diretamente pela libvirt. O processamento das máquinas físicas é calculado com a soma do processamento das máquinas virtuais. O perfil de uso de memória é obtido através da quantidade de memória alocada nas máquinas físicas e virtuais. O uso de rede das máquinas virtuais é coletado a partir da quantidade de dados que trafegam pelas interfaces virtuais. Como a solução atual não considera a topologia da rede, o uso de banda das máquinas virtuais contribui apenas no processamento do Domínio-0. O perfil de uso de recursos é gerado através do monitoramento das má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 número de máquinas físicas ativas. Ao final, o Otimizador gera uma nova distribuição de máquinas físicas e virtuais. Os dados das máquinas virtuais que serão migradas e os dados das máquinas físicas e virtuais são então enviados para o Orquestrador de Migração. O Orquestrador de Migração é responsável por gerenciar a migração das máquinas virtuais para a distribuição gerada pelo módulo de otimização. O Orquestrador usa a migração ao vivo do Xen com pré-cópia que se dá em duas fases. Na primeira fase as páginas de memória da máquina virtual são copiadas para a máquina de destino, se uma página é modificada ela é reenviada. A segunda fase inicia quando a taxa de reenvio é menor que a taxa de modificação. A máquina virtual é suspensa na origem e o restante das páginas modificadas é copiado para a máquina de destino. Ao final, a execução da 96

111 máquina virtual é retomada na máquina de destino. Dessa forma, o tempo de migração dependerá do tamanho da memória a ser transferida, da taxa de atualização dos dados na memória e do uso de recursos das máquinas físicas envolvidas na migração. Para evitar a sobrecarga do uso de rede devido a migração, uma máquina virtual só pode ser migrada quando a migração da máquina virtual anterior terminar. O Gerenciador de Energia desliga as máquinas físicas que após a execução das migrações não apresentam máquinas virtuais instanciadas. Esse módulo também liga as máquinas físicas quando não é 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 máquina física atinge determinado limiar em um determinado número de medições, o que caracteriza uma sobrecarga. Caso o algoritmo de otimização não encontre uma solução de menor custo, uma máquina física é religada através do protocolo Wake on Lan e as máquinas virtuais são redistribuídas após uma nova execução do algoritmo. O pseudocódigo desse módulo está em Algoritmo 2. Entrada: HostsOciosos, M aquinasdesligadas, M aquinasf isicas se sobrecarga(maquinasf isicas) e HostsOciosos = 0 então acordar(m aquinasdesligadas.pop()) Otimizador(M aquinasf isicas) fim senão para Maquina em MaquinasF isicas faça se M aquinasv irtuais(m aquina) = 0 então desligar(m aquina) M aquinasdesligadas.append(m aquina) fim fim fim Algoritmo 2: Gerenciador de Energia Uma máquina virtual é migrada para uma máquina física apenas se a máquina física possui recursos suficientes para alocar a máquina virtual. Do contrário, outra máquina é escolhida como destino. Se antes da migração o uso de recursos da máquina virtual é superior ao da máquina física de destino, a máquina virtual não migra para esse destino. Caso a máquina virtual oscile após a migração e ultrapasse um determinado limiar, a sobrecarga é detectada com base no histórico dos perfis de uso. As máquinas virtuais são então redistribuídas. O mecanismo não considera a topologia da rede para efetuar as migrações. Porém, o escopo de máquinas físicas participantes do processo de migração é configurável pelo administrador que pode estabelecer um grupo máquinas físicas geograficamente próximas. Assim, a latência da máquina virtual em relação ao cliente no novo destino pode ser reduzida. A coleta dos perfis de uso e a migração é realizada pela biblioteca multiplataforma libvirt. Dessa forma, o mecanismo de gerência pode ser usado em plataformas de virtualização como o Xen e o KVM. Além disso, as medidas para a geração de perfis são 97

112 obtidas através da libvirt, o que não requer a modificação de nenhuma máquina virtual, nem a instalação de softwares. Assim, preserva o isolamento das máquinas virtuais. O agendamento de execução do mecanismo depende da política do administrador podendo ser mantido em execuçã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 solução, o que varia com a quantidade de máquinas físicas e virtuais. 4. Resultados Dois testes foram realizados: um experimento para a verificação do bom comportamento do mecanismo proposto em migrar as máquinas virtuais e desligar as máquinas físicas e um estudo para a verificação da escalabilidade da solução de otimização. Para o primeiro teste que verifica o funcionamento do mecanismo proposto foram monitoradas três máquinas da plataforma FITS, a Leblon, Pão de Açúcar e Itanhangá. As máquinas Leblon e Pão de Açúcar possuem processador Intel i7 de 3.2 GHz e 16 GB de RAM, a máquina Itanhangá possui processador Intel i7 de 3.1 GHz e 8 GB de RAM. As máquinas possuem sistema operacional Debian Wheezy e executam a versão do Xen. As imagens das máquinas virtuais encontram-se em um nó central do FITS, não sendo necessário copiar o disco pela rede. O mecanismo de gerência proposto é executado em uma máquina Intel Core 2 Quad de 2.4 GHz com 3 GB de RAM que é externa à plataforma FITS para não interferir no experimento. O Domínio-0 está configurado para consumir 2 GB de memória. As máquinas virtuais possuem configurações heterogêneas de memória e processamento para avaliar a eficácia do mecanismo proposto. A máquina virtual lpcvm1 foi configurada com 2 processadores virtuais e 2 GB de memória RAM. As máquinas virtuais lpcvm2 e lpcvm3 foram configuradas com 1 processador virtual e com 4 GB e 3 GB de memória respectivamente. O processamento nas má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 migrações, foram escolhidas máquinas físicas com configurações semelhantes de processamento. A Figura 3 mostra a migração da máquina virtual lpcvm1 da máquina física Itanhangá para a máquina física Pão de Açúcar, Figura 3(a), Figura 3(b), Figura 3(c) e Figura 3(d). Em sequência ocorre a migração da máquina virtual lpcvm3 que é transferida da máquina física Leblon para a Pão de Açúcar, Figura 4 e, finalmente, as máquinas Itanhangá e Leblon são desligadas. Esse resultado mostra que o mecanismo é capaz de executar o algoritmo de otimização, fazer as migrações necessárias e desligar as máquinas físicas ociosas, atingindo o objetivo de reduzir o consumo de energia elétrica. Além disso, as máquinas migradas são as que possuem a menor quantidade de memória o que reduz a carga na rede durante a migração. Após esse experimento é feito um teste de sobrecarga de recursos. Nesse teste uma quarta máquina virtual é instanciada na máquina Pão de Açúcar. A Pão de Açúcar atinge o limiar de uso de memória e o mecanismo detecta a sobrecarga. Como a oferta de recursos é menor que a demanda o Gerenciador de Energia liga uma máquina física, nesse caso, a Itanhangá. Assim que a máquina é ligada o Otimizador calcula uma nova solução e a máquina virtual lpcvm1 é transferida para a Itanhangá. Para o teste do módulo de otimização foram comparadas três técnicas para 98

113 Processamento (%) Início da migração da máquina lpcvm1 } Aumento de processamento devido a migração Memória (%) Uso de memória da máquina lpcvm1 Redução da carga devido } ao início da migração Uso de memória do Domínio 0 Janela de tempo(s) (a) Uso de CPU em função do tempo. Janela de tempo(s) (b) Uso de memória em função do tempo. Processamento (%) Início da migração } Aumento do processamento devido a migração Memória (%) Memória não se altera pois ainda está migrando. Janela de tempo(s) (c) Uso de CPU em função do tempo. Janela de tempo(s) (d) Uso de memória em função do tempo. Processamento (%) lpcvm3 continua operando normalmente enquanto lpcvm1 é migrada Memória (%) lpcvm3 continua operando normalmente enquanto lpcvm1 é migrada Janela de tempo(s) (e) Uso de CPU em função do tempo. Janela de tempo(s) (f) Uso de memória em função do tempo. Figura 3. Início da execução do plano de ação de migração das máquinas virtuais determinado como resultado da meta-heurística de Arrefecimento Simulado. Assim que o programa inicia, a meta-heurística calcula uma solução e redistribui as máquinas virtuais. Na figura o mecanismo transfere a máquina lpcvm1 da máquina Itanhangá para a Pão de Açúcar que contém a máquina virtual lpcvm2. A figura também mostra a máquina lpcvm3 instanciada na máquina Leblon. Processamento (%) Carga total de processamento Término da migração de lpcvm3 Memória (%) Término da migração de lpcvm3 Janela de tempo(s) Janela de tempo(s) (a) Uso de CPU na máquina Pão de Açúcar em (b) Uso de memória na máquina Pão de Açúcar em função do tempo. função do tempo. Figura 4. Após a migração da máquina lpcvm1 a máquina virtual lpcvm3 é migrada para a Pão de Açúcar e as máquinas físicas Itanhangá e Leblon são desligadas. 99

114 alocação de máquinas virtuais. A meta-heurística de Arrefecimento descrita na Seção 3.2, e as heurísticas First Fit (FF) e First Fit Decreasing (FF). A heurística First Fit tenta alocar as máquinas virtuais na máquina física de menor índice e caso não seja possível aloca na próxima máquina. A First Fit Decreasing se diferencia da FF por ordenar as máquinas virtuais de forma decrescente de uso de recursos antes de iniciar a minimização. Para esse teste foi o utilizado o FFD padrão que considera as máquinas físicas com a mesma capacidade. O critério de ordenação para a técnica FFD foi estabelecido como o uso de processamento, memória e rede, nessa ordem. Foram utilizadas 50, 100, 500 e 1000 máquinas virtuais inicialmente instanciadas em 50, 100, 500 e 1000 máquinas físicas, respectivamente. Foram consideradas máquinas físicas com capacidade de 100% de processamento e 16 GB de memória. Para criar um ambiente heterogêneo de máquinas virtuais foram gerados recursos de processamento, memória e rede para cada máquina virtual seguindo uma distribuição normal. Os recursos de memória foram gerados entre 0 e 16 GB com média de 8 GB e desvio padrão de 4 GB. Os de CPU e rede entre 0 a 100% da capacidade das máquinas físicas com média e desvio padrão de 50%. Os testes consistiram de 10 rodadas limitadas a 320 segundos de execução e a temperatura do algoritmo de Arrefecimento Simulado foi inicializada em 1 milhão. Assim, o algoritmo para quando a temperatura ou o tempo chega a zero, o que ocorrer primeiro. Esses parâmetros foram configurados para simular um ambiente em que o tempo de reação do algoritmo é limitado SA FFDSA FFSA SA FFDSA FFSA Custo Custo Tempo (s) Tempo (s) (a) Desempenho dos algoritmos para 50 máquinas virtuais. (b) Desempenho dos algoritmos para 100 máquinas virtuais SA FFDSA FFSA SA FFDSA FFSA Custo Custo Tempo (s) Tempo (s) (c) Desempenho dos algoritmos para 500 máquinas virtuais. (d) Desempenho dos algoritmos para 1000 máquinas virtuais. Figura 5. Gráficos Custo x Tempo para os testes de otimização com 50, 100, 500 e 1000 máquinas físicas e virtuais. 100

115 Os gráficos da Figura 5 representam o tempo médio para o Arrefecimento Simulado encontrar soluções e melhorar as soluções das heurísticas. As figuras mostram a execução do Arrefecimento Simulado independente de heurísticas (SA), e a partir das soluções obtidas pelas heurísticas First Fit (FFSA) e First Fit Decreasing (FFDSA). O tempo de cálculo da solução inicial gerada pelo FF e pelo FFD para todos os testes foi menor que 1 segundo e foi desconsiderado do gráfico. Cada ponto representa a média e o desvio padrão para 10 rodadas. Os dados foram tomados sempre que o algoritmo encontrava uma solução de menor custo ou mesmo custo em termos de máquinas físicas. Independentemente do estado inicial, o algoritmo de Arrefecimento Simulado é capaz de reduzir a função custo. Consequentemente, o algoritmo reduz o número de máquinas físicas para cerca de 60% em todas configurações, economizando energia ao desligá-las. 5. Conclusão Este artigo propôs um mecanismo de gerência de máquinas virtuais que minimiza o consumo de energia elétrica ao reduzir o número de máquinas físicas em funcionamento. O mecanismo utiliza técnicas de otimização baseadas em Arrefecimento Simulado para obter as soluções de menor custo, desligando as máquinas ociosas. O mecanismo também ativa máquinas físicas quando a demanda por recursos é maior que a oferta disponibilizada pelas máquinas ligadas. Uma importante contribuição é o teste e a implementação do mecanismo na plataforma FITS, mostrando que o mecanismo funciona 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 otimização. Os resultados mostram que o mecanismo é capaz de encontrar soluções de menor custo e migrar as máquinas virtuais para essas soluções, desligando as máquinas físicas que se tornam ociosas nesse processo. Por sua vez, o estudo dos algoritmos de otimização mostrou que o uso do Algoritmo de Arrefecimento Simulado melhora os resultados, sendo a melhor solução aquela que faz uso desse algoritmo com a heurística First Fit. Futuramente pretende-se aprimorar o mecanismo através de um estudo dos principais parâmetros a serem utilizados em diferentes distribuições de máquinas virtuais e também em diferentes topologias de rede. Variáveis tais como número de saltos entre as máquinas físicas, origem e destino da migração e capacidades dos enlaces envolvidos na migração poderiam ser inseridas. Assim, seria possível determinar qual a solução de distribuição de máquinas é a menos custosa em termos de tempo de migração e distância do cliente a sua máquina virtual. Referê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 gerência de recursos para ambientes virtualizados. Em a ser publicado em XXXII Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC [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, páginas 3:1 3:7, New York, NY, USA. ACM. 101

116 [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, páginas , 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, páginas 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, pá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: [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). Análise de desempenho de mecanismos de encaminhamento de pacotes em redes virtuais. Em XXXI Workshop de Gerência e Operação de Redes e Serviços - (WGRS 2013) - SBRC [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): [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, páginas 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 interuniversitária com técnicas de virtualização híbridas. Em XXX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC [Mitchell 2002] Mitchell, J. E. (2002). Branch-and-cut algorithms for combinatorial optimization problems. Handbook of Applied Optimization, páginas [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: 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): [Waterland 2003] Waterland, A. (2003). Stress. Disponível em: seas.harvard.edu/ apw/stress/. Acessado em: Março de [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, páginas

117 32º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Florianópolis - SC XIX Workshop de Gerência e Operação de Redes e Serviços (WGRS) Sessão Técnica 3 Segurança, privacidade e qualidade de serviço na Internet

118

119 Um Modelo de Falhas em Cascata para Sistemas Globais de Gerenciamento de Identidades Ricardo Macedo 1, Aldri Santos 1, André Luiz Pires Guedes 1, Michele Nogueira 1, Yacine Ghamri-Doudane 2 1 Universidade Federal do Paraná Curitiba PR Brasil 2 University of La Rochelle La Rochelle CEDEX 1 France {rtmacedo,aldri,andre,michele}@inf.ufpr.br, yacine.ghamri@univ-lr.fr 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

120 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

121 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. 2. Trabalhos Relacionados 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

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

123 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 = {(a 1, a 2 ) a 1 A, a 2 A}, E4 = {(b 1, b 2 ) b 1 B, b 2 B}, E5 = {(c 1, c 2 ) c 1 C, c 2 C}, logo E = 5 E i. 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 i=1 109

124 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 C n 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 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 o conjunto de subconjuntos de C, ou seja, C = 2 C, logo os elementos de C representam todas as combinações possíveis dos elementos de C. Em outras palavras, cada elemento de C é 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 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 a função sobrejetora que descreve as arestas do conjunto B para C. Onde, 110

125 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, falso} 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 fault a função que representa esta falha de segurança no SGI. Logo, podemos denotar fault 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 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

126 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 b 1 B o provedor de identidades cuja a vulnerabilidade vul foi explorada para burlar o acesso da ID a B. Seja b 2 B o provedor de identidades adjacente à b 1. Seja E4 o conjunto de arestas que representa a relação dos provedores de identidades com propriedades em comum. Logo, as arestas incidentes à b 1 E4 descrevem quais provedores de identidades a vulnerabilidade vul pode ser explorada. Logo, exitem dois vértices b 1, b 2 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 b 1 é o vértice inicial e b 2 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 = {b 1, b 2..., b i }, onde cada provedor de identidades possui a vulnerabilidade vul. Logo, aplicando o Lema 1, existe um caminho P a = {b 1, b 2..., b i+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

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

128 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

129 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 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 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 ) = M 6,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 m i,j da matriz M contenham 1 se m i,j e mj, i são adjacentes e 0 caso contrário. A Figura 5 apresenta a matriz de adjacência M. M 6,6 = índices m 1,1 m 1,2 m 1,3 m 1,4 m 1,5 m 1,6 2 m 2,1 m 2,2 m 2,3 m 2,4 m 2,5 m 2,6 3 m 3,1 m 3,2 m 3,3 m 3,4 m 3,5 m 3,6 4 m 4,1 m 4,2 m 4,3 m 4,4 m 4,5 m 4,6 5 m 5,1 m 5,2 m 5,3 m 5,4 m 5,5 m 5,6 6 m 6,1 m 6,2 m 6,3 m 6,4 m 6,5 m 6,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. 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

130 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 2 15, resultando em 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 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 mensurar o efeito da falha em cascata a métrica IF C, denotada pela equação IF C = é definida. Onde NPIF consiste no número de provedores de identidades falhos e NTPI representa o número total de provedores de identidades. NP IF, NT P I 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 (%) CCG CCA Probabilidade de Vulnerabilidade Figura 6. Comparação da Disseminação de Falhas na CCG e em CCAs 116

131 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. edu/stats/. Último Acesso em Outubro de 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 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): 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 Cisco (2014). Cisco Visual Networking Index. com/c/en/us/solutions/collateral/service-provider/ visual-networking-index-vni/white_paper_c pdf. Último Acesso em Fevereiro de

132 Correcher, A., Garcia, E., Morant, F., Quiles, E., and Rodriguez, L. (2012). Intermittent failure dynamics characterization. IEEE Transactions on Reliability, 61(3): 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): 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 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): Lampropoulos, K. and Denazis, S. G. (2011). Identity management directions in future internet. IEEE Communications Magazine, 49(12): Lynch, L. (2011). Inside the identity management game. IEEE Internet Computing, 15(5): Motter, A. E. and Lai, Y.-C. (2002). Cascade-based attacks on complex networks. Phys. Rev. E, 66: 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): Torres, J., Nogueira, M., and Pujolle, G. (2013). A survey on identity management for the future network. IEEE Communications and Surveys Tutorials, 15(2): 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): 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 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

133 Análise Sistemática do Fenômeno Bufferbloat Thiago B. Cardozo 1, Alex B. Vieira 2, Artur Ziviani 1, Ana Paula C. Silva 3 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 Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) Belo Horizonte MG Brasil thiagoc@lncc.br,alex.borges@ufjf.edu.br, ziviani@lncc.br,ana.coutosilva@dcc.ufmg.br 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

134 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

135 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

136 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 MacMinis 1 executando GNU/Debian com kernel Linux 3.2 e 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 Quagga

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

138 Espaço de usuário Espaço de Kernel Aplicação 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 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

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

140 RTT Médio (ms) Tamanho do ring buffer (pacotes) (a) RTT médio x tamanho do ring buffer. Número de pacotes descartados Tamanho do ring buffer (pacotes) (b) Média de pacotes descartados x tamanho do ring buffer. Número de retransmissões Tamanho do ring buffer (pacotes) (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, 2 8, 2 9, 2 10, 2 11, 2 12 ), 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 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

141 RTT Médio (ms) Tamanho do qdisc (pacotes) (a) RTT médio x tamanho do qdisc. Número de pacotes descartados Tamanho do qdisc (pacotes) (b) Média de pacotes descartados x tamanho do qdisc. Número de retransmissões Tamanho do qdisc (pacotes) (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 scaling 6 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 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

142 14000 RTT médio (ms) Tamanho do qdisc (pacotes) 4096 Tamanho do Ring Buffer (pacotes) Figura 5. Impacto dos tamanhos de buffer (ring buffer e qdisc) no RTT Vazão (kbps) Tamanho do qdisc (pacotes) 4096 Tamanho do Ring Buffer (pacotes) 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 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

143 5 Janela de recepção Tamanho da janela anunciada (MB) Janela anunciada Sequência Figura 7. Tamanho da janela de recepção anunciada pelo TCP. 1 P(RTT h) RTT h (ms) Tamanho do Ring Buffer/qdisc (pacotes) 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 CoDel 7 [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 Con- 7 O CoDel é um algoritmo recente de gerenciamento ativo de fila (AQM) motivado pelo bufferbloat. 129

144 1 P(RTT h) RTT h (ms) Tamanho do Ring Buffer/qdisc (pacotes) 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

145 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 FA- PEMIG 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):

146 Appenzeller, G., Keslassy, I., e McKeown, N. (2004). Sizing router buffers. In Proceedings of ACM SIGCOMM, pages 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 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): Gettys, J. e Nichols, K. (2012). Bufferbloat: Dark Buffers in the Internet. Communications of the ACM, 55(1): 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): 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 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): Wehrle, K., Pahlke, F., Ritter, H., Muller, D., e Bechler, M. (2004). Linux Networking Architecture. Prentice Hall. 132

147 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

148 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

149 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. 2. Trabalhos Relacionados 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 ]. 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

150 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 Net- PaaS possibilita uma redução do consumo de banda e do atraso na recepção de conteúdo. Contudo, o NetPaas não tange o que diz respeito à distribuição do conteúdo 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

151 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íceis 2 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 anycasting 3 [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

152 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

153 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

154 à 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

155 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 instalada. Nos pontos de conversão, além da CCNx, foi instalado o VLC media player versão 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

156 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 Análise de tráfego (a) Consumo de banda no enlace entre o servidor e a rede de distribuição. (b) Consumo de banda de um dos clientes ligados 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

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

158 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

159 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 (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 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

160 5th international conference on Emerging networking experiments and technologies, pages 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 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 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): [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: [NS ] NS-3 (2014). Ns-3. Disponível em (Acessado em 15/03/2014). [Peng 2004] Peng, G. (2004). Cdn: Content distribution network. arxiv preprint cs/ [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): [Schulze and Mochalski 2009] Schulze, H. and Mochalski, K. (2009). 2008/2009. IPOQUE Report, 37: 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). mobility support. A new perspective on 146

161 32º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos Florianópolis - SC XIX Workshop de Gerência e Operação de Redes e Serviços (WGRS) Sessão Técnica 4 Gerenciamento de VANETs e VANTs

162

163 Um Mecanismo para Realçar a Conectividade de Roteamento Geográfico na Transmissão Multimídia em VANTs Rodrigo Costa 1, Denis Rosário 1, Aldri Santos 2, Eduardo Cerqueira 1 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,aldri@inf.ufpr.br 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

164 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

165 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. 2. Trabalhos Relacionados 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 Surveillance- Broadcast) 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

166 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 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ó n j. Esta estimativa ocorre por meio de informações de coordenadas no plano 3D (x j,y j,z j), da velocidade (v j ) e do tempo (t) de n j. Portanto, o posicionamento estimado (x pred, y pred, z pred ) de n j é calculado de acordo com a Equação

167 x pred = x j + t(v j sinθ j cosφ j ) y pred = y j + t(v j sinθ j sinφ j ) z pred = z j + t(v j cosθ j ) Onde, t é a diferença entre o tempo atual t c e o tempo do último pacote de posição para cada nó vizinho n j, ou seja, t = t c t l. Por outro lado, θ j e φ j representam as direções de deslocamento de n j. Em redes VANTs, existe a possibilidade de um nó n j sair da área de transmissão de um outro nó n i. Neste caso, a predição de posicionamento permite o monitoramento da distância entre um nó n i e seu próximo salto durante a transmissão multimídia. Portanto, o RCRV garante que um nó n i selecione um novo próximo salto antes da ocorrência da quebra do enlace Í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 (n j ) 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 = min Nj N i IC i,j = α T ExL i,j + β DirI j,d (c j, v j, D) + γ DisI i,j (D) (2) O cálculo de IC considera pesos (α, β, γ) para cada um dos critérios: T ExL i,j (tempo de expiração do enlace), DirI j,d (c j, v j, D) (direção de interceptação) e DisI i,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 ExL i,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 DirI j,d (c j, v j, D) provê a seleção dos nós que não estejam em movimentações opostas ao destino. Por fim, o DisI i,j (D) permite a seleção dos nós com base em suas distâncias. Portanto, um nó n i 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. (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 ExL i,j ) é um critério que estima a duração de um enlace entre dois nós. O RCRV calcula o T ExL i,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 ExL i,j de acordo com a variação da velocidade, da direção e da distância entre os nós. 153

168 Para explicar o cálculo do tempo de expiração de um enlace, assumem-se dois nós n i e n j, os quais permanecem dentro da área de transmissão de ambos. Sejam (x i, y i, z i ) e (x j, y j, z j ) as coordenas de n i e n j R 3, 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 v i e v j m/s. Então, as operações da Equação 3 indicam a distância entre os nós e suas direções. a = (x i x j ) b = (y i y j ) c = (z i z j ) e = (v i sinθ i cosφ i v j sinθ j cosφ j ) f = (v i sinθ i sinφ i v j sinθ j sinφ j ) g = (v i cosφ i v j cosφ j ) (3) O T ExL i,j entre dois nós n i e n j 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 ExL i,j é obtido por meio da Equação 4. T ExL i,j = (2ae + 2bf + 2cg) ± (2ae + 2bf + 2cg) 2 4(e 2 + f 2 + g 2 )(a 2 + b 2 + c 2 T R 2 ) 2(e 2 + f 2 + g 2 ) (4) De acordo com a equação proposta, o T ExL i,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 ExL i,j indicam uma movimentação com trajetórias contrárias ou com velocidades diferentes entre os nós n i e n j. 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 ExL i,j significam que o enlace entre os nós n i e n j é mais duradouro e robusto a quebra devido a mobilidade Direção de Interceptação A direção de interceptação (DirI j,d (c j, v j, 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 DirI j,d (c j, v j, D) é obtido por meio de operações trigonométricas e calculado conforme a Equação 5. Porém, o cálculo do DirI j,d (c j, v j, D) utiliza apenas informações de mobilidade no espaço 2D (R 2 ), 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, c j = (x j, y j ) e v j = (v jx, v jy ) as coordenadas e as componentes da velocidade de um nó n j. Além disso, todos os nós da rede têm o conhecimento sobre as coordenadas (x d, y d ) do destino. Então, a Equação 5 indica o nó com direção mais próxima ao destino. 154

169 DirI j,d (c j, v j, D) = θ 1 θ 2 anglet h (5) Onde, θ 1 = atan2(v jy, v jx ) 180 representa o ângulo em graus entre o eixo x π positivo e as componentes da velocidade v jy e v jx de um nó n j. Além disso, θ 2 = atan2(y d y j, x d x j ) 180 é o ângulo em graus entre o eixo x positivo de um nó n π j 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 (n 1 e n 2 ) presentes na tabela de nós vizinhos de um nó n i. Ambos n 1 e n 2 podem estabelecer uma rota com n i. 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ó n 1 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ó n 2 é o melhor candidato na tabela de n i. A tabela de vizinhos do n i 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ó n i 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 n i 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

170 A distância de interceptação (DisI i,j (D)) é um critério baseado na distância entre um nó n i e um outro nó n j. 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 n i e n j. d ni,n j = (x j x i ) 2 + (y j y i ) 2 + (z j z i ) 2 (6) Considerando (x i, y i, z i ) como as coordenadas de um nó n i que deseja selecionar seu próximo salto. Além disso, assumindo (x j, y j, z j ) e (x d, y d, z d ) como as coordenadas do candidato à próximo salto n j e do destino, respectivamente. Assim, a distância de interceptação é obtida pela Equação 7. DisI i,j (D) = d i,d d j,d d i,d (7) Onde, d ni,d é a distância entre o um nó n i que deseja selecionar seu próximo salto e o destino. Além disso, d nj,d é a distância entre o candidato à próximo salto n j e o destino. Como resultado da equação proposta, a distância DisI i,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

171 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. IC Q = 1.06 IC R = 0.89 IC O = 0.39 IC P = 1.59 IC M = 0.44 IC N = 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 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

172 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 b 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 UAV 1 e UAV 2 [GERCOM 2013] na transmissão, pois eles representam a cobertura de um VANT em um ambiente urbano. No entanto, o vídeo UAV 2 possui uma maior região de movimentação do que o UAV 1, 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 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

173 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,

174 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 UAV 1 apresenta um SSIM máximo de Assim, para 36, 44 e 56 VANTs a 1 m/s, o GPSR- RCRV apresentou um desempenho 4% inferior ao máximo para este vídeo. Por 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 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 UAV 2 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

175 A Figura 5 mostra o desempenho dos protocolos diante da transmissão do vídeo UAV 2. 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

176 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 , Chicago, USA. IEEE. Bekmezci, İ., Sahingoz, O. K., and Temel, Ş. (2013). Flying Ad-Hoc Networks (FANET): A Survey. Ad Hoc Networks, 11(3): 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): 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): Gavalas, D., Konstantopoulos, C., and Pantziou, G. (2010). Mobility Prediction in Mobile Ad Hoc Networks. Next Generation Mobile Networks and Ubiquitous Computing, pages GERCOM (2013). Source Videos Used for Simulations. Acessado em 10 de Setembro de 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 , 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 , 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 , 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 , 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 , 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

177 Investigação sobre o Uso de VANTs em Redes DTN para Cenários de Emergência José 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 comunicação entre equipes de resgate e o centro de comando (CC) de operações de busca em áreas de catástrofe é frequentemente afetada por obstáculos geográficos, tornando-a ineficaz. Uma forma de superar tais problemas é utilizando veículos aéreos não tripulados (VANTs) como nós móveis de uma rede tolerante a atrasos e desconexões (DTN), servindo de apoio às comunicações. Este artigo analisa o desempenho de diferentes protocolos de roteamento DTN através de simulações baseadas em traços reais de voo de um VANT sobre um cenário de desastre natural. Os resultados obtidos permitem verificar os protocolos mais adequados e a relação custo/benefício entre o número de VANTs e o desempenho da DTN. 1. Introdução No Brasil, de acordo com a base de dados internacional de desastres, encontrada em [EM-DAT 2012], os desastres mais recorrentes desde 1900 são as inundações, causadas principalmente por fortes chuvas, e em seguida os deslizamentos de terra, geralmente decorrentes dessas inundações. Especificamente no Estado do Rio de Janeiro, principalmente no período compreendido entre os meses de Janeiro e Fevereiro, existem diversas áreas com níveis pluviométricos altos, o que invariavelmente leva a situações de enchente e alagamento. Estradas interditadas, pontes destruídas, casas parcial ou integralmente soterradas ou inundadas - esses são alguns dos resultados decorrentes do cenário catastrófico que se abate sobre essa região nesta época do ano. Em meio a este cenário caótico, existem as equipes de socorro e resgate que precisam estar em constante comunicação com as bases de comando que coordenam estas operações. Tradicionalmente, toda a comunicaçã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 rádiocomunicação nas faixas de VHF e UHF. Entretanto, na ocorrência 163

178 de obstáculos geográficos ou por dificuldades na instalação de antenas para a transmissão do sinal de rádio, nem sempre esta comunicação é eficaz. Nestes cenários, a utilização de uma rede tolerante a atrasos e desconexões (delay/disruption tolerant network - DTN) [Warthman 2003, Venkataraman et al. 2009], adaptada para trabalhar com nós móveis, pode ser uma importante estrutura de apoio às equipes de socorro. Uma DTN é um tipo de rede sem fio na qual não se exige conectividade fim-a-fim e que são caracterizadas por atrasos, longos ou variáveis, no encaminhamento das mensagens, ou ainda pela intermitência das conexões. Como a superação de obstáculos geográficos pela via aérea é claramente uma forma mais rápida de se atingir locais isolados por desastres naturais, os Veículos Aéreos Não-Tripuláveis (VANTs) surgem como uma vantajosa opção para uso como nós móveis desta DTN. Os VANTs, como o próprio nome diz, são veículos aéreos que podem ser controlados de forma remota, por um operador, ou terem seu percurso pré-programado. Esses veículos podem ser classificados em 5 categorias básicas [Sarris 2001], as quais englobam tanto as aeronaves de asa fixa (aviões e planadores) quanto as de asas rotativas (helicópteros e girocópteros), e as que não se enquadram exatamente em nenhuma dessas categorias (quadricópteros, foguetes e balões). Equipando-se os VANTs para que estes se comportem como nós móveis de uma DTN, conquista-se uma ampla capacidade de mobilidade que propicia o estabelecimento de uma comunicação de dados entre os VANTs e entre estes e os nós terrestres, como as equipes de busca e/ou resgate e o centro de comando. Além disso, este tipo de comunicação potencializa a troca de informações entre equipes e centro de comando, uma vez que permite o envio de imagens e outros tipos de dados. Devido às características de intermitência nas conexões entre os nós de uma DTN, juntamente com a posssível mobilidade dos mesmos, foram propostos diversos protocolos de roteamento que contemplam as necessidades genéricas de uma DTN. Estes protocolos são baseados no envio, armazenamento e repasse de mensagens, com diferentes estratégias para cada etapa. Estas estratégias almejam melhorar diferentes aspectos relacionados ao desempenho e à eficiência na entrega de mensagens, sendo que estes fatores podem variar bastante de acordo com o cenário de uso e a rede em si. Assim sendo, o objetivo deste artigo é investigar o desempenho dos principais protocolos de roteamento DTN quando aplicados a uma rede formada por VANTs e nós terrestres, com finalidade de apoiar as operações de socorro em cenários de desastres naturais. Para tal, foram coletados dados reais de voos realizados com um VANT do tipo asa voadora numa trajetória pré-programada para cobrir quatro zonas de interesse e o local do centro de comando das operações de socorro relativas a uma enchente em Janeiro de 2013 no distrito de Xerém, município de Duque de Caxias (RJ). A partir destes dados, foram realizadas simulações variando o número de equipes nas zonas de interesse e o número de VANTs. Os protocolos utilizados nas aná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 fração de mensagens entregues, latência e overhead na entrega de mensagens. Pelos resultados obtidos, é possível verificar os protocolos mais adequados para este tipo de cenário e a relação custo/benefício entre número de VANTs e a melhora no desempenho da DTN. O restante do texto está organizado da seguinte forma: a Seção 2 apresenta os 164

179 trabalhos relacionados; a Seção 3 descreve brevemente os protocolos de roteamento DTN a serem analisados; a Seção 4 descreve o protótipo e o cenário utilizado para a coleta de dados; a Seção 5 detalha as simulações realizadas; a Seção 6 apresenta os resultados; for fim, a Seção 7 traz a conclusão e trabalhos futuros. 2. Trabalhos relacionados Historicamente a comunicação entre as equipes de socorro e destas com o centro de controle se dá pela utilização de rá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 comunicação para auxiliar nesses cenários vêm sendo propostas, como em [Dilmaghani and Rao 2008], onde uma infraestrutura de comunicação baseada em redes mesh é proposta para ser implementada nesse tipo de cenário. Em [Braunstein et al. 2006] é proposta uma nova arquitetura de rede sem fio híbrida e distribuída para auxiliar as equipes de emergência de forma escalável. Baseia-se em uma estrutura do tipo mesh para prover conectividade entre os nós e dos nós para o mundo (Internet). Um dos problemas dessas soluções é a necessidade de instalação de pontos infraestruturados, o que nem sempre é possível em virtude das limitações da área do desastre. Uma solução interessante apresentada em [Dilmaghani and Rao 2008] é a utilização de tiers, ou níveis, para separar os diversos tipos de conexões entre dispositivos. Em um nível temos clientes utilizando PDAs, notebooks e itags (por exemplo, etiquetas RFID). Em outro nível temos nós mesh e um terceiro nível links provê conexão à Internet. Embora essa solução também precise de nós infraestruturados no segundo nível, uma vez que a solução é separada em níveis existe a possibilidade de substituir a tecnologia utilizada neste nível por uma solução mais adequada para um ambiente de desastre. O trabalho em [Yarali et al. 2009] também propõe redes mesh como solução de conectividade em cenários de emergência. No entanto, se os roteadores e gateways não puderem contar com fontes de energia capazes de alimentá-los por longos períodos, eventualmente alguns desses equipamentos poderão ficar inoperantes, comprometendo a conectividade. Um algoritmo hierárquico para DTN é proposto em [Mota et al. 2009] com o intuito de suprir eventuais carências de infraestrutura numa rede de comunicação. Esse algoritmo objetiva aumentar a taxa de entrega de dados em redes intermitentes sem afetar o overhead de comunicação da rede. Em [Jiang et al. 2011] é proposta uma forma de utilizar DTNs para auxiliar vítimas numa situação de emergência. A proposta é a de que os celulares das vítimas sejam utilizados como nós em uma rede oportunística que se vale de um protocolo Epidemic modificado para este fim. Neste contexto, um cenário hipotético de incêndio em um prédio de três andares é explorado em [Gelenbe and Gorbil 2012], onde é verificada a resiliência em caso de falhas de alguns dos nós móveis. Durante um desastre, a percepção da situação ou o entendimento da gravidade e extensão da situação de emergência é um fator critico para minimizar o número de feridos, mortos e danos a propriedades. Em [Fall et al. 2010] é proposta uma arquitetura tolerante a desconexões na qual as pessoas comuns, envolvidas diretamente com a situação de desastre ou não, possam fornecer informações como texto, imagens etc às equipes de apoio e resgate. Para isso, basta que essas pessoas estejam próximas de um outro nó da 165

180 rede capaz de encaminhar as mensagens, o que nem sempre é viável. Em [Sivakumar and Tan 2010] é proposto um mecanismo de controle para permitir o voo em formação de vários VANTs, com o objetivo de utilizar esses VANTs como backbone para conectar eventuais nós móveis em terra ao redor de uma área específica onde haja equipes de resgate ou sobreviventes. Entretanto, neste trabalho não é 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 cenários de emergência. O estudo considera que os nós estarão se deslocando da área do incidente para a área onde será feita a triagem das vítimas, trocando mensagens entre si nessas regiões e no caminho de uma região para outra. Entretanto, não é considerado o uso de VANTs. 3. Protocolos de Roteamento DTN A DTN é um tipo de rede que funciona diferentemente das redes ad hoc, pois nã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 interrupções, a outros nós que, de outra forma, estariam completamente desconectados do restante da rede. Para isso elas utilizam-se de uma técnica denominada armazena-transporta-encaminha (store-carry-forward), onde os nós da rede podem armazenar a mensagem e a transportar até que esta possa ser entregue ao seu destinatário ou encaminhada para outro nó com o mesmo objetivo. Os protocolos convencionais de redes ad hoc, focados em situações onde os nó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, estão o Epidemic, o Maxprop, o Spray and Wait e o Prophet. Estes são os protocolos usados nas simulações realizadas no contexto deste trabalho. O protocolo Epidemic[Vahdat and Becker 2000] tenta disseminar cópias das mensagens por toda a rede, ou seja, todos os nós podem estar transportando a mensagem e cada nó, ao encontrar com o outro nó da rede, apenas troca as mensagens que eles não têm em seus buffers de memória. Essa técnica de disseminação garante uma alta tolerância a falhas de nós na rede, garantindo um número suficiente de trocas de mensagens entre todos os nós da rede e, eventualmente, recebendo as mensagens em um curto período de tempo. Esta abordagem não requer informaçõ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 são então classificados de acordo com essa prioridade. A prioridade dos pacotes é baseada na probabilidade de entrega ao nó de destino de acordo com dados históricos e outros mecanismos auxiliares, tais como uma lista de nós intermediários, notificações de recebimento e novos pacotes, que são priorizados em detrimento de pacotes mais antigos. Diversos métodos podem ser utilizados para definir essa prioridade, incluindo a taxa de sucesso na definição de um determinado caminho para um determinado nó ou a quantidade de tentativas bem sucedidas de entrega de mensagem de um determinado nó para outro. Essa técnica melhora, de maneira geral, a taxa de entrega de mensagens. 166

181 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 parâmetro L de ajuste do protocolo, para o número de có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 é enviado um indicador do número máximo de cópias desta mensagem. Durante a fase disseminar, N cópias são disseminadas na rede de forma epidêmica e, quando um número suficiente de cópias foi disseminado para garantir que pelo menos um deles irá chegar ao destino, de forma rápida esta fase é encerrada. Os nós que tenham recebido uma cópia da mensagem a mantêm armazenada e passam para a fase de espera, na qual cada nó carregando uma cópia da mensagem irá tentar entregar a mensagem de forma direta. O protocolo Prophet[Lindgren et al. 2003] parte da premissa de que o encontro dos nós de uma rede raramente ocorre de forma totalmente aleatória. Operando de forma probabilística, este protocolo estima uma métrica chamada previsão de entrega. Essa métrica indica a probabilidade de sucesso em entregar uma mensagem a um determinado nó de destino a partir de um outro nó de origem. O protocolo Prophet trabalha de forma que, quando dois nós se encontram, eles trocam um vetor de informação contendo uma previsão probabilística de entrega. Teoricamente, se dois nós se encontram frequentemente eles têm alta probabilidade de entrega entre eles, entretanto, se um determinado par de nós não se encontram por um longo tempo, eles não sã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 nós encaminhando mensagens somente para os nós que têm mais probabilidade de encontrar com o nó de destino, este protocolo consegue diminuir a inundação de pacotes de mensagens na rede e, consequentemente, diminuir o consumo de recursos, como buffer de mensagens e banda. 4. Cenário Investigado e Obtenção de Dados Reais Em Janeiro de 2013, uma sobrecarga de chuvas causou enchentes e deslizamentos na região do distrito de Xerém, em Duque de Caxias (RJ). Após a relativa normalização do acesso a esta regiã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 às atividades de busca e resgate realizadas neste cenário. A coleta de dados se deu a partir do sobrevoo de um VANT sobre um circuito definido com base nas á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 região limítrofe usada na definição da trajetória do VANT. O traçado de voo envolve um cirtuito onde o VANT sai do centro de comando (CC), atinge os pontos de interesse na sequência A, B, C e D, e retorna diretamente para o CC, quando então o ciclo é reiniciado. A partir deste voo, foram obtidas as informações utilizadas na simulação. A peculiaridade deste cenário é 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 desconexão com os VANTs, o que influencia diretamente 167

182 Figura 1. Cenário de Xeré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 á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 regiões. O acesso ao centro de comando també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 áreas. Os VANTs, portanto, teriam sido os únicos nós que conseguiriam atingir todos os pontos de interesse e o centro de comando, mesmo após a estiagem das chuvas fortes. Sobre cada ponto de interesse apontados no mapa, e também sobre o CC, o VANT usado para coleta de dados realizou três voltas de cerca de 50 metros de raio, dando assim tempo para que mensagens pudessem ser enviadas ou recebidas do VANT Protó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, são os mais indicados para uso em cenários de desastre. Em especial, as asas voadoras, por não necessitarem de pista para sua decolagem e aterrissagem, tornam-se extremamente versáteis e práticas para serem utilizadas nestes ambientes. Por este motivo, fez-se uso deste tipo de VANT para a obtenção dos dados a serem inseridos no simulador. Foi montado um protótipo composto por uma asa Zagi contendo bússola digital, acelerômetros, controle de altitude, GPS e sistema de piloto automático. A Figura 2 mostra o protótipo desenvolvido. A asa foi idealizada tomando como referência o manual de construção de asas voadoras[nogueira 2008] e utilizou um perfil MH5, com comprimento total de 1,60 metros e chapas de madeira balsa, que é um tipo de madeira bastante resistente e extremamente leve. As superfícies de comando da asa têm sua atuação efetivada por dois servo-comandos, um em cada lado da asa, da marca Towerpro. Como propulsão foi utilizado um motor elé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 construção torna o VANT extremamente estável em voo, facilmente controlável e bastante resistente a impactos. Como sistema de pi- 168

183 loto automático, para permitir voos programados, foi utilizado o sistema de código aberto Ardupilot [Sivakumar and Tan 2010] em sua configuração básica, sem alterações em seu firmware. A energia necessária para o funcionamento de todo esse equipamento é 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 protótipo VANT foi concebido para suportar ventos fortes em regiões litorâneas e, impermeabilizando as partes eletrônicas, pode ser usado com chuvas. VANTs de asa rotativa são úteis p/restrição de mobilidade, mas os de asa fixa têm mais robustez e autonomia, e estabilizadores de imagem melhoram a qualidade do que é filmado. Este VANT pode atingir 1000 metros de altura, mas acima de 500 metros há perigo para a aviação civil. Vale notar que consideramos usar o VANT após estiagem ou redução da chuva, momento no qual se costumam iniciar as buscas. Figura 2. O Protótipo de VANT desenvolvido. As rotas de voo a serem realizadas pelo VANT são programadas através do aplicativo desenvolvido pela equipe de desenvolvimento do Ardupilot, rodando em um notebook convencional. A conexão entre o notebook e o sistema de piloto automático é realizada através de um link de telemetria composto de rá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 distância é para leitura de telemetria e reprogramação em tempo real, porém o VANT realizará o percurso programado independente de alcance. 5. Etapa de Simulação Para simular o cenário pretendido, foi utilizado o simulador THE ONE [Keranen 2008]. Os mapas da região estudada foram importados para o simulador no formato WKT. Para cada elemento da simulação, ou seja, nós terrestres e nós VANT, foi necessária a criação de um mapa específico uma vez que cada um possui suas próprias caracteristicas de mobilidade. Os nós terrestres ficam agrupados em torno dos pontos de interesse, onde cada ponto de interesse apresenta limites de mobilidade correspondentes às estradas da regiã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, porém cada VANT tem sua própria posição inicial de voo. Para a geração desses mapas foi utilizado o sofware Openjump, que permite a importação 169

184 de mapas reais como camada de fundo, o que facilita a criaçã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 simulações, os VANTs voam a uma velocidade constante de 36 km/h, que é a velocidade mé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 número de VANTs variou de zero, para que tivéssemos um controle de como a rede se comporta sem o auxílio dos nós móveis, até o valor de seis VANTs. A partir do momento que temos dois VANTs no cenário, estes partem de posições iniciais distintas, de maneira que um VANT esteja metade do percurso à frente do outro. Com três VANTs, o mesmo procedimento é adotado, porém dividindo-se o percurso total em três partes. Com quatro, cinco e seis VANTs a mesma lógica é estabelecida, porém estes novos VANTs realizarão o percurso no sentido inverso, o que propiciará conexões entre VANTs durante o voo. O deslocamento das equipes ocorre de forma aleatória ao longo das estradas e ruas, porém restrito aos caminhos possíveis dentro do ponto de interesse a que estão confinados. A velocidade média vai de 0,5 a 1,5 m/s, para simular as dificuldades encontradas no deslocamento das equipes. Foram incorporados também momentos aleató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 número de nós representando as equipes ou pessoas nas zonas de interesse foi variado em 12, 20 e 32 nós, sendo que cada ponto de interesse possui um mesmo número de nós. O CC foi mantido numa mesma posição fixa em todas as rodadas de simulação realizadas. Com relação ao ambiente de rede sem fio, para todos os nós foram utilizados enlaces de rádio WiFi configurados para um alcance de 100 metros e capacidade de transmissã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 nó com destino para qualquer outro nó, exceto os VANTs, os quais não geram nem recebem mensagens, apenas as encaminham. As mensagens geradas foram agrupadas da seguinte forma: (i) mensagens geradas de um nó qualquer com destino a outro nó qualquer, incluindo o centro de comando; (ii) mensagens geradas de um nó qualquer com destino a outro nó qualquer, exceto o centro de comando; e (iii) mensagens geradas de um nó qualquer exclusivamente com destino ao centro de comando. Como citado antes, os protocolos de roteamento DTN escolhidos para análise foram o Epidemic, o Prophet, o Spray and Wait e o Maxprop. No caso do Spray and Wait, o número de cópias usado foi 6, que é um valor padrão. Estes protocolos foram escolhidos por serem os mais populares dentre aqueles que priorizam rapidez na entrega de mensagens. Foram efetuadas 10 rodadas de simulação para cada protocolo em cada cenário de simulaçã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 médio para entrega das mensagens, fração de mensagens entregues e overhead do número de mensagens. O intervalo de confiança adotado foi de 95%, obtido a partir da tabela de referência t-student, considerando 10 rodadas. 170

185 O atraso médio para entrega corresponde à média dos tempos de entrega de todas as mensagens que tenham chegado a seu destino. A fração de mensagens entregues corresponde à razão entre o total de mensagens entregues e o total de mensagens geradas. Já o overhead do número de mensagens corresponde ao número adicional de mensagens geradas por mensagem entregue. Seja T MT o total de mensagens transmitidas e T ME o total de mensagens entregues, o overhead é calculado por T MT T ME T ME. É interessante notar que, em um cenário de emergência, o overhead de mensagens, ou seja, a quantidade de cópias de mensagens geradas numa DTN, pode ser considerada uma métrica de menor importância uma vez que é mais urgente que as mensagens sejam entregues em seus destinos no menor tempo possível. Entretanto, para entender o desempenho geral dos protocolos nos cenários simulados, o overhead foi também analisado. Os buffers dos nós foram superdimensionados de forma a evitar a perda de mensagens, pois entende-se que isto seria inadequado num cenário de emergência. 6. Resultados Obtidos Figura 3. Fração de mensagens entregues. (a) (b) (c) A Figura 3 apresenta a fração de mensagens entregues no cenário com 20 nós terrestres para cada agrupamento de mensagens: (a) mensagens entre todos os nós, inclusive CC; (b) mensagens entre todos os nós, menos CC; e (c) mensagens entre os nós e o CC. Como podemos observar, a fraçã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 região e pelo tamanho do buffer utilizado nos nós, tendendo a infinito. Os resultados referentes a cada protocolo apresentam muito pouca ou nenhuma variação entre si, independente do número de nós, excetuando o caso do protocolo spray and wait. Para este protocolo, a fraçã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 número máximo de cópias de uma mesma mensagem na rede. Uma vez que a escolha dos nós que receberão essas cópias não considera a existência de VANTs, é possível que algumas mensagens não consigam ser entregues a um VANT. No caso de quando as mensagens são geradas tendo o CC exclusivamente como origem ou destino, verifica-se que a fração de pacotes entregues é zero quando não há VANTs circulando, uma vez que somente os VANTs conseguem alcançar o CC (Figura 3). 171

186 Os resultados para a fração de mensagens entregues nos cenários com 12 e 32 foram muito similares ao do cenário com 20 nós e tiveram seus gráficos omitidos para poupar espaço. Figura 4. Atraso médio para entrega de mensagens entre todos os nós. (a) (b) (c) Figura 5. Atraso médio para entrega de mensagens entre todos os nós, exceto CC. (a) (b) (c) Figura 6. Atraso médio para entrega de mensagens entre CC e qualquer outro nó. (a) (b) (c) As Figuras 4, 5 e 6 apresentam o atraso médio na entrega de mensagens respectivamente para os casos de mensagens entre todos os nós, mensagens entre todos os nós exceto o CC, e mensagens entre o CC e demais nós. Para cada caso, são mostrados os cenários com 12, 20 e 32 nós terrestres. De uma forma geral, é possível verificar uma redução do atraso a medida que aumenta o número de VANTs, sendo que esta redução fica percentualmente menor quanto maior o número de VANTs, sugerindo que ela tenderá a um valor limite. No caso de zero VANTs, este valor destoa da tendência encontrada no restante da curva, sendo valores menores quanto maior o número de nós terrestres. Isto se explica pelo fato da medida considerar apenas as mensagens entregues, incluindo aquelas 172

187 entregues entre os nós terrestres em um mesmo ponto de interesse, caso onde o atraso se torna bem pequeno. Quanto o maior o número de nós terrestres, maior a quantidade de mensagens entregues nestes pontos de interesse. No caso da Figura 6, com zero VANTs não há mensagem entregue, portanto não há valor associado a este número. Com relação ao comportamento por protocolo, o atraso médio do Prophet e do Spray and Wait sã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 nós capazes de realizar a entrega de determinada mensagem, um tempo maior na entrega é esperado. Mesmo no caso da Figura 6, que considera apenas mensagens entre o CC e demais nós, o Spray and Wait teve um atraso médio um pouco maior, enquanto que todos os demais tiveram resultados muito próximos, inclusive o Prophet. No caso do Prophet, este protocolo possui uma métrica que calcula a probabilidade do encontro entre dois nós e, como os VANTs são os únicos que se encontram constantemente com o centro de comando, esses passam a ser os nós preferidos para encaminhar mensagens ao CC. Tanto o protocolo Maxprop quanto o Epidemic apresentaram os menores atrasos médios em todos os casos. Uma vez que esses protocolos trabalham disseminando mensagens para quantos nós forem possiveis, essa baixa latência é esperada. Figura 7. Overhead de mensagens entre todos os nós. (a) (b) (c) Figura 8. Overhead de mensagens entre todos os nós, exceto CC. (a) (b) (c) As Figuras 7, 9 e 8 apresentam o overhead médio de mensagens respectivamente para os casos de mensagens entre todos os nós, mensagens entre todos os nós exceto o CC, e mensagens entre o CC e demais nós. Assim como antes, para cada caso, são mostrados os cenários com 12, 20 e 32 nós terrestres. É 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

188 Figura 9. Overhead de mensagens entre CC e demais nós. (a) (b) (c) controle de mensagens na rede. Entretanto, deve-se recordar que a fração de mensagens entregues e o atraso médio ficam comprometidos por conta deste mecanismo. Em situação oposta, o protocolo Maxprop apresentou os maiores valores de overhead, crescendo substancialmente com o aumento do número de nós terrestres. Isto ocorre porque este protocolo gera uma certa quantidade de mensagens de controle juntamente com a mensagem que está tentando entregar, o que torna seu overhead maior que o do próprio Epidemic. Os protocolos Epidemic e Prophet tê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 número de VANTs, se comparado com o Epidemic. Tabela 1. Tabela comparativa de resultado dos protocolos. 1: Pior caso, 2: Intermediário, Fração de mensa- Overhead Atraso Total 3: Melhor caso gens entregues médio Epidemic Maxprop Prophet Spray and Wait A Tabela 1 apresenta um sumário dos resultados de cada métrica para cada protocolo. De maneira a auxiliar na comparação, foi atribuída uma pontuação de 1, 2 e 3 para os casos onde a métrica associada a determinado protocolo apresenta o pior desempenho, um desempenho intermediá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 cenário aqui analisado, seguido de perto pelo protocolo Maxprop que recebeu uma pontuação pior devido ao seu overhead. Desconsiderando-se esta métrica, que pode ter pouca relevância no contexto de cenários de emergência, ambos têm desempenho equivalente. Outra observação relevante é quanto ao número de VANTs e sua relação com a melhora do desempenho na entrega de mensagens para o cenário estudado. Pelos resultados apresentados, fica claro que a métrica mais determinante para esta análise é o atraso médio, já que a fração de mensagens entregues é praticamente 100% para quase todos 174

189 os casos, uma vez que se tenha ao menos um VANT circulando, e que o overhead variou pouco com o aumento do número de VANTs no caso do Epidemic. Sendo assim, é possível verificar que, no caso do Epidemic, a partir do uso de dois VANTs a redução do atraso passa a ser muito pequena, o que também é verificado nos demais protocolos. Conclui-se portanto que, para o cenário estudado, bastam dois VANTs para se obter um desempenho relativamente próximo do ótimo na entrega de mensagens pela DTN. 7. Conclusão Os cenários de desastre podem apresentar características que dificultam o uso de tecnologias tradicionais de comunicação pelas equipes de resgate. Além disso, dependendo do cenário, a mobilidade das equipes também pode ficar comprometida, a ponto de não ser possível a locomoção dessas equipes até o centro de comando. Neste contexto, o uso de VANTS se apresenta como uma opção vantajosa para cenários de emergência, podendo servir como nós móveis na composição de uma DTN para apoio na comunicação com as equipes de resgate. Este trabalho analisou o desempenho de uma rede DTN formada por nós móveis, dentre os quais VANTs, para uso em cenários de emergência. As simulações realizadas se basearam em dados realistas coletados a partir de um protótipo de VANT que sobrevoou as áreas críticas que foram afetadas por uma enchente ocorrida em Janeiro de 2013 no distrito de Xerém, em Duque de Caxias (RJ). Foram comparados quatro conhecidos protocolos de roteamento DTN segundo as métricas de fração de entrega de mensagens, atraso médio da entrega e overhead de mensagens. Constatou-se que o protocolo Epidemic se apresentou como melhor opção e que bastam dois VANTs circulando para se obter um desempenho próximo do ótimo no cenário estudado. Como trabalho futuro, pretende-se utilizar os conhecimentos adquiridos no desenvolvimento de um protocolo de roteamento DTN usando nós móveis que seja otimizado para cenários de emergência, privilegiando os VANTs como nós de encaminhamento de mensagens. Além disso, outros tipos de VANTs deverão ser experimentados de forma conjunta, como por exemplo, balões. Referê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 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 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. Acessado em: 14 dez 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

190 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 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): 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 tolerância a interrupção em redes ad hoc móveis para cenários de emergência. Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuidos (SBRC), Recife, PE, Brasil. Nogueira, R. (2008). Manual básico para construção de zagis (asas voadoras). Acessado em: 14 dez 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 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 ACM. Vahdat, A. and Becker, D. (2000). Epidemic routing for partially-connected ad hoc networks. Technical Report CS , 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, MESH Second International Conference on, pages IEEE. 176

191 Protocolo Adaptativo de Disseminação de Dados para Aplicações de Segurança no Trânsito em Rodovias Renê Oliveira 1, Carlos Montez 1, Michelle Wangham 2 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) reneoliveira@das.ufsc.br, montez@das.ufsc.br, wangham@univali.br 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

192 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. 2. Trabalhos Relacionados 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

193 prioritários a disputa do canal é minimizada, desta forma o protocolo não sofre tanto com as colisões em cenários de alta densidade e também evita retransmissões desnecessárias. Ao utilizar o protocolo ackpbsm, os veículos emitem beacons periódicos, a fim de adquirir conhecimento sobre a topologia da rede local. Depois de cada troca, esta informação é utilizada para determinar se o próprio veículo faz ou não parte do CDS. Além disso, os beacons contêm os identificadores das mensagens que tenham sido recebidos recentemente. O protocolo é capaz de alcançar alta confiabilidade, minimizando o número de retransmissões. Porém, por utilizar beacons periódicos em cenários com maiores densidades, o protocolo pode atrasar a entrega das mensagens e também gerar sobrecarga com a utilização das mensagens de confirmação. O protocolo Density-aware Reliable Broadcasting Protocol (DECA) [Kamoltham 2011] faz uso do método store-and-forward e utiliza beacons periódicos. Veículos que trafegam em vias podem formar grupos, fazendo com que algumas faixas de rodagem tenham maior densidade do que outras faixas da mesma pista. Escolher um veículo que está na área de maior densidade para retransmitir uma mensagem pode maximizar o número de vizinhos que receberão a mensagem por meio de uma única transmissão. Portanto, o protocolo DECA usa informações referentes a densidade local para selecionar o nó que fará a retransmissão seguinte. De acordo com os autores, o protocolo DECA consegue alcançar seu objetivo que é prover confiabilidade e eficiência na transmissão de dados em redes de conectividade intermitente. Porém, o protocolo não se adapta de acordo com a densidade de veículos no cenário, desta forma sobrecarrega a largura de banda utilizada na troca de informações. O DECA pode superar outros protocolos, porém sofre com a utilização de beacons periódicos, que geram sobrecarga na rede em cenários com alta densidade. No modelo Reliable Broadcast routing based on Gain Prediction (RB-GP) [Chuan 2012], as informações de cada nó que integra a rede estão disponíveis por meio de trocas de beacons ou mensagens curtas periódicos. O principal objetivo do modelo RB-GP é maximizar o raio de cobertura em cada difusão e diminuir os atrasos nas transmissões, que é obtido por meio da seleção do próximo salto mais adequado (maior ganho), considerando todas as direções. Em cenários com baixa e média densidade, o protocolo garante que o nó selecionado pode receber os pacotes com sucesso e, com isso, diminuir o conflito nos canais e as informações retransmitidas de forma desnecessária. Os resultados mostram que o RB- GP é mais eficaz, no que diz respeito a taxa de entrega dos pacotes, e possui atraso médio menor quando comparado a outros modelos que utilizam inundação. Porém, este sofre com o excesso de beacons periódicos em cenários com alta densidade. Os autores deixam claro este problema e o definem como ponto chave a ser resolvido em trabalhos futuros [Chuan 2012]. Tabela1: Comparação dos Trabalhos Relacionados Trabalhos Beacons Confirmação Lista de Vizinhos Seleção do Retransmissor Adaptabilidade Nagaraj (2011) Não Utiliza Não Sim Direção Não Ros (2009) Periódicos Sim Sim Prioridade Não Kamoltham (2011) Periódicos Não Sim Densidade Local Não Chuan (2012) Periódicos Não Sim Distância e Densidade Não Protocolo Proposto Aperiódicos Não Sim Densidade Local e Distância Sim A Tabela 1 apresenta uma comparação destes protocolos confiáveis, considerando as seguintes características: (1) se utilizam mensagens de controle (beacons) e qual o tipo, periódicas ou aperiódicas; (2) se fazem uso de mensagens de confirmação (ack); (3) se 179

194 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

195 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 W j de cada vizinho da sua lista, que contém as informações dos vizinhos a um salto de comunicação. Este peso W j é 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) h h A componente B j 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 D j 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 Th B e Th D determinam o limiar para cada uma das componentes B j e D j, 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 W j, 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

196 de comunicação e é difundida o mais distante possível. Para calcular a distância B j 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 B j é dado por: = ( ) ( ) (2) na qual, x i e y i representam as coordenadas do veiculo i, e as componentes x j e y j representam as coordenadas do veiculo j. De posse da função B j, cada veículo calcula sua distância em relação a cada vizinho presente em sua lista, sendo que quanto maior valor de B j, 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 B j, define-se um limiar referente à distância, neste caso, este limiar é definido pelo raio de cobertura do nó i. A componente D j da Equação 1 determina a densidade local do nó j. Quanto maior a densidade, maior será seu valor. Para o valor D j, 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 ). ). h h (3) sendo que Dr j define o sentido de direção do nó j e pode ter o valor +1 ou -1. Após obter o valor de W j, o nó com maior peso W será selecionado para ser o retransmissor. Este processo se repete sempre que for necessário transmitir ou retransmitir uma mensagem de dado na rede. 3.2 Módulo de Comunicação Para permitir que dois nós se comuniquem, assume-se que cada um deles tem capacidade de comunicação e processamento embarcado. A comunicação entre os nós da rede veicular ocorre por difusão de mensagens. Dois nós que estejam dentro do mesmo raio de comunicação podem se comunicar diretamente, ou seja, receber e enviar mensagens um ao outro. O raio de comunicação de um nó i é denominado r i e define uma área de cobertura de comunicação descrita por um círculo, no qual i encontra-se no centro e todos os nós que estejam dentro deste círculo são denominados vizinhos ou membros da vizinhança do nó i. Os vizinhos dentro do raio de comunicação de um nó são ditos vizinhos a um salto de comunicação deste nó; e aqueles que estão dentro 2r i 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

197 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 Id k 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 Em i, t i k e Ds k. na qual Em i é a sequência de bits que representa o endereço MAC da máquina que criou o alerta; t i k é a sequência de bits que representa a data e hora em que o alerta foi enviado; e Ds k é 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 Em i, é responsável por armazenar o endereço MAC do nó que criou o alerta e tem seu tamanho estipulado em 48 bits Envio adaptativo de Mensagens de Controle Conforme visto anteriormente, a mensagem de controle utilizada pelo nó i para obter informações de sua vizinhança é a mensagem CM. Nos trabalhos citados na Seção2, esta mensagem também é usada, porém, de forma periódica. Esta característica interfere no funcionamento da rede, já que em determinados cenários, por exemplo, os com alta densidade de veículos, a troca de mensagens de controle de forma periódica pode causar uma quantidade elevada de colisões de pacotes. Para diminuir a quantidade de mensagens de controle em cenários densos, utilizam-se mensagens de controle aperiódicas. Estas mensagens têm como base um período mínimo entre retransmissões, sendo que este período se adapta de acordo com a densidade local do nó. Quanto maior a densidade local do nó, maior será o período entre retransmissões da mensagem de controle, desta forma em cenários de congestionamento, os nós deixarão o canal de comunicação livre mais tempo para que este possa ser utilizado por uma transmissão de alerta. Para que o nó i calcule este período, a cada mudança de densidade local, utiliza-se a seguinte equação: = ( + (. )) [0,0.002] (4) 183

198 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 D i 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 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 TeCM max. Durante este tempo de espera, o nó i recebe um conjunto de mensagens de controle (CM) de outros vizinhos e, ao expirar TeCM max, 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 TamMC i é o tamanho da lista de mensagens de controle recebidas durante o período TeCM max. O limiar [Int inicial, Int final ] é 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

199 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 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 D j, é 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 D j 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 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 N i. 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 t k-1, o raio de comunicação r i 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 g e com o datasheet do equipamento Access Point Cisco Aironet 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

200 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 Th B (300 metros); limiar Th D (50 veículos); TeCM max (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. Densidade (v/h) Tabela 2: Proporção de Colisões - Broadcast Puro, AFR, APR, DECA e Protocolo Proposto Broadcast Puro APR AFR Protocolo Proposto DECA ,1 % 10,2 % 11,5 % 8,4 % 9,8 % ,2 % 16,5 % 17,4 % 13,2 % 16,2 % ,8 % 19,7 % 20,1 % 16,2 % 19,1 % ,2 % 21,2 % 23,4 % 18,7 % 20,5 % ,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

201 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% 98,0% 100,0% 100,0% 100,0% 99,5% 100,0% 99,6% 100,0% 99,0% 99,3% 99,5% 100,0% 100,0% 99,0% 99,0% 99,0% 98,8% 97,8% 95,0% 95,0% 94,5% 93,0% 92,5% 92,3% 92,0% 91,2% Total de nós atendidos 90,0% 85,0% 80,0% 83,0% 82,0% 80,0% 78,0% 91,6% 86,6% 89,7% 75,0% 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

202 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 ,5 % Cenário ,2 % Cenário ,5 % Cenário ,9 % Cenário % 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, DECA 2, Protocolo Proposto 2, AFR 3, APR 4,

203 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, 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 ISSN Chuan, D. e Jian, W. (2012), "A reliable and efficient highway multihop vehicular broadcast model. Communications and Networking", ISRN, v. 2012, n , p. 8, quarter

204 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.], p ISSN 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.], p 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.], p. 1 {5. ISSN Lee J. et al. (2008), Vehicle local peer group based multicasting protocol for vehicletovehicle communications, In: The Fourth International Workshop on Vehicle-to- Vehicle Communications. Nagaraj, U. e Dhamal, P. (2011), "Broadcasting routing protocols in vanet. Network and Complex Systems", IISTE, v. 1, n. 2, p , ISSN Nakorn, K. N. e Rojviboochai, K. (2010), "Comparison of reliable broadcasting protocols for vehicular ad-hoc networks", In: Communication Technology (ICCT), th IEEE International Conference on. [S.l.: s.n.], p 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.], p ISSN 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, Gramado. SBRC, p Ros, F., Ruiz, P. e Stojmenovic, I. (2009), "Reliable and efficient broadcasting in vehicular ad hoc networks", In: Vehicular Technology Conference, VTC Spring IEEE 69th. [S.l.: s.n.], p ISSN Tonguz, O. et al. (2007), "Broadcasting in vanet" In: 2007 Mobile Networking for Vehicular Environments. [S.l.: s.n.], p

205 Simulação e Análise de Métodos de Detecção de Congestionamento de Veículos em VANET Mariana Ramos de Brito 1, Anna Izabel J. Tostes 1, Fátima de L.P. Duarte-Figueiredo 1, Antonio A. F. Loureiro 2 1 Departamento de Ciência da Computação Pontifícia Universidade Católica de Minas Gerais - Belo Horizonte, MG Brasil 2 Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) - Belo Horizonte, MG Brasil marianaramosbrito@gmail.com, annatostes@gmail.com fatimafig@pucminas.br, loureiro@dcc.ufmg.br 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

206 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. 2. Trabalhos Relacionados 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

207 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

208 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

209 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

210 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

211 foram o SUMO (Simulation of Urban MObility) [SUMO 2012], que é o simulador de mobilidade; o OMNeT++ [OMNeT ], 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

212 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 Fonte: Dados da pesquisa 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

213 Figura 5. Instante no tempo que a raiz somou o total de veículos Fonte: Dados da pesquisa Figura 6. Quantidade de beacons enviados Fonte: Dados da pesquisa 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

214 Figura 7. Chamadas ao algoritmo de descobrir congestionamento Fonte: Dados da pesquisa 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 27 0 Simpósio Brasileiro de Redes de 200