GRUPO XVI GRUPO DE ESTUDO DE SISTEMAS DE INFORMAÇÃO E TELECOMUNICAÇÃO PARA SISTEMAS ELÉTRICOS

SNPTEE SEMINÁRIO NACIONAL DE PRODUÇÃO E TRANSMISSÃO DE ENERGIA ELÉTRICA GTL - 15 16 a 21 Outubro de 2005 Curitiba - Paraná GRUPO XVI GRUPO DE ESTUDO DE SISTEMAS DE INFORMAÇÃO E TELECOMUNICAÇÃO PARA SISTEMAS ELÉTRICOS IMPLANTAÇÃO DE PLATAFORMAS DE GERENCIAMENTO DE REDE EM UMA EMPRESA DE ENERGIA ELÉTRICA Aloivo Bringel Guerra Jr Ednei Teruaki Iamaguti * Márcio Luiz Ferreira Miguel COPEL TELECOMUNICAÇÕES COPEL TELECOMUNICAÇÕES COPEL TELECOMUNICAÇÕES RESUMO Em uma rede de dados em que os seus elementos são essenciais para o fornecimento de uma infra-estrutura confiável, com alta disponibilidade e segurança é necessário a utilização de métodos e sistemas para o gerenciamento dos elementos físicos e lógicos que a compõem. Foi utilizado para este fim várias plataformas de gerenciamento visando atender algumas das áreas que englobam uma completa gerência de rede. Neste trabalho focaremos nas áreas em que a Copel Telecomunicações atualmente está implantando que são Falhas, Desempenho, SLA e Ativação. PALAVRAS-CHAVE Gerenciamento, Monitoração, Sistemas, Rede, Telecomunicações 1.0 - INTRODUÇÃO Os atuais equipamentos da rede IP da Copel já são gerenciados e monitorados por diversas plataformas, mas com a implantação de um novo backbone IP utilizando a tecnologia MPLS e das redes metropolitanas em Gigabit Ethernet e o franco crescimento da utilização destas redes no fornecimento de serviços tanto para a própria Copel quanto para clientes externos constata-se a necessidade de melhorar o gerenciamento desta infra-estrutura de rede e prover as áreas de engenharia e operação de Redes IP com ferramentas para o gerenciamento de falhas, desempenho, configuração, ativação, segurança, contabilização e monitoração de níveis de serviços da rede. Os elementos físicos que trataremos neste trabalho são equipamentos de telecomunicação e informática deste novo backbone e das redes metropolitanas que são os do tipo roteador, switch, servidor, console de gerenciamento e conversores de diversos tipos. Os elementos lógicos que abordaremos são aqueles que são configurados nestes equipamentos, por exemplo as VPN (camada 2 e 3), as VLAN, tráfego das portas e níveis de serviços. A abrangência deste sistema são todos os pontos de presença do backbone IP/MPLS, que totalizam 17 localidades em 12 principais cidades conectadas numa topologia em anel, 60 localidades numa topologia radial de distribuição desta rede e os pontos de presença das redes metropolitanas em Gigabit Ethernet distribuídas em mais de 100 cidades do Paraná. A gerência desta rede é efetuada utilizando duas abordagem para o acesso as informações, uma gerência inband assim denominada por utilizar a própria rede IP para a coleta das informações necessárias para o gerenciamento, embora utilize a própria rede, a rede de gerência é separada logicamente das demais utilizando uma VLAN e uma VPN exclusiva, este tipo de gerência está presente em todos os locais da rede, e a gerência out-of-band que utiliza outra rede IP para prover o acesso aos equipamentos, esta gerência está presente nos pontos principais desta rede. *Rua José Izidoro Biazetto, 158 - Bloco A - CEP 81200-240 - Curitiba - PR - BRASIL Tel.: (041) 331-32652 - Fax: (041) 331-3422 - e-mail: ednei.iamaguti@copel.com

