Universidade Federal do Rio de Janeiro Núcleo de Computação Eletrônica GERENCIAMENTO DE REDES ATM

Transcrição

1 Universidade Federal do Rio de Janeiro Núcleo de Computação Eletrônica GERENCIAMENTO DE REDES ATM Ana Paula M. Dumont Disciplina: Redes Legadas Outubro de 1999

2 Índice 1. Introdução Áreas Funcionais do Gerenciamento de Redes Gerenciamento de Configuração Gerenciamento de Falhas Gerenciamento de Segurança Gerenciamento de Desempenho Gerenciamento de Contabilização Gerenciando redes ATM utilizando o Protocolo SNMP Modelo de Referência de Gerenciamento de Redes ATM MIBs SNMP aplicadas ao ATM MIBs mapeadas pelo ATM Forum MIBs mapeadas pelo IETF MIBs definidas por outras organizações MIBs específicas de fabricantes Mapeamento de MIBs no modelo do ATM Forum AtoM MIB Descrição da AtoM MIB Informações da interface ATM Informações de circuitos virtuais ATM Configurações de VPLs e VCLs Descritores de Tráfego ATM Cruzamento de Conexões VP/VC AAL5 Connection Performance Statistics MIB suplementar à AtoM MIB Informações de Endereços ATM Informações de Circuitos Virtuais Informações de Cross Connects Sinalização Sinalização em uma interface ATM Parâmetros descritores de sinalização VPL em portas lógicas Integrated Local Management Interface (ILMI) Protocolo ILMI ATM Interface MIB Link Management MIB Informações da camada física Informações da camada ATM Estatísticas da camada ATM Informações de conexões virtuais Informações adicionais de tráfego ABR Traps SNMP para gerenciamento de links Procedimentos de operação ILMI Procedimentos de Conectividade Procedimentos em caso de mudanças nos atributos locais Procedimentos opcionais Address Registration MIB Service Registry MIB ILMI e AtoM MIB CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS

3 1. Introdução A partir do momento que as redes de computadores começaram a existir, pessoas começaram a confiar nelas, e começaram utilizá-las para enviar mensagens de s para os amigos até chegar ao ponto em que a performance e a disponibilidade da rede tornaram-se vitais para a sobrevivência dos negócios e das pessoas. Hoje a tecnologia de rede ATM está saindo da fase de pesquisa e de ambientes de testes para redes de produção. O primeiro requerimento para se ter uma rede ATM confiável é que ela seja bem desenhada e que o design seja claro e bem compreendido. É igualmente importante, entretanto que uma vez que a rede ATM torne-se operacional existem razões suficientes para monitorar e influenciar a operação da rede com o objetivo de prevenir problemas. Se problemas ainda surgirem deverá haver meios de resolvê-los de forma rápida e segura, com o objetivo de amenizar as conseqüências. Essas atividades podem ser definidas como o gerenciamento das redes ATM. O gerenciamento de redes de computadores e de telefone vêem sendo estudado há vários anos. Desde que uma rede ATM passou a transportar tipos diferentes de tráfegos, que antes eram transportados em diferentes redes o gerenciamento tornou-se muito importante. Na rede ATM todos os diferentes tipos de tráfego estão competindo por um único recurso compartilhado, que é a disponibilidade de banda nos links da rede. O principal objetivo do gerenciamento de redes ATM é prover os usuários com a capacidade de controlar, configurar e monitorar a rede de maneira a ter os serviços desejados. Pelo fato do ATM ser um protocolo orientado a conexão, construir e manter a topologia da rede constitui uma tarefa importante. Os administradores de rede deverão gerenciar mudanças na topologia sem impactar no tráfego dos usuários. Eles precisam de ferramentas que permitam obter uma variedade de condições: desempenho, delay de células, jitter,etc de algumas das conexões virtuais que possam haver. Deve-se controlar e monitorar a infra-estrutura física da comutação. Existe uma interdependência entre as diferentes fontes de tráfego que podem ocasionar problemas de gerenciamento, já que um tráfego pode ter influência no outro. Este trabalho visa apresentar o atual estágio das definições ILMIs (Integrated Local Management Interface), apresentando um estudo do SNMP e do ATM para situar e fundamentar os conceitos utilizados. 3

4 2. Áreas Funcionais do gerenciamento Na definição do modelo de gerenciamento OSI foram especificadas cinco áreas funcionais, as quais descrevem a atuação dos sistemas de gerenciamento: Gerenciamento de Configuração Gerenciamento de Falhas Gerenciamento de Segurança Gerenciamento de Desempenho Gerenciamento de Contabilização As principias funções das cinco áreas funcionais são: Gerenciamento de Configuração registrar as configurações atuais e suas eventuais alterações identificar componentes da rede habilitar e desativar sistemas da rede alterar parâmetros da rede Gerenciamento de Falhas detectar falhas notificar a ocorrência de falhas registrar e manusear as notificações de eventos rastrear e identificar ocorrência de falhas agendar e executar diagnóstico e procedimentos corretivos Gerenciamento de Segurança autenticação controle de acesso manutenção e manipulação de logs de auditoria Gerenciamento de Desempenho medição e armazenamento de informações de desempenho e tráfego análise de informações de desempenho e geração de relatórios Gerenciamento de Contabilização armazenamento de medições de utilização estabelecimento de limites de utilização 4

5 2.1. Gerenciamento de Configuração Em redes ATM, o Gerenciamento de Configuração deve identificar e controlar os dispositivos que compõem a rede, mantendo informações do estado operacional e de configuração de comutadores ATM. Dentre as tarefas desta área de gerenciamento estão: definir os parâmetros de funcionamento normal de um sistema; associar nomes aos objetos gerenciados; inicializar e finalizar objetos gerenciados; coletar informações (sob demanda) sobre as condições atuais de um sistema de comunicação; receber comunicados sobre mudanças significativas em sistemas de comunicação; mudar a configuração de um recurso. Na prática, o Gerenciamento de Configuração deve manter atualizado o inventário de software, hardware e circuitos. Abaixo estão as principais atividades dos elementos que compõem o Gerenciamento de Configuração; A partir dos elementos gerenciados deve haver a comunicação de: alteração do estado operacional nos recursos gerenciados; mudanças na configuração; Na estação de gerenciamento deve ser possível: configurar UNIs e B-ICIs; configurar VPLs e VCLs; configurar conexões ATM ponto-a-ponto e ponto-multiponto; ativar e desativar funções de comutadores; consultar a configuração de comutadores; manter cópias de segurança de arquivos de configuração; efetuar a restauração da configuração nos comutadores; atualizar o software dos comutadores quando necessário. 5

