Sociedade Brasileira de Computação (SBC)sbrc2011.facom.ufms.br/files/workshops/wpeif/wpeif.pdf · Luciano Paschoal Gaspary (UFRGS) Membros Institucionais . CEFET-CE, CEFET-PR, IME,

ANAIS

XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas

Distribuídos 30 de maio a 3 de junho de 2011

Campo Grande, MS

II Workshop de Pesquisa Experimental da Internet do

Futuro (WPEIF)

Editora Sociedade Brasileira de Computação (SBC)

Organizadores

Marcos Rogério Salvador (CPqD) Michael Stanton (RNP/UFF) Fábio Moreira Costa (UFG)

Ronaldo Alves Ferreira (UFMS)

Realização Faculdade de Computação

Universidade Federal de Mato Grosso do Sul (UFMS)

Promoção Sociedade Brasileira de Computação (SBC)

Laboratório Nacional de Redes de Computadores (LARC)

ii Anais

Copyright © 2011 da Sociedade Brasileira de Computação Todos os direitos reservados Capa: Venise Melo Produção Editorial: Lucilene Vilela Gonçalves, Ronaldo Alves Ferreira Cópias Adicionais: Sociedade Brasileira de Computação (SBC) 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] Dados Internacionais de Catalogação na Publicação (CIP)

Workshop de Pesquisa Experimental da Internet do Futuro (2.: 2011 : Campo Grande, MS).

Anais / II Workshop de Pesquisa Experimental da Internet do Futuro; organizadores

Marcos Rogério Salvador... et al. – Porto Alegre : SBC, c2011. 48 p. ISSN 2177-496X 1. Redes de computadores. 2. Sistemas distribuídos. I. Salvador, Marcos Rogério. II.

Título.

II Workshop de Pesquisa Experimental da Internet do Futuro iii

Promoção Sociedade Brasileira de Computação (SBC) Diretoria Presidente José Carlos Maldonado (USP) Vice-Presidente Marcelo Walter (UFRGS) Diretor Administrativo Luciano Paschoal Gaspary (UFRGS) Diretor de Finanças Paulo Cesar Masiero (USP) Diretor de Eventos e Comissões Especiais Lisandro Zambenedetti Granville (UFRGS) Diretora de Educação Mirella Moura Moro (UFMG) Diretora de Publicações Karin Breitman (PUC-Rio) Diretora de Planejamento e Programas Especiais Ana Carolina Salgado (UFPE) Diretora de Secretarias Regionais Thais Vasconcelos Batista (UFRN) Diretor de Divulgação e Marketing Altigran Soares da Silva (UFAM) Diretor de Regulamentação da Profissão Ricardo de Oliveira Anido (UNICAMP) Diretor de Eventos Especiais Carlos Eduardo Ferreira (USP) Diretor de Cooperação com Sociedades Científicas Marcelo Walter (UFRGS)

iv Anais

Promoção Conselho Mandato 2009-2013 Virgílio Almeida (UFMG) Flávio Rech Wagner (UFRGS) Silvio Romero de Lemos Meira (UFPE) Itana Maria de Souza Gimenes (UEM) Jacques Wainer (UNICAMP) Mandato 2007-2011 Cláudia Maria Bauzer Medeiros (UNICAMP) Roberto da Silva Bigonha (UFMG) Cláudio Leonardo Lucchesi (UFMS) Daltro José Nunes (UFRGS) André Ponce de Leon F. de Carvalho (USP) Suplentes – Mandato 2009-2011 Geraldo B. Xexeo (UFRJ) Taisy Silva Weber (UFRGS) Marta Lima de Queiroz Mattoso (UFRJ) Raul Sidnei Wazlawick (PUCRS) Renata Vieira (PUCRS) Laboratório Nacional de Redes de Computadores (LARC) Diretoria Diretor do Conselho Técnico-Científico Artur Ziviani (LNCC) Diretor Executivo Célio Vinicius Neves de Albuquerque (UFF) Vice-Diretora do Conselho Técnico-Científico Flávia Coimbra Delicato (UFRN) Vice-Diretor Executivo Luciano Paschoal Gaspary (UFRGS) Membros Institucionais CEFET-CE, CEFET-PR, IME, INPE/MCT, LNCC, PUCPR, PUC-RIO, SESU/MEC, UECEM UERJ, UFAM, UFBA, UFC, UFCG, UFES, UFF, UFMG, UFMS, UFPA, UFPB, UFPE, UFPR, UFRGS, UFRJ, UFRN, UFSC, UFSCAR, UNICAMP, UNIFACS, USP

II Workshop de Pesquisa Experimental da Internet do Futuro v

Realização Comitê de Organização Coordenação Geral Ronaldo Alves Ferreira (UFMS) Coordenação do Comitê de Programa Artur Ziviani (LNCC) Bruno Schulze (LNCC) Coordenação de Palestras e Tutoriais Nelson Luis Saldanha da Fonseca (UNICAMP) Coordenação de Painéis e Debates José Augusto Suruagy Monteiro (UNIFACS) Coordenação de Minicursos Fabíola Gonçalves Pereira Greve (UFBA) Coordenação de Workshops Fábio Moreira Costa (UFG) Coordenação do Salão de Ferramentas Luis Carlos Erpen De Bona (UFPR) Comitê Consultivo Antônio Jorge Gomes Abelém (UFPA) Carlos André Guimarães Ferraz (UFPE) Francisco Vilar Brasileiro (UFCG) Lisandro Zambenedetti Granville (UFRGS) Luci Pirmez (UFRJ) Luciano Paschoal Gaspary (UFRGS) Marinho Pilla Barcellos (UFRGS) Paulo André da Silva Gonçalves (UFPE) Thais Vasconcelos Batista (UFRN)

vi Anais

Realização Organização Local Brivaldo Alves da Silva Jr. (UFMS) Edson Norberto Cáceres (UFMS) Eduardo Carlos Souza Martins (UFMS/POP-MS) Hana Karina Sales Rubinstejn (UFMS) Irineu Sotoma (UFMS) Kátia Mara França (UFMS) Luciano Gonda (UFMS) Lucilene Vilela Gonçalves (POP-MS) Márcio Aparecido Inácio da Silva (UFMS) Marcos Paulo Moro (UFGD) Massashi Emilson Oshiro (POP-MS) Nalvo Franco de Almeida Jr. (UFMS) Péricles Christian Moraes Lopes (UFMS) Renato Porfírio Ishii (UFMS)

II Workshop de Pesquisa Experimental da Internet do Futuro vii

Mensagem do Coordenador Geral Sejam bem-vindos ao XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC 2011) em Campo Grande, MS. É um prazer e uma distinção organizar um simpósio de tamanha relevância para a Computação no Brasil, mais ainda por ser a primeira vez que a Região Centro-Oeste tem o privilégio de sediá-lo. O SBRC é um evento anual promovido pela Sociedade Brasileira de Computação (SBC) e pelo Laboratório Nacional de Redes de Computadores (LARC). Ao longo dos seus quase trinta anos, o SBRC tornou-se o mais importante evento científico nacional em Redes de Computadores e Sistemas Distribuídos e um dos maiores da área de Informática no país. O SBRC 2011 está com uma programação bastante rica, de qualidade diferenciada e que consiste em: 18 sessões técnicas de artigos completos que abordam o que há de mais novo nas áreas de redes de computadores e sistemas distribuídos; três sessões técnicas para apresentação de ferramentas selecionadas para o Salão de Ferramentas; cinco minicursos, com quatro horas de duração, sobre temas atuais; três palestras e três tutoriais com pesquisadores de alto prestígio internacional; e três painéis sobre assuntos de interesse da comunidade. Além dessas já tradicionais atividades do simpósio, ocorrerão em paralelo oito workshops: XVI Workshop de Gerência e Operação de Redes e Serviços (WGRS), XII Workshop da Rede Nacional de Ensino e Pesquisa (WRNP), XII Workshop de Testes e Tolerância a Falhas (WTF), IX Workshop em Clouds, Grids e Aplicações (WCGA), VII Workshop de Redes Dinâmicas e Sistemas P2P (WP2P), II Workshop de Pesquisa Experimental da Internet do Futuro (WPEIF), I Workshop on Autonomic Distributed Systems (WoSIDA) e I Workshop de Redes de Acesso em Banda Larga (WRA). O desafio de organizar um evento como o SBRC só pode ser cumprido com a ajuda de um grupo especial. Eu tive a f elicidade de contar com a co laboração de inúmeras pessoas ao longo desta jornada. Meus sinceros agradecimentos aos membros dos Comitês de Organização Geral e Local por realizarem um trabalho de excelente qualidade e com muita eficiência, a qualidade da programação deste simpósio é fruto do trabalho dedicado dessas pessoas. Sou grato a Faculdade de Computação da UFMS por ter sido uma facilitadora ao longo de todo o processo de organização, desde a nossa proposta inicial até o fechamento da programação. Gostaria de agradecer, também, ao Comitê Gestor da Internet no Brasil (CGI.br), às agências governamentais de fomento e aos patrocinadores por reconhecerem a importância do S BRC e investirem recursos financeiros fundamentais para a realização do evento. Com o apoio financeiro recebido, foi possível manter os custos de inscrição baixos e oferecer um programa social de alta qualidade. Em nome do Comitê Organizador, agradeço a todos os participantes pela presença em mais esta edição do SBRC e d esejo uma semana produtiva, agradável e com estabelecimento de novas parcerias e amizades.

Ronaldo Alves Ferreira Coordenador Geral do SBRC 2011

viii Anais

Mensagem do Coordenador de Workshops do SBRC 2011 Os workshops são uma parte tradicional do que hoje faz do SBRC o principal evento da área no país, sendo responsáveis por atrair uma parcela cada vez mais expressiva de participantes para o S impósio todos os anos. O SBRC 2011 pr ocurou manter essa tradição, com a realização de workshops já considerados parte do circuito nacional de divulgação científica nas várias subáreas de Redes de Computadores e S istemas Distribuídos, como o WTF (Workshop de Testes e Tolerância a Falhas), o W CGA (Workshop em Clouds, Grids e Aplicações), o WGRS ( Workshop de Gerência e Operação de Redes e Serviços) e o WP2P (Workshop de Redes Dinâmicas e Sistemas P2P). Incluímos também nesta lista de iniciativas bem sucedidas o WRNP (Workshop da Rede Nacional de Ensino e Pesquisa), que cumpre o importantíssimo papel de fazer a ponte entre as comunidades técnica e científica da área. Como novidade em 2011, e reconhecendo o s urgimento e o fortalecimento de novas linhas de pesquisa de expressiva importância dentro da comunidade brasileira de Redes e Sistemas Distribuídos, procuramos incentivar a criação de novos workshops dentro do Simpósio. Foi com esse intuito que introduzimos pela primeira vez no SBRC a chamada aberta de workshops, por meio da qual membros da comunidade foram convidados a submeter propostas de workshops inéditos para realização em conjunto com o S BRC 2011. Em resposta à chamada, recebemos nove propostas de alta qualidade, das quais oito foram aceitas e seus respectivos proponentes convidados a organizarem os workshops no SBRC em Campo Grande. Das oito propostas aceitas, cinco tratavam dos workshops já tradicionais acima mencionados, e uma referia-se à segunda edição de um workshop mais recentemente criado, mas que teve sua primeira edição realizada de forma muito bem sucedida no S BRC 2010, o WPEIF (Workshop de Pesquisa Experimental da Internet do Futuro). As outras duas propostas foram resultado direto da chamada aberta de workshops e resultaram na adição de dois novos eventos ao leque do SBRC, o WRA (Workshop de Redes de Acesso em Banda Larga) e o W oSiDA (Workshop on Autonomic Distributed Systems), ambos com ótima aceitação pela comunidade, a julgar pelos números de submissões de trabalhos recebidos. Esperamos que 2011 s eja mais um ano de sucesso para os workshops do S BRC, em particular para aqueles criados nesta edição do Simpósio, e para que eles continuem contribuindo como importantes fatores de agregação para os avanços promovidos pela comunidade científica da área de Redes e Sistemas Distribuídos no Brasil. Aproveitamos para agradecer o i nestimável apoio recebido de diversos membros da comunidade e, em particular, da Organização Geral do SBRC 2011. A todos, um excelente SBRC em Campo Grande!

Fábio M. Costa Coordenador de Workshops do SBRC 2011

II Workshop de Pesquisa Experimental da Internet do Futuro ix

