Livrogerencia

Introduo Gerncia de
Redes ATM
Laboratrio Multiinstitucional de
Redes e Sistemas Distribudos
Mauro Oliveira
Miguel Franklin
Adriano S
Marcelo Vidal
XVI Simpsio Brasileiro de Redes de Computadores

Rio de Janeiro, maio de 1998
Introduo Gerncia
de Redes ATM
Mauro Oliveira
Miguel Franklin
Adriano Nascimento
Marcelo Vidal
Introduo Gerncia de Redes ATM
"s mulheres de nossas vidas."

Mauro, Miguel, Adriano e Marcelo.
Apresentao
A dcada de 90 tem sido aquela em que as telecomunicaes vm apresentando
boas reaes aos avanos da informtica. To indispensvel quanto os
computadores e seus programas no mundo moderno, as telecomunicaes no
entanto experimentaram um progresso tcnico menos rpido, quando constatamos
que o poder computacional das mquinas vem dobrando regularmente a cada dois
anos e que foram precisos aproximadamente vinte anos rede pblica comutada
para passar de alguns kilobits a uma centena de kilobits por segundo nas
velocidades de transmisso. Mas a situao parece se modificar at a entrada do
sculo XXI, com as telecomunicaes dando sinais de um progresso
extraordinrio, cujo efeito ser uma multiplicao por vrias centenas ou milhares
no fator de desempenho das redes. Esse progresso espetacular suportado por
avanos tecnolgicos significativos em dois domnios distintos: o da infraestrutura
fsica das telecomunicaes, principalmente atravs do uso de fibras pticas, e o
dos programas de comunicao, com nfase para a arquitetura e protocolos
necessrios para tratar redes de alta velocidade e integrar diferentes trfegos de
informao, tais como dados, voz e vdeo.
nesse segundo domnio que se insere o modo de transferncia assncrono
(ATM-Asynchronous Transfer Mode), como resultado de quinze anos de
pesquisas internacionais para encontrar uma soluo nica aos problemas de
transmisso, comutao e multiplexao de fluxos heterogneos em redes de
banda larga, de forma economicamente vivel e aceita mundialmente. a
primeira vez na histria dos avanos tecnolgicos que uma norma obtm consenso
na indstria mundial da tecnologia da informao e das telecomunicaes.
As redes em banda larga baseadas em ATM j trazem em sua arquitetura um
modelo de gerenciamento, concebido desde a origem, diferentemente das outras
arquiteturas de redes tais como OSI/ISO e TCP/IP. Sem dvida alguma esse
detalhe muito importante para o sucesso na sua aceitao nos anos vindouros.
Esse livro se constitui numa tima referncia introdutria aos modelos de
gerenciamento existentes, apresentando conceitos e arquiteturas dos sistemas OSI
iii
e Internet, com nfase para os padres em desenvolvimento para o gerenciamento

de redes ATM, bem como seus mecanismos de controle de trfego.
Jos Neuman de Souza

Professor Adjunto da UFC
Coordenador da RNP-CE
iv
Prefcio
Esta a verso preliminar do livro-texto utilizado no mini-curso "Introduo
Gerncia de Redes ATM, selecionado para apresentao no XVI SBRC
(Simpsio Brasileiro de Redes de Computadores), realizado no Rio de Janeiro
de 15 a 28 de maio de 1998.
Nascida no contexto das chamadas RDSI-FL (Redes Digital de Servios
Integrados - Faixa Larga), a tecnologia ATM tem sido tambm apresentada
como uma alternativa atraente no transporte do trfego multimdia em redes de
computadores. Vrias solues para "backbones" comerciais de alta velocidade
baseadas em comutadores ATM encontram-se, hoje, operacionais no mercado.
A atividade de gerncia de redes toma-se mais indispensvel medida que
esses sistemas so cada vez mais complexos. No sendo exceo regra, a
gerncia de redes ATM assume uma importncia vital para o melhor
desempenho e perfeito funcionamento do sistema dentro da expectativa da
Qualidade de Servio (QoS - Quality of Service) acordada entre usurio e o
provedor do servio.
O trabalho aqui apresentado resultado da experincia dos autores na
realizao de pesquisas e desenvolvimento de prottipos em gerncia de redes
de pacotes no LAR (Laboratrio Multiinstitucional de Redes e Sistemas
Distribudos) e, mais recentemente, do interesse pela gerncia de redes ATM.
Gerncia de redes de pacotes encontra-se hoje devidamente formalizada pelo
paradigma Gerente/Agente e pelo conceito de MIB onde se encontram os
Objetos Gerenciados que modelam os elementos de rede. A tecnologia ATM
introduz novos conceitos que exigem a incorporao de novas solues de
gerncia intrnsecas a esta tecnologia.
Na parte I desse livro so apresentados conceitos bsicos sobre gerncia de
redes, com destaque especial ao protocolo SNMP. Na parte II, encontra-se uma
"arrumao" didtica do universo de informaes sobre gerncia ATM,
provavelmente, a contribuio maior deste trabalho.
Os autores desculpam-se, antecipadamente, por quaisquer "descuidos de

linguagem" ou falhas na diagramao que tenham escapado "meterica"
reviso feita s vsperas do evento, procedimento infelizmente costumeiro na
academia. Em conseqncia, agradecem a gentileza dos que desejarem
contribuir com suas crticas para a edio definitiva deste trabalho.
Rio de Janeiro, 25 de maio de 1998
Os Autores
vi
Sumrio
Parte I - Gerncia de Redes de Computadores
1. Conceitos Bsicos ...................................................................... 1
1.1.
Introduo Gerncia de Redes ............................................ 1
1.1.1. O que a Gerncia de Redes ................................................ 3
1.1.2. A Importncia da Gerncia de Redes ..................................... 4
1.1.3. A Complexidade da Gerncia de Redes................................. 4
1.2.
Elementos Bsicos de Gerncia de Redes............................. 6
1.2.1. Etapas na Gerncia de Redes ................................................ 6
1.2.2. Atividades na Gerncia de Redes........................................... 6
1.3.
Objeto Gerenciado.................................................................. 9
1.3.1. Conceito.................................................................................. 9
1.3.2. Objetos Gerenciados e os Elementos de Rede ...................... 11
2. Sistemas de Gerncia de Redes ................................................ 13
2.1.
O Paradigma Gerente x Agente.............................................. 13
2.2.
MIB ......................................................................................... 14
2.2.1. Estrutura de um Objeto Gerenciado na MIB ........................... 14
2.2.2. Estrutura de Informao de Gerncia (SMI) ........................... 15
2.2.3. Exemplos de Objetos Gerenciados......................................... 16
2.3.
Arquitetura de um SGR........................................................... 17
2.3.1. Elementos de um SGR ........................................................... 18
2.3.2. Agente Proxy .......................................................................... 19
2.4.
Sistemas Abertos.................................................................... 21
3. Gerncia OSI................................................................................ 23
3.1.
Arquitetura de Gerncia OSI................................................... 23
3.1.1. Gerente, Agente e Objeto Gerenciado.................................... 23
3.1.2. SMAP, SMAE e CMIP/S ......................................................... 24
3.2.
Estrutura de Gerncia OSI...................................................... 25
3.3.
Modelo de Gerncia OSI ........................................................ 27
3.3.1. Modelo Organizacional ........................................................... 27
3.3.2. Modelo Funcional.................................................................... 29
3.3.3. Modelo de Informao ............................................................ 31
3.3.4. Modelo de Comunicao ........................................................ 33
vii
4. Gerncia Internet .........................................................................39

4.1.
O Protocolo SNMP ..................................................................39
4.1.1. Generalidades .........................................................................39
4.1.2. Descrio dos Comandos SNMP ............................................41
4.2.
O Protocolo SNMP verso 2 ...................................................42
4.2.1. Generalidades .........................................................................42
4.2.2. Estrutura de Informao Gerenciada (SMI).............................42
4.2.3. Operaes do Protocolo..........................................................44
4.2.4. MIB Gerente-Gerente ..............................................................45
4.2.5. Segurana ...............................................................................46
4.2.6. MIB SNMPv2...........................................................................46
4.3.
RMON .....................................................................................46
4.3.1. Conceito ..................................................................................46
4.3.2. RMON MIB ..............................................................................47
4.3.3. Grupo RMON MIB ...................................................................48
4.4.
SNMP & CMIP.........................................................................49
4.4.1. Similaridades...........................................................................49
4.4.2. Diferenas ...............................................................................49
4.5.
MIB ISO & MIB SNMP.............................................................51
4.5.1. MIB OSI...................................................................................51
4.5.2. MIB Internet.............................................................................53
Parte II Gerncia ATM

5. Redes ATM ...................................................................................59
5.1.
Introduo ...............................................................................59
5.2.
Modelo da Arquitetura dos Protocolos RDSI-FL......................60
5.3.
Interfaces ATM ........................................................................61
5.4.
Conexes ATM........................................................................62
5.5.
Organizao de Protocolos .....................................................63
5.5.1. Camada Fsica ........................................................................63
5.5.2. Camada Fsica ........................................................................65
5.5.3. Camada de Adaptao ATM (AAL) .........................................67
5.6.
Endereamento, Sinalizao e Roteamento ...........................68
5.7.
Categoria de Servio e Contrato de Trfego ...........................69
viii
6. Gerncia ATM .............................................................................. 75

6.1.
Introduo ............................................................................... 75
6.2.
Modelo de Referncia de Protocolos RDSI-FL ....................... 77
6.2.1. Plano de Gerncia de Camadas ............................................. 78
6.2.2. Plano de Gerncia de Planos ................................................. 79
6.3.
Modelo de Referncia para Gerncia de Redes ATM ............ 79
6.4.
CNM........................................................................................ 81
7. reas Funcionais da Gerncia ATM .......................................... 83
7.1.
Gerenciamento de Configurao ............................................ 84
7.2.
Gerenciamento de Falhas....................................................... 86
7.2.1. Vigilncia de Alarmes ............................................................. 87
7.3.
Gerenciamento Segurana ..................................................... 88
7.4.
Gerenciamento de Desempenho ............................................ 88
7.4.1. Monitoramento de Desempenho............................................. 89
7.4.2. Monitoramento de Processamento de Cabealhos ................ 90
7.4.3. Monitoramento de Protocolo na Camada AAL........................ 91
7.5.
Gerenciamento de Contabilizao .......................................... 95
8. MIBs SNMP aplicadas ao ATM ................................................... 97
8.1.
Introduo ............................................................................... 97
8.2.
AToM MIB............................................................................... 98
8.2.1. Interfaces ................................................................................ 99
8.2.2. Circuitos Virtuais ..................................................................... 101
8.2.3. Cruzamento de Conexes ...................................................... 102
8.2.4. Diagrama da Estrutura da MIB ............................................... 104
8.3.
MIBs SNMP e o Modelo de Referncia .................................. 105
8.4.
Aspectos Prticos para o Uso de MIBs................................... 106
9. ILMI (Integrated Local Management Interface) ......................... 107
9.4. ATM Interface MIB .................................................................... 109
9.5. ILMI e AToM MIB ...................................................................... 115
9.6. ILMI e os Modelos de Referncia ............................................. 116
10. Funes OAM............................................................................... 117
10.4. OAM para o Gerenciamento de Falhas .................................... 121
10.5. OAM para o Gerenciamento de Desempenho.......................... 125
ix
11. Gerenciamento de Trfego ..........................................................129

11.4. Controle de Admisso de Conexes (CAC) ............................131
11.5. Controle de Parmetros de Uso e de Rede (UPC/NPC) .........132
11.5.1. Leaky Bucket...........................................................................133
11.5.2. Tcnicas de Janelas................................................................135
11.6. Tcnicas de Notificao de Ns Terminais .............................135
11.6.1. Estimation by the End Nodes ..................................................135
11.6.2. Explicit Backward Congestion Indication .................................136
11.6.3. Explicit Forward Congestion Indication....................................136
11.7. Descarte Seletivo ....................................................................137
11.7.1. Push-Out .................................................................................137
11.7.2. Threshold ................................................................................138
11.8. Modelagem de Trfego ...........................................................140
11.9. Descarte de Quadros ..............................................................141
11.10. Controle de Fluxo ABR............................................................142
Anexos ...................................................................................145
Anexo A: MIBs....................................................................................147
A.1.
MIB Suplementar.....................................................................147
A.1.1. Sinalizao ..............................................................................148
A.1.2. Cruzamento de Conexes.......................................................151
A.1.3. Endereamento .......................................................................152
A.1.4. Circuitos Virtuais......................................................................153
A.1.5. Configuraes Extras ..............................................................155
A.1.6. Diagrama da Estrutura da MIB ................................................156
A.2.
DXI MIB ...................................................................................157
A.3.
PNNI MIB ................................................................................158
A.4.
Aplicaes de MIB-II para ATM ...............................................162
Anexo B: TILA - Uma Arquitetura Inteligente e Distribuda para o
Gerenciamento de Redes ATM
Anexo C: RENATA - Uma Ferramenta para Gerncia Pr-Ativa de
Redes ATM usando Redes Neurais
Referncias Bibliogrficas
Parte I
Gerncia de Redes
11
Captulo 1
1. Gerncia de Redes de Computadores
1.1. Introduo Gerncia de Redes

Nos ltimos anos, redes de computadores tm tido especial destaque, quer pela
proliferao das redes locais (LAN - Local Area Network) interligando computadores
pessoais (Figura 1.1), estaes de trabalhos, computadores de grande porte
(mainframes) em universidades, empresas, etc., quer pela banalizao do acesso
redes de longa distncia (WAN - Wide Area Network), notadamente o acesso
Internet, facilitando sobremaneira o processo de comunicao seja local, seja mundial1
(Figura 1.2).
Figura 1.1: LAN (Local Area Network)
Pode-se citar como exemplo o trabalho cooperativo na comunidade

acadmica, o qual seria hoje inadmissvel sem as facilidade disponveis pelas
redes de computadores.
1
DSEs
Fronteira da Sub-Rede de
Comunicao
DCEs
Figura 1.2: WAN (Wide Area Network)
Este crescimento vertiginoso das redes de computadores, bem como de suas

interligaes, tem provocado, naturalmente, discusses tanto filosficas como
tecnolgicas.
O aspecto filosfico das redes de computadores, o qual foge ao escopo deste trabalho,
nos leva a uma importante reflexo sobre a "Aldeia Global", as alteraes no "modus
vivendi" que as redes e suas interconexes produzem nos que nelas se iniciam, em
especial o uso de correios, listas eletrnicas e, mais recentemente, a chamada
"navegao" na Internet. Esta ltima, com a tecnologia WWW (World Wide Web) e
suas extraordinrias ferramentas de busca automtica (FBA), tem tido um carter
revolucionrio prprio dentro da revoluo da informao experimentada nesta
passagem de sculo. A "janela" para uma biblioteca mundial que a
Internet/WWW/FBA proporcionam, por exemplo, constitui-se uma verdadeira
mudana de paradigma scio-poltico, comparvel com o aparecimento do livro no
sculo XIV, quando, pela primeira vez democratiza-se o acesso ao conhecimento.
Figura 1.3: Integrao a Grandes Distncias
No que se refere ao aspecto tecnolgico das redes de computadores, interessa-nos

neste trabalho questes intrinsecamente associadas gerncia das chamadas redes de
alta velocidade, notadamente as redes baseadas em tecnologia ATM (Asynchronous
Transfer Mode).
1.1.1.
O que Gerncia de Redes
Gerncia de Redes de Computadores pode ser conceituada como a coordenao

(controle de atividades e monitorao do uso) de recursos materiais (modems,
roteadores, etc) e/ou lgicos (e.g. protocolos), fisicamente distribudos na rede,
assegurando, na medida do possvel, confiabilidade, tempos de resposta aceitveis e
segurana das informaes2. Portanto, gerenciar uma rede significa dotar este sistema
de mecanismos de monitoramento e controle dos elementos de rede de tal sorte a
2 A existncia de sistemas heterogneos e suas respectivas solues
proprietrias de gerncia constituem um elemento complicador na j
complexa atividade de gerncia.
permitir seu funcionamento dentro de uma Qualidade de Servio (QoS) esperada pelos
usurios da mesma.
1.1.2.
A Importncia da Gerncia de Redes
Em geral, numa empresa moderna as metas so fixadas no sentido de torn-la cada vez
maior, o que implica necessariamente em sistema de comunicao cada vez mais
complexo, suportando cada vez mais aplicaes e usurios. medida que a empresa
cresce, cria-se uma dependncia funcional da empresa com o sistema de comunicao
utilizado. Como conseqncia deste crescimento, maiores so os pontos de erro no
sistema de comunicao, capazes de prejudicar o seu desempenho como um todo.
Surge desse fato a importncia do uso eficiente de mecanismos de gerncia que
permitam manter os ndices de desempenho das redes de computadores em nveis
aceitveis.
Uma rede no gerenciada pode apresentar congestionamento anormal de trfego, m
utilizao de recursos, problemas com segurana, etc., com conseqncias desastrosas
para as empresas que tm em seus sistemas de comunicao o "calcanhar de Aquiles".
1.1.3.
A Complexidade da Gerncia de Redes
Uma implicao imediata no crescimento das redes de computadores o aumento

substancial de problemas e a conseqente necessidade de gerncia do maior nmero
possvel de recursos materiais e lgicos destas redes. importante notar tambm que a
complexidade desta gerncia provocada, principalmente, pela convivncia de
sistemas heterogneos e sistemas proprietrios (IBM, DEC etc), e suas conseqentes
diferentes solues de gerncia. Assim, a complexidade na atividade de gerenciamento
ser to maior quanto mais diversificados forem os equipamentos de redes fornecidos
por diferentes fabricantes.
Integrao Total
Centro de
Processamento
de Dados
Departamento Pessoal
Departamento Financeiro
Sala de D istribuio
Sala de
Reunies
Departamento Comercial
Diretoria
Figura 1.4: Ambiente Corporativo Integrado
Essa complexidade implicar no uso de ferramentas automatizadas associadas ao

esforo humano. medida que os sistemas baseados em redes se tornam maiores,
mais complexos e heterogneos, os custos inerentes atividade de gerncia de redes se
destacam.
Estes sistemas proprietrios foram, naturalmente, projetados para um conjunto
particular de equipamentos, com protocolos e servios proprietrios, o que resultou na
dificuldade, seno na impossibilidade destes de interoperarem. Em geral, ferramentas
de gerncia de um determinado fabricante de redes de computadores no permitem a
gerncia global em um ambiente heterogneo.
A fim de contribuir para minimizar custos que modelos e ferramentas padronizados
de gerncia de redes vm sendo pesquisados.
1.2. Elementos Bsicos na Gerncia de Redes

1.2.1.
Etapas no Processo de Gerncia
A primeira idia na soluo de um sistema de gerncia de redes consiste em se utilizar

um computador interagindo com os diversos componentes da rede a serem gerenciados
para deles extrair as informaes necessrias a sua gerncia. A Figura 1.5 mostra um
sistema integrado de gerncia de redes.
As etapas no processo de gerncia de redes so as seguintes:
Coleta de dados: um processo, em geral automtico, que consiste de monitorao
sobre os recursos gerenciados.
Diagnstico: esta etapa consiste no tratamento e anlise realizados a partir dos
dados coletados. O computador de gerenciamento executa uma srie de
procedimentos (por intermdio de um operador ou no) com o intuito de determinar
a causa do problema representado no recurso gerenciado.
Ao: uma vez diagnosticado o problema, cabe uma ao, ou controle, sobre o
recurso, caso o evento no tenha sido passageiro (incidente operacional)
1.2.2.
Atividades na Gerncia
As etapas de Coleta, Diagnstico e Ao no processo de gerncia de redes so

executadas pelas funes de Monitoramento, Tratamento e Controle.
O Monitoramento essencialmente uma funo de leitura, onde so observados e
analisados o status e o comportamento do sistema e seus componentes.
O Tratamento da informao de gerncia coletada intermedia, de forma algortmica
ou atravs de heurstica, as aes de Controle. Esta uma funo tipicamente de
escrita, onde os parmetros de configurao podem ser alterados, causando a execuo
de algumas aes predefinidas.
Sistema Integrado
de Gerenciamento
Sistema de
Gerenciamento
A
Elemento
de
Rede
Elemento
de
Rede
Sistema de
Gerenciamento
B
Elemento
de
Rede
Elemento
de
Rede
Sistema de
Gerenciamento
C
Elemento
de
Rede
Elemento
de
Rede
Figura 1.5: Sistema Integrado de Gerncia de Redes

Naturalmente, as funes de Monitoramento, Tratamento e Controle dos recursos
lgicos e fsicos de uma rede so precedidas pela fase de Interpretao de uma
poltica gerncia.
Conforme mostrado na Figura 1.6, Tratamento uma funo intrnseca ao bloco
Gerente, enquanto as funes de Monitoramento e Controle resultam em uma relao
Cliente/Servidor entre o bloco Gerente e o bloco Recursos. J a funo de
Interpretao melhor representada como uma relao inter-processos onde o bloco de
Diretivas de Gerenciamento pode ser o administrador da rede sendo gerenciada. Este
bloco pode envolver tambm outros mecanismos no-humanos como sistemas
inteligentes.
D iretivas de
G erenciam ento
1
G erente
3
4
Interpretao
M onitoram ento
Tratam ento
C ontrole
R ecursos
Figura 1.6: Fluxo de Informao de Gerncia

Uma vez estabelecida esta poltica (que inicia o processo), as atividades de Tratamento
e Interpretao se confundem, produzindo o ciclo mostrado na Figura 1.7.
Monitorar status e
receber relatrios de
eventos
Interpretar polticas
de gerenciamento e
tomar decises
Executar operaes
de controle
Figura 1.7: Ciclo da Atividade de Gerenciamento

Dentre as alternativas para se assegurar a continuidade de um servio, pode-se fazer
uso de equipamentos redundantes ou de um mecanismo de reconfigurao do
equipamento afetado. Por exemplo, na ocorrncia de uma falha em uma conexo entre
dois ns roteadores em uma WAN, o operador pode configurar a rede de tal forma que
uma rota alternativa seja ativada.
1.3. Objeto Gerenciado
1.3.1.
Conceito
Orientao a objetos nos ltimos anos tem se estabelecido como um paradigma

interessante na modelagem de sistemas de informtica. Esta abordagem, onde as
entidades da camada de aplicao so identificadas como objetos, permite que cada
recurso a ser gerenciado tambm corresponda a um objeto sobre o qual se realizam
operaes abstratas.
Um dos principais conceitos em gerncia de redes o de Objeto Gerenciado
(Managed Object), o qual pode ser definido como uma representao abstrata das
caractersticas relativas gerncia de um recurso real da rede (uma conexo, uma
entidade de camada, um dispositivo, etc), participante da comunicao entre sistemas
abertos.
Em geral, a definio de um Objeto Gerenciado apresenta dois aspectos:
Onde ele se situa (localizao dentro do sistema sendo gerenciado);
A natureza (representada por seus atributos).
Assim, a noo de Objeto Gerenciado utilizada na fase de modelagem de
informaes, para fazer abstrao dos recursos de rede sobre os quais incidem as
atividades de gerncia. Em sendo o Objeto Gerenciado a representao de um recurso
fsico ou lgico de rede, qualquer elemento de rede no modelado como um Objeto
Gerenciado invisvel ao sistema de gerenciamento.
Dois tipos de interaes entre as aplicaes de gerncia e os objetos gerenciados so
identificadas:
A primeira relativa s informaes estticas e corresponde ao uso das informaes
de gerncia pelas aplicaes como elas esto representadas no interior de uma Base
de Informaes de Gerenciamento (MIB - Management Information Base), isto ,
as aplicaes realizam suas funes com base nas informaes diretamente
recuperadas a partir dos objetos gerenciados.
A segunda relativo s informaes dinmicas e corresponde manuteno da

coerncia das informaes de gerncia no interior da MIB. Os recursos reais podem
gerar eventos que so transmitidos aos respectivos objetos gerenciados, os quais
atualizam os atributos devidos e enviam relatrios de eventos para as aplicaes
interessadas. No outro sentido, quando uma aplicao envia uma ao para um
objeto gerenciado, este atualiza o atributo referenciado antes de aplicar a referida
ao sobre o recurso real. Desse modo, uma viso coerente dos recursos
gerenciados garantida.
Aplicaes de Gerenciamento
Aes
Aes
Interface
de Gerenciamento
Eventos
Eventos
Objeto Gerenciado
do Tipo 2
Objeto Gerenciado
do Tipo 1
Aes
Interface
de Gerenciamento
Eventos
Recurso
Interface Material
(Telecomunicao)
Figura 1.8: Relao entre objetos gerenciados e recursos reais de rede
10
1.3.2.
Objetos Gerenciados e os Elementos de Rede
A classificao dos recursos reais de rede feita de acordo com as seguintes regras:
um recurso real a unidade de base de um sistema gerenciado do ponto de vista de
gerncia;
os recursos reais possuem pontos de referncia e interfaces para com os usurios, os
sistemas de gerncia e controle;
um recurso real possui uma interface de gerncia atravs da qual feita a
comunicao com o sistema de gerncia;
os recursos reais tm a capacidade de detectar a ocorrncia de eventos e de reagir s
aes de gerncia;
os recursos reais podem ser programas (software) ou materiais (hardware);
os recursos reais podem ser agrupados de acordo com as necessidades da atividade
de gerncia.
Os recursos reais devem ser claramente distinguidos de suas representaes em termos
de Objetos Gerenciados. Abaixo mostrada a correlao entre os objetos gerenciados
abstratos e os recursos reais que eles representam:
um objeto gerenciado pode representar um recurso real;
um objeto gerenciado pode representar um certo nmero de recursos reais
inter-relacionados;
vrios objetos gerenciados podem representar um nico recurso;
podem existir recursos que no possuem objetos gerenciados que os
representem. Nesse caso, esses recursos no podem ser gerenciados atravs da
interface de gerncia e, portanto, no so visveis pelo sistema.
um objeto gerenciado pode representar uma relao entre recursos;
um objeto gerenciado pode representar outro(s) objeto(s) gerenciado(s).
11
Captulo 2
2. Sistemas de Gerncia de Redes
2.1. Paradigma Gerente x Agente

Devido a natureza distribuda dos recursos (elementos de rede) a serem gerenciados, a
gerncia de redes uma aplicao distribuda. Os processos usados na atividades de
gerncia destes recursos distribudos so classificados como processo Gerente e
processo Agente (Figura. 2.1):
Sistema Aberto
Gerenciado
Sistema Aberto
Gerente
Comunicao
de Gerncia
operaes
Gerente
notificaes
Agente
Objetos
Gerenciados
Aplicaes
Figura 2.1: Modelo Gerente x Agente

O processo Gerente a parte de uma aplicao distribuda associada ao usurio da
Gerncia (processo ou humano). Ele tem a responsabilidade de realizar operaes
de gerncia (atravs do envio de comandos) sobre os Objetos Gerenciados, atravs
13
dos processos Agentes. O Gerente recebe tambm notificaes enviadas pelo

Agente.
O processo Agente a parte de uma aplicao distribuda que ir executar sobre o
Objeto Gerenciado os comandos enviados pelo processo Gerente. Assim, ele
passar para o Gerente uma viso dos objetos sendo gerenciados e refletir o
comportamento destes objetos, emitindo notificaes sobre os mesmos.
Uma aplicao de gerncia pode exercer o papel de Gerente, de Agente ou ambos. Um
processo de gerncia no papel de Agente atua sobre Objetos em seu ambiente local,
executando aes de gerncia sobre estes objetos como conseqncia de operaes
enviadas pelo Gerente.
O Agente, em geral, no pode determinar o contexto onde se inserem as operaes de
gerncia que ele executa ou das notificaes que ele envia ao Gerente. Por exemplo, o
Agente no tem como saber se as informaes solicitadas sobre um controle de erro
sero usadas para a gerncia de falhas ou para a gerncia de desempenho.
Processos Gerentes monitoram ou modificam as instncias remotas de Objetos
Gerenciados, bastando para tanto se comunicarem (atravs de um protocolo de
gerncia) com os Agentes, controlando desta forma os recursos de uma rede.
2.2. Base de Informaes de Gerenciamento (MIB)
2.2.1.
Estrutura de um Objeto Gerenciado na MIB
A atividade de gerncia de uma rede de computadores necessita de uma base para

armazenar os Objetos Gerenciados denominada Base de Informaes de
Gerenciamento ou MIB (Management Information Base).
O conceito de MIB no impe nenhuma condio, ao nvel de normalizao, de sua
estrutura interna ou a nvel de organizao local de uma base de informao. Em
outras palavras, a MIB o repositrio conceitual de todos os Objetos Gerenciados, no
importando qual seja o meio para armazenamento fsico das informaes de gerncia.
14
Um Objeto Gerenciado OSI3 (Open Systems Interconnection) na MIB definido em

termos de:
Atributos: so propriedades dos Objetos Gerenciados.
Operaes: so as operaes a que esto submetidos os Objetos Gerenciados;
Notificaes: so informaes que os Agentes podem emitir ao Gerente para
informar sobre a ocorrncia de eventos nos Objetos Gerenciados;
Relaes com outros objetos.
Um Atributo tem um valor que pode ter uma estrutura simples ou complexa. Parte da
definio de um Objeto Gerenciado a especificao do conjunto de Operaes de
gerncia que ele pode executar, bem como o efeito que estas operaes tm sobre estes
Objetos Gerenciados e seus atributos4. A execuo de operaes de gerncia pode ser
condicional, ou seja, ela pode depender do estado de um Objeto Gerenciado ou de seus
atributos.
2.2.2.
Estrutura da Informao de Gerncia (SMI)
Num cenrio tpico de um sistema de gerncia de redes, o Gerente solicita uma

operao ao Agente de acordo com o esquema conceitual dos Objetos Gerenciados.
responsabilidade do Agente fazer com que a operao sobre o Objeto Gerenciado afete
o recurso que este modela. Alguns aspectos importantes neste processo so a definio
de uma estrutura lgica, a compreenso das aes a serem executadas sobre os Objetos
Gerenciados na MIB, bem como os eventos que eles podem gerar5.
Se por um lado a informao a base para todo e qualquer processo de gerncia, em
um processo de coleta de dados necessrio adotar padres para que diversos usurios
destes dados possam falar a mesma linguagem.
Objeto Gerenciado no ambiente Internet tem uma estrutura mais
simplificada que o Objeto OSI.
4 A definio pode tambm especificar o efeito em objetos
relacionados, se existirem.
3
Entretanto, a sintaxe e a semntica destas informaes devem ser tal que possam
ser representadas dentro do contexto dos protocolos OSI.
5
15
A forma de criao de um item de dado segue uma Estrutura de Informao de

