Relatório ReVir. Programabilidade em Redes Virtualizadas

Transcrição

1 Relatório ReVir Programabilidade em Redes Virtualizadas Julho 2011

2 SUMÁRIO 1 INTRODUÇÃO VIRTUALIZAÇÃO DE REDES DE COMPUTADORES OpenFlow FlowVisor VMWare e VirtualBox Xen LibVirt PROGRAMABILIDADE DE REDES Propostas da Comunidade Científica Redes Ativas Agentes Móveis MIBs DISMAN Tecnologias Disponíveis no Mercado Click Modular Router OpenFlow Juniper Junos SDK Cisco AON NetFPGA CONSIDERAÇÕES FINAIS Propostas da comunidade científica Tecnologias Disponíveis no Mercado REFERÊNCIAS

3 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 construção do conhecimento. Um dos fatores que contribuíram para o sucesso da Internet é a facilidade de implementação aliada ao baixo custo das tecnologias de comunicação mais básicas. Isto permitiu a rápida popularização da Internet e consequentemente a criação de diversas 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 servidores e 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 o núcleo da Internet não operar adequadamente, as aplicações deixarão de funcionar; em uma visão mais simplificada para o usuário, o núcleo da Internet oferece basicamente serviços de conexão. Com o intuito de disponibilizar uma maior gama de funcionalidades e serviços no núcleo da rede, diversas tecnologias e soluções foram propostas no passado, tais como Redes Ativas (TENNENHOUSE et al., 1997), Agentes Móveis (WHITE, 1996) e Script MIB (LEVI; SCHOENWAELDER, 2001). O termo programabilidade de redes (LA- ZAR, 1997) foi cunhado para referenciar a capacidade que os usuários finais de uma rede teriam de programar os dispositivos do núcleo da mesma. Porém, o efetivo emprego de soluções de programabilidade nunca teve apoio dos administradores de rede. Um dos motivos para o insucesso dessas tecnologias deriva-se da falta de garantias convincentes quanto à consistência das configurações aplicadas sobre os dispositivos ao serem programados por usuários finais. Portanto, a programabilidade de redes ainda permanece como um problema em aberto. Nesse contexto, a comunidade científica se vê diante de diversos empecilhos para propor, experimentar e implementar novas arquiteturas e funcionalidades na rede atual. Tais empecilhos são também conhecidos pelo termo ossificação da Internet. Porém, recentemente, tecnologias de virtualização de redes passaram a ser suportadas pelos principais fornecedores de dispositivos de rede, como Cisco (CISCO, 2011a), Juniper (JUNIPER, 2011) e Extreme Networks (NETWORKS, 2011). A virtualização de redes permite que dispositivos 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. As ligações entre os roteadores virtuais formam então redes virtuais rodando acima de redes físicas reais. Uma característica importante da virtualização é o isolamento entre dispositivos lógicos em uma rede física com suporte à virtualização. Um roteador virtual, por exemplo, pode ser criado, deslocado e destruído sem afetar os outros roteadores virtuais existentes.

4 4 O isolamento proporcionado pelas tecnologias para virtualização de redes, e o fato de que a programabilidade de redes ainda é um problema em aberto, são razões que motivam a retomada do desenvolvimento de tecnologias a fim de programar os dispositivos sem afetar o funcionamento normal das redes. Redes com suporte à virtualização já são de fato reais, mas ainda não são programáveis pelos usuários finais. A programabilidade de redes permitirá que inovações na Internet, até então realizadas apenas em sua periferia, possam também acontecer em seu núcleo. Por comparação, se aplicações altamente difundidas na Internet atual, como Skype e BitTorrent, operam apenas com softwares instalados em servidores e computadores pessoais, aplicações inovadoras para uma nova geração da Internet serão criadas a partir do desenvolvimento criativo e seguro, por parte dos usuários finais, de softwares instalados agora também nos próprios dispositivos da rede. Isto possibilita a criação de uma vasta gama de protocolos, aplicações, funcionalidades e novos serviços. Apesar de o tema programabilidade de redes ter gerado, no passado, debates acalorados, acredita-se hoje que a programabilidade é uma solução factível para combater a ossificação da Internet, contribuindo assim para a criação da Internet do Futuro 1. Em tal Internet do Futuro, um núcleo programável por usuários finais permitiria que serviços inovadores pudessem ser criados. Da mesma forma que Twitter e DropBox representam serviços que caracterizam a Internet atual, serviços que programam o núcleo da rede representariam uma Internet de próxima geração. Tal núcleo programável não existe atualmente, portanto vislumbra-se uma relevante oportunidade. Com o objetivo de fornecer uma visão geral sobre pesquisas relacionadas a programabilidade e a virtualização de redes de computadores, no presente relatório do projeto ReVir, apresentamos algumas das principais tecnologias que possibilitam a criação e o gerenciamento de redes virtualizadas. Além disso, são introduzidas as principais soluções, desenvolvidas pela academia ao longo dos anos, bem como as atuais tecnologias disponí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ão das mais relevantes tecnologias de virtualização de redes. No Capítulo 3 são descritas soluções que possibilitam a programabilidade de redes, soluções estas propostas pela comunidade científica bem como disponíveis no mercado. No Capítulo 4 são apresentadas considerações finais deste relatório. 1 De fato, a tradução da expressão Future Internet para o português não é consenso. Assim como neste relatório, alguns autores utilizam a expressão Internet do Futuro (MOREIRA et al., 2009). Porém, existem trabalhos que referenciam essa evolução como Futura Internet (CAMILO et al., 2005).

5 5 2 VIRTUALIZAÇÃO DE REDES DE COMPUTADORES A comunidade científica vislumbra na virtualização de redes uma possível alternativa para superar as dificuldades existentes para propor, experimentar e implementar novas funcionalidades e soluções para a Internet do Futuro. Estas dificuldades se concentram, em sua maioria, nos problemas de manutenção da rede, uma vez que pra cada implantação de uma técnica ou proposta, uma nova configuraçã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 vez que a rede não é exclusiva para testes. Ou seja, é preciso criar uma camada isolada para o tratamento 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 como uma plataforma de rede que permite a manipulação de sub-redes lógicas, ou seja, permite criar, adicionar, mover e alterar redes virtuais. Tais tarefas de manipulação das redes virtuais são realizadas em software e não dependem de aquisição de equipamentos reais como acontece em redes convencionais, o que economiza tempo e custos. Uma rede física com suporte a virtualização é assim segmentada em várias redes lógicas baseadas nas 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 supracitados, oferece uma série de benefícios que tratam de alguns aspectos físicos e teóricos fundamentais 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 recursos fí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 rede física, sem comprometer a operação da mesma e sem interferir nos serviços virtuais que já existem nessas redes. Flexibilidade e disponibilidade - Um dispositivo virtual deve poder ser criado, deslocado e removido sem afetar os outros roteadores virtuais existentes. Isto permite que, ao ocorrer um problema no hardware ou simplesmente uma sobrecarga na rede, os dispositivos virtuais possam migrar, de forma transparente para o usuário final, entre os equipamentos físicos disponíveis, de acordo com políticas definidas pelos administradores. Escalabilidade - Os roteadores virtuais podem inicialmente agrupar funcionalidades simplificadas e, à medida que novas demandas vão surgindo, outras características

6 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 compartilhado por várias redes virtuais, reduzindo assim a necessidade de se adquirir equipamentos 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 um ambiente 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 as redes virtuais é chamada de substrato. Os roteadores virtuais são geralmente conectados entre si através de túneis IP, o que permite a utilização de implementações de protocolos de aplicação, transporte, algoritmos de roteamento e outras características presentes na Internet atual (TOUCH et al., 2003). A rede virtual é uma rede completa, pois conta com todos os elementos que compõem uma rede real, i.e., roteadores, hosts e enlaces. Além disso, a virtualização permite que vários componentes físicos possam participar de múltiplas redes virtuais, bem como uma rede virtual possa ser construída sobre outra rede virtual. Isto traz flexibilidade e possibilita a criação de arquiteturas de rede avançadas sem interferir de forma significativa nos equipamentos físicos. 2.1 OpenFlow Baseado na manipulação de tabelas de fluxo em switches Ethernet, o OpenFlow vem recebendo muita atenção da comunidade científica. O grupo Internet2 mantém alguns projetos nesta área e é apoiado por diversas grandes companhias, como Facebook, Google, Microsoft, Verizon, Yahoo!, Broadcom, Cisco, Dell, Ericsson, Extreme Networks, HP, IBM, Intel, as quais, em conjunto, formaram uma organização sem fins lucrativos chamada ONF (Open Network Foundation) (INTERNET2, 2011). Esta organização é dedicada a promover uma nova abordagem para a área de redes, marcada pela utilização de Redes Definidas por Software (do inglês, Software Defined Network). O OpenFlow tem papel fundamental neste cenário.