6 2.2. Gerenciamento de Falhas O Gerenciamento de Falhas tem como função detectar,localizar, isolar e corrigir falhas. Dentre as suas funções, estão: procurar e identificar problemas; receber e atuar sobre notificações de falhas; iniciar seqüências de testes; isolar pontos de falhas; corrigir os problemas; e manter e examinar o histórico de erros. Nos comutadores ATM devem ser implementados mecanismos que facilitem a detecção e a notificação de problemas. Três aspectos devem ser observados por estes mecanismos. O primeiro é a detecção de problemas a nível das camadas física e ATM, identificando defeitos ou falhas nos elementos de rede. O segundo aspecto é a divulgação dos problemas através da indicação de alarmes entre os elementos de rede afetados. O terceiro aspecto é informar o problema ao sistema de gerenciamento Gerenciamento de Segurança A área funcional de Gerenciamento de Segurança deverá assegurar a integridade e a privacidade das informações de uma concessionária de serviços de rede e de seus clientes. Nesse contexto os seguintes passos são importantes: autenticação; integridade de dados e sistemas; identificação; controle de acesso aos recursos; controle de acesso a sistemas; histórico de auditorias dos sistemas Gerenciamento de Desempenho Uma rede ATM tem como característica marcante a heterogeneidade dos vários tipos de tráfego integrados pelo sistema (ex: dados,vídeo e áudio). Este fato facilita a ocorrência de problemas de desempenho que degradam os serviços de rede. Necessita-se, então de funções de controle e monitoramento de recursos para evitar tais situações. 6

7 O monitoramento de desempenho se refere à tarefa de periodicamente recuperar e avaliar dados sobre o funcionamento de uma função de rede, de forma a detectar disfunções intermitentes ou originadas da deteriorização gradual de equipamentos de rede. A importância dos mecanismos de Monitoramento de Desempenho reside na capacidade de detecção antecipada de problemas na rede que podem ser evitados, antes mesmo que ocorram. Diversos parâmetros são objetos chave para a avaliação do desempenho de uma rede. Ao nível de usuário, um desses parâmetros é a classe de Qualidade de Serviço (QoS) de cada conexão. Através desta característica, informações mais detalhadas acerca do comportamento de uma fonte de tráfego podem ser estimadas, de forma a analisar a probabilidade de ocorrência de congestionamento na rede. Existem 3 aspectos que merecem ênfase: Monitoramento de Desempenho do Transporte Físico; Monitoramento de Protocolo; Monitoramento de Desempenho de VPCs e VCCs. O monitoramento de desempenho em nível de protocolo envolve todas as camadas da pilha de protocolos ATM. Portanto, duas abordagens são especificadas e definem suas funções: Funções em nível de processamento de cabeçalho em células ATM; Envolve os protocolos das camadas Físicas e ATM, no que diz respeito à manipulação, processamento e detecção de erros em bits de cabeçalho de células. Funções em nível de monitoramento dos protocolos da camada AAL (AAL ¾ e AAL5). Engloba as funções relativas às emulações e adaptações realizadas pela camada AAL, monitorando protocolos orientados a conexão ou não. Para o monitoramento de desempenho a nível da camada física e ATM, informações acerca da ocorrência de problemas de processamento de cabeçalhos de células ATM são necessárias. Esses dados podem facilitar a detecção dos problemas que podem deteriorar o serviço de rede. Essas informações são: Número de células descartadas de vido a erros nos bits de cabeçalho de células. Esta informação tem como função dar a indicação implícita de falhas intermitentes na camada física, através da detecção sucessiva de situações anormais. Número de células com erros detectados nos bits de cabeçalho. 7

8 Células descartadas pela camada ATM, sendo consideradas descartadas pelos mecanismos de policiamento (bit CLP ligado) ou porque apresentam valores inválidos de VPI/VCI. O monitoramento de protocolos da camada de Adaptação ATM é responsável por acompanhar o desempenho de serviços que utilizem os protocolos oferecidos por esta camada. Existem especificações distintas para o Monitoramento de Desempenho de camada AAL. Os critérios de gerenciamento da camada AAL variam de acordo com o seu tipo (Tipo1, Tipo2, Tipo ¾ ou Tipo 5), portanto, de acordo com a classe de serviço a que cada tipo de camada AAL está apta a suportar. O monitoramento de protoclo para camada AAL se baseia na contagem de eventos anormais ocorridos sobre PDUs (Protocol Data Units). Para isto, são implememtados sistemas de contagem de eventos que fazem uso de contadores simples ou do algoritmo Sum-of-Errors. A detecção de estados anormais é feita através do reconhecimento de ultrapassagem de limites (threshold) para os contadores, onde cada contador pode ter ou não limite estipulado. O algoritmo Sum-of-Errors tem como função detectar erros persistentes dentro de um determinado intervalo de tempo, e consiste de uma série de contadores individuais com valores limite estipulados. O registro de contagem é feito durante um determinado tempo (período de agregação), que é recomendado em 15 minutos pela ATM forum. Quando um ou mais contadores acusam a ultrapassagem de seus limites, uma notificação TCA é gerada e enviada para o sistema de gerenciamento adequado. Para cada conexão, seja VCC ou VPC, uma implementação do sistema de contagem de eventos é ativada, de forma a realizar o monitoramento de desempenho no protocolo AAL utilizado nesta conexão. A camada AAL se divide em duas subcamadas: SAR (Segmentation and Reassembly Sublayer) e CS (Convergence Sublayer). O monitoramento de desempenho AAL é feito a nível de subcamada AAL. O monitoramento de desempenho da subcamada SAR é feito com o uso de contadores de erro com valores limite definidos. Dois tipos de erros são passíveis de ocorrer em um campo do SAR-PDU: campo inválido e campo incorreto. A ocorrência de Campo inválido se dá quando o valor de um certo campo da SAR-PDU está fora dos limites estipulados para este campo. Por exemplo, SAR-PDUs com funções de BOM (Begining of Messages) e COM (Continuing of Message) devem ter 44 como valor do campo User Information Lenght. A ocorrência de valor diferente de 44 para este campo caracteriza um Campo Inválido. Um Campo Incorreto se dá quando os valores dos campos de um SAR-PUD são válidos, mas há indícios concretos de falhas na transmissão ou manipulação do PDU que possam comprometer sua integridade, Um exemplo é a verificação de validade de todos os campos de uma SAR-PDU, mas o CRC 8

