Relatório ReVirProgramabilidade em Redes Virtualizadas

Julho 2011

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 VIRTUALIZAÇÃO DE REDES DE COMPUTADORES . . . . . . . . . . 52.1 OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.1 FlowVisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 VMWare e VirtualBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 LibVirt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 PROGRAMABILIDADE DE REDES . . . . . . . . . . . . . . . . . . . . 123.1 Propostas da Comunidade Científica . . . . . . . . . . . . . . . . . . . . 123.1.1 Redes Ativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.2 Agentes Móveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.3 MIBs DISMAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 Tecnologias Disponíveis no Mercado . . . . . . . . . . . . . . . . . . . . 283.2.1 Click Modular Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.2 OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2.3 Juniper Junos SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.4 Cisco AON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.5 NetFPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . 444.1 Propostas da comunidade científica . . . . . . . . . . . . . . . . . . . . . 444.2 Tecnologias Disponíveis no Mercado . . . . . . . . . . . . . . . . . . . . 45

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

1 INTRODUÇÃO

Atualmente, a Internet além de agilizar a comunicação entre as pessoas e organiza-ções, tornou-se um dos principais alicerces tanto para a disseminação quanto para a cons-trução do conhecimento. Um dos fatores que contribuíram para o sucesso da Internet é afacilidade de implementação aliada ao baixo custo das tecnologias de comunicação maisbásicas. Isto permitiu a rápida popularização da Internet e consequentemente a criação dediversas aplicações.

Grande parte das aplicações mais utilizadas da Internet atual (e.g., navegação Web,Twitter, DropBox, Skype, BitTorrent) são baseadas em softwares instalados em servidorese computadores pessoais. Neste sentido, pode-se dizer que o efetivo valor da Internet,para o usuário final, está na periferia da rede e não em seu núcleo. Evidentemente, se onúcleo da Internet não operar adequadamente, as aplicações deixarão de funcionar; emuma visão mais simplificada para o usuário, o núcleo da Internet oferece basicamenteserviços de conexão.

Com o intuito de disponibilizar uma maior gama de funcionalidades e serviços nonúcleo da rede, diversas tecnologias e soluções foram propostas no passado, tais comoRedes Ativas (TENNENHOUSE et al., 1997), Agentes Móveis (WHITE, 1996) e ScriptMIB (LEVI; SCHOENWAELDER, 2001). O termo “programabilidade de redes” (LA-ZAR, 1997) foi cunhado para referenciar a capacidade que os usuários finais de uma redeteriam de programar os dispositivos do núcleo da mesma. Porém, o efetivo emprego desoluções de programabilidade nunca teve apoio dos administradores de rede. Um dosmotivos para o insucesso dessas tecnologias deriva-se da falta de garantias convincentesquanto à consistência das configurações aplicadas sobre os dispositivos ao serem progra-mados por usuários finais. Portanto, a programabilidade de redes ainda permanece comoum problema em aberto.

Nesse contexto, a comunidade científica se vê diante de diversos empecilhos para pro-por, experimentar e implementar novas arquiteturas e funcionalidades na rede atual. Taisempecilhos são também conhecidos pelo termo ossificação da Internet. Porém, recente-mente, tecnologias de virtualização de redes passaram a ser suportadas pelos principaisfornecedores de dispositivos de rede, como Cisco (CISCO, 2011a), Juniper (JUNIPER,2011) e Extreme Networks (NETWORKS, 2011). A virtualização de redes permite quedispositivos físicos abriguem internamente diversas instâncias de dispositivos lógicos. Épossível, por exemplo, ter um roteador físico hospedando vários roteadores virtuais. Asligações entre os roteadores virtuais formam então redes virtuais rodando acima de redesfísicas reais. Uma característica importante da virtualização é o isolamento entre dispo-sitivos lógicos em uma rede física com suporte à virtualização. Um roteador virtual, porexemplo, pode ser criado, deslocado e destruído sem afetar os outros roteadores virtuaisexistentes.

4

O isolamento proporcionado pelas tecnologias para virtualização de redes, e o fato deque a programabilidade de redes ainda é um problema em aberto, são razões que motivama retomada do desenvolvimento de tecnologias a fim de programar os dispositivos semafetar o funcionamento normal das redes. Redes com suporte à virtualização já são de fatoreais, mas ainda não são programáveis pelos usuários finais. A programabilidade de redespermitirá que inovações na Internet, até então realizadas apenas em sua periferia, possamtambém acontecer em seu núcleo. Por comparação, se aplicações altamente difundidasna Internet atual, como Skype e BitTorrent, operam apenas com softwares instalados emservidores e computadores pessoais, aplicações inovadoras para uma nova geração da In-ternet serão criadas a partir do desenvolvimento criativo e seguro, por parte dos usuáriosfinais, de softwares instalados agora também nos próprios dispositivos da rede. Isto pos-sibilita a criação de uma vasta gama de protocolos, aplicações, funcionalidades e novosserviços.

Apesar de o tema “programabilidade de redes” ter gerado, no passado, debates aca-lorados, acredita-se hoje que a programabilidade é uma solução factível para combatera ossificação da Internet, contribuindo assim para a criação da Internet do Futuro1. Emtal Internet do Futuro, um núcleo programável por usuários finais permitiria que serviçosinovadores pudessem ser criados. Da mesma forma que Twitter e DropBox represen-tam serviços que caracterizam a Internet atual, serviços que programam o núcleo da rederepresentariam uma Internet de próxima geração. Tal núcleo programável não existe atu-almente, portanto vislumbra-se uma relevante oportunidade.

Com o objetivo de fornecer uma visão geral sobre pesquisas relacionadas a progra-mabilidade e a virtualização de redes de computadores, no presente relatório do projetoReVir, apresentamos algumas das principais tecnologias que possibilitam a criação e ogerenciamento de redes virtualizadas. Além disso, são introduzidas as principais solu-ções, desenvolvidas pela academia ao longo dos anos, bem como as atuais tecnologiasdisponíveis no mercado, que implementam algum nível de programabilidade na rede.

O presente relatório está assim dividido. No Capítulo 2 é apresentada uma revisãodas mais relevantes tecnologias de virtualização de redes. No Capítulo 3 são descritassoluções que possibilitam a programabilidade de redes, soluções estas propostas pela co-munidade científica bem como disponíveis no mercado. No Capítulo 4 são apresentadasconsiderações finais deste relatório.

1De fato, a tradução da expressão Future Internet para o português não é consenso. Assim como nesterelatório, alguns autores utilizam a expressão Internet do Futuro (MOREIRA et al., 2009). Porém, existemtrabalhos que referenciam essa evolução como Futura Internet (CAMILO et al., 2005).

5

2 VIRTUALIZAÇÃO DE REDES DE COMPUTADORES

A comunidade científica vislumbra na virtualização de redes uma possível alternativapara superar as dificuldades existentes para propor, experimentar e implementar novasfuncionalidades e soluções para a Internet do Futuro.

Estas dificuldades se concentram, em sua maioria, nos problemas de manutenção darede, uma vez que pra cada implantação de uma técnica ou proposta, uma nova configu-ração seria necessária. Além disso, caso o experimento necessite de um ambiente real,é preciso manter os serviços de produção instalados funcionando corretamente, uma vezque a rede não é exclusiva para testes. Ou seja, é preciso criar uma camada isolada para otratamento do fluxo de dados dos testes, de forma que não gere redução no desempenho,na segurança, e/ou na qualidade de serviço da rede de produção.

Uma rede virtualizada pode ser a solução para estes problemas. Ela é definida comouma plataforma de rede que permite a manipulação de sub-redes lógicas, ou seja, permitecriar, adicionar, mover e alterar redes virtuais. Tais tarefas de manipulação das redesvirtuais são realizadas em software e não dependem de aquisição de equipamentos reaiscomo acontece em redes convencionais, o que economiza tempo e custos. Uma redefísica com suporte a virtualização é assim segmentada em várias redes lógicas baseadasnas necessidades dos usuários e não na disposição física dos equipamentos reais.

A virtualização de redes, fundamentada nos desejos da comunidade científica supra-citados, oferece uma série de benefícios que tratam de alguns aspectos físicos e teóricosfundamentais para que se alcance o objetivo claro de apoiar a inovação. Alguns deles,apontados por Anderson et al. (ANDERSON et al., 2005), Merwe e Kalmanek (JUNI-PER NETWORKS, 2009) são descritos a seguir.

• Isolamento - A virtualização de redes deve garantir o isolamento, tanto dos recursosfísicos da rede quanto entre os diversos recursos virtuais hospedados no hardware.Isto torna possível a utilização de múltiplas redes virtuais sobre uma única redefísica, sem comprometer a operação da mesma e sem interferir nos serviços virtuaisque já existem nessas redes.

• Flexibilidade e disponibilidade - Um dispositivo virtual deve poder ser criado, des-locado e removido sem afetar os outros roteadores virtuais existentes. Isto permiteque, ao ocorrer um problema no hardware ou simplesmente uma sobrecarga narede, os dispositivos virtuais possam migrar, de forma transparente para o usuáriofinal, entre os equipamentos físicos disponíveis, de acordo com políticas definidaspelos administradores.

• Escalabilidade - Os roteadores virtuais podem inicialmente agrupar funcionalidadessimplificadas e, à medida que novas demandas vão surgindo, outras características

6

possam ser adicionadas, resultando em arquiteturas de rede mais robustas.

• Redução de custos - Um recurso físico, por exemplo uma porta LAN, pode ser com-partilhado por várias redes virtuais, reduzindo assim a necessidade de se adquirirequipamentos dedicados para cada tipo de serviço.

• Segurança - Cada roteador virtual manipula seu próprio espaço de endereçamento.Sendo assim, os riscos de que ocorram brechas de segurança, erros de configuração,erros de software entre outros devem ser reduzidos.

Figura 2.1: Ambiente genérico de virtualização de rede.

Basicamente, uma rede virtual é composta por roteadores virtuais, sistemas finais(hosts) virtuais e enlaces virtuais. Na Figura 2.1 é ilustrado um modelo genérico de umambiente de de rede com suporte à virtualização (CHOWDHURY; BOUTABA, 2009).Como pode ser observado, a infraestrutura física da rede que dá suporte e hospeda asredes virtuais é chamada de substrato. Os roteadores virtuais são geralmente conectadosentre si através de túneis IP, o que permite a utilização de implementações de protocolosde aplicação, transporte, algoritmos de roteamento e outras características presentes naInternet atual (TOUCH et al., 2003). A rede virtual é uma rede completa, pois conta comtodos os elementos que compõem uma rede real, i.e., roteadores, hosts e enlaces. Alémdisso, a virtualização permite que vários componentes físicos possam participar de múl-tiplas redes virtuais, bem como uma rede virtual possa ser construída sobre outra redevirtual. Isto traz flexibilidade e possibilita a criação de arquiteturas de rede avançadassem interferir de forma significativa nos equipamentos físicos.

2.1 OpenFlow

Baseado na manipulação de tabelas de fluxo em switches Ethernet, o OpenFlow vemrecebendo muita atenção da comunidade científica. O grupo Internet2 mantém algunsprojetos nesta área e é apoiado por diversas grandes companhias, como Facebook, Go-ogle, Microsoft, Verizon, Yahoo!, Broadcom, Cisco, Dell, Ericsson, Extreme Networks,HP, IBM, Intel, as quais, em conjunto, formaram uma organização sem fins lucrativoschamada ONF (Open Network Foundation) (INTERNET2, 2011). Esta organização é de-dicada a promover uma nova abordagem para a área de redes, marcada pela utilização deRedes Definidas por Software (do inglês, Software Defined Network). O OpenFlow tempapel fundamental neste cenário.

7

Os roteadores e switches mais recentes são constituídos de duas partes distintas: oplano de controle e o plano de dados (INTERNET2, 2011). O plano de controle é formadopelos protocolos de roteamento, enquanto o plano de dados realiza o encaminhamento dospacotes. O OpenFlow, diferentemente dos softwares proprietários e restritos aos fabrican-tes de dispositivos de rede, apresenta-se como uma alternativa gratuita, de código aberto egeneralizada para fazer a integração destes planos. Tal integração é realizada de maneirasimples e elegante.

O OpenFlow define um protocolo de comunicação para ser utilizado entre switches euma entidade externa, comumente chamada de controlador. A comunicação entre swit-ches e controlador possibilita, junto ao controlador, a manipulação das tabelas de en-caminhamento do plano de dados do switch. O fato do controlador estar externamentelocalizado, representado geralmente por um computador simples, possibilita uma visãogeral da topologia da rede, favorecendo assim a tomada de decisões, que independeriam,por exemplo, de protocolos switch-to-switch.

Pode-se dizer então que o protocolo definido pelo OpenFlow determina uma série deregras de encaminhamento de pacotes. Cada pacote que passa por um switch OpenFlowpode se adequar a uma determinada regra ou não, dependendo de alguns fatores definidosem regras especificadas usualmente por operadores de rede. Poderiam ser, por exemplo,endereço IP e porta de origem e/ou de destino, tamanho do pacote, endereço MAC deorigem/destino, enfim, todos os campos contidos no cabeçalho dos pacotes. Uma vezdetectados os possíveis pacotes alvos, são definidas ações, que tipicamente consistemem descartar, encaminhar para uma porta específica, ou modificar algum parâmetro docabeçalho. O enfoque das ações oferecidas pelo OpenFlow é obviamente direcionadopara o próprio cenário controlado. Entretanto, nada impede o controlador de tomar açõesfora deste escopo.

2.1.1 FlowVisor

O OpenFlow oferece um conjunto de ferramentas para conectar um controlador a umconjunto de dispositivos físicos ou simulados. Neste cenário, é possível que se tenha maisde um controlador, ou seja, o sistema pode acoplar diversos usuários, cada qual com suaimplementação de controlador, ou até mesmo um usuário com diversos controladores,dependendo da lógica de negócios.

O FlowVisor surge neste contexto com o papel de dividir os recursos de banda, to-pologia, tráfego, CPU e tabelas de fluxo dos switches envolvidos na rede experimental econtrolados pelo protocolo OpenFlow, de maneira que se mantenham garantias pra cadausuário/controlador.

Pode-se considerar o FlowVisor como um moderador que utiliza o Openflow comoprotocolo padrão de comunicação entre os dispositivos físicos e os controladores. Nestacamada, ele possibilita o controle dos fluxos de acordo com uma política de utilização dodispositivo, ou seja, dado um comando de inserção de regra de fluxo em um determinadodispositivo, utilizando o protocolo OpenFlow, o FlowVisor analisa as políticas de utiliza-ção daquele usuário específico e aplica as mudanças na tabela de fluxo da porção físicacompatível. Uma vez que foi gerado um evento no dispositivo, este evento é comparadocom os interesses cadastrados e o evento é encaminhado então somente para os usuáriosinteressados.

Conforme podemos analisar na Figura 2.2, o controlador do Doug tem controle de umarede com apenas um nó físico (switch), enquanto Alice consegue visualizar e controlarquatro. É possível, a partir da virtualização de instâncias diferentes do FlowVisor, o

8

Figura 2.2: Exemplo ilustrativo da utilização do FlowVisor (SHERWOOD et al., 2009).

agrupamento de visualizações. Neste exemplo esta funcionalidade possibilitou que Bob eCathy tivessem uma visão geral da topologia real de rede, com cinco nós.

Cada usuário define uma parte da rede total (slice) para a sua utilização. Desta ma-neira se cria uma rede virtual, ou seja, uma rede que representa apenas alguns nós reais(SHERWOOD et al., 2009). Esse tipo de estratégia possibilita um controle independentede diferentes tipos de fluxos, ou seja, pode-se ter controladores dedicados a tratar fluxosde vídeo, priorizando-o sobre o fluxo de dados HTTP por exemplo.

As características de virtualização do FlowVisor se diferem um pouco das demais,uma vez que define a criação de redes virtuais e não de dispositivos virtuais. Ou seja, apartir do FlowVisor é possível instanciar diversas redes virtuais sobre um mesmo substratofísico. Sendo assim, o isolamento neste caso trata de manter os recursos reservados paracada slice, de maneira que seus respectivos controladores funcionem independentementee de forma que as operações de um não influenciem nas do outro.

Uma das vantagens oferecidas pela utilização do FlowVisor é a transparência, ou seja,a camada de virtualização é imperceptível tanto para os controladores quanto para a ca-mada física da rede. Como consequência desta característica, o controle do usuário podeser mantido sob uma rede virtual da mesma forma que sob uma rede real, ou seja, todo ocontrole da comunicação é abstraido.

2.2 VMWare e VirtualBox

Tanto o VMWare (VMWARE, 2009), quanto o VirtualBox (VIRTUALBOX, 2009)são exemplos de aplicações que permitem a virtualização de maneira bem simples, compouca configuração. Ambas viabilizam ao usuário a instalação e execução de sistemasoperacionais em ambiente virtualizado, além de oferecer diversas funcionalidades e fer-ramentas adicionais que variam de acordo com a versão do software escolhida e, conse-quentemente, da licença adquirida.