2 2.0 - ARQUITETURA DO SISTEMA DE GERÊNCIA DOS EQUIPAMENTOS DE REDE IP FIGURA 1 - A arquitetura da solução adotada pela Copel Como mostrado na Figura 1 os módulos coletam informações dos equipamentos da rede e armazenam em estruturas de bases de dados internas ou externas aos módulos. Os protocolos de específicos de gerência utilizados são o SNMP e ICMP, mas outros protocolos são necessários nesta arquitetura como o XML para a configuração utilizado na Gerência de Ativação. O módulo de Gerência de Falhas é responsável por coletar informações dos elementos de rede com o objetivo de verificar o seu funcionamento e a disponibilidade da rede, correlacionando essas informações de modo a identificar a real causa dos problemas detectados. O módulo de Gerência de Desempenho é responsável por coletar informações e monitorar o desempenho da rede e dos equipamentos que a compõe, detectando problemas antes que eles se tornem perceptíveis aos usuários. Os dois módulos se integram entre si trocando informações, como por exemplo os alarmes e eventos gerados pela gerência de desempenho que são enviados para a gerência de falhas. O módulo de Gerência de SLA é responsável pela geração de relatórios para acompanhamento de níveis de serviço acordados em contrato com os clientes a partir das informações coletadas pelas Gerências de Falhas e Desempenho, segundo os parâmetros configurados. O módulo de Gerência de Ativação é responsável pela configuração padronizada dos equipamentos que compõe esta rede. As seções seguintes apresentam algumas características de cada um dos módulos da solução. 2.1 Gerência de Falhas 2.1.1 Coleta Nesta seção ocorrem a definição de quais equipamentos da rede serão descobertos e gerenciados e quais de seus recursos serão monitorados, essa operação é realizada aplicando-se filtros e é necessária para restringir a

