V Workshop de Pesquisa Experimental da Internet do Futuro ... · Wagner Meira Junior (UFMG) ... Aline Maria Santos Andrade (UFBA) Daltro José Nunes ... 3Grupo de Pesquisa em Redes

Anais V Workshop de Pesquisa

Experimental da Internet do Futuro WPEIF 2014

XXXII Simpósio Brasileiro de Redes de Computadores e

Sistemas Distribuídos

5 a 9 de Maio de 2014

Florianópolis - SC

Anais

V Workshop de Pesquisa Experimental da

Internet do Futuro (WPEIF 2014)

Editora

Sociedade Brasileira de Computação (SBC)

Organizadores

Marcos Rogério Salvador (Lenovo)

Michael Stanton (RNP & UFF)

Carlos André Guimarães Ferraz (UFPE)

Joni da Silva Fraga (UFSC)

Frank Siqueira (UFSC)

Realização

Universidade Federal de Santa Catarina (UFSC)

Promoção


Laboratório Nacional de Redes de Computadores (LARC)

Anais do V Workshop de Pesquisa Experimental da Internet do Futuro - WPEIF 2014

i

Copyright ©2014 da Sociedade Brasileira de Computação

Todos os direitos reservados

Capa: Vanessa Umbelino (PostMix)

Produção Editorial: Roberto Willrich (UFSC)

Cópias Adicionais:


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

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

Fone: (51) 3308-6835

E-mail: [email protected]

Workshop de Pesquisa Experimental da Internet do Futuro (5: 2014:

Florianópolis, SC)

Anais / Anais do V Workshop de Pesquisa Experimental da Internet do Futuro;

organizado por Marcos Rogério Salvador... [et al.] - Porto Alegre: SBC, c2014

40 p.

WPEIF 2014

Realização: Universidade Federal de Santa Catarina

ISSN: 2177-496X

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

I. Salvador, Marcos Rogério. II. Sociedade Brasileira de Computação. III. Título.


ii

Promoção


Diretoria

Presidente

Paulo Roberto Freire Cunha (UFPE)

Vice-Presidente

Lisandro Zambenedetti Granville (UFRGS)

Diretora Administrativa

Renata de Matos Galante (UFRGS)

Diretor de Finanças


Diretor de Eventos e Comissões Especiais

Altigran Soares da Silva (UFAM)

Diretora de Educação

Mirella Moura Moro (UFMG)

Diretor de Publicações

José Viterbo Filho (UFF)

Diretora de Planejamento e Programas Especiais

Claudia Lage Rebello da Motta (UFRJ)

Diretor de Secretarias Regionais

Marcelo Duduchi Feitosa (CEETEPS)

Diretor de Divulgação e Marketing

Edson Norberto Caceres (UFMS)

Diretor de Relações Profissionais

Roberto da Silva Bigonha (UFMG)

Diretor de Competições Científicas

Ricardo de Oliveira Anido (UNICAMP)

Diretor de Cooperação com Sociedades Científicas

Raimundo José de Araujo Macêdo (UFBA)

Diretor de Articulação de Empresas

Avelino Francisco Zorzo (PUC-RS)


iii

Promoção


Conselho

Mandato 2013-2017

Alfredo Goldman (IME/USP)

José Palazzo Moreira de Oliveira (UFRGS)

Maria Cristina Ferreira de Oliveira (ICMC/USP)

Thais Vasconcelos Batista (UFRN)

Wagner Meira Junior (UFMG)

Mandato 2011-2015

Ariadne Carvalho (UNICAMP)

Carlos Eduardo Ferreira (IME - USP)

Jose Carlos Maldonado (ICMC - USP)

Luiz Fernando Gomes Soares (PUC-Rio)

Marcelo Walter (UFRGS)

Suplentes - 2013-2015

Alessandro Fabrício Garcia (PUC-Rio)

Aline Maria Santos Andrade (UFBA)

Daltro José Nunes (UFRGS)

Karin Koogan Breitman (PUC-Rio)

Rodolfo Jardim de Azevedo (UNICAMP-IC)


iv

Promoção

Laboratório Nacional de Redes de Computadores (LARC)

Diretoria 2012-2014

Diretor do Conselho Técnico-Científico

Elias P. Duarte Jr. (UFPR)

Diretor Executivo

Luciano Paschoal Gaspary (UFRGS)

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

Rossana Maria de C. Andrade (UFC)

Vice-Diretor Executivo

Paulo André da Silva Gonçalves (UFPE)

Membros Institucionais

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

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

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

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


v

Realização

Comitê de Organização

Coordenação Geral

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

Coordenação do WPEIF

Marcos Rogério Salvador (Lenovo) Michael Stanton (RNP & UFF)

Coordenação de Workshops



vi

Realização

Organização Local

Carlos Barros Montez (UFSC)

Edison Tadeu Lopes Melo (UFSC)

Guilherme Eliseu Rhoden (PoP-SC)

Leandro Becker (UFSC)

Mário A. R. Dantas (UFSC)

Michelle Wangham (Univali)

Ricardo Felipe Custódio (UFSC)

Roberto Willrich (UFSC)

Rodrigo Pescador (PoP-SC)

Rômulo Silva de Oliveira (UFSC)

Secretaria do SBRC 2014

Juliana Clasen (UFSC)

Jade Zart (UFSC)


vii

Mensagem do Coordenador de Workshops do SBRC 2014

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

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

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

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

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

envolvendo pesquisadores e muitos estudantes em fase de desenvolvimento de seus

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Coordenador de Workshops do SBRC 2014


viii

Mensagem dos Coordenadores do WPEIF 2014

A Internet cresceu e evoluiu muito desde suas origens em 1969, transformando a

sociedade como um todo. Apesar do seu inegável sucesso, a tecnologia da Internet tem

mostrado suas limitações diante dos cenários atual e, principalmente, futuro que se

apresentam.

Preocupados com a perenidade da Internet e com sua capacidade de adaptação perante

estes novos desafios, partiram de pesquisadores mundo afora, em particular nos Estados

Unidos, na Europa e no Japão, iniciativas que buscam estudar e conceber novas

arquiteturas e tecnologias para a Internet do Futuro, a partir de abordagens tanto

evolutivas quanto revolucionárias.

O WPEIF é uma tentativa de chamar este tema à atenção da comunidade brasileira de

redes de computadores e sistemas distribuídos, porém de uma perspectiva mais

experimental, mais voltada à prototipagem de ideias e à experimentação e validação de

propostas em ambientes que apresentem características e fenômenos bastante próximos

daqueles apresentados em redes IP de produção.

Para tanto, desde sua 1ª. edição , no SBRC 2010, em Gramado, temos tido e atuado em

torno de quatro preocupações principais: i) despertar este espírito de prototipagem e de

validação em larga escala dos protótipos, bem no espírito do “we believe in runing code

and rough consensus” que permeia a Internet, ii) capacitar a comunidade para tal, iii)

criar infraestruturas para a experimentação e validação em larga escala e iv) buscar o

diálogo e fontes de financiamento para a execução de projetos desta natureza.

Na edição de 2010 trouxemos membros do time do Prof. Nick Mckeown, da

Universidade de Stanford, para ministrar um curso teórico e prático, de um dia inteiro,

sobre o protocolo OpenFlow para mais de 50 participantes. E é com grande satisfação

que vimos esta comunidade crescer ao longo dos anos.

Nesta 5ª edição, o WPEIF dedica metade da sua programação ao lançamento oficial da

infraestrutura de validação e experimentação em larga escala desenvolvida no projeto

FIBRE – Future Internet testbed/experimentation between BRazil and Europe. A outra

metade da programação contempla os artigos selecionados na chamada pública de

trabalhos e a apresentação de abertura sobre a tecnologia Netwok Functions

Virtualization (NFV), suas oportunidades para a comunidade e seus impactos na rede

FIBRE.

Gostaríamos de agradecer aos autores pelo interesse no evento e pela qualidade dos

trabalhos submetidos, aos membros do comitê técnico de programa e revisores pela

qualidade das revisões e aos coordenadores de workshops e geral do SBRC pela

confiança em nós depositada e pelo apoio na organização do WPEIF. E principalmente,

gostaríamos de agradecer aos participantes do WPEIF, cujo número cresce a cada

edição, consagrando-o como um dos maiores e mais importantes workshops do SBRC.

Marcos Rogério Salvador (Lenovo)

Michael Stanton (RNP & UFF)

Coordenadores do WPEIF 2014


ix

Comitê de Programa do WPEIF 2014

Adriano Cansian (ACME/Unesp)

Antonio Jorge G. Abelém (FERCOM/UFPA)

Christian Esteve Rothenberg (CPqD)

Edmundo Roberto Madeira (IC/Unicamp)

Fabio Luciano Verdi (UFSCar)

José Augusto Suruagy Monteiro (Unifacs)

José Ferreira de Rezende (GTA/UFRJ)

Lisandro Zambenedetti Granville (UFRGS)

Luciano Paschoal Gaspary (UFRGS)

Ronaldo Alves Ferreira (UFMS)


x