7 7 Os roteadores e switches mais recentes são constituídos de duas partes distintas: o plano de controle e o plano de dados (INTERNET2, 2011). O plano de controle é formado pelos protocolos de roteamento, enquanto o plano de dados realiza o encaminhamento dos pacotes. O OpenFlow, diferentemente dos softwares proprietários e restritos aos fabricantes de dispositivos de rede, apresenta-se como uma alternativa gratuita, de código aberto e generalizada para fazer a integração destes planos. Tal integração é realizada de maneira simples e elegante. O OpenFlow define um protocolo de comunicação para ser utilizado entre switches e uma entidade externa, comumente chamada de controlador. A comunicação entre switches e controlador possibilita, junto ao controlador, a manipulação das tabelas de encaminhamento do plano de dados do switch. O fato do controlador estar externamente localizado, representado geralmente por um computador simples, possibilita uma visão geral 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 de regras de encaminhamento de pacotes. Cada pacote que passa por um switch OpenFlow pode se adequar a uma determinada regra ou não, dependendo de alguns fatores definidos em 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 de origem/destino, enfim, todos os campos contidos no cabeçalho dos pacotes. Uma vez detectados os possíveis pacotes alvos, são definidas ações, que tipicamente consistem em descartar, encaminhar para uma porta específica, ou modificar algum parâmetro do cabeçalho. O enfoque das ações oferecidas pelo OpenFlow é obviamente direcionado para o próprio cenário controlado. Entretanto, nada impede o controlador de tomar ações fora deste escopo FlowVisor O OpenFlow oferece um conjunto de ferramentas para conectar um controlador a um conjunto de dispositivos físicos ou simulados. Neste cenário, é possível que se tenha mais de um controlador, ou seja, o sistema pode acoplar diversos usuários, cada qual com sua implementaçã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, topologia, tráfego, CPU e tabelas de fluxo dos switches envolvidos na rede experimental e controlados pelo protocolo OpenFlow, de maneira que se mantenham garantias pra cada usuário/controlador. Pode-se considerar o FlowVisor como um moderador que utiliza o Openflow como protocolo padrão de comunicação entre os dispositivos físicos e os controladores. Nesta camada, ele possibilita o controle dos fluxos de acordo com uma política de utilização do dispositivo, ou seja, dado um comando de inserção de regra de fluxo em um determinado dispositivo, 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ísica compatível. Uma vez que foi gerado um evento no dispositivo, este evento é comparado com os interesses cadastrados e o evento é encaminhado então somente para os usuários interessados. Conforme podemos analisar na Figura 2.2, o controlador do Doug tem controle de uma rede com apenas um nó físico (switch), enquanto Alice consegue visualizar e controlar quatro. É possível, a partir da virtualização de instâncias diferentes do FlowVisor, o

8 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 e Cathy 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 maneira 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 independente de diferentes tipos de fluxos, ou seja, pode-se ter controladores dedicados a tratar fluxos de 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, a partir do FlowVisor é possível instanciar diversas redes virtuais sobre um mesmo substrato físico. Sendo assim, o isolamento neste caso trata de manter os recursos reservados para cada slice, de maneira que seus respectivos controladores funcionem independentemente e 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 camada física da rede. Como consequência desta característica, o controle do usuário pode ser mantido sob uma rede virtual da mesma forma que sob uma rede real, ou seja, todo o controle 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, com pouca configuração. Ambas viabilizam ao usuário a instalação e execução de sistemas operacionais em ambiente virtualizado, além de oferecer diversas funcionalidades e ferramentas adicionais que variam de acordo com a versão do software escolhida e, consequentemente, da licença adquirida. O VMWare (VMWARE, 2009) consiste em um software de virtualização desenvol-

9 9 vido pela VMWare Inc. e é distribuído em versões gratuitas, com recursos limitados, e versões comerciais, com recursos adicionais ativos. Algumas versões são baseadas em monitores clássicos, como VMWare ESX e VMWare ESXi, e outras em monitores incorporados, como VMWare Player e VMWare Workstation. Enquanto a versão Workstation fornece as principais funcionalidades para um sistema de virtualização, como criar, modificar e executar uma máquina virtual, a versão Player permite apenas executar máquinas virtuais, sem as demais funcionalidades. Ambas 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 desenvolvido pela Oracle que oferece uma versão sob licença GPL (GNU General Public Licence) e uma versão comercial com algumas funcionalidades extras. O VirtualBox não necessita de 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 rede fornecendo um ambiente com dispositivos de rede (switches e roteadores) virtuais, que quando conectados por meio de configurações, formam uma rede virtual. Essa rede pode ser utilizada para diversos propósitos, como representar topologias que servirão de base para simulações ou definir uma réplica virtual de uma rede real. Esta última estratégia foi utilizada no projeto RouteFlow (NASCIMENTO et al., 2011). No que se refere ao projeto RouteFlow, esse apresenta uma aplicação que gera uma rede virtualizada a partir da análise da topologia de uma rede real. Desta forma, diferentes tipos de protocolos e soluções podem executar em nível virtual, mantendo a camada física apenas como infraestrutura de comunicação. Isto é feito através da virtualização de sistemas operacionais de dispositivos de rede reais ou sistemas genéricos de roteamento tais como Quagga (GNU QUAGGA PROJECT, 2006) e Vyatta (VYATTA PROJECT, 2010). Como auxílio a este tipo de estratégia, existem diversos aplicativos que facilitam o planejamento e programação dos dispositivos virtualizados. Alguns deles utilizam interfaces gráficas para auxiliar a construção dos projetos, o que permite ao projetista desenhar a arquitetura e programar os nós de forma visual e simplificada. O GNS3 é um programa opensource que utiliza o Qemu (QEMU, 2011) um aplicativo opensource genérico para virtualizaçã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 é novidade, além de ser uma funcionalidade facilmente suportada pelos computadores atuais. Entretanto, manter os sistemas virtuais totalmente isolados, suportar a heterogeneidade dos sistemas operacionais e minimizar o impacto no desempenho ainda continuam sendo grandes desafios. O Xen é um monitor de máquinas virtuais que permite o compartilhamento de hardware por múltiplos sistemas operacionais virtualizados de maneira balanceada e segura, sem sacrificar o desempenho ou as funcionalidades de cada sistema operacional (BARHAM et al., 2003). Esse projeto foi desenvolvido pela Citrix Tecnologies sob a licença GPL com a ambição de hospedar até 100 máquinas virtuais simultaneamente em um servidor moderno. O objetivo principal do Xen é retirar dos administradores a responsabilidade de manter eficientemente um controle sobre o desempenho de cada Máquina Virtual Virtual

10 10 Machine (VM) o que exige o gerenciamento manual dos recursos de armazenamento e processamento. 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 de recursos pra cada um deles, entretanto esta abordagem implicaria uma em uma sobrecarga de gerenciamento que impactariam no desempenho da virtualização. (ii) o Xen usa uma abordagem de multiplexação de recursos de hardware em um nível de granularidade de um sistema operacional, o que permite fazer o isolamento de desempenho por sistema operacional e não por processos. Sendo assim, o acesso aos recursos de hardware por cada sistema operacional seria multiplexado de acordo com as políticas definidas pelo administrador. O nível de virtualização pode ser definido por dois modelos: a virtualização completa e 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 operacional do visitante. Entretanto, é necessário hardware com suporte à virtualização (Intel-VT ou AMD-V). Já a paravirtualização exige que os sistemas operacionais visitantes sejam adaptados de tal forma que as requisições de recursos de hardware sejam direcionadas ao Xen e não ao hardware. Desta forma, o Xen faz o devido controle do acesso repassando ao hardware requisitado apenas a demanda que julgar pertinente. O Xen suporta ambos modelos, embora se refira à virtualização completa com outro termo: 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 do Domain 0, uma abstração do sistema operacional hospedeiro, o qual possui privilégios de acesso ao hardware e a responsabilidade de controlar os Domain Us, abstração do sistema operacional dos visitantes (XEN, 2011b). O Domain 0 possui uma implementação de kernel 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 ferramentas que permitem o gerenciamento remoto de um conjunto de VMs, entretanto, este controle é feito de forma indireta, intermediada por algum hypervisor compatível com essa biblioteca (WU et al., 2010). O hypervisor tem o papel de efetivamente executar os comandos gerados pela plataforma de gerenciamento oferecida pela Libvirt, possibilitando, entre outros, a criação, exclusão, alteração e o monitoramento das VMs. O hypervisor e outras entidades envolvidas neste ambiente estão representadas na Figura 2.3: Domínio Domínio Domínio Nó Hypervisor Figura 2.3: Ilustração dos componentes de um nó gerenciado pelo Libvirt (THE VIRTU- ALIZATION API, 2011).

11 11 Nó - Uma máquina física única. Hypervisor - Uma camada de software que permite a execução de múltiplas máquinas virtuais Virtual Machine (VM) em um único nó, tratando de toda heterogeneidade referente às configurações que podem diferir de VM para VM bem como para o próprio hospedeiro. Domínio - Uma instância de um sistema operacional rodando em uma máquina virtual. Uma vez definidas as entidades, pode-se dizer que o Libvirt é uma API que tem como objetivo 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ção com diversos tipos de hypervisors, uma vez que as VMs são controladas por esta entidade, 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 mesmas operações de controle, mas caso alguma específica seja realmente necessária para o gerenciamento de um certo domínio, implementá-la pode ser uma boa medida, uma vez que múltiplos nós podem ser acessados simultaneamente de forma que esta operação pode acabar sendo útil também em um outro nó. Algumas operações aplicáveis aos próprios nós também estão no escopo do Libvirt, como definição de interfaces, gerência de regras de 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 que está o programa gerenciador baseado na Libvirt, por este motivo a Libvirt suporta acesso remoto. Entretanto esta funcionalidade deve ser utilizada em conjunto com protocolos seguros 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 encontrar diversas adaptações para utilização em outras linguagens de programação, como Java, Ruby, Python, C#, PHP e Perl.

