Onix: Sistema Integrado de Gerencia para Redes Sobrepostas

Feliciano, G. O.; Berenguel, A. L. A.; Zagari, E. N. F. e Cardozo, E.1

1Departamento de Computacao e Automacao (DCA)Faculdade de Engenharia Eletrica e de Computacao (FEEC)

Universidade Estadual de Campinas (Unicamp)Caixa Postal 6101 – CEP 13.083-970 – Campinas – SP – Brasil

{eng.guilhermef, andre.berenguel}@gmail.com{zagari, eleri}@dca.fee.unicamp.br

Abstract. The widespread of overlay networks are explaining by the benefitsof supporting customized control and forwarding functions over an existingnetwork. However, overlay networks increase the complexity of managingthe configuration of the supporting (physical) network. This paper proposesa management architecture for configuring the physical and overlay (logical)networks in an integrated way. The components of the architecture and theirrelationships are presented, as well as an implementation of the architecture,the Onix system. Onix allows the configuration of both physical and logicalnetworks and employs several design patterns in its conception.

Resumo. O emprego de rede sobrepostas tem aumentado devido aos benefıciosde suportar funcoes de controle e de encaminhamento particulares. No en-tanto, o seu emprego aumenta a complexidade de gerencia de configuracao darede. Este artigo propoe uma arquitetura de gerencia integrada de configuracaode redes de suporte (fısica) e sobreposta (logica). Sao discutidos os compo-nentes de configuracao das redes fısica e logica, seus relacionamentos e umaimplementacao da arquitetura, o sistema Onix. Onix contempla a configuracaode ambas as redes de forma integrada e utiliza padroes de projeto na interfacecom o usuario e nos componentes da arquitetura.

1. IntroducaoO crescimento do numero de usuarios na Internet tem impulsionado o surgimento deaplicacoes e servicos que a utilizam como infra-estrutura. Cada aplicacao impoe seusproprios requisitos de qualidade de servico (QoS), tais como, confiabilidade, atraso evariacao do atraso (jitter). A arquitetura padrao da Internet, baseada no servico de melhoresforco, nao consegue atender estes requisitos. Esta e a realidade que os provedores deacesso a Internet (ISPs) vem enfrentando: a convergencia de voz, dados e vıdeo trafe-gando em suas redes com servico de melhor esforco. Assim, para suportar os chamadosservicos de rede de nova geracao, as redes destes provedores devem migrar para uma ar-quitetura de rede multiservico, que suporte as diferencas de QoS de cada aplicacao seminterferir na rede como um todo [Wood 2005].

Para oferecer os mais diversos tipos de servicos aos usuarios, a tendencia hoje eque as redes sejam utilizadas de forma mais abrangente. Redes VPNs (Virtual PrivateNetworks), redes VoIP (Voice over IP) e redes P2P (Peer-to-Peer) sao exemplos de redes

89Sessão Técnica 3 - Gereciamento Integrado

que, atraves de esquemas de tunelamento, constroem redes sobrepostas sobre a infra-estrutura de rede existente (rede de suporte). O estabelecimento destes tuneis geralmente erealizado com o intuito de diferenciar um fluxo de dados segundo algum parametro (QoS,seguranca, roteamento, etc.). Tais tuneis estabelecem um domınio de controle separadodo domınio da rede de suporte. Assim, ha a necessidade de uma solucao de gerencia capazde auxiliar os administradores tanto na configuracao da rede de suporte como na gerenciada rede sobreposta. Este artigo apresenta o sistema Onix (Overlay Network IntegratedConfigurator System), uma implementacao de um sistema integrado de gerencia para asredes de suporte e sobreposta, com enfase na configuracao das redes. Tres caracterısticasimportantes desta implementacao sao: o uso intensivo de padroes de projeto na interface,a flexibilidade do uso de protocolos baseados em XML e, principalmente, a portabilidadepara diferentes tecnologias de tunelamento.

O artigo esta organizado da seguinte forma. A secao 2 faz uma breve conceituacaosobre redes sobrepostas. A secao 3 apresenta casos de uso do sistema e a arquiteturada aplicacao de gerencia integrada. As secoes 4 e 5 apresentam as solucoes de projetoadotadas para a configuracao das topologias fısicas e logicas, respectivamente, e a secao6 os padroes de projeto empregados. A secao 7 apresenta o sistema Onix e seus resultadose, finalmente, a secao 8 apresenta as conclusoes do trabalho.