9 constante no PDU não confere com o CRC calculado quando do recebimento das informações. O monitoramento de desempenho de protocolo da subcamada CS são os mesmos utilizados para a subcamada SAR. O monitoramento de protocolo para a AAL5 se dá no ponto de chegada dos quadros, onde as seguintes condições de erro são checadas: Formato inválido do campo de controle: ocorre quando há inconsistência nas informações do campo de controle de um quadro. Lenght violation : quando há ocorrência de quadros cujos tamanhos diferem do tamanho do quadro especificado para o seu protocolo. Oversized Service Data Units (SDUs) received Quando o tamanho da unidade de dados do serviço não confere com o tamanho especificado para o serviço. Neste caso, o tamanho de unidade se refere ao serviço, e não ao protocolo de transmissão de dados. Cyclic Redundancy Checking (CRC) violations Quando ocorre diferença entre o campo CRC constante no quadro recebido e o CRC calculado no ponto de chegada. Pode indicar erro de transmissão dos dados. Para o gerenciamento de desempenho de uma rede ATM como um todo, é necessário agregar os valores obtidos de cada comutador individualmente, de modo a modelar o estado de desempenho de toda a rede, baseado em seus componentes. A análise de desempenho do conjunto fornece a medida de desempenho do ponto de vista do usuário, que pode observar o desempenho da rede na medida fim-a-fim. Para que esta análise de desempenho possa ser feita, algumas tarefas têm de ser suportadas pelo sistema de gerenciamento. São elas: Acúmulo de dados de monitoramento de desempenho e gerenciamento de tráfego; Análise de informações de gerenciamento de desempenho e geração de relatórios sobre as conclusões; Correlação de alertas e alarmes e geração de relatórios sobre as conclusões; Atualização e consulta a base de dados de informações de gerenciamento de desempenho dos acumuladores Gerenciamento de Contabilização O gerenciamento de contabilização em redes ATM tem como objetivo permitir a uma concessionária de rede pública contabilizar e taxar o uso de seus recursos e serviços de rede por parte de seus clientes. 9

10 Para isto, informações sobre a utilização da rede, chamadas formalmente de Contabilização Automática de Mensagens (AMA Automatic Message Accounting) são recolhidas, armazenadas e tarifadas pelo sistema de gerenciamento. As funções que o gerenciamento de contabilização deve suportar para redes ATM: coletar informações AMA; assegurar a confiabilidade das informações AMA; registrar a ocorrência de células recebidas com violação ao contrato de tráfego; suportar formatos padrões para informações AMA. Algumas das informações a serem coletadas para fins de tarifação são: número total de células,células de alta prioridade (CLP), células OAM e células OAM de alta prioridade Gerenciando redes ATM utilizando o Protocolo SNMP O SNMP Simple Network Management protocol (protocolo Simples de Gerência de Rede) é um protocolo da camada de aplicação da arquitetura do TCP/IP que é usado para monitorar e controlar serviços e dispositivos de uma rede. Manager SNMP MIB MIB ATM Network Para que uma rede ATM seja gerenciável utilizando o SNMP ela deverá satisfazer 3 requerimentos: 1. Os sistemas dentro da rede devem conter agentes SNMP e MIBs. A MIB é uma base de informação de gerenciamento.essas MIBs deverão conter objetos pertencentes a todos os aspectos da rede a serem gerenciados.exemplos de tais aspectos são: tabelas de conxão,tabelas de roteamento, etc. 2. Cada sistema na rede deve tratar as alterações na MIB que realmente afetem o comportamento do sistema e vice-versa. Vamos considerar uma tabela de conexões ATMna MIB de um switch ATM. 10

11 Depois que um gerente criar uma entrada na tabela de uma nova conexão o software do switch deverá, realmente, criar uma conexão. 3. Um gerente deverá ser capaz de trocar SNMP Protocol Data Units (PDUs) com o agente. Na figura abaixo isso é representado pela conexão do gerente com o agente. Trocando PDUs SNMP O terceiro requerimento para habilitar o gerenciamento é a possibilidade de trocar PDUs SNMP entre as entidades gerente e agente. O serviço de transporte de informação de gerenciamento é usado para isso, como mostra a figura abaixo. Manager Agent SNMP Manager SNMP Agent SNMP Manager Entity SNMP Agent Entity MIB ATM Entity to be managed Management O serviço information de transporte transportation de service informações de gerenciamento é diferente do serviço de transporte de dados do usuário. Para redes ATM o serviço de transporte de dados do usuário é igual ao serviço da camada física. Equipamentos de rede ATM geralmente tem as camadas físicas Ethernet e/ou RS232, e usualmente uma entidade de protocolo IP. O serviço de transporte de informações de gerenciamento pode ser construído de diferentes maneiras, dependendo de quais entidades de protocolo e camadas físicas estão disponíveis nos sites do gerente e do agente. Abaixo estão dois exemplos de serviço de transporte de informações de gerenciamento. IP sobre Ethernet Se ambos os sites de gerente e agente possuem camada física Ethernet e uma pilha de protocolo IP sobre Ethernet então as PDUs SNMP podem ser trocadas usando IP sobre Ethernet. Esse método é frequentemente disponível nos switches ATM. 11

12 Manager Agent SNMP Manager UDP IP LLC MAC SNMP Agent UDP IP LLC MAC SNMP = Simple Network Management Protocol UDP = User Datagram Protocol IP = Internet protocol LLC = Logical Link Control MAC = Medium Access Control Pysical layer A figura acima mostra a pilha de protocolos para IP sobre Ethernet. As entidades de protocolo para gerente SNMP e agente SNMP são as mesmas. IP sobre Ethernet não envolve nenhuma parte do protocolo ATM, com isso o transporte das informações de gerenciamento pode ser implemetado completamente separado do transporte dos dados de usuário ATM. Para o gerenciamento da Internet existem aplicações de gerenciamento que também usam o SNMP,UDP e IP. Essas aplicações de gerenciamento podem ser facilmente adaptadas para o gerenciamento de redes ATM, o que é uma grande vantagem. IP sobre ATM Manager SNMP Manager UDP IP AAL5 ATM Pysical layer Agent SNMP Agent UDP IP AAL5 ATM SNMP = Simple Network Management Protocol UDP = User Datagram Protocol IP = Internet protocol LLC = Logical Link Control MAC = Medium Access Control O IP sobre ATM pode ser usado para serviço de transportae de informações de gerenciamento. IP sobre ATM usa um VCC ATM para transportar pacotes IP, ao invéz da camada LLC. IP sobre Ethernet usa o ARP (Address Resolution Protocol) para achar endereços MAC para ser usado 12