Sumário

Sessão Técnica 1............................................................................................................ 1

RepoSDN: Um Método de Organização e Coordenação de Aplicações em

Repositório para Redes Definidas por Software

Romulo Pinheiro (UFPA), Andre Bahia, Dangelo Mendes, Billy Pinheiro,

Antônio Abelém e Joelyson Rodrigues................................................................. 3

Sessão Técnica 2............................................................................................................ 7

Resiliência no Plano de Controle para Redes Definidas por Software

Eros Spalla (UFES), Diego R. Mafioletti, Alextian Liberato,

Magnos Martinello, Rodolfo Villaça..................................................................... 9

Balanceamento de Carga em SDN Provido por Comutadores Estocásticos de

Prateleira

Alextian Liberato (UFES, IFES), Diego R. Mafioletti (UFES), Eros Spalla

(UFES), Magnos Martinello (UFES) e Rodolfo Villaça (UFES).......................... 13

Análise e Gerenciamento de Rede através de Grafos em Redes Definidas por

Software

Gustavo Pantuza (UFMG), Frederico Sampaio, Luiz F. M. Vieira,

Dorgival Guedes e Marcos A. M. Vieira............................................................... 17

Quality-oriented Mobility Control Architecture for ETArch Handover

Optimization

Felipe Silva (IFRN, UFRN), José Castillo-Lema (UFRN), Augusto Neto (UFRN),

Flávio Silva (UFU), Pedro Frosi Rosa (UFU), Daniel Corujo (ITAV, Portugal),

Carlos Guimarães (ITAV, Portugal) e Rui Aguiar (ITAV, Portugal)................... 21

Enabling a Carrier Grade SDN by Using a Top-Down Approach

Flávio Silva (UFU), Caio C. Ferreira (Algar Telecom), Natal Neto (UFU, Algar

Telecom), Alex Mota (Algar Telecom), Luiz Claudio Theodoro (UFU, Algar

Telecom), João H. S. Pereira (Algar Telecom), Augusto Neto (UFRN) e

Pedro Frosi Rosa (UFU)........................................................................................ 25

Índice por Autor............................................................................................................ 29

32º Simpósio Brasileiro de Redes de Computadores e


Florianópolis - SC

V Workshop de Pesquisa

Experimental da Internet do

Futuro (WPEIF)

Sessão Técnica 1

RepoSDN: Um Método de Organização e Coordenação deAplicações em Repositório para Redes Definidas por Software

Rômulo S. Pinheiro1,3 , Billy A. Pinheiro2,3 , André Bahia1,3

Dangelo Mendes3 , Joelyson Rodrigues1,3 , Antônio J. G. Abelém1,3

1 Programa de Pós-Graduação em Ciência da Computação (PPGCC)

2Programa de Pós-Graduação em Engenharia Elétrica (PPGEE)

3Grupo de Pesquisa em Redes de Computadores e Comunicação Multimídia (GERCOM)Universidade Federal do Pará (UFPA)

Caixa Postal 479 – 66075-110 – Belém – PA – Brasil

{romulosp, billy, andrebahia, dangelo, joelyson, abelem}@ufpa.br

Abstract. Software-Defined Networking paradigm provides better flexibility andprogramability for computer networks. This model passes to network applicati-ons, which is running on a controller, responsability to define network behavioursuch as routing and dynamic addressing that used to run in a closed box. In thispaper, we propose a method of organizing and coordinating applications reposi-tory for SDN that specify, model and automate the steps needed by applicationsto achieve the network administrator, and then to be used on the network byhim/her. This way, applications usage by the network owner becomes simpler,faster and safer.

Resumo. O paradigma de Redes Definidas por Software proporciona maiorprogramabilidade e flexibilidade às redes de computadores. Este novo modelodesloca para aplicações disponíveis nos controladores, a reponsabilidade dedefinir o comportamento da rede como, por exemplo, o roteamento, a atribui-ção de endereços dinâmicos e etc, que antes ficavam em comutadores fechados.Neste artigo, é proposto um método de organização e coordenação de aplica-ções em repositório para redes definidas por software, que especifica, modela eautomatiza os processos necessários para que as aplicações cheguem até o ad-ministrador e este possa gerenciar suas utilizações na rede, tornando-a simples,segura e ágil.

1. IntroduçãoAs redes de computadores são dinâmicas e complexas, como resultado, a sua configura-ção e o seu gerenciamento continuam sendo um desafio. Estas redes normalmente com-preendem um grande número de comutadores com muitos tipos de eventos que ocorremsimultaneamente, sendo os administradores de rede os responsáveis pela sua configura-ção, a fim de aplicar várias políticas de alto nível, para responder à ampla gama de eventosde rede [Kim and Feamster 2013].

Uma das formas de se prover autonomia às redes de computadores é através daimplementação de Software Defined Network (SDN), que são redes cujo substrato fí-sico é composto por equipamentos onde o plano de controle é realizado por um com-ponente externo chamado de controlador, e o funcionamento de cada equipamento, ou


3

conjunto de equipamentos, é definido por aplicações especializadas, armazenadas dentrodeste componente[Greenhalgh et al. 2009].

O gerenciamento de aplicações SDN ainda é uma solução pouco explorada, taisaplicações se encontram espalhadas em diversos repositórios de códigos na Internet.Sendo assim, o RepoSDN é proposto, desenvolvendo todo um ecossistema entre APIs,aplicações SDN, repositórios e controladores, o que possibilita um melhor gerenciamentoe controle dessas aplicações SDN, definindo toda a sua trajetória, iniciada no desenvolve-dor até o seu uso pelos controladores.

O RepoSDN foi inicialmente proposto no International Workshop on ADVANCEsin ICT Infrastructures and Services[Pinheiro et al. 2013]. Adicionalmente, nos reestrutu-ramos a arquitetura da proposta, fizemos implementação de um protótipo e testes de cargaforam realizados para comprovar a viabilidade da proposta.

2. Trabalhos Relacionados

Utilizamos como trabalhos relacionados modelos consagrados no sentido de gerência derepositório de aplicações, visto que existe uma grande dificuldade em encontrar trabalhoscientíficos sobre o tema proposto, cada tecnologia abaixo foi analisada e potencializadada melhor forma para o desenvolvimento do RepoSDN, a fim de tornar viável a sua im-plementação.

O Google Play1 é uma loja virtual da Google que tem como objetivo distribuiraplicativos, que podem ser criados por qualquer desenvolvedor. Essas aplicações estãodisponíveis de graça ou a um custo, o que pode alternar de acordo com cada desenvolve-dor.

App Online Store2 é a loja a onde estão disponíveis todas as aplicações desenvolvi-das exclusivamente para o Sistema Operacional (SO) fechado da Apple. Para desenvolveraplicativos para esta plataforma do IOS, a Apple disponibiliza uma Software DeveloperKit (SDK) e cobra uma licença para os usuários se tornarem desenvolvedores.

O Advanced Packaging Tool (APT)3 é uma ferramenta de pacotes utilizada nasdistribuições Debian do linux baseadas em comandos dpkg, ela permite que os usuáriosescolham de quais repositórios querem receber atualizações.

A Hewlett-Packard (HP)4 está desenvolvendo uma loja de aplicativos SDN, e dis-ponibilizando uma SDN Developer Kit, permitindo que os usuários desenvolvam aplica-tivos apenas para seu controlador de hardware fechado, ou seja, os aplicativos contidosna loja virtual só funcionarão no controlador da HP.

3. RepoSDN: Um Método de Organização e Coordenação de Aplicações emRepositório para Redes Definidas por Software

O RepoSDN tem como objetivo de reunir aplicações para Redes Definidas por Software,padronizando e definindo quais aplicações o controlador poderá utilizar, permitindo uma

1Google play: https://play.google.com/store2Apple Store: http://store.apple.com3http://wiki.ubuntu-br.org/AptGet4http://h17007.www1.hp.com/


4

maior confiabilidade dessas aplicações, uma vez que haverá apenas uma fonte de aplica-ções, facilitando a organização, especificação e atualização das mesmas, fazendo com queas aplicações SDN saiam do desenvolvedor e cheguem até seu destino final. As aplica-ções serão utilizadas por controladores de redes, logo este repositório fornecerá diversossoftwares para vários tipos de controladores existentes, seja a arquitetura aberta ou fe-chada.

Para utilizar o RepoSDN a fim de armazenar e controlar as aplicações, foi de-senvolvido um repositório de aplicações, onde qualquer usuário previamente cadastradopoderá enviar a sua aplicação e disponibilizá-la para outros usuários. É importante ressal-tar que este repositório de aplicações não é um repositório de códigos como o Git Hub5.

Todo esse processo tem início no desenvolvedor que envia a sua aplicação parao repositório de aplicações, que por sua vez é gerenciada pelo Administrador das Apli-cações (ADM APP) onde através das políticas de uso do repositório, vai decidir quaisaplicações são aceitas ou rejeitadas. O Administrador SDN (ADM SDN) tem a funçãode baixar as aplicações e inserir ou não nos controladores da sua rede programável, ouseja, ele tem a opção de baixar e instalar as aplicações diretamente em sua rede, pode sevisualizar melhor essa arquitetura através da Figura 1.

