The widespread of overlay networks are explaining by the benefits of supporting customized control and forwarding functions over an existing network. However, overlay networks increase the complexity of managing the configuration of the supporting (physical) network. This paper proposes a management architecture for configuring the physical and overlay (logical) networks in an integrated way. The components of the architecture and their relationships are presented, as well as an implementation of the architecture, the Onix system. Onix allows the configuration of both physical and logical networks and employs several design patterns in its conception.

1. Sessão Técnica 3 - Gereciamento Integrado 89
Onix: Sistema Integrado de Gerˆ ncia para Redes Sobrepostas
e
Feliciano, G. O.; Berenguel, A. L. A.; Zagari, E. N. F. e Cardozo, E.1
1
¸˜ ¸˜
Departamento de Computacao e Automacao (DCA)
¸˜
Faculdade de Engenharia El´ trica e de Computacao (FEEC)
e
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 benefits
of supporting customized control and forwarding functions over an existing
network. However, overlay networks increase the complexity of managing
the configuration of the supporting (physical) network. This paper proposes
a management architecture for configuring the physical and overlay (logical)
networks in an integrated way. The components of the architecture and their
relationships are presented, as well as an implementation of the architecture,
the Onix system. Onix allows the configuration of both physical and logical
networks and employs several design patterns in its conception.
Resumo. O emprego de rede sobrepostas tem aumentado devido aos benef´cios ı
de suportar funcoes de controle e de encaminhamento particulares. No en-
¸˜
tanto, o seu emprego aumenta a complexidade de gerˆ ncia de configuracao da
e ¸˜
rede. Este artigo prop˜ e uma arquitetura de gerˆ ncia integrada de configuracao
o e ¸˜
de redes de suporte (f´sica) e sobreposta (l´ gica). S˜ o discutidos os compo-
ı o a
nentes de configuracao das redes f´sica e l´ gica, seus relacionamentos e uma
¸˜ ı o
implementacao da arquitetura, o sistema Onix. Onix contempla a configuracao
¸˜ ¸˜
de ambas as redes de forma integrada e utiliza padr˜ es de projeto na interface
o
com o us´ ario e nos componentes da arquitetura.
u
¸˜
1. Introducao
O crescimento do n´ mero de usu´ rios na Internet tem impulsionado o surgimento de
u a
¸˜ ¸˜
aplicacoes e servicos que a utilizam como infra-estrutura. Cada aplicacao imp˜ e seus
¸ o
pr´ prios requisitos de qualidade de servico (QoS), tais como, confiabilidade, atraso e
o ¸
¸˜
variacao do atraso (jitter). A arquitetura padr˜ o da Internet, baseada no servico de melhor
a ¸
¸ a ´
esforco, n˜ o consegue atender estes requisitos. Esta e a realidade que os provedores de
`
acesso a Internet (ISPs) vˆ m enfrentando: a convergˆ ncia de voz, dados e v´deo trafe-
e e ı
gando em suas redes com servico de melhor esforco. Assim, para suportar os chamados
¸ ¸
¸˜
servicos 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 sem
interferir na rede como um todo [Wood 2005].
¸ a e ´
Para oferecer os mais diversos tipos de servicos aos usu´ rios, a tendˆ ncia hoje e
que as redes sejam utilizadas de forma mais abrangente. Redes VPNs (Virtual Private
Networks), redes VoIP (Voice over IP) e redes P2P (Peer-to-Peer) s˜ o exemplos de redes
a

2. 90 XII WGRS
que, atrav´ s de esquemas de tunelamento, constr´ em redes sobrepostas sobre a infra-
e o
´
estrutura de rede existente (rede de suporte). O estabelecimento destes t´ neis geralmente e
u
realizado com o intuito de diferenciar um fluxo de dados segundo algum parˆ metro (QoS,
a
seguranca, roteamento, etc.). Tais t´ neis estabelecem um dom´nio de controle separado
¸ u ı
ı a ¸˜
do dom´nio da rede de suporte. Assim, h´ a necessidade de uma solucao de gerˆ ncia capaz
e
¸˜
de auxiliar os administradores tanto na configuracao da rede de suporte como na gerˆ nciae
da rede sobreposta. Este artigo apresenta o sistema Onix (Overlay Network Integrated
¸˜
Configurator System), uma implementacao de um sistema integrado de gerˆ ncia para as
e
ˆ ¸˜
redes de suporte e sobreposta, com enfase na configuracao das redes. Trˆ s caracter´sticas
e ı
¸˜ a
importantes desta implementacao s˜ o: o uso intensivo de padr˜ es de projeto na interface,
o
a flexibilidade do uso de protocolos baseados em XML e, principalmente, a portabilidade
para diferentes tecnologias de tunelamento.
¸˜ ¸˜
O artigo est´ organizado da seguinte forma. A secao 2 faz uma breve conceituacao
a
¸˜
sobre redes sobrepostas. A secao 3 apresenta casos de uso do sistema e a arquitetura
¸˜ ¸˜ ¸˜
da aplicacao de gerˆ ncia integrada. As secoes 4 e 5 apresentam as solucoes de projeto
e
¸˜ ¸˜
adotadas para a configuracao das topologias f´sicas e l´ gicas, respectivamente, e a secao
ı o
¸˜
6 os padr˜ es de projeto empregados. A secao 7 apresenta o sistema Onix e seus resultados
o
¸˜
e, finalmente, a secao 8 apresenta as conclus˜ es do trabalho.
o
2. Gerˆ ncia de Redes Sobrepostas
e
Os enlaces que conectam os n´ s participantes da rede sobreposta consistem de t´ neis es-
o u
tabelecidos sobre a rede de suporte. Os t´ neis “escondem” o tr´ fego que flui na rede
u a
sobreposta da rede de suporte e fazem com que as topologias das redes de suporte e so-
brepostas geralmente n˜ o sejam as mesmas. Al´ m disto, eles estabelecem um dom´nio de
a e ı
controle separado do dom´nio da rede de suporte. Um n´ que faz parte da rede sobreposta
ı o
¸˜
deve suportar funcoes de controle e de encaminhamento particulares, tais como funcoes¸˜
de ingresso e de egresso em t´ neis. Os protocolos de rede da rede sobreposta necess´ rios
u a
¸˜
para tais funcoes especializadas podem diferir daqueles equivalentes da rede de suporte.
¸˜
A construcao de redes sobrepostas levantam algumas quest˜ es interessantes, que
o
influem no grau de complexidade de sua gerˆ ncia, das quais podemos citar:
e
• quais n´ s prover˜ o suporte as funcoes adicionais requeridas pela rede sobreposta?
o a ` ¸˜
• como conectar este n´ s? (ou, como encontrar a melhor topologia para a rede
o
sobreposta?) [Han, J.; Watson, D.; Jahanian, F. 2005]
• qual e o melhor esquema de tunelamento? (deve-se considerar tanto as quest˜ es
´ o
` `
relativas a desempenho quanto a seguranca);
¸
• como projetar as funcoes adicionais (empregando-se protocolos de rede j´ exis-
¸˜ a
tentes, estendendo-os ou introduzindo-se novos protocolos)?;
• de que forma estas funcoes adicionais devem ser implementadas: em processado-
¸˜
res dedicados ou no n´ cleo do roteador?
u
Os n´ s que pertencem a redes sobrepostas podem ser identificados pelos mesmos
o
identificadores empregados na rede de suporte (por exemplo, atrav´ s de seus enderecos
e ¸
´
IP) ou por uma nova estrutura de nomes. Neste ultimo caso, deve-se prover tamb´ m um
e
¸˜
mecanismo de resolucao de nomes, que mapeie identificadores da rede sobreposta para
os identificadores correspondentes na rede de suporte.