2. Gerencia de Redes Sobrepostas

Os enlaces que conectam os nos participantes da rede sobreposta consistem de tuneis es-tabelecidos sobre a rede de suporte. Os tuneis “escondem” o trafego que flui na redesobreposta da rede de suporte e fazem com que as topologias das redes de suporte e so-brepostas geralmente nao sejam as mesmas. Alem disto, eles estabelecem um domınio decontrole separado do domınio da rede de suporte. Um no que faz parte da rede sobrepostadeve suportar funcoes de controle e de encaminhamento particulares, tais como funcoesde ingresso e de egresso em tuneis. Os protocolos de rede da rede sobreposta necessariospara tais funcoes especializadas podem diferir daqueles equivalentes da rede de suporte.

A construcao de redes sobrepostas levantam algumas questoes interessantes, queinfluem no grau de complexidade de sua gerencia, das quais podemos citar:

• quais nos proverao suporte as funcoes adicionais requeridas pela rede sobreposta?• como conectar este nos? (ou, como encontrar a melhor topologia para a rede

sobreposta?) [Han, J.; Watson, D.; Jahanian, F. 2005]• qual e o melhor esquema de tunelamento? (deve-se considerar tanto as questoes

relativas a desempenho quanto a seguranca);• como projetar as funcoes adicionais (empregando-se protocolos de rede ja exis-

tentes, estendendo-os ou introduzindo-se novos protocolos)?;• de que forma estas funcoes adicionais devem ser implementadas: em processado-

res dedicados ou no nucleo do roteador?

Os nos que pertencem a redes sobrepostas podem ser identificados pelos mesmosidentificadores empregados na rede de suporte (por exemplo, atraves de seus enderecosIP) ou por uma nova estrutura de nomes. Neste ultimo caso, deve-se prover tambem ummecanismo de resolucao de nomes, que mapeie identificadores da rede sobreposta paraos identificadores correspondentes na rede de suporte.

90 XII WGRS

Com relacao a topologia, algumas redes sobrepostas tem sua topologia determi-nada pela localizacao fısica onde as funcoes especializadas sao necessarias. Um exemplode tais redes sobrepostas sao as redes VPN. Outras redes sobrepostas tentam “instalar”estas funcionalidades especializadas proximas a potenciais usuarios. Redes sobrepostasbaseadas em conteudo geralmente mantem cache de informacao proximas a grandes con-sumidores.

Os esquemas de tunelamento variam de acordo com os requisitos de projeto.Tuneis IP/IP, por exemplo, sao simples. Tuneis IPsec sao seguros, mas mais comple-xos de lidar. Ja os tuneis MPLS (Multiprotocol Label Switching) [Rosen E. et al. 2001]permitem encaminhamento rapido e roteamento baseado em restricoes. Os protocolos es-pecializados, por sua vez, podem ser desenvolvidos integralmente como novos protocolosou apenas como extensoes de protocolos ja existentes. Normalmente as extensoes saobaseadas em novos objetos ou TLVs (Type, Length and Value), ignorados pela rede de su-porte, ou como dados “opacos” transferidos por protocolos que rodam na rede de suporte.Por fim, a escolha da localizacao das funcionalidades extras tambem permite multiplosprojetos. Geralmente uma parte destas funcionalidades sao instaladas no nucleo de rote-adores (push, pop e swapping de rotulos, por exemplo) e outra parte em processadoresdedicados (funcoes de gerencia, por exemplo).

3. Arquitetura de Gerencia IntegradaConforme exposto na secao anterior, o domınio de controle de uma rede sobreposta podeatingir razoavel complexidade. A integracao deste controle com o da rede fısica, atravesde padroes de projeto, tanto na interface com o administrador quanto na comunicacaocom os dispositivos gerenciados, pode trazer vantagens de simplificacao e eficiencia agerencia da rede. As subsecoes a seguir descrevem, respectivamente os casos de uso, umavisao geral e de distribuicao da arquitetura desenvolvida.

3.1. Casos de UsoA Figura 1 ilustra os casos de uso de um sistema de gerencia integrada das redes desuporte e sobreposta. Conceitualmente, existem duas classes de requisitos: os referentesa configuracao de topologia fısica e os referentes a configuracao de topologia logica.

Figura 1. Casos de Uso do Sistema