O VMWare (VMWARE, 2009) consiste em um software de virtualização desenvol-

9

vido pela VMWare Inc. e é distribuído em versões gratuitas, com recursos limitados, eversões comerciais, com recursos adicionais ativos. Algumas versões são baseadas emmonitores clássicos, como VMWare ESX e VMWare ESXi, e outras em monitores incor-porados, como VMWare Player e VMWare Workstation.

Enquanto a versão Workstation fornece as principais funcionalidades para um sis-tema de virtualização, como criar, modificar e executar uma máquina virtual, a versãoPlayer permite apenas executar máquinas virtuais, sem as demais funcionalidades. Am-bas versões executam em Windows e Linux. Com a versão Fusion, similar à Workstation,também é possível executar no MacOS.

O VirtualBox (VIRTUALBOX, 2009) é um software de virtualização desenvolvidopela Oracle que oferece uma versão sob licença GPL (GNU General Public Licence) euma versão comercial com algumas funcionalidades extras. O VirtualBox não necessitade hardware com suporte à virtualização nativo para prover virtualização total, como énecessário, por exemplo, para outras soluções como o Xen, descrito na Seção 2.3.

Este tipo de virtualização contribui para o desenvolvimento de aplicações de redefornecendo um ambiente com dispositivos de rede (switches e roteadores) virtuais, quequando conectados por meio de configurações, formam uma rede virtual. Essa rede podeser utilizada para diversos propósitos, como representar topologias que servirão de basepara simulações ou definir uma réplica virtual de uma rede real. Esta última estratégia foiutilizada no projeto RouteFlow (NASCIMENTO et al., 2011).

No que se refere ao projeto RouteFlow, esse apresenta uma aplicação que gera umarede virtualizada a partir da análise da topologia de uma rede real. Desta forma, diferentestipos de protocolos e soluções podem executar em nível virtual, mantendo a camada físicaapenas como infraestrutura de comunicação. Isto é feito através da virtualização de sis-temas operacionais de dispositivos de rede reais ou sistemas genéricos de roteamento taiscomo Quagga (GNU QUAGGA PROJECT, 2006) e Vyatta (VYATTA PROJECT, 2010).

Como auxílio a este tipo de estratégia, existem diversos aplicativos que facilitam oplanejamento e programação dos dispositivos virtualizados. Alguns deles utilizam inter-faces gráficas para auxiliar a construção dos projetos, o que permite ao projetista desenhara arquitetura e programar os nós de forma visual e simplificada. O GNS3 é um programaopensource que utiliza o Qemu (QEMU, 2011) – um aplicativo opensource genérico paravirtualização e emulação – para permitir este tipo de simulação.

2.3 Xen

A virtualização de diferentes sistemas operacionais sob um único hardware não é no-vidade, além de ser uma funcionalidade facilmente suportada pelos computadores atuais.Entretanto, manter os sistemas virtuais totalmente isolados, suportar a heterogeneidadedos sistemas operacionais e minimizar o impacto no desempenho ainda continuam sendograndes desafios.

O Xen é um monitor de máquinas virtuais que permite o compartilhamento de hard-ware por múltiplos sistemas operacionais virtualizados de maneira balanceada e segura,sem sacrificar o desempenho ou as funcionalidades de cada sistema operacional (BARHAMet al., 2003). Esse projeto foi desenvolvido pela Citrix Tecnologies sob a licença GPLcom a ambição de hospedar até 100 máquinas virtuais simultaneamente em um servidormoderno.

O objetivo principal do Xen é retirar dos administradores a responsabilidade de man-ter eficientemente um controle sobre o desempenho de cada Máquina Virtual – Virtual

10

Machine (VM) o que exige o gerenciamento manual dos recursos de armazenamento eprocessamento. Apresenta-se então duas soluções para automatizar este gerenciamento:(i) uma opção é fazer o controle dos recursos a nível de processos, impondo limites derecursos pra cada um deles, entretanto esta abordagem implicaria uma em uma sobrecargade gerenciamento que impactariam no desempenho da virtualização. (ii) o Xen usa umaabordagem de multiplexação de recursos de hardware em um nível de granularidade deum sistema operacional, o que permite fazer o isolamento de desempenho por sistemaoperacional e não por processos. Sendo assim, o acesso aos recursos de hardware porcada sistema operacional seria multiplexado de acordo com as políticas definidas peloadministrador.

O nível de virtualização pode ser definido por dois modelos: a virtualização completae a paravirtualização. A completa oferece os elementos básicos de hardware e software(e.g., processador, memória e kernel), implicando em menores ajustes no sistema operaci-onal do visitante. Entretanto, é necessário hardware com suporte à virtualização (Intel-VTou AMD-V). Já a paravirtualização exige que os sistemas operacionais visitantes sejamadaptados de tal forma que as requisições de recursos de hardware sejam direcionadas aoXen e não ao hardware. Desta forma, o Xen faz o devido controle do acesso repassandoao hardware requisitado apenas a demanda que julgar pertinente.

O Xen suporta ambos modelos, embora se refira à virtualização completa com outrotermo: hardware virtual machine (HVM) (XEN, 2011a). Para essa dupla compatibilidade,são utilizados alguns drivers para controlar o acesso aos recursos, que se dão através doDomain 0, uma abstração do sistema operacional hospedeiro, o qual possui privilégios deacesso ao hardware e a responsabilidade de controlar os Domain Us, abstração do sistemaoperacional dos visitantes (XEN, 2011b). O Domain 0 possui uma implementação dekernel modificada para a inclusão do Xen, que roda de modo acoplado a ele.

2.4 LibVirt

A Libvirt (THE VIRTUALIZATION API, 2011) é formada por um conjunto de ferra-mentas que permitem o gerenciamento remoto de um conjunto de VMs, entretanto, estecontrole é feito de forma indireta, intermediada por algum hypervisor compatível comessa biblioteca (WU et al., 2010). O hypervisor tem o papel de efetivamente executaros comandos gerados pela plataforma de gerenciamento oferecida pela Libvirt, possi-bilitando, entre outros, a criação, exclusão, alteração e o monitoramento das VMs. Ohypervisor e outras entidades envolvidas neste ambiente estão representadas na Figura2.3:

Domínio

Domínio

Domínio

Hypervisor

Nó

Figura 2.3: Ilustração dos componentes de um nó gerenciado pelo Libvirt (THE VIRTU-ALIZATION API, 2011).

11

• Nó - Uma máquina física única.

• Hypervisor - Uma camada de software que permite a execução de múltiplas máqui-nas virtuais – Virtual Machine (VM) em um único nó, tratando de toda heteroge-neidade referente às configurações que podem diferir de VM para VM bem comopara o próprio hospedeiro.

• Domínio - Uma instância de um sistema operacional rodando em uma máquinavirtual.

Uma vez definidas as entidades, pode-se dizer que o Libvirt é uma API que tem comoobjetivo principal prover uma camada de abstração para que se faça a gerência dos domí-nios presentes em um nó. Pode-se presumir desta forma que seja necessário a interaçãocom diversos tipos de hypervisors, uma vez que as VMs são controladas por esta enti-dade, ou seja, todo tipo de requisição gerencial será encaminhada por elas. Sendo assim,as funcionalidades do Libvirt estão limitadas àquelas suportadas pelo hypervisor.

O Libvirt suporta atualmente tecnologias de virtualização como Xen, QEMU, KVM,LXC, OpenVZ, User Mode Linux, VirtualBox e VMware. Nem todos oferecem as mes-mas operações de controle, mas caso alguma específica seja realmente necessária para ogerenciamento de um certo domínio, implementá-la pode ser uma boa medida, uma vezque múltiplos nós podem ser acessados simultaneamente de forma que esta operação podeacabar sendo útil também em um outro nó. Algumas operações aplicáveis aos própriosnós também estão no escopo do Libvirt, como definição de interfaces, gerência de regrasde firewall, gerenciamento de armazenamento e monitoramento dos recursos.

O nó físico gerenciado pode estar em uma máquina física diferente da máquina queestá o programa gerenciador baseado na Libvirt, por este motivo a Libvirt suporta acessoremoto. Entretanto esta funcionalidade deve ser utilizada em conjunto com protocolosseguros de comunicação a fim de manter a integridade das requisições (THE VIRTUALI-ZATION API, 2011).

A linguagem de desenvolvimento da API Libvirt é C, mas pode-se facilmente encon-trar diversas adaptações para utilização em outras linguagens de programação, como Java,Ruby, Python, C#, PHP e Perl.

12

3 PROGRAMABILIDADE DE REDES

A programabilidade de redes é definida como a capacidade de um dispositivo de rede(e.g., um roteador) executar código no próprio dispositivo (LAZAR, 1997). Tal capaci-dade pode ser importante, pois permite que novas funcionalidades e serviços (e.g., novosprotocolos, sistemas de monitoramento, entre outros) sejam implementados sem a neces-sidade de substituição de hardware na infraestrutura da rede (MERWE; KALMANEK,2009). Com a programabilidade de redes também é possível permitir que serviços ino-vadores possam ser criados pelos usuários da rede, criando assim um núcleo de redeprogramável, núcleo este que não existe hoje em dia.

Atualmente, a comunidade científica têm se voltado para o desenvolvimento de no-vas tecnologias que facilitam a introdução de novos serviços, protocolos e arquiteturasna rede. Desde a década de 1990, muitos trabalhos foram desenvolvidos visando permi-tir que as redes sejam em algum programáveis. Exemplos de tais trabalhos são RedesAtivas (TENNENHOUSE et al., 1997), Agentes Móveis (WHITE, 1996) e Script MIB(MERWE; KALMANEK, 2009), descritos neste capítulo.

Os esforços anteriores não obtiveram sucesso por dois principais motivos: (i) a falta degarantias quanto a consistência das configurações aplicadas sobre os dispositivos ao seremprogramados por usuários finais; e (ii) o elevado custo por parte dos ISPs (Internet ServiceProviders) para a constante substituição de dispositivos compatíveis com as tecnologiasdesenvolvidas. No entanto, através da virtualização, que vem sendo gradativamente su-portada nos dispositivos de redes mais modernos, a substituição dos equipamentos ocorreapenas de forma virtual, permitindo a implementação de novas tecnologias desenvolvidassem a necessidade de troca dos equipamentos físicos.

3.1 Propostas da Comunidade Científica

Nesta Seção serão revisadas propostas relevantes da comunidade científica para a pro-gramabilidade de rede. Na Subseção 3.1.1 são apresentadas as Redes Ativas. Na Subse-ção 3.1.2 são apresentados os Agentes Móveis. A Script MIB é apresentada na Subseção3.1.3. Encerra a Seção a Subseção 3.2.2, onde são apresentados os aspectos de prgrama-bilidade do OpenFlow.

3.1.1 Redes Ativas

Tradicionalmente o principal objetivo de uma rede IP é entregar pacotes de um pontoa outro, examinando o endereço de destino presente no cabeçalho do pacote e, após uti-lizar as tabelas de roteamento, decidir para qual vizinho deve repassar o pacote. Aindapodem realizar outras operações como controle do congestionamento da rede e correção

13

de possíveis erros na transmissão, mas em nenhum caso há a possibilidade de altera-ção nas informações contidas nos pacotes. Essas características identificam uma rede quepode ser chamada de “passiva”. Muitos problemas são facilmente identificados em “redespassivas”, tais como a dificuldade de introduzir novas tecnologias e serviços na infraes-trutura de rede (também chamada de ossificação), redução no desempenho e operaçõesredundantes na camada de rede (PSOUNIS, 1999).

Durante discussões sobre o futuro das redes na DARPA (Defense Advanced ResearchProjects Agency), em meados da década de 1990, foi construído o conceito das chamadasredes ativas. Segundo Tennenhouse et al. (TENNENHOUSE et al., 1997), uma rede ativaé caracterizada pela possibilidade dos nodos da rede realizarem alterações ou computa-ções no conteúdo de um pacote. Dispositivos como roteadores e switches executam açõescustomizadas no fluxo das mensagens. Essas ações podem ser implementadas pelos ad-ministradores da rede ou até pelos usuários da rede ativa, que podem construir soluçõespara problemas específicos – o que muitas vezes demanda a substituição de hardware.

Psounis define a diferença entre redes passivas e redes ativas. A rede passiva é com-posta por hosts inteligentes nas bordas, que podem realizar computações na camada deaplicação, e roteadores simples, que fazem a ligação entre os hosts mas que só conseguemrealizar computações na camada de rede. Já uma rede ativa é uma rede que permite tam-bém aos roteadores realizarem computações na camada de aplicação, além de permitiremaos usuários a injeção de programas na rede. O autor afirma que, em um caso extremo,os pacotes de uma rede ativa podem ser considerados programas – chamados de pacotesativos para diferenciá-los dos pacotes tradicionais (PSOUNIS, 1999).

O principal problema da rede está associado à segurança, uma vez que é possívela programação e execução de aplicações nos nodos da rede. As ameaças de segurançaatreladas a essa característica são enormes, e grande parte dos fabricantes optaram pornão dar suporte às redes ativas, impedindo que elas fossem amplamente implementadasna Internet.

As arquiteturas das redes ativas podem ser classificadas em três diferentes abordagens:arquitetura de pacotes ativos (ou integrada), arquitetura de nodos ativos (ou discreta) earquitetura híbrida (SECURE ARCHITECTURES WITH ACTIVE NETWORKS, 2006)(ou mista), descritas a seguir.

• Arquitetura de Pacotes Ativos – os pacotes transmitidos, além dos dados, possuemcódigo que é executado nos nodos. Os nodos, por sua vez, apenas fornecem apossibilidade de realizar a computação dos pacotes. Apesar de ser flexível, porquestões de segurança, é exigido que os pacotes sejam autenticados, o que acabatendo um impacto no seu desempenho. Esses pacotes com códigos executáveispodem também ser chamados de cápsulas (TENNENHOUSE et al., 1997).

• Arquitetura de Nodos Ativos – os serviços e programas estão presentes apenas nosnodos e não mais nos pacotes, que por sua vez carregam apenas referências e pa-râmetros usados pelos códigos executados no nodos. Como a implementação estános próprios nodos, a segurança fica reforçada. Entretanto, perde flexibilidade secomparada à arquitetura de pacotes ativos. Tennenhouse chamou essa arquiteturade switches programáveis (TENNENHOUSE et al., 1997).

• Arquitetura Híbrida – essa abordagem une as características da arquitetura de paco-tes ativos e da arquitetura de nodos ativos, uma vez que os nodos possuem códigosexecutáveis, assim como os pacotes também carregam códigos executáveis con-sigo. O código carregado pelos pacotes é geralmente escrito em uma linguagem

14

com objetivos específicos que tem recursos limitados. Se necessário, o programados pacotes pode invocar serviços que são realizados pelo nodo, podendo essasações serem avaliadas por questões de segurança a qualquer momento.

Os pesquisadores participantes de projetos da DARPA envolvendo redes ativas opta-ram por criar um modelo de programação comum. Esse modelo é importante, uma vezque os programas são transmitidos pela rede através de meios de comunicação os maisdistintos, além de serem executados em uma diferente gama de plataformas. Para isso,também foi preciso criar um modelo de programação para as primitivas (serviços) exis-tentes em cada nodo da rede e para a alocação de recursos necessários para execução dosprogramas, detalhados em seguida.

• Código dos programas - Nesse modelo busca-se atender três objetivos principais:mobilidade, proteção (safety) e eficiência. No tocante a mobilidade, é importanteque o programa possa ser transmitido e executado no maior número de plataformaspossíveis. Para isso, sugeriu-se o uso de linguagens de script para expressar o pro-grama. Outra sugestão seria o uso de uma linguagem intermediária como bytecodesJava, reconhecidos por serem multiplataforma. A terceira sugestão foi a transmis-são dos programas executáveis em modo binário. Quanto à proteção, é necessáriorestringir os recursos disponibilizados aos programas. Por fim, quanto à eficiência,deve-se garantir que a rede continue funcionando com bom desempenho.

• Primitivas - algumas primitivas ou serviços executados pelos nodos são imprescin-díveis, como a possibilidade de: o pacote se auto-manipular (e.g. alterando seupróprio cabeçalho), de fornecer ao pacote acesso ao ambiente do nodo (podendoobter dados como horário, endereço, etc.) e de controlar o fluxo do pacote (se serárepassado, copiado ou descartado). Podem ser incluídas, ainda, primitivas de acessoaos dados armazenados no nodo ou escalonamento de pacotes.

• Recursos do nodo - necessidade de acesso a informações como a banda disponí-vel, capacidade de processamento e de armazenamento, recursos lógicos como astabelas de roteamento e informações de gerenciamento da rede.

A aplicação da tecnologia de redes ativas possibilita o desenvolvimento de novos ser-viços. Entre as possíveis implementações que potencialmente se beneficiam dessas me-lhorias podem ser incluídas as descritas por (TENNENHOUSE; WETHERALL, 2002)(PSOUNIS, 1999).

