openflow e redes definidas por software: um novo …...openflow e redes definidas por software: um...

OpenFlow e redes definidas por software: umnovo paradigma de controle e inovação em

redes de pacotesChristian Esteve Rothenberg*, Marcelo Ribeiro Nascimento, Marcos Rogério Salvador, Maurício

Ferreira Magalhães**

Há algum tempo observa-se o surgimento da necessidade de maior abertura e flexibilidade dosequipamentos de rede, especialmente com o propósito de pesquisa e inovação. Os roteadores atuaisimplementam uma arquitetura composta por uma camada de software fechada, que é executada em umhardware proprietário. Esse modelo resulta em soluções de alto custo, dificulta a inserção de novasfuncionalidades e inviabiliza a experimentação de novas ideias. Com o avanço da padronização doprotocolo OpenFlow para programar o plano de encaminhamento dos equipamentos de redes depacotes, o conceito de redes programadas por software traz um novo paradigma de inovação cujopotencial disruptivo assemelha-se ao da introdução de sistemas operacionais em computadores e, maisrecentemente, em dispositivos móveis. Este artigo introduz os princípios da tecnologia OpenFlow eapresenta a arquitetura RouteFlow como exemplo de inovação para a função de roteamento em umambiente aberto (open source), executado sobre hardware comercial (commodity).

Palavras-chave: Redes de pacotes. Roteamento. Encaminhamento. Software livre. Virtualização.

Introdução

A infraestrutura das redes de pacotes écomposta, atualmente, por equipamentosproprietários, fechados e de alto custo, cujasarquiteturas básicas são concebidas a partir dacombinação de circuitos dedicados,responsáveis por garantir alto desempenho(Application Specific Integrated Circuit – ASIC),ao processamento de pacotes. A infraestrutura écomplementada por uma camada de software decontrole, responsável pelo suporte a umaextensa pilha formada por um número elevadode protocolos. No entanto, torna-se evidente anecessidade de especialização da lógica decontrole de acordo com cada tipo e objetivo derede. Porém, qualquer mudança de configuraçãoavançada do equipamento ou especialização dalógica de controle e tratamento dos pacotes ou,ainda, inserção de novas funcionalidades estãosujeitas a ciclos de desenvolvimento e de testesrestritos ao fabricante do equipamento,resultando em um processo demorado e custoso(HAMILTON, 2009). No âmbito da pesquisa,essas exigências são ainda maiores poisrequerem experimentações de novos protocolose funcionalidades da rede em condições reais,idealmente em ambientes “espalhados” da redeem operação (SHERWOOD et al., 2010).A ausência de flexibilidade no controle dofuncionamento interno dos equipamentos assimcomo o alto custo da infraestrutura vigente sãobarreiras para a evolução das arquiteturas e paraa inovação decorrente da oferta de novosserviços e aplicações de rede (ANWER et al.,

2010).Este artigo faz um levantamento do estado daarte da tecnologia OpenFlow como quebra deparadigma de controle em software (remoto) dosequipamentos de rede, habilitando o conceito deredes definidas por software. Como exemplo deutilização, apresenta-se um trabalho emdesenvolvimento, voltado para uma arquiteturade roteamento denominada RouteFlow(NASCIMENTO et al., 2011), cujo controle érealizado remotamente via software. Essaarquitetura é implementável em produtoscomerciais e utiliza ambientes de software dedomínio público para implementação das funçõesde controle.

1 Redes definidas por software

Apesar da evolução formidável da Internet, emtermos de penetração e de aplicações, suatecnologia, representada pela arquitetura emcamadas e pelos protocolos do modelo TCP/IP,não evoluiu suficientemente nos últimos vinteanos. A Internet tornou-se comercial e osequipamentos de rede tornaram-se “caixaspretas”, ou seja, implementações integradasverticalmente baseadas em software fechadosobre hardware proprietário. O resultado dessemodelo é o já reconhecido engessamento daInternet (CHOWDHURY; BOUTABA, 2009).Em contraste com o desenho da arquitetura daInternet, caracterizada por um plano de controle(PC) distribuído, os avanços na padronização deAPIs (Application Programming Interface)independentes do fabricante do equipamento

*Autor a quem a correspondência deve ser dirigida: [email protected]. ** Faculdade de Engenharia Elétrica e de Computação – Unicamp.

Cad. CPqD Tecnologia, Campinas, v. 7, n.1, p. 65-76, jul. 2010/jun. 2011

OpenFlow e redes definidas por software: um novo paradigma de controle e inovação em redes de pacotes

(OPENFLOW, 2010; IETF, 2011) permitemmover grande parte da lógica de tomada dedecisão dos dispositivos de rede paracontroladores externos, que podem serimplementados com o uso da tecnologia deservidores comerciais (PCs), um recursoabundante, escalável e barato. Essa “lobotomia”da inteligência do equipamento da rede paracontroladores logicamente centralizadospossibilita a definição do comportamento da redeem software não apenas pelos fabricantes doequipamento, mas também por fornecedores oupelos próprios usuários, como, por exemplo,operadores de rede.

1.1 Arquiteturas de roteamento