Gerenciamento ou SMI (Structure of Management Information),6 que consiste num
conjunto de regras a ser obedecido para definir e identificar variveis na MIB.
Enquanto o protocolo de gerncia diz a MIB "o que fazer", o SMI diz "como fazer",
funcionando o SMI como uma interface bem definida entre o protocolo e a MIB.
A SMI OSI e a SMI Internet determinam que todos os nomes e tipos de variveis da
MIB devem ser definidos e referenciados em ASN.1 (Abstract Sysntax Notation 1),
que uma linguagem formal padronizada pela ISO (International Standard
Organisation). A ASN.1 determina regras tanto para a linguagem humana quanto para
a sua representao codificada, que utilizada nos protocolos de comunicao.
A utilizao da ASN.1 particularmente importante quando se tm sistemas
computacionais heterogneos, que normalmente utilizam diferentes representaes
para as variveis consideradas. Com a ASN.1 tem-se uma documentao sem
ambigidades, garantindo uma implementao facilitada dos protocolos de
gerenciamento de redes.
2.2.3.
Exemplos de Objetos Gerenciados
As estruturas a seguir mostram dois Objetos Gerenciados. O primeiro deles, SysDescr,

um Objeto Internet. O segundo objeto, pduCounterObject, um Objeto OSI.
A SMI adota uma estrutura orientada a objetos na caracterizao e identificao

dos Objetos Gerenciados.
6
16
SysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRITION
"A textual description of the entity.. This value should
include the full name and version identification of the
system's hardware type, software operating-system, and
networking software. It is mandatory that only contain
printable ASCII characters."
::= {system 1}
Como fcil perceber, a estrutura (template) do Objeto OSI bem mais complexa
do que a do Objeto Internet.
pduCounterObject MANAGED OBJECT CLASS
DERIVED FROM CCITT REC.X.721 (1992)|ISO ...;
CHARACTERIZED BY
basePackage PACKAGE -- in-line PACKAGE definition
ATTRIBUTES pduCounterName
GET;
pduCounter
INITIAL VALUE syntax.initialZero
GET
; -- End of in-line PACKAGE definition
; -- End of CHARACTERIZED BY construct
CONDITIONAL PACKAGES additional Package
PRESENT IF *enable/disable control is required*;
REGISTERED AS {object-identifier 1}
2.3. Arquitetura de um SGR (Sistema de Gerncia de Redes)

Como ilustrado nas Figuras 1.5 e 1.8, a primeira idia para a realizao da gerncia de
uma rede consiste na utilizao de um computador de gerncia, de forma centralizada,
que interaja com os Objetos Gerenciados, representantes dos recursos de hardware e
17
de software passveis de gerncia, para deles extrair as informaes necessrias

identificao de uma falha, do mau funcionamento da rede, etc. A natureza da
atividade de gerncia, onde Gerentes e Agentes esto, normalmente, em mquinas
distintas, faz com que essa tarefa seja distribuda.
2.3.1.
Elementos de um SGR
Um Sistema de Gerncia de Redes (SGR) uma plataforma distribuda contendo uma

coletnea de ferramentas projetadas para a realizao de monitoramento e controle da
rede, com as seguintes caractersticas (Figura. 2.2):
Uma interface amigvel, permitindo que comandos possam ser invocados para a
realizao das tarefas de gerncia;
Uma quantidade mnima de equipamentos separados (hardware e software), o que
significa dizer que a maioria das funes de gerncia so incorporadas nos
equipamentos j existentes. Na realidade, o sistema de gerncia consiste de
hardware e software adicionais implementados entre os componentes de rede
existentes.
Cada n (host) da rede possui um conjunto de programas para a tarefa de gerncia de
redes, denominado EGR (Entidade de Gerncia de Rede).
Em sntese, a arquitetura genrica de um SGR pode ser dividida em trs categorias:
Um programa de apresentao para o usurio, cuja finalidade fornecer uma
interface amigvel;
Um programa de suporte a comunicao e acesso base de informaes, que
permitir a comunicao entre gerentes e agentes remotos e o acesso ao repositrio
local de dados, denominada MIB;
Um programa de gerncia de rede propriamente dito, responsvel pela
implementao do servio e do protocolo do modelo de gerncia adotado.
18
2.3.2.
Agente Proxy
Outro conceito muito importante na rea de gerncia de redes o de Agente

procurador ou proxy. O Agente Proxy surge da evidncia segundo a qual podem
existir elementos de rede no sistema que no suportam os padres de gerncia que
esto sendo adotados e, portanto, no podem ser consultados Nesse caso, um agente
especial ser responsvel pela converso dos pedidos do gerente para um protocolo
especfico ao elemento, conforme mostrado na Figura 2.3.
A funo do agente proxy suportada pelo mecanismo de RPC (Remote Procedure
Call), onde os mdulos Stub realizam as tarefas de empacotamento e
desempacotamento (marshalling/unmarshalling) de mensagens e chamadas remotas de
procedimentos.
Agente
Gerente
Processador
front-end (agente)
AGR
EGR
Aplic.
COM
EGR
EGR
COM
COM
SO
SO
SO
Controladora
de terminais
(agente)
EGR
COM
Agente
SO
EGR
COM
SO
AGR=Aplicao de Gerncia de Rede

EGR=Entidade de Gerncia de Rede
Aplic.=Aplicao
COM=Software de Comunicao
SO=Sistema Operacional
Figura 2.2: Elementos de um Sistema de Gerncia
19
Aplicaao de
Gerncia
Interface de Gerncia
Proprietaria
Agente Proxy
Stub
Servidor
Stub
Cliente
Stub
Cliente Proxy
Pilha de
Protocolos
Pilha de
Protocolos
Stub Servidor
Proxy
Pilha de
Protocolos
Pilha de
Protocolos
Operaoes Proprietarias
e Relatorios de Eventos
Operaoes padronizadas
e relatorio de eventos
Figura 2.3: Arquitetura do Proxy

A Figura 2.4 mostra a arquitetura do SGR da SUN (SunNetManager).
D a ta
Log
D is c o v e r
A S C II
MCB
R u n -T im e
MDB
A c tiv ity
D aem on
R e s u lts
B ro w s e r
C o n s o le
(O p e n W in d o w s )
R e s u lts
G ra p h e r
Event
D is p a tc h e r
A c tiv ity
Log
Event
Log
M a n a g e r S e rv ic e s
A g e n t S e rv ic e s
P ro x y A g e n t
AAggeennt tSSeerv
rv iciceess
AAggeennt t
A g e n t S e rv ic e s
Agent
Agent
M a n a g e d O b je c ts
Figura 2.4: SGR da SUN (SunNetManager)
20
2.4. Sistemas Abertos

O desenvolvimento de arquiteturas distribudas e heterogneas bem como a integrao
destes sistemas tm tornado cada vez mais complexa a tarefa de gerncia destas redes.
Uma soluo para a questo da heterogeneidade a adoo de sistemas normalizados
(arquitetura, funes, estrutura da informao, protocolos de gerenciamento, etc) por
parte dos fabricantes.
O Departamento de Defesa dos EUA, ao financiar o desenvolvimento da tecnologia
Internet, objetivava resolver o problema de interligao de seus computadores e redes
diferentes, de uma forma pragmtica, ou seja, induzia a uma soluo que funcionasse a
curto prazo, com a tecnologia da poca (processadores e transmisso de dados).
Por outro lado, por perseguir uma soluo "tima", de consenso da comunidade
cientfica e dos fabricantes, a soluo OSI resultou num processo demorado e "pesado"
do ponto de vista funcional. O organismo de pesquisa NM-Forum (Network
Management Forum), resultado de um consrcio de fabricantes criado em 1988 para
acelerar a implantao do modelo de gerncia OSI, tem trabalhado no sentido de
propor solues realistas e eficazes, diminuindo assim a distncia entre as propostas
normalizadas e as proprietrias.
Gerncia em sistemas abertos existentes , atualmente, baseada principalmente em
dois padres: SNMP (Single Network Management Protocol) da tecnologia Internet e
CMIP (Common Management Information Protocol) da arquitetura OSI.
O protocolo SNMP tem sua popularidade devido a sua simplicidade e sua base
instalada. Entretanto, ele contem um conjunto limitado de comandos, alm de que suas
funes so dirigidas mais gerncia de roteadores, hubs, etc. Neste sentido, diversos
fornecedores tm criado extenses do SNMP, mas o problema da falta de integrao
destes diferentes produtos reaparece.
21
O protocolo CMIP fornece um modelo mais poderoso (abrangente) de gerncia que o

SNMP. Alm disso, o fato de o CMIP ser um padro internacional definido pela ISO
permite que os fabricantes testem suas implementaes atravs de testes de
conformidade e de interoperabilidade.
Colocado no escopo dos conceitos j apresentados, o propsito de um Agente CMIP
fornecer informaes do Objeto Gerenciado para o Gerente CMIP. O Gerente envia
uma mensagem CMIP para um objeto localizado em um particular Agente. funo
do Agente decodificar a mensagem e determinar que informaes necessitam ser
recuperadas ou modificadas, e ento ele executa a tarefa.
Um Gerente CMIP genrico fornecer um mapeamento entre Objetos Gerenciados
CMIP e a representao de dados interna aplicao. funo do Agente fornecer um
mapeamento (em tempo de execuo) entre a forma interna da informao e a
representao externa, face aos Objetos Gerenciados7.
O contexto no qual se inscrevem o CMIP e o SNMP no diferente, nem poderia, do
contexto controvertido que d margem a comparaes entre solues OSI e solues
Internet.
A relao Gerente/Agente no necessariamente um-a-um, embora que para

um dado Objeto esteja associado um nico Agente. A um Agente podem estar
associados vrios Gerentes, sendo a recproca falsa.
7
22
Captulo 3
3. Gerncia OSI
3.1. Arquitetura de Gerncia OSI

3.1.1.
Gerente, Agente e Objeto Gerenciado OSI
Diversos trabalhos tm sido realizados para a definio de modelos de especificao

de um sistema de gerncia, provendo mecanismos para a monitoramento, controle e
coordenao de recursos em um ambiente OSI, e definindo padres de protocolos OSI
para troca de informaes entre estes recursos8.
O modelo de gerncia OSI define um sistema integrado, composto de Gerentes, de
Agentes e de Objetos Gerenciados que modelam os recursos de interesse do sistema de
gerncia, como definido no item 1.3. O Gerente coleta informaes sobre os Objetos
Gerenciados atravs do Agente e solicita a estes Agentes que executem operaes de
gerncia a fim de controlar o funcionamento dos Objetos Gerenciados.
Conforme definido no item 1.3, o Objeto Gerenciado OSI definido por seus
atributos, pelas operaes que capaz de executar, pelas notificaes que pode emitir
e pelo seu relacionamento com outros objetos gerenciados.
Embora o modelo de gerncia se apresente atualmente como uma tendncia,

estes trabalhos no representam (ainda) uma soluo de fato.
8
23
3.1.2.
SMAP, SMAE e CMIS/CMIP
O responsvel pelas funes de gerncia num ambiente OSI o Processo de Aplicao

de Gerncia do Sistema ou SMAP (System Management Application Process). Como
mostra a Figura 3.1, o SMAP pode atuar tanto como gerente como agente.
A troca de informaes entre sistemas realizada pelas Entidades de Aplicao de
Gerncia de Sistemas, SMAE (Service Management Application Entity). A SMAE
residente no sistema agente comunica-se com a SMAE no gerente atravs do protocolo
de comunicao CMIP (Common Management Information Protocol).
Assim, o SMAP utiliza os servios de gerncia fornecidos pelo SMAE com o objetivo
de executar funes de gerncia e transporta as operaes de gerncia, as notificaes,
bem como os resultados da execuo destas operaes atravs do CMIP.
Sistema Aberto
Gerente
Sistema Aberto
Gerenciado
Comunicao
de Gerncia
operaes
SMAP
Gerente
SMAP
Agente
notificaes
SMASE
SMASE
CMISE
CMISE
Outros
ASEs
ROSE
ROSE
ACSE
Nvel de Apresentao
Outros
ASEs
ACSE
Nvel de Apresentao
Figura 3.1: Modelo de Gerncia OSI

A arquitetura OSI de gerncia definida por uma estrutura de gerncia e uma
Estrutura da Informao de Gerenciamento ou SMI (Structure Management
24
Information). Esta ltima fornece um modelo de informao e guias para a definio

dos objetos gerenciados
3.2. Estrutura da Gerncia OSI

Em relao sua estrutura de gerncia, o modelo OSI subdividido em trs reas de
gerncia (Figura 3.2):
Gerncia de Sistema;
Gerncia de Camada;
Operao de Camada.
No modelo de gerncia OSI, cada camada gerenciada pela Entidade de Gerncia da
Camada (LME - Layer Management Entity), a qual responsvel pelo mapeamento
dos objetos de gerncia na MIB em objetos e eventos reais relativos camada que
gerencia.
Gerncia de Sistemas (SM - System Management)
A Gerncia de Sistemas fornece os mecanismos para a superviso, o controle e a
coordenao dos objetos gerenciados em um sistema aberto. Estes objetos podem
pertencer a uma ou vrias camadas, sendo o SM, portanto, o nico meio de realizar a
gerncia das vrias camadas OSI.
, portanto, atravs dos protocolos do SM da camada de aplicao que quaisquer
objetos pertencentes ou associados a um sistema aberto podem ser gerenciados, o que
exige funes de apoio em todas as sete camadas.
As comunicaes entre SMs so realizadas atravs das entidades de aplicao SMAE.
Esta gerncia faz uso do protocolo do nvel de aplicao SMP (System Management
Protocol).
25
Gerncia de Sistemas
LM
SMAE
Aplicao
LM Apresentao
M
I
B
Protocolo de Gerncia
de Sistemas
Protocolo de Gerncia
de Camadas (N)
Gerncia de Sistemas
SMAE
Aplicao
LM
Apresentao
LM
LM
Sesso
Sesso
LM
LM
Transporte
Transporte
LM
LM
Rede
Rede
LM
LM
Enlace
Enlace
LM
LM
Fsica
Fsica
LM
Protocolo de Camada (N)
M
I
B
Figura 3.2: Estrutura de Gerncia OSI

Gerncia de Camadas (N - Layer Management)
A Gerncia de Camadas fornece os mecanismos que permitem a superviso e a
coordenao dos objetos de comunicao associados a uma determinada camada N, ou
seja, esta gerncia realizada sobre objetos relacionados com atividades sobre objetos
na mesma camada. Para realizar esta gerncia, um protocolo de propsito especial
denominado LMP (Layer Management Protocol) utilizado9.
Operao de Camada (N - Layer Operation)
A operao de Camada fornece os mecanismos necessrios a superviso e ao controle
de uma nica instncia de comunicao. Este tipo de gerncia no necessita de um
protocolo especfico para a troca de informaes de gerncia, como no caso da
Gerncia de Camadas. Estas informaes so trocadas fazendo-se uso do protocolo
normal de cada camada.
Esse protocolos no prestam servios de comunicao s camadas superiores,

sendo independentes de protocolos de gerncia de outras camadas.
9
26
3.3. Modelos de Gerncia de Sistemas

A Gerncia de Sistema fornece os mecanismos para a gerncia a nvel da camada de
Aplicao. Este modelo evidencia quatro aspectos ou modelos da Gerncia OSI:
Aspecto Organizacional: descreve a maneira como as aplicaes de gerncia
podem ser distribudas no que se refere ao contexto administrativo;
Aspecto Funcional: descreve o conjunto de funes de gerncia e suas
diferentes relaes entre si;
Aspecto de Informao: descreve o conjunto de funes dos Objetos
Gerenciados, suas relaes, bem como o conjunto de informaes de gerncia
associado;
Aspecto de Comunicao: descreve o servio e o protocolo necessrios
troca de informaes de gerncia.
3.3.1.
Modelo Organizacional
O aspecto organizacional na Gerncia de Sistema diz respeito natureza distribuda da

gerncia OSI. Sua arquitetura , ento, constituda de um conjunto de Gerentes e
Agentes, conforme apresentado no item 1.3.
A aplicao de gerncia pode efetuar dois tipos de tratamento:
Sistema Gerente: permite o monitoramento e controle dos Objetos
Gerenciados;
Sistema Agente: efetua operaes de gerncia sobre os objetos locais que lhe
so associados, a pedido do Gerente.
Assim, o sistema Agente necessita receber comandos e enviar notificaes ao sistema
no papel de Gerente10. As entidades que originam informaes de interesse do sistema
Gerente pertencem a uma das trs reas de gerncia OSI:
Os Objetos Gerenciados podem ser definidos de tal forma a gerar

notificaes, sempre que um evento especial acontecer.
10
27
Entidade de Aplicao de Gerncia de sistemas (SMAE),

Entidade de Gerncia de Camadas (LME),
Entidade de Comunicao das Camadas.
Com o intuito de dividir responsabilidades e de definir os limites entre as diferentes
funcionalidades de gerncia, a arquitetura divida em Domnios Gerenciais (Figura
3.3).
Cada domnio inclui um ou vrios sistemas Gerentes e Agentes que podem
simultaneamente pertencer a outros domnios. Dentro do contexto de um Sistema
Agente existem vrias informaes de interesse de uma aplicao de gerncia (tabelas
de controle de conexes, nmero de pacotes transmitidos/recebidos, etc.).
Sistema OSI A
DOMINIO 1
Sistema OSI B
Gerente
Agente
Sistema OSI C
Agente
DOMINIO 2
Agente
Gerente
Figura 3.3: Domnios Gerenciais

O fluxo de gerncia entre sistemas Gerente e Agente compreende basicamente as
seguintes etapas:
28
1. Uma aplicao no papel de gerente invoca o CMISE solicitando a execuo de

uma operao de gerncia11.
2. O CMISE monta a mensagem, solicita uma associao ao ACSE e a execuo de
uma operao remota ao ROSE12.
3. Um comando CMIP , ento, transmitido pela rede atravs do ASE ROSE, o qual
faz uso dos servios da camada de apresentao.
4. O processo inverso aos passos 3 e 2 acima acontece na estao remota: o ASE
ROSE remoto passa ao CMISE remoto (no papel de gerente) a mensagem
recebida. Este a desmonta e executa a operao solicitada
3.3.2.
Modelo Funcional
O Modelo Funcional tem por objetivo descrever um conjunto de funes aos usurios,
para o gerncia de suas redes de modo a permitir s aplicaes destes usurios
realizarem os servios necessrios gerncia, por exemplo, para detectar um elemento
defeituoso e assegurar seu isolamento.
As diferentes funcionalidades reunidas em reas denominadas SMFA (Specific
Management Functional Areas), so realizadas por elementos de servio de gerncia
especfico SMASE, o qual define a semntica e a sintaxe da informao transferida
nas Unidades de Dados do Protocolo de Gerncia, as MAPDUs (Management
Applications Protocol Data Units).
Assim, uma MAPDU representa um comando, uma resposta, uma notificao ou
qualquer outra comunicao de gerncia entre dois sistemas atravs dos SMASEs.
Nas funes que requerem intercmbio de informaes de gerncia com outros
sistemas, o elemento de servio SMASE utiliza o elemento de servio CMISE. Este,
por sua vez, fornece uma coleo de funes bsicas de gerncia, comum s cinco
reas funcionais, descritas a seguir:
11
Esta operao normalmente realizada por um SMASE
Um dos parmetros da operao a ser transmitida pelo ROSE o comando

CMIP.
12
29
Gerncia de falhas
O objetivo da Gerncia de Falhas fornecer um funcionamento contnuo da rede e de
seus servios. Ela corresponde ao conjunto de funes destinadas deteco, ao
diagnstico e correo ou isolamento de anomalias no funcionamento do ambiente
OSI, sejam provocadas por um problema material ou pelo mau funcionamento de um
componente de software. Para tanto, ele realiza uma seqncia de testes de
diagnstico.
Ex.: Inexistncia do sinal da portadora, falha em concentrador..
Gerenciamento
de Contabililizao
MIB
Gerenciamento
de Segurana
Gerenciamento
de Desempenho
SMAE
Gerenciamento
de Configurao
Gerenciamento
de Falhas
MAPDUs
SMASE
CMIP
CMISE
Apresentao
Sesso
Transporte
Rede
Enlace
Fsica
Figura 3.4: reas Funcionais

Gerncia Configuraes
O objetivo da Gerncia de Configuraes gerenciar os servios de interconexo de
sistemas abertos. Ela corresponde ao conjunto de funes relativas aos controle, a
identificao, a superviso e a coleta de informaes sobre os Objetos Gerenciados.
Ex.: Reconfigurao de um roteador devido a um trfego intenso.
30
Gerncia de Desempenho
O objetivo da Gerncia de Desempenho possibilitar a avaliao do comportamento
dos Objetos Gerenciados numa tentativa de garantir a qualidade de servio acordada
com os usurios. Ela fornece as funes que permitem coletar dados estatsticos, de
manter e examinar o histrico do estado destes objetos, com o objetivo de
planejamento e anlise do sistema13.
Ex.: Clculo da eficincia de um determinado protocolo.
Gerncia de Contabilizao
O objetivo da Gerncia de Contabilizao determinar o custo de utilizao da rede e
dos recursos nela disponveis. Ela define, para os recursos que podem ser faturados, o
custo relativo a sua utilizao, possibilitando a combinao destes custos no caso de
vrios recursos serem solicitados na realizao das necessidades do usurio.
Ex.: Custo de utilizao mensal do servio de comutao de pacotes.
Gerncia de Segurana
A Gerncia de Segurana corresponde ao conjunto de funes necessrias criao,
supresso, ao controle dos mecanismos e aos servios de segurana e do trfego de
informaes sigilosas na rede. Assim, ela suporta a poltica OSI relacionada ao bom
funcionamento da gerncia OSI, bem como a proteo dos recursos suportados por
esta gerncia.
Ex.: Proteo de senhas, com codificao criptografada.
3.3.3.
Modelo de Informao
O Modelo de Informao introduz o conceito de Objeto Gerenciado, o qual foi

anteriormente definido como a representao abstrata de um recurso lgico ou fsico a
ser gerenciado. Este modelo define os conceitos gerais, a terminologia dos Objetos
Gerenciados e a Estrutura de Informao de Gerenciamento (SMI - Structure
Management Information) que especifica o modelo a ser adotado. Este modelo deve
Este tipo de gerncia , em algumas situaes, erroneamente
confundido com a Gerncia de Falhas.
13
31
incluir a definio da estrutura da informao de gerncia armazenada na MIB, as

operaes que podem ser realizadas sobre a mesma e as notificaes que podem ser
emitidas em decorrncia de alguma operao ou alterao destas informaes.
A SMI define o conjunto de operaes que podem ser realizadas sobre os objetos na
MIB, o comportamento desses objetos mediante a execuo destas operaes,
estrutura lgica destes objetos em termos de atributos e as relaes entre eles. Estas
relaes so definidas segundo trs representaes hierrquicas a que esto sujeitos os
Objetos Gerenciados:
Hierarquia de Herana (Figura 3.5): define as relaes de herana entre as
classes de objetos gerenciados, relacionando assim as propriedades associadas
aos objetos (atributos, comportamento, pacotes condicionais, operaes e
notificaes). Uma subclasse herda todas as propriedades de sua superclasse,
independentemente da necessidade ou no destas propriedades14.
Hierarquia de Agregao ou "Containment" (Figura 3.6): define as relaes
entre instncias de objetos do tipo "est contido". Objetos de uma mesma
classe podem conter objetos da mesma classe ou de classes diferentes15.
Hierarquia de Registros (Figura 3.7): identifica os Objetos Gerenciados
independentemente das hierarquias de herana e nomeao. Esta hierarquia
especificada em ASN.1 (Abstract Syntax Notation - One).
14
A estas subclasses podem ser associadas propriedades adicionais.
Um Objeto Gerenciado que contm outro, dito superior. Um objeto

gerenciado est contido dentro de um e somente um objeto gerenciado superior.
15
32
ARVORE DE HERANA ( Inheritance Tree )

Top
Discriminator
EventForward
Discriminator
LogRecord
Connection
EventLog
Record
Transport
Connection
AlarmRecord
Figura 3.5: Hierarquia de Herana
3.3.4.
Modelo de Comunicao
A ISO definiu um modelo de comunicao entre sistemas abertos baseado no

protocolo CMIP e no servio CMISE16. O servio CMISE define um conjunto de
elementos de servios de comunicao representando as funes de base para a troca
de informaes ou de comandos CMIP entre aplicaes de gerncia. As caractersticas
dos objetos so representadas por meio de atributos. As operaes realizadas pelos
comandos CMIP podem referir-se aos atributos dos objetos ou ao objeto como um
todo.
16 A ISO no define quais os objetos gerenciados de um sistema. Ela define o
conjunto de operaes que podem ser realizadas sobre os objetos,
independentemente do que eles representam.
33
Quatro tipos de operao so definidos, os quais so mostrados a seguir, junto com

seus servios associados:
Notificao de eventos
Event-report: este servio de notificao utilizado por um sistema aberto

Agente para informar aos sistemas abertos Gerentes a ocorrncia de um
evento.
Operaes sobre atributos
Get-attribute-value: utilizado por um Gerente para solicitar um Agente

recuperar uma informao. Retorna o valor de um atributo ou uma lista de
atributos;
Set: utilizado por um Gerente para solicitar um Agente modificar uma
informao de gerncia. Vrios atributos podem ser modificados numa
mesma operao;
Operaes sobre objetos
Create: utilizado por um Gerente para solicitar a um Agente criar uma

instncia de um Objeto gerenciado.
Delete: utilizado por um Gerente para solicitar um Agente destruir uma
instncia de um Objeto Gerenciado. Vrios agentes podem ser destrudos
numa mesma operao.
Action: utilizado por um Gerente para solicitar um Agente executar uma
ao especfica e informar os resultados. Este comando pode gerar mais de
uma resposta, ou seja, pode ser executado sobre vrios objetos.
34
Controle de Associaes
Inicialize: estabelece a associao entre o Gerente e o Agente (CMISEservice-user).

Terminate: permite o trmino normal de uma associao.
Abort: permite o abandono abrupto de uma associao por um usurio.
A R V O R E D E A G R E G A O (C o n ta in m e n t T re e )
S y s te m
S y s te m Id = m ila d y
U n ix
U n ix Id = te s t
S u b s y s te m
S u b s y s te m Id = 4
E v F o rw D is c r
d is c rId = 5
tp E n tity
e n tity Id = is o d e
tp C o n n
c o n n Id = 5 6 7 8
tp C o n n
c o n n Id = 1 2 3 4
Figura 3.6: Hierarquia de Agregao

O protocolo CMIP define os elementos de protocolo utilizados para fornecer os
servios de operao e de notificao descritos dentro do servio CMISE acima. Como
todo protocolo, ele define as regras de criao e de troca de unidades de dados de
protocolos (PDU)17:
17
Ele utiliza a notao normalizada ASN.1.
35
Root
ITU-T
ISO (1)
Joint ISO ITU-T
Org (3)
Dod (6)
Internet (1)
Directory (1)
Mgmt (2)
Experimental (3)
Enterprise (1)
Private (4)
Enterprise (1)
Model (X) Reserved (0) IBM (2)

Class
Attribute
Group-Attribute
Action
Notification
Error
Name-Binding
Figura 3.7: Hierarquia de Registro

M-EVENT-REPORT (confirmado)
M-GET(confirmado)
M-CANCEL-GET (no confirmado)
M-SET (confirmado)
M-ACTION (confirmado ou no)
36
M-CREATE (confirmado)
M-DELETE (confirmado)
M-INICIALIZE (confirmado)
M-TERMINATE (confirmado)
M-ABORT (no confirmado)
Alm dessas mensagens (CMIP-PDU), facilidades so tambm definidas, permitindo a
seleo de um grupo de objetos em cima dos quais aplicvel uma determinada
operao:
"Scoping": permite selecionar um grupo de instncias de objeto sobre os
quais realizado uma operao.
"Filtering": permite definir um conjunto de testes aplicveis a um grupo de
instncias de objetos, anteriormente selecionado pela facilidade de "scoping",
sobre o qual realizado uma operao.
"Syncronization": permite sincronizar vrias operaes de gerncia a serem
realizadas sobre instncias de objetos selecionados atravs das facilidades de
"scoping" e "filtering".
A Figura 3.8, a seguir, mostra o modelo de comunicao de gerncia OSI.
37
Elemento de Servio de Aplicao para Gerenciamento de Sistemas (SMASE)
M-EVENT-REPORT
M-GET M-SET
M-ACTION
M-CREATE M-DELETE
A-Associate
A-Release / A-Abort
Elemento de Servio de Informao Comum de Gerenciamento (CMISE)

ISO 9595, ISO9596
A-Associate
A-Release / A-Abort
RO-Invoke / RO-Reject
RO-Result / RO-Error
Elemento de Servio de
Controle de Associao
(ACSE) ISO 8649
Elemento de Servio de
Operaes Remotas
(ROSE) ISO 9072
P-CONNECT / P-RELEASE
P-ABORT
P-DATA
Servio de Apresentao
ISO 8822
38
Figura 3.8: Modelo de Comunicao de Gerncia OSI.
39
Captulo 4
4. Gerncia Internet
4.1. O Protocolo SNMP

4.1.1.
Generalidades
O sistema de gerncia Internet observa a seguinte filosofia: o impacto de adicionar-se

atividades de gerncia sobre o sistema gerenciado deve ser o menor possvel. Assim, o
gerenciamento Internet baseado num protocolo simples denominado SNMP (Simple
Network Management Protocol).
Um exemplo da simplicidade do SNMP a reinicializao de um sistema. O protocolo
SNMP simula esse comando afetando o valor do atributo que indica o horrio em que
deve ocorrer a prxima reinicializao. Se o horrio corrente colocado neste atributo,
o sistema reinicializado18.
O SNMP um protocolo de solicitao/resposta assncrono. Com efeito, o SNMP
utiliza o princpio de leitura de variveis a distncia ("polling"): cada mquina onde se
situa um Agente, coordena um certo nmero Objetos Gerenciados os quais so
acessados periodicamente pelo protocolo para leitura (monitoramento) ou escrita.
Basicamente, o SNMP tem dois tipos de comandos: um para recuperar o valor de um
atributo e outro para afetar o valor deste atributo. Alm destas leitura e escrita simples
sobre os Objetos Gerenciados, o SNMP oferece duas outras operaes: operao de
fcil concluir que a incluso de novos Objetos na MIB equivale
incluso de uma nova operao.
18
40
leitura sobre uma lista de Objetos e a operao "trap". Este comando permite ao
gerente ser notificado sobre eventos crticos que ocorram no sistema gerenciado.
Gerente SNMP
Trap
SetRequest
GetResponse
GetRequest
Mensagens
SNMP
GetNextRequest
Objetos SNMP
Gerenciados
Trap
SetRequest
GetResponse
GetRequest
GetNextRequest
Aplicao de
Gerenciamento
Agente SNMP
UDP
UDP
IP
IP
Protocolos dependentes
de rede
Protocolos dependentes
de rede
Rede de
Comunicao
Figura 4.1: Operaes do Protocolo SNMP

A exemplo do modelo de gerenciamento OSI, num quadro tpico, o Agente SNMP
aceita os comandos vindos do Gerente, executa as operaes indicadas e retorna ao
Gerente a resposta devida. Portanto, o comportamento do Agente SNMP pode ser
sumarizado nos seguintes passos:
1.
2.
3.
4.
5.
Ele recebe comandos do Gerente;