3 grande quantidade de equipamentos existentes na rede e a grande quantidade de recursos monitoráveis contidas nestes equipamentos. O descobrimento da rede é uma das funções importantes realizada aqui nesta seção e utiliza o protocolo SNMP para montar a topologia lógica e física da rede e que servirá para a montagem dos mapas e diagramas da rede disponibilizados para os operadores desta rede. É função deste módulo, monitorar o funcionamento dos elementos de rede procurando por falhas, através de coletas baseadas nos protocolos ICMP e SNMP de toda rede, iniciada automaticamente e periodicamente a partir da ferramenta instalado em um servidor ou através dos alarmes gerados pelos próprios equipamentos da rede, permitindo aos operadores da rede visualizarem as condições dos equipamentos e os recursos internos destes equipamentos como por exemplo o estado operacional de cada porta, a utilização de recursos como memória e cpu. Este módulo está preparado para suportar equipamentos que implementam o protocolo SNMPv1, SNMPv2c e SNMPv3, pois a cada versão do protocolo são adicionadas melhorias principalmente no aspecto de segurança. Os eventos e dados coletados são armazenados em uma base de dados para possibilitar a geração de relatórios com informações de histórico dos eventos recebidos. 2.1.2 Apresentação Nesta seção são apresentadas as definições referentes a utilização da interface gráfica do usuário. O método de autenticação para controle de acesso à interface gráfica é feito pelo próprio recurso de segurança fornecido pelo sistema operacional utilizado no servidor. O sistema está configurado para não permitir que os usuários apaguem eventos. Para a apresentação da topologia da rede gerenciada são disponibilizados mapas que representam os elementos de acordo com a sua disposição na rede, assim no nível 1 serão apresentados os equipamentos que fazem parte do backbone e os repositórios correspondentes às redes metropolitanas Gigabit Ethernet e as redes de distribuição radiais. Ao clicar em um destes repositórios abre-se o nível 2 do mapa. No nível 2 serão apresentados os equipamentos que fazem parte das redes metropolitanas e das redes de distribuição. Este módulo pode ser acessado tanto pela própria console do sistema quanto pela interface WEB. 2.1.3 Processamento Os eventos recebidos pela Gerência de Falhas são classificadas em categorias para com a finalidade de agrupar os alarmes similares e facilitar a operação da rede. Adicionalmente à estas categorias, os eventos podem ser classificados segundo a sua severidade, que indica quão crítico é o evento, por ex. existem alguns eventos que são mais críticos e devem ser tratados com prioridade pelos operadores, enquanto outros podem ter menor relevância pois causam pouco ou nenhum impacto na rede, podendo ser tratado posteriormente. É função deste módulo disparar ações externas automaticamente no recebimento destes alarmes de equipamentos ou de eventos de violações de limites configurados, indicando a necessidade de verificação de algum elemento específico ou da rede como um todo por uma pessoa responsável. Exemplos dessas ações englobam: o envio de e-mail, mensagens para pager ou mensagens curtas para celulares, execução de algum comando, entre outras. A Gerência de Falhas está preparado para correlacionar eventos distintos que permitem diminuir a quantidade de alarmes exibidos na lista de eventos. 2.2 Gerência de Desempenho 2.2.1 Desempenho da rede IP Da mesma forma apresentada na Gerência de Falhas, aqui é definido o escopo de quais recursos físicos e lógicos serão gerenciados e monitorados. Similarmente à Gerência de Falhas, a Gerência de Desempenho também executa o descobrimento dos elementos da rede e de seus recursos. Assim que ocorre o descobrimento, o processo de coleta de dados das variáveis do protocolo SNMP com o enfoque no desempenho é iniciado, assim para uma porta WAN podemos coletar informações sobre a utilização de banda em percentagem, tráfego em bytes ou bits por segundo, quantidade de frames por segundo, erros por segundo, descartes de frames por segundo, a disponibilidade desta interface e a latência do ponto de vista do servidor de gerência. Os dados obtidos pelo descobrimento e pelas coletas periódicas são armazenados no banco de dados. Esse armazenamento permite gerar relatórios que informam o estado operacional da rede, identificam o desempenho da rede, pontos passíveis de falhas e situações que devem ser analisadas por algum operador ou engenheiro da rede. 2.2.2 Desempenho do Serviço de VoIP