Uma análise da arquitetura atual dos roteadores(Figura 1) permite observar que se trata de ummodelo formado basicamente por duas camadasbem distintas: o software de controle e ohardware dedicado ao encaminhamento depacotes (JUNIPER NETWORKS, 2010). Oprimeiro, encarregado de tomar as decisões deroteamento, transfere essas decisões para oplano de encaminhamento através de uma APIproprietária. A única interação da gerência com odispositivo ocorre através de interfaces deconfiguração (Web, SNMP, CLI, por exemplo),limitando o uso dos dispositivos àsfuncionalidades programadas pelo fabricante.É coerente pensar que se a arquitetura é,atualmente, composta por duas camadasautocontidas, elas não precisam estar fechadasem um mesmo equipamento. Para isso, bastaque exista uma forma padrão de se programar odispositivo de rede remotamente, permitindo quea camada de controle possa ser movida para umservidor dedicado e com alta capacidade deprocessamento. Desse modo, mantém-se o altodesempenho no encaminhamento de pacotes emhardware aliado à flexibilidade de se inserir,remover e especializar aplicações em softwarepor meio de um protocolo aberto paraprogramação da lógica do equipamento(Figura 1). Com esse propósito, nasceu oconsórcio OpenFlow (MCKEOWN et al., 2008),dando origem ao conceito de software-definednetworking – as redes definidas por software(GREENE, 2009).

Figura 1 Arquiteturas de roteadores: modelo atualmainframe e modelo programável OpenFlow

1.2 OpenFlow

O OpenFlow foi proposto pela Universidade deStanford para atender à demanda de validaçãode novas propostas de arquiteturas e protocolosde rede (incluindo as abordagens clean slate)sobre equipamentos comerciais. OpenFlowdefine um protocolo-padrão para determinar asações de encaminhamento de pacotes emdispositivos de rede, como, por exemplo,comutadores, roteadores e pontos de acessosem fio. As regras e ações instaladas nohardware de rede são responsabilidade de umelemento externo, denominado controlador, quepode ser implementado em um servidor comum,conforme Figura 2.

Figura 2 Exemplo de uma rede com OpenFlowhabilitado

A principal abstração utilizada na especificaçãoOpenFlow é o conceito de fluxo. Um fluxo éconstituído pela combinação de campos docabeçalho do pacote a ser processado pelodispositivo, conforme Figura 3. As tuplas podemser formadas por campos das camadas deenlace, de rede ou de transporte, segundo omodelo TCP/IP. Deve-se enfatizar que aabstração da tabela de fluxos ainda está sujeita arefinamentos, com o objetivo de oferecer umamelhor exposição dos recursos do hardware e,nesse caso, permitir a concatenação de váriastabelas já disponíveis, como, por exemplo,tabelas IP/Ethernet/MPLS. Nesse sentido, acontribuição mais importante do paradigma doOpenFlow é a generalização do plano de dados –qualquer modelo de encaminhamento de dadosbaseado na tomada de decisão fundamentadaem algum valor, ou combinação de valores, doscampos de cabeçalho dos pacotes pode sersuportado.

De forma pragmática, a especificação OpenFlow(OPENFLOW, 2010) procura reutilizar asfuncionalidades do hardware existente (por

66 Cad. CPqD Tecnologia, Campinas, v. 7, n.1, p. 65-76, jul. 2010/jun. 2011

Figura 3 Cabeçalhos disponíveis no OpenFlowpara a especificação de fluxos


exemplo, Access Control List – ACL em switchese roteadores para implementar serviços comoNAT, firewall e VLANs) através da definição deum conjunto simples de regras e das açõesassociadas: encaminhar, descartar, enviar para ocontrolador, reescrever campos do cabeçalho,etc.

1.2.1 Componentes

Basicamente, uma rede programável comOpenFlow consiste em equipamentos de redehabilitados para que o estado das tabelas defluxos possa ser instalado através de um canalseguro, conforme as decisões de um controladorem software:

1.2.1.1 Tabela de fluxosCada entrada na tabela de fluxos do hardware derede consiste em regra, ações e contadores.A regra é formada com base na definição dovalor de um ou mais campos do cabeçalho dopacote. Associa-se a ela um conjunto de açõesque definem o modo como os pacotes devem serprocessados e para onde devem serencaminhados. Os contadores são utilizadospara manter estatísticas de utilização e pararemover fluxos inativos. As entradas da tabela defluxos podem ser interpretadas como decisõesem cache (hardware) do plano de controle(software), sendo, portanto, a mínima unidade deinformação no plano de dados da rede.

1.2.1.2 Canal seguroPara que a rede não sofra ataques de elementosmal-intencionados, o canal seguro garanteconfiabilidade na troca de informações entre oswitch e o controlador. A interface de acessorecomendada é o protocolo SSL (Secure SocketLayer). Interfaces alternativas (passivas ouativas) incluem TCP e pcap (packet capture), esão especialmente úteis em ambientes virtuais eexperimentais pela simplicidade de utilização,pois não necessitam de chaves criptográficas.

1.2.1.3 Protocolo OpenFlowProtocolo aberto para comunicação que usa umainterface externa, definida pelo OpenFlow para atroca de mensagens entre os equipamentos derede e os controladores. Essas mensagenspodem ser simétricas (hello, echo vendor),assíncronas (packet in, flow removed, portstatus, error) ou, ainda, iniciadas pelo controlador(features, configuration, modify state, sendpacket, barrier).

1.2.1.4 ControladorÉ o software responsável por tomar decisões eadicionar e remover as entradas na tabela defluxos, de acordo com o objetivo desejado.O controlador exerce a função de uma camadade abstração da infraestrutura física, facilitando a

criação de aplicações e serviços que gerenciemas entradas de fluxos na rede. Esse modeloassemelha-se a outros sistemas de software queproveem abstração do hardware e funcionalidadereutilizável. Dessa forma, o controladorOpenFlow atua como um sistema operacional(SO) para gerenciamento e controle das redes, eoferece uma plataforma com base na reutilizaçãode componentes e na definição de níveis deabstração (comandos da API). Contudo, novasaplicações de rede podem ser desenvolvidasrapidamente (GUDE et al., 2008).A programabilidade do controlador permite aevolução em paralelo das tecnologias nos planosde dados e as inovações na lógica dasaplicações de controle. A Figura 4 mostra umaabstração de uma rede com OpenFlow e ocontrolador NOX executando inúmerasaplicações que necessitam de uma visão doestado da rede (network view). Essa visão podeser armazenada, por exemplo, em um simplesbanco de dados executado localmente ou em umservidor remoto.