Figura 1. Arquitetura Geral do Modelo de Administração e Gerenciamento

4. Experimento e Resultado4.1. Teste de Desempenho no Repositório de AplicaçõesA ferramenta utilizada para medir o desempenho e estressar o servidor foi o ApacheJMeter6 que é um software livre desenvolvido em java, projetado para medir capacidadee desempenho de aplicações web.

Foram feitos testes no servidor onde o repositório está armazenado e configurado,foram criados 1.000, 2.000, 5.000, 10.000, 20.000 e 50.000 usuários virtuais (threads),

5Git Hub: https://github.com/6jmeter: http://jmeter.apache.org/


5

onde o tempo de inicialização foi de 1 segundo e o contador de iteração foi de 1, ou seja,cada usuário irá requisitar uma vez a cada um segundo para o Repositório de AplicaçõesSDN.

Figura 2. Média de Tempo dos Usuários Virtuais

A Figura 2 apresentada, exibe média de tempo que os usuários virtuais levarampara acessar e fazer o download do arquivo ospfviz.zip de tamanho 70KB no Repositório,onde nas 50.000 requisições houve um tempo médio de 17550,5 milisegundos e o desviopadrão de 2245,53. A barra de erro do gráfico representa o desvio padrão.

5. Conclusões e Trabalhos FuturosPara viabilizar todo o processo que permite que a aplicação se inicie no desenvolvedore chegue até o cliente (controlador), encontra se em desenvolvimento um Middlewarechamado de Midcontroller, que integra e automatiza as funcionalidades do gerenciadorde aplicações com o controlador, auxiliado pelo controller orchestrator.

Outro experimento a ser realizado será o teste de carga, que analisará como o Con-troller Orchestrator e o Midcontroller se comportariam em um sistema real. Este projetoencontra-se em desenvolvimento no Grupo de Pesquisa em Redes de Computadores eComunicação Multimídia - GERCOM7.

ReferênciasGreenhalgh, A., Huici, F., Hoerdt, M., Papadimitriou, P., Handley, M., and Mathy, L.

(2009). Flow Processing and the Rise of Commodity Network Hardware. ACM SIG-COMM Computer Communication Review, 39(2):20–26.

Kim, H. and Feamster, N. (2013). Improving network management with software definednetworking. IEEE Communications Magazine, 51(2):114–119.

Pinheiro, R., Pinheiro, B., and Abelém, A. (2013). A Strategy for Distributing and Mana-ging Software Defined-Network Applications.

7GERCOM: http://gercom.ufpa.br/


6

32º Simpósio Brasileiro de Redes de Computadores e


Florianópolis - SC

V Workshop de Pesquisa

Experimental da Internet do

Futuro (WPEIF)

Sessão Técnica 2

Resiliencia no Plano de Controlepara Redes Definidas por Software

Eros Spalla1, Diego Mafioletti1, Alextian Liberato1,Magnos Martinello1, Rodolfo Villaca1

1 Programa de Pos-Graduacao em Informatica (PPGI)Universidade Federal do Espirito Santo (UFES) – Vitoria, ES

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

[email protected], [email protected]

Abstract. In Software Defined Networks (SDN) is not yet clear how to ensurehigh availability. When it uses a central controller which is a single point offailure, the network may become unavailable. This work presents a proposal toprovide resilience in control plane of SDNs based on OpenFlow 1.3.We defineprotocols and their primitives for supporting fault recovery of controllers andswitch migration between controllers. Varying network traffic, evaluates the la-tency of failover and migration. The results in Mininet indicate that the networktraffic has a greater impact on migration than in the failure recovery process.

Resumo. Em Redes Definidas por Software (SDN), ainda nao esta claro comogarantir alta disponibilidade, ao passo que, o uso de um controlador central quee um ponto unico de falha, pode gerar indisponibilidade da rede. O trabalhoapresenta uma proposta para prover resiliencia no plano de controle de SDNsque utilizam o protocolo OpenFlow 1.3. Definimos protocolos e suas primitivaspara recuperacao de falha dos controladores e para migracao de switches entrediferentes controladores. Em cenarios com variacao de trafego, avalia-se alatencia de recuperacao de falhas e migracao. Os resultados obtidos no Mininetindicam que o trafego da rede teve um maior impacto no processo de migracaodo que no de recuperacao de falha.

1. Introducao

A flexibilidade oferecida pela arquitetura das Redes Definidas por Software (SDN) apoia-se na separacao do plano de dados e plano de controle, permitindo programar a rede egerencia-la a partir de uma visao centralizada. Nesta arquitetura, os estados da rede saodefinidos por um controlador que envia sua decisao (entradas nas tabelas de fluxos) paraos elementos de rede por meio do protocolo OpenFlow [McKeown et al. 2008].

O protocolo OpenFlow tornou-se um “padrao de fato” em SDN. No entanto, sea visao centralizada for implementada por um controlador, ha um ponto unico de falhana arquitetura, e assim, garantir alta disponibilidade no plano de controle e atualmenteum enorme desafio. Desde a versao 1.2 [ONF 2011], o OF tem incorporado modificacoespara prover funcionalidades que permitem aos switches se comunicarem com multiploscontroladores. Uma dessas funcionalidades e o modo de operacao dos controladores,conhecido como Roles (Papeis) de master, equal e slave.


9

Esse trabalho explora o conceito de papeis para prover resiliencia do plano decontrole SDN. Nossa proposta baseia-se em um protocolo distribuıdo entre controladoresredundantes, e nas mensagens de troca de papeis (role-request e role-reply). Como provade conceito, a proposta foi implementada em um prototipo no qual mede-se a latencia noprocesso de recuperacao de falha e migracao de switches entre controladores. O prototipofoi implementado no controlador Openflow Ryu [RYU 2014], e os testes realizados noambiente Mininet [Lantz et al. 2010].

A seguir, a Secao 2 apresenta a arquitetura do prototipo, o tratamento dos proces-sos de falha dos controladores e a migracao de switches; na Secao 3 sao apresentados osresultados; e na Secao 4 trabalhos futuros e conclusao.

2. Arquitetura SDN para resiliencia do plano de controle

O uso dos papeis definidos no OF, master, equal e slave, permite que os controladorestenham diferentes pontos de vista relacao aos switches, isso torna possıvel a comunicaode um switch com varios controladores. Por exemplo, se o switch x tiver o controlador ycomo master ou equal, esse controlador tera acesso total ao switch, caso o switch x tenhao controlador y como slave, o controlador acessa o switch apenas para leitura, a excecao,nesse caso, se da pelo fato do controlador poder enviar requisicoes para troca de papeisao switch. A principal diferenca entre os papeis master e equal, e a possibilidade de umswitch se conectar a varios controladores em modo equal, porem a apenas um em modomaster.

Em cada controlador existem tres modulos que dividem as funcoes do sistema,sao eles: ConnectionManager, que gerencia a comunicacao entre os controladores; Role-Manager, que coordena as operacoes de troca de papeis, migracao e recuperacao de falhas;Application (switching), que carrega um aplicacao de switching com suporte OF 1.3. AFigura 1(a) mostra a arquitetura do controlador.

(a) Arquitetura do controlador (b) Arquitetura inicial

Figura 1. Ambiente experimental

Ao iniciar a execucao dos controladores, os modulos sao carregados em sequencia,sendo ConnectionManager o primeiro. Esse modulo abre uma conexao tcp com o con-trolador parceiro, executa um processo de handshake, onde os seus identificadores saotrocados, e a partir de entao, para monitoramento, uma mensagem de keep alive passa aser enviada entre os pares.


10

A conexao de todos switches da rede aos dois controladores e uma premissa para ofuncionamento do sistema. A medida que switches sao adicionados a topologia, o moduloRoleManager faz uma operacao para que os papeis do controlador fiquem de forma in-tercalada, entre master e slave, para o switch em questao. Por exemplo, o switch 1 ao seradicionado a rede, tera o controlador 1 como master e o 2 como slave, o switch 2 tera ocontrolador 1 como slave e o 2 como master. A Figura 1(b) mostra como fica o cenariocom dois switches.

A situacao de falha ocorre quando ha indisponibilidade de um dos controladores.Ja a migracao acontece quando o controlador que falhou se recupera da falha, ou seja,esta apto novamente a processar pacotes. Nesse caso, o controlador, que volta da falha,executa o protocolo de migracao e recupera os switches que o tinham como master nomomento anterior a falha.

A recuperacao de falha consiste em um processo que faz o controlador, que con-tinua ativo, tornar-se o novo master para todos os switches que perderam o seu controladorprincipal. Os passos executados no protocolo, sao: no momento em que a troca de men-sagens keep alive e interrompida, o modulo ConnectionManager envia uma mensagemcontrollerdown para o RoleManager, este modulo verifica quais sao os switches que temcomo master o controlador que falhou, e os envia uma mensagem role-request master,cada switch responde com uma mensagem role-reply para confirmar a operacao.