Traduz o comando para uma formato interno;
Pesquisa na MIB o Objeto Gerenciado referenciado no comando SNMP;
Executa a operao solicitada pelo Gerente sobre o Objeto19;
Traduz a resposta para um formato externo;
Caso seja solicitada uma operao sobre mltiplos objetos, os passos

3 e 4 sero repetidos mltiplas vezes.
19
41
6. Envia a resposta.
4.1.2.
Descrio dos Comandos SNMP
O SNMP um protocolo simples, com apenas quatro operaes:

Operao Get: permite a leitura de atributos dos Objetos Gerenciados
armazenados na MIB. A PDU (Protocol Data Unit) utilizada para essa
operao (Figura 4.2) recebe como argumento o identificador do elemento de
rede a ser gerenciado (onde se encontra o Agente), alm do identificador do
Objeto Gerenciado;
Tipo de PDU
request-ID
variable-bindings
Figura 4.2: PDU para GetRequest, GetNextRequest e SetRequest

Operao Get-next: recebe como argumento o identificador do elemento de
rede a ser gerenciado (onde se encontra o Agente), alm do identificador do
Objeto Gerenciado ou de um grupo de Objetos. Enviada a PDU (Figura 4.2),
o Gerente recebe como resultado uma lista de Objetos gerenciados pelo
Agente. Esta leitura feita percorrendo a rvore de identificao;
Operao Set: altera um valor de um atributo de um Objeto Gerenciado. Para
tanto a PDU (Figura 4.2) recebe como argumentos: o identificador do
elemento de rede a ser gerenciado sobre o qual a alterao ser feita, a
identificao do Objeto Gerenciado e o novo valor do atributo afetado;
Operao "trap": o Agente informa ao gerente sobre a ocorrncia de eventos
anormais que se produzem sobre o Objetos Gerenciados. Assim, se um
problema acontece em um n gerenciado, o Agente envia imediatamente um
comando trap ao Gerente sem esperar que este lhe solicite informaes. Por
exemplo, um Agente pode ser programado para enviar ao Gerente uma
mensagem de alarme sempre que houver a perda de uma conexo. A Figura
4.3 mostra a PDU para o comando Trap.
Figura 4.3: PDU para Trap
42
4.2. SNMP Verso 2

4.2.1.
Generalidades
O protocolo SNMP verso 2 o resultado de trabalhos isolados, na busca de corrigir

as deficincias funcionais do SNMPv1. Ele inclui principalmente as especificaes do
secure SNMP e SMP (Simple Management Protocol), as quais foram introduzidas em
1992.
As principais inovaes fornecidas pelo SNMPv2 localizam-se nos seguintes pontos:
4.2.2.
Estrutura da Informao de Gerenciamento (SMI);

Operaes do protocolo;
Comunicao gerente-a-gerente;
Segurana.
Estrutura da Informao Gerenciada (SMI)
A SMI do SNMPv2 expande a SMI do SNMPv1 para incluir novos tipos de dados e
melhorar a documentao associada a objetos, atravs de modificaes na macro
OBJECT-TYPE. A SMI agora dividida em quatro partes:
Definies de objetos
Tabelas conceituais
Definies de notificaes
Mdulos de informao
Definies de Objetos:
Como na SMI SNMP, definies de objetos na SMI SNMPv2 so usadas para
descrever objetos gerenciados. Para ambos, o tipo de um objeto pode ser simples
(simple) ou baseado em aplicao (application-based). Os tipos simples so bem
similares em ambas SMIs, porm uma diferena que valores enumerados so
permitidos no SNMPv2, sendo teis na definio de mscaras e flags. Para tipos
application, o SNMPv2 inclui tanto o endereo OSI NSAP (Network Service-Access
43
Point) como o IP; e inclui tambm um contador de 64 bits, alm do de 32 bits

existentes no SNMP SMI.
Tabelas Conceituais
Tanto no SNMP como no SNMPv2, cada tabela contm zero ou mais linhas, cada uma
contendo um ou mais objetos escalares. Essencialmente, existem duas categorias de
tabelas conceituais permitidas no SNMPv2:
Tabelas que probem criao e remoo de linhas pelo gerente;
Tabelas que permitem criao e remoo de linhas pelo gerente.
Cada linha da tabela deve possuir um INDEX ou AUGUMENTS, mas no ambos para
indexao. A clusula INDEX define uma linha conceitual base, determinando que
valores de objetos distinguem as linhas da tabela. A nica diferena no SNMPv2 em
relao ao uso do INDEX o uso opcional do modificador IMPLIED. A palavra chave
IMPLIED habilita uma pequena modificao no identificador da instncia quando um
dos objetosndice uma string de tamanho varivel. O IMPLIED somente deve ser
usado quando no existe risco de ambigidade. Os objetos associados com a clusula
AUGUMENTS devem referir-se a uma linha conceitual, e o objeto que inclui esta
clusula referido como sendo uma conceptual-row extension. Na essncia, o
AUGUMENTS projetado para aumentar o nmero de colunas na tabela sem
reescrever a sua definio. Os objetos escalares subordinados ao objeto extenso da
linha conceitual (conceptual-row extension) tornam-se objetos colunares opcionais na
linha conceitual base.
44
Definies de Notificaes:
A macro NOTIFICATION-TYPE usada para definir a informao enviada por uma
entidade SNMPv2 quando um evento excepcional ocorre na entidade. Tanto os traps
como os inform-request (definidos na prxima seo) so notificaes. A clusula
opcional OBJECT define a seqncia ordenada de objetos da MIB que esto contidos
juntamente com todas as instncias do tipo notification. Os valores desses objetos so
comunicados ao gerente quando uma notificao ocorre. A clusula DESCRIPTION
contm uma definio textual das semnticas de notificao. A clusula opcional
REFERENCE contm uma referncia cruzada textual para um evento ou para uma
notificao definida em outro mdulo da MIB. O valor de uma invocao da macro
NOTIFICATION-TYPE um identificador de objeto designado para a notificao.
Quando uma entidade SNMPv2 determina que uma notificao deve ser enviada, ele
consulta a aclTable e acha todas as entradas que satisfazem as seguintes condies:
Valor de aclSubject refere-se a esta entidade;

Valor de aclPrivileges permite um TRAP PDU;
Nome da notificao est presente na MIB correspondente;
As instncias dos objetos associados com esta notificao, como
definido na clusula OBJECTS, esto todos presentes na viso da MIB
correspondente.
Para cada entrada satisfazendo essas condies, uma notificao enviada do

aclSubject para o aclTarget.
4.2.3.
Operaes do Protocolo
As mudanas no nvel do protocolo so as incluses de duas novas PDUs (Protocol

Data Unit): a GetBulkRequest (Figura 4.4) e a InformRequest (Figura 4.5).
O objetivo da GetBulkRequest retornar um grande nmero de informaes
gerenciadas permitindo ao gerente SNMPv2 requisitar uma resposta seja to grande
quanto possvel, dada as restries de tamanho de mensagem. A operao
GetBulkRequest usa o mesmo princpio de seleo da operao GetNextRequest; isto
, a seleo sempre no prximo objeto da ordem lexicogrfica. A diferena que
com o GetBulkRequest possvel especificar o nmero de sucessores na ordem
lexicogrfica que devem ser selecionados. A PDU do GetBulkRequest possui dois
campos diferentes: nonpeaters e maxrepetitions. O campo nonpeaters especifica o
45
nmero de variveis na lista de variable-bindings para o qual um nico sucessor na

ordem lexicogrfica deve ser retornado. O campo maxrepetitions especifica o nmero
de sucessores na ordem lexicogrfica para as variveis restantes na lista. Esta operao
remove uma das maiores limitaes do SNMP, que a no habilidade de retornar um
grande volume de dados.
Tipo de PDU
request-ID
nonrepeaters
maxrepeatitions
variable-bindings
Figura 4.4: PDU para GetBulkRequest

No InformRequest, uma PDU enviada por uma entidade SNMPv2 agindo como
gerente para uma outra entidade agindo tambm como gerente, para fornecer
informaes gerenciadas para uma aplicao usando a ltima entidade. Esta PDU
enviada para o destino especificado na tabela eventNotifyTable, que definida na MIB
Gerente-Gerente (a seguir definida), ou para os destinos especificados pela aplicao.
Esta PDU inclui um campo variable-binding com os seguintes elementos:
A primeira varivel sysUptime.0 como definida na MIB-II;

A segunda varivel SNMPv2EventID.i, o qual definido na MIB
Gerente-Gerente e contm o object identifier do tipo do evento;
A PDU (Figura 4.5) pode opcionalmente incluir variveis adicionais
especificados por uma requisio.
Tipo de PDU
request-ID
variable-bindings
Figura 4.5: PDU para InformRequest
4.2.4.
MIB Gerente-Gerente (M2M)
A comunicao Gerente-Gerente suportada pela definio de uma nova base de

informaes, a M2M MIB. Essa MIB pode ser usada para permitir um processo
gerente intermedirio desempenhar o papel de monitor remoto de informao de
trfego e tambm emitir relatrios.
46
4.2.5.
Segurana
SNMPv2 incorpora as especificaes contidas no conjunto de documentos conhecido

como S-SNMP (Secure SNMP), as quais foram submetidas em Julho/1992 como
propostas de padro s especificaes j existentes no mundo Internet. Estas
especificaes fornecem um servio de autenticao e integridade, que permite ao
receptor saber com certeza se uma mensagem veio de onde ela diz que veio. Esta
tcnica utiliza o conceito de chave privada criptografada. Opes de criptografia esto
disponveis para cada mensagem SNMPv2. Os fabricantes ficam livres para
implementar as trs maiores partes de segurana: autenticao e integridade; controle
de acesso; e segurana e privacidade.
4.2.6.
MIB SNMPv2:
A MIB SNMPv2 define objetos que descrevem o comportamento de uma entidade

SNMPv2. Esta MIB consiste de cinco grupos:
Grupo Statistics SNMPv2;

Grupo Statistics SNMPv1;
Grupo Object Resource;
Grupo Trap;
Grupo Set.
4.3. RMON Remote Monitoring

4.4. Conceito
O RMON empregado para estudar o trfego em uma rede como um todo, superando
as limitaes da MIB-II onde um gerente SNMP pode obter apenas informaes
localizadas em um determinado equipamento. Tipicamente, estes monitores (tambm
chamados de probes) operam em uma rede no modo promscuo, visualizando todos os
pacotes que passam atravs dela. A Figura 4.6 mostra um exemplo de configurao
uma rede com RMON.
47
4.4.1. RMON MIB

A gerncia de redes remotas atravs de agentes remotos (por exemplo, agentes que
implementam a RMON MIB) possui cinco funes:
Operaes off-line: so as operaes nas quais uma estao de gerenciamento no

necessita estar em contato direto com seus dispositivos de monitorao remotos.
Essa funo na RMON MIB permite que os agentes sejam configurados para
realizar diagnsticos e coletar estatsticas continuamente, mesmo que a
comunicao entre a estao de gerenciamento no seja possvel ou no seja
eficiente;
Estao de
Gerenciamento
com RMON
Ethernet
Roteador
Ponte
Ethernet
Token Ring
Gerente Local
com RMON
PC com
Probe RMON
Figura 4.6: Exemplo de Configurao com RMON
48
Monitorao pr-ativa: os recursos disponveis nos monitores so potencialmente

teis para continuamente executar diagnsticos e manter logs do desempenho da
rede. Essas informaes so importantes para desenvolver a funo baseline. A
funo baseline refere-se ao fato de manter um histrico da operao normal de

uma rede por um tempo estendido, com o objetivo dessas informaes
posteriormente serem analisadas para identificar problemas potenciais numa rede;
Deteco e registro de problemas: o monitor remoto pode fazer o reconhecimento

de determinadas condies, realizando constantes averiguaes;
Valorizao dos dados coletados: o monitor pode executar anlises especficas nos
dados coletados em suas subredes;
Mltiplos gerentes: na configurao de uma rede pode haver mais de uma estao
de gerenciamento como forma de oferecer maior nvel de disponibilidade, para
executarem diferentes funes ou ainda para gerenciar diferentes departamentos
em uma empresa.
4.4.2. Grupos da RMON MIB

A RMON MIB est dividida em nove grupos:
Grupo Statistics: esse grupo contm estatsticas medidas pelo monitor para cada
interface monitorada no dispositivo.
Grupo History: esse grupo registra amostras estatsticas periodicamente e as

armazena para uma posterior recuperao.
Grupo Alarm: esse grupo periodicamente obtm amostras estatsticas de variveis

do monitor e as compara com os limiares previamente configurados;
Grupo Host: esse grupo contm estatsticas associadas a cada host descoberto na
rede. Os endereos fonte e destino desses hosts so mantidos numa lista e obtidos
dos pacotes bons que foram promiscuamente recebidos pela interface.
Grupo HostTopN: esse grupo usado para preparar relatrios que especificam os
principais hosts de uma lista ordenada por uma de suas estatsticas;
Grupo Matrix: esse grupo armazena a estatstica do trfego e nmero de erros

entre pares de hosts.
49
Grupo Filter: esse grupo permite que os pacotes sejam capturados com uma
expresso de filtro arbitrria;
Grupo Capture: esse grupo permite que os pacotes sejam capturados sobre a
correspondncia de um filtro e que o sistema de gerenciamento crie mltiplos
buffers de captura, controlando se o buffer de monitorao (trace buffer) continua
ou interrompe a captura de pacotes quando estiver cheio;
Grupo Event: esse grupo controla a gerao e notificao de eventos;
4.5.
SNMP & CMIP
4.5.1. Similaridades
Tanto SNMP quanto CMIP tm, naturalmente, o mesmo objetivo: permitir o envio de
comandos e receber resultados e notificaes de tal modo a coordenar (monitorar e
controlar) os recursos lgicos e fsicos de uma rede.
As principais similaridades entre os dois so:
Ambos protocolos usam o conceito de MIB e o modelo Gerente x Agente;
So protocolos de arquiteturas abertas (no proprietrias);
4.5.2. Diferenas
A diferena entre os sistemas de gerncia OSI e Internet, pode ser melhor ilustrada na
seguinte analogia. Consideremos duas fbricas: uma cujo proprietrio contratou uma
tcnico para sua administrao no perodo noturno e outra que contratou um vigia. A
primeira fbrica (OSI), que contratou um tcnico, fez naturalmente um maior
investimento. A segunda fbrica (Internet) decidiu por um processo aparentemente
mais simples e mais barato ao contratar o vigia. O proprietrio da fbrica OSI ao
desejar realizar alguma atividade nas mquinas da fbrica simplesmente emite ordens
de mais alto nvel, uma vez que o tcnico l existente tem conhecimentos suficientes
para realizar essas ordens. O mesmo j no acontece na fbrica Internet que dever
manter um dilogo mais intenso com o vigia, ou seja, enviar ao mesmo uma
seqncia mais numerosa de ordens. Se considerarmos agora em ambas as fbricas a
50
ocorrncia de um problema, provvel que na fbrica OSI o tcnico seja capaz de

resolver esse problema e, posteriormente, apenas notificar o proprietrio. J na fbrica
Internet, o vigia seria obrigado a acordar o proprietrio para que ele dissesse
detalhadamente os passos que o vigia deveria realizar para resolver o problema.
Percebe-se com esta analogia que um agente OSI mais inteligente que seu
equivalente Internet, necessitando pagar mais caro por isso (espao em disco e tempo
de processamento). Por outro lado, o trfego na rede bem menor comparativamente
a uma mesma atividade de gerncia Internet. Em se tratando de notificaes, a
analogia tambm feliz medida que um agente Internet incapaz de solucionar
problemas, limitando-se a simplesmente sinalizar ao gerente a ocorrncia dos
mesmos. Em resumo, pode-se dizer que os modelos OSI e Internet so,
respectivamente, gerente magro-agente pesado e gerente pesado-agente magro.
A diferena entre o SNMP e CMIP pode ser resumida nos seguintes tpicos:
Acesso a dados: SNMP orientado mais recuperao individual de itens de
uma informao, enquanto CMIP mais orientado recuperao de
informaes agregadas.
Polling x reporting: SNMP trabalha por polling (o gerente
regularmente pergunta ao agente sobre seu status), enquanto o CMIP usa
reporting (o Agente informa ao gerente quando o status do Objeto
Gerenciado mudou). Esta filosofia de gerenciamento do CMIP vantajosa
sobre o SNMP quando se tem um nmero considervel de Agentes a serem
consultados.
Tamanho e desempenho: SNMP menor e mais rpido. CMIP requer maior
capacidade de processamento e mais memria. Esta caracterstica associada
a filosofia: polling requer menos inteligncia dos dispositivos sendo
gerenciados.
Funcionalidade: CMIP tem mais caractersticas e capacidades especficas
Nvel de Transporte: SNMP requer somente datagramas no confiveis, o
que implica que ele pode ser implementado em vrias redes. Em comparao,
CMIP exige um nvel de transporte orientado a conexo: TCP, TP-4, etc.
51
Padronizao: CMIP, a exemplo dos demais protocolos OSI, um padro

internacional, sujeito portanto a testes de conformidade. SNMP, por sua vez,
somente pode dispor de testes de interoperabilidade.
A Figura 4.7 resume as diferenas entre o SNMP e o CMIP.
SNMP
CMIP/S
Ambiente Internet
Ambiente OSI
Simples
Complexo
Primitivas Limitadas
Primitivas
Expressivas
Agente Passivo
Agente Ativo
MIBs - Tabelas
MIBs - Classes
Figura 4.7: Quadro Comparativo SNMP x CMIP/S
4.6.
MIB OSI & MIB Internet
4.6.1. MIB OSI

A linguagem ASN.1 especifica como deve ser a representao dos dados e seus
respectivos nomes. Os nomes das variveis so determinados de acordo com o
conceito de objeto identificado. O rgo que os administra a "International
Standardization Organization (ISO)", garantindo que cada objeto tenha uma
identificao nica mundialmente.
A SMI, baseada na abordagem orientada a objetos, introduz os conceitos de hierarquia
de herana, de nomeao e de registros, utilizados na caracterizao e identificao de
Objetos Gerenciados OSI, alm de definir o conjunto de operaes que pode ser
52
realizado sobre os Objetos Gerenciados da MIB e o comportamento desses objetos

mediante a execuo dessas operaes.
Na hierarquia de herana, define-se o conceito de classes de objeto hierarquizadas
s quais pertencem objetos com propriedades semelhantes. Nesse contexto, existem
super-classes s quais esto subordinadas as subclasses. Uma subclasse herda todas as
propriedades da superclasse qual est subordinada, de maneira irrestrita,
independentemente da necessidade ou no destas propriedades. Alm disso,
propriedades extras podem ser adicionadas s subclasses.
O conceito de herana mltipla pode ser utilizado para permitir a maior reutilizao
de definies de classes, com uma subclasse derivando de mais de uma superclasse, e
tambm para permitir uma melhoria na capacidade de um sistema de gerenciamento
reconhecer caractersticas familiares entre classes de objetos.
A MIB divide as informaes de gerenciamento, com o objetivo de padronizar o seu
layout e agrupar as variveis de mesma natureza sob uma mesma denominao, em
classes. Cada uma dessas classes possui um conjunto de variveis (itens de dados)
associadas. Uma configurao hierrquica em rvore foi adotada para contemplar de
forma ampla as necessidades de identificao de objetos. Alm da ISO, o Consultative
Committee for International Telegraph and Telephone (ITU) e uma associao entre
ambas tambm tm outras padronizaes hierrquicas em rvore.
A ISO delega autoridade para outras entidades sobre a administrao de subrvores
especficas, devido ao fato de existirem ns muito abrangentes. Com isso, tem-se
subrvores designadas para pases e outras organizaes. Cada n identificado por
um texto curto (mnemnico) que corresponde a um nmero.
A determinao do nome de um objeto dada pela seqncia hierrquica dos ns
desde a raiz at o item elementar, seguindo um determinado caminho. A escrita tanto
na forma humana quanto numrica separa um identificador do outro atravs de um
ponto.
A padronizao das informaes gerenciais fez a MIB tornar-se independente dos
protocolos de gerenciamento. Isso resultou em vantagens para fabricantes,
fornecedores de softwares de gerenciamento e usurios. Entretanto, para que essa
padronizao permanecesse era necessrio que os grupos que desenvolveram os
53
protocolos de gerenciamento continuassem trabalhando em conjunto para determinar

os mesmo tipos de informaes a serem gerenciadas.
Em virtude dos grupos SNMP e CMOT no chegarem a um acordo sobre as extenses
a serem includas na MIB original, surgiram as extenses MIB-II (SNMP) e MIB-IIOIM (CMOT).
Apesar da existncia desses dois padres atualmente, a forma de criao de um item
de dado segue o padro "Structure of Management Information" (SMI), que consiste
num conjunto de regras a ser obedecido para definir e identificar variveis na MIB.
A grande diferena entre essas MIBs esto nas hierarquias utilizadas para representar
os objetos. No caso da MIB ISO, utiliza-se as trs hierarquias definidas anteriormente
(de herana, de nomeao e de registro). No caso da Internet, no so utilizados os
conceitos de classes de objetos e seus respectivos atributos.
4.6.2. MIB Internet

Na MIB Internet so definidos os tipos de objeto, contendo cinco campos: nome
textual com o respectivo identificador de objeto (OBJECT IDENTIFIER), uma
sintaxe ASN.1, a definio da semntica associada ao objeto, o tipo de acesso (readonly, read-write, write-only ou no acessvel) e o status (obrigatrio, opcional e
obsoleto).
No caso da Internet, no utilizada nenhuma hierarquia de nomeao para identificar
instncias de objetos. O conceito de instncia de objeto definido e desvinculado do
conceito de atributo. A hierarquia de registro utilizada tanto no caso da Internet
como no caso da ISO, segundo as regras definidas pela notao ASN.1, utilizada na
atribuio de identificadores de objetos. A figura 4.8 apresenta a subrvore de registro
onde se encontra a MIB Internet. Observa-se que as 8 classes descritas na tabela 4.1
so os 8 ns dependentes dessa MIB.
54
internet
1
directory
mgmt
experimental
private
mib-2
1
system
interfaces
at
ip
icmp
tcp
udp
egp
Figura 4.8: Sub-rvore da MIB Internet

Classe
system
interfaces
address translation
ip
icmp
tcp
udp
egp
Informaes fornecidas
Sistema operacional do host ou gateway
Cada interface da rede
Mapeamento ARP (traduo de endereos)
Internet Protocol
Internet Control Message Protocol
Transmission Control Protocol
User Datagram Protocol
Exterior Gateway Protocol
Tabela 4.1. Grupos de Variveis da MIB da Internet

Baseado na Figura 4.8 e como exemplo de sintaxe, tem-se que todas as variveis
pertencentes ao TCP tero a seguinte denominao:
55
###
###
humana: iso.org.dod.internet.mgmt.mib.tcp
numrica: 1.3.6.1.2.1.6
A MIB da Internet no inclui informaes de gerenciamento para aplicaes, tais

como: Acesso a Terminal Remoto (TELNET), Transferncia de Arquivo (FTP - File
Transfer Protocol) e Correio Eletrnico (Simple Mail Transfer Protocol). Alm disso,
no prev mecanismos para definir aes e eventos associados a um objeto gerenciado
e possui um conjunto bem menor de operaes.
56
Parte II
Gerncia ATM
57
Captulo 5
5. Redes ATM
5.1. Introduo
Servios multimdia (voz, dados, vdeo, imagem, etc.) tm sido cada vez mais
requisitados em redes de comunicao e apresentam-se como uma tendncia
tambm nas empresas operadoras de telefonia.
O grande problema encontrado no trfego multimdia deve-se ao fato que cada
tipo de servio adequadamente atendido por um determinado tipo de tecnologia.
Por exemplo, comutao de circuitos foi desenvolvida para o servio de
transmisso de voz (rede de telefonia). J o servio de transmisso de dados
melhor atendido pela comutao de pacotes (rede de pacotes).
O advento das chamadas RDSI (Redes Digitais de Servios Integrados) no
contexto das empresas operadoras de telefonia motivou o desenvolvimento de
uma tecnologia capaz de atender satisfatoriamente aos requisitos da transmisso
de no s dados e voz, mas tambm de outras mdias. Trata-se da tecnologia ATM
(Asynchronous Transfer Mode).
Embora ATM tenha sido projetada para suportar as RDSI-FL (RDSI de Faixa
Larga), ela logo despertou ateno como uma possvel soluo s redes de
computadores de alta velocidade, permitindo a estas disponibilizarem servios
multimdia, impraticveis com a tecnologia tradicional baseada em comutao de
pacotes.
ATM uma tecnologia de comunicao que utiliza um protocolo orientado a
conexo. Ela oferece uma capacidade de transmisso de dados a altas velocidades
e com delay mnimo e Qualidade de Servio (QoS) garantida. ATM
caracterizado por pacotes de tamanho fixo de 53 bytes, denominados clulas.
59
Trata-se de uma tecnologia de transmisso assncrona devido ocorrncia de

clulas contendo informaes no ser transmitida de forma peridica.
Recursos ATM, tais como, largura de banda e buffers so compartilhados entre
os usurios, e so alocados somente quando eles tem algo a transmitir. Logo, a
rede usa multiplexao estatstica para aumentar o throughput efetivo.
5.2. Modelo da Arquitetura dos Protocolos RDSI-FL

As recentes modificaes na estrutura da rede telefnica em todo o mundo,
primeiro com a crescente utilizao de computadores e segundo com a introduo
de fibras de alta capacidade, aumentam a possibilidade de ATM desempenhar um
papel importante na rea de tecnologia de transmisso num futuro prximo.
Vrios rgos tem definido padres para redes ATM: ITU-T, ATM Forum e
ANSI, facilitando a interoperabilidade entre os produtos dos fornecedores. Como
citado anteriormente, a tecnologia ATM foi escolhida pelo ITU-T como modo de
transferncia para RDSI-FL.
O modelo de arquitetura RDSI-FL consiste de trs plano e quatro camadas (Figura
5.1). Este modelo difere do modelo de referncia OSI, em vrios aspectos,
destacando-se o fato dele fazer uso de trs e no duas dimenses.
A funo de cada plano a seguinte:
Plano do Usurio: Transferncia de informaes do usurio.
Plano de Controle: Funes de controle de chamada e de estabelecimento de
conexo, tal como a sinalizao.
Plano de Gerenciamento: Este plano oferece dois tipos de funes:
gerenciamento dos planos e gerenciamento das camadas. O gerenciamento dos
planos trata das funes associadas ao sistema como um todo, proporcionando
coordenao entre os planos. Gerenciamento de camada trata dos recursos e
parmetros residindo em cada protocolo das camadas, como por exemplo, fluxo
OAM (Operation, Administration and Maintenance).
60
A funo caracterstica de cada camada a seguinte:
Camada Fsica: Transmisso de bits;

Camada ATM: Comutao de clulas;
Camada de Adaptao: Interfaceamento com usurios;
Camada Superior: Usurios da Pilha ATM.
As camadas incluem: camada fsica, ATM e camada de adaptao ATM (AAL),

descritas nas prximas sees.
Funes do Plano de Gerenciamento
Camada de
Adaptao ATM
Camada ATM
Gerncia de Plano
Camada de
Adaptao ATM
Gerncia de Camada
Plano de Usurio
Plano de Controle
Funes e Protocolos Funes e Protocolos
das Camadas
das Camadas
Superiores
Superiores
Camada Fsica
Figura 5.1: Modelo da Arquitetura dos Protocolos RDSI-FL
5.3. Interfaces ATM

A Figura 5.2 mostra um ambiente genrico que faz uso da tecnologia ATM, onde
so encontrados comutadores ATM pblicos e privados, bem como as diversas
interfaces: a UNI (User-Network Interface), NNI (Network-Node Interface), PNNI
(Private Network-Node Interface) e B-ICI (Broadband Inter-Carrier Interface).
Padronizada pelo ATM Forum a UNI [28], conecta uma rede ATM a um
equipamento, o qual pode ser um comutador ou host. Existem dois tipos de UNI:
pblica e privada. A UNI pblica conecta um dispositivo ATM privado a uma
rede ATM pblica. A UNI privada conecta usurios ATM a um comutador ATM.
61
A interface NNI descreve a interconexo de dispositivos de rede dentro de uma

rede de um nico provedor (carrier). A PNNI especifica um protocolo atravs do
qual comutadores ATM, que so partes de uma rede ATM privada, podem se
comunicar. A especificao da PNNI define duas configuraes possveis: private
network-node interface, operando entre dois comutadores; ou a private networknetwork interface, operando entre dois grupos de comutadores, ou redes ATM.
Quando uma NNI interconecta redes pblicas ATM, esta chamada B-ICI.
SMDS
Comutador ATM
UNI
Pblica
PNNI
IWF
Rede ATM
Pblica
UNI
Privada
Comutador ATM
UNI
Pblica
Rede ATM
Pblica
B-ICI
IWF
NNI
Notas :
UNI : User-Network Interface
B-ICI : Broadband Inter-Carrier Interface
IWF : Internetworking Function
NNI : Network-Node Interface
PNNI : Private Network-Node Interface
Frame-Relay
Comutador ATM
PBLICO
Figura 5.2: Estrutura das Interfaces de um Ambiente ATM

Caso uma rede ATM se conecte com outra rede pblica ou privada, tal como
Frame-Relay ou SMDS, necessrio uma converso entre elas. Processos IWF,
definidos pela especificao da interface B-ICI, realizam esta converso.
5.4. Conexes ATM

Como j comentado, a camada ATM utiliza-se de um servio orientado
conexo, onde a transferncia de informaes baseada em circuitos virtuais.
Independente de ser enviada atravs de uma UNI ou NNI, uma clula ATM possui
o identificador do seu canal (circuito) virtual. Este identificador possui duas
62
partes. Ambas podem ser usadas na camada ATM: VPI (Identificador de Caminho
Virtual) e VCI (Identificador de Canal Virtual).
Um caminho virtual (VP) formado por um conjunto de enlaces de caminhos
virtuais (VPL), todos tendo o mesmo ponto de trmino. O VPI ou associado ou
removido para originar ou terminar um enlace de caminho virtual (VPL). Estes
enlaces so concatenados formando uma conexo de caminho virtual (VPC). Cada
enlace de canal virtual (VCL) dentro de um VPC mantm a seqncia de
transmisso das clulas, mas no assegura a sua integridade.
Um VCI ou associado ou removido, respectivamente, para originar ou terminar
um enlace de canal virtual (VCL). Enlaces de canais virtuais so concatenados
para formar uma conexo de canal virtual (VCC), ou seja, um caminho fim-a-fim
para clulas na camada ATM.
A operao bsica de um comutador ATM simples: receber uma clula atravs
de um enlace com um valor de VPI/VCI conhecido; verificar o valor da conexo
numa tabela local para determinar a porta de sada da conexo e o seu novo valor
do VPI/VCI neste enlace; e ento retransmitir a clula no enlace de sada com os
identificadores de conexo apropriados.
5.5. Organizao dos Protocolos