Figura 4 Elementos de uma rede OpenFlow

1.2.2 OpenFlow em ação

Quando um pacote chega a um equipamentocom OpenFlow habilitado, os cabeçalhos dopacote são comparados às regras das entradasdas tabelas de fluxos, os contadores sãoatualizados e as ações correspondentes sãorealizadas. Se não houver correspondência entreo pacote e alguma entrada da tabela de fluxos, opacote é encaminhado, por completo, aocontrolador. Alternativamente, apenas ocabeçalho é encaminhado ao controladormantendo o pacote armazenado no buffer dohardware. Normalmente, os pacotes que chegam aocontrolador correspondem ao primeiro pacote deum novo fluxo ou, em função do tipo de pacote eda aplicação, o controlador pode optar porinstalar uma regra no switch para que todos ospacotes de determinado fluxo sejam enviadospara o controlador para serem tratadosindividualmente. Esse último caso corresponde,em geral, a pacotes de controle (ICMP, DNS,DHCP) ou de protocolos de roteamento (OSPF,BGP).Como exemplo de fluxo, têm-se todos os pacotes

Cad. CPqD Tecnologia, Campinas, v. 7, n.1, p. 65-76, jul. 2010/jun. 2011 67


em uma faixa de endereços IP ( roteamento IPtradicional), uma conexão TCP em uma portaespecífica ou, ainda, todos os pacotespertencentes a uma mesma VLAN. As açõesassociadas aos fluxos incluem:

a) encaminhar o fluxo de pacotes paradeterminada porta (ou portas);

b) modificar os campos do cabeçalho;c) encapsular e transmitir o pacote para o

controlador;d) descartar os dados, como medida de

segurança, com a implementação defirewalls, ou ainda para inibir ataques denegação de serviço;

e) encaminhar o pacote para oprocessamento normal do equipamentonas camadas 2 ou 3.

O último item garante que o tráfego experimentalnão interfira no processamento-padrão do tráfegode produção. Conforme ilustrado na Figura 5,outra forma de garantir isso é definir um conjuntode VLANs para fins experimentais. Essasegmentação do tráfego permite terequipamentos híbridos que processem tráfegolegado conforme os protocolos e asfuncionalidades embarcadas no equipamento e,ao mesmo tempo e de forma isolada, obtertráfego baseado na programabilidade doOpenFlow.

Figura 5 Modelo de operação híbrido com VLANsisolando tráfego legado e OpenFlow

Na versão 1.1 do protocolo OpenFlow (ainda sobespecificação), está sendo considerado o suportea múltiplas tabelas de fluxos concatenadas(Figura 6) mediante um novo conjunto deinstruções (Go-to-Table, Write-Metadata), bemcomo novas ações (copy/decrement TTL,push/pop tag, QoS) e campos de cabeçalho(VLAN priority, MPLS label/traffic class, SCTPport) para uma definição ainda mais completados fluxos e do conjunto de ações associadas.

Figura 6 Diagrama detalhando o tratamento de umpacote no pipeline de um switch OpenFlow

1.2.3 Fatores críticos de sucesso

Existem quatro razões fundamentais quecontribuem para a aceitação da tecnologiaOpenFlow:

a) o OpenFlow pode ser incorporado emequipamentos de rede (roteadores,switches, pontos de acesso Wi-Fi)comerciais, atualmente, em operação, semmodificação do hardware e mediante umaatualização do firmware, garantindo odesempenho de tecnologias consolidadasno encaminhamento de pacotesIP/Ethernet, como, por exemplo, ASICs,FPGAs, etc.;

b) o protocolo OpenFlow separa o plano decontrole do plano de dados, permitindo autilização de controladores remotosbaseados em servidores com sistemasoperacionais e linguagens de programaçãocomuns na indústria de TI. O software docontrolador é responsável por definir omodo como os fluxos de pacotes sãoencaminhados e processados na rede.Isso permite que o controle sobre o planode dados seja "terceirizado" apesquisadores, sistemas de gerência,desenvolvedores, operadores de rede,plataformas de serviços e, até mesmo, àspróprias aplicações finais, como, porexemplo, servidores de conteúdo ouserviços em nuvem. Dessa forma, ocontrole da rede deixa de estar embarcadonos equipamentos e limitado porimplementações e padrões com mais de15 anos de existência;

c) o OpenFlow não dependente da formacomo o software controla a rede, e ofereceum simples serviço de encaminhamentomulticamada (L1-L4) orientado a fluxosdefinidos por qualquer combinação demais de 20 cabeçalhos-padrão. Uma redeOpenFlow permite a definição de fatias derede (slices ou flow-spaces), com garantiade isolamento entre os diferentescontroladores que operam sobre a rede,permitindo que o tráfego operacional(conforme os protocolos tradicionais) e otráfego experimental (conforme definidopelo usuário/operador da rede) operem emparalelo;

d) o OpenFlow é compatível com a Internetatual, cujo tráfego pode continuar emoperação em uma ou mais fatias da redeOpenFlow.

Todos os argumentos citados, anteriormente,apontam o OpenFlow como uma tecnologiainovadora que abre uma série de oportunidadesde desenvolvimento tecnológico na área dasredes de pacotes. Com a consolidação dastecnologias de equipamentos programáveis emsoftware no padrão OpenFlow, ou tecnologias



similares, o conceito de redes definidas porsoftware envolve novos paradigmas de gerênciaintegrada, inovação em protocolos e serviçosbaseados em recursos de redes virtualizados,como, por exemplo, Network as a Service(CHOWDHURY; BOUTABA, 2009; KELLER;REXFORD, 2010).

1.3 Mercado e cenários de aplicação