4 A solução adotada pela Copel permite monitorar ainda a qualidade de serviços de VoIP (voz sobre IP), através de um módulo adicional. Este módulo provê a gerência fim-a-fim da disponibilidade e desempenho da infra-estrutura de VoIP, permitindo monitorar e gerar relatórios sobre estatísticas de qualidade de voz e identificar degradação neste tipo de serviço, muitas vezes antes que se torne perceptível aos usuários finais. Ele também fornece dados para monitoramento em tempo real de limiares de qualidades de voz pré-definidos. 2.2.3 Desempenho de aplicações Este módulo permite a gerência de aplicações a partir do ponto de vista do usuário. Um agente é instalado em um computador comum utilizado por um usuário da aplicação, e monitora a comunicação Cliente-Servidor, medindo o tempo gasto para executar cada transação. O projeto da Copel contempla somente aplicações padrões suportadas por este módulo que são: e-mail (POP3 ou SMTP), Lotus Notes, Oracle, Microsoft Outlook, SAP R/3, Telnet, Web (acessadas através de Internet Explorer e Netscape Navigator), este módulo permite a configuração de outras aplicações Cliente-Servidor em ambiente Microsoft Windows porém é necessário um módulo adicional. Estes agentes são instalados em notebooks de modo a permitir testes de diferentes aplicativos a partir de diferentes localidades. 2.2.4 Gerência de Desempenho de aplicações e serviços de Internet O sistema permite ainda a monitoração remota do estado de serviços de Intenet. Este processo simula o acesso aos serviços monitorados, por exemplo, enviar um e-mail, realizar um FTP ou efetuar o acesso à uma página de algum site da Internet e medir os tempos de resposta do servidor, fornecendo estatísticas importantes que poderão ser visualizadas como relatórios. Os serviços de Internet gerenciáveis incluem: NNTP, DNS, POP3, HTTP, HTTPS, FTP, SMTP e PING. Os parâmetros necessários para o monitoramento são específicos de cada serviço, e correspondem a quaisquer prérequisitos para a simulação de acesso a um destes serviços. Exemplos incluem arquivo e endereço destino para teste de um serviço FTP ou conta de e-mail e senha para um teste de serviço POP3 entre outros. O projeto da Copel foi especificado para monitorar dez instâncias de serviços de Internet providos pela Copel a seus clientes ou mesmo de uso interno. 2.2.5 Relatórios de Desempenho Alguns tipos de relatórios são configurados no sistema. Os relatórios de visão geral do equipamento exibem uma série de gráficos que ilustram a performance de variáveis de desempenho críticas para o elemento gerenciado em um dado período. Cada um destes gráficos exibe a tendência de comportamento de variáveis como: uso de banda, disponibilidade, latência, taxa de erros e taxa de perda de pacotes, entre outras. Os relatórios de tendência exibem o desempenho de um elemento ou um grupo de elementos, com base em variáveis de performance disponíveis, durante um determinado período. No sistema utilizado pela Copel é possível gerar um relatório de tendência para até dez variáveis de um único elemento, ou de uma única variável em até dez elementos. Também é possível especificar uma meta sobre uma variável, que servirá para auxílio à análise do relatório. As customizações realizadas nos modelos dos relatórios de tendência objetivarão auxiliar o usuário a prever quando os elementos gerenciados poderão apresentar problemas. Os relatórios ordenados são relatórios tabulares que exibem todos os elementos de um grupo que violem um determinado limiar configurado. Estes relatórios podem ser customizados, por exemplo, para mostrar: os cinqüenta elementos de um grupo com maior utilização de banda, as vinte interfaces com maior taxa de erros dentro de um grupo, ou ainda todos os elementos de um grupo qualquer. Estes tipos de relatórios permitem também combinar condições (limiares), de modo a restringir ainda mais os elementos selecionados para o relatório, totalizando até seis por relatório. Os relatórios interativos de tendência permitem a visualização do comportamento de uma determinada variável se submetida a demandas e capacidades diferentes das atuais. Os relatórios comparativos efetuam a comparação do desempenho de um elemento gerenciado em um dado momento a valores contidos no seu histórico (baseline). É possível traçar comparações com o histórico de comportamento para hora do dia, dia da semana e mês. Além disso, esses relatórios predizem quando os elementos devem apresentar problemas que são identificadas de acordo com limiares estabelecidos para o comportamento de cada variável. Os elementos são classificados de acordo com uma pontuação (0 a 100) estabelecida pelo sistema. Esta pontuação é calculada através de: total de violações (0-66 pontos), proximidade do ponto de limiar (0-17 pontos) e ângulo da curva de tendência (0-17 pontos). Os relatórios compostos apresentam diversas tabelas e gráficos, de forma a prover ao usuário uma visão geral do desempenho de um elemento ou grupo de elementos. Um relatório deste tipo pode conter até vinte gráficos. 2.3 Gerência de SLA