A Tabela 5.1 mostra uma viso ampla da pilha de protocolos ATM, juntamente
com as funes de cada camada ou sub-camada.
A seguir, so descritas em detalhes estas funes.
5.5.1.
Camada Fsica
A camada fsica possui duas sub-camadas: Physical Medium (PM) e Transmission

Convergence (TC).
A sub-camada PM prov transmisso a nvel de bit. Entre suas funes incluem-se
funes dependentes do meio de transmisso, seja ele uma interface tica ou
eltrica, tais como, cabo a ser utilizado, recuperao de bits, temporizao, etc.
63
Camada de Adaptao
ATM (AAL)
CS
Convergncia
SAR
Segmentao e Remontagem
Controle de Fluxo Genrico
Gerao/extrao de cabealho de clula
Traduo de VPI/VCI
Multiplexao/demultiplexao de clulas
Camada ATM
TC
Gerao/recuperao de transmisso
Delineao de clulas
Gerao/verificao de sequencia do HEC
Adaptao de transmisso de "frame"
Adaptao de taxas de tranmisso
PM
Temporizao de Bit
Meio fsico
Camada Fsica
Tabela 5.1: Estrutura e Funes das Camadas

A sub-camada TC, desempenha cinco funes: gerao/recuperao de frames de
transmisso (se existentes), empacotamento de clulas ATM em frames (se for
utilizado), delimitao das clulas, gerao/recuperao do HEC (Header Error
Check) das clulas ATM, insero e retirada de clulas ATM de preenchimento.
A Gerao de frames cria e recupera os frames de dados enviados pela subcamada PM. Clulas transmitidas pela camada ATM devem ser adaptadas para o
formato utilizado pela sub-camada PM. Na direo receptora, a funo de
empacotamento extrai as clulas dos frames. A funo de delineao de clula
identifica os limites das clulas, para a camada ATM poder decodific-las. A
seqncia do HEC calculada e adicionada no cabealho ATM para frames
transmitidos. Para frames recebidos os cabealhos das clulas so checados para
erros. Se erros so encontrados, eles so recuperados quando possvel, ou no outro
caso as clulas so descartadas. Finalmente, a retirada ou insero de clulas de
preenchimento adaptam as taxas de transmisso das clulas ATM vlidas para a
capacidade do sistema de transmisso.
A camada fsica especifica as duas formas de transmisso da arquitetura RDSIFL:
64
As clulas podem ser empacotadas em envelopes (frames) a serem

transportados pela tcnica TDM; neste caso, a estrutura desses frames
denominada SDH (Synchronous Digital Hierarchy), definida pelo ITU-T no
documento G-709; nos EUA essa estrutura conhecida como SONET
(Synchronous Optical Network).
As clulas podem ser transmitidas atravs do meio fsico sem nenhum
envelope adicional, sendo a sincronizao feita atravs do campo HEC das
mesmas.
O ATM Forum define vrias tecnologias de transmisso para UNIs. Abaixo as
Tabelas 5.2 e 5.3 citam as mais comuns utilizadas em redes pblicas:
SONET / SDH (Synchronous Digital Hierarchy) Rates
Velocidade (Mbps)
SONET
SDH
51.840
STS-1
155.520
STS-3
STM-1
466.560
STS-9
STM-3
622.080
STS-12
STM-4
933.120
STS-18
STM-6
1244.160
STS-24
STM-8
2488.370
STS-48
STM-16
Tabela 5.2: Synchronous Digital Hierarchy (SDH)
5.5.2.
Camada ATM
A camada ATM fornece um servio do tipo orientado conexo para as camadas

superiores, isto , a transferncia de informaes entre as aplicaes em uma rede
ATM baseada em circuitos virtuais. Esses circuitos virtuais podem ser tanto
circuitos comutados (SVC - Switched Virtual Circuit), alocados conforme
demanda; ou circuitos permanentes (PVC - Permanent Virtual Circuit), em geral
alocados por uma entidade administrativa de forma esttica.
Os pacotes em que so agrupadas as informaes para transmisso na tecnologia
ATM so conhecidos como clulas ATM e possuem 53 bytes (Figura 5.3).
65
O significado dos campos das clulas o seguinte:

GFC (Generic Flow Control) (4 bits): Usado apenas nas clulas ATM da UNI
tem como funo auxiliar o controle de fluxo atravs desta interface.
VPI (Virtual Path Identifier) (8/12 bits, UNI/NNI): Identifica um caminho
virtual em um meio fsico de transmisso, para a comutao de clulas ATM.
VCI (Virtual Channel Identifier) (16 bits): Identifica um canal virtual em um
meio fsico de transmisso, para a comutao de clulas ATM.
PTI (Payload Type Identifier) (3 bits): Indica o tipo de informao do campo
Information Field da clula ATM (dados de usurio ou de controle, por
exemplo).
CLP (Cell Loss Priority) (1 bit): Associa uma prioridade clula, no caso de
necessidade de descarte de clulas ATM em situaes de congestionamento;
clulas com CLP = 1 podem ser descartadas nessas situaes.
HEC (Header Error Check) (8 bits): Valor calculado para validar o cabealho
da clula, a partir dos 32 bits restantes desse cabealho; o nico campo no
gerado na camada ATM, e sim na sub-camada TC da camada fsica.
Information Field (48 bytes): Tambm conhecido como information payload,
constitui os dados das camadas superiores a serem transportados via clulas ATM.
8
GFC/VPI
VPI
1 Oct
VPI
VCI
2
3
VCI
VCI
PTI
HEC
Informaes
(Payload)
48 Octetos
CLP
4
5
6
...
53 Oct
Figura 5.3: Estrutura Geral de uma Clula ATM
66
Esta camada funciona independentemente da camada fsica e realiza trs funes

principais: multiplexao/demultiplexao de clulas ATM, traduo de VPI/VCI
e gerao/extrao de cabealho. Estas funes so detalhadas abaixo.
Multiplexao/demultiplexao de clulas ATM de conexes lgicas distintas
de uma mesma interface fsica. Na direo de transmisso a camada ATM
multiplexa clulas de caminhos virtuais (VPs) e canais virtuais (VCs) individuais
em um fluxo de clulas composto. Na direo do receptor, a demultiplexao
direciona clulas do fluxo de clulas composto para o VP ou VC apropriado.
Traduo VPI/VCI, ou seja comutao de clulas de acordo com os
identificadores da conexo (VPI/VCI). Os campos VCI e VPI nas clulas de
entrada podem requerer mapeamento para novos valores.
Gerao/extrao dos cabealhos das clulas. A camada ATM gera o cabealho
ATM e o adiciona ao payload para transmisso ou extrai o payload de uma
clula recebida e o repassa para as camadas mais altas.
5.5.3.
Camada de Adaptao ATM (AAL)
A camada AAL tem como funo principal permitir o uso da tecnologia ATM por
outros protocolos de mais alto nvel, ou seja, por vrios tipos de aplicaes.
Esta camada fornece alguns tipos de servios com caractersticas orientadas a cada
tipo de aplicao, os quais so agrupados em classes. Alm disso, existem nessa
camada alguns protocolos conhecidos como AAL Types. Segue, abaixo, relao
entre as classes de servios e os protocolos mais adequados para a classe.
Caractersticas
Tempo Real
Taxa de
Transferncia
Tipo de Servio
Classe A
Sim
Constante
Classe B
Sim
Varivel
Orientado
conexo
AAL 1
Vdeo e Voz.
Classe C
No
Varivel
Orientado
Orientado
conexo
conexo
Protocolo AAL
AAL 2
AAL 3/4 e 5
Aplicaes
Voz e Vdeo
Frame-Relay e
comprimidas
X.25
Tabela 5.4: Classes de Servios na Camada AAL
Classe D
No
Varivel
No orientado
conexo
AAL 3/4
SMDS e
trfego LAN
67
A camada AAL possui duas sub-camadas: Segmentation e Reassembly Sublayer

(SAR) e a Convergence Sublayer (CS).
A sub-camada SAR segmenta/reagrupa as informaes da camada superior em
clulas ATM. Ela segmenta as informaes de tamanho variveis para serem
transmitidos nos payload de tamanho fixo ATM, e reagrupa os payloads recebidos
em informaes de camadas superiores.
Plesiochronous Digital Hierarchy (PDH) Rates
Velocidade (Mbps)
Amrica do Norte
Europa
0.064
DS0
1.544
DS1
2.048
E1
3.152
DS1C
6.312
DS2
8.448
E2
34.368
E3
44.736
DS3
139.264
E4
274.176
DS4
Tabela 5.3: Plesiochronous Digital Hierarchy (PDH)
A sub-camada CS realiza funes requisitadas pelo tipo de AAL sendo utilizada, e
portanto dependente do servio. Em alguns casos as suas funes podem ser
subdivididas em Common Part Convergence Sublayer (CPCS), e Service Specific
Convergence Sublayer (SSCS).
5.4. Endereamento, Sinalizao e Roteamento

O fato de ATM ser orientado a conexo implica na necessidade de protocolos de
sinalizao e estruturas de endereamento, tanto quanto protocolos para rotear
requisies de conexo atravs de uma rede ATM.
68
Todo equipamento ATM precisa de um endereo ATM em adio a qualquer

endereamento de camadas superiores. O espao de endereamento ATM deve ser
logicamente disjunto do espao de endereamento de qualquer protocolo que
execute sobre a camada ATM. Portanto, todos os protocolos operando sobre uma
sub-rede ATM devero possuir alguma forma de protocolo de resoluo de
endereo ATM, para mapear endereos de camadas mais altas (ex. IP) para o seu
endereo ATM correspondente.
Sinalizao em ATM utiliza o mtodo one-pass de estabelecimento de conexo,
que se comporta da seguinte maneira: uma requisio de conexo a partir do
equipamento fonte propagado atravs da rede, estabelecendo a conexo por onde
passa, at chegar ao equipamento final. O roteamento da requisio de conexo, e
portanto qualquer fluxo de dados subsequente governado pelos protocolos de
roteamento. Tais protocolos roteiam a requisio de conexo baseado no endereo
destino, e nos parmetros de QoS e trfego requisitados pelo equipamento fonte.
O protocolo de sinalizao ATM opera em cima do SSCOP (Service Specific
Convergence Protocol), o qual garante a entrega, atravs da utilizao de janelas e
retransmisses.
Como comentado anteriormente, endereamento de fundamental importncia
numa rede ATM. O ITU-T props uma estrutura de endereamento hierrquico
para redes pblicas ATM baseado no padro E.164, usado na numerao
internacional de sistemas telefnicos. O ATM Forum estendeu o endereamento
ATM para incluir redes privadas, e avaliou dois modelos diferentes de
endereamento. O primeiro o formato E.164 e o outro um endereo de 20
bytes modelado a partir do formato de endereos de um OSI NSAP (Network
Service Access Point).
5.5. Categoria de Servio e Contrato de Trfego

Os mecanismos de controle do trfego numa rede ATM se baseiam na qualidade
de servio definida para cada aplicao. Estas categorias de servio dizem respeito
a caractersticas de trfego e requisitos de qualidade de servio (QoS) para o
comportamento da rede. Funes como roteamento, CAC (Controle de Admisso
de Conexo), alocao de recursos so, em geral, estruturados diferentemente para
cada categoria de servio. Categorias de servio so distinguidas como sendo de
tempo-real ou no. Para trfego em tempo-real , existem duas categorias, CBR
69
(Constant Bit Rate) e rt-VBR (Real-Time Variable Bit Rate). Para trfego que no
leva em conta o tempo, ou seja, no possui trfego em tempo-real, temos trs
categorias ABR (Available Bit Rate), UBR (Unspecified Bit Rate) e nrt-VBR
(Non-Real Time Variable Bit Rate).
Cada categoria de servio possui um conjunto de parmetros que identificam o
trfego a ser entregue pelo usurio rede e a qualidade de servio (QoS)
requisitada rede. Abaixo descrito em mais detalhes cada categoria.
Real-Time Variable Bit Rate (rt-VBR): Utilizado por aplicaes de tempo-real

que exigem atrasos e variaes de atraso bem limitadas (voz, vdeo), este servio
baseado nos seguintes parmetros de trfego: PCR, SCR e MBS e maxCTD.
esperado da fonte uma taxa de transmisso varivel no tempo. Clulas que so
atrasadas alm do valor especificado para mximo atraso de transferncia de
clulas (maxCTD) so assumidas como sendo de valor significativamente
reduzido para a aplicao. O servio VBR pode suportar multiplexao estatstica
de fontes de tempo-real.
Atributos
CBR
Parmetros de Trfego
PCR e CDVT (4,5)
SCR, MBS e CDVT (4,5)
MCR
Parmetros de QoS
CDV ponto-a-ponto
MaxCTD
CLR
Outros Atributos
Feedback
70
Categorias de Servio da Camada ATM

rt-VBR nrt-VBR
UBR
ABR
Especificado
n/a
Especificado
n/a
Especificado (2) Especificado (3)

n/a
Especificado
Especificado
Especificado
Especificado
No Especificado
No Especificado
No Especifica
No Especificado
(1)
Especificado
Categorias de Servio
CBR
Constant Bit Rate
rt-VBR
Real-Time Variable Bit Rate
nrt-VBR No-Real-Time Variable Bit
Rate
UBR
Unspecified Bit Rate
ABR
Available Bit Rate
Parmetros de Trfego
MCR
Minimum Cell Rate
MBS
Maximum Burst Size
CDVT
Cell Delay Variation
Tolerance
PCR
Peak Cell Rate
SCR
Sustainable Cell Rate
Parmetros de QoS
Cell Delay Variation
CDV
Cell Loss Ratio
CLR
Cell Transfer Delay
CTD
Notas:
(1) CLR baixo para fontes que ajustam o fluxo de clulas em resposta
informaes de controle. O valor quantitativo para CLR especificado
dependendo da rede.
(2) Pode no estar sujeito aos procedimentos de CAC (Controle de Admisso de
Conexo) e UPC (Usage Parameter Control).
(3) Representa a taxa mxima a qual um fonte ABR pode enviar informaes. A
taxa real est sujeita informaes de controle.
(4) Estes parmetros so especificados implcita ou explicitamente para PVCs ou
SVCs.
(5) CDVT refere-se tolerncia de variao de delay da clula. CDVT no
sinalizado. Em geral, CDVT no precisa possuir um valor nico para uma
conexo. Valores diferentes podem aplicar-se em cada interface ao longo do
caminho de uma conexo.
Tabela 5.5: Categorias de Servio da Camada ATM
Constant Bit Rate (CBR): Este servio usado por aplicaes que exigem uma
taxa de transmisso constante durante todo o tempo de existncia da conexo. Ele
caracterizado pelo parmetro PCR. Utiliza tambm o parmetro mximo CTD
(maxCTD). O compromisso bsico assumido pela rede com o usurio que reserva
recursos atravs da capacidade CBR que uma vez estabelecida a conexo, a QoS
da camada ATM assegurada para todas as clulas que esto de acordo com os
71
testes de conformidade relevantes. A fonte pode emitir clulas na PCR a qualquer

instante e por qualquer durao de tempo e os compromissos de QoS ainda so
mantidos. voltada para aplicaes de tempo-real que requerem variaes de
atraso de transferncia (peak-to-peak CDV) bastante limitadas (voz, vdeo) mas
no restrita a estas aplicaes. A fonte pode emitir clulas na PCR, ou abaixo (e
pode at mesmo permanecer em silncio), por perodos de tempo. Clulas que so
atrasadas alm do valor especificado para mximo atraso de transferncia de
clulas (maxCTD) so assumidas como sendo de valor significativamente
reduzido para a aplicao.
Non-Real-Time VBR (nrt-VBR): Usado por aplicaes que no sejam de temporeal e que tm trfego em rajadas, ou explosivo, este servio caracterizado pelos
seguintes parmetros: PCR, SCR e MBS. Para aquelas clulas que so transferidas
dentro do contrato de trfego, a aplicao espera uma baixa taxa de perda de bits
(CLR). Pode suportar multiplexao estatstica de conexes. No h limite de
atraso relacionado com essa categoria de servio.
Unspecified Bit Rate (UBR): Este servio utilizado por aplicaes que no so
de tempo-real e que no exijam restries de atraso e variao de atraso, como
transferncia de arquivos e correio eletrnico. No especifica garantias de servio
relacionadas ao trfego. No h nenhum compromisso numrico com relao ao
CTD ou ao CLR. Uma rede pode ou no aplicar o PCR s funes do CAC e do
UPC. No caso das redes em que PCR no exigido, o valor de PCR apenas
informativo. Quando PCR no exigido, ainda assim til t-lo negociado,
porque isto pode permitir a fonte descobrir a limitao da menor largura de banda
ao longo da via de conexo. O controle de congestionamento para UBR pode ser
executado numa camada mais alta ou numa base fim-a-fim. especificado pelo
uso do Indicador de Melhor Esforo (BEI - Best Effort Indicator) no ATM User
Cell Rate Information Element (UCRIE)
Available Bit Rate (ABR): Neste tipo de servio, as caractersticas das conexes
ATM podem ser alteradas a qualquer momento aps o seu estabelecimento. Um
mecanismo de controle de fluxo especificado e suporta vrios tipos de
realimentao para controlar a taxa da fonte em resposta s mudanas nas
caractersticas de transferncia da camada ATM. Esta realimentao levada at a
fonte atravs de clulas de controle especficas chamadas Resource Management
Cells, ou RM-cells. No estabelecimento de uma conexo ABR, o usurio deve
especificar para a rede tanto uma taxa de transmisso mxima (PCR) quanto uma
72
taxa mnima (MCR) de clulas, podendo este ltimo ser especificado como zero.
No voltada para aplicaes de tempo-real, desta forma no especifica limites
para o atraso (maxCTD) e para a variao do atraso (CDV). esperado que um
usurio que adapta seu trfego de acordo com a realimentao obtenha baixo CLR
e consiga uma diviso justa da largura de banda disponvel de acordo com a
poltica de alocao especfica da rede.
73
Captulo 6
6. Gerncia ATM
6.1. Introduo
POR QUE GERNCIA ATM NO , SIMPLESMENTE, A APLICAO DOS
CONCEITOS DE GERNCIA DE REDES APRESENTADOS NA PARTE I, AOS
RECURSOS A SEREM GERENCIADOS NUMA REDE ATM?
Ao iniciar esta segunda parte, natural o leitor se fazer a pergunta acima. Afinal,
uma aplicao de gerncia de rede ATM uma aplicao distribuda semelhante a
de uma rede de pacotes, baseada no modelo Gerente x Agente. Vamos, ento, ver
neste captulo, as razes que tornam a gerncia de redes ATM to especial.
Redes de computadores baseadas em comutao de pacotes, em particular a
Internet, foram concebidas sem a preocupao de dotar o design de sua
arquitetura de Mecanismos Intrnsecos Atividade de Gerncia (MIAG).
Conforme ilustrado no captulo anterior, a tecnologia ATM caracterizada pela
integrao, desde seu surgimento, de tcnicas e infra-estrutura destinadas ao
monitoramento e controle de seus componentes. A esta tcnica denominaremos
MIAG-ATM. Quanto a infra-estrutura, trata-se do Plano de Gerncia do Modelo
de Arquitetura nos Protocolos RDSI-FL (Figura 5.1).
Provavelmente, esta caracterstica adicional na arquitetura ATM que privilegia a
questo da gerncia, deve-se a uma maior complexidade desta tecnologia,
necessria ao tratamento eficientemente de vrios tipos de mdia, tendo resultado
no que chamamos neste captulo de MIAG-ATM.
75
Para melhor equacionarmos a problemtica da gerncia ATM, vamos considerar

que todos os Elementos de Interesse Gerncia (EIG) de redes ATM possam ser
agrupados em uma das seguintes opes:
1. EIGs semelhantes a Objetos Gerenciados SNMP
2. EIG resultado da interao de dois blocos funcionais em uma rede
ATM (ex.: Comutador-comutador, comutador-estao),
3. EIG intrnseco arquitetura de protocolos RDSI-FL, portanto sem
similaridades com Objetos Gerenciados SNMP.
A opo 1 pode ser tratada, com limitaes, da mesma forma que o modelo de
gerncia apresentado na parte 1. Afinal, devem existir EIGs numa rede ATM que
podem ser modeladas como Objetos Gerenciados em uma MIB e acessados pelo
mecanismo Gerente x Agente. Esta opo ser vista no captulo 8 denominado
MIBs SNMP aplicadas a ATM.
A opo 2 refere-se a EIGs associadas as diversas interfaces existentes, em
particular a interface UNI. Ela faz tambm uso do modelo Gerente x Agente
explicitado na parte 1, com um detalhe adicional importante. A MIB do modelo
necessita de um MIAG-ATM. Esta opo ser ilustrada no captulo 9 denominado
ILMI (Integrated Local Management Interface).
SET / GET
GERENTE
Notifications
Results
AGENTE
MIB
RECURSO
Figura 6.1: Gerente X Agente X MIB
76
SNMP/UDP/IP
Agente SNMP
Agente SNMP
PRIVATE
UNI
PUBLIC
UNI
MIB
IME
Computador
MIB
ILMI
SNMP/AAL
IME
MIB
IME
ILMI
SNMP/AAL
Comutador ATM
Privado
IME
IME
Comutador ATM
Pblico
Figura 6.2: Ambiente ILMI (Integrated Local Management Interface)
A opo 3 um MIAG-ATM tpico. Trata-se de um conjunto de funes de

Operao, Administrao e Manuteno recomendadas pelo ITU-T. Esta opo
abordada no captulo 10 denominado Funes ATM.
6.2. Modelo de Referncia de Protocolos RDSI-FL

A arquitetura de protocolos RDSI-FL especifica, dentro do seu contexto, dois
planos de gerncia ATM, um a nvel de gerncia de camada e outro de gerncia de
plano. As funes desempenhadas pelo Plano de Gerncia de Planos esto
relacionadas ao nvel lgico, enquanto o Plano de Gerncia de Camada atua a
nvel de servio e ainda realiza outras funes especficas.
77
Conexo de Canal Virtual

F5
Camada
ATM
Conexo de Caminho Cirtual

F4
Caminho de Transmisso
F3
Seo Digital
Camada
Fsica
F2
Seo de
Regenerador
F1
Figura 6.3: Nveis Hierrquicos OAM
6.2.1. Plano de Gerncia de Camada

As funes de Gerncia de Camada usualmente trabalham em conjunto com os
protocolos de uma determinada camada. Na proposta da ISO e ITU-T, em todas as
camadas da arquitetura da rede devem ser coletadas informaes de gerncia
especficas de cada protocolo e aquelas relacionadas camada como um todo. As
funcionalidades de gerncia de camadas incluem capacidades, tais como:
loopback, monitoramento de desempenho e superviso de alarmes.
78
6.2.1.
Plano de Gerncia de Planos
As funes de Gerncia de Planos supervisionam totalmente as funes de

comunicao desempenhadas e coordenam o comportamento dos subsistemas
individuais. O software de gerncia de sistema interage com o software de
gerncia de camada para coletar valores de atributos e para controlar e operar os
aspectos de comunicao em questo.
Funes do Plano de Gerenciamento
Camada de
Adaptao ATM
Camada ATM
Gerncia de Camada
Camada de
Adaptao ATM
Gerncia de Plano
Plano de Usurio
Plano de Controle
Funes e Protocolos Funes e Protocolos
das Camadas
das Camadas
Superiores
Superiores
Camada Fsica
Figura 6.4: Modelo da Arquitetura dos Protocolos RDSI-FL
6.3. Modelo de Referncia de Gerenciamento de Redes ATM

Nesta seo apresentado o modelo de gerenciamento de redes ATM sugerido
pelo ATM Forum (tambm conhecido como Modelo das 5 Interfaces). Este
modelo descreve os vrios tipos de gerenciamento de redes necessrios para
suportar redes privadas, redes pblicas e redes hbridas. Especifica tambm
gateways entre sistemas baseados nos protocolos SNMP e CMIP, e sistemas
com protocolo proprietrio. Esse modelo tem sido utilizado para situar as diversas
solues e especificaes apresentadas para ATM.
Para isto foram criadas cinco interfaces, nomeadas M1, M2, M3, M4 e M5 (Figura
6.5). Estas interfaces so essenciais para o monitoramento e controle fim-a-fim de
uma rede ATM. Abaixo so descritas as funes de cada interface.
79
M1 necessria para realizar a gerncia de um dispositivo ATM.

M2 utilizada para se realizar o gerenciamento de uma rede ATM privada.
M3 permite que o usurio supervisione sua poro de uma rede pblica ATM.
M4 necessria para se gerenciar uma rede pblica ATM. Ela inclui as funes
de gerenciamento de elementos de rede e funes de gerenciamento de
servios.
M5 utilizada para se gerenciar a interao entre dois sistemas de gerncia de
redes pblicas ATM.
Tipicamente, o protocolo SNMP tm sido utilizado nas interfaces M1, M2 e M3.
Enquanto o CMIP se apresenta nas solues das interfaces M4 e M5, ambientes
pblicos.
Sistema Gerncia de Rede
Empresa/Corporao
Sistemas Gerncia de
Rede
Concessionria
M3
Comutador
ATM
M1
M2
Rede ATM
privada
M5
M4
Rede ATM
pblica
Rede ATM
pblica
Figura 6.5: Modelo de Referncia de Gerenciamento de Redes ATM
Essa classificao tem sido utilizada em algumas especificaes do ATM Forum

para o gerenciamento de redes, como mostra a Tabela 6.1.
80
Algumas Especificaes do ATM Forum para Gerncia de Redes

Customer Network Management (CNM) for ATM Public Network Service
M4 Interface Requirements and Logical MIB
CMIP Specification for the M4 Interface
M4 Public Network view
M4 "NE View"
M4 Network View CMIP MIB Spec v1.0
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 (*)
(*) Ainda no aprovadas.
Tabela 6.1: Especificaes do ATM Forum para Gerncia de Redes
Como visto na tabela, o ATM Forum tm se concentrado na M4 e M5. J as

interfaces M1 e M2 tm sido atendidas pela criao de MIBs, como as
apresentadas no captulo 8 e Anexo A. A interface M3 tm como maior soluo a
estrutura CNM (Customer Network Management), apresentada a seguir.
6.4. CNM
A viso da gerncia de redes segundo a abordagem CNM mostrada na Figura
6.6. Provedores de servio (concessionrias) gerenciam a sua infra-estrutura para
prover servios ATM aos usurios, atravs dos Sistemas de Operao (OS). Numa
rede ATM privada, os usurios, atravs de um Sistema de Gerncia de Redes
(NMS Network Management System), precisam suportar muitas, (mas no
necessariamente todas) as funes de gerncia que um provedor disponibiliza.
Outros usurios simplesmente obtm servios ATM de um provedor. Neste caso,
eles precisam somente de um mecanismo para gerenciar certos aspectos de seu
servio. O servio CNM suportado pelos provedores facilita o planejamento,
81
operao, manuteno, administrao, reconfigurao da poro da rede do cliente

alugada ao provedor.
NMS
CNMA
CNMa
OS/NMS
Rede ATM Pblica
Comutador ATM
Privado
OS : Operations System
NMS : Network Management System
CNMA : Customer Network Management Application
CNMa : Customer Network Management Agent
Figura 6.6: Ambiente CNM (Customer Network Management)
82
Captulo 7
7. As reas Funcionais do Gerenciamento
A ISO definiu 5 reas funcionais para o gerenciamento de redes, as quais

descrevem a atuao de sistemas de gerenciamento. Estas reas so:
Gerenciamento de Configurao
Gerenciamento de Falhas
Gerenciamento de Segurana
Gerenciamento de Desempenho
Gerenciamento de Contabilizao
A Tabela 7.1 resume as principais funes das 5 reas funcionais do

gerenciamento.
As redes ATM, devido a suas caractersticas prprias, necessitam de novas
funes em cada uma das reas funcionais especificadas pela ISO.
Atualmente, verifica-se uma nfase maior nos estudos de mecanismos de gerncia
de configurao e falhas, justamente devido maior aplicabilidade prtica destes
mecanismos para a garantia de servio a curto prazo em um ambiente de
produo. As demais reas de gerenciamento tm, entretanto, grande importncia
para o total controle de uma rede, visto que aspectos como segurana e
desempenho so vitais para o bom funcionamento da rede a mdio e longo prazos,
e a contabilizao propicia uma avaliao confivel sobre a utilizao da rede,
ajudando para o projeto de expanso de uma rede, por exemplo.
A seguir, sero apresentadas as reas funcionais da gerncia sob o enfoque das
redes ATM.
83
Gerenciamento de
Configurao
Gerenciamento de
Falhas
Gerenciamento de
Segurana
Gerenciamento de
Desempenho
Gerenciamento de
Contabilizao
Backup de dados para recuperaes futuras

Gerenciamento de inventrio de recursos
Planejamento e execuo de ativao e desativao de recursos
Selecionar e agrupamento de recursos
Alterao e consultas de dados
Anlise e reportao de alarmes
Anlise e reportao de resultados de testes e diagnsticos
Correlao de alarmes mltiplos
Manuteno do histrico de alarmes
Selecionar, executar e cancelar rotinas genricas de teste e
diagnstico
Autenticao
Controle de acesso
Monitoramento da integridade de dados e sistemas
Suportar Auditorias
Recuperar o sistema de invases
Reportar alarmes de segurana
Armazenamento de informaes sobre o monitoramento de
desempenho
Armazenamento de dados sobre o gerenciamento de trfego
Anlise de informaes de desempenho e gerao de relatrio de
concluses
Correlao de alarmes e alertas e gerao de relatrio de
concluses
Atualizar e consultar informaes de controle e desempenho
Armazenamento de medies de utilizao
Formatao e relao de estatsticas de utilizao
Tabela 7.1: reas e Funes de Gerenciamento
7.1. Gerenciamento de Configurao

O Gerenciamento de Configurao em redes ATM deve identificar e controlar os
dispositivos de comunicao, coletando e fornecendo informaes, de forma a
manter conectividade contnua e confivel aos recursos de rede. O Gerenciamento
de Configurao deve manter informaes de status e de configurao de
comutadores ATM, de forma a realizar o seu gerenciamento.
84
Dentre as tarefas do Gerenciamento de Configurao, esto:
Definir os parmetros de funcionamento normal de um sistema;

Associar nomes a objetos gerenciados individuais ou agrupados;
Inicializar e finalizar objetos gerenciados;
Coletar informaes (sob demanda) sobre as condies atuais de um sistema
de comunicao;
Receber comunicados sobre mudanas significativas em sistemas de
comunicao; e
Mudar a configurao de um recurso.
Na prtica, o Gerenciamento de Configurao deve manter atualizado o inventrio

de software, hardware e circuitos. Um sistema de gerenciamento de configurao
deve Ter a possibilidade de realizar mudanas neste inventrio de forma a
representar da melhor forma possvel uma rede, mantendo a consistncia e
confiabilidade dos parmetros operacionais, nomes, tabelas de endereos e
configurao de hardware e software. A Tabela 7.2 resume as principais
atividades de cada funo do Gerenciamento de Configurao.
External Update Support
Alterao do estado operacional