Os fatores apontados anteriormente e o potencialdisruptivo da tecnologia OpenFlow têm atraído aatenção da indústria, o que tem se traduzido:

a) no desenvolvimento dos primeiros protótiposcom suporte ao OpenFlow (HP, NEC,Extreme, Arista, Ciena, Juniper, Cisco);

b) no suporte dos fornecedores deprocessadores em silício (Broadcom,Marven);

c) na criação de novas empresas (Nicira, BigSwitch Networks); e

d) no interesse de operadoras, como DeutscheTelekom e Docomo, e provedores deserviços em nuvem, como Google,Facebook e Amazon).

Entre os vários cenários de rede em que aadoção da tecnologia OpenFlow traz aspectospromissores, vale destacar:

a) redes corporativas: novos mecanismos decontrole de acesso e segurança, gerênciaintegrada de rede cabeada e sem fio,configuração de VLANs, suporte àmobilidade, etc. (CASADO et al., 2007);

b) backbone: convergência de redes depacotes e circuitos, (Figura 7), como, porexemplo, agregação e gerência dinâmica eflexível do tráfego, novos mecanismos deroteamento e engenharia de tráfego erecuperação de falhas; balanceamento dotráfego Web; mobilidade de máquinasvirtuais; etc. (GUDLA et al., 2010);

c) redes celulares: uso transparente dediversas redes de acesso(Wi-Fi/3G/WiMAX), separação do provedorde infraestrutura do provedor de serviços(por exemplo, virtual network operators),etc. (YAP et al., 2010);

d) data center: técnicas de conservação deenergia, engenharia de tráfego, roteamentoplano e multicaminho, suporte àvirtualização de hosts e software switches(KOPONEN et al., 2010);

e) redes domésticas: terceirização(outsourcing) da gerência de rede,compartilhamento da rede com váriosprovedores de serviços e usuários, como,por exemplo, Open Wi-Fi, e gerência deenergia com medidores inteligentes, comosmart grid;

f) redes de ensino e pesquisa: infraestruturade experimentação de novas arquiteturas derede e paradigmas de encaminhamento depacotes, compartilhamento de umainfraestrutura experimental multicamada,multidomínio e multitecnologia, validaçãosobre hardware comercial, etc.

Fonte: GUDLA et al., 2010

Figura 7 Rede híbrida com switches TDM, WDM eroteadores IP controlados por OpenFlow (NOX),que implementa as funcionalidades em software

2 Arquitetura RouteFlow

O RouteFlow é uma proposta de oferta deserviços de roteamento IP remoto de formacentralizada, e que visa um desacoplamentoefetivo entre o plano de encaminhamento e oplano de controle (ROUTEFLOW, 2011). Oobjetivo é tornar as redes IP mais flexíveis pelafacilidade de adição, remoção e especializaçãode protocolos e algoritmos. O RouteFlowarmazena a lógica de controle dos switchesOpenFlow na infraestrutura de rede, através deuma rede virtual composta por máquinas virtuais(MV), cada uma executando um código (engine)de roteamento de domínio público (open source).Essas MVs podem ser interconectadas demaneira a formar uma topologia lógica,espelhando a topologia de uma rede físicacorrespondente ou uma topologia virtualsimplificada. O ambiente virtual é armazenadoem um servidor externo, ou um conjunto deles,que se comunicam com os equipamentos doplano de dados através de um controladorOpenFlow, que transporta para o plano deencaminhamento as decisões tomadas pelosprotocolos de roteamento no plano de controle(OSPF, BGP, RIP). A Figura 8 ilustra umasub-rede com switches programáveis, em que alógica de roteamento é implementada no servidorRouteFlow. O resultado consiste numa solução flexível dealto desempenho e comercialmente competitiva,a partir da combinação de recursos disponíveis,como, por exemplo:

a) switches programáveis de baixo custo esoftware embarcado reduzido (OpenFlow);

b) pilhas de protocolos de roteamento opensource (QUAGGA, 2009; XORP, 2011); e



c) servidor de prateleira de alto poder deprocessamento e, também, de baixo custo.

Cabe ressaltar que, apesar de o controle estarfisicamente centralizado, ele continua distribuídologicamente. Dessa forma, não é necessáriaqualquer alteração dos protocolos de roteamentoexistentes. Além disso, a solução pode tornar-semais escalável no futuro, com o uso de váriosservidores de alto desempenho.

2.1 Blocos funcionais

Uma visão global dos principais componentes doRouteFlow pode ser observada na Figura 9. Aseguir, apresenta-se a descrição de cada um doscomponentes da arquitetura proposta.

Figura 9 Componentes da solução RouteFlow

2.1.1 RouteFlow-Slave (RF-S)

Cada MV do plano de controle executa umprocesso (daemon) responsável pelas seguintesfunções:

a) registrar a MV no controlador como recursoda topologia virtual, sendo que a MV setorna um recurso disponível para serutilizado na representação de um roteador;

b) gerenciar as interfaces de rede do sistema(portas do roteador);

c) detectar as atualizações das tabelasAddress Resolution Protocol (ARP) e de

roteamento do sistema; e d) converter rotas em fluxos a serem

instalados no plano de dados por meio daAPI do OpenFlow.

Pacotes de protocolos – e outros, cujos destinossejam o próprio roteador – são encaminhados erecebidos pela MV para processamento (ARP,ICMP, Telnet, SSH, OSPF, RIP, etc.). PacotesARP e ICMP, por exemplo, são tratados pelapilha TCP/IP do Linux, enquanto pacotes deprotocolos são utilizados pela engine deroteamento para cálculo de rotas. Oprocessamento no caminho inverso ocorre domesmo modo. Concomitantemente aoprocessamento de pacotes da MV, ummecanismo de polling executa a tarefa deverificar as tabelas ARP e ROUTE do sistemaem busca de atualizações que devem serreproduzidas no plano de dados. Quandoatualizações são detectadas, as modificaçõescorrespondentes são convertidas na instalaçãoou remoção de fluxos da tabela do elemento deencaminhamento atribuído à MV.