Para topologia fısica existem 4 casos de uso especıficos. O requisito Editar To-pologia Fısica tem como objetivo possibilitar ao administrador da rede inserir/removernovos dispositivos na rede ou alterar sua topologia fısica, criando uma topologia nova oumodificando uma ja existente. O requisito Salvar Topologia Fısica permite armazenar as

91Sessão Técnica 3 - Gereciamento Integrado

informacoes de uma topologia para posterior uso. O requisito Carregar Topologia Fısicapermite ao administrador informar ao sistema a topologia da rede que sera gerenciada,a partir de informacoes previamente armazenadas. O requisito Aplicar Topologia Fısicatem por objetivo enviar informacoes necessarias aos elementos da rede, fazendo valer atopologia fısica, editada ou carregada.

Com relacao a configuracao de topologia logica existem outros 5 casos de uso. Osrequisitos Criar Tunel e Remover Tunel permitem ao administrador criar um tunel a partirde uma origem ate um ou mais destinos e remover os tuneis criados, respectivamente. Orequisito Visualizar Tunel permite ao administrador visualizar o caminho de um deter-minado tunel criado, com base na topologia fısica da rede gerenciada. Ja o caso de usoNotificar Alteracoes Tunel oferece ao sistema informacoes sobre a criacao e a remocaode tuneis, ocorridas em cada roteador da rede gerenciada. Estas informacoes refletem oestado dos tuneis da rede em um determinado instante de tempo, sendo que este estadopode ser alterado mediante acoes do administrador ou devido a fatores da propria rede(por exemplo, o tunel solicitado nao pode ser criado devido a rede nao poder honrar re-quisitos de QoS). Por fim, o requisito Descobrir Topologia Logica oferece ao sistema ainformacao de todos os tuneis que estao ativos na rede.

Alem dos requisitos levantados, como pode-se observar na Figura 1, ha dois atoresque interagem com os requisitos do sistema de gerencia: o Administrador e o Agente. OAdministrador e o ator interessado em observar e, eventualmente, (re-)configurar as topo-logias fısica e logica da rede. O Agente tem como responsabilidade receber a requisicaodos servicos de gerencia e configurar os dispostivos, bem como alertar a gerencia aocorrencia de eventos de remocao e criacao dos tuneis.

3.2. Visao Geral da ArquiteturaA Figura 2 ilustra o padrao arquitetural do sistema integrado de gerencia proposto. O sis-tema apresentado oferece a possibilidade de gerenciar, a partir de uma mesma ferramenta,tanto a rede de suporte (topologia fısica) quanto a rede sobreposta (topologia logica).

AgenteMecanismo dePropagação de Mensagens

Gerenciador deTopologia Lógica

Topologia FísicaGerenciador de

Apresentação

Figura 2. Visao Geral da Arquitetura Integrada

O pacote Apresentacao agrupa as funcionalidades de edicao grafica e configuracaoda topologia fısica e logica (configuracao de tuneis), bem como a apresentacao em tela doestado atual da rede sobreposta. O pacote Gerenciador de Topologia Fısica e responsavelpor transformar a topologia e os parametros informados pelo administrador em mensa-gens de configuracao dos nos e dos dispositivos de rede. A alteracao topologica deveainda garantir que a configuracao de cada no esteja consistente com a dos dispositivos deinterligacao.

Tendo configurado a rede de suporte ou iniciando a partir de uma configuracaopre-informada, o administrador pode dar inıcio a configuracao da rede sobreposta. A

92 XII WGRS

configuracao desta rede (estabelecimento de tuneis) se da via o pacote Gerenciador deTopologia Logica. Os tuneis contemplados pela arquitetura proposta podem ser tanto dotipo ponto-ponto (possuem um ponto de origem e um unico ponto de destino) como ponto-multiponto (possuem um ponto de origem e um ou mais pontos de destinos). Neste ultimotipo de tunel, pacotes que ingressem no ponto de origem do tunel poderao, de acordo coma polıtica da rede, ser replicados nos pontos de bifurcacao do mesmo e entregues a todosos pontos de destino. O pacote Gerenciador de Topologia Logica tambem e responsavelpor monitorar a topologia logica existente a fim de manter a consistencia com o estado darede sobreposta.

