Gerência de Configuração de Estações de Medição de Tráfego Baseadas no Pacote CoralReef

Luís Felipe Balbinot <hades@exatas.unisinos.br>
Luciano Paschoal Gaspary <paschoal@exatas.unisinos.br>

Pesquisa em Redes de Alta Velocidade (PRAV)
Universidade do Vale do Rio dos Sinos (UNISINOS)

Resumo
Abstract
1. Introdução
2. Pacote Coral Reef
2.1. Software
2.2. Hardware
2.3. Metodologia de Medição de Tráfego
2.3. Scripts de Medição de Tráfego
3. Script MIB
4. Gerenciando o Coral Reef Através da Script MIB
4.1. Java Script MIB Implementation (Jasmin)
4.2. Sistema de Execução Perl
4.3 Operação
5. Conclusões e Trabalhos Futuros
7. Bibliografia

Resumo

CoralReef é um pacote de software destinado ao monitoramento passivo de enlaces ATM. As ferramentas que compõem o pacote são parametrizáveis, permitindo que o gerente da rede defina os indicadores a serem medidos. Para tal, a metodologia disponível é composta de quatro passos: (1) configuração das interfaces, (2) configuração do modo de captura, (3) coleta de tráfego e (4) processamento e geração de resultados. Esses quatro passos podem ser realizados na console da estação ou através de sessões remotas. A metodologia não é plausível em redes onde vários enlaces são monitorados. Este trabalho apresenta uma abordagem escalável e flexível para o gerenciamento de configuração do pacote. O artigo propõe a utilização da Script MIB do IETF, como uma interface entre um gerente da rede e as estações de medição de tráfego distribuídas.

Abstract

CoralReef is a software package for the passive monitoring of ATM links. The tools that make up the package are configurable, thus enabling the network manager to define the indicators to be measured. In order to achieve that, the methodology is made up of four steps: (1) network interfaces configuration, (2) capture mode configuration, (3) traffic collection and (4) result processing and generation. These four steps may be performed at the station console or through remote sessions. This methodology is not feasible for networks where several links are monitored. This paper presents a scalable and flexible approach for the configuration management of CoralReef-based traffic measurement stations. The paper proposes the use of the IETF Script MIB as an interface between network managers and the distributed traffic measurement stations.

1. Introdução

As redes de computadores cresceram muito rapidamente nos últimos anos, grande parte graças à Internet, e novas tecnologias começaram a ser empregadas para suportar esse crescimento. Os enlaces, que há poucos anos atrás não passavam dos 45 Mbps, agora chegam a 40 Gbps e, como se não bastasse o aumento da velocidade, novos serviços começaram a ser fornecidos. Esses avanços requerem um sistema de monitoramento de alto desempenho, capaz de realizar a caracterização do tráfego e da tendência de uso dos enlaces.

Métodos tradicionais de monitoramento de redes, como os que fazem polling em intervalos de minutos, não são adequados, já que eles não são capazes de capturar o comportamento do tráfego em rajadas, o que é importante em redes onde algum nível de garantia de serviço é oferecida. Outros métodos de coleta de estatísticas utilizados em roteadores, como o Cisco Netflow, influem na capacidade de envio de pacotes (monitoramento ativo), além de serem inflexíveis e de não suportarem a coleta contínua de tráfego [ 1 ].

CoralReef é o nome dado a um pacote de software distribuído pelo Cooperative Association for Internet Data Analysis (CAIDA) ¹ . Esse pacote permite o monitoramento passivo e não intrusivo de interfaces ATM e inclui APIs de programação e softwares para captura, análise e geração de relatórios. A flexibilidade e o baixo custo da solução proposta pelo CAIDA está fazendo com que cada vez mais monitores baseados nessa solução sejam instalados pelo mundo.

Um dos principais problemas relacionados com o pacote é a falta de um modelo uniforme de gerenciamento. Mesmo suportando um mecanismo rudimentar de configuração, a operação de um monitor CoralReef se resume a scripts executando como cron jobs em momentos predeterminados. Essa metodologia é suficiente quando poucos monitores são gerenciados, mas, em um conjunto distribuído com vários monitores, alguns problemas, como o controle de versão dos scripts e a obtenção dos resultados distribuídos, começam a aparecer.