• Gerenciamento de redes - Atualmente, para monitorar uma rede os nodos podemtanto emitir alarmes sob condições previamente determinadas quanto serem cons-tantemente interrogados sobre seus estados – estratégia denominada polling. Como crescente aumento do tamanho das redes, a quantidade de nodos gerenciadosaumenta, o que torna o uso da estratégia polling um problema. Informações redun-dantes e grande carga de mensagens são fatores que atrapalham as estações geren-ciadoras. Usar as redes ativas para realizar o gerenciamento da rede pode diminuira ocorrência de atrasos, já que poderiam existir diversos centros de gerenciamentodentro da rede, deslocando o ponto de decisão para próximo do nodo que está sendogerenciado. Tal alteração reduziria o tráfego resultante do processo de polling e acomplexidade da rede. Além disso, a inclusão de “inteligência” nos elementos ge-renciados, através de programas implementados nos próprios dispositivos, pode in-crementar a agilidade no controle da rede. Dentre outros benefícios, pode-se citar a

15

facilidade de alterações nas políticas de administração, filtragem mais eficiente dosdados obtidos de acordo com a necessidade da gerência, e a possibilidade da criaçãode pacotes de “primeiros socorros”, que poderiam resolver problemas encontradosnos nodos da rede imediatamente.

• Firewalls - Implementam filtros que determinam quais pacotes devem passar trans-parentemente e quais devem ser bloqueados. Entretanto, o firewall exige ser cons-tantemente atualizado para se adequar aos novos protocolos criados. Esse é umproblema que pode ser solucionado com o uso das redes ativas, que tornaria essasatualizações mais rápidas e eficientes, já que seria possível às organizações teremliberdade de acesso ao firewall e injetarem módulos atualizados nele.

• Web proxies ou caching - São desenvolvidos para servir e armazenar temporaria-mente páginas web. Quanto mais perto de um nodo que deseja acessar essas pági-nas, mais rápida será a entrega dos dados e a visualização do usuário. Pode-se usaras redes ativas para utilizar um esquema inteligente de caching, onde os pontos decache são distribuídos de acordo com as necessidades.

• Multicasting - É grande o potencial futuro de aplicações multimídia. Atrasos natransmissão de streaming podem causar sobrecarga nos servidores devido aos pe-didos de retransmissão, além da inconveniente espera do usuário pela chegada dosdados. Uma solução, utilizando redes ativas, permitiria a utilização de um dis-positivo de cache desses pacotes em nós intermediários, ou seja, a solicitação dereenvio de pacotes seria respondida pelo nó ativo e não pelo servidor. Desta forma,o servidor não ficaria sobrecarregado por diversas solicitações de retransmissão.

Quanto à implementação das redes ativas, são três as abordagens: integrada, discretae mista. Na abordagem integrada, os programas que implementam as aplicações são en-capsulados nos próprios pacotes, juntamente com os dados. Neste caso, a aplicação ativaé “instalada” imediatamente, na hora de sua utilização. Os pacotes ativos referentes a essaabordagem são chamados de cápsulas. Por outro lado, na abordagem discreta, os pacotestransportam apenas identificadores das aplicações (rotinas) que devem ser executadas nosnodos. Nesse caso, as aplicações ativas são instaladas por um esquema de download decódigo sob demanda. E por fim, a abordagem mista, em que ambas as abordagens são uti-lizadas, isto é, os programas podem tanto estar encapsulados nos pacotes como tambémserem instalados via download (TENNENHOUSE; WETHERALL, 2002).

Visando permitir a carga e execução de programas nos nós da rede, diversos trabalhosforam conduzidos no contexto de redes ativas. Entre esses trabalhos podem ser citados oprojeto SwitchWare (ALEXANDER et al., 1998), o projeto ANTS (Active Node TransferSystem) (WETHERALL; GUTTAG; TENNENHOUSE, 1998) e o projeto Smart Packets,descritos a seguir.

3.1.1.1 Switchware

O projeto Switchware (ALEXANDER et al., 1998) foi criado com o intuito de for-necer uma arquitetura para redes ativas, provendo um balanço entre a flexibilidade deredes programáveis e os requisitos de segurança. O Switchware define uma arquiteturaem três camadas: pacotes ativos, extensões ativas (ou switchless) e infraestrutura de ro-teador ativo. Para compensar a vulnerabilidade intrínseca às redes ativas, são utilizadosalguns recursos de segurança e proteção como verificação de integridade, autenticação e

16

verificação estática de tipo para a codificação. A arquitetura Switchware foi criada paraser abrangente, isto é, servir aos mais diversos propósitos. No entanto, é uma solução umtanto antiga, e, apesar de ter causado certo impacto no período em que foi publicado, hámuito tempo não é utilizado como base para novos projetos. Abaixo são listadas as trêscamadas da arquitetura Switchware:

• Pacotes ativos - Os pacotes, no Switchware, carregam programas contendo códigoe dados, substituindo, respectivamente, o cabeçalho e o payload dos pacotes tra-dicionais. O código provê as mesmas funcionalidades dos dados de controle deum pacote tradicional, mas com mais flexibilidade, já que permite a interação como ambiente no qual o pacote percorre, permitindo realizar ações mais complexase customizadas. Os dados, além das funcionalidades tradicionais do payload, pos-suem uma estrutura configurável que pode ser usada pelo programa. Como é precisoque esse pacote percorra a rede com bom desempenho, foi desenvolvido o PLAN(Programming Language for Active Networks) como linguagem dos pacotes ativos.É uma linguagem simples e que não podem alterar o estado de um roteador, ou seja,não tem a capacidade de manipular informações presentes nos nodos da rede. Paraisso, devem ser feitas chamadas a serviços já presentes no nodo.

• Extensões ativas (ou switchless)- são executadas exclusivamente nos nodos do sis-tema. Fornecem serviços requisitados pelos pacotes ativos. Esses serviços podemser obtidos dinamicamente de fontes confiáveis, de acordo com a necessidade, oufazerem parte dos recursos nativos do roteador – os nodos onde provavelmente asextensões são executadas. Podem ser escritos em qualquer linguagem, já que nãoprecisam ser leves por serem invocados apenas quando necessários. As extensões,em conjunto com os pacotes ativos, dão poder ao sistema ao mesmo tempo que,separados em camadas diferentes, garantem segurança na execução dos códigos.As extensões executam em um nodo específico, ou seja, não trafegam pela rede.Entretanto, podem utilizar os pacotes ativos para se comunicarem remotamente.

• Roteador Ativo - o objetivo nessa camada é prover uma base segura para que as duascamadas acima – que precisam ser dinamicamente flexíveis – possam ser construí-das. Apesar das primeiras camadas proverem segurança em algum nível, é impos-sível garantir que continuem sendo inseguro se os códigos forem carregados em umambiente inseguro. Dentre algumas das ações do roteador ativo estão o controle deníveis de acesso, controle de prioridades e o agendamento de recursos do sistema.

3.1.1.2 ANTS

O projeto de pesquisa ANTS (Active Node Transfer System) (WETHERALL; GUT-TAG; TENNENHOUSE, 1998) é basicamente um toolkit de redes ativas, que permite aimplantação de novos protocolos nos nodos intermediários e nos sistemas finais. Ao de-senvolverem o ANTS, os autores tiveram três objetivos: o suporte a vários protocolos derede diferentes que disponibilizam distintos tipos de serviços; a arquitetura deveria permi-tir a construção de novos protocolos; e deveria permitir que os novos protocolos fossemdisponibilizados dinamicamente, já que não há como desconectar pedaços da rede paraque sejam atualizadas.

Para alcançar cada um desses objetivos, a arquitetura do ANTS utilizou os seguintescomponentes-chave: cápsulas, nodos ativos e distribuição de código.

17

• Cápsulas - substituem os pacotes de uma rede tradicional. As cápsulas levam con-sigo as referências para as rotinas que devem ser utilizadas pelos nodos ativos parao processamento da cápsula. Algumas dessas rotinas são bem-conhecidas, havendogarantia de disponibilidade dessas rotinas nos nodos ativos da rede. Caso o nododesconheça a rotina, ela é transferida de alguma fonte segura, que garante que a im-plementação é correta. Ao conjunto de cápsulas e suas rotinas, transferidas comouma unidade pelos nodos, dá-se o nome de grupo de código (code group). O con-junto de grupos de códigos relacionados e tratados como uma única unidade segurasão chamados de protocolo.

• Nodos ativos - substituem os roteadores e nodos das redes tradicionais. Os nodosativos executam as rotinas apontadas pelas cápsulas. São os responsáveis pela inte-gridade das ações. Algumas das primitivas existentes nos nodos ativos são o acessoao ambiente (dados como horário local, tabelas de roteamento, etc), manipulaçãodas cápsulas, controle das operações (permitir, por exemplo, que cápsulas criemoutras cápsulas e que repassem, copiem ou descartem a si mesmas) e armazena-mento de dados por um curto período. Outras ações podem ser incluídas através dadistribuição dinâmica de código quando necessário.

• Distribuição de código - mecanismo que garante que uma rotina seja automática edinamicamente transferida para o nodo que dela necessita. Quando uma cápsulachega ao nodo, é verificado na cache desse nodo se ele possui o código necessáriopara a execução das rotinas contidas na cápsula. Caso não possua, é feita umasolicitação do código ao nodo “anterior” que enviou a cápsula. Enquanto isso, aexecução da cápsula é suspensa. O nodo “anterior” recebe a solicitação do código eenvia. Quando o nodo recebe a informação, a cápsula volta a ser executada. Alémdisso, esse novo código é incorporado pelo nodo à sua cache para futuras execuções.

3.1.1.3 Smart Packets

O projeto Smart Packets (SCHWARTZ et al., 1999) é focado no uso de redes ativaspara o gerenciamento das redes. Esta solução melhora o gerenciamento de redes com-plexas das seguintes maneiras: (i) movendo as decisões de gerenciamento para pontos darede mais próximos dos nodos sendo gerenciados; (ii) sendo mais objetivo a que tipo deinformação será obtida do nodo, evitando o uso de coletas exaustivas de dados devidoao polling e (iii) abstraindo os conceitos de gerenciamento para e construindo-os comlinguagem de programação, tornando o controle da rede mais ágil.

Duas importantes decisões foram feitas no projeto: os pacotes (chamados de smartpackets) deveriam conter todo o programa, evitando que dados fossem armazenados nosnodos da rede, o que é custoso e gera problemas de gerenciamento e consistência. Dessaforma, a linguagem de programação para os smart packets deveria produzir programascom menos de 1 Kbyte de tamanho, e ainda assim expressar completamente o programa.Outra decisão do projeto foi que, por questões de segurança, o código deveria ser execu-tados em uma máquina virtual, onde as operações realizadas estão sob controle.

Para permitir programas com menos de 1 Kbyte os autores criaram duas linguagens:uma linguagem assembly chamada Spanner e outra, mais alto nível e similar à C, cha-mada Sprocket. As duas linguagens são equivalentes, uma vez que um programa feitoem sprocket gera um código assembly em Spanner que, por sua vez, é transformada emum código binário independente da máquina em que é executada. A linguagem Java, que

18

também possui essa característica de gerar um código intermediário que funciona em di-ferentes sistemas, foi rejeitado por gerar código muito grande, extrapolando o limite de 1Kbyte exigido.

Os smart packets são encapsulados dentro do ANEP (Active Network EncapsulationProtocol) que, por sua vez, é encapsulado em um pacote IP. Dessa forma, é garantido queo pacote possa circular pelos nodos da rede ainda que eles não sejam ativos ou não este-jam prontos para executar os smart packets. O cabeçalho do endereço IP é checado, assimcomo uma opção do IP chamada Router Alert, que indica se o roteador deve examinar oconteúdo do datagrama em busca de códigos executáveis. Caso essa opção esteja assi-nalada e o roteador suporte redes ativas, ele pode checar a mensagem ANEP no interiordo pacote e descobrir se se trata de um smart packet. Se o nodo tiver suporte aos smartpackets, pode, então, executar o código contido nele. Antes de executar esse código, o da-emon do ANEP contido no nodo autentica e autoriza essa execução. Esse mesmo daemoncria uma nova instância da máquina virtual aonde o código é, então, executado.

3.1.1.4 Conclusão das Redes Ativas

A pesquisa sobre as redes ativas foi bastante produtiva até o final dos anos 1990. Fi-nanciadas pela DARPA, diversas instituições investigaram, por alguns anos, como trans-formar a Internet em um ambiente ainda mais dinâmico e menos ossificado. Foram cria-dos diversos sistemas, promissores na época, mas que não convenceram os fabricantes aadicioná-los às suas tecnologias, principalmente por razões de segurança. O Switchware,com suas diferentes camadas, tentou criar uma arquitetura com um ambiente seguro edinâmico para execuções de programas nos pacotes. O problema dessa solução, o mesmodo ANTS, é quanto à segurança: seria necessário confiar na honestidade dos autores doscódigos executáveis. Seria necessário certificar desenvolvedores confiáveis dos quais pu-dessem ser obtidos, sem risco, os programas executáveis quando necessários. O ANTSé bastante similar ao Switchware, mas seus pacotes, chamados de cápsulas, não contémcódigos executáveis, apenas referências para funções que estão implementadas nos no-dos. Caso essas funções não estejam presentes, o ANTS tem um sistema de distribuiçãode códigos. O projeto Smart Packets, apesar de ter sido construído especificamente parao gerenciamento das redes, usa alguns conceitos que podem ser úteis no futuro, princi-palmente o uso de redes virtuais para a execução dos pacotes com códigos. O formaque o encapsulamento é realizado no Smart Packets pode acabar mantendo o correto fun-cionamento dos pacotes mesmo nas redes legadas. Assim, haveria a possibilidade dacoexistência de protocolos antigos e nodos desatualizados com a flexibilidade das redesativas e nodos que suportem esse tipo de rede.

3.1.2 Agentes Móveis

Agentes móveis são agentes que podem trafegar fisicamente por uma rede, executandotarefas nas máquinas que têm capacidade de executá-los (LANGE; OSHIMA, 1999). Osagentes móveis podem carregar para o novo ambiente de execução tanto os dados quantoo estado de execução em que parou no último host da rede, sendo possível continuar essaexecução do exato ponto aonde havia parado. Segundo (GRAY et al., 1997), os agentesmóveis podem ser vistos como uma extensão das chamadas de procedimentos remotas(Remote Procedure Call ou RPC), que permitem ao usuário invocar a execução de algumaoperação no servidor ou mesmo enviar um subprograma para o servidor.

Uma das dificuldades dos agentes móveis é seu funcionamento em um ambiente muitoheterogêneo quanto a Internet. Os programas podem ser escritos em uma linguagem de

19

máquina ou serem interpretadas, por exemplo, por uma máquina virtual, que seria a so-lução preferível para esse problema (CHESS; HARRISON; KERSHENBAUM, 1997).Apesar de terem desempenho inferior, a utilização de ambientes virtuais traz mais segu-rança ao ambiente. Essa segurança se deve ao fato de que que estariam explícitos para odesenvolvedor todos os recursos disponíveis, evitando acessos indevidos.

Segundo Lange e Oshima, o uso apropriado de agentes móveis para a criação de siste-mas distribuídos possibilita diversos benefícios, entre eles é válido observar os apontadospor (LANGE; OSHIMA, 1999) e descritos em seguida.

• Redução no tráfego da rede - Agentes móveis permitem mover a computação paraonde o dado se encontra e não o dado para o local onde é feita a computação. Siste-mas distribuídos podem depender de muitas interações para realizar uma determi-nada tarefa, resultando em um elevado tráfego na rede, já que em muitos casos ocusto de transmitir o código que será executado é menor do que o custo para trans-mitir os dados da fonte até o nodo. Invertendo essa lógica, ou seja, realizando acomputação diretamente onde os dados se encontram, o tráfego na rede pode serreduzido.

• Superação da latência da rede - Sistemas de tempo real, tais como robôs em proces-sos de produção, necessitam responder em tempo real às mudanças do ambiente.Controlar tais sistemas através de redes substancialmente grandes envolve latênciasque não são aceitáveis. Agentes móveis oferecem uma solução para este problema,uma vez que podem ser disparados por uma estação central, interagindo e execu-tando instruções nos próprios dispositivos.

• Encapsulamento de protocolos - Sistemas distribuídos podem realizar muitas trocasde dados. Para realizar tal tarefa, cada host possui o código que implementa osprotocolos necessários para envio e recebimento de dados. Porém, a atualizaçãodo código dos protocolos para acrescentar novos requisitos como, por exemplo,maior eficiência ou segurança, se torna praticamente impossível de ser realizadacorretamente em um ambiente tão grande como a Internet. Ao utilizar agentesmóveis, podem ser criados “canais” baseados em protocolos proprietários a fim derealizar tal operação.

