Pesquisa Experimental para a Internet do Futuro

Capítulo

1Pesquisa Experimental para a Internet do Futuro:Uma Proposta Utilizando Virtualização e o Frame-work Openflow

Fernando N. N. Farias, José M. Dias Júnior, João J. Salvatti, Sérgio Silva,Antônio J. G. Abelém, Marcos R. Salvador and Michael A. Stanton

Abstract

The Internet has become a huge worldwide success and is changing the way we interact,work, and amuse ourselves. Much of its success is due to the great flexibility of IP (Inter-net Protocol) technology. Despite all the success of the Internet, IP core technology is thecause of its own limitations, which become increasingly more evident. The main goals ofactivities labeled as Future Internet (FI) are the formulation and evaluation of alternativearchitectures to substitute IP. In this context, two approaches are being discussed and in-vestigated, where the first, called Clean Slate, aims at replacing the current architectureby a new fully rebuilt one, and the second, called Evolutionary, that intends to evolvethe current architecture without losing compatibility with the current one. However, thebiggest challenge now is where to enable and test the proposed approaches in order tovalidate efficiently them without sacrificing the current infrastructure, since there will bethe need for routers and switches to be reconfigured, and resources to be allocated andmonitored. Thus, the network must be as flexible as possible so that this infrastructure al-lows the coexistence of multiple parallel models. In this sense, virtualization (of networkdevices, links, etc.) and the OpenFlow solution are being seen as the best alternatives toenable multiple experiments of new architectures in a production environment. An Open-Flow network allows the programming of network behavior, in addition to creating virtualnetwork environments called slices (virtual networks with nodes, links and resources) totest new protocol models. This short course will be essentially theoretical and starts bypresenting the motivation that is leading professionals and the academic community to

invest in research to investigate the challenges of the Future Internet. Next, recent exper-iments carried out for the Future Internet in Brazil and in research networks in Europe,North America, and Asia will be presented. After that, the OpenFlow framework will bedetailed, including the main aspects of virtualization. We also describe the requirementsfor construction of an experimental testbed, including demonstration and details of themechanisms needed to configure and evaluate such a test environment. A case study ofcreating multiple slices for testing networking protocols will be shown. Finally, futuretrends will be presented regarding the experimental research and the Future Internet.

Resumo

A Internet é um enorme sucesso mundial e vem mudando a forma como interagimos, tra-balhamos e nos divertimos. Boa parte deste sucesso se deve à grande flexibilidade datecnologia IP. Apesar de todo o sucesso da Internet, a tecnologia básica IP é a causadas suas próprias limitações que se tornam cada vez mais evidentes. Um dos principaisobjetivos da atividade conhecida como Internet do Futuro (IF) é a formulação e avali-ação de arquiteturas alternativas para substituir o protocolo IP. Nesse contexto, duasabordagens estão sendo discutidas e investigadas: a primeira denominada limpa (CleanSlate), que visa substituir a arquitetura atual por uma nova totalmente reconstruída, e aoutra chamada evolucionária (Evolutionary) que pretende evoluir a arquitetura atual semperder a compatibilidade com a anterior. No entanto, o maior desafio agora é onde habil-itar e testar as propostas das respectivas abordagens de modo a validá-las eficientemente,sem prejudicar a infraestrutura atual, já que haverá a necessidade de que roteadores eswitches sejam reconfigurados, e recursos sejam alocados e monitorados. Em suma, arede deve ser a mais flexível possível, para que essa infraestrutura permita a coexistên-cia de múltiplos modelos paralelos. Nesse sentido, a virtualização (de rede, dispositivos,enlace e etc.) e a solução OpenFlow vem se tornando uma interessante alternativa parahabilitar múltiplos experimentos com novas arquiteturas em um ambiente de produção.Uma rede OpenFlow admite a programação do comportamento da rede, além da cri-ação de ambientes de rede virtuais chamados fatias (redes virtuais com nós, enlaces erecursos) para testar novos modelos de protocolo. Este minicurso tem como principalobjetivo apresentar os desafios e soluções para se criar um ambiente de testes para aInternet do Futuro utilizando técnicas de virtualização de redes e o framework Open-Flow. O minicurso será essencialmente teórico e apresentará os fatores motivacionaisque vêm levando os profissionais da área e a comunidade acadêmica a investirem na re-alização de pesquisa experimental para investigar os desafios da Internet do Futuro. Emseguida, serão expostas as recentes experiências realizadas para IF, tanto no Brasil comoem backbones da Europa, da América do Norte e da Ásia. Após isso, será detalhado oarcabouço OpenFlow, incluindo os principais aspectos sobre virtualização. Logo depois,serão descritos os requisitos para construção de uma rede para experimentação, coma demonstração e o detalhamento dos mecanismos necessários para configurar e testaresse ambiente. Um estudo de caso de criação de várias fatias de redes para testes deprotocolos também será demonstrado. Por fim, serão apresentadas as tendências futurasem relação à pesquisa experimental em Internet do Futuro.

2 Minicursos Livro Texto

1.1. IntroduçãoA Internet hoje está sendo usada para uma grande variedade de propósitos comerciais enão comerciais. Para muitas pessoas é uma ferramenta de trabalho crucial, para outras, seulocal de trabalho. Porém, para a grande maioria, é um eficiente meio de comunicação, en-tretenimento ou plataforma educacional. Ou seja, a Internet é um enorme sucesso mundiale vem mudando a forma como interagimos, trabalhamos e nos divertimos. Boa parte destesucesso se deve à grande flexibilidade da tecnologia IP (Internet Protocol), que provê ummecanismo uniforme de transporte fim a fim, independente das tecnologias utilizadas nascamadas de mais baixo nível.

Apesar de todo o sucesso da Internet, a tecnologia básica IP é a causa das suaspróprias limitações, que se tornam cada vez mais evidentes. A noção central de tamanhoúnico, que requer tratamento idêntico para todos os fluxos de informação na Internet aonível do pacote IP, não é desejável e nem necessariamente econômica, especialmentequando certas classes de aplicação, tais como de mídia interativa ou de acesso remotoa instrumentos científicos que, requerem garantias de qualidade de serviço (Quality ofService - QoS) desnecessárias para a maioria de outras aplicações.

A atual arquitetura da Internet, inicialmente projetada há aproximadamente 30anos, sofreu muitas extensões nos anos recentes para incluir novas funcionalidades, asquais não foram previstas no projeto inicial. Muitos especialistas de rede agora consid-eram que é necessário conduzir um estudo de arquiteturas alternativas para Internet doFuturo (IF), como uma maneira realmente eficiente de resolver muitos dos problemasprementes que atualmente afligem a Internet. Algumas das desvantagens da continuadapersistência no uso da atual arquitetura incluem:

• Exaustão já anunciada do espaço atualmente disponível de identificadores de redeIP versão 4 (IPv4), causando uma “balcanização” da Internet, sem verdadeira conec-tividade global;

• Custos elevados dos roteadores IP, restringindo o crescimento da rede, motivadoprincipalmente pela natureza não escalonável das tabelas de roteamento, e dos req-uisitos de desempenho necessários para poder processar essas gigantescas tabelasna mesma velocidade que seus enlaces;

• Investimentos imensos em medidas paliativas para conter problemas de segurançaatualmente causados por spam, negação de serviço (DoS - denial of service) ecrimes de roubo de informação;

• Dificuldades de combinar transparência de acesso e desempenho de aplicação parausuários móveis.

Devido a isso, nos últimos anos, vêm sendo aplicadas à arquitetura da Internetuma série de modificações pontuais ou “remendos”, para atender às limitações encon-tradas. Entre os “remendos” mais conhecidos, podem ser mencionados Classless Inter-net Domain Routing (CIDR), Network Address Translation (NAT), Serviços Integrados(Intserv), Serviços Diferenciados (Diffserv), IP Seguro, IP Móvel, firewalls e filtros despam; estes são os mais conhecidos.

XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC 2011 3

Por conta disso, há um entendimento crescente entre os pesquisadores em redesde computadores que soluções para a maioria destes problemas, dependerão de um re-desenho fundamental da atual arquitetura da Internet, baseada em IP. E como aliada nabusca dessas soluções, surge a atividade conhecida como Internet do Futuro, que incluientre seus principais objetivos a formulação e avaliação de arquiteturas alternativas parasubstituir o IP, o qual é frequentemente ilustrado pelo conhecido modelo da ampulheta daInternet, apresentado na Figura 1.1.

Figura 1.1. A evolução do conceito da Internet [Banniza et al. 2009]

Nesse contexto, duas abordagens estão sendo discutidas e investigadas. A primeiradenominada limpa (Clean Slate), que visa substituir a arquitetura atual por uma novatotalmente reconstruída. A outra, chamada evolucionária (Evolutionary), que pretendeevoluir a arquitetura atual sem perder a compatibilidade com a anterior.

A proposta Clean Slate, que atualmente é um dos esforços para o desenvolvi-mento da Internet do Futuro, tem como principal objetivo direcionar como será efetuadoo desenho da nova Internet [McKeown 2011].

Mas para que isso ocorra, a IF deve atender a um conjunto de requisitos impor-tantes. Dentro desse contexto, David Clark [Clack 2011] cita os caminhos e os requi-sitos fundamentais para o sucesso desta nova arquitetura, proposta que Clean Slate irátomar para projetar a IF. Dentre esses requisitos, é possível destacar como os principaisdesafios: robustez e disponibilidade, suporte a nós móveis economicamente viável e ren-tável, gerenciabilidade com segurança e ser evolutiva.

As pesquisas baseadas em Clean Slate permitem explorar radicalmente uma novaarquitetura para Internet, mas isso não quer dizer que serão imediatamente aplicadas.Desse modo, algumas dessas soluções podem ter ou não um caminho viável de implan-tação na Internet atual [Feldmann 2007].

Por outro lado, tem-se a abordagem Evolutionary ou Incremental, que tem a mis-são, como pesquisadores da Internet, de primeiro medir e entender o estado corrente


que se encontra a infraestrutura atual da Internet, para poder prever qual caminho elaseguirá e quais problemas enfrentará. Depois, com isso, criar o que pode ser referenciadocomo uma “inteligente mutação” [Rexford and Dovrolis 2010], ou seja, inovações quepodem, primeiro, afastar ou resolver estes desafios e, segundo, adaptar-se para a correnteinfraestrutura da Internet, de uma forma que seja compatível com as versões anteriores epossa ser incrementalmente expansível.

A adoção de qualquer uma das arquiteturas alternativas pode alterar a situação emque a Internet atual se encontra. Entretanto, um sério obstáculo para adoção efetiva detais inovações tem sido a inabilidade de validá-las de maneira convincente. A redução noimpacto do mundo real de qualquer inovação se deve à enorme base instalada de equipa-mentos e protocolos e à relutância em experimentar com tráfego de produção, o que temcriado uma barreira extremamente alta para a entrada de novas ideias. O resultado é quea maior parte das novas ideias da comunidade de pesquisa de rede não é testada, levandoà crença comumente mantida de que a infraestrutura da Internet “ossificou” ou enrije-ceu [Paul et al. 2011].

Tendo reconhecido o problema, a comunidade de pesquisa de rede está desen-volvendo soluções alternativas para pesquisa experimental em IF. Suas atividades inicias,usando redes para experimentação (testbeds), começaram nos EUA com os programasGlobal Environment for Network Innovations (GENI) [GENI 2011] e Future Internet De-sign (FIND) [FIND 2011], onde suas principais propostas são testar e amadurecer umgrande conjunto de pesquisas em comunicação de dados e sistemas distribuídos.

Além disso, ainda há o programa Future Internet Research and Experimenta-tion (FIRE) na UE (União Europeia) [FIRE 2011] que é uma iniciativa de ambiente depesquisa para experimentação e validação de ideias inovadoras e revolucionárias paranovos paradigmas de redes e serviços. Nesta mesma linha, temos o projeto AKARI noJapão [AKARI 2009], um programa de pesquisa que tem como objetivo implementar anova geração de redes para 2015, baseada na proposta Clean Slate. E por fim, iniciativassemelhantes também foram lançadas mais recentemente na Coreia [Liu et al. 2009] e naChina [Bi 2011].

Neste sentido, redes de experimentação programáveis e virtualizadas vêm sendoutilizadas por esses projetos para diminuir a barreira de custo à entrada de novas ideias,aumentando a taxa de inovação da infraestrutura de rede. Com isso, são oferecidas in-fraestruturas capazes de habilitar, controlar e testar as respectivas abordagens, de modo avalidá-las eficientemente, sem prejudicar a infraestrutura atual.

No contexto de redes programáveis, o arcabouço OpenFlow é uma solução quevem oferecendo aos pesquisadores a possibilidade de testar seus protocolos experimentaisem redes de produção como: redes de um campus, redes metropolitanas ou em um back-bone de rede de ensino e pesquisa [McKeown et al. 2008]. O OpenFlow, além de ofere-cer o protocolo de controle, chamado de OpenFlow protocol para manipular a tabela deencaminhamento dos roteadores e switches, também oferece uma API (Application Pro-gramming Interface) simples e extensível para programar o comportamento dos fluxos depacotes. Desta forma que, através desta API, pesquisadores podem rapidamente construirnovos protocolos e aplicá-los em um ambiente de produção sem prejudicá-lo.


A virtualização de computadores tem sido usada há muito tempo e hoje está am-plamente disponível em plataformas comuns. É realizada por meio do compartilhamentode processadores e dispositivos de E/S, utilizando técnicas de fatiamento de tempo ememória virtual. A virtualização de redes, a mais recente, é conseguida pelo uso deswitches, roteadores virtuais e a multiplexação de enlaces [Chowdhury and Boutaba 2010].

Observando isso, o uso das técnicas de virtualização de redes (dispositivos, enlace,etc.) em conjunto com a solução OpenFlow vem se tornando uma excelente alternativapara habilitar múltiplos experimentos com novas arquiteturas em um ambiente de pro-dução. Uma rede OpenFlow permite que se possa programar o comportamento da rede,além de criar ambientes virtuais de rede chamados de “fatias” (redes virtuais com nós,enlaces e recursos) para testar novas ideias e modelos de protocolos para IF.

Este minicurso tem como principal objetivo apresentar as iniciativas para o de-senvolvimento da IF, seus requisitos necessários e o uso de virtualização e OpenFlowpara se criar um ambiente de testes para experimentação e desenvolvimento de protoco-los na abordagem de IF. Além desta seção introdutória, o artigo está dividido da seguintemaneira:

• Seção 2 - são apresentadas as recentes experiências realizadas para Internet do Fu-turo, tanto no Brasil como em backbones da Europa e da América do Norte;

• Seção 3 - é detalhado o framework OpenFlow, incluindo os principais aspectossobre virtualização;

• Seção 4 - são descritos os requisitos para construção de um testbed experimental;

• Seção 5 - tem-se um estudo de caso de criação de vários slices de redes para testesde protocolos;

• Seção 6 - são apresentadas as considerações finais e tendências futuras em relaçãoà pesquisa experimental e Internet do Futuro.

1.2. Pesquisa Experimental em Internet do Futuro no Brasil e no MundoAtualmente, na comunidade acadêmica, existe um amplo consenso de que a Internet atualsofre várias limitações relacionadas com escalabilidade, suporte a redes móveis de váriostipos (ad-hoc, multi-hop e mesh), mobilidade, ao consumo de energia, à transparência, àsegurança e outras [Jain 2006].

A partir disso, nesta seção, são levantados e comentados os principais desafiosque estão relacionados à Internet do Futuro. Como também, são observados os projetosa respeito de investigação da IF como o caso do GENI (Global Environment for NetworkInnovation), financiado pela NSF (National Science Foundation), FIRE (Future InternetResearch and Experimentation), pela União Europeia e por iniciativas brasileiras.

1.2.1. Desafios Relacionados à Internet do Futuro

O conceito básico da arquitetura da Internet foi desenvolvido há mais de trinta anos atrás.Neste tempo, tem-se aprendido bastante sobre redes de computadores e encaminhamento


de pacotes. Também, durante este mesmo período, a Internet vem sofrendo contínuasadaptações, causadas pelo seu rápido crescimento e pela quantidade de usuários e apli-cações habilitadas sobre sua arquitetura. Essas adaptações ou “remendos” demonstramque o projeto inicial já não se ajusta às necessidades atuais na rede. Além disso, a arquite-tura atual da Internet já apresenta inúmeros problemas ainda não solucionados, impedindoo atendimento dos requisitos destas novas aplicações e serviços.

Muitos especialistas em rede de computadores chegaram a um consenso de queagora consideram extremamente importante realizar estudos de arquiteturas alternativaspara Internet do Futuro como uma maneira realmente eficiente de resolver muitos dosproblemas prementes que atualmente afligem a Internet. A seguir, são apresentados al-guns dos principais desafios, que, segundo Paul [Paul et al. 2011], a nova arquitetura daInternet deve atender.

a. Suporte a Novas Tecnologias de Rede

A Internet atual é projetada para tirar vantagem de uma grande gama de tecnologias decomunicação em rede. No entanto, hoje há vários desafios no horizonte, entre elas astecnologias sem fio e as novas soluções ópticas

As redes sem fio abrangem uma série de tecnologias que vão do Wi-Fi de hoje atéas ultra-widebands e redes de sensores sem fio de amanhã. Considera-se que as redes semfio são talvez umas das maiores tecnologias de rede e com granularidade maior ou igualàs redes locais (LAN). No entanto, uma consequência das redes sem fio é a mobilidade.Atualmente, a mobilidade está na “borda” da rede, mas, os mecanismos para torná-lamais eficiente não funcionam de maneira satisfatória. Principalmente, nas questões rela-cionadas à eficiência energética, mudança de ponto de acesso e aplicações. Portanto,identificam-se os seguintes desafios para suporte às tecnologias sem fio:

• a Internet do Futuro deve suportar a mobilidade como o objetivo primordial em suaconstrução. Os nós devem ser capazes de modificar seu ponto de acesso na Internete, mesmo assim, continuarem sendo alcançáveis

• a Internet do Futuro deve oferecer meios adequados para uma aplicação de descobriras características dos mais variados tipos de enlace de rede sem fio e se adaptar aeles, de maneira a prover as eficiências energéticas destes nós.

• a Internet do Futuro deve facilitar o processo pelo qual os nós móveis, fisicamentepróximos, descubram-se uns aos outros.

Outra tecnologia revolucionária é a rede de transporte óptica. A comunidade depesquisadores em redes ópticas está desenvolvendo maneiras de como usar as novas tec-nologias como comutadores ópticos e elementos lógicos para encaminhar dados comtaxas de transmissão muito maiores que as redes puramente eletrônicas. Isso envolvemudanças em vários níveis: de redes em anéis para redes em malha; de redes com com-primentos de ondas fixamente alocados para transmissores (e receptores) dinamicamentesintonizados; de redes sem buffers ópticos para redes com planos de controles inteligentes


e com buffers ópticos suficientes; e de redes ópticas que utilizam larguras de bandas fixaspara as que permitem que a largura de banda seja dinamicamente alocada, acessada e uti-lizada. Logo se identificam os desafios para Internet do Futuro poder explorar a emergentecapacidade óptica:

• a Internet do Futuro deve ser projetada para permitir aos usuários utilizarem es-sas novas capacidades de transporte ópticos, incluindo uma melhor confiabilidadeatravés de diagnósticos entre camadas;

• a Internet do Futuro deve permitir que os nós que são dinamicamente configuráveishabilitem a camada eletrônica para o acesso dinâmico de usuários;

• a Internet do Futuro deve incluir softwares de controle e gerenciamento que per-mitam à rede formada por nós dinamicamente reconfiguráveis ser configurada poraplicações que necessitem de uma grande quantidade de recursos de rede, tal comolargura de banda

b. Segurança e Robustez

Talvez a razão que mais estimulou a comunidade acadêmica a pensar em um redesenhoda Internet foi a possibilidade de ter uma rede com grandes avanços na segurança e narobustez. Na Internet atual, não há nenhuma abordagem, realmente abrangente para tratarquestões de segurança. Ela possui muitos mecanismos, mas não uma “arquitetura segura”e muito menos um conjunto de regras determinando como esses mecanismos devem sercombinados para se obter uma boa segurança de maneira geral. A segurança em redes eprincipalmente a da Internet, atualmente se assemelha a um conjunto crescente de remen-dos, extremamente suscetível a falhas.

Para construção de uma rede mais robusta e segura, identificam-se os seguintesdesafios:

• qualquer conjunto de hosts deve ser capaz de se comunicar entre si com alta confi-abilidade e previsibilidade e nós maliciosos ou defeituosos não podem ser capazesde interromper esta comunicação. Além disso, os usuários devem esperar por umnível de disponibilidade correspondente ou que exceda o sistema de telefonia dehoje;

• a segurança e robustez devem ser estendidas através de suas camadas, pois a segu-rança e confiabilidade de um usuário final dependem da robustez, tanto nas camadasde comunicação quanto nas aplicações distribuídas.

c. Eficiência Energética na Comunicação

Atualmente, há uma preocupação mundial [Joseph and Lewis 2008] pelo desenvolvimentode tecnologias que diminuam o consumo de energia, principalmente em redes, como as desensores sem fio e as de dispositivos móveis Wi-Fi, onde recursos energéticos são fatores


relevantes em sua comunicação. Com as atuais tecnologias, comunicando um bit sobreum meio sem fio, em intervalos curtos, consomem mais energia do que o seu processa-mento, e não possui tendência de mudanças em um futuro próximo [Chen, 2006]. Noentanto, a Internet atual não possui mecanismos que levem em consideração a comuni-cação com requisitos de eficiência de energia, de modo a adaptar o seu consumo mediantea observação do meio. Ou ainda, que adapte o uso de energia para oferecer uma comu-nicação eficiente, na transmissão de dados e no gerenciamento de rede, a baixos níveisenergéticos.

Portanto, como desafio para o projeto da Internet do Futuro:

• deve-se prover meios para uma eficiência energética generalizada tanto para dispos-itivos sem fio quanto os com fio;

• desenvolver tecnologias com o foco no uso eficiente da energia elétrica;

• incluir em sua arquitetura mecanismos que ofereçam uma comunicação eficientetanto na transmissão de dados como no gerenciamento de rede;

• prover uma arquitetura para Internet do Futuro energeticamente otimizada.

d. Separação de Identidade e Endereço

Na Internet atual, um sistema é identificado pelo seu endereço IP. Como resultado, quandoo sistema mudar a localização do ponto da sua interligação, seu endereçamento tambémpode mudar. Ou seja, o endereço IP, neste caso, ao mesmo tempo, tem o papel de iden-tificador e localizador. Devido a isso, os nós móveis se tornaram um desafio na Internetatual. Por essas características, torna-se difícil iniciar a comunicação com um sistemamóvel.

Este é um problema bem conhecido na Internet e há um número considerável detentativas e propostas para resolver esse problema, incluindo: mobile IP, Internet indirec-tion infraestructure [Stoica et al. 2004], host identify protocol [Moskowitz et al. 2005] eoutros [Balakrishnan et al. 2004].

Assim, para a Internet do Futuro existem os seguintes desafios:

• aplicar soluções que permitam a localização global de um determinado host, atravésda utilização de um sistema de endereçamento global;

• definir novas formas de localização e identificação, além do desenvolvimento deendereçamentos coesos às necessidades da rede.

e. Qualidade de Serviço e Qualidade de Experiência

A natureza do IP, não orientado a conexão, dificulta qualquer aplicação de garantia deQoS (Quality of Service - qualidade de serviço). Além disso, a característica de en-caminhamento de pacote baseado em melhor esforço faz com que qualquer abordagem


relacionada a questões de reservar de recursos ou prioridade interfira no funcionamentoestabelecido para Internet atual.

Desta maneira, embora a qualidade de serviço tenha sido extremamente pesquisadana comunidade acadêmica ainda não há um modelo claro de como diferentes níveis dequalidade devem ser aplicados e de que forma ele se integrar arquitetura de rede atual.

Desta fora, são desafios para arquitetura da Internet do Futuro:

• permitir uma variedade de garantias levando em consideração tanto a qualidade daaplicação na rede como a qualidade de experiência do usuário;

• novos métodos de encaminhamentos de pacote baseados nas características dasaplicações, principalmente as de tempo real.

f. Separação entre os Planos de Controle, Gerenciamento e Dados

Na Internet atual, os planos de controle, gerenciamento e dados são unificados, ou seja,mensagens de controle, por exemplo, mensagens de conexão TCP (Transmission ControlProtocol) ou mensagens de gerenciamento SNMP (Simple Network Management Proto-col), seguem no mesmo canal em que trafegam os dados. Como consequência, ocorrea possibilidade de um significante risco de segurança dos dados de controle, além dodesperdício de recursos da rede.

Uma vantagem desta separação de planos é a adoção de novas tecnologias de planode dados pela arquitetura de rede como: um comprimento de onda; quadro SDH; ou umalinha de transmissão de energia (Power Line Comunication - PLC). Logo a separaçãoentre os planos deve ser parte integrante desta próxima geração da arquitetura da Internet.

g. Isolamento

Para algumas aplicações críticas, o usuário demanda isolamento em um ambiente compar-tilhado como na Internet atual. Isolamento significa garantir que o desempenho desta apli-cação crítica não seja afetado por outras aplicações que queiram compartilhar o mesmorecurso.

Com o uso da virtualização, o isolamento se tornou um fator ainda mais impor-tante, principalmente para virtualização de redes, onde um roteador ou uma infraestruturade rede é totalmente virtualizada, de forma que o encaminhamento de pacotes não pode,de maneira alguma, sofrer interferências de, ou causá-las em outras infraestruturas.

Assim, a próxima geração da Internet deve prover em sua arquitetura um modoeficiente de prover uma combinação programável de isolamento e compartilhamento àssuas aplicações e serviços.


h. Mobilidade

Com a crescente e diversificada quantidade de serviços na Internet, impulsionada princi-palmente pelo aumento do acesso de dispositivos sem fio. Amplia-se a necessidade demobilidade pelos usuários.

Com isso, a forma de comunicação estabelecida originalmente pela arquitetura daInternet atual como conexão ponto-a-ponto e entrega imediata, faz com que esses tiposde usuários não sejam atendidos satisfatoriamente. Principalmente, por causa de umaquestão comum relacionada à mobilidade, que são os handovers, criados com o objetivode evitar que os nós móveis tenham a perda das suas conexões ativas. Os protocolos daInternet atual não prevêem o tratamento desse comportamento. E ainda, protocolos comoTCP também são prejudicados por não prever esse tipo de usuário.

Com isso, a Internet do Futuro enfrenta o grande desafio de como permitir a movi-mentação do nó entre diferentes pontos de acesso sem que as conexões ativas sejam per-didas.

i. Escalabilidade

Com o aumento exponencial do número de estações ou sistemas conectados à Internet,alguns componentes da arquitetura atual têm sofrido com problemas de escalabilidade.Esse é o caso do sistema de roteamento, que sofre com o aumento e as atualizações fre-quentes de suas tabelas. Ainda há a questão dos endereçamentos que não são capazes desuportar todos os elementos conectados à rede, como é o caso do IPv4.

Portanto, a Internet do Futuro terá o desafio de manter o sistema global de rotea-mento escalável, além de novos protocolos que mantenham essa escalabilidade, mesmocom o aumento do espaço de endereçamento. E também novas formas de endereçamentopara evitar a escassez do recurso.

1.2.2. Iniciativas para Investigação em Internet do Futuro

Na comunidade de pesquisa em redes, há muito tempo atento ao crescimento de proble-mas da Internet, aumentou-se o interesse em estudar os desafios da Internet do Futuro e,com isso, modelar a arquitetura que conduzirá a um nova geração da Internet.

No entanto, estas novas propostas e especulações teóricas na direção destas soluçõesdeveriam ser suportadas por uma infraestrutura real de rede experimental e testadas emambientes de larga escala. Estas instalações experimentais desempenhariam o papel derede para experimentação ou ambiente de tese (testbed), possibilitando experimentos paraa prova de conceitos de novas arquiteturas, protocolos, tecnologias e serviços.

Uma coexistência com a rede de tráfego de produção é essencial para observaçãoe captura de certos aspectos e fenômenos perceptíveis apenas em instalações operacionaise assim permitir que sejam avaliados os seus impactos sobre a sociedade e a economia.

Observando essas necessidades, algumas iniciativas em pesquisa na Internet doFuturo começaram a surgir, em fiferentes cantos do mundo, conforme a seguir.


1.2.2.1. GENI (Global Environment for Network Inovation)

O Global Environment for Network Innovation (GENI) é a principal iniciativa norteamer-icana em investigação e experimentação em Internet do Futuro. O GENI é um conjunto deinfraestruturas de redes para experimentação, dos mais variados modelos tais como: semfio, óptico e elétrico. Patrocinado pela National Science Fundation (NSF) desde 2005,atualmente está em fase de desenvolvimento e prototipagem.

O objetivo do GENI é montar um grande laboratório em larga escala para experi-mentações em redes de computadores, onde a maior importância é validar novas possibil-idades para Internet do Futuro.

Para o GENI, os conceitos principais relacionados à experimentação em Internetdo Futuro e que fazem parte do projeto de sua arquitetura são [GENI-Sys 2008]:

Programabilidade: Os pesquisadores poderão carregar software nos nós do GENI paramodificar o seu comportamento;

Virtualização e outras formas de compartilhamento de recursos: Qualquer que seja aimplementação de máquina virtual sobre um nó GENI, será permitido que múltiplospesquisadores simultaneamente compartilhem a mesma infraestrutura. Cada exper-imento terá à sua disposição uma fatia isolada, com recursos fim-a-fim alocadosdentro do infraestrutura do GENI;

Federação: O GENI será composto por infraestruturas próprias e por outras de apoio,operadas por organizações parceiras ao projeto, criando o conceito de uma feder-ação de recursos e nós, que, na visão de um pesquisador, comportar-se-á como sefosse uma única infraestrutura;

Experimentos baseados em fatias (Slices): Cada experimento no GENI será realizadasobre uma plataforma composta de um conjunto de recursos reservados em diversaslocalizações, chamada de uma fatia de recursos. Dentro dessa fatia o pesquisadorpoderá remotamente descobrir, reservar, configurar, “depurar”, operar e gerenciarseus experimentos e recursos disponíveis.

Para se ter uma ideia de como o GENI irá funcionar após a sua concepção, aFigura 1.2 ilustra o fluxo que um pesquisador percorrerá para habilitar seu experimentodentro da infraestrutura do GENI.

Na Figura 1.2 é ilustrado o processo que um pesquisador irá executar para solic-itar e utilizar uma fatia para experimentação de seus modelos ou protocolos no ambienteGENI. Esse processo é formado por três estágios intermediários: descoberta de recurso,criação da fatia e experimentação.

Na descoberta de recursos (DR), Figura 1.2(a), o pesquisador terá uma visãoglobal dos recursos disponíveis para o seu experimento. A partir disso, poderá definir,de maneira simples, quais os recursos do GENI serão utilizados em seus experimentos.

Na criação da fatia, Figura 1.2(b), o pesquisado recebe uma fatia ou contêinervazio onde serão instanciados os recursos e o software que foram definidos pela DR.


Figura 1.2. A criação de um fatia sobre a infraestrutura do GENI [GENI-Sys 2008]

Neste caso, uma fatia é uma integração de dois agregados: um cluster de computadores euma rede ou um conjunto de redes.

Por fim, na experimentação, Figura 1.2(c), o pesquisador poderá instalar os seussoftwares, executar, parar e coletar resultados do experimento.

O GENI pode ser visto como a confluência de vários grandes ambientes de teste,oferecendo alternativas para experimentação em redes. Dentre estes ambientes de testepodemos destacar: PlanetLab, ORBIT e EmuLab [Spiral2 2010] [Paul et al. 2011].

PlanetLab