Em [Dixit et al. 2013] e apresentado um protocolo para migracao de switches en-tre controladores. Nossa proposta apresenta uma variacao deste protocolo. O controladorque volta de uma falha, no momento da inicializacao de seus modulos, ja carrega osswitches em modo equal. Esse procedimento otimiza a execucao do protocolo, ja queas mensagens de troca de papel sao enviadas na inicializacao do controlador. Apos essaoperacao, uma mensagem de migracao e enviada para o controlador que ja estava ativo, eentao, o protocolo segue o mesmo fluxo descrito por Dixit.

3. Resultados ExperimentaisPara avaliar a latencia do processo de recuperacao de falha, medicoes foram feitas emtres instantes: na deteccao da falha, no momento de envio da mensagem role-request eno recebimento da mensagem role-reply. Na operacao de migracao, foi medido o tempototal para execucao do processo.

Ao efetuar os testes no ambiente emulado Mininet, tres cenarios foram utilizadospara medir o tempo de recuperacao de falha e migracao de um switch. Em um primeiromomento, o experimento foi feito sem trafego nos controladores, logo entao, com umamedia de 300 packet-in/s, e por fim, com uma taxa de 500 packet-in/s. As cargas detrafego foram escolhidas de modo a nao sobrecarregar o controlador, ja que o objetivonao era medir desempenho. A Figura 2(a) apresenta os tempos de recuperacao de falha emigracao, para os cenarios descritos.

Os tempos de deteccao da falha variaram entre 69,4 a 72,2 ms, ja envio da men-sagem role-request, aconteceu no mınino 69,8 e maximo 70,5 ms apos a falha. O tempode recebimento da mensagem role-reply significa a latencia total para o processo derecuperacao de falha, e ficou entre 70,5 e 73,8 ms. E importante salientar que a latenciadas trocas de mensagens entre o controlador e o switch foi baixa, ao contrario da deteccao,que tomou pelo menos 69,4 ms.


11

A operacao de migracao (Figura 2(b)) mostrou-se mais sensıvel a variacao dacarga de trafego devido a maior quantidade de troca de mensagens. Os tempos ficaramentre 3,8 ms quando nao havia trafego nos controladores, aumentou para 9,8 e chegoua 19,6 quando taxa era de 500 packet-in/s. Como o processamento de pacotes e feitono plano de controle, a taxa de packet-in influencia diretamente o tempo de resposta docontrolador.

(a) Latencia Recuperacao de Falha (b) Latencia Migracao

Figura 2. Ambiente experimental

4. Conclusoes e Trabalhos FuturosO objetivo do trabalho foi apresentar uma proposta para prover resiliencia no Plano deControle em SDN, e os resultados demonstram que as funcionalidades disponıveis no OF1.3 atendem plenamente os requisitos para construir sistemas com alta disponibilidade.Tambem percebemos o impacto que a variacao de trafego nos controladores causa aosprocessos de recuperacao de falha e migracao. Ficou claro que a carga dos controladores,no ambiente reproduzido, pode tornar a migracao bastante custosa.

Como trabalhos futuros, o projeto sera ampliado para suportar mais controladores,utilizar uma camada de persistencia externa e explorar caracterısticas de balanceamentode carga.

ReferenciasDixit, A., Hao, F., Mukherjee, S., Lakshman, T., and Kompella, R. (2013). Towards an

elastic distributed sdn controller. SIGCOMM Comput. Commun. Rev., 43(4):7–12.

Lantz, B., Heller, B., and McKeown, N. (2010). A network in a laptop: rapid prototypingfor software-defined networks. In Proceedings of the Ninth ACM SIGCOMM Workshopon Hot Topics in Networks, page 19. ACM.

McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G. M., Peterson, L. L., Rexford,J., Shenker, S., and Turner, J. S. (2008). Openflow: enabling innovation in campusnetworks. Computer Communication Review, 38(2):69–74.

ONF, O. N. F. (2011). Openflow switch specification version 1.2.0 (wire protocol 0x04).Website. https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.0.pdf.

RYU, P. T. (2014). Ryu sdn framework using openflow 1.3. Website. http://osrg.github.io/ryu-book/en/Ryubook.pdf.


12

Balanceamento de Carga em SDNProvido por Comutadores Estocasticos de Prateleira

Alextian Liberato1 2, Diego Mafioletti1, Eros Spalla1,Magnos Martinello1, Rodolfo Villaca1

1 Programa de Pos-Graduacao em Informatica (PPGI)Universidade Federal do Espırito Santo (UFES) – Vitoria, ES

2Grupo de Pesquisa em Informatica Aplicada – Departamento de InformaticaInstituto Federal do Espırito Santo (IFES) – Colatina, ES

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

[email protected], [email protected]

Abstract. The network load balancing allows you to share traffic in order toreduce congestion the links. Existing products make use of routing algorithmsthat have not been designed for local networks or require costly proprietary so-lutions. Our proposal presented in this paper reveals an open platform that useslow-cost hardware and SDN technology to make the stochastic load balancing.The results show a very satisfactory performance.

Resumo. O balanceamento de carga em rede permite dividir o trafego de modoa reduzir o congestionamento nos enlaces. Os produtos existentes fazem uso dealgoritmos de roteamento que nao foram projetados para redes locais ou exigemsolucoes proprietarias de alto custo. A proposta apresentada nesse artigo revelauma plataforma aberta que utiliza hardware de baixo custo e a tecnologia SDNpara realizar o balanceamento de carga estocastico. Os resultados apresentamum desempenho bastante satisfatorio.

1. IntroducaoAs Redes Definidas por Software (SDN - Software-Defined Networking) surgiram comoum promissor conceito para o projeto de novas arquiteturas para a Internet. SDN e umaproposta baseada na separacao dos planos de dados e de controle, em uma interfaceuniforme independente de fornecedor para o mecanismo de encaminhamento (ex: (OF)[McKeown et al. 2008]) e em um plano de controle logicamente centralizado.

O OpenFlow e um padrao aberto que permite a programacao dos elementos ativosda rede, tais como roteadores, switches ou pontos de acesso sem fio. Trata-se de umaproposta pragmatica com grande potencial para suportar o grau de programabilidade queas SDN necessitam.

Os equipamentos habilitados com Openflow tem sido projetados pelos fabri-cantes como um sistema fechado no qual o projetista de redes torna-se dependente daimplementacao do fabricante (e.g. RouterBoard Mikrotik). Se a inovacao do projetistarequer modificacao no plano de dados, por exemplo, encaminhar para uma porta comuma certa probabilidade, entao o equipamento nao permite tal operacao e impede suavalidacao experimental. Esses fatos limitam significativamente o potencial de inovacao


13

na arquitetura SDN, tanto pela restricao imposta pelo modelo de encaminhamento quantopelo sistema fechado pelo fabricante.

O balanceamento de carga em uma rede permite o encaminhamento do trafego pordiversos caminhos. No entanto, as solucoes proprietarias que implementam o balancea-mento de carga na rede apoiam-se em protocolos de roteamento (OSPF ou EIGRP) paraequilibrar a carga de trafego entre os switches da rede, o que gera uma enorme sobrecargade configuracao, alem de exigir equipamentos com custos elevados.

Nossa proposta neste trabalho, e utilizar equipamentos nao especializados de pra-teleira para demonstrar a viabilidade de habilitar o protocolo Openflow na sua versaomais recente, Openflow 1.3, permitindo assim que novas caracterısticas possam ser in-corporadas pelo projetista de rede. Como prova de conceito, projetamos um comu-tador estocastico com desempenho similar as plataformas fechadas, em um cenarioflexıvel utilizando nossa proposta de plataforma aberta. A plataforma foi projetadasobre o sistema operacional OpenWRT [OpenWRT 2014] com Open vSwitch (OvS)[Subramanian et al. 2009] compilado para os equipamentos RouterBoard RB2011UAS-IN, RB433 e RB450G.

O restante deste artigo esta organizado da seguinte forma: na Secao 2 sao apre-sentados os conceitos de tabela de grupos no OF 1.3 e a plataforma utilizada; na Secao 3sao apresentado os resultados experimentais; na Secao 4 e apresentada a conclusao e ostrabalhos futuros.

2. Plataforma Aberta em Equipamentos ReaisO projeto da plataforma aberta iniciou-se pela substituicao do sistema operacional ori-ginalmente RouterOS que suporta apenas OF 1.0 (Plataforma Fechada) pelo OpenWRT(Plataforma Aberta) que permite a instalacao dos switches virtuais (OvS e Softswitch13[CPqD 2014]) que suportam OF 1.3.

Na arquitetura do OpenFlow, o switch executa apenas a logica de encaminha-mento. A logica de controle e executada no controlador e a comunicacao entre elas se daatraves do protocolo OpenFlow. Na recente versao do Openflow 1.3, uma determinadaentrada em uma tabela de fluxo pode apontar para um grupo constituıdo por entradaspreviamente definidas. O objetivo e estender o comportamento do switch para suportardiferentes metodos de encaminhamento, por exemplo tipos de grupos [ONF 2012].