• Execução assíncrona e autônoma - A maioria dos dispositivos móveis dependem deconexões de rede caras ou frágeis. Tarefas que exijam uma conexão contínua entreum dispositivo móvel e a rede fixa são tecnicamente ou economicamente inviáveis.Para resolver este problema, tarefas podem ser embarcadas em agentes móveis que,após serem iniciados, se tornam independentes e podem operar assincronamentee autonomamente em relação ao dispositivo que os criou, sendo possível que odispositivo esteja até mesmo inativo.

• Adaptação dinâmica - Agentes móveis podem perceber o ambiente de execução emque se encontram e, autonomamente, conseguem reagir às mudanças. Múltiplosagentes móveis têm ainda a capacidade de se espalharem pela rede para manteruma configuração ótima no processo de resolução de um problema.

• Heterogeneidade - Redes de computadores são fundamentalmente heterogêneastanto do ponto de vista de hardware quanto de software. Por serem independentesda camada de transporte e da máquina em que são executados (os agentes móveis

20

são dependentes somente de seu ambiente de execução), os agentes móveis forne-cem condições para a integração destes sistemas.

• Robustez e tolerância à falhas - Agentes móveis podem reagir dinamicamente a si-tuações adversas. Ao ser detectado algum problema em um dispositivo, os agentesmóveis hospedados podem migrar para outro host da rede, permitindo a continui-dade da execução.

O paradigma dos agentes móveis foi inicialmente proposto no projeto chamado Te-lescript, que será descrito a seguir. Além dele, também serão comentadas outras duasimplementações, os Aglets e o µCode.

3.1.2.1 Telescript

O Telescript (WHITE, 1996) foi a primeira implementação comercial de agentes mó-veis. O foco da implementação, até pelo fato de ter sido desenvolvido por uma empresa,foi o mercado eletrônico. A tecnologia do Telescript possui três componentes principais:a linguagem usada para desenvolvimento dos agentes móveis; o interpretador que com-preende os comandos carregados pelo agente móvel e os protocolos que permitem a trocade agentes entre diferentes máquinas. A linguagem de programação do Telescript podeser usada para o desenvolvimento de um programa completo. Apesar disso, a linguagemC também pode ser usada no desenvolvimento dos agentes móveis. Dentre algumas carac-terísticas da linguagem pode-se citar o fato dela ser orientada a objetos, portável e segura– já que é executada através do interpretador, que não permite acesso direto à memória,por exemplo.

No Telescript foram definidos alguns conceitos principais: lugares, agentes, viagem,encontros, conexões, autoridades e permissões, descritos a seguir.

• Lugares - São serviços que permitem a entrada dos agentes móveis. Seriam simila-res às lojas de um shopping que permite a entrada de clientes.

• Agentes - O Telescript modela a comunicação como uma coleção de agentes. Cadaagente ocupa um determinado lugar, sendo seu representante e provendo os serviçosaos agentes móveis. Como exemplos, um lugar “bilheteria”, onde há um agente fixonesse lugar – o vendedor – que fornece informações sobre eventos e vende entradas.

• Viagem - O sistema permite que os agentes viagem de um lugar a outro lugar,independente da distância. Por exemplo, o agente pode viajar da casa do usuárioaté o lugar “bilheteria” e comprar ingressos, retornando ao ponto de saída inicialapós concluído o objetivo.

• Encontros - O Telescript permite que dois agentes em um mesmo lugar se comuni-quem, ou seja, permite que um agente faça chamadas de procedimento um do outro.Os encontros são os motivadores para as viagens dos agentes móveis, já que dessaforma encontra o agente de um lugar e pode usar seus serviços. Mas, o sistematambém permite que dois agentes móveis se encontrem em um determinado lugar,podendo, por exemplo, se comunicarem para realizarem a venda de um automóvelusado.

• Conexões - Permite a comunicação entre agentes que estão em diferentes lugares.Por exemplo, o agente móvel que está no lugar “bilheteria” pode se informar sobre

21

um espetáculo e se comunicar com um agente na casa do usuário enviando quaisos lugares ainda livres. O agente, na casa, exibiria essa informação ao usuário, queselecionaria os lugares os quais, posteriormente, seriam enviados ao agente no lugar“bilheteria”.

• Autoridades - A autoridade, no ambiente eletrônico, é o indivíduo ou organizaçãono mundo físico que representa o agente móvel. Um agente ou um lugar conse-guem saber a informação de qual a autoridade uns dos outros. Isso acontece porquestões de segurança, já que a autoridade é verificada antes da execução de ações,por exemplo, a remoção de dados. Apenas se o agente móvel tem uma autorizaçãoadequada essa ação será realizada.

• Permissões - Permite que as autoridades limitem as ações de um agente ou de umlugar através de permissões.

3.1.2.2 Aglets

O Aglets é uma biblioteca desenvolvida em Java. Implementada inicialmente porMitsuro Oshima and Danny Lange para a IBM de Tóquio, hoje é uma biblioteca de có-digo aberto e recebe constantes atualizações feitas pela comunidade (Mitsuro Oshimaand Danny Lange, 2004), além de ser bastante utilizado para pesquisas envolvendo agen-tes móveis. Por utilizar a linguagem Java, amplamente difundida, não exige uma grandecurva de aprendizado para ser utilizada. Além disso, a linguagem é poderosa e pode serexecutada nos mais distintos dispositivos, mesmo em ambientes com sistemas comple-tamente diferentes, justamente pela geração dos bytecodes. Assim como os applets, osaglets devem estar instalados em todos os hosts da rede em que serão executados. Cadahost instala também o gerenciador de segurança. Antes de deixar um host e ir para outro,o estado do aglet é serializado, ou seja, exportado para um stream de bits, facilitando seuuso. As principais ações de um aglet são a criação e clonagem de outro aglet, ativação/-desativação e messaging.

Um aglet é composto de um identificador, um itinerário – ou seja, a rota que seráseguida pelo aglet, caso seja necessário –, um núcleo – o coração do aglet, que mantémas variáveis internas, métodos e interface de comunicação com o ambiente em que seencontra. Esse núcleo é encapsulado por um proxy, que age como um escudo para prote-ger o aglet de qualquer tentativa de acesso direto aos métodos ou variáveis, escondendotambém a localização real do aglet.

3.1.2.3 µCode

É uma pequena API desenvolvida em Java. Desenvolvida por Gian Pietro Picco e dis-tribuída gratuitamente (Gian Pietro Picco, 2000), o próprio autor não considera o µCodecomo um sistema apenas para agentes móveis. O µCode tem a expressividade necessá-ria para se criar as próprias primitivas móveis, incluindo agentes móveis. O argumentousado para não implementar mais uma biblioteca de agentes móveis foi que a realocaçãode toda uma unidade do agente móvel não seria sempre necessária nem desejada, sendomuitas vezes melhor ter uma glanularidade mais fina quanto à mobilidade, por exemplouma classe simples ou um objeto.

O µCode tenta prover boas abstrações para fazer apenas uma coisa, que é mover có-digo e estado por diferentes lugares. Apesar de o µCode não possuir uma implementaçãocompleta de um sistema, há pacotes adicionais que provêm diferentes funcionalidades

22

para o µCode, como serviços avançados de comunicação para agentes móveis. Com essaabordagem mais simples, o µCode é de leve execução.

3.1.2.4 Conclusão de Agentes Móveis

Os agentes móveis, diferentemente das redes ativas, têm sido maior alvo de pesquisasrecentemente. Apesar de ainda não ser utilizado amplamente pelas mesmas questões desegurança que barraram as redes ativas, os agentes móveis, talvez por serem uma evolu-ção das chamadas a procedimentos remotos, ainda resistam com maior força. Outro pontoimportante é a evolução tecnológica da última década, que lançou no mercado diversoscomponentes móveis que possuem certa capacidade de computação, como os sensores.Cada vez mais são construídos sistemas com tais componentes, e agentes móveis se en-caixam perfeitamente nesta necessidade. Essa, aliás, foi uma das conclusões de (CHESS;HARRISON; KERSHENBAUM, 1997), os quais afirmam que os agentes móveis teriamnichos em que seriam utilizados, e não seriam adotados amplamente. Um ponto positivoé o uso da linguagem Java, hoje amplamente difundida ao contrário do final da década de1990, que tem a vantagem de ser uma linguagem multiplataforma, capaz de ser executadonos mais diferentes sistemas. Outro ponto positivo para as redes ativas é a existência dediversas bibliotecas bastante utilizadas.

3.1.3 MIBs DISMAN

Ao longo dos anos, as redes de computadores e seus recursos tornaram-se de fun-damental importância para as organizações. Muitos dos serviços prestados dependemdrasticamente da rede. Neste cenário, uma correta operação da rede é um requisito básicopara os negócios das empresas. Para tanto monitorar e controlar os dispositivos que com-põem a rede é fundamental. Tais funções são desempenhadas pela gerência de redes quevisa o funcionamento contínuo da rede, assegurando assim um elevado grau de qualidadedos serviços oferecidos. Tipicamente o modelo utilizado para o gerenciamento de redes écentralizado, e composto pelos elementos descritos em seguida.

• Gerente - é parte da aplicação que tem a responsabilidade de uma ou mais atividadesde gerenciamento, ou seja, ele transmite operações de gerenciamento (actions) aosagentes e recebe notificações (events) destes. Além disso, serve como interface parao gerente humano em um sistema de gerenciamento de rede.

• Agente - um processo que executa associado a um recurso, elemento ou sistemagerenciado. Esse processo responde às solicitações de informações e de ações dogerente e, deve também prover assincronamente informações importantes que nãoforam previamente solicitadas, informações que são transmitidas em alarmes.

• MIB (Management Information Base) - um conjunto de objetos gerenciados, queprocura abranger todas as informações necessárias para a gerência da rede, permi-tindo a automatização de grande parte das tarefas. Cada objeto gerenciado é umavisão abstrata de um recurso real do sistema. Assim, todos os recursos da rede quedevem ser gerenciados são modelados, e as estruturas dos dados resultantes são osobjetos gerenciados. Os objetos gerenciados podem ter permissões para serem lidosou alterados, sendo que cada leitura representará o estado real do recurso e, cadaalteração também será refletida no próprio recurso.

• Protocolo de gerenciamento - permite a comunicação entre o gerente e o agente,como por exemplo, o SNMP (Simple Network Management Protocol).

23

No entanto, com o crescimento da complexidade e do tamanho das redes, o modelocentralizado apresentou algumas deficiências importantes, como por exemplo, a falta deescalabilidade e a pouca eficiência no transporte de grandes quantidades de informação.Estas limitações levaram o IETF (Internet Engineering Task Force) a promover um grupode trabalho que foi designado por DISMAN (Distributed Management). Entre os princi-pais objetivos do DISMAN estavam:

• definir a gerência distribuída;

• definir objetos gerenciáveis para aplicações de gerência SNMP;

• proporcionar escalabilidade através da delegação de tarefas para outros dispositivos;

• promover uma arquitetura de sistema modular para maior flexibilidade e reuso decomponentes.

Visando estes objetivos, os esforços do grupo de trabalho DISMAN resultaram emalgumas RFCs (Request for Comments) que versam sobre o gerenciamento distribuído,entre elas a RFC 2981 (Event MIB), RFC 2982 (Expression MIB), RFC 4560 (RemoteOperations MIB), RFC 3231 (Schedule MIB) e RFC 3165 (Script MIB), descritas a seguir.

3.1.3.1 RFC 2981 - Event MIB

O envio de notificações indicando alguma falha ou indício de que algo não está funci-onando corretamente é importante para o gerenciamento de uma rede. A concepção origi-nal do SNMP previa somente as notificações já pré-definidas na MIB (como por exemplo,AuthenticationFailure que indica que um agente recebeu uma mensagem SNMP que nãofoi autenticada; LinkDown que indica que a comunicação com a rede deste dispositivofalhou, entre outras), não permitindo a criação de novas notificações sob demanda. Parasolucionar esta limitação foi definida na RFC 2981 (KAVASSERI; STEWART, 2000a), aEvent MIB. O principal objetivo desta MIB é permitir o monitoramento de objetos MIBem um sistema local ou remoto, e possibilitar o disparo de ações com base em políticaspré-definidas, ou seja, quando uma condição definida previamente ocorre.

A Event MIB possui duas principais seções: triggers e eventos. Os triggers (gatilhos)definem os objetos monitorados, as condições que acionam os eventos e como relacionarcada gatilho a um evento. Os eventos determinam o que acontece quando uma condiçãopré-definida é verificada, que resulta no envio de uma notificação, na alteração do valor deum objeto, ou em ambos. Para cada trigger definida é possível especificar o tipo de testea ser executado. Os testes podem ser de dois tipos diferentes, como descritos a seguir.

• Existence - pode disparar eventos quando a instância do objeto monitorado se tor-nar presente, ausente ou mudar de valor. Se um evento for acionado quando umainstância de um objeto se tornar presente, esta instância deverá deixar de existirantes que o evento possa ser disparado novamente e vice-versa. Se um evento foracionado devido a uma mudança de valor do objeto, o mesmo evento será acionadono caso de futuras mudanças de valor, sem maiores restrições;

• Boolean - exige a seleção de um teste específico, além de requerer que o objetomonitorado possua um valor inteiro. São indicados, nos gatilhos, um valor de refe-rência inteiro para ser comparado com o valor do objeto monitorado e a comparação

24

a ser executada entre o valor amostrado e o valor de referência, podendo ser dife-rente, igual, menor, menor ou igual, maior ou maior ou igual. Se o resultado do testefor verdadeiro, um evento será disparado. Este mesmo evento só será disparado no-vamente quando o resultado do teste passar a ser falso e tornar a ser verdadeiro.

Além das informações sobre os testes, cada gatilho contém um índice que aponta aum evento que deverá ser acionado. Se a ação disparada pelo evento pré-definido foruma notificação (trap), o evento deverá possuir informações sobre a notificação a serrealizada. Quando a ação disparada for a alteração de um valor em um objeto, o eventodeverá conter informações sobre o valor que deve ser atribuído ao objeto, bem como oidentificador deste objeto.

3.1.3.2 RFC 2982 - Expression MIB

Definida pela RFC 2982 (KAVASSERI; STEWART, 2000b), a Expression MIB foidesenvolvida com o propósito de permitir que novos objetos sejam definidos a partir deoutros já existentes. Esta MIB permite a construção e avaliação de expressões compostaspor objetos existentes, expressões simples e/ou expressões encadeadas (que dependamdo resultado de outras expressões). Sem a Expression MIB este tipo de operação ficarialimitado aos objetos pré-definidos em outras MIBs.

Os resultados destas expressões ficam disponíveis como objetos MIB, podendo serutilizados por uma aplicação de gerência de maneira direta ou serem referenciados poroutra MIB, como a Event MIB. Estes objetos ainda podem ser utilizados pela própriaExpression MIB formando expressões mais complexas. Os valores que compõem umaexpressão podem ser constantes ou variáveis (associados a um object identifier, OID).Porém, a obtenção das variáveis está limitada ao agente local. Tal obtenção das variáveispode ser retornada em uma das seguintes amostragens:

• delta - define coletas periódicas dos valores amostrados, além de sempre armazenaro último valor a fim de que este possa ser utilizado no cálculo da diferença entre asduas amostras;

• absoluta 1 - é simplesmente o valor de um objeto no instante em que ele foi amos-trado;

• booleana - retorna verdadeiro se o valor da amostra atual for diferente do da amostraanterior, ou seja, se o valor do delta para as duas amostras for diferente de zero.

As expressões não podem ser recursivas, porém uma expressão já em uso pode usarresultados de outra expressão, desde que a segunda não possua nenhuma variável queseja o resultado direto ou indireto da sua própria avaliação. Os operadores permitidossão delimitadores de escopo, aritméticos, lógicos e relacionais. São suportadas tambémalgumas funções como, por exemplo, a função exists que verifica se uma instância deobjeto indicada existe, retornando um valor booleano com o resultado.

As variáveis envolvidas na construção de uma expressão são os próprios objetos e sãoexpressas como um símbolo dólar (“$”), seguido de um inteiro, que serve para indexar avariável correspondente. Um exemplo de expressão válida é ($1 * 10 + $2), dado que $1= .1.3.6.9.10 e $2 = .1.3.6.10.14, onde o valor obtido do objeto MIB OID .1.3.6.9.10 émultiplicado por 10 e somado ao valor do objeto MIB OID .1.3.6.10.14.

1A obtenção das variáveis através desta amostragem não pode ser utilizada para a avaliação de expres-sões que envolvam contadores, sendo que estes devem ser manipulados como um delta (diferença) entreduas amostras.

25

3.1.3.3 RFC 4560 - Remote Operations MIB

A Remote Operations MIB permite executar remotamente algumas operações essen-ciais para o gerenciamento de redes, como os comandos ping, traceroute e lookup. Essasoperações permitem ao operador ter uma visão do estado da rede remotamente. Por seremextremamente necessárias, diversas empresas fizeram diferentes implementações de MIBsespecíficas para a realização destas operações. Neste contexto, a RFC 2925, obsoleta pelaRFC 4560, surgiu com o objetivo de definir um padrão para tais operações visando ainteroperabilidade entre as diversas MIBs implementadas (WHITE, 2000) (QUITTEK;WHITE, 2006).