2.1.2 RouteFlow-Controller (RF-C)

É o componente central da arquitetura proposta.Como o próprio nome sugere, trata-se de umafunção de controle que conecta todos oselementos do plano de dados e as MVs do planode controle. As principais funções do RF-C são:

a) registrar-se no controlador de rede paraeventos de recebimento de pacotes,conexão e desconexão de switches;

b) registrar os recursos (MVs) disponíveis natopologia virtual;

c) fazer a configuração do software switchpara montar a topologia lógica da rede;

d) gerenciar o mapeamento entre switchesOpenFlow e MVs;

e) instalar/remover fluxos OpenFlow dosswitches do plano de dados.

A vinculação das máquinas virtuais aos switchesdo plano de dados pode ser feita estaticamenteatravés de um arquivo de configuração, quepermite configurar uma topologia virtualindependentemente da topologia física.Alternativamente, a configuração pode serdinâmica, com base em um mecanismo dedescoberta de topologia governado pelocontrolador de rede. Nesse último caso, a redevirtual será uma réplica da topologia física. Outrapossibilidade consiste em agregar um conjuntode nós físicos, como, por exemplo, switchstacking/trunking, em uma única MV no planovirtual, ou ter várias engines de roteamentoatuando sobre um mesmo elemento físico – oque remete ao conceito de roteadores virtuais,em que múltiplos planos de controle comobjetivos diferentes compartilham o mesmosubstrato hardware de rede (CHOWDHURY;BOUTABA, 2009).


Figura 8 Visão geral do RouteFlow


2.1.3 RouteFlow-Protocol (RF-P)

Protocolo desenvolvido na arquitetura propostapara a comunicação entre os componentes doRouteFlow. Nele, estão definidas as mensagense os comandos básicos para conexão econfiguração das MVs e, também,gerenciamento das entradas de roteamento emhardware. Entre os campos da mensagem-padrão estão: identificação do controlador,identificação da MV, tipo da mensagem,comprimento e dados.

3 Avaliação do protótipo RouteFlow

O RF-Controller foi implementado em C++ comouma aplicação do controlador open source NOX(2011). Como engine de roteamento, foi utilizadoo Quagga (2009), uma conhecida solução deroteamento open source com suporte aosprincipais protocolos de roteamento (RIP, OSPF,BGP). Como plataforma para programaçãoremota dos equipamentos de rede, utilizou-se aversão 1.0 da tecnologia OpenFlow, cujavantagem é sua abordagem multifornecedor.Isso significa que ele não depende do fabricantee do modelo do equipamento que compõe arede. Desde que haja suporte ao protocoloOpenFlow, não são necessárias mudanças nocontrolador nem nas aplicações de rede queexecutam sobre ele. A infraestrutura do plano dedados do protótipo é formada por NetFPGAs,que são hardware programáveis com quatrointerfaces de rede Gigabit e com móduloOpenFlow. A escolha da plataforma NetFPGA sedeu pela flexibilidade de programação do planode encaminhamento e pela taxa deprocessamento de pacotes em Gigabits.Também foi usado o switch L2/L3 CPqDEnterprise, baseado em um ASIC da Broadcomcom 24 portas de 1 Gbit/s e 2 de 10 Gbit/s.Devido ao número de equipamentos disponíveiscom suporte ao OpenFlow, por se tratar de umambiente real e não simulado, as redes testadasapresentam um número limitado de nós.Entretanto, a quantidade de nós é suficiente parauma avaliação de viabilidade da proposta,através da análise detalhada das trocas demensagens e dos tempos relacionados àconvergência da rede em caso de falha, como,por exemplo, o tempo de processamento dasmensagens RouteFlow e OpenFlow. Essasmensagens não existem em uma arquiteturaclássica de roteador com pilha de protocolosembarcada.

3.1 Tempo de convergência com tráfego linerate

Para os testes de convergência, foi utilizado umgerador e um analisador de tráfego configuradospara transmissão de pacotes IP de 1500 bytesem ambos os sentidos (full duplex), a uma taxa

de 1 Gbit/s. Dessa forma, garante-se que essasolução de roteamento remota sobre uma redeprogramável é capaz de operar com tráfego nataxa de transmissão da interface (line rate), umavez que os pacotes são processados emhardware (ARGYRAKI et al., 2008). A Figura 10 apresenta um gráfico que mostra otempo total de convergência da rede após falhade um enlace, utilizando o protocolo OSPFv3configurado com o parâmetro hello time em1 segundo. Esse é o principal parâmetro doprotocolo diretamente relacionado ao tempo dedetecção de falhas. O hello time foi configuradopara 1, 5 e 10 segundos, correspondendo aosvalores típicos da indústria, que apresentamdefault de 10 segundos em enlaces Ethernet. Odead interval utilizado foi o recomendadocorrespondendo a quatro vezes o hello time.

Figura 10 Tempo total de convergência (OSPFhello interval = 1 s)

Figura 11 Fragmentação do tempo deconvergência (OSPF hello interval = 1 s)

Com o intuito de estudar os componentes quecontribuem com o tempo total de convergência,foram realizadas análises das mensagensenviadas e recebidas pelo hardware OpenFlowpara o controlador NOX. Nos resultados, estáincluso o tempo gasto pelas mensagens paratransitar entre o dispositivo de encaminhamento,o controlador e a MV. T1 pode ser obtido a partirdo intervalo entre o instante em que ocorre ainterrupção do tráfego e a primeira mensagem deLS-Update gerada pelo RouteFlow ao detectar afalha. Em seguida, leva-se T2 + T3 para que oRF-Slave inicie o envio da primeira mensagemde alteração de fluxo e, por último, T4 finaliza oprocesso com o restabelecimento do tráfego.