5 SLAs (Service Level Agreements), são os acordos de nível de qualidade para os serviços prestados a clientes. Cada SLA descreve um ou mais parâmetros, valores aceitáveis para os mesmos, e punições para o caso de ocorrer descumprimento. Um mesmo contrato de prestação de serviços pode conter diversos SLAs. Exemplos de parâmetros/slas conhecidos para serviços de rede são: disponibilidade do serviço, latência, taxas de perda de pacotes e erros. O objetivo desta seção é apresentar um detalhamento dos SLAs já suportados pela Copel, assim como descrever que outros SLAs poderão ser gerenciados e ofertados com a utilização deste sistema. A solução de Gerência de SLA é construída sobre as soluções de Gerência de Falhas e Gerência de Desempenho, que comporão a infra-estrutura de monitoramento dos parâmetros de SLA definidos para os serviços prestados sobre a rede de dados da Copel Telecomunicações. Desta forma, a solução de Gerência de SLA permitirá a geração de relatórios de SLA baseados nos dados coletados da rede e os parâmetros de SLA configurados. 2.3.1 Disponibilidade Este parâmetro de SLA possui dois critérios: A disponibilidade do backbone da rede e do acesso até o cliente. A disponibilidade para os equipamentos da rede será obtida através de requisições ICMP (Ping) e SNMP aos equipamentos e da medição da variável SNMP sysuptime, que informa o tempo decorrido desde que o elemento de rede está em funcionamento. Assim caso o sistema identifique que o valor de sysuptime é maior que o horário da última requisição bem sucedida ele considera que o equipamento esteve indisponível no prazo desconhecido. A disponibilidade das interfaces de rede (LAN/WAN) é consolidada através da medição de duas variáveis SNMP utilizadas pelo agente SNMP residente no equipamento para informar ao sistema de gerência sobre o estado das mesmas. As variáveis são IfOperStatus (indica o estado operacional da interface no momento da requisição) e iflastchange (indica o momento em que ocorreu uma mudança de estado operacional nesta interface). Assim caso o valor de IfLastChange seja maior que o horário do último polling em que ifoperstatus tenha indicado que a interface estava disponível, o sistema considerará que esteve indisponível durante todo o prazo indefinido (ou seja, o pior caso). 2.3.2 Latência O termo latência se refere ao atraso da rede ocasionado no processamento realizado pelos equipamentos da rede. Este parâmetro de SLA aponta valores totais ou médios não-aceitáveis para a latência dos serviços de VPN oferecidos pela Copel a seus clientes. O SLA é medido em milisegundos (ms), e é medido de duas formas: latência do backbone e latência do link (túnel de VPN). A medição da latência deverá ser realizada através do envio de pacotes ICMP entre dois pontos (Ping), calculando-se assim o tempo de ida e volta dos mesmos (Round-Trip Time - RTT). Para medir corretamente a latência de um determinado link, é necessário medir o RTT entre os dois roteadores que o delimitam. Isso é possível através da utilização das funcionalidades de Remote Ping (RPing) suportadas pelos roteadores adquiridos pela Copel. O RPing é definido em uma MIB (Management Information Base) padronizada na RFC 2925 Ping MIB. Essa MIB define uma tabela com destinos para o envio de pacotes ICMP, a pingctltable, onde cada entrada na mesma corresponde a um endereço IP de um roteador. Quando uma entrada é criada, o equipamento automaticamente envia os pacotes ICMP de teste e mede os tempos de retorno e outras estatísticas, armazenando-as em outras tabelas definidas na mesma MIB (pingstatisticstable e pinghistorytable). O sistema poderá então identificar essas entradas na pingctltable e tratar cada uma como um elemento do tipo Response Path, exibindo relatórios específicos com os valores coletados. Para a medição de latência do backbone, a Copel deverá configurar os roteadores de backbone para efetuar testes de RPing entre si. Isto pode ser implementado de diferentes formas, desde a configuração de cada roteador para realizar testes em todos os outros roteadores até a escolha de um roteador que servirá como base para todos os testes. Como devemos prover informação mais completa possível de latência de cada ponto que compõe a VPN de determinado cliente, a primeira opção é a mais recomendada, embora seja a mais trabalhosa. A medição de latência de túneis de VPN poderia ser completamente implementada através da configuração de RPings desde um rotador até um ponto na rede do cliente. Esta solução, entretanto, requer um estabelecimento de um full-mesh de testes ICMP, o que é inviável. A recomendação é que a Copel implemente esses RPings apenas para clientes de grande porte. 2.3.3 Taxa de erros Este parâmetro de SLA aponta valores percentuais não-aceitáveis e passíveis de punição para a taxa de erros em uma porta LAN ou WAN por onde trafega os pacotes de um determinado cliente. A taxa de erros em portas LAN e WAN é medida pelo sistema para os roteadores e switches. Como é possível identificar as interfaces específicas de cada cliente a partir dos roteadores, o SLA pode ser medido a partir dessas portas.