3.1.3.4 RFC 3231 - Schedule MIB

Nas atividades de monitoração e controle de redes, executar operações periódicas ouem determinados instantes é de fundamental importância. Observando tal necessidade, foidefinida na RFC 2591 (LEVI; SCHOENWAELDER, 1999a), tornada obsoleta pela RFC3231 (LEVI; SCHOENWAELDER, 2002), a Schedule MIB, que apresenta um conjuntode objetos que possibilitam agendar operações de escrita SNMP (set) sobre objetos locaisdo tipo inteiro.

A Schedule MIB contém um repositório onde armazena os instantes definidos pelooperador, o identificador OID do objeto sobre o qual vai atuar e o valor que deve serassociado. Ao constatar que uma operação agendada deve ser executada, dispara entãouma operação set. Porém, tal operação pode apenas ser efetuada sobre a máquina local,não sendo possível associar um endereço de forma a modificar valores num agente remoto.Os instantes definidos pelo operador podem ser de três tipos:

• periódicos - a operação é repetida com uma determinada frequência, definida porum inteiro que representa o número de segundos entre as ações;

• de calendário - a operação é repetida sempre que ocorre a hora e a data agendados;

• únicos - a operação não é repetida, sendo executada uma única vez.

3.1.3.5 RFC 3165 - Script MIB

Proposta na RFC 2592 (LEVI; SCHOENWAELDER, 1999b) e posteriormente naRFC 3165 (LEVI; SCHOENWAELDER, 2001), a Script MIB apresenta um conjuntode objetos que permitem a delegação de scripts de gerenciamento através dos nós da rede.Estes (scripts), também chamados de processos remotos, podem ser escritos em qual-quer linguagem de programação, compilada ou interpretada, desde que esta esteja supor-tada pela Script MIB (SCHONWALDER; QUITTEK; KAPPLER, 2000). Após instaladoo script nos nós da rede, o gerente poderá, através de uma requisição SNMP (SimpleNetwork Management Protocol), realizar as seguintes operações:

• transferir códigos executáveis de gerenciamento para locais distribuídos;

• gerir os scripts, realizando ações como: inicialização; suspensão; reinicialização; efinalização dos códigos nestes locais;

• enviar parâmetros para os scripts de gerenciamento;

• monitorar e controlar os scripts que estão em execução;

26

• transferir para o gerente dos resultados produzidos.

As operações descritas acima, são realizadas em seis diferentes tabelas que constituemos objetos da Script MIB. Estas tabelas são brevemente descritas em seguida.

• ScriptTable - contém todos os scripts conhecidos e armazenados localmente. Quandoé instalado um novo script, este é incluído nesta tabela, ou seja, haverá uma linhaque identifica o script, suas configurações, a linguagem de programação utilizadae outras informações pertinentes para sua criação, manutenção e uso. Esta tabelapermite operações como leitura, inserção e deleção de entradas que descrevem osscripts. Existem dois modelos de transferência de scripts para o agente, o primeirochamado de “modelo pull”, que requer o envio de uma URL de onde será buscadoo script no momento de sua execução; o segundo é chamado de “modelo push”,que requer o envio do script, que será armazenado na tabela CodeTable, através doprotocolo SNMP;

• CodeTable - armazena os scripts que foram transferidos para o agente através do“modelo push”. Um script pode ser dividido em diversas linhas nesta tabela, isto sefaz necessário, para que seja possível a utilização de scripts maiores que o tamanholimite das mensagens SNMP. Além da inclusão de novas linhas, esta tabela tambémpermite a alteração de linhas já existentes, ou seja, é possível utilizar requisiçõesSNMP para modificar os scripts anteriormente transferidos;

• LanguageTable - contém as linguagens de programação que podem ser utilizadaspara a criação dos scripts que serão executados, ou seja, as linguagens que a imple-mentação da Script MIB é capaz de reconhecer/interpretar e executar. Cada entradanesta tabela apresenta detalhes de linguagens de programação suportadas, como porexemplo, nome, versão e descrição da linguagem;

• ExtensionTable - apresenta as extensões que a implementação da Script MIB aceitapara as linguagens disponíveis. Cada entrada nesta tabela representa uma extensãodisponível, como por exemplo, um pacote Perl para utilização de comandos SNMP.Os recursos de programação que podem ser utilizados na criação dos scripts sãodescritos através da combinação das informações das tabelas LanguageTable e Ex-tensionTable. Além disso, estas duas tabelas só podem ser acessadas para leitura,já que é o agente quem possui controle sobre as linguagens de programação e asextensões suportadas;

• LaunchTable - utilizada para a execução e controle dos scripts. Nessa tabela sãodescritos os ambientes para a execução de cada script, incluindo os parâmetros deentrada, bem como o tempo máximo de execução de cada script. Se um mesmoscript necessita ser executado com diferentes parâmetros, ou seja, configurandooutro ambiente de execução, este deverá ser descrito mais de uma vez nesta tabela;

• RunTable - armazena informações sobre os scripts que estão em execução, comopor exemplo, o script que está sendo executado, os argumentos de sua inicialização,o atual estado de execução (que pode ser, inicializando, executando, suspendendo,suspenso, recomeçando, cancelando e concluído). Além disso, os scripts que jáconcluíram sua execução, permanecem um determinado tempo, para que seja pos-sível consultar os resultados obtidos com a sua execução.

27

Na Figura 3.1, adaptada de (SCHONWALDER; QUITTEK; KAPPLER, 2000), éapresentada uma implementação de um agente SNMP com suporte a Script MIB, bemcomo os passos para a execução e controle de um script em um nó da rede. Primeira-mente um gerente verifica se o script, que deseja executar, já está instalado no nó da rede.Tal verificação é realizada consultando na ScriptTable (Passo 1). Caso o script já estiverinstalado o gerente continua no Passo 4. Para proceder com a instalação do script (Passo2), o gerente consulta as linguagens de programação disponíveis na tabela LanguageTa-ble (se necessário consulta as extensões instaladas na tabela ExtensionTable, omitida naFigura 3.1).

Figura 3.1: Implementação de um agente SNMP com suporte a Script MIB(SCHONWALDER; QUITTEK; KAPPLER, 2000).

Com base nas informações obtidas, o gerente armazena na tabela ScriptTable as in-formações referentes ao script instalado (Passo 3). Neste momento a instalação pode serrealizada através do “modelo pull” de transferência, onde a URL do repositório é arma-zenada e posteriormente é realizado o download do script através do protocolo HTTP;ou através do “modelo push”, que realiza a transferência do script através do protocoloSNMP, e armazena o código na tabela CodeTable (omitida na Figura 3.1).

Após a instalação, o gerente armazena na tabela LaunchTable as configurações para oambiente de execução do script (Passo 4). Após realizadas estas etapas, o gerente pode darinício a execução do script. As informações sobre tal execução, bem como os resultadosobtidos são armazenados na tabela RunTable e ficam disponíveis por um determinadotempo para a consulta do gerente.

3.1.3.6 Considerações Finais

O grupo DISMAN surgiu pela necessidade de desenvolver ferramentas que possibi-litem o gerenciamento de redes de forma distribuída. De certa forma, ao longo do pro-cesso, foram desenvolvidas diversas técnicas que possibilitam implementar “inteligência”nos dispositivos gerenciados. Dentre estas técnicas a que possui um maior grau de pro-gramabilidade é a Script MIB, que foi alvo de diversas pesquisas no passado, entre elas,automação e gerenciamento remoto de processos de controle (QUITTEK; KAPPLER,

28

1999), gerenciamento de configurações baseado em políticas (MARTINEZ et al., 2002) edetecção de intrusão distribuída, com utilização de estados (GASPARY et al., 2005).

Além de seu foco restrito ao gerenciamento, algumas importantes limitações ocasio-naram a não utilização da Script MIB para prover a programabilidade de redes, dentre elasum dos fatores mais determinantes foi a segurança, pois havia a necessidade de possuirprivilégios de administrador para realizar a instalação e execução dos scripts nos dispo-sitivos. Porém, o desenvolvimento dos scripts em qualquer linguagem de programação,desde que essa seja suportada pela implementação da Script MIB; as diferentes formas dedistribuição dos scripts; e a recuperação de resultados obtidos com a execução em locaisdistribuídos, são algumas características merecem destaque.

Outras técnicas também desenvolvidas pelo DISMAN devem ser mencionadas, en-tre elas a RFC 2981 (Event MIB), a RFC 2982 (Expression MIB), a RFC 4560 (RemoteOperations MIB) e a RFC 3231 (Schedule MIB). Essas soluções permitem que novastarefas sejam executadas pelos dispositivos, tais como, agendamento de operações perió-dicas, envio de notificações ao detectar falhas, criação de novos objetos com base em umaexpressão pré-definida, entre outras. Isoladamente tais técnicas pouco contribuem paraefetivamente programar os dispositivos. Entretanto, ao utilizar um conjunto destas técni-cas, aliadas a Script MIB, é possível desenvolver aplicações que vislumbrem um maiornível de programabilidade, como por exemplo, executar script pré-definido ao detectaruma determinada falha.

3.2 Tecnologias Disponíveis no Mercado

A função mais básica dos roteadores é o encaminhando de pacotes de um ponto aoutro. Entretanto, mais recentemente com o amadurecimento da Internet outras funçõestêm sido atribuídas a estes equipamentos. Citando algumas novas funções assumidas porroteadores, pode-se listar: filtro de pacotes (firewall), tradução de endereços de rede, QoS,entre outras.

Entretanto, apesar dessas funções, o núcleo da rede composto pelos roteadores temse tornado pouco flexível, limitando-se a pequenas atualizações. Neste cenário algumastecnologias que visam fomentar inovação, tornando a Internet mais flexível, têm surgido,cada uma com sua abordagem, tais como as descritas a seguir.

• Software Routers, utilizando computadores com múltiplas interfaces e implemen-tando o roteamento por software.

• Hardware customizado, utilizando hardware customizado para as aplicações, comopor exemplo, o NetFPGA (NAOUS et al., 2008).

• Equipamentos proprietários, utilizando equipamento de prateleira modificados.

3.2.1 Click Modular Router

O Click Modular Router (KOHLER et al., 2000), um roteador baseado em softwareque implementa através de módulos as funcionalidades de um roteador. Existem diversostrabalhos na literatura que fazem uso do Click, tais como, (SRINIVASAN et al., 2009),(DOSHI; BHANDARE; BROWN, 2002), (SCHMID; DREIER; SRIVASTAVA, 2006) e(KULKARNI; BREBNER; SCHELLE, 2004).

Em (SAUCEZ; NGUYEN, 2009) é proposta uma implementação baseada no Click,chamada Locator/ID Separation Protocol (LISP), um novo protocolo que visa separar a

29

Figura 3.2: Um roteador simples baseado no Click.

parte que identifica um nó na rede da parte que o localiza, ao contrário do IP, onde tanto alocalização quanto a identificação residem em seu endereço, visando resolver alguns pro-blemas da Internet atual, tais como: nós Multihomed e nós móveis. Nesta implementação,todo o processamento associado ao LISP, como por exemplo, a classificação de pacotes, acriação dos túneis e o cache de mapeamento de endereços é realizado em vários módulosClick.

O Projeto VRouter tem por objetivo desenvolver uma plataforma para roteadores vir-tuais baseados em computadores os quais, segundo os autores, seriam capazes de suportardiversas instâncias desses roteadores simultaneamente. Esse projeto utiliza o Click paraimplementar os roteadores virtuais funcionando sobre um sistema operacional Linux emáquinas virtuais funcionando sobre o Xen.

O problema de desempenho de roteadores funcionando sobre computadores comunsé tratado através da modificação do Click para atuar em clusters de computadores conec-tados através de links de alta-velocidade e baixa latência. Nessa proposta foi comprovadoque o desempenho de roteadores virtuais é similar a roteadores dedicados além de mantere permitir o desenvolvimento de novas funcionalidades do Click.

O Click Modular Router é uma ferramenta utilizada para implementar roteadores demaneira modular. A arquitetura destes roteadores é centrada em pequenos módulos cha-mados Elementos, que são pequenos blocos de software , escritos na linguagem C++, queimplementam operações simples como decrementar o TTL de um pacote. Estes elemen-tos que compõem um roteador são organizados na forma de um grafo, onde os vérticessão os próprios elementos e as arestas descrevem o caminho que o pacote deve percorrer.A Figura 3.2 mostra um roteador simples montado através da conexão de três elemen-tos. O primeiro elemento, denominado FromDevice(eth0), é responsável por encaminharos pacotes para o próximo elemento. O segundo, denominado de Counter, conta o nú-mero de pacotes e, finalmente, o terceiro elemento, denominado Discard é responsávelpor descartar os pacotes.

Os roteadores Click cujas funcionalidades são apresentadas em seguida, podem operarsegundo 3 modos distintos, a saber: kernel, UserLevel, simulação.

No modo kernel, os pacotes recebidos pelo computador são encaminhados para oroteador Click e não para as interfaces. O roteador Click no modo UserLevel funcionacomo um processo de usuário. Por fim, no modo Simulação o roteador Click funcionacomo um módulo do NS-2, chamado NSClick.

Um roteador Click operando no modo kernel em um computador com configuraçãode hardware normal, chega a atingir a taxa de encaminhamento de 357.000 pacotes de 64bytes por segundo, mais que alguns roteadores comerciais. Com otimizações efetuadasno hardware esta taxa pode chegar a 446.000 pacotes por segundo.

30

3.2.1.1 Elementos

Os Elementos, conforme já mencionado, são os módulos centrais dos roteadores Clickassim, toda configuração depende de como eles são organizados e implementados. Oselementos possuem cinco propriedades, que são: classes, portas, string de configuração,interfaces de métodos e handlers. Esses elementos são descritos a seguir.

As classes do Elemento especificam o formato dos dados e o comportamento desteelemento. Em C++, todos os elementos são subclasses da classe Element. Por sua vez,todo elemento pode possuir diversas portas de entrada e de saída. A quantidade de portasé definida na configuração do elemento, e toda porta definida deve ser utilizada por pelomenos uma conexão. As portas podem ser de três tipos: pull, push e agnostic. Outrapropriedade são as strings ou parâmetros de configuração. As strings ou parâmetros deconfiguração são opcionais e devem ser utilizados para alterar o estado do elemento. Essesparâmetros são fornecidos no momento da inicialização do roteador. Quanto à interfacede métodos, essa interface é composta pelos métodos que cada elemento disponibilizapara uso para os demais elementos. Por fim, handlers são métodos disponibilizados parao usuário, baseados em leitura e escrita simples de texto. Através deles é possível, porexemplo, obter informações dos elementos.

Na Figura 3.3 são exibidas as propriedades do elemento Tee. O elemento Tee, de umclasse Tee, copia cada pacote recebido em sua porta de entrada e envia uma cópia paracada porta de saída. O parâmetro de configuração da classe Tee está entre parênteses einforma ao elemento que devem ser criadas duas portas de saída. A interface de métodose os handlers não são exibidos, mas estão implícitos na classe.

Figura 3.3: Elemento Tee.

No site dos desenvolvedores do Click é disponibilizada uma vasta biblioteca de ele-mentos prontos para uso cujos códigos-fonte estão disponíveis. Uma forma de criar novoselementos é alterando os códigos-fonte disponíveis dos elementos encontrados nessa bi-blioteca de elementos. Além disso, como todos os elementos herdam suas característicada classe Element, normalmente poucos métodos precisam ser sobrescritos, não exigindoportanto que toda a lógica seja reconstruída. Outra maneira de se criar novos elementos éatravés da composição de vários para formar um elemento mais complexo. Na listagemabaixo é exibida parte do código fonte do elemento ICMP.

00124 static inline size_t00125 click_icmp_hl(uint8_t icmp_type)00126 {00127 if (icmp_type == ICMP_TSTAMP || icmp_type == ICMP_TSTAMPREPLY)00128 return sizeof(click_icmp_tstamp);00129 else00130 return sizeof(click_icmp);00131 }

31

0013200133 #endif

No tocante as conexões, os elementos Click suportam dois tipos: push e pull. Asconexões, do tipo push são indicadas para as situações onde o recebimento de pacotesnão solicitados é esperado, por exemplo, pacotes provenientes de outros equipamentospara o roteador. As conexões do tipo pull aplicam as situações onde o roteador tem ocontrole de quando pode transmitir os dados, por exemplo, quando o destinatário estiverdisponível. É importante que conexões entre portas pull e push não são permitidas. Nassituações onde é necessário este tipo de conexão as portas do tipo agnostic são utilizadase se comportam como portas pull quando conectadas a portas push e vice-versa.

Na Figura 3.4 é exibido um pacote P sendo recebido por um roteador e sendo armaze-nado em um elemento que implementa uma fila. Os pacotes são “empurrados” até a filapor conexões push e depois são retirados da mesma a através de conexões pull.

Figura 3.4: Pacote é recebido por roteador e armazenado em fila.