Mensagem dos Coordenadores do WPEIF A Internet cresceu e evoluiu muito desde suas origens em 1969, t ransformando a sociedade, as economias, os negócios. 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 t ecnologias para a Internet do Futuro, a partir de abordagens tanto evolutiva quanto revolucionária. O WPEIF é uma tentativa de chamar este tema à atenção da comunidade brasileira de redes de computadores e sistemas distribuídos, de discutir uma agenda de pesquisa e desenvolvimento para o país em assuntos relacionados, e de promover articulações nacionais e internacionais para explorar de forma sinérgica as oportunidades científicas e tecnológicas inéditas que o tema oferece ao país. Além de incluir quatro sessões técnicas, a programação do WPEIF II se encerra com um painel onde serão debatidas as ações realizadas e os avanços obtidos pela comunidade nos últimos doze meses desde o WPEIF I, bem como propostas de novas ações e articulações nacionais e internacionais. Em duas das sessões técnicas serão apresentados os oito artigos selecionados em chamada aberta, que tratam de propostas e resultados preliminares de pesquisa científica e tecnológica obtidos em projetos isolados. As outras duas sessões técnicas terão caráter mais informativo e serão baseadas em apresentações convidadas, dando uma visão geral de algumas iniciativas européias bem sucedidas e, em particular, das duas propostas de projeto em temas relacionados à Internet do Futuro que foram selecionadas para financiamento através das chamadas coordenadas Brasil-Europa em TIC realizadas conjuntamente pelo CNPq, pelo lado brasileiro, e pela Comissão Européia, pelo lado europeu. Gostaríamos de agradecer aos autores pelo interesse no evento e p ela qualidade dos trabalhos submetidos, aos membros do comitê técnico de programa pela qualidade das revisões e ao coordenador de workshops e ao coordenador geral do SBRC pela confiança em nós depositada e pelo apoio na organização do WPEIF.

Marcos Rogério Salvador Michael Anthony Stanton

Coordenadores do WPEIF 2011

x Anais

Comitê de Programa do WPEIF Antonio Jorge Gomes 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) Mauricio Ferreira Magalhães (FEEC/UNICAMP)

II Workshop de Pesquisa Experimental da Internet do Futuro xi

Revisores do WPEIF Antonio Jorge Gomes 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) Mauricio Ferreira Magalhães (FEEC/UNICAMP)

xii Anais

II Workshop de Pesquisa Experimental da Internet do Futuro xiii

Sumário

Sessão Técnica 1 – Artigos Selecionados I .................................................................... 1

A Survey with Owners and Users of Experimental Facilities Aimed at Applications on Future Internet Alessandro Santiago dos Santos (IPT), Franck Le Gall, Marianne Baumberger (Inno Group TSD), Mario Yoshikazu Miyake (IPT) e Rao Sathya (ETSI) ............................. 3

Experiments with a Self-Management System for Virtual Networks Carlos R. Senna, Daniel M. Batista, Milton A. Soares Junior, Edmundo R. M. Madeira e Nelson L. S. da Fonseca (UNICAMP) ......................................................... 7

A Monitoring Framework for the FIBRE Project Marcelo Machado de Pinheiro e José Augusto Suruagy Monteiro (UNIFACS) ........ 11

Implementação de um Novo Datapath OpenFlow em Ambientes de Switches Legados Fernando N. N. Farias, João J. Salvatti, José M. Dias, Hugo S. Toda, Eduardo Cerqueira e Antônio J. G. Abelém (UFPA) ................................................................ 15

Sessão Técnica 2 – Artigos Selecionados II ................................................................ 19

CMFLOW: Uma Extensão do Protocolo OpenFlow para Criação de Circuitos em Redes Multicamadas João J. Salvatti, Fernando N. N. Farias, José M. Dias, Hugo S. Toda, Eduardo Cerqueira e Antônio J. G. Abelém (UFPA) ................................................................ 21

The RouteFlow Approach to IP Routing Services on Software-Defined Networks Marcelo R. Nascimento, Christian E. Rothenberg, Marcos R. Salvador (Fundação CPqD), Maurício F. Magalhães (UNICAMP), Carlos N. A. Corrêa e Sidney C. de Lucena (UNIRIO) ....................................................................................................... 25

Estratégias de Seleção de Nodos no PlanetLab para Execução de Experimentos Thiago Garrett, Elias P. Duarte Jr. e Luis C. E. Bona (UFPR) ................................. 29

Domain Title Service for Future Internet Networks Flávio de O. Silva, João H. S. Pereira, Sérgio T. Kofuji (USP) e Pedro Frosi Rosa (UFU) .......................................................................................................................... 33

Sessão Técnica 3 – Artigos Convidados I ................................................................... 37

Can We Build a Testbed to Explore the Futures of the Internet Serge Fdida (University Pierre & Marie Curie) ........................................................ 39

Research and Experimentation Facilities for Implementing and Evaluating Wireless Networks Thanasis Korakis (University of Thessaly and Polytechnic Institute of NYU) ........... 41

SecFuNet – Security for Future Networks Djamel F. H. Sadok (UFPE) ....................................................................................... 43

Sessão Técnica 4 – Artigos Convidados II .................................................................. 45

FIBRE – Future Internet Testbeds/Experimentation Between Brazil and Europe Antônio J. G. Abelém (UFPA) .................................................................................... 47

Índice por Autor ........................................................................................................... 48

II Workshop de Pesquisa Experimental da Internet do Futuro

♦ Sessão Técnica 1

Artigos Selecionados I

A survey with owners and users of Experimental Facilitiesaimed at applications on Future Internet

Alessandro Santiago dos Santos1 , Franck Le Gall2 , Marianne Baumberger2,Mario Yoshikazu Miyake1 , Rao Sathya3

1Instituto de Pesquisa Tecnologicas do Estado de Sao Paulo (IPT)CEP: 055032–55 – Sao Paulo – SP – Brazil

2Inno Group TSD (Inno)Place Joseph Bermond – Ophira 1 – BP 63 06902 Sophia–Antipolis – France

3Intitut Europeen Des Normes de Telecommunication (ETSI)Sophia–Antipolis – France

{alesan,mymiyake}@ipt.br, {f.le-gall,M.Baumberger}@inno-group.com, [email protected]

Abstract. FIRE initiative aims at creation of advanced experimental facilitiesto foster the Future Internet services. MyFire project conducted a survey tosketch a landscape of the present state of Experimental Facilities(EF) related toFuture Internet(FI). Survey results point to attention areas for research commu-nities and policy makers: need for more documentation and ease of use of EFs,education and support for the adoption of standardisation and interoperabilityof EFs, adequate business models for sustainability of EFs, improved pathwaysto transfer experimental research into innovative services open to the extendedcommunity.

1. IntroductionFuture Internet Research and Experimentation-FIRE [Commission 2008] initiative aimsto address current and future expectations that will be put on the future internet. TheFIRE experimental facility is aiming to become a major support instrument for mediumand long-term research on networks and services by industry and academia. The visionincludes a large scale experimental facility, with a broad range of advanced and inter-connected testbeds, which cover areas from network connectivity to the service architec-ture. These testbeds will be used for development as well as for proof of concept andpre-service trials. There is considerable interest in interoperation of different testbeds,leading to collaboration around the globe[Stanton 2010].

MyFIRE project[Myfire 2010] aims to develop efficient mechanisms of testbedprocesses to make them more effective and widely used, especially by standardized ap-proaches. To achieve these goals a mass consultation with the enlarged FIRE communityhas been built, to harvest details on Experimental Research Facility in the field of FI.This document shows the results of a worldwide survey to cover several aspects to FIREinitiatives.

2. Survey descriptionThe survey, conducted via web by MyFire project team members, was designed to collectquantitative data on several aspects from Future Internet.

II Workshop de Pesquisa Experimental da Internet do Futuro 3

Figura 1. worldwide survey

The web survey questionnaire has been distributed to a large number of peopleinvolved in ICT research(5.142), especially those who use or possess an experimentalresearch facility. MyFIRE project distributed the survey to representatives from variousgeographical areas, especially in European and BRIC countries. From a total of 439 retur-ned questionnaires(301 valid), the profile of respondents included 44% from Universitiesor Education Institutions, 24% from Private commercial organisations, 18% from Publicorganisations, and 14% from other origins. The Figure 1 shows the local coverage.

3. Survey Results and findingsThe data was collected on the following topics: 1) Researchers and users needs in termsof Experimental Research Facilities; 2) Research commercialization and the innovationpathway; 3)Socio-economic aspects; 4) Standardisation aspects.

3.1. Researchers and users needs

Most used EF services by respondents are experimental setup (57%), measurement andreporting (45,5%), training (44%), and testing methodology expertise (39%). EF aremostly set-up for internal experimentation: 61% of users use only internal EF and40% of providers opens their EF only to internal users. The main reason to use exter-nal EF is financial: 49% of users of external EF declare using external EF to reducetheir experimentation cost, and 31% to capture public fund. We noticed that resourcesor competencies reasons are also important: 44% of users of external EF declare usingexternal EF because they don’t have adequate facilities, and 23% because they have alack of internal expertise. The main reason for providers of EF to not open to externalusers is also financial: 32% of providers of EF opened only for internal users don’t ope-ned their EF because they don’t have financial interest in doing so. We noticed also a lackof knowledge from the providers on the potentialities and opportunities of openingtheir EF for external users. The main choices of criteria to select a specific EF are theavailability of information about it, the fit with user technical needs, and the ease of use.Existing EF available services need to be well advertised and documented so to beeasy to be found and use. Support for testbed federation mechanisms and standardisedmethods are not identified as important requirements for users. Users agree that testbeds

4 Anais

need to be well documented and easy to use. EF needs to be well documented to attractusers. To keep their users informed, providers of EF pass information through collabora-tive projects for more than 50%. And the most cited way to identify the relevant EF forusers is partnership. Thus collaborative projects are opportunities to access externalEF. The main reason to not use a FIRE facility is the lack of information about the FIREEFs, but for those who have used a FIRE EF, finding information about the EF is identifiedas a good experience. Information on FIRE EF exists but is difficult to find, mainlyfor new comers on Future Internet community. Overall, EFs are recognised as keytools of the Future Internet Research, because they increase reliability and quality ofresearch, and they increase visibility of the research team. In addition, users of EFsrecognised the efficiency of standardised methods to permit conformance and inte-roperability, and increase reliability of testing. And yet, use of standardised methodsmentioned were valued as of very low importance by users.

3.2. Research facility commercialization and the innovation pathwayAnother main topic for MyFIRE is the commercialization of research results. The ob-jective is to understand the innovation pathway, and the impact of use of EF in the inno-vation pathway. Forty two per cent (42%) of users of EFs commercialise innovation inInternet technologies. The typical time to market is 1 to 2 years. For more than halfof the respondents (59%), the innovation pathway is made within the research network.Other pathways use open source research communities (29%), transfer of research ideasto commercial companies through patents and spinoffs (28%), contributions to standardsand regulation organizations (26%), and direct transformation of research by commercialfirms into products and services (23%). Thus, without surprise, research networks arethe actors the most cited by users for the introduction of innovation into the Inter-net field. Commercial network operators and Internet platform operators are importantactors, too, in the innovation process. We note a correlation between the time to marketand the pathway to innovate: transfer through contribution to open source communitiesis the most short term time-scale with 96% declaring a time-scale under 2 years. On theother side, exploitation via spin-off or patents is logically the longest innovation pathway,with 42% declaring a time-scale longer than 2 years. To better exploit their research,users express a need for international coordination of research and policy. Dominance bya few large technology firms and difficulties in transferring research to industry areidentified as major bottlenecks for exploitation of research.

3.3. Socio–economic aspectsIn terms of usage cost of EF, the access is in general free of charge for internal EF(73%), and it is mostly a paying service when using external EF (56%). Pricing is madeagainst consumed resources: manpower (29%), technical (33%) or time (33%). The mo-del whereby you pay membership fees is not a business model used by EFs. In durationterms, the average time to gain access to EF is longer for external EF than internalEF. We also noticed that users run longer experiments in external EF than in internalEF. Seventy four (74%) of users think that the duration of experiments is adequate. Forthe unsatisfied users, two trends can be identified: users of internal EF consider the dura-tion too short but limited by the cost or time availability, while users of external EF thinkthat the time is too long and can be reduced. More than 90% quantify the efforts ne-eded to conduct their experiment. Planning of experiments is mostly based upon staff


efforts (69%). Running experiments often consume more time (33% of users) and humanresources (26% of users) than planned. Mechanisms for charging customers are rare:80 % of providers of EF for internal users said that they don’t charge for the use, andthis rate decrease to 55% for external users. For University and Education institutions,offer of commercial EF services are practically nonexistent (8% of EF providers); there isfunding in many cases by research project (50% of EF providers). Sustainability is nota priority for providers of facility: only 37% declared to have a business model for thesustainability of the EF. Finally, when we consider the long-term outlook, practically halfof providers declare continued funding from research projects (48%), and a third a shiftto commercialization of test and experimental activities (29%).

3.4. StandardisationStandardised approaches are rarely used by users of EF, either to specify or to validatetheir experiments. However, 70% of users think that using a standardised method fordescribing experiments is useful or very useful. This result is surprising, given that mostof the respondents either do not know or do not use standardized methods. This confirmsthe added value to support standards adoption, given that formal standardized methodshelp users to outsource testing and help operators of EF to offer services to external users.Sixty per cent (60%) of users do not participate in standardization activities. Indeed, usersneed technical support to understand standard development processes and participate instandardization activities.