3. Sessão Técnica 3 - Gereciamento Integrado 91
¸˜ `
Com relacao a topologia, algumas redes sobrepostas tˆ m sua topologia determi-
e
¸˜ ı ¸˜
nada pela localizacao f´sica onde as funcoes especializadas s˜ o necess´ rias. Um exemplo
a a
de tais redes sobrepostas s˜ o as redes VPN. Outras redes sobrepostas tentam “instalar”
a
estas funcionalidades especializadas pr´ ximas a potenciais usu´ rios. Redes sobrepostas
o a
u e ¸˜
baseadas em conte´ do geralmente mantˆ m cache de informacao pr´ ximas a grandes con-
o
sumidores.
Os esquemas de tunelamento variam de acordo com os requisitos de projeto.
T´ neis IP/IP, por exemplo, s˜ o simples. T´ neis IPsec s˜ o seguros, mas mais comple-
u a u a
xos de lidar. J´ os t´ neis MPLS (Multiprotocol Label Switching) [Rosen E. et al. 2001]
a u
¸˜
permitem encaminhamento r´ pido e roteamento baseado em restricoes. Os protocolos es-
a
pecializados, por sua vez, podem ser desenvolvidos integralmente como novos protocolos
ou apenas como extens˜ es de protocolos j´ existentes. Normalmente as extens˜ es s˜ o
o a o a
baseadas 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 tamb´ m permite m´ ltiplos
e u
projetos. Geralmente uma parte destas funcionalidades s˜ o instaladas no n´ cleo de rote-
a u
adores (push, pop e swapping de r´ tulos, por exemplo) e outra parte em processadores
o
¸˜
dedicados (funcoes de gerˆ ncia, por exemplo).
e
3. Arquitetura de Gerˆ ncia Integrada
e
¸˜
Conforme exposto na secao anterior, o dom´nio de controle de uma rede sobreposta pode
ı
a ¸˜
atingir razo´ vel complexidade. A integracao deste controle com o da rede f´sica, atrav´ s
ı e
de padr˜ es de projeto, tanto na interface com o administrador quanto na comunicacao
o ¸˜
¸˜
com os dispositivos gerenciados, pode trazer vantagens de simplificacao e eficiˆ ncia a
e `
¸˜
gerˆ ncia da rede. As subsecoes a seguir descrevem, respectivamente os casos de uso, uma
e
¸˜
vis˜ o geral e de distribuicao da arquitetura desenvolvida.
a
3.1. Casos de Uso
A Figura 1 ilustra os casos de uso de um sistema de gerˆ ncia integrada das redes de
e
suporte e sobreposta. Conceitualmente, existem duas classes de requisitos: os referentes
` ¸˜ ı ` ¸˜
a configuracao de topologia f´sica e os referentes a configuracao de topologia l´ gica.
o
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/remover
ı
novos dispositivos na rede ou alterar sua topologia f´sica, criando uma topologia nova ou
ı
modificando uma j´ existente. O requisito Salvar Topologia F´sica permite armazenar as
a ı