Figura 1. Recurso de tabela de grupos OF 1.3 – metodo select

Na Figura 1 ilustramos o metodo Select, como um tipo de grupo com sua propriasemantica. Note que o valor do peso (“Weight”) que e atribuıdo ao fluxo determina a


14

probabilidade de execucao da respectiva acao. Existem ainda outros tres metodos, quenao serao discuticos nesse artigo: All que executa todos os buckets do grupo; Indirectque executa o bucket definido no grupo; e o Fast Failover que executa o primeiro bucket“vivo”.

O ambiente experimental utilizado esta descrito na Figura 2, sendo doisRB2011UAS-IN (S1 e S5), dois RB433 (S2 e S4) e um RB450G (S3). Para realizarum balanceamento de carga, modificamos o software do OvS para permitir o encaminha-mento dos pacotes de forma estocastica, alterando a funcao xlate select group no arquivo“ofproto-dpif-xlate.c”, de modo a gerar um numero aleatorio que representa a probabili-dade de escolha de um bucket. Essa probabilidade e usada para selecionar uma porta desaıda. Ja o Softswitch13 nao precisou ser alterado, pois ja possuıa o algoritmo weightedround-robin (WRR) implementado na funcao select from select group.

Figura 2. Topologia experimental

3. Balanceamento Estocastico

Avaliamos o balanceamento estocastico atraves da transmissao de dados (TCP) com aferramenta Iperf 3.0.3 entre h1 e h2 (Figura 2), inserindo no S1 a seguinte regra: 50% detodo trafego de h1 para h2 saira pela porta 4, devido ao enlace ser Gigabit Ethernet, 30%saira pela porta 3, menor caminho via Fast Ethernet, o restante 20% saira pela porta 2.

(a) Balanceamento estocastico no OvS (b) Balanceamento estocastico no Softswitch13

Figura 3. Balanceamento estocastico utilizando semantica select – OF 1.3


15

A Figura 3(a) apresenta o grafico do OvS com a utilizacao das portas no S1 du-rante o tempo de 60 segundos. Em virtude da aleatoriedade, a utilizacao das portas variaconsideravelmente. No entanto, na media, a escolha do bucket e respeitada conforme ospesos atribuıdos. No Softswitch13 (Figura 3(b)) o grafico e uniforme, caracterıstica doalgoritmo WRR presente na funcao de selecao do bucket, em contrapartida o desempenhomedio (Mbits) e inferior ao OvS.

Aferimos que no OvS sem o balanceador estocastico apresentou valor medio de122,48 Mbits/seg, contra 44 Mbits/seg com o select, e no Softswitch13 o valor medio foide 32,54 Mbits/seg contra 24,89 Mbits/seg com o select.

4. Conclusoes e Trabalhos FuturosA proposta do trabalho foi utilizar equipamentos nao especializados de prateleira parademonstrar a viabilidade de habilitar o protocolo Openflow na sua versao mais recenteOpenflow 1.3. A ideia e permitir que novas caracterısticas possam ser incorporadas livre-mente pelos projetistas de rede e customizaveis. Como prova de conceito, projetamos umcomutador estocastico com desempenho similar as plataformas fechadas.

Os resultados obtidos demonstram que existe um grande potencial no uso dosrecursos disponıveis no switches OpenFlow 1.3. A operacao de Select pode ser usadadinamicamente ajustando os pesos, e tambem tomar decisoes em nıvel de plano de dadossem a ajuda do controlador (de forma pro-ativa). A diferenca de desempenho, principal-mente no OvS, foi causada pela limitacao de processamento do hardware utilizado. Comotrabalhos futuros pretendemos modificar o OvS para usar o select em modo Kernel.

Agradecimentos: aos parceiros Christian Esteve Rothenberg (UNICAMP) e EderLeao Fernandes (CPqD) pelas orientacoes com o Softswitch13 e ao professor Ali Moham-mad Salahuddin (Western Michigan University) no OvS.

ReferenciasCPqD, F. (2014). Openflow 1.3 software switch. Website. https://github.com/CPqD/ofsoftswitch13.

McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G. M., Peterson, L. L., Rexford,J., Shenker, S., and Turner, J. S. (2008). Openflow: enabling innovation in campusnetworks. Computer Communication Review, 38(2):69–74.

ONF, O. N. F. (2012). Openflow switch specification version 1.3.0 (wire protocol 0x04).Website. https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.0.pdf.

OpenWRT (2014). Openwrt. Website. "http://www.openwrt.org".

Subramanian, L., Leland, W. E., and Mahajan, R., editors (2009). Eight ACM Workshopon Hot Topics in Networks (HotNets-VIII), HOTNETS ’09, New York City, NY, USA,October 22-23, 2009. ACM SIGCOMM.


16

Analise e Gerenciamento de Rede atraves de Grafos em RedesDefinidas por Software

Gustavo Pantuza, Frederico Sampaio, Luiz F M Vieira,Dorgival Guedes, Marcos A M Vieira

1Departamento de Ciencia da ComputacaoUniversidade Federal de Minas Gerais

{pantuza,fredmbs,lfvieira,dorgival,mmvieira}@dcc.ufmg.br

Abstract. Software Defined Networking (SDN) is an emergent architecture thatis dynamic, flexible, manageable and with low cost, consistent with the dyna-mics of the modern applications. This paper presents a network representationmodel using a graph through the control plane of a SDN controller. The graphaproach provides a global view of the network in real time and consistency. Theexperiments show that the graph is a reliable representation of the real networkeasing the management in Software Defined Networking.Key Words: SDN, Graph, Network Management, OpenFlow, POX.

Resumo. As redes definidas por software (SDN) representam uma arquiteturaemergente dinamica, flexıvel, gerenciavel e de baixo custo, condizente com adinamicidade das aplicacoes atuais. Esse trabalho apresenta um modelo derepresentacao da rede em grafos atraves do plano de controle de um controladorSDN. Essa abordagem em grafos fornece uma visao global da rede em temporeal e com consistencia. Os experimentos demonstram que o grafo propostorepresenta de maneira fiel o estado da rede facilitando o gerenciamento emRedes Definidas por Software.Palavras Chave: SDN, Grafos, Gerenciamento de redes, OpenFlow, POX.

1. IntroducaoUma caracterıstica em comum em quase todas as aplicacoes em SDN e a necessidade deuma “visao” topologica da rede. Grafos representam a topologia de uma rede de formadireta, natural e precisa. Por isso, a descricao da rede em forma de grafos e um ele-mento comum em diversos dos principais trabalhos, protocolos e softwares de rede, in-clusive os elaborados para SDN, como (Martın Casado 2010), Network Information Base,(Ramya Raghavendra 2012).

Este artigo apresenta as seguintes contribuicoes. Primeiro, descrevemos um sis-tema para o gerenciamento de redes. As redes sao representadas por grafos. Os grafossao dinamicos, em tempo real e contem estatısticas da rede. Este sistema e compatıvelcom o padrao OpenFlow, um dos protocolos para Rede Definidas por Software. Depois,validamos o nosso sistema com experimentos.

2. Projeto2.1. Modelagem do grafoO grafo proposto e representado por G = (V,A), no qual V e A sao os conjuntos devertices e arestas, respectivamente. V e A, sao finitos. Cada vertice v ∈ V pode repre-


17

sentar um host ou um switch na rede. Cada aresta u → v ∈ A representa um link entredois vertices. As arestas possuem um peso g(u, v) que descreve o volume de trafego embytes recebidos e transmitidos atraves da aresta/link. Cada vertice e um objeto das classesHost ou Switch. O peso das arestas e obtido atraves da leitura dos contadores de fluxospresentes nos switches openflow.

2.2. Interface de programacao (API)O graph possui uma interface (API) para que outros modulos do controlodor possamrequisitar informacoes da topologia da rede.

Os Metodos com dados do grafo sao:• get vertex(id): Retorna uma entidade do grafo identificada (host/switch).• get adjacents(id): Retorna a lista de adjascencia de um vertice.• snapshot(): Copia do grafo, em forma de duas colecoes(vertices e arestas).• to dot(harq, layout = ”dot”): Copia do grafo para o Graphviz (Ellson et al. 2003).• get mst(): Retorna uma arvore geradora mınima do grafo (MST)em tempo real.

3. ExperimentosConsidere-se uma rede com uma topologia simples em que tem-se dois switches. Cadaswitch possui 3 hosts. Existe uma aresta link entre os dois switches. Uma instancia docontrolador POX controla os dois switches. Essa topologia foi configurada atraves domininet (Lantz et al. 2010). O mininet permite a criacao de scripts que geram topologiasna rede simulada.

3.1. Deteccao de entidadesO sistema inicia o grafo da rede vazio. Os switches sao os primeiros a serem identificados.Como o controlador esta ligado diretamente a eles pela interface OpenFlow, um eventode ConnectionUp e disparado pelo nucleo do controlador.