4. ConclusionThe survey shows that EFs are mostly set-up for internal experimentation and providersopen their EFs having in mind internal users. Existing EFs available services need to bewell advertised and documented so to be easy to be found and used by the extended com-munity of researchers. Commercial use of EF is still in it’s infancy. Support for testbedfederation mechanisms and standardised methods, deemed to be essential to future inter-net applications, are not identified as essentials requirements for users, posing a questionfor policy makers on how to improve these aspects in future projects. The innovationpathway is made mostly within the research network. Researchers are mostly concernedwith academic objectives and lack expertise to bring experimental research results to themarket through patents or spinoffs. Finally, low priority of sustainability and the absenceof a business model pose a question mark on the continuity of present EFs, when thefunding of the projects ends.

ReferenciasEC (2008). Future internet research & experimentation – fire, available at

http://cordis.europa.eu/fp7/ict/fire/.

Myfire (2010). The project – myfire – from experiment to future internet, available athttp://www.my-fire.eu/.

R. Sathya, Franck Le Gall, M. B. (2011). D4.1: Landscape analysis report. Technicalreport, Myfire project.

Stanton, M. (2010). Future internet initiatives. In Anais / I Workshop de Pesquisa Experi-mental na Internet do Futuro, volume 1, page 35, Gramado, RS. Instituto de Informa-tica Universidade Federal do Rio Grande do Sul (UFRGS), SBC.

6 Anais

Experiments with a self-management system for

virtual networks

Carlos R. Senna, Daniel M. Batista, Milton A. Soares Junior, Edmundo R. M.

Madeira, and Nelson L. S. da Fonseca

Institute of Computing - University of Campinas (UNICAMP)

Av. Albert Einstein, 1251, 13083-852, Campinas, São Paulo, Brazil

{crsenna, batista, edmundo, nfonseca}@ic.unicamp.br, [email protected]

Abstract. This paper presents an agent-based platform to support the

development of a self-management system for the network architecture

proposed by the Horizon Project. The platform consists of a substrate network,

a software for creating virtual networks, and a set of agents that support

ontology to enable the development of a Piloting Plane. We also show the

prototype built to evaluate a simple ontology for the exchange of information

between agents. The self-management system proposed is an intermediary

between the control and management entities and the context of network and

services. The piloting concepts of the system are realised with the help of

multi-agents based on the Ginkgo System. Details about the testbed built to

evaluate the proposed system are also presented.

1. Introduction

Autonomic networks [Gaiti 2006] were proposed to deal with the problem of increasing

complexity of telecommunications. They represent a specific topic in the area of

autonomic computing [Kephart 2003], a term coined by IBM, intended to deal with

complexity by enabling systems to self-manage themselves. This concept is bio-inspired

by the autonomic nervous system that carries out the regulation of body in the face of

changes in the environment without a conscious control. In the scenario of networks,

simple tasks of configuration, optimization, disaster recovery, and security are achieved

by the network itself, leaving administrators free to more complex tasks such as setting

policies and goals. Nowadays it is also advocated the approach of pluralism of

architectures for the future Internet over the one-size-fits-all TCP/IP. The new approach

defines that network providers should be splitted into service and infrastructure

providers and proposes the use of virtualization. Users request network services from

the service providers, which instantiate virtual networks over the substrate provided by

the infrastructure providers. Each virtual network can have its own protocols and

configurations, in accordance with the objectives of the service running on it, and must

have isolation, i.e., the operation of virtual networks does not cause interference

among them, although they are on the same infrastructure.

The Horizon [Horizon 2011] project aims to define and validate a new network

architecture based on the principles of pluralism and the knowledge plane. To achieve

these objectives, it is necessary to have a piloting plane where the decisions are made.

This paper presents a self-management system proposed by us, which is within the

piloting plane, being an intermediary between the control and management entities and


the context of network and services. Our proposal is to apply concepts of autonomic

computing in a scenario of virtual networks through a multi-agent system.

2. Platform architecture

The platform consists of a network substrate, a set of software tools for creating on-

demand virtual networks, and a set of agent-based tools that support ontology to enable

the development of a Piloting Plane. The following subsections describe the main

components of the platform.

2.1 Testbed

Before deploying the proposed self-management system in a real network, it is

important to evaluate it in a controlled environment. Figure 1 illustrates the testbed built

with this objective.

Figure 1. The testbed.

The testbed contains two virtual networks (virtual network A and virtual

network B). Each virtual networks contains two virtual routers. The virtual routers are

located at the real hosts zeus and dionisio. To the virtual network A to be instantiated, it

is necessary to instantiate the virtual routers horizonzeusA, at the real host zeus, and

horizondionisioA, at the real host dionisio. Similar instantiations are needed to the

virtual network B. Virtual network A is created to interconnect hosts artemis and apolo

through a 2-hop virtual path. Similarly, virtual network B is created to interconnect

hosts nix and cronos. The 2-hop paths of each virtual network can be mapped on one of

two possible physical paths between the real hosts zeus and dionisio: an 100Mbps link

and an 1Gbps link. Initially the two virtual paths share the 100Mbps link.

2.2. Tools

The major tools used to build out testbed are qemu, KVM, libvirt and Ginkgo Platform.

The qemu is a processor emulator which can also be used as a virtualization platform.

The Kernel-based Virtual Machine (KVM) is a full virtualization hypervisor based on

the machine emulator qemu. KVM is a free software under the GPL and open-source,

and allows the use of external tools to control it, like libvirt. The libvirt is an API to

access the virtualization capabilities of Linux with support to a variety of hypervisors,

including qemu, KVM and Xen, and some virtualization products for other operating

systems. It allows local and remote management of virtual machines. With libvirt it is

8 Anais

possible that an agent uses the same code to request information regarding the

performance of a virtual link independent of the hypervisor running in the virtual

routers.

Ginkgo System [Ginkgo 2011] is an agent platform based on autonomic

networks. It has the building blocks for the development of a piloting system for

computer networks. The framework allows the creation of lightweight and portable

agents, which facilitates its implementation in heterogeneous environments: routers,

switches, hosts, wired, and wireless networks. The agents play the role of the autonomic

manager of autonomic computing. The platform allows to form clusters of agents in

neighborhoods. Neighbors exchange information and get a situated view of the network.

Thus, besides the local environment, the agent is aware of other network places. This

information is stored in the knowledge base that has an information model to facilitate

communication between agents. Other data repository is the policy file, which contains

application rules. With the environment and application knowledge, the multi-agent

system can provide to network the self-knowledge property. The sensing, cognition, and

acting of agents are realized by the behaviors. They feed the knowledge base, perceive

and predict threatening events, and perform changes on the managed elements. Agents

also have a dynamic planner that, with knowledge base information and the rules in the

policy file, changes parameters of the behaviors and controls the life cycle of the agent.

3. The multi-agent system and experiment

We implemented a multi-agent system within the testbed to perform the management of

virtual networks in context of the Horizon project. The aim of the experiment is to

change the mapping of virtual links over paths in the substrate network dynamically and

automatically, according to context changing. The resources being monitored are in the

virtual networks, not in the physical network. For example, the failure of a resource in

the data plane is monitored, which can lead to faults in the management system. In the

knowledge base, each network resource is an individual of the information model. Each

resource is controlled by a single agent and, therefore, each individual is unique in the

knowledge base even after the diffusion. In the information model, the links are

directed, i.e., each wire is represented by two links in opposite directions. The agents are

located in routers, send data over a directed link, monitor and control this link. The

neighborhood consists of all agents of the routers within the domain, so the information

is exchanged by broadcast. To make a change in the mapping of the virtual link it is

necessary to perform actions on both ends of the physical path. Two agents in separate

routers are responsible for a part of the execution (zeus GA and dionisio GA in Figure

1). Ideally, the two actions occur at the same time to reduce losses in the data plane, so

we must create a mechanism to synchronize agents. The Ginkgo platform

communication is based on the diffusion of knowledge base, then, we need to extend the

information model in order to indicate the status of the resources and agents. With this

information, behaviors perform the actions at approximately the same time.

We use the multi-agent system to manage situations that require the exchange of

virtual paths during the operation of both virtual networks. The main idea of our

experiment is to overload the 100Mbps link and, after that, to migrate just one virtual

path to the 1Gbps link. This experiment simulates a scenario where agents located at the

routers detect the high utilization of a link and decide to migrate one of the virtual links.


4. Results

In the experiment, the virtual routers are VMs based on KVM. The virtual links are

created in the data link layer, with the Ethernet protocol, via virtual interfaces and

bridges. The configuration parameters of the agents are in the policy file, and behaviors

of the autonomic cycle runs at an interval of 1s in normal state. The use of all physical

links in the network are below the threshold set, configured at 50%. When an overload

occurs, the cycle frequency runs at an interval of 0.2s.

Figure 2. Utilization of the physical links.

The graph of Figure 2 shows the utilization of the physical links throughout the

experiment. A flow passing through the virtual network A, with constant rate of 40Mbps

generated by the iperf application, starts close to 5s. The Fast Ethernet physical link

reaches 40% of utilization, not exceeding the threshold. Another flow is started about

15s, through the virtual network B at a constant rate of 40Mbps. The link utilization

exceeds the threshold, reaching 80%, and the correction begins to be performed. The

ending of the execution occurs near the 18s, when the flow of the virtual network is

migrated to the Giga Ethernet link. Therefore, the multi-agent system takes about 3

seconds to prepare and implement the changes.

5. Conclusion

This paper presents an agent-based platform to support the development of a self-

management system for the network architecture in the context of the Horizon Project.

The proposed system changes the mapping of virtual links if the load of specific

physical links increases more than a certain threshold. Although the simplicity of this

experiment, the results show the viability of the Piloting Plane.

References

Gaiti, D., Pujolle, G., Salaun, M., and Zimmermann, H. (2006) “Autonomous network equipments”,

Springer LNCS, Vol. 3854/2006, pp. 177–185.

Kephart, J. O. and Chess, D. M. (2003) “The vision of autonomic computing”. Computer, vol. 36,

no. 1, no. 1, pp. 41–50.

Horizon Project: A New Horizon to The Internet (2011). On line: http://www.gta.ufrj.br/horizon/.

Ginkgo Networks. (2008) “Ginkgo distributed network piloting system. white paper”. On line:

www.ginkgo-networks.com/IMG/pdf/WP_Ginkgo_DNPS_v1_1.pdf

10 Anais

A Monitoring Framework for the FIBRE project

Marcelo Machado de Pinheiro, José Augusto Suruagy Monteiro

Computing and Networking Research Group (NUPERC) Universidade Salvador (UNIFACS)

R. Ponciano de Oliveira, 126 – Rio Vermelho – 41950-275 Salvador - Brazil [email protected], [email protected]

Abstract. Performance is a key instrument in today's networks. It allows to diagnose problems in an end to end basis, helping IT staff to reduce costs, downtime and also improving the end user experience. In network research and development, measurement is a key point to guarantee more efficient, correct and accurate results, especially when dealing with Future Internet experimentations. FIBRE (Future Internet testbeds/experimentation between Brazil and Europe) –is a cooperation project which intends to implement and validate a shared research infrastructure between Brazilian and European universities and institutes. This paper elaborates on a proposal for a Monitoring Framework for the FIBRE project which will be a federated management tool, using perfSONAR services. This tool will provide information about slices, queues, response time, flow aggregation, and flow setup time at FIBRE facilities.

Introduction

Future Internet testbeds are being widely deployed all over the world. These experimental networks, such as GENI, Emulab, PlanetLab/OneLab, PanLab, Federica and AKARI, allow the development of new protocols, services, algorithms of any kind in a real network without disrupting the production environment. For more information on these testbeds please refer to [Abelém et al., 2010]. Aligned with this goal, FIBRE is a cooperation project that is intended to implement and validate a shared research infrastructure between Brazilian and European universities and institutes. FIBRE, in a nutshell, aims at building a shared large-scale experimental network based on OpenFlow, federate Brazilian and European resources and also augment collaboration among Brazilian and European researchers. FIBRE, not differently from any other major Future Internet Experimental project, will rely on the Sliced-base Facility Architecture (SFA) [Peterson et al., 2009] and OpenFlow (OF) [McKeown 2008].

Monitoring is a crucial component of any testbed in order to collect all relevant data for each experiment, including not only network related measurements but also operational data which can help operations personnel on monitoring and troubleshooting the infrastructure itself, as pointed out in [Monteiro, 2010].


Several monitoring frameworks have been proposed and/or implemented on these large-scale experimental Future Internet networks such as GENI Instrumentation and Measurement System (GIMS), Leveraging and Abstracting Measurements with perfSONAR (LAMP), Instrumentation Tools (INSTOOLS), TopHat, etc. [Monteiro 2010].