O trabalho apresentado neste artigo propõe a utilização da Script MIB, do Internet Engineering Task Force (IETF), como uma interface entre o gerente da rede e a estação de medição de tráfego. A proposta apresentada está baseada na integração dessa MIB com os monitores distribuídos, seguindo uma abordagem mais automatizada, controlada e padronizada. Esse mecanismo permite que um gerente remoto seja capaz de delegar e controlar scripts nos monitores distribuídos. Através dessa proposta os problemas mais comuns são solucionados.

O restante do artigo está organizado da seguinte forma: na Seção 2 a plataforma CoralReef é descrita em maiores detalhes, dando uma visão geral do seu funcionamento e de suas características principais; na Seção 3 a Script MIB é descrita; na Seção 4 o projeto de integração da Script MIB com o pacote CoralReef é detalhado; na Seção 5 são apresentados os primeiros resultados e os trabalhos futuros.

2. Pacote Coral Reef

O pacote CoralReef é composto por um conjunto de ferramentas e bibliotecas capazes de armazenar e instrumentar fluxos de células ATM vindos de interfaces OC-x ou de arquivos previamente capturados. Esses arquivos podem conter tanto células capturadas das interfaces OC-x quanto podem ser arquivos de captura da biblioteca pcap. Apesar de suportar a leitura de células ATM individuais, o uso maior da plataforma está voltado ao estudo de protocolos de níveis acima, principalmente os pacotes IP sobre ATM. A organização dos componentes do CoralReef pode ser melhor compreendida pela ilustração da Figura 1 .

Figura 1: Componentes do CoralReef.

2.1. Software

O CoralReef foi desenvolvido em C++ e possui interfaces para as linguagens C/C++, através da libcoral, e para a linguagem Perl, através do módulo CRL.pm (ver Figura 1 ). Várias ferramentas, grande parte desenvolvidas em Perl, acompanham o pacote. Graças ao Simplified Wrapper and Interface Generator (SWIG), todas as funções em C da libcoral podem ser acessadas de forma eficiente por programas em Perl.

Uma biblioteca extra, a Unpack, é fornecida para otimizar o processo de extração de campos do cabeçalho dos pacotes IP, já que o método utilizado pelo Perl não é muito eficiente dentro de laços curtos (ele extrai todos os campos do cabeçalho, mesmo que eles não sejam necessários). O SWIG permite que as funções em C, que são mais eficientes, consigam ser acessadas de forma bastante transparente por programas em Perl. As interfaces ATM são configuradas através de firmwares reprogramáveis, permitindo que vários modos diferentes de coleta de células sejam realizados. Os modos mais utilizados são o de captura da primeira célula de cada frame AAL5 (que contém o cabeçalho do IPv4), das primeiras duas células de cada frame AAL5 (que contém o cabeçalho do IPv6) ou de todas as células, para análises mais detalhadas de qualidade de serviço (QoS) ou para testes de conformação de tráfego.

A maioria das ferramentas que acompanham o pacote são utilizadas para gerar relatórios bem específicos, deixando a complexidade nas pontas: é responsabilidade do programador de uma aplicação de medição de tráfego juntar e processar adequadamente os resultados obtidos. Apesar disso, por terem o código-fonte aberto, essas ferramentas servem como ótimo ponto de partida para o desenvolvimento de novas aplicações.

O sistema operacional utilizado é o FreeBSD ² 4.0-RELEASE. Ele roda um kernel especialmente modificado com drivers para as interfaces ATM.

2.2. Hardware

O hardware recomendado pelo CAIDA para uso nos monitores é composto por um computador Pentium II de 400 MHz ou superior, no mínimo 256 MB de memória ECC, uma interface Ethernet, duas interfaces ATM suportadas ³ , unidades de armazenamento UW/SCSI (6 GB ou mais) e um gabinete ATX industrial de 19".