12 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 capacidade pode ser importante, pois permite que novas funcionalidades e serviços (e.g., novos protocolos, sistemas de monitoramento, entre outros) sejam implementados sem a necessidade 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 inovadores possam ser criados pelos usuários da rede, criando assim um núcleo de rede programável, núcleo este que não existe hoje em dia. Atualmente, a comunidade científica têm se voltado para o desenvolvimento de novas tecnologias que facilitam a introdução de novos serviços, protocolos e arquiteturas na rede. Desde a década de 1990, muitos trabalhos foram desenvolvidos visando permitir que as redes sejam em algum programáveis. Exemplos de tais trabalhos são Redes Ativas (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 de garantias quanto a consistência das configurações aplicadas sobre os dispositivos ao serem programados por usuários finais; e (ii) o elevado custo por parte dos ISPs (Internet Service Providers) para a constante substituição de dispositivos compatíveis com as tecnologias desenvolvidas. No entanto, através da virtualização, que vem sendo gradativamente suportada nos dispositivos de redes mais modernos, a substituição dos equipamentos ocorre apenas de forma virtual, permitindo a implementação de novas tecnologias desenvolvidas sem 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 programabilidade de rede. Na Subseção são apresentadas as Redes Ativas. Na Subseção são apresentados os Agentes Móveis. A Script MIB é apresentada na Subseção Encerra a Seção a Subseção 3.2.2, onde são apresentados os aspectos de prgramabilidade do OpenFlow Redes Ativas Tradicionalmente o principal objetivo de uma rede IP é entregar pacotes de um ponto a outro, examinando o endereço de destino presente no cabeçalho do pacote e, após utilizar as tabelas de roteamento, decidir para qual vizinho deve repassar o pacote. Ainda podem realizar outras operações como controle do congestionamento da rede e correção

13 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 que pode ser chamada de passiva. Muitos problemas são facilmente identificados em redes passivas, tais como a dificuldade de introduzir novas tecnologias e serviços na infraestrutura de rede (também chamada de ossificação), redução no desempenho e operações redundantes na camada de rede (PSOUNIS, 1999). Durante discussões sobre o futuro das redes na DARPA (Defense Advanced Research Projects Agency), em meados da década de 1990, foi construído o conceito das chamadas redes 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ções customizadas no fluxo das mensagens. Essas ações podem ser implementadas pelos administradores da rede ou até pelos usuários da rede ativa, que podem construir soluções para 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 é composta por hosts inteligentes nas bordas, que podem realizar computações na camada de aplicação, e roteadores simples, que fazem a ligação entre os hosts mas que só conseguem realizar computações na camada de rede. Já uma rede ativa é uma rede que permite também aos roteadores realizarem computações na camada de aplicação, além de permitirem aos 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 pacotes ativos para diferenciá-los dos pacotes tradicionais (PSOUNIS, 1999). O principal problema da rede está associado à segurança, uma vez que é possível a programação e execução de aplicações nos nodos da rede. As ameaças de segurança atreladas a essa característica são enormes, e grande parte dos fabricantes optaram por não dar suporte às redes ativas, impedindo que elas fossem amplamente implementadas na 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) e arquitetura híbrida (SECURE ARCHITECTURES WITH ACTIVE NETWORKS, 2006) (ou mista), descritas a seguir. Arquitetura de Pacotes Ativos os pacotes transmitidos, além dos dados, possuem código que é executado nos nodos. Os nodos, por sua vez, apenas fornecem a possibilidade de realizar a computação dos pacotes. Apesar de ser flexível, por questões de segurança, é exigido que os pacotes sejam autenticados, o que acaba tendo um impacto no seu desempenho. Esses pacotes com códigos executáveis podem também ser chamados de cápsulas (TENNENHOUSE et al., 1997). Arquitetura de Nodos Ativos os serviços e programas estão presentes apenas nos nodos e não mais nos pacotes, que por sua vez carregam apenas referências e parâ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 se comparada à arquitetura de pacotes ativos. Tennenhouse chamou essa arquitetura de switches programáveis (TENNENHOUSE et al., 1997). Arquitetura Híbrida essa abordagem une as características da arquitetura de pacotes ativos e da arquitetura de nodos ativos, uma vez que os nodos possuem códigos executáveis, assim como os pacotes também carregam códigos executáveis consigo. O código carregado pelos pacotes é geralmente escrito em uma linguagem