1 INFO:topology.graph:SwitchJoin id: 22 INFO:topology.graph:SwitchJoin id: 13 INFO:topology.graph:1, 24 DEBUG:openflow.discovery:Dropping LLDP packet 2755 INFO:topology.graph:LinkEvent fired6 INFO:host_tracker:Learned 1 1 7e:e6:9b:89:39:2e got IP 10.0.0.17 INFO:topology.graph:HostJoin id: 7e:e6:9b:89:39:2e8 INFO:host_tracker:Learned 2 1 62:77:44:24:13:49 got IP 10.0.0.29 INFO:topology.graph:HostJoin id: 62:77:44:24:13:49

Figura 1. Deteccao de entidades

Nas duas primeiras linhas do log mostrado na figura 1, o modulo graph foi noti-ficado da descoberta de dois switches na rede. Assim, dois vertices do tipo switch foramreferenciados no grafo. Na linha 5, nota-se que a descoberta de um link (entre switches).O modulo openflow.discovery, atraves do protocolo LLDP identificou o link entre swit-ches. As linhas 7 e 9 mostram a descoberta de dois hosts. Esses hosts foram descobertospelo modulo host tracker via escuta dos eventos de DHCP. Um novo pacote que passa porum switch e nao possui regra instalada na tabela de fluxos e encaminhado ao controladorque dispara um evento de PacketIn e identifica as entidades de hosts e switches. Dessaforma as entidades da rede sao identificadas e computadas no grafo.


18

3.2. Remocao de entidadesAo remover um host o host tracker, apos um tempo fixo (timerInterval), verifica via ARPPing se o host esta ativo. No teste executado, apos 30 segundos o host tracker identificoua inatividade do host e disparou o evento de HostLeave, atualizando assim o grafo. Aoremover um Switch, o controlador dispara um evento de SwitchLeave ao qual o modulograph esta inscrito. Logo, o grafo e atualizado removendo o vertice do switch e dos hostsligados a ele.

3.3. Visualizacao em tempo real da redeNa figura 2 e apresentado parte do grafo de uma rede com 8 switches, cada um com 30hosts conectados totalizando 248 entidades na rede. Esse grafo e atualizado em temporeal em funcao dos eventos de rede ocorridos dentro do controlador, como entrada e saıdade entidades, volume de trafego na rede entre outros citados nesta secao.

Figura 2. Grafo representando uma grande rede

3.4. Identificacao de trafego na redePara computar o trafego (TCP) na rede foi executado o programa iperf como servidor nohost ’Host 0a’ utilizando a topologia apresentada na figura 3. O host ’Host 1e’ conecta-secomo cliente. Conformo pode ser notado na figura 3, o trafego em bytes na arestas desseshosts e superior ao demais hosts. No momento em que foram lidos os contadores Open-Flow e computados os pesos das arestas, obteve-se um trafego de 55894 bytes atravesdo caminho entre os dois hosts citados. Os valores apresentados para os demais hosts(41 bytes) sao referentes ao trafego ARP PING disseminado pelo modulo host tracker Oexperimento com o iperf mostrou uma taxa de envio (throughput) entre os hosts de 300Mega bits por segundo.

3.5. Arvore Geradora MınimaUma arvore geradora mınima e mantida em tempo real sobre o grafo da rede. Quando ografo atualiza arestas/vertices a arvore geradora mınima e computada. Outros modulospodem utiliza-la atraves da API do modulo em grafos. Arvores geradoras mınimassao essenciais em diversas tarefas no gerenciamento de redes. Tarefas como dispa-rar ’alarmes’ quando a arvore estiver desconexa ou contenha loops, conforme mos-trado em (Schmid and Suomela 2013). E possıvel imaginar um sistema distribuıdo


19

Figura 3. Trafego TCP (em bytes) entre os hosts ’Host 1e’ e ’Host 0a’

que consulte a arvore para executar um algoritmo de propagacao de mensagem flood(Monsanto et al. 2013).

4. ConclusaoO presente trabalho apresentou o uso de grafos no contexto de SDN. Um grafo da rede emtempo real vai de encontro com uma das principais vantagens em se desacoplar o planode controle do plano de dados que e obter uma visao global da rede. Notou-se que osistema mantem um estado fiel, consistente e dinamico da rede real, facilitando a tarefade gerenciamento de um rede definida por software.

Referencias[Ellson et al. 2003] Ellson, J., Gansner, E. R., Koutsofios, E., North, S. C., and Woodhull,

G. (2003). Graphviz and dynagraph – static and dynamic graph drawing tools. InGRAPH DRAWING SOFTWARE, pages 127–148. Springer-Verlag.

[Lantz et al. 2010] Lantz, B., Heller, B., and McKeown, N. (2010). A network in a lap-top: Rapid prototyping for software-defined networks. In Proceedings of the 9th ACMSIGCOMM Workshop on Hot Topics in Networks, Hotnets-IX, pages 19:1–19:6, NewYork, NY, USA. ACM.

[Martın Casado 2010] Martın Casado, Teemu Koponen, R. R. S. S. (2010). Virtualizingthe Network Forwarding Plane. ACM.

[Monsanto et al. 2013] Monsanto, C., Reich, J., Foster, N., Rexford, J., and Walker, D.(2013). Composing software-defined networks. In Proceedings of the 10th USENIXconference on Networked Systems Design and Implementation, nsdi’13, pages 1–14,Berkeley, CA, USA. USENIX Association.

[Ramya Raghavendra 2012] Ramya Raghavendra, Jorge Lobo, K.-W. L. (2012). Dy-namic Graph Query Primitives for SDN-based Cloud Network Management.HotSDN’12.

[Schmid and Suomela 2013] Schmid, S. and Suomela, J. (2013). Exploiting locality indistributed sdn control. In Proceedings of the Second ACM SIGCOMM Workshop onHot Topics in Software Defined Networking, HotSDN ’13, pages 121–126, New York,NY, USA. ACM.


20

Quality-oriented Mobility Control Architecture for ETArchHandover Optimization

Felipe Silva1,2, Jose Castillo-Lema2, Augusto Neto2, Flavio Silva3, Pedro Frosi3,Daniel Corujo4, Carlos Guimaraes4, Rui Aguiar4

1Federal Institute of Rio Grande do Norte (IFRN) – Joao Camara-RN, Brazil

2Informatics and Applied Mathematics Department (DIMAp) – Federal University ofRio Grande do Norte (UFRN) – Natal-RN, Brazil

3Faculty of Computing, Federal University of Uberlandia (UFU) – Uberlandia-MG, Brazil

4Instituto de Telecomunicacoes de Aveiro (ITAV) – Aveiro, Portugal

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

{flavio,frosi}@facom.ufu.br, {dcorujo,cguimaraes,ruilaa}@av.it.pt

Abstract. This paper presents a work in progress focused on improve the CleanSlate Future Internet Entity Title Architecture (ETArch) with quality-orientedmobility functions, by deploying mobility prediction, Point of Attachment (PoA)decision and handover setup meeting both session quality requirements and cur-rent quality wireless conditions.

1. IntroductionAmong the initiatives to enhance the Internet of today, known as Future Internet (FI),the Entity Title Architecture (ETArch) [Silva et al. 2012] is a promising FI clean-slatearchitecture that employs a new naming and addressing scheme based on the Title, andshares the vision of content-oriented paradigms. It is a realization of the Entity TitleModel [Pereira et al. 2011], and consists of a vision of how the entities should be ableto semantically specify their requirements and capabilities so that they can communicatewith each other. ETArch can inherently support mobile group-communication based onthe OpenFlow [McKeown et al. 2008] substrate within the Workspace, a channel that isable to gather two or more communicating participants.

ETArch has been recently enhanced with seamless mobility optimization controlcapabilities, by being integrated with enhancements inspired by the IEEE 802.21 Me-dia Independent Handover (MIH) Standard [Corujo et al. 2011]. As a result, despitebeing Media Independent in nature in terms of their ability to operate independentlyof the underlying access technology (both wired and wireless), the ETArch mobilitycontrol mechanisms [Silva et al. 2013], are currently only based on link layer features.Although the IEEE 802.21 Standard provides access to events associated with link qua-lity, (such as its ability to indicate the support and characteristics of differentiable Clas-ses of Service – CoS in the link, and minimum/maximum delay/jitter experience, amongother factors), the ETArch mobility control currently triggers the handover process solelyon the basis of the Received Signal Strength (RSS) of the candidate Points of Attach-ment (PoA), which will seriously restrict the scope of ETArch in future Internet scena-rios (More information about ETArch components and their relationship can be found in[Silva et al. 2013][Silva et al. 2012]).


21

The limitations described above justify our work in the sense that there is a needto extend the mobility support of legacy ETArch with quality-oriented mechanisms forboth prediction and handover control functions. In addition to the current RSS-basedscheme, we will make use of the flexible nature of the ETArch framework, and empowerits handover management scheme so that it can be applied not only to quality-orientedlink layer parameters, but also to high level (e.g., application and user) parameters forenhanced handover decisions. Thus, we seek to maintain best connectivity over time, andbe able to make decisions that go beyond those that are strictly guided by the motionevents of MN.