São utilizados splitters ópticos para permitir que os monitores consigam ver a luz viajando pelas fibras ópticas. Para dividir a luz são utilizados dois desses splitters, ambos com taxa de divisão 90/10, ou seja, 90% da luz segue passivamente (com um pouco de atenuação) para o destino, enquanto que os 10% restantes são desviados para as interfaces ATM no monitor. Mesmo que enlaces com fibras monomodo sejam monitorados, a atenuação resultante dos splitters permite que a luz seja injetada nas interfaces multimodo sem causar danos. Em alguns casos pode ser necessário o uso de repetidores ópticos, devido à atenuação causada pelos splitters.

2.3. Metodologia de Medição de Tráfego

A metodologia adotada está baseada em experiências realizadas com um monitor instalado na Rede Metropolitana da Grande Porto Alegre (MetroPoa) ⁴ , localizado no enlace STM-1 que conecta o laboratório de Pesquisa em Redes de Alta Velocidade (PRAV), na Universidade do Vale do Rio dos Sinos (UNISINOS), com a Companhia Riograndense de Telecomunicações (CRT). Essa rede é um testbed para pesquisas, e faz parte da Internet 2 brasileira, fundada pela Rede Nacional de Pesquisa (RNP) através do edital de Redes Metropolitanas de Alta Velocidade (ReMAV).

A metodologia de medição de tráfego é apresentada no diagrama da Figura 2 . Dois splitters ópticos desviam parte da luz viajando em cada sentido do enlace para as duas interfaces ATM da estação monitora: a luz vinda de ambas portas de transmissão, uma em cada sentido do enlace, é injetada nas portas de recepção das interfaces ATM, permitindo à estação observar o fluxo de células ATM de ambas direções. A captura do tráfego nas duas direções pode ser feita de forma independente.

Para realizar a captura são disparados scripts em Perl, em intervalos constantes de tempo. Esses scripts geram relatórios em HTML, alimentam bancos de dados com estatísticas, ou simplesmente capturam células para arquivos de trace. Alguns parâmetros podem ser passados para os scripts, definindo o tempo de duração da captura, o tipo de encapsulamento IP sobre ATM utilizado, o modo de captura de células, entre outras opções. Para tornar o processo um pouco mais flexível, são suportados arquivos de configuração contendo essas opções.

Figura 2:Metodologia de monitoramento.

2.3. Scripts de Medição de Tráfego

Os scripts para medição de tráfego são geralmente bem específicos, muitas vezes sendo necessário combinar os resultados produzidos por mais de um deles a fim de chegar a uma estatística conclusiva. Boa parte dos scripts usados para a medição de tráfego são desenvolvidos em Perl e tendem a ser bastante pequenos, graças aos recursos e facilidades oferecidos por essa linguagem.

Figura 3 :Script em Perl para contabilizar pacotes IP baseado no campo ToS.

Na Figura 3 é apresentado o código-fonte de um script exemplo, desenvolvido em Perl. Esse script é uma versão modificada da ferramenta crl_tos, que acompanha o CoralReef. A saída desse script (ver Figura 4 ) apresenta a contabilização dos pacotes IP, agrupados pelo valor do seu campo ToS. No exemplo ilustrado, observou-se num intervalo de tempo de 300 segundos a presença de 159 pacotes com o campo ToS igual a 0xc0 (192), 3.458 pacotes com o ToS igual a 0xef (239) e 239.584 pacotes com o ToS igual a 0x0 (0). A saída desse script pode ser adaptada para gerar uma tabela em HTML ou pode até mesmo ser usada para gerar um gráfico com o gnuplot.

3. Script MIB

A Script MIB [ 3 ] foi desenvolvida pelo grupo de trabalho Distributed Network Management (DISMAN) ⁵ , do IETF, e publicada em maio de 1999 como um proposed standard. A Script MIB permite que processos remotos (ou scripts) sejam iniciados, controlados e terminados através do framework de gerenciamento SNMP. A especificação da MIB é muito sucinta ao descrever o que são scripts e, até onde lhe diz respeito, um script é um pedaço de código capaz de ser executado pelo agente remoto que implementa a MIB.