4. 92 XII WGRS
¸˜
informacoes de uma topologia para posterior uso. O requisito Carregar Topologia F´sica
ı
permite ao administrador informar ao sistema a topologia da rede que ser´ gerenciada,
a
¸˜
a partir de informacoes previamente armazenadas. O requisito Aplicar Topologia F´sica
ı
¸˜
tem por objetivo enviar informacoes necess´ rias aos elementos da rede, fazendo valer a
a
topologia f´sica, editada ou carregada.
ı
¸˜ ` ¸˜
Com relacao a configuracao de topologia l´ gica existem outros 5 casos de uso. Os
o
requisitos Criar T´ nel e Remover T´ nel permitem ao administrador criar um t´ nel a partir
u u u
de uma origem at´ um ou mais destinos e remover os t´ neis criados, respectivamente. O
e u
requisito Visualizar T´ nel permite ao administrador visualizar o caminho de um deter-
u
minado t´ nel criado, com base na topologia f´sica da rede gerenciada. J´ o caso de uso
u ı a
¸˜ ¸˜ ¸˜
Notificar Alteracoes T´ nel oferece ao sistema informacoes sobre a criacao e a remocao
u ¸˜
¸˜
de t´ neis, ocorridas em cada roteador da rede gerenciada. Estas informacoes refletem o
u
estado dos t´ neis da rede em um determinado instante de tempo, sendo que este estado
u
¸˜
pode ser alterado mediante acoes do administrador ou devido a fatores da pr´ pria rede
o
u a `
(por exemplo, o t´ nel solicitado n˜ o pode ser criado devido a rede n˜ o poder honrar re-
a
quisitos de QoS). Por fim, o requisito Descobrir Topologia L´ gica oferece ao sistema a
o
¸˜
informacao de todos os t´ neis que est˜ o ativos na rede.
u a
Al´ m dos requisitos levantados, como pode-se observar na Figura 1, h´ dois atores
e a
que interagem com os requisitos do sistema de gerˆ ncia: o Administrador e o Agente. O
e
´
Administrador e o ator interessado em observar e, eventualmente, (re-)configurar as topo-
ı o ¸˜
logias f´sica e l´ gica da rede. O Agente tem como responsabilidade receber a requisicao
¸ e `
dos servicos de gerˆ ncia e configurar os dispostivos, bem como alertar a gerˆ ncia a
e
¸˜ ¸˜
ocorrˆ ncia de eventos de remocao e criacao dos t´ neis.
e u
3.2. Vis˜ o Geral da Arquitetura
a
A Figura 2 ilustra o padr˜ o arquitetural do sistema integrado de gerˆ ncia proposto. O sis-
a e
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 l´ gica).
ı o
Gerenciador de
Topologia Física
Apresentação Mecanismo de Agente
Propagação de Mensagens
Gerenciador de
Topologia Lógica
˜
Figura 2. Visao Geral da Arquitetura Integrada
¸˜ ¸˜
O pacote Apresentacao agrupa as funcionalidades de edicao gr´ fica e configuracao
a ¸˜
ı o ¸˜ u ¸˜
da topologia f´sica e l´ gica (configuracao de t´ neis), bem como a apresentacao em tela do
ı ´
estado atual da rede sobreposta. O pacote Gerenciador de Topologia F´sica e respons´ vel
a
por transformar a topologia e os parˆ metros informados pelo administrador em mensa-
a
¸˜ ¸˜
gens de configuracao dos n´ s e dos dispositivos de rede. A alteracao topol´ gica deve
o o
¸˜
ainda garantir que a configuracao de cada n´ esteja consistente com a dos dispositivos de
o
¸˜
interligacao.
¸˜
Tendo configurado a rede de suporte ou iniciando a partir de uma configuracao
` ¸˜
pr´ -informada, o administrador pode dar in´cio a configuracao da rede sobreposta. A
e ı