This paper proposes a Monitoring Framework for the FIBRE project that will use perfSONAR services to provide a federated monitoring solution. It will be built upon the work started by GENI’s LAMP Project1 which exactly aims at leveraging and abstracting measurements with perfSONAR.

Monitoring Framework proposals and ideas

perfSONAR is a multi-domain performance monitoring framework, which defines a set of protocols standards for sharing data between measurement and monitoring systems [Tierney, 2009]. Among the defined services we find: Measurement Point (MP) Service: active and passive measurements monitoring information creation and publication; Measurement Archive (MA) Service: measurement data retrieval; Lookup Service: registration process for all participating services; Authentication and Authorization (AA) Service: domain-level access management; Transformation Service (TS): custom data manipulation of existing archived measurements; and Topology Service (TopS): topological information on networks [Hanemann 2005].

As mentioned before, we plan on building upon LAMP’s results and experience which is based on ProtoGENI’s control framework to support the proposed monitoring framework. Besides making available network related data, the LAMP tool also collects host monitoring data using Ganglia2, and uses perfSONAR API and schemas to export them through a new Ganglia MA service. Based on the expected results of LAMP’s activities, we plan on adapting its prototype to the FIBRE Control Framework.

Since the experimental facilities both in Europe and in Brazil will use OpenFlow switches, the proposed Monitoring Framework will aggregate some OpenFlow information to the existing perfSONAR services, including information about slices, queues, response time, flow aggregation and flow setup time, not limiting the monitoring framework to these parameters. OpenFlow switch table and port statistics can be collected at its controller, e.g., NOX [NOX, 2009]. The collected data will be made available through a measurement archive (MA) and shared to other monitoring tools.

Besides OpenFlow’s data, FlowVisor’s data should also be taken into account in the proposed monitoring framework. Since FlowVisor is considered an OpenFlow proxy that acts between an OF switch and an OF controller [Sherwood et al., 2009], it

1 http://groups.geni.net/geni/wiki/LAMP 2 http://ganglia.sourceforge.net/

12 Anais

adds an extra layer of processing and overhead [Yap 2009], which impacts response time, delays and flow setup time, for example.

Another possibility is to integrate QuagFlow monitored data to the proposed monitoring framework. QuagFlow is a transparent combination of the popular and mature Quagga3 routing software suite and OpenFlow-enabled hardware [Nascimento, 2010]. This integration may be achieved by installing an SNMP agent using SMUX protocol on Quagga boxes and retrieving some routing and flow information that could be used to help to infer some interesting information about routing changes impact on flow setup time for instance. It would be relevant to monitor the very same behavior using OpenFlow with FlowVisor. This could lead to interesting results, especially when considering the integration and operation of OpenFlow, FlowVisor, NOX Controller, and QuagFlow. The later tool was recently released by CPqD [Nascimento, 2010].

Another approach is to consider a possible integration of the Orbit Measurement Library (OML) to perfSONAR. OML is a part of cOntrol and Management Framework (OMF). OML has been developed by the WinLab and NICTA, which is an Australian ICT institute that is also a FIBRE partner. OML main feature is the possibility to add Measurement Points (MP) to applications or services and it is a researcher’s decision to enable it at run-time [White, 2010]. OML focuses mainly on mobile networks and FIBRE proposed monitoring framework could benefit from this expertise and could integrate this service to perfSONAR, at least through a MA interface to OML’s server. It is also interesting to analyze and monitor the communication between the client and the server in FIBRE’s federated environment.

Conclusion

Despite the ideas and proposals that were presented in this paper, there are still a lot of decisions to be made in FIBRE that can affect many of them. These will be quite challenging due to the federated model that Brazilians and Europeans researchers will define for the FIBRE project. The proposed Monitoring Framework will eventually evolve from the discussion points that were presented in this paper.

Clearly, there are several unsolved problems and new challenges to overcome. FIBRE’s monitoring framework proposed in this paper will endeavor to solve at least some of these challenges.

3 http://www.quagga.net/docs/docs-info.php


References

Abelém, A., Machado, I., Stanton, M., and Carvalho, T. (2010) “Design of a testbed for R&D in network architectures”. First Workshop of the Brazilian Institute for Web Science Research. Rio de Janeiro, 2010.

Hanemann, A., Boote, J. W., Boyd, E. L., Durand, J., Kudarimoti, L., Lapacz, R., Swany, D. M., Zurawski, J., Trocha, S., (2005) "PerfSONAR: A Service Oriented Architecture for Multi-Domain Network Monitoring", In "Proceedings of the Third International Conference on Service Oriented Computing", Springer Verlag, LNCS 3826, pp. 241-254, ACM Sigsoft and Sigweb, Amsterdam, The Netherlands.

McKeown, N. et al. (2008), “OpenFlow: Enabling Innovation in Campus Networks”. Available at http://www.openflowswitch.org//documents/openflow-wp-latest.pdf

Monteiro, J. A. S., “Measurement Infrastructures for Future Internet Testbeds”. First Workshop of the Brazilian Institute for Web Science Research. Rio de Janeiro, 2010.

Nascimento, M., Rothenberg, C., Salvador, M., Magalhães, M. (2010). "QuagFlow: Partnering Quagga with OpenFlow". QuagFlow Technical Report. Available at: http://www.dca.fee.unicamp.br/~chesteve/pubs/quagflow-sigcomm10-poster.pdf

NOX (2009). NOX Manual. Available at http://noxrepo.org/manual/index.html perfSONAR (2011). perfSONAR Website. Available at http://www.perfsonar.net

Peterson, L., Sevinc, S., Lepreau, J., Ricci, R., Wroclawski, K., Faber, T., Schwab, S., Baker, S. (2009). “Slice-Based Facility Architecture. Draft Version 1.04”. April 7, 2009

Sherwood, R., Gibb, G., Yap, K., Appenzeller, G., Casado, M., McKeown, N., Parulkar, G. (2009). “FlowVisor: A Network Virtualization Layer”. OpenFlow Technical Report. Available at http://www.openflowswitch.org/downloads/technicalreports/openflow-tr-2009-1-flowvisor.pdf

Tierney, B., Metzger, J., Boote, J., Boyd, E., Brown, A., Carlson, R., Zekauskas, M., Zurawski, J., Swany, M., Grigoriev, M. (2009). “perfSONAR: Instantiating a Global Network Measurement Framework”, LBNL Technical Report LBNL-1452E. Available at acs.lbl.gov/~tierney/papers/perfsonar-LBNL-report.pdf

White, J. (2010). A Tutorial Introduction to OML. GEC9. Available at http://omf.mytestbed.net/projects/oml

Yap, K., Sherwood, R., Kobayashi, M., Handigol, N., Huang, T., Chan, M., McKeown, N., Parulkar, G. (2009). “Blueprint for Introducing Innovation into the Wireless Networks we use every day”. OpenFlow Technical Report. Available at http://openflowswitch.org/downloads/technicalreports/openflow-tr-2009-3-openflow-wireless.pdf

14 Anais

Implementacao de um Novo Datapath OpenFlow emAmbientes de Switches Legados

Fernando N. N. Farias1, Joao J. Salvatti1, Jose M. Dias1, Hugo S. Toda1,Eduardo Cerqueira1, Antonio J. G. Abelem1

1Grupo de Pesquisa em Redes de Computadores e Comunicacao Multimıdia (GERCOM)Universidade Federal do Para (UFPA) – Belem – PA – Brasil

{fernnf, salvatti, jdias, toda, cerqueira, abelem}@ufpa.br

Abstract. The OpenFlow proposal allows that production environments canused as testbed for evaluating new network experiments without modifying onthe production traffic. However, the current OpenFlow implementation is notable to ensure its support to legacy equipments, thus is required that they shouldbe replaced by new switches with OpenFlow supported. This article proposesa new OpenFlow datapath scheme that is able to interact with legacy equip-ment, offering a integration of legacy equipments to OpenFlow environment anda possibility of a gradual support changing on the production environment.

Resumo. O OpenFlow permite que ambientes de producao possam servir detestbed para execucao de experimentos sem interferir no trafego de producao.No entanto, a implementacao atual do OpenFlow nao e capaz de garantir seusuporte a equipamentos legados, necessitando que eles sejam subtituıdos pornovos com o suporte habilitados. Portanto, artigo propoe a utilizacao de umnovo datapath OpenFlow capaz de interagir com equipamentos legados, ofer-ecendo uma integracao deles ao ambiente OpenFlow e a possibilidade de umamudanca gradativa do ambiente de producao.

1. Introducao

O OpenFlow [McKeown et al. 2008] e um exemplo de Software-Defined Network(SDN) [Lantz et al. 2010], onde o hardware (switch) e controlado via software e execu-tado em um plano de controle externo (Controlador) ao plano de dados (Datapath). Estacapacidade possibilita que os pesquisadores/administradores reprogramem os elemen-tos integrados ao datapath (Comutadores ou Roteador) sem interferir nas configuracoesdos equipamentost da rede de producao. Atualmente, o uso do OpenFlow esta em fasede padronizacao onde o seu uso limita-se apenas equipamentos PC ( Personal Com-puter) com GNU/Linux e um numero limitado de roteadores e comutadores comerciasdisponıveis no mercado.

Deste modo, para habilitar o OpenFlow em um ambiente de producao, por exem-plo em um campus universitario, toda infraestrutura de equipamentos legados deve sersubstituıda por equipamentos compatıveis com OpenFlow. Podendo levar a prejuızos edificuldades na implementacao.

1Este trabalho foi desenvolvido com o apoio do Conselho Nacional de Desenvolvimento Cientıfico e Tecnologico (CNPq) e daFundacao de Amparo a Pesquisa do Estado do Para (Fapespa)


O objetivo deste artigo e apresentar uma proposta de um novo modelo de dat-apath para o OpenFlow, diferente dos modelos “Tipo 0” e “Tipo 1” definidos em[McKeown et al. 2008], que integra os equipamentos legados a sua arquitetura. Este novomodelo interage com os equipamentos atraves de interfaces conhecidas como Simple Net-work Management Protocol (SNMP), WebService ou o proprio Commom Language In-terface (CLI) do comutador, de forma que as acoes aplicadas a um datapath remoto saorefletidas em configuracoes no datapath fısico.

Alem desta introducao, o artigo esta dividido nas seguintes partes: na Secao 2 tem-se a descricao da proposta de extensao do OpenFlow para uso de equipamentos legados;em seguida na Secao 3 a definicao da aquitetura utilizada e; por ultimo na Secao 4 estaoas conclusoes e propostas de trabalhos futuros.

2. Usando OpenFlow em Switches LegadosUma rede formada apenas por equipamentos OpenFlow, ilustrado na Figura 1a, observa-se que quando um fluxo de pacote passa pelo comutador da rede o datapath OpenFlowverifica se ha alguma acao para aquele fluxo em sua tabela de encaminhamento como porexemplo, acoes de encaminhar o fluxos para uma determina porta de saıda ou descartaro pacote. Caso nao haja, o cabecalho do pacote e enviado para o controlador para seridentificado, conforme apresentado pelo passo 2 na Figura 1a.

Apos a identificacao, uma acao e aplicada ao datapath do comutador para tratar ofluxo, ilustrado na passo 3 da Figura 1a. Alem disso, a mesma acao e replicada aos outroscomutadores utilizados para levar o fluxo ao seu destino final, passos 3 na Figura 1a.

Tambem percebeu-se que os switches que compoe o backbone, onde foram apli-cadas as regras, formam uma “especie de circuito virtual” ate o destino do fluxo (passos4 e 5 na Figura 1a).

Figura 1. A operacao em uma rede OpenFlow (a) e a proposta de operacao donovo datapath usando switches legados (b)

Portanto, chegou-se a conclusao que essa “especie de circuito virtual” pode serformada por comutadores legados criando um circuito virtual “real” baseado em VLAN(passo 4 na Figura 1b). Isso proporcionaria que, inicialmente, apenas as bordas, ouseja, os equipamentos que interagem diretamente com os clientes da rede, possam sofrermodificacoes de hardware e mantendo ou diminundo os equipamentos legados do back-bone.

16 Anais

Levando em consideracao o cenario apresentado acima, esta em desenvolvimentoum terceiro modo de funcionamento, em outras palavras, um novo datapath OpenFlow.Este datatpth esta localizado em um ambiente remoto que interage tanto com o contro-lador OpenFlow quanto com os switches legados. Alem disso, novas acoes no datapathforam criadas especialmente para o suporte a circuitos VLAN.

3. Arquitetura3.1. Datapath RemotoO datapath remoto e um elemento que teve sua estrututura baseada nos datapath encontra-dos atualmente no OpenFlow e o seu funcionamento e semelhante a um proxy que recebeas acoes enviadas via controlador, interpreta seu conteudo, e converte em configuracoesnos comutadores reais. Atualmente, as interfaces utilizadas para se comunicar com osequipamentos sao SNMP, WebService e CLI. Para cada switch legado que for fazer parteda rede OpenFlow existe um datapath remoto. O novo datapath e executado em umamaquina real ou virtual utilizando o GNU/Linux.