13 Protocol stacks for IP over Ethernet interconnection para um determinado endereço IP de destino. IP sobre ATM usa um diferente protocolo ARP, para achar uo endereço AST de um determinado endereço IP de destino. Uma conexão ATM para um endereço ATM é setado, e o pacote IP é transmitido em uma pacote AAL5. Apesar de uma conexão ATM ser usada, ambas as entidades agente e gerente enviam e recebem suas PDUs usando UDP e IP. Por isso ser igual ao gerenciamento na Internet, muitas aplicações de gerenciamento usam SNMP sobre UDP e IP já existe, e pode ser usado para gerenciamento ATM com pequenas adaptações. LAN Emulation LAN Emulation (LANE) pode ser usada para serviço de transporte de informações de gerenciamento se ambos o gerente e o agente possuem o protocolo LANE disponível. Manager Agent SNMP Manager UDP IP LLC LANE AAL5 ATM SNMP Agent UDP IP LLC LANE AAL5 ATM SNMP = Simple Network Management Protocol UDP = User Datagram Protocol IP = Internet protocol LLC = Logical Link Control MAC = Medium Access Control Pysical layer Protocol stacks for IP over Ethernet interconnection Esse método envolve uma pilha de protocolos mais complexa quando comparada com a pilha de protocolo exigida para direct ATM e IP sobre ATM. 13

14 A pilha de protocolo mostrada na figura acima não inclui os componentes adicionais requeridos para a emulação de uma LANE, nem as funções de sinalização necessária para configurar as conexões ATM requeridas. O grupo de trabalho de LANE do ATM Forum lançou o LAN Emulation Servers Management Specification 1.0. Essa especificação define informações de gerenciamento não só para os servidores LANE como para toda a rede LAN emulada. Essa nova especificação define 3 módulos de MIB SNMP. A MIB LAN é implementada por um LECS (Lan Emulation Configuration Server). Ele contém configurações estáticas de LANS emuladas incluíndo políticas usadas para determinar qual ELAN um cliente deverá se conectar, como parâmetro de configuração para cada ELAN. A MIB do LES (Lan Emulation Server) é implementada para cada LES. Ela contém informações de configuração e status, estatísticas, os endereços registrados e conexões ATM que estão sendo usadas pelo LES. A MIB do BUS (Broadcast and Unknow Server) contém informações de status e configuração, incluíndo estatísticas e conexões ATM que estão sendo usadas pelo BUS. 4. Modelo de Referência de Gerenciamento de Redes ATM: O ATM Forum definiu um modelo de gerenciamento de redes ATM também conhecido como modelo das 5 interfaces. Esse modelo descreve os vários tipos de gerenciamento de redes privadas,redes públicas e redes híbridas. Ele especifica também gateways entre sistemas baseados nos protocolos SNMP e CMIP, e sistemas com protocolo proprietário. Esse módulo tem sido utilizado para situar diversas soluções e especificações apresentadas para ATM. Para isso foram criadas 5 interfaces, nomeadas M1,M2,M3,M4 e M5.Estas interfaces são essenciais para o monitoramento e controle fim-a-fim de uma rede ATM. 14

15 Abaixo são descritas as funções de cada interface. 1) A interface M1 é necessária para realizar a gerência de um dispositivo ATM. 2) A M2 é utilizada para se realizar o gerenciamento de uma rede ATM privada. 3) A interface M3 opera na conexão entre os sistemas de gerenciamento de redes privadas e os das concessionárias de serviços públicos. Permite que o administrador de rede supervisione sua conexão com uma rede pública ATM, tendo o controle em tempo real dos serviços que ele usa. 4) A M4 é necessária para se gerenciar uma rede pública ATM.Ela inclui as funções de gerenciamento de elementos de rede e funções de gerenciamento de serviços. Para os gerentes de empresas privadas que usam os serviços de concessionárias públicas, há a necessidade de se Ter um controle sobre a qualidade do serviço oferecido. A concessionária, por outro lado, pode oferecer aos clientes relatórios sobre o uso da rede, como um serviço de valor agregado. 5) A M5 suporta interações ou trocar de informações de gerenciamento entre duas redes ATM públicas. Todas as interfaces definidas são essenciais no monitoramento e controle fim-a-fim. Entretanto, em administração de redes privadas são de particular interesse as interfaces M1 e M2. Estas definem a interface entre os sistemas de gerenciamento e uma estação ou comutador ATM. O protocolo SNMP tem sido utilizado nas interfaces M1,M2 e M3. Já o CMIP se apresenta nas soluções das interfaces M4 e M5, ambientes públicos. Estas interfaces utilizam MIBs padronizadas pelo IETF e pelo ATM Forum, tais como: 15

16 MIB II, MIBs padrões para conexões (DS-1,DS-2, e SONET), AtoM MIB e ILMI MIB. A interface M3 adota as MIBs: M3 MIB e AtoM MIB. O ATM Forum fez algumas especificações para a gerência de redes que são: Customer Network Management (CNM) for ATM Public Network Service; M4 Interface Requirements and Logical MIBs; CMIP Specification for the M4 interface; M4 Public Network View; M4 Network Element View; M4 Network View Requirements & Logical MIB Addendum; Enterprise/Carrier Network management (M4) SNMP MIB; Carrier Interface (M5) Requirements & CMIP MIB; Management System Network Interface Security Requirements & Logical MIB ATM Access Function Specification Requirements & Logical MIB; M4 Requirements & Logical MIB Network View v2.0 Além dessas definições existem funções de gerenciamento relevantes para o ATM, como o Interim Local Management (ILMI) que fornece a visão de configuração de um link específico ATM e parâmetros de falha da UNI (User Network Interface). A UNI também fornece algumas funcionalidades de camadas de gerenciamento via Operations Administration and Maintenance (OAM). Desde que a ILMI permite a recuperação de informações da rede pública pelos cliente, ela pode ser considerado um serviço CNM. A ILMI está embutida na UNI e deve ser processada por um equipamento diretamente conectado a UNI. CNM A visão de gerência de redes segundo a abordagem CNM mostra que provedores de serviço (concessionárias) gerenciam a sua infra-estrutura para prover serviços Atm aos usuários, através dos Sistemas de Operação (OS). Numa rede ATM privada, os usuários através de um Sistema de Gerência de Redes precisam suportar muitas funções de gerência que um provedor disponibiliza. Outros usuários apenas obtêm serviços ATM de um provedor.neste caso, eles precisam de um mecanismo para gerenciar certos aspectos de seu serviço. O serviço CNM suportado pelos provedores facilita o planejamento,operação, manutenção,administração,reconfiguração da porção da rede do cliente alugada ao provedor. 16