A operação da Script MIB resume-se a operações realizadas nas seis tabelas que a constituem. Um gerente que deseja delegar um script deve primeiro verificar a tabela smLangTable, que lista todas as linguagens suportadas pela implementação da Script MIB no agente. Além de verificar essa tabela, ele também pode verificar a tabela smExtsnTable, que contém todas as extensões suportas pelas linguagens instaladas (ex.: um pacote Java para acesso SNMP). Essas duas tabelas só podem ser acessadas para leitura, já que é o agente quem possui controle sobre quais são as linguagens e extensões suportadas.

Baseado nas informações obtidas nas tabelas de linguagens e extensões, o gerente deve selecionar um script apropriado de um repositório. Esse script deve ser registrado em uma nova linha criada na tabela smScriptTable, que contém uma lista de todos os scripts conhecidos pelo agente. Esses scripts podem ser instalados permanentemente ou podem ser obtidos através dos modelos client pull ou server push. O modelo client pull requer que apenas um URL seja escrito nessa linha da tabela para que o agente possa fazer o download do script. Já o modelo server push requer que o script seja escrito linha por linha na tabela smCodeTable, através de diversos PDUs contendo SNMP SetRequests. A implementação desse último modelo não é obrigatória pela definição da Script MIB e a sua atual funcionalidade foi questionada em [ 4 ]. Outras operações, como a leitura e deleção de scripts, também são suportadas por essa tabela.

Para que os scripts sejam disparados é preciso que uma entrada seja criada na tabela smLaunchTable. Nessa tabela é descrito o ambiente de execução para cada script, incluindo os argumentos que serão passados, o tempo máximo de vida e a identificação do dono do script. Um objeto gerenciável nessa tabela, chamado smLaunchStart, inicia a execução de um script com apenas um SNMP SetRequest (com a Schedule MIB [ 5 ], por exemplo). Várias instâncias de um mesmo script podem ser criadas através de uma única entrada nessa tabela e várias entradas dessa tabela podem apontar para um mesmo script na tabela smScriptTable. Dessa forma pode-se ter vários scripts iguais em execução, mas com argumentos ou permissões diferentes.

Cada script disparado possui uma linha criada na tabela smRunTable automaticamente. Essa tabela possui a lista de todos os scripts que estão executando ou que terminaram a sua execução recentemente. Através dessa tabela um gerente pode controlar os scripts em execução, assim como pode obter os resultados intermediários ou finais gerados por eles. O resultado final é mantido no agente até que o seu tempo de vida expire.

Como mecanismo de segurança, a Script MIB suporta todas as facilidades oferecidas pelo SNMPv3, incluindo o User-based Security Model (USM) [ 6 ] e o View-based Access Control (VACM) [ 7 ]. Em [ 8 ], os autores descrevem em detalhes os aspectos de segurança relacionados com a Script MIB.

4. Gerenciando o Coral Reef Através da Script MIB

Foram identificados três requisitos principais para permitir o gerenciamento do pacote CoralReef através da Script MIB:

A implementação da Script MIB deve prover um ambiente de execução capaz de executar scripts escritos em linguagens suportadas pelas bibliotecas do CoralReef.
A implementação da Script MIB deve fornecer mecanismos de segurança para garantir uma comunicação segura entre os gerentes e os agentes localizados nos monitores distribuídos.
A implementação da Script MIB deve ser capaz de escalar de forma flexível à medida que novos recursos sejam adicionados ao CoralReef ou a outros softwares que suportam a sua operação.

Após identificar os passos, foi dado início ao processo de escolha de qual implementação da Script MIB seria utilizada. Existem pelo menos três implementações conhecidas, mas a que mais se destaca é a desenvolvida pela TU Braunschweig e pelo NEC C&C Research Laboratories, conhecida como Java Script MIB Implementation, ou Jasmin (ver Seção 4.1 ). Essa foi a nossa opção pois ela permite que diversos sistemas de execução para linguagens diferentes sejam instalados e estendidos de uma forma bastante flexível. A segurança do Jasmin fica por conta do protocolo SNMPv3 e pelos mecanismos internos que são implementados.