O objetivo deste datapath virtual e representar um datapath OpenFlow com asinformacoes das caracterısticas do switches legados, tais como: quantidade de portas,velocidade das portas, taxa de pacotes enviados e recebidos dentre outros previstos naespecificacao do OpenFlow [OpenFlow 2011]. Para este datapath, alem das informacoesbasicas, tambem foram desenvolvidos algumas acoes especıficas.

As acoes desenvolvidas para o datapath remoto estao baseadas em caracterısticasde circuitos, tais como: a criacao de circuito sem temporizador, onde ha a criacao de umaVLAN no comutador legado com duas interfaces, sendo uma para entrada do fluxo e aoutra para saıda nao havendo um tempo para remocao da VLAN; a criacao de circuitocom temporizador, esta acao possui o mesmo funcionamento da anterior, diferenciandosomente o uso de um perıodo para manter a configuracao estara ativa no switch; a criacaode circuito com Qualidade de Servico (QoS), neste caso as configuracoes no switches uti-lizarao parametros de QoS; taxa de bytes recebidos e transmitidos, essa acao ira informarestatısticas de dados transmitidos e recebidos para uma determinada interface; e remocaode um circuito, esta acao, quando executada, removeria de imediato as configuracoes doswitch.

3.2. Interface VirtualNo OpenFlow, para inicializacao de um datapath, e necessario que seja passado comoparametros as interfaces de rede que farao parte do mesmo. Para o datapath remoto issonao e diferente, no entanto, como o novo datapath nao esta dentro do comutador, naohaveria uma forma de coletar diretamente as informacoes das interfaces dos switches.

Para resolver esse problema foi desenvolvido um modulo para o GNU/Linux, quee instanciado quando o datapath virtual e inicializado. Este modulo cria interfaces deredes virtuais, de acordo com a quantidade de portas do switch e suas caracterısticas.Essas caractetrısticas sao preenchidas conforme os estados atuais das portas do switch,tais como: velocidade da porta, tamanho de Unidade Maxima de Transmissao (MTU),taxa de pacotes recebidos e transmitidos e outras. Dependendo de como o comutadoroferece essas informacoes, elas podem ser transferidas do switch para interfaces virtuaisvia SNMP ou Webservice.


3.3. Funcionamento da PropostaO funcionamento da proposta inicia-se com execucao do datatpath virtual, e comoparametro informa-se qual e o modelo do switch ao qual sera vinculado o datapath demodo a determinar a comunicacao correta entre os mesmos.

Durante a inicializacao do datapath, o modulo da interface virtual e inicializadocriando interfaces virtuais no sistema operacional de acordo com as caracterısticas docomutador. Esta comunicacao e feita atraves de um canal fora da banda e dedicado entreo comutador e datapath virtual.

Tambem, conexoes SNMP sao criadas para obter as caracterısticas das interfacesdo comutador e aplica-las as interfaces virtuais. Com objetivo de manter as informacoesmais precisas diminui-se as taxa de atualizacao do SNMP para 3 segundos.

Apos o modulo esta completamente carregado, as interfaces sao integradas aodatapath virtual, ja estando o datapath preparado para receber as acoes que serao aplicadasvia controlador. Quando a acao chega ate o datapath, o OpenFlow interpreta a mensageme verifica se a acao e compatıvel com o datapath, em caso afirmativo a acao e aplicada eem caso negativo a acao e negada e ema excessao e enviada ao controlador.

Portanto, o que se pretende obter no final e que quando um fluxo passa pelo switchOpenFlow o controlador identificaria que o destino do fluxo seria outro switch openflowe construiria uma circuito ate este proximo switch openflow.

4. Conclusoes e Trabalhos FuturosConclui-se que a proposta e uma alternativa para implantacao gradativa do OpenFlow emum ambiente de producao sem a necessidade de modificacoes em toda a infraestrutura ealem disso, ainda reutilizar equipamentos legados e os integra com OpenFlow. Tambemconclui-se que a proposta pode ser expandida para o uso de circuitos entre instituicoes quepossuam OpenFlow habilitados, podendo assegurar experimentos em ambiente federadoscom a utilizacao de circuitos dinamicos entre essas instituicoes.

Como trabalho futuro pretende-se ampliar os testes com os elementos da arquite-tura e desenvolver ainda mais sua integracao com outras caracterısticas do frameworkOpenFlow. Para isso, esta em desenvolvimento um testbeb para avaliar a proposta emequipamentos reais onde sao utilizados comutadores ethernet do modelo SummitX150com 24 portas. Interligados em uma topologia em linha com enlaces de 1Gbps. Parasimular os comutadores com OpenFlow sao utilizados appliances Soekris Net5501 como Openflow e o sistema GNU/Linux instalado.

ReferenciasLantz, B., Heller, B., and McKeown, N. (2010). A network in a laptop: rapid prototyping

for software-defined networks. In Proceedings of the Ninth ACM SIGCOMM Workshopon Hot Topics in Networks, Hotnets ’10, pages 19:1–19:6, New York, NY, USA. ACM.

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 Comput. Commun. Rev., 38:69–74.

OpenFlow (2011). Openflow switch specification. Disponıvel em: http://www.openflow.org/documents/openflow-spec-v1.0.0.pdf.

18 Anais



Artigos Selecionados II

CMFLOW: Uma Extensão do Protocolo OpenFlow para Criação de Circuitos em Redes Multicamadas

João J. Salvatti, Fernando N. N. Farias, José M. Dias, Hugo S. Toda, Eduardo C. Cerqueira, Antônio J. G. Abelém

Grupo de Pesquisa em Redes de Computadores e Comunicação Multimídia (GERCOM) Universidade Federal do Pará (UFPA) – Belém – PA – Brasil

{salvatti, fernnf, jdias, toda, cerqueira, abelem}@ufpa.br

Abstract. This paper presents an Openflow datapath implementation that enables its use on multilayer circuit networks. It also describes two operation models, one that runs directly on the switch and another that works as a virtual datapath..

Resumo. Este artigo apresenta uma implementação do datapath OpenFlow que permite sua utilização em redes de circuitos multicamadas. São descritos os dois modelos de funcionamento, um que é executado diretamente no harware do switch e outro que funciona como um datapath virtual.

1. Introdução O OpenFlow [McKeown 2008] é uma proposta que permite a programabilidade, via um controlador, de switches e roteadores. É capaz de manipular fluxos de pacotes baseados em informações de seus cabeçalhos que vai da camada 2 até a 4 da arquitetura TCP/IP. No entanto, a utilização de redes de transporte pelo protocolo OpenFlow ainda é um desafio a ser explorado. Neste contexto, extensões do OpenFlow com suporte a manipulação redes de circuitos ópticos são requisitos para a Internet do Futuro. Portanto, este artigo apresenta uma proposta preliminar de extensão para o OpenFlow que permita a manipulação e gerenciamento de circuitos em redes multicamadas, tais como: circuitos em camada 2, baseados em VLAN (Virtual Local Area Network) ID, camadas 1, via time-slot em SONET/SDH (Synchronous Optical Networking/Synchronous Digital Hierarchy) e camada 0, utilizando valor de comprimentos de ondas em redes WDM (Wavelenght Division Multiplexing) Além desta seção introdutória, este trabalho está dividido da seguinte maneira: Seção 2, apresentando a proposta, como modelo proposto e modo de funcionamento; e a Seção 3 com as considerações finais e trabalhos futuros.

2. Extensão do Protocolo OpenFlow para Circuitos Esta seção apresenta as extensões OpenFlow para redes de circuito multicamadas focando no protocolo e nos modos de funcionamento.


2.1 Modelo Proposto O modelo atual do protocolo OpenFlow, distribuídos na versões 1.0 e 1.1, possui suporte para redes de pacotes e com isso toda a sua operação está relacionada com o cabeçalho ilustrado na Figura 1a.

Figura 1. (a) cabeçalho OpenFlow original, (b) extensão para suporte a circuitos.

É através dos campos apresentados na Figura 1a, que as ações para os fluxos de pacotes são criadas no datapath atual do Protocolo OpenFlow. Isso o impossibilita de trabalhar com circuitos em redes multicamadas, pois como observado na Figura 1a, a estrutura não contempla as informações necessárias para manipulação dos mesmos nas principais tecnologias existentes, tais como: em redes ethernet, a manipulação de circuitos do tipo VLAN; SONET/SDH, a sincronização para o uso de time slots; e em WDM, a alocação de comprimento de onda. Para aplicar o modelo proposto, o datapath foi estendido para habilitar o suporte a circuitos. A Figura 1b, exemplifica a extensão para circuitos baseados em ethernet e as informações utilizadas. A partir disso, foi possível fazer com que esta implementação pudesse adicionar, remover e gerenciar circuitos independentemente da tecnologia de transporte na rede. O modelo proposto possibilita uma visão homogênea para o controlador, abstraindo de suas aplicações questões específicas de cada tecnologia de circuito supracitada. Isso é alcançado através de uma definição de alto nível dos elementos básicos que compõem um circuito, como por exemplo, largura de banda, Qualidade de Serviço (QoS), atraso ou variação do atraso. Além disso, estes dados são refletidos em configurações específicas para cada tipo de tecnologia de circuito.

2.2 Modo de Funcionamento Foram desenvolvidos dois modelos de funcionamento para o novo datapath OpenFlow: datapath interagindo diretamente com o hardware; e datapath virtual.

2.2.1. Datapath OpenFlow Interagindo Diretamente com Hardware Este modelo de datapath funciona da seguinte maneira: detecta o tipo de porta que o equipamento possui e, baseado nisso, carrega todas as informações necessárias para sua operação dentro de estruturas de dados adequadas para cada tipo de tecnologia. Por exemplo, em um switch ethernet, o módulo carrega informações como: os modos de links suportados; velocidade da porta; MTU ou tipo de negociação da interface. Já para um switch óptico, são carregadas informações como: quantidade de portas ou quantidade de comprimentos de ondas. No entanto, o acesso a essas informações podem variar dependo do suporte do equipamento as interfaces, de modo que algumas informações podem ser inseridas de forma estática, por exemplo, via um arquivo de configuração.

22 Anais

Quando um circuito é gerado ao longo de um caminho com diversas tecnologias subjacentes, o novo datapath recebe a mensagem OpenFlow e converte em ações diretas ao sistema operacional do equipamento. Para um switch ethernet, o datapath trabalhará com VLANS, já em um switch óptico, irá operar com comprimentos de ondas, logo é necessário que todos os datapaths ao longo do caminho saibam como converter informações de um tipo, por exemplo VLAN, para outro tipo, por exemplo, um comprimento de onda. Na extensão proposta, o datapath faz isso através de arquivos de configuração e funções de conversão. Quando um circuito está estabelecido, o datapath mantém informações do mesmo, porém dependendo da tecnologia do switch, algumas informações podem mudar. Se for feita uma consulta sobre os circuitos estabelecidos em um switch ethernet a saída do mesmo mostrará informações como, porta de entrada, porta de saída, ID de VLAN, prioridade, tempo que o circuito está estabelecido e tempo para que ele expire, ou seja, o tempo que falta para que o circuito seja destruido pelo datapath. Para o datapath da proposta foram adicionadas novas estruturas de dados e mensagens ao protocolo OpenFlow original, como a descrição do tipo de tecnologia que o protocolo irá suportar. As operações são baseadas no documento do projeto OpenFlow para suporte a circuitos [Das, 2009]. As portas ethernets não foram modificadas, porém, adicionou-se uma estrutura para descrever circuitos utilizando esta tecnologia (Figura 1b). As mensagens que foram adicionadas são para criação, remoção, e monitoramento de circuitos. 2.2.2. Datapath OpenFlow Virtualizado

Atualmente o uso do OpenFlow está em fase de padronização, podendo ser utilizado apenas em máquinas GNU/Linux funcionando como roteador ou switch, e alguns switches comerciais disponíveis no mercado, que possuem suporte OpenFlow. Deste modo, muitas vezes, fica inviável sua utilização em equipamentos de circuito sem suporte OpenFlow, devido o custo de mudança das tecnologias já utilizadas.

Figura 2. Funcionamento do datapath virtual.

Para solucionar este problema foi desenvolvido um datapath OpenFlow virtual que age como um proxy entre o equipamento que não suporta OpenFlow e o controlador OpenFlow. Para cada switch sem suporte Openflow de uma rede, deve-se ter um datapath virtual. Este executa no sistema operacional GNU/Linux, em uma máquina real ou virtual. A Figura 2 exibe o funcionamento do datapath virtual. Ao ser inicializado, o datapath verifica um arquivo de configuração que o informa sobre o endereço IP, o tipo do switch (ethernet, SONET/SDH ou WDM), e o