17 Os requerimentos da M3 estão definidos em 2 classes para permitir que provedores de rede pública possam oferecer capacidades incrementais e modulares para os diferentes níveis de necessidades do cliente. A primeira classe de funções M3, classe I, identifica quais os requerimentos que um provedor de rede pública deve fornecer para monitorar informações de gerenciamento de configuração, falha e performance de uma porção específica do cliente na rede pública. Exemplos da classe I: a) Recuperar dados de gerenciamento de performance para um link UNI; b) Reportar mensagem de alarme (ou trap) após a queda de um link UNI de um site de cliente para a rede pública. A segunda classe de funções M3, classe II identifica identifica os requerimentos pelos quais o cliente pode requisitar adição, alteração ou deleção de conexões virtuais e informação de subscrição em uma rede pública ATM. As conexões devem ocorrer entre facilidades físicas existentes e todas as facilidades devem pertencer a um único cliente. Um exemplo dessa classe seria quando o cliente requisita um novo caminho virtual entre duas de suas conexões UNI para a rede pública. Com a interface M3 o cliente pode ter uma visão da rede ATM, mostrando a porção lógica do cliente para a rede pública ATM. Um agente CNM representa um único provedor público da rede ATM. A rede pública suporta um único segmento de PVC. O agente CNM suporta MIBs definidas para o suporte de classes M3. Essas MIBs modelam um segmento de PVC através de uma rede pública ATM. Se os PVCs do cliente atravessam múltiplas redes públicas, então o cliente NMS poder obter informações de múltiplos agentes CNM para recuperar a visão fim-a-fim dos seus serviços. 5. MIBs SNMP aplicadas ao ATM Com a popularização da Internet e por consequência de todos os protocolos da família TCP/IP é natural que o SNMP tenha sido a primeira tentativa de se integrar toda a infra-estrutura disponibilizada pelo Plano de Gerência em um sistema de gerência adequado a este ambiente. A prática tem mostrado que o protocolo SNMP não tem se mostrado uma solução eficiente em gereência de redes ATM. Dentre as limitações do SNMP na gerência ATM merece destaque que o gerentes de redes ATM necessitam administrar recursos multimídia, o que envolve uma quantidade enorme de dados a serem coletados,processados e 17

18 apresentados, para o qual SNMP não foi originalmente projetado.além disso, a natureza destes dados é incompatível com a característica de simplicidade do SNMP. No caso da rede ATM, o que está em questão é como adaptar e estender as funcionalidades básicas do SNMP para prover as funções de gerenciamento em tempo real ATM. Isso significa que devemos repensar a arquitetura de gerenciamento de redes. Já que o ATM provê conexões virtuais, a arquitetura de gerenciamento tem que ser descentralizada, ou seja, desenvolvida como uma série de subagentes que reportam informações sobre a configuração e estado da rede a partir de vários dispositivos ATM, como por exemplo o estabelecimento de uma conexão.utilizando esta abordagem, dispositivos ATM podem enviar dados SNMP para uma estação de gerenciamento central,assim provendo monitoramento SNMP em tempo real. Os objetos gerenciados e os atributos associados, necessários à implementação das várias funções de gerenciamento encontram-se na base de informações gerenciais (MIB). São necessárias plataformas de gerenciamento ATM capazes de atender às necessidades de gerenciamento em ambiente de redes compostos de equipamentos de múltiplos fabricantes. A palavra chave de plataformas abertas de gerenciamento de redes é ter em comum, o protocolo de comunicação e um conjunto de objetos gerenciáveis, de maneira a facilitar a monitoração e o controle dos elementos que compõem uma rede ATM. Este objetivo é concretizado pelo uso de protocolos e MIBs padronizados. Neste contexto, existe uma grande quantidade de MIBs relevantes. Estas são baseadas nos padrões SNMP (Simple Network Managemnt Protocolo) e CMIP (Common Managemnt Information Protocolo). Além das MIBs definidas pelo ATM Forum (SNMP e CMIP), existem diversas MIBs definidas por outros órgãos de padronização, incluindo o IETF (SNMP), o Network Managemnt Forum (CMIP), e o ITU-T (CMIP). Existem ainda as MIBs proprietárias desenvolvidas pelos fabricantes para gerenciar características específicas de seus equipamentos, fundamentalmente baseadas em SNMP. Mesmo cada um tendo onjetivos específicos, existem algumas coincidências entre as MIBs desenvolvidas pelos diferentes órgãos. Frequentemente, é preciso combinar várias MIBs para atender às necessidades. Com isso, é importante atender as várias MIBs aplicáveis a redes ATM seus propósitos, escopo e interrelacionamentos de forma a gerenciar redes ATM. Dentre as MIBs SNMP aplicadas à ATM, a mais importante e a padrão para o gerenciamento ATM é a AtoM MIB. A seguir são apresentadas detalhadamente as MIBs AtoM MIB e ILMI, especificadas pelo IETF e pelo ATM Forum, respectivamente. 18