14 14 com objetivos específicos que tem recursos limitados. Se necessário, o programa dos pacotes pode invocar serviços que são realizados pelo nodo, podendo essas ações serem avaliadas por questões de segurança a qualquer momento. Os pesquisadores participantes de projetos da DARPA envolvendo redes ativas optaram por criar um modelo de programação comum. Esse modelo é importante, uma vez que os programas são transmitidos pela rede através de meios de comunicação os mais distintos, 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) existentes em cada nodo da rede e para a alocação de recursos necessários para execução dos programas, 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, é importante que o programa possa ser transmitido e executado no maior número de plataformas possíveis. Para isso, sugeriu-se o uso de linguagens de script para expressar o programa. Outra sugestão seria o uso de uma linguagem intermediária como bytecodes Java, reconhecidos por serem multiplataforma. A terceira sugestão foi a transmissão dos programas executáveis em modo binário. Quanto à proteção, é necessário restringir 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 imprescindíveis, como a possibilidade de: o pacote se auto-manipular (e.g. alterando seu próprio cabeçalho), de fornecer ao pacote acesso ao ambiente do nodo (podendo obter 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 acesso aos 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 as tabelas de roteamento e informações de gerenciamento da rede. A aplicação da tecnologia de redes ativas possibilita o desenvolvimento de novos serviços. Entre as possíveis implementações que potencialmente se beneficiam dessas melhorias podem ser incluídas as descritas por (TENNENHOUSE; WETHERALL, 2002) (PSOUNIS, 1999). Gerenciamento de redes - Atualmente, para monitorar uma rede os nodos podem tanto emitir alarmes sob condições previamente determinadas quanto serem constantemente interrogados sobre seus estados estratégia denominada polling. Com o crescente aumento do tamanho das redes, a quantidade de nodos gerenciados aumenta, o que torna o uso da estratégia polling um problema. Informações redundantes e grande carga de mensagens são fatores que atrapalham as estações gerenciadoras. Usar as redes ativas para realizar o gerenciamento da rede pode diminuir a ocorrência de atrasos, já que poderiam existir diversos centros de gerenciamento dentro da rede, deslocando o ponto de decisão para próximo do nodo que está sendo gerenciado. Tal alteração reduziria o tráfego resultante do processo de polling e a complexidade da rede. Além disso, a inclusão de inteligência nos elementos gerenciados, através de programas implementados nos próprios dispositivos, pode incrementar a agilidade no controle da rede. Dentre outros benefícios, pode-se citar a

15 15 facilidade de alterações nas políticas de administração, filtragem mais eficiente dos dados obtidos de acordo com a necessidade da gerência, e a possibilidade da criação de pacotes de primeiros socorros, que poderiam resolver problemas encontrados nos nodos da rede imediatamente. Firewalls - Implementam filtros que determinam quais pacotes devem passar transparentemente e quais devem ser bloqueados. Entretanto, o firewall exige ser constantemente atualizado para se adequar aos novos protocolos criados. Esse é um problema que pode ser solucionado com o uso das redes ativas, que tornaria essas atualizações mais rápidas e eficientes, já que seria possível às organizações terem liberdade de acesso ao firewall e injetarem módulos atualizados nele. Web proxies ou caching - São desenvolvidos para servir e armazenar temporariamente páginas web. Quanto mais perto de um nodo que deseja acessar essas páginas, mais rápida será a entrega dos dados e a visualização do usuário. Pode-se usar as redes ativas para utilizar um esquema inteligente de caching, onde os pontos de cache são distribuídos de acordo com as necessidades. Multicasting - É grande o potencial futuro de aplicações multimídia. Atrasos na transmissão de streaming podem causar sobrecarga nos servidores devido aos pedidos de retransmissão, além da inconveniente espera do usuário pela chegada dos dados. Uma solução, utilizando redes ativas, permitiria a utilização de um dispositivo de cache desses pacotes em nós intermediários, ou seja, a solicitação de reenvio 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, discreta e mista. Na abordagem integrada, os programas que implementam as aplicações são encapsulados 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 essa abordagem são chamados de cápsulas. Por outro lado, na abordagem discreta, os pacotes transportam apenas identificadores das aplicações (rotinas) que devem ser executadas nos nodos. Nesse caso, as aplicações ativas são instaladas por um esquema de download de código sob demanda. E por fim, a abordagem mista, em que ambas as abordagens são utilizadas, isto é, os programas podem tanto estar encapsulados nos pacotes como também serem instalados via download (TENNENHOUSE; WETHERALL, 2002). Visando permitir a carga e execução de programas nos nós da rede, diversos trabalhos foram conduzidos no contexto de redes ativas. Entre esses trabalhos podem ser citados o projeto SwitchWare (ALEXANDER et al., 1998), o projeto ANTS (Active Node Transfer System) (WETHERALL; GUTTAG; TENNENHOUSE, 1998) e o projeto Smart Packets, descritos a seguir Switchware O projeto Switchware (ALEXANDER et al., 1998) foi criado com o intuito de fornecer uma arquitetura para redes ativas, provendo um balanço entre a flexibilidade de redes programáveis e os requisitos de segurança. O Switchware define uma arquitetura em três camadas: pacotes ativos, extensões ativas (ou switchless) e infraestrutura de roteador ativo. Para compensar a vulnerabilidade intrínseca às redes ativas, são utilizados alguns recursos de segurança e proteção como verificação de integridade, autenticação e

16 16 verificação estática de tipo para a codificação. A arquitetura Switchware foi criada para ser abrangente, isto é, servir aos mais diversos propósitos. No entanto, é uma solução um tanto 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ês camadas da arquitetura Switchware: Pacotes ativos - Os pacotes, no Switchware, carregam programas contendo código e dados, substituindo, respectivamente, o cabeçalho e o payload dos pacotes tradicionais. O código provê as mesmas funcionalidades dos dados de controle de um pacote tradicional, mas com mais flexibilidade, já que permite a interação com o ambiente no qual o pacote percorre, permitindo realizar ações mais complexas e customizadas. Os dados, além das funcionalidades tradicionais do payload, possuem uma estrutura configurável que pode ser usada pelo programa. Como é preciso que 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. Para isso, devem ser feitas chamadas a serviços já presentes no nodo. Extensões ativas (ou switchless)- são executadas exclusivamente nos nodos do sistema. Fornecem serviços requisitados pelos pacotes ativos. Esses serviços podem ser obtidos dinamicamente de fontes confiáveis, de acordo com a necessidade, ou fazerem parte dos recursos nativos do roteador os nodos onde provavelmente as extensões são executadas. Podem ser escritos em qualquer linguagem, já que não precisam 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 duas camadas acima que precisam ser dinamicamente flexíveis possam ser construídas. Apesar das primeiras camadas proverem segurança em algum nível, é impossível garantir que continuem sendo inseguro se os códigos forem carregados em um ambiente inseguro. Dentre algumas das ações do roteador ativo estão o controle de níveis de acesso, controle de prioridades e o agendamento de recursos do sistema ANTS O projeto de pesquisa ANTS (Active Node Transfer System) (WETHERALL; GUT- TAG; TENNENHOUSE, 1998) é basicamente um toolkit de redes ativas, que permite a implantação de novos protocolos nos nodos intermediários e nos sistemas finais. Ao desenvolverem o ANTS, os autores tiveram três objetivos: o suporte a vários protocolos de rede diferentes que disponibilizam distintos tipos de serviços; a arquitetura deveria permitir a construção de novos protocolos; e deveria permitir que os novos protocolos fossem disponibilizados dinamicamente, já que não há como desconectar pedaços da rede para que sejam atualizadas. Para alcançar cada um desses objetivos, a arquitetura do ANTS utilizou os seguintes componentes-chave: cápsulas, nodos ativos e distribuição de código.

17 17 Cápsulas - substituem os pacotes de uma rede tradicional. As cápsulas levam consigo as referências para as rotinas que devem ser utilizadas pelos nodos ativos para o processamento da cápsula. Algumas dessas rotinas são bem-conhecidas, havendo garantia de disponibilidade dessas rotinas nos nodos ativos da rede. Caso o nodo desconheça a rotina, ela é transferida de alguma fonte segura, que garante que a implementação é correta. Ao conjunto de cápsulas e suas rotinas, transferidas como uma unidade pelos nodos, dá-se o nome de grupo de código (code group). O conjunto de grupos de códigos relacionados e tratados como uma única unidade segura são chamados de protocolo. Nodos ativos - substituem os roteadores e nodos das redes tradicionais. Os nodos ativos executam as rotinas apontadas pelas cápsulas. São os responsáveis pela integridade das ações. Algumas das primitivas existentes nos nodos ativos são o acesso ao ambiente (dados como horário local, tabelas de roteamento, etc), manipulação das cápsulas, controle das operações (permitir, por exemplo, que cápsulas criem outras cápsulas e que repassem, copiem ou descartem a si mesmas) e armazenamento de dados por um curto período. Outras ações podem ser incluídas através da distribuição dinâmica de código quando necessário. Distribuição de código - mecanismo que garante que uma rotina seja automática e dinamicamente transferida para o nodo que dela necessita. Quando uma cápsula chega ao nodo, é verificado na cache desse nodo se ele possui o código necessário para a execução das rotinas contidas na cápsula. Caso não possua, é feita uma solicitação do código ao nodo anterior que enviou a cápsula. Enquanto isso, a execução da cápsula é suspensa. O nodo anterior recebe a solicitação do código e envia. Quando o nodo recebe a informação, a cápsula volta a ser executada. Além disso, esse novo código é incorporado pelo nodo à sua cache para futuras execuções Smart Packets O projeto Smart Packets (SCHWARTZ et al., 1999) é focado no uso de redes ativas para o gerenciamento das redes. Esta solução melhora o gerenciamento de redes complexas das seguintes maneiras: (i) movendo as decisões de gerenciamento para pontos da rede mais próximos dos nodos sendo gerenciados; (ii) sendo mais objetivo a que tipo de informação será obtida do nodo, evitando o uso de coletas exaustivas de dados devido ao polling e (iii) abstraindo os conceitos de gerenciamento para e construindo-os com linguagem de programação, tornando o controle da rede mais ágil. Duas importantes decisões foram feitas no projeto: os pacotes (chamados de smart packets) deveriam conter todo o programa, evitando que dados fossem armazenados nos nodos da rede, o que é custoso e gera problemas de gerenciamento e consistência. Dessa forma, a linguagem de programação para os smart packets deveria produzir programas com 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 executados 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, chamada Sprocket. As duas linguagens são equivalentes, uma vez que um programa feito em sprocket gera um código assembly em Spanner que, por sua vez, é transformada em um código binário independente da máquina em que é executada. A linguagem Java, que

18 18 também possui essa característica de gerar um código intermediário que funciona em diferentes sistemas, foi rejeitado por gerar código muito grande, extrapolando o limite de 1 Kbyte exigido. Os smart packets são encapsulados dentro do ANEP (Active Network Encapsulation Protocol) que, por sua vez, é encapsulado em um pacote IP. Dessa forma, é garantido que o pacote possa circular pelos nodos da rede ainda que eles não sejam ativos ou não estejam prontos para executar os smart packets. O cabeçalho do endereço IP é checado, assim como uma opção do IP chamada Router Alert, que indica se o roteador deve examinar o conteúdo do datagrama em busca de códigos executáveis. Caso essa opção esteja assinalada e o roteador suporte redes ativas, ele pode checar a mensagem ANEP no interior do pacote e descobrir se se trata de um smart packet. Se o nodo tiver suporte aos smart packets, pode, então, executar o código contido nele. Antes de executar esse código, o daemon do ANEP contido no nodo autentica e autoriza essa execução. Esse mesmo daemon cria uma nova instância da máquina virtual aonde o código é, então, executado Conclusão das Redes Ativas A pesquisa sobre as redes ativas foi bastante produtiva até o final dos anos Financiadas pela DARPA, diversas instituições investigaram, por alguns anos, como transformar a Internet em um ambiente ainda mais dinâmico e menos ossificado. Foram criados diversos sistemas, promissores na época, mas que não convenceram os fabricantes a adicioná-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 e dinâmico para execuções de programas nos pacotes. O problema dessa solução, o mesmo do ANTS, é quanto à segurança: seria necessário confiar na honestidade dos autores dos códigos executáveis. Seria necessário certificar desenvolvedores confiáveis dos quais pudessem 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ém códigos executáveis, apenas referências para funções que estão implementadas nos nodos. Caso essas funções não estejam presentes, o ANTS tem um sistema de distribuição de códigos. O projeto Smart Packets, apesar de ter sido construído especificamente para o gerenciamento das redes, usa alguns conceitos que podem ser úteis no futuro, principalmente o uso de redes virtuais para a execução dos pacotes com códigos. O forma que o encapsulamento é realizado no Smart Packets pode acabar mantendo o correto funcionamento dos pacotes mesmo nas redes legadas. Assim, haveria a possibilidade da coexistência de protocolos antigos e nodos desatualizados com a flexibilidade das redes ativas e nodos que suportem esse tipo de rede Agentes Móveis Agentes móveis são agentes que podem trafegar fisicamente por uma rede, executando tarefas nas máquinas que têm capacidade de executá-los (LANGE; OSHIMA, 1999). Os agentes móveis podem carregar para o novo ambiente de execução tanto os dados quanto o estado de execução em que parou no último host da rede, sendo possível continuar essa execução do exato ponto aonde havia parado. Segundo (GRAY et al., 1997), os agentes mó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 alguma operação no servidor ou mesmo enviar um subprograma para o servidor. Uma das dificuldades dos agentes móveis é seu funcionamento em um ambiente muito heterogêneo quanto a Internet. Os programas podem ser escritos em uma linguagem de

19 19 máquina ou serem interpretadas, por exemplo, por uma máquina virtual, que seria a solução preferível para esse problema (CHESS; HARRISON; KERSHENBAUM, 1997). Apesar de terem desempenho inferior, a utilização de ambientes virtuais traz mais segurança ao ambiente. Essa segurança se deve ao fato de que que estariam explícitos para o desenvolvedor todos os recursos disponíveis, evitando acessos indevidos. Segundo Lange e Oshima, o uso apropriado de agentes móveis para a criação de sistemas distribuídos possibilita diversos benefícios, entre eles é válido observar os apontados por (LANGE; OSHIMA, 1999) e descritos em seguida. Redução no tráfego da rede - Agentes móveis permitem mover a computação para onde o dado se encontra e não o dado para o local onde é feita a computação. Sistemas distribuídos podem depender de muitas interações para realizar uma determinada tarefa, resultando em um elevado tráfego na rede, já que em muitos casos o custo de transmitir o código que será executado é menor do que o custo para transmitir os dados da fonte até o nodo. Invertendo essa lógica, ou seja, realizando a computação diretamente onde os dados se encontram, o tráfego na rede pode ser reduzido. Superação da latência da rede - Sistemas de tempo real, tais como robôs em processos de produção, necessitam responder em tempo real às mudanças do ambiente. Controlar tais sistemas através de redes substancialmente grandes envolve latências que 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 executando instruções nos próprios dispositivos. Encapsulamento de protocolos - Sistemas distribuídos podem realizar muitas trocas de dados. Para realizar tal tarefa, cada host possui o código que implementa os protocolos necessários para envio e recebimento de dados. Porém, a atualização do código dos protocolos para acrescentar novos requisitos como, por exemplo, maior eficiência ou segurança, se torna praticamente impossível de ser realizada corretamente em um ambiente tão grande como a Internet. Ao utilizar agentes móveis, podem ser criados canais baseados em protocolos proprietários a fim de realizar tal operação. Execução assíncrona e autônoma - A maioria dos dispositivos móveis dependem de conexões de rede caras ou frágeis. Tarefas que exijam uma conexão contínua entre um 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 assincronamente e autonomamente em relação ao dispositivo que os criou, sendo possível que o dispositivo esteja até mesmo inativo. Adaptação dinâmica - Agentes móveis podem perceber o ambiente de execução em que se encontram e, autonomamente, conseguem reagir às mudanças. Múltiplos agentes móveis têm ainda a capacidade de se espalharem pela rede para manter uma configuração ótima no processo de resolução de um problema. Heterogeneidade - Redes de computadores são fundamentalmente heterogêneas tanto do ponto de vista de hardware quanto de software. Por serem independentes da camada de transporte e da máquina em que são executados (os agentes móveis

20 20 são dependentes somente de seu ambiente de execução), os agentes móveis fornecem condições para a integração destes sistemas. Robustez e tolerância à falhas - Agentes móveis podem reagir dinamicamente a situações adversas. Ao ser detectado algum problema em um dispositivo, os agentes móveis hospedados podem migrar para outro host da rede, permitindo a continuidade da execução. O paradigma dos agentes móveis foi inicialmente proposto no projeto chamado Telescript, que será descrito a seguir. Além dele, também serão comentadas outras duas implementações, os Aglets e o µcode 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 compreende os comandos carregados pelo agente móvel e os protocolos que permitem a troca de agentes entre diferentes máquinas. A linguagem de programação do Telescript pode ser usada para o desenvolvimento de um programa completo. Apesar disso, a linguagem C também pode ser usada no desenvolvimento dos agentes móveis. Dentre algumas caracterí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 similares às lojas de um shopping que permite a entrada de clientes. Agentes - O Telescript modela a comunicação como uma coleção de agentes. Cada agente ocupa um determinado lugar, sendo seu representante e provendo os serviços aos agentes móveis. Como exemplos, um lugar bilheteria, onde há um agente fixo nesse 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ário até o lugar bilheteria e comprar ingressos, retornando ao ponto de saída inicial após concluído o objetivo. Encontros - O Telescript permite que dois agentes em um mesmo lugar se comuniquem, 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 dessa forma encontra o agente de um lugar e pode usar seus serviços. Mas, o sistema també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óvel usado. 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 21 um espetáculo e se comunicar com um agente na casa do usuário enviando quais os lugares ainda livres. O agente, na casa, exibiria essa informação ao usuário, que selecionaria os lugares os quais, posteriormente, seriam enviados ao agente no lugar bilheteria. Autoridades - A autoridade, no ambiente eletrônico, é o indivíduo ou organização no mundo físico que representa o agente móvel. Um agente ou um lugar conseguem saber a informação de qual a autoridade uns dos outros. Isso acontece por questõ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ção adequada essa ação será realizada. Permissões - Permite que as autoridades limitem as ações de um agente ou de um lugar através de permissões Aglets O Aglets é uma biblioteca desenvolvida em Java. Implementada inicialmente por Mitsuro 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 Oshima and Danny Lange, 2004), além de ser bastante utilizado para pesquisas envolvendo agentes móveis. Por utilizar a linguagem Java, amplamente difundida, não exige uma grande curva de aprendizado para ser utilizada. Além disso, a linguagem é poderosa e pode ser executada nos mais distintos dispositivos, mesmo em ambientes com sistemas completamente diferentes, justamente pela geração dos bytecodes. Assim como os applets, os aglets devem estar instalados em todos os hosts da rede em que serão executados. Cada host 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 seu uso. 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ém as variáveis internas, métodos e interface de comunicação com o ambiente em que se encontra. Esse núcleo é encapsulado por um proxy, que age como um escudo para proteger o aglet de qualquer tentativa de acesso direto aos métodos ou variáveis, escondendo também a localização real do aglet µcode É uma pequena API desenvolvida em Java. Desenvolvida por Gian Pietro Picco e distribuída gratuitamente (Gian Pietro Picco, 2000), o próprio autor não considera o µcode como 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 argumento usado para não implementar mais uma biblioteca de agentes móveis foi que a realocação de toda uma unidade do agente móvel não seria sempre necessária nem desejada, sendo muitas vezes melhor ter uma glanularidade mais fina quanto à mobilidade, por exemplo uma 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ção completa de um sistema, há pacotes adicionais que provêm diferentes funcionalidades