Atualmente o CoralReef fornece interfaces nativas apenas para as linguagens C/C++ e Perl, ambas ainda não suportadas pelo Jasmin, o que obriga o desenvolvimento de um sistema de execução para pelo menos uma dessas linguagens. Desenvolver um sistema de execução para as linguagens C/C++ seria uma tarefa complicada, já que a melhor abordagem nesse caso seria realizar a transferência de código-objeto para os agentes distribuídos e depois realizar a ligação desse código, assim como foi proposto por Goldszmidt no seu modelo Management by Delegation (MbD) [ 9 ]. Essa abordagem pode trazer diversos problemas relacionados com segurança, controle de uso dos recursos, portabilidade e depuração de scripts, além dessas linguagens não serem ideais para o desenvolvimento de scripts. Por outro lado, desenvolver um sistema de execução para a linguagem Perl mostrou ser uma alternativa melhor e mais adequada, já que essa linguagem possui características inerentes para o desenvolvimento de scripts, além de proporcionar a interoperabilidade entre plataformas de uma forma bastante transparente.

O restante desta seção descreve a implementação do Jasmin, a nossa abordagem para a integração dessa implementação da Script MIB com o CoralReef e a metodologia resultante para realizar a medição de tráfego na plataforma.

4.1. Java Script MIB Implementation (Jasmin)

O Jasmin ⁶ , ou JAva Script Mib ImplementatioN, é um projeto onde o objetivo principal é testar na prática a funcionalidade da especificação da Script MIB e compartilhar os resultados obtidos com o grupo de trabalho DISMAN, do IETF. A Figura 5 ilustra a estutura interna da implementação.

Figura 5:Estrutura interna da implementação do Jasmin.

A implementação suporta múltiplos ambientes de execução para linguagens diferentes. Isso é possível através do Script MIB Extensibility Protocol (SMX) [ 10 ], que cria uma interface entre o agente Jasmin e os sistemas de execução. Esse protocolo utiliza primitivas simples e roda com uma conexão TCP local, que é suportada pela maioria das linguagens mais conhecidas. Os sistemas de execução são iniciados pelo kernel do Jasmin e um mecanismo local de segurança realiza a autenticação desses sistemas. O protocolo suporta o envio de mensagens de forma síncrona (p. ex., requisitando o início da execução de um script) ou assíncrona (p. ex., a notificação do término da execução de um script).

O Jasmin possui dois perfis de segurança. O primeiro perfil é o operating system security profile, que especifica quais são os serviços do sistema operacional que são disponibilizados para um sistema de execução. O segundo perfil é o runtime security profile, que é dependente do sistema de execução. Nesse perfil, uma string contendo as definições de segurança é passada para o sistema de execução via o protocolo SMX e é tarefa do sistema de execução mapear essa string para políticas locais de acesso e uso de recursos.

4.2. Sistema de Execução Perl

A abordagem adotada para o desenvolvimento do sistema de execução Perl é apresentada na Figura 6 . O sistema de execução está sendo desenvolvido na linguagem C++, já que o fato desse sistema executar scripts em Perl não obriga que ele também tenha que ser desenvolvido nessa linguagem. A escolha pela linguagem C++ se deu por ela ser mais robusta e eficiente, além de oferecer um melhor suporte ao uso de sockets e threads.

Figura 6:Estrutura do sistema de execução Perl.

O Script Manager é a entidade responsável pela comunicação via protocolo SMX com o agente Jasmin. Cada script presente no sistema de execução é executado dentro de uma thread (Script Thread). Essas threads funcionam como wrappers para os scripts sendo executados e, na prática, nada mais fazem do que abrir pipes para o interpretador Perl.

Sempre que um script é disparado, o Jasmin passa uma string contendo políticas de segurança para o ambiente de execução. O Script Manager interpreta essa string e a transforma em políticas locais de segurança para acesso e uso de recursos. Essas políticas definem, por exemplo, a prioridade dada à Script Thread que irá executar o script.