5. Sessão Técnica 3 - Gereciamento Integrado 93
¸˜
configuracao desta rede (estabelecimento de t´ neis) se d´ via o pacote Gerenciador de
u a
Topologia L´ gica. Os t´ neis contemplados pela arquitetura proposta podem ser tanto do
o u
´
tipo 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 ultimo´
tipo de t´ nel, pacotes que ingressem no ponto de origem do t´ nel poder˜ o, de acordo com
u u a
¸˜
a pol´tica da rede, ser replicados nos pontos de bifurcacao do mesmo e entregues a todos
ı
o e ´
os pontos de destino. O pacote Gerenciador de Topologia L´ gica tamb´ m e respons´ vel a
por monitorar a topologia l´ gica existente a fim de manter a consistˆ ncia com o estado da
o e
rede sobreposta.
O pacote Agente tem basicamente duas responsabilidades: a de receber as
¸˜ ¸˜ ¸˜ `
requisicoes de configuracao da estacao de gerˆ ncia e a de notificar a mesma as eventu-
e
¸˜ ´
ais alteracoes na rede. Este pacote, portanto, e respons´ vel por repassar para os distintos
a
¸˜
dispositivos gerenciados os comandos de configuracao e receber deles os eventos a se-
¸˜ ¸˜
rem notificados na estacao de gerˆ ncia. No caso da configuracao da topologia f´sica da
e ı
rede, os dispositivos gerenciados s˜ o, por exemplo, os roteadores, switches e protocolos
a
a ¸˜
de roteamento. J´ no caso da configuracao de t´ neis, s˜ o os protocolos de sinalizacao.
u a ¸˜
´
E importante ressaltar que, com o uso dos agentes, h´ a possibilidade de coexistˆ ncia de
a e
a e ¸˜
duas ou mais instˆ ncias de gerˆ ncia, sendo que as acoes realizadas em uma refletem nas
outras e vice-versa.
¸˜ ¸˜
Realizar a comunicacao entre a estacao de gerˆ ncia e os dispositivos atrav´ s dos
e e
agentes de gerˆ ncia traz o benef´cio de tornar a gerˆ ncia independente do dispositivo
e ı e
¸˜ ı ¸˜
(configuracao f´sica), do protocolo de sinalizacao de t´ neis e do esquema de tunela-
u
¸˜ o ¸˜ ´
mento (configuracao l´ gica). Toda a comunicacao entre as entidades e realizada sobre um
mesmo padr˜ o de mensagens e realizada pelo componente Mecanismo de Propagacao de
a ¸˜
Mensagens. As mensagens recebidas pelo Agente s˜ o localmente adaptadas ao padr˜ o do
a a
correspondente dispositivo ou protocolo.
¸˜
3.3. Vis˜ o de Distribuicao da Arquitetura
a
´
A 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-
ı
o ¸˜
logia L´ gica e Mecanismo de Propagacao de Mensagens do componente Gerente s˜ o a
o ¸˜ e ¸˜ ´
executados no n´ denominado Estacao de Gerˆ ncia. O componente Apresentacao e de-
pendente dos componentes Gerenciador de Topologia F´sica e Gerenciador de Topologia
ı
o a ¸˜
L´ gica. Estes, por sua vez, s˜ o dependentes do componente Mecanismo de Propagacao
de Mensagens. Por fim, o componente Gerenciador de Topologia L´ gica tamb´ m possui
o e
dependˆ ncia do componente Gerenciador de Topologia F´sica.
e ı
Estação de Gerência
Nó Gerenciado
Gerente Agente
Apresentação Gerenciador de
Topologia Física XML/TCP Mecanismo de
Propagação de Mensagens
Gerenciador de
Topologia Lógica Mecanismo de Adaptador
Propagação de Mensagens
˜ ¸˜
Figura 3. Visao de Distribuicao da Arquitetura
a ´
J´ o componente Agente e executado em n´ s existentes na rede gerenciada. A
o

6. 94 XII WGRS
¸˜ ¸˜
comunicacao entre a Estacao de Gerˆ ncia e o N´ Gerenciado se d´ atrav´ s de envio de
e o a e
dados em mensagens XML, sobre o protocolo TCP. Por isso a dependˆ ncia do compo-
e
¸˜
nente Adaptador por parte do componente Mecanismo de Propagacao de Mensagens.
¸˜
4. Configuracao da Topologia F´sica
ı
a ı ´
Uma vis˜ o 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 se
ı
encontra as classes que representam os objetos de rede, e do pacote Gerˆ ncia, onde est´ o
e a
´
controle do Gerenciador. Este pacote e respons´ vel por editar tais objetos, manipular os
a
arquivos da topologia e aplicar a topologia f´sica na rede.
ı
¸˜ ´ ¸˜
A edicao da topologia e feita via camada de apresentacao (ver Figura 2), que altera
´
diretamente as propriedades dos objetos do pacote Modelo. E poss´vel, nesta camada,
ı
editar os dados das interfaces de rede dos n´ s (endereco IP e m´ scara de rede), dados
o ¸ a
¸˜
dos n´ s (rota default) e atributos das VLANs (nome, ativacao de GVRP - Generic VLAN
o
Registration Protocol).
O Gerenciador de Topologia F´sica permite tamb´ m modificar e salvar a topologia
ı e
¸˜
modificada em um arquivo XML e carreg´ -lo posteriormente para continuar a edicao da
a
topologia f´sica.
ı
´ ¸˜
Outra responsabilidade do pacote Gerˆ ncia e permitir a aplicacao da topologia
e
¸˜ ¸˜
criada/editada na rede, finalizando a configuracao da topologia f´sica. A aplicacao da
ı
topologia na rede consiste em configurar os roteadores e switches (respons´ veis pelo ge-
a
¸˜
renciamento de VLANs). A configuracao de cada roteador se d´ atrav´ s de um protocolo
a e
simples baseado em mensagens XML. A classe ConfiguradorRoteador cria a mensagem
¸˜
XML e ordena seu envio ao pacote Mecanismo de Propagacao de Mensagens. No caso
¸˜
de uma rede IP, as mensagens XML de configuracao dos roteadores tˆ m por objetivo al-
e
¸ a ¸˜
terar o endereco IP, a m´ scara de rede de suas interfaces de rede e a configuracao dos
protocolos de roteamento. Os Agentes (ver Figura 3) residentes nos roteadores recebem
¸˜
estas mensagens e as transformam em comandos de configuracao. O Agente responde
com uma mensagem de sucesso ou erro na configuracao. ¸˜
¸˜
Os comandos de configuracao de VLANs tamb´ m s˜ o realizados atrav´ s de um
e a e
protocolo simples baseado em mensagens XML e repassados ao switch pelo Agente, por

7. Sessão Técnica 3 - Gereciamento Integrado 95
exemplo, via interface de gerˆ ncia CLI (Command Line Interface) ou HTTP. A classe
e
ConfiguradorVLANs monta a mensagem adequada para configurar o switch e a repassa
para o Mecanismo de Propagacao de Mensagens, que por sua vez estabelece conex˜ o
¸˜ a
´
com o dispositivo e envia a mensagem. Para criar uma VLAN e necess´ rio conhecer o
a
¸˜
relacionamento entre a interface de rede do roteador com a porta conectada. Estas relacoes
a e a ¸˜
s˜ o obtidas atrav´ s de um arquivo e s˜ o representadas pela ligacao entre as classes Porta
e InterfaceRede da Figura 4.
¸˜
5. Configuracao da Topologia L´ gica
o
A Figura 5 mostra uma vis˜ o estrutural do pacote Gerenciador de Topologia L´ gica.
a o
˜ ´
Figura 5. Visao Estrutural do Gerenciador de Topologia Logica
As classes do pacote Modelo s˜ o respons´ veis, basicamente, por representar, a
a a
o o ´
topologia l´ gica. A classe TopologiaL´ gica e uma estrutura de dados do tipo grafo. Esta
´ ¸˜ ´
classe e uma composicao da classe T´ nel, que, por sua vez, e composta de n´ s que apon-
u o
tam para a interface de rede e para o roteador. Assim, o conjunto de n´ s desta classe
o
´
representa o caminho percorrido por um dado t´ nel. E importante ressaltar que o pa-
u
cote Modelo possui uma dependˆ ncia para o pacote Gerenciador de Topologia F´sica, por
e ı
´
manipular classes contidas neste ultimo.
A classe ConfiguradorTopologiaL´ gica, presente no pacote Gerˆ ncia, e res-
o e ´
pons´ vel por criar e remover os t´ neis. Os m´ todos desta classe s˜ o chamados tanto
a u e a
¸˜
pela janela de gerˆ ncia, presente no pacote Apresentacao (Figura 2), como pelo moni-
e
¸˜
tor da topologia, pois em ambas as direcoes (administrador-sistema-rede e rede-sistema-
´ ¸˜ ¸˜
administrador), e poss´vel haver criacao e remocao de t´ neis. Com efeito, os m´ todos
ı u e
desta classe s˜ o todos sincronizados.
a
´
Por ultimo, as classes MonitorTopologia e RegistradorAgentes, ambas do pacote
Gerˆ ncia, s˜ o classes auxiliares da classe ConfiguradorTopologiaL´ gica. O registrador
e a o
´
de agentes e respons´ vel por fazer registro e desregistro, em cada roteador, da instˆ ncia
a a
de gerˆ ncia interessada em manipular a rede de suporte. J´ o monitor da topologia e
e a ´
a ¸˜
respons´ vel por receber notificacoes do Agente e, assim, executar m´ todos apropriados
e
do configurador da topologia, para manter o sistema de gerˆ ncia consistente com o estado
e
real da rede gerenciada. O pacote Gerˆ ncia tem a dependˆ ncia com o pacote Mecanismo
e e
¸˜ ¸˜
de Propagacao de Mensagens, pois toda a informacao de gerˆ ncia produzida tem que ser
e
¸˜
encaminhada ao roteador de ingresso do t´ nel, no caso de uma mensagem de criacao ou
u
¸˜
remocao de t´ nel, ou aos roteadores da rede de suporte, no caso de mensagens de registro
u
ou desregistro.

8. 96 XII WGRS
´
O Agente (ver Figura 3) e respons´ vel tanto pelo processo de descoberta da to-
a
¸˜ ¸˜
pologia l´ gica quanto pela notificacao do estado dos t´ neis, enviando notificacoes por
o u
¸˜ ¸˜ ¸˜
excecao, ou seja, apenas envia informacoes quando h´ alteracoes de estado. Caso n˜ o
a a
´ ¸˜ ´
haja t´ neis, nada e enviado e, somente com a deteccao de um novo t´ nel criado e que
u u
¸˜ ` ¸˜ e ´
o agente ir´ enviar novas informacoes a gerˆ ncia. A integracao com o agente tamb´ m e
a e
¸˜
realizada atrav´ s de troca de informacoes em formato XML.
e
6. Padr˜ es de Projeto Empregados
o
¸˜
No projeto do pacote de Apresentacao (Figura 2) utilizou-se o padr˜ o a
arquitetural para sistemas interativos denominado Model-View-Controller
(MVC) [Buschmann F. et al. 1996]. O padr˜ o MVC visa separar uma aplicacao in-
a ¸˜
terativa em trˆ s componentes: um modelo, respons´ vel por conter as funcionalidades e
e a
¸˜ ¸˜ ¸˜
os dados principais da aplicacao; uma visualizacao, respons´ vel pela apresentacao em
a
¸˜
tela das informacoes ao usu´ rio e um controlador, respons´ vel pelo comportamento da
a a
interface mediante eventos produzidos pelo usu´ rio.
a
¸˜ e ´
Como a interacao com o administrador tamb´ m e um fator a ser considerado no
projeto de sistemas de gerˆ ncia, o desenvolvimento da interface gr´ fica baseou-se em
e a
padr˜ es de projeto bem conhecidos, que s˜ o descritos a seguir [Grand 1999]:
o a
Ephemeral Feedback: o prop´ sito deste padr˜ o e prover aos usu´ rios uma
o a ´ a
¸˜
realimentacao dos estados das tarefas realizadas ou solicitadas, sem interferir na
¸˜
realizacao de outras tarefas. Este padr˜ o foi adotado para que o administrador conheca o
a ¸
¸˜ ¸˜ ¸˜
estado das solicitacoes de criacao ou remocao de t´ neis. O padr˜ o tamb´ m permite que o
u a e
¸˜
administrador veja informacoes das entidades VLAN e roteador na barra de status, ao se
clicar em seus ´cones; veja a resposta do switch na caixa de logs, ao se aplicar VLANs; e
ı
¸˜ ¸˜
veja informacoes referentes aos n´ s, ao se aplicar uma nova topologia. Estas informacoes
o
¸˜ ¸˜ ¸˜
apresentadas n˜ o interferem nas tarefas de visualizacao, criacao ou remocao de outros
a
u ¸˜
t´ neis e nas tarefas de edicao da topologia f´sica pelo administrador.
ı
Window Per Task: e um padr˜ o de projeto para desenvolvimento de interfaces
´ a
¸˜
gr´ ficas que visa separar, em janelas distintas, as tarefas relacionadas. Toda a informacao
a
requerida, para o usu´ rio realizar uma tarefa, est´ dispon´vel em uma mesma janela, com
a a ı
a o ¸˜
o objetivo de deixar claro para o usu´ rio o prop´ sito de cada tela. A utilizacao deste
padr˜ o foi importante para separar as tarefas relacionadas aos t´ neis j´ criados da tarefa
a u a
¸˜
de criacao de novos t´ neis.
u
Direct Manipulation: uma interface projetada sob a otica do padr˜ o Direct Mani-
´ a
¸˜
pulation, permite que o usu´ rio realize operacoes e manipule diretamente os objetos apre-
a
¸˜ a ´
sentados por ela. Com a adocao deste tipo de padr˜ o, e poss´vel reduzir para o usu´ rio o
ı a
¸˜
modelo mental referente aos resultados de suas acoes. Este modelo foi utilizado na edicao¸˜
´ ¸˜
de topologia f´sica, onde e poss´vel ao administrador editar informacoes de roteadores e
ı ı
VLANs 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 VLANs
e roteadores clicando diretamente nos ´cones dessas duas entidades. Este modelo tamb´ m
ı e
a ¸˜ u e ¸˜
foi utilizado na janela respons´ vel pela criacao dos t´ neis, onde, atrav´ s da manipulacao
´
direta dos roteadores, e poss´vel estabelecer o caminho do t´ nel de forma intuitiva.
ı u
Supplementary Window: o intuito do padr˜ o Supplementary Window e oferecer
a ´
¸˜
ao usu´ rio uma nova janela contendo informacoes que suplementam a janela anterior
a