Tabela 1 Tempos de convergência após falha

HelloTime T1 [s] T2 + T3 [s] T4 [s] Ttotal [s]

OSPF Tmed. T90% Tmed. T90% Tmed. T90% Tmed. T90%

1 s 3,25 3,92 0,36 0,40 0,07 0,12 3,70 4,37

5 s 16,7 18,9 0,32 0,39 0,06 0,10 17,1 19,3

10 s 36,4 37,8 0,36 0,49 0,04 0,11 36,8 38,3

Na Figura 11 e na Tabela 1, apresentam-se ostempos conforme a fragmentação propostaanteriormente, em que cada um deles possui ovalor de tempo abaixo do qual se encontrammetade dos testes e o valor de tempo abaixo doqual se encontram 90% dos testes, num total de20 repetições para cada uma das configurações. Conforme os dados apresentados, o tempo totalde convergência é bem próximo de T1 (tempo dedetecção da falha). Portanto, o tempo restante,gasto com o cálculo de rotas, detecção demodificações da tabela de roteamento peloRF-Slave e instalação do fluxo tem poucoimpacto no tempo de convergência. Apesar deT2 e T3 não terem sido analisadosseparadamente, sabe-se que o tempo de pollingpara verificar atualizações da tabela deroteamento e ARP do Linux é fixo em 100 ms, ouseja, da soma T2 + T3, T3 representa até100 milissegundos, no pior caso. Vale ressaltarque foi utilizada a estratégia de polling porsimplificação; no entanto, podem ser feitasotimizações para reduzir substancialmente T3.Uma opção seria fazer com que a aplicação seregistrasse no Zebra (módulo central do Quagga)para receber notificações sobre a RIB. Dessaforma, a informação chegaria ao RF-Slave deforma muito mais rápida e eficiente.Dada a baixa representatividade dos tempos T3e T4 sobre o tempo total, é razoável afirmar aviabilidade da solução RouteFlow no contextoproposto.

3.2 Encaminhamento em slow path e fastpath

Outra forma de se avaliar o impacto de uma pilhade protocolos de roteamento remota é compararos tempos para os modos de encaminhamentode pacotes: slow path e fast path. A primeiraforma de encaminhamento ocorre quando oroteador precisa se comunicar com um nó deuma rede diretamente conectada a ele, masantes do aprendizado do endereço MAC dodestino, necessário para o encaminhamento emhardware. O slow path normalmente ocorre comos nós que entraram na rede ou que ficaram semcomunicação por um longo período. Por essarazão, essa operação nos roteadores, apesar denecessária, é considerada de baixa relevância.

O fast path refere-se ao encaminhamento emhardware que ocorre após o aprendizado dosendereços dos nós e o preenchimento dastabelas em hardware. Portanto, em umatransmissão de dados, o slow path ocorre,quando necessário, apenas para o primeiropacote, a partir do qual será realizado oaprendizado, sendo que o restante dos pacotesserão processados em line rate. Através desse teste, é possível avaliar adiferença de desempenho entre umencaminhamento por software e por hardware,de um roteador tradicional com protocolosembarcados, e do RouteFlow, com o plano decontrole remoto. Foram realizados testes dePING (Internet Control Message Protocol –ICMP) entre dois hosts diretamente conectados aportas distintas, de um mesmo roteador, econfiguradas em redes diferentes. No início, oshosts não têm conhecimento do endereço MACdos gateways, e o roteador também nãocontempla ambos os hosts em suas tabelas.Após o aprendizado dos endereços, são obtidosos valores de fast path. Foram utilizados osseguintes switches layer 3: CISCO 3560-eCatalyst, Extreme x450-e, CPqD Enterprise(protótipo) e RouteFlow. Os resultados dos testesestão apresentados na Tabela 2. Foi observado nos testes com o RouteFlow quealém do primeiro pacote ICMP request, o replytambém é encaminhado no slow path emsoftware. O motivo desse comportamento estárelacionado principalmente aos 100 ms de pollingpara que as atualizações nas tabelas do Linuxsejam detectadas. No momento da respostaICMP, os fluxos ainda não estão instalados e opacote precisa novamente ser direcionado aocontrolador para ser, então, encaminhado porsoftware. Portanto, é válido pensar em um tempoconsideravelmente menor para esse teste, comuma otimização da forma com que o RF-Slavepassa a ter conhecimento das atualizações,como exemplificado anteriormente. Outro ponto a ser destacado sobre o resultado deslow path, consideravelmente superior quandocomparado aos dispositivos com softwareembarcado, é o desempenho do controladorOpenFlow (NOX) utilizado nos testes, cujaproposta é a de prover uma plataforma simplesde desenvolvimento de aplicações de rede sem ocompromisso de manter o foco em desempenho.Nesse sentido, já foram identificadas possíveisotimizações que devem trazer ganhossignificativos no tempo de processamento dasmensagens no controlador, como, por exemplo,tornar o controlador multitarefa, de forma arealizar o processamento paralelo dasmensagens e, também, a implementação demensagens que agreguem mais informação,resultando em um menor chaveamento decontexto da aplicação para processar cada



pacote recebido.Em contrapartida, pode-se observar o melhordesempenho de fast path do RouteFlow, que é aforma de encaminhamento mais relevante.Nesse modo, a tabela de fluxos é encaminhadamais rapidamente, se comparado ao modolongest prefix match, que é utilizado nas tabelasde encaminhamento IP.

Tabela 2 Tempo de resposta ICMP

EquipamentoSlow path [ms] Fast path [ms]

Tmed. T90% Tmed. T90%