método de acesso ao mesmo (CLI, WebService ou SNMP). Utilizando um desses métodos e com as devidas credenciais de acesso, o datapath se inicializa fazendo consultas no switch e pegando todas as informações necessárias para seu correto funcionamento. Com estas informações, o datapath carrega um módulo para o kernel Linux que cria portas virtuais com os dados das portas do switch sem OpenFlow. Posteriormente, o datapath procede com sua inicialização, registrando para si as portas virtuais do sistema Linux e não as do switch. Quando o controlador da rede requer uma nova configuração, como por exemplo, a criação de uma nova VLAN, o controlador manda a mensagem para o datapath virtual, este traduz a mensagem em comandos compreensíveis pelo switch usandos um dos métodos de acesso, por exemplo, CLI. Se a rede possuir switches com suporte a OpenFlow, estes não necessitam de datapaths virtuais e se registram diretamente no controlador da rede.

3. Conclusões e Trabalhos Futuros

O OpenFlow permite que sejam testados protocolos experimentais em redes de produção. A atual implementação do OpenFlow só tem suporte para redes de circuitos. Além disso, não existe a compatibilidade entre equipamento com e sem OpenFlow. O modelo prosposto apresenta soluções para estes dois problemas. Para isso, foram implementados dois tipos de datapaths, um com suporte a circuitos nas principais tecnologias existentes, como ethernet, SONET/SDH e WDM. Permitindo que o controlador possa criar circuitos de uma maneira uniforme e sem se preocupar com as tecnologias subjacentes. O outro datapath funciona de modo virtual que recebe as mensagens OpenFlow e as traduz em comandos para o equipamento que não possui suporte ao protocolo. Isso possibilita a integração dos equipamentos sem a necessidade de troca do mesmo, com isso reduzindo custos e aumentando a flexibilidade. Como trabalho futuro pretende-se continuar o desenvolvimento da solução, corrigindo problemas e refinando a implementação. Também pretende-se receber colaborações de outras instituições, uma vez que o código fonte estará disponível para download.

Agradecimentos Este trabalho foi desenvolvido com o apoio do Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq) e da Fundação de Amparo à Pesquisa do Estado do Pará (Fapespa).

Referências Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson,

Jennifer Rexford, Scott Shenker, and Jonathan Turner. 2008. OpenFlow: enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev. 38, 2 (March 2008), 69-74.

Das, Saurav. 2009. Extensions to OpenFlow Protocol in support Circuit Switching. OpenFlow. Relatório Técnico. Disponível em: http://www.OpenFlow.org/wp/wp-content/uploads/2009/09/OpenFlow-circuitspec-v02.pdf

24 Anais

The RouteFlow approach to IP routing services onsoftware-defined networks

Marcelo R. Nascimento1, Christian E. Rothenberg1, Marcos R. Salvador1,Maurıcio F. Magalhaes2, Carlos N. A. Correa3, Sidney C. de Lucena3

1Fundacao CPqD – Centro de Pesquisa e Desenvolvimento em TelecomunicacoesCampinas, SP – Brazil

2Faculdade de Enganharia Eletrica e Computacao – UnicampCampinas, SP – Brazil

3Federal University of the Rio de Janeiro State – UniRioRio de Janeiro, RJ - Brazil

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

1. IntroductionBesides the formidable evolution of the Internet with respect to its pervasiveness and ap-plications, its core technology, mainly represented by the layered TCP/IP protocol suite,has not gone through an equally radical transformation. Since the Internet became com-mercial, network devices have been “black boxes”in the sense of vertically integratedimplementations based on closed-source software over proprietary hardware [Hamilton ].This model not only leads to the already recognized Internet “ossification” but also im-plies higher R&D costs and slower time to market of new product features.

Recent developments in the standardization of vendor-neutral APIs (e.g.,ForCES [Khosravi and Anderson 2003], OpenFlow [McKeown et al. 2008]) allow for“lobotomizing” a big part of the decision logic of network devices to external controllersimplementable with commodity hardware (e.g. x86 server technology), a plentiful, scal-able, and affordable resource.

RouteFlow, the work in progress depicted is this paper, is an architecture follow-ing the software-defined networking (SDN) [Greene 2009] paradigm based on a program-matic approach to logically centralize the network control, unify state information, anddecouple forwarding logic and configuration from the hardware elements. It is composedby an OpenFlow controller application, an independent RouteFlow server, and a virtualnetwork environment that interconnects traditional IP routing engines (e.g. Quagga).

The main goal of RouteFlow is enabling remote IP routing services in a centralizedway, as a consequence of effectively decoupling the forwarding and control planes. Thisway, IP networks become more flexible and allow for the addition and customization ofprotocols and algorithms, paving the way for “router-as-a-service” models of networkingin the virtual era. RouteFlow is the evolution of our early work on partnering Quagga withOpenFlow [Nascimento et al. 2010] and works transparent to the specific routing engine(e.g., XORP, BIRD) as long as it is based on the Linux networking stack.

The balance of this paper is as follows. Section 2 presents the design and modesof operation of the software-defined RouteFlow routing architecture. Section 3 describesthe prototype implementation and Section 4 concludes the paper.


VM

VM

VM

VM

OSPF / RIP / BGPVirtual Topology

Programmable Switch

Programmable Switch

Programmable Switch

Physical Infrastructure

Programmable Switch

Legacy Network

BGP

RouteFlow Server Controller

OSPFOSPF

Quagga

Quagga

Quagga

Quagga

Lecacy Switch

(a) Overview of a RouteFlow-controlled network.

hardware

software

hardware

software

hardware

software

kernel space

user space

kernel space

user space

kernel space

user space

hardware

software

kernel space

user spaceVirtual

Environment

Controller

Programmable Switches

RouteTable

RouteFlowSlave

Route Engine

ARPTable

NIC 1NIC 2NIC n

RouteFlowController

Network Controller

AP.1

HW TablePORT 1PORT 2PORT n

DriverAPI

RouteFlow Protocol

OpenFlow

AP.n

. . .

RouteFlow Server

RouteFlow Protocol

OpenFlow

OVS

DB*

(b) RouteFlow components.

Figura 1. RouteFlow architecture conceptual design.

2. The RouteFlow designRouteFlow runs OpenFlow switches’ control logic through a virtual network composedby virtual machines (VMs), each of them executing a routing engine (see Fig. 1(a)). ThoseVMs (or virtual environments) are dynamically interconnected to form a logic topologythat mirrors a physical infrastructure – or a simplified version of it. The virtual envi-ronment is held in (a set of) external servers and communicate with the forwarding planethrough an OpenFlow controller application that receives from the RF server the decisionsmade by the routing protocols. As a result, flow rules are maintained in the data plane tospecify how traffic must be handled (i.e. port forwarding, MAC re-writing, TTL decre-ment). While the control is centralized, it stays logically distributed. This way, it does notrequire modification of existing routing protocols. Moreover, legacy infrastructure can betransparently integrated, given that routing messages, like those of the BGP protocol, canbe sent from/to the virtual control plane.

This approach leads to a flexible, high-performance and commercially competitivesolution to provide IP routing based on: (a) programmable low cost switches and small-footprint embedded software (i.e. OpenFlow); (b) open-source routing protocols stacks(e.g. Quagga); and (c) commodity x86 server technology.

2.1. Modes of operation

Separating the control plane from the forwarding substrate allows for a flexible mappingand operation between the virtual elements and their physical counterparts. Figure 2shows the three main modes of operation that RouteFlow aims at supporting.

Logical split: This 1 : 1 mapping between hardware switches and the virtualizedrouting engines basically mirrors the physical substrate (number of switch ports, connec-tivity) into the virtual control plane. Two submodes of operation can be defined dependingon whether the routing protocol messages are sent through the physical infrastructure (i.e.traditional routing) or are kept in the virtual plane.

Multiplexing: This 1 : n mapping of physical to virtual substrate represents thecommon approach to router virtualization where multiple control planes run simultane-

26 Anais

Router Multiplexation(1:n)

Router Aggregation(m:1 or m:n)

Logical Split Router(1:1)

Infrastructure Provider(Physical Substrate)

Virtual Network Provider(Network Slices)

Figura 2. Different modes of operation and scenarios of router virtualization.

ously and install their independent FIBs on the same hardware. Multi-tenant virtual net-works can be defined by letting control protocol messages flow through the virtual planeand stitching the data plane connectivity accordingly.

Aggregation: This m : 1 mapping of hardware resources to virtual instancesallows to simplify the network protocol engineering by bundling a group of switches,such that neighbouring devices or domains can treat the aggregated as if it were a singleelement. This way intra-domain routing can be independently defined per software whiletraditional inter-domain or inter-zone routing (e.g. BGP) can be converged into singlecontrol unit for signaling scalability and simplified, centralized management purposes.

3. Prototype implementation

The current RouteFlow prototype is a combination of open-source software publicly avail-able and newly-developed software daemons:1

The RouteFlow Controller and Server: The RF-Controller component is im-plemented as a C++ application running over NOX [Gude et al. 2008] named routeflowc.The RouteFlow network protocol is used to let routeflowc communicate with the RF-Server that interacts with the RF-Slave instances and the virtual switch. To support vir-tualization tool independence, Libvirt [Bolte et al. 2010] is the framework choosen tosupport the needed VM operations. Having the RF-Server as a standalone applicationfacilitates the interaction with other (remote) OpenFlow controllers.

FIB gathering and rfslaved: Each VM in the virtual topology executes a RF-Sdaemon named rfslaved along with its routing engine (e.g. Quagga). rfslaved gathers FIBupdates via the Netlink Linux API and sends the event data to the routeflowc via the RF-Server. Using Netlink to keep processes aware of connectivity changes renders rfslavedagnostic of the routing suites as long as it updates the OS FIB in response to the routingprotocols execution.

Virtual topology networking: OpenVSwitch (OVS) [Pfaff et al. 2009] is thesoftware switch controlled by the RF-Server and used to connect all NICs in a virtualtopology that must be mutually reachable. OVS instances running in different hosts canbe interconnected through a tunnel port. In addition to a distributed virtual topology andOpenFlow programmability support, our experimental evaluation shows better conver-gence times when using OVS.

1Available in the RouteFlow project page: https://sites.google.com/site/routeflow/


4. ConclusionsRouteFlow is an ongoing example of the power of innovation resulting from the blend ofopen interfaces to commercial hardware and open-source community-driven software de-velopment. The RouteFlow architecture allows for a flexible resource association betweenlegacy routing control protocols and a programmable physical substrate, opening the doorfor multiple use cases around virtual routing services. However, a number of challengeshave still to be overcome, and, to fully realize this vision, further work is required to seethe PaaS model meet the networking world [Keller and Rexford 2010].

ReferenciasBolte, M., Sievers, M., Birkenheuer, G., Niehorster, O., and Brinkmann, A. (2010). Non-

intrusive virtualization management using libvirt. In DATE ’10.

Greene, K. (2009). TR10: Software-Defined Networking. MIT Technology Review.

Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown, N., and Shenker, S.(2008). Nox: towards an operating system for networks. SIGCOMM CCR., 38.

Hamilton, J. Networking: The last bastion of mainframe computing.http://perspectives.mvdirona.com/2009/12/19/ NetworkingTheLastBastionOfMain-frameComputing.aspx.

Keller, E. and Rexford, J. (2010). The ’Platform as a Service’ model for networking. InINM/WREN 10.

Khosravi, H. and Anderson, T. (2003). Requirements for separation of ip control andforwarding. RFC 3654.

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 CCR, 38:69–74.

Nascimento, M. R., Rothenberg, C. E., Salvador, M. R., and Magalhaes, M. F. (2010).Quagflow: partnering quagga with openflow. SIGCOMM CCR, 40:441–442.

Pfaff, B., Pettit, J., Koponen, T., Amidon, K., Casado, M., and Shenker, S. (2009). Ex-tending networking into the virtualization layer. In HotNets-VIII.

28 Anais

Estrategias de Selecao de Nodos noPlanetLab para Execucaode Experimentos

Thiago Garrett, Elias P. Duarte Jr., Luis C. E. Bona

1Departamento de Informatica – Universidade Federal do Parana (UFPR)Caixa Postal 19.081 – 81.531-980 – Curitiba – PR – Brasil

{garrett,elias,bona}@inf.ufpr.br

Abstract. PlanetLab is a global research testbed for protocols and distributedsystems experimentation. Users of such testbeds often execute experiments whichdemand a group of nodes with a reasonable level of stability. In this paper wedescribe an online monitoring strategy and several node selection strategies,focused on the communication between each pair of nodes on PlanetLab.

Resumo. O PlanetLabe um testbed global de pesquisa que suporta a expe-rimentacao de protocolos e sistemas distribuıdos. Usuarios de tais testbedsfrequentemente executam experimentos que necessitam de um conjunto de nodoscom um nıvel razoavel de estabilidade. Neste artigo descrevemos uma estrategiaonline de monitoramento e varias estrategias de selecao de nodos focadas nacomunicacao entre cada par de nodos no PlanetLab.