O pacote Agente tem basicamente duas responsabilidades: a de receber asrequisicoes de configuracao da estacao de gerencia e a de notificar a mesma as eventu-ais alteracoes na rede. Este pacote, portanto, e responsavel por repassar para os distintosdispositivos gerenciados os comandos de configuracao e receber deles os eventos a se-rem notificados na estacao de gerencia. No caso da configuracao da topologia fısica darede, os dispositivos gerenciados sao, por exemplo, os roteadores, switches e protocolosde roteamento. Ja no caso da configuracao de tuneis, sao os protocolos de sinalizacao.E importante ressaltar que, com o uso dos agentes, ha a possibilidade de coexistencia deduas ou mais instancias de gerencia, sendo que as acoes realizadas em uma refletem nasoutras e vice-versa.

Realizar a comunicacao entre a estacao de gerencia e os dispositivos atraves dosagentes de gerencia traz o benefıcio de tornar a gerencia independente do dispositivo(configuracao fısica), do protocolo de sinalizacao de tuneis e do esquema de tunela-mento (configuracao logica). Toda a comunicacao entre as entidades e realizada sobre ummesmo padrao de mensagens e realizada pelo componente Mecanismo de Propagacao deMensagens. As mensagens recebidas pelo Agente sao localmente adaptadas ao padrao docorrespondente dispositivo ou protocolo.

3.3. Visao de Distribuicao da ArquiteturaA Figura 3 mostra como a arquitetura do sistema e distribuıda. Como podemos observar,os componentes Apresentacao, Gerenciador de Topologia Fısica, Gerenciador de Topo-logia Logica e Mecanismo de Propagacao de Mensagens do componente Gerente saoexecutados no no denominado Estacao de Gerencia. O componente Apresentacao e de-pendente dos componentes Gerenciador de Topologia Fısica e Gerenciador de TopologiaLogica. Estes, por sua vez, sao dependentes do componente Mecanismo de Propagacaode Mensagens. Por fim, o componente Gerenciador de Topologia Logica tambem possuidependencia do componente Gerenciador de Topologia Fısica.

Nó Gerenciado

Apresentação

Mecanismo dePropagação de Mensagens

Mecanismo dePropagação de Mensagens

Estação de Gerência

Gerente

Topologia FísicaGerenciador de

Gerenciador deTopologia Lógica

Agente

Adaptador

XML/TCP

Figura 3. Visao de Distribuicao da Arquitetura

Ja o componente Agente e executado em nos existentes na rede gerenciada. A

93Sessão Técnica 3 - Gereciamento Integrado

comunicacao entre a Estacao de Gerencia e o No Gerenciado se da atraves de envio dedados em mensagens XML, sobre o protocolo TCP. Por isso a dependencia do compo-nente Adaptador por parte do componente Mecanismo de Propagacao de Mensagens.

4. Configuracao da Topologia Fısica

Uma visao estrutural do pacote Gerenciador de Topologia Fısica e mostrada na Figura 4.

Figura 4. Visao Estrutural do Gerenciador de Topologia Fısica

O pacote Gerenciador de Topologia Fısica e composto do pacote Modelo, onde seencontra as classes que representam os objetos de rede, e do pacote Gerencia, onde esta ocontrole do Gerenciador. Este pacote e responsavel por editar tais objetos, manipular osarquivos da topologia e aplicar a topologia fısica na rede.

A edicao da topologia e feita via camada de apresentacao (ver Figura 2), que alteradiretamente as propriedades dos objetos do pacote Modelo. E possıvel, nesta camada,editar os dados das interfaces de rede dos nos (endereco IP e mascara de rede), dadosdos nos (rota default) e atributos das VLANs (nome, ativacao de GVRP - Generic VLANRegistration Protocol).

O Gerenciador de Topologia Fısica permite tambem modificar e salvar a topologiamodificada em um arquivo XML e carrega-lo posteriormente para continuar a edicao datopologia fısica.

Outra responsabilidade do pacote Gerencia e permitir a aplicacao da topologiacriada/editada na rede, finalizando a configuracao da topologia fısica. A aplicacao datopologia na rede consiste em configurar os roteadores e switches (responsaveis pelo ge-renciamento de VLANs). A configuracao de cada roteador se da atraves de um protocolosimples baseado em mensagens XML. A classe ConfiguradorRoteador cria a mensagemXML e ordena seu envio ao pacote Mecanismo de Propagacao de Mensagens. No casode uma rede IP, as mensagens XML de configuracao dos roteadores tem por objetivo al-terar o endereco IP, a mascara de rede de suas interfaces de rede e a configuracao dosprotocolos de roteamento. Os Agentes (ver Figura 3) residentes nos roteadores recebemestas mensagens e as transformam em comandos de configuracao. O Agente respondecom uma mensagem de sucesso ou erro na configuracao.

