gerenciamento de redes atm - nce.ufrj.br · orientados a conexão ou não. para o monitoramento de...
TRANSCRIPT
Universidade Federal do Rio de JaneiroNúcleo de Computação Eletrônica
GERENCIAMENTO DE REDES ATM
Ana Paula M. DumontDisciplina: Redes Legadas
Outubro de 1999
2
Índice
1. Introdução.................................................................................................................. 3 2. Áreas Funcionais do Gerenciamento de Redes.............................................................4
2.1. Gerenciamento de Configuração......................................................................5 2.2. Gerenciamento de Falhas................................................................................6 2.3. Gerenciamento de Segurança............................................................... ..........6 2.4. Gerenciamento de Desempenho.......................................................................6 2.5. Gerenciamento de Contabilização....................................................................9
3. Gerenciando redes ATM utilizando o Protocolo SNMP.................................................10 4. Modelo de Referência de Gerenciamento de Redes ATM..............................................14
5. MIBs SNMP aplicadas ao ATM....................................................................................17 5.1. MIBs mapeadas pelo ATM Forum ..................................................................18 5.2. MIBs mapeadas pelo IETF..............................................................................19 5.3. MIBs definidas por outras organizações.................................. .......................19 5.4. MIBs específicas de fabricantes......................................................................20 5.5. Mapeamento de MIBs no modelo do ATM Forum............................................22
6. AtoM MIB.....................................................................................................................23 6.1 Descrição da AtoM MIB...................................................................................25 6.1.1. Informações da interface ATM................................................................25 6.1.2. Informações de circuitos virtuais ATM.....................................................26 6.1.2.1. Configurações de VPLs e VCLs ............................................................28 6.1.2.2. Descritores de Tráfego ATM..................................................................28
6.1.2.3. Cruzamento de Conexões VP/VC..........................................................29 6.1.2.4. AAL5 Connection Performance Statistics ..............................................30 7. MIB suplementar à AtoM MIB.......................................................................................30
7.1. Informações de Endereços ATM......................................................................31 7.2. Informações de Circuitos Virtuais...................................................................31 7.3. Informações de Cross Connects......................................................................32 7.4. Sinalização.....................................................................................................33 7.4.1. Sinalização em uma interface ATM ..........................................................33 7.4.2. Parâmetros descritores de sinalização.......................................................34 7.4.3. VPL em portas lógicas ..............................................................................35
8. Integrated Local Management Interface (ILMI)...............................................................35 8.1. Protocolo ILMI.................................................................................................37 8.2. ATM Interface MIB .........................................................................................37 8.2.1. Link Management MIB .............................................................................38 8.2.1.1. Informações da camada física.............................................................38 8.2.1.2. Informações da camada ATM..............................................................39 8.2.1.3. Estatísticas da camada ATM...............................................................40 8.2.1.4. Informações de conexões virtuais........................................................40 8.2.1.5. Informações adicionais de tráfego ABR................................................41 8.2.1.6. Traps SNMP para gerenciamento de links...........................................42
8.2.2 Procedimentos de operação ILMI................................................................42 8.2.2.1. Procedimentos de Conectividade.............................................................42 8.2.2.2. Procedimentos em caso de mudanças nos atributos locais......................43 8.2.2.3. Procedimentos opcionais.........................................................................43 8.3. Address Registration MIB ................................................................................44 8.4. Service Registry MIB........................................................................................45
9. ILMI e AtoM MIB............................................................................................................45 10. CONCLUSÃO................................................................................................................47 11. REFERÊNCIAS BIBLIOGRÁFICAS................................................................................48
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 e-mails 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.
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
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.
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. 2.3. 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.
2.4. 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.
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.
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
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.
2.5. 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.
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. 3.0. 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.
SNMP
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.
Manager
MIB MIB ATM
Network
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
O serviço de transporte de 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.
SNMP Manager Entity
SNMP Agent Entity
Management information transportation service
SNMP Manager SNMP Agent
ATM Entity to be managed
MIB
12
Manager Agent
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 Agent
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
MAC
Pysical layer
UDP
IP
UDP
SNMP Manager
IP
LLC
SNMP Agent
SNMP = Simple Network Management Protocol UDP = User Datagram Protocol IP = Internet protocol LLC = Logical Link Control MAC = Medium Access Control MAC
LLC
ATM
UDP
IP
UDP
SNMP Manager
ATM
AAL5
IP
AAL5
SNMP Agent
SNMP = Simple Network Management Protocol UDP = User Datagram Protocol IP = Internet protocol LLC = Logical Link Control MAC = Medium Access Control
Pysical layer
13
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.
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.
ATM
Manager Agent
LANE
LLC
ATM
AAL5 AAL5
LLCProtocol stacks for IP over Ethernet interconnection
SNMP = Simple Network Management Protocol UDP = User Datagram Protocol IP = Internet protocol LLC = Logical Link Control MAC = Medium Access Control
IP
UDP UDP
SNMP Manager SNMP Agent
LANE
IP
Pysical layer
Protocol stacks for IP over Ethernet interconnection
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.
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:
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.
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
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 inter-relacionamentos 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.
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.
5.2. 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.
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.
5.3. 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 E3.
5.4. 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.
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 foreview
6 8 9 10 11 13 14 7
3 4 5 1 2
12
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.
1 2 3 4 5 6 7
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 1997.
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:
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.
MIB ATM Cruzamento Conexões
Interface
Circuitos Virtuais
Configuração Interface
DS3 PLCP
Subcamada TC
Configurações VPL/VCL
Descritores de Tráfego
25
6.1. Descrição da AtoM MIB 6.1.1. 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.
26
6.1.2. 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. 6.1.2.1. 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:
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 1483.
28
6.1.2.2. 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.
29
• Parâmetro atmTrafficQosClass, que caracteriza a classe de serviço
em uso no circuito virtual (Classes A a D, ou não especificada). 6.1.2.3. 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:
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.
6.1.2.4. 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:
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.
7.2. 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;
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.
7.3. 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.
33
7.4. Sinalização Na MIB suplementar estão presentes dois tipos de informação sobre sinalização. Na tabela atmSigTable estão disponíveis informações sobre a configuração das entidades de sinalização, e na atmSigDescrParamTable, informações sobre a sinalização das conexões VCC existentes. 7.4.1. Sinalização em uma interface ATM (atmSigTable) Essa tabela é uma extensão da ifTable (MIB-II) para as interfaces que suportam sinalização para a criação de conexões virtuais. A relação entre as duas tabelas pode ser vizualizado na fig. 7, abaixo.
Relação entre as tabelas iftable (MIB-II) e atmSigTable Os atributos mais importantes desta tabela são divididos nos seguintes grupos:
• Tipo de sinalização: informa o tipo de sinalização configurado (atmConfigSigType) e o que realmente está em uso na interface (atmActualSigType). Os valores possíveis são Dss2 (do ITU-T), Uni 3.0, UNI 3.1 e UNI 4.0, IISP (do ATM Forum) e B-ICI 2.0 (Broadband ISDN).
• Papel da entidade de sinalização : indica o papel que a respectiva entidade têm no protocolo de sinalização. Os valores possíveis são: symmetric, user e network;
• SSCOP : esse grupo possui informações sobre a camada de sinalização SSCOP, representadas através de dois contadores,. O primeiro contém a soma de diferentes condições de erro ocorridas nesta camada, tais como desconexões e falhas na conexão. O segundo contador contém o número de PDUs SSCOP com erro.
34
• Tentativas de setup: informa o número de tentativas de iniciar uma conexão (call setups), bem sucedidas ou não.
• Falhas no serviço: contém informações sobre falhas ocortridas no estabelecimento de um SVC, tais como: time-out (atmSigEmittTimerExpires) e rotas indisponíveis (atmSigEmmittUnavailRoutes) em sinalizações emitidas a partir da interface; e de recursos não disponíveis para efetivar a conexão (atmSigDetectUnavailResrcs), em sinalizações recebidas na interface;
• Erros de protocolo na camada de sinalização no estabelecimento de um SVC. Contém o número de Restarts receibidos (atmSigDetectRestarts) e enviados (atmSigEmittRestarts);
• Estatísticas: contém dois atributos que informam o número de conexões estabelecidas para SVCs que entram (atmSiglnEstabls) na interface relacionada e para conexões que saem (atmSigOutEstabls) da interface.
7.4.2. Parâmetros descritores de sinalização (atmSigDescrTable)
Essa tabela contém os parâmetros de sinalização negociados durante a criação de uma copnexão (Information Elemenst). Estão disponíveis informações sobre a AAL utilizada e do contrato de trpafego. Os proncipais atributos desta tabela são divididos de acordo com os Information Elements (IE) correpondentes:
• AAL: são descritos aqui o tipo de AAL (AalType) e a subcamada de convergência (AalSccsType) em uso na conexão.
• Broadband High Layer information: informações sobre o tipo de
camada que está sendo usada . (BhliType) e dados adicionais que dependem do tipo utilizado (Bhlinfo). Os valores possíveis são other, user, ISO e vendor specific.
• Broadband Bearer Capability (BBC): é feita a identificação
somente se a conexão é ponto-a-ponto ou ponto-multiponto.Não são mapeados outros parãmetros importantes do IE correpondente.
• Broadband Low Layer information: identificação do protocolo de nível 2 usado (BlliLayer2); de nível 3 (Bllilayer3), o tamanho “default” do pacote (BlliPktSize) e de como é feita a codificação dos campos OUI/PID utilizados no protocolo de nível 3 (BlliOuiPID).
35
7.4.3. VPL em portas lógicas (atmVplLogicalPortTable) O conceito de portas lógicas é introduzido na MIB suplementar para criar túneis VP. Túneis VP tem como principal utilização a interligação entre duas redes ATM privadas através de uma ou mais redes públicas mesmo que estas não suportem sinalização. As redes públicas só devem fornecer uma conexão permanente VP e as redes privadas fazem uso da sinalização para criar VCCs dentro deste VP. Os túneis VP terminam em cada uma das ponbtas em interfaces lógicas que são definidas na tabela ifTable da MIB-II. A tabela atmVpLogicalPortTable é utilizada para fazer a conexão entre um dos VPLs defindidos numa interface física ATM e a interface lógica criada. Como em qualquer outra interface , a interface lógica tenm associada uma entidade de sinalização. Essa tabela é uma extensão da tabela atmVplTable na AtoM MIB e possui uma variável booleana associada a cada VPL existente, indicando se o VPL pertence a uma porta lógica ATM.
Caso pertença, o atributo atmVplLogicalPortIndex irá indicar qual das interfaces lógicas definidas na ifTable está associada ao VPL. 8. Integrated Local Management Interface (ILMI)
Esse modelo é incluído como parte da UNI 4.0, proposto pelo ATM Forum. O objetivo desse padrão é auxiliar no gerenciamento de configuração e de obtenção de informações status de uma interface específica. Ele também incorpora um mecanismo para registro de endereços e serviços ATM através da UNI. Cada UNI de um dispositivo possui um IME (interface management Entity), associada a esta, para suportar as suas funções e dar suporte às funções ILMI. As informações de gerenciamento são trocadas somente entre IMEs adjacentes. Caso um dispositivo tenha mais de uma interface (ex: um comutador), uma IME será associada a cada interface que suporte ILMI. Cada IME executa procedimentos de agente e gerente para prover troca bidirecional de informações entre IMEs. ILMI define a sua MIB (chamada de ATM Interface MIB) separadamente do seu mecanismo de acesso. Esta abordagem não requer que existam agentes nos dois lados da UNI. Por outro lado, foram definidas IMEs que acessam as informações da MIB, diretamente sobre um VCC predefinido(normalmente VPI=0 e VCI=16), através de comandos SNMP encapsulados na AAL5. Neste caso, UDP/IP não são
36
utilizados. Outro mecanismo de acesso a esta MIB se dá através de sistemas de gerenciamento usando SNMP sobre UDP/IP/AAL5.
O protocolo ILMI é utilizado para que as UNIs adjacentes obtenham informações presentes na MIB de seus pares. As informações de gerenciamento são trocadas somente entre IMEs adjacentes.
Cada IME terá associada uma instância da MIB ILMI.
Definição do contexto ILMI A interface ILMI suporta a troca bidirecional de parâmetros entre duas IMEs diretamente conectadas. Cada IME possuirá procedimentos de agente, quando fornece informações mantidas em sua MIB às solicitações da IME adjacente, e de gerente, quando solicita informações ao seu par. Equipamentos que podem fazer uso da ILMI incluem :
• Estações de trabalho configuradas com interface ATM conectadas a um comutador;
• Comutadores ATM conectados a outris dispositivos ATM; e • Roteadores, comutadores Frame Relay ou pontes para LAN,
que possuam interfaces ATM diretamente conectadas a um comutador ATM
As interfaces ATM podem estar configuradas para operar como UNI pública, UNI privada ou PNNI, em decorrência do equipamento ou da rede ao qual estão conectadas. Em interfaces UNI, a IME deve ser configurada para atuar no lado do usuário ou no lado da rede. Nas interfaces NNI , ela irá operar de forma simétrica. Afora qualquer alteração que possa ser efetuada pelo fabricante, todas as IMEs devem conter a mesma ATM Interface MIB. Entretando, a semântica dos objetos da MIB podem ter interpretações diferentes em função da configuração da IME.
37
8.1. Protocolo ILMI O protocolo ILMI utiliza mensagens SNMP para troca informações ILMI entre IMEs adjacentes. As mensagens SNMP são formatadas de acordo com a especificação SNMPv1. Essas mensagens são encapsuladas em AAL5 Common Part Convergence Sublayer (CPCS) PDUs. Na troca de mensagens ILMI é utilizada a commuty name “ILMI”. Todas as implementações de ILMI devem suportar mensagens SNMP com tamanhos de até 484 bytes. Esse valor pode ser alterado se os dois lados suportarem tamanhos maiores.
A troca de mensagens é efetuada através de um VCC estabelecido entre as IMEs, que por defalut usa o VPI=0 e o VCI=16. Com o objetivo de um impacto mínimo na operação normal da rede, o tráfego ILMI não deve ser superior a 1% da taxa física da interface ATM. È importante que não haja descarte de células que transportam tráfego ILMI, desta forma as mesmas devem ter o campo CLP=0. 8.2. ATM Interface MIB
Também conhecida como ILMI MIB, a ATM Interface MIB possui 4 módulos: Textual Conventions MIB, Link Management MIB, Address Registration MIB e Service Registry MIB. A Textual Conventions MIB define um número de Convenções de Texto (definição de vários tipos de dados) e Identificadores de Objetos em um único módulo, de modo que outros módulos da ILMI MIB possam importar essas informações de modo consistente. A Link Management MIB provê a facilidade de gerenciamento de interface para todas as interfaces ATM. A Adress Registration MIB provê um mecanismo para o registro de endereços em uma UNI.A Service Registry MIB provê um registro geral de serviços para a localização de servidores ATM, como o LECS (Lan Emulation Configuration Server) ou o ANS (ATM Name Server). A figura abaixo mostra o tipo de informações existentes na ATM Interface MIB, correspondendo às tabelas da MIB.
A não ser que seja declarado ao contrário para porções específicas da ILMI, cada IME contém a mesma ATM Interface MIB. Contudo, a semântica de alguns objetos da MIB pode mudar dependendo do papel de cada IME (se rede ou usuário).
38
Uma interface ATM corresponde exatamente a uma interface física. Logicamente, as informações que são obtidas através do protocolo ILMI correpondem a uma única interface ATM.
Nos equipamentos que possuem mais de uma interface física, como no caso de comutadores ou estações com mais de uma placa de rede, pode ser implementada uma única MIB, indexada através da variável if Index (MIB-II) correspondente à interface física. Obrigatoriamente, um dispositivo que implemente a ATM Interface
MIB deve também implementar o grupo “system” da MIB-II. Deste modo, um IME deve prover acesso ao grupo “system” via ILMI. Desta forma, uma IME poderá usar a ILMI para identificar o sistema onde está instalada a IME adjacente.
8.2.1. Link Management MIB Este módulo provê facilidades de gerenciamento de conexões em interfaces ATM. Serão discutidas inicialmente as informações disponíveis neste módulo, e a seguir procedimentos usados na conexão ILMI. 8.2.1.1. Informações da camada física (atmPhysicalGroup) Contém informações de identificação e configuração da interface física gerenciada pela IME. Grande parte dos objetos deste grupo tem o status obsoleto na versão 4.0 da ILMI, e só devem ser implementados quando for necessária a compatibilidade com as versões anteriores. O ATM Forum considera que esses objetos devem ficar em outras MIBs padrões, como a AToM MIB.
39
Os parâmetros da tabela atmPorTable são os seguintes:
• Endereço - Na ILMI 4.0, as informações de endereço da interface ATM estão disponíveis nas tabelas de registro de endereços;
• Transmission Type – deprecated; • Media Type – deprecated; • Physical Layer operational status – deprecated; • Port Specific Information - deprecated; • Adjacency information – conjunto de informações que
identificam a interface onde a IME está operando, caso o equipamento seja gerenciável via SNMP. São eles:
• MylfName – contém o nome da interface. É obtido na variável ifname da MIB-II
• MylfIdentifier – contém um valor inteiro que permita identificar a interface. Sugere-se o uso da variável ifIndex da MIB-II.
• MylpNmAddress e MyOsiNmsapAddress – esses objetos mantém um endereço IP e um endereço NSAP do equipamento. Geralmente só é mantido um deles. Estes objetos permitem que uma aplicação de gerenciamento use a ILMI para obter o endereço IP do equipamento no outro lado da UNI, podendo desta forma, trocar informações de gerenciamento com a aplicação agente nesse dispositivo.
8.2.1.2. Informações da camada ATM (atmfAtmLayerGroup) Contém informações da configuração da camada ATM em cada interface do dispositivo. Os parâmetros mantidos para cada entrada na tabela são:
• MaxVPCs e MAXVCCs – número máximo de VPCs e VCCs que a UNI suporta;
• Configured VPCs e Configured VCCs – númerode VPCs e VCCs, comutados e permanentes,configurados na UNI;
• MaxVpiBits e MaxVciBits – indica a quantidade de bits nos campos VPI e VCI utilizados nesta interface. Existe uma relação direta entre estes valores e os objetos MaxVPCs e MaxVCCs;
• UniType – identifica se a UNI é pública ou privada; • UniVersion – indica a versão de UNI em uso: 2.0,3.0,3.1 ou
4.0;
40
• DeviceType – determina o tipo de dispositivo ATM: user ou network node;
• Llmiversion – indica a versão de ILMI que a interface suporta: unsupported ou ILMI 4.0.
• NniSigVersion – indicação da versão da sinalização PNNI suportada nesta interface:unsupported,IISP ou PNNI 1.0;
• MaxSvpcVpi e MaxSvcc Vpi – indicação do valor máximo de VPI que a sinalização ATM suporta na alocação de VPCs e VCCs comutados;
• MinSvccVci – indicação do valor mínimo de VCI que a sinalização ATM suporta na alocação de VCCs comutados.
8.2.1.3. Estatísticas de camada ATM (atmfAtmLayerTable) Este grupo ficou obsoleto na ILMI 4.0. Ele continha estatísticas do número de células recebidas,transmitidas e descartadas.Essas informações devem ficar em outras MIBs padrões. 8.2.1.4. Informações de conexões virtuais
Existem duas tabelas neste grupo com informações do estado operacional e de parâmetros de configuração das conexões virtuais que passam por esta interface: a atmfVpcTable para VPCs e atmfVccTable para VCCs. A primeira tabela é indexada pelo índice da interface na iftable (MIB-II) e pelo VPI, enquanto que a segunda é indexada pela interface e pelo VPI/VCI da conexão.
Essas tabelas não possuem informações sobre os endereços ATM das interfaces envolvidas na conexão, sejam elas locais ou remotas. Não existem de fato nesta MIB, informações que possam ser utilizadas para
41
indicar a direção das conexões virtuais. Da mesma forma, não são mantidas informações sobre o cruzamento de conexões (cross-connects). Como as tabelas apresentam parâmetros idênticos, elas serão descritas em conjunto:
• OperStatus – indica o estado operacional da conexão. Os valores possíveis para este parâmetro são: desconhecido,operacional fim-a-fim,não operacional fim-a-fim, e não operacional localmente.
• TransmitTrafficDescriptorType e ReceiveTrafficDescriptorType – indicam o tipo de descritor de tráfego associado à conexão. Como as conexões são bidirecionais, é utilizado um descritor para o sentido de transmissão, e outro para o de recepção. Na especificação da MIB são definidos diferentes de descritores, que distinguem o significado dos 5 parâmetros (Param1 a Param5). Na tabela 2 são apresentados os descritos previstos e a descrição dos parãmetros associados.
• QoSCategory – obsoleto; • TransmitQoSClass e ReceiveQoSClass – deprecated; • BestEffortIndicator – diferencia categoria de serviço CBR da UBR
quando estiber associado o descritor atmfNoClpNoScr; • Servicecategory – indica a categoria de serviço usada na
conexão: CBR,rtVBR,nrtVBR,ABR e UBR. A tabela atmfVccTable apresenta ainda os parãmetros:
• TransmitFrameDiscard e ReceiveFrameDiscard – indica que os dados oriundos desta conexão devem ser tratados como frames (AAL5 CPCS_PDU,por exemplo) ao invés de células individuais.Desta forma,é possível usar o mecanismo de Frame Discard definido na UNI 4.0.
8.2.1.5. Informações adicionais de tráfego ABR A MIB ILMI prevê dois grupos de objetos opcionais, que estendem as informações das tabelas VPC (atmfVpcTable) e VCC (atmfVccTable). Contém informações a respeito dos parâmetros operacionais de conexões VPC e VCC com tráfego ABR. Os parâmetros especificados são:
• Transmitlcr – indica a taxa inicial de transmissão (ICR) na conexão. Este valor também será utilizado após um período inativo;
42
• TransmitNrm – indica o número máximo de células de dados que podem ser enviadas para cada célula RM (Resource Management) transmitida. Varia de 2 a 256 em potências de 2;
• TransmitTrm – tempo máximo entre o envio de células RM para uma fonte ativa;
• TransmitCdf – indica o fator de decréscimo da taxa de transmissão (CutOff Decrease Factor) em função de perdas ou atrasos no retorno de células RM. Varia de 0 a 64 em potências de 2;
• Transmit Tif – indica o fator de incremento da taxa de transmissão, quando uma célula RM retorna com CI=0 e RI=0;
• TransmitRdf – indica o fator de decréscimo da taxa de transmissão em função do retorno de células RM com CI=1;
• TransmitCrm – número de células RM que podem ser enviadas antes do retorno de uma célula RM enviada.
8.2.1.6. Traps SNMP para gerenciamento de links
Na MIB ILMI são definidos dois Traps. Eles indicam a criação, alteração na configuração ou remoção de um VPC ou VCC na outra ponta da UNI. São eles: VpcChange e VccChange. Estas operações serão utilizadas nos procedimentos de mudança de atributos descrita na seção 7.2.2.2. 8.2.2. Procedimentos de operação ILMI Além da especificação das MIBs, foram definidos também procedimentos de operação na ILMI. Serão descritos a seguir os procedimentos obrigatórios em qualquer implementação de ILMI. 8.2.2.1. Procedimentos de Conectividade Os procedimentos de conectividade ILMI são usados para estabelecer a conectividade ILMI e detectar perdas nessa conexão. Esses procedimentos são obrigatórios para nós ATM (rede) e opcionais para um host ATM (usuário). Para estabelecer, testar ou restabelecer a conectividade, a IME envia uma PDU SNMP GetRequest para os objetos atmPortMyIfIdentifier, atmfMySystemIdentifier e sysUpTime.
43
O recebimento de uma resposta irá indicar que a conectividade (ainda) está estabelecida. O estabelecimento da conectividade é verificado através do envio da requisição SNMP em períodos fixos preestabelecidos (1 Seg.), até que haja o retorno de uma resposta. Uma vez recebida a resposta são iniciados procedimentos de configuração automática. Ao completar a configuração,poderá então ser iniciado o procedimento de registro de endereços. Para detectar perdas na conectividade, um IME irá testar seu par a cada 5 seg. A conectividade será considerada perdida se não houver o retorno de 4 requisições consecutivas. Estes procedimentos não afetam a operação de PVCs, da sinalização UNI ou PNNI, ou AAL de sinalização UNI ou PNNI. 8.2.2.2. Procedimentos em caso de mudanças nos atributos locais Qualquer mudança que ocorra nos grupos Virtual Path Group e Virtual Channel Group, tais como criação ou remoção de uma conexão virtual devem ser informadas ao IME vizinho através dos traps de gerenciamento de links especificados na seção 7.2.1.6. Quando o valor de qualquer objeto pertencente a qualquer outro grupo for modificado, os da camada modificado, os da camada ATM por exemplo, o IME tem que ser reinicializado para que seja efetuada a alteração. Com isso, o IME deverá:
• Declarar perdida a conectividade ILMI; • Informar às entidades de sinalização UNI e PNNI para
disconectar todas as conexões; • Atribuir o valor zero ao contador sysUpTime (MIB-II); • Enviar um trap de Coldstart para o seu IME vizinho para
indicar que a interface está sendo reinicializada; • Iniciar qualquer procedimento de configuração automática; • Realizar o registro de endereços,se for necessário; • Declarar restabelecida a conectividade ILMI.
8.2.2.3. Procedimentos opcionais A ILMI também descreve procedimentos opcionais para:
• Configurar automaticamente o tipo de interface ATM (UNI pública, UNI privada, ou PNNI), e o tipo de IME (user side, network side ou simétrico).
44
• Configurar automaticamente os parâmetros de tráfego da VCC de sinalização (VPI=0, VCI=5).
8.3. Address Registration MIB
Para se estabelecer uma conexão ATM na UNI, o usuário e a rede devem saber os endereços ATM ativos naquela UNI. Esses endereços ATM podem ser usados nas informações do “Calling Party Number” das mensagens de sinalização. Os procedimentos de registro de endereços possibilitam a troca dinâmica de informação de endereçamento entre o usuário e a rede, quando da inicialização e outros momentos. Tanto equipamentos com UNI privada como pública devem suportar mecanismos de registros de endereços.
Como especificado na UNI 4.0, um endereço ATM privado consiste de diversos campos.Dois desses,End System Identifier (ESI) e o Selector (SEL), formam a “parte do usuário” e são fornecidas pelo IME do lado do usuário. Os outros campos formam o “lado da rede”, normalmente únicos em uma UNI,sendo fornecidos pelo lado da rede.
O endereço de um terminal ATM de uma UNI privada seria obtido pela junção dos valores ESI e SEL com um prefixo da rede para aquela UNI. Os procedimentos estabelecidos para o registro de enderços consiste em:
• Troca de informações de endereçamento em momento de inicialização
• Restrições das combinações de prefixo da rede e parte do usuário
• Aceitação de prefixos de redes livres • Rejeição de valores inaceitáveis,tanto rejeição de um
prefixo de rede por parte do usuário, como a rejeição da parte do usuário por parte da rede.
• Adição/Remoção dinâmica de prefixos da rede ou parte do usuário.
• Remoção de um endereço quando a conectividade ILMI é perdida
• Indicação de suporte ou falta de suporte para o registro de endereços em uma interface.
45
Duas tabelas na MIB foram definidas para tratar do registro de endereços: uma contendo prefixos de rede (atmfNetPrefixTable) e outra contendo os endereços ATM registrados (atmfAddressTable). A tabela de prefixos da rede fica no IME do lado do usuário, mas é mantida pelo IME do lado da rede, que envia PDUs SNMP de SetRequest para registrar ou remover prefixos.Analogamente,a tabela de endereços ATM fica no IME do lado da rede, mas é mantida pelo IME do lado do usuário, que envia PDUs SNMP de SetRequest para registrar ou remover endereços ATM. Na inicialização, o registro de prefixos de rede ocorre primeiro.A seguir , o IME do lado do usuário combina a parte do usuário com prefixo da rede registrado para formar um ATM completo.Então, o IME do usuário registra esse endereço na atmfAdressTable. O grupo atmfAddressRegistrationAdminGroup, implementado em todos IMEs,contém um indicador que informa se os mecanismos de registro de endereço,descritos acima são suportados ou não naquela interface. 8.4. Service Registry MIB
A Service Registry MIB provê um registro geral de serviços para a localização de servidores ATM. Estão definidos atualmente os serviços de LAN Emulation Configuration Server (LECS) e o ATM Name Server (ANS). Esta MIB é implementada em IMEs que representam o "lado da rede". Uma estação pode obter o endereço ATM completo do servidor desejado efetuando uma consulta à tabela atmfSrvcRegTable. Será possível efetuar a conexão com o servidor.
9. ILMI E a AtoM MIB
Na especificação da UNI 3.1, as informações mantidas na MIB ILMI eram utilizadas somente para uso das UMEs (UNI Management Interface). Uma estação de gerenciamento só podia efetuar acesso SNMP às informações mantidas nas MIBs de gerenciamento, como a MIB-II e a AtoM MIB.
Na especificação da ILMI 4.0 já é previsto o uso opcional de um agente proxy SNMP.
É possível o acesso SNMP as informações da ATM Interface MIB,
em ambos os lados da UNI. Esta solução é apresentada na figura abaixo.
46
Quando o agente proxy recebe um pedido de um agente exterior, ele deve determinar se deve ter acesso diretamente a AtoM MIB ou repassá-lo para o proxy. O proxy deve também decidir se o pedido deve ser direcionado para um IME local ou para um IME remoto. Esta decisão é tomada com base na community name contida na PDU do pedido. O proxy atua no papel de agente do IME no acesso às informações da ATM interface MIB local; e no papel de gerente, para ter acesso às informações da MIB de seus vizinhos. Para cada IME, são definidas duas community names para diferenciar os pedidos para a MIB local dos pedidos para a MIB remota. Todos os equipamentos ATM pesquisados,incluindo os da Cisco, Fore e 3COM implementam ILMI. Entretanto nenhum deles possuía um agente proxy para acesso às informações disponíveis na MIB.
47
10. Conclusão
Devemos considerar dois aspectos importantes para a conclusão desse trabalho: um refere-se ao protocolo SNMP e o outro refere-se a ILMI. Em relação a ILMI é que ela não provê funções de gerenciamento nas áreas de falha, segurança e contabilização, e possui limitações em relação ao gerenciamento entre diferentes redes.
Os fabricantes implementam ILMI em seus equipamentos , mas não oferecem acesso direto às informações da MIB ILMI com SNMP. O gerenciamento de redes ATM está sendo efetuado com o uso da AToM MIB e de MIBs proprietárias. Não sabemos porque o ATM Forum mantever duas bases de informação distintas com um grande número de informações duplicadas. Um outro aspecto importante é em relação ao protocolo SNMP. Vimos que o SNMP pode ser usado como um protocolo de gerenciamento para gerenciar redes ATM. Porém existem algumas funções de gerenciamento que só podem ser realizadas através de ferramentas proprietárias e protocolos específicos. Um exemplo disso, é a configuração de rede de um switch da Cisco chamado Cisco LS1000, que pode apenas ser monitorado através de uma conexão de console proprietária ao switch.
48
11. Referências Bibliográficas: 1. Introdução à Gerência de Redes ATM
XVI Simpósio Brasileiro de Redes de Computadores
2. Internet Engineering Task Force (IETF) . “Definitions of Managed Objects for ATM Management Version 8.0”, RFC 1695, Ago.1994
3. The ATM Forum “M4 NE View”, af-nm-0071.000,Jan 1997 4. The ATM Forum “Traffic Management 4.0”, af-tm-0056.000, Abr
1996 5. The ATM Forum “ILMI Specification Version 4.0”, af-ilmi-0065.000,
Sep 1996. 6. wwwhome.cs.utwente.nl – site sobre Gerência de Rede 7. Internet Engineering Task Force (IETF). “Definitions of Managed
Objects for ATM Managemnt Version 8.0”, RFC 1695, Ago. 1994. 8. Bellcore Technical Advisory TA-NWT-001112. “Broadband ISDB User
to Network and Network Node Interface Physical Layer Generic Criteria” – Aug 1992.
9. Zbigniew Dziong , 1997 . “ATM Network Resource Management” 10. William Stallings,1996 “SNMP SNMPv2 and RMON” 11. Internet Engineering Task Force (IETF) “Suplemental ATM Management Objects”