19 5.1. MIBs do ATM Forum ILMI MIB: interface M1 que provê informações sobre a configuração, estado operacional e de estatísticas dos circuitos físicos e virtuais estabelecidos. Data Exchange Interface (DXI) MIB: define a interface entre um roteador e uma DSU (Data Service Unit) ATM. A MIB DXI dá suporte à gerência de configuração e performance de interaces DXI. É basicamente uma interace M1. Lan Emulation MIB: é uma interface M2 que engloba as MIBs LANE client e LANE server. Juntas, permitem o gerenciamento de configuração, de falhas, e de performance de clientes (LECS) e servidores (LES), respectivamente, do serviço de LAN Emulation. MIB M3: descreve os objetos que devem estar disponíveis aos usuários de redes ATM públicas. M3 é uma interface entre sistemas de gerenciamento de redes públicas e privadas. Customer Network Management (CNM) for ATM Public Network Service Diferentes tipos de MIBs M4 são descritas: Circuit Emulation Service Interworking Requirements, Logical and CMIP MIB (CES MIB); M4 Interface Requirements and Logical MIB; M4 Network Element (NE) MIB; M4 Network View MIB; M4 Switched Virtual Circuit (SVC) MIB: define os objetos necessários à gerência de SVCs entre os elementos da rede; ATM AAL MIB: define os objetos relacionados à camada de adaptação ATM nos elementos de rede que compõem uma rede pública; Private Network to Network Interface (PNNI) MIB; M5 Network to Network MIB: define os objetos necessários à troca de informações entre os sistemas de gerenciamento de duas concessionárias de redes públicas ATM; Remote Monitoring MIB extensions for ATM Networks (RMON MIB) :apresenta estatísticas de tráfego associado a interfaces, hosts,par de hosts que se comunicam e, a indicação dos hosts que geram o maior tráfego MIBs do IETF AtoM MIB (RFC 1695): esta foi a primeira MIB definida para o gerenciamento de redes privadas e dispositivos ATM. É importante na configuração fim-a-fim e no gerenciamento de performance. 19

20 Transmission MIBs: estas MIBs apresentam informações necessárias ao gerenciamento de falhas, configuraçãoe performance em alguns meios de transmissão que suportam ATM. Estas incluem: RFC 1406 para o gerenciamento T1-E1, RFC 1407 para gerenciar canais T3-E3, e RFC 1595 na gerência de interfaces que utilizam as hierarquias SDH e SONET MIBs definidas por outras organizações Diferentes organizações definem MIBs baseadas no padrão CMIP para o gerenciamento de redes das concessionárias de redes ATM. As principais MIBs ATM apresentadas por estas organizações são apresentadas resumidamente a seguir: Carrier NE Management MIBs: corresponde à M4 NE MIB. O padrão ITU I.751 standard define os objetos necessários à gerência de elementos de rede (NE) ATM usando CMIP. O Network Management Forum (NM Forum) também definiu MIBs relacionadas ao gerenciamento de serviços, do ponto de vista da concessionária. Bellcore GR1114 é uma extensão à M4 CMIP MIB do ATM Forum. Transmission MIBs: definem objetos importantes no gerenciamento de configuração, falhas e performance de vários sistemas de transmissão que suportam ATM. Alguns exemplos: ANSI T1.247 para gerenciar circuitos T1, ITU-T G.704 e G.706 para a gerência SONET SDH e E1, respectivamente, Bellcore GR.836 para gerenciar circuitos T3, ITU-T G.826 e G.832 no gerenciamento de circuitos E MIBs específicas de fabricantes Utilizadas primariamente para administrar a configuração, monitoração e remoção de SVCs e PVCs. Geralmente são fornecidas extensões que auxiliam na detecção e investigação de problemas tanto no hardware quanto no software do comutador. Os fabricantes incluem ainda, objetos que permitem obter características de performance de circuitos virtuais, tais como: throughput, células com erro e células descartadas. Estas MIBs são geralmente baseadas em SNMP. 20

21 Ex. Fore A Fore utiliza definições próprias de MIBs para serem usadas em seus switches ATM e cartões de interface ATM: The Fore switch MIB e Fore adapter MIB. Não há indicação do switch conter outras MIBs padrões. A MIB do switch da Fore contém 250 objetos e a MIB do adaptador 75. A ATM MIB da Fore contém informação de todo o switch e de suas interfaces ATM. O switchgroup contém objetos com informação do switch como um todo. Essas informações referem-se ao número máximo de caminhos virtuais e canais virtuais que o switch pode suportar e o endereço Atm do switch. Os valores defaults para os parâmetros UPC desse switch estão nesse grupo: os objetos switchcdv e switchpolicingaction. O PortGroup contém a porttable com informações de cada porte. Os endereços de sistema destino desse porte estão presentes, tanto o endereço ATM quanto o endereço IP. Informações de ambas as direções de transmissão com valores máximo e corrente são representadas, para o número de caminhos e para a largura de banda. Um contador para o número de células transmitidas em cada direção também está presente. A partir da descrição de objetos da MIB conclui-se que o switch ATM da Fore é internamente construído como um cluster de switches ATM interconectados. Cada board é considerado como um próprio switch ATM. ATMSwitch Hardware Software asx environment asxd snmp traps config forevi ew

22 Legenda: 1 = boards 9=channels 2 = modules 10=topology 3 = power 11=signalling 4=temperatura 12=spans 5=tans 13=boards 6=switch 14=boardsTopology 7=ports 8=paths atmadapter Legenda: 1=adapterTable 2=phyLayerTable 3=atmLayerTable 4=aa14atable 5=aa15Table 6=aa10Table 7=connTable 5.5. Mapeamento de MIBs no modelo ATM Forum Na tabela abaixo, é apresentado o mapeamento das diversas MIBs ATM, incluive MIBs CMIP, para o modelo das cinco interfaces definido pelo ATM Forum. 22

23 6. AtoM MIB Esta especificação da AtoM MIB é de responsabilidade do grupo de trabalho ATOM MIB da IETF que é o encarregado pelas questões de gerenciamento ATM dentro do IETF. Ela se preocupa com a definição de objetos que auxiliam no gerenciamento de interfaces,circuitos virtuais,cruzamento de conexões, entidades AAL5 e conexões AAL5 em um ambiente AT> A especificação atual dessa MIB é baseada na SMIv2, tendo como base o protocolo de gerenciamento SNMPv2. Esta MIB tem como principal propósito o gerenciamento de circuitos virtuais permanentes (PVC - Permanent Virtual Circuit) em ambientes ATM. Apesar de oferecer objetos que possuem informações sobre circuitos virtuais comutados (SVCs),este serviço requer definições adicionais não apresentadas nesta MIB.Estas capacidades estão sendo especificadas Estas definições adicionais são especificadas numa proposta (Internet-draft), chamada Definitions of Supplemental Managed Objects for ATM Management, publicada em Jullho de