A implementação prevê o uso de três mecanismos diferentes de segurança. O primeiro deles está no uso obrigatório da cláusula ``use strict'' nos scripts. Essa cláusula faz com que o interpretador Perl realize uma verificação mais rígida do código-fonte. Dessa forma pode ser possível prevenir que strings tornem-se variáveis ou pode-se obrigar o uso do modificador ``my'' antes de todas as declarações de variáveis locais. O segundo mecanismo envolve o uso de tainted variables. Todas as variáveis que recebem informações de fora dos scripts são marcadas e, se o valor dessas variáveis se propagar para outras variáveis, essas também são marcadas. Esse mecanismo realiza a verificação do escopo de uso das variáveis marcadas, impedindo que informações vindas de fora de um script (p. ex., através de um pipe) sejam utilizadas em comandos de acesso ao sistema (p. ex., eval(), system() e exec()). O último mecanismo é implementado através de uma Safe class, que usa o conceito de compartments (similares à sandbox do Java). Todas as operações consideradas inseguras podem ser realizadas dentro desses compartments, que são ambientes de execução capazes de restringir o acesso às funções do sistema.

4.3 Operação

A integração dos diversos recursos - ambos hardware e software - envolvidos na operação de um monitor baseado no pacote de software CoralReef é uma das etapas mais importantes da pesquisa sendo realizada. A Script MIB fornece a padronização e os meios para permitir o gerenciamento dos scripts, mas isso de nada adianta se a metodologia de operação do conjunto não for adequada. A integração dos recursos deve ser feita de forma a maximizar a portabilidade e a escalabilidade e minimizar os problemas de gerenciamento.

A metodologia de operação que será adotada para os monitores na rede MetroPoa é mostrada na Figura 7 . Os scripts em Perl, que são gerenciados pelo Jasmin, possuem acesso aos serviços do CoralReef, que por sua vez possui acesso ao hardware de captura ou aos arquivos de trace. Um sistema de arquivos compartilhado atua como meio de armazenamento e troca de resultados entre scripts. Um diretório dentro desse sistema de arquivos é usado como raiz de um servidor web, permitindo que desde simples arquivos de trace até elaborados relatórios sejam disponibilizados às estações de gerenciamento ou até mesmo a outros monitores remotos. Os scripts disponíveis são armazenados em um repositório e podem ser obtidos através dos protocolos FTP e HTTP.

Figura 7:Metodologia de operação.

É importante notar que a metodologia proposta não prevê a troca de resultados diretamente através dos recursos oferecidos pela Script MIB. A Script MIB possui somente uma linha na tabela smRunTable reponsável pelo armazenamento de resultados, o que não é suficiente para a troca de resultados mais complexos. Para contornar essa limitação, a implementação prevê o uso de URLs como resultados, ou seja, o resultado de um script é armazenado em um servidor web (que pode ser implementado por um script) e a URL para este resultado é retornada para a MIB. Um gerente pode então visualizar os resultados através de um navegador qualquer. Isso não impede que resultados sejam gerados da forma tradicional (p. ex., um script pode retornar uma informação textual reportando o estado da sua execução).

O CoralReef não permite que múltiplos scripts realizem a captura de células simultaneamente usando a mesma interface. O que se faz é realizar o processamento de arquivos de trace previamente capturados, permitindo que uma ou mais ferramentas se utilizem desses arquivos. Nessa metodologia um script pode ser agendado para executar em intervalos regulares (p. ex., a cada 30 minutos), realizando a captura para um arquivo de trace em algum local dentro do sistema de arquivos compartilhado (o caminho para o arquivo pode ser indicado pelo resultado da execução do script). O script da Figura 3 pode ser agendado para executar logo após o término do script de captura, tendo como parâmetro o caminho para o arquivo de trace capturado pelo primeiro script. Esse script pode então realizar o processamento em paralelo a outros scripts, gerando relatórios (nesse exemplo poderia ser uma tabela em HTML) e retornando as URLs desses relatórios para o agente Script MIB.

5. Conclusões e Trabalhos Futuros