Comunicao de mudanas na configurao
Relato de mudanas de configurao externas
Memory Update Support
Configurao de UNIs, B-ICIs e B-ISSIs
Configurao de VPLs and VCLs
Configurao de conexes ATM ponto-a-ponto e pontoa-multiponto
Ativao e desativao de funes de comutadores
Supresso e duplicao de mensagens autnomas
Memory Query Support
Consulta de dados de configurao de comutadores
Memory Backup and
Manuteno de cpias de segurana de arquivos de
Restoration
configurao
Restaurao da configurao de comutadores para suas
memrias RAM
Software Download Support
Carga e recarga de componentes de software de
comutadores
Tabela 7.2: Atividades Especficas do Gerenciamento de Configurao de
comutadores ATM
85
No caso de operao com mais de um comutador ATM, funes agregadas para o

Gerenciamento de Configurao so definidas. Algumas delas so:
Gerenciar Inventrio de Elementos de Rede

Envolve a manuteno de informaes atualizadas sobre os elementos de rede
e da rede como um todo. Estas informaes devem ser atualizadas a partir das
informaes disponibilizadas por cada elemento de rede. O controle de
inicializao e paralisao de elementos de rede e controle sobre VCCs e
VPCs tambm tarefa inerente a esta funo.
Cadastrar Recursos de Rede

Tem como finalidade selecionar e cadastrar recursos de rede instalados,
atendendo solicitao do sistema de gerenciamento na camada superior.
Ativao e Desativao de um Recurso de Rede

Cada recurso de rede tem associado a si caracterstica de estado, que indica se
o recurso est operacional (ativado) ou fora de servio (desativado). O sistema
de gerenciamento de configurao deve controlar (se necessrio) a seqncia
de estados ativado/desativado dos recursos da rede conjuntamente, de acordo
com a necessidade.
Backup de Dados
Referente capacidade de salvaguardar e recuperar os bancos de dados dos
recursos de rede, quando dados forem perdidos ou corrompidos.
7.2. Gerenciamento de Falhas
O Gerenciamento de Falhas tem como funo a deteco, localizao, isolamento

e correo de falhas e gerao de relatrios acerca de anormalidades na operao
da rede.
Problemas (persistentes ou temporrios) so disfunes que ocasionam reduo ou
queda total dos servios. As falhas se manifestam como eventos. A deteco de
86
eventos tem como funo analisar e detectar os eventos de forma a encontrar

falhas.
Dentre as funes do Gerenciamento de Falhas, esto:
Procurar e identificar problemas;

Receber e atuar sobre notificaes de deteco de erros;
Desencadear seqncias de testes de diagnstico;
Isolar os pontos de falhas;
Corrigir os problemas; e
Manter e examinar o histrico de erros.
7.2.1.
Vigilncia de Alarmes
Funes de vigilncia de alarmes tm como funo facilitar a deteco e a

notificao de problemas na rede. Em comutadores ATM, a vigilncia de alarmes
pode ser realizada tanto a nvel de recurso de rede quanto a nvel de sistema de
gerenciamento. Esta funo dever realizar um monitoramento na rede de forma a
detectar anomalias, defeitos e falhas.
Anomalias so discrepncias entre os estados atual e desejado da rede. O estado
desejado deve ser especificado, definindo-se assim o baseline da rede. Uma
anomalia pode ou no afetar o funcionamento da rede. Erros de delimitao de
quadros e violaes de formato de quadros (CRC e BIP) so exemplos de
anomalias.
Defeitos so suspenses momentneas em algum servio ou componente da rede.
Um defeito pode ou no requerer alguma ao de manuteno, dependendo da
concluso acerca de seus possveis efeitos. Anomalias sucessivas em um objeto de
rede que possa reduzir o seu desempenho podem constituir um defeito. Pequenos
intervalos de perda de sinal no meio fsico, sinais de indicao de alarme e perda
de quadros so considerados defeitos.
Falha uma paralisao de funcionamento de algum servio ou componente de
rede. Uma falha declarada quando defeitos sucessivos que afetam o servio de
rede ocorrem dentro de um determinado intervalo de tempo. Falhas remotas e
locais podem ser observadas em um elemento de rede.
87
O primeiro indcio de situao problemtica a observao de anomalias. Se as

anomalias persistirem por, digamos, uma pequena frao de segundo, um defeito
declarado. Neste caso, mecanismos de notificao de alarmes so ativados. Caso o
defeito permanea por um determinado intervalo de tempo, a falha declarada, e
o sistema de gerenciamento dever ser tambm notificado.
Trs aspectos devem ser observados pelo processo de vigilncia de alarmes. O
primeiro a deteco de problemas a nvel de camadas Fsica e ATM, declarando
defeitos e falhas nos elementos de rede. O segundo aspecto a divulgao dos
problemas atravs de mecanismos de indicao de alarmes entre os elementos de
rede afetados. O terceiro aspecto a gerao de relatrios ao sistema de
gerenciamento.
7.3. Gerenciamento de Segurana

O Gerenciamento de Segurana dever assegurar a integridade e a privacidade das
informaes de uma concessionria de servios de rede e de seus clientes. Nesse
contexto, os seguintes aspectos so relevantes:
Autenticao;
Integridade de Dados e Sistemas;
Identificao;
Controle de Acesso aos Recursos;
Controle de Acesso aos Sistemas;
Histrico de Auditorias dos Sistemas.
Esta rea de gerenciamento ainda no foi suficientemente desenvolvida e estudada

em redes ATM.
7.4. Gerenciamento de Desempenho

Uma rede ATM tem como caracterstica marcante a heterogeneidade dos vrios
tipos de trfego integrados pelo sistema (ex. dados, vdeo e udio). Este fato
facilita a ocorrncia de problemas de desempenho que degradam os servios de
rede. Necessita-se, ento, de funes de controle e monitoramento de recursos
para evitar tais situaes.
88
Dentre as principais funes de relevncia de desempenho em redes ATM,

destacam-se:
Gerao de clulas GD-OAM;

Monitoramento de Protocolo de clulas OAM, AAL e a nvel de cabealhos de
clulas;
Ativao e desativao do monitoramento de desempenho em VCs e VPs.
7.4.1.
Monitoramento de Desempenho
O Monitoramento de Desempenho se refere tarefa de periodicamente recuperar e

avaliar dados sobre o funcionamento e eficcia das funes que foram atribudas a
um recurso de rede. A funo do Monitoramento de Desempenho observar
periodicamente quedas no funcionamento de uma funo de rede, de forma a
detectar disfunes intermitentes ou originadas da deteriorao gradual de
equipamentos de rede. A importncia dos mecanismos de Monitoramento de
Desempenho reside na capacidade de deteco antecipada de problemas na rede
que podem ser evitados, antes mesmo que ocorram.
Diversos parmetros so objetos chave para a avaliao do desempenho de uma
rede. Ao nvel de usurio, um desses parmetros a classe de Qualidade de
Servio (QoS) de cada conexo. Atravs desta caracterstica, informaes mais
detalhadas acerca do comportamento de uma fonte de trfego podem ser
estimadas, de forma a analisar a probabilidade de ocorrncia de
congestionamentos na rede.
Trs aspectos merecem nfase no Monitoramento de Desempenho:
Monitoramento de Desempenho do Transporte Fsico;

Monitoramento de Protocolo;
Monitoramento de Desempenho de VPCs e VCCs.
O Monitoramento de Desempenho do Transporte Fsico lida com a avaliao da

eficcia do transporte de dados ATM sobre os meios fsicos, como DS1, DS3 e
SONET. Para cada especificao de meio fsico, uma srie de funes de
gerenciamento de desempenho so descritos em [30].
89
O Monitoramento de Desempenho a nvel de protocolo envolve todas as camadas

da pilha de protocolos ATM. Portanto, duas abordagens so especificadas e
definem suas funes:
Funes a nvel de processamento de cabealho em clulas ATM

Envolve os protocolos das camadas Fsica e ATM, no que diz respeito
manipulao, processamento e deteco de erros em bits de cabealho de
clulas.
Funes a nvel de monitoramento dos protocolos da camada AAL (AAL3/4 e

AAL5)
Engloba as funes relativas s emulaes e adaptaes realizadas pela
camada AAL, monitorando protocolos orientados a conexo ou no.
7.4.2.
Monitoramento de Protocolo por Processamento de Cabealhos
Cada clula ATM processada a partir das informaes constantes em seu

cabealho. O processamento dessas informaes feito tanto a nvel de camada
Fsica quanto a nvel de camada ATM, diferenciando apenas no tipo de
processamento: estrutura fsica na camada fsica e estrutura semntica na camada
ATM. Este processamento tem como funes: definir o roteamento das clulas
ATM, atravs do mapeamento entre informaes VPI/VCI e as portas de entrada,
de forma a definir a porta de sada; e manter o controle de fluxo genrico das
conexes.
Entretanto, fatores como deteriorao ou defeito em equipamentos, bugs de
software ou tabelas de mapeamento de VPI/VCI adulteradas podem afetar o
desempenho dos servios de rede, resultando na perda ou descarte de clulas e na
degradao do servio de conectividade fim-a-fim.
O ideal, ento, processar os cabealhos das clulas ATM, de forma a detectar
anormalidades que possam influir na qualidade da operao da rede, e, ento,
disparar procedimentos corretivos.
Para o monitoramento de desempenho a nvel de camada fsica e ATM,
informaes acerca da ocorrncia de problemas de processamento de cabealhos
de clulas ATM so necessrias. Estes dados podem facilitar a deteco dos
problemas que podem deteriorar o servio de rede. Estas informaes so:
90
Nmero de clulas descartadas devido a erros nos bits de cabealho de

clulas
Esta informao tem como funo dar a indicao implcita de falhas
intermitentes na camada fsica, atravs da deteco sucessiva de situaes
anormais.
Nmero de clulas com erros detectados nos bits de cabealho

Esta informao pode dar a idia do efeito do erro de cabealho para a clula
ATM.
Clulas descartadas devido a erros de cabealho na camada ATM

Esta informao est mais relacionada a erros semnticos em cabealhos de
clulas ATM, os quais so detectados a nvel de camada ATM. Nesse nvel,
com o descarte de clulas com erro de bits de cabealho, clulas invlidas e
Unasigned cells, restam apenas as clulas fisicamente vlidas. feita, ento, a
checagem de integridade e consistncia dos dados do cabealho, utilizando-se
regras para sua avaliao. Essas regras definem operaes como: o descarte de
clulas com indicaes explcitas do tipo de trfego que no respeitam seus
valores permitidos de VPI/VCI, PTI e CLP. (Ex. clulas de sinalizao pontoa-ponto que tm 1 como primeiro bit do campo PTI de seu cabealho devem
ser descartadas), ou o descarte de clulas sem identificao predefinida do tipo
de trfego (Ex. clulas com valores de VPI/VCI que no correspondem a um
endereo de rede ativo devem ser descartadas). A recepo de clulas OAM
que no podem ser processadas tambm exige o descarte dessas clulas, como
no caso da recepo de clulas OAM-GD em uma conexo onde o
Monitoramento de Desempenho no esteja ativado.
7.4.3.
Monitoramento de Protocolo na Camada AAL
O monitoramento de protocolos da Camada de Adaptao ATM visa acompanhar

o desempenho de servios que utilizem os protocolos oferecidos por esta camada.
No que diz respeito a armazenamento, limitao e gerao de relatrios, os
mtodos utilizados para o monitoramento de protocolos da camada AAL so
semelhantes aos adotados pelo monitoramento de protocolos a nvel de camada
ATM.
91
Existem especificaes ligeiramente distintas para o Monitoramento de

Desempenho de camada AAL. O documento [21] especifica o gerenciamento de
desempenho para camada AAL em interfaces M4, levando em conta a
implementao de camada AAL em rede pblica.
Os critrios de gerenciamento da camada AAL variam de acordo com o seu tipo
(Tipo 1, Tipo 2, Tipo 3/4 ou Tipo 5), portanto, de acordo com a classe de servio a
que cada tipo de camada AAL est apta a suportar.
O Monitoramento de Protocolo para camada AAL se baseia na contagem de
eventos anormais ocorridos sobre suas PDUs (Protocol Data Units). Para isto, so
implementados sistemas de contagem de eventos que podem utilizar contadores
simples ou o algoritmo Sum-of-Errors. A deteco de estados anormais feita
atravs do reconhecimento de ultrapassagem de limites (threshold) para os
contadores, onde cada contador pode ou no ter seu valor limite estipulado.
O algoritmo Sum-of-Errors tem como funo detectar erros persistentes dentro de
um determinado intervalo de tempo, e consiste de uma srie de contadores
individuais com valores limite estipulados. O registro de contagem feito durante
um determinado tempo (perodo de agregao), que recomendado em 15
minutos pela ATM Forum, em [21]. Quando um ou mais contadores acusam a
ultrapassagem de seus limites, uma notificao TCA (Threshold Crossing Alert)
gerada e enviada para o sistema de gerenciamento adequado. A contagem de erros
prossegue, mesmo aps a emisso do TCA, at que o perodo de agregao tenha
expirado, ou o contador chegue ao nmero mximo definido. Aps o trmino do
perodo de agregao, os contadores sero todos zerados e a contagem reinicia,
marcando o incio de um novo perodo de agregao. A Figura 7.1 mostra o
funcionamento do algoritmo Sum-of-Errors.
Para cada conexo, seja VCC ou VPC, uma implementao do sistema de
contagem de eventos ativada, de forma a realizar o monitoramento de
desempenho no protocolo AAL utilizado nesta conexo.
A camada AAL se divide em duas subcamadas: SAR (Segmentation and
Reassembly Sublayer) e CS (Convergence Sublayer). O monitoramento de
desempenho AAL feito tambm a nvel de subcamada AAL.
92
Contadores
Sistema de
Gerenciamento
TCA
Limites
Sum-of-Errors
Observao de
Ultrapassagem de Limite
Figura 7.1: Algoritmo Sum-of-Errors

O Monitoramento de Desempenho da subcamada SAR feito atravs do uso de
contadores com valores limite para suas PDUs (SAR-PDUs). Dois tipos de erros
so passveis de ocorrer em um campo do SAR-PDU: Campo Invlido e Campo
Incorreto.
A ocorrncia de Campo Invlido se d quando o valor de um certo campo da
SAR-PDU est fora dos limites estipulados para este campo. Por exemplo, SARPDUs com funes de BOM (Beginning of Message) e COM (Continuing of
Message) devem ter 44 como valor do campo User Information Lenght. A
ocorrncia de valor diferente de 44 para este campo caracteriza um Campo
Invlido.
Um Campo Incorreto se d quando os valores dos campos de um SAR-PUD so
vlidos, mas h indcios concretos de falhas na transmisso ou manipulao do
PDU que possam comprometer sua integridade. Um exemplo a verificao de
validade de todos os campos de uma SAR-PDU, mas o CRC constante no PDU
no confere com o CRC calculado quando do recebimento das informaes.
A principal diferena entre um Campo Invlido e um Campo Incorreto que a
ocorrncia de um campo invlido pode caracterizar uma implementao incorreta
ou imprpria do protocolo, enquanto um Campo Incorreto indica alguma falha de
procedimento ou de transmisso do SAR-PDU.
Para o Monitoramento de Desempenho de Protocolo da subcamada CS, um
procedimento de contagem onde se classificam erros dos tipos Campo Invlido e
93
Campo Incorreto em CS-PDUs similar ao sistema de monitoramento de

desempenho da subcamada SAR utilizado.
A checagem de erros da camada AAL5 feita em todo o corpo de cada quadro,
que pode variar em tamanho e chagar at o valor mximo de 65.536 octetos. O
tamanho do quadro ajustado de acordo com o PDU empregado, de forma a
possibilitar o preenchimento total de um nmero inteiro de clulas.
O Monitoramento de Protocolo para AAL5 se d no ponto de chegada dos
quadros, onde as seguintes condies de erro so checadas:
Invalid format of control field

Ocorre quando h inconsistncia nas informaes do campo de controle de um
quadro.
Lenght violation
Quando h ocorrncia de quadros cujos tamanhos diferem do tamanho de
quadro especificado para o seu protocolo.
Oversized Service Data Units (SDUs) received

Quando o tamanho da unidade de dados do servio no confere com o
tamanho especificado para o servio. Neste caso, o tamanho de unidade se
refere ao servio, e no ao protocolo de transmisso de dados.
Cyclic Redundancy Checking (CRC) violations

Quando ocorre diferena entre o campo CRC constante no quadro recebido e o
CRC calculado no ponto de chegada. Pode indicar erro de transmisso dos
dados.
Para o gerenciamento de Desempenho de uma rede ATM como um todo,

necessrio 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 anlise de desempenho do conjunto d a medida de desempenho
do ponto de vista do usurio, que pode observar o desempenho da rede na medida
fim-a-fim. Para que esta anlise de desempenho possa ser feita, algumas tarefas
tm de ser suportadas pelo sistema de gerenciamento. So elas:
94
Acumulao de dados de monitoramento de desempenho e gerenciamento de

trfego
O sistema de gerenciamento deve acumular informaes em um mbito maior
do que de um comutador individual. Deve, tambm, manter informaes
atualizadas de histrico maiores do que a memria de eventos usual de
comutadores, que em geral no passa de 15 minutos para informaes de
monitoramento de desempenho. Ocorre, em alguns casos, a necessidade de
informaes de histrico de dias ou meses para alguns tipos de anlise.
Anlise de informaes de gerenciamento de desempenho e gerao de

relatrios sobre as concluses
tarefa do sistema de gerenciamento realizar anlises acerca das informaes
de desempenho coletadas e armazenadas, produzindo relatrios acerca dos
resultados obtidos.
Correlao de alertas e alarmes e gerao de relatrios sobre as concluses

Durante o perodo monitorado, alarmes e alertas so emitidos ao sistema de
gerenciamento, que deve correlacionar as notificaes nos relatrios de falhas
que podem debilitar o desempenho da rede. Embora cada comutador possa
fazer uma correlao de suas notificaes localmente, a correlao a nvel
global ainda se faz necessria, para que se possa realizar um diagnstico de
desempenho fim-a-fim de forma confivel.
Atualizao e Consulta a base de dados de informaes de gerenciamento de

desempenho dos comutadores
Permite que o sistema de gerenciamento possa recuperar informaes
armazenadas nos comutadores da rede, e tambm atualizar e estipular limites
s informaes de desempenho, alm de agendar procedimentos de
monitoramento nos comutadores.
7.5. Gerenciamento de Contabilizao

O Gerenciamento de Contabilizao em redes ATM tem coimo funo permitir a
uma concessionria de rede pblica contabilizar e taxar o uso de seus recursos e
servios de rede por parte de seus clientes.
Para isto, informaes sobre a utilizao da rede, chamadas formalmente de
Contabilizao Automtica de Mensagens (AMA - Automatic Message
95
Accounting) so recolhidas, armazenadas e tarifadas pelo sistema de

gerenciamento.
As funes que o gerenciamento de contabilizao deve suportar para redes ATM
incluem:
Coletar informaes AMA;
Assegurar a confiabilidade das informaes AMA;
Registrar a ocorrncia de clulas recebidas com violao ao contrato de
trfego;
Suportar formatos padres para informaes AMA.
Algumas das informaes a serem coletadas para fins de tarifao so: Nmero
Total de Clulas, Clulas de Alta Prioridade, Clulas OAM e Clulas OAM de
Alta Prioridade.
Para o caso de gerenciamento de contabilizao de mltiplos comutadores,
funes adicionais para agrupamento das informaes coletadas de cada
equipamento devem ser implementadas. Alm disso, subfunes de anlise dessas
informaes AMA devem ser suportadas, de forma a evitar mltipla tarifao.
96
Captulo 8
8. MIBs SNMP aplicadas ao ATM

8.1. Introduo
Com a popularizao da Internet e, por conseqncia, de todas os protocolos da
famlia TCP/IP, natural que o SNMP tenha sido a primeira tentativa de se
integrar toda a infra-estrutura disponibilizada pelo Plano de Gerncia em um
sistema de gerncia adequado a este ambiente.
Era de se esperar, e a prtica tem mostrado, que o protocolo SNMP no tenha se
mostrado uma soluo eficiente em gerncia de redes ATM. Dentre as limitaes
do SNMP na gerncia ATM, merece destaque:
Gerentes de redes ATM necessitam administrar recursos multimdia, o que

envolve uma quantidade enorme de dados a serem coletados, processados e
apresentados, para o qual SNMP no foi originalmente projetado. Alm disso,
a natureza destes dados incompatvel com a caracterstica de simplicidade do
SNMP.
A despeito destas limitaes, o SNMP tem sido adaptado e estendido para

suportar produtos baseados na tecnologia ATM. O que est em questo como
adaptar e estender as funcionalidades bsicas do SNMP para prover as funes de
gerenciamento em tempo real ATM.
Isto significa repensar a arquitetura de gerenciamento de redes. J que o ATM
prov conexes virtuais, a arquitetura de gerenciamento tem que ser
descentralizada, ou seja, desenvolvida como uma srie de subagentes que
reportam informaes sobre configurao e estado da rede a partir de vrios
dispositivos ATM, como por exemplo o estabelecimento de uma conexo.
Utilizando esta abordagem, dispositivos ATM podem enviar dados SNMP para
97
uma estao de gerenciamento central, assim provendo monitoramento SNMP em

tempo real.
O emprego desta abordagem tambm significa repensar o papel do hardware da
rede. Tradicionalmente, dispositivos de rede tm tido propsitos bem definidos.
Basicamente, estes dispositivos ou distribuem ou processam os dados sobre links
fsicos, usando os dados do cabealho para determinar o destino. Com o advento
do ATM, alguns destes dispositivos (especialmente pontes e roteadores) esto
ficando obsoletos, e os comutadores e concentradores (hubs) centrais esto
comeando a realizar todas as funes.
Estes equipamentos (comutadores, hubs, etc) se tornam uma parte crtica de uma
estratgia de gerenciamento da rede. Isto significa que fornecedores podem usar
processadores mais baratos nesses equipamentos, j que a sua CPU somente
processa sua poro dos dados SNMP. Alm disso, atualizar a capacidade de
gerenciamento torna-se mais fcil. Por exemplo, empregando um estrutura de
gerenciamento SNMP descentralizada, hubs individuais podem ser prontamente
atualizados com mdulos ou cartes novos sem a necessidade de se reconfigurar a
rede inteira.
Dentre as MIBs SNMP aplicadas ATM, a mais importante e a padro para o
gerenciamento ATM a AToM MIB, apresentada na prxima seo. Outras
MIBs, que modelam aspectos especficos, so apresentadas no Anexo A.
8.2. AToM MIB

Esta especificao da AToM MIB (tambm chamada de MIB ATM) de
responsabilidade do grupo de trabalho ATOM MIB da IETF (Internet
Engineering Task Force), que o encarregado pelas questes de gerenciamento
ATM dentro do IETF. Ela se preocupa com a definio de objetos que auxiliam
no gerenciamento de interfaces, circuitos virtuais, cruzamento de conexes,
entidades AAL5 e conexes AAL5 em um ambiente ATM. A especificao atual
desta MIB baseada na SMIv2, ou seja, tem como base o protocolo de
gerenciamento SNMPv2.
98
Esta MIB tem como principal propsito o gerenciamento de circuitos virtuais

permanentes (PVC Permanent Virtual Circuit) em ambientes ATM. Apesar de
oferecer objetos que possuem informaes sobre circuito virtuais comutados
(SVC Switched Virtual Circuit), este servio requer a definio de capacidades
adicionais no representadas nesta MIB. Estas capacidades esto sendo
especificados em MIBs suplementares, como a descrita no anexo A.
Com o objetivo de realizar o gerenciamento de interfaces, circuitos virtuais e
cruzamento de conexes, outras MIBs so necessrias. Dentre elas temos: MIB II
para o gerenciamento de interfaces e do sistema com um todo, MIBs relacionadas
com interfaces fsicas (DS3 e SONET), e MIBs que representam aplicaes que se
utilizam de ATM, como SMDS e Frame Relay.
Os objetos de gerenciamento definidos nesta MIB so representados atravs de
tabelas e divididos de acordo com suas funes, como descrito no diagrama da
Figura 8.1.
8.2.1.
Interfaces
Configurao de interfaces (atmInterfaceConfTable)

Este grupo contm informaes de configurao sobre as interfaces ATM, alm
das encontradas na tabela de interfaces ifTable, da MIB II.
Cada entrada se relaciona com uma interface ATM presente no dispositivo e
composta de parmetros de configurao como: endereo ATM da interface
(atmInterfaceAdminAddress), numero mximo de VPCs e VCCs suportados
(atmInterfaceMaxVpcs e atmInterfaceMaxVccs), nmero de VPCs e VCCs
configurados (atmInterfaceConfVpcs e atmInterfaceConfVccs) (incluindo SVCs e
PVCs), VPI e VCI utilizado pelo protocolo ILMI, etc.
Interfaces DS3 PLCP (atmInterfaceDs3PlcpTable)

Este grupo tambm uma extenso da tabela ifTable (MIB-II) e contm
parmetros de configurao, e de estado do DS320 PLCP23.
99
Configurao
Inte rface
Inte rface s
DS3 PLCP
Subcamada
TC
M IB ATM
RFC 1695
Cruzame nto
Cone xe s
Configurae s
VPL/VCL
Circuitos
Virtuais
De s critore s
de Trfe go
Figura 8.1: Estrutura da AToM MIB

Esta tabela possui uma entrada por interface, que se utiliza de DS3 PLCP para
transportar clulas sobre DS3. Cada entrada possui informaes sobre o nmero
de eventos de erro (atmInterfaceDs3PlcpSEFSs), existncia de alarmes
(atmInterfaceDs3PlcpAlarmSate) e de perodos de tempo em que a interface no
esteve disponvel (atmInterfaceDs3PlcpUASs).
Subcamada TC (atmInterfaceTCTable)
Este grupo possui parmetros de estado e de configurao da subcamada TC.
Tambm uma extenso da tabela ifTable.
20.
Nvel de multiplexao de PDH (Plesiochronous Digital Hierarchy) que

opera a taxas de transmisso de 45Mb/s.
23 PLCP (Physical Layer Convergence Procedure) um mtodo para
transportar clulas sobre PDH, um meio fsico baseado em frames.
100
Cada entrada se relaciona com uma interface que utiliza a subcamada TC para
transportar clulas. As entradas possuem dois atributos (atmInterfaceOCDEvents
e atmInterfaceTCAlarmState) que contm informaes sobre a existncia de
problemas na delineao de clulas. Exemplos destas interfaces so aquelas que
possuem como camada fsica SONET ou DS3.
8.2.2.
Circuitos Virtuais ATM
Configurao de VPLs e VCLs (atmVplTable e atmVclTable)

Estes grupos contm informaes de configurao e de estado de um circuito
VPL/VCL bidirecional que so definidos a partir de duas tabelas: atmVplTable e
atmVclTable, respectivamente. Como seus parmetros so similares, iremos
detalh-las juntamente. Estas tabelas so definidas em terminais e comutadores e
podem ser utilizadas para se criar, atualizar ou liberar um VPL/VCL.
Os parmetros comuns estas tabelas so: identificador de caminho virtual, que
o VPI (atmVplVpi) para conexes VPL e a combinao de VPI e VCI (atmVclVpi
e atmVclVci) para VCL; os atributos que caracterizam o estado do circuito,
AdminStatus (implementado para um VPL/VCL final de um VPC/VCC e
descreve o estado administrativo do VPL/VCL indicando se o fluxo de trfego
est habilitado ou no), OperStatus (especifica o estado operacional do VPL/VCL)
e LastChange (Timestamp que indica a ltima alterao do estado do circuito).
Os outros parmetros so ndices para a tabela de descrio de trfego
(atmTrafficDescrParamTable - um para cada direo de trfego dentro do
circuito), e um ndice para a tabela de cruzamento de conexes
(CrossConnectTable).
O grupo VCL possui mais alguns parmetros em sua tabela. Estes s so
aplicados no caso em que o fim de um VCL tambm o fim de um VCC. So
eles: atmVccAalType (identifica o tipo de camada de adaptao utilizada neste
circuito), atmVccAal5CpcsTransmitSduSize (descreve o tamanho mximo da
AAL5 CPCS SDU em octetos que suportado na direo de transmisso deste
VCC), atmVccAal5CpcsReceiveSduSize (Igual o anterior na direo de recepo)
e atmVccAal5EncapsType (especifica o tipo de encapsulamento de dados usado
sobre a camada AAL5 SSCS).
101
Descritores de trfego ATM (atmTrafficDescrParamTable)

Este grupo possui um conjunto de parmetros que caracterizam o trfego ATM,
incluindo a classe da Qualidade de Servio (QoS). Esta tabela definida tanto em
terminais como em comutadores.
Cada entrada descreve o trfego que transportado sobre um circuito virtual, tanto
quantitativamente quanto qualitativamente. Os descritores de trfego esto de
acordo com os resultados da negociao, quando do estabelecimento da conexo.
Quando criada uma nova entrada nesta tabela seus parmetros so checados para
garantir a consistncia.
Os atributos definidos em cada entrada da tabela podem ser divididos em dois
subconjuntos:
parmetro atmTrafficDescrType descreve o tipo de trfego e como interpretar
outros cinco parmetros, que caracterizam fluxo de trfego. Os atributos
definidos neste subconjunto so utilizados pelo servio UPC (Usage Parameter
Control);
parmetro atmTrafficQoSClass caracteriza a classe de servio sendo utilizada
pelo circuito virtual.
8.2.3.
Cruzamento de Conexes
Cruzamento de Conexes VP/VC (atmVp(Vc)CrossConnectTable) - PVC

Estes grupos descrevem informaes sobre estado e configurao de todos os
cruzamentos de conexo VP/VC relacionados com PVC (Permanent Virtual
Circuit), sejam eles ponto a ponto, ponto a multiponto e multiponto a multiponto.
Estas informaes so disponibilizadas somente em comutadores, onde temos a
funcionalidade de cruzamento de conexes. Os grupos baseiam-se
respectivamente
nas
tabelas
atmVpCrossConnectTable
e
atmVcCrossConnectTable, que sero descritas juntas em virtude de suas
similaridades.
102
Um conjunto de entrada nesta tabela representa o cruzamento de conexes