O PlanetLab [Peterson et al. 2006] é um grande laboratório para testes e desenvolvi-mento de aplicações distribuídas, criado a partir de 2002 por um consórcio de instituiçõesacadêmicas, governamentais e industriais, que montou uma grande malha de computa-dores espalhados pelo mundo em diversas redes. Hoje, possui mais de 1050 máquinas es-palhadas em mais de 550 locais diferentes, em todos os continentes (v. http://www.planet-lab.org/). O projeto é dirigido a partir da Universidade de Princeton, EUA, mas há seg-mentos, por exemplo, na Europa, onde há outros centros de desenvolvimento e controledos recursos comuns.

O PlanetLab foi pioneiro no uso amplo dos conceitos de virtualização dos nós ede criação de fatias de recursos virtuais e dedicados nos nós usados num experimento. NoBrasil há participação do consórcio desde 2004.


No projeto GENI, o PlanetLab GENI [Spiral2 2010], será uma alternativa de redepara experimentação para seus pesquisadores. O grupo de Princeton dirige esta ativi-dade e tem como escopo integrar logicamente os componentes GENI aos serviços Plan-etLab como: PLC (PlanetLab Central Sofware), responsável por criar a rede sobrepostadefinindo a topologia virtual que será usada para experimento; e o SFA (Slice-Based Fa-cility Architecture), responsável por localizar e alocar os recursos para os experimen-tos [Peterson et al. 2009].

ORBIT

O projeto ORBIT provê um rede sem fio flexível aberto à comunidade acadêmica paraexperimentação. Ele foi desenvolvido para que pesquisadores entendessem as limitaçõesdo mundo real das redes sem fio, que muitas vezes não são percebidas em simulaçõespor causa das simplificações aplicadas ao modelo ou por terem sido aplicadas em umaquantidade pequenas de nós.

O ORBIT possui dois ambientes de teste no campus da Universidade Rutgers: oprimeiro é dentro de um laboratório, constituído por 400 nós dispostos em uma grade20x20 (ilustrado na Figura 1.3), separados por um metro de distância entre os nós adja-centes, onde cada nó é composto por uma plataforma PC com múltiplas interfaces sem fioe com fio. O segundo está localizado ao ar livre , numa área de 1,5 hectares. Entre elesexistem nós fixos, e também nós móveis para prover mobilidade entre os roteadores (v.http://www.orbit-lab.org/wiki/WikiStart).

Figura 1.3. ORBIT Testbed Indoor

No GENI, sua integração permitirá que pesquisadores gerenciem esse ambientede redes sem fio dentro do GENI, além estender a capilaridade de nós do ORBIT paraoutros ambientes sem fio. No GENI, o ORBIT será integrado dentro do ambiente OMF(cOntrol and Management Framework) [OMF 2011].


EmuLab

EmuLab [Eide et al. 2006] é um ambiente de teste em redes de computadores que ofereceaos seus pesquisadores um leque de ambientes nos quais eles podem desenvolver, analisare avaliar seus sistemas. O nome EmuLab refere-se tanto ao ambiente de teste quanto aosoftware de interação do usuário com ele.

O projeto é gerenciado pela Universidade de Utah, onde foram desenvolvidos osprimeiros nós do EmuLab. Atualmente, há mais de doze países utilizando o EmuLab,totalizando uma rede para experimentação com mais de cem nós. No Brasil, há um nódesta rede instalado na USP (v. http://www.emulab.net/).

Na Figura 1.4 temos os clusters de computadores utilizados pelo EmuLab. Os am-bientes disponíveis no EmuLab são: Emulação (Emulation), neste ambiente, o pesquisadordefine uma topologia arbitrária com switches ou roteadores e nós PC; Live-Internet, ondeo Emulab oferece um ambiente federado para experimentos sobre Internet; No 802.11Wireless, provê um ambiente com ponto de acesso, roteadores e cliente para experimen-tos em rede sem fio; e o ambiente Software-Defined Radio o qual permite experimentaçõesem camada 1 para análise de processamento de sinal.

Figura 1.4. Cluster EmuLab

No GENI, a integração do EmuLab ao projeto deu origem a um subprojeto con-hecido como ProtoGENI [ProtoGENI 2011], e permitirá ao EmuLab expandir ainda maisseu ambiente de teste, além de controlar novos não oferecidos atualmente, por exemplo,à infraestrutura de altíssima velocidade da rede Internet2.


1.2.2.2. Future Internet Research and Experimentation (FIRE)

A iniciativa FIRE (Future Internet Research and Experimentation) na Europa visa apesquisa experimental e ao financiamento de projetos que produzam infraestruturas paraexperimentação em Internet do Futuro. A meta é que as pesquisas em tecnologias paraInternet do Futuro sejam direcionadas à rede ou a serviço e tenham a possibilidade decomparar as soluções correntes com as propostas futuras. Desta forma, afirma-se que oFIRE possui duas dimensões relacionadas que direcionam suas pesquisas e seus investi-mentos [FIRE 2008]:

Pesquisa Experimental: o objetivo é integrar a pesquisa multidisciplinar e a experi-mentação em larga escala. A partir daí, definir uma metodologia que direcionarápesquisa experimental na infraestrutura FIRE, baseada em um ciclo interativo quevai da pesquisa, passando pelo projeto e chegando à experimentação;

Facilidades para Testes: o objetivo é oferecer múltiplos ambientes de teste, suportandovárias tecnologias e interligados e federados entre si para permitir a realizaçãode experimentos envolvendo dois ou mais dos ambientes distintos. Deste modopretende-se que FIRE seja sustentável, renovável, dinâmico e integrado em largaescala. Deverá ainda facilitar a pesquisa experimental na comunidade acadêmica,nos centros de pesquisa e na indústria.

Para o FIRE, as experiências práticas são essenciais para dar credibilidade e lev-antar o nível de confiança na conclusão da pesquisa. Além disso, a experimentação deveser executada em larga escala para que seja representativa, convincente e, para provar aescalabilidade da solução, testada. Os projetos de ambiente de teste em destaque aqui,financiados pela iniciativa FIRE incluem [FIRE 2010]: BonFIRE, CREW e OFELIA.

BonFIRE

A iniciativa BonFIRE (Building Services Testbeds on FIRE) [BonFIRE 2011] é um pro-jeto baseado em nuvens em múltiplos locais para o suporte à pesquisa de aplicações,serviços e sistemas, visando a “Internet de Serviços” dentro da Internet do Futuro. O Bon-FIRE objetiva oferecer aos pesquisadores acesso a um ambiente experimental em largaescala para experimentação de seus sistemas e aplicações, avaliações do efeito “cross-cutting” da convergência dos serviços, infraestrutura de rede e a análise do impacto so-cioeconômico.

O BonFIRE irá operar uma nuvem baseada em IaaS (Infrastructure as a Service)com políticas e melhores práticas de experimentações. Ele irá se adaptar a uma abor-dagem multiplataforma federada provendo interconexão e interoperação entre os serviçose a rede no ambiente de teste. A plataforma irá oferecer serviços avançados e ferramen-tas para pesquisa de novos serviços, incluindo nuvens de federações, gerenciamento demáquinas virtuais, modelagem, gerenciamento do ciclo de vida a experimentação, moni-toramento da qualidade de serviço e análise de desempenho.


CREW

O principal objetivo do CREW (Cognitive Radio Experimentation World) [CREW 2011]é estabelecer uma plataforma de teste aberta e federada que facilite o avanço em pesquisaem sensoriamento de espectros, rádios cognitivos e estratégias de redes cognitivas emvisões horizontais e verticais do espectro compartilhado em bandas licenciadas e nãolicenciadas. A Figura 1.5 ilustra a topologia e as tecnologias utilizadas no ambiente deteste.

Figura 1.5. Ambiente federado CREW [FIRE 2010]

O CREW incorpora quatro ambientes individuais de teste de rede sem fio uti-lizando um leque de tecnologias sem fio como: heterogêneos ISM, Celular e Sensoressem fio, com o estado da arte de plataforma de sensoriamento cognitivo.

O CREW irá fisicamente e virtualmente federar componentes interligando enti-dades de software e hardware de diferentes padrões usando APIs padronizadas. Alémdisso, o CREW estabelecerá um “benchmark framework” (arcabouço de controle padrão),habilitará experimentos controlados, metodologias para análise automática de perfor-mance e reproduzirá condições para teste.

OFELIA

O projeto OFELIA [OFELIA 2011] visa criar um ambiente para experimentação que tam-bém permita a seus pesquisadores o controle a redes da sua maneira de forma precisa edinâmica. Para alcançar isso, o ambiente OFELIA é baseado em OpenFlow, atualmenteuma tecnologia de rede emergente que permite virtualizar e controlar ambientes de redeatravés de interfaces seguras e padronizadas (v. seção 4.3.1). O OFELIA proverá equipa-mentos OpenFlow de alto desempenho para habilitar experimentos em alta escala.

A infraestrutura federada pelo OFELIA inclui “ilhas” (ambientes de teste locais)OpenFlow na Bélgica, Alemanha, Espanha, Suíça e Reino Unido. Essas ilhas reúnem umadiversidade de infraestruturas baseadas em OpenFlow que permitirá experimentações em


redes multicamadas e multitecnologicas. Na Figura 1.6 é apresentada como a estruturadessas ilhas serão instaladas em cada um desses países.

Figura 1.6. Estrutura de uma “ilha”, baseada em OpenFlow no projeto OFE-LIA [OFELIA 2011]

O OFELIA permitirá o teste de novos algoritmos de roteamento, tunelamento,protocolos e planos de controle. Além disso, novas aplicações poderão ser colocadas nocontrolador OpenFlow a qualquer momento na infraestrutura. Também permitirá sereminvestigadas novas estruturas e formatos de endereçamento e modelos de encaminhamen-tos.

1.2.2.3. Iniciativas Brasileiras

Os parceiros brasileiros contribuem no projeto com a experiência na implantação de in-stalações de experimentações locais e na participação em diferentes projetos de pesquisaexperimental em Internet do Futuro, embora com pouca ou nenhuma coalizão estratégicaentre elas. O primeiro desses projetos a destacar-se é o de pesquisa e desenvolvimentoGIGA e suas instalações experimentais em grande escala conhecido como rede GIGA,coordenado conjuntamente pelo CPqD e a RNP [Scarabucci et al. 2005].

O projeto GIGA atualmente se concentra em redes ópticas e as definidas por soft-ware. Deverá ser atualizado em breve com comutadores OpenFlow de 10G (o primeirona América do Sul) e uma solução aberta (“open-source”) de roteamento de pacotes (oprimeiro do mundo e neste momento disponível para parceiros selecionados nos EUA eno Brasil) que roda sobre o NOX para controlar o encaminhamento de pacotes em redescom tecnologia OpenFlow habilitada.

A rede GIGA conecta mais de 66 laboratórios de 23 instituições da Região Sud-este do Brasil e está conectada com a rede nacional da RNP (Rede Ipê). Através desta,interliga-se com redes de pesquisa e ensino em todo o mundo. A rede GIGA mantém umnó GENI, ou seja, servidores, no CPqD.

O segundo projeto de destaque é o projeto Web Science [WEBSCIENCE, 2010],


apoiado pelo CNPq dentro do programa Institutos Nacionais de Ciência e Tecnologia(INCT). O projeto Web Science começou efetivamente em 2010 e o subprojeto de Ar-quiteturas para a Internet do Futuro envolve a RNP, e 4 Universidades parceiras (UFF,UFPA, UNIFACS e USP), com experiência em redes ópticas e sem fio, estudos de sim-ulação e emulação e monitoramento de rede. Um dos primeiros objetivos do projeto éestabelecer ilhas experimentais nos laboratórios de cada parceiro e interligá-las em ca-mada 2 através das redes de Ipê e GIGA.

1.3. OpenFlow e Virtualização1.3.1. O OpenFlow

A pesquisa na área de arquiteturas de redes de computadores possui diversos desafiosem relação à implementação e experimentação de novas propostas em ambientes reais.Isso ocorre devido à dificuldade para o pesquisador possuir uma rede de testes próximade uma rede real. Para isso foi desenvolvido o OpenFlow [McKeown et al. 2008], quepropõe um mecanismo para permitir que redes reais sejam utilizadas como um ambientede experimentos.

O OpenFlow é uma proposta tecnológica que, baseada na separação dos planosde controle e de dados em comutadores de pacotes, permite que pesquisadores executemseus experimentos em redes utilizadas no dia-a-dia, sem interferir no tráfego de produção.A proposta é fundamentado em comutadores Ethernet comerciais e define um protocolopadrão para controlar o estado destes comutadores (tabela de fuxos, estatísticas e etc.). Oconceito de fluxo é o bloco fundamental que habilita aos pesquisadores definir o planode encaminhamento na rede, conforme os objetivos definidos pelas novas propostas dearquiteturas e protocolos de rede. O OpenFlow também define um novo elemento derede, o controlador, e software de controle que executa nele, entre os quais o softwareNOX criado pelo grupo OpenFlow da U. Stanford (v. Seção 4.3.1.3).

No OpenFlow é proposto um mecanismo que é executado em todos os comuta-dores ou roteadores de forma que se possa haver isolamento entre os tráfegos, o exper-imental e o de produção. Assim, o OpenFlow possibilita que os pesquisadores repro-gramem os comutadores, sem provocar interferência na configurações da rede de pro-dução. Outro objetivo dessa proposta é permitir que os fabricantes possam incluir asfuncionalidades do OpenFlow nos seus comutadores sem necessitarem expor o projetodesses equipamentos.

Além disso, tais equipamentos devem possuir um custo baixo e desempenho semel-hante aos já utilizados nas redes de produção, tanto nas universidades como nas redes depesquisa, de forma que os administradores destas redes aceitem a substituição dos equipa-mentos já existentes. Com base no exposto, o projeto do OpenFlow tem como objetivoser flexível para atender aos seguintes requisitos:

• possibilidade de uso em implementação de baixo custo e de alto desempenho;

• capacidade de suportar uma ampla gama de pesquisas científicas;

• garantia de isolamento entre o tráfego experimental e o tráfego de produção;


• consistência com a necessidade dos fabricantes não exporem o projeto de suasplataformas.

O OpenFlow explora a tabela de fluxo que já existe nos comutadores atuais, enormalmente são utilizadas para implementar serviços como NAT, firewall e VLANs. Ocomutador OpenFlow é constituído de uma tabela de fluxos e um evento associado a cadaentrada na tabela. Basicamente, a arquitetura do OpenFlow é composto por três partes:

Tabela de Fluxos: Cada entrada na tabela de fluxos contém uma ação associada, e con-siste em Campos do cabeçalho (utilizado para definir um fluxo), ações (define comoos pacotes devem ser processados e para onde devem ser encaminhados) e conta-dores (utilizados para estatísticas ou remoção de fluxos inativos).

Canal Seguro: Para que a rede não sofra ataques de elementos mal intencionados, oSecure Channel assegura confiabilidade na troca de informações entre o comutadore o controlador. A interface utilizada para acesso ao tráfego é o protocolo SecureSocket Layer (SSL). O NOX também suporta outras interfaces (passivas ou ativas),TCP e PCAP. Essas são bem úteis em ambientes virtuais, pela simplicidade deutilização, pois não necessitam de chaves criptográficas.

Protocolo OpenFlow: Disponibiliza um protocolo aberto para estabelecer a comunicaçãoentre o comutador e o controlador. Ao fornecer uma interface externa que atue so-bre os fluxos de um comutador, o Protocolo OpenFlow (OFP - OpenFlow Protocol)evita a necessidade de um comutador programável.

1.3.1.1. Aplicações

Como visto anteriormente, o OpenFlow permite o experimento de novas propostas na áreade Redes de Computadores, utilizando uma infraestrutura de rede já existente. Dentre ospossíveis experimentos permitidos, podem ser citados os seguintes [McKeown et al. 2008]:

Novos Protocolos de Roteamento: Os algoritmos de um protocolo de roteamento podemser implementados para executarem no controlador de uma rede OpenFlow. Assim,quando um pacote do experimento chegar a um comutador, ele é encaminhado parao controlador, que é responsável por escolher a melhor rota para o pacote seguir narede a partir dos mecanismos do protocolo de roteamento proposto. Após isso, ocontrolador adiciona entradas na Tabela de Fluxos de cada comutador pertencenteà rota escolhida. Os próximos pacotes desse fluxo que forem encaminhados na redenão necessitarão serem enviados para o controlador;

Mobilidade: Uma rede OpenFlow pode possuir pontos de acesso sem-fio, permitindoque clientes móveis utilizem sua infraestrutura para se conectarem a Servidores ouà Internet. Assim, mecanismos de handoff podem ser executados no Controladorrealizando alteração dinâmica das tabelas de fluxo dos comutadores de acordo coma movimentação do cliente, permitindo a redefinição da rota utilizada;


Redes Não-IP: Como visto anteriormente, um comutador OpenFlow pode ser desen-volvido para analisar campos arbitrários de um pacote, permitindo flexibilidade nadefinição do fluxo. Assim, podem ser testadas, por exemplo, novas formas de en-dereçamento e roteamento. Nos comutadores do “tipo 0”, os pacotes Não-IP podemser definidos pelo endereço MAC de origem ou destino ou a partir de um novo Tipode Ethernet ou IP;

Redes com Processamento de Pacotes: Existem propostas de protocolos que realizamprocessamento de cada pacote de um fluxo como, por exemplo, os protocolos deRedes Ativas. Esse tipo de proposta pode ser implementado no OpenFlow forçandoque cada pacote que um comutador receba seja enviado para o Controlador paraser processado. Outra alternativa é enviar esses pacotes para processamento por umcomutador programável, como é o caso de um roteador programável baseado emNetFPGA [Lockwood et al. 2007].

1.3.1.2. Modos de funcionamento dos Switch

Existem dois tipos de comutadores OpenFlow. O primeiro consiste em um comutadorOpenFlow dedicado, que não suporta encaminhamento comum de Nível 2 e Nível 3. Osegundo tipo consiste em um comutador ou roteador comercial com OpenFlow habilitadoque, além de suportar as funcionalidades do OpenFlow, realiza as funções comuns de umcomutador ou roteador. Esses dois tipos são detalhados abaixo.

Comutador OpenFlow Dedicado

Esse tipo de comutador, exemplificado na Figura 1.7, é um elemento que apenas encam-inha o tráfego entre as portas do comutador de acordo com a Tabela de Fluxos configuradaremotamente via controlador. O fluxo pode ser definido de diferentes formas, por exem-plo, um fluxo pode ser definido como todos os pacotes provenientes de certa porta TCPou os pacotes com um determinado endereço MAC de destino. Além disso, alguns co-mutadores OpenFlow podem tratar pacotes que não utilizam o IPv4, verificando camposarbitrários de seu cabeçalho. Isso mostra a flexibilidade do OpenFlow para suportar difer-entes tipos de experimentos.

Para cada entrada da tabela de fluxos é definida uma ação para ser tomada com ospacotes oriundos de um determinado fluxo. As três ações básicas que todos ComutadoresOpenFlow devem suportar são as seguintes:

• encaminhar os pacotes do fluxo para uma ou várias portas específicas. Isso permiteque os pacotes sejam roteados pela rede;

• encapsular os pacotes e encaminhá-los para o Controlador utilizando o Canal Se-guro de comunicação. Essa ação pode ser executada no momento do envio doprimeiro pacote de um fluxo, que ainda não tenha sido definido nas Tabelas deFluxo dos comutadores, com o objetivo do Controlador configurar os comutadores


Figura 1.7. Comutador OpenFlow Dedicado

com esse novo fluxo. Além disso, a ação pode ser realizada em um experimento noqual é necessário processamento adicional nos pacotes de um fluxo;

• descartar o pacote. Essa ação pode ser utilizada em aplicações de segurança paraimpedir, por exemplo, ataques de negação de serviço.

Uma entrada na Tabela de Fluxos possui três campos, como apresentado na Figura1.8a. O primeiro identifica o cabeçalho que define o fluxo. Por exemplo, no cabeçalhodos comutadores OpenFlow (comutadores “tipo 0”), um fluxo pode ser definido por 10parâmetros. Esses parâmetros podem ser o MAC e IP de origem ou destino, as portasTCP usadas, entre outros como mostra a Figura 1.8b. Em outras gerações de comutadoresOpenFlow, esses parâmetros podem ser definidos arbitrariamente, permitindo o experi-mento de protocolos que não utilizam o IP.

(a)

(b)

Figura 1.8. Cabeçalhos que definem um fluxo em comutadores do“tipo 0”.


O segundo campo identifica a ação a ser tomada e o terceiro armazena as estatís-ticas do fluxo. Essas estatísticas podem ser o número de pacotes ou bytes referentes aofluxo que passaram pelo comutador e o intervalo de tempo desde a última vez em que umpacote do fluxo foi identificado pelo comutador. Esse último é importante, por exemplo,para remoção de um fluxo da tabela caso esteja inativo.

Comutador com OpenFlow Habilitado

Esse tipo de comutador consiste nos equipamentos que já realizam encaminhamento nor-mal de Nível 2 e Nível 3, mas adicionaram o OpenFlow com uma funcionalidade. Assim,o tráfego de produção pode ser encaminhado utilizando o encaminhamento normal e per-manece isolado do tráfego experimental, que utiliza o mecanismo do OpenFlow. Paraisso, esses comutadores podem adicionar outra ação além das três ações básicas citadasanteriormente:

• encaminhar os pacotes do fluxo pelo pipeline normal do comutador. Nessa ação,um fluxo identificado como não sendo referente ao OpenFlow será processado uti-lizando o encaminhamento normal.

Como alternativa ao uso da ação anterior, um comutador pode isolar o tráfego deprodução do tráfego OpenFlow através do uso de VLANs. Alguns comutadores podemsuportar tanto essa alternativa como a outra.

1.3.1.3. Controle usando NOX

O NOX [Gude et al. 2008] é uma proposta de sistema operacional para redes, possuindocomo objetivo facilitar o gerenciamento de redes de grande escala. O conceito de sis-tema operacional de rede pode ser entendido pela analogia com os sistemas operacionaisutilizados nos computadores. As ideias básicas dos sistemas operacionais de computa-dores são oferecer uma interface de alto nível para as aplicações utilizarem os recursos dehardware e também controlar a interação entre essas aplicações.

A interface de alto nível tornou os programas mais fáceis de serem desenvolvidose de executarem em diferentes plataformas de hardware. Isso ocorre porque os progra-madores não precisam mais se preocupar com interações de baixo nível da aplicação como hardware e podem escrever seus programas utilizando primitivas genéricas que fun-cionam em diversas arquiteturas.

Em redes de computadores, o gerenciamento é realizado por configurações debaixo nível que depende do conhecimento da rede, análogo às aplicações desenvolvidassem os sistemas operacionais. Como exemplo, o controle de acesso aos usuários de umarede utilizando uma ACL (Access Control List - Lista de Controle de Acesso), necessita doconhecimento do endereço IP do usuário, que é um parâmetro de baixo nível dependenteda rede.


Portanto, existe a necessidade de um sistema operacional de redes que forneçainterfaces para controlar e observar uma rede, semelhantes às interfaces de leitura e es-crita em diversos recursos oferecidos através de um sistema operacional de computador[Gude et al. 2008]. Assim, o sistema operacional de redes deverá fornecer uma interfacegenérica de programação que permite o desenvolvimento de aplicações de gerenciamentoda rede. Esse sistema centraliza o gerenciamento da rede, necessitando haver uma grandepreocupação com sua escalabilidade.

O NOX é um sistema operacional de rede que procura atender os requisitos jácitados. Esse sistema foi desenvolvido para ser executado nos controladores de redesOpenFlow. Apesar do objetivo principal do OpenFlow ser o experimento de novas pro-postas, o NOX pode ser utilizado também no gerenciamento de redes de produção.

A Figura 1.9 ilustra os principais componentes de uma rede baseada no NOX. Essetipo de rede possui um ou mais servidores executando o NOX. Cada um realiza o papeldo controlador OpenFlow. Esses controladores possuem aplicações executando a partirdo NOX. Todos os controladores compartilham uma única visão da rede, que é mantidana base de dados de um dos servidores.

Figura 1.9. Componentes de uma rede baseada no NOX

A visão da rede é montada com base em informações da rede coletadas pelo NOXe é usada na tomada de decisões pelas aplicações de gerenciamento. As informaçõescoletadas podem ser a topologia dos comutadores, a localização dos elementos da rede(ex. usuários, clientes, middleboxes) e os serviços oferecidos (ex. HTTP ou NFS).

As aplicações irão manipular o tráfego da rede a partir da configuração remotados comutadores OpenFlow. Esse controle é realizado no nível de fluxo, ou seja, semprequando um determinado controle é realizado no primeiro pacote de um fluxo todos osoutros pacotes desse fluxo sofrerão a mesma ação.

O funcionamento da rede baseada no NOX ocorre da seguinte forma: ao receberum pacote, o comutador verifica o cabeçalho do pacote para ver se ele está definido em suaTabela de Fluxos. Se estiver definido, o comutador executa a ação especificada na Tabela


de Fluxos e atualiza os contadores referentes à estatística do fluxo. Senão, encapsula opacote e o envia para o NOX.

O NOX então será responsável por adicionar uma entrada na Tabela de Fluxos docomutador, identificando o fluxo referente aquele pacote. Dependendo da aplicação, oNOX pode não adicionar essa entrada, forçando que os comutadores enviem sempre parao NOX os pacotes que receberem.

Como exemplo de aplicação que pode ser desenvolvida para o NOX, pode sercitado o gerenciamento de consumo de energia [Gude et al. 2008]. Por exemplo, nessetipo de gerenciamento, pode ser reduzida a velocidade de enlaces subutilizados ou essesenlaces podem ser simplesmente desligados. Com a Visão da Rede do NOX, na qualé conhecida uma visão global da rede e as rotas em uso, pode-se adquirir conhecimentonecessário para realizar tais ações. Além disso, essas ações podem ser auxiliadas por apli-cações desenvolvidas para o NOX, como redução de velocidade dos enlaces ou migraçãodos fluxos de um comutador que será desligado para outro comutador em uso.

Além do NOX ainda há outro tipos de controladores para redes OpenFlow, comoé caso do BEACON [BEACON 2011] que é baseado na linguagem JAVA, e do DIFANE[Yu et al. 2010] que é um controlador distribuído.

1.3.2. Virtualização

A virtualização é uma técnica que permite que um sistema execute processos oferecendo acada um deles a ilusão de executar sobre recursos dedicados. Inicialmente um mecanismode isolamento, ela representa um fator de uso eficiente da crescente capacidade computa-cional disponível [Egi et al. 2010] e a integra arquiteturas onde elementos comuns a umconjunto de processos virtualizados possuem apenas uma cópia em execução, acessadade forma compartilhada [Bhatia et al. 2008].

O conceito foi estendido do âmbito de nós para os demais elementos de uma redede computadores, dando origem à virtualização de redes [Chowdhury and Boutaba 2010].Em um processo paralelo àquele descrito para a virtualização tradicional, a aplicação davirtualização de redes passou a permitir que os componentes de uma rede física parti-cionassem sua capacidade de maneira a realizar simultaneamente múltiplas funções, es-tabelecendo infraestruturas lógicas distintas e mutuamente isoladas.

Assim como no caso da virtualização de sistemas, a virtualização de redes tam-bém permitiu que as arquiteturas de redes se tornassem mais eficientes. Funções quetradicionalmente eram gerenciadas de forma distribuída passaram a ser projetadas parauma execução e administração centralizadas. É o caso do encaminhamento do tráfego IP:podem ser encontradas arquiteturas do estado-da-arte [Nascimento et al. 2010] em quedecisões de roteamento, originalmente tomadas de forma local por nós especializados,são encaminhados por comutadores a um sistema controlador, que executa em memóriauma versão virtualizada da rede e dos respectivos elementos roteadores. Deriva decisõesda base de informações de roteamento construída pela execução desta rede virtual e astransmite aos comutadores, que reagem de acordo.


1.3.2.1. Virtualização de Sistemas

Uma solução de virtualização fornece aos sistemas, executando sob sua supervisão, aabstração de um ambiente computacional exclusivo sobre o qual eles estão operando (nó“convidado”), quando de fato tem-se um computador (“anfitrião”) cujos recursos forampartilhados entre esses mesmos sistemas.

Pode-se realizar a virtualização de sistemas de duas formas: a virtualização com-pleta, em que cada convidado executa seu sistema operacional, e a virtualização baseadaem containers, em que o sistema operacional do anfitrião distribui e isola os recursosdisponíveis entre os sistemas convidados [Bhatia et al. 2008].

Ainda segundo Bhatia [Bhatia et al. 2008], na virtualização completa, ilustradana Figura 1.10, o anfitrião executa um Monitor de Máquinas Virtuais - MMV, tambémchamado hypervisor. É responsabilidade do MMV prover abstração de hardware (chamadade máquina virtual) para que seja possível executar o sistema operacional convidado, bemcomo mapear cada requisição dos convidados a seus respectivos dispositivos virtuais, parao elemento físico correspondente.

Figura 1.10. Virtualização Completa

Também existe uma variação desta técnica chamada paravirtualização, que con-siste em otimizar a emulação de hardware provida pelo MMV com vistas a um ganhode desempenho. Nesta abordagem, porém, os sistemas operacionais convidados devemser modificados para que possam ser executados, o que não acontece na virtualizaçãocompleta.

Em um sistema baseado em containers, apresentado na Figura 1.11, uma imagemde sistema operacional virtualizada é compartilhada entre todos os convidados - o quepode ser especialmente eficiente em cenários em que se deseja apenas executar de formaisolada diversas cópias do mesmo software. Ainda assim, os nós virtuais podem ser indi-vidualmente gerenciados, tal como na virtualização completa.


Figura 1.11. Virtualização utilizando Container

A virtualização é empregada através de ferramentas que apresentam diferençasentre si e possuem suas vantagens e desvantagens. Atualmente, há uma gama enorme desoftwares livres e empresas que fornecem soluções com esse conceito. Neste minicurso,são comentados apenas as ferramentas Xen e o OpenVz, por serem as mais relevantes nocontexto atual.

XEN

O Xen é um monitor de máquina virtual (VMM ou hypervisor), em software livre, paraarquiteturas x86. Originário de um projeto de pesquisa da Universidade de Cambridge,sua primeira versão foi criada em 2003, quatro anos antes de ser comprada pela CitrixSystem, em 2007. Ele apresenta uma solução para virtualização um pouco diferente dasconhecidas.

Seu conceito consiste em criar um hypervisor, responsável por controlar os re-cursos das máquinas virtuais, mas que não possui drivers de dispositivos. Dessa forma,não é possível rodar um sistema operacional diretamente no hypervisor. Assim, faz-senecessário que um sistema seja invocado para fazer a comunicação entre o hypervisor eos sistemas hóspedes.

A Figura 1.12 apresenta uma visão geral do Xen. Esse sistema inicial chama-sedomínio 0. Ele consiste em uma máquina virtual que executa um núcleo Linux modifi-cado e possui privilégios para acessar dispositivos de entrada e saída às outras máquinasvirtuais, onde podem rodar outros sistemas operacionais, chamados domínio U. Elas sãocriadas, inicializadas e desligadas através do domínio 0. Possuem um driver virtual paraacesso aos recursos de hardware.

O domínio 0 possui os drivers dos dispositivos da máquina física, além de doisdrivers especiais que tratam as requisições de acesso à rede e ao disco enviadas pelas


Figura 1.12. Visão Geral do Arquitetura XEN

máquinas virtuais. Assim, toda requisição de uso da máquina real feita por uma máquinado domínio U deve ser tratada pelo domínio 0 antes de ser enviada ao hypervisor.

Originalmente, o Xen foi desenvolvido com o objetivo de implementar a técnicade para-virtualização, e, para isso, era necessário modificar os sistemas hóspedes para dar-lhes a consciência de rodarem sobre um hypervisor. Essa estratégia foi tomada visandoganhos em desempenho, mas limitou a difusão do Xen aos sistemas Unix, de códigoaberto.

OPENVZ

O OpenVZ é uma solução de virtualização em nível de sistema operacional. Cria ambi-entes virtuais isolados, que funcionam como servidores convencionais, porém, utilizandoum único hardware em comum. Estes ambientes virtuais seguros são conhecidos comoVE (Virtual Environment) ou como VPS (Virtual Private Server).

VPS’s podem ser reinicializados independentes uns dos outros. Todos possuemhostname, “root access” e endereço IP próprio, ou seja, o que um servidor real normal-mente possui, sendo assim uma solução extremamente confiável e funcional de virtual-ização.

As capacidades básicas dos VPS’s são:

Dynamic Real-time Partitioning: artição de um único servidor físico em dezenas de VPSs,cada um com funcionalidade total;

Resource Management: atribuição e controle dos recursos dos VPSs. Realocação derecursos em tempo real;

Mass Management: gerenciamento unificado de uma grande quantidade de servidoresfísicos e virtuais (VPSs).

Como pode ser visto na Figura 4.13, um servidor físico pode conter diversos VPS’s


Figura 1.13. Arquitetura de virtualização utilizada pelo openVZ

(Virtual Private Servers). Cada VPS possui isolamento total uns dos outros, inclusive comuma visão única de seus Ambientes Virtuais (VE’s).

O OpenVZ provê uma solução para Provedor de Serviços de Hospedagem possi-bilitando que:

• Centenas de usuários possuam seus próprios servidores privados (Virtual PrivateServers) compartilhando um único servidor físico;

• Provê para cada usuário uma garantia de qualidade de serviço;

• Transferência transparente dos ambientes virtuais dos usuários para outros servi-dores físicos, sem nenhum tipo de reconfiguração manual.

O Virtual Private Server se comporta como um único servidor, onde:

• Cada VPS possui seus próprios processos, usuários e provê acesso completo de rootvia shell

• Cada VPS possui seu próprio endereço IP, número de portas, firewall e roteamento;

• Cada VPS possui seus próprios arquivos de configuração para o sistema e apli-cações, como também suas próprias bibliotecas de sistema.

1.3.2.2. Virtualização de Redes

Assim como a virtualização provê o compartilhamento de recursos de um nó computa-cional por múltiplos sistemas, a virtualização de redes (VR) é um método para que múlti-plas arquiteturas de rede heterogêneas compartilhem o mesmo substrato físico - nestecaso, componentes de uma rede como roteadores, comutadores, etc.


Segundo Chowdhury [Chowdhury and Boutaba 2010], existem quatro abordagenspara a implementação de VR: as Redes Locais Virtuais (VLANs), as Redes PrivadasVirtuais (VPNs) e as redes de sobreposição (Overlay). Em [Sherwood et al. 2010a] ,apresenta-se uma quarta, a partir do conceito de redes programáveis.

Redes Locais Virtuais (VLANs)

Uma VLAN é um agrupamento lógico de dispositivos ou usuários que podem ser unidospor função, departamento ou aplicativo, independentemente da localização de seus seg-mentos físicos. A configuração de VLANs é feita no comutador, e possivelmente noroteador, através de software proprietário do fabricante.

Com efeito, numa rede local a comunicação entre as diferentes máquinas é gov-ernada pela arquitetura física. Graças às redes virtuais (VLANs), é possível livrar-se daslimitações da arquitetura física (constrangimentos geográficos, restrições de endereça-mento, etc), definindo uma segmentação lógica (software), baseada num agrupamento demáquinas com critérios como endereços MAC, números de porta ou protocolo.

Foram definidos vários tipos de VLAN, de acordo com o critério de comutação eo nível em que se efetua:

• VLAN de nível 1 (Port-Based VLAN) - define uma rede virtual em função das portasde conexão no comutador;

• VLAN de nível 2 (MAC Address-Based VLAN) - consiste em definir uma rede vir-tual em função dos endereços MAC das estações;

• VLAN de nível 3 - distinguem-se vários tipos de VLAN de nível 3: VLAN porsub-rede (Network Address-Based VLAN), que associa sub-rede de acordo como endereço IP fonte dos datagramas e VLAN por protocolo (em inglês Protocol-Based VLAN) que permite criar uma rede virtual por tipo de protocolo, por exem-plo: TCP/IP, IPX e AppleTalk, agrupando assim todas as máquinas que utilizam omesmo protocolo numa mesma rede.

A VLAN permite definir uma nova rede acima da rede física e a esse respeitooferece mais flexibilidade para a administração e modificações da rede porque qualquerarquitetura pode ser alterada por simples parametrização dos comutadores. E ainda, umganho em segurança, porque as informações são encapsuladas em um nível suplementare são eventualmente analisadas. A VLAN oferece também redução da divulgação dotráfego sobre a rede.

Redes Privadas Virtuais (VPNs)

A ideia de utilizar uma rede pública como a Internet em vez de linhas privativas paraimplementar redes corporativas é denominada de VPN (Virtual Private Network) ou RedePrivada Virtual. As VPNs são túneis seguros entre pontos autorizados, criados através da


Internet ou outras redes públicas e/ou privadas para transferência de informações, comproteção criptográfica, entre redes corporativas ou usuários remotos.

A segurança é a primeira e mais importante função da VPN. Uma vez que dadosprivados serão transmitidos pela Internet, que é um meio de transmissão inseguro, elesdevem ser protegidos de forma a não permitir que sejam modificados ou interceptados.

Outro serviço oferecido pelas VPNs é a conexão entre corporações, as Extranets,através da Internet, além de possibilitar conexões discadas e cifradas que podem ser muitoúteis para usuários móveis ou remotos, bem como filiais distantes de uma empresa.

Uma das grandes vantagens decorrentes do uso das VPNs é a redução de custoscom comunicações corporativas, pois elimina a necessidade de enlaces dedicados de longadistância que podem ser substituídos pela Internet.

As LANs podem, através de enlaces dedicados ou discados, conectarem-se a al-gum provedor de acesso local e interligarem-se a outras LANs, possibilitando o fluxo dedados através da Internet. Esta solução pode ser bastante interessante sob o ponto de vistaeconômico, sobretudo nos casos em que enlaces internacionais ou nacionais de longa dis-tância estão envolvidos. Outro fator que simplifica a operacionalização da WAN é que aconexão LAN-Internet-LAN fica parcialmente a cargo dos provedores de acesso.

1.3.2.3. Redes de Sobreposição (Overlay)

Uma rede de sobreposição é uma rede virtual que cria uma topologia virtual no topo datopologia física de outras redes. Os nós em uma rede de sobreposição são unidos por meiode ligações virtuais que correspondem a caminhos na rede subjacente. Na Figura 1.14ilustra essa afirmação, na camada “IP” os nós correspondem aos roteadores e sistemasterminais, enquanto na camada “Overlay”, que é uma rede de sobreposição, tem-se atopologia virtual. As redes de sobreposição são tipicamente programadas na camada deaplicação, embora várias implementações nas camadas inferiores da pilha de redes o façaexistir.

As redes de sobreposição não são restritas geograficamente e são bastante flexíveise adaptáveis a mudanças, se comparadas a qualquer outra rede. Como resultado, as redessobrepostas têm sido usadas para implantar novos recursos e extensões na Internet.

Figura 1.14. Modelo de Rede de Sobreposição


Muitos modelos de sobreposição têm sido propostos nos últimos anos para re-solver problemas que incluem: desempenho assegurado [Savage et al. 1999], disponibil-idade de roteamento na internet [Andersen et al. 2001], multicast [Jannotti et al. 2000][Chu et al. 2001], garantias de qualidade de serviço [Subramanian et al. 2004], ataque denegação de serviços [Andersen 2003], distribuição de conteúdo, compartilhamento de ar-quivos [Lua et al. 2005] e até sistemas de armazenamento [Dabek et al. 2001]. Redes desobreposição também estão sendo usada como ambientes de teste, por exemplo PlanetLab[Peterson et al. 2009], Federica [Campanella 2011] e o GENI [GENI 2011], para desen-volvimento e avaliação de novas arquiteturas.

1.3.2.4. Virtualização de Rede com OpenFlow

Similar à virtualização de computadores, a virtualização de redes promete melhorar aalocação de recursos além de permitir que seus operadores possam checar suas redes antesde eventuais mudanças, e também que clientes compartilhem o mesmo equipamento deforma controlada e isolada.

Portanto, analogamente, a rede em si deve ter uma camada de abstração de hard-ware, similar ao que acontece na virtualização de computadores. Esta camada deve serfacilmente “fatiável”, para que múltiplas redes completamente diferentes possam ser exe-cutadas simultaneamente em cima, sem interferir uns aos outros, sobre uma variedade dehardwares diferentes abaixo, incluindo comutadores, roteadores, pontos de acesso e assimpor diante. Ou seja, acima desta camada de abstração de hardware, têm-se novos protoco-los e formatos de endereçamento rodando independentemente e sua própria “fatia”, umamesma rede física, e na parte de baixo da camada de virtualização, novos hardwares, po-dendo ser desenvolvidos para diferentes ambientes e diferentes velocidade, mídia (comfio e sem fio) e energia.

De acordo com Sherwood [Sherwood et al. 2010a], a camada de abstração dehardware é provida pelo OpenFlow e como camada de virtualização se tem FlowVisor.Similar à virtualização de computadores, o FlowVisor é uma camada de abstração quereside entre o hardware e o software dos componentes da arquitetura, conforme ilustradona Figura 1.15. Portanto, a integração FlowVisor e OpenFlow permite que em uma redeOpenFlow possam ser criados várias fatias de recursos de redes rodando simultaneamentee isoladamente.

O FlowVisor é um controlador especializado que atua como um procurador (proxy)transparente entre os comutadores de uma rede OpenFlow e seus múltiplos controladores.Todas as mensagens do protocolo OpenFlow tanto aquelas originárias dos comutadorespara os controladores quanto as dos controladores para os comutadores, são intercep-tadas através do FlowVisor. Desse modo, os controladores não necessitam de modifi-cações e, devido à interceptação transparente do FlowVisor, os mesmos acreditam estarse comunicando diretamente com os dispositivos da rede que constitui o plano de da-dos [Sherwood et al. 2010b].

Devido à existência da interface entre os planos de dados e o de controle, a técnicaempregada permite a partição do plano de dados em fatias que estão sob a gerência doFlowVisor [Sherwood et al. 2009].


Figura 1.15. Comparação entre o FlowVisor como camada de virtualização coma virtualização computacional [Sherwood et al. 2009]

Cada fatia está vinculado a um controlador. O FlowVisor define uma fatia comoum conjunto de fluxos também chamado de “espaço de fluxo” (ou flowspace). Dev-ido à versão atual do protocolo OpenFlow permitir a definição de um fluxo como umacombinação de dez campos do cabeçalho de pacote incluindo informações das camadasfísica, de enlace, de rede e de transporte, o FlowVisor possibilita que se implemente fatiascom um elevado nível de granularidade, no que diz respeito à caracterização do flows-pace [Sherwood et al. 2010a] . Além disso, as fatias podem ser definidas por ações denegação, união e intersecção.

A Figura 1.16 ilustra o particionamento da rede em fatias. Nesta figura, alémda fatia da rede de produção, têm-se mais duas fatias identificadas por “Alice” e “Bob”.Os círculos enumerados em ordem crescente indicam a dinâmica de execução durante oprocessamento das mensagens interceptadas pelo FlowVisor. Inicialmente, o FlowVisorintercepta as mensagens provenientes de um determinado controlador “convidado” noambiente de controle (1). Utilizando a política do espaço de fluxos definida para aquelafatia (2), o FlowVisor reescreve a mensagem do controlador transparentemente para a fatiada rede que compõe o plano de dados (3). As mensagens originárias dos comutadorespara o plano de controle (4), por sua vez, são novamente interceptadas pelo FlowVisor ereescritas para o respectivo controlador de acordo com a política que define o espaço defluxos.

O particionamento da rede possibilita que as ações desenvolvidas em uma de suasfatias não interfiram negativamente nos demais, mesmo que estes estejam compartilhandoa mesma infraestrutura física. Em arquiteturas mais tradicionais, a rede é fatiada atravésda técnica de VLAN (Virtual Local Area Network), porém, com a diversidade dos mode-los de redes, a estrutura de VLANs torna os experimentos, como IP Mobility ou WirelessHandover, por exemplo, bastante difíceis de gerenciar.


Figura 1.16. Gerenciamento de slices por meio do FlowVisor [Sherwood et al. 2009]

As características inerentes ao FlowVisor, como a virtualização transparente, oforte isolamento entre as fatias e a sua rica política de definição de flowspaces tornamo mesmo uma ferramenta extremamente eficiente no que diz respeito à virtualização eimplementação de redes programáveis orientadas a software.

1.4. Requisitos para Construção de um Ambiente para Experimento e Virtu-alização de Redes

Iniciativas [FIRE 2011] [GENI 2011] [AKARI 2009] vêm construindo infraestruturas paratestar novos protocolos, serviços e aplicações em ambientes de larga escala, visando solu-cionar esses desafios da Internet atual e compor a arquitetura da chamada Internet doFuturo.

Por essas razões, definir estratégias corretas para construção e operação destesambientes de teste para Internet do Futuro é considerado uma etapa vital. Além disso,o ambiente deve combinar flexibilidade a um conjunto mínimo de restrições e um com-pleto controle do ambiente para seus pesquisadores [Kim et al. 2009]. Deste modo, oOpenFlow vem se destacando como arcabouço capaz de habilitar experimentos de novastecnologias utilizando redes reais de produção. Nesta mesma linha, a virtualização vemcomo uma ferramenta essencial, para permitir o acesso compartilhado de recursos, sejade rede ou computacional.

Portanto nesta seção, observam-se as informações importantes para construçãode uma rede para experimentação, levando em consideração a utilização de OpenFlowe virtualização. Verificam-se o modo que se descrevem, os hardwares utilizados dentrodesta infraestrutura, tipos de enlaces, software de virtualização e ferramentas para análisede tráfegos e geração de tráfego


1.4.1. Tipos de Hardwares

Para construção do ambiente de teste, é necessário principalmente hardware que suportevirtualização e OpenFlow. Para isso, são necessários dispositivos especiais para que odesempenho da rede virtual não tenha uma influência nos experimentos realizados, e queseja possível sua otimização de forma programável. Entre esses dispositivos estão inter-faces de redes programáveis e comutadores programáveis com OpenFlow habilitado.

Interface de Rede Programável

O NetFPGA [Lockwood et al. 2007] é uma plataforma aberta que permite estudantese pesquisadores desenvolverem protótipos de sistemas de redes em alta velocidade esistemas de aceleração de redes via hardware, além de protótipos de comutadores ouroteadores IP para Internet do Futuro.

O NetFPGA consiste em um placa de desenvolvimento reconfigurável, interfacede ligação ao PC, utilizando PCI e PCI-e, dois processadores PowerPC, e software quepossibilita o desenvolvimento de novas funcionalidades. Há duas versões da placa: amais antiga possui quatro interfaces de 1 Gbps Ethernet RJ-45 e um vazão que de 8Gbps;a mais nova tem quatro interfaces 10 Gbps Ethernet SFP+, e vazão até 80 Gbps. Alémdisso, é totalmente compatível com Linux e OpenFlow.

Switches Programáveis

O OpenFlow é um arcabouço que permite o gerenciamento da tabela de encaminhamentode comutadores Ethernet, desacoplando a lógica de controle do equipamento do hard-ware de encaminhamento de pacotes, permitindo assim o conceito chamado de Software-Defined Networking (SDN) [Greene 2009]. Esta separação não só permite um modelode inovação aberta tanto no plano de controle quanto no plano de encaminhamento, mastambém permite a virtualização do plano de encaminhamento em fatias ou redes lógicas.Deste modo, são necessários equipamentos que possuam o OpenFlow habilitado.

No entanto, o protocolo Openflow ainda está em fase de padronização nos co-mutadores e algum fabricantes já disponibilizam versões de comutadores com OpenFlowhabilitado, como é o caso dos modelos Pronto 3290 para soluções até 1 Gbps Ethernet e oPronto 3790 para 10 Gbps Ethernet e SFP+. Também há o projeto Indigo [INDIGO 2011]que é uma implementação aberta do OpenFlow que permite rodar sobre comutadores físi-cos baseados em chipsets da Broadcom. A cada comutador suportado é desenvolvidoum firmware para essa linha de produto. Este firmware sobrescreve o original do co-mutador, instalando a nova imagem com OpenFlow habilitado. Dentre os comutadorescompatíveis, temos, além dos modelos da linha Pronto, os modelos GSM7328 (24 x 1GbE) e GSM7352 (48 x 10 GbE) da linha Netgear.

Servidores de Alto Desempenho

Os servidores também são uma parte importante dentro do substrato, pois deles são vir-tualizados recursos como: processador, armazenamento e E/S. Para isso, são necessáriosservidores de alto capacidade computacional para que não haja perda de desempenho nonível virtualizado e suporte à quantidade de usuários locais e também os federados. Obser-vando esses requisitos, as linhas de servidores do tipo blade surgem como uma excelente


solução para oferecer essa capacidade computacional.

Blade é uma nova forma de tecnologia computacional que permite a alta den-sidade de componentes e recursos incluindo servidores, armazenamento e interfaces decomunicação integradas em um mesmo chassis.

A vantagem do uso de servidores blade é a possibilidade do crescimento incre-mental mediante a demanda de usuários, devido a sua característica modular, baseadaem containers de servidores, comutadores e armazenamento. O seu capacidade computa-cional pode ser incrementado com introdução de novas lâminas blade, que são servidoresque são inseridos no chassis e incluem recursos de processamento e memória. Além disso,outra vantagem é a sua otimização para uso de virtualização com barramento em altíssi-mas taxas de transferência, e implementação de grupos de recursos dentro de conjuntovirtualizado. O uso de blades está ligado principalmente à virtualização de servidores e àcomputação em nuvem.

1.4.2. Arcabouços de Controle

O arcabouço de controle é o coração de qualquer infraestrutura de experimentação baseadaem virtualização. Porém, muitos arcabouços são limitados a certos tipos de recurso e aum tipo de comunidade de pesquisa. Com base nisso, são apresentados alguns arcabouçosde controle que devem ser selecionados de acordo com o tipo de infraestrutura que se estáoferecendo:

ProtoGENI (GENI)

O ProtoGENI [ProtoGENI 2011] é atualmente dirigido pela Universidade de Utah. É umarcabouço que pretende controlar a integração em larga escala de infraestruturas exis-tentes e em construção no GENI. Esses ambientes de teste são compostos principalmentepor elementos embarcados e programáveis nas redes backbone, PCs com hardwares pro-gramáveis e uma variedade de redes sem fio, redes de acesso e clusters programáveis. At-ualmente, o ProtoGENI está usando RSpec para descrever seus nós, enlaces e interfaces.Esses recursos são mapeados para o Emulab que aplica os mapas virtuais de recursos emnós locais e vlans.

ORCA(GENI)

O ORCA [ORCA 2011] [BEN 2011] é framework de código fonte aberto, utilizado paragerenciar e controlar a programabilidade de substratos (hardware) compartilhados, quepodem incluir, servidores, storages, redes e outros componentes. O ORCA foi desen-volvido como um protótipo arcabouço GENI.

No ORCA, há uma coleção dinâmica de controladores de interação que trabalhamjuntas para o aprovisionamento e configuração de recursos para as fatias requisitadas pelosseus usuários, de acordo com as políticas dos participantes.

Atualmente, o ORCA foi estendido para gerenciar um ambiente de teste em umarede óptica metropolitana. Também está em processo de integração a seleção para utiliza-ção de protótipos para redes de sensores e sem fio, de modo que o ORCA ofereça a maiorvariedade possível de ambientes de teste.


FEDERICA (FIRE)

O FEDERICA [Szegedi et al. 2009] é uma iniciativa composta de roteadores, comuta-dores e computadores para experimentações em Internet do Futuro. Ele é baseado nasredes acadêmicas de alguns países europeus e na rede pan-europeia GEANT.

O arcabouço FEDERICA é capaz de alocar recursos para múltiplas fatias e difer-entes redes a serem utilizadas pelos pesquisadores que possuem o controle completo dosrecursos de sua fatia. Ele é composto de pequenas ferramentas e outros recursos de instru-mentação que vão desde a gerência e controle de máquinas virtuais à alocação de circuitosfim-a-fim camada 2, camada 1 ou MPLS.

PII (FIRE)

O objetivo do projeto PII [Paul et al. 2011] é criar uma federação de instalações experi-mentais entre diferentes pólos de inovação regional na Europa. Isso permite que as em-presas participantes possam testar novos serviços de comunicação e aplicações na Europacomo um todo.

O arcabouço também terá como objetivo federar redes para experimentação dis-tribuídas por laboratórios espalhados pela Europa, assim provendo um ambiente de testerealístico para novos conceitos de serviços, tecnologias de rede e modelos de negócios.Os mecanismos de seu arcabouço incluem regras e procedimentos para alcançar níveis deteste e colaboração dentro dessas federações de infraestruturas dentro da Europa.

1.4.3. Monitoração e Medição

Medição e monitoramento são atividades que observam o estado operacional do ambientede teste que está sendo usado, de modo que se possa obter informações sobre o desem-penho dos recursos disponíveis no ambiente, e verificar a disponibilidade do recurso oucomponente. O objetivo disso é oferecer a outros sistemas uma visão dos recursos dainfraestrutura, para auxiliar decisões como a possibilidade de alocação de recurso, bemcomo sua escolha e disponibilização.

Portando, dentro dos requisitos para construção dessas ambientes de teste, esseselementos são essenciais. A seguir, são apresentados alguns softwares relacionados acaracterísticas de medição e monitoramento.

PerfSONAR

O perfSONAR (PERFormance Service-Oriented Network monitoring ARchitecture) é umaarquitetura orientada a serviços (SOA) que foi projetada para o monitoramento de re-des em ambientes interdomínios. No perfSONAR, existe um conjunto de serviços bemdefinidos que realizam ou disponibilizam resultados de medições de desempenho em umambiente federado. Esses serviços atuam como uma camada intermediária entre as ferra-mentas de medições e as ferramentas de visualização [Tierney et al. 2009].

Além disso, o perfSONAR também definiu um protocolo comum entre os serviçospara permitir que sejam criados novos serviços seguindo a padronização deste protocolo,dando flexibilidade à arquitetura. Também, criou-se uma representação unificada paradefinir, armazenar e arquivar os dados relativos às medidas do experimento que é mais


um componente chave, de modo que certo nível de concordância é necessário para fazerconvergir esforços e melhorar a experiência, fidelidade e usabilidade das infraestruturasde experimentação em escala global.

O pS-Performance Toolkit [Ps-Performace 2011] é uma coleção de ferramentas demedida de desempenho de redes desenvolvida dentro do projeto perfSONAR.

BWCTL

O BWCTL [Hu et al. 2010] é uma aplicação cliente/servidor que permite o agendamentode testes com políticas de medidas utilizando IPERF, THRULAY [Shalunov 2011] eNUTTCP [Fink and R. 2011]. Estes testes podem medir, por exemplo, a máxima largurade banda para TCP ou testes UDP para medir o atraso, a variação do atraso ou nível deperda de datagrama na rede. BWCTL tem sido utilizado para testar as qualidades dasreservas de circuitos. Neste caso, o seu cliente solicita e agenda um circuito, verifica sefoi criado ou não, e caso seja criado, ele verifica se os desempenhos solicitados estãorealmente disponíveis.

Real-Time Unified Measurement Framework

O UMF (Unifed Measurament Framework) é um arcabouço desenvolvido para oferecercapacidade de medições em tempo real a avaliações de desempenho sobre vários cenáriosde infraestrutura, interfaces de integração dos recursos de medição com os substratose os framewoks de controle dos protótipos de GENI e outros sistemas que necessitemde suas medidas e a monitoração das condições dos recursos de um slice durante umexperimento [UMF 2011].

Inicialmente, o UMF está sendo desenvolvido para alimentar informações dos de-mais arcabouços de controle do GENI e de visualização dos usuários pesquisadores. NaFigura 1.17, mostra o esquema de interação dos arcabouços com o UMF.

Figura 1.17. Esquema de interação do UMF com outros frameworks do GENI

UMF é um arcabouço genérico para gerenciamento de ambiente de teste e coletade métricas de experimentos. Quando o experimento está sendo executado, os dadossão medidos e coletados de acordo com a descrição do usuário. Pontos de medição são


definidos dentro de uma aplicação C/C++ ou automaticamente, baseados em arquivos deconfiguração XML.

Os dados medidos são transmitidos usando codificação XDR e salvos em umbanco de dados para análise posterior. Um novo banco de dados de medição é criadopara cada experimento. O SQLite pode ser usado para manipular os dados ou estes po-dem ser exportados para geração de gráficos ou tabelas.

No UMF, há medidores de desempenho (Performance Monitors) para os maisvariados tipos de substratos físicos, como: unidades externas de hardware, por exemplo,servidores com capacidade de armazenamento (storage), interface de Ethernet NetFPGA(10G - NetFPGA). Outras interfaces Ethernet seriam GPIB e sem fio, e protocolos padrõespara medição como TL1, SNMP e NetConf.

1.4.4. Ferramentas para Gerência de Virtualização

As ferramentas de gerência são essenciais no desenvolvimento dos ambientes de experi-mentação, pois elas têm o papel de manipular, criar, configurar e remover recursos nestesambientes. Portanto, abaixo, são apresentadas as principais ferramentas para gerencia-mento de virtualização, computação em nuvem e manipulação de fatias.

LIBVIRT

A LIBVIRT [Wu et al. 2010] existe como um conjunto de APIs projetadas para seremusadas como um aplicativo de gerenciamento. Por meio de um mecanismo específico dehypervisors, a LIBVIRT comunica-se com um hypervisor disponível para executar as so-licitações da API. Deste modo, a LIBVIRT provê uma comum genérica e estável camadapara gerenciamento. A API pode acessar esse hypervisor permitindo o aprovisionamento,criação, modificação, controle, monitoramento, migração, inicialização e finalização daVM (virtual machine). No entanto, o suporte a todas essas operações irá depender datecnologia de virtualização utilizada.

Com a LIBVIRT, têm-se dois meios de controle distintos. O primeiro é demon-strado na Figura 1.18, no lado esquerdo, em que o aplicativo de gerenciamento e osdomínios existem no mesmo nó. Nesse caso, o aplicativo de gerenciamento trabalhapor meio da biblioteca libvirt para controlar os domínios locais. Outros meios de con-trole existentes são quando o aplicativo de gerenciamento e os domínios estão em nósseparados, o que é ilustrado na Figura 4.19, lado direito. Este modo usa um daemonespecial chamado libvirtd que é executado em nós remotos. Tal daemon é iniciado au-tomaticamente quando a libvirt é instalada em um novo nó e pode determinar, de formaautomática, os hypervisors locais e configurar drivers para eles. O aplicativo de gerencia-mento se comunica por meio da libvirt local com o libvirt remoto através de um protocolocustomizado [Bolte et al. 2010].

A API LIBVIRT foi construída para trabalhar através de múltiplos ambientes devirtualização. Dentre as tecnologias de virtualização temos: QEMU, LXC, OpenVZ, UserMode Linux, KVM, VirtualBox e VMWare. Além disso, também consegue gerenciar asseguintes tecnologias de armazenamento: Storage IDE/SCSI/USB, FiberChannel, LVM,iSCSI e NFS.


Figura 1.18. Modos de controle de hypervisor [Wu et al. 2010]

EUCALYPTUS

Eucalyptus [Nurmi et al. 2009] é um arcabouço aberto para montagem e gerência de am-bientes de computação em nuvem utilizando virtualização, sendo o seu foco a pesquisaacadêmica. Ele provê uma implementação baseada em IaaS (Infraestructure as a Service),ou seja, infraestrutura como recurso nuvem. Os usuários do Eucalyptus são capazes deiniciar, controlar, acessar e finalizar máquinas virtuais (VMs). A atual versão do Eu-calyptus suporta VMs, rodando sobre uma hypervisor XEN, mas há planos de utilizarKVM/QEMU e VMWare.

O projeto Eucalyptus apresenta quatro características que o diferenciam de outrassoluções de computação em nuvem e virtualização: o Eucalyptus foi projetada para sersimples, de modo que não há a obrigatoriedade da dedicação de recursos; o arcabouçofoi projetado para encorajar extensões de software de terceiros; possui uma interface ex-terna que é baseada na API EC2 da Amazon; e o Eucalyptus provê uma rede sobrepostavirtual que isola o tráfego de rede de diferentes usuários, permitindo que clusters remotospareçam partes da mesma rede local.

A gerência do Eucalyptus é baseada em serviços Web, o que oferece alguns bene-fícios à arquitetura, como a exposição da API em forma bem conhecida e funcional comoo WSDL (Web Service Description Language), definindo tanto as operações que seusserviços podem desempenhar, quanto as estruturas de dados de entrada e saída utilizadas.A arquitetura define três níveis de gerenciamento da infraestrutura de nuvem:

Instace Manager (IM): Controla a execução, inspecção e finalização das instâncias deVMs nos hospedeiros nos quais estão rodando;

Group Manager (GM): Suas funcionalidades são as seguintes: escalonamento e geren-ciamento de execução de operações sobre os IM, controle de operações sobre a redevirtual sobreposta e reportagem de informações sobre um conjunto de IMs;

Cloud Manager (CM): Interage com os usuários e gerenciadores reportando informaçõesa respeito dos estados dos recursos da nuvem.


O Eucalyptus é flexível e pode ser instalado em uma infraestrutura mínima (nomínimo duas máquinas), como também em milhares de núcleos e terabytes de armazena-mento, Com total integração sobre uma rede sobreposta de interligação das infraestruturasde nuvem.

E-GENI

O Enterprise-GENI [E-GENI 2011] é uma arquitetura/arcabouço utilizada para gerenciaro uso de fatia em uma infraestrutura baseada em OpenFlow e FlowVisor. O objetivo doarcabouço é criar uma interface para visualização e gerências de múltiplos experimentosem rede OpenFlow. A Figura 1.19 mostra como está definida a arquitetura do E-GENI.

Figura 1.19. Arquitetura do E-GENI [E-GENI 2011]

A arquitetura do E-GENI é dividida em três partes:

OpenFlow-Based Substrate: Composto de switches que se comunicam utilizando o pro-tocolo OpenFlow para uma aplicação do controlador;

FlowVisor: Customizado para controlar slice de rede pelo isolamento e controle de tráfegode experimentos individuais;

Aggregate Manager: Uma aplicação integra o Clearinghouse, responsável pela manipu-lação dos experimentos, ao E-GENI FlowVisor utilizando o protocolo SOAP, baseadono GENILight Protocol.

O E-GENI vem sendo desenvolvido para integrar redes do tipo OpenFlow ao ar-cabouço GENI como mais uma alternativa dentro da infraestrutura de experimentaçãopara Internet do Futuro do GENI.


1.5. Estudo de CasoCom o propósito de criação de ambientes experimentais em Internet do Futuro, a co-munidade acadêmica vem orientando esforços consideráveis na criação de ambientes deteste baseados em redes programáveis. Baseada em tráfegos reais de usuários, a criaçãode ambientes programáveis permite uma abordagem mais realística com relação à escala-bilidade da rede e seu comportamento interativo

De maneira complementar a esta abordagem com ambientes de teste, este estudode caso tem por objetivo demonstrar como é possível implementar uma rápida prototi-pagem de protocolos de rede que seja facilmente aplicável a redes reais. Ou seja, pormeio de um ambiente local, é possível implementar uma funcionalidade que possa serimediatamente aplicada para testes num ambiente global possibilitando uma maior ino-vação em redes programáveis.

Como importante proposta no contexto de redes programáveis, neste estudo decaso utiliza-se do arcabouço OpenFlow devido à possibilidade de criação de uma in-fraestrutura de experimentação sobre uma rede de produção. Além disso, por meio dautilização do OpenFlow associado à virtualização, demonstra-se como é possível criar,utilizar e gerenciar várias fatias sobre uma infraestrutura de rede compartilhada, possi-bilitando que vários experimentos de protocolos possam ser executados de maneira si-multânea.

Por meio deste estudo de caso demonstra-se que é possível implementar uma novafuncionalidade, ou mesmo uma nova arquitetura de rede em ambientes locais baseados emsoftware. Estas funcionalidades podem então ser testadas por seus usuários por meio delargas topologias e com tráfegos específicos. Posteriormente, os mesmos códigos queimplementam estas funcionalidades podem ser empregados em ambientes de teste reais.

1.5.1. Definição do Ambiente

Para exemplificar a utilização do OpenFlow associado à virtualização, esse estudo de casotem como principal objetivo apresentar como se pode desenvolver um ambiente capaz desuportar simultaneamente vários experimentos de protocolos compartilhando a mesmainfraestrutura física.

1.5.1.1. Dados de Implementação do Ambiente

O estudo de caso é formado por um ambiente virtualizado, ou seja, os nós de equipamen-tos OpenFlow e hosts clientes da redes são elementos de virtualização. Para implementaresse ambiente com suporte ao arcabouço OpenFlow, utiliza-se dois servidores: um comXen Server para armazenar os servidores que contêm os controladores que são utilizadosem cada fatia do experimento e outro servidor utilizando apenas o sistema operacionalLinux e o software Mininet [MiniNet 2011].

O Mininet utiliza virtualização baseada em contêineres para criar instâncias virtu-ais de cada comutador (ou host cliente) que seja utilizado no experimento. Além disso,utiliza-se um comutador para interligar o plano de controle (controlador) e plano de dados(comutadores). A Figura 1.20 ilustra o ambiente que foi desenvolvido para realização do


estudo de caso.

Figura 1.20. Ambiente de teste do estudo de caso

A Tabela 1.1 apresenta, de forma resumida, as informações e configurações dosservidores utilizados no estudo de caso.

Tabela 1.1. Dados dos Servidores

Dados Servidor MiniNet Servidor de Controladores NOXSistema Operacional Debian Lenny 5.0 Citrix XenServer 5.6Memória 4096 MB 2048 MBInterface de Rede 1GbE 2 2Armazenamento 320 GB SAS 500 GB SATAVirtualização Contêiner XEN

No servidor de controladores têm-se três maquinas virtuais (VM) rodando trêsaplicações diferentes no controlador. Cada controlador se comunica com o FlowVisor us-ando 3-tuplas de informações: VLAN, IP e porta TCP do processo servidor do FlowVisor.

Com o objetivo de isolar o tráfego de cada controlador para eventuais análises docomportamento das informações de controle entre o controlador e o FlowVisor são divi-didas por VLANs, VM1 VLAN 100, VM2 VLAN 200 e VM3 VLAN 300. A Tabela 1.2contém um resumo dos dados de configuração de cada VM de controlador.


Tabela 1.2. Configurações das VMs com os Controladores NOX

Dados VM 1 VM 2 VM 3Sistema Operacional Debian Lenny 5.0 Debian Lenny 5.0 Debian Lenny 5.0Memória 512 MB 512 MB 512 MBInterface de Rede 1GbE 1 1 1Endereçamento IP 192.168.100.1 192.168.200.1 192.168.300.1VLAN 100 200 300Software Controlador NOX 0.6 NOX 0.6 NOX 0.6Porta de Conexão com FlowvVisor 1515 1516 1517Armazenamento 4 GB 4 GB 4 GBAplicação Switch Switch e SpanningTree Switch e Routing

No Servidor Mininet, observa-se dois ambientes distintos virtualizados. O primeirocontém o aplicativo Mininet virtualizando a infraestrutura física de comutadores e clientes.E um segundo com o FlowVisor que realiza a criação, remoção e gerência das fatias noplano de dados do Mininet. A Tabela 1.3 resume as configurações do servidor Mininet.

Tabela 1.3. Dados do Servidor MiniNet

Dados Servidor MiniNetSistema Operacional Debian Lenny 5.0Memória 4096 MBInterface de Rede 1GbE 2Armazenamento 320 GB SASVirtualização de Rede FlowVisor 0.6Virtualização Contêiner Virtuais LXCPorta FlowVisor 6633

Mesmo utilizando a infraestrutura virtualizada de comutadores Openflow, os testesaqui executados são totalmente compatíveis se aplicados em uma ambiente real de comu-tadores OpenFlow. Deste modo, o ambiente desenvolvido aqui serve como um ponto departida no desenvolvimento de uma nova solução que depois pode ser aplicado em umambiente maior com elementos OpenFlow reais.

1.5.1.2. Plano de Dados

Para o planejamento do plano de dados, foi desenvolvido o um script 1 , que é utilizadopelo Mininet, e contém a descrição da topologia e dos elementos que fazem parte damesma, como: comutadores ou roteadores e hosts (clientes). Para isso é utilizado umaAPI fornecida pela Mininet. A Figura 1.21 ilustra o plano de dados configurado no ambi-ente Mininet.

Para este trabalho optou-se pelo emprego de uma topologia em malha 3x3. Oobjetivo é ter um cenário com uma quantidade de nós consideráveis e que também pos-

1O scripts para o Mininet, assim como as aplicações NOX podem ser encontrados emhttp://www.gercom.ufpa.br/minicurso_sbrc


Figura 1.21. Topologia e do plano de dados

sibilite nós em comum entre as fatias, de modo a observar entre eles o compartilhamentode recursos e isolamento.

1.5.1.3. Plano de Controle

Para o plano de controle foi alocado três fatias de planos de dados distintos, mostrado naFigura 1.22, nomeados de switch, switch_stp e switch_router. O comportamento de en-caminhamento de pacote em cada fatia é gerenciado por três aplicações NOX, tais como,Switch, Spanning_Tree e Routing. Nas extremidades têm-se os hosts utilizados para ger-ação de tráfego no plano de dados, seja por meio de requisições ICMP ou utilizando fluxosTCP ou UDP com uso da aplicação Iperf.

Figura 1.22. Slice dos Experimentos


Representando o controle lógico dos pesquisadores, tem-se três controladoresNOX, um em cada VM, associado a uma fatia do plano de dados. Abaixo apresenta-mos os comandos utilizados e executados em cada VM, para iniciar os controlares NOXscom sua aplicação respectiva:

# nox_core -v -i ptcp:1515 switch# nox_core -v -i ptcp:1516 switch spanning_tree# nox_core -v -i ptcp:1517 switch route

Os comandos acima indicam: iniciação do processo núcleo do NOX (nox_core),onde a opção -v indica o modo de depuração, a opção -i informa o protocolo de transportee a porta ao qual o NOX estará escutando conexões dos comutadores do plano de dados,e, por fim, a aplicação NOX utilizada.

Cada um destas fatias deve conectar-se ao seu respectivo controlador NOX ini-cializado pelos comandos anteriores. As instruções a seguir, utilizando o comando fvctl,efetivam a criação das fatias:

# fvctl createSlice switch tcp:192.168.100.1:1515 [email protected]# fvctl createSlice switch_stp tcp:192.168.200.1:1516 [email protected]# fvctl createSlice switch_router tcp:192.168.300.1:1517 [email protected]

O comando fvctl permite a gerência das fatias, portanto os parâmetros dos coman-dos acima indicam: createSlice o tipo de ação que é aplicado à fatia; switch descreve onome da fatia a ser criado; tcp:192.168.100.1:1515 apresenta o endereço do controladorvinculado à fatia; e no final define-se o correio eletrônico do responsável.

Ao final de cada entrada é solicitada a criação de uma senha para fatia específica,provendo um controle de acesso a cada operação na fatia. O comando a seguir lista asfatias criadas atualmente:

# fvctl listSlicesEnter root’s password:Slice 0: rootSlice 1: switchSlice 2: switch_stpSlice 3: switch_router

1.5.2. Aplicação Prática

A primeira aplicação apenas efetua o encaminhamento de pacote na camada 2, com umcomportamento de comutador; a segunda, além de efetuar o encaminhamento na camada2 via comutador, também trata o aparecimento de ciclos na rede através do algoritmoSpanningTree; e, a terceira, habilita o roteamento de pacotes.

Fatia Switch

Para a fatia Switch, foi designado a topologia representada pela Figura 1.23. Nesta topolo-gia, têm-se dois hosts clientes, um em cada extremidade da topologia da fatia, gerandofluxo de pacotes entre eles.


Figura 1.23. Slice Switch

Os comandos abaixo alocam os recursos para o slice Switch. A definição incluia especificação dos nós que compõem o plano de dados e a característica do fluxo quepercorre o plano de dados.

# fvctl addFlowSpace 00:00:00:00:00:01 10 dl_vlan=100 “Slice:switch=4”# fvctl addFlowSpace 00:00:00:00:00:02 10 dl_vlan=100 “Slice:switch=4”# fvctl addFlowSpace 00:00:00:00:00:03 10 dl_vlan=100 “Slice:switch=4”

Neste comando os parâmetros são as flags, addFlowSpace, que adiciona o recursoidentificado pelo Datapath, a prioridade de execução (10) , onde quanto maior o valor daprioridade mais rápido a informação da fatia é processada, e, por fim, “Slice:switch=4”que indica a qual fatia o recurso é alocado.

Nos comandos acima se tem a adição dos nós SW01, SW02 e SW03 formando atopologia da fatia Switch, neste caso os nós são identificados pelos endereços Datapath00:00:00:00:00:01, 00:00:00:00:00:02 e 00:00:00:00:00:03, respectivamente. Para iden-tificar os fluxos acrescentados à fatia foram utilizados elementos de camada 2, neste casopelo vlan_id 100. O que se percebe é que, dependendo da camada onde o experimentoé realizado, precisa-se de elementos dessa camada para identificar o fluxo que faz partedaquela fatia.

Nesta aplicação o comportamento do comutador consiste em analisar cada pacotee “aprender” sobre sua porta de origem, associando o endereço MAC de origem à portaonde o mesmo está conectado. Caso o destino do pacote já esteja associado a uma dadaporta, o pacote será enviado diretamente, caso contrário, o comutador realizará a ação de“flood”, ou seja, encaminha para todas as portas.

Após a inclusão dos nós na fatia Switch, os nós OpenFlow passam a ser recon-hecidos pelo NOX correspondente à fatia, e a executar as ações da aplicação instanciadana mesma. Para ilustrar o funcionamento da aplicação Switch, aplica-se um fluxo ICMPdo tipo ECHO_REQUEST e ECHO_REPLY entre os hosts da fatia. Na primeira tentativade comunicação são trocadas informações de controle entre os comutadores da fatia e ocontrolador. Como o pacote é desconhecido é aplicada a todos os nós a ação FLOOD,


como mostra a Figura 1.24.

Figura 1.24. Encaminhamento dos primeiros pacotes

Para os pacotes seguintes que possuem o mesmo destino como o primeiro pacote,e como o controlador já aprendeu a porta que possui o MAC correspondente de destino,ele muda a ação de FLOOD para a porta correspondente, de modo a alcançar o nó dedestino. Como mostrado na Figura 1.25.

Figura 1.25. Tabela de fluxo após o conhecimento do nó de destino

Fatia STP

O protocolo STP possibilita a inclusão de ligações redundantes entre os comutadores,provendo caminhos alternativos no caso de falha de uma dessas ligações. Nesse contexto,seu objetivo é evitar a formação de ciclos entre os comutadores e permitir a ativação edesativação automática dos caminhos alternativos.


Para a fatia denominado switch_stp, optou-se por implementar a topologia rep-resentada pela Figura 1.26. Nesta topologia tem-se um cenário no qual há presença deciclos no caminho entre os hosts finais. O objetivo, neste caso, é tratar este problema pormeio da implementação do algoritmo SpanningTree no ambiente do controlador.

Figura 1.26. Slice STP

A alocação de recursos à fatia switch_stp é feita de maneira similar ao que foiimplementado para a fatia switch. Para este fim, deve-se executar a seguinte sequência decomandos:

# fvctl addFlowSpace 00:00:00:00:00:04 10 dl_vlan=200 “Slice:switch_stp=4”# fvctl addFlowSpace 00:00:00:00:00:05 10 dl_vlan=200 “Slice:switch_stp=4”# fvctl addFlowSpace 00:00:00:00:00:07 10 dl_vlan=200 “Slice:switch_stp=4”# fvctl addFlowSpace 00:00:00:00:00:08 10 dl_vlan=200 “Slice:switch_stp=4”

Os comandos definem os recursos da fatia switch_stp, que neste caso são osfluxos de pacotes com vlan_id igual a 200. E também os nós utilizados, tais como:SW4 (Datapath 00:00:00:00:00:04); SW5 (Datapath 00:00:00:00:00:05); SW7 (Datap-ath 00:00:00:00:00:07); e SW8 (Datapath 00:00:00:00:00:08).

No módulo STP, quando um novo comutador conecta-se ao controlador NOX, omódulo registra o nó e neste momento desabilita a operação de FLOOD em todas as suasportas. Periodicamente o módulo realiza consultas com todos os enlaces para montar alista de elementos da topologia. Esta lista é utilizada para a construção da árvore geradora(Spanning Tree). De modo que, todos os comutadores candidatos são alocados em umalista e ordenados (de maneira crescentemente) por meio de seu Datapath; O primeiroelemento é removido da lista e definido como "comutador raiz"da árvore geradora.

Este procedimento é então executado para todos os comutadores candidatos quecompõem a lista. O módulo Spanning Tree, também utiliza o módulo de descoberta doNOX, chamado Discovery, para localizar as ligações dos comutadores com os seus nós


vizinhos.

Como realizado no experimento anterior, foi gerado um fluxo ICMP entre os hostsclientes que utilizam a fatia switch_stp. Uma vez encontrada a topologia, através domódulo Discovery, o algoritmo calcula a melhor forma de desfazer o ciclo, desabilitandoumas das portas do comutador que foi escolhida no cálculo.

Na Figura 1.27, os itens numerados de 1 a 5 mostram o processo de reconheci-mento de características dos comutadores que compõem a fatia, além da convergência daaplicação na habilitação (e não-habilitação) de portas.

Figura 1.27. Log do controlador sobre as decisões do STP

O item “1” corresponde à descoberta dos comutadores, neste momento o comandode non-flood é enviado em todas as portas dos comutadores OpenFlow descobertos, rep-resentados por valores numéricos. No item “2”, o primeiro comutador é selecionado, temsuas portas 1, 3 e 4 habilitadas para flood e a porta 2 desabilitada. Deste modo o algoritmosegue para os próximos comutadores candidatos conforme itens “3”, “4” e “5” até que aárvore esteja formada e o protocolo convirja completamente, habilitando assim o tráfegoentre os dois hosts. A partir desse momento o encaminhamento dos dados é igual ao domódulo comutador.

Fatia Roteamento

Na fatia switch_router utiliza-se a aplicação de routing. Esta aplicação possui a capaci-dade de aplicar aos nós o comportamento de roteadores, efetuando encaminhamento nacamada 3. A Figura 1.28 exibe como os recursos de rede que são visualizados pelo con-trolador NOX que está habilitado com a aplicação routing.

Para aplicar os nós que fazem parte da fatia neste experimento, a seguinte config-uração foi realizada:


Figura 1.28. Visão do controlador do fatia Roteamento

# fvctl addFlowSpace 00:00:00:00:00:01 10 dl_vlan=300 “Slice:switch_router=4”# fvctl addFlowSpace 00:00:00:00:00:02 10 dl_vlan=300 “Slice:switch_router=4”# fvctl addFlowSpace 00:00:00:00:00:03 10 dl_vlan=300 “Slice:switch_router=4”# fvctl addFlowSpace 00:00:00:00:00:06 10 dl_vlan=300 “Slice:switch_router=4”# fvctl addFlowSpace 00:00:00:00:00:09 10 dl_vlan=300 “Slice:switch_router=4”

Para esta fatia utilizou-se os comutadores SW01, SW02, SW03, SW06 e SW09.Cada host está endereçado com sub-redes diferentes por meio das seguintes configuraçõesde endereçamento IP listados pela Tabela 5.

Tabela 1.4. Endereçamento IP dos hosts ligados ao slice

Host Endereço IP Sub-redeHost02 192.168.1.5 192.168.1.0/24Host04 192.168.1.6 192.168.1.0/24Host05 10.1.1.7 10.1.1.0/24

Para testar o encaminhamento de pacotes via camada 3, utiliza-se dois fluxos depacotes, sendo o primeiro UDP e o segundo TCP. Desta forma, entre os hosts 02 e 04têm-se um fluxo TCP na porta 200 e entre os hosts 02 e 05 têm-se um fluxo UDP na porta100.

O que se percebeu nesse experimento é que na primeira tentativa de estabeleci-mento de comunicação entre os hosts, tanto para fluxo TCP quanto UDP, são trocadasinformações de controle (comutador e controlador), para determinar o que fazer comesse fluxo. Os primeiros pacotes são enviados para a fila, através da ação IN_QUEUE,ilustrado na Figura 1.29, para evitar a perda de pacote, enquanto se determina a sua rota.Quando a rota é determinada, são aplicadas as ações de encaminhamento para cada nóOpenFlow do caminho encontrado, conforme ilustrado na Figura 1.30. De forma que


essa rota é calculada apenas uma vez quando o primeiro pacote entra no roteador, osdemais usam as ações que já foram aplicadas.

O que se observa é que quando um pacote é destinado a um host que está nestamesma sub-rede, o nó age como um comutador, encaminhando o pacote sem alteraçõespara uma porta conhecida. Caso um pacote seja destinado para um endereço IP no qual oroteador conhece o próximo salto, o mesmo utiliza a rota previamente definida e aplica asações de encaminhamento para cada comutador na rota determinada.

Figura 1.29. Ações aplicadas a tabela de fluxo dos nós openflow durante oprimeiro pacote

Figura 1.30. Após a passagem dos primeiro pacote

Também se observou que esta aplicação de roteamento não é baseada em algorit-mos específicos tais como de vetor de distâncias ou estado de enlaces. O que se percebe éa necessidade de melhorias e novas idéias para a aplicação de roteamento. Nesse sentido,


existem exemplos de esforços vem sendo desenvolvido para aplicar essas características,como é o caso da aplicação QuagFlow [Nascimento et al. 2010].

Por meio do QuagFlow é possível aplicar algoritmos de roteamento baseado noconjunto de aplicações disponíveis do Quagga [Quagga 2011], para uso no OpenFlow.Desse modo, algoritmos como RIP ou OSPF, implementados no Quagga, podem ser uti-lizados pelo NOX para atender aos requisitos mais exigentes de roteamento.

1.5.3. Conclusão

O estudo de caso mostrou que de uma maneira rápida e simplificada é possível con-struir infraestruturas prontas para experimento de protocolos baseadas em redes Open-Flow. Além disso, é uma excelente ferramenta para experimentação em Internet do Fu-turo (IF). Observou-se que com pequenos recursos é possível iniciar estes estudos para IFvirtualizando todo plano de dados alinhado às necessidades de um ambiente real.

Um ponto fraco da solução seria a não disponibilidade de interfaces de mais altonível, como por exemplo interfaces web que facilitem a interação com FlowVisor. O quedeixa a sua manipulação fortemente dependente do administrador da rede para criação dafatia do experimento com alta probabilidade de falha durante a inserção de comandos.

1.6. Considerações finais e o futuro em Pesquisa Experimental em Internet doFuturo

1.6.1. Considerações Finais

A virtualização tornou-se a principal ferramenta para pesquisa de desenvolvimento e ha-bilitação da Internet do Futuro em todas as comunicações ou camadas computacionaisdessas grandes infraestruturas. Com o uso da virtualização na construção desses ambi-entes de teste foi possível desacoplar a complexidade dos recursos físicos dos serviçosoferecidos e apresentar simples interfaces com usuário, em localizações geográficas dis-tintas e independentes de dispositivo de acesso.

Além disso, a virtualização terá um papel importante, pois ela permitirá a com-paração das novas tecnologias que estão sendo desenvolvidas para Internet do Futuro,com as tecnologias atuais. Também garantirá que tecnologias desenvolvidas no passadopossam ser disponíveis nessa moderna infraestrutura.

Com isso, a construção dos arcabouços para esses ambientes de teste está sendodesenvolvida com base na virtualização, seja ela baseada na virtualização do substrato,seja na infraestrutura física que contém todos os hardware e software para inicializar osrecursos virtuais, bem como para a criação da infraestrutura virtual contendo os recursosvirtuais e a topologia lógica, interligando-as.

O arcabouço OpenFlow é uma dessas soluções, pois provê um protocolo abertopara programação do comportamento de fluxos de pacote em diferentes comutadores eroteadores. A rede contendo OpenFlow pode ter o tráfego particionado entre tráfego deprodução e tráfego de experimentação, de maneira que pesquisadores possam controlarseus próprios fluxos. A rede de produção permanecerá isolada e processada da mesmamaneira que antes do uso do OpenFlow.


Ainda, o OpenFlow integrado com a ferramenta FlowVisor é capaz de criar evirtualizar elementos de redes de modo que uma mesma infraestrutura física possa sercompartilhada entre várias topologias lógicas, onde cada uma possui sua própria lógicade encaminhamento e tratamento de fluxos de pacotes distintos.

Por fim, o OpenFlow possibilita de maneira rápida e simples a criação de uma in-fraestrutura para concepção de novos protocolos, como apresentada na seção de estudosde casos onde em um único servidor, conseguimos simular uma infraestrutura de comuta-dores e roteadores OpenFlow. Também conseguimos aplicar os conceitos de virtualizaçãobaseada em fatias de recursos e redes programáveis.

Este capítulo apresentou o andamento da pesquisa experimental em Internet doFuturo no mundo e observou duas grandes tecnologias que estarão presentes nessas in-fraestruturas montadas em escala mundial. São elas: a virtualização e o arcabouço Open-Flow.

1.6.2. Tendências Futuras

Nossa observação é que esta busca pela Internet do Futura ainda está em sua fase inicial,porém se expandindo com rapidez em algumas regiões do mundo. Liderando esta buscaestão os EUA, a UE e o Japão, seguida por Coreia, China e Brasil.

Nos EUA o programa GENI está iniciando a sua terceira fase, a chamada espiral 3,e as tendências, nesta terceira fase, será iniciar o suporte de pesquisadores nas infraestru-turas de experimentação e a incrementação de recursos disponíveis para uso entre seususuários, através de integração à chamada meso-scale, envolvendo a participação de maiornúmero de universidades interligadas pelas grandes redes de pesquisa, Internet2 e NLR.Além disso, a ênfase será em ambientes de redes móveis 4G na periferia, integradas porredes ópticas e Ethernet nas redes fixas, e a ênfase no uso de tecnologia OpenFlow, parapossibilitar experimentação com redes definidas por software. O GENI está sendo com-plementado pelo novo programa Future Internet Architectures (FIA), lançado em 2010pela NSF, para fomentar pesquisa em novas arquiteturas, que poderiam ser validadas noambiente GENI.

Já na Europa, o programa FIRE, que deu início no final de 2010 à segunda ro-dada de grandes projetos, incluindo OFELIA, o primeira projeto europeu com OpenFlow.Diferente dos EUA, onde foram separados os programas FIA (pesquisa em arquiteturas) eGENI (ambiente de teste), os europeus misturam ambos facetas no mesmo projeto, atravésdo estudo de casos de uso dos ambientes montados. No Japão, representado pelo projetoAKARI, que está na em seu segundo período desenvolvimento, à tendência futura é parainício das construções de seus ambientes de teste e as primeiras demonstrações experi-mentais. O objetivo é que para o final de 2016 oferecer um protótipo da nova geração derede para disponibilidade aos pesquisadores. OpenFlow também é importante no Japãoe a empresa NEC está apostando na importância desta tecnologia para seu portfólio deprodutos das categorias comutador e controlador.

Por fim, no Brasil, a pesquisa em Internet do Futuro iniciou através de projetos iso-lados, como o projeto Horizon [Horizon 2011] e o projeto Webscience [WebScience 2010]que prevê a construção de uma rede para experimentação em arquiteturas de Internet do


Futuro. Este último projeto servia como uma das bases para a proposta de cooperação comum consórcio europeu, através do projeto FIBRE submetido às Chamadas Coordenadasem TIC entre Brasil e a UE.

O projeto FIBRE, se confirmado, tornará possível a construção de uma instalaçãoexperimental compartilhada de larga escala, que permita a experimentação em infraestru-tura de rede e aplicações distribuídas. Isso consistirá em um novo ambiente de testebaseado em OpenFlow no Brasil e uma melhoria dos recursos dos projetos OFELIA eOneLab, atualmente em desenvolvimento na Europa.

Além disso, possibilitará a federação de ambientes de teste dos parceiros brasileirose europeus para permitir aos pesquisadores que usem recursos de ambos em um mesmoexperimento. Tal iniciativa demonstrará o potencial das instalações ao mostrar aplicaçõesbaseadas em OpenFlow, estabelecidas sobre os recursos das instalações federadas. Por-tanto, aumentará a colaboração e a troca de conhecimentos entre pesquisadores europeuse brasileiros no campo de Internet do Futuro.

AgradecimentosEste trabalho esta sendo apoiado por recursos financiados pelas seguintes instituições:FAPESPA, CAPES, CNpQ e RNP.

Referências[AKARI 2009] AKARI (2009). New generation network architecture: Akari concep-

tual design. Technical report, National Institute of Information and Communica-tions Technology. http://akari-project.nict.go.jp/eng/concept-design/AKARI_fulltext_e_preliminary.pdf.

[Andersen et al. 2001] Andersen, D., Balakrishnan, H., Kaashoek, F., and Morris, R.(2001). Resilient overlay networks. SIGOPS Oper. Syst. Rev., 35:131–145.

[Andersen 2003] Andersen, D. G. (2003). Mayday: distributed filtering for internet ser-vices. In Proceedings of the 4th conference on USENIX Symposium on Internet Tech-nologies and Systems - Volume 4, USITS’03, pages 3–3, Berkeley, CA, USA. USENIXAssociation.

[Balakrishnan et al. 2004] Balakrishnan, H., Lakshminarayanan, K., Ratnasamy, S.,Shenker, S., Stoica, I., and Walfish, M. (2004). A layered naming architecture forthe internet. SIGCOMM Comput. Commun. Rev., 34:343–352.

[Banniza et al. 2009] Banniza, T.-R., Boettle, D., Klotsche, R., Schefczik, P., Soellner,M., and Wuenstel, K. (2009). A european approach to a clean slate design for thefuture internet. Bell Lab. Tech. J., 14:5–22.

[BEACON 2011] BEACON (2011). Java-based openflow controller. Disponível em:http://www.openflowhub.org/display/Beacon/Beacon+Home.Acessado em: 20/02/11.

[BEN 2011] BEN (2011). Breakable experimental network. Disponível em: https://geni-orca.renci.org/trac. Acesso em: 20/02/2011.


[Bhatia et al. 2008] Bhatia, S., Motiwala, M., Muhlbauer, W., Mundada, Y., Valancius,V., Bavier, A., Feamster, N., Peterson, L., and Rexford, J. (2008). Trellis: a platformfor building flexible, fast virtual networks on commodity hardware. In Proceedings ofthe 2008 ACM CoNEXT Conference, CoNEXT ’08, pages 72:1–72:6, New York, NY,USA. ACM.

[Bi 2011] Bi, J. (2011). Future internet related research activities in china. Disponívelem: http://www.apan.net/meetings/Hanoi 2010/Session/Slides/FutureInternet/3-1.pdf .Acesso em 20/02/2011.

[Bolte et al. 2010] Bolte, M., Sievers, M., Birkenheuer, G., Niehorster, O., andBrinkmann, A. (2010). Non-intrusive virtualization management using libvirt. InDesign, Automation Test in Europe Conference Exhibition (DATE), 2010, pages 574–579.

[BonFIRE 2011] BonFIRE (2011). Building service testbeds on future internet researchand experimentation. Disponível em: http://www.bonfire-project.eu/project . Acessoem: 20/02/2011.

[Campanella 2011] Campanella, M. (2011). Federica: A virtualization based infras-tructure for future and present internet research. In Akan, O., Bellavista, P., Cao,J., Dressler, F., Ferrari, D., Gerla, M., Kobayashi, H., Palazzo, S., Sahni, S., Shen,X. S., Stan, M., Xiaohua, J., Zomaya, A., Coulson, G., Magedanz, T., Gavras, A.,Thanh, N. H., and Chase, J. S., editors, Testbeds and Research Infrastructures. Devel-opment of Networks and Communities, volume 46 of Lecture Notes of the Institute forComputer Sciences, Social Informatics and Telecommunications Engineering, pages123–132. Springer Berlin Heidelberg. 10.1007/978-3-642-17851-1_9.

[Chowdhury and Boutaba 2010] Chowdhury, N. M. K. and Boutaba, R. (2010). A surveyof network virtualization. Comput. Netw., 54:862–876.

[Chu et al. 2001] Chu, Y., Rao, S., Seshan, S., and Zhang, H. (2001). Enabling confer-encing applications on the internet using an overlay muilticast architecture. SIGCOMMComput. Commun. Rev., 31:55–67.

[Clack 2011] Clack, D. C. (2011). Toward the design of a future in-ternet. technical report: National science fundation. Disponível em:http://groups.csail.mit.edu/ana/People/DDC/Future Internet 7-0.pdf. NationalScience Fundation.

[CREW 2011] CREW (2011). Cognitive radio experimentation world. Disponível em:http://www.crew-project.eu/. Acesso em: 20/02/2011.

[Dabek et al. 2001] Dabek, F., Kaashoek, M. F., Karger, D., Morris, R., and Stoica, I.(2001). Wide-area cooperative storage with cfs. SIGOPS Oper. Syst. Rev., 35:202–215.

[E-GENI 2011] E-GENI (2011). Enterprise geni. Disponível em:http://OpenFlow.org/wk/index.php/E-GENI Acesso em: 20/02/2011.


[Egi et al. 2010] Egi, N., Greenhalgh, A., Handley, M., Hoerdt, M., Huici, F., Mathy, L.,and Papadimitriou, P. (2010). A platform for high performance and flexible virtualrouters on commodity hardware. SIGCOMM Comput. Commun. Rev., 40:127–128.

[Eide et al. 2006] Eide, E., Stoller, L., Stack, T., Freire, J., and Lepreau, J. (2006). Inte-grated scientific workflow management for the emulab network testbed. In Proceed-ings of the annual conference on USENIX ’06 Annual Technical Conference, pages33–33, Berkeley, CA, USA. USENIX Association.

[Feldmann 2007] Feldmann, A. (2007). Internet clean-slate design: what and why? SIG-COMM Comput. Commun. Rev., 37:59–64.

[FIND 2011] FIND (2011). Future internet design. http://www.nets-find.net.

[Fink and R. 2011] Fink, B. and R., S. (2011). Nuttcp. Disponível em:ftp://ftp/lcp.nrl.navy.mil/pub/nuttcp/2006. Acesado em: 20/02/2011.

[FIRE 2008] FIRE (2008). Future internet research and ex-periment: Area 6. Disponível em: http://www.future-Internet.eu/fileadmin/documents/bled_documents/experiemental_facilities/FIRE-Issues-paper-2.2.pdf.

[FIRE 2010] FIRE (2010). Future internet research and experimentation: An overviewof european fire initiative and its projects. Technical report, Disponível em:http://cordis.europa.eu/fp7/ict/fire/docs/fire-brochure-201_en.pdf.

[FIRE 2011] FIRE (2011). Future internet research and experimentation.http://cordis.europa.eu/fp7/ict/fire/. FP7 - Seventh Framework Programme.

[GENI 2011] GENI (2011). Global environment for network innovations.http://www.geni.net.

[GENI-Sys 2008] GENI-Sys (2008). Geni system overview. Disponível em:http://groups.geni.net/geni/attachment/wiki/GeniSysOvrvw/GENISysOvrvw092908.pdf.

[Greene 2009] Greene, K. (2009). Tr10: Software-defined networking.http://www.technologyreview.com/printer_friendly_article.aspx?id=22120.

[Gude et al. 2008] Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown, N.,and Shenker, S. (2008). Nox: towards an operating system for networks. SIGCOMMComput. Commun. Rev., 38:105–110.

[Horizon 2011] Horizon (2011). Horizon project: A new horizon to the internet.Disponível em: http://www.gta.ufrj.br/horizon/. Acesso em: 20/02/2011.

[Hu et al. 2010] Hu, J.-W., Chen, H.-M., Liu, T.-L., Tseng, H.-M., Lin, D., Yang, C.-S.,and Yeh, C. (2010). Implementation of alarm correlation system for hybrid networksbased upon the perfsonar framework. In Advanced Information Networking and Appli-cations Workshops (WAINA), 2010 IEEE 24th International Conference on, pages 893–898.


[INDIGO 2011] INDIGO (2011). Disponível em:http://www.OpenFlowhub.org/display/Indigo/Indigo+-+OpenFlow+for+Hardware+Switches. Acesso em: 20/02/2011.

[Jain 2006] Jain, R. (2006). Internet 3.0: ten problems with current internet architectureand solutions for the next generation. In Proceedings of the 2006 IEEE conference onMilitary communications, MILCOM’06, pages 153–161, Piscataway, NJ, USA. IEEEPress.

[Jannotti et al. 2000] Jannotti, J., Gifford, D. K., Johnson, K. L., Kaashoek, M. F., andO’Toole, Jr., J. W. (2000). Overcast: reliable multicasting with on overlay network.In Proceedings of the 4th conference on Symposium on Operating System Design &Implementation - Volume 4, OSDI’00, pages 14–14, Berkeley, CA, USA. USENIXAssociation.

[Joseph and Lewis 2008] Joseph, W. and Lewis, C. (2008). Green: The new computingcoat of arms? IT Professional, 10:12–16.

[Kim et al. 2009] Kim, D. Y., Mathy, L., Campanella, M., Summerhill, R., Williams, J.,Shimojo, S., Kitamura, Y., and Otsuki, H. (2009). Future internet: Challenges in virtu-alization and federation. Advanced International Conference on Telecommunications,0:1–8.

[Krishnamurthy et al. 2001] Krishnamurthy, B., Wills, C., and Zhang, Y. (2001). On theuse and performance of content distribution networks. In Proceedings of the 1st ACMSIGCOMM Workshop on Internet Measurement, IMW ’01, pages 169–182, New York,NY, USA. ACM.

[Liu et al. 2009] Liu, J., Cho, S., Han, S., Kim, K., Ha, Y., Choe, J., Kamolphiwong,S., Choo, H., Shin, Y., and Kim, C. (2009). Establishment and traffic measurementof overlay multicast testbed in koren, thairen and tein2. In Proceedings of the 6thInternational Conference on Mobile Technology, Application & Systems, Mobility’09, pages 42:1–42:7, New York, NY, USA. ACM.

[Lockwood et al. 2007] Lockwood, J. W., McKeown, N., Watson, G., Gibb, G., Hartke,P., Naous, J., Raghuraman, R., and Luo, J. (2007). Netfpga–an open platform forgigabit-rate network switching and routing. In Proceedings of the 2007 IEEE Interna-tional Conference on Microelectronic Systems Education, MSE ’07, pages 160–161,Washington, DC, USA. IEEE Computer Society.

[Lua et al. 2005] Lua, E. K., Crowcroft, J., Pias, M., Sharma, R., and Lim, S. (2005).A survey and comparison of peer-to-peer overlay network schemes. CommunicationsSurveys Tutorials, IEEE, 7(2):72 – 93.

[McKeown 2011] McKeown, N. (2011). Clean slate research program.http://cleanslate.stanford.edu/. Stanford Univesity.

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


[MiniNet 2011] MiniNet (2011). Rapid prototyping for software-defined networks.Disponível em: http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Mininet. Aces-sado em: 20/02/11.

[Moskowitz and Nikander 2005] Moskowitz, R. and Nikander, P. (2005). Host identityprotocol architecture. Internet draf, IETF.

[Moskowitz et al. 2005] Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T.(2005). Host identity protocol. Internet draf, IETF.

[Nascimento et al. 2010] Nascimento, M. R., Rothenberg, C. E., Salvador, M. R., andMagalhães, M. F. (2010). Quagflow: partnering quagga with openflow. In Proceedingsof the ACM SIGCOMM 2010 conference on SIGCOMM, SIGCOMM ’10, pages 441–442, New York, NY, USA. ACM.

[Nurmi et al. 2009] Nurmi, D., Wolski, R., Grzegorczyk, C., Obertelli, G., Soman, S.,Youseff, L., and Zagorodnov, D. (2009). The eucalyptus open-source cloud-computingsystem. In Proceedings of the 2009 9th IEEE/ACM International Symposium on Clus-ter Computing and the Grid, CCGRID ’09, pages 124–131, Washington, DC, USA.IEEE Computer Society.

[OFELIA 2011] OFELIA (2011). Openflow in europe - linking infrastructure and appli-cations. Disponível em: http://www.fp7-ofelia.eu/. Acesso em: 20/02/2011.

[OMF 2011] OMF (2011). control and management framework. Disponível:http://omf.mytestbed.net. Acesso em: 20/02/2011.

[ORCA 2011] ORCA (2011). Open resource control architecture. Disponível em:http://groups.geni.net/ geni/wiki/ORCABEN. Acesso em: 20/02/2011.

[Paul et al. 2011] Paul, S., Pan, J., and Jain, R. (2011). Architectures for the future net-works and the next generation internet: A survey. Comput. Commun., 34:2–42.

[Peterson et al. 2006] Peterson, L., Muir, S., Roscoe, T., and Klingaman, A.(2006). Planetlab architecture: An overview. Disponível em: http://www.planet-lab.org/files/pdn/pdn-06-031/pdn-06-031.pdf, PLANTLAB.

[Peterson et al. 2009] Peterson, L., Sevinc, S., Lepreau, J., and et al. (2009). Slice-based facility architecture, draft version 1.04. Disponiível em: http://svn.planet-lab.org/attachment/wiki/GeniWrapper/sfa.pdf.

[ProtoGENI 2011] ProtoGENI (2011). Disponível em:http://groups.geni.net/geni/wiki/ProtoGENI. Acesso em: 20/02/2011.

[Ps-Performace 2011] Ps-Performace (2011). ps-performace toolkit. Disponvel em:http://www.internet2.edu/performance/toolkit. Acesso em: 20/02/2011.

[Quagga 2011] Quagga (2011). Quagga routing suite. Disponível em:http://www.quagga.net/. Acesso em: 14/03/2011.


[Rexford and Dovrolis 2010] Rexford, J. and Dovrolis, C. (2010). Future internet archi-tecture: clean-slate versus evolutionary research. Commun. ACM, 53:36–40.

[Savage et al. 1999] Savage, S., Anderson, T., Aggarwal, A., Becker, D., Cardwell, N.,Collins, A., Hoffman, E., Snell, J., Vahdat, A., Voelker, G., and Zahorjan, J. (1999).Detour: informed internet routing and transport. Micro, IEEE, 19(1):50 –59.

[Scarabucci et al. 2005] Scarabucci, R. R., Stanton, M. A., de Barros, M. R. X., Sal-vador, M. R., Rossi, S. M., Sim?, F. D., Rocha, M. L., da Silva Neto, I. L., Rosolem,J. B., Fudoli, T. R. T., Mendes, J. M. D., Castro, N. F., Machado, I., Reggiani, A. E.,Paradisi, A., and Martins, L. (2005). Project giga-high-speed experimental ip/wdmnetwork. Testbeds and Research Infrastructures for the Development of Networks &Communities, International Conference on, 0:242–251.

[Shalunov 2011] Shalunov, S. (2011). Thrulay - network capacity tester. Disponível em:http://shlang.com/thrulay/, Acesso em: 20/02/2011.

[Sherwood et al. 2010a] Sherwood, R., Chan, M., Covington, A., Gibb, G., Flajslik, M.,Handigol, N., Huang, T.-Y., Kazemian, P., Kobayashi, M., Naous, J., Seetharaman,S., Underhill, D., Yabe, T., Yap, K.-K., Yiakoumis, Y., Zeng, H., Appenzeller, G.,Johari, R., McKeown, N., and Parulkar, G. (2010a). Carving research slices out of yourproduction networks with openflow. SIGCOMM Comput. Commun. Rev., 40:129–130.

[Sherwood et al. 2009] Sherwood, R., Gibb, G., Yap, K., Appenzeller, G., McKe-own, N., and Parulkar, G. (2009). Flowvisor: A network virtualization layer.Disponível em: http://OpenFlowswitch.org/downloads/technicalreports/OpenFlow-tr-2009-1flowvisor.pdf.

[Sherwood et al. 2010b] Sherwood, R., Gibb, G., Yap, K.-K., Appenzeller, G., Casado,M., McKeown, N., and Parulkar, G. (2010b). Can the production network be thetestbed? In Proceedings of the 9th USENIX conference on Operating systems designand implementation, OSDI’10, pages 1–6, Berkeley, CA, USA. USENIX Association.

[Spiral2 2010] Spiral2 (2010). Geni spiral 2 overview. Disponível em:http://groups.geni.net/geni/attachment/wiki/SpiralTwo/GENIS2Ovrvw060310.pdf.

[Stoica et al. 2004] Stoica, I., Adkins, D., Zhuang, S., Shenker, S., and Surana, S. (2004).Internet indirection infrastructure. IEEE/ACM Trans. Netw., 12:205–218.

[Subramanian et al. 2004] Subramanian, L., Stoica, I., Balakrishnan, H., and Katz, R. H.(2004). Overqos: an overlay based architecture for enhancing internet qos. In Pro-ceedings of the 1st conference on Symposium on Networked Systems Design and Im-plementation - Volume 1, pages 6–6, Berkeley, CA, USA. USENIX Association.

[Szegedi et al. 2009] Szegedi, P., Figuerola, S., Campanella, M., Maglaris, V., andCervello-Pastor, C. (2009). With evolution for revolution: managing federica for futureinternet research. Communications Magazine, IEEE, 47(7):34 –39.


[Tierney et al. 2009] Tierney, B., Metzger, J., Berkeley, L., Laboratory, N., Boote, J.,Boyd, E., Brown, A., Carlson, R., Zekauskas, M., and Internet, J. Z. (2009). perf-sonar: Instantiating a global network measurement framework. Disponível em:http://acs.lbl.gov/ tierney/papers/perfsonar-LBNL-report.pdf.

[UMF 2011] UMF (2011). Embedding real-time substrate measurements for cross-layer communications. Disponível em: http://groups.geni.net/geni/wiki/Embeddedem:20/02/2011.

[WebScience 2010] WebScience (2010). Brazilian institute for web science re-search. Disponível em: http://webscience.org.br/files/INCTportugues2010.pdf.Acesso em:20/02/2011.

[Wu et al. 2010] Wu, S., Deng, L., Jin, H., Shi, X., Zhao, Y., Gao, W., Zhang, J., andPeng, J. (2010). Virtual machine management based on agent service. In Parallel andDistributed Computing, Applications and Technologies (PDCAT), 2010 InternationalConference on, pages 199 –204.

[Yu et al. 2010] Yu, M., Rexford, J., Freedman, M. J., and Wang, J. (2010). Scalableflow-based networking with difane. SIGCOMM Comput. Commun. Rev., 40:351–362.


Pesquisa Experimental para a Internet do Futuro

Documents

Transcript of Pesquisa Experimental para a Internet do Futuro