22 22 para o µcode, como serviços avançados de comunicação para agentes móveis. Com essa abordagem mais simples, o µcode é de leve execução Conclusão de Agentes Móveis Os agentes móveis, diferentemente das redes ativas, têm sido maior alvo de pesquisas recentemente. Apesar de ainda não ser utilizado amplamente pelas mesmas questões de seguranç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 ponto importante é a evolução tecnológica da última década, que lançou no mercado diversos componentes 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 encaixam perfeitamente nesta necessidade. Essa, aliás, foi uma das conclusões de (CHESS; HARRISON; KERSHENBAUM, 1997), os quais afirmam que os agentes móveis teriam nichos 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 de 1990, que tem a vantagem de ser uma linguagem multiplataforma, capaz de ser executado nos mais diferentes sistemas. Outro ponto positivo para as redes ativas é a existência de diversas bibliotecas bastante utilizadas MIBs DISMAN Ao longo dos anos, as redes de computadores e seus recursos tornaram-se de fundamental importância para as organizações. Muitos dos serviços prestados dependem drasticamente da rede. Neste cenário, uma correta operação da rede é um requisito básico para os negócios das empresas. Para tanto monitorar e controlar os dispositivos que compõem a rede é fundamental. Tais funções são desempenhadas pela gerência de redes que visa o funcionamento contínuo da rede, assegurando assim um elevado grau de qualidade dos 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 atividades de gerenciamento, ou seja, ele transmite operações de gerenciamento (actions) aos agentes e recebe notificações (events) destes. Além disso, serve como interface para o gerente humano em um sistema de gerenciamento de rede. Agente - um processo que executa associado a um recurso, elemento ou sistema gerenciado. Esse processo responde às solicitações de informações e de ações do gerente e, deve também prover assincronamente informações importantes que não foram previamente solicitadas, informações que são transmitidas em alarmes. MIB (Management Information Base) - um conjunto de objetos gerenciados, que procura abranger todas as informações necessárias para a gerência da rede, permitindo a automatização de grande parte das tarefas. Cada objeto gerenciado é uma visão abstrata de um recurso real do sistema. Assim, todos os recursos da rede que devem ser gerenciados são modelados, e as estruturas dos dados resultantes são os objetos gerenciados. Os objetos gerenciados podem ter permissões para serem lidos ou alterados, sendo que cada leitura representará o estado real do recurso e, cada alteraçã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 23 No entanto, com o crescimento da complexidade e do tamanho das redes, o modelo centralizado apresentou algumas deficiências importantes, como por exemplo, a falta de escalabilidade 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 grupo de trabalho que foi designado por DISMAN (Distributed Management). Entre os principais 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 de componentes. Visando estes objetivos, os esforços do grupo de trabalho DISMAN resultaram em algumas RFCs (Request for Comments) que versam sobre o gerenciamento distribuído, entre elas a RFC 2981 (Event MIB), RFC 2982 (Expression MIB), RFC 4560 (Remote Operations MIB), RFC 3231 (Schedule MIB) e RFC 3165 (Script MIB), descritas a seguir RFC Event MIB O envio de notificações indicando alguma falha ou indício de que algo não está funcionando corretamente é importante para o gerenciamento de uma rede. A concepção original 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ão foi autenticada; LinkDown que indica que a comunicação com a rede deste dispositivo falhou, entre outras), não permitindo a criação de novas notificações sob demanda. Para solucionar esta limitação foi definida na RFC 2981 (KAVASSERI; STEWART, 2000a), a Event MIB. O principal objetivo desta MIB é permitir o monitoramento de objetos MIB em um sistema local ou remoto, e possibilitar o disparo de ações com base em políticas pré-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 relacionar cada gatilho a um evento. Os eventos determinam o que acontece quando uma condição pré-definida é verificada, que resulta no envio de uma notificação, na alteração do valor de um objeto, ou em ambos. Para cada trigger definida é possível especificar o tipo de teste a 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 tornar presente, ausente ou mudar de valor. Se um evento for acionado quando uma instância de um objeto se tornar presente, esta instância deverá deixar de existir antes que o evento possa ser disparado novamente e vice-versa. Se um evento for acionado devido a uma mudança de valor do objeto, o mesmo evento será acionado no 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 objeto monitorado possua um valor inteiro. São indicados, nos gatilhos, um valor de referência inteiro para ser comparado com o valor do objeto monitorado e a comparação

24 24 a ser executada entre o valor amostrado e o valor de referência, podendo ser diferente, igual, menor, menor ou igual, maior ou maior ou igual. Se o resultado do teste for verdadeiro, um evento será disparado. Este mesmo evento só será disparado novamente 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 a um evento que deverá ser acionado. Se a ação disparada pelo evento pré-definido for uma notificação (trap), o evento deverá possuir informações sobre a notificação a ser realizada. Quando a ação disparada for a alteração de um valor em um objeto, o evento deverá conter informações sobre o valor que deve ser atribuído ao objeto, bem como o identificador deste objeto RFC Expression MIB Definida pela RFC 2982 (KAVASSERI; STEWART, 2000b), a Expression MIB foi desenvolvida com o propósito de permitir que novos objetos sejam definidos a partir de outros já existentes. Esta MIB permite a construção e avaliação de expressões compostas por objetos existentes, expressões simples e/ou expressões encadeadas (que dependam do resultado de outras expressões). Sem a Expression MIB este tipo de operação ficaria limitado aos objetos pré-definidos em outras MIBs. Os resultados destas expressões ficam disponíveis como objetos MIB, podendo ser utilizados por uma aplicação de gerência de maneira direta ou serem referenciados por outra MIB, como a Event MIB. Estes objetos ainda podem ser utilizados pela própria Expression MIB formando expressões mais complexas. Os valores que compõem uma expressã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áveis pode ser retornada em uma das seguintes amostragens: delta - define coletas periódicas dos valores amostrados, além de sempre armazenar o último valor a fim de que este possa ser utilizado no cálculo da diferença entre as duas amostras; absoluta 1 - é simplesmente o valor de um objeto no instante em que ele foi amostrado; booleana - retorna verdadeiro se o valor da amostra atual for diferente do da amostra anterior, 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 usar resultados de outra expressão, desde que a segunda não possua nenhuma variável que seja o resultado direto ou indireto da sua própria avaliação. Os operadores permitidos são delimitadores de escopo, aritméticos, lógicos e relacionais. São suportadas também algumas funções como, por exemplo, a função exists que verifica se uma instância de objeto 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ão expressas como um símbolo dólar ( $ ), seguido de um inteiro, que serve para indexar a variável correspondente. Um exemplo de expressão válida é ($1 * 10 + $2), dado que $1 = e $2 = , onde o valor obtido do objeto MIB OID é multiplicado por 10 e somado ao valor do objeto MIB OID A obtenção das variáveis através desta amostragem não pode ser utilizada para a avaliação de expressões que envolvam contadores, sendo que estes devem ser manipulados como um delta (diferença) entre duas amostras.