VPC/VCC bidirecionais. Para uma conexo ponto a ponto temos uma entrada,
ponto a mutiponto com N ns folhas temos N entradas e para conexes
multiponto a multiponto entre N ns temos, N(N-1)/2 entradas. Cada uma dessas
entradas referencia duas entradas nas tabelas de circuitos virtuais (VPL e VCL).
103
8.2.4.
Diagrama da Estrutura da MIB
Modelo Entidade/Relacionamento
ifTable
atmVplTable
IfIndex
Vpi
IfIndex
Vpi
Vci
atmTrafficDescrParamTable
ReceiveTrafficDescrIndex
TransmitTrafficDescrIndex
CrossConnectIdentifier
********
********
RowStatus
atmVclTable
MIB II - RFC1213
DescrParamIndex
DescrType
2
Param 1 - 5
QosClass, ****
ReceiveTrafficDescrIndex
TransmitTrafficDescrIndex
2
"LINKS" Virtuais
atmVPCrossConnectTable
CrossConnectIdentifier
********
RowStatus
atmVcCrossConnectTable
Index
Index
LowIfIndex
LowVpi
LowIfIndex
LowVpi
HighIfIndex
LowVci
HighVpi
********
HighIfIndex
HighVpi
********
RowStatus
HighVci
********
atmInterfaceConfTable
Index
MaxVpcs
MaxVccs
********
Cruzamento de Conexes
atmInterfaceTcTable
Index
OCDEvents
TCAlarmState
atmInterfaceDs3PlcpTable
Index
AlarmState
SEFs
-------------
********
Aal5VccTcTable
Index
Vpi
Vci
CrcErrors, ********
Interfaces
****** Outros atributos
-------- No existe mais

atributos nesta tabela
ifTable
MIB II - RFC1213
Figura 8.2: Modelo Entidade/Relacionamento: AToM MIB
104
8.3. MIBs SNMP e o Modelo de Referncia
Modelo das Cinco Interfaces
As interfaces M1 e M2 possuem suas especificaes baseadas no SNMP, em

virtude deste protocolo ser amplamente empregado atualmente. Gerentes de uma
rede privada estaro particularmente interessados nas interfaces M1 e M2. Estas
interfaces utilizam MIBs padronizadas pelo IETF e ATM Forum, tais como: MIB
II, MIBs padres para conexes (DS-1, DS-3 e Sonet), AToM MIB e ILMI MIB.
A tabela 8.1 mostra o mapeamento de diversas MIBs ATM (inclusive MIBS
CMIP) para o modelo das Cinco Interfaces.
Interface de
Gerenciamento
MIBs Aplicveis
M1
M2 (SNMP)
AToM MIB, LANE MIB, DXI MIB, MIBs Proprietrias

AToM MIB, LANE MIB, PNNI MIB, MIBs de Transmisso
(RFC 1406, RFC 1595), IMA, RMON MIB, MIBs Proprietris
M4 Network View MIB, M4 Network Element MIB, M2 SVC
MIB, ITU-T SONET MIB e E1/E3 MIBs
M3 MIB e AToM MIB
ILMI MIB, LANE MIB, CES MIB, M4 SNMP MIB, ATM AAL
MIB, MIBs de Transmisso (RFC 1406, RFC 1595), ATM
IMA MIB e RMON MIB
M4 NE MIB, ITU-T I.751 MIB, M4 SVC MIB, ATM AAL MIB,
MIBs de Transmisso (ITU-T G.704, G.706, G.774, G.826,
G.882), Bellcore G.I114 e NM Forum MIB
ATM Forum Network-to-Network MIB e ETSI NAS-2212
carrier-to-carrier MIB
M2 (CMIP)
M3
M4 (SNMP)
M4 (CMIP)
M5 (CMIP)
Tabela 8.1: Mapeamento das MIBs para o Modelo das Cinco Interfaces
105
8.4. Aspectos Prticos para o Uso de MIBs

Frente aos diversos tipos de MIBs existentes atualmente, um problema muito
comum a escolha da MIB mais apropriada para um determinado problema de
gerenciamento em uma rede ATM.
Neste mbito, existem dois casos especficos: definio do gerenciamento de uma
rede ATM que est em fase de projeto ou a aplicao de tarefas de gerenciamento
em uma rede ATM j existente. No primeiro caso, deve-se identificar as
necessidades de gerenciamento que se deseja suprir; identificar as MIBs existentes
que possam atender a essa necessidade; e consultar os fabricantes no mercado,
verificando se seus produtos suportam a(s) MIB(s) escolhida(s). Se o caso for a
implantao de gerenciamento em uma rede j existente, deve-se identificar os
equipamentos que compem a rede, de forma a verificar as MIBs suportadas pelos
produtos; e desenvolver aplicaes que possam fazer uso das MIBs disponveis.
Em ambos os casos, existem algumas dicas que podem ajudar a identificar e
analisar as MIBs:
Identificar as necessidades funcionais

Primeiramente, deve-se identificar e entender as necessidades de
gerenciamento de configurao, falha e desempenho da rede que se deseja
gerenciar.
Analisar as MIBs suportadas

Identificar nos comutadores existentes ou a serem avaliados as MIBs (padro
ou proprietrias) que so suportadas. Caso se trate de uma rede em projeto,
escolher o produto que suporte o melhor conjunto de MIBs.
Determinar um subconjunto de MIBs

Baseado nas necessidades funcionais definidas, deve-se determinar o
subconjunto de MIBs que podem responder ao problema exposto.
106
Captulo 9
9. ILMI (Integrated Local Management Interface)

Este modelo includo como parte da UNI (User-Network Interface) 4.0, proposto
pelo ATM Forum. O propsito deste padro auxiliar no gerenciamento de
configurao e de obteno de informaes status de uma interface especfica. Ele
tambm incorpora um mecanismo para registro de endereos e servios ATM
atravs da UNI.
Essas especificaes antes se chamavam Interim Local Management Interface,
porque o ATM Forum tinha a expectativa que essa fosse a soluo temporria de
gerenciamento enquanto o ITU-T no definisse padres para a gerncia de redes
ATM. Como essa expectativas no passaram, a proposta foi confirmada na verso
4.0, como dita Integrated.
Cada UNI de um dispositivo possui uma IME (Interface Management Entity),
associada a esta, para suportar as suas funes. As informaes de gerenciamento
so trocadas somente entre IMEs adjacentes. Caso um dispositivo tenha mais de
uma interface (como o caso de um comutador), uma IME ser associada a cada
interface. Cada IME executa procedimentos de agente e gerente para prover a
troca bidirecional de informaes entre IMEs.
ILMI define a sua MIB (conhecida como ATM Interface MIB) separadamente do
seu mecanismo de acesso (Figura 9.1). Esta abordagem no requer que existam
agentes nos dois lados da UNI. Por outro lado, foram definidas IMEs que acessam
as informaes da MIB, diretamente sobre um VCC predefinido (normalmente,
VPI=0 e VCI=16), atravs de comandos SNMP encapsulados na AAL5. Neste
caso, UDP/IP no so utilizados. Outro mecanismo de acesso a esta MIB se d
atravs de sistemas de gerenciamento usando SNMP sobre UDP/IP/AAL5. Como
tambm ilustrado na figura, ILMI pode ser usado tanto sobre UNIs pblicas e
privadas.
107
SNMP/UDP/IP
Agente SNMP
Agente SNMP
PRIVATE
UNI
PUBLIC
UNI
MIB
IME
Computador
MIB
ILMI
SNMP/AAL
IME
MIB
IME
ILMI
SNMP/AAL
Comutador ATM
Privado
IME
IME
Comutador ATM
Pblico
Figura 9.1: Ambiente ILMI (Integrated Local Management Interface)

Uma srie de equipamentos utilizam ILMI. Entre eles esto:
Estaes de trabalho que enviam suas clulas atravs de sua interface para
um comutador ATM
Comutadores ATM que enviam clulas para outros dispositivos ATM
atravs de suas interfaces
Comutadores de camadas superiores, como roteadores Internet,
comutadores de Frame Relay ou pontes de LAN, que transferem seus
quadros atravs de clulas ATM, e repassam suas clulas atravs de uma
interface ATM para um comutador ATM.
Um usurio ou um n privado pode automaticamente configurar o tipo de sua
interface ATM, como UNI Pblica, UNI Privada ou PNNI. Pode tambm
configurar o tipo de seu IME: tipo usurio (user-side), tipo rede (network-side) ou
simtrico.
Apesar de ser bastante divulgada, ILMI no prov funes de gerenciamento nas
reas de falha, segurana e contabilizao, possui limitaes em relao ao
108
gerenciamento de interfaces entre redes, e no distribui inteligncia de

gerenciamento sobre a rede.
9.1. ATM INTERFACE MIB

Tambm conhecida como ILMI MIB, a ATM Interface MIB possui 4 mdulos:
Textual Conventions MIB, Link Management MIB, Address Registration MIB e
Service Registry MIB.
A Textual Conventions MIB define um nmero de Convenes de Texto
(definio de diversos tipos de dados) e Identificadores de Objetos em um nico
mdulo, de modo que outros mdulos da ILMI MIB possam importar essas
informaes de modo consistente. A Link Management MIB prov a facilidade de
gerenciamento de interface para todas interfaces ATM. A Address Registration
MIB prov um mecanismo para o registro de endereos em uma UNI. A Service
Registry MIB prov um registro geral de servios para a localizao de servidores
ATM, como o LECS (LAN Emulation Configuration Server) ou o ANS (ATM
Name Server). A Figura 9.2 mostra o tipo de informaes existentes na ATM
Interface MIB, correspondendo s tabelas da MIB.
Physical Layer
ATM Layer
Virtual Path Connection
ATM Interface
MIB
Virtual Channel Connection

Network Preffix
Address
Service Registry
Figura 9.2: Informaes da ATM Interface MIB

109
A no ser que seja declarado ao contrrio para pores especficas da ILMI, cada
IME contm a mesma ATM Interface MIB. Contudo, a semntica de alguns
objetos da MIB pode mudar dependendo do papel de cada IME (se rede ou
usurio).
Obrigatoriamente, um dispositivo que implemente a ATM Interface MIB deve
tambm implementar o grupo "system" da MIB-II. Deste modo, um IME deve
prover acesso ao grupo "system" via ILMI.
Link Management MIB

a) Grupos da Link Management MIB
atmfPhysicalGroup: Esse grupo contm informaes que identificam a

interface fsica gerenciada pela IME e endereos do dispositivo (IP ou NSAP).
Alguns objetos dessa MIB (como tipo do meio fsico da interface, por
exemplo) se tornaram obsoletos na verso 4.0. O ATM Forum considera que
esses objetos devem ficar em outras MIBs padres, como a AToM MIB.
atmfAtmLayerGroup: Esse grupo contm informaes de configurao

camada ATM do dispositivo, presentes em todas conexes virtuais
interface. Por exemplo: o nmero mximo de VPCs e VCCS permitidos
interface, o tipo do dispositivo (usurio ou rede), o tipo da UNI (pblica
privada), a verso da UNI e da ILMI, entre outras.
atmfAtmStatsGroup: Esse grupo se tornou obsoleto na verso 4.0. Ele

continha estatsticas como nmero de clulas recebidas, transmitidas e
descartadas. Essas informaes devem ficar em outras MIBs padres.
atmfVpcGroup: Esse grupo contm informaes de status e parmetros dos
VPCs que passam por essa interface. Por isso, a tabela indexada pelo ifIndex
da MIB-II e pelo VPI da conexo. As informaes do grupo descrevem o
estado operacional da conexo (desconhecido, up fim-a-fim, up localmente, up
local e desconhecido fim-a-fim, down fim-a-fim, e down local), os descritores
de trfego relativos a transmisso e recepo do VPC e a categoria de servio
do VPC.
110
da
da
na
ou
atmForumUni
atmfPhysicalGroup
atmfNetPreffixGroup
atmfPortTable
atmfAtmLayerGroup
atmfNetPreffixTable
atmfSrvcRegGroup
atmfAtmLayerTable
atmfAtmStatsGroup
atmfSrvcRegTable
atmfVpcAbrGroup
atmfAtmStatsTable
atmfVpcGroup
atmfVpcAbrTable
atmfVccAbrGroup
atmfVpcTable
atmfVccAbrTable
atmfAddressRegistration
AdminGroup
atmfVccGroup
atmfVccTable
atmfAddressRegistration
AdminTable
atmfAddressGroup
atmfAddressTable
Figura 9.3: Estrutura da ATM Interface MIB
111
atmfVpcAbrGroup: Esse grupo de objetos uma extenso opcional ao

atmfVpcGroup, indexada tambm pelo VPI e pelo ifIndex. Ele contm
informaes a respeito dos parmetros operacionais de conexes VPC com
trfego ABR (Available Bit Rate)
atmfVccGroup: Esse grupo contm informaes de status e parmetros dos

VCCs que passam por essa interface. Por isso, a tabela indexada pelo ifIndex
e pelo par VPI/VCI da conexo. As informaes do grupo so anlogas
quelas para VPCs. Adicionalmente, o grupo traz indicadores de descarte de
quadros, para o caso de congestionamentos.
atmfVccAbrGroup: Esse grupo de objetos uma extenso opcional ao

atmfVccGroup, indexada tambm pelo par VPI/VCI e pelo ifIndex. Ele
contm informaes a respeito dos parmetros operacionais de conexes VPC
com trfego ABR (Available Bit Rate), anlogos aos contidos na
atmfVpcAbrGroup.
b) Procedimentos da Link Management MIB

Juntamente com as MIBs, foram definidos procedimentos de operao na ILMI.
Os procedimentos de Conectividade ILMI so usados para detectar a perda e o
estabelecimento de conectividade ILMI. Esses procedimentos so obrigatrios
para ns ATM (tipo rede) e opcionais para um host ATM (tipo usurio). Esse
eventos so utilizados para auto-configurao e registro de endereos. Para testar
ou estabelecer a conectividade, a IME envia uma PDU SNMP GetRequest para os
objetos atmfPortMyIfIdentifier, atmfMySystemIdentifier e sysUpTime.
Procedimentos de mudana do ponto de conexo (attachment point) podem ser
implementados opcionalmente em qualquer IME. Tais procedimentos tratam do
problema que podem ocorrer durante a sinalizao. Os mecanismos de sinalizao
podem suportar falhas na camada fsica por um curto perodo de tempo, antes de
liberar as conexes. Durante esse breve espao de tempo, existe uma possibilidade
que dois links sejam trocados, sem a deteco dos mecanismos de sinalizao.
Se um ponto de conexo (attachment point) no executa ILMI (executa IISP, por
exemplo), o IME local pode interpretar uma mudana no ponto de conexo como
112
uma perda da conectividade ILMI, o que pode ser inaceitvel para links seguros.
Assim, quando uma perda de conectividade ILMI detectada, a IME de um link
seguro deve informar as entidades de sinalizao para liberar todos SVCs
controlados por essa entidade, alm dos procedimentos de Conectividade ILMI
descritos acima. Esses procedimentos de links seguros so opcionais.
O VCC de VPI=0 e VCI=5 utilizado para sinalizao. A ILMI tambm define
procedimentos para configurar automaticamente os parmetros de transmisso
desse VCC. Outro procedimento da ILMI, implementado obrigatoriamente, trata
da modificao de atributos locais. Se o valor de alguns atributos, como os
interface da camada ATM, so modificados; o IME deve ser reinicializado para
efetuar as mudanas.
Address Registration MIB

Para se estabelecer uma conexo ATM na UNI, o usurio e a rede devem saber os
endereos ATM ativos naquela UNI. Esses endereos ATM podem ser usados nas
informaes do "Calling Party Number" das mensagens de sinalizao. Os
procedimentos de registro de endereos possibilitam a troca dinmica de
informao de endereamento entre o usurio e a rede, quando da inicializao e
em outros momentos. Tanto equipamentos com UNI privada como pblica devem
suportar mecanismos de registro de endereos.
Como especificado na UNI 4.0, um endereo ATM Privado consiste de diversos
campos. Dois desses, End System Identifier (ESI) e o Selector (SEL), formam a
"parte do usurio" e so fornecidas pelo IME do lado do usurio. Os outros
campos formam o "lado da rede", normalmente nicos em uma UNI, sendo
fornecidos pelo lado da rede. O endereo de um terminal ATM de uma UNI
Privada seria obtido pela juno dos valores ESI e SEL com um prefixo da rede
para aquela UNI.
Os procedimentos estabelecidos para o registro de endereos consistem em:
Troca de informaes de endereamento em momento de inicializao

Restries das combinaes de prefixo da rede e parte do usurio
Aceitao de prefixos de redes livres
Rejeio de valores inaceitveis, tanto rejeio de um prefixo de rede por
113
parte do usurio, como a rejeio da parte do usurio por parte da rede.

Adio/Remoo dinmica de prefixos da rede ou parte do usurio
Remoo de um endereo quando a conectividade ILMI perdida
Indicao de suporte ou falta de suporte para o registro de endereos em
uma interface.
Duas tabelas na MIB foram definidas para tratar do registro de endereos: uma
contendo prefixos de rede (atmfNetPrefixTable) e outra contendo os endereos
ATM registrados (atmfAddressTable).
A tabela de prefixos da redes fica no IME do lado do usurio, mas mantida pelo
IME do lado da rede, que envia PDUs SNMP de SetRequest para registrar ou
remover prefixos. Analogamente, a tabela de endereos ATM fica no IME do lado
da rede, mas mantida pelo IME do lado do usurio, que envia PDUs SNMP de
SetRequest para registrar ou remover endereos ATM.
Na inicializao, o registro de prefixos de rede ocorre primeiro. A seguir, o IME
do lado do usurio combina a partes do usurio com o prefixo da rede registrado
para formar um ATM completo. Ento, o IME do usurio registra esse endereo
na atmfAdressTable. A Figura 9.4 mostra o processo de registro de endereos,
quando da inicializao do sistema.
O grupo atmfAddressRegistrationAdminGroup, implementado em todos IMEs,
contm um indicador que informa se os mecanismos de registro de endereo,
descritos acima, so suportados ou no naquela interface.
Service Registry MIB

A Service Registry MIB prov um registro geral de servios para a localizao de
servidores ATM, como o LECS (LAN Emulation Configuration Server) ou o
ANS (ATM Name Server). Essa MIB implementada em IMEs que representam
o lado da rede. Para localizar um servio, um IME de usurio consulta o IME da
rede por informaes contidas na tabela atmfSrvcRegTable. Cada entrada dessa
tabela contm o endereo do servidor para que o IME do usurio possa estabelecer
conexo com o servidor.
114
Lado do Usurio
Parte do Usurio
UNI
Lado da Rede
Prefixo da Rede
atmfNetPrefixTable
atmfAddressTable
Endereo ATM completo
Figura 9.4: Registro de Endereos na ILMI
9.2. ILMI e a AToM MIB

Na especificao ILMI 4.0, o ATM Forum props a criao de um proxy para
integrar a AToM MIB e a ILMI, visando permitir o acesso por parte de um
gerente dos dados das MIBs ILMI. A Figura 9.5 mostra essa soluo.
Quando o agente proxy recebe um pedido de um gerente exterior, ele deve
determinar se deve acessar diretamente a AToM MIB ou repass-lo para o proxy.
O proxy deve tambm decidir se o pedido deve ser direcionado para um IME local
ou para um IME remoto. Essa deciso tomada com base na community contida
na PDU do pedido. O proxy usa o papel de agente do IME para acessar a ATM
Interface MIB local; e o papel de gerente, para acessar as informaes da MIB de
seus vizinhos. Para cada IME, duas strings community so definidas para
diferenciar pedidos para a MIB local dos pedidos para a MIB remota.
115
Sistema de Gerenciamento
Agente SNMP
PROXY
MIB
AToM
Interface ATM
MIB
ILMI
IME
IME
ILMI
Dispositivo ATM
MIB
ILMI
Dispositivo ATM
Figura 9.5: Acesso da MIB ILMI via Agente-Proxy
9.3. ILMI e os Modelos de Referncia
Modelo de Referncia RDSI-FL
Como as informaes contidas na ATM Interface MIB so claramente divididas

em camadas (atmfPhysicalGroup, atmfAtmLayerGroup), a tendncia afirmar
que ILMI se enquadraria no gerenciamento de camada. Contudo, as
especificaes no so claras a esse respeito. Visto que o gerenciamento de planos
trata do sistema como um todo e no possui uma estrutura em camadas.
Modelo das Cinco Interfaces
Visto sua aplicao em redes pblicas e privadas, ILMI se encaixa nas interfaces
M1, M2 e M4.
116
Captulo 10
10. Funes OAM
O OAM um conjunto de funes de Operao, Administrao e Manuteno,

recomendadas pela ITU-T no contexto das RDSIs. Esta infra-estrutura foi,
posteriormente, ratificada pelo ATM Forum, em sua recomendao da interface
UNI 3.1.
Atualmente, cinco funes de gerenciamento OAM so definidas. So elas:
Monitoramento de Desempenho
O funcionamento normal de uma entidade de rede observada a partir da
checagem peridica de funes, mantendo-se informaes sobre eventos
observados.
Deteco de Falhas e Defeitos

O funcionamento anormal detectado atravs de checagem peridica aos
elementos de rede. Notificaes e alarmes so emitidos e o histrico de
eventos mantido.
Proteo de Sistemas
Os efeitos de uma falha podem ser minimizados ou evitados atravs do
bloqueio ou do redirecionamento do servio. A entidade com falhas , ento,
retirada de operao.
117
Informaes de Falha e Desempenho

Informaes de falha, indicaes de alarme e respostas a solicitaes so
repassadas s entidades ou planos de gerenciamento correspondentes.
Localizao de Falhas
Determinao do local exato de uma falha, adicionalmente aos testes internos
e externos realizados pelos componentes de rede com problemas.
Para realizar as operaes citadas acima, as funes OAM so aplicadas em 5

nveis hierrquicos de fluxos: F1, F2, F3, F4 e F5 (Figura 10.1).
Conexo de Canal Virtual
F5
Camada
ATM
Conexo de Caminho Cirtual

F4
Caminho de Transmisso
F3
Seo Digital
Camada
Fsica
F2
Seo de
Regenerador
F1
Figura 10.1: Nveis Hierrquicos OAM
118
As informaes de fluxo F1, F2 e F3 dizem respeito ao transporte fsico ATM,

que envolvem tcnicas em geral proprietrias para a implementao do OAM.
Fluxo 1 (F1): Para o monitoramento do estado de transmisso entre

repetidores;
Fluxo 2 (F2): Para o monitoramento do estado de transmisso entre
multiplexadores e cross-connects;
Fluxo 3 (F3): Para o monitoramento fim-a-fim do nvel fsico entre
multiplexadores.
Os fluxos F4 e F5 tm como finalidade o monitoramento de funes na camada

ATM, abrangendo a transmisso de clulas entre os componentes de uma
conexo. O OAM implementado a nvel de camada ATM como clulas
especiais, denominadas clulas OAM.
Fluxo 4 (F4): Para o monitoramento de Caminhos Virtuais (VPs);

Fluxo 5 (F5): Para o monitoramento de Canais Virtuais (VCs).
Os fluxos OAM que dizem respeito Camada Fsica so F1, F2 e F3. A

implementao das funes OAM variam de acordo com a estrutura de
transmisso utilizada.
No caso de sistemas baseados em SDH, as funes OAM se utilizam dos
overheads dos quadros para transporte de seus fluxos, sendo que os fluxos F1 e F2
so transportados no overhead de seo (SOH - Section Overhead) enquanto o
fluxo F3 se utiliza do overhead de caminho (POH - Path Overhead).
Como dito anteriormente, OAM implementado a nvel de camada ATM como
clulas especiais, denominadas clulas OAM. Os fluxos F4 e F5 se utilizam de
vrios tipos de clulas OAM para realizar determinadas funes. A definio
dessas funes feita atravs dos campos da clulas OAM, apresentada na Figura
10.2.
Tipo de
OAM
4 bits
Tipo de
Funo
4 bits
Campo Especfico
de Funo
360 bits
Reservado
6 bits
CRC
10 bits
Figura 10.2: Payload da Clula OAM
119
Os valores possveis para os campos Tipo de OAM e Tipo de Funo do payload

da clula OAM so mostrados na Tabela 10.1. O campo especfico, mostrado na
figura, transporta informaes relativas a cada funo OAM. O campo Cyclic
Redundancy Check (CRC) utilizado para a deteco de erros no payload desta
clula.
Tipo de Clula OAM
Gerenciamento de Falha
Gerenciamento de Desempenho
Ativao/Desativao
Valor
Tipo de Funo OAM
0001 Alarm Information Signal
Far-End Receive Failure
OAM cell loopback
Continuity Check
0010 Forward Monitoring
Backward Monitoring
Monitoring/Reporting
1000 Performance Monitoring
Continuity Check
Valor
0000
0001
0010
0100
0000
0001
0010
0000
0001
Tabela 10.1: Campos das Clula OAM

Os fluxos F4 e F5 podem ser aplicados tanto a nvel de conexo fim-a-fim quanto
a nvel de segmento de conexo. No caso do fluxo F4, sua identificao feita
atravs da aplicao de valores de VCI 3 e 4 para conexes fim-a-fim e segmentos
de conexes, respectivamente. O fluxo F5 possui os mesmos valores de VPI/VCI
das clulas de usurios, sendo identificado pelos valores do campo PTI (Payload
Type Identifier) 101 e 100 para conexes fim-a-fim e segmentos de conexes,
respectivamente.
O funcionamento dos fluxos F4 e F5 seguem algumas regras, que dependem dos
componentes de uma conexo, os quais podem ser: ponto de conexo, n terminal
ou n intermedirio. Um ponto de conexo representado pelo equipamento onde
as conexes so solicitadas (Ex. Estao de Trabalho). Chamamos de ns
terminais os equipamentos comutadores aos quais os dois pontos de conexo esto
diretamente ligados. Um n intermedirio um equipamento comutador
localizado entre ns terminais ao longo da conexo. A Figura 10.3 ilustra os
conceitos de ponto de conexo, n terminal e n intermedirio.
120
N Terminal
Ponto de
Conexo
N Intermedirio
N Terminal
N Intermedirio
Ponto de
Conexo
Figura 10.3: Pontos de Conexo, Ns Terminais e Ns Intermedirios

Assim, a aplicao dos fluxos F4 e F5 em uma rede ATM controlada pelas
seguintes regras:
1. Os fluxos OAM so finalizados nos ns terminais ou nos ns intermedirios
das bordas de segmentos de uma conexo (VC ou VP). Cada fluxo
bidirecional.
2. As clulas OAM devem seguir o mesmo caminho fsico de ns intermedirios
nas duas direes.
3. Os ns intermedirios podem inspecionar as clulas OAM que chegam, ou
inserir novas clulas OAM, mas no podem terminar um fluxo ATM.
4. O controle das clulas OAM deve se certificar de que um fluxo OAM foi
propriamente terminado.
10.1. OAM para o Gerenciamento de Falha

As clulas OAM so utilizadas na funo de Gerenciamento de Falhas, mais
especificamente para os Mecanismos de Indicao de Falhas e Localizao e
Diagnstico de Falhas.
Os Mecanismos de Indicao de Falhas tm como funo propagar elementos
de rede ou a toda a rede a existncia de problemas, sejam estes da camada Fsica
ou ATM.
Existem mecanismos especficos de indicao de alarmes para VC e VP em redes
ATM. So eles:
121
Sinais de Indicao de Alarmes (AIS - Alarm Indication Signals)

Os VP-AIS e VC-AIS so gerados por um n que detectou algum problema
em ns anteriores, com a funo de sinalizar o problema para os ns seguintes.
Estes sinais so propagados atravs de clulas OAM (Operation and
Mantainance) do tipo de Gerenciamento Falhas, que contm a semntica do
sinal AIS em um de seus campos.
Indicaes de Defeito Remoto (RDI - Remote Defect Indication)21

Os alarmes do tipo VP-RDI e VC-RDI so gerados por um dos ns terminais
conexo virtual defeituosa, com a funo de notificar o problema aos ns
seguintes. Estes sinais so propagados atravs de clulas OAM do tipo de
Gerenciamento Falhas, que contm a semntica do sinal AIS.
Uma falha de VPC na camada ATM verificada quando da recepo de uma

notificao a partir da camada Fsica ou a partir de algum elemento de rede. O
procedimento de gerao de notificaes varia, dependendo de onde o sinal
percebido. Uma notificao pode ser detectada nos ns intermedirio, de origem
ou de destino da conexo.
Quando uma falha percebida em um n intermedirio da conexo, clulas AIS
so geradas periodicamente (uma clula por segundo) e enviadas aos ns
posteriores, notificando-os do problema. Clulas AIS so geradas at que a falha
no esteja mais sendo percebida, o que acontece quando clulas VP/VC-AIS no
so percebidas em um perodo de 3 segundos ou quando uma clula vlida (i.e.
clula de usurio ou clula de continuidade) for percebida. A notificao de falha
chega, ento, ao n destino, o qual gera clulas RDI aos ns anteriores at a fonte.
A gerao de clulas RDI pelo destino da conexo persiste enquanto o estado AIS
persistir. Para o n de origem, a falha persiste enquanto clulas RDI advindas do
destino continuarem a ser recebidas. A Figura 10.4 exemplifica a gerao de
clulas OAM AIS e RDI.
21 Por alguns autores tambm conhecido como FERF (Far-End Receive

Failure).
122
Conexo Virtual
Defeito
N Terminal
N
Intermedirio
N
Intermedirio
N Terminal
AIS
RDI
Figura 10.4: Indicao de Alarmes

Se a falha percebida no n de origem da conexo, o procedimento o mesmo,
exceto pelo fato de as clulas RDI que chegam ao n de origem so ignorados.
Quando a falha percebida no n de destino da conexo, o procedimento o
mesmo que no procedimento anterior, variando apenas no fato de que clulas AIS
no so geradas.
Falhas de VCC podem ser detectadas pela camada ATM a partir da camada Fsica
ou do n destino da conexo. Diferentemente das conexes VPC, nem todas as
conexes VCC permitem a gerao de alarmes. A caracterstica de suporte a
alarmes deve ser definida durante a conexo.
Aps identificado um problema, o procedimento padro : (1) isolar o ponto
especfico de falha, de modo a tentar no comprometer o funcionamento da rede
como um todo; (2) realizar testes e diagnsticos, com a funo de identificar o
problema; (3) disparar mecanismos para correo do problema. Relatrios devem
ser gerados de forma a documentar toda a operao.
Os mecanismos de diagnstico interno de cada elemento de rede dependente de
fabricante, enquanto os mtodos de diagnstico de conexes VCC e VPC so
genricos. Estes mecanismos so baseados em loopback de clulas OAM.
O mecanismo de loopback OAM pode ser utilizado para verificar conectividade,
isolar falhas e realizar testes de conformidade de servio. Estes testes so
123
realizados pela insero de clulas OAM especiais para lookback de

Gerenciamento de Falhas. Clulas deste tipo so lanadas na rede a partir de um
ponto arbitrrio, contendo instrues para cada ns intermedirio enviar
mensagem de recebimento da clula. Desta forma, possvel no s testar
conectividade, mas tambm verificar o tempo de resposta do teste, atravs de
clulas time-stamp.
Loopback
OAM
Loopback
OAM
T1
N1
ACK
N2
N3
T2
ACK
Defeito
Figura 10.5: Clulas OAM Lookback

Na Figura 10.5, o n terminal T1 gera clula loopback com destino ao n terminal
T2. Ao longo do caminho, cada n intermedirio emite uma clula de
reconhecimento (ACK) do recebimento da clula loopback. Como o defeito se
encontra entre os ns intermedirios N2 e N3, a clula no pode ser propagada
para os ns N3 e T2, que por sua vez no emitem o ACK do recebimento de
loopback OAM. Desta forma o defeito localizado.
Vrias aplicaes para loopback so especificadas pela ITU-T, em I.610 [33].
Entre elas esto:
Loopback Fim-a-Fim
Clulas OAM loopback so geradas em um dos ns terminais com destino
outra extremidade da conexo.
Loopback de Linha de Acesso