6 A maneira como é calculada pelo sistema esta taxa de erros é dependente do tipo de porta a ser monitorada. Para portas Ethernet, o sistema considera como erros a soma dos erros de alinhamento (CRC), fragmentos, jabbers (frames que excedem o tamanho máximo de 1518 bytes para pacotes Ethernet) e runts (frames menores que o tamanho mínimo de 64 bytes para pacotes Ethernet). Descartes não são incluídos como erros, sendo monitorados individualmente e podendo até mesmo ter SLAs próprios. O percentual de Erros é calculado através da razão entre o número de erros sobre o número total de frames que trafegaram. É possível ter medições específicas para os totais e percentuais de erros de entrada e saída também, no caso de portas Ethernet. 2.3.4 Perda de pacotes Este parâmetro de SLA aponta valores percentuais não-aceitáveis e passíveis de punição para a taxa de perda de pacotes em um link por onde trafegam pacotes da VPN de um cliente. A MIB Ping, descrita na seção anterior, permite a configuração do número de pacotes de teste enviados para o endereço do outro equipamento que compõem o link. As tabelas que contêm o resultado desses testes apresentam estatísticas de perda desses pacotes enviados, podendo ser utilizadas para a medição do SLA. O mesmo Response-Path identificado pelo sistema para a medição de latência é utilizado para a verificação das taxas de perda de pacotes. Isto significa que, de forma semelhante, deverão ser definidos SLAs para a perda de pacotes no backbone e por link. 2.3.5 Relatórios de SLA Os relatórios de SLA são os principais produtos desta gerência: - Relatórios de disponibilidade por cliente - Relatórios de latência - Relatórios de perda de pacotes - Relatótios de taxas de erros - Relatório de MTTR (Mean Time to Repair) - Relatório de MTTR (Mean Time to Repair) - Relatório de MTBF (Mean Time Between Failures) 2.4 Gerência de Ativação Entende-se por gerência de ativação a capacidade de configurar os parâmetro necessários para o aprovisionamento de um cliente nos modelos de serviços definidos pela Copel. Esta gerência deve possuir as seguintes características: - Configurar as interfaces dos equipamentos onde os clientes serão ligados fisicamente. - Capacidade de configurar as VLANs dos clientes nos switches - Configurar na rede MPLS as VPNs de camada 2 e de camada 3 - Criar, modificar e alterar os requisitos de QoS que o cliente contratou. - Capacidade de configurar parâmetros de segurança para evitar que alguma operação indevida prejudique o backbone e conseqüentemente a rede de outros clientes. - Interface de fácil uso, pois será operada por técnicos novatos na operação desta nova platafoma - Possuir níveis de segurança no acesso e configuração dos equipamentos. - Permitir a verificação através de registros (log) das configurações realizadas pelos seus usuários. - Gerência fim-a-fim de toda a plataforma. - Gerenciar as desativações, desfazendo todas as configurações criadas no atendimento de um cliente. 2.4.1 Definição da Solução Inicialmente foi necessária a realização de um longo estudo sobre as gerências existentes e a possibilidade de desenvolvimento de uma solução personalizada. Este estudo identificou que existiam poucas empresas no mercado que possuíam uma solução já em produção, as empresas que apresentavam soluções em sua grande maioria possuíam uma forma de comercialização incompatível com a realidade da Copel. As soluções customizadas, por outro lado, necessitariam de um longo tempo para desenvolvimento, além de uma grande preocupação com a continuidade do produto, visto que os equipamentos adquiridos pela Copel sofrem freqüentemente uma atualização de recursos nos seus sistemas e a gerência necessitaria acompanhar este tipo de evolução. Definiu-se a escolha da solução pronta mas com algumas ressalvas, esta solução deveria se enquadrar ao orçamento da Copel e deveria possuir alguma capacidade de personalização para o modelo de serviços explorado.