Os comandos de configuracao de VLANs tambem sao realizados atraves de umprotocolo simples baseado em mensagens XML e repassados ao switch pelo Agente, por

94 XII WGRS

exemplo, via interface de gerencia CLI (Command Line Interface) ou HTTP. A classeConfiguradorVLANs monta a mensagem adequada para configurar o switch e a repassapara o Mecanismo de Propagacao de Mensagens, que por sua vez estabelece conexaocom o dispositivo e envia a mensagem. Para criar uma VLAN e necessario conhecer orelacionamento entre a interface de rede do roteador com a porta conectada. Estas relacoessao obtidas atraves de um arquivo e sao representadas pela ligacao entre as classes Portae InterfaceRede da Figura 4.

5. Configuracao da Topologia LogicaA Figura 5 mostra uma visao estrutural do pacote Gerenciador de Topologia Logica.

Figura 5. Visao Estrutural do Gerenciador de Topologia Logica

As classes do pacote Modelo sao responsaveis, basicamente, por representar, atopologia logica. A classe TopologiaLogica e uma estrutura de dados do tipo grafo. Estaclasse e uma composicao da classe Tunel, que, por sua vez, e composta de nos que apon-tam para a interface de rede e para o roteador. Assim, o conjunto de nos desta classerepresenta o caminho percorrido por um dado tunel. E importante ressaltar que o pa-cote Modelo possui uma dependencia para o pacote Gerenciador de Topologia Fısica, pormanipular classes contidas neste ultimo.

A classe ConfiguradorTopologiaLogica, presente no pacote Gerencia, e res-ponsavel por criar e remover os tuneis. Os metodos desta classe sao chamados tantopela janela de gerencia, presente no pacote Apresentacao (Figura 2), como pelo moni-tor da topologia, pois em ambas as direcoes (administrador-sistema-rede e rede-sistema-administrador), e possıvel haver criacao e remocao de tuneis. Com efeito, os metodosdesta classe sao todos sincronizados.

Por ultimo, as classes MonitorTopologia e RegistradorAgentes, ambas do pacoteGerencia, sao classes auxiliares da classe ConfiguradorTopologiaLogica. O registradorde agentes e responsavel por fazer registro e desregistro, em cada roteador, da instanciade gerencia interessada em manipular a rede de suporte. Ja o monitor da topologia eresponsavel por receber notificacoes do Agente e, assim, executar metodos apropriadosdo configurador da topologia, para manter o sistema de gerencia consistente com o estadoreal da rede gerenciada. O pacote Gerencia tem a dependencia com o pacote Mecanismode Propagacao de Mensagens, pois toda a informacao de gerencia produzida tem que serencaminhada ao roteador de ingresso do tunel, no caso de uma mensagem de criacao ouremocao de tunel, ou aos roteadores da rede de suporte, no caso de mensagens de registroou desregistro.

95Sessão Técnica 3 - Gereciamento Integrado

O Agente (ver Figura 3) e responsavel tanto pelo processo de descoberta da to-pologia logica quanto pela notificacao do estado dos tuneis, enviando notificacoes porexcecao, ou seja, apenas envia informacoes quando ha alteracoes de estado. Caso naohaja tuneis, nada e enviado e, somente com a deteccao de um novo tunel criado e queo agente ira enviar novas informacoes a gerencia. A integracao com o agente tambem erealizada atraves de troca de informacoes em formato XML.

6. Padroes de Projeto EmpregadosNo projeto do pacote de Apresentacao (Figura 2) utilizou-se o padraoarquitetural para sistemas interativos denominado Model-View-Controller(MVC) [Buschmann F. et al. 1996]. O padrao MVC visa separar uma aplicacao in-terativa em tres componentes: um modelo, responsavel por conter as funcionalidades eos dados principais da aplicacao; uma visualizacao, responsavel pela apresentacao emtela das informacoes ao usuario e um controlador, responsavel pelo comportamento dainterface mediante eventos produzidos pelo usuario.

Como a interacao com o administrador tambem e um fator a ser considerado noprojeto de sistemas de gerencia, o desenvolvimento da interface grafica baseou-se empadroes de projeto bem conhecidos, que sao descritos a seguir [Grand 1999]:

Ephemeral Feedback: o proposito deste padrao e prover aos usuarios umarealimentacao dos estados das tarefas realizadas ou solicitadas, sem interferir narealizacao de outras tarefas. Este padrao foi adotado para que o administrador conheca oestado das solicitacoes de criacao ou remocao de tuneis. O padrao tambem permite que oadministrador veja informacoes das entidades VLAN e roteador na barra de status, ao seclicar em seus ıcones; veja a resposta do switch na caixa de logs, ao se aplicar VLANs; eveja informacoes referentes aos nos, ao se aplicar uma nova topologia. Estas informacoesapresentadas nao interferem nas tarefas de visualizacao, criacao ou remocao de outrostuneis e nas tarefas de edicao da topologia fısica pelo administrador.

Window Per Task: e um padrao de projeto para desenvolvimento de interfacesgraficas que visa separar, em janelas distintas, as tarefas relacionadas. Toda a informacaorequerida, para o usuario realizar uma tarefa, esta disponıvel em uma mesma janela, como objetivo de deixar claro para o usuario o proposito de cada tela. A utilizacao destepadrao foi importante para separar as tarefas relacionadas aos tuneis ja criados da tarefade criacao de novos tuneis.

Direct Manipulation: uma interface projetada sob a otica do padrao Direct Mani-pulation, permite que o usuario realize operacoes e manipule diretamente os objetos apre-sentados por ela. Com a adocao deste tipo de padrao, e possıvel reduzir para o usuario omodelo mental referente aos resultados de suas acoes. Este modelo foi utilizado na edicaode topologia fısica, onde e possıvel ao administrador editar informacoes de roteadores eVLANs acessando diretamente seus ıcones, trocar a VLAN ou roteador ligados a um en-lace por simples arrastamento de uma das pontas do enlace e inserir enlaces entre VLANse roteadores clicando diretamente nos ıcones dessas duas entidades. Este modelo tambemfoi utilizado na janela responsavel pela criacao dos tuneis, onde, atraves da manipulacaodireta dos roteadores, e possıvel estabelecer o caminho do tunel de forma intuitiva.

Supplementary Window: o intuito do padrao Supplementary Window e oferecerao usuario uma nova janela contendo informacoes que suplementam a janela anterior

96 XII WGRS

(pai). A nova janela (filha) e responsavel por coletar informacoes necessarias para otermino de uma operacao da janela pai. A tarefa da janela pai nao e finalizada ate que ousuario forneca a operacao requerida na janela filha. Este padrao foi utilizado na criacaode janelas para a edicao de VLANs, roteadores e interfaces de rede. Tambem foi utilizadopara a coleta da informacao de qual interface de rede de um roteador participara do tuneldesejado.

7. Onix (Overlay Networks Integrated Configurator System)O Onix e um sistema computacional capaz de configurar tanto a topologia fısica de umarede quanto a topologia logica. O componente Gerente foi desenvolvido em Java 1.5 e fazuso de diversos pacotes Java, dentre eles o JGraph, JDom, Java Swing e o Jakarta Com-mons HttpClient. O componente Agente dos switches tambem foi desenvolvido em Javae transforma as requisicoes XML em requisicoes HTTP do tipo POST. Ja o componenteAgente dos roteadores foi desenvolvido em C++.

O projeto do Onix foi motivado para a gerencia de configuracao de uma rede decomputadores real do Laboratorio de Computacao e Automacao da Faculdade de Enge-nharia Eletrica e de Computacao da Unicamp, composta por roteadores Linux conectadosatraves de dispositivos de rede de camada 2. O objetivo era a gerencia de configuracaode uma rede sobreposta com a funcionalidade especıfica de roteamento especial para nosmoveis dentro do domınio. Atualmente, a rede conta com 16 roteadores com 4 interfacesde rede cada, 2 switches e uma estacao de gerencia. A Figura 6 ilustra o cenario alvo deconfiguracao de topologias. A estacao de gerencia, o switch e os nos estao conectados viaRede de Configuracao, que viabiliza a comunicacao de gerencia. O switch gerenciavelsegmenta os enlaces entre os nos da Rede de Topologia Configuravel atraves da VLANsconfiguraveis.

Figura 6. Cenario de Configuracao das Topologias Fısica e Logica

A arquitetura sugerida objetiva reduzir a complexidade da gerencia de ambas astopologias fısica e logica, realizando todo esse processo atraves de uma unica estacao degerencia e via uma interface grafica integrada. Para isto e necessario que a estacao degerencia tenha acesso ao switch (para configurar as conexoes atraves de VLANs), aosroteadores (para configurar suas interfaces de rede) e aos daemons de sinalizacao (paraconfiguracao de tuneis).