Clulas loopback para segmentos de conexo so produzidos por um cliente
de uma concessionria. O primeiro equipamento da rede pblica deve
responder clula. Tem como funo principal testar o acesso de um cliente
rede pblica, atravs de uma concessionria.
124
Interdomain Loopback
Clulas loopback so para segmentos de conexes so lanadas rede a partir
de um domnio e retornado pelo primeiro equipamento de comutao do
domnio destino da conexo.
Network-to-End Loopback
Clulas OAM loopback so geradas em um domnio e respondidas pelo n
terminal da conexo em outro domnio.
Intradomain Loopback
Clulas loopback para segmentos de conexo so lanadas por um n terminal
de conexo ou de segmento de conexo e retornado por um n intermedirio
da conexo.
Clulas OAM de Continuidade de VPC/VCC so enviadas por um dos ns

terminais de uma conexo virtual, caso no haja a recepo de clulas de usurios
por um determinado intervalo de tempo e no h declarao de um estado de
defeito, isto , fatos que indicam que a conexo continua ativa.
10.2. OAM para o Gerenciamento de Desempenho

Para o Monitoramento de Desempenho de VPCs e VCCs, funes so definidas
especificamente para o controle de desempenho de conexes, tanto a nvel de
segmentos de conexes quanto a conexes fim-a-fim. A implementao desse
subsistema compreende a definio dos mecanismos de gerao de clulas OAM
especficas para o gerenciamento de performance de conexes, a definio dos
parmetros de monitoramento de conexes e a ativao/desativao de
procedimentos de monitoramento.
As clulas OAM de Gerenciamento de Desempenho (OAM-GD) de uma conexo
contm informaes acerca de um bloco de clulas geradas pela aplicao de
usurio. As clulas de Gerenciamento de Desempenho ou outras clulas OAM no
fazem parte desses blocos. Portanto, a cada srie de clulas de dados geradas em
nmero representativo a um bloco, uma clula OAM-GD de conexo gerada,
contendo informaes sobre o bloco de clulas transmitidos anteriormente. O
nmero de clulas que compem um bloco pode variar entre os valores 128, 256,
512 e 1024. A escolha do tamanho do bloco , portanto, parametrizada pela
relao entre a severidade do monitoramento e a quantidade de trfego extra
125
submetido rede. Quanto maior o tamanho do bloco, menor o nmero de clulas

OAM-GD (trfego extra) submetido rede, e menor a severidade do
monitoramento. A Figura 10.6 exemplifica o processo de gerao de clulas
OAM-GD.
Clula
OAM-GD
...
Bloco
128, 256, 512 ou 1024 clulas
Clula
OAM-GD
...
...
Figura 10.6: Gerao de Clulas OAM-GD

Apesar de no haver nenhuma recomendao que formalize o uso de clulas
OAM para o Monitoramento de Desempenho em redes de comutao de clulas, a
definio dos parmetros para o Monitoramento de Desempenho recomendados
pela ITU-T em I.356 [34] so adotados. Estes parmetros so:
Errored Blocks
Contagem do nmero de blocos onde erros foram detectados. utilizado para
medir a qualidade de transmisso de dados da rede como um todo, tentando
detectar suas deterioraes de desempenho.
Severely Errored Blocks

Medio da ocorrncia de blocos severamente afetados por erros, detectados
atravs da extrapolao de um limite especificado de ocorrncia de blocos
com erro.
Lost User Information Cells

Ocorrncia de perda de clulas contendo informaes de aplicaes de
usurios. No pode, porm, distinguir o motivo da perda de clulas, i.e., se
ocorreu erro no cabealho da clula, no cabealho a nvel de camada ATM,
descarte devido a parmetros de UPC (Usage Parameter Control) ou estouro
de buffer.
126
Misinserted User Information Cells

Contagem de inseres indevidas de clulas em blocos, que podem ter sido
causadas por erros de roteamento.
Excessive Cell Transfer Delay Ocurrences

Ocorrncia de sucessivas ocorrncias anormais no que diz respeito ao tempo
de transmisso de clulas.
O Monitoramento de Desempenho de conexes pode ser ativado ou desativado a

partir do sistema de gerenciamento ou do usurio final. Para o estabelecimento ou
liberao do monitoramento de performance, clulas so lanadas na ao longo da
rede, entre os pontos finais da conexo, de forma a comunicar os ns
intermedirios da ativao ou desativao do monitoramento de desempenho. Este
procedimento tem como funes coordenar e sincronizar o incio e fim da
transmisso e recepo de clulas OAM-GD, alm de estabelecer o tamanho de
bloco e as direes de transmisso para o incio ou final de monitoramento.
127
Captulo 11
11. Gerenciamento de Trfego
O Gerenciamento de Trfego tem como funo monitorar e controlar o fluxo de

clulas de uma rede ATM, de modo a evitar ou reagir a congestionamentos,
mantendo a sincronia entre a transmisso e a recepo de clulas em conexes. As
duas principais tarefas para a gerncia de trfego so, ento, controle de fluxo e
controle de congestionamento.
O controle de fluxo lida com a sincronizao entre fonte e receptor de trfego, de
modo que a gerao de clulas na fonte seja compatvel com a disponibilidade de
recepo na outra ponta da conexo.
O controle de congestionamentos visa evitar, reagir ou minimizar os efeitos de
situaes de perda excessiva de clulas, como um congestionamento. Um
congestionamento observado quando h aumento excessivo na demanda de
largura de banda, provocando perda de clulas devido limitao de largura de
banda nos links de sada. Outro problema que pode ocasionar perda de clulas o
estouro de ocupao dos buffers dos equipamentos comutadores.
A probabilidade de ocorrncia de congestionamentos depende diretamente do tipo
de multiplexao utilizada: determinstica ou estatstica. Na multiplexao
determinstica, a cada conexo est alocada a sua taxa de pico. Desta forma, a taxa
de utilizao do link dificilmente superar a sua capacidade. A multiplexao
estatstica permite que o somatrio das taxas de pico das conexes ultrapassem a
capacidade do link, mantendo, entretanto, a probabilidade de um
129
congestionamento abaixo de um certo limiar . Apesar da multiplexao

determinstica praticamente impossibilitar situaes de congestionamento, h
subutilizao dos recursos, uma vez que as conexes nem sempre transmitem
taxa de pico. No caso de conexes do tipo CBR, entretanto, a multiplexao
determinstica no proporciona subutilizao de recursos, pois a taxa de pico
dessas conexes coincidem com suas taxas mdias de transmisso.
A complexidade da tarefa do controle de congestionamento se deve
principalmente s seguintes dificuldades:
Diferena de taxa de transmisso entre diferentes fontes;

Uma nica fonte pode gerar vrios tipos de trfego (voz, dados, vdeo) com
diferentes caractersticas;
Necessidade de lidar adicionalmente com a variao do atraso das clulas,
atraso mximo e desvios estatsticos;
Servios possuem diferentes parmetros de Qualidade de Servio;
As caractersticas de trfego de diversos tipos de servios ainda no esto bem
especificados;
A alta velocidade de transmisso limita o tempo disponvel para o
processamento nos ns intermedirios.
Diversos mecanismos esto sendo definidos para o controle de congestionamento

em redes ATM. Dentre eles, esto:
Controle de Admisso de Conexes (CAC22);
Controle de Parmetros de Uso e de Rede (UPC/NPC23);
Tcnicas de Notificao de Ns Terminais;
Descarte Seletivo;
Modelagem de Trfego;
Descarte de Quadros;
Controle de Fluxo ABR.
1.
2.
3.
4.
5.
6.
7.
Cada mecanismo ser descrito a seguir.
22
23
CAC Connection Admission Control

UPC Usage Parameter Control e NPC Usage Parameter Control
130
11.1. Controle de Admisso de Conexes (CAC)

O Controle de Admisso de Conexes um conjunto de aes tomadas pela rede
durante o estabelecimento ou renegociao de uma conexo, com o intuito de
determinar se a rede pode ou no aceitar esta conexo. Esta deciso dever ser
tomada de forma a somente aceitar novas conexes se a QoS das conexes j
ativas no for afetada. O mecanismo de controle de admisso de novas conexes
est ilustrado na Figura 11.1.
Comut.
ATM
Comutador
ATM
Link Fsico
QoS
CAC
Pedidos
de
Conexo
Controle
de
Trfego
Figura 11.1: Funcionamento do CAC
As informaes utilizadas pelo controle de conexes so as descries de suas

caractersticas de trfego e os parmetros de QoS desejados (se aplicvel). Para
uma conexo ser aceita, deve-se haver uma avaliao sobre o impacto desta
conexo sobre a rede, atravs de uma projeo de seu comportamento.
131
Dentre os algoritmos de controle de admisso mais conhecidos, est o

Mecanismo de Aproximao Gaussiana, que ser descrito a seguir, como
exemplo.
Mecanismo de Aproximao Gaussiana
Cada conexo caracterizada pela sua taxa mdia de transmisso e seu desvio
padro. Uma aproximao ao modelo estatstico de Gauss feito. A finalidade
determinar o total de largura de banda alocada por todas as conexes que esto
sendo multiplexadas, de modo que a probabilidade deste total de largura de banda
alocada ultrapassar a capacidade do link esteja abaixo de um dado valor . O
problema desse mecanismo que todas as conexes so tratadas como se fossem
de mesma natureza. Alm disso, s pode haver a aproximao de todas as
conexes agregadas distribuio Gaussiana se cada conexo individualmente se
aproximar a este modelo.
11.2. Controle de Parmetros de Uso e de Rede (UPC/NPC)

Uma vez estabelecida uma conexo, de acordo com os parmetros declarados em
seu contrato de trfego, necessrio se certificar de que este contrato seja
devidamente cumprido. Esta a tarefa do Controle de Parmetros de Uso (UPC) e
do Controle de Parmetros de Rede (NPC).
O Controle de Parmetros de Uso lida com o policiamento de trfego nas
interfaces UNI da rede, enquanto o Controle de Parmetros de Rede atua sobre o
trfego nas interfaces NNI.
O Controle de Parmetros de Uso e de Rede se utilizam de funes especficas
prara a deteco de anormalidades de trfego. Estas funes incluem:
132
Checagem da validade de valores de VPI e VCI;

Monitoramento do volume de trfego que entra na rede a partir de todas as
conexes virtuais ativas, de forma a assegurar que os parmetros do contrato
de trfego esto sendo cumpridos;
Monitoramento do total de trfego aceito nos links.
A partir da utilizao destas funes, pode-se detectar conexes que

desrespeitaram seus contratos de trfego. O sistema de UPC/NPC deve, ento,
atuar sobre o trfego destas conexes. Esta atuao dever garantir ou obrigar o
cumprimento dos parmetros estabelecidos.
Neste caso, as aes que podem ser tomadas pelo sistema de UPC/NPC incluem:
Descarte de clulas excedentes;

Neste caso, todas as clulas que no esto em conformidade com os limites
fixados no contrato de trfego sero descartadas.
Atraso na transferncia de clulas;

Antes de acessar a rede, o trfego da fonte violadora submetido a uma fila,
que adapta a sua taxa de sada taxa de transmisso acordada em seu contrato
de trfego.
Reduo de prioridade de clulas excedentes;

Em caso de congestionamento nos links de sada, as clulas marcadas de baixa
prioridade sero imediatamente descartadas. A diminuio da prioridade das
clulas excedentes feita atravs do campo CLP no cabealho de cada clula.
Controle de feedback fonte.

Quando um contrato de trfego comear a ser violado, o sistema UPC/NPC
dever comunicar esta desconformidade sua fonte.
A maioria dos esquemas definidos para o controle de parmetros se utilizam das

informaes de taxas mdia, taxa de pico e durao do perodo ativo para realizar
o policiamento sobre conexes. De posse dessas informaes, algoritmos como
Leaky Bucket monitoram e controlam o comportamento de conexes na rede. O
algoritmo Leaky Bucket ser descrito a seguir.
11.2.1.
Leaky Bucket
A idia bsica deste algoritmo, que foi posteriormente estendida, a utilizao de

tokens (fichas) em um reservatrio (token pool), caracterizado por sua capacidade,
e uma fonte de tokens, que gera fichas a uma taxa constante.
133
Cada clula, antes de ter acesso rede, dever consumir um token do reservatrio.
Se o token pool estiver vazio, as clulas que solicitarem token ou sero
descartadas ou sero marcadas com baixa prioridade em caso de
congestionamento.
A Figura 11.2 mostra o esquema Leaky Bucket mais simplificado, onde clulas
que no disponham de tokens so descartadas. Algumas implementaes dispem
de um buffer para armazenar um determinado nmero de clulas enquanto novos
tokens so gerados. Outras implementaes, ao invs de descartar clulas sem
token disponvel, marcam-nas como de baixa prioridade no caso de descarte.
Descarte
de Clulas
Chegada
de
Clulas
Leaky
Bucket
Sada
de
Clulas
Rede
ATM
Token
Pool
Gerador
de Tokens
Figura 11.2: Algoritmo Leaky Bucket

O esquema Leaky Bucket pode realizar policiamento de trfego tanto a nvel de
VC quanto a nvel de VP. Para uma concessionria, por exemplo, mais
interessante o policiamento de trfego a nvel de VP, visto que cada cliente visto
como um conjunto de valores agregados de suas conexes VC.
Os parmetros do Leaky Bucket determinam a tolerncia do policiamento de
trfego. O tamanho do token pool determina o tamanho mximo de rajada e a taxa
de gerao, a tolerncia a atrasos e as variaes de atraso; enquanto a taxa de
gerao de novos tokens controla a taxa mdia ou de pico da conexo.
134
Este esquema foi escolhido e recomendado tanto pela ATM Forum quanto pela
ITU-T para o policiamento de trfego das redes ATM.
11.2.2.
Tcnicas de Janelas
Outra tcnica de policiamento de trfego a limitao do nmero de clulas

transmitidas em um certo intervalo fixo de tempo, denominado janela. Portanto,
aps a transmisso de seu nmero limite de clulas por janela, as demais clulas
sero descartadas ou marcadas de baixa prioridade, at que a janela seja
finalizada.
Algumas variaes deste algoritmo sugerem janelas no consecutivas ou tamanho
de janela varivel como formas de aumentar o desempenho e reduzir a
complexidade de processamento.
11.3. Tcnicas de Notificao de Ns Terminais

Uma vez detectado um congestionamento em um n intermedirio, necessrio
que os ns terminais (fonte e destino) sejam notificados, de modo a reagir ao
problema. Trs tcnicas principais foram propostas para a notificao de
congestionamento. So elas:
Estimation by the End Nodes

Explicit Backward Congestion Indication
Explicit Forward Congestion Indication
11.3.1.
Estimation by the End Nodes
Nesta tcnica, uma fonte de trfego gera clulas especiais com registro de tempo
(time stamp), chamadas probe cells. Estas clulas so repassadas atravs da rede
pelos ns intermedirios como clulas normais. Somente no n terminal de
destino estas clulas so processadas. Ao chegar ao destino, as probe cells so
utilizadas para estimar o atraso de transmisso entre fonte e destino. Uma vez
detectado um possvel congestionamento, a fonte dever ser notificada.
O principal problema desta tcnica a necessidade de submisso de trfego extra
na rede. Apesar do custo de transmisso de uma clula em uma conexo no ser
considervel, a existncia de milhares de conexes pode causar desperdcio de
135
recursos. Alm disso, esta tcnica no localiza o congestionamento. Apenas

notifica a possibilidade de sua existncia.
Esta tcnica no foi adotada pelos rgos de padronizao das redes RDSI-FL,
sendo deixada como opo para os provedores de servios de rede.
11.3.2.
Explicit Backward Congestion Indication
Nesta tcnica, cada n intermedirio monitora as filas de seus links. Quando uma
dessas filas ultrapassa um limite de ocupao especificado, clulas especiais so
enviadas a todas as fontes de trfego que utilizam este n nas rotas de suas
conexes. Estas clulas especiais sero mais detalhadamente descritas na Seo
11.7. Os campos dessas clulas pode ser utilizado para carregar informaes
acerca do n congestionado. Uma vez recebida a notificao de congestionamento
pelo n terminal, o ponto de conexo deve reduzir ou suspender a submisso de
trfego rede at que a situao se normalize.
Apesar de sua eficcia, este mtodo no tem sido adotado pelos rgos de
padronizao, devido necessidade de processamento extra de clulas nos ns
intermedirios. Alm disso, se uma conexo for configurada para um s sentido, o
n congestionado dever estabelecer uma nova conexo para que a notificao
seja entregue ao ponto de conexo.
11.3.3.
Explicit Forward Congestion Indication
Nesta tcnica, um n congestionado ou em iminncia de congestionamento dever

comunicar os ns seguintes deste problema. Esta notificao feita atravs da
ativao do bit EFCI constante no cabealho, definido pela ITU-T. A recepo por
parte do ponto de conexo de clulas com o bit EFCI marcado indicam que h um
n em congestionamento ao longo do caminho da conexo. Entretanto, no h
como saber em que ponto exatamente a rede est congestionada.
Devido ao atraso pelo tempo em que as clulas chegam ao destino, possvel que
o n que iniciou a notificao a notificao no mais esteja congestionado.
Portanto, o destino no deve reagir imediatamente a uma notificao de
congestionamento EFCI. Em vez disso, o destino deve coletar informaes
estatsticas que possam ratificar a situao de congestionamento contnuo. Se o
congestionamento for realmente observado, o destino dever enviar uma
136
notificao de congestionamento fonte de trfego, a qual dever reduzir ou

suspender a submisso de trfego desta conexo rede.
Esta tcnica foi sugerida pela ATM Forum como mecanismo opcional para
gerenciamento de trfego, em sua especificao [27].
11.4. Descarte Seletivo

Como foi dito anteriormente, o gerenciamento de trfego visa controlar o fluxo de
clulas por links e buffers nas entidades que compem esta rede. Entretanto, a
necessidade de maximizar a utilizao dos recursos expe a rede ao perigo de
congestionamento e de buffer overflows.
No caso de um congestionamento, o procedimento o descarte de clulas
excedentes. Porm, devido possibilidade de distino de prioridade entre clulas
(atravs do bit de cabealho CLP), aconselhvel a distino entre clulas no caso
de necessidade de descarte.
Os mecanismos de descarte seletivo so formas de descarte de clulas que seguem
o critrio de que clulas de alta prioridade devem ter preferncia na ocupao de
buffers e de links em caso de congestionamento.
Em caso especial, se o nmero de clulas descartadas influir diretamente no
requisito de CLR (Cell Loss Ratio) de uma determinada conexo, o controle de
descarte dever realizar algum tipo de compensao de forma a respeitar o
requisito de CLR desta conexo.
Mecanismos especiais para o descarte seletivo de clulas foram desenvolvidos.
Dois desses mecanismos sero descritos a seguir: Push-Out e Threshold.
11.4.1.
Push-Out
Neste mecanismo, clulas de alta e baixa prioridades so submetidas rede, com a

condio de haver espao disponvel nos buffers dos ns intermedirios. Uma
clula de baixa prioridade ser descartada se chegar a um n cujo buffer esteja
cheio. Caso uma clula de alta prioridade chegue a um n e no houver clulas de
baixa prioridade no buffer cheio, esta clula ser descartada. Mas se houver clula
137
de baixa prioridade no buffer, esta ser substituda pela clula de alta prioridade
que chegar. O mecanismo Push-Out ilustrado na Figura 11.3.
(A)
(B)
Descarte
H L L H H
(C)
Descarte
H H H H H
H
L
H H H
Descarte
Figura 11.3: Push-Out

O principal problema deste esquema a complexidade de implementao. Apesar
da substituio de clulas parecer uma tarefa simples, necessrio que se
mantenha a ordem de seqncia das clulas. Este fato torna este esquema mais
complexo.
11.4.2.
Threshold
Neste caso, utiliza-se se um valor limite (threshold) inferior ao tamanho do buffer

para controlar a sua ocupao entre clulas de alta e baixa prioridades.
Clulas de alta e baixa prioridades sero aceitas no buffer at que a sua
ocupaolimite seja alcanada. A partir da, clulas de baixa prioridade sero
descartadas, at que a ocupao do buffer esteja abaixo do seu valor limite.
O algoritmo Threshold exemplificado na Figura 11.4.
O principal desafio desta tcnica o clculo do valor limite. Se este valor for
muito alto, o desempenho das clulas de alta prioridade ser afetado, visto que no
haver muito espao reservado para estas clulas. Por outro lado, se o valor limite
for muito baixo, clulas de baixa prioridade sero descartadas desnecessariamente,
uma vez comearo a ser descartadas prematuramente, ainda havendo espao
relativamente suficiente para a operao normal.
138
L H H L
Threshold
H L H H L
Threshold
L
Descarte
L H L H H L
Threshold
L H L H H L
Threshold
L
Descarte
H L H L H H L
(Fila Cheia)
Threshold
Figura 11.4: Algoritmo Threshold
Embora a determinao do valor limite dependa das caractersticas do trfego de

ambas as seqncias de clulas (alta e baixa prioridades), nfase maior dada s
caractersticas de trfego das clulas de alta prioridade, de forma a garantir sua
QoS. Portanto, aconselhvel o reajuste do parmetro de valor limite quando as
caractersticas de trfego mudam.
139
Comparativamente, ambas as tcnicas de descarte seletivo (Push-Out e Threshold)

apresentam praticamente o mesmo comportamento de perda de clulas, se o valor
limite da implementao Threshold estiver adequada ao seu tipo de trfego.
Porm, a tcnica Threshold vem recebendo preferncia por sua maior
simplicidade de implementao, uma vez que o descarte de clulas nesta tcnica
no altera a ordem de seqncia das clulas no buffer.
11.5. Modelagem de Trfego

A modelagem de trfego um mecanismo que altera as caractersticas de trfego
originais de uma seqncia de clulas em uma conexo, de forma a alcanar uma
maior eficincia na rede, despeitando a QoS da conexo, ou assegurar o
cumprimento de seu contrato de trfego.
De acordo com as informaes de taxa de pico, taxa mdia e durao de perodo
ativo, o limite de taxa de pico remodelada a um valor mais baixo. Desta forma,
uma rajada seria remodelada de forma a reduzir a taxa de pico e,
consequentemente, aumentar a durao do perodo ativo. Isto feito atravs do
uso de filas de sada. Clulas de uma conexo so armazenadas em uma fila de
sada, antes de serem submetidas redes. A file, por sua vez, libera as clulas
rede a uma taxa menor do que a taxa de pico da conexo, reduzindo a taxa de pico
e aumentando o perodo ativo.
Entretanto, a modelagem de trfego dever levar em conta a taxa mdia de
transmisso de modo a no desestabilizar a conexo. Portanto, o clculo da nova
taxa de pico dever seguir critrios que respeitem a taxa mdia de transmisso de
uma fonte.
Por exemplo, considere-se uma conexo VBR caracterizada por perodos ativos de
transmisso a taxa de pico e nenhum trfego no perodo de silncio. Esta conexo
tem taxa de pico de 16 Mbps e perodos ativo e de silncio de 0,5 e 1,5 ms,
respectivamente. Uma modelagem de trfego que reduz a taxa de pico para 8
Mbps pode ser feita, aumentando o perodo ativo para 1 ms. Esta modelagem
apresentada na Figura 11.5.
O principal problema que a modelagem de trfego influi negativamente em
conexes sensveis a atrasos. Isto ocorre porque as clulas so sujeitas a uma
reteno na fila de sada, e so liberadas rede a uma taxa menor do que a taxa
140
real da conexo. Portanto, a eficincia da modelagem de trfego depende

diretamente da tolerncia da conexo a atrasos.
141
Aps a Modelagem
16
14
12
10
8
6
4
2
0
Largura de Banda (Mbps)
Largura de Banda (Mbps)
Antes da Modelagem
0,5
1,5
2,5
3,5
16
14
12
10
8
6
4
2
0
0
0,5
1,5
2,5
3,5
Tempo (ms)
Tempo (ms)
Figura 11.5: Modelagem de Trfego
11.6. Descarte de Quadros

Se um elemento de rede necessitar descartar clulas, em muitos casos o descarte a
nvel de quadros pode ser mais eficaz. Um quadro representa a Unidade de Dados
de Protocolo (PDU) da Camada de Adaptao (AAL).
O descarte a nvel de quadro pode ser feito sempre que for possvel a identificao
das delimitaes de um quadro, atravs da anlise de sua Unidade de Dados de
Servio (SDU). Entretanto, o descarte de quadros s poder ser feito se a conexo
estiver habilitada a esta ao, seja definido no momento do estabelecimento da
conexo ou atravs de sinalizao.
Os mecanismos de deciso sobre o descarte de quadros so dependentes da
implementao desta tcnica.
142
11.7. Controle de Fluxo do Servio ABR

Em conexes ABR, a fonte de trfego se adapta s mudanas das condies da
rede. Para isto, informaes acerca do estado da rede, como largura de banda
disponvel e estado de congestionamento, devem chegar fonte de trfego. Esta
comunicao feita atravs de clulas de gerenciamento de recursos (RM-cells).
Clulas RM podem ser produzidas tanto nos ns terminais quanto nos ns
intermedirios da conexo ABR. A Tabela 11.1 mostra a estrutura de uma clula
RM.
Campo
Cabealho
ID
DIR
BN
CI
NI
RA
Reservado
ER
CCR
MCR
QL
SN
Reservado
Reservado
CRC-10
Octeto
1-5
6
7
7
7
7
7
7
8-9
10-11
12-13
11-17
18-21
22-51
52
52
53
Bit
todos
todos
8
7
6
5
4
3-1
todos
todos
todos
todos
todos
todos
8-3
2-1
todos
Descrio
Cabealho de Clula ATM
Identificador de Protocolo
Direo
Clula BECN
Indicao de Congestionamento
No Increase
Request / Acknowledge
Reservado
Estabelecimento de Taxa de Clulas
Taxa de Clulas Corrente
Taxa de Clulas Mnima
Tamanho da Fila
Nmero de Seqncia
Reservado
Reservado
Cyclic Redundancy Check
Tabela 11.1: Estrutura da Clula RM

possvel tambm a segmentao da conexo ABR, dividindo a responsabilidade
do gerenciamento de recursos (Figura 11.6).
O fluxo de clulas RM podem ter dois sentidos: fonte-destino (forward) e destinofonte (backward). Em uma conexo, ambos os pontos de conexo fazem papel de
fonte e destino, uma vez que ambos enviam e recebem dados.
143
Fluxo Forward
D
DV
Segmento
F: Fonte
D: Destino
FV
DV
Segmento
FV
Segmento
FV: Fonte Virtual

DV: Destino Virtual
Figura 11.6: Segmentao de Conexo ABR

No cabealho das clulas RM, o valor de PTI=1102 identifica clulas RM para
VCCs e, adicionalmente, VCI=6 para VPCs.
Os campos do payload das clulas RM so descritos a seguir:
ID: Protocol Identifier
O ID do protocolo identifica o servio que est utilizando a clula RM. A ITU-T
definiu o valor ID=1 para o servio ABR.
Message Type Field

! DIR: Este campo identifica a que direo de fluxo de dados a clula est
associada. Uma clula RM de fluxo forward identificada pelo DIR=0,
enquanto o fluxo backward identificado por DIR=1.
! BN: O bit BN identifica se a clula RM de BECN (Backward Explicit
Congestion Notification), i.e., no foi gerada na fonte. O valor BN=0
indica que a clula foi gerada na fonte, enquanto BN=1 indica uma clula
BECN, gerada nos ns intermedirios ou no destino.
! CI: Este bit permite a um elemento de rede indicar se h um congestionamento

na rede. Quando uma fonte percebe uma clula com CI=1, o valor de ACR
(Avaliable Cell Rate) reduzido.
144
! NI: O bit No Increase usado para evitar que uma fonte de trfego ABR
aumente o seu valor ACR.
! RA: O bit Request / Acknowledge identifica se a clula representa uma
solicitao em si ou apenas o reconhecimento de recebimento de uma
solicitao feita anteriormente. Este bit no utilizado pelo servio ABR.
! ER: O campo Explicit Rate utilizado para definir um valor limite para o
ACR da fonte. Para cada clula RM, o campo ER definido pela fonte em um
determinado valor (como PCR, por exemplo). Este valor pode ser reduzido por
algum elemento de rede a um valor sustentvel.
! CCR: O campo Current Cell Rate definido pela fonte como o valor de ACR
vigente na conexo. Este campo til para que elementos de rede possam
fazer a alocao de largura de banda entre as suas conexes.
! MCR: O campo Minimum Cell Rate especifica o valor mnimo de ACR
requisitado para esta conexo. tambm til para que elementos de rede
possam alocar largura de banda a suas conexes.
! QL: O campo Queue Lenght no utilizado pelo servio ABR.
! SN: O campo Sequence Number no utilizado pelo servio ABR.
! CRC-10: O campo Cyclic Redundancy Check utilizado para a deteco de
erros no corpo da clula RM. Utiliza o mesmo processo de clculo das clulas
OAM.
145
Anexos
147
Anexo A
MIBs
Nesse Anexo, analisaremos mais algumas MIBs SNMP aplicadas ao ATM. A
MIB Suplementar uma extenso da AToM MIB, apresentada no captulo 8. J a
DXI MIB modela o funcionamento da DXI para permitir seu gerenciamento. De
modo anlogo, a MIB apresentada na seo A.3 possui informaes de erro e
status para a interface PNNI. Na seo A.4, mostramos a aplicao da MIB-II em
interfaces ATM e AAL5.
A.1. MIB Suplementar

Esta especificao, que um Internet Draft, foi proposta com o objetivo de
auxiliar a AToM MIB no gerenciamento de redes ATM. Este documento prov
extenses para o suporte ao gerenciamento de SVCs (Switched Virtual Circuit), o
que no oferecido pela AToM MIB, alm de introduzir conceitos novos como
Tneis VP.
Na figura A.1 a seguir apresentada a estrutura desta MIB e logo aps
detalhado o seu contedo.
149
Sinalizao
Inte rface
Sinalizao
Suporte SVCs
(UNI ATM)
De s critore s
Sinalizao
Cruzamento
Conexes
VP/VC - SVC
Endereos
Administrativos
M IB Suple me ntar
IETF Draft
Endereamento
VPI/VCI
End. ATM
End. ATM
VPI/VCI
Configuras
Extras
Es tats ticas
"LINKS"
Virtuais
Portas
Lgicas (VPL)
Informae s
Ge rais (VCL)
Figura A.1: Estrutura da MIB Suplementar
A.1.1. Sinalizao
Este grupo composto de trs tabelas onde a tabela atmSigTable possui
informaes sobre a configurao das entidades de sinalizao,
atmSigSupportTable prov informaes que do suporte ao processo de
sinalizao utilizado para o estabelecimento de SVCs, e atmSigDescrTable que
possui dados sobre a sinalizao das conexes VCCs existentes.
150
Sinalizao numa interface ATM (atmSigTable)