Due to space limitation this paper focuses in provide only an overview of our workin progress, describing our proposal to improve ETArch mobility issues. The remainderof the document is structured as follows: Section 2 provides an overview of our proposal.And Section 3 outlines the next stages of this work.

2. Proposal OverviewThe architecture presented in Fig. 1a represents the set of proposed extensions to theETArch Mobility Manager mechanism, named QoDM (Quality-oriented Decision Mana-ger) and consists of the following components:

(a) Proposed architecture (b) Fuzzification example

Figure 1. Proposed architecture and attribute fuzzification example

2.1. QAMC

QAMC (Quality Attribute Monitoring and Collector) is responsible for identifying themodification of parameters that indicates the occurrence of mobility or quality degrada-tion of current session and for obtaining the quality parameters of the entities. In caseof occurrence of the first event, the QAMC can start the handover process (System Dis-covery) by asking the MN to scan networks in their coverage area. Collected data (withpre-determined frequency) will be sent to FNQE, to enable the handover prediction basedon the quality of the active session.

2.2. QWCM

The QWCM (Quality Weight CoS Mapping) component is responsible to perform themapping for the CoS to which a particular session (affected by the events identified inQAMC) belongs, and thus, determine the importance weights of attributes, through theAHP method [Dhar et al. 2010].


22

2.3. Decision MakerThis component works intermediating the different requests for the decision function(E2BS) and quality estimation (FNQE) subcomponents of the architecture.

2.4. E2BSE2BS (Extended Elitism for Best Selection) is a handover decision method inspired in theElitist Selection Strategy [Engelbrecht 2007], combined with MADM (Multiple AttributeDecision Making) [Dhar et al. 2010] features to enable quality-oriented mobility decisi-ons efficiently. Its main goal is to meet both the quality requirements of active mobilesession flows and to match the current quality standards of neighbouring PoA candida-tes. The elitism strategy employed by E2BS is based on a multi-attribute evaluation of theQoS candidate networks. In our model, the population is represented by a set of PoAs andtheir attributes. This technique is used to select the PoA which offers the best connectioncriteria. Assessing the QoS offered by the various PoA to select the best one is carriedout by measuring the similarity between the attributes of the elite individual, representedby the reference PoA, and other candidates. The reference PoA is considered to be theone that have the ideal values, (i.e. attributes like delay and jitter should have values closeto zero). The following steps are required to perform the calculating of the score of thecandidate networks:

1. The QoS attributes of the candidate networks are joined to compose the decision matrix;2. Since the data value of the attributes is expressed in different formats, there is a need for

standardization;3. Traffic class weight assignment is applied according to the respective traffic classes;4. The final score is computed by calculating the Euclidean distance between the attributes

of the reference PoA and other candidates. The selected network is that which has thehighest final score;

2.5. FNQEFNQE (Fuzzy Network Quality Estimator) is a quality estimator that makes use of fuzzylogic to assess the quality of active sessions, enabling the handover in situations wherethere is no explicit mobility. To accomplish this, it will check if the quality level providedby the network meets the needs of the application.

FNQE consists of n inputs and 1 output, being n the amount of attributes infor-med by the application at the time of its registration in DTSA [Silva et al. 2012], and theoutput the quality indicator, that will alert about the need for handover, according to theapplication preferences.

During the registration at DTSA, the application should inform your communica-tion requirements, and through these data the FNQE will be able to model the fuzzificationsystem by means of the CoS to which the application belongs. Through this process, thecrisp input values will be represented by linguistic terms and associated with a given setaccording to their degree of membership, as shown in Fig. 1b, where delay is rated bythree linguistic terms: low, medium and high. Each term represents the thresholds forcertain application in its respective CoS.

The requirements of each attribute will, at first, go through the fuzzification pro-cess in order to identify which universe of discourse is associated to your needs. Then, the


23

QAMC will send to FNQE, with certain frequency, the data collected from the network tonew fuzzification. Thus, according to the degree of membership, new results will be gene-rated to be correlated in the inference process, where pre-defined rules for the respectiveCoS will be confronted with the linguistic terms which were derived from the previousstep. The result of this process, known as defuzzification, corresponds to the stage wherefuzzy values are converted to real numbers and are associated with the universe of dis-course of the application preferences, represented by: Desirable, Good, Tolerable, Weakand Poor. In the cases where the conditions offered by the network does not meet theexpectations of the applications, the FNQE will trigger the Decision Maker to start theSystem Discovery process.

3. Conclusion and Future WorksAlthough several studies have extensively explored the quality-oriented mobility controlfield, we believe that the benefits of our approach will contribute to compose a betterand efficient mobility mechanism into ETArch framework. Finally, there is still a lack ofstudies that explores the mobility prediction by quality conditions of active session (i.e. ifthe network can meet the quality requirements of the applications satisfactorily).

Whereas this work is still in progress, the next step is to integrate our proposalinto ETArch mobility manager mechanism and evaluate it at ETArch real testbed in orderto assess our mobility prediction model by session quality requirements.

ReferencesCorujo, D., Guimaraes, C., Santos, B., and Aguiar, R. L. (2011). Using an open-source

ieee 802.21 implementation for network-based localized mobility management. IEEECommunications Magazine, 49(9):114–123.

Dhar, S., Bera, R., and Ray, A. (2010). Design and simulation of vertical handover algo-rithm for vehicular communication. International Journal of Engineering Science andTechnology, 2(10):5509–5525.

Engelbrecht, A. P. (2007). Computational Intelligence: An Introduction. Wiley Pu-blishing, 2nd edition.

McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford,J., Shenker, S., and Turner, J. (2008). Openflow: Enabling innovation in campusnetworks. SIGCOMM Comput. Commun. Rev., 38(2):69–74.

Pereira, J. H. d. S., Silva, F. O., Filho, E. L., Kofuji, S. T., and Rosa, P. F. (2011). Titlemodel ontology for future internet networks. In Future Internet Assembly, volume6656 of Lecture Notes in Computer Science, pages 103–116. Springer.

Silva, F., Corujo, D., Guimaraes, C., de Souza Pereira, J. H., Rosa, P. F., Kofuji, S. T.,Neto, A., and Aguiar, R. (2013). Enabling Network Mobility by Using IEEE 802.21Integrated with the Entity Title Architecture. In IV WPEIF - 31o Simposio Brasileirode Redes de Computadores e Sistemas Distribuıdos, pages 24–34. SBC.

Silva, F. d. O., Goncalves, M., de Souza Pereira, J., Pasquini, R., Rosa, P., and Kofuji,S. (2012). On the analysis of multicast traffic over the entity title architecture. InNetworks (ICON), 2012 18th IEEE International Conference on, pages 30–35.


24

Enabling a Carrier Grade SDN by Using a Top-DownApproach

Flavio Silva1, Caio Ferreira2, Natal Neto1,2, Alex Mota2, Luiz Theodoro1,2,Joao Henrique de Souza Pereira2, Augusto Neto3, Pedro Frosi Rosa1

1Faculdade de Computacao (FACOM) – Universidade Federal de Uberlandia (UFU)Caixa Postal 593 – 38.400-902 – Uberlandia, MG – Brasil

2Algar Telecom - Uberlandia, MG – Brasil

3Dept. de Informatica e Matematica Aplicada (DIMAp) - Universidade Federal doRio Grande do Norte(UFRN) - Campus Lagoa Nova, Natal-RN - Brasil

{flavio,frosi}@facom.ufu.br, [email protected]

{caiocf,alex,lclaudio,joaohs}@algartelecom.com.br

[email protected]

Abstract. Software-Defined Networking (SDN) essentially decouples the hard-ware from the software that controls it. Currently, OpenFlow materializes someSDN abstractions and several OpenFlow controllers, based on different pro-gramming paradigms and architectures, are available. In this scenario, SDNcommunity is using a bottom-up approach in order to build a SDN control layerthat meets carrier grade requirements such as throughput, availability and scal-ability. Conversely, this work proposes a top-down approach for SDN controllerarchitecture that is integrated with a carrier grade service level execution envi-ronment, based on the JAIN SLEE specification. The proposed approach reusesa mature component model, already deployed, thus extending SDN based ser-vices by integrating OpenFlow with several network resources and communi-cation protocols providing a cross layer platform that can satisfy these telecomoperators requirements.

1. IntroductionSoftware-Defined Networking (SDN) [Open Networking Foundation 2012] essentiallydecouples the data plane from the control plane and provides a deep control of infrastruc-ture by abstracting it from the network applications, thus, enabling innovation. Currently,OpenFlow [McKeown et al. 2008] materializes some concepts of SDN.

However SDN come up with some research challenges [Sezer et al. 2013] to thescientific community. A key challenge is related with the controllers that should meetcarrier grade requirements [UNION 2006] that encompasses high availability, scalability,high performance, reliability, fault tolerance and manageability in order to foster the SDNadoption in mission critical environments, such as the ones handled by telecom operators.

Currently, several telecom operators have services [TeleStax 2013] deployed ontop of a mature platform, known as JAIN SLEE. The JAIN (Java APIs for Integrated Net-works) is a set of APIs dedicated to creating voice and data convergent services. The JAIN