3.2.1.2 Configuração dos roteadores

Os roteadores Click são compostos por elementos que são configurados na forma deum grafo o qual descreve o caminho dos pacotes. Existem basicamente duas diretivasprincipais para configuração dos roteadores, a saber: as declarações e as conexões.

O formato das declarações de elementos é ilustrado abaixo e utilizam o símbolo “::”.

nome1 :: classe1(string-de-configuração);nome2 :: classe2;nome3, nome4 :: classe3;

No exemplo, classe1, classe2 e classe3 são as classes dos elementos que serão defi-nidos para então serem usados e nome1, nome2, nome3 e nome4 são os elementos emsi.

Já o formato das conexões entre os elementos é ilustrado abaixo:

nome1[porta1] -> [porta2] nome2 [porta3] -> [porta4] nome4

No exemplo, as portas de conexão são identificadas por colchetes e quando colocadasantes do nome do elemento atuam como portas de entrada e se colocadas após o mesmoatuam como portas de saída. A conexão entre os elementos e suas portas é feito pelosímbolo “->”.

32

Em síntese, a força do Click reside na sua modularidade apoiada pela orientação aobjetos de sua programação que permite que novos elementos, que implementem as fun-cionalidades almejadas pelo desenvolvedor, sejam mais simples de serem construídas jáque as características principais já estão prontas. Além disso, módulos totalmente novospode ser criados.

3.2.1.3 Considerações Finais

Os seguintes critérios foram utilizados para avaliação do Click no que concerne a pro-gramabilidade de rede: aplicabilidade da solução, interoperabilidade/controle de trans-ferência, segurança, infraestrutura de rede e relação da proposta perante a comunidadecientifica quanto a maturidade, atualidade e impacto em relação a outras propostas.

No tocante a aplicabilidade, o Click pode ser considerado como sendo abrangente umavez que ele pode ser utilizado tanto para modificar serviços já disponíveis quanto paracriar outros. Adicionalmente, o Click proporciona facilidade quanto ao desenvolvimentode roteadores uma vez que é adotado a linguagem de programação C/C++ a qual é muitodifundida no meio comercial e acadêmico, considerada de fácil aprendizado, portável,além de ser flexível.

Quanto à interoperabilidade/controle de transferência, o Click não suporta a migraçãodo código e do estado de execução, e se caracteriza pela falta de mecanismos que evitemque problemas na rede causem impacto no roteador, reduzindo assim sua eficiência oumesmo tornando-o inoperante. Quanto à existência de segurança até o presente momentonão foram encontradas referências no que diz respeito a existência de uma estrutura desegurança que possibilite um controle de acesso granularizado, permitindo a crianção deníveis de acesso aos roteadores Click.

Quanto à infraestrutura de rede, é importante ressaltar que o custo dos equipamentosnecessários para disponibilizar a solução na rede é baixo uma vez que pode ser utilizadohardwares programáveis ou mesmo computadores e que os mesmo precisam utilizar aplataforma Linux como base.

Por fim, destaca-se que o Click evoluiu desde que foi concebido em 2000 pois é possí-vel encontrar na literatura diversos trabalhos que apresentam melhorias quanto ao projetooriginal. É relativamente atual, uma vez que sua última versão foi lançada em 2010. Porfim, é apoiado pela comunidade científica no sentido que é uma ferramenta gratuita e decódigo aberto.

3.2.2 OpenFlow

O OpenFlow (MCKEOWN et al., 2008) utiliza a separação dos switches Ethernetmodernos em dois planos: plano de controle e plano de dados. O OpenFlow é capazde alterar o comportamento da rede através de interfaces padronizadas, fornecidas porestes switches para manipulação das tabelas de fluxo no plano de dados, através de umprotocolo definido por sua API, e através de ações que atuam sobre o fluxo de pacotes quepassa pelo switch.

Apesar do OpenFlow ter sido concebido para tratar da separação dos fluxos através deações associadas definidas pelo fabricante do switch, é possível que com o surgimento denovas ações, a capacidade do OpenFlow de atuar sobre a rede seja ampliada. Por exem-plo, Heller et. al. (HELLER et al., 2010) propõem uma aplicação que controla o statusdas portas dos switches de acordo com a carga sobre os mesmos, ativando assim apenas asportas necessárias, ou seja, em uso. O fato de desligar portas por tal aplicação possibilitareduzir o consumo de energia do switch. O artigo cita inclusive que uma nova ação possí-

33

vel seria um mecanismo de controle de energia permitido desligar totalmente os switchesquando não houvesse fluxo de pacotes. Já Braga e Mota (BRAGA RODRIGO; MOTA,2010) propõem uma ferramenta de detecção de ataques de negação de serviço distribuídos(DDoS) que, a partir das estatísticas dos fluxos que passam pelos switches, uma aplicaçãofuncionando no controlador, no caso o NOX, classifica os diversos tipos de ataque DDoS.

Um switch OpenFlow, conforme ilustrado na Figura 3.5 é composto por três partes:tabela de Fluxo, Canal Seguro e Protocolo OpenFlow. As Tabelas de Fluxo contêm regrasque são responsáveis por controlar como o switch tratará o fluxo de dados. De acordocom a regra é associada ao fluxo uma ação. As tabelas de fluxo conforme já mencionadoassociam ações aos fluxo e como várias ações podem ser agrupadas em um mesmo grupo,tem-se as tabelas de grupo - Group Table. O Canal Seguro visa conectar o switch aocontrolador remoto, representado pelo controlador NOX. Por fim, o protocolo OpenFlowé responsável pela padronização da interface pela qual o controlador se comunica com oswitch.

Figura 3.5: Switch OpenFlow.

Existem dois tipos de switches OpenFlow: habilitados (OpenFlow-Enabled) e os na-tivos. Os switches OpenFlow habilitados suportam tanto o processamento das camadas2 e 3 quanto do OpenFlow, enquanto que os nativos ou dedicados suportam apenas oOpenFlow.

Os pacotes uma vez localizados nos switches, são tratados de acordo com regrasdefinidas pelo Controlador OpenFlow e armazenadas nas tabelas de fluxo, como podeser visto na Figura 3.6. Estas regras podem utilizar várias informações do pacote paraclassificá-los tais como: a porta de entrada, o endereço físico de origem, o VLAN ID, en-tre outras. Baseando-se nesta classificação são atribuídas ações que devem ser aplicadasaos pacotes.

Todo switch OpenFlow deve suportar pelo menos três ações, a saber: (i) encaminhar,(ii) encapsular e encaminhar e (iii) descartar. Na ação Encaminhar, o pacote é encami-nhado para uma ou mais portas. Na ação encapsular e encaminhar, o pacote é encapsuladoe encaminhado para o Controlador. Tal procedimento é efetuado para que o controladorpossa decidir qual ação tomar para este pacote e todos os demais pacotes que possuem asmesmas características ou ainda para processamento do pacote pelo próprio Controlador.Na ação descartar, o pacote é descartado propriamente dito. Por fim, no caso de switchesOpenFlow-Enabled existe ainda uma quarta ação, encaminhar para processamento, naqual o pacote é encaminhado para processamento normal do switch sem interação com o

34

OpenFlow.

Figura 3.6: Funcionamento do OpenFlow.

Os switches que suportam essas quatro ações e o formato de cabeçalho do OpenFlowsão classificados como Tipo 0. Espera-se que outras ações sejam suportadas, como porexemplo: reescrita do cabeçalho, controle de prioridade, criptografia, entre outras. Oconjunto destas novas ações deverá criar uma nova classificação para os switches, a Tipo1.

3.2.2.1 Considerações Finais

Quanto a avaliação do OpenFlow no que concerne a aplicabilidade, pode-se afirmarque o OpenFlow tem uma abrangência relativa uma vez que não é possível criar ou mo-dificar serviços. No OpenFlow é possível apenas atuar sobre o comportamento dos fluxosque passam pelo equipamento e criar novas ações que atuem de maneira mais abrangentenos pacotes e nos switches.

Com relação ao custo, o OpenFlow peca por exigir a utilização de equipamentos es-pecíficos, que permite o controlador ter acesso à tabelas de fluxos e que seja capaz desuportar as ações sobre os fluxos citadas anteriormente. Além disso, a utilização dessesequipamentos também impacta o quesito de suporte à arquitetura existente.

Já quanto à facilidade no desenvolvimento e às características de programação, comoo OpenFlow apenas especifica como um equipamento que o implementa devem se com-portar, especificando também um protocolo de acesso a estes equipamentos, fica a cargodo desenvolvedor como implementar as aplicações, o que na verdade acaba por facilitar eaté mesmo reduzir os custos com o desenvolvimento, visto que não é necessário aprenderalgo novo.

Quanto ao critério de eficiência destaca-se a capacidade de separação dos fluxos, iso-lando portanto as aplicações e impedindo que uma aplicação afete as outras que estejamutilizando o mesmo equipamento. Com relação ao critério segurança, vale ressaltar a ca-pacidade do controlador OpenFlow, de controlar os limites das aplicações quanto à áreade atuação e o acesso as tabelas de fluxos do equipamento.

Por fim, destaca-se que o OpenFlow foi proposto em 2008 e continua evoluindo desdeentão, sendo inclusive a base da Global Environment for Network Innovations (GENI),

35

um grande laboratório de redes de computadores em grande escala. Além disso é possí-vel encontrar diversos trabalhos recentes, como os citados nestes relatório, utilizando oOpenFlow. Por fim, a comunidade científica apoia seu uso uma vez que o OpenFlow éuma ferramenta gratuita e de código aberto.

3.2.3 Juniper Junos SDK

O Junos Software Development Kit (SDK) é uma plataforma aberta e extensível parao desenvolvimento de aplicações que funciona integrada ao sistema operacional de rededa Juniper, o Junos2. O Junos SDK faz parte da Partner Solution Development Plataform(PSDP), um programa da Juniper através do qual parceiros podem desenvolver aplicaçõespara os seus equipamentos.

O Junos é capaz de integrar os serviços de roteamento, switching, segurança e serviçose é utilizado pela maioria dos equipamentos Juniper. Seu núcleo é baseado no FreeBSD,um sistema operacional open-source baseado em Linux desenvolvido originalmente pelaUniversidade de Berkeley.

O Junos está divido em 3 partes, a saber: (i) plano de controle; o (ii) plano de dados;e (iii) o plano de serviço. As aplicações desenvolvidas no Junos SDK são executadas noPlano de Controle e no Plano de Serviço.

O objetivo principal do plano de controle é gerenciar e controlar o comportamento doequipamento como um todo, incluindo os dois outros planos. Esse plano funciona em umhardware chamado Router Engine (RE), normalmente redundante, cujo elemento prin-cipal é o Junos Software Operating System. Para gerenciar o equipamento, é necessárioutilizar além do RE, daemons3 e aplicações lançadas sob demanda. Além disso, a gerên-cia atua em um destes dois modos: operacional e configuração. O modo Operacional éutilizado para mudança de versão de software, lançamento de eventos e consulta de statuse estatísticas. O modo de Configuração atua sobre as configurações dos equipamentos. Osdaemons se registram nesta área para serem notificados no caso de eventuais alterações,para então agir de acordo com as mesmas.

O plano de dados é composto de um hardware ASIC 4 e do micro código Junos e tem afunção de encaminhar ou filtrar o tráfego de acordo com a tabela de roteamento com baseem filtros e regras pré estabelecidas. Esse plano realiza este processamento baseado noscabeçalhos da camada de enlace e da camada de transporte e pode descartar, redirecionar,controlar a taxa de vazão, criar logs e modificar parâmetros de QoS de acordo com oque for estabelecido pelo plano de controle. Normalmente, o plano de dados, tambémchamado de Packet Forwarding Engine (PFE), objetivando ganhos de desempenho operasem ciência do estado das conexões.

Finalmente, o plano de serviço é uma extensão opcional do plano de dados e executaos serviços cientes de estado de conexão e qualquer outra função não nativa do PFE.Cada plano de serviço é executado em módulos de hardware instaláveis nos equipamentosJuniper chamados genericamente de MultiServices Modules os quais são conectados aoPFE por via canais de 10Gbps. Esses módulos de hardware são similares ao RE maspossuem um CPU multitarefa e mais memória dedicada, além de serem hot-swappable 5.

2http://www.juniper.net3Um programa de computador que roda de forma independente em background sem ser diretamente

controlado por um usuário.4Application Specific Integrated Circuit, um circuito integrado customizado para executar uma tarefa

específica.5Dispositivo que pode ser trocado mesmo com o equipamento ligado e em funcionamento.

36

Esta capacidade adicional os tornam capazes de processar pacotes em paralelo e manteruma grande quantidade de estados.

Mais uma peculiaridade do plano de serviço é a sua divisão em: subplano de serviçoe o subplano de controle. O primeiro pode ser usado para execução de aplicações quenormalmente funcionariam no RE para, dentre outros motivos, se beneficiar do ganhode desempenho devido ao compartilhamento de memória e informações com aplicaçõesfuncionando no plano de serviço. Já o subplano de controle atua transformando ou moni-torando os pacotes que são encaminhados pelo PFE.

Como dito anteriormente, o plano de controle também é responsável por gerenciar oplano de serviço, sendo portanto responsável pelas tarefas descritas em seguida.

• Instalar e executar o software nos MS.

• Configurar o software de acordo com as políticas pré-definidas.

• Desviar o tráfego do plano de dados para o plano de serviço. Tal desvio pode serefetuado de três formas. Na primeira, cria-se rotas na tabela de rotamento que apon-tam para o MS. Na segunda são utilizadas políticas que marcam o tráfego que deveser direcionado, as quais são aplicadas as interfaces de entrada. E, finalmente, naterceira é utilizado um método chamado de sampling, onde os dados são copiadospara o MS de acordo com regras sem que o tráfego original seja afetado.

3.2.3.1 Junos SDK

O Junos SDK provê Application User Interfaces (APIs) que permitem que aplicaçõessejam incorporadas ao Junos permitindo que as mesmas controlem o comportamento dosequipamentos. Os componentes e aplicações desenvolvidos através da SDK, uma vezimplantados, rodam nativamente nos equipamentos Juniper com Junos como qualqueroutro processo nativo do sistema.

Como o PSDP se propõe a suportar diversos parceiros, o ambiente onde as aplicaçõessão executadas é controlado de maneira que uma aplicação não cause interferência emoutra. Este controle começa pela separação da área de instalação de cada parceiro, base-ado no seu identificador ID fornecidos pela Juniper e extraído de um certificado assinadopela mesma. O número máximo de identificadores depende da quantidade de memóriae CPU disponíveis e também da quantidade de arquivos aberto e permissão de acesso asockets. Um efeito colateral desta separação de área de instalação por parceiro baseadono identificador é a garantia de autenticidade das aplicações e também a identificação decódigos que não nativos do sistema.

3.2.3.2 O Routing Engine e o Services SDK

Como já foi dito, através do Junos SDK é possível interagir com diversos componentesdo Junos utilizando suas APIs, que são bibliotecas em linguagem C/C++. Ele é compostode duas partes distintas o Routing Engine SDK (RE SDK), voltada para o plano de controlee o Services Engine SDK dedicado ao plano de serviço.

O RE SDK é utilizado na construção de aplicações que estendem o software do planode controle na Routing Engine. Como o RE está sempre presente em todo equipamentoJuniper, as aplicações baseadas neste SDK podem ser instaladas sem a necessidade dequalquer hardware adicional.

Já as aplicações desenvolvidas no Services SDK, apesar de similares às do RE SDK,funcionam apenas nos MS e processam os dados desviados, como descrito no item Plano

37

de Serviço na Subseção 3.2.3. Na Figura 3.7 é exibida a visão integrada dos módulos doJunos SDK.

Figura 3.7: Módulos do Junos SDK.

Existem dois modos usados para construir aplicações no MS SDK, que são: MóduloProcesso (Process Model) e Módulo Plugin (Plugin Model) exibido na Figura 3.9. CadaMS só suporta um desses modos por vez.

O Módulo Processo descrito na Figura 3.8 cria um daemon composto de dois compo-nentes: Controle e Data. O primeiro (Control Component) se comunica com o RE parareceber e armazenar as políticas definas para o MS. Além disso, esse componente tambémpode enviar dados de estatísticas para o RE. O segundo componente (Data Component)funciona em diversas tarefas (threads) e tem como função a coleta de pacotes.

No módulo Plugin, o Junos cria para cada plugin seu próprio componente de data(Data Component) permitindo assim que vários serviços possam coexistir e mesmo coo-perar entre si. Em ambos módulos, cabe ao kernel do Junos processar a tarefa de forneceros pacotes ao MS e devolvê-los ao tráfego normal.

3.2.3.3 Virtual Build Environment

Tanto o RE SDK quando o services SDK utilizam o Virtual Build Environment (VBE)como ambiente de desenvolvimento. O VBE é fornecido no formato de uma máquina vir-tual FreeBSD executável através do VMWare Player, sendo portanto portável para qual-quer plataforma onde este último funcione. Com o VBE são fornecidas todas as ferramen-tas necessárias para o desenvolvimento, como por exemplo: compiladores, linkeditores edebuggers.