CISCO 3560-e C. 5,46 7,75 0,100 0,130

Extreme x450-e 11,30 14,00 0,106 0,141

CPqD Enterprise 14,20 17,30 0,101 0,147

RouteFlow 116,00 138,00 0,082 0,119

3.3 Discussão dos resultados e trabalhosfuturos

Os resultados alcançados na avaliação doprotótipo sugerem o grande potencial doRouteFlow como solução de roteamento pararedes de campus/corporativas, mediante o ganhode flexibilidade e o poder de inovaçãoproporcionados. As questões pertinentes aodesempenho não inviabilizam a proposta, umavez que já foram identificadas otimizações eoutras melhorias decorrentes da maturidade doprotocolo OpenFlow.Como em qualquer abordagem baseada emcontroladores centralizados, tornam-se desafiosos aspectos de escalabilidade, resiliência afalhas e segurança. Vale a pena notar que acentralização do modelo OpenFlow é somentelógica. Não existe nenhuma restrição a umaimplementação distribuída dos elementoscontroladores para atender aos requisitos deescala, desempenho e confiabilidade da rede.Esforços atuais no aprimoramento da arquiteturanesses aspectos incluem a distribuição do planode controle virtual em múltiplos servidores, aadoção de técnicas avançadas de virtualizaçãopara o balanceamento e migração das MVs, eoutras melhores práticas da programação desistemas em nuvem (cloud computing) paratornar a plataforma escalável e tolerante a falhas(ex.: BD distribuída do tipo NoSQL, replicação doestado em controladores backup) (KOPONENet al., 2010).Outros aspectos da proposta, que merecemconsiderações adicionais e são objeto de estudo,incluem o isolamento entre as MVs(FERNANDES et al., 2010) e a materialização doconceito de roteamento como serviço (KELLER;REXFORD, 2010). Dessa forma, pode-se obtertopologias lógicas independentes sobre umamesma rede, que executem protocolos distintos,resultando em uma abordagem de virtualização

com um melhor aproveitamento dos recursos dainfraestrutura, que, agora, pode sercompartilhada com diferentes propósitos(CASADO et al., 2010). Outra questão pertinente é o gargalo observadonas implementações disponíveis do OpenFlowquanto ao tamanho da tabela de fluxos (entre 2 e4 mil) e à capacidade de instalação de novasentradas por segundo (valor em torno de100 fluxos por segundo). Essas limitações sãotransitórias e serão contornadas com o avançodas especificações. Por exemplo, a partir daversão 1.1 do protocolo OpenFlow é possivelexpor e controlar as tabelas L2/L3 do hardware.Outras técnicas para reduzir o consumo dasentradas em hardware incluem algoritmos queescolhem aquelas entradas mais utilizadas(SARRAR et al., 2010). Essas e outras questõesencontram-se atualizadas na agenda de P&D doprojeto (ROUTEFLOW, 2011).

ConclusãoO conceito de redes definidas por software –decorrente da disponibilidade de um protocoloaberto, como o OpenFlow – promete um modelodisruptivo de inovação tecnológica de potencialimpacto nos cenários de convergência ampla(consolidação de planos de controle de redesheterogêneas) e de computação em nuvem(integração da rede com recursos de TI).Equipamentos de rede programáveis poderãoservir de base para o início de um ciclo deinovação aberta e rápida, envolvendopesquisadores, engenheiros e desenvolvedoresde software da academia, dos institutos deciência e tecnologia, dos fabricantes deequipamentos, das operadoras detelecomunicações e dos provedores de serviçosde Internet. Essas inovações se darão tanto noâmbito dos controladores como das aplicaçõesque são executadas nesses controladores. Poraplicações entenda-se algoritmos, protocolos,serviços e aplicações de controle e gerência deredes e serviços. Além disso, o movimento deinovação aberta, decorrente do modeloOpenFlow, poderá alavancar e induzir um grandedesenvolvimento na área de redes e tecnologiasda informação e computação de uma formaconsiderável, como ocorreu com oscomputadores pessoais com o advento dossistemas operacionais DOS, do Windows, doLinux e da consolidação destes por meio detécnicas de virtualização que dominam,atualmente, o mundo das tecnologias dainformação. Em resumo, os principais benefícios e impactosdo advento da tecnologia OpenFlow incluem:

1. Capacidade de inovação (possivelmenteaberta) em soluções de redes e serviçospara os proprietários de infraestrutura, osprovedores de serviços e a comunidade



de pesquisa.2. Oportunidade para que novas empresas

possam competir e inovar na área deaplicações avançadas para gerenciamentoe controle de redes de pacotes.

3. Novos modelos de negócio quepromovem redução de CAPEX e OPEXpor meio de novos serviços – através daalocação dinâmica de fatias/recursos darede, por exemplo – e dereaproveitamento de ativos –virtualização/consolidação.

4. Redução do custo de manutenção dosequipamentos, através, por exemplo, daincorporação de novos protocolos, daatualização do hardware do equipamento,etc.

5. Redução do tempo de implementação denovas funcionalidades nos equipamentose de integração de soluções de redesespecializadas às demandas do clientefinal.

6. Simplificação e barateamento dosequipamentos de rede pela diminuiçãodos requisitos mínimos do softwareembarcado e das pilhas de protocolosproprietárias.

7. Consolidação dos planos de controle e dagerência de infraestruturas de rede,facilitando a migração para novosprotocolos-padrão e tecnologias de redede transporte.

