As redes ATM possuem capacidade de tratar vários tipos de tráfego e oferecer, por consequencia, uma grande variedade de serviços, caracterizando-se esta como uma de suas principais virtudes. Estes aspectos, no entanto, podem causar problemas gerenciais, por se tornar, o controle de tráfegos distintos e peculiares, uma atividade deveras complexa [ARA 98].
Um sistema de gerência de redes eficiente torna-se indispensável,
dada a complexidade e a flexibilidade inerentes às redes ATM. Soluções
que eram adequadas para outras tecnologias, no entanto, passam a ser insuficientes
para o gerenciamento ATM, sugerindo uma redefinição de paradigmas
ou o acréscimo de novas funcionalidades [VAS 98]
1 Peculiaridades do gerenciamento ATM
Em muitos aspectos, o gerenciamento de redes ATM dá-se da mesma forma que o gerenciamento de redes não-ATM. Ambos recaem nas mesmas cinco áreas funcionais [ULB 97]: gerência de falhas, gerência de configuração, gerência de contabilidade, gerência de desempenho e gerência de segurança. Algumas características, no entanto, são peculiares ao gerenciamento de redes ATM [ABU 98]:
· as estações de gerência passam a necessitar de uma maior robustez e um maior poder de processamento, uma vez que as taxas altas e variáveis de dados significam uma maior chegada de informações à plataforma de gerência em qualquer intervalo de tempo, possivelmente em rajadas;
· manutenção de uma maior quantidade de informações da camada física, visto a aceitação de múltiplos tipos de mídia;
· agregação de complexidade de mais uma camada devido a introdução de caminhos virtuais sobre caminhos físicos;
· necessidade de reportagem de violações em relação à garantia de diversos níveis de QoS.
1.1 Gerência de Falhas
Quando se trata da gerência de redes ATM, falhas devem ser identificadas e isoladas de maneira rápida. A geração de alarmes ocorre com uma frequência muito maior que na gerência de redes não-ATM, uma vez que as redes ATM operam em taxas muito mais elevadas, sendo ainda, de um modo geral, muito mais amplas. Assim, uma maior quantidade de informações pode ser perdida em curtos intervalos de tempo, dada a transmissão de dados em alta velocidade.
Assim como em redes não-ATM, probes e analisadores podem residir em qualquer local da rede, necessitando, no entanto, de um maior poder de processamento para a monitoração e a notificação. Estações de gerenciamento precisam estar aptas a manter armazenado um grande volume de dados, sem, todavia, sobrecarregar operadores de rede, fazendo com que o processo de filtragem e correlação de alarmes passem a ter grande importância.
Os principais tópicos a serem abordados são [DUT 95]:
· deteção automática de erros de software e hardware, de modificações no estado dos módulos dos switchs ATM ou ainda de alterações no estado de links ATM;
· monitoração de parâmetros críticos, tais como contadores de conexões e de SVCs, assim como a obtenção de estatísticas em relação a erros em portas através da definição de limiares e taxas de amostragens pelo usuário;
· realização de testes dinâmicos, sob demanda, de módulos de hardware, interfaces ATM e, através da utilização de protocolos OAM, conexões ATM, VCs, VPs e links.
1.2 Gerência de Configuração
A gerência de configuração cobre tanto a rede em si, quanto o fluxo de dados sobre a mesma.
Em relação a rede, vários parâmetros devem ser configurados antes de sua operação, tais como switches, roteadores e circuitos físicos. Em relação ao fluxo de dados, PVCs e SVCs também fazem parte da gerência de configuração.
A grande questão é a limitação da padronização de configuração de dispositivos e circuitos. Por consequencia, fabricantes agregam extensões aos padrões existentes, visando permitir maiores capacidades de gerenciamento, sendo as tarefas de configuração tratadas diferentemente por cada um, acarretando na impossibilidade de inter-operação.
A tarefa de controle operacional dos switchs ATM inclui:
· na adição e remoção de módulos dos switchs ATM;
· na habilitação e desabilitação de módulos, portas e demais componentes dos switchs ATM;
· na deteção e notificação de modificações na configuração dos switchs ATM, possibilitando a tomada de ações de maneira automatizada.
O controle de PVCs caracteriza-se pelas tarefas de adição, deleção e reinício.
1.3 Gerência de Contabilidade
Fabricantes ainda não chegaram a um consenso em como caracterizar, monitorar e controlar o tráfego de usuários para o suporte de vários serviços. A principal questão na gerência de contabilidade é a quantidade de portas e VCs associados a cada consumidor.
Em relação a PVCs, a contabilização por usuário não tem muito sentido, visto que usuários pagam por uma conexão a uma determinada velocidade, independente do modo com que esta venha a ser utilizada. Para a contabilização de SVCs em relação a cada usuário, em contrapartida, o sistema de gerenciamento necessita distinguir entre as diversas categorias de serviço, sendo coletadas as seguintes informações para cada chamada completada:
· número (endereço) chamado e número (endereço) do chamador;
· tempo de início e tempo de duração da chamada;
· características da chamada, tais como QoS e taxa de transmissão de células requisitada;
· total de células enviadas
e recebidas.
1.4 Gerência de Desempenho
A gerência de desempenho em redes ATM apresenta grandes desafios, à medida que passam a existir duas redes a gerenciar – a rede física e a rede virtual – ao contrário do gerenciamento em redes não-ATM.
A gerência das conexões físicas é direta, onde deve-se garantir a operação dos links na taxa mais rápida por eles suportada. Já a gerência de VCs (Virtual Circuits), por sua vez, caracteriza-se por ser mais complicada, visto que as rotas tomadas pelos VCs podem variar de acordo com as condições da rede, devendo a estação de gerencia notificar seu desempenho sem levar em consideração os links físicos por eles utilizados.
Outros importantes parâmetros a serem levados em conta são a existência de múltiplos tipos de tráfego e a necessidade de garantia de QoS, sendo de responsabilidade do sistema de gerenciamento instruir os switchs ATM para darem prioridade a um determinado tipo de tráfego sobre outro, alterando a rota de VCs com base na monitoração periódica de limiares de performance, onde a correlação de eventos passa a ter, novamente, papel fundamental.
Vários tipos de amostragens estatísticas são necessárias para a correta operação e controle de uma rede ATM, tais como:
· contadores de células transmitidas e recebidas por porta;
· contadores de células errôneas recebidas;
· contadores de células por conexão (VCs e VPs);
· contadores por canais de sinalização.
1.5 Gerência de Segurança
Embora métodos de segurança em redes ATM estejam sendo desenvolvidos e avaliados, não existem muitas opções para o controle de acesso a redes ATM. Switches ATM não possuem facilidades de controle de acesso à rede, enquanto VCs estabelecidas não apresentam informações relacionadas a fonte, destino ou aplicações envolvidas.
A utilização de firewalls garante, certamente, um maior nível de segurança, acarretando, contudo, em riscos de perda de alguns benefícios que a tecnologia ATM proporciona.
Os modelos de gerência de redes OSI e Internet [ULB 97a], baseados na arquitetura cliente/servidor – gerente/agente/objetos gerenciados, apresentam restrições quando utilizados para a gerência de redes ATM.
Estas restrições ocorrem devido às novas características apresentadas pelas redes ATM que, agregadas às peculiaridades as quais envolvem seu gerenciamento, descritas anteriormente, contribuem para que os tempos de respostas exigidos passem a ser impossíveis de serem atendidos pelo modelo de gerência tradicional.
As principais restrições são:
· habilidade da rede de prover, a cada aplicação, qualidade de serviço diferenciada;
· imprevisibilidade das demandas de tráfego;
· mecanismos de controle de tráfego, evitando problemas como perdas de células, congestionamento e buffer overflow, entre outros;
· promoção da utilização eficiente dos recursos da rede.
Ao questionar-se a eficiência do modelo de gerência tradicional para a gerência de redes ATM, duas abordagens podem ser adotadas:
· melhoria do modelo existente, através da adição de novas funcionalidades e pequenas alterações em sua estrutura, sem maiores alterações em relação a características básicas do paradigma;
· redefinição total da estrutura de gerência.
Adotou-se, para o desenvolvimento deste trabalho, a primeira abordagem. Exemplo de utilização da segunda abordagem pode ser visto em [VAS 98].
Além da possibilidade de realização do gerenciamento
de redes ATM através da utilização do protocolo SNMP
– abordagem adotada para o desenvolvimento do corrente trabalho, outras
três alternativas são passíveis de utilização:
o modelo de gerência ATM Forum, a interface ILMI e as funções
OAM.
3.1 Modelo de gerência ATM Forum
O ATM Forum definiu um modelo genérico de gerenciamento, através da utilização dos protocolos CMIP e SNMP, abrangendo as diferentes perspectivas de gerenciamento de redes ATM públicas e privadas. A figura 3.1 apresenta este modelo [KRI 97].
Figura 3.1 - Modelo ATM Forum de gerenciamento
O modelo define cinco interfaces:
l M1 - relaciona-se à gerencia de TEs conectados a switches públicos ou privados;
l M2 - relaciona-se ao gerenciamento de switches e redes ATM privados;
l M3 - vem a ser a ligação entre redes públicas e privadas para o intercâmbio de informações referentes a falhas, performance e configuração;
l M4 - relaciona-se ao gerenciamento de switches e redes ATM públicos;
l M5 - suporta interações
e troca de informações de gerência entre redes públicas.
3.2 ILMI
O ATM Forum propõe o ILMI (Integrated Local Management Interface) para o gerenciamento de uma interface M1.
O ILMI baseia-se no uso do protocolo SNMP, provendo ao usuário mecanismos de atuação, obtenção de estado e configuração relacionados aos vários parâmetros de uma interface UNI.
Cada dispositivo ATM possui uma entidade denominada UME (UNI Management Entity) associada a cada UNI. As entidades UME são responsáveis pelo suporte às funções da interface ILMI. UMEs ligadas diretamente são denominadas adjacentes. A figura 3.2 apresenta a topologia da interface ILMI.
Figura 3.2 - Topologia do ILMI
Desejando obter ou modificar alguma informação em uma UME adjacente, uma UME deve enviar uma mensagem SNMP sobre um VCC previamente definido, estando o PDU SNMP encapsulado segundo o formato AAL5. As mensagens são definidas segundo a primeira versão do protocolo SNMP, sendo considerada a utilização da segunda versão em estudo futuro.
O ILMI suporta a troca bidirecional de parâmetros de uma interface ATM entre duas UMEs conectadas, onde cada uma possui uma aplicação agente e uma aplicção gerente.
Para cada UNI presente em um dispositivo deverá existir uma MIB ILMI implementada.
Para que uma conexão ATM venha a ser estabelecida, ambos usuário e rede devem ter conhecimento dos endereços ATM a serem utilizados. O ILMI define procedimentos de registro de endereço os quais permitem a troca dinâmica de informações de endereçamento entre o usuário e a rede em uma UNI.
Um endereço ATM privado é constituído de um prefixo de rede agregado a uma porção fornecida pelo usuário. Endereços ATM públicos possuem a mesma estrutura dos endereços ATM privados ou apresentam o formato Native E.164, definido em [TAF 94].
O lado do usuário em uma UNI necessita do prefixo de rede, fornecido pelo lado da rede, com fins de formação de seu próprio endereço ATM. Em contrapartida, o lado da rede em uma UNI necessita saber quais endereços ATM são utilizados pelo lado usuário.
O ILMI encontra-se definido na UNI 3.1 do ATM Forum [TAF 94]. Originalmente, o ILMI foi definido como uma solução de gerenciamento por um período interino até encontrarem-se disponíveis os padrões de gerenciamento propostos pelo ITU-T e pelo ANSI, tendo sido entitulado como Interim Local Management Interface. Atualmente, a expectativa do ATM Forum é de utilização indefinida do ILMI, tendo sido o nome Interim substituído por Integrated.
3.3 Funções OAM
As funções OAM foram definidas pelo ITU-T e agem no Plano de Gerenciamento do modelo de referência B-ISDN, tendo como princípio a realização de uma manutenção controlada, visando minimizar a manutenção preventiva e reduzir a manutenção corretiva. A manutenção controlada consiste na monitoração de performance, teste e supervisão [PRY 95].
Cinco fase distintas são recomendadas, onde busca-se obter uma funcionalidade otimizada em termos de funcionalidade:
· monitoração de desempenho – verificação contínua ou periódica das funções de uma entidade gerenciada para a obtenção de informações de manutenção, sendo estas transportadas para entidades OAM; estas, por sua vez, utilizam as informações para a avaliação do sistema a longo prazo e controle de QoS ou ações preventivas a curto prazo;
· deteção de defeitos e falhas – verificação contínua ou periódica para a deteção de defeitos provisórios, com a manutenção de informações de eventos ou disparo de alarmes;
· proteção do sistema – exclusão de uma entidade de sua operação em caso de falha, através de seu bloqueio ou transferência de suas funções para outra entidade.
· informações de falhas ou desempenho – envio a outras entidades de gerenciamento de informações relativas à falha de uma entidade ou ao estado da mesma;
· localização de falhas – testes internos ou externos de sistemas os quais determinam a localização de entidades que falharam – a partir desta localização a fase de proteção do sistema garante a exclusão da entidade falha.
A manutenção e a operação de redes ATM são organizadas conforme um modelo em camadas, onde as funções OAM são efetuadas através de cinco níveis hierárquicos associados à camada física ou à camada ATM. A cada função é associado, ainda, um fluxo bidirecional de informações correspondente.
Os fluxos associados à camada ATM, F4 e F5, utilizam células especiais para a realização do transporte das informações, denominadas células ATM, sendo o primeiro utilizado para o gerenciamento de VPs e o segundo para o gerenciamento de VCs.
Os fluxos associados à camada física, F1, F2 e F3, diferem de acordo com as funções disponíveis nos protocolos de link.
Os recursos oferecidos pelas funções OAM fornecem aos dispositivos ATM a capacidade de obtenção de informações em relação a conexões fim-a-fim, reduzindo a necessidade de distribuição de MIBs através da rede, minimizando, consequentemente, o tráfego gerado pelo gerenciamento. [LIM 97]
Para que uma rede ATM venha a tornar-se gerenciável através do protocolo SNMP, três requisitos devem ser cumpridos [SPR 96]:
l os sistemas pertencentes à rede devem conter agentes e MIBs SNMP;
l os sistemas pertencentes à rede devem considerar que mudanças realizadas na MIB devem afetar o comportamento dos mesmos e vice-e-versa;
l gerentes devem encontrar-se aptos a enviar e receber PDUs dos agentes SNMP.
A figura 4.1 esquematiza o gerenciamento SNMP em redes ATM.
Figura 4.1 – Gerenciamento de uma rede ATM via SNMP
Para que a troca de PDUs SNMP possa ser efetuada em uma rede ATM, torna-se necessária a utilização de serviços os quais permitam a interoperabilidade entre ATM e LANs herdadas.
A solução mais direta vem a ser a definição de um bloco funcional intermediário entre ambas as tecnologias o qual emula acesso ATM por uma interface e a tecnologia de uma LAN herdada em outra.
Três propostas para a emulação de LANs herdadas sobre ATM foram elaboradas [PRO 97]:
· LANE (LAN Emulation) – garante a interoperabilidade dos dados de LANs herdadas e redes ATM [TAF95];
· Classical IP and ARP over ATM – especifica como mecanismos os quais permitem uma rede TCP/IP trafegar sobre uma rede ATM [LAU 98];
· MPOA (Multiprotocol Over ATM) utiliza e complementa as duas propostas anteriores, onde busca-se o provimento de conexões fim-a-fim entre entidades de rede de LANs herdadas conectadas a uma rede ATM [TAF97].
4.1 - MIBS
A padronização do gerenciamento de redes recai, de maneira direta, nas MIBs, as quais definem os objetos passíveis de gerenciamento, assim como os atributos associados necessários para a implementação das várias funções de gerência.
Existem várias MIBs concernentes ao gerenciamento de redes ATM, tanto baseadas em padrões SNMP quanto em padrões CMIP. Estas são definidas por várias entidades de padronização, tais como o ATM Forum, o IETF, o NM Forum e o ITU-T. Somente o ATM Forum e o IETF definiram MIBs com base no protocolo SNMP, no entanto. MIBs proprietárias também são definidas por fabricantes para a gerência exclusiva de seus produtos ATM.
Apesar de terem sido planejadas com objetivos específicos de gerenciamento, acaba por ocorrer a sobreposição de objetos gerenciáveis entre MIBs distintas, tornando-se necessária, em algumas oportunidades, a combinação de várias MIBs para a que os requisitos de gerenciamento de cada usuário venham a ser atingidos.
4.1.1 MIBs SNMP definidas pelo ATM Forum
As principais MIBs baseadas no protocolo SNMP definidas pelo ATM Forum são:
l DXI (Data Exchange Interface) MIB - define roteadores para a interface DSU (Data Service Unit), suportando gerenciamento de configuração e desempenho das interfaces DXI - basicamente uma interface M1;
l LANE (LAN Emulation) MIB - compreende a LANE Cliente MIB e a LANE Server MIB, suportando a gerência de configuração, falhas e desempenho e sendo utilizada para o gerenciamento de interfaces M2;
l M3 MIB - define objetos relacionados à porção consumidora de uma rede pública. A interface da porção pública utiliza CMIP, enquando a interface da porção privada utiliza SNMP;
l M4 SNMP MIB - suporta configuração de subredes, gerência de conexão e gerenciamento de falhas e desempemho. Constitúi-se em uma MIB lógica, permitindo o desenvolviemnto de MIBs de protocolos específicos;
l ATM AAL MIB - define objetos relacionados à camada AAL para elementos de rede no domínio de redes públicas;
l PNNI MIB - define objetos para PNNIs;
l ATM IM (Inverse Multiplexer) MIB - define objetos para a multiplexação ATM sobre sistemas de transmissão T1;
l M5 Network to Network MIB - define objetos para a troca de informações de gerência entre sistemas de gerenciamento de redes ATM distintos;
l Test Access MIB - permite controle de acesso remoto em switchs com o propósito de realização de testes.
A tabela 4.1 apresenta a aplicabilidade das MIBs em relação às interfaces definidas pelo ATM Forum.
Tabela 4.1 - Mapeamento de MIBs ao modelo ATM Forum de gerenciamento
|
|
|
MIBs proprietárias |
|
MIBs proprietárias |
|
|
|
ATM IM MIB |
|
|
4.1.1.1 ILMI MIB
A ILMI MIB [TAF 96] utilizada para a troca de informações gerenciais entre UMEs adjacentes também pode ser acessada por sistemas de gerenciamento de redes através da utilização de SNMP sobre UDP/IP/AAL5.
As funções ILMI provêem informações de configuração, controle e estado em relação a parâmetros das camadas física e ATM de uma interface ATM, constituindo estas um conjunto de objetos gerenciáveis estruturados na ILMI MIB, dispostos em <x> grupos, apresentados na tabela 4.2.
Tabela 4.2 - Grupos do ILMI MIB
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4.1.1.1.1 Informações sobre Sistema
O grupo System da MIB-II [McC 91] é incluido na ILMI MIB, sendo sua implementação obrigatória.
Mais informações sobre o grupo System podem ser
obtidas em [ULB 97].
4.1.1.1.2 Informações sobre Camada Física
Uma UNI possui uma interface ATM física a si associada. Os atributos relacionados a uma determinada interface ATM são armazenados como uma entrada na tabela atmfPortTable (grupo 1), sendo esta interface identificada pelo valor do objeto index.
A indexação da tabela suporta a combinação de todas as estruturas ILMI MIBs presentes em um dispositivo com múltiplas UNIs em uma única MIB. O valor do objeto index o qual identifica uma interface ATM em atmfPortTable será o mesmo indexador utilizado nas demais tabelas para a identificação da mesma interface.
Outros três objetos também fazem parte do grupo Physical Port:
· atmfMyIpNmAddress – endereço IP para o qual um sistema de gerência pode enviar informações gerenciais;
· atmfMyOsiNmNsapAddress – endereço NSAP para o qual um sistema de gerência pode enviar informações gerenciais;
· atmfMySystemIdentifier –
um identificador único de 48 bits pego a partir do espaço
de endereçamento MAC administrado universalmente pela IEEE.
4.1.1.1.2 Informações sobre Camada ATM
Informações referentes à camada ATM encontram-se em duas tabelas:
· atmfAtmLayerTable (grupo 2) – contém informações de estado e configuração de todas as entidades de camada ATM em um dispositivo ATM, sendo indexada de maneira correspondente a tabela atmfPortTable;
· atmfAtmStatsTable (grupo 3) – este grupo tornou-se obsoleto, não devendo mais ser implementado.
4.1.1.1.3 Informações sobre Conexões Virtuais
Informações concernentes à conexões virtuais são apresentadas em quatro tabelas:
· atmfVpcTable (grupo 4) – possui uma entrada para cada VPC de uma interface ATM e contém informações de estado. Cada entrada é identificada por um indexador correspondente ao da tabela atmfPortTable, juntamente com o valor do campo VPI;
· atmfVpcABRTable (grupo 5) – possui parâmetros operacionais relacionados aos VPCs ABR de uma interface ATM; a implementação deste grupo é opcional;
· atmfVccTable (grupo 6) - possui uma entrada para cada VCC de uma interface ATM e contém informações de estado. Cada entrada é identificada por um indexador correspondente ao da tabela atmfPortTable, juntamente com o valor dos campo VPI e VCI;
· atmfVccABRTable (grupo 7) - possui parâmetros operacionais relacionados aos VCCs ABR de uma interface ATM; a implementação deste grupo é opcional.
As informações relativas às tabelas de conexões virtuais não contém informações sobre cross connect, sendo descrito apenas o primeiro link virtual de cada conexão, não havendo possibilidade de descobrir o destino da mesma.
4.1.1.1.3 Informações sobre Traps
Dois tipos de traps são definidos, os quais indicam uma mudança de configuração ou deleção de um VPC (VpcChange) ou VCC (VccChange) na UME presente no outro lado do UNI em questão.
4.1.1.1.4 Informações sobre Registro de Endereço
Informações relacionadas ao registro de endereços encontram-se presentes em três tabelas:
· atmfNetworkPrefixTable (grupo 9) – é implementada no lado do usuário em uma UNI, contendo prefixos de rede para endereços ATM efetivos; a implementação deste grupo é obrigatória-condicional;
· atmfAddressTable (grupo 10) – é implementada no lado de rede em uma UNI, contendo endereços ATM efetivos no lado do usuário; a implementação deste grupo é obrigatória-condicional;
· atmfAddressRegistrationAdminTable
(grupo 11) – contém informações administrativas
relacionadas ao registro de endereços em uma interface ATM.
4.1.1.1.4 Informações sobre Registro de Serviços
A tabela atmfSrvcRegTable (grupo 12) é opcional, devendo ser implementada no lado de rede em uma UNI, possuindo todos os serviços disponíveis ao lado do usuário, indexados por um identificador de serviço.
4.1.2 MIBs definidas pelo IETF
O IETF define MIBs com base no protocolo SNMP para o gerenciamento de
redes ATM e para sistemas de transmissão os quais suportam ATM.
Estas MIBs encontram-se definidas nos RFCs "Definitions of Managed Objects
for the DS1 and E1 Interface Types" [BAK 93], "Definitios of Managed
Objects for the DS3/E3 Interface Type" [COX 93] e "Definitions of
Managed Objects for the SONET/SDH Interface Type" [BRO 94].
4.1.2.1 AToM MIB
O IETF definiu uma base de informações gerenciais a ser utilizada em redes ATM através do RFC 1695 [AHM 94], sendo este compatível com as definições SNMP e SNMPv2.
A AToM MIB é orientada apenas para o gerenciamento de PVCs, uma vez que o gerenciamento de SVCs requer capacidades não cobertas pelo RFC 1695. O documento Internet-Draft draft-ietf-atommib-atm2-03.txt propõe especificações de objetos adicionais para permitir o gerenciamento de SVCs.
Os objetos gerenciáveis do AToM MIB estão dispostos em 9 grupos, apresentados na tabela 4.3.
Tabela 4.3 - Grupos do AToM MIB
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cada grupo de objetos gerenciáveis é representado na AToM
MIB como uma tabela conceitual, sendo esta uma prática comum em
MIBs SNMP. As tabelas são descritas em SNMPv2 SMI.
4.1.2.1.1 Informações sobre Interfaces
Informações referentes às interfaces ATM encontram-se em três tabelas:
· atmInterfaceConfTable (grupo 1) – armazena informações de configuração específicas da tecnologia ATM associadas às interfaces ATM, em adição às informações genéricas sobre interfaces presentes na tabela IfTable (grupo 2 da MIB-II), caracterizando-se, assim, como uma extensão conceitual à tabela IfTable;
· atmInterfaceTCTable (grupo 2) – extende a tabela ifTable, contendo informações referentes à configuração DS3 (Digital Signal Level 3) PLCP (Physical Layer Convergence Protocol) e os parâmetros de estado das interfaces ATM as quais utilizam-se de DS3 PLCP para a transmissão de células sobre DS3 (a tabela só é válida se este estiver sendo utilizado);
· atmInterfaceTCTable (grupo
3) – extende a tabela ifTable, contendo informações
referentes à configuração da subcamada TC (Transmission
Convergence) e os parâmetros de estado das interfaces ATM as
quais utilizam-se da subcamada TC para a transmissão de células
sobre SONET ou DS3 (a tabela só é válida se a camada
TC estiver sendo utilizada pela interface ATM).
4.1.2.1.2 Informações sobre Links Virtuais
Informações referentes a links virtuais encontram-se em três tabelas, as quais juntas descrevem os links virtuais – tanto SVCs quanto PVCs – presentes nos dispositivos gerenciados ATM (TEs e switchs). As tabelas são:
· atmTrafficDescrParam (grupo 4) – contém um conjunto de parâmetros de tráfego ATM, sendo utilizada pelas tabelas atmVplTable e atmVclTable para atribuir parâmetros associados a tráfego e classes QoS a direções de recebimento e transmissão dos links virtuais ATM (as tabelas atmVplTable e atmVclTable indicam uma entrada na tabela atmTrafficDescrParamTable através do valor do objeto atmTrafficDescrParamIndex);
· atmVplTable (grupo 5) – armazena informações de configuração e estado de um VPL bi-direcional, podendo ser utilizada para a criação, deleção ou alteração de um VPL o qual encontra-se terminado em um dispositivo ATM, assim como VPLs transversalmente conectados a outros;
· atmVclTable (grupo 6) – armazena
informações de configuração e estado de um
VCL bi-direcional, podendo ser utilizada para a criação,
deleção ou alteração de um VCL o qual encontra-se
terminado em um dispositivo ATM, assim como VCLs transversalmente conectados
a outros;
4.1.2.1.3 Informações sobre Cross Connects
As informações relacionadas às conexões transversais descrevem como os links virtuais conectam-se entre si. Este tipo de informação encontra-se presente apenas em equipamentos ATM os quais possuem a funcionalidade de conexão transversal, como switches ATM.
Informações referentes a cross connects encontram-se em duas tabelas:
· atmVpCrossConnectTable (grupo 7) – contém informações de configuração e estado de cross connects VP (o objeto atmVpCrossConnectIndex é utilizado para associar os VPLs os quais encontram-se em cross connect);
· atmVcCrossConnectTable (grupo 8) – contém informações de configuração e estado de cross connects VC bidirecionais (o objeto atmVcCrossConnectIndex é utilizado para associar os VCLs os quais encontram-se em cross connect).
Entradas nas tabelas de cross connects relacionam exatamente dois links virtuais. Conexões ponto-a-multiponto e multiponto-a-multiponto são representadas através da utilização de múltiplas entradas, as quais possuem o mesmo índice.
4.1.2.1.4 Informações sobre AAL5
Informações referentes a entidades AAL5 encontram-se em uma única tabela:
· aal5VccTable (grupo 9) – contém
estatísticas de desempenho AAL5 de um VCC na interface associada
com uma entidade AAL5 em um dispositivo ATM.
4.1.3 Aplicação da MIB-II para a gerência de redes ATM
A segunda versão da base de informações de gerenciamento (MIB-II) para uso conjunto com protocolos de gerenciamento TCP/IP é definida no RFC 1213 [McC 91], apresentando incrementos adicionais em relação à primeira versão da MIB, definida no RFC 1156. [ULB 97a]
A tabela 4.4 apresenta os grupos da MIB-II.
Tabela4.4 - Grupos da MIB-II
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
O grupo System contém informações genéricas em relação ao nodo gerenciado.
O grupo Interface define objetos genéricos para o gerenciamento de interfaces.
Assumindo que o grupo Interface esteja em concordância com as especificações definidas no RFC 1573 [McC 94] – "Evolution of the Interfaces Group of MIB-II" – o qual define a tabela de interfaces (ifTable) como contendo informações referentes às interfaces dos recursos gerenciados e cada subcamada abaixo da camada de rede de uma interface de rede como uma interface propriamente dita, a interface da camada ATM passa a ser representada como uma entrada na tabela ifTable. Esta entrada é concernente à camada ATM como um todo e não como conexões virtuais individuais, sendo as últimas gerenciadas por objetos especificados na AToM MIB. A inter-relação entre cada uma das entradas da tabela fTable é obtida no grupo Interface Stack Group, definido no RFC 1573. [AHM 94]
A interpretação dos objetos do grupos System e
Interfaces para o gerenciamento ATM encontram-se no
Anexo B.
5.1 Escolha dos objetos gerenciáveis
Critério
Considerando-se o consórcio METROPOA, o que cada um dos consorciados:
AToM MIB (RFC 1695) – permite a gerência de PVCs ATM
atmInterfaceConfTable – informações específicas de configurações ATM associadas a uma interface ATM
|
|
|
|
|
|
|
|
|
|
|
|
|
atmInterfaceDs3PlcpTable - informações referentes à configuração DS3 (Digital Signal Level 3) PLCP (Physical Layer Convergence Procedure(Protocol)) e os parâmetros de estado das interfaces ATM as quais utilizam-se de DS3 PLCP para a transmissão de células sobre DS3 (a tabela só é válida se este estiver sendo utilizado)
|
|
|
|
AtmInterfaceTCTable - informações referentes à configuração da subcamada TC (Transmission Convergence) e os parâmetros de estado das interfaces ATM as quais utilizam-se da subcamada TC para a transmissão de células sobre SONET ou DS3 (a tabela só é válida se a camada TC estiver sendo utilizada pela interface ATM)
|
|
|
atmTrafficDescrParamTable – conjunto de parâmetros de tráfego ATM; utilizada pelas tabelas atmVplTable e atmVclTable para atribuir parâmetros associados a tráfego e classes QoS a direções de recebimento e transmissão dos links virtuais ATM (as tabelas atmVplTable e atmVclTable indicam uma entrada na tabela atmTrafficDescrParamTable através do valor do objeto atmTrafficDescrParamIndex)
|
|
|
|
|
|
|
|
|
|
atmVplTable – informações de configuração e estado de um VPL bi-direcional, podendo ser utilizada para a criação, deleção ou alteração de um VPL o qual encontra-se terminado em um dispositivo ATM, assim como VPLs transversalmente conectados a outros
|
|
|
|
|
|
|
|
|
atmVclTable – informações de configuração e estado de um VCL bi-direcional, podendo ser utilizada para a criação, deleção ou alteração de um VCL o qual encontra-se terminado em um dispositivo ATM, assim como VCLs transversalmente conectados a outros
|
|
|
|
|
|
|
|
|
|
|
|
|
|
atmVpCrossConnectTable – informações de configuração e estado de Cross Connects VP(o objeto atmVpCrossConnectIndex é utilizado para associar os VPLs os quais encontram-se conectados transversalmente)
|
|
|
|
|
|
|
|
|
|
|
|
atmVcCrossConnectTable – informações de configuração e estado de Cross Connects VC (o objeto atmVcCrossConnectIndex é utilizado para associar os VCLs os quais encontram-se conectados transversalmente)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
aal5VccTable – estatísticas de desempenho AAL5 de um VCC na interface associada com uma entidade AAL5 em um dispositivo ATM
|
|
|
|
|
|