A configuracao de uma topologia fısica da rede consiste em acessar cada no darede e ajustar sua configuracao. Em um no de uma rede IP, p.ex., deve-se alterar oendereco IP e a mascara de rede de cada interface de rede do no. Em um roteador, deve-sealterar tambem os parametros de configuracao do protocolo de roteamento. Neste tra-balho, considera-se que todos os nos (hosts e roteadores) estejam ligados diretamente a

97Sessão Técnica 3 - Gereciamento Integrado

um switch com capacidade de configuracao de VLANs, tornando-se possıvel alterar a to-pologia atraves da interface de configuracao deste dispositivo e que todos os roteadorespossuam um daemon de roteamento OSPF (Open Shortest Path First). O componenteAgente do Onix faz a adaptacao da requisicao de servico XML para os comandos deconfiguracao dos roteadores Linux e do protocolo de roteamento ou para a interface degerencia de VLANs no switch.

Para a construcao da rede sobreposta, em cada roteador deve haver ainda,alem do componente Agente, um daemon de sinalizacao para construcao e remocaode tuneis. A arquitetura proposta e independente do protocolo de sinalizacao, quepode ser adaptado pelo componente Agente. Ainda, e preciso que a rede de su-porte a algum esquema de tunelamento. A rede de testes ja contava com um da-emon de sinalizacao RSVP-TE (Resource ReSerVation Protocol - Traffic Enginee-ring) [R. Aggarwal, D. Papadimitriou and S. Yasukawa 2007], com suporte a sinalizacaode tuneis ponto-multiponto e esquema de tunelamento IP/IP nativo do Linux. O trafegonos tuneis ponto-multiponto desta rede de testes e encaminhado a um ou mais nos deegresso, dependendo de sua configuracao. Caso o trafego deva ser direcionado a doisou mais destinos, os pacotes sao duplicados no ponto de bifurcacao adequado atraves decomandos nativos do Linux. Para a validacao da arquitetura, implementou-se o Agentecom um adaptador para a interface de gerencia do daemon de sinalizacao ja existente, quetambem e baseada em XML.

7.1. Configuracao de Topologia Fısica no Sistema Onix

Para criar uma topologia fısica ou modificar uma pre-existente atraves do sistema Onix,apos informar o arquivo de mapeamento de portas/interfaces na janela principal, e car-regado o Gerenciador de Topologia Fısica. Do lado esquerdo superior ha uma caixa deferramentas, por onde e possıvel inserir VLANs, enlaces, inspecionar propriedades deelementos (no, VLAN) e aplicar a topologia fısica na rede. Do lado esquedo inferior hauma caixa de logs que mostra informacoes do processo de aplicacao da topologia na rede.Na parte maior a direita a topologia fısica e exibida atraves da biblioteca JGraph.

Ao clicar com o botao direito do mouse sobre um no, pode-se abrir sua caixa depropriedades, ilustrada na Figura 7, onde ha opcoes para editar a rota default do no, oendereco IP, a mascara de rede e a area do protocolo de roteamento de suas interfaces derede. Se a interface de rede for a de gerencia, pode-se editar o nome da interface.

Pode-se inserir VLANs na topologia fısica clicando sobre o ıcone de VLAN nacaixa de ferramentas e depois clicando sobre alguma regiao da topologia fısica. Uma novacaixa de propriedades sera aberta, onde deverao ser informados identificador, o nome daVLAN e a ativacao (ou nao) do protocolo GVRP. Apos inserir alguns enlaces tem-sea topologia mostrada na Figura 8, terminando assim a configuracao da topologia fısica.Para aplicar a topologia fısica, existem 2 botoes na caixa de ferramentas: uma para aplicar(gravar) todas as VLANs no switch e outro para aplicar as configuracoes em todos os nos.E possıvel tambem aplicar cada VLAN individualmente no switch e aplicar a configuracaoem cada no individualmente. Para isto, basta clicar com o botao direito sobre a entidadedesejada na representacao da topologia e escolher a opcao de aplicar. Porem, para finalizarpor completo a configuracao da topologia fısica, e necessario aplicar todas as entidadesna rede configuravel.

98 XII WGRS

Figura 7. Edicaode Propriedadesdo Roteador