Como exemplo de inovação sobre redesprogramáveis com OpenFlow, foi apresentada aproposta do RouteFlow, que representa umaabordagem expansível (scale-out) paraarquiteturas de redes de pacotes. Com o planode controle externo ao dispositivo de rede, passaa existir maior independência entre esse plano eo de encaminhamento, de forma que ambosescalem e evoluam separadamente. Nessesentido, o RouteFlow possibilita o surgimento deredes mais baratas e flexíveis, mantendocompatibilidade com redes legadas e apoiandouma evolução das redes em que a conectividadeIP possa se tornar um produto (commodity)ofertado em um modelo de plataforma comoserviço (KELLER; REXFORD, 2010) e adiferenciação dos serviços dos operadores possase dar pelas potenciais inovações do paradigmade redes definidas por software.

AgradecimentosOs autores agradecem o apoio dado a estetrabalho, desenvolvido no âmbito do projeto“Arquitetura de Redes para ComunicaçõesMóveis IP” que contou com recursos do Fundopara o Desenvolvimento Tecnológico dasTelecomunicações – FUNTTEL, do Ministériodas Comunicações, através do Convênionº 002/2007 com o Ministério das Comunicações.

Referências

ANWER, M. B. et al. Switchblade: a platform forrapid deployment of network protocols onprogrammable hardware. In: SIGCOMM ’10.Proceedings... New York, USA: ACM, 2010.p.183-194.ARGYRAKI, K. et al. Can software routers scale?In: PRESTO ’08. Proceedings... New York, USA:ACM, 2008. p. 21-26.CASADO, M. et al. Ethane: Taking Control of theEnterprise. In: SIGCOMM '07. Proceedings...New York, USA: ACM, 2007. ______. Virtualizing the network forwardingplane. In: PRESTO ’10. Proceedings...Philadelphia, USA, 2010.CHOWDHURY, M.; BOUTABA, R. NetworkVirtualization: State of the Art and ResearchChallenges. IEEE Communications Magazine,v. 47, n. 7, p. 20-26, 2009. FERNANDES, N. et al. Virtual networks: isolation,performance, and trends. Annals ofTelecommunications, p. 1-17. 2010. GREENE, K. TR10: Software-DefinedNetworking. MIT Technology Review. 2009.Disponível em:<http://www.technologyreview.com/communications/22120/>. Acesso em: 31 jan. 2011.GUDE, N. et al. NOX: towards an operatingsystem for networks. SIGCOMM ComputerCommunication Review, 38(3), p.105-110,2008.GUDLA, V. et al. Experimental Demonstration ofOpenFlow Control of Packet and CircuitSwitches. In: OPTICAL FIBER CONFERENCE(OFC/NFOEC'10). Proceedings... San Diego,USA, 2010. HAMILTON, J. Networking: The last bastion ofmainframe computing. 2009. Disponível em:<http://perspectives.mvdirona.com/2009/12/19/NetworkingTheLastBastionOf-MainframeComputing.aspx>. Acesso em: 31 jan.2011.INTERNET ENGINEERING TASK FORCE(IETF). Forwarding and Control ElementSeparation (ForCES), WG, 2011. Disponível em:<http://datatracker.ietf.org/wg/forces/charter/>.Acesso em: 31 jan. 2011.JUNIPER NETWORKS. Network OperatingSystem Evolution. White paper, Oct. 2010.KELLER, E.; REXFORD, J. The 'Platform as aService' model for networking. In: INM/WREN.Proceedings... San Jose, USA, 2010.KOPONEN, T. et al. Onix: A distributed controlplatform for large-scale production networks. In:OSDI’10. Proceedings... Vancouver, Canada,



Oct. 2010. MCKEOWN, N. et al. OpenFlow: enablinginnovation in campus networks. SIGCOMMComputer Communication Review, 38,p.69-74, 2008.NASCIMENTO, M. R. et al. RouteFlow:Roteamento Commodity Sobre RedesProgramáveis. In: XXIX SIMPÓSIO BRASILEIRODE REDES DE COMPUTADORES - SBRC'2011,Campo Grande, MS, Brasil, 2011.Proceedings...NOX. An open-source OpenFlow controller.2011. Disponível em: <http://noxrepo.org>.Acesso em: 31 jan. 2011.SARRAR, N. et al. FIBIUM – towards hardwareaccelerated software routers. In: EUROVIEW2010 (poster session). SHERWOOD, R. et al. Can the productionnetwork be the testbed? In: OSDI’10.

Proceedings... USENIX Association, Vancouver,Canada, 2010.The OPENFLOW Specification. 2010. Disponívelem:<http://www.openflowswitch.org/documents/openflow-wp-latest.pdf>. Acesso em: 31 jan. 2011.The QUAGGA Project. 2009. Disponível em:<http://www.quagga.net>. Acesso em: 31 jan.2011.The XORP Project. Extensible open routerplatform. 2011. Disponível em:<http://www.xorp.org>. Acesso em: 31 jan. 2011. The ROUTEFLOW Project. 2011. Disponível em:<https://sites.google.com/site/routeflow/>. Acessoem: 31 mai. 2011. YAP, K. K. et al. Blueprint for IntroducingInnovation into Wireless Mobile Networks. In:VISA'10, New Delhi, India, 2010. Proceedings...New York: ACM, 2010.

Abstract

For some time we have seen the need for greater openness and flexibility of networking equipment, notonly for research purposes, but also in search of in-house innovation. Today’s networking gear follows themodel of computer mainframes, with closed software running on proprietary hardware. This approachresults in expensive solutions and prevents equipment owners to put new ideas into practice. Advances inthe standardization of OpenFlow as a hardware-independent, open protocol to control the networking gearof packet networks introduces the notion of software-defined networks, a new paradigm for innovationwith a disruptive potential comparable to the emergence of operating systems in the computer and mobiledevice industries. This paper introduces the principles of OpenFlow and presents the RouteFlow as anexample of innovative ongoing work on open-source routing services over commodity hardware.

Key words: Packet networks. Routing. Switching. Free Software. Virtualization.


openflow e redes definidas por software: um novo …...openflow e redes definidas por software: um...

Documents