25

SLEE (Service Logic Execution Environment) [Ferry and ODoherty 2008] is a compo-nent model that supports the deployment of event driven applications that requires carriergrade requirements [Gomez et al. 2009] [Femminella et al. 2011]. JAIN SLEE is avail-able as commercial products, such as Rhino [OpenCloud 2013], and also as open sourceplatform, such as Mobicents [MOBICENTS 2012].

At this moment, the SDN community is still in pursuit of a carrier grade SDNcontrol layer that is suitable for the demands of such environments. The current ef-forts related to this area uses a bottom-up approach, which consists of creating the con-trol layer components from scratch. Some examples of these ongoing efforts are theprojects OpenDaylight [OpenDaylight 2013] and ONOS (Open Network Operation Sys-tem) [ON.LAB 2013].

This work presents a contribution to this research area by using a top-down ap-proach, which differs from the efforts currently undertaken by the SDN community inrelation to this quest. This manner consists of constructing a control layer that reuses thecomponent model defined by JAIN SLEE.

This paper briefly presents, at Section 2, the JAIN SLEE component model and thecomponents created in order to integrate OpenFlow with the protocols used by telecom’svoice and data services. Section 3 presents the status of this work, concluding remarksand future work.

2. Carrier Grade SDN Control LayerThe work, presented here, is deployed on top of the Java APIs for Integrated Networks(JAIN). The goal of these APIs is to abstract the underlying network, so those servicescan be developed independently of network technology. This approach couples with SDNabstractions.

The main components of JAIN SLEE are presented at Figure 1. The compo-nent model consists of two different layers: the Application Layer that represents theservices which run at the JAIN SLEE Application Server and the Resource AdaptationLayer which abstracts underlaying protocol stacks and adapts them to the JAIN SLEEmodel.

At the Application Layer, the Service Build Blocks (SBB) contains the applicationand service logic. Each SBB can be composed of one or more children SBBs and theyare organized as a graph. A Service is a deployed and managed artifact which specifiesits root SBB and the default event delivery priority. A SBB registers to capture and fireevents. An Activity is a related stream of events, such as a phone call, that are capturedby SBBs entities. The state of these entities can be replicated in a clustered deployment.By using clustering, JAIN SLEE supports high availability and fault tolerance. In ourapproach, the services of the SDN Control Layer can be deployed as SBBs.

According to the JAIN SLEE specification, a Resource represents a system that isexternal to the JAIN SLEE. The Resource Adaptation layer (depicted at Figure 1) enablesseveral control plane protocols, currently used at the telecommunication protocol stackto plug in at the JAIN SLEE component model. The approach presented here uses anOpenFlow compliant adapter that integrates OpenFlow with JAIN SLEE and fosters thedevelopment of new services and applications that can exploit SDN benefits.


26

The figure also presents two resource adapters created through this work, one inorder to adapt the OpenFlow 1.0, the basis to our claims, and the other to integrate theIEEE 802.21 Media Independent Handover (MIH) [IEEE 2009] highlighting the flexibil-ity of the presented approach to accommodate other protocols and build new scenarios.

Figure 1. JAIN SLEE Architecture Main Components.

Considering all these features, JAIN SLEE is a platform suitable to handle carrier-grade throughput, latency and fault tolerance requirements over a general purpose ITinfrastructure [Gomez et al. 2009].

3. Concluding Remarks and Future WorkThis work proposes a new SDN controller architecture, which is integrated with a carriergrade service level execution environment, based on the JAIN SLEE specification. Sucharchitecture can abstract several different protocol stacks and provides a common compo-nent model where new services and applications could be deployed. JAIN SLEE currentimplementations are adopted and being used by several telecom operators worldwide.

The approach proposed here was applied and in order to couple JAIN SLEEwith SDN and an OpenFlow 1.0 resource adapter was created. Moreover, using theflexibility of the presented architecture, another resource adapter was created enablingthe use of both protocols in order to optimize handover between different networks[Guimaraes et al. 2014].

The carrier grade approach presented in this work is aligned with most currenttrends regarding a SDN control layer, but on the contrary of other proposals, it enablesan integration of the protocols that controls the network hardware, such as OpenFlow,with the ones the controls the applications, thus enabling new types of network services.Moreover, the extensible model can accommodate new protocols and future initiatives,thus preserving investments and becoming an interesting outcome that can be exploitedby telecom operators.

As future work, the proposed, and constructed, carrier grade SDN control layerwill be tested under different scenarios in order to demonstrate the fault tolerance andscalability. In addition, an OpenFlow 1.3 compliant resource adapter, based on the ONFOpenFlow driver (a.k.a. libfluid), will be deployed and plugged into the architecture.


27

The innovative approach presented under this work shows to the research com-munity a SDN control layer that is suitable to meet carrier grade requirements and is aviable alternative to bring SDN into the telecom infrastructure, capable of fostering SDNadoption by this industry.

References[Femminella et al. 2011] Femminella, M., Francescangeli, R., Maccherani, E., and Mona-

celli, L. (2011). Implementation and performance analysis of advanced IT servicesbased on open source JAIN SLEE. In 2011 IEEE 36th Conference on Local ComputerNetworks (LCN), pages 746–753.

[Ferry and ODoherty 2008] Ferry, D. and ODoherty, P. (2008). JAIN SLEE (JSLEE) 1.1specification, final release.

[Gomez et al. 2009] Gomez, M., Torres, E., Chamorro, J., Hernandez, T., and Mendez, E.(2009). On the integration and convergence of IN and IP mobile service infrastructures.In International Conference on Telecommunications, 2009. ICT ’09, pages 143–148.

[Guimaraes et al. 2014] Guimaraes, C., Corujo, D., de Oliveira Silva, F., Rosa, P. F., Au-gusto Jose Venancio Neto, P. D., and Aguiar, R. L. (2014). IEEE 802.21-enabled entitytitle architecture for handover optimization. In IEEE WCNC’14 Track 3 (Mobile andWireless Networks) (IEEE WCNC’14 Track 3 : NET), Istanbul, Turkey. Unpublished.

[IEEE 2009] IEEE (2009). IEEE standard for local and metropolitan area networks- part21: Media independent handover. IEEE Std 802.21-2008, pages c1 –301.

[McKeown et al. 2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peter-son, L., Rexford, J., Shenker, S., and Turner, J. (2008). OpenFlow: enabling innova-tion in campus networks. SIGCOMM Comput. Commun. Rev., 38(2):69–74. ACM ID:1355746.

[MOBICENTS 2012] MOBICENTS (2012). Mobicents JAIN SLEE.http://www.mobicents.org/slee/intro.html.

[ON.LAB 2013] ON.LAB (2013). ONOS - open network operating system.

[Open Networking Foundation 2012] Open Networking Foundation (2012). Software-defined networking: The new norm for networks.

[OpenCloud 2013] OpenCloud (2013). Rhino SLEE carrier grade system.

[OpenDaylight 2013] OpenDaylight (2013). OpenDaylight technical overview.

[Sezer et al. 2013] Sezer, S., Scott-Hayward, S., Chouhan, P., Fraser, B., Lake, D.,Finnegan, J., Viljoen, N., Miller, M., and Rao, N. (2013). Are we ready for SDN? im-plementation challenges for software-defined networks. IEEE Communications Mag-azine, 51(7):36–43.

[TeleStax 2013] TeleStax (2013). TeleStax – open source cloud communications - successstories.

[UNION 2006] UNION, I. T. (2006). The carrier grade open environment reference model.SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTO-COL ASPECTS AND NEXT-GENERATION NETWORKS. International Telecom-munication Union.


28


29

Índice por Autor

A

Abelém, A. ...........................................3

Aguiar, R. ...........................................21

B

Bahia, A................................................3

C

Castillo-Lema, J. ................................21

Corujo, D. ..........................................21

F

Ferreira, C.C. .....................................25

G

Guedes, D. ..........................................17

Guimarães, C. ....................................21

L

Liberato, A. ....................................9, 13

M

Mafioletti, D.R. ..............................9, 13

Martinello, M. ................................9, 13

Mendes, D. ...........................................3

Mota, A. .............................................25

N

Neto, A. ........................................21, 25

Neto, N. ..............................................25

P

Pantuza, G. .........................................17

Pereira, J.H.S. ....................................25

Pinheiro, B. ..........................................3

Pinheiro, R. ..........................................3

R

Rodrigues, J. ........................................3

Rosa, P.F. .....................................21, 25

S

Sampaio, F. ........................................17

Silva, Felipe .......................................21

Silva, Flávio .................................21, 25

Spalla, E. ........................................9, 13

T

Theodoro, L.C. ...................................25

V

Vieira, L.F.M. ....................................17

Vieira, M.A.M. ..................................17

Villaça, R. ......................................9, 13

Documents

V Workshop de Pesquisa Experimental da Internet do Futuro ... · Wagner Meira Junior (UFMG) ... Aline Maria Santos Andrade (UFBA) Daltro José Nunes ... 3Grupo de Pesquisa em Redes