7 O modelo adotado nesta aquisição foi satisfatório, pois foi possível adquirir muito mais do que simplesmente uma gerência de ativação, adquiriu-se uma solução completa de gerência com módulos que serão utilizados no futuro mas que já estarão integrados, facilitando a exploração e controle de novos serviços sobre a rede IP/MPLS da Copel. Atualmente estamos na fase de implantação da solução que irá auxiliar a realização das ativações em grande escala, facilitando a comercialização de serviços em prazos menores e com melhor qualidade, auxiliando a área de operação nas suas atividades. 2.4.2 Dificuldades Muitas dificuldades foram encontradas na escolha da melhor solução de gerência de ativação ou de aprovisionamento, como muitas vezes é referenciada, relacionamos um conjunto de dificuldades que consideramos pertinentes mencionar neste artigo: - Dificuldade em encontrar soluções para uma tecnologia realmente nova. - Custo elevado das soluções em produção. - Soluções em fase de conclusão para a gama de equipamentos que compõem os serviços a serem explorados pela Copel. - Garantia de continuidade do fabricante junto às empresas de software. - Solidariedade do fornecedor junto ao fabricante. - Sistema aberto permitindo futura independência através de possibilidade de customizações. - Dependência de técnicos do exterior na fase de transferência de conhecimento. - Sistema que seja expansível para futuras plataformas que poderão incorporar a rede da Copel. A aquisição e implantação desta solução está sendo um grande desafio, como todo projeto da nova rede da Copel, mas está permitindo um crescimento técnico e operacional de toda equipe, num novo segmento de atividades da Copel na área de telecomunicações que é a gerência da rede. 3.0 - CONCLUSÃO Uma rede de dados bem gerenciada já vem servindo de infra-estrutura para atendimento de diversos serviços aos clientes internos e externos da Copel e pode vir a servir para outras aplicações antes não imaginadas. A utilização de uma rede IP como suporte a convergência de serviços de voz, vídeo e dados sob uma só plataforma compravam a necessidade de investimento na área de gerenciamento de redes, visto a redução de custos ao compartilhar a mesma estrutura física e a demanda de uma rede sempre operacional. Uma rede gerenciada oferece segurança, redundância e disponibilidade para suportar aplicações críticas que necessitavam de uma estrutura totalmente dedicada para atender requisitos mínimos exigidos pelas mesmas, da mesma forma que outras aplicações com tecnologias consagradas podem utilizar a mesma estrutura física desta rede para transportar seus dados e informações, como por exemplo ao protótipo de uma solução adotada em uma das subestações da Copel Transmissão para a automação da mesma. Solução esta que foi utilizado um adaptador da interface RS232 para o padrão Ethernet, desta forma os dados de automação trafegam transparentemente com segurança sob a rede IP. Alem de outros testes que estão sendo realizados para a gerência de reles de proteção, estações remotas entre outras. 4.0 - BIBLIOGRAFIA (1) Tanenbaum, Andrew S. Redes de Computadores. Ed Campus (2) Marshall DenHartog The Fast Track Introduction to SNMP Alarm Monitoring. DPS Telecom (3) RFC 1157 - Simple Network Management Protocol (SNMP) (4) RFC 2271 - An Architecture for Describing SNMP Management Frameworks. (5) RFC 2925 - Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations (6) Especificação técnica COPEL para sistemas de gerencia de redes IP. (7) Manuais de fornecedores de sistemas de gerência para redes IP. (8) Manuais de fabricantes de equipamentos de redes IP.