uma extenso da ifTable (do Grupo Interface da MIB-II) ou seja, as interfaces
que suportam sinalizao possuem uma entrada nesta tabela. Portas lgicas
tambm podem se relacionar com esta tabela.
Os atributos mais importantes so divididos nos seguintes grupos:
Tipo da sinalizao: informa o tipo de sinalizao configurado
(atmConfigSigType) e o utilizado (atmActualSigType);
Papel da entidade de sinalizao: informa o papel da entidade de sinalizao
(atmConfSigSide) e o papel realmente sendo desempenhado (atmActualSigSide);
SSCOP: este grupo possui informaes sobre a camada de sinalizao SSCOP,
como: numero de eventos (desconexes, falhas na conexo, etc.) ocorridos nesta
camada
(atmSigSSCOPConEvents),
nmero
de
PDUs
com
erro
(atmSigSSCOPErrPdus);
Falhas no servio: contm informaes sobre falhas que ocorreram quando do
estabelecimento de um SVC, como: time-out em sinalizaes emitidas a partir
da
interface
(atmSigEmittTimerExpires24),
recursos
indisponveis
25
(atmSigDetectUnavailResrcs ), rotas indisponveis (atmSigEmittUnavailRoutes)
, etc.;
Erros de protocolo na camada de sinalizao quando estamos estabelecendo
um SVC. Contm dois atributos que definem o nmero de Restarts recebidos
(atmSigDetectRestarts) e enviados (atmSigEmittRestarts);
Estatsticas: contm dois atributos que informam o nmero de conexes
estabelecidas para SVCs entrando (atmSigInEstabls) na interface relacionada e
para conexes saindo (atmSigOutEstabls) desta interface.
24.
O Emitt existente nesta varivel, relaciona-se com sinalizaes que so

emitidas a partir da interface relacionada.
25. O Detect existente nesta varivel, relaciona-se com sinalizaes que
chegam na interface relacionada.
151
Suporte a SVCs na interface UNI ATM (atmSigSupportTable)

Esta tabela utilizada para auxiliar no isolamento de problemas. Para que se possa
isolar um problema temos que obter informaes sobre quais objetos esto sendo
suportados.
Alguns dos atributos citados abaixo devem existir em comutadores ou redes que
suportam SVCs. Eles indicam se a entidade que iniciou o processo de sinalizao
ou a entidade que recebeu a requisio da sinalizao disponibilizam ou no uma
determinada informao.
atmSigSupportClgPtySubAddr: indica que o sub-endereo da entidade que
requisitou o processo de sinalizao ser transferido at a entidade que recebeu
esta requisio. AtmSigSupportCldPtySubAddr: idem, mas o envio do subendereo feito de maneira inversa, ou seja, da entidade requisitada entidade
requisitante.
atmSigSupportAALInfo: parmetros da camada AAL so enviados pela
entidade que iniciou o processo de sinalizao at a entidade que recebe esta
requisio.
atmSigSupportPerfCarrier: identifica o carrier para o qual chamadas entre
carrier originadas desta interface so roteadas quando informaes sobre a rede
no provida pela entidade requisitante da sinalizao.
Parmetros descritores de sinalizao (atmSigDescrTable)

As informaes contidas nesta tabela so disponibilizadas para a rede no momento
da criao de um novo VCC, ou seja, quando ocorre a negociao de um conjunto
de parmetros entre o usurio e a rede. Informaes adicionais so
disponibilizadas pelas aplicaes RDSI-FL, que alm de fornecerem informaes
sobre a conexo, informam sobre parmetros de contrato de trfego. As
informaes sobre contrato de trfego esto contidas na tabela
atmTrafficDescrParamTable, descrita na seo 8.1.2
Os dados contidos nesta tabela podem ser utilizados pela camada ATM para
garantir a qualidade de servio (QoS) desejada. Os principais atributos so
divididos nos seguintes grupos (atmSigDescrParamTable):
152
AAL: so descritos aqui o tipo de AAL (AalType), o modo da AAL

(AalMode) e a sub-camada de convergncia (ex. SSCOP)( AalSscsType) utilizada
pela conexo;
Camadas acima da AAL: informa-se o tipo da camada sendo utilizada (Ex.
ISO, proprietria) (BhliType) e dados adicionais (BhliInfo) dependendo do seu
tipo;
Broadband Bearer Capability (BBC): atmSigDescrParamBbcConConf;
Camadas abaixo da AAL: contm informaes sobre os protocolos de nvel 2

(BlliLayer2), nvel 3 (BlliLayer3), tamanho default do pacote (BlliPktSize),
identificador do SNAP (BlliSnapId) e codificao OUI/PID (BlliOuiPid).
A.1.2. Cruzamento de Conexes

Cruzamento de conexes VP/VC (atmSvcVp(Vc)CrossConnectTable) - SVC
As informaes sobre cruzamento de conexes relacionadas nesta MIB falam a
respeito de SVCs. As informaes sobre PVCs so especificadas na ATOM MIB,
descrita na seo 8.1.
Este grupo se baseia em duas tabelas, atmSvcVpCrossConnectTable e
atmSvcVcCrossConnectTable, onde so armazenadas as informaes sobre a
configurao e o estado de todos os SVCs. A funo destas tabelas fazer a
associao entre circuitos virtuais. Elas permitem acesso somente de leitura e
podem ser utilizadas para monitorar o cruzamento de conexes entre os
VPLs/VCLs em um comutador ATM.
Como na ATOM MIB, no caso de uma conexo ponto a ponto temos uma nica
entrada nestas tabelas, para uma conexo ponto a multiponto (N ns destino)
temos N entradas e para conexes multiponto a multiponto (N membros) temo
N(N-1)/2 entradas. Uma diferena entre a tabela de cruzamento de conexes
relativas a PVCs e a relativa a SVC, que a ltima no possui dados sobre o
estado dos cruzamentos enquanto a primeira possui esta informao para cada
uma das direes.
153
Como as informaes sobre VPs e VCs so idnticas iremos descrev-las ao

mesmo tempo. Os termo Low e High representam a ordenao de duas
interfaces associados com um cruzamento de conexes VPC/VCC. A interface
com o termo Low a que possui menor IfIndex26 e High significa maior
IfIndex.
Cada entrada (AtmSvcVpCrossConnect + ou AtmSvcVcCrossConnect +) possui
um identificador de linha (Index), possui informaes que identificam as
interfaces e as conexes que sero cruzadas (LowIfIndex, LowVpi, HighIfIndex,
HighVpi), no caso da tabela de VCs temos mais dois atributos (LowVci e
HighVci) e o atributo RowStatus que especifica a validade da entrada da tabela.
A.1.3. Endereamento
Este grupo composto de dois tipos de informaes sobre endereamento
divididas em trs tabelas. A tabela atmIfAdminAddrTable possui uma lista de
todos os endereos validos por interface e outras duas tabelas referem-se ao
mapeamento de endereo. So elas: atmVclAddrBindTable que prov
informaes sobre o mapeamento de VPI/VCI em endereos ATM e
atmAddrVclTable que possui dados sobre mapeamento de endereos ATM para
VPI/VCI.
Endereos administrativos de uma interface (atmIfAdminAddrTable)

Esta tabela aplicada somente para comutadores ou redes e somente para
interfaces que possuam mais de um endereo.
Cada entrada nesta tabela informa: o endereo ATM de uma interface em um
comutador ou rede (atmIfAdminAddrAddress); o tipo da fonte de um endereo
dado a um endereo ATM, por exemplo, dinmico (3) no caso de se usar ILMI,
(atmIfAdminAddrAddressSource); e a validade da entrada na tabela
(atmIfAdminAddrRowstatus).
26.
IfIndex o ndice de uma interface na tabela IfTable (tabela de interfaces),

especificada na MIB II.
154
Mapeamento de VPI/VCI em endereos ATM (atmVclAddrBindTable)

Esta tabela possibilita o mapeamento entre a tabela atmVclTable e os endereos
ATM locais e remotos. Ou seja, tendo o VPI/VCI de um VCL podemos encontrar
os endereos ATM das duas entidades que se conectam atravs deste VCL. bom
notar que podemos ter nesta tabela vrias entradas para uma mesma VCL, no caso
de conexes ponto a multiponto.
Cada entrada possui: o endereo ATM de um lado do VCL (Este dado sempre
informado no momento da criao do VCL, sendo que no caso de SVC quem
informa o agente e no PVC este valor informado pelo gerente)
(atmVclAddrBindAddr), tipo do endereo representado (ex. Local ou Remoto)
(atmVclAddrBindType)
e
a
validade
da
entrada
na
tabela
(atmVclAddrBindRowStatus).
Mapeamento de endereos ATM para VPI/VCI (atmAddrVclTable)

Esta tabela se comporta da mesma maneira que a atmVclAddrBindTable, a
diferena que enquanto esta tabela indexada pelo endereo ATM a outra
indexada pelo ndice da interface na tabela IfTable.
Os atributos informados em cada entrada so: o ndice da interface que eqivale
ao definido na tabela IfTable da MIB II (atmAddrVclAtmIfIndex), o valor do
VPI para o VCL (atmAddrVclVpi), o valor do VCI para o VCL(atmAddrVclVci)
e o tipo de endereo ATM representado pelo objeto (atmVclAddrBindAddress)
(ex. local ou remoto)(atmAddrVclAddrType). Os trs primeiros parmetros so
utilizados em conjunto como ndice na tabela atmVclTable definida na ATOM
MIB descrita na seo 8.1.
A.1.4. Circuitos Virtuais

Este grupo composto de quatro tabelas onde atmVplStatTable possui todas as
informaes estatsticas de cada VPL, atmVclStatTable possui todas as
informaes estatsticas de cada VCL, atmVplLogicalPortTable define portas
lgicas que sero utilizadas na criao dos chamados tneis VP e
atmVplGenTable que possui informaes gerais sobre cada VC.
155
Estatsticas (atmVplStatTable e atmVclStatTable)

Estas tabelas so utilizadas para fazer o monitoramento da utilizao de
VPLs/VCLs em termos de clulas que entram e que saem.
Os atributos definidos so (atmVplStat + ou atmVclStat +):
TotalCellIns: nmero total de clulas ATM vlidas recebidas por este
VPL/VCL, incluindo clulas com CLP=0 ou CLP=1;
Clp0CellIns: nmero de clulas ATM vlidas recebidas por este VPL/VCL
com CLP=0;
TotalDiscards: nmero total de clulas ATM vlidas descartadas neste
VPL/VCL pela entidade de policiamento de trfego, incluindo clulas com
CLP=0 ou CLP=1;
Clp0Discards: nmero total de clulas ATM vlidas recebidas com CLP=0 por
este VPL/VCL, e que foram descartadas pela entidade de policiamento de trfego;
TotalCellOuts: nmero total de clulas ATM vlidas enviadas por este
VPL/VCL, incluindo clulas com CLP=0 ou CLP=1;
Clp0CellOuts: nmero total de clulas ATM vlidas com CLP=0, enviadas
por este VPL/VCL;
TaggedOuts: nmero total de clulas ATM vlidas assinaladas pela entidade
de policiamento de trfego de CLP=0 para CLP=1 neste VPL/VCL.
VPL em Portas lgicas (atmVplLogicalPortTable)

As portas lgicas, como citado acima, so utilizadas na criao de tneis VP.
Tneis VP tem como principal utilizao a interligao entre duas redes ATM
privadas atravs de uma ou mais redes pblicas mesmo que estas no suportem
sinalizao. As redes pblicas s devem fornecer uma conexo permanente VP e
as redes privadas se utilizam da sinalizao para criar VCCs dentro deste VP. Os
tneis VP terminam em cada uma das pontas em interfaces lgicas que so
definidas na tabela IfTable da MIB II.
A tabela atmVplLogicalPortTable utilizada para fazer a conexo entre um dos
VPLs definidos numa interface fsica ATM com a interface lgica criada. Esta
tabela uma extenso da tabela atmVplTable na AToM MIB e possui um atributo
que identifica para cada VPL se este pertence a uma porta lgica ATM
156
(atmVplLogicalPortDef). Se pertence, o outro atributo utilizado para definir na

tabela IfTable qual a interface lgica que esta relacionada com este VPL
(atmVplLogicalPortIndex).
Informaes gerais sobre VCL (atmVclGenTable)

Como falado acima, esta tabela contm informaes gerais a respeito de cada VC.
A.1.5. Configuraes Extras

Extenses de configuraes das interfaces (atmInterfaceExtTable)
Esta tabela contm informaes adicionais
atmInterfaceConfTable da AToM MIB.
no
contidas
na
tabela
Os atributos definidos so separados em grupos:

Dados configurados (atmInterfaceConfMin): SvpcVpci (Mnimo VPCI que
uma pilha de sinalizao numa interface ATM configurada para suportar, na
alocao de VPCs comutadas), SvccVpci e SvccVci (Idem ao anterior, mas em
relao ao valor de VPCI e VCCI na alocao de VCCs comutadas.
Dados reais (atmInterfaceCurrentMin): SvpcVpci (Mnimo VPCI que uma
pilha de sinalizao numa interface ATM pode atualmente alocar para VPCs
comutadas), SvccVpci (Idem ao anterior, mas em relao ao valor de VPCI na
alocao de VCCs comutadas.) e SvccVci (Idem ao anterior, mas em relao ao
valor de VCCI na alocao de VCCs comutadas.).
157
A.1.6. Diagrama da Estrutura da MIB

atmSigSupportTable
atmSigTable
atmSigDescrParamTable
Index
Index
Index
AALInfo
PrefCarrier
ConfigSigType
AalType
AalMode
ConfigSide
SSCOPConEvents
********
********
SSCOPErrPdus
SigDetectMsgErrors
SigEmmitMsgErrors
Sinalizao
********
atmVclGenTable
Circutos Virtuais
ParamIndex
ifTable
SigDescrIndex
MIB II - RFC1213
atmVplLogicalPortTable
atmInterfaceExtTable
atmInterfaceConfTable
Index
Index
ConfMinSvpcVpci
ConfMinSvccVpci
MIB ATM - RFC1695
Def
---------------------------
********
atmVplStatTable
atmVclStatTable
atmVplTable
Index
Index
MIB ATM - RFC1695
Vpi
StatTotalCellsIns
Vpi
Vci
********
********
atmSvcVPCrossConnectTable
atmSvcVcCrossConnectTable
Index
Index
LowIfIndex
LowIfIndex
LowVpi
HighIfIndex
HighVpi
********
********
atmVclTable
MIB ATM - RFC1695
LowVpi
LowVci
HighIfIndex
HighVpi
ifTable
HighVci
MIB II - RFC1213
RowStatus
********
Endereamento
atmIfAdminAddrTable
atmVclAddrBindTable
atmAddrVclTable
Index
Index
VclAddrBindAddr
Address
Vpi
AddrVclInAtmIfIndex
AddressSource
Vci
AddrVclVpi
RowStatus
AddrBindAddr, ********
AddrVclVci, ********
Figura A.2: Modelo Entidade/Relacionamento: MIB Suplementar
158
A.2. DXI MIB

A ATM DXI (Data Exchange Interface) permite que um DTE (como um
roteador) e um DCE cooperem para prover uma UNI para redes ATM. Quando
uma ATM DXI usada, a implementao da UNI dividida entre o DTE e o
DCE, como ilustrado na figura A.3.
DTE
DCE
ATM DXI
ATM UNI
Comutador
ATM
Figura A.3: ATM DXI

DXI LMI (Local Management Information) opera juntamente com o DXI e define
o protocolo para a troca de dados na DXI, incluindo informao de gerenciamento
especficas da DXI, da AAL e da UNI. LMI foi projetado para suportar um
gerente SNMP e/ou um comutador com ILMI. Ento, assume-se que um agente
SNMP proxy reside no DTE, para determinar quando consultar o ATM DCE em
resposta um pedido SNMP do gerente; assim como um agente proxy ILMI para
pedidos ILMI vindos do comutador. De maneira anloga, traps vindas do DCE
podem estimular traps ILMI ou traps SNMP para um gerente. O relacionamento
da DXI LMI com o SNMP e o ILMI mostrado na Figura A.4.
ILMI
DTE
DCE
ATM DXI
SNMP
ATM UNI
Comutador
ATM
DXI LMI
NMS
Figura A.4: DXI LMI

159
O DTE mantm as informaes SNMP relativas ao seu lado da DXI na MIB

associada quela interface, na ifTable da MIB-II. O DCE tambm mantm todas
estatsticas e informaes contidas na ifTable e, alm dessas informaes, o DCE
mantm a ATM DXI MIB.
A ATM DXI MIB consiste de duas tabelas, ambas indexadas pelo ifIndex: a
atmDxiConfTable, que armazena o modo de operao daquela interface (1a, 1b ou
2); e a atmDxiDFAConfTable, que armazena a AAL para cada DFA (DXI Frame
Address).
A.3. PNNI MIB

PNNI (Private Network Node Interface) define o protocolo para a comunicao
entre comutadores ATM privados ou entre grupos de comutadores privados. PNNI
inclui duas categorias de protocolos: um protocolo para distribuio de
informao topolgica entre os comutadores, visando a criao de caminhos
(paths) pela rede; e outro para sinalizao.
Junto com a definio desses protocolos, foi definida a PNNI MIB, para acesso
via SNMP. A PNNI MIB possibilita o gerenciamento do roteamento PNNI. A
figura A.5 mostra a estrutura da PNNI MIB.
pnniNodeTable
- Coleta atributos que afetam a operao de um n lgico PNNI
pnniNodePglTable
- Informao sobre a eleio do lder do grupo, para um n PNNI. A
hierarquia PNNI exige que um n seja selecionado em cada grupo para executar
funes de LGN (Logical Group Node).
pnniNodeTimerTable
- Valores do timer PNNI e valores limites de alguns parmetros.
pnniNodeSvccTable
- Variveis relacionadas aos canais de controle de roteamento (RCC)
baseados em SVCC (Switched Virtual Channel Connection)
160
pnniMIBObjects
pnniBaseGroup
pnniIfTable
pnniMapNodeTable
pnniNodeTable
pnniLinkTable
pnniMapAddrTable
pnniNodePglTable
pnniNbrPeerTable
pnniMapTnsTable
pnniNodeTimerTable
pnniNbrPeerPortTable
pnniMetricsTable
pnniNodeSvccTable
pnniSvccRccTable
pnniScopeMappingTable
pnniPtseTable
pnniSummaryTable
pnniMapTable
pnniRoutingGroup
Figura A.5: Estrutura da PNNI MIB

pnniScopeMappingTable
- Contm informaes sobre o mapeamento dos valores usados nas
interfaces UNI para valores da PNNI.
pnniSummaryTable
- Possui a lista dos prefixos endereos sumrios que podem ser publicados
por uma entidade PNNI. Um endereo sumrio a abreviao de um conjunto de
endereos, representada por um prefixo comum.
161
pnniIfTable
- Contm os atributos necessrios para configurar uma interface fsica em
sistema de comutao para ser usada para roteamento PNNI. As interfaces podem
ser pontos de conexo fsica ou VPC configurados para uso do PNNI. Esse tabela
indexada pelo ifIndex da ifTable da MIB-II.
pnniLinkTable
- Contm os atributos necessrios para descrever a operao de links
lgicos conectados ao sistema de comutao; e o relacionamento com os ns
vizinhos na outra ponta do link.
pnniNbrPeerTable
- Contm os atributos necessrios para descrever o relacionamento que um
n possui com um n vizinho, dentro do mesmo grupo.
pnniNbrPeerPortTable
- Contm informaes sobre as portas que esto no estado 2-way Inside"
em um n PNNI lgico para um ponto vizinho. Pacotes "hellos" so trocados
entre ns vizinhos, sobre RCCs com o intuito de descobrir e verificar a identidade
dos ns vizinhos. Um ponto vizinho estar no estado "2-way inside" significa que
uma comunicao bidirecional entre esses dois links foi conseguida, indicada pelo
recebimento de pacotes "hello".
pnniSvccRccTable
- Contm os atributos necessrios para analisar a operao do protocolo
PNNI em RCCs baseados em um SVCCs.
pnniPtseTable
- Contm os atributos que descrevem as instncias mais recentes de PTSes
no banco de dados de topologias do n. O PTSP (PNNI Topology State Packet)
um pacote usado para mandar informao topolgica PNNI para um ponto
vizinho. O PTSP contm um ou mais PTSEs (PNNI Topology State Element)
descrevendo aspectos individuais da topologia, como links ativos e largura de
banda disponvel.
pnniMapTable
- Contm informaes sobre a conectividade de um n ou link, no domnio
de roteamento do PNNI.
162
pnniMapNodeTable
- Lista dos ns vistos da perspectiva do n local. Contm toda informao
recebida pelo n local atravs dos PTSEs.
pnniMapAddrTable
- Contm uma lista de todos endereos alcanveis de cada n visvel ao
n local.
pnniMapTnsTable
- Lista de todas redes de transio alcanveis de cada n visvel ao n
local.
pnniMetricsTable
- Para uma dada categoria de servio (CBR, VBR, ABR ou VBR), esta
tabela contm parmetros da conectividade de um certo n para um outro n, de
um porta para outra porta, ou para um ou mais prefixos de endereos ou redes de
transio.
PnniRoutingGroup
- O pnniRoutingGroup (figura A.6) contm algumas tabelas e o
pnniRouteBaseGroup, que contm duas variveis: o nmero corrente de rotas
vlidas para ns PNNI e para endereos ou redes de transio.
pnniRouteNodeTable
- A tabela de rotas da entidade PNNI gerenciada.
pnniDTLTable
- O conjunto de todas pilhas DTL (Designated Transit List) usadas para
rotas mantidas pela entidade gerenciada.
pnniRouteAddrTable
- Contm todos atributos necessrios para se determinar o que a entidade
PNNI acredita alcanar em termos de endereos ATM e para determinar que ns
publicam esse alcance. Esta tabela tambm usada para configurar rotas estticas
a prefixos de endereos alcanveis.
163
pnniRoutingGroup
pnniRouteBaseGroup
pnniRouteNodeTable
pnniDTLTable
pnniRouteAddrTable
pnniRouteTnsTable
Figura A.6: Estrutura do Grupo pnniRoutingGroup

pnniRouteTnsTable
- Contm todos atributos necessrios para se determinar que redes de
transio a entidade PNNI acredita alcanar e para se determinar que ns
publicam esse alcance.
A.4. Aplicao da MIB-II para ATM

Alguns grupos da MIB-II recebem valores especiais para possibilitar o
gerenciamento de interfaces ATM:
Grupo System:
- Para os propsitos do objeto sysServices do grupo system. ATM um
protocolo da camada de enlace, portanto ter valor 2.
164
Grupo Interface:
- Na mesma RFC da AToM MIB, foram definidas extenses ao grupo Interface
para possibilitar o gerenciamento de interfaces ATM.
ifTable
ifEntry
ifIndex
ifName
ifDescr
ifInOctets,
ifOutOctets
ifType
ifInErrors,
ifOutErrors
ifPhysAddress
ifUnknownProtos
ifAdminStatus
ifHighSpeed
ifOperStatus
ifConnectorPresent
ifLastChange
ifHCInOctets,
ifHCOutOctets
ifInErrors
ifLinkUpDownTrapEnable
Figura A.7: Estrutura da ifTable
Suporte Camada ATM
Cada porta ATM representada como uma entrada na ifTable (mostrada na figura
A.7) e o valor do ifType 37. Muitas tabelas da AtoM MIB e algumas da ATM
165
Inteface MIB, entre outras, so indexadas pelo ifIndex. Um dispositivo com ILMI
deve tambm implementar o grupo System.
Gerenciamento de AAL5
AAL5 ser gerenciada em um comutador, se existirem conexes que carregam
informaes AAL5 terminam na Entidade AAL5 do comutador. A Figura A.8
mostra o modelo de uma Entidade AAL5 e de uma Entidade ATM (responsvel
pela comutao em si). Tanto a Entidade AAL5 (tanto em um host, como em um
switch) e a Interface Virtual Proprietria so gerenciadas pela ifTable. Cada uma
representada como uma entrada na ifTable.
Entidade AAL5
Interface Virtual
Prorprietria
Entidade ATM
Figura A.8: Modelo das Entidades AAL5 e ATM em um Comutador
166
Anexo B
Artigo
TILA - Uma Arquitetura Inteligente e Distribuda

para o Gerenciamento de Redes ATM
Anexo C
Artigo
RENATA, Uma Ferramenta para Gerncia

Pr-Ativa de Redes ATM Usando Redes Neurais
Referncias Bibliogrficas
[1]
Alexander, P. and Carpenter, K., ATM Net Management: A Status
Report, Data Communications, Sep, 1995.
[2]
Alles, A., ATM Internetworking, May, 1995.
[3]
IETF <draft-ietf-atommib>, Definitions of Supplemental Managed
Objects for ATM Management, Apr, 1996.
[4]
ATM-FORUM <af-nm-0019.000>, Customer Network Management
(CNM) for ATM Public Network Service, Oct, 1994.
Greaves, D. J., McAuley, D., French, L. J. and Kyden, E., Protocol
and Interfaces for ATM LANs, 1994.
[5]
[6]
Hott, R., Technical Review of ATM Specifications, Jul, 1996.
[7]
ATM-FORUM <af-ilmi-0065.000>, Integrated Local Management
Interface (ILMI) Specification Version 4.0, Sep, 1996.
[8]
International
http://www.itu.ch.
Telecommunication
Union
(ITU-T),
URL:
[9]
Heinnen, J., Routing and Addressing in ATM Networks, Telecom
Finland, 1992.
ATM-FORUM <af-lane-0021.000>, ATM Forum LAN Emulation 1.0
(LANE) Specification, Jan, 1995.
[10]
ATM-FORUM <af-nm-0020.000>, M4 Interface Requirements and

Logical MIB, Oct, 1994.
[11]
[12] ATM-FORUM <af-nm-0058.000>, M4 Public Network view, Mar,

1996.
[13]
Rose, M., and McCloghrie, K., IETF RFC1213 Management
Information Base for Network Management of TCP/IP-based Internets:

MIB-II, 1991.
[14] Miller, M., Analyzing Broadband Networks (ISDN, Frame-Relay,
SMDS, ATM), 2nd Ed., M&T Books, 1997.
[15] Minoli, D. e Golway, T., Planning & Managing ATM Networks,
Prentice Hall, 1997.
ATM-FORUM <af-mpoa-0087.000> - Multi-Protocol Over ATM
Specification v1.0, Jul, 1997.
[16]
[17] Partridge, C., Gigabit Networking, Addison-Wesley Publishing

Company, 1993.
IETF <RFC 1695>, Definitions of Managed Objects for ATM
Management Version 8.0 using SMIv2, Aug, 1994.
[18]
Rose, M, e McCloghrie, K., How to Manage your Network Using

SNMP, Prentice Hall, 1995.
[19]
[20] Pujolle, G., Les nouvelles technologies des rseaux haut-dbits:

ATM versus Internet, Proc. of II SFBSID97, Nov, 1997.
[21]
ATM Forum <af--0071.000> "M4 NE View", Jan, 1997.
Soares, L., Redes de Computadores: Das LANSs e WANSs s

Redes ATM. Editora Campus, 1995.
[22]
Stallings, W., SNMP, SNMPv2 and CMIP, The Pratical Guide to

Management
Standards,
Addison-Wesley
Publishing
Company,Inc., 1993.
[23]
Network
[24] Stiller, B., A Survey of UNI Signaling Systems and Protocols for
ATM Networks, Cambridge University.
[25] Tanenbaum, A., Distributed Operating Systems, Prentice Hall,
1995.
[26]
Tanenbaum, A., Computer Networks, 2nd ed., 1996.
[27]
ATM Forum <af-tm-0056.000>, ATM Forum Traffic Management
Specification Version 4.0, Apr, 1996.
ATM Forum <af-sig-0061.000>, ATM User-Network Interface

(UNI) Signalling Specification Version 4.0, Jul, 1996.
[28]
[29]
ATM Forum - URL: http://www.atmforum.com.
[30] Bellcore Technical Advisory TA-NWT-001112, "Broadband ISDB

User to Network and Network Node Interface Physical Layer Generic
Criteria", Aug, 1992.
[31] ATM Forum, <af-tm-0056.000>, " Traffic Management 4.0", Apr,
1996.
[32] Sprenkels, R., "Management of ATM Networks", Masters Thesis,
University of Twente, Jun, 1996.
[33] ITU-T I.610, "B-ISDN operation and maintenance principles and
functions", Nov, 1995.
[34] ITU-T I.356, "B-ISDN ATM layer cell transfer performance", Oct,
1996.
[35]
ATM Forum, <af-dxi-0014.000>, "Data Exchange Interface (DXI)
Specification", Aug, 1993.
[36] ATM Forum, <af-pnni-0055.000>, "Private

Interface (PNNI) Specification Version 1.0", Mar, 1996.
Network-Network
Krishnan, K., e Fuller, W., "An OVERVIEW of MIBs for ATM Network
Management", 53 Bytes, vol. 5, no. 4, Dec, 1997.
[37]

Livrogerencia

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Livrogerencia

Enviado por

Direitos autorais:

Formatos disponíveis

Introduo Gerncia de

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

"s mulheres de nossas vidas."

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

e Internet, com nfase para os padres em desenvolvimento para o gerenciamento

Jos Neuman de Souza

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

Os autores desculpam-se, antecipadamente, por quaisquer "descuidos de

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

Introduo Gerncia de Redes ATM

4. Gerncia Internet .........................................................................39

Parte II Gerncia ATM

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

6. Gerncia ATM .............................................................................. 75

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

11. Gerenciamento de Trfego ..........................................................129

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

1. Gerncia de Redes de Computadores

1.1. Introduo Gerncia de Redes

Figura 1.1: LAN (Local Area Network)

Pode-se citar como exemplo o trabalho cooperativo na comunidade

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

Figura 1.2: WAN (Wide Area Network)

Este crescimento vertiginoso das redes de computadores, bem como de suas

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

Figura 1.3: Integrao a Grandes Distncias

No que se refere ao aspecto tecnolgico das redes de computadores, interessa-nos

O que Gerncia de Redes

Gerncia de Redes de Computadores pode ser conceituada como a coordenao

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

A Importncia da Gerncia de Redes

A Complexidade da Gerncia de Redes

Uma implicao imediata no crescimento das redes de computadores o aumento

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

Figura 1.4: Ambiente Corporativo Integrado

Essa complexidade implicar no uso de ferramentas automatizadas associadas ao

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

1.2. Elementos Bsicos na Gerncia de Redes

Etapas no Processo de Gerncia

A primeira idia na soluo de um sistema de gerncia de redes consiste em se utilizar

As etapas de Coleta, Diagnstico e Ao no processo de gerncia de redes so

XVI Simpsio Brasileiro de Redes de Computadores

Introduo Gerncia de Redes ATM

Figura 1.5: Sistema Integrado de Gerncia de Redes

XVI Simpsio Brasileiro de Redes de Computadores