1. Introducao

Conforme novas alternativas para a arquitetura da Internet sao propostas,testbedsrealısti-cos de larga escala, como o PlanetLab, tornam-se cada vez mais importantes [Ortiz 2008].O PlanetLab [Chun et al. 2003]e uma destas redes globais de pesquisa que suporta o de-senvolvimento de novos protocolos e servicos. Atualmente o PlanetLabe composto porcerca de 1088 nodos em cerca de 578 locais ao redor do mundo. Cada nodo apresentacapacidades e ambiente diferentes, e todos os usuarios dos nodos utilizam-nos simultane-amente, sem reserva de recursos, resultando em um ambiente de grande instabilidade.

Pesquisadores necessitam de um ambiente real, sujeito a condicoes reais, taiscomo perdas ocasionais de conectividade e congestionamento, a fim de avaliar suas pro-postas. Alem disso, dependendo do nıvel de instabilidade, pode ser ate mesmo impossıvelexecutar uma aplicacao que envolva comunicacao de nodos. Para executar um protocoloou uma aplicacao distribuıdae frequentemente necessaria a existencia de um grupo de no-dos que apresentem um nıvel razoavel de estabilidade entre si. Naoe trivial encontrar talgrupo de nodos no PlanetLab [Duarte Jr. et al. 2010]. Em um dado momento, um grupogrande desses nodos pode nem mesmo existir.

Neste artigo descrevemos uma estrategiaonlinede monitoramento do PlanetLabe varias estrategias de selecao de nodos focadas na comunicacao entre cada par de nodos.Uma estrategia de monitoramentooffline no PlanetLab foi anteriormente implementada[Duarte Jr. et al. 2010]. No monitoramentoonline, cada nodo monitora o tempo de re-sposta de cada outro nodo, obtendo-se assim o ponto de vista de cada nodo sobre o es-tado da rede. A partir destes dados, gera-se um grafo no qual os nodos sao selecionadosseguindo algumas estrategias descritas neste artigo.


O restante deste artigo esta organizado daseguinte maneira. A secao 2 descreve aestrategia de monitoramento e as estrategias de selecao de nodos no PlanetLab. A secao 3descreve alguns experimentos realizados com a ferramenta implementada e os resultadosobtidos, seguido da conclusao na secao 4.

2. Estrategia Online de Monitoramento e SelecaoNa estrategia de monitoramentoonline, cada nodo monitora o RTT entre ele e os outrosnodos do sistema. Periodicamente, cada nodo mede o RTT para cada outro, e envia oresultado a um servidor. Uma caracterıstica da estrategiae que o RTTe medido na camadade aplicacao, por isso o seu valor pode variar nao apenas pelas condicoes da rede, mastambem pelas condicoes do proprio nodo.

O servidore responsavel por armazenar os valores de RTT recebidos dos no-dos. Alem disso, o servidor tambem e responsavel por sumarizar dados antigos, a fimde diminuir o espaco em disco necessario para armazena-los, possibilitando guarda-lospor um perıodo de tempo maior.

Varias estrategias de selecao de nodos foram definidas. Todas elas utilizam omodelo de grafo para representar o PlanetLab: cada verticee um nodo da rede, e umaaresta entre dois vertices corresponde a uma comunicacao estavel entre os nodos refer-entes aos dois vertices. Comunicacao estavel significa que um nodo considera o outroestavel, e vice-versa. Estes grafos sao construidos a partir dos dados do monitoramento.Dois parametros sao necessarios: limiar para o RTT e perıodo de tempo. Com isso, paracada par de nodos(a, b), e contado quantos valores de RTT (ou media do RTT, casoestejam sendo usados dados sumarizados) existem dentro do perıodo desejado, e quan-tos valores sao menores ou iguais ao limiar. Caso pelo menos 90% dos valores sejammenores ou iguais ao limiar,e dito que o nodoa considerab estavel naquele perıodo,e para aquele limiar. Seb tambem considerara estavel, entao existe uma aresta entrea e b. Este processo resulta em um grafo que representa o sistema no perıodo e limiarespecificados.

A partir deste grafo, os nodos podem ser selecionados de diversas formas: clique,grau mınimo, e subgrafo com grau mınimo. A estrategia da clique seleciona um grupo denodos que consideram-se mutuamente estaveis. Assim, todos os pares de nodos do grupotem um aresta entre eles. A estrategia do grau mınimo seleciona os nodos que tenham grauigual ou maior ao grau mınimo desejado. Um estrategia similare encontrar o maior graumınimo possıvel que resulte em um grupo de nodos com um tamanho mınimo desejado.A estrategia do subgrafo com grau mınimo seleciona nodos com um grau mınimo entreeles. Uma estrategia similare encontrar o subgrafo com o maior grau mınimo possıvel,que resulte em uma quantidade mınima de nodos desejada.

3. ResultadosEsta secao descreve os experimentos realizados no PlanetLab com uma ferramenta im-plementada a partir da estrategia descrita na secao anterior, assim como alguns resultadosobtidos.

Para a execucao dos experimentos fizemos questao de monitorartodosos nodosdo PlanetLab, que no inıcio do desenvolvimento deste trabalho eram 1036 nodos. Sur-preendentemente, o numero de nodos que efetivamente executou o experimento, ficou,

30 Anais

em um instante qualquer, entre 600 e 700 nodos. Isto ocorreu pois, um grande numerodenodos alterna entreonlinee offline, e alguns outros nao foi possıvel acessar em nenhummomento. A ferramenta foi executada durante 21 dias, nos quais os grafos foram geradosde hora em hora. O perıodo de tempo entre cada medicao do RTT foi de 5 minutos, e oslimiares foram de 0.1s e 0.2s.

A partir dos grafos gerados, alguns resultados foram obtidos aplicando as es-trategias de selecao de nodos descritas na secao 2. Foi observado o comportamento decada estrategia no decorrer do tempo.

A figura 1 mostra a variacao da quantidade de nodos selecionados com varios val-ores de grau mınimo: 50, 100, 150 e 200. Cada grafico mostra o resultado para um limiardiferente, para todo o perıodo de 3 semanas. Observa-se que a variacao da quantidade denodos selecionados durante o perıodoe maior com o limiar de 0.2s.

0

50

100

150

200

250

300

350

400

450

500

29/01 00:00

31/01 00:00

02/02 00:00

04/02 00:00

06/02 00:00

08/02 00:00

10/02 00:00

12/02 00:00

14/02 00:00

16/02 00:00

18/02 00:00

20/02 00:00

22/02 00:00

Numero de nodos encontrados com grau minimo, Limiar 0.1

grau minimo 50grau minimo 100grau minimo 150grau minimo 200

250

300

350

400

450

500

550

600

29/01 00:00

31/01 00:00

02/02 00:00

04/02 00:00

06/02 00:00

08/02 00:00

10/02 00:00

12/02 00:00

14/02 00:00

16/02 00:00

18/02 00:00

20/02 00:00

22/02 00:00

Numero de nodos encontrados com grau minimo, Limiar 0.2

grau minimo 50grau minimo 100grau minimo 150grau minimo 200

Figura 1. Quantidade de nodos com diferentes graus mınimos no decorrer de 3semanas.

A figura 2 mostra a quantidade de nodos e grau mınimo do subgrafo com o maiorgrau mınimo encontrado, no decorrer de 3 semanas. Cada grafico mostra o resultado paraum limiar diferente. Observa-se que a variacao da quantidade de nodose grande, ja avariacao do grau mınimo entre os nodose menor.

60

80

100

120

140

160

180

200

220

240

260

29/01 00:00

31/01 00:00

02/02 00:00

04/02 00:00

06/02 00:00

08/02 00:00

10/02 00:00

12/02 00:00

14/02 00:00

16/02 00:00

18/02 00:00

20/02 00:00

22/02 00:00

Melhor subgrafo induzido, Limiar 0.1

nodos selecionadosgrau minimo entre os nodos selecionados

140

160

180

200

220

240

260

280

300

29/01 00:00

31/01 00:00

02/02 00:00

04/02 00:00

06/02 00:00

08/02 00:00

10/02 00:00

12/02 00:00

14/02 00:00

16/02 00:00

18/02 00:00

20/02 00:00

22/02 00:00

Melhor subgrafo induzido, Limiar 0.2

nodos selecionadosgrau minimo entre os nodos selecionados

Figura 2. Tamanho e grau mınimo do subgrafo com o maior grau mınimo encon-trado no decorrer de 3 semanas.

Com o objetivo de observar se uma clique mantem-se valida com o passar dotempo, foram encontradas 3 cliques no primeiro grafo do perıodo observado, com o lim-iar de 0.05s. Foi empregado um limiar menor que os utilizados no restante do experimentoa fim de verificar se nodos selecionados com um limiar mais restritivo teriam um com-portamento mais estavel quando observados com o uso de um limiar maior, mantendo-se


assim como uma clique por grandes perıodos de tempo. Afigura 3 mostra, para os 3grupos de nodos encontrados, a quantidade de nodos com o maior grau possıvel dentrodo grupo(numero de nodos menos 1), no perıodo de um dia. A quantidade de nodos como maior grau possıvel dentro de cada um desses grupos foi obervada em cada um dos 2limiares. Perıodos em que todos os nodos do grupo tem o maior grau possıvel, o grupoeuma clique. O grupo de 20 nodos deixou de ser clique em apenas 1 momento, em ambosos limiares. Ja o grupo de 33 nodos deixou de ser clique por perıodos maiores, e o de 10nodos manteve-se como clique em poucos perıodos.

0

5

10

15

20

25

30

35

09/02 02:00

09/02 04:00

09/02 06:00

09/02 08:00

09/02 10:00

09/02 12:00

09/02 14:00

09/02 16:00

09/02 18:00

09/02 20:00

09/02 22:00

10/02 00:00

10/02 02:00

Numero de nodos com o maior grau possivel no conjunto, Limiar 0.1

10 nodos20 nodos33 nodos

0

5

10

15

20

25

30

35

09/02 02:00

09/02 04:00

09/02 06:00

09/02 08:00

09/02 10:00

09/02 12:00

09/02 14:00

09/02 16:00

09/02 18:00

09/02 20:00

09/02 22:00

10/02 00:00

10/02 02:00

Numero de nodos com o maior grau possivel no conjunto, Limiar 0.2

10 nodos20 nodos33 nodos

Figura 3. Quantidade de nodos com o maior grau possıvel dentro de diferentesgrupos no decorrer de 3 semanas.

4. Conclusao

Neste trabalho definimos uma estrategiaonlinede monitoramento e selecao de nodos paraa realizacao de experimentos no PlanetLab. Esta estrategiae focada na comunicacao entrecada par de nodos do sistema, diferentemente das ferramentas ja existentes, que baseiama selecao dos nodos em medidas referentes somente ao estados dos proprios nodos, naona interacao entre eles. Na estrategia definida, cada nodo monitora o RTT de cada outronodo, tendo-se assim o ponto de vista de cada nodo sobre o estado do sistema. A partirdos dados deste monitoramento, sao gerados grafos nos quais os nodos sao selecionadosde diversas formas: clique estavel, grau mınimo e subgrafo com grau mınimo.

Trabalhos futuros incluem a definicao de uma “nota” para cada nodo, indicandose o nodo tem um bom historico ou nao. Outra ideiae permitir a classificacao das falhasdos nodos como transientes e intermitentes. Alem disso, executar aplicacoes P2P com osnodos selecionadose uma forma de avaliar a ferramenta criada.

Referencias

Chun, B., Culler, D., Roscoe, T., Bavier, A., Peterson, L., Wawrzoniak, M., and Bowman,M. (2003). PlanetLab: An Overlay Testbed for Broad-coverage Services.SIGCOMMComput. Commun. Rev.

Duarte Jr., E. P., Garrett, T., Bona, L. C. E., Carmo, R. J. S., and Zuge, A. (2010). Find-ing Stable Cliques of PlanetLab Nodes.The 40th Annual IEEE/IFIP InternationalConference on Dependable Systems and Networks (DSN’2010 DCCS).

Ortiz, S. (2008). Internet Researchers Look to Wipe the Slate Clean.IEEE Computer,41(1).

32 Anais

Domain Title Service for Future Internet Networks

Flávio de O. Silva1, João H. S. Pereira1, Sérgio T. Kofuji1, Pedro Frosi Rosa2