9. Sessão Técnica 3 - Gereciamento Integrado 97
´ ¸˜
(pai). A nova janela (filha) e respons´ vel por coletar informacoes necess´ rias para o
a a
¸˜ a ´
t´ rmino de uma operacao da janela pai. A tarefa da janela pai n˜ o e finalizada at´ que o
e e
a ¸ ¸˜ a ¸˜
usu´ rio forneca a operacao requerida na janela filha. Este padr˜ o foi utilizado na criacao
¸˜
de janelas para a edicao de VLANs, roteadores e interfaces de rede. Tamb´ m foi utilizado
e
¸˜
para a coleta da informacao de qual interface de rede de um roteador participar´ do t´ nel
a u
desejado.
7. Onix (Overlay Networks Integrated Configurator System)
´
O Onix e um sistema computacional capaz de configurar tanto a topologia f´sica de uma
ı
rede quanto a topologia l´ gica. O componente Gerente foi desenvolvido em Java 1.5 e faz
o
uso de diversos pacotes Java, dentre eles o JGraph, JDom, Java Swing e o Jakarta Com-
mons HttpClient. O componente Agente dos switches tamb´ m foi desenvolvido em Java
e
¸˜ ¸˜
e transforma as requisicoes XML em requisicoes HTTP do tipo POST. J´ o componente
a
Agente dos roteadores foi desenvolvido em C++.
¸˜
O projeto do Onix foi motivado para a gerˆ ncia de configuracao de uma rede de
e
¸˜ ¸˜
computadores real do Laborat´ rio de Computacao e Automacao da Faculdade de Enge-
o
¸˜
nharia El´ trica e de Computacao da Unicamp, composta por roteadores Linux conectados
e
atrav´ s de dispositivos de rede de camada 2. O objetivo era a gerˆ ncia de configuracao
e e ¸˜
de uma rede sobreposta com a funcionalidade espec´fica de roteamento especial para n´ s
ı o
m´ veis dentro do dom´nio. Atualmente, a rede conta com 16 roteadores com 4 interfaces
o ı
¸˜
de rede cada, 2 switches e uma estacao de gerˆ ncia. A Figura 6 ilustra o cen´ rio alvo de
e a
¸˜ ¸˜
configuracao de topologias. A estacao de gerˆ ncia, o switch e os n´ s est˜ o conectados via
e o a
¸˜ ¸˜
Rede de Configuracao, que viabiliza a comunicacao de gerˆ ncia. O switch gerenci´ vel
e a
segmenta os enlaces entre os n´ s da Rede de Topologia Configur´ vel atrav´ s da VLANs
o a e
configur´ veis.
a
´ ¸˜ ´
Figura 6. Cenario de Configuracao das Topologias F´sica e Logica
ı
A arquitetura sugerida objetiva reduzir a complexidade da gerˆ ncia de ambas as
e
ı o e ´ ¸˜
topologias f´sica e l´ gica, realizando todo esse processo atrav´ s de uma unica estacao de
e a ´ a ¸˜
gerˆ ncia e via uma interface gr´ fica integrada. Para isto e necess´ rio que a estacao de
gerˆ ncia tenha acesso ao switch (para configurar as conex˜ es atrav´ s de VLANs), aos
e o e
¸˜
roteadores (para configurar suas interfaces de rede) e aos daemons de sinalizacao (para
¸˜
configuracao de t´ neis).
u
¸˜
A configuracao de uma topologia f´sica da rede consiste em acessar cada n´ da
ı o
¸˜
rede e ajustar sua configuracao. Em um n´ de uma rede IP, p.ex., deve-se alterar o
o
endereco IP e a m´ scara de rede de cada interface de rede do n´ . Em um roteador, deve-se
¸ a o
e a ¸˜
alterar tamb´ m os parˆ metros de configuracao do protocolo de roteamento. Neste tra-
balho, considera-se que todos os n´ s (hosts e roteadores) estejam ligados diretamente a
o