24 Com o objetivo de realizar o gerenciamento de interfaces,circuitos virtuais e cruzamento de conexões (cross-connects), são necessárias outras MIBs. Dentre elas temos: MIBs relacionadas com interfaces físicas (DS3 e SONET) e MIBs que representam aplicações que se utilizam de ATM, como SMDS e Frame Relay. Os objetos de gerenciamento definidos nesta MIB são apresentados através de tabelas e divididos de acordo com as suas funções, como descrito no diagrama a seguir: Interface Configuração Interface DS3 PLCP MIB ATM Cruzamento Conexões Circuitos Virtuais Subcamada TC Configurações VPL/VCL Descritores de Tráfego Essa tabela possui uma entrada por interface, que se utiliza de DS3 PLCP para transportar células sobre DS3. Cada entrada possui informações sobre o número de eventos de erro (atminterfaceds3plcpsefs),existência de alarmes (atminterfaceds3plcpalarmsate) e de períodos de tempo em que a interface não esteve disponível (atminterfaceds3plcpuass). Uma introdução ao esquema da estrutura de informações da AtoM MIB é apresentada na figura abaixo. 24

25 6.1. Descrição da AtoM MIB Informações da interface ATM As informações relativas à camada física ATM são organizadas em tabelas que fazem parte de três grupos: Configuração de Interface (tabela atminterfaceconftable) Essa tabela contém informações sobre a configuração da interface ATM, além das que são encontradas na tabela IfTable do grupo interfaces (MIB II). As duas tabelas utilizam a mesma variável para indexar a tabela, no caso, a variável ifindex (MIB-II). Cada entrada da tabela é composta dos parâmetros: tipo de endereço ATM utilizado (privado, NSAPE 164, E164 nativo, etc); endereço ATM da interface o nome e o endereço IP da interface do sistema a que se está diretamente conectado; o número máximo de VPCs e VCCs que a interface suuporta, e o número real configurado no momento; número de bits utilizados para os campos VPI e VCI; o VPI e VCI do VCC usado para o transporte de informações de gerenciamento ILMI. Caso a interface não suporte ILMI, estes conterão o valor zero. Interface DS3 PLCP (atminterfaceds3plcptable) Este grupo é também uma extensão da tabela iftable (MIB-II), e contém parâmetros de configuração, e de estado do DS3 PLCP. Essa tabela possui uma entrada por interface,que se utiliza de DS3 PLCP para transportar células sobre DS3.Cada entrada possui informações sobre o número de eventos de erro(atminterfaceds3plcpsefss),existência de alarmes (atminterfaceds3plcpalarmstate) e de períodos de tempo em que a interface não esteve disponível (atminterfaceds3plcpuass). Subcamada TC (atminterface TCTable) Este grupo possui parâmetros de estado e de configuração da subcamada TC. Também é uma extensão da tabela iftable. Cada entrada se relaciona com uma interface que utiliza a subcamada TC para transportar células. As entradas possuem dois atributos (atminterfaceocdevents e atminterfacetcalarmstate) que contém informações sobre a existência de problemas na delineação de células.exemplos destas interfaces são aquelas que possuem como camada física SONET ou DS3. 25

26 Informações de circuitos virtuais ATM As informações de circuitos virtuais ATM estão distribuídos em três tabela Juntas elas descrevem os circuitos virtuais, sejam eles SVCs ou PVCs,presentes no dispositivo ATM gerenciado. São utilizadas tabelas distintas para Virtual Path Links (atmvpltable) e Virtual Channel Links (atmvcltable). Uma terceira tabela (atmtrafficdescrparamtable) mantém as informações do contrato de tráfego de cada circuito. Na figura a seguir é apresentado um exemplo de configuração de um circuito virtual Configuração de VPLs e VCLs (atmvpltable e atmvcltable) Esses grupos contém informações de configuração e do estado de um circuito VPL/VCL bidirecional definidos a partir das duas tabelas: atmvpltable e atmvcltable. Como seus parâmetros são similares, serão detalhadas juntamente. Estas tabelas são definidas nos hosts e nos comutadores ATM. Cada entrada numa das tabelas contém os parâmetros: 26

27 o identificador de caminho virtual, que é o VPI (atmvplvpi) para conexões VPL e a combinação de VPI e VCI (atmvclvpi e atmvclvci) para VCL; atributos que caracterizam o estado operacional do circuito: Adminstatus implementado para um VPL/VCL indicando se o fluxo de tráefgo está habilitado ou não; OperStatus - especifica o estado operacional do VPL/VCL LastChange Timestamp que indica a última alteração do estado do circuito. índices para a tabela de descrição de tráefgo (atmtrafficdescrparamtable um para cada direção de tráfego dentro do circuito), e um ínice para a tabela de cruzamento de conexões (CrossConnectTable) que permite identificar VCLs comuns a um VCC. O grupo VCL possui alguns parâmetros em sua tabela. Estes só são aplicados no caso em que o fim de um VCL é também o fim de um VCC. São eles:atmvccaaltype (identifica o tipo de camada de adaptação uytilizada neste circuito),atmvccaal5cpcstransmitsdusize(descreve o tamanho máximo da Aal5 CPCS SDU em octetos que é suportado na direção de transmissão deste VCC),atmVccAal5CpcsReceiveSduSize (igual o anterior na direção de recepção) e atmvccaal5encapstype (especifica o tipo de encapsulamento de dados usado sobre a camada AAL5 SSCS). Se estiver sendo utilizada AAL5, são usados mais alguns parâmetros da tabela VCL.: atmvccaaa5cpcstransmitsdusize descreve o tamanho máximo da AAL5 CPSC SDU suportada no fluxo de transmissão de um VCC; atmaal5cpcsreceivesdusize idêntico ao anterior, só que na recepção; atmaal5encapstype especifica o tipo de encapsulamento de dados que está sendo utilizado sobre a camada AAL5 SSCS, como definido na RFC