3.2.3.4 Aplicações Utilizando o Junos SDK

Algumas empresas já estão utilizando o Junos SDK para desenvolver softwares paraos equipamentos Juniper. A Macadamian (BLOG, 2011) desenvolveu um gravador de li-gações VOIP o qual, captura o áudio das ligações SIP sobre UDP, filtrando estas chamadaspor endereço de origem da chamada.

Outra aplicação utilizando o Junos SDK é o MoniTube utilizado para monitorar aqualidade de streams IPTV e que também pode espelhar esses streams para outras locali-dades.

38

Figura 3.8: Process Model

3.2.3.5 Considerações Finais

Com relação a abrangência, destaca-se a capacidade do Junos SDK de ser utilizadatanto para efetuar o controle dos equipamentos quanto para a criação de novas aplicações.A linguagem de programação utilizada é o C/C++., portanto, é robusta e difundida. Essalinguagem por utilizar a abordagem orientada a objetos, é considerada de boa legibilidadee muito flexível.

Quanto a interoperabilidade e ao controle de transferência, não foram encontradasreferências quanto a capacidade de suporta a migração do código e do estado de execução,mas não existe restrições descritas no material quanto a implementação deste recurso pelodesenvolvedor.

Com relação ao custo, à portabilidade e ao suporte a infraestrutura existente, o JunosSDK peca por exigir a utilização de equipamentos Juniper. Por outro lado, como o JunosSDK funciona sobre um sistema operacional único e comum a todos os equipamento destefabricante, é bem avaliado quanto ao critério heterogeneidade pois, apesar de limitado àJuniper, pode ser utilizado em todos os equipamentos.

Quanto à segurança, destaca-se o fato da tecnologia prover mecanismos que limitamo que cada aplicação pode fazer e de que maneira as mesmas afetam o tráfego, podendoser transparente para o mesmo.

3.2.4 Cisco AON

O Application-Oriented Networking (AON), terceira e última fase do projeto Intelli-gent Information Network (IIN) da Cisco System (CISCO, 2011b), consiste em um sis-tema de roteamento que compreende o conteúdo e o contexto das mensagens que circulam

39

Figura 3.9: Plugin Model

na rede. Ou seja, o AON atua na camada de aplicação e, portanto, é capaz de realizar ope-rações nestas mensagens de acordo com a política da empresa. O AON serve de base paraa criação de produtos e soluções de rede Cisco, que possibilitam a convergência entre arede e aplicações. É importante mencionar que o Cisco AON requer para seu funciona-mento que equipamentos dedicados sejam instalados na rede, como o Cisco ApplicationDeployement Engine (CADE) 2142, exibido na Figura 3.10.

Figura 3.10: Cisco Application Deployement Engine.

3.2.4.1 Operação

Os switches ou roteadores Cisco podem redirecionar de maneira transparente o tráfegodas aplicações para o equipamento do AON onde as políticas definidas serão aplicadas aeste tráfego que então é direcionado à aplicação destino.

Figura 3.11: Cisco AON: redirecionamento transparente do tráfego de aplicações.

Como pode ser visto na Figura 3.11, o tráfego das aplicações é redirecionado de formatransparente para o módulo Cisco AON sem que sejam necessárias alterações nas aplica-

40

ções. O tráfego é reencaminhado ao seu destino após as políticas definidas serem aplica-das.

Por exemplo, o AON pode atuar como um gateway entre empresas parceiras, for-necendo uma interface transparente entre as mesmas ao lidar com os dados a nível deaplicação. Nesse exemplo, o AON pode estar garantir a autenticação e autorização deacesso, validação de mensagens dentre outros serviços ou integrar filiais remotas atuandocom uma ponte entre as aplicações operando nas mesmas, como descrito na Figura 3.12.

Figura 3.12: Exemplos de utilização do AON.

As operação realizadas nas mensagens são orquestradas pelo Cisco AON Develop-ment Studio, exibidas na Figura 3.13, onde as bladelets, operações que atuam sobre osdados, e os adaptadores, para tratamento de protocolos ou mensagens proprietárias, sãoorganizadas em um Plano de Execução de Políticas (PEP).

Além do sistema Cisco AON também é fornecida uma biblioteca de bladelets com asfuncionalidades descritas em seguida.

• Acesso externo - chamadas HTML (get/post) e acesso a bancos de dados.

• Log - criação e recuperação de log e cache.

• Lógica - criação de operações lógicas no Plano de Execução de Políticas.

• Manipulação de mensagens - operações realizadas diretamente sobre as mensagens,tais como, validação, atualização ou mesmo aplicação de políticas de QoS.

• Roteamento - redirecionamento e balanceamento de carga de mensagens.

• Segurança - serviço que possibilita a autorização, codificação, verificação de assi-natura, entre outros.

• Transformação - função que possibilitam conversão dos dados de/e para XML.

41

Figura 3.13: Orquestração de operações com Cisco AON Development Studio.

3.2.4.2 Serviços providos pelo AON

O AON provê um pacote de serviços, a saber: segurança, visibilidade, roteamentointeligente de mensagem e extensibilidade.

O serviço de Segurança provê segurança às aplicações, garantindo mecanismos deautenticação, autorização de acesso, integridade e autenticidade dos dados, confidenciali-dade e gerenciamento centralizado de certificados.

No serviço de Visibilidade, os nós do AON pode ser configurados para coletar e pro-cessar os dados sobre as aplicações que estão trafegando pela rede. Através desse serviçoé possível, por exemplo, criar aplicações que monitorem o tráfego em busca de ataques àsegurança ou mesmo criar logs para auditoria sem a necessidade de alterações nas aplica-ções envolvidas.

O serviço de Roteamento Inteligente de mensagens, possibilita de implementar qua-lidade de serviço em nível de aplicação, garantindo, por exemplo, que um sistema tenhamaior prioridade que um outro. Além disso, esse serviço pode realizar traduções entrediferentes protocolos e também pode atuar como um proxy de serviços.

Por fim, no serviço de Extensibilidade é incluída um conjunto de Application ProgramInterfaces (APIs) através da qual é possível desenvolver, utilizando linguagem C/C++ ouJava, novas operações (bladelets) e adaptadores que atuarão sobre as mensagens.

3.2.4.3 Considerações Finais

Com relação à facilidade de desenvolvimento, o Cisco AON utiliza linguagens am-plamente difundidas e fornece documentação para apoio ao desenvolvimento de novasaplicações. Entretanto, para facilitar o aprendizado do ambiente de desenvolvimento,cursos são fornecidos pelo fabricante de forma que se tenha uma total compreensão doambiente de desenvolvimento, o que aumenta o custo do processo.

42

Figura 3.14: Placa NetFPGA 1Gbps

Quanto à abrangência do CISCO AON, essa mostrou-se ser um fator limitante pelofato de atuar apenas sobre as mensagens, apesar de novas bladelets e novos adaptadorespoderem ser criados.

Com relação à heterogeneidade, é importante destacar que o AON é uma tecnologiadedicada da Cisco requerendo, portanto, que os equipamentos de rede sejam deste mesmofabricante. Tal fato pode causar impacto no custo e suporte à arquitetura existente.

É importante destacar que com relação à segurança, não foi encontrado no materialpesquisado informações a respeito de como o tráfego é tratado caso o equipamento quehabilita o AON apresente problemas de rede, nem como é definido o acesso das aplicaçõesàs mensagens.

3.2.5 NetFPGA

A plataforma NetFPGA foi criada visando o ensino e a pesquisa na área de redes decomputadores através da construção de sistemas de alta performace, switches ethernet eroteadores IP, utilizando hardwares programáveis ao invés de software.

O NetFPGA é opensource e consiste em uma placa PCI composta por um circuitoFPGA com dois processadores PowerPC, memórias e quatro portas Ethernet de 1Gbps,demonstrada na Figura 3.14, ou de 10Gbps, além das implementações de referência de umrouter IPv4, de um switch Ethernet e de uma placa de rede com quatro portas e materialdidático.

É importante ressaltar que, apesar da placas por enquanto estarem limitadas a quatroportas, um mesmo computador pode hospedar mais de uma placa, que são então co-nectadas através de um conector SATA para troca de dados em alta velocidade, sem anecessidade de utilização do barramento PCI.

A programação da placa, que utiliza uma linguagem Hardware Definition Language(HDL), e a administração é realizada através de computador, local ou remotamente, uti-lizando uma interface gráfica desenvolvida em java. Mas especificamente com relação aprogramação são utilizadas as seguintes ferramentas: Mentor Graphics ModelSim (MEN-TOR GRAPHICS MODELSIM, 2011) para debug e o pacote Xilinx ISE (XILINX ISE,2011) para compilação do código.

As aplicações desenvolvidas para o NetFPGA são organizadas em módulos e estes emum pipeline. Os dados chegam à placa, seja pela interface ethernet ou pela conexão PCI,são processados neste pipeline de acordo com a lógica de programação, demonstrado naFigura 3.15.

Esta modularidade facilita o desenvolvimento pois permite que apenas com a inclu-

43

Figura 3.15: Pipeline NetFPGA

são de módulos novos, seja modificado o comportamento do equipamento. Além disso,os módulos podem ser compartilhados, como já é feito pela netfpga.org, que possui umrepositório de módulos disponíveis para download com diversas funcionalidades (CO-VINGTON et al., 2009).

Outro fator importante do NetFPGA é o fato de utilizar um módulo de kernel recarre-gável, desta maneira não é necessário recompilar o sistema operacional para o funciona-mento. Além disso, uma vez configurada e programada, na maioria dos casos, os pacotesque chegam à interface são processados internamente, sem necessidade de interação como host.

Apesar de ter sido desenvolvido originalmente para o estudo e pesquisa, já existemaplicações utilizando o NetFPGA. Naous et. al. propõem uma implementação do Open-Flow (MCKEOWN et al., 2008) a qual está sendo utilizada no prédio da EngenhariaElétrica e de Ciência da Computação da Universidade de Stanford e também em parte dobackbone da Internet2 desta instituição (NAOUS et al., 2008).

Canini et. al. (CANINI et al., 2009) propõem um sistema de organização do tráfegode acordo com a aplicação que o está produzindo, permitindo o encaminhamento pelosdiferentes links ethernet. Esse sistema, com utilização do NetFPGA, provou ser até 20mais rápido que similares utilizando implementações apenas sobre software.

3.2.5.1 Conclusão

Com relação a abrangência destaca-se a capacidade do NetFPGA de ser utilizadotanto para efetuar o controle do comportamento da rede quanto para a criação de novasaplicações. Entretanto, a linguagem de programação utilizada não é fácil utilização.

Com relação ao custo, a portabilidade e ao suporte a infra-estrutura existente, o NetFPGAapresenta desvantagens pois requer a troca de equipamentos, os quais possuem custo emtorno de US$ 1.643,00 na época em que este documento foi escrito.

Quanto a interoperabilidade e ao controle de transferência devido a estrutura modula-rizada de desenvolvimento é possível alterar o funcionamento da aplicação com a adiçãoou remoção de módulos, sem que seja necessária alteração de todo o software. Entretantonão foram encontradas referências sobre a capacidade de migração de código e estadosde execução.

Quanto à segurança, não foram encontradas referências sobre controles de segurançanativos no NetFPGA, ficando a cargo do desenvolvedor implementar conforme suas ne-cessidades.

4 CONSIDERAÇÕES FINAIS

Neste relatório, apresentamos as principais tecnologias utilizadas para virtualizaçãoe para a programabilidade de redes, tanto as desenvolvidas pela comunidade acadêmica,quanto as atualmente disponibilizadas no mercado.

Ao longo dos anos houve uma crescente necessidade de implantar novos recursos narede, desde novos requisitos não previstos na concepção da Internet (e.g., a mobilidade),até alterações em suas características básicas (e.g., inclusão da tecnologia IPv6). Porém,por questões de padronização, de troca sucessiva de equipamentos e de custos atrelados,as tecnologias desenvolvidas não são rapidamente implantadas na rede. Com a recenteadoção da virtualização de redes pelos principais fornecedores de dispositivos (e.g., Cisco,Juniper e Extreme Networks), a comunidade científica vislumbra uma alternativa quepermita desenvolver, testar e implantar rapidamente as novas soluções desenvolvidas.

Neste contexto, a programabilidade de redes surge como uma ferramenta que possibi-litaria a implantação de diferentes recursos na rede. Com o intuito de avaliar o desenvol-vimento de uma nova proposta para a programabilidade à luz da virtualização de redes,foram analisadas diversas tecnologias, tanto as que foram propostas no passado, quantoas disponíveis no mercado atualmente, e que permitem algum nível de programabilidade.

4.1 Propostas da comunidade científica

Na década de 1990 houveram debates acalorados com relação a programabilidadede redes. Diversas pesquisas no meio acadêmico surgiram nesta época, dentre elas éválido citar, os Agentes Móveis, as Redes Ativas e as MIBs do Disman. Recentementeo OpenFlow surgiu como uma solução que permite implementar facilidades e um certonível de “inteligência” nos dispositivos da rede.

Os Agentes Móveis e o OpenFlow, diferentemente das Redes Ativas e das MIBs doDisman, têm sido alvos de um número maior de pesquisas recentemente, o que sinaliza-ria uma inclinação da comunidade científica para a utilização destas tecnologias. Porém,além de serem padronizadas por diversas RFCs, as MIBs do grupo Disman, foram di-versas vezes atualizadas ao longo da última década e, muitos equipamentos vendidosatualmente oferecem suporte a esta tecnologia. Algo semelhante está ocorrendo com oOpenFlow, que já possui dispositivos disponíveis no mercado que oferecem suporte àsúltimas versões.

Dentre as MIBs desenvolvidas pelo grupo de trabalho do IETF, o Disman, a que me-rece um maior destaque é a descrita na RFC 2592 e 3165, a Script MIB. Apesar de outrasRFCs permitirem algum nível de programabilidade, a Script MIB é a mais flexível dentreelas. Além disso, permite a execução de scripts desenvolvidos pelos próprios usuários, oque não se repete nas outras MIBs, que limitam-se a oferecer cálculos de expressões e/ou

45

comandos (sets e traps) do protocolo SNMP.Todas as tecnologias, desenvolvidas pela comunidade científica, possuem uma certa

facilidade na implementação dos programas desenvolvidos, visto que elas permitem o usoda linguagem Java, hoje amplamente difundida. Porém a Script MIB, leva uma pequenavantagem nesse critério, pois permite a escrita do programa em qualquer linguagem deprogramação, desde que esta seja suportada pela implementação da Script MIB instaladanos dispositivos.

No desenvolvimento com OpenFlow é especificado apenas como os equipamentos de-vem operar. Portanto, fica a cargo do desenvolvedor a implementação das aplicações ede suas necessidades específicas. Tal característica facilita e até reduz os custos com odesenvolvimento, pois não é necessário aprender uma linguagem de programação especí-fica.

A nível de abrangência da solução, a Script MIB deixa a desejar em relação as demais,visto que o seu escopo, limita-se ao gerenciamento de redes. Enquanto ela não possibilitaa criação de aplicações maiores e mais flexíveis, as demais tecnologias (Redes Ativas,Agentes Móveis e o OpenFlow) possibilitam a criação destas aplicações/serviços.

Uma característica encontrada apenas no OpenFlow é a sua capacidade de separaçãodos fluxos, pois isola as aplicações que estão utilizando o mesmo equipamento. Alémdisso, vale ressaltar que o controlador Openflow, limita a área de atuação das aplicaçõese o acesso destas às tabelas de fluxos dos equipamentos. Tal característica é um pontofraco nas demais tecnologias, que não possuem uma separação dos diferentes fluxos, poispermitem que um fluxo altere indevidamente outro.

Porém, todas as tecnologias pecam em um ponto específico, a segurança. Para permitira execução de um programa pelos dispositivos da rede, o administrador deverá forneceracesso as configurações dos dispositivos, o que no passado foi motivo para a não utilizaçãodestas tecnologias.

4.2 Tecnologias Disponíveis no Mercado

Dentre as tecnologias disponíveis atualmente no mercado, podemos destacar a plata-forma Junos SDK, desenvolvida pela Juniper; o Cisco AON, desenvolvido pela Cisco; e oClick uma ferramenta gratuita e de código aberto. Esta última leva uma grande vantagemem relação as demais, por não exigir o equipamento específico de um fabricante. Em umagrande rede de produção é praticamente impossível que todos os equipamentos sejam deum único fabricante, visto a heterogeneidade desta. Além disso, é importante ressaltarque o custo dos equipamentos necessários para disponibilizar a solução na rede é rela-tivamente baixo, uma vez que podem ser utilizados hardwares programáveis ou mesmocomputadores comuns.

Por serem desenvolvidos pelos próprios fabricantes, tanto o Cisco AON, quanto o Ju-nos SDK, possuem características próprias e que funcionam perfeitamente em seus equi-pamentos. No entanto, tal fato pode causar impacto no custo e no suporte da arquiteturaexistente, na implantação das aplicações desenvolvidas nestas plataformas.