10. 98 XII WGRS
¸˜
um switch com capacidade de configuracao de VLANs, tornando-se poss´vel alterar a to-
ı
¸˜
pologia atrav´ s da interface de configuracao deste dispositivo e que todos os roteadores
e
possuam um daemon de roteamento OSPF (Open Shortest Path First). O componente
¸˜ ¸˜
Agente do Onix faz a adaptacao da requisicao de servico XML para os comandos de
¸
¸˜
configuracao dos roteadores Linux e do protocolo de roteamento ou para a interface de
gerˆ ncia de VLANs no switch.
e
¸˜
Para a construcao da rede sobreposta, em cada roteador deve haver ainda,
¸˜ ¸˜
al´ m do componente Agente, um daemon de sinalizacao para construcao e remocao
e ¸˜
´ ¸˜
de t´ neis. A arquitetura proposta e independente do protocolo de sinalizacao, que
u
´
pode ser adaptado pelo componente Agente. Ainda, e preciso que a rede dˆ su- e
porte a algum esquema de tunelamento. A rede de testes j´ contava com um da-
a
¸˜
emon de sinalizacao RSVP-TE (Resource ReSerVation Protocol - Traffic Enginee-
`
ring) [R. Aggarwal, D. Papadimitriou and S. Yasukawa 2007], com suporte a sinalizacao ¸˜
de t´ neis ponto-multiponto e esquema de tunelamento IP/IP nativo do Linux. O tr´ fego
u a
u ´
nos t´ neis ponto-multiponto desta rede de testes e encaminhado a um ou mais n´ s de
o
¸˜
egresso, dependendo de sua configuracao. Caso o tr´ fego deva ser direcionado a dois
a
a ¸˜
ou mais destinos, os pacotes s˜ o duplicados no ponto de bifurcacao adequado atrav´ s de
e
¸˜
comandos nativos do Linux. Para a validacao da arquitetura, implementou-se o Agente
¸˜ a
com um adaptador para a interface de gerˆ ncia do daemon de sinalizacao j´ existente, que
e
e ´
tamb´ m e baseada em XML.
¸˜
7.1. Configuracao de Topologia F´sica no Sistema Onix
ı
Para criar uma topologia f´sica ou modificar uma pr´ -existente atrav´ s do sistema Onix,
ı e e
´
ap´ s informar o arquivo de mapeamento de portas/interfaces na janela principal, e car-
o
regado o Gerenciador de Topologia F´sica. Do lado esquerdo superior h´ uma caixa de
ı a
´
ferramentas, por onde e poss´vel inserir VLANs, enlaces, inspecionar propriedades de
ı
elementos (n´ , VLAN) e aplicar a topologia f´sica na rede. Do lado esquedo inferior h´
o ı a
¸˜ ¸˜
uma 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 atrav´ s da biblioteca JGraph.
ı e
Ao clicar com o bot˜ o direito do mouse sobre um n´ , pode-se abrir sua caixa de
a o
a ¸˜
propriedades, ilustrada na Figura 7, onde h´ opcoes para editar a rota default do n´ , o
o
¸ a ´
endereco IP, a m´ scara de rede e a area do protocolo de roteamento de suas interfaces de
rede. Se a interface de rede for a de gerˆ ncia, pode-se editar o nome da interface.
e
Pode-se inserir VLANs na topologia f´sica clicando sobre o ´cone de VLAN na
ı ı
caixa de ferramentas e depois clicando sobre alguma regi˜ o da topologia f´sica. Uma nova
a ı
caixa de propriedades ser´ aberta, onde dever˜ o ser informados identificador, o nome da
a a
¸˜
VLAN e a ativacao (ou n˜ o) do protocolo GVRP. Ap´ s inserir alguns enlaces tem-se
a o
¸˜
a topologia mostrada na Figura 8, terminando assim a configuracao da topologia f´sica. ı
Para aplicar a topologia f´sica, existem 2 bot˜ es na caixa de ferramentas: uma para aplicar
ı o
¸˜
(gravar) todas as VLANs no switch e outro para aplicar as configuracoes em todos os n´ s. o
´ poss´vel tamb´ m aplicar cada VLAN individualmente no switch e aplicar a configuracao
E ı e ¸˜
em cada n´ individualmente. Para isto, basta clicar com o bot˜ o direito sobre a entidade
o a
¸˜ ¸˜
desejada na representacao da topologia e escolher a opcao de aplicar. Por´ m, para finalizar
e
¸˜ ´
por completo a configuracao da topologia f´sica, e necess´ rio aplicar todas as entidades
ı a
na rede configur´ vel.
a

11. Sessão Técnica 3 - Gereciamento Integrado 99
¸˜
Figura 7. Edicao
de Propriedades ´
Figura 8. Interface Grafica do Gerenciador
do Roteador de Topologia F´sica
ı
¸˜
7.2. Configuracao de Topologia L´ gica no Sistema Onix
o
Depois de aplicar toda a topologia f´sica na rede configur´ vel, pode-se realizar a
ı a
¸˜ o a `
configuracao da topologia l´ gica, que estar´ sobreposta a topologia f´sica configurada.
ı
Na aba Logical Topology Manager, a interface do sistema Onix altera seus componentes
´
visuais, oferencendo ao administrador uma area de trabalho contendo apenas componen-
¸˜ ´ ´
tes necess´ rios para a realizacao da gerˆ ncia da topologia l´ gica. A area de trabalho e
a e o
ent˜ o dividida em trˆ s partes principais. A parte do lado superior esquerdo oferece a
a e
¸˜ ¸˜ ¸˜
possibilidade de criacao, remocao e visualizacao dos t´ neis. A parte inferior esquerda
u
¸˜ ¸˜
apresenta ao administrador o resultado de suas acoes de gerˆ ncia, bem como acoes re-
e
` ´
alizadas pelo pr´ prio sistema. A parte localizada a direita e onde o administrador pode
o
visualizar a topologia f´sica gerenciada e o caminho de um dado t´ nel.
ı u
¸˜ u ´
Para a criacao de um t´ nel e preciso que o administrador clique com o bot˜ o direito
a
´ ´
na area em branco do lado superior esquerdo da area de trabalho e escolha a opcao de ¸˜
criar um t´ nel no menu popup que aparece. Aparecer´ uma janela, onde o administrador
u a
a a ¸˜
poder´ estabelecer o caminho e definir os parˆ metros para a criacao do t´ nel. Para o
u
estabelecimento do caminho, faz-se necess´ rio que o administrador clique em cima do
a
roteador desejado e selecione uma interface. Ao final do processo de configuracao do ¸˜
¸˜ ¸˜
caminho, o sistema transformar´ a representacao visual em uma requisicao de criacao de
a ¸˜
a a ¸˜
t´ nel e, ent˜ o, enviar´ ao agente do servidor de sinalizacao de origem do t´ nel.
u u
Caso o t´ nel seja criado com sucesso, o administrador poder´ removˆ -lo ou visu-
u a e
alizar o seu caminho. Para remover, o administrador necessita apenas clicar com o bot˜ o
a
¸˜ ¸˜
direito em cima do t´ nel e selecionar a opcao de remover o t´ nel. Para a visualizacao
u u
do caminho, o administrador necessita clicar com o bot˜ o esquerdo em cima do mesmo.
a
¸˜
Para esta acao, o sistema ir´ tracar, em cima da topologia da rede de suporte, o caminho
a ¸
u ¸˜
deste t´ nel. A Figura 9 ilustra um exemplo da visualizacao de um t´ nel.
u
8. Conclus˜ es
o
Redes sobrepostas vˆ m sendo empregadas nos mais diversos cen´ rios de oferecimento
e a
¸ ı ¸˜
de novos servicos sobre as redes de transporte existentes. Os benef´cios da criacao de

12. 100 XII WGRS
¸˜
Figura 9. Exemplo de Visualizacao de um Tunel
´
novos planos de controle e encaminhamento dedicados aos novos servicos tendem a se
¸
contrapor a um aumento na complexidade da gerˆ ncia das redes f´sica e sobrepostas. Este
e ı
¸˜
artigo apresentou o projeto e implementacao de um sistema integrado de gerˆ ncia que tem
e
por meta minimizar a complexidade de gerˆ ncia introduzida pelas redes sobrepostas.
e
O sistema vem sendo utilizado com sucesso na gerˆ ncia de uma rede de 16 rote-
e
`
adores que oferece suporte a mobilidade de terminais IP. A rede f´sica consiste de uma
ı
topologia densamente conectada, enquanto a topologia da rede sobreposta consiste de
a u ´
t´ neis ponto-multiponto. O tr´ fego nos t´ neis da rede sobreposta e direcionado para o n´
u o
u a o ¸˜
de egresso do t´ nel capaz de atingir o destinat´ rio (terminal m´ vel). Uma sinalizacao de
mobilidade faz com que o encaminhamento na rede sobreposta seja atualizado em funcao ¸˜
da mobilidade dos terminais.
¸˜
O sistema Onix tem se mostrado de grande utilidade na configuracao de topologias
f´sicas e l´ gicas de teste e seu n´ cleo ser´ a base de um sistema de engenharia de tr´ fego,
ı o u a a
que permitir´ a tolopogia da rede sobreposta se ajustar de forma autom´ tica em resposta
a a
` ¸˜
as condicoes de tr´ fego desta rede.
a
Referˆ ncias
e
Buschmann 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 Conference
of the IEEE Computer and Communications Societies.
R. Aggarwal, D. Papadimitriou and S. Yasukawa (2007). Extensions to RSVP-TE for
Point-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.