28 Descritores de tráfego ATM (atmtrafficdescrparamtable) Este grupo possui um conjunto de parâmetros que caracterizem o tráfego ATM, incluindo a classe de Qualidade de Serviço (QoS). Cada entrada descreve o tráfego que é transportado sobre um circuito virtual, tanto quantitativamente quanto qualitativamente. Os descritores de tráfego estão de acordo com os resutados da negociação, quando do estabelecimento da conexão. Quando é criada uma nova entrada nesta tabela seus parâmetros são checados para garantir a consistência. Os relacionamentos entre as tabelas de configuração de circuitos virtuais (VPL e VCL) e a tabela de parâmetros de descrição de tráfego são apresentados na figura abaixo. Os atributos definidos em cada entrada da tabela de descritores podem ser divididos em dois subconjuntos: Parâmetro atmtrafficdescrtype descreve o tipo de descritor de tráfego e como interpretar os parâmetros associados, que caracterizam o fluxo de tráfego. Os atributos definidos neste subconjunto são utilizados pelo serviço UPC Usage Parameter Control). Os parâmetros especificados para cada descritor de tráfego previsto na especificação da AtoM MIB são mostrados na tabela abaixo. 28

29 Parâmetro atmtrafficqosclass, que caracteriza a classe de serviço em uso no circuito virtual (Classes A a D, ou não especificada) Cruzamento de Conexões VP/VC (atmvp(vc)crossconnecttable) Esses grupos descrevem informações sobre estado e configuração de todos os cruzamentos de conexão VP/VC relacionados com PVC (Permanent Virtual Circuit), sejam eles ponto a ponto,ponto a multiponto e multiponto a multiponto. Estas informações são disponibilizadas somente em comutadores onde temos a funcionalidade de cruzamento de conexões. Os grupos se baseiam respectivamente nas tabelas atmvpcrossconnecttable e atmvccrossconnecttable, que serão descritas juntas em virtude de suas similaridades. Um conjunto de entrada nesta tabela representa o cruzamento de conexões VPC/VCC bidirecionais.para uma conexão ponto a ponto temos uma entrada, ponto a multiponto com N nós folhas temos N entradas e para conexões multiponto a multiponto entre N nós temos, N(N-1)/2 entradas. Cada uma dessas entradas referencia duas entradas nas tabelas de circuitos virtuais (VPL e VCL). Cada cruzamento de conexões é efetuado necessariamente entre dois circuitos virtuais em interfaces distintas. Os parâmetros que caracterizam cada cross-connect, são: 29

30 CrossConnectAdminStatus indica o estado administrativo do cross-connect. Este parâmetro é alterado por meio de comandos do administrador de rede, que habilita ou não o cruzamento; CrossConnectL2HoperStatus e CrossConnectH2LopenStatus indica o estado operacional do circuito em uma das direções AAL5 Connection Performance Statistics AAL5VccTable Contém informações sobre os erros que podem ocorrer um VCC do tipo AAL5. Cada entrada na tabela é identificada pelo índice da interface, e pelo VPI e VCI do VCC correspondente. As informações são: número de AAL5 CPCS PDUs recebidas com erro de CRC; número de AAL5 CPCS PDUs descartadas por não terem sido totalmente remontadas no tempo estipulado; número e AAL5 CPCS descartadas por terem sido recebidas AAL5 CPCS SDUs com tamanho superior ao especificado. 7. MIB Suplementar à AtoM MIB A AtoM MIB não oferece todas as funcionalidades necessárias ao gerenciamento de circuitos comutados virtuais (SVCs). Por esta razão, o IETF publicou um Internet Draft descrevendo uma MIB que permitisse a gerência de SVCs, chamada Supplemental Managed Objects MIB. Como o próprio nome já sugere, esta MIB deve ser usada em conjunção com a AtoM MIB (RFC 1695). Além do gerenciamento de SVCs, esta MIB introduz conceitos novos como os Túneis VP. A estrutura funcional da MIB suplementar é apresentada na figura a seguir: 30

31 7.1. Informações de endereços ATM A MIB suplementar incorpora dois tipos de informações sobre endereços ATM: Todos os endereços ATM válidos numa interface (atmifadminaddrtable) Essa tabela estende a tabela iftable (MIB-II), apresentando o registro de todos os endereços ATM secundários associados a uma interface ATM. Essa tabela é utilizada somente em comutadores. Mapeamento entre endereços ATM e os circuitos virtuais A MIB suplementar apresenta duas tabelas para mapeamento de endereços, um para mapear valores de VPI/VCI nos endereços ATM locais e remotos do circuito (atmvcladdrbindtable), e outra para a direção oposta (atmaddrvcltable). Ou seja, tendo o VPI/VCI de um circuito virtual (VPL) podem ser encontrados os endereços ATM das duas entidades que se conectam através deste VCL, e vice-versa. No caso de conexões ponto-a-multiponto são encontradas várias entradas nas tabelas para uma VCL Informações de Circuitos Virtuais Essa MIB contém algumas informações adicionais sobre cada circuito virtual. A AtoM MIB já apresenta a maioria das informações necessárias sobre estes circuitos. As tabelas atmvclstattable e atmvplstattable estende as tabelas da AtoM MIB com informações estatísticas sobre os circuitos virtuais, para fazer o monitoramento da utilização de VPLs / VCLs em termos de células que entram e que saem. Os atributos definidos para cada tabela são: TotalCellIns: número total de células ATM válidas recebidas por este VPL ou VCL incluindo células com CLP=0 ou CLP = 1 Clp0CellIns: número de células ATM válidas recebidas por este VPL ou VCL vom CLP = 0; TotalDiscards: número total de células ATM válidas descartadas neste VCL / VPL pela entidade de policiamenbto de tráfego, incluindo células com CLP = 0 ou CLP = 1; 31

32 ClpoDiscards: número total de células ATM válidas recebidas com CLP=0 por este VPL/VCL, e que foram descartadas pela entidade de policiamento de tráfego; TotalCellsOuts: número total de células ATM válidas enviadas por este VPL/VCL, incluindo células com CLP = 0 ou CLP = 1; Clp0CellOuts: número total de células ATM válidas com CLP=0, enviadas por este VPL/VCL; TaggedOuts: número total de células ATM válidas assinaladas pela entidades de policiamento de tráfego de CLP=0 para CLP=1 neste VPL/VCL Informações de Conexões Cruzadas (Cross Connects) Nesta MIB são mantidas informações somente do cruzamento de conexões em SVCs. Informações sobre PVCs são mantidas nas tabelas AtoM MIB. Fazem parte deste grupo duas tabelas, atmsvcvccrossconnecttable e atvpsvcconnecttable, onde são mantidas informações sobre a configuração e o estado operacional de todos os SVCs. O relacionamento entre as tabelas cross-connect da MIB suplementar e as tabelas da AtoM MIB são apresentadas na Fig.6, a seguir. 32