Quanto à segurança, o Junos SDK destaca-se por limitar o que cada aplicação pode re-alizar e a maneira como estas afetam o tráfego. Já o Click, peca pela falta de mecanismospara evitar que problemas da rede causem impactos nos dispositivos, reduzindo assim suaeficiência ou mesmo tornando este inoperante. Além disso, é importante ressaltar que atéo presente momento não foram encontradas referências à respeito do funcionamento deuma estrutura de segurança, tanto no Click, quanto no Cisco AON.

46

As tecnologias avaliadas utilizam linguagens robustas e amplamente difundidas, comopor exemplo, o C/C++. Tal linguagem é extremamente flexível e permite a programaçãoorientada à objetos. É válido salientar, que o Cisco AON fornece a documentação deapoio ao desenvolvimento de novas aplicações. Além disso, para facilitar o aprendizadodo ambiente de desenvolvimento, cursos são fornecidos pelo fabricante de forma que setenha uma total compreensão do framework.

Dentre as tecnologias analisadas, a que possui um menor nível de abrangência é aCisco AON, limitando sua atuação apenas sobre as mensagens, apesar de possibilitar quenovas bladelets e novos adaptadores sejam criados. Já o Junos SDK pode ser utilizado,tanto para efetuar o controle dos equipamentos, quanto para a criação de novas aplicações.Enquanto isso, o Click pode ser considerado como o mais abrangente, uma vez que podeser utilizado tanto para modificar, quanto para criar novos serviços.

47

REFERÊNCIAS

ALEXANDER, D.; ARBAUGH, W.; HICKS, M.; KAKKAR, P.; KEROMYTIS, A.; MO-ORE, J.; GUNTER, C.; NETTLES, S.; SMITH, J. The SwitchWare Active Network Ar-chitecture. Network, IEEE, [S.l.], v.12, n.3, p.29–36, may/jun 1998.

ANDERSON, T.; PETERSON, L.; SHENKER, S.; TURNER, J. Overcoming the InternetImpasse Through Virtualization. Computer, [S.l.], v.38, n.4, p.34–41, april 2005.

BARHAM, P.; DRAGOVIC, B.; FRASER, K.; HAND, S.; HARRIS, T.; HO, A.; NEU-GEBAUER, R.; PRATT, I.; WARFIELD, A. Xen and the art of virtualization. In: ACMSYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES, 2003, New York, NY, USA.Proceedings. . . ACM, 2003. p.164–177. (SOSP ’03).

BLOG, M. VoIP Recorder on the Junos SDK. Disponível em:<http://www.macadamian.com/>. Acesso em: agosto 2011.

BRAGA RODRIGO; MOTA, E. . P. A. Lightweight DDoS Flooding Attack DetectionUsing NOX/OpenFlow. 35th Annual IEEE Conference on Local Computer Networks,[S.l.], 2010.

CAMILO, T.; SILVA, J.; CARRETO, C.; BOAVIDA, F. Redes de Sensores de PróximaGeração. In: Conferência sobre Redes de Computadores (CRC), 2005, Portalegre, Portu-gal. Anais. . . [S.l.: s.n.], 2005. p.85–98.

CANINI, M.; LI, W.; ZADNIK, M.; MOORE, A. W.; FD, C. C.; MOORE, A. W.; CA-NINI, M.; LI, W.; ZADNIK, M.; MOORE, A. W. AtoZ: an automatic traffic organizerusing netfpga. 2009.

CHESS, D.; HARRISON, C.; KERSHENBAUM, A. Mobile Agents: are they a goodidea? In: VITEK, J.; TSCHUDIN, C. (Ed.). Mobile Object Systems Towards the Pro-grammable Internet. [S.l.]: Springer Berlin / Heidelberg, 1997. p.25–45. (Lecture Notesin Computer Science, v.1222). 10.1007/3-540-62852-5_4.

CHOWDHURY, N. M. M. K.; BOUTABA, R. Network virtualization: state of the art andresearch challenges. Comm. Mag., Piscataway, NJ, USA, v.47, p.20–26, July 2009.

CISCO. Cisco. Disponível em: <http://www.cisco.com/>. Acesso em: maio 2011.

CISCO. Cisco AON Software. 2011.

COVINGTON, G. A.; GIBB, G.; NAOUS, J.; LOCKWOOD, J. W.; MCKEOWN, N.Encouraging Reusable Network Hardware Design. 2009.

48

DOSHI, S.; BHANDARE, S.; BROWN, T. X. An on-demand minimum energy routingprotocol for a wireless ad hoc network. SIGMOBILE Mob. Comput. Commun. Rev.,New York, NY, USA, v.6, p.50–66, June 2002.

GASPARY, L.; SANCHEZ, R.; ANTUNES, D.; MENEGHETTI, E. A SNMP-based Plat-form for Distributed Stateful Intrusion Detection in Enterprise Networks. Selected Areasin Communications, IEEE Journal on, [S.l.], v.23, n.10, p.1973–1982, oct. 2005.

Gian Pietro Picco. µCode. Disponível em: http://mucode.sourceforge.net/. Acesso: Maiode 2011.

GNU Quagga Project. Disponível em: http://www.quagga.net/docs/quagga.pdf. Acessoem: Junho de 2011.

GRAY, R.; KOTZ, D.; NOG, S.; RUS, D.; CYBENKO, G. Mobile Agents: the nextgeneration in distributed computing. In: IN AIZU INTERNATIONAL SYMPOSIUM ONPARALLEL ALGORITHMS AND ARCHITECTURES SYNTHESIS, 1997. Anais. . .[S.l.: s.n.], 1997. p.8–24.

HELLER, B.; SEETHARAMAN, S.; MAHADEVAN, P.; YIAKOUMIS, Y.; SHARMA,P.; BANERJEE, S.; MCKEOWN, N. ElasticTree: saving energy in data center networks.In: USENIX CONFERENCE ON NETWORKED SYSTEMS DESIGN AND IMPLE-MENTATION, 7., 2010, Berkeley, CA, USA. Proceedings. . . USENIX Association,2010. p.17–17. (NSDI’10).

INTERNET2, I. U. e. S. U. The Network Development and Deployment Initi-ative: expanding the breadth and reach of internet2 network services through thedevelopment of the open science, scholarship, and services exchange. Disponível em:http://www.internet2.edu/network/ose/docs/Open%20Science%20Exchange%20Whitepaper.pdf. Acesso: Maio de 2011.

JUNIPER. Juniper. Disponível em: <http://www.juniper.net/>. Acesso em: maio 2011.

JUNIPER NETWORKS. Control Plane Scaling and Router Virtualization. Disponívelem: http://www.juniper.net/us/en/local/pdf/whitepapers/2000261-en.pdf. Acesso: Maiode 2011.

KAVASSERI, R.; STEWART, B. Event MIB (RFC 2981). [S.l.]: RFC Editor, 2000.

KAVASSERI, R.; STEWART, B. Distributed Management Expression MIB (RFC2982). [S.l.]: RFC Editor, 2000.

KOHLER, E.; MORRIS, R.; CHEN, B.; JANNOTTI, J.; KAASHOEK, M. F. The ClickModular Router. In: USENIX ASSOCIATION, 2000, New York, NY, USA. Anais. . .ACM, 2000. v.18, p.263–297.

KULKARNI, C.; BREBNER, G.; SCHELLE, G. Mapping a domain specific language toa platform FPGA. In: DESIGN AUTOMATION CONFERENCE, 41., 2004, New York,NY, USA. Proceedings. . . ACM, 2004. p.924–927. (DAC ’04).

LANGE, D. B.; OSHIMA, M. Seven Good Reasons for Mobile Agents. Commun. ACM,New York, NY, USA, v.42, p.88–89, March 1999.

49

LAZAR, A. Programming telecommunication networks. Network, IEEE, [S.l.], v.11,n.5, p.8 –18, sep/oct 1997.

LEVI, D.; SCHOENWAELDER, J. Definitions of Managed Objects for SchedulingManagement Operations (RFC 2591). [S.l.]: RFC Editor, 1999.

LEVI, D.; SCHOENWAELDER, J. Definitions of Managed Objects for the Delegationof Management Script (RFC 2592). United States: RFC Editor, 1999.

LEVI, D.; SCHOENWAELDER, J. Definitions of Managed Objects for the Delegationof Management Scripts (RFC 3165). United States: RFC Editor, 2001.

LEVI, D.; SCHOENWAELDER, J. Definitions of Managed Objects for SchedulingManagement Operations (RFC 3231). [S.l.]: RFC Editor, 2002.

MARTINEZ, P.; BRUNNER, M.; QUITTEK, J.; STRAUSS, F.; SCHONWALDER, J.;MERTENS, S.; KLIE, T. Using the Script MIB for Policy-based Configuration Manage-ment. In: IEEE/IFIP Network Operations and Management Symposium, 2002. NOMS2002., 2002. Anais. . . [S.l.: s.n.], 2002. p.187–202.

MCKEOWN, N.; ANDERSON, T.; BALAKRISHNAN, H.; PARULKAR, G.; PETER-SON, L.; REXFORD, J.; SHENKER, S.; TURNER, J. OpenFlow: enabling innovationin campus networks. SIGCOMM Comput. Commun. Rev., New York, NY, USA, v.38,p.69–74, March 2008.

MENTOR Graphics ModelSim. Disponível em http://www.mentor.com/products/fv/modelsim/.Acesso em: Maio de 2011.

MERWE, J. V. d.; KALMANEK, C. Control Plane Scaling and Router Virtualization.Tech. Rep. 2000261-001-EN, Juniper Networks, Feb. 2009.

Mitsuro Oshima and Danny Lange. Aglets. Disponível em: http://aglets.sourceforge.net/.Acesso em: Maio de 2011.

MOREIRA, M.; FERNANDES, N.; COSTA, L.; DUARTE, O. Internet do Futuro: umnovo horizonte. In: XXVII Simpósio Brasileiro de Redes de Computadores e SistemasDistribuídos (SBRC), 2009. Anais. . . [S.l.: s.n.], 2009. p.1–59.

NAOUS, J.; ERICKSON, D.; COVINGTON, G. A.; APPENZELLER, G.; MCKEOWN,N. Implementing an OpenFlow switch on the NetFPGA platform. In: ACM/IEEE SYM-POSIUM ON ARCHITECTURES FOR NETWORKING AND COMMUNICATIONSSYSTEMS, 4., 2008, New York, NY, USA. Proceedings. . . ACM, 2008. p.1–9. (ANCS’08).

NAOUS, J.; GIBB, G.; BOLOUKI, S.; MCKEOWN, N. NetFPGA: reusable router ar-chitecture for experimental research. In: ACM WORKSHOP ON PROGRAMMABLEROUTERS FOR EXTENSIBLE SERVICES OF TOMORROW, 2008, New York, NY,USA. Proceedings. . . ACM, 2008. p.1–7. (PRESTO ’08).

NASCIMENTO, M. R.; ROTHENBERG, C. E.; SALVADOR, M. R.; CORRêA, C.; LU-CENA, S.; MAGALHãES., M. F. Virtual Routers as a Service: the routeflow approachleveraging software-defined networks. In: INTERNATIONAL CONFERENCE ON FU-TURE INTERNET TECHNOLOGIES 2011, CFI 11, 6., 2011. Anais. . . [S.l.: s.n.], 2011.

50

NETWORKS, E. Extreme Networks. Disponível em:<http://www.extremenetworks.com/>. Acesso em: maio 2011.

PSOUNIS, K. Active Networks: applications, security, safety, and architectures. Com-munications Surveys Tutorials, IEEE, [S.l.], v.2, n.1, p.2–16, quarter 1999.

QEMU. Disponível em: http://wiki.qemu.org. Acesso em: Julho de 2011.

QUITTEK, J.; KAPPLER, C. Remote Service Deployment on Programmable Switcheswith the IETF SNMP Script MIB. In: Proceedings of the 10th IFIP/IEEE InternationalWorkshop on Distributed Systems: Operations and Management, 1999, London, UK.Anais. . . Springer-Verlag, 1999. p.135–147. (DSOM ’99).

QUITTEK, J.; WHITE, K. Definitions of Managed Objects for Remote Ping, Trace-route, and Lookup Operations (RFC 4560). [S.l.]: RFC Editor, 2006.

SAUCEZ, D.; NGUYEN, V. N. LISP-Click: a click implementation of the locator/idseparation protocol. 2009.

SCHMID, T.; DREIER, T.; SRIVASTAVA, M. B. Software radio implementation of short-range wireless standards for sensor networking. In: EMBEDDED NETWORKED SEN-SOR SYSTEMS, 4., 2006, New York, NY, USA. Proceedings. . . ACM, 2006. p.381–382.(SenSys ’06).

SCHONWALDER, J.; QUITTEK, J.; KAPPLER, C. Building Distributed ManagementApplications with the IETF Script MIB. Selected Areas in Communications, IEEEJournal on, [S.l.], v.18, n.5, p.702–714, May 2000.

SCHWARTZ, B.; JACKSON, A.; STRAYER, W.; ZHOU, W.; ROCKWELL, R.; PAR-TRIDGE, C. Smart Packets for Active Networks. In: Open Architectures and NetworkProgramming Proceedings, 1999. OPENARCH ’99, 1999. Anais. . . [S.l.: s.n.], 1999.p.90–97.

SAMPALLI, S.; HAGGAG, Y.; LABONTE, C. Secure Architectures with ActiveNetworks. [S.l.]: John Wiley & Sons, Inc., 2006. p.135–151.

SHERWOOD, R.; GIBB, G.; YAP, K.-K.; APPENZELLER, G.; CASADO, M.; MCKE-OWN, N.; PARULKAR, G. FlowVisor: a network virtualization layer. 2009.

SRINIVASAN, S. R.; LEE, J. W.; LIU, E.; KESTER, M.; SCHULZRINNE, H.; HILT,V.; SEETHARAMAN, S.; KHAN, A. NetServ: dynamically deploying in-network ser-vices. In: RE-ARCHITECTING THE INTERNET, 2009., 2009, New York, NY, USA.Proceedings. . . ACM, 2009. p.37–42. (ReArch ’09).

TENNENHOUSE, D.; SMITH, J.; SINCOSKIE, W.; WETHERALL, D.; MINDEN, G.A survey of Active Network Research. Communications Magazine, IEEE, [S.l.], v.35,n.1, p.80–86, Jan. 1997.

TENNENHOUSE, D.; WETHERALL, D. Towards an Active Network Architecture. In:DARPA Active Networks Conference and Exposition, 2002. Proceedings, 2002. Anais. . .[S.l.: s.n.], 2002. p.2–15.

THE virtualization API. Disponível em: http://libvirt.org. Acesso em: Julho de 2011.

51

TOUCH, J. D.; WANG, Y. shun; EGGERT, L.; FINN, G. G. A Virtual Internet Architec-ture 1. Disponível em: http://www.isi.edu/div7/publication_files/tr-570.pdf. Acesso em:Maio de 2011.

VIRTUALBOX. Disponível em: http://www.virtualbox.org. Acesso em: Junho de 2011.

VMWARE. VMware Virtualization Software for Desktops, Servers & Virtual Machi-nes for Public and Private Cloud Solutions. Disponível em: http://www.vmware.com.Acesso em: Junho de 2011.

VYATTA Project. Disponível em: http://www.vyatta.com/solutions/physical/networkOS.Acesso em: Junho de 2011.

WETHERALL, D.; GUTTAG, J.; TENNENHOUSE, D. ANTS: a toolkit for building anddynamically deploying network protocols. In: Open Architectures and Network Program-ming, 1998 IEEE, 1998. Anais. . . [S.l.: s.n.], 1998. p.117–129.

WHITE, J. Mobile Agents White Paper. Disponível em:www.cs.cmu.edu/ rwh/courses/mobile/Telescript/White-Telescript.ps. Acesso: Maiode 2011.

WHITE, K. Definitions of Managed Objects for Remote Ping, Traceroute, and Loo-kup Operations (RFC 2925). [S.l.]: RFC Editor, 2000.

WU, S.; DENG, L.; JIN, H.; SHI, X.; ZHAO, Y.; GAO, W.; ZHANG, J.; PENG, J. VirtualMachine Management Based on Agent Service. In: PARALLEL AND DISTRIBUTEDCOMPUTING, APPLICATIONS AND TECHNOLOGIES (PDCAT), 2010 INTERNA-TIONAL CONFERENCE ON, 2010. Anais. . . [S.l.: s.n.], 2010. p.199 –204.

XEN. What is Xen Hypervisor? Disponível em:http://www.xen.org/files/Marketing/WhatisXen.pdf. Acesso em: Junho de 2011.

XEN. How Does Xen Work? Disponível em:http://www.xen.org/files/Marketing/WhatisXen.pdf. Acesso em: Junho de 2011.

XILINX ISE. Disponível em http://www.xilinx.com/. Acesso em: Maio de 2011.