25 RFC Remote Operations MIB A Remote Operations MIB permite executar remotamente algumas operações essenciais para o gerenciamento de redes, como os comandos ping, traceroute e lookup. Essas operações permitem ao operador ter uma visão do estado da rede remotamente. Por serem extremamente necessárias, diversas empresas fizeram diferentes implementações de MIBs específicas para a realização destas operações. Neste contexto, a RFC 2925, obsoleta pela RFC 4560, surgiu com o objetivo de definir um padrão para tais operações visando a interoperabilidade entre as diversas MIBs implementadas (WHITE, 2000) (QUITTEK; WHITE, 2006) RFC Schedule MIB Nas atividades de monitoração e controle de redes, executar operações periódicas ou em determinados instantes é de fundamental importância. Observando tal necessidade, foi definida na RFC 2591 (LEVI; SCHOENWAELDER, 1999a), tornada obsoleta pela RFC 3231 (LEVI; SCHOENWAELDER, 2002), a Schedule MIB, que apresenta um conjunto de objetos que possibilitam agendar operações de escrita SNMP (set) sobre objetos locais do tipo inteiro. A Schedule MIB contém um repositório onde armazena os instantes definidos pelo operador, o identificador OID do objeto sobre o qual vai atuar e o valor que deve ser associado. Ao constatar que uma operação agendada deve ser executada, dispara então uma 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 por um 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 RFC Script MIB Proposta na RFC 2592 (LEVI; SCHOENWAELDER, 1999b) e posteriormente na RFC 3165 (LEVI; SCHOENWAELDER, 2001), a Script MIB apresenta um conjunto de 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 qualquer linguagem de programação, compilada ou interpretada, desde que esta esteja suportada pela Script MIB (SCHONWALDER; QUITTEK; KAPPLER, 2000). Após instalado o script nos nós da rede, o gerente poderá, através de uma requisição SNMP (Simple Network 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; e finalizaçã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 26 transferir para o gerente dos resultados produzidos. As operações descritas acima, são realizadas em seis diferentes tabelas que constituem os 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 linha que identifica o script, suas configurações, a linguagem de programação utilizada e outras informações pertinentes para sua criação, manutenção e uso. Esta tabela permite operações como leitura, inserção e deleção de entradas que descrevem os scripts. Existem dois modelos de transferência de scripts para o agente, o primeiro chamado de modelo pull, que requer o envio de uma URL de onde será buscado o 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 do protocolo 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 se faz necessário, para que seja possível a utilização de scripts maiores que o tamanho limite das mensagens SNMP. Além da inclusão de novas linhas, esta tabela também permite a alteração de linhas já existentes, ou seja, é possível utilizar requisições SNMP para modificar os scripts anteriormente transferidos; LanguageTable - contém as linguagens de programação que podem ser utilizadas para a criação dos scripts que serão executados, ou seja, as linguagens que a implementação da Script MIB é capaz de reconhecer/interpretar e executar. Cada entrada nesta tabela apresenta detalhes de linguagens de programação suportadas, como por exemplo, nome, versão e descrição da linguagem; ExtensionTable - apresenta as extensões que a implementação da Script MIB aceita para as linguagens disponíveis. Cada entrada nesta tabela representa uma extensão disponí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ão descritos através da combinação das informações das tabelas LanguageTable e ExtensionTable. 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 as extensões suportadas; LaunchTable - utilizada para a execução e controle dos scripts. Nessa tabela são descritos os ambientes para a execução de cada script, incluindo os parâmetros de entrada, bem como o tempo máximo de execução de cada script. Se um mesmo script necessita ser executado com diferentes parâmetros, ou seja, configurando outro 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, como por 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 possível consultar os resultados obtidos com a sua execução.

27 27 Na Figura 3.1, adaptada de (SCHONWALDER; QUITTEK; KAPPLER, 2000), é apresentada uma implementação de um agente SNMP com suporte a Script MIB, bem como os passos para a execução e controle de um script em um nó da rede. Primeiramente 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á estiver instalado o gerente continua no Passo 4. Para proceder com a instalação do script (Passo 2), o gerente consulta as linguagens de programação disponíveis na tabela LanguageTable (se necessário consulta as extensões instaladas na tabela ExtensionTable, omitida na Figura 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 informações referentes ao script instalado (Passo 3). Neste momento a instalação pode ser realizada através do modelo pull de transferência, onde a URL do repositório é armazenada 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 protocolo SNMP, 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 o ambiente de execução do script (Passo 4). Após realizadas estas etapas, o gerente pode dar início a execução do script. As informações sobre tal execução, bem como os resultados obtidos são armazenados na tabela RunTable e ficam disponíveis por um determinado tempo para a consulta do gerente Considerações Finais O grupo DISMAN surgiu pela necessidade de desenvolver ferramentas que possibilitem o gerenciamento de redes de forma distribuída. De certa forma, ao longo do processo, foram desenvolvidas diversas técnicas que possibilitam implementar inteligência nos dispositivos gerenciados. Dentre estas técnicas a que possui um maior grau de programabilidade é 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 ), gerenciamento de configurações baseado em políticas (MARTINEZ et al., 2002) e detecçã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 ocasionaram a não utilização da Script MIB para prover a programabilidade de redes, dentre elas um dos fatores mais determinantes foi a segurança, pois havia a necessidade de possuir privilégios de administrador para realizar a instalação e execução dos scripts nos dispositivos. 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 de distribuição dos scripts; e a recuperação de resultados obtidos com a execução em locais distribuídos, são algumas características merecem destaque. Outras técnicas também desenvolvidas pelo DISMAN devem ser mencionadas, entre elas a RFC 2981 (Event MIB), a RFC 2982 (Expression MIB), a RFC 4560 (Remote Operations MIB) e a RFC 3231 (Schedule MIB). Essas soluções permitem que novas tarefas 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 uma expressão pré-definida, entre outras. Isoladamente tais técnicas pouco contribuem para efetivamente programar os dispositivos. Entretanto, ao utilizar um conjunto destas técnicas, aliadas a Script MIB, é possível desenvolver aplicações que vislumbrem um maior nível de programabilidade, como por exemplo, executar script pré-definido ao detectar uma determinada falha. 3.2 Tecnologias Disponíveis no Mercado A função mais básica dos roteadores é o encaminhando de pacotes de um ponto a outro. Entretanto, mais recentemente com o amadurecimento da Internet outras funções têm sido atribuídas a estes equipamentos. Citando algumas novas funções assumidas por roteadores, 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 tem se tornado pouco flexível, limitando-se a pequenas atualizações. Neste cenário algumas tecnologias 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 implementando o roteamento por software. Hardware customizado, utilizando hardware customizado para as aplicações, como por exemplo, o NetFPGA (NAOUS et al., 2008). Equipamentos proprietários, utilizando equipamento de prateleira modificados Click Modular Router O Click Modular Router (KOHLER et al., 2000), um roteador baseado em software que implementa através de módulos as funcionalidades de um roteador. Existem diversos trabalhos 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 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 a localização quanto a identificação residem em seu endereço, visando resolver alguns problemas 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, a criação dos túneis e o cache de mapeamento de endereços é realizado em vários módulos Click. O Projeto VRouter tem por objetivo desenvolver uma plataforma para roteadores virtuais baseados em computadores os quais, segundo os autores, seriam capazes de suportar diversas instâncias desses roteadores simultaneamente. Esse projeto utiliza o Click para implementar os roteadores virtuais funcionando sobre um sistema operacional Linux e má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 conectados através de links de alta-velocidade e baixa latência. Nessa proposta foi comprovado que o desempenho de roteadores virtuais é similar a roteadores dedicados além de manter e permitir o desenvolvimento de novas funcionalidades do Click. O Click Modular Router é uma ferramenta utilizada para implementar roteadores de maneira modular. A arquitetura destes roteadores é centrada em pequenos módulos chamados Elementos, que são pequenos blocos de software, escritos na linguagem C++, que implementam operações simples como decrementar o TTL de um pacote. Estes elementos que compõem um roteador são organizados na forma de um grafo, onde os vértices sã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 elementos. O primeiro elemento, denominado FromDevice(eth0), é responsável por encaminhar os 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ável por descartar os pacotes. Os roteadores Click cujas funcionalidades são apresentadas em seguida, podem operar segundo 3 modos distintos, a saber: kernel, UserLevel, simulação. No modo kernel, os pacotes recebidos pelo computador são encaminhados para o roteador Click e não para as interfaces. O roteador Click no modo UserLevel funciona como um processo de usuário. Por fim, no modo Simulação o roteador Click funciona como um módulo do NS-2, chamado NSClick. Um roteador Click operando no modo kernel em um computador com configuração de hardware normal, chega a atingir a taxa de encaminhamento de pacotes de 64 bytes por segundo, mais que alguns roteadores comerciais. Com otimizações efetuadas no hardware esta taxa pode chegar a pacotes por segundo.

30 Elementos Os Elementos, conforme já mencionado, são os módulos centrais dos roteadores Click assim, toda configuração depende de como eles são organizados e implementados. Os elementos 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 deste elemento. 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 pelo menos uma conexão. As portas podem ser de três tipos: pull, push e agnostic. Outra propriedade são as strings ou parâmetros de configuração. As strings ou parâmetros de configuração são opcionais e devem ser utilizados para alterar o estado do elemento. Esses parâmetros são fornecidos no momento da inicialização do roteador. Quanto à interface de métodos, essa interface é composta pelos métodos que cada elemento disponibiliza para uso para os demais elementos. Por fim, handlers são métodos disponibilizados para o usuário, baseados em leitura e escrita simples de texto. Através deles é possível, por exemplo, obter informações dos elementos. Na Figura 3.3 são exibidas as propriedades do elemento Tee. O elemento Tee, de um classe Tee, copia cada pacote recebido em sua porta de entrada e envia uma cópia para cada porta de saída. O parâmetro de configuração da classe Tee está entre parênteses e informa ao elemento que devem ser criadas duas portas de saída. A interface de métodos e 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 elementos prontos para uso cujos códigos-fonte estão disponíveis. Uma forma de criar novos elementos é alterando os códigos-fonte disponíveis dos elementos encontrados nessa biblioteca de elementos. Além disso, como todos os elementos herdam suas característica da classe Element, normalmente poucos métodos precisam ser sobrescritos, não exigindo portanto 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 listagem abaixo é exibida parte do código fonte do elemento ICMP static inline size_t click_icmp_hl(uint8_t icmp_type) { if (icmp_type == ICMP_TSTAMP icmp_type == ICMP_TSTAMPREPLY) return sizeof(click_icmp_tstamp); else return sizeof(click_icmp); }

31 #endif No tocante as conexões, os elementos Click suportam dois tipos: push e pull. As conexões, do tipo push são indicadas para as situações onde o recebimento de pacotes não solicitados é esperado, por exemplo, pacotes provenientes de outros equipamentos para o roteador. As conexões do tipo pull aplicam as situações onde o roteador tem o controle de quando pode transmitir os dados, por exemplo, quando o destinatário estiver disponível. É importante que conexões entre portas pull e push não são permitidas. Nas situações onde é necessário este tipo de conexão as portas do tipo agnostic são utilizadas e 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 armazenado em um elemento que implementa uma fila. Os pacotes são empurrados até a fila por 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 Configuração dos roteadores Os roteadores Click são compostos por elementos que são configurados na forma de um grafo o qual descreve o caminho dos pacotes. Existem basicamente duas diretivas principais 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 definidos para então serem usados e nome1, nome2, nome3 e nome4 são os elementos em si. 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 colocadas antes do nome do elemento atuam como portas de entrada e se colocadas após o mesmo atuam como portas de saída. A conexão entre os elementos e suas portas é feito pelo símbolo ->.

32 32 Em síntese, a força do Click reside na sua modularidade apoiada pela orientação a objetos de sua programação que permite que novos elementos, que implementem as funcionalidades 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 novos pode ser criados Considerações Finais Os seguintes critérios foram utilizados para avaliação do Click no que concerne a programabilidade de rede: aplicabilidade da solução, interoperabilidade/controle de transferência, segurança, infraestrutura de rede e relação da proposta perante a comunidade cientifica quanto a maturidade, atualidade e impacto em relação a outras propostas. No tocante a aplicabilidade, o Click pode ser considerado como sendo abrangente uma vez que ele pode ser utilizado tanto para modificar serviços já disponíveis quanto para criar outros. Adicionalmente, o Click proporciona facilidade quanto ao desenvolvimento de roteadores uma vez que é adotado a linguagem de programação C/C++ a qual é muito difundida 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ção do código e do estado de execução, e se caracteriza pela falta de mecanismos que evitem que problemas na rede causem impacto no roteador, reduzindo assim sua eficiência ou mesmo tornando-o inoperante. Quanto à existência de segurança até o presente momento não foram encontradas referências no que diz respeito a existência de uma estrutura de segurança que possibilite um controle de acesso granularizado, permitindo a crianção de níveis de acesso aos roteadores Click. Quanto à infraestrutura de rede, é importante ressaltar que o custo dos equipamentos necessários para disponibilizar a solução na rede é baixo uma vez que pode ser utilizado hardwares programáveis ou mesmo computadores e que os mesmo precisam utilizar a plataforma 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 projeto original. É relativamente atual, uma vez que sua última versão foi lançada em Por fim, é apoiado pela comunidade científica no sentido que é uma ferramenta gratuita e de código aberto OpenFlow O OpenFlow (MCKEOWN et al., 2008) utiliza a separação dos switches Ethernet modernos em dois planos: plano de controle e plano de dados. O OpenFlow é capaz de alterar o comportamento da rede através de interfaces padronizadas, fornecidas por estes switches para manipulação das tabelas de fluxo no plano de dados, através de um protocolo definido por sua API, e através de ações que atuam sobre o fluxo de pacotes que passa pelo switch. Apesar do OpenFlow ter sido concebido para tratar da separação dos fluxos através de ações associadas definidas pelo fabricante do switch, é possível que com o surgimento de novas ações, a capacidade do OpenFlow de atuar sobre a rede seja ampliada. Por exemplo, Heller et. al. (HELLER et al., 2010) propõem uma aplicação que controla o status das portas dos switches de acordo com a carga sobre os mesmos, ativando assim apenas as portas necessárias, ou seja, em uso. O fato de desligar portas por tal aplicação possibilita reduzir o consumo de energia do switch. O artigo cita inclusive que uma nova ação possí-

33 33 vel seria um mecanismo de controle de energia permitido desligar totalmente os switches quando 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ção funcionando 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 regras que são responsáveis por controlar como o switch tratará o fluxo de dados. De acordo com a regra é associada ao fluxo uma ação. As tabelas de fluxo conforme já mencionado associam 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 ao controlador remoto, representado pelo controlador NOX. Por fim, o protocolo OpenFlow é responsável pela padronização da interface pela qual o controlador se comunica com o switch. Figura 3.5: Switch OpenFlow. Existem dois tipos de switches OpenFlow: habilitados (OpenFlow-Enabled) e os nativos. Os switches OpenFlow habilitados suportam tanto o processamento das camadas 2 e 3 quanto do OpenFlow, enquanto que os nativos ou dedicados suportam apenas o OpenFlow. Os pacotes uma vez localizados nos switches, são tratados de acordo com regras definidas pelo Controlador OpenFlow e armazenadas nas tabelas de fluxo, como pode ser visto na Figura 3.6. Estas regras podem utilizar várias informações do pacote para classificá-los tais como: a porta de entrada, o endereço físico de origem, o VLAN ID, entre outras. Baseando-se nesta classificação são atribuídas ações que devem ser aplicadas aos 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 é encaminhado para uma ou mais portas. Na ação encapsular e encaminhar, o pacote é encapsulado e encaminhado para o Controlador. Tal procedimento é efetuado para que o controlador possa decidir qual ação tomar para este pacote e todos os demais pacotes que possuem as mesmas 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 switches OpenFlow-Enabled existe ainda uma quarta ação, encaminhar para processamento, na qual o pacote é encaminhado para processamento normal do switch sem interação com o

34 34 OpenFlow. Figura 3.6: Funcionamento do OpenFlow. Os switches que suportam essas quatro ações e o formato de cabeçalho do OpenFlow são classificados como Tipo 0. Espera-se que outras ações sejam suportadas, como por exemplo: reescrita do cabeçalho, controle de prioridade, criptografia, entre outras. O conjunto destas novas ações deverá criar uma nova classificação para os switches, a Tipo Considerações Finais Quanto a avaliação do OpenFlow no que concerne a aplicabilidade, pode-se afirmar que o OpenFlow tem uma abrangência relativa uma vez que não é possível criar ou modificar serviços. No OpenFlow é possível apenas atuar sobre o comportamento dos fluxos que passam pelo equipamento e criar novas ações que atuem de maneira mais abrangente nos pacotes e nos switches. Com relação ao custo, o OpenFlow peca por exigir a utilização de equipamentos específicos, que permite o controlador ter acesso à tabelas de fluxos e que seja capaz de suportar as ações sobre os fluxos citadas anteriormente. Além disso, a utilização desses equipamentos também impacta o quesito de suporte à arquitetura existente. Já quanto à facilidade no desenvolvimento e às características de programação, como o OpenFlow apenas especifica como um equipamento que o implementa devem se comportar, especificando também um protocolo de acesso a estes equipamentos, fica a cargo do desenvolvedor como implementar as aplicações, o que na verdade acaba por facilitar e até mesmo reduzir os custos com o desenvolvimento, visto que não é necessário aprender algo novo. Quanto ao critério de eficiência destaca-se a capacidade de separação dos fluxos, isolando portanto as aplicações e impedindo que uma aplicação afete as outras que estejam utilizando o mesmo equipamento. Com relação ao critério segurança, vale ressaltar a capacidade do controlador OpenFlow, de controlar os limites das aplicações quanto à área de 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 desde então, sendo inclusive a base da Global Environment for Network Innovations (GENI),

35 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 o OpenFlow. Por fim, a comunidade científica apoia seu uso uma vez que o OpenFlow é uma ferramenta gratuita e de código aberto Juniper Junos SDK O Junos Software Development Kit (SDK) é uma plataforma aberta e extensível para o desenvolvimento de aplicações que funciona integrada ao sistema operacional de rede da Juniper, o Junos 2. O Junos SDK faz parte da Partner Solution Development Plataform (PSDP), um programa da Juniper através do qual parceiros podem desenvolver aplicações para os seus equipamentos. O Junos é capaz de integrar os serviços de roteamento, switching, segurança e serviços e é utilizado pela maioria dos equipamentos Juniper. Seu núcleo é baseado no FreeBSD, um sistema operacional open-source baseado em Linux desenvolvido originalmente pela Universidade 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 no Plano de Controle e no Plano de Serviço. O objetivo principal do plano de controle é gerenciar e controlar o comportamento do equipamento como um todo, incluindo os dois outros planos. Esse plano funciona em um hardware chamado Router Engine (RE), normalmente redundante, cujo elemento principal é o Junos Software Operating System. Para gerenciar o equipamento, é necessário utilizar além do RE, daemons 3 e aplicações lançadas sob demanda. Além disso, a gerência 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 status e estatísticas. O modo de Configuração atua sobre as configurações dos equipamentos. Os daemons 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 a função de encaminhar ou filtrar o tráfego de acordo com a tabela de roteamento com base em filtros e regras pré estabelecidas. Esse plano realiza este processamento baseado nos cabeç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 o que for estabelecido pelo plano de controle. Normalmente, o plano de dados, também chamado de Packet Forwarding Engine (PFE), objetivando ganhos de desempenho opera sem ciência do estado das conexões. Finalmente, o plano de serviço é uma extensão opcional do plano de dados e executa os 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 equipamentos Juniper chamados genericamente de MultiServices Modules os quais são conectados ao PFE por via canais de 10Gbps. Esses módulos de hardware são similares ao RE mas possuem um CPU multitarefa e mais memória dedicada, além de serem hot-swappable Um programa de computador que roda de forma independente em background sem ser diretamente controlado por um usuário. 4 Application Specific Integrated Circuit, um circuito integrado customizado para executar uma tarefa específica. 5 Dispositivo que pode ser trocado mesmo com o equipamento ligado e em funcionamento.

36 36 Esta capacidade adicional os tornam capazes de processar pacotes em paralelo e manter uma grande quantidade de estados. Mais uma peculiaridade do plano de serviço é a sua divisão em: subplano de serviço e o subplano de controle. O primeiro pode ser usado para execução de aplicações que normalmente funcionariam no RE para, dentre outros motivos, se beneficiar do ganho de desempenho devido ao compartilhamento de memória e informações com aplicações funcionando no plano de serviço. Já o subplano de controle atua transformando ou monitorando os pacotes que são encaminhados pelo PFE. Como dito anteriormente, o plano de controle também é responsável por gerenciar o plano 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 ser efetuado de três formas. Na primeira, cria-se rotas na tabela de rotamento que apontam para o MS. Na segunda são utilizadas políticas que marcam o tráfego que deve ser direcionado, as quais são aplicadas as interfaces de entrada. E, finalmente, na terceira é utilizado um método chamado de sampling, onde os dados são copiados para o MS de acordo com regras sem que o tráfego original seja afetado Junos SDK O Junos SDK provê Application User Interfaces (APIs) que permitem que aplicações sejam incorporadas ao Junos permitindo que as mesmas controlem o comportamento dos equipamentos. Os componentes e aplicações desenvolvidos através da SDK, uma vez implantados, rodam nativamente nos equipamentos Juniper com Junos como qualquer outro processo nativo do sistema. Como o PSDP se propõe a suportar diversos parceiros, o ambiente onde as aplicações são executadas é controlado de maneira que uma aplicação não cause interferência em outra. Este controle começa pela separação da área de instalação de cada parceiro, baseado no seu identificador ID fornecidos pela Juniper e extraído de um certificado assinado pela mesma. O número máximo de identificadores depende da quantidade de memória e CPU disponíveis e também da quantidade de arquivos aberto e permissão de acesso a sockets. Um efeito colateral desta separação de área de instalação por parceiro baseado no identificador é a garantia de autenticidade das aplicações e também a identificação de códigos que não nativos do sistema O Routing Engine e o Services SDK Como já foi dito, através do Junos SDK é possível interagir com diversos componentes do Junos utilizando suas APIs, que são bibliotecas em linguagem C/C++. Ele é composto de duas partes distintas o Routing Engine SDK (RE SDK), voltada para o plano de controle e 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 plano de controle na Routing Engine. Como o RE está sempre presente em todo equipamento Juniper, as aplicações baseadas neste SDK podem ser instaladas sem a necessidade de qualquer 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 37 de Serviço na Subseção Na Figura 3.7 é exibida a visão integrada dos módulos do Junos SDK. Figura 3.7: Módulos do Junos SDK. Existem dois modos usados para construir aplicações no MS SDK, que são: Módulo Processo (Process Model) e Módulo Plugin (Plugin Model) exibido na Figura 3.9. Cada MS só suporta um desses modos por vez. O Módulo Processo descrito na Figura 3.8 cria um daemon composto de dois componentes: Controle e Data. O primeiro (Control Component) se comunica com o RE para receber e armazenar as políticas definas para o MS. Além disso, esse componente também pode 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 cooperar entre si. Em ambos módulos, cabe ao kernel do Junos processar a tarefa de fornecer os pacotes ao MS e devolvê-los ao tráfego normal 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 virtual FreeBSD executável através do VMWare Player, sendo portanto portável para qualquer plataforma onde este último funcione. Com o VBE são fornecidas todas as ferramentas necessárias para o desenvolvimento, como por exemplo: compiladores, linkeditores e debuggers Aplicações Utilizando o Junos SDK Algumas empresas já estão utilizando o Junos SDK para desenvolver softwares para os equipamentos Juniper. A Macadamian (BLOG, 2011) desenvolveu um gravador de ligações VOIP o qual, captura o áudio das ligações SIP sobre UDP, filtrando estas chamadas por endereço de origem da chamada. Outra aplicação utilizando o Junos SDK é o MoniTube utilizado para monitorar a qualidade de streams IPTV e que também pode espelhar esses streams para outras localidades.

38 38 Figura 3.8: Process Model Considerações Finais Com relação a abrangência, destaca-se a capacidade do Junos SDK de ser utilizada tanto 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. Essa linguagem por utilizar a abordagem orientada a objetos, é considerada de boa legibilidade e muito flexível. Quanto a interoperabilidade e ao controle de transferência, não foram encontradas referê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 pelo desenvolvedor. Com relação ao custo, à portabilidade e ao suporte a infraestrutura existente, o Junos SDK peca por exigir a utilização de equipamentos Juniper. Por outro lado, como o Junos SDK funciona sobre um sistema operacional único e comum a todos os equipamento deste fabricante, é 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 limitam o que cada aplicação pode fazer e de que maneira as mesmas afetam o tráfego, podendo ser transparente para o mesmo Cisco AON O Application-Oriented Networking (AON), terceira e última fase do projeto Intelligent Information Network (IIN) da Cisco System (CISCO, 2011b), consiste em um sistema de roteamento que compreende o conteúdo e o contexto das mensagens que circulam

39 39 Figura 3.9: Plugin Model na rede. Ou seja, o AON atua na camada de aplicação e, portanto, é capaz de realizar operações nestas mensagens de acordo com a política da empresa. O AON serve de base para a criação de produtos e soluções de rede Cisco, que possibilitam a convergência entre a rede e aplicações. É importante mencionar que o Cisco AON requer para seu funcionamento que equipamentos dedicados sejam instalados na rede, como o Cisco Application Deployement Engine (CADE) 2142, exibido na Figura Figura 3.10: Cisco Application Deployement Engine Operação Os switches ou roteadores Cisco podem redirecionar de maneira transparente o tráfego das aplicações para o equipamento do AON onde as políticas definidas serão aplicadas a este 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 forma transparente para o módulo Cisco AON sem que sejam necessárias alterações nas aplica-

40 40 ções. O tráfego é reencaminhado ao seu destino após as políticas definidas serem aplicadas. Por exemplo, o AON pode atuar como um gateway entre empresas parceiras, fornecendo uma interface transparente entre as mesmas ao lidar com os dados a nível de aplicação. Nesse exemplo, o AON pode estar garantir a autenticação e autorização de acesso, validação de mensagens dentre outros serviços ou integrar filiais remotas atuando com uma ponte entre as aplicações operando nas mesmas, como descrito na Figura Figura 3.12: Exemplos de utilização do AON. As operação realizadas nas mensagens são orquestradas pelo Cisco AON Development Studio, exibidas na Figura 3.13, onde as bladelets, operações que atuam sobre os dados, e os adaptadores, para tratamento de protocolos ou mensagens proprietárias, são organizadas em um Plano de Execução de Políticas (PEP). Além do sistema Cisco AON também é fornecida uma biblioteca de bladelets com as funcionalidades 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 assinatura, entre outros. Transformação - função que possibilitam conversão dos dados de/e para XML.

41 41 Figura 3.13: Orquestração de operações com Cisco AON Development Studio Serviços providos pelo AON O AON provê um pacote de serviços, a saber: segurança, visibilidade, roteamento inteligente de mensagem e extensibilidade. O serviço de Segurança provê segurança às aplicações, garantindo mecanismos de autenticação, autorização de acesso, integridade e autenticidade dos dados, confidencialidade e gerenciamento centralizado de certificados. No serviço de Visibilidade, os nós do AON pode ser configurados para coletar e processar 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 qualidade de serviço em nível de aplicação, garantindo, por exemplo, que um sistema tenha maior prioridade que um outro. Além disso, esse serviço pode realizar traduções entre diferentes 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 Program Interfaces (APIs) através da qual é possível desenvolver, utilizando linguagem C/C++ ou Java, novas operações (bladelets) e adaptadores que atuarão sobre as mensagens Considerações Finais Com relação à facilidade de desenvolvimento, o Cisco AON utiliza linguagens amplamente difundidas e fornece documentação para apoio ao desenvolvimento de novas aplicaçõ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 do ambiente de desenvolvimento, o que aumenta o custo do processo.

42 42 Figura 3.14: Placa NetFPGA 1Gbps Quanto à abrangência do CISCO AON, essa mostrou-se ser um fator limitante pelo fato de atuar apenas sobre as mensagens, apesar de novas bladelets e novos adaptadores poderem ser criados. Com relação à heterogeneidade, é importante destacar que o AON é uma tecnologia dedicada da Cisco requerendo, portanto, que os equipamentos de rede sejam deste mesmo fabricante. Tal fato pode causar impacto no custo e suporte à arquitetura existente. É importante destacar que com relação à segurança, não foi encontrado no material pesquisado informações a respeito de como o tráfego é tratado caso o equipamento que habilita o AON apresente problemas de rede, nem como é definido o acesso das aplicações às mensagens NetFPGA A plataforma NetFPGA foi criada visando o ensino e a pesquisa na área de redes de computadores através da construção de sistemas de alta performace, switches ethernet e roteadores IP, utilizando hardwares programáveis ao invés de software. O NetFPGA é opensource e consiste em uma placa PCI composta por um circuito FPGA 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 um router IPv4, de um switch Ethernet e de uma placa de rede com quatro portas e material didático. É importante ressaltar que, apesar da placas por enquanto estarem limitadas a quatro portas, um mesmo computador pode hospedar mais de uma placa, que são então conectadas através de um conector SATA para troca de dados em alta velocidade, sem a necessidade 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, utilizando uma interface gráfica desenvolvida em java. Mas especificamente com relação a programaçã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 em um 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 na Figura Esta modularidade facilita o desenvolvimento pois permite que apenas com a inclu-