Figura 8. Interface Grafica do Gerenciadorde Topologia Fısica

7.2. Configuracao de Topologia Logica no Sistema Onix

Depois de aplicar toda a topologia fısica na rede configuravel, pode-se realizar aconfiguracao da topologia logica, que estara sobreposta a topologia fısica configurada.Na aba Logical Topology Manager, a interface do sistema Onix altera seus componentesvisuais, oferencendo ao administrador uma area de trabalho contendo apenas componen-tes necessarios para a realizacao da gerencia da topologia logica. A area de trabalho eentao dividida em tres partes principais. A parte do lado superior esquerdo oferece apossibilidade de criacao, remocao e visualizacao dos tuneis. A parte inferior esquerdaapresenta ao administrador o resultado de suas acoes de gerencia, bem como acoes re-alizadas pelo proprio sistema. A parte localizada a direita e onde o administrador podevisualizar a topologia fısica gerenciada e o caminho de um dado tunel.

Para a criacao de um tunel e preciso que o administrador clique com o botao direitona area em branco do lado superior esquerdo da area de trabalho e escolha a opcao decriar um tunel no menu popup que aparece. Aparecera uma janela, onde o administradorpodera estabelecer o caminho e definir os parametros para a criacao do tunel. Para oestabelecimento do caminho, faz-se necessario que o administrador clique em cima doroteador desejado e selecione uma interface. Ao final do processo de configuracao docaminho, o sistema transformara a representacao visual em uma requisicao de criacao detunel e, entao, enviara ao agente do servidor de sinalizacao de origem do tunel.

Caso o tunel seja criado com sucesso, o administrador podera remove-lo ou visu-alizar o seu caminho. Para remover, o administrador necessita apenas clicar com o botaodireito em cima do tunel e selecionar a opcao de remover o tunel. Para a visualizacaodo caminho, o administrador necessita clicar com o botao esquerdo em cima do mesmo.Para esta acao, o sistema ira tracar, em cima da topologia da rede de suporte, o caminhodeste tunel. A Figura 9 ilustra um exemplo da visualizacao de um tunel.

8. ConclusoesRedes sobrepostas vem sendo empregadas nos mais diversos cenarios de oferecimentode novos servicos sobre as redes de transporte existentes. Os benefıcios da criacao de

99Sessão Técnica 3 - Gereciamento Integrado

Figura 9. Exemplo de Visualizacao de um Tunel

novos planos de controle e encaminhamento dedicados aos novos servicos tendem a secontrapor a um aumento na complexidade da gerencia das redes fısica e sobrepostas. Esteartigo apresentou o projeto e implementacao de um sistema integrado de gerencia que tempor meta minimizar a complexidade de gerencia introduzida pelas redes sobrepostas.

O sistema vem sendo utilizado com sucesso na gerencia de uma rede de 16 rote-adores que oferece suporte a mobilidade de terminais IP. A rede fısica consiste de umatopologia densamente conectada, enquanto a topologia da rede sobreposta consiste detuneis ponto-multiponto. O trafego nos tuneis da rede sobreposta e direcionado para o node egresso do tunel capaz de atingir o destinatario (terminal movel). Uma sinalizacao demobilidade faz com que o encaminhamento na rede sobreposta seja atualizado em funcaoda mobilidade dos terminais.

O sistema Onix tem se mostrado de grande utilidade na configuracao de topologiasfısicas e logicas de teste e seu nucleo sera a base de um sistema de engenharia de trafego,que permitira a tolopogia da rede sobreposta se ajustar de forma automatica em respostaas condicoes de trafego desta rede.

ReferenciasBuschmann F. et al. (1996). Pattern-Oriented Software Architecture: A System of Pat-

terns. John Wiley & Sons.

Grand, M. (1999). Patterns in Java, volume 2. Wiley Computer Publishing.

Han, J.; Watson, D.; Jahanian, F. (2005). Topology aware overlay networks. In Procee-dings of INFOCOM 2005, volume 4, pages 2554 – 2565. 24th Annual Joint Conferenceof the IEEE Computer and Communications Societies.

R. Aggarwal, D. Papadimitriou and S. Yasukawa (2007). Extensions to RSVP-TE forPoint-to-Multipoint TE LSPs. IETF Draft.

Rosen E. et al. (2001). Multiprotocol Label Switching Architecture. RFC-3031.

Wood, R. (2005). Next-Generation Network Services. Cisco Press.

100 XII WGRS