1Escola Politécnica da USP (EPSUP – PSI – Universidade de São Paulo (USP) Caixa Postal 61.548 – 05.424-970 – São Paulo – SP – Brazil

2Faculdade de Computação (FACOM) – Universidade Federal de Uberlândia (UFU) Caixa Postal 593 – 38.400-902 – Uberlândia – MG – Brazil

{flavio,kofuji}@pad.lsi.usp.br, [email protected], [email protected]

Abstract. The basic principles of the core protocols of Internet remain since they were established. The Internet allowed a revolution on communications and this lead to a complete set of communication requirements. The evolution of the Internet is limited by its vision, so different research groups are designing a future Internet. This work presents a contribution to this research area by describing the DTS (Domain Title Service), a distributed system responsible for the communication requirements of an entity over time and its horizontal addressing. Using OpenFlow, DTS will be experimentally deployed over production networks, collaborating with the design of future networks.

Resumo. Os princípios básicos dos protocolos da Internet permanecem os mesmos desde a sua proposição. A Internet promoveu uma revolução nas comunicações que conduziram a um novo conjunto de requisitos de comunicação. A evolução da Internet está limitada por sua visão, e desta forma, diferentes grupos de pesquisa estão projetando a Internet do futuro. Este trabalho apresenta uma contribuição para esta área de pesquisa descrevendo o DTS (Domain Title Service), um sistema distribuído responsável pelos requisitos de comunicação de uma entidade ao longo do tempo bem como o seu endereçamento horizontal. Utilizando OpenFlow, o DTS será experimentalmente implantado nas redes atuais, colaborando com o projeto das futuras redes.

1. Introduction The ideas and the basic principles regarding the core protocols of the Internet were established at the beginning of the seventies by Cerf; Kahn (1974). Internet on its turn is generating a revolution on communications and the way people, data, services and contents interacts each other.

The stability of these protocols, as presented by De Souza Pereira; Kofuji, S. T; Rosa, P. F (2010a), lead to the dissemination of the Internet and this lead to a new set of requirements, among others: security; privacy; quality of service; mobility; support of real time contents such as voice and video; Web Services; support for new devices like smartphones and sensors; autonomic management; support to virtualization and policies. A totally new scenario considers as well the energy consumption, social and economic needs as exposed by Tselentis et al. (2009).


At the present researchers all over the world are engaged in clean-slate design of a new Internet as related by Roberts (2009). European Union, FIA (Future Internet Assembly) aggregates more than one hundred different projects related with different aspects of networks as discussed by Tselentis et al. (2010). At United States FIND (Future Internet Design) program aggregates different projects as presented by Fisher (2007). At Brazil, among others, projects like Horizon described by Moreira et al. (2009) and Web Science introduced by Maculan et al. (2009), are involved with the development of novel networks. The research is experimentally oriented based on test beds like: PlanetLab introduced by Peterson; Roscoe (2006); Geni; OneLAB and initiatives like FIRE related by Gavras, A. et al. (2007), are dealing with the promotion of this experimental approach. At Brazil, RNP under project GIGA is enabling the use of OpenFlow and is federating Brazilian test beds with experimental facilities outside Brazil, as exposed by Stanton (2010).

In this paper, section 2 presents the DTS (Domain Title Service), a distributed system responsible for the communication requirements of an entity over time and section 3 shows some concluding remarks and future work.

2. DTS (Domain Title Service) Actually at Internet, applications are addressed using an IP address, related with the Network Layer, and a port, related with the Transport Layer. So the addressing is based on two distinct concepts, defined at different layers which results in a tight coupling between them. But, at the user point of view, a name is still used and needs to be translated by a name service, the DNS (Domain Name System). The need of a name service shows that a network user is not interested at these aspects of the address but in content, service, or some data available by the network.

The DTS (Domain Title Service), shown at Figure 1, introduced by De Souza Pereira; Kofuji, S.T.; Rosa, P.F. (2010b) consists of a distributed system over the network elements responsible for maintaining the Entity Titles, as defined by Pereira et al. (2011), available in that domain and their communication requirements over time. Besides that, DTS will be responsible for handling QoS and QoE parameters.

Source

Applications

Resources

Hosts

DTS

NE1 NE2 NE...

NE3

Destination

Applications

Resources

Hosts

Figure 1 – DTS Topology

DTS plays an important role at basic aspects of the networking like routing and addressing and is responsible for handling the QoS and security parameters provided by the application to the lower layers of the protocol stack. One of its goals is to guarantee

34 Anais

that the communications requirements will be handled appropriately not only on an end-to-end view but also at point-to-point view.

Over the network, DTA (Domain Title Agents) are distributed on that domain and being deployed at servers and network elements (switches, routers and so on). The DTS interacts with protocol entities providing a cross layer support in order to propagate communication needs, as shown on Figure 2.

Figure 2 – DTS interaction with the protocol stack

A DTA can be implemented as an OpenFlow Controller. Based on this approach, each network will have a DTA responsible for the configuration of network elements based on the communication requirements.

5. Concluding Remarks and Future Work Considering the new set of requirements, Internet architecture must be reviewed. This process of revision using a clean-slate can free researchers of current shortcomings, providing a rich environment for experimentations. The evolution, provided by this process, might be deployed at current Internet, modifying its structures resulting in a new Internet.

This paper shows our contribution to this research area by presenting the DTS, a distributed system responsible for handling communications needs over time and a horizontal addressing of the entities playing a important role with networks aspects like routing and addressing and features like an intelligent use of unicast and multicast in a end-to-end communication.

As a future work, DTS approach and the concepts will be deployed at a production network using OpenFlow in order to experiment and test the horizontal addressing by title.

6. Acknowledgement This work has been supported by the faith and beliefs of MEHAR project team. The authors would like to thank the MEHAR Project members for all discussions and collaboration


7. References CERF, V.; KAHN, R. A protocol for packet network intercommunication.

Communications, IEEE Transactions on, v. 22, n. 5, p. 637–648, 1974.

DE SOUZA PEREIRA, J. H.; KOFUJI, S. T; ROSA, P. F. Distributed systems ontology. New Technologies, Mobility and Security (NTMS), 2009 3rd International Conference on. Anais... p.1–5, 2010a.

FISHER, D. US National Science Foundation and the Future Internet Design. ACM SIGCOMM Computer Communication Review, v. 37, n. 3, p. 85–87, 2007.

GAVRAS, A.; KARILA, A.; FDIDA, S.; MAY, M.; POTTS, M. Future internet research and experimentation: the FIRE initiative. ACM SIGCOMM Computer Communication Review, v. 37, p. 89–92, 2007.

MACULAN, N.; XEXÉO, G.; MEDEIROS, B.; et al. Brazilian Institute for Web Science Research. ,2009.

MOREIRA, M. D. D.; FERNANDES, N. C.; COSTA, L. H. M. K.; DUARTE, O. C. M. B. Internet do futuro: Um novo horizonte. Minicursos do Simpósio Brasileiro de Redes de Computadores-SBRC 2009, p. 1–59, 2009.

PEREIRA, J. H. DE S.; SILVA, F. DE O.; LOPES FILHO, E.; KOFUJI, SERGIO TAKEO; ROSA, PEDRO FROSI. Title Model Ontology for Future Internet Networks. Future Internet Assembly 2011: Achievements and Technological Promises, Lecture Notes in Computer Science.. v. 6656, p.465, 2011. Future Internet: Achievements and Promising Technology: Springer-Verlag.

PETERSON, L.; ROSCOE, T. The design principles of PlanetLab. ACM SIGOPS Operating Systems Review, v. 40, n. 1, p. 11–16, 2006.

ROBERTS, J. The clean-slate approach to future Internet design: a survey of research initiatives. annals of telecommunications - annales des télécommunications, v. 64, n. 5-6, p. 271-276, 2009. Disponível em: <http://www.springerlink.com/content/e240776641607136/>. Acesso em: 11/4/2011.

DE SOUZA PEREIRA, J. H.; KOFUJI, S.T.; ROSA, P.F. Horizontal Addressing by Title in a Next Generation Internet. Networking and Services (ICNS), 2010 Sixth International Conference on. Anais... p.7-11, 2010b.

STANTON, M. RNP Experiences and Expectations in Future Internet Research and Development. New Network Architectures, p. 153–166, 2010.

TSELENTIS, G.; DOMINGUE, J.; GALIS, A.; et al. Towards the future internet a European research perspective. Amsterdam Netherlands ;;Washington DC: IOS Press, 2009.

TSELENTIS, G.; GALIS, A.; GAVRAS, A.; et al. Towards the future internet emerging trends from European research. Amsterdam : IOS Press,, 2010.

36 Anais



Artigos Convidados I

��

��

��

�� !��"��#$%$%�&��

��

�� !��"�� !�� "�� #��$�� %�� &�� '��'�� "�� '��

(�� %�� #�� "��)�� %��*�� *� �� "� ��+�� ,�� "� �� "� �� "�� -��,�� %�� '�� $�� "�� !$�./�!��"��

� ��-�0��,��,�� %��


� �

�� %�� -�0�� ,�� "�� %�� #� �� '�� %�� %�� 1��2�� '��

�� %�� %��-�� 3��'�� "�� 4556�� ,�� ,�� -�0��(�� #� �� -�� #� �� 4577�� 4574�� ,�� "�� $�#��-!�$��#��3�� ,�� '�� ,�� #�� ,��

� �� -�0��*�� -�0��

40 Anais

��

��

��

��

��

! � �� "!�#$�� "�� !�� #�� $�� "!�#$�� %� �� &'(�� ) �� *��+��! �� "!�#$�� ,�� -�� "!�#$� �� ./&� �� &�� "!�#$� �� 0�� "!�#$�� ! � �� "!�#$��

! �� 1�� ! �� "2)� �� +'"!� ��


� �

��+'"!�� 3�)$�) ��1�� ,��(��-��

42 Anais

��

��

��

�� !�� "�#$�%�"�&�'��&��&�(��

��

�� !�"��#�� $�� % �� &�� '�� $�� % �� ' �� #� � �� #� � �� (�� ' � � � �� &� �$�� #� � �� '�� ' �� '�� '� �� )�� *�� !�� *�� +�� ,��

�� ' �� *� � �� +�� -�� .� /�� 0�� 1�� /01,�� '�� #� � �� 2�� % �� 3��'�� - .�0��


� �

�� *�� 4 �� ' � �� '�� 4�� &�� &� ��

� �� 5�6��6�� +70 ,3�

8� 7093�"�� %�0./:��+%&�� *�� 0��./�� :�;�� ;,� �� *� � �� &� �� %�0.��1� +%&�� *�� 0��.�� ;� 1��,�� '� �� &�� ' ��&�� &�� '��'�� /01 ��

8� 70<3��

8� 70=3� % �� +�� ,�� >�� ?�� *��*�� $��

8� 70@3�% �� *� �� ' �� '�� ' � � � ��

8� 70A3�B� ��$�� *� ��

8� 70C3� % ��

8� 70D3�� 4�� 5�� 4��

�

44 Anais



Artigos Convidados II

��

��

� � ��

�� !�� "��#�$�%��#�"�#�$��

��

�� !�� "�� #� �$� ��%� �� %� �� &�� !�� $'� � � ��(�� % ��#� �� )� �� %�&�� !�� $� �� !�� "� �� #�� %�� *�+�,�-��$��$� ��*�+��,��#��.�/��+0��#�� 1�� #�� &�� &�� !��1� �� $� �$�� %��!�� "&�� $�� 1�� !��%�� "� ��%�� '�


48 Anais

Índice por Autor

A Abelém, A. J. G. ..................... 15, 21, 47

B Batista, D. M. ........................................ 7 Baumberger, M. .................................... 3 Bona, L. C. E. ..................................... 29

C Cerqueira, E. ................................. 15, 21 Corrêa, C. N. A. .................................. 25

D da Fonseca, N. L. S. .............................. 7 de Lucena, S. C. .................................. 25 de Pinheiro, M. M. .............................. 11 Dias, J. M. ..................................... 15, 21 dos Santos, A. S. ................................... 3

F Farias, F. N. N. ............................. 15, 21 Fdida, S. .............................................. 39

G Gall, F. L. .............................................. 3 Garrett, T. ........................................... 29

J Junior, E. P. D. .................................... 29 Junior, M. A. S. .................................... 7

K Kofuji, S. T. ....................................... 33 Korakis, T. ......................................... 41

M Madeira, E. R. M. ................................ 7 Magalhães, M. F. ............................... 25 Miyake, M. Y. ...................................... 3 Monteiro, J. A. S. ............................... 11

N Nascimento, M. R. ............................. 25

P Pereira, J. H. S. .................................. 33

R Rosa, P. F. .......................................... 33 Rothenberg, C. E. ............................... 25

S Sadok, D. F. H. .................................. 43 Salvador, M. R. .................................. 25 Salvatti, J. J. ................................. 15, 21 Sathya, R. ............................................. 3 Senna, C. R. ......................................... 7 Silva, F. de O. .................................... 33

T Toda, H. S. ................................... 15, 21

Patrocínios:

9 772177 496009

ISSN 2177-496X

Documents

Sociedade Brasileira de Computação (SBC)sbrc2011.facom.ufms.br/files/workshops/wpeif/wpeif.pdf · Luciano Paschoal Gaspary (UFRGS) Membros Institucionais . CEFET-CE, CEFET-PR, IME,