Neste trabalho apresentou-se uma proposta para o gerenciamento de configuração de estações de medição de tráfego baseadas no pacote de software CoralReef. A mesma está baseada no uso do Jasmin, uma implementação conhecida da Script MIB, para permitir que o gerenciamento de diversos monitores distribuídos seja feito de forma padronizada, segura e sistemática. Mostrou-se que, através dos mecanismos propostos, problemas como o controle da execução e a parametrização dos scripts, bem como o processamento e a recuperação dos resultados, são eliminados.

Acredita-se que os esforços despendidos no gerenciamento das estações de monitoramento sejam bem menores do que os atualmente praticados. Os scripts utilizados não precisam ser modificados para serem utilizados nessa nova metodologia. Além disso, os resultados gerados pelos mesmos passam a ficar disponíveis em servidores web e, portanto, acessíveis de qualquer local.

O grupo está atualmente trabalhando no desenvolvimento da integração do pacote de software CoralReef e da Script MIB. Por enquanto o Jasmin só foi testado nos sistemas operacionais Solaris e Linux. Como o pacote CoralReef depende do kernel do FreeBSD, alguns testes de funcionalidade do Jasmin e das máquinas virtuais Java disponíveis para esse sistema operacional estão sendo realizados. Paralelamente está sendo implementado o sistema de execução Perl proposto.

Até o momento o Jasmin ainda não está sendo distribuído livremente. Tão logo ele esteja disponível, serão realizados testes procurando validar a integração da gerência da plataforma com o framework de gerenciamento distribuído da arquitetura Internet. Os aspectos de segurança relacionados aos scripts e ao acesso aos resultados precisam ser melhor estudados.

O trabalho apresentado, assim como o realizado por Jürgen Quittek e Cornelia Kappler em [ 11 ], mostram que a Script MIB é bastante flexível e não precisa ficar limitada apenas ao uso em equipamentos de rede, como roteadores ou comutadores. A especificação da Script MIB é muito mais ampla do que isso, e permite que ela seja facilmente adaptada ao gerenciamento de diversos recursos, sejam eles distribuídos ou não.

7. Bibliografia

[1] C. Courcoubetis and V. A. Siris. Measurement and analysis of real network traffic. Techinical Report 252, ICS-FORTH, March 1999.

[2] J. Apisdorf, K. Claffy, K. Thompson, and R. Wilder. OC3MON: Flexible, Affordable, High-Performance Statistics Collection. In Proc. of INET'97, 1997. Disponível em http://www.nlanr.net/NA/Oc3mon/.

[3] D. Levi and J. Schönwälder. Definitions of Managed Objects for the Delegation of Management Scripts. RFC 2592, SNMP Research, TU Braunschweig, May 1999.

[4] The Simple Times, 7(2), November 1999.

[5] D. Levi and J. Schönwälder. Definitions of Managed Objects for Scheduling Management Operations. RFC 2591, Nortel Networks, TU Braunschweig, May 1999.

[6] U. Blumenthal and B. Wijnen. User-based Security Model (USM) for version 3 of the Simple Network Management Protocol. RFC 2274, January 1998.

[7] B. Wijnen, R. Presuhn, and K. McCloghrie. View-based Access Control Model for the Simple Network Management Protocol. RFC 2275, January 1998.

[8] J. Schönwälder and J. Quittek. Secure Management by Delegation within the Internet Management Framework. In Proc. 6th International Symposium on Integrated Network Management, Boston, May 1999.

[9] G. Goldszmidt and Y. Yemini. Distributed Management by Delegation. In Proc. 15th Int. Conf. on Distributed Computing Systems (ICDCS'95). IEEE Press, Vancouver, Canada, May 1995.

[10] J. Schönwälder and J. Quittek. Script MIB Extensibility Protocol Version 1.0. RFC 2593, TU Braunschweig, NEC Europe Ltd., May 1999.

[11] J. Quittek and C. Kappler. Remote Service Deployment on Programmable Switches with the IETF SNMP Script MIB. In Proc. of DSOM'99. Springer Verlag, Zurich, 1999.

Notas

1- ver http://www.caida.org/

2- ver http://www.freebsd.org/

3- ver http://www.metropoa.tche.br/

4- ver http://www.ietf.org/html.charters/disman-charter.html

4- ver http://www.ibr.cs.tu-bs.de/jasmin/