Gerncia de Redes de Computadores

e de Telecomunicaes

Profa. Elizabeth Sueli Specialski, Dra.

Elizabeth Sueli Specialski graduou-se em Matemtica pela Pontifcia
Universidade Catlica do Rio Grande do Sul em 1978, obteve o ttulo de
Mestre em Cincias da Computao pela Universidade Federal do Rio
Grande do Sul em 1981 e o ttulo de Doutora em Engenharia pela
Universidade Federal de Santa Catarina em maro de 2000. professora
no nvel Adjunto IV da Universidade Federal de Santa Catarina e vem
atuando em pesquisa e formao na rea de Redes de Computadores e de
Gerncia de Redes de Computadores e de Telecomunicaes junto ao
Departamento de Informtica e de Estatstica da UFSC nos cursos de
Graduao em Computao e Ps-Graduao em Computao e em
Engenharia de Produo. Seu desempenho traduzido pela publicao de
mais de 50 trabalhos em Congressos Nacionais e Internacionais, palestras
convidadas e consultorias realizadas junto a empresas fornecedoras de
produtos e servios de telecomunicaes.

Endereo para contato:

Prof. Elizabeth Sueli Specialski
Departamento de Informtica e de Estatstica
Universidade Federal de Santa Catarina
Campus Universitrio Trindade
88040-900 Florianpolis SC
Tel.: (048) 331-7513 / 331-9739 / 9972-4345
Fax: (048) 331-9566
E-mail: beth@inf.ufsc.br ou especialski@bol.com.br

Sumrio
1
NECESSIDADES DE GERENCIAMENTO...........................................................................................2
1.1
REAS FUNCIONAIS DE GERENCIAMENTO ................................................................................................2
1.2
MONITORAO E CONTROLE DA REDE .....................................................................................................5
2
MODELOS DE GERENCIAMENTO DE REDE ..................................................................................7
2.1
SOFTWARE DE APRESENTAO .................................................................................................................8
2.2
SOFTWARE DE GERENCIAMENTO ............................................................................................................10
2.3
SOFTWARE DE SUPORTE AO GERENCIAMENTO .......................................................................................10
3
A ARQUITETURA SNMP .....................................................................................................................12
3.1
SERVIOS E PROTOCOLOS DE GERNCIA .................................................................................................12
3.2
ELEMENTOS DA ARQUITETURA...............................................................................................................13
3.3
MODELO DE INFORMAO ......................................................................................................................15
3.4
MONITORAO REMOTA - RMON MIB ...............................................................................................22
3.5
O SNMPV2 ............................................................................................................................................28
3.6
O SNMPV3 ............................................................................................................................................32
3.7
O SMON................................................................................................................................................35
4
NECESSIDADES DE GERENCIAMENTO DE APLICAES DE REDE .....................................36
4.1
CONSTRUO DE NOVAS MIBS ..............................................................................................................38
5
GERNCIA DE REDES DE TELECOMUNICAES......................................................................39
6
A ARQUITETURA DE GERENCIAMENTO OSI..............................................................................41
6.1
ESTRUTURAS DE GERENCIAMENTO .........................................................................................................41
6.2
COMPONENTES DE GERNCIA OSI ..........................................................................................................43
6.3
ESTRUTURA DA INFORMAO DE GERENCIAMENTO ...............................................................................43
6.4
SERVIOS E PROTOCOLOS DE COMUNICAO .........................................................................................44
7
SERVIOS DE SUPORTE COMUNICAO ................................................................................47
7.1
ELEMENTOS DE SERVIO PARA APLICAES DE GERENCIAMENTO .........................................................49
7.2
FLUXO DA INFORMAO DE GERENCIAMENTO........................................................................................57
7.3
CONHECIMENTO DE GERENCIAMENTO COMPARTILHADO .......................................................................60
7.4
DOMNIOS GERENCIAIS...........................................................................................................................61
8
FUNES E SERVIOS CMISE .........................................................................................................63
8.1
SERVIOS DE GERENCIAMENTO ..............................................................................................................63
8.2
PROTOCOLO DE GERENCIAMENTO CMIP................................................................................................67
9
ARQUITETURA FUNCIONAL DO MODELO OSI ..........................................................................71
9.1
SMASE - SYSTEM MANAGEMENT APPLICATION SERVICE ELEMENT ASPECTOS FUNCIONAIS ................72
9.2
FUNO DE GERENCIAMENTO DE OBJETO..............................................................................................73
9.3
FUNO DE GERENCIAMENTO DE ESTADO .............................................................................................74
9.4
ATRIBUTOS DE STATUS...........................................................................................................................75
9.5
ATRIBUTOS PARA REPRESENTAO DE RELACIONAMENTO .....................................................................76
9.6
FUNO DE RELATRIO DE ALARME......................................................................................................77
9.7
FUNO DE GERENCIAMENTO DE RELATRIO DE EVENTO .....................................................................78
9.8
FUNO DE CONTROLE DE LOG .............................................................................................................79
9.9
FUNES DE GERENCIAMENTO DE SEGURANA .....................................................................................81
9.10 FUNO DE MEDIDA DE CONTABILIZAO ............................................................................................83
9.11 FUNO DE MONITORAO DE CARGA DE TRABALHO ..........................................................................85
9.12 FUNO DE GERENCIAMENTO DE TESTE ................................................................................................86
9.13 FUNO DE SUMARIZAO ....................................................................................................................87
10
CARACTERSTICAS DAS ARQUITETURAS DE GERENCIAMENTO ...................................89
10.1 A UTILIZAO DE PLATAFORMAS DE GERENCIAMENTO: MITOS E FATOS .................................................89
10.2 A VISO DOS DADOS ...............................................................................................................................90
10.3 IMPLANTAO DE UM SISTEMA DE GERNCIA .........................................................................................91
10.4 CONSIDERAES FINAIS .........................................................................................................................92
11
BIBLIOGRAFIA .................................................................................................................................93
12
ANEXO: INFORMAES SOBRE ALARMES: CAUSA PROVVEL......................................95

1 Necessidades de Gerenciamento
Por menor e mais simples que seja uma rede de computadores, precisa ser gerenciada, a
fim de garantir, aos seus usurios, a disponibilidade de servios a um nvel de desempenho
aceitvel.
medida que a rede cresce, aumenta a complexidade de seu gerenciamento, forando a
adoo de ferramentas automatizadas para a sua monitorao e controle.
A adoo de um software de gerenciamento no resolve todos os problemas da pessoa
responsvel pela administrao da rede. Geralmente o usurio de um software de
gerenciamento espera muito dele e, conseqentemente, fica frustrado quanto aos resultados
que obtm. Por outro lado, esses mesmos softwares quase sempre so sub-utilizados, isto ,
possuem inmeras caractersticas inexploradas ou utilizadas de modo pouco eficiente. Para
gerenciar um recurso, necessrio conhec-lo muito bem e visualizar claramente o que este
recurso representa no contexto da rede [Adams 97].
O investimento em um software de gerenciamento pode ser justificado pelos seguintes
fatores [Harnedy 97]:
As redes e recursos de computao distribudos esto se tornando vitais para a
maioria das organizaes. Sem um controle efetivo, os recursos no proporcionam
o retorno que a corporao requer.
O contnuo crescimento da rede em termos de componentes, usurios, interfaces,
protocolos e fornecedores ameaam o gerenciamento com perda de controle sobre
o que est conectado na rede e como os recursos esto sendo utilizados.
Os usurios esperam uma melhoria dos servios oferecidos (ou no mnimo, a
mesma qualidade), quando novos recursos so adicionados ou quando so
distribudos.
Os recursos computacionais e as informaes da organizao geram vrios grupos
de aplicaes de usurios com diferentes necessidades de suporte nas reas de
desempenho, disponibilidade e segurana. O gerente da rede deve atribuir e
controlar recursos para balancear estas vrias necessidades.
medida que um recurso fica mais importante para a organizao, maior fica a
sua necessidade de disponibilidade. O sistema de gerenciamento deve garantir esta
disponibilidade.
A utilizao dos recursos deve ser monitorada e controlada para garantir que as
necessidades dos usurios sejam satisfeitas a um custo razovel.

1.1 reas Funcionais de Gerenciamento

Alm desta viso qualitativa, uma separao funcional de necessidades no processo de
gerenciamento foi apresentada pela ISO (International Organization for Standardization),
como parte de sua especificao de Gerenciamento de Sistemas OSI. Esta diviso funcional
foi adotada pela maioria dos fornecedores de sistemas de gerenciamento de redes para
descrever as necessidades de gerenciamento: Falhas, Desempenho, Configurao,
Contabilizao e Segurana.

Gerenciamento de Falhas
Falhas no so o mesmo que erros. Uma falha uma condio anormal cuja recuperao
exige ao de gerenciamento. Uma falha normalmente causada por operaes incorretas
ou um nmero excessivo de erros. Por exemplo, se uma linha de comunicao cortada
fisicamente, nenhum sinal pode passar atravs dela. Um grampeamento no cabo pode
causar distores que induzem uma alta taxa de erros. Certos erros como por exemplo, um
bit errado em uma linha de comunicao, podem ocorrer ocasionalmente e normalmente
no so considerados falhas.
Para controlar o sistema como um todo, cada componente essencial deve ser monitorado
individualmente para garantir o seu perfeito funcionamento. Quando ocorre uma falha,
importante que seja possvel, rapidamente:
Determinar o componente exato onde a falha ocorreu;
Isolar o resto da rede da falha, de tal forma que ela continue a funcionar sem
interferncias;
Reconfigurar ou modificar a rede para minimizar o impacto da operao sem o
componente que falhou;
Reparar ou trocar o componente com problemas para restaurar a rede ao seu estado
anterior.
O impacto e a durao do estado de falha pode ser minimizado pelo uso de componentes
redundantes e rotas de comunicao alternativas, para dar rede um grau de tolerncia
falhas.

Gerenciamento de Contabilizao
Mesmo que nenhuma cobrana interna seja feita pela utilizao dos recursos da rede, o
administrador da rede deve estar habilitado para controlar o uso dos recursos por usurio ou
grupo de usurios, com o objetivo de:
evitar que um usurio ou grupo de usurios abuse de seus privilgios de acesso e
monopolize a rede, em detrimento de outros usurios;
evitar que usurios faam uso ineficiente da rede, assistindo-os na troca de
procedimentos e garantindo a desempenho da rede;
conhecer as atividades dos usurios com detalhes suficientes para planejar o
crescimento da rede.
O gerente da rede deve ser capaz de especificar os tipos de informaes de
contabilizao que devem ser registrados em cada nodo, o intervalo de entrega de relatrios
para nodos de gerenciamento de mais alto nvel e os algoritmos usados no clculo da
utilizao.

Gerenciamento de Configurao
O gerenciamento de configurao est relacionado com a inicializao da rede e com
uma eventual desabilitao de parte ou de toda a rede. Tambm est relacionado com as
tarefas de manuteno, adio e atualizao de relacionamentos entre os componentes e do
status dos componentes durante a operao da rede.
Alguns recursos podem ser configurados para executar diferentes servios como, por
exemplo, um equipamento pode atuar como roteador, como estao de trabalho ou ambos.
3

Uma vez decidido como o equipamento deve ser usado, o gerente de configurao pode
escolher o software apropriado e um conjunto de valores para os atributos daquele
equipamento.
O gerente da rede deve ser capaz de, inicialmente, identificar os componentes da rede e
definir a conectividade entre eles. Tambm deve ser capaz de modificar a configurao em
resposta s avaliaes de desempenho, recuperao de falhas, problemas de segurana,
atualizao da rede ou a fim de atender necessidades dos usurios.
Relatrios de configurao podem ser gerados periodicamente ou em resposta s
requisies de usurios.

Gerenciamento de Desempenho
O gerenciamento do desempenho de uma rede consiste na monitorao das atividades da
rede e no controle dos recursos atravs de ajustes e trocas. Algumas das questes relativas
ao gerenciamento do desempenho, so:

qual o nvel de capacidade de utilizao?

o trfego excessivo?
o throughput foi reduzido para nveis aceitveis?
existem gargalos?
o tempo de resposta est aumentando?

Para tratar estas questes, o gerente deve focalizar um conjunto inicial de recursos a
serem monitorados, a fim de estabelecer nveis de desempenho. Isto inclui associar mtricas
e valores apropriados aos recursos de rede que possam fornecer indicadores de diferentes
nveis de desempenho. Muitos recursos devem ser monitorados para se obter informaes
sobre o nvel de operao da rede. Colecionando e analisando estas informaes, o gerente
da rede pode ficar mais e mais capacitado no reconhecimento de situaes indicativas de
degradao de desempenho.
Estatsticas de desempenho podem ajudar no planejamento, administrao e manuteno
de grandes redes. Estas informaes podem ser utilizadas para reconhecer situaes de
gargalo antes que elas causem problemas para o usurio final. Aes corretivas podem ser
executadas, tais como, trocar tabelas de roteamento para balancear ou redistribuir a carga de
trfego durante horrios de pico, ou ainda, a longo prazo, indicar a necessidade de expanso
de linhas para uma determinada rea.

Gerenciamento de Segurana
O gerenciamento da segurana prov facilidades para proteger recursos da rede e
informaes dos usurios. Estas facilidades devem estar disponveis apenas para usurios
autorizados. necessrio que a poltica de segurana seja robusta e efetiva e que o sistema
de gerenciamento da segurana seja, ele prprio, seguro.
O gerenciamento de segurana trata de questes como:
gerao, distribuio e armazenamento de chaves de criptografia;
manuteno e distribuio de senhas e informaes de controle de acesso;
monitorao e controle de acesso rede ou parte da rede e s informaes obtidas

dos nodos da rede;

coleta, armazenamento e exame de registros de auditoria e logs de segurana, bem
como ativao e desativao destas atividades.

1.2 Monitorao e Controle da Rede

As funes de gerenciamento de rede podem ser agrupadas em duas categorias:
monitorao de rede e controle de rede. A monitorao da rede est relacionada com a
tarefa de observao e anlise do estado e configurao de seus componentes; uma funo
de leitura. O controle da rede uma funo de escrita e est relacionada com a tarefa de
alterao de valores de parmetros e execuo de determinadas aes.

Monitorao
A monitorao consiste na observao de informaes relevantes ao gerenciamento.
Estas informaes podem ser classificadas em trs categorias:
Esttica: caracteriza a configurao atual e os elementos na atual configurao, tais
como o nmero e identificao de portas em um roteador.
Dinmica: relacionada com os eventos na rede, tais como a transmisso de um
pacote na rede.
Estatstica: pode ser derivada de informaes dinmicas; ex. mdia de pacotes
transmitidos por unidade de tempo em um determinado sistema.
A informao de gerenciamento coletada e armazenada por agentes e repassada para
um ou mais gerentes. Duas tcnicas podem ser utilizadas na comunicao entre agentes e
gerentes: polling e event-reporting.
A tcnica de polling consiste em uma interao do tipo request/response entre um
gerente e um agente. O gerente pode solicitar a um agente (para o qual ele tenha
autorizao), o envio de valores de diversos elementos de informao. O agente responde
com os valores constantes em sua MIB.
Na tcnica de event-reporting, a iniciativa do agente. O gerente fica na escuta,
esperando pela chegada de informaes. Um agente pode gerar um relatrio periodicamente
para fornecer ao gerente o seu estado atual. A periodicidade do relatrio pode ser
configurada previamente pelo gerente. Um agente tambm pode enviar um relatrio quando
ocorre um evento significativo ou no usual.
Tanto o polling quanto o event-reporting so usados nos sistemas de gerenciamento,
porm a nfase dada a cada um dos mtodos difere muito entre os sistemas. Em sistemas
de gerenciamento de redes de telecomunicaes, a nfase maior dada para o mtodo de
relatrio de evento. Em contraste, o modelo SNMP d pouca importncia ao relatrio de
evento. O modelo OSI fica entre estes dois extremos.
A escolha da nfase depende de um nmero de fatores, incluindo os seguintes:
a quantidade de trfego gerada por cada mtodo;
robustez em situaes crticas;
o tempo entre a ocorrncia do evento e a notificao ao gerente;
5

 a quantidade de processamento nos equipamentos gerenciados;

a problemtica referente transferncia confivel versus transferncia no
confivel
as aplicaes de monitorao de rede suportadas;
as consideraes referentes ao caso em que um equipamento falhe antes de enviar
um relatrio.

Controle de Rede
Esta parte do gerenciamento de rede diz respeito modificao de parmetros e
execuo de aes em um sistema remoto. Todas as cinco reas funcionais de
gerenciamento (falhas, desempenho, contabilizao, configurao e segurana), envolvem
monitorao e controle. Tradicionalmente, no entanto, a nfase nas trs primeiras destas
reas, tem sido na monitorao, enquanto que nas duas ltimas, o controle tem sido mais
enfatizado. Alguns aspectos de controle na gerncia de configurao e de segurana so
apresentados a seguir.
O controle de configurao inclui as seguintes funes:
definio da informao de configurao - recursos e atributos dos recursos sujeitos
ao gerenciamento;
atribuio e modificao de valores de atributos;
definio e modificao de relacionamentos entre recursos ou componentes da
rede;
inicializao e terminao de operaes de rede;
distribuio de software;
exame de valores e relacionamentos;
relatrios de status de configurao.
O controle de segurana relativo segurana dos recursos sob gerenciamento,
incluindo o prprio sistema de gerenciamento. Os principais objetivos em termos de
segurana, so relativos confidencialidade, integridade e disponibilidade. As principais
ameaas segurana referem-se interrupo, interceptao, modificao e mascaramento.
As funes de gerenciamento de segurana podem ser agrupadas em trs categorias:
manuteno da informao de segurana
controle de acesso aos recursos
controle do processo de criptografia

2 Modelos de Gerenciamento de Rede

Um sistema de gerenciamento de rede uma coleo de ferramentas para monitorar e
controlar a rede, integradas da seguinte forma:
uma nica interface de operador, com um poderoso mas amigvel conjunto de
comandos, para executar a maioria ou todas as tarefas de gerenciamento da rede;
uma quantidade mnima de equipamentos separados, isto , que a maioria do
hardware e software necessrio para o gerenciamento da rede seja incorporado nos
equipamentos de usurios existentes.
O software usado para realizar as tarefas de gerenciamento, reside nos computadores
hospedeiros (estaes de trabalho) e nos processadores de comunicao (switches, routers,
hubs,...).
Todos os equipamentos da rede, que fazem parte do sistema de gerenciamento, possuem
um conjunto de software destinado s tarefas de coletar informaes sobre as atividades
relacionadas com a rede, armazenar estatsticas localmente e responder aos comandos do
centro de controle da rede. Estes nodos so referenciados como AGENTES. No mnimo um
hospedeiro da rede designado para as tarefas de controlador da rede (GERENTE) e possui
uma coleo de software chamada Aplicao de Gerenciamento da Rede. A aplicao de
gerenciamento da rede possui uma interface que permite, a um usurio autorizado, gerenciar
a rede. A figura 2.1 apresenta um cenrio possvel de um sistema de gerenciamento de rede.
Um software de gerenciamento genrico composto por:

Elementos gerenciados
Agentes
Gerentes
Bancos de Dados de Informaes
Protocolos para troca de informaes de gerenciamento
Interfaces para programas aplicativos
Interfaces com o usurio

HOSPEDEIRO CONTROLADOR

GERENTE
AGENTE

ROTEADOR
AGENTE

HUB
AGENTE

Figura 2.1. Configurao de um sistema de gerenciamento de rede.

A arquitetura do software de gerenciamento residente no gerente e nos agentes varia de
acordo com a funcionalidade da plataforma adotada. Genericamente, o software pode ser
dividido em trs grandes categorias:
software de apresentao (interface)
software de gerenciamento (aplicao)
software de suporte (base de dados e comunicao)

2.1 Software de apresentao

A interface de usurio, em um sistema de gerenciamento, permite que o usurio
monitore e controle a rede. Normalmente ela est localizada no sistema hospedeiro gerente.
Em alguns casos comum existir uma interface em alguns agentes a fim de permitir a
execuo de testes e tambm a visualizao ou alterao de alguns parmetros localmente.
A figura 2.2 (a) mostra os dois blocos que representam o software de apresentao das
informaes de gerncia.

Interface de usurio unificada

(a)
Servio de apresentao das informaes de gerncia

Aplicao de gerenciamento
de rede

elemento de
aplicao
(b)

elemento de
aplicao

  

Aplicao de gerenciamento
de rede

elemento de
aplicao

  
Servio de transporte de dados de gerenciamento de rede

Mdulo de acesso
MIB

Pilha de protocolos
de comunicao

MIB
(c)

rede gerenciada

Figura 2.2. Arquitetura de um sistema de gerenciamento de rede.

O principal, em qualquer sistema de gerenciamento, que a interface seja unificada, isto
, que ela seja a mesma em qualquer nodo, permitindo que o usurio gerencie uma rede
heterognea com um mnimo de treinamento.
Um dos perigos em qualquer sistema de gerenciamento a sobrecarga de informaes.
Dependendo da configurao estabelecida, uma grande quantidade de informaes pode ser
disponibilizada para o usurio. As ferramentas da interface de apresentao devem
organizar, sumarizar e simplificar, tanto quanto possvel, estas informaes. Na maioria dos

produtos existentes no mercado, so utilizados grficos e tabelas para a apresentao das

informaes.

2.2 Software de Gerenciamento

O software que fornece a aplicao de gerenciamento pode ser muito simples, como o
caso do modelo SNMP, ou muito complexo, como o modelo OSI. A figura 2.2 (b) mostra
uma estrutura genrica de um software de gerenciamento, organizado em trs nveis:
aplicao de gerenciamento de rede, elementos de servio da aplicao e servio de
transporte de dados de gerenciamento da rede.
A aplicao de gerenciamento de rede prov os servios de interesse do usurio como,
por exemplo, gerenciamento de falhas, de configurao, de segurana, etc. Os elementos de
servio da aplicao implementam as funes com propsito geral, que servem de suporte
s diversas aplicaes, tais como, alarmes genricos ou sumarizao de dados. O servio de
transporte de dados de gerenciamento consiste de um protocolo usado para a troca de
informaes entre gerentes e agentes e de uma interface de servio para os elementos de
servio de aplicao.

2.3 Software de Suporte ao Gerenciamento

Para executar suas tarefas, o software de gerenciamento necessita acessar uma base de
informaes de gerenciamento (MIB) e agentes e gerentes remotos.
A MIB localizada em um nodo agente contm informaes de gerenciamento que
refletem a configurao e o comportamento do nodo e parmetros que podem ser usados
para controlar a operao do nodo. A MIB localizada no gerente contm informaes
especficas do nodo onde est localizada e informaes resumidas sobre os agentes sob o
seu controle.
O mdulo de acesso MIB, mostrado na figura 2.2 (c), inclui software de
gerenciamento de arquivos que habilitam o acesso MIB. Adicionalmente, o mdulo de
acesso MIB pode converter o formato local das informaes para um formato padronizado
do sistema de gerenciamento.
O modelo de informao de um sistema de gerenciamento fornece a estrutura para
representao, armazenamento e transferncia das informaes de gerenciamento. Esta
estrutura denominada SMI (Structure Management Information) e, dependendo do
sistema, poder apresentar maior ou menor complexidade.
No modelo OSI, a SMI baseada no paradigma de orientao a objetos, enfatizando as
hierarquias de classe, de containment e de registro. J o modelo SNMP, utiliza conceitos de
Tipos de Dados, embora a sua nomenclatura refira-se a objetos.
A figura 2.3. mostra exemplos de definio de objeto em cada um dos modelos.

10

Modelo SNMP
abcObjectType OBJECT-TYPE
SYNTAX
INTEGER {
choicelabel1 (1),
choicelabel2 (2)
}
ACCESS
read-only
STATUS
mandatory
DESCRIPTION
"Description Text"
::= { pqr 3 }

Modelo OSI
network
MANAGED OBJECT CLASS
DERIVED FROM top;
BEHAVIOR network-behavior;
CHARACTERIZED BY
networkPackage PACKAGE
ATTRIBUTES
networkID
GET,
networkType
GET;
REGISTERED AS

(exemplo MObjectClass 2);

Figura 2.3. Exemplos de especificao de objetos gerenciados

A comunicao entre gerentes e agentes suportada por uma pilha de protocolos, tais
como a pilha OSI ou a pilha TCP/IP. A arquitetura de comunicao suporta o protocolo de
gerenciamento de rede que est localizado na camada de aplicao.
Os servios bsicos de um sistema de gerenciamento de rede so os servios de
monitorao e controle. Estes servios so obtidos atravs de primitivas para a leitura e
escrita nos valores dos objetos gerenciados. Outros servios adicionais so: criao e
destruio de objetos gerenciados, execuo de aes sobre objetos gerenciados e emisso
de relatrios de eventos.
A comunicao entre agentes e gerentes, a fim de alcanar estes servios, deve seguir
um conjunto de regras bsicas, como em qualquer outra aplicao distribuda. Este conjunto
de regras pode apresentar maior ou menor complexidade, dependendo do modelo adotado.
O modelo OSI utiliza o protocolo CMIP (Common Management Information Protocol) que
apresenta funcionalidades para emitir relatrios diversos sobre a ocorrncia de eventos,
criar e destruir instncias de classes de objetos, executar aes sobre objetos, ler e modificar
valores de atributos de objetos e para a execuo de operaes sobre vrios objetos a partir
da definio de um escopo e de um filtro para a seleo de objetos. O modelo Internet
utiliza o protocolo SNMP (Simple Network Information Protocol), cuja funcionalidade
reside basicamente na leitura e alterao de valores de variveis e em alguns relatrios de
evento para situaes especficas.

11

3 A arquitetura SNMP
O modelo arquitetural SNMP consiste em uma coleo de estaes de gerenciamento e
elementos de rede. As estaes de gerenciamento executam aplicaes que monitoram e
controlam os elementos de rede. Os elementos de rede so equipamentos tais como
hospedeiros, gateways, servidores de terminais, e similares, que possuem agentes de
gerenciamento, e que so responsveis pela execuo das funes de gerenciamento de
rede, requisitadas pelas estaes de gerenciamento. O protocolo SNMP usado para
transportar a informao de gerenciamento entre as estaes de gerenciamento e os agentes
existentes nos elementos de rede. A figura 3.1 mostra algumas das interaes possveis
entre um Gerente e um Agente, atravs do protocolo SNMP.
ler valor de varivel (GET request)
mudar valor de varivel (SET request)

Gerente

Figura 3.1. Troca de mensagens SNMP entre Gerente e Agente

Agente
informar
valor de varivel
(GET
O modelo proposto busca
minimizar
o nmero
e aresponse)
complexidade de funes de
ocorrncia
de evento (TRAP)
gerenciamento realizadas informar
pelos agentes
de gerenciamento.
As razes que tornam este
objetivo atrativo, so:
o custo de desenvolvimento do software de agente de gerenciamento, necessrio
para suportar o protocolo significativamente reduzido;
o grau de funcionalidade suportado remotamente proporcionalmente aumentado,
medida que se aumenta a utilizao dos recursos internet na tarefa de
gerenciamento;
a quantidade de funes de gerenciamento, que so suportadas remotamente,
gradativamente aumentada, atravs da imposio de algumas restries sobre a
forma e sofisticao das ferramentas de gerenciamento.
conjuntos simplificados de funes de gerenciamento so facilmente entendidos e
utilizados pelos desenvolvedores de ferramentas de gerenciamento de redes.
O segundo objetivo do protocolo que o paradigma funcional para monitorao e
controle deve ser suficientemente extensvel para acomodar aspectos adicionais, e
possivelmente no previstos, da operao e gerenciamento de redes.
O terceiro objetivo que a arquitetura deve ser, tanto quanto possvel, independente da
arquitetura e dos mecanismos de hospedeiros e gateways particulares.

3.1 Servios e protocolos de gerncia

O primeiro dos protocolos de gerncia de rede foi o SGMP (Simple Gateway
Monitoring Protocol) que surgiu em novembro 1987. Entretanto, o SGMP era restrito
monitorao de gateways. A necessidade crescente de uma ferramenta de gerenciamento de
rede mais genrica fez emergirem mais algumas abordagens:
12

High-Level Entity Management System HEMS generalizao do HMP Host

Management Protocol;
SNMP Simple Network Management Protocol um melhoramento do SGMP;
CMOT (CMIP over TCP/IP) uma tentativa de incorporar o mximo possvel o
protocolo (CMIP), servios e estrutura de base de dados que estava sendo padronizada pela
ISO para gerenciamento de redes.
No incio de 1988 a IAB (Internet Architecture Board) revisou os protocolos e escolheu
o SNMP como uma soluo de curto prazo e o CMOT como soluo de longo prazo para o
gerenciamento de redes. O sentimento era que, em um perodo de tempo razovel, as
instalaes migrariam do TCP/IP para protocolos baseados em OSI. Entretanto, como a
padronizao do gerenciamento baseado no modelo OSI apresentava muita complexidade
de implementao e o SNMP, devido sua simplicidade, foi amplamente implementado
nos produtos comerciais, o SNMP tornou-se um padro de fato. Posteriormente, pela
existncia de lacunas funcionais (devido exatamente simplicidade do SNMP), foram
definidas novas verses do protocolo SNMP chamadas de SNMPv2 e SNMPv3, e o SNMP
original ficou conhecido como SNMPv1.
A primeira verso da arquitetura de gerenciamento SNMP foi definida no RFC 1157 de
maio de 1990.
O RFC 1157 define que a arquitetura SNMP consiste de uma soluo para o problema
de gerenciamento de redes, em termos de:

o escopo da informao de gerenciamento comunicada pelo protocolo;

a representao da informao de gerenciamento comunicada pelo protocolo;
operaes sobre a informao de gerenciamento, suportadas pelo protocolo;
a forma e o significado das trocas entre entidades de gerenciamento;
a definio dos relacionamentos administrativos entre entidades de gerenciamento;
a forma e o significado das referncias s informaes de gerenciamento.

O RFC 1157 define ainda trs objetivos a serem alcanados pelo SNMP: minimizar o
nmero e complexidade das funes de gerenciamento, ser flexvel o suficiente para
permitir expanses futuras e ser independente da arquitetura e mecanismo dos dispositivos
gerenciados.

3.2 Elementos da Arquitetura

O SNMP foi projetado para ser um protocolo de camada de aplicao da famlia TCP/IP
e trabalhar sobre UDP, que um protocolo no orientado conexo.
A comunicao de informaes de gerenciamento feita no SNMPv1 utilizando
somente cinco mensagens de protocolo, conforme mostrado na figura 3.2. Trs delas (getrequest, get-next-request e set-request) so iniciadas pelo processo de aplicao gerente, as
outras duas (get-response e trap) so geradas pelo processo agente. A gerao de mensagens
chamada de um evento. No esquema de gerenciamento SNMP, o gerente monitora a rede,
indagando os agentes sobre seu estado e caractersticas. Entretanto a eficincia aumentada

13

quando agentes enviam mensagens no solicitadas chamadas de traps. Um trap ocorre

quando o agente observa a ocorrncia de um parmetro pr-configurado no mdulo agente.
Operao

Funo

get-request

Solicitao de recuperao do valor de uma ou um conjunto de

variveis informados na solicitao

get-next-request

set-request
get-response
Trap

Solicitao de recuperao do valor de uma ou um conjunto de

variveis que sucedem lexicograficamente quelas informadas na
solicitao
Solicitao para atribuio de valor a uma ou um conjunto de variveis
Resposta s operaes get-request, get-next-request e set-request
Envio de um evento no solicitado para uma ou vrias estaes de
gerenciamento. Tipos de traps definidos no RFC 1215: cold start, warm
start, link down, link up, authentication failure, egp neighbor loss e
enterprise specific.

Figura 3.2 Operaes Suportadas no SNMPv1

A mensagem SNMP dividida em duas sees: uma identificao de verso e nome da
comunidade e a PDU (protocol data unit). A verso e comunidade so s vezes chamadas
de header de autenticao SNMP. Existem 5 tipos diferentes de PDU: get-request, get-nextrequest, get-response, set-request e trap. Todas as PDUs, exceto o trap, tm o mesmo
formato, conforme mostra a figura 3.3.

Figura 3.3 Formato de Mensagens SNMPv1

O SNMPv1 tem um processo de autenticao fraca. Ele se baseia em um string de
caracteres chamado community contido no cabealho do pacote SNMP e que trafega em
modo legvel pela rede. So definidas duas communities, uma para acesso somente de
14

leitura e outra para acesso de leitura e gravao.

O SNMP no prov mecanismos especficos para que um gerente d comandos para que
um agente execute uma ao. Entretanto, possvel utilizar a operao set para contornar
esta deficincia. Um objeto pode ser utilizado para representar um comando, ento uma
ao especfica executada se o valor do objeto alterado para um valor especfico (ex:
objeto reboot).
Apesar de amplamente difundido e utilizado no gerenciamento de redes de
computadores, o SNMPv1 possui as seguintes limitaes:










no apropriado para o gerenciamento de redes muito grandes, devido limitao

de performance de polling;
traps SNMP no so reconhecidos, pois so implementados sobre protocolos sem
reconhecimento/conexo;
o padro SNMPv1 prov somente autenticao trivial;
o modelo da MIB limitado e no suporta aplicaes que questionam o
gerenciamento baseado em valores ou tipos de objetos;
no possvel ter uma idia do trfego existente nas redes onde os recursos
gerenciados esto instalados pois estas informaes referem-se ao prprio recurso
onde o agente est executando;
incapacidade de analisar seus prprios dados e enviarem notificaes quando
alguns limiares forem atingidos; e
no suporta a comunicao gerente-gerente.
no suporta a comunicao gerente-gerente.

3.3 Modelo de informao

Atualmente vrios documentos definem a informao de gerenciamento no modelo
SNMP, sendo que os principais so: o RFC 1155 - Estrutura da Informao de
Gerenciamento (SMI), o RFC 1213 - Base de Informao de Gerenciamento (MIB) e o RFC
1157 Protocolo Simples de Gerenciamento de Rede (SNMP).
A SMI (Structure and Identification of Management Information for TCP/IP-Based
Internets) descreve como os objetos gerenciados contidos na MIB so definidos.
A MIB (Management Information Base) descreve quais so os objetos contidos na MIB.
O SNMP (Simple Network Information Protocol) define o protocolo usado para
gerenciar estes objetos.
3.3.1 Estrutura da Informao de Gerenciamento (SMI)
A SMI especifica as estruturas que representam os recursos a serem gerenciados, usando
um subconjunto da sintaxe denominada ASN.1 (Abstract Syntax Notation One) [ISO8824,
1987].
Tambm, para efeitos de simplicidade, utilizado um subconjunto das regras bsicas de
codificao ASN.1. Todas as codificaes utilizam a forma de tamanho definido. Alm

15

disso, quando permitido, so usadas codificaes de no construtores, preferencialmente s

codificaes de construtores. Esta restrio se aplica a todos os aspectos de codificao
ASN.1, tanto para as unidades de dados do protocolo, quanto para os objetos de dados que
elas contm.
Os nomes para todos os tipos de objetos contidos na MIB, so definidos explicitamente
na MIB padro Internet ou em outros documentos que seguem as convenes de nomeao
definidas na SMI. A SMI requer que todos os protocolos de gerenciamento definam
mecanismos para identificar instncias individuais dos tipos de objetos de um elemento de
rede particular.
Cada instncia de tipo de objeto definido na MIB identificada, nas operaes SNMP,
por um nome nico chamado nome de varivel. Geralmente, o nome de uma varivel
SNMP um OBJECT IDENTIFIER da forma x.y, onde x o nome de um tipo de objeto
no agregado definido na MIB e y um fragmento de OBJECT IDENTIFIER que, de uma
forma especfica para o tipo de objeto nomeado, identifica a instncia desejada.
Esta estratgia de nomeao permite a explorao completa da semntica da PDU
GetNextRequest, porque ela atribui nomes para variveis relacionadas, em uma ordem
lexicogrfica contnua.
A nomeao de tipos especficos de algumas instncias de objetos, para algumas classes
de tipos de objetos, definida a seguir. Instncias de um tipo de objeto, para as quais
nenhuma das seguintes convenes de nomeao so aplicveis, so nomeadas por um
OBJECT IDENTIFIER da forma x.0, onde x o nome do tipo de objeto na definio da
MIB.
Suponha-se, por exemplo, que se deseje identificar uma instncia da varivel sysDescr.
A classe de objeto para sysDescr :
iso

org

dod

internet

mgmt

mib

system

sysDescr

Neste caso, o tipo de objeto x deve ser 1.3.6.1.2.1.1.1, para o qual deve ser concatenado
um sub-identificador 0, isto , 1.3.6.1.2.1.1.1.0 identifica uma e somente uma instncia de
sysDescr.
A figura 3.4 mostra a rvore de registro utilizada para nomeao de objetos definidos na
MIB.

16

TOP
CCITT (0)

JOINT-ISO-CCITT (2)

ISO (1)

STD(0)

MEMBER
BODY(2)

ORG (3)

REG
AUTHORITY(1)

DOD (6)
INTERNET (1)

DIRECTORY (1)

MGMT (2)

PRIVATE (4)
EXPERIMENTAL(3)

MIB (1)

ENTERPRISES[1]

EGP (8)
TCP (6)
INTERFACE (2)

IP (4)

IBM (2)
UDP (7)

PROTEON (1)

ICMP (5)
SYSTEM(1)

ADDRESS

RESERVED (0)

TRANSLATION (3)

Figura 3.4 - rvore de registro de tipos de objetos

A sub-rvore MGMT contm a definio das bases de informao de gerenciamento que
foram aprovadas pelo IAB. Atualmente, existem duas verses da MIB: mib-1 e mib-2. A
mib-2 uma extenso da primeira. As duas possuem o mesmo identificador na sub-rvore
porque apenas uma das duas estar presente em qualquer configurao.
A SMI identifica os tipos de dados que podem ser usados na construo de uma base de
informao de gerenciamento e como os recursos dentro desta base podem ser
representados e nomeados. So definidos apenas dois tipos de dados simples: escalar
(variveis simples) e array bidimensional de escalares (tabelas).
Os tipos de dados ASN.1 que podem ser utilizados na definio dos objetos da MIB so
basicamente:
UNIVERSAL:
INTEGER, OCTET STRING, NULL, OBJECT IDENTIFIER, SEQUENCE e
SEQUENCE OF.
APPLICATION:
NetworkAddress, IpAddress, Counter, Gauge, TimeTicks e Opaque.
Cada objeto na MIB possui um nome, um tipo, um valor, uma forma de acesso, um
status e uma descrio, e sua definio, de acordo com a SMI, segue a seguinte estrutura:
nome do objeto OBJECT-TYPE

17

SYNTAX
<nome de um tipo, ex.: INTEGER, IpAddress, etc.>
ACCESS
<read-only, write-only, read-write, not-accessible >
STATUS
<se obrigatrio ou no: mandatory ou optional>
DESCRIPTION
<um texto explicativo escrito entre aspas>
::= {<nome usado para acessar o objeto via SNMP>}
Exemplos:
tcpConnTable OBJECT-TYPE
SYNTAX
SEQUENCE OF TcpConnEntry
ACCESS
not-accessible
STATUS
mandatory
DESCRIPTION
A table containing TCP connection-specific information.
::= {tcp 13}
tcpConnEntry OBJECT-TYPE
SYNTAX
TcpConnEntry
ACCESS
not-accessible
STATUS
mandatory
DESCRIPTION
Information about a particular current TCP connection. An object of this type is
transient, in that it ceases to exist when (or soon after) the connection makes the
transition to the CLOSED state.
::= {tcpConnTable 1}
TcpConnEntry SEQUENCE

tcpConnState OBJECT-TYPE
SYNTAX
INTEGER

ACCESS

{tcpConnState
INTEGER,
tcpConnLocalAddress
IpAddress,
tcpConnLocalPort
INTEGER (0..65535),
tcpConnRemAddress
IpAddress,
tcpConnRemPort
INTEGER (0..65535)}
{closed (1),
listen (2),
synSent (3),
synReceived (4),
established (5),
finWait1 (6),
finWait2 (7),
closeWait (8),
lastAck (9),
closing (10),
timeWait (11),
deleteTCB (12) }

read-write

18

STATUS
mandatory
DESCRIPTION
The state of this TCP connection.
The only value which may be set by a management station is deleteTCB(12).
Accordingly, it is appropriate for an agent to return a bad value response if a
management station attempts to set this object to any other value.
If a management station sets this object to the value deleteTCB(12), then this has the
effect of deleting the TCB (as defined in RFC 793) of the corresponding connection
on the managed node, resulting in immediate termination of the connection.
As an implementation-specific option, a RST segment may be sent from the
managed node to the other TCP end point (note however that RST segments are not
sent reliably).
::= {tcpConnEntry 1}
tcpConnRemPort OBJECT-TYPE
SYNTAX
INTEGER (0..65535)
ACCESS
read-only
STATUS
mandatory
DESCRIPTION
The remote port number for this TCP connection.
::= {tcpConnEntry 4}
3.3.2 A base de informaes de gerenciamento - MIB
A MIB uma coleo estruturada de objetos gerenciados. Objetos gerenciados
representam os recursos sujeitos ao gerenciamento. Cada nodo do sistema de gerenciamento
mantm uma MIB que reflete o estado dos recursos gerenciados naquele nodo. Uma
entidade de gerenciamento pode monitorar os recursos de um nodo, lendo os valores dos
objetos na MIB e pode controlar os recursos de um nodo, modificando estes valores.
Os objetos da mib-2 so subdivididos nos seguintes grupos:
system: informaes gerais sobre o sistema;
interfaces: informaes sobre cada uma das interfaces do sistema para a sub-rede;
at(address translation; deprecated): descreve a tabela de translao de endereos
para mapeamento de endereos internet para endereos de sub-rede;
ip: informao relativa a experincias de implementao e execuo do protocolo
IP (internet protocol) no sistema;
icmp: informao relativa a experincias de implementao e execuo do
protocolo ICMP (internet control message protocol) no sistema;
tcp: informao relativa a experincias de implementao e execuo do protocolo
TCP (transmission control protocol) no sistema;
udp: informao relativa a experincias de implementao e execuo do protocolo
UDP (user datagram protocol) no sistema;
egp: informao relativa a experincias de implementao e execuo do protocolo
EGP (external gateway protocol) no sistema;
cmot: informaes para sistemas de gerncia OSI;
transmission: fornece informaes sobre esquemas de transmisso e protocolos de
19

acesso em cada interface do sistema;

snmp: informao relativa a experincias de implementao e execuo do
protocolo SNMP (simple network management protocol) no sistema;
A organizao em grupos conveniente porque os objetos so organizados de acordo
com as funes das entidades gerenciadas e tambm porque ela oferece um guia para os
implementadores de agentes, no sentido de identificar quais objetos devem ser
implementados. Se a semntica de um grupo for aplicvel para uma determinada
implementao, ento todos os objetos do grupo devem ser implementados. Por exemplo,
uma implementao deve incluir todos os objetos do grupo TCP se e somente se ela
implementa o protocolo TCP; portanto, uma bridge ou um router no necessita implementar
os objetos do grupo TCP. Uma exceo a esta regra o grupo de translao de endereos
(at). A figura 3.5 ilustra a estrutura do grupo system e a tabela 3.1 fornece a sintaxe do
objeto, a forma de acesso permitida e uma descrio sucinta da semntica.

20

system (mib-2 1)
sysDescr(1)
sysObjectID(2)
sysUpTime(3)
sysContact(4)
sysName(5)
sysLocation(6)
sysServices(7)
Fig. 3.5. Grupo System da MIB-II

Tabela 3.1 - Objetos do grupo System da MIB-II

Objeto

Sintaxe

Acesso

sysDescr

DisplayString

RO

Descrio
de
uma
entidade
(hardware, sistema
operacional, etc.

RO

Identificao do
sub-sistema contido
na entidade

(Size (0..255)
sysObjectID

OBJECT
IDENTIFIER

Semntica

sysUpTime

TimeTicks

RO

Tempo decorrido
desde
a
ltima
reinicializao

sysContact

DisplayString

RW

Identificao da
pessoa de contato
para
este
nodo
gerenciado

RW

Nome atribudo
administrativamente
para este nodo

RW

Localizao
fsica do nodo

(Size (0..255)
sysName

DisplayString
(Size (0..255)

sysLocation

DisplayString
(Size (0..255)

sysServices

INTEGER

RO
o

Valor indicando
conjunto
de
21

(0..127)

servios oferecidos
pela entidade

3.4 Monitorao Remota - RMON MIB

A medida em que as redes foram crescendo e se tornando geogrfica e logicamente
distribudas, o gerenciamento de redes tornou-se mais desafiador. Utilizando apenas
informaes da MIB-II, o gerente de redes no consegue ter uma idia do trfego existente
nas redes onde os recursos gerenciados esto instalados porque estas informaes referemse apenas ao prprio recurso onde o agente est executando. Em uma grande rede, com
vrios ns gerenciados e no gerenciados, fica praticamente impossvel inspecionar
variveis da MIB-II de todos os agentes da rede para se ter uma idia do trfego entre eles.
Uma soluo encontrada foi a instalao de dispositivos remotos de gerenciamento,
denominados probes, nos segmentos remotos. A mais importante adio ao conjunto de
padres SNMP foi a MIB RMON (Remote Network Monitoring MIB) que padronizou as
informaes de gerenciamento enviadas para e recebidas desses probes na RFC1757 [Wal
95].
Outro problema com os agentes SNMP tradicionais que estes no so capazes de
analisar seus prprios dados e, por exemplo, serem programados para enviarem notificaes
quando certos limiares nas variveis forem atingidos. Isto fora a estao de gerenciamento
a ficar inspecionando (fazendo polling) as variveis das diversas entidades de
gerenciamento, causando um trfego excessivo na rede.
A tecnologia de RMON consiste na presena de um monitor instalado na rede que se
deseja estudar, coletando informaes e, eventualmente, enviando notificaes sobre a
ocorrncia de eventos. O monitor pode ser tanto um dispositivo dedicado captura de
dados e sua anlise, como tambm pode estar implementado em estaes de trabalho, em
servidores, roteadores, hubs, etc.
Essencialmente, a RMON uma extenso da MIB Internet. Atravs da escrita em
variveis desta MIB, o gerente pode programar o monitor para coletar dados e armazen-los
em tabelas para serem recuperados posteriormente.
O RMON divide o processo de captao de dados em duas partes. Os dados so
coletados pelo agente RMON que pode estar em um segmento prximo ao dispositivo ou
implementado no dispositivo. Uma ou mais estaes de gerenciamento falam com o agente
RMON (usando SNMP) em lugar de falar diretamente com o dispositivo gerenciado. Por
terminologia, um sistema que implementa a MIB RMON chamado de probe RMON.
Mesmo que a estao de gerenciamento perca conexo ao probe a coleta de dados continua,
uma vez que o probe est conectado diretamente rede sendo monitorada.
A RMON foi projetada para atingir os seguintes objetivos:
operao off-line: o monitor coleta e armazena estatsticas que podem ser recuperadas
pela estao gerente a qualquer momento;

22

monitorao preemptiva: o monitor est sempre ativo, continuamente rodando

diagnsticos e armazenando dados;
deteco e alerta de problemas: o monitor pode verificar continuamente determinadas
condies e comunic-las quando ocorrerem;
resumo dos dados: o monitor capaz de realizar algum processamento como, por
exemplo, descobrir os 10 hosts mais ativos na rede;
mltiplos gerentes: o monitor deve suportar vrias estaes gerentes.
A figura 3.6 mostra o cenrio de gerenciamento de uma rede utilizando RMON.

Figura 3.6 Utilizao do RMON na gerncia de rede.

Para implementar um agente RMON em um dispositivo, ele deve ser capaz de operar no
modo promscuo, isto , dever poder aceitar dados no endereados especificamente para
ele.
As metas definidas pelo grupo de trabalho para a definio das MIBs RMON so
definidas nos RFCs 1757 e 2021. So elas:


operao off-line o probe acumula estatsticas e executa diagnsticos

continuamente, mesmo que a comunicao com a estao gerente no seja possvel
ou eficiente. As notificaes podem ser enviadas para o gerente quando eventos
excepcionais ocorrerem. Alm disso o gerente pode recuperar informaes do
probe RMON quando melhor lhe aprouver, utilizando o protocolo SNMP;

23

monitoramento pr-ativo - se o monitor tiver recursos suficientes, pode executar

continuamente diagnsticos e logar performance da rede. Em uma falha na rede,
pode notificar a estao gerente da falha e prover informaes proveitosas no
diagnstico da falha;
 deteco e registro de problemas - O monitor pode passivamente reconhecer
certas condies de erro e outros, como congestionamento, no trfego observado.
Quando uma condio configurada ocorrer, pode registrar e tentar notificar a
estao gerente;
 anlise de dados - o monitor pode executar anlises especficas sobre os dados
coletados na sub-rede. Por exemplo, pode determinar qual host gera a maior parte
do trfego ou dos erros na sub-rede;
 mltiplos gerentes - uma configurao de rede pode ter mais do que uma estao
gerente como medida de redundncia, que podem executar funes diferentes e
prover capacidades de gerncia para unidades diferentes na organizao.
O RMON prov informaes estatsticas e de diagnstico, minimiza o trfego de
gerenciamento, reduz o impacto de perda de conectividade, serve vrias estaes de
gerenciamento simultaneamente e fornece, ainda, um conjunto padro de mtricas que pode
ser usado por vrios dispositivos que suportam RMON.


A MIB RMON possui OID {1.3.6.1.2.1.16} e foi originalmente definida para redes
ethernet em novembro de 1991 no RFC 1271, em 1995 foi substituda pelo RFC 1757, que
foi, em maio de 2000, substitudo pelo RFC 2819. Originalmente a MIB RMON s
contemplava redes ethernet, mas em setembro de 1993 foi desenvolvido o RFC 1513, que
trazia extenses para redes token ring. A MIB RMON contm 10 grupos. A figura 3.7
mostra a localizao da MIB RMON com os grupos definidos:











statistics (rmon 1) prov estatsticas medidas pelo probe no segmento, tais como
nmero e tamanho dos pacotes, broadcast, colises, etc;
history (rmon 2) - grava amostras estatsticas peridicas do trfego para permitir
anlise posterior;
alarm (rmon 3) - compara amostras estatsticas com limiares configurados gerando
alarmes quando estes limiares forem ultrapassados;
host (rmon 4) - mantm estatsticas dos hosts na rede, incluindo o MAC address dos
hosts ativos;
hostTopN (rmon 5) - prov relatrios indicando quais hosts esto no topo de uma
categoria em particular;
matrix (rmon 6) - armazena estatsticas de trfego sobre conversaes entre hosts;
filter (rmon 7) - permite que pacotes sejam selecionados de acordo com um critrio
especificado;
capture (rmon 8) - permite que pacotes sejam capturados depois de passarem pelo
filtro;
event (rmon 9) - controla a gerao e notificao de eventos, o que pode incluir
mensagens de trap SNMP;
tokenRing (rmon 10) prov parmetros adicionais para redes token ring.

24

Figura 3.7 Grupos RMON

Subramanian [Subramanian 2000] (p.327) enquadra os grupos RMON em trs grandes
categorias: a maior a dos grupos que analisam as informaes e geram estatsticas. Nesta
categoria enquadram-se os grupos statistics, history, host e host top N. A segunda categoria
trata de eventos da rede e funes de gerao de relatrios. Estes so os grupos de alarm e
event. A terceira categoria trata com filtragem e captura de pacotes. Nesta categoria
enquadram-se os grupos filter e packet capture. A figura 3.8 ilustra esta classificao.

Figura 3.8 Classificao dos grupos RMON

25

Todos os grupos so opcionais, mas a implementao de alguns grupos requer outros

grupos. Existem as seguintes dependncias:
o grupo alarm requer a implementao do grupo event;
o grupo hostTopN requer a implementao do grupo host;
o grupo capture requer a implementao do grupo filter.
Tipicamente, um monitor remoto necessitar ser configurado para coletar dados. A
configurao dita o tipo e forma de dados para serem coletados. A MIB organizada em
grupos funcionais. Cada grupo ter uma ou mais tabelas de controle e uma ou mais tabelas
de dados. Uma tabela de Controle contm parmetros que descrevem o dado na tabela de
Dados, que somente para leitura. Assim, a estao gerente seta os parmetros apropriados
para configurar o monitor remoto para coletar os dados desejados. Os parmetros so
setados pela adio de um novo registro na tabela, ou alterando uma existente. Desse modo,
funes para serem executadas pelo monitor so definidas e implementadas na tabela. Por
exemplo, uma tabela Controle pode conter objetos que especifiquem a origem dos dados
coletados, tipos de dados, hora/data da coleta etc...





A RMON2
A MIB RMON original se preocupava basicamente com operao e gerenciamento das
camadas fsica e de enlace, de uma rede remota. O RMON2 definido no RFC2021, estende
as capacidades do RMON s camadas superiores, adicionando 10 novos grupos, conforme
mostra a figura 3.9: (Miller 1997, Subramanian 2000)


protocol directory (rmon 11) - identifica os protocolos que o probe pode monitorar. Os
protocolos que podem ser monitorados foram definidos no RFC2074;

protocol distribution (rmon 12) - prov informao relativa ao trfego de diferentes

protocolos, tanto em bytes quanto em pacotes. Ele coleta estatsticas que ajudam o
administrador de rede a gerenciar a banda alocada para cada protocolo;

address map (rmon 13) - correlaciona os endereos de rede com endereos MAC,
armazenando-os em uma tabela. A traduo de endereos permite a gerao de mapas
topolgicos aprimorados e a deteco de endereos ip duplicados;

network-layer host (rmon 14) coleciona estatsticas sobre o volume de trfego de

entrada e sadas das estaes com base no endereo de nvel de rede. Como
conseqncia, o gerente pode observar alm dos roteadores que interligam as sub-redes
e identificar as reais estaes que esto se comunicando;

network-layer matrix (rmon 15) prov estatsticas sobre o volume de trfego entre
pares de estaes com base no endereo do nvel de rede;

application-layer host (rmon 16) agrega estatsticas sobre o volume de trfego por
protocolo de nvel superior gerado de ou para cada endereo de rede;

application-layer matrix (rmon 17) coleciona estatsticas sobre o volume de trfego,

por protocolo, trocados por pares de endereos de rede;

26

user history collection (rmon 18) - combina mecanismos vistos nos grupos alarm e
history para prover informaes de coleo de dados histricos especificados pelo
usurio;

probe configuration (rmon 19) define parmetros de configurao padres para

probes RMON. Deste modo, a estao de gerenciamento com software de um
fabricante capaz de configurar, remotamente, um probe de outro fabricante;

rmon conformance (rmon 20) descreve os requisitos de conformidade para a MIB

RMON2.

Figura 3.9 Grupos RMON2

Stallings [Stallings 1999], (p.277) cita duas implicaes importantes decorrentes do fato
de que o RMON2 decodifica pacotes das camadas 3 a 7 do modelo OSI:


o probe RMON2 pode monitorar o trfego baseado nos endereos e protocolos de

camada de rede, incluindo o IP. Isto possibilita que o probe veja acima da rede local ao
qual est conectado;

como o RMON2 pode decodificar e monitorar trfego da camada de aplicao, o probe

pode gravar trfego para aplicaes especficas.

A figura 3.10 mostra o nvel de visibilidade que RMON e RMON2 provem dentro de
um segmento LAN ou de uma rede em cada uma das camadas do OSI.

27

Figura 3.10 Visibilidade RMON1 x RMON2

As restries com relao performance para implementao do RMON1 so ainda

maiores no RMON2, pois ele necessita ainda de mais recursos de memria e processamento
para ser implementado. Para atender a estas demandas, os fabricantes de dispositivos
RMON2 esto oferecendo probes stand-alone que executam em plataformas de hardware de
alta capacidade de memria e processamento. (Stallings 1999, p.326)

3.5 O SNMPv2
O SNMP foi desenvolvido como uma soluo temporria para prover um gerenciamento
mnimo da rede, a soluo definitiva viria com o gerenciamento baseado no modelo OSI.
Alguns motivos fizeram que esta transio no acontecesse da forma planejada,
principalmente porque:
o modelo OSI usava a abordagem orientada a objeto que era mais complexa do que o
que se planejava implementar no SNMP que implementou um MIB escalar, o que
tornava a transio mais complexa.
 o desenvolvimento de padres OSI de gerenciamento e subseqente disponibilizao
de sua implementao em dispositivos de rede demorou muito mais do que o esperado,
abrindo uma janela de oportunidade que foi aproveitada pelo SNMP.
A verso 2 do SNMP (SNMPv2) foi desenvolvida quando se tornou bvio que o padro
de gerenciamento OSI no seria implementado em um futuro prximo. Os maiores
fabricantes de dispositivos de rede j haviam incorporado mdulos SNMP em seus
equipamentos e estava claro para todos que o SNMP necessitava de melhoramentos.


O primeiro projeto do SNMPv2 no foi amplamente aceito pelo mercado. As razes,

28

para esta falta de aceitao, so a complexidade dos melhoramentos de segurana e

administrao do framework. Vrias tentativas de simplificao foram tentadas, entretanto
no se chegou a nenhum consenso. Como resultado ocorreram trs aes (Miller 1997,
p.201):


os documentos que tinham atingido consenso foram publicados em janeiro de 1996

como RFCs 1902-1908;

modificaes menores no modelo de administrao e segurana do SNMPv2,

denominados comunit-based SNMPv2 (SNMPv2c), foram publicados em janeiro de
1996, documento RFC 1901;

o trabalho continuou em outras reas: segurana, framework administrativo, MIB de

configurao remota e comunicao gerente-gerente.
Vrias mudanas significativas deveriam ser introduzidas no SNMPv2. Uma das mais
significativas seria a de prover funes de segurana, que inexistiam no SNMPv1.
Infelizmente, depois de muito esforo, no houve consenso, ento a feature de segurana foi
retirada da especificao final.


Apesar do modelo organizacional permanecer praticamente inalterado e a despeito da

falta de melhorias na parte de segurana, vrias melhorias foram feitas na arquitetura
SNMPv2: novos tipos de dados, novas macros, convenes textuais, operaes que
facilitam a transferncia de grandes quantidades de dados (bulk), transferncia de blocos de
dados (bulk), cdigos de erro mais detalhados, suporte a multiprotocolos na camada de
transporte, incluso de mensagem de gerente para gerente, definio de uma nova estrutura
de informaes de gerenciamento (SMIv2 definida nas RFCs 1902 a 1904), comandos de
conformidade, melhorias em tabelas e incluso de dois novos grupos na MIB , security e
SNMPv2. [Subramanian 2000], [Miller 1997]
O SNMPv2 prov trs tipos de acesso s informaes de gerenciamento de redes. O
primeiro tipo de interao chamado request-response, quando o gerente SNMP envia uma
solicitao a um agente SNMPv2 que responde. O segundo tipo de interao um requestresponse onde ambas as entidades so gerentes SNMP. O terceiro tipo uma interao no
confirmada, onde um agente SNMPv2 envia uma mensagem no solicitada, ou trap, para o
gerente e nenhuma resposta retornada. Somente a segunda forma nova no SNMPv2, as
outras duas j existiam no SNMPv1. A figura 3.11 mostra a arquitetura de gerenciamento
utilizando o SNMPv2.

29

Figura 3.11 Arquitetura de gerenciamento de rede SNMPv2

A alterao mais importante nas operaes do SNMPv2 foi a incluso de duas novas
PDUs. A GetBulkRequest que permite ao gerente recuperar grandes blocos de dados
eficientemente, em particular vrias linhas de tabelas. A PDU information-request gerada
por um gerente para informar a outro gerente informao contida em sua viso da MIB.
Uma resposta gerada pelo gerente que recebeu a mensagem para o gerente que a enviou.
A estrutura de dados PDU foi padronizada (figura 3.12) para que todas as mensagens
possuam um formato comum, a informao nos traps na verso 2 do SNMP foi modificada
para ficar com o mesmo padro das outras PDUs. Isto aumenta a eficincia e performance
na troca de mensagens entre sistemas.

30

Figura 3.12 Formato de PDUs do SNMPv2

As PDUs GetRequest e GetNextRequest so idnticas s do SNMPv1 em formato e

semntica. A diferena que no SNMPv1 as operaes eram atmicas: ou todos os valores
eram retornados ou nenhum valor retornava. No SNMPv2 a lista de variable-bindings
preparada, mesmo se valores no podem ser recuperados para todas as variveis. Se uma
condio de exceo encontrada para uma varivel ento a varivel retornada com a
indicao da exceo em lugar do valor.
A verso 1 do SNMP foi originalmente definida para transmisso sobre o UDP e IP.
Pesquisas subseqentes exploraram o uso do SNMP com outros protocolos de transporte,
incluindo o OSI (RFC 1418), appletalk (RFC 1419) e IPX (RFC 1420). O SNMPv2
formalmente define implementaes sobre outros protocolos de transporte no RFC 1906.
apesar de definido para vrios protocolos de transporte, o RFC 1906 sugere que agentes
continuem ouvindo o UDP na porta 161 e gerem notificaes na porta 162 do UDP.
O grupo de trabalho do IETF responsvel pelo SNMPv2 props dois esquemas de
migrao (RFC 1908) do SNMPv1 para o SNMPv2: o gerente bilnge que falaria com o
agente SNMP na verso que ele entendesse e o SNMP proxy server que receberia as
mensagens SNMPv2 e, atuando como proxy, as transmitiria para o agente como SNMPv1.
Algumas modificaes foram introduzidas na MIB internet, conforme ilustrado na
figura 3.13: o grupo system do SNMPv2 composto pelos mesmos objetos do SNMPv1
expandindo com a incluso de novos objetos que permitem a uma entidade SNMPv2
agindo como agente descrever seus recursos dinamicamente. Alm disso, o grupo SNMP na
verso do SNMPv2 comparado com o originalmente definido da MIBII tem muito menos
objetos. A razo que as estatsticas detalhadas definidas na MIB II no auxiliam na
soluo de problemas e adicionam complexidade desnecessria aos agentes.
Apesar das vantagens apresentadas pelo SNMPv2 ele apresenta algumas limitaes:
pouqussimo utilizado, sua complexidade implica em dificuldades de implementao e no
foi bem recebido pela comunidade de gerncia.

31

Figura 3.13 rvore do SNMPv2

3.6 O SNMPv3
Depois de muita controvrsia, o SNMv2 foi liberado como um framework SNMP,
SNMPv2C, sem qualquer implementao adicional de segurana. Esta deficincia foi
solucionada no SNMPv3. Os documentos do grupo de trabalho do SNMPv3 no so de fato
especificaes completas de um protocolo de gerenciamento de redes. Na verdade estes
documentos definem um conjunto de caractersticas de segurana e um framework que
poderia ser utilizado com as capacidades funcionais do SNMPv2 ou SNMPv1. (Stallings
1999, Subramanian 2000)
Uma das caractersticas chave do SNMPv3 a modularidade da documentao e
arquitetura. O projeto da arquitetura integrada das especificaes SNMPv1 e SNMPv2 com
as do SNMPv3. Esta integrao permite a continuao de uso do legado de SNMP por
agentes e gerentes SNMPv3.
O RFC 2571, documento que definiu a arquitetura do SNMPv3, define os seguintes
objetivos que guiaram seu desenvolvimento:


utilizar o trabalho existente. Os conceitos de segurana do SNMPv3 se baseiam

fortemente no SNMPv2u e SNMPv2*;

resolver o problema de segurana, principalmente para a operao set-request,

considerada a deficincia mais importante no SNMPv1 e SNMPv2C;

ser modular para possibilitar o desenvolvimento de parte da arquitetura, mesmo que o

consenso no tenha sido atingido no todo;

definir uma arquitetura que permita longevidade ao framework SNMP que j tenha
sido definido e que venha a ser definido no futuro;
32

manter o SNMP o mais simples possvel;

projetar uma arquitetura modular que permita a implementao sobre diversos

ambientes operacionais; e

acomodar modelos de segurana alternativos.

Um dos principais objetivos do SNMPv3 foi a rea de segurana. Autenticao,
privacidade, bem como a autorizao e controle de acesso foram incorporados na
especificao SNMPv3. O SNMPv3 projetado para prover segurana conta as seguintes
ameaas:

modificao da informao uma entidade poderia alterar uma mensagem em trnsito

gerada por uma entidade autorizada;

masquerade uma entidade no autorizada assumir a identidade de uma entidade

autorizada;

modificao de stream de mensagem como o SNMP projetado para operar sobre

um protocolo no orientado conexo, existe a ameaa de que as mensagens SNMP
possam ser reordenadas, atrasadas ou duplicadas;

descoberta uma entidade poderia observar trocas de mensagens entre gerentes e

agentes e aprender o valor de objetos gerenciados e eventos notificados.
O SNMPv3 no contm mecanismos de segurana contra duas ameaas:

denial of service uma pessoa poderia impossibilitar trocas de mensagens entre

gerente e agente;

anlise de trfego uma pessoa poderia observar o padro de trfego entre gerentes e
agentes.
A arquitetura SNMP, conforme definida no RFC 2571, consiste de uma coleo de
entidades SNMP distribudas e interagindo. Cada entidade implementa uma parte das
caractersticas do SNMP e pode atuar como um n agente, um n gerente ou uma
combinao dos dois. Cada entidade SNMP consiste de uma coleo de mdulos que
interagem entre si para prover servios.


A figura 3.14, definida no RFC 2571, mostra detalhes de uma entidade SNMP e seus
componentes:


dispatcher permite o suporte concorrente a mltiplas verses de mensagens SNMP

no engine SNMP;

message processing subsystem responsvel por preparar mensagens para envio e

extrair dados de mensagens recebidas;

security subsystem prov servios de segurana tais como autenticao e privacidade

de mensagens. Este subsistema pode conter mltiplos modelos de segurana;

access control subsystem prov um conjunto de servios que uma aplicao pode
usar para checagem de direitos de acesso;

33

command generator inicializa as PDUs SNMP (get, getnext; getbulk, setrequest) e

processa a resposta gerada para uma requisio;

command responder recebe as PDUs SNMP destinadas para o sistema local. A

aplicao command responder executar a operao apropriada do protocolo, usando o
controle de acesso, e gera a mensagem de resposta a ser enviada;

notification originator monitora o sistema por eventos e condies particulares e gera

mensagens (trap/inform) baseado nos eventos e condies. Devem existir mecanismos
para determinar para onde enviar as mensagens, qual verso do SNMP utilizar e quais
parmetros de segurana devem ser utilizados;

notification receiver ouve as mensagens de notificao e gera mensagens de resposta

quando uma mensagem contendo uma PDU inform recebida;

proxy forwarder repassa mensagens SNMP. Sua implementao opcional;

Figura 3.14 Entidade SNMPv3 (RFC 2571)

O formato das mensagens SNMPv3 consiste de quatro grupos, mostrados na figura 4.15.
O primeiro grupo um campo simples, que o nmero da verso e est na mesma posio
que no SNMPv1 e SNMPv2, o subsistema dispatcher verifica o nmero da verso e
encaminha para o modelo de processamento de mensagem apropriado. O segundo grupo,
denominado global/header data, contm parmetros administrativos da mensagem,
incluindo o modelo de segurana utilizado, vrios modelos so permitidos. O terceiro grupo
contm parmetros de segurana e usado pelo modelo de segurana na comunicao entre
entidades. O quarto grupo de dados contm os campos da PDU, conforme da verso do
SNMP utilizada, podendo estar criptografado ou em texto claro.

34

Figura 3.15 Formato de mensagens SNMPv3

O modelo de segurana do SNMPv3 um modelo de segurana baseado em usurios
(USM User-based Security Model) que reflete o conceito tradicional de nome de usurios
e senhas. A base de segurana no uso de esquemas de autenticao e privacidades so
chaves secretas. A chave secreta para autenticao derivada de uma senha escolhida pelo
usurio.
O controle de acesso trata de quem pode acessar os componentes de gerenciamento
das redes e o que pode ser acessado. Nas verses anteriores do SNMP, este tpico era
coberto pela poltica de acesso baseada em nomes de comunidade. No SNMPv3, o controle
de acesso tornou-se muito mais seguro e flexvel pela introduo do modelo de controle de
acesso baseado em viso (VACM View-based Access Control Model). O VCAM define
um conjunto de servios que uma aplicao em um agente podem usar para validar
comandos de requisio e notificao.

3.7 O SMON
Um switch um dispositivo de rede utilizado para reduzir a conteno e o
congestionamento da rede, comumente verificados em redes compartilhadas. Os switches
permitem tambm a comutao entre diferentes tecnologias (ethernet, token ring, fast
ethernet, etc.). Alm disso, comum a implementao de VLANs (Virtual LAN ou Redes
Locais Virtuais) em switches, de tal forma que diferentes redes locais possam coexistir em
um mesmo equipamento e uma mesma rede local virtual possa ser implementada por vrios
equipamentos, desde que os mesmos obedeam a um padro. Neste sentido foi
desenvolvido o padro de identificao de VLAN IEE 802.1Q.
A principal diferena entre gerenciar uma rede local compartilhada e uma rede com
switches o nvel de granularidade necessrio. Em redes tradicionais, o monitoramento de
desempenho, segurana e contabilizao pode ser feito monitorando-se uns poucos pontos
na rede, por onde flui o trfego. Em redes que utilizam switches, aumenta enormemente o
nmero de pontos, onde se faz necessrio o monitoramento, porque cada switch pode conter
vrios segmentos de rede.
Para contornar os problemas gerados pela excessiva segmentao de redes baseadas em
35

switch, pela implementao de priorizao de trfego e tambm pela criao de VLANs, foi
definido no RFC 2613 um padro que estende o RMON para adequ-lo melhor ao
gerenciamento de redes com switch. Este padro foi inicialmente definido pela Lannet e
denominado de SMON.
O SMON estende o conceito de fonte de dados, que na MIB II e RMON eram somente
instncias das interfaces, acrescentando VLANs e entidades fsicas, conforme definido no
RFC 2037, como a sub rvore 22 do RMON. Dessa forma, os grupos host e matrix do
RMON e seus similares do RMON 2, devem ser estendidos para suportar as novas fontes de
dados definidas no SMON.

4 Necessidades de Gerenciamento de Aplicaes de

Rede
Com a popularidade das redes de computadores hoje em dia, cada vez mais usurios
utilizam diferentes aplicaes de rede. O acesso Internet hoje j no mais considerado
um privilgio de poucos, e h quem diga que no mundo moderno no se pode mais viver
sem uma conexo Internet.
Dentro das organizaes, o uso mais intensivo de aplicaes de rede mudou
completamente o padro de uso das redes de computadores. Se antigamente as pessoas
utilizavam a rede para consultas espordicas a bancos de dados ou para o uso compartilhado
de um recurso caro, hoje as redes de computadores esto substituindo os meios de
comunicao tradicionais, como o prprio telefone.
Basta tomar como exemplo o caso da Universidade Federal de Santa Catarina (UFSC).
Hoje existem mais computadores na Universidade interligados em rede do que terminais
telefnicos, e esta diferena tende a aumentar.
Com tanta utilizao da rede de computadores nas mais diversas tarefas, bvio que o
trfego dentro da rede aumenta. Mas saber a quanto anda o trfego no suficiente para
saber o qu os usurios esto fazendo.
interessante conhecer quais so as aplicaes que mais consomem largura de banda da
rede, e que tipos de servios de informaes os usurios mais utilizam. Nos dias de hoje,
comum pensarmos que o maior trfego dentro da rede seja gerado pelos servios de
informao disponveis via WWW (World Wide Web). Entretanto, nada nos diz com
certeza de que este servio seja o maior devorador de largura de banda. Outros servios
essenciais como o terminal virtual (telnet), transferncia de arquivos (ftp) e o correio
eletrnico (e-mail) esto sendo utilizados a todo o momento.
Assim, para conhecer que aplicaes so responsveis por quais fatias de trfego na
rede, fazem-se necessrios mecanismos que permitam ao gerente de rede obter estas
informaes. As aplicaes de gerenciamento tradicionais somente so capazes de obter
informaes sobre o trfego total de cada mquina, com detalhamento dos protocolos de
transporte e de nveis inferiores.
Existem no mercado produtos que conseguem dar o trfego recebido e enviado pelos
servios executados nas mquinas servidoras, mas isto no suficiente. Nem sempre o
36

usurio est acessando mquinas servidoras da prpria rede da organizao. Portanto, medir
trfego nos servidores no mostra todo o trfego das aplicaes dos usurios pois, parte
deste trfego direcionada para servidores em outras redes.
O gerenciamento de cada mquina cliente da rede poderia fornecer informaes sobre o
que o usurio est usando, e dentro de cada rede seria possvel ter-se uma noo dos
padres de trfegos das aplicaes.
Dessa forma, o gerenciamento de aplicaes de rede pode ter dois enfoques:
Gerenciamento das estaes servidoras de aplicaes, isto , com enfoque nos servios.
Para esta situao j existe uma tentativa, proposta em janeiro de 1994 sob a forma da RFC
1565 [Kil 94] - Network Services Monitoring MIB. Esta proposta consiste de um mdulo
de MIB, em conformidade com a SMIv2, e que acrescenta 24 novos objetos para a
monitorao de servios de rede;
Gerenciamento das estaes clientes, com enfoque nas atividades dos softwares clientes.
No existe ainda nenhuma proposta no IETF neste sentido, mas boa parte do trabalho pode
ser aproveitada da RFC 1565 [Kil 94].
Segundo a RFC 1565 [Kil 94], o gerenciamento efetivo de servios Internet deve
satisfazer dois requisitos:

Deve ser possvel monitorar um grande nmero de componentes (tipicamente

para uma grande organizao); e

O monitoramento de aplicaes deve ser integrado ao gerenciamento de redes

genrico.

Para satisfazer a estes dois requisitos, o mdulo MIB proposto na RFC 1565 no inclui
nenhum objeto que permita o controle dos servios de rede em execuo, para que a
implementao seja facilitada. O monitoramento dos servios de rede est integrado ao
gerenciamento de redes genrico atravs do uso do modelo de gerenciamento SNMP.
Entretanto, o gerenciamento de aplicaes nos clientes de rede pode exigir algumas
situaes onde sejam necessrias funes de controle. Assim, um agente construdo para
este fim deve ser capaz de:
identificar as aplicaes clientes de rede em execuo;
monitorar as conexes ativas das aplicaes;
coletar estatsticas de conexes e informaes relacionadas;
controlar o estado operacional das conexes;
controlar o estado operacional de cada aplicao, sendo possvel, por exemplo,
suspender uma aplicao, restaur-la ao estado normal, abort-la, etc.;
ser programado para reportar a ocorrncia de eventos relativos a conexes de rede.
Um agente SNMP com estas caractersticas estaria envolvido em trs reas funcionais
(segundo o modelo OSI) do gerenciamento de redes:

1. Performance: a coleta de estatsticas atravs das funes de monitorao permite o

conhecimento do uso que os usurios fazem da rede;

37

2. Configurao: as funes de controle permitem que sejam configuradas nas

mquinas clientes quais servios de rede podem ou no ser utilizados. Tais
configuraes tm efeito no desempenho da rede;
3. Segurana: atravs das funes de controle e de reporte de eventos, a estao de
gerenciamento pode ser notificada da tentativa de uma estao cliente conectar a
hosts considerados no seguros, por exemplo.

4.1 Construo de novas MIBs

Criar novas definies de informao de gerenciamento uma tarefa que deve tornar-se
mais comum medida que novas tecnologias surgem e medida que a experincia com as
tecnologias existentes acumulada.
Definies de novos tipos de informao de gerenciamento podem ser criadas pelos
engenheiros que criaram a nova tecnologia, pelos engenheiros que desenvolvem as
aplicaes para gerenciar a tecnologia, e pelos gerentes de marketing de produtos que
representam as necessidades dos clientes (e usurios) do produto. Uma definio bem
sucedida se ela largamente difundida e se agrega valor a sistemas de gerenciamento. O
tempo tem mostrado que o sucesso inclui os seguintes ingredientes [Per 97]:
A definio deve ser escrita e disponibilizada amplamente a um custo insignificante;
Ela deve ser implementvel por desenvolvedores de agentes;
Ela deve ser implementvel por desenvolvedores de aplicaes de gerenciamento;
As implementaes de agentes e aplicaes devem ser interoperveis umas com as
outras;
Os resultados obtidos da aplicao devem possuir um valor maior do que o custo do
sistema (e da rede) em termos de recursos necessrios para executar a aplicao.
Para atingir estes objetivos, a pessoa ou grupo que esteja escrevendo as novas definies
devem possuir uma certa experincia e habilidade com o assunto, incluindo [Per 97]:

Conhecimento de como escrever definies vlidas;

Conhecimento da tecnologia a ser gerenciada;
Compreenso de como a tecnologia precisa ser gerenciada;
Compreenso dos custos de implementao de vrias tcnicas usadas para escrever
definies tanto em agentes como em aplicaes de gerenciamento;

A habilidade de, concisa e precisamente, escrever as definies de forma que elas

sejam interpretadas com o mesmo significado pela maioria dos leitores (pessoas)
das definies;

A habilidade de escrever as definies em um nvel de abstrao de forma que elas

possam ser estendidas e aplicadas para reas para as quais no se tinha pensado, e
ainda em um nvel de abstrao que possa ser eficientemente entendido e aplicado
gerao atual de tecnologia.

Novos objetos podem ser adicionados a uma MIB SNMP atravs de uma entre trs
maneiras diferentes [Sta 93]:

38

1. A sub-rvore mib-2 pode ser expandida ou completamente trocada por uma nova
reviso (provavelmente seria chamada de mib-3). Um exemplo de expanso da MIB
a RMON MIB [Wal 95];
2. Uma MIB experimental pode ser construda para uma aplicao particular. Tais
objetos podem ser subseqentemente movidos para a sub-rvore mgmt. Exemplos
disso so as vrias MIBs especficas a tipos de enlaces que tm sido definidas, como
a IEEE 802.5 token ring LAN (RFC 1231);
3. Extenses privadas podem ser adicionadas sub-rvore private. Uma que est
documentada em uma RFC a MUX (multiplexer) MIB (RFC 1227).

5 Gerncia de Redes de Telecomunicaes

As operadoras de servios de telecomunicaes passam por uma fase de transio entre
um ambiente de monoplio para um ambiente onde a desregulamentao do mercado
incentiva a concorrncia e a oferta de novos e sofisticados servios. A sobrevivncia neste
mercado requer um conhecimento slido das tecnologias emergentes e uma viso clara de
como administrar os recursos existentes para aumentar a relao entre o custo do sistema
implantado e a receita obtida junto aos usurios.
Caso o fator qualidade no estivesse envolvido, este relacionamento seria facilmente
equacionado. No entanto, quando se deseja um relacionamento envolvendo os trs fatores
custo X qualidade X lucro, fundamental que se tenha uma poltica de gerenciamento com
objetivos bem definidos e com uma perfeita integrao das informaes vitais para o
alcance de um resultado satisfatrio.
O ambiente de telecomunicaes bastante complexo para que se tenha uma viso
simplista de administrao. Neste sentido, o ITU-T apresentou uma srie de recomendaes
que visam organizar este ambiente e orientar as operadoras e fornecedores de equipamentos
e servios de telecomunicaes atravs de um modelo de gerenciamento. No entanto, uma
das tarefas mais difceis consiste, exatamente, em organizar este conjunto de informaes
de forma a torn-lo aplicvel em um ambiente real de uma rede de telecomunicaes.
Em primeiro lugar, importante ficar claro que o gerenciamento de um ambiente de
telecomunicaes foi estruturado segundo uma hierarquia composta de 5 nveis e ilustrada
pela figura 5.1:

39

Responsvel por dar uma viso geral do

Gerncia do
Negcio
Gerncia do
Servio

negcio ou da empresa

Responsvel pelos gerncia dos

servios oferecidos aos clientes ou para
outros servios oferecidos

Gerncia da Rede

Responsvel pelos gerncia da rede

Coleta informao de elementos

Gerncia do Elemento da Rede

gerenciados da rede individualmente, ou

seja, gerencia cada elemento da rede

Elementos da Rede

Sistema agente OSI, diretamente conectado

ao gerenciador de recursos, o prprio
elemento da rede

Figura 5.1 - Hierarquia de gerenciamento

Entender esta hierarquia o primeiro passo para se chegar a um sistema de
gerenciamento eficaz. Esta hierarquia aplicvel no s no ambiente de Telecomunicaes
mas, tambm, em qualquer ambiente que tenha uma rede como suporte s suas atividades.
Em primeiro lugar, deve ficar bem claro qual o negcio da empresa. No caso de uma
empresa operadora de servios de telecomunicaes, fica bvio que o negcio o
fornecimento de servios de telecomunicaes e que este fornecimento deve ser realizado
de forma competitiva e que deve apresentar resultados satisfatrios em termos de receita.
Gerenciar um negcio de telecomunicaes implica em investimentos em novas tecnologias
para o fornecimento de novos servios antes mesmo que estes servios sejam exigidos pelos
usurios. fundamental, portanto, que existam ferramentas para possibilitar o planejamento
de novos servios, amparadas por um eficiente estudo de tendncias de mercado. Fica claro
que, neste contexto, devem ser utilizadas as tcnicas de marketing e administrao como
seriam utilizadas em qualquer outra empresa, independentemente do tipo de negcio a que
ela se dedica.
Uma vez identificados os objetivos a serem alcanados pela empresa, deve-se focalizar
o conjunto de servios de telecomunicaes que sero comercializados. Nesta etapa,
importante que se defina claramente quais os objetivos de cada um dos servios em termos
de funcionalidades, disponibilidade, custo, qualidade e, se possvel, tempo de vida. De
posse destas informaes, possvel planejar a tarifao de cada servio, considerando-se
fatores tais como nmero de usurios, nveis de qualidade oferecidos e at mesmo a
existncia de servios alternativos.
A oferta de um servio de telecomunicao depende da existncia de tecnologias
que o suportem e do custo destas tecnologias. Muitas vezes um determinado servio possui
custos proibitivos e a empresa deve aguardar pelo surgimento de solues alternativas ou
mesmo, caso este seja um dos objetivos da empresa, investir em pesquisas por novas
solues.

40

Uma vez instalado, um servio de telecomunicao deve ser constantemente

observado para a identificao de fatores que possam influenciar em seu desempenho. A
gerncia de um servio de telecomunicao implica, portanto, em uma contnua
monitorao de parmetros relacionados com taxa de utilizao, disponibilidade, qualidade,
custos associados e desempenho. Os desvios observados devem ser corrigidos o mais
rapidamente possvel, a fim de evitar perdas de receitas ou mesmo descontentamento de
seus usurios. Para que a gerncia de um servio seja completa, necessrio que o sistema
de gerncia tenha acesso s informaes relativas infraestrutura de suporte ao servio.
Problemas relacionados com a infraestrutura de suporte devem ser reportados ao sistema de
gerncia do servio para que aes corretivas ou alternativas sejam realizadas.

6 A arquitetura de gerenciamento OSI

A arquitetura de gerenciamento OSI define:
 as estruturas de gerenciamento passveis de serem empregadas
 os componentes de um sistema de gerenciamento
 a estrutura da informao de gerenciamento
 os servios e protocolos para troca de informaes de gerenciamento

6.1 Estruturas de gerenciamento

A estrutura de gerenciamento refere-se aos trs enfoques definidos pela ISO em seu
framework [ISO 7498-4]: Gerenciamento de Sistemas, Gerenciamento de Camada e
Operao de Camada.
O Gerenciamento de Sistemas, conforme apresentado na figura 5.1, foi idealizado
para monitorar e controlar o sistema como um todo. Para tanto, prev funes de
gerenciamento em todas as camadas da pilha de protocolos e seu escopo de abrangncia o
mais completo.

41

processo gerente

processo agente

CMIP

SMAE

SMAE

MIB
LME

APLICAO

LME

APLICAO

LME

APRESENTAO

LME

APRESENTAO

LME

SESSO

LME

SESSO

LME

TRANSPORTE

LME

MIB

TRANSPORTE

LME

REDE

LME

REDE

LME

ENLACE

LME

ENLACE

LME

FSICO

LME

FSICO

Figura 6.1 Gerenciamento de Sistemas

O Gerenciamento de Camada consiste na monitorao e controle dos recursos de uma
camada de forma isolada e independente, conforme ilustrado na figura 5.2. Pode-se, por
exemplo, enfocar aspectos da camada de transporte, analisando-se o nmero de conexes
estabelecidas com sucesso e o nmero de tentativas, sem sucesso, de estabelecimento de
conexes, para identificar situaes de sobrecarga ou ociosidade nos sistemas. Esta
abordagem, no entanto, no contempla um relacionamento com as atividades das outras
camadas de protocolo; ela til para controlar recursos que, por sua natureza, no suportam
uma arquitetura completa (todas as sete camadas do RM-OSI).

camada N

protocolodegerenciamento
da camada N

camada N

Figura 5.2 Gerenciamento de Camada

A estrutura de Operao de Camada, mostrada na figura 5.3, restringe-se monitorao

e controle de uma nica instncia de comunicao. Neste caso, as informaes de
gerenciamento so concernentes uma conexo. Por exemplo, na camada de transporte,
pode-se ter vrias conexes ativas; a operao de camada trata da gerncia de cada uma
destas conexes, de forma independente. Esta estrutura se aplica quando desejvel que,
por exemplo, o usurio fique encarregado de gerenciar a sua prpria conexo.

42

operao de
camada

conexo 1
conexo 2
...
conexo n

Figura 5.3 Operao de Camada

6.2 Componentes de gerncia OSI

O ambiente de gerenciamento OSI composto por elementos gerenciados, agentes e
gerentes. Os elementos gerenciados so representados por objetos gerenciados, seguindo o
paradigma da Abordagem de Orientao a Objetos. Os agentes e gerentes so entidades
usurias do servio de gerenciamento OSI e so denominados de MIS-Users (Management
Information Service - Users). Os papis assumidos por estas entidades no so fixos, isto ,
um MIS-User pode executar o papel de gerente em um contexto, definido por uma
associao, e um papel de agente em outro contexto, definido por outra associao. A figura
2.4 ilustra um possvel cenrio de um ambiente de gerenciamento OSI.
No modelo de gerenciamento OSI, o nmero de associaes estabelecidas entre os MISUser considerado uma questo local, dependente de implementao. Conforme mostra a
figura 5.4, pode-se ter um gerente associado a vrios agentes e um agente associado a vrios
gerentes. Estas associaes so estabelecidas com a finalidade de trocar informaes de
gerenciamento.
Gerente
Agente

Gerente
Agente

Agente

Gerente

Figura 5.4 Componentes do Gerenciamento OSI

6.3 Estrutura da informao de gerenciamento

As informaes de gerenciamento so organizadas em bases de dados. O conjunto das
bases de dados de informaes de gerenciamento denominado MIB (Management
Information Base), e a sua implementao no est sujeita padronizao. As informaes
so definidas segundo uma SMI (Structure Management Information). No modelo de
43

gerenciamento OSI, a SMI estabelece que a forma de representao das informaes deve
seguir o modelo de orientao a objetos, considerando trs hierarquias: hierarquia de
herana, hierarquia de nomeao ou de containment e hierarquia de registro.

6.4 Servios e protocolos de comunicao

A comunicao entre as entidades de gerenciamento Gerente e Agente realizada pelo
protocolo CMIP (Common Management Information Protocol), definido em [ISO/IEC
9596].
No caso especial de gerenciamento de redes de telecomunicaes, tambm permitida a
utilizao do protocolo FTAM (File Transfer Access and Management) para a transferncia
de informaes de gerenciamento entre agentes e gerentes. Esta facilidade tornou-se
essencial devido necessidade de transferncia de grandes quantidades de dados neste
ambiente.
Os servios de gerenciamento disponveis para as entidades gerentes e agentes so
definidos pelo CMIS (Common Management Information Service), descrito em [ISO/IEC
9595]. Neste documento so definidos dois servios de gerenciamento: o servio de
operaes de gerenciamento e o servio de notificaes de gerenciamento. As operaes de
gerenciamento so emitidas pelos MIS-Users (Management Information Service - Users),
que so entidades de gerenciamento no papel de gerente; as notificaes so emitidas pelos
MIS-Users (Management Information Service - Users) que assumem o papel de agente. A
figura 5.5 mostra um cenrio de comunicao onde so trocadas operaes e notificaes de
gerenciamento.

MIS-User
(papel de
gerente)

Operaes de
gerenciamento
Notificaes

Controle de
Acesso
Disseminao
Notificao
MIS-User
(papel de agente)

Objetos
Gerenciados

Figura 5.5 Servios de Gerenciamento

As operaes de gerenciamento podem sofrer um controle de acesso dependendo da

especificao dos objetos gerenciados, isto , dependendo da definio do objeto, a
operao pode ter sucesso ou ser negada ao MIS-User solicitante. Na figura 5.5, observa-se
que existe uma funo de controle de acesso associada ao MIS-User agente. Esta funo

44

tem como objetivo principal, autenticar o Gerente na solicitao de uma associao e

verificar sua autoridade na execuo de operaes de gerenciamento. Mais detalhes desta
funo sero apresentados no captulo 5 onde descrita a Funo de Controle de Acesso no
Modelo Funcional de Gerenciamento OSI.
As notificaes representam informaes sobre eventos ocorridos no sistema gerenciado
e so enviadas ao destinatrio atravs da utilizao do servio M-EVENT-REPORT,
definido no CMIS. Na figura 5.5, pode-se observar a funo de disseminao de
notificaes que consiste em um suporte funcional ao MIS-User agente para a identificao
dos destinatrios para os quais devem ser repassadas as notificaes geradas pelos objetos
gerenciados. A tabela 5.1 mostra as primitivas de servio de gerenciamento definidas pelo
CMIS.
Embora uma notificao possa ser gerada como efeito colateral de uma operao de
gerenciamento, ela no pode ser considerada como uma resposta a uma operao. As
operaes de gerenciamento so emitidas por iniciativa de um gerente. Se uma operao de
gerenciamento for solicitada no modo confirmado, ento ela ser respondida atravs das
primitivas response e confirm; caso contrrio, nenhuma resposta ser gerada. Uma
notificao emitida por iniciativa do MIS-User agente que, por sua vez, pode solicitar este
servio no modo confirmado ou no confirmado.

45

Tabela 5.1 Servios de Gerenciamento

Tipo de servio
M-CANCELGET

Modo
requisio

de

confirmado

(operao)
M-GET

(operao)
no
confirmado
M-CREATE

request/indicatio

Modificar
n
valores
de
de
response/confirm atributos
objetos
request/indicatio
n
n

confirmado
n

(operao)

Ler valores
de atributos de
response/confirm objetos
request/indicatio

confirmado

(operao)
M-ACTION

Cancelar uma
n
operao
de
leitura realizada
response/confirm
sobre
vrios
objetos
n

confirmado

Semntica

request/indicatio

confirmado

(operao)
M-SET

Primitivas

no
confirmado

request/indicatio

Criar
instncia
response/confirm objeto

uma
de

request/indicatio

que
prseja
por

Solicitar
uma ao
response/confirm definida
executada
um objeto
request/indicatio

n
M-DELETE

confirmado

(operao)
no
confirmado

request/indicatio

Destruir uma
n
instncia
de
objeto
response/confirm
request/indicatio
n

M-EVENTREPORT

confirmado

(notificao)

request/indicatio

Notificar
a
n
ocorrncia de um
response/confirm evento a um
sistema gerente

no
confirmado

request/indicatio
n
46

n
Resumo
Pode-se resumir este conjunto de definies, da seguinte forma:
As estruturas de gerenciamento que podem ser empregadas no modelo de gerenciamento
OSI so: Gerenciamento de Sistemas (abrange todas as camadas), Gerenciamento de
Camada (abrange apenas uma camada) e Operao de Camada (abrange apenas uma
instncia de comunicao).
Os componentes de um sistema de gerenciamento OSI so: MIS-Users (que podem
assumir o papel de Gerente ou de Agente), e os Objetos Gerenciados (que representam os
recursos sujeitos ao gerenciamento).
Os Servios de Gerenciamento disponveis so as Operaes e as Notificaes.
Dependendo de sua natureza, podem ser solicitados no modo confirmado ou no
confirmado.
O Protocolo para transferncia das informaes de gerenciamento o CMIP e, no caso
de Sistemas de Telecomunicaes, pode ser utilizado o protocolo FTAM em lugar do
CMIP.
A Informao de Gerenciamento definida seguindo a AOO-Abordagem de Orientao
a Objetos e armazenada em uma MIB.

7 Servios de suporte comunicao

A camada de aplicao OSI definida para suportar diferentes aplicaes. No modelo
de referncia OSI, a camada que d suporte para os aplicativos (ou aplicaes) dos
usurios. Os aplicativos que fazem o verdadeiro trabalho para o qual os computadores
foram adquiridos. Os aplicativos utilizam-se dos servios da camada de aplicao para suas
necessidades de comunicao.
Um Processo de Aplicao (AP - Application Process) um processo que roda na
camada de aplicao e uma Entidade de Aplicao (AE) representa os aspectos de
comunicao dos processos de aplicao.
Vrios agrupamentos de funcionalidades foram definidos para preencher as
necessidades das aplicaes. Um elemento de servio de aplicao (ASE - Application
Service Element) um agrupamento que suporta um conjunto de necessidades de
comunicao de uma aplicao. Cada AE composta por um ou mais elementos de servio
de aplicao (ASEs). Alguns exemplos de ASEs so o ACSE - Association Control Service
Element (usado para estabelecer e gerenciar uma associao entre entidades pares de
aplicao), o ROSE - Remote Operation Service Element (usado para a execuo de
operaes remotas), o RTSE - Reliable Transfer Service Element (oferecendo um servio de
transferncia confivel), o CCR - Commitment Concurrency and Recovery (que possibilita
a execuo de vrias operaes de uma forma atmica).

47

Alguns processos de aplicao (APs), tais como o FTAM - File Transfer Access
Management (usado para a transferncia e manipulao remota de arquivos) e o MHS Message Handling System (usado para a transferncia e manipulao de mensagens)
tambm so utilizados por outras aplicaes devido s facilidades que eles oferecem.

48

7.1 Elementos de Servio para aplicaes de gerenciamento

Uma aplicao de gerenciamento, como qualquer outra aplicao no Modelo OSI,
utiliza-se dos servios oferecidos pelos elementos de servio ASEs (Application Service
Element) da camada 7 do RM-OSI (Reference Model - Open System Interconnection).
Para o caso especial da aplicao de gerenciamento, dois elementos de servio
genrico so necessrios: o ACSE (Association Control Service Element), que oferece
servios para o estabelecimento e controle das associaes de gerenciamento e o ROSE
(Remote Operations Service Element) que fornece servios para a execuo de operaes
remotas.
Alm destes elementos de servio, dois outros so definidos para dar suporte s
aplicaes de gerenciamento: o CMISE (Common Management Information Service
Element) e o SMASE (System Management Application Service Element).
O CMISE constitudo de uma descrio de servios (CMIS) e da definio do
protocolo de gerenciamento CMIP. Os servios obrigatrios oferecidos por este elemento
de servio possibilitam a criao de um objeto (servio M-CREATE), a destruio de um
objeto (servio M-DELETE), a execuo de uma ao sobre um objeto (servio MACTION), a leitura de valores de atributos de um objeto (servio M- GET) e a modificao
de valores dos atributos de um objeto (servio M-SET). Embora o CMISE tenha sido
desenvolvido para dar suporte ao gerenciamento de entidades de comunicao OSI, devido
ao poder de suas facilidades, tem sido aplicado, tambm, no gerenciamento de redes de
telecomunicaes. Uma descrio mais detalhada deste elemento de servio realizada no
captulo 4.
O SMASE um elemento de servio que apresenta facilidades relacionadas com a
funcionalidade da aplicao de gerenciamento. Nele esto agrupados os servios oferecidos
pelas funes de gerenciamento definidas na srie de recomendaes ISO/IEC 10164 - X |
ITU-T X.700. Existem vrias funes de gerenciamento definidas e, entre elas, a funo de
gerenciamento de objetos OMF - Object Management Function assume um papel
fundamental no cenrio do gerenciamento por oferecer servios de pass-throught para as
demais funes de gerenciamento acessarem os servios CMIS. Esta funo e as demais
funes que compem o SMASE sero abordadas no captulo 5. Para efeitos de clareza na
descrio do fluxo da informao de gerenciamento, basta, por enquanto, observar a tabela
6.1 que mostra como os servios de gerenciamento podem ser solicitados para o SMASE
(atravs da OMF) e o seu respectivo mapeamento para as primitivas de servio do CMISE.

49

Tabela 7.1 - Servio de Pass-throught

Servios
Servio de passCMISE
throught da OMF

Servio solicitado
Criao de objeto: Create

PT-CREATE

M-CREATE

Destruio de objeto: Delete

PT-DELETE

M-DELETE

PT-ACTION

M-ACTION

Modificao de valor de
atributo: Replace

PT-SET

M-SET

Modificao de valor de
atributo: Replace-with-default

PT-SET

M-SET

Modificao de valor de
atributo: Add

PT-SET

M-SET

Modificao de valor de
atributo: Remove

PT-SET

M-SET

Leitura de valor de atributo:

Get

PT-GET

M-GET

PT-EVENTREPORT

M-EVENTREPORT

Ao
Action

sobre

Notificao

um

objeto:

do

Na figura 7.1 esto representados os elementos de servio ACSE, ROSE, SMASE e

CMISE, utilizados por uma aplicao de gerenciamento, com as respectivas primitivas de
servio.
Para garantir um perfeito entendimento do fluxo das informaes de gerenciamento
trocadas entre gerentes e agentes, necessrio conhecer, com detalhes, os elementos de
servio envolvidos. Com este objetivo, os tens 7.1.1 e 7.1.2 apresentam aspectos
importantes dos elementos de servio ACSE e ROSE.

50

Aplicao de
gerenciamento

Aplicao de
gerenciamento
A
SMASE
C
CMISE
S
E
ROSE
outras camadas

SMASE
CMIP - PDU

CMISE

A
C

S
ROSE E
outras camadas

Primitivas oferecidas pelos elementos de servio:

ACSE
A-ASSOCIATE
A-RELEASE
A-ABORT

ROSE
RO-INVOKE
RO-RESULT
RO-ERROR
RO-REJECT

SMASE (OMF)
PT-GET
PT -SET
PT -CANCEL-GET
PT -ACTION
PT -CREATE
PT -DELETE
PT -EVENTREPORT

CMISE
M-GET
M-SET
M-CANCEL-GET
M-ACTION
M-CREATE
M-DELETE
M-EVENTREPORT

Figura 7.1 Elementos de Servio para o suporte s aplicaes de gerenciamento

7.1.1. Controle de Associao (ACSE)
A funo principal do ACSE prover facilidades bsicas para o controle de uma
associao de aplicao entre duas entidades de aplicao, as quais se comunicam por meio
de uma conexo realizada na camada de apresentao.
Os servios ACSE so providos pelo uso do protocolo ACSE em conjunto com os
servios P-CONNECT, P-RELEASE, P-U-ABORT e P-P-ABORT da camada de
apresentao.
A fim de efetuar o controle de uma associao de aplicao, o ACSE prov os seguintes
servios:
A-ASSOCIATE usado para prover o incio do uso de uma associao. Este um servio
confirmado e possui os seguintes parmetros:
Modo;
Nome do Contexto de Aplicao;
Ttulo do AP(Application Process) Chamador;
Qualificador da AE Chamadora;
Identificador de Invocao do AP Chamador;
51

Identificador de Invocao da AE Chamadora;

Ttulo do AP Chamado;
Qualificador da AE Chamada;
Identificador de Invocao do AP Chamado;
Identificador de Invocao da AE Chamada;
Ttulo do AP Respondente;
Qualificador da AE Respondente;
Identificador de Invocao do AP Respondente;
Identificador de Invocao da AE Respondente;
Informao do Usurio;
Resultado;
Fonte do Resultado;
Diagnstico;
Endereo de Apresentao Chamador;
Endereo de Apresentao Chamado;
Endereo de Apresentao Respondente;
Lista de Definio do Contexto de Apresentao;
Lista do Resultado de Definio do Contexto de Apresentao;
Nome do Contexto de Apresentao Default;
Resultado do Contexto de Apresentao;
Default;
Qualidade do Servio;
Requerimentos de Apresentao;
Requerimentos de Sesso;
Nmero Serial do Ponto de Sincronizao Inicial;
Especificao Inicial de Tokens;
Identificador de Conexo de Sesso.
A-RELEASE: usado por um usurio de servios ACSE para prover a finalizao normal
do uso de uma associao. Opcionalmente, o usurio receptor pode responder
negativamente ao pedido de finalizao da associao. Este um servio confirmado e
possui os seguintes parmetros:
Razo;
Informao do Usurio;

52

Resultado.
A-ABORT: um usurio de servios ACSE se utiliza deste servio para provocar a
liberao anormal de uma associao, com possvel perda de informao. Este um servio
no confirmado e possui os seguintes parmetros:
Fonte do Aborto;
Informao do Usurio.
A-P-ABORT: usado pelo provedor de servios ACSE para indicar a liberao anormal
de uma associao, a qual provocada por problemas em servios das camadas inferiores
camada de aplicao. Sua ocorrncia indica uma possvel perda de informao. Este um
servio iniciado pelo provedor e possui o seguinte parmetro:
Razo do Provedor.
A cada usurio ACSE est associada uma mquina de protocolo de controle de
associao (ACPM) que ir prover os servios ACSE atravs da camada de apresentao.
Dados especficos das primitivas de servio so passados atravs das unidades de dados do
protocolo de aplicao (APDUs), conforme ilustrado na tabela 6.2.
Tabela 7.2 Mapeamento das primitivas de servio do ACSE em APDUs
Primitiva
APDU
A-ASSOCIATE. Request

AARQ

A-ASSOCIATE. Response

AARE

A-RELEASE. Request

RLRQ

A-RELEASE.response

RLRE

A-ABORT. Request

ABRT

Essas APDUs so enviadas como dados de usurio nas primitivas dos servios de
apresentao.
Conforme descrito anteriormente, o ACSE o elemento de servio que gerencia
associaes entre processos de aplicao. Uma associao corresponde a uma conexo de
apresentao com a adio de alguma semntica da camada de aplicao. Cada associao
estabelecida especfica a uma dada aplicao. Todas as entidades de aplicao OSI
contm um ACSE, uma vez que, at a presente data, todas as aplicaes definidas pelo RMOSI so orientadas conexo.
A entidade que solicita um pedido de associao de aplicao chamada de entidade
iniciadora e a entidade que aceita um pedido de associao de aplicao chamada de
entidade respondedora.
Uma vez que o conceito de embedding empregado nas trs camadas superiores,
conexes de aplicao, apresentao e sesso ocorrem ao mesmo tempo.

53

Os servios do ACSE so alcanados pela invocao de suas primitivas de servio,

relacionadas na tabela 7.3.

Primitiva
AASSOCIATE
A-RELEASE

Tabela 7.3 Primitivas do ACSE

servio oferecido

tipo
servio

de

Estabelece uma associao

confirmado

Libera uma conexo

confirmado

A-ABORT

Encerramento
usurio

iniciado

pelo

A-P-ABORT

Encerramento
provedor

iniciado

pelo

nno
confirmado
s indicao

7.1.2.Operaes Remotas (ROSE)

O elemento de servio ROSE oferece servios de suporte s aplicaes interativas. De
uma forma geral, opera de maneira equivalente a uma chamada de procedimento remoto
(RPC - Remote Procedure Call).
Este elemento de servio bastante til no suporte s aplicaes distribudas.
Existe sempre uma aplicao que solicita a execuo de uma operao a outra aplicao,
que pode devolver ou no o resultado correspondente.
A entidade que solicita uma operao chamada entidade invocadora e a que recebe a
solicitao chamada entidade executora.
importante observar que as entidades de aplicao somente podem utilizar os servios
do ROSE se j houver uma associao de aplicao estabelecida. Neste caso, podem existir
3 classes de associao:
Classe 1: somente a entidade iniciadora da associao pode invocar operaes.
Classe 2: somente a entidade respondedora da associao pode invocar operaes.
Classe 3: ambas as entidades, iniciadora e respondedora da associao, podem invocar
operaes.
So definidas, tambm, cinco classes de operao, que so caracterizadas pelo tipo de
interao (sncrona ou assncrona) e pelo comportamento da entidade executora. O tipo de
interao diz respeito forma como a entidade iniciadora se comporta aps a solicitao de
uma operao, isto , se fica bloqueada aguardando o resultado da operao (operao
sncrona) ou se fica livre para executar outras operaes (operao assncrona). O
comportamento da entidade executora modelado em termos de emisso de uma resposta
operao (sucesso ou falha da operao) ou se nenhum resultado emitido (operao no
confirmada). A tabela 7.4 ilustra as possveis classes de operaes no ROSE.
54

55

Tabela 7.4 - Classes de operao definidas no ROSE

Classe
operao

de Tipo de interao

Forma de resposta

Operao classe sncrona

relatando sucesso ou falha

Operao classe assncrona

relatando sucesso ou falha

Operao classe assncrona

relatando somente falha

Operao classe assncrona

relatando somente sucesso

Operao classe assncrona

resultado no relatado

1
2
3
4
5
O ROSE geralmente utilizado por aplicaes envolvendo o servio de mensagens
MHS (Message Handling Service), o servio de diretrio DS (Directory Service) ou o
servio de informao de gerenciamento CMIS. O usurio do ROSE dispe de um
conjunto de primitivas de servio descritas na tabela 6.5.
Tabela 7.5 - Primitivas de servio do ROSE
Primitiva
ROINVOKE
RORESULT
RO-ERROR

Significado

Tipo
servio

Invoca uma operao

no
confirmada

Resultado
sucedida

de

operao

bem

no
confirmada

Resultado
sucesso

de

operao

sem

no
confirmada

ROREJECT-U

Rejeio iniciada pelo usurio

ROREJECT-P

Rejeio iniciada pelo provedor

de

no
confirmada
s indicao

Protocolo ROSE
Para cada servio iniciado pelo usurio do ROSE criada uma APDU ROSE, que
mapeada para a primitiva RT-TRANSFER do RTSE ou para o servio P-DATA de
apresentao.
56

7.2 Fluxo da informao de gerenciamento

Uma aplicao de gerenciamento (exercendo o papel de gerente ou de agente), solicita
uma associao com uma entidade par, atravs da primitiva de servio de associao AASSOCIATE.request oferecida pelo ACSE, indicando as unidades funcionais que suporta e
outras informaes relevantes para a associao a ser estabelecida. A entidade par responde
ao pedido atravs da primitiva A-ASSOCIATE.response, confirmando ou negando o
estabelecimento da associao. A fase de troca de informaes de gerenciamento s pode
ser iniciada caso a associao tenha sido estabelecida com sucesso. Na resposta afirmativa
para o estabelecimento da associao, a entidade respondedora confirma ou restringe o
conjunto das funcionalidades que podem ser utilizadas nesta instncia de associao. A
figura 7.2 mostra um exemplo de fluxo de informaes em uma associao entre duas
entidades de aplicao de gerenciamento.

MIS-User
local

ACSE
local

outras
camadas

ACSE
remoto

MIS-User
remoto

A-Assoc.req
PConnect.req
PConnect.ind
A-Assoc.ind
A-Assoc.resp
PConnect.resp
PConnect.conf
AAssoc.conf

57

Figura 7.2 - Fase de Associao entre dois MIS-Users

O elemento de servio CMISE composto da especificao de um conjunto de servios
denominado CMIS (Common Management Information Service) e de um protocolo
denominado CMIP (Common Management Information Protocol). O CMIS composto de
um conjunto de primitivas que oferecem servios para a criao (M-CREATE) e destruio
(M-DELETE) de objetos gerenciados, para a execuo de aes (M-ACTION) sobre objetos
gerenciados e, ainda, operaes de leitura (M-GET) e modificao (M-SET) de valores de
atributos de objetos gerenciados. Um servio para o cancelamento de um pedido de leitura
de valores de atributos de vrios objetos (M-CANCEL-GET) oferecido de modo opcional,
isto , o suporte a este servio no obrigatrio.
As operaes e notificaes de gerenciamento so solicitadas diretamente ao
CMISE (que utiliza os servios oferecidos pelo ROSE) ou, em sistemas que apresentam
alguma funcionalidade, ao SMASE. O CMISE utiliza os servios oferecidos pelo ROSE
para transferir as operaes e notificaes para o MIS-User remoto. No caso de serem
solicitadas ao SMASE, estas so repassadas por um servio de Pass-Through para o
CMISE. O servio de Pass-Through para as operaes e notificaes de gerenciamento
oferecido pela Funo de Gerenciamento de Objetos, denominada OMF (Object
Management Function). A figura 7.3 mostra o cenrio de comunicao entre dois MISUsers, na solicitao de uma leitura de valor de atributo.

58

GERENTE
1

AGENTE

16

Aplicao

Aplicao
SMASE

A
C
S
E

SMASE

15

CMISE

A
C
S
E

CMISE
3

10

14

11

ROSE

ROSE
5

13

12

Apresentao

Apresentao
outras camadas

Do Gerente para o Agente

Do Agente para o Gerente

PT-Get. request

PT-Get. response

M-GET. request

M-Get. response

RO-INVOKE.

RO-RESULT. request

request

P-Data. request

P-Data. request

P-Data.indication

P-Data. indication

RO-INVOKE.indication

RO-RESULT. indication

M-Get. indication

M-Get.confirm

PT-Get. indication

PT-Get.confirm

Figura 7.3 Cenrio de comunicao para a operao de leitura de valor de atributo

59

7.3 Conhecimento de Gerenciamento Compartilhado

Quando duas entidades de aplicao de gerenciamento estabelecem uma associao para
troca de informaes de gerenciamento, necessrio que seja identificado um
Conhecimento de Gerenciamento Compartilhado (SMK - Shared Management Knowledge)
a fim de garantir uma compatibilidade entre os dois sistemas comunicantes. Um
conhecimento de gerenciamento compartilhado inclui:
 informaes sobre os objetos gerenciados que so visveis para aquela aplicao;
 o protocolo a ser utilizado na troca de informaes de gerenciamento;
 as funes e unidades funcionais suportadas;
 as restries nas unidades funcionais.
Os objetos gerenciados visveis para uma determinada aplicao, constituem uma viso
da MIB e as informaes sobre eles incluem as classes s quais eles pertencem,
identificao das instncias e restries de acesso.
O protocolo de gerenciamento a ser utilizado pode ser o CMIP ou o FTAM ou ainda
algum outro protocolo que possa vir a ser definido no futuro.
As unidades funcionais so, portanto, as unidades bsicas de negociao entre MISUsers e consistem em agrupamentos de servios de funes de gerenciamento. Uma
funcionalidade pode ser alcanada em uma ou mais unidades funcionais; neste caso,
algumas restries podem ser estabelecidas.
Unidades funcionais que atravessam os limites de uma funo, podem suportar os
seguintes conjuntos de capacidades:
 somente notificaes;
 somente operaes de gerenciamento;
 notificaes e operaes de gerenciamento.
As Unidades Funcionais definidas at o momento, so:
 Kernel (obrigatria) oferece os servios de criao e destruio de objetos
gerenciados, execuo de uma ao sobre um objeto gerenciado, leitura e
modificao de valores de atributos e emisso de notificaes.
 Cancel Get (opcional) permite o cancelamento de uma operao de leitura quando
esta for realizada sobre mltiplos objetos.
 Scoping (opcional) fornece a facilidade de seleo de um conjunto de objetos sobre
os quais uma determinada operao de gerenciamento deve ser aplicada. Esta
unidade funcional s pode ser utilizada se a unidade funcional Multiple Objects
Selection tambm tiver sido selecionada para utilizao. O escopo pode ser definido

60

considerando-se uma sub-rvore completa ou apenas um nvel particular da subrvore. A raiz da sub-rvore indicada pelo identificador de um objeto gerenciado
(chamado, neste caso, de objeto gerenciado base).
 Filter (opcional) fornece a possibilidade de se estabelecer condies que devem ser
satisfeitas por um objeto gerenciado a fim de que a operao de gerenciamento possa
ser executada sobre ele.
 Multiple Reply (opcional) permite que vrias respostas sejam emitidas a partir de
uma nica operao de gerenciamento. As vrias respostas so relacionadas atravs
de um parmetro denominado linked-id. Um exemplo da utilizao desta unidade
funcional o caso onde uma ao de teste solicitada a um sistema gerenciado e
deseja-se receber informaes durante a execuo do teste.
 Multiple Objects Selection (opcional) permite que uma nica operao de
gerenciamento seja executada sobre mais do que um objeto gerenciado. Deve ser
utilizada em conjunto com a unidade funcional Scoping.
De acordo com a norma X.700, o conhecimento de gerenciamento pode ser
estabelecido antes da associao, durante o estabelecimento da associao ou ainda, durante
o tempo de vida da associao. A figura 6.4 apresenta uma viso do conhecimento de
gerenciamento compartilhado entre duas entidades de aplicao de gerenciamento.
No exemplo da figura 7.4, trs unidades funcionais foram negociadas para
utilizao: Multiple Objects Selection, Scoping e Multiple Reply.

CMIP

Gerente
unidades funcionais:
Multiple Objects Selection,
Scoping e Multiple Reply

B
Agente
objetos
gerenciado

Figura 7.4 Conhecimento de Gerenciamento Compartilhado entre A e B.

A unidade funcional Multiple Objects Selection indica que as operaes de
gerenciamento podem ser executadas, no apenas sobre um nico objeto mas sobre vrios
objetos e a unidade funcional Multiple Reply indica que uma nica operao de
gerenciamento pode ocasionar diversas respostas.

7.4 Domnios Gerenciais

O ambiente de gerenciamento OSI pode ser organizado em Domnios Gerenciais com o
objetivo de diminuir a complexidade, estabelecer diferentes polticas de gerenciamento na
organizao ou at mesmo para atender s necessidades geogrficas. Os domnios
61

gerenciais devem ser definidos, portanto, com base nos seguintes critrios:
a)

o ambiente a ser gerenciado dividido seguindo um propsito funcional (falhas,

configurao, desempenho, segurana ou contabilizao), ou seguindo um
propsito de gerenciamento (diferentes tecnologias, estrutura organizacional ou
estrutura geogrfica).

b)

para cada um dos propsitos anteriormente descritos, devem ser designados os

papis de gerentes e agentes em uma viso da MIB. Estes papis no so fixos,
podendo ser alterados dinamicamente.

c)

formas de controle consistentes devem ser estabelecidas, isto , o agrupamento

de objetos gerenciados em um domnio de gerenciamento deve permitir, por
exemplo, a aplicao de diferentes polticas de gerenciamento em diferentes
grupos.

Um exemplo de utilizao dos Domnios de Gerenciamento pode ser encontrado em

uma empresa que possui uma poltica de segurana diferente para cada um de seus
Departamentos; as informaes do Departamento de Recursos Humanos certamente so
informaes mais sensveis que as do Departamento de Engenharia e, portanto, necessitam
de formas de controle diferenciadas. A organizao em Domnios de Gerenciamento
permite diminuir a complexidade de gerenciamento dos diferentes servios e mecanismos
utilizados nas diferentes polticas de segurana.
Em redes de telecomunicaes, o ambiente de gerenciamento pode ser dividido,
primeiramente, segundo uma estrutura geogrfica (Estados, regies dentro dos Estados,
etc.), e depois segundo critrios funcionais e estruturais. Desta forma, pode-se pensar, por
exemplo, em um Gerente de Falhas do Servio de Telefonia Pblica da cidade de
Florianpolis, em Santa Catarina e tambm em um Gerente de Desempenho para o Servio
de Comutao de Pacotes no Estado de Santa Catarina. Na verdade, no existem regras
fixas para a organizao em Domnios Gerenciais; esta organizao deve atender, antes de
tudo, s necessidades do ambiente a ser gerenciado.
Uma vez estabelecidos os Domnios de Gerenciamento, necessrio ainda atender aos
seguintes requisitos administrativos:
a)

estabelecer e manter as respectivas autoridades em cada domnio de

gerenciamento, aplicar modificaes em seus limites e organizar a forma de
sobreposio de domnios gerenciais;

b)

gerenciar a transferncia de controle de um domnio de gerenciamento para outro.

Um domnio administrativo de gerenciamento um domnio de gerenciamento onde os

objetos gerenciados esto sob a responsabilidade de uma e somente uma autoridade
administrativa.

62

8 Funes e servios CMISE

O CMISE consiste de uma definio de servio (CMIS) e de uma especificao de
protocolo (CMIP).
Os servios e o protocolo so especificados pela definio de vrias operaes que
podem ser invocadas pela aplicao de gerenciamento (no papel de gerente) sobre objetos
gerenciados e pela definio de notificaes que so emitidas pela aplicao de
gerenciamento (no papel de agente) como resultado de algum evento ocorrido nos objetos
gerenciados, para o gerente.
A definio do CMISE especificada em termos do servio que a mquina de protocolo
proporciona a seus usurios e pela sintaxe e semntica das unidades de dados de protocolo
(PDUs) trocadas entre entidades pares.
O protocolo baseado no paradigma request-reply onde o invocador requisita a
execuo de uma operao sobre um ou mais objetos gerenciados. O sistema que invoca a
operao atua no papel de gerente e, o sistema que recebe a operao atua no papel de
agente. O executor da operao possui o processo agente que proporciona a interface de
comunicao externa e uma viso dos objetos gerenciados em uma estrutura de rvore.
As operaes de gerenciamento consistem em troca de unidades de protocolo para criar,
destruir, ler e modificar a informao de gerenciamento, bem como executar aes
especficas de objeto gerenciado. O termo informao de gerenciamento usado, aqui, para
referenciar objetos gerenciados e suas propriedades.
Alm das operaes j mencionadas, o protocolo suporta a transferncia de relatrios
que descrevem eventos ocorridos nos objetos gerenciados.

8.1 Servios de gerenciamento

Os servios definidos em ISO/IEC 9595 so:
M-GET: para ler o valor de um conjunto de atributos de um objeto.
M-SET: para substituir o valor de um conjunto de atributos de um objeto.
M-CREATE: para criar uma instncia de objeto de uma determinada classe.
M-DELETE: para destruir uma instncia de objeto.
M-ACTION: para solicitar que uma instncia de objeto realize uma determinada ao.
M-EVENT-REPORT: para avisar a ocorrncia de um evento em um objeto.
M-CANCEL-GET: para cancelar uma operao de leitura realizada sobre mltiplos
objetos.
Os servios M-SET, M-ACTION, M-DELETE e M-EVENT-REPORT podem ser
requisitados tanto no modo confirmado quanto no modo no-confirmado, enquanto que os

63

servios M-GET, M-CREATE e M-CANCEL-GET so sempre confirmados.

Alguns destes servios podem ser requisitados de tal forma que a operao pode ser
executada sobre um objeto individual ou sobre mltiplos objetos. O mecanismo para
seleo de mltiplos objetos descrito como uma combinao dos mecanismos de escopo
(scoping) e filtro (filtering).
O mecanismo de scoping pode ser utilizado pelo usurio do servio CMIS, para
identificar os objetos gerenciados que so candidatos para a execuo de uma operao
particular, utilizando um dos mtodos seguintes:
selecionar todos os objetos em uma sub-rvore;
selecionar objetos em um nvel particular de uma sub-rvore.
A raz da sub-rvore indicada por um parmetro cujo valor o identificador de um
objeto denominado objeto gerenciado base.
Filtering um mecanismo de aplicao de critrios para selecionar objetos a fim de
determinar se uma operao deve ou no ser executada sobre o objeto. O parmetro filter
um conjunto de uma ou mais asseres sobre a presena ou valor de um atributo em um
objeto gerenciado.
As asseres sobre o valor de um atributo so avaliadas usando regras de comparao
associadas com o tipo do atributo. So definidas as seguintes regras de comparao:
equality: avaliado como TRUE se e somente se existe um valor de atributo que igual
ao declarado;
greater or equal: avaliado como TRUE se e somente se o valor do atributo fornecido na
assero de valor do atributo maior ou igual ao valor do atributo;
less or equal: avaliado como TRUE se e somente se o valor do atributo fornecido na
assero de valor do atributo menor ou igual ao valor do atributo;
present: avaliado como TRUE se e somente se tal atributo est presente no objeto
gerenciado;
substring: avaliado como TRUE se e somente se existe um valor de atributo no qual o
substring especificado aparece em uma determinada ordem.
subset of: avaliado como TRUE se e somente se todos os membros declarados esto
presentes no atributo;
superset of: avaliado como TRUE se e somente se todos os membros do atributo esto
presentes na assero de valor de atributo;
non-null set intersection: avaliado como TRUE se e somente se no mnimo um dos
membros declarados est presente no atributo.
Alm dos mecanismos de scoping e filtering, tambm definido um mecanismo de
sincronizao (synchronization) que indica a forma que uma operao de gerenciamento
deve ser sincronizada sobre instncias de objetos gerenciados, quando mltiplos objetos
gerenciados foram selecionados atravs dos mecanismos de escopo e filtro. Duas tcnicas
de sincronizao foram definidas: melhor esforo (best effort) e atmica (atomic). A
64

sincronizao de melhor esforo, quando selecionada para a execuo de uma operao,

indica que a operao deve ser executada sobre todos os objetos selecionados pelo
mecanismo de escopo, para os quais possvel a execuo da operao. Para aqueles os
quais a operao falha, deve ser retornada uma mensagem de erro. Para o caso onde a
sincronizao atmica selecionada, se a operao falhar em pelo menos um dos objetos
selecionados, ela no deve ser executada em nenhum dos outros, mesmo que seja possvel.
A sincronizao atmica pode ser comparada ao mecanismo de operaes atmicas
oferecido pela camada de sesso do modelo de referncia OSI. A ordem com que os objetos
gerenciados so selecionados para a execuo da operao considerada uma questo local
e, portanto, dependente da implementao. O CMIS no fornece um parmetro para indicar
sincronizao de atributos de um objeto, isto , no existe uma forma de se executar uma
operao com sincronizao atmica sobre vrios atributos de um mesmo objeto.
Os prximos tens so dedicados apresentao dos servios de gerenciamento
oferecidos pelo CMISE, com mais detalhes.
8.1.1.M-EVENT-REPORT
Este servio usado para relatar a ocorrncia de um evento, para outro sistema aberto.
As aes que devem ser executadas quando um relatrio de evento recebido, no so
especificadas na definio deste servio.
Se o servio for requisitado no modo confirmado, uma confirmao de recepo deve
ser encaminhada pelo sistema receptor para o sistema que emitiu o relatrio de evento.
Os parmetros obrigatrios, associados com a requisio deste servio, so: um nmero
de sequncia, o modo de servio (confirmado ou no confirmado) e o tipo de evento
relatado. Adicionalmente, o relatrio de evento pode incluir o horrio em que o evento
ocorreu e informaes especficas do evento. No modo confirmado, a resposta positiva deve
conter o nmero de seqncia como parmetro obrigatrio. As informaes como
identificao do objeto, tipo de evento e horrio de resposta, podem ser includas
opcionalmente na resposta. Uma resposta de erro tambm pode ser gerada.
8.1.2. M-GET
Este servio confirmado e possibilita que o sistema aberto invocador recupere
valor(es) de atributo(s) de um ou mais objetos gerenciados de um outro sistema aberto. Os
parmetros obrigatrios, na requisio do servio, so: um nmero de seqncia e a
identificao do objeto gerenciado ( que pode ser usado de duas formas: como referncia
para os atributos que devem ser recuperados ou como referncia para a seleo de outros
objetos gerenciados que ele contenha). A requisio pode incluir, tambm, informaes de
segurana para validar a requisio e os identificadores dos atributos cujos valores devem
ser recuperados. Se nenhum atributo especificado, os valores de todos os atributos do
objeto so requisitados.
Se a operao refere-se seleo de mltiplos objetos, uma resposta enviada para cada
objeto individual. Neste caso, o nmero de seqncia da requisio original usado para
ligar as mltiplas respostas requisio e referenciado como o parmetro linked-ID. O
trmino das mltiplas respostas, se a operao teve sucesso, pode ser indicado tanto por um

65

resultado vazio quanto por uma informao na ltima resposta. No caso de sucesso parcial,
a resposta contm tanto a informao de erro quanto os valores dos atributos recuperados
com sucesso.
8.1.3. M-SET
Este servio utilizado pelo sistema invocador para requisitar a modificao de valor de
atributo(s) de um ou mais objetos gerenciados em um outro sistema aberto. Os parmetros
obrigatrios so o nmero de seqncia, a identificao do MO (que usado de uma ou
duas formas, conforme descrito no servio M-GET) e um operador de modificao. O
operador de modificao serve para identificar se a operao mapeada um Set-WithDefault, um Replace, um Add ou um Remove. O conjunto de valores de um atributo multivalorado considerado como um conjunto matemtico quando a operao Add executada;
se o valor j existe, ele no adicionado e nenhum erro ser gerado.
Quando o servio requisitar a seleo de mltiplos objetos, os procedimentos so
similares queles descritos no servio M-GET. importante observar que este servio pode
ser requisitado no modo confirmado ou no modo no confirmado e que, respostas mltiplas
s podem ser obtidas no modo confirmado. No servio no confirmado, o sistema
invocador s poder determinar o resultado da operao atravs da recuperao dos valores
dos atributos modificados.
8.1.4. M-ACTION
Este servio habilita a um sistema aberto invocador, requisitar para um outro sistema
aberto, a execuo de uma ao sobre um ou mais objetos gerenciados. O tipo de ao
definido como parte da descrio do MO. Os detalhes associados execuo da ao (como
por exemplo, as pr e ps condies necessrias para manter a integridade do MO), no so
definidas pelo CMIS, uma vez que as aes so especficas aos MOs e s funes de
gerenciamento. Os parmetros obrigatrios so: um nmero de seqncia, a identificao
do MO (que usado em uma das formas j descritas no servio M_GET), e o tipo de ao.
Os parmetros opcionais incluem uma informao especfica da ao (se definida) e
informao de controle de segurana.
Os procedimentos associados a este servio, quando requisitado para realizao sobre
mltiplos objetos, so os mesmos definidos para o servio M_SET.
8.1.5. M-CREATE
Este servio confirmado utilizado para requisitar a criao de um novo MO em um
outro sistema aberto. Apenas um nico MO pode ser criado por requisio. Diferentes
mtodos podem ser utilizados na criao de um nome para o novo objeto e na atribuio de
valores para seus atributos. Um MO pode ser criado como uma cpia de um outro MO j
existente, com um nome diferente. Na criao da cpia, os valores dos atributos podem ser
alterados explicitamente. A atribuio do nome para o novo MO pode ser feita de uma das
seguintes maneiras:
indicao do nome explicitamente na criao;
atribuio de um identificador nico relativo ao objeto superior especificado na
66

requisio;
atribuio do nome pelo sistema criador do MO, de acordo com as restries impostas
na definio do objeto.
A atribuio de valores para os atributos depende dos valores que so fornecidos com a
requisio e da existncia ou no de definio de valores iniciais ou de valores default. Se
no existirem valores para todos os atributos requisitados, a operao de create ir falhar e
uma resposta de erro ser enviada.
Se a operao de criao for realizada com sucesso, a resposta ir incluir o nome do
novo objeto, se ele no foi fornecido na requisio. Adicionalmente, os identificadores e
valores de todos os atributos atribudos para o MO, podem tambm serem includos na
resposta.
8.1.6. M-DELETE
Este servio utilizado para solicitar que um outro sistema aberto delete um ou mais
objetos gerenciados. Os parmetros obrigatrios para a requisio deste servio so: um
nmero de seqncia e a identificao do MO (que pode ser usado de uma das formas
descritas no servio M-GET). Quando mltiplos objetos so deletados, respostas so
geradas para cada um dos objetos deletados.
Existem duas opes de permisso para a destruio de objetos e elas se referem
forma de manter a integridade dos nomes dos MOs. Estas opes so descritas como parte
da definio do MO e consistem em permitir ou no a destruio de um objeto quando
existem outros objetos nele contidos. importante ressaltar que a requisio de destruio
deve manter a integridade dos relacionamentos entre os objetos, de forma que os
apontadores de relacionamento de um MO no referenciem objetos que no existam mais.
8.1.7. M-CANCEL-GET
Este servio confirmado utilizado para solicitar o cancelamento de um servio
M_GET, solicitado previamente e, para o qual, nenhuma resposta tenha sido recebida. O
cancelamento de uma operao de get pode ser necessrio em alguns casos onde, por
exemplo, mltiplos objetos foram selecionados e a aplicao invocadora no deseja mais
receber as mltiplas respostas ou o tempo de execuo da operao get muito longo. Se a
operao get j tiver sido completada antes da recepo do cancelamento, uma resposta de
erro ser emitida. Se o cancelamento tiver sucesso, uma resposta positiva enviada para o
servio M-CANCEL-GET e uma resposta de erro enviada para o servio M-GET
solicitado anteriormente. Os parmetros obrigatrios na requisio deste servio so: um
nmero de seqncia para esta requisio e o nmero de seqncia da requisio a ser
cancelada.

8.2 Protocolo de gerenciamento CMIP

O CMIP especifica os elementos de protocolo que devem ser utilizados para fornecer os
servios de operao e notificao do CMIS; As operaes podem ser:

67

classe 1 - confirmada sncrona

classe 2 - confirmada assncrona
classe 5 - no confirmada assncrona
O CMIP especificado em termos das vrias semnticas das operaes, sintaxe das
informaes trocadas e procedimentos que devem ser suportados pela mquina de
protocolo.
A mquina de protocolo CMIPM (Commom Management Information Protocol
Machine) recebe as primitivas de servio request e response do usurio do servio CMIS
(MIS-User) e emite PDUs (Protocol Data Unit) que sero transferidas atravs dos servios
oferecidos pelo elemento de servio ROSE.
Por outro lado, a CMIPM remota recebe as PDUs do ROSE e as encaminha atravs de
primitivas indication e confirm apropriadas, para o MIS-User correspondente.
Os procedimentos de protocolo somente indicam como interpretar cada um dos campos
existentes na PDU mas no indicam como o usurio deve processar a informao recebida.
A sintaxe das unidades de dados do protocolo, especificada usando uma sintaxe
denominada ASN.1 (Abstract Syntax Notation One).
8.2.1. Formato das PDUs CMIP
Fase de Associao (mapeadas sobre PDUs do ACSE):
CMIPUserInfo ::=SEQUENCE {
protocolVersion [0]

IMPLICIT ProtocolVersion

DEFAULT {version1},
funcional Units

[1]

IMPLICIT FuncionalUnits

DEFAULT { },
accessControl

[2]

EXTERNAL OPTIONAL,

userInfo

[3]

EXTERNAL OPTIONAL }

ProtocolVersion ::= BIT STRING { version1 (0), version2 (1) }

FuncionalUnits ::= BIT STRING {
multipleObjectSelection (0),
filter (1),
multipleReply (2),
extendedService (3),
cancelGet (4) }
Fase de Operao (mapeadas sobre PDUs do ROSE):

68

ROIVapdu ::=SEQUENCE {
invokeID
linked-ID

InvokeIDType,
[0]

IMPLICIT InvokeIDType OPTIONAL,

operation-value

OPERATION,

argument

ANY DEFINED BY operation-value OPTIONAL }

InvokeIDType ::= INTEGER

Exemplo:
m-Get OPERATION ::= localValue 3
ROIV-m-Get ::= ROIVapdu ( WITH COMPONENTS
{

invokeID

PRESENT,

linked-ID

ABSENT,

operation-value

(m-Get),

argument

(INCLUDES GetArgument) } )

Operao M-GET
M-Get OPERATION
ARGUMENT

GetArgument

RESULT

GetResult

ERRORS
(accessDenied,
classInstanceConflict,
complexityLimitation,
operationCancelled, getListError, invalidFilter, invalidScope, noSuchObjectClass,
noSuchObjectInstance, processingFailure, syncNotSupported)
LINKED (m-Linked-Reply)
::= localValue 3
GetArgument ::= SEQUENCE {
COMPONENTS OF BaseManagedObjectId,
accessControl

[5] AccessControl OPTIONAL,

synchronization

[6] IMPLICIT CMISSync DEFAULT bestEffort,

scope

[7] Scope DEFAULT baseObject,

filter

CMISFilter DEFAULT and { },

attributeIdList

[12] IMPLICIT SET OF AttributeId OPTIONAL }

BaseManagedObjectId ::= SEQUENCE {

baseManagedObjectClass

ObjectClass,

baseManagedObjectInstance ObjectInstance }
AccessControl ::= EXTERNAL
69

CMISSync ::= ENUMERATED { bestEffort (0), atomic (1) }

Scope ::= CHOICE {INTEGER {

baseObject (0),
firstLevelOnly (1),
wholeSubtree (2) },

individualLevels [1] IMPLICIT INTEGER

baseToNthLevel [2] IMPLICIT INTEGER }
CMISFilter ::= CHOICE {

item

[8] FilterItem,

and

[9] IMPLICIT SET OF CMISFilter,

or

[10] IMPLICIT SET OF CMISFilter,

not

[11] CMISFilter }

AttributeId ::= CHOICE { globalForm [0] IMPLICIT OBJECT IDENTIFIER,

localForm [1] IMPLICIT INTEGER }
GetResult ::= SEQUENCE {
managedObjectClass ObjectClass OPTIONAL
managedObjectInstance
ObjectInstance OPTIONAL
currentTime [5] IMPLICIT GeneralizedTime OPTIONAL
attributeList [6] IMPLICIT SET OF Attribute OPTIONAL
ObjectClass ::= CHOICE {
globalForm

[0] IMPLICIT OBJECT IDENTIFIER,

localForm

[1] IMPLICIT INTEGER }

ObjectInstance ::= CHOICE {

distinguishedName

[2] IMPLICIT DistinguishedName,

nonSpecificForm

[3] IMPLICIT OCTET STRING,

localDistinguishedName [4] IMPLICIT RDNSequence }

8.2.2. ERROS
Quando um servio requisitado no modo confirmado, uma resposta enviada para
indicar o sucesso ou a falha na execuo do servio. So definidos vrios erros no padro
CMIS. Alguns destes erros so gerais e aplicveis a todos os servios (como por exemplo,
duplicate invocation, no such object instance, unrecognized operation e processing failure).
Alguns erros especficos, aplicveis a servios individuais, so, por exemplo:
No such event type para M-EVENT-REPORT
Access denied para M-GET, M-SET, M-ACTION, M-CREATE e M-DELETE
No such action para M-ACTION
No such attribute para M-GET e M-SET
70

9 Arquitetura Funcional do modelo OSI

Este captulo dedicado ao estudo mais aprofundado do elemento de servio de
aplicao de gerenciamento de sistemas SMASE (System Management Application Service
Element).
O SMASE define a semntica e a sintaxe abstrata da informao transferida em
MAPDUs (Management Application Protocol Data Unit), isto , especifica a informao de
gerenciamento a ser trocada entre as entidades de aplicao de gerenciamento de sistemas.
Os servios providos pelo SMASE podem ser agrupados em unidades funcionais, com o
objetivo de facilitar o processo de negociao entre as entidades comunicantes. A
negociao de unidades funcionais de gerenciamento de sistemas SMFUs (Systems
Management Funtional Units) opcional. Um conjunto inicial de SMFUs agregadas pode
ser determinado em tempo de estabelecimento de associao, atravs do uso do parmetro
smfuPackages. O parmetro smfuPackages definido como um conjunto de unidades
funcionais e deve estar presente nas primitivas A-ASSOCIATE (request e indication)
quando for realizada uma negociao das SMFUs e nas primitivas A-ASSOCIATE
(response e confirm) se a negociao for aceita; nos demais casos, o parmetro deve ser
omitido.
A informao do usurio, a ser passada no parmetro user information da primitiva AASSOCIATE, definida em CCITT Rec.X.701 | ISO/IEC 10040, usando a syntaxe abstrata
ASN.1:
SMASE-A-ASSOCIATE-Information {joint-iso-ccitt ms(9) smo(0) asn.1Modules(2)
negotiationDefinitions(0) version1(1)}
DEFINITIONS ::= BEGIN
SMASEUserData ::= SEQUENCE{
smfuPackages SET OF

FunctionalUnitPackage

OPTIONAL,

-- shall be present on request/indication if SMFU negotiation is proposed and

-- on response/confirm if SMFU negotiation is accepted, otherwise this
-- parameter shall be omited.
reason

Reason

OPTIONAL,

-- may only be present on A-ASSOCIATE response/confirm. When

-- SMFU negotiation fails, when SMFU negotiation results in a
-- reduction of the proposed set of SMFUs or when association request
-- is rejected, it may carry a specific reason for this.
systemManagementUserInformation

GraphicString OPTIONAL

-- this parameter is provided solely for the convenience of

--implementations needing to distinguish between different

71

-- implementation environments, it shall not be subject of conformance

-- test
Aps o estabelecimento do conjunto de SMFUs, a associao deve restringir-se ao
conjunto de unidades funcionais agregadas at que um novo conjunto seja estabelecido, isto
, somente podem ser utilizadas operaes e notificaes pertencentes ao conjunto
agregado. No entanto, a negociao das unidades funcionais feita apenas na fase de
estabelecimento de associao, uma vez que a definio dos mecanismos para modificar o
conjunto agregado de SMFUs durante o tempo de vida da associao, ainda no foram
definidos, sendo objeto de estudos posteriores.
Para identificar um conjunto de SMFUs, os bits correspondentes a cada SMFU, no
parmetro smfuPackages, devem ser marcados com o valor 1. O conjunto de todas as
SMFUs cuja posio correspondente no parmetro smfuPackages est setada com o valor 1,
o conjunto agregado de SMFUs a ser negociado durante a fase de estabelecimento de
associao entre as entidades de aplicao de gerenciamento. A omisso de sequncias de
bits em um BITSTRING deve ser interpretada como setada para zero.
O servio de comunicao usado pelo SMASE pode ser fornecido pelo CMISE ou por
outros ASEs, tais como o FTAM (File Transfer, Access and Management) [ISO8571] ou
TP (Transaction Processing) [ISO/IEC 10026]. Quando o CMISE utilizado, a presena do
ROSE [CCITT Rec. X.219 | ISO/IEC 9072] requerida.
De uma forma geral, este elemento de servio pode ser visto como sendo composto
um conjunto de funes que oferecem servios de suporte para as aplicaes
gerenciamento. Embora nem todas as funes sejam obrigatrias, importante que
conhea cada uma delas no sentido de se ter parmetros para selecionar produtos
gerenciamento no mercado.

de
de
se
de

9.1 SMASE - System Management Application Service Element

Aspectos funcionais
O SMASE pode ser visto como um conjunto de funes de gerenciamento de
sistemas que do suporte s reas funcionais de gerenciamento.
Uma funo de gerenciamento define as atividades de gerenciamento e as
informaes necessrias para alcanar um determinado objetivo. As funes de
gerenciamento podem ser combinadas para executar uma atividade de gerenciamento
especfica; este agrupamento denominado de Unidade Funcional.
Unidades funcionais

unidades bsicas de negociao entre MIS-Users;

servios de funes de gerenciamento podem ser agrupados em uma ou mais
unidades funcionais;
unidades funcionais que atravessam os limites de uma funo, podem suportar os
seguintes conjuntos de capacidades:
o somente notificaes;

72

o somente operaes de gerenciamento;

o notificaes e operaes de gerenciamento.
Existem diversas Funes de Gerenciamento definidas nos documentos de
padronizao mas, neste documento, iremos abordar apenas algumas delas. O objetivo
mostrar a funcionalidade que pode ser obtida no caso da sua incluso em solues de
gerenciamento.

9.2 Funo de Gerenciamento de Objeto

Uma operao de gerenciamento pode ser realizada sobre os atributos de um objeto
ou sobre o objeto como um todo.
Sobre o objeto:
CREATE: criao de uma instncia de classe de objeto
DELETE: destruio de uma instncia de classe de objeto
ACTION: solicitao para a execuo de uma ao sobre uma instncia de classe de objeto
Sobre os atributos:
GET ATTRIBUTE VALUE: leitura do valor de um atributo
REPLACE ATTRIBUTE VALUE: modificao do valor de um atributo
REPLACE WITH DEFAULT VALUE: modificao do valor de um atributo pelo seu valor
default
ADD MEMBER: adio de um elemento no conjunto de valores de um atributo
REMOVE MEMBER: remoo de um elemento do conjunto de valores de um atributo
Esta funo oferece servios de relatrios sobre a criao de objeto, remoo de
objeto e mudana de valor de atributo.
Oferece, ainda, os servios de PASS-THROUGH para as demais funes de
gerenciamento acessarem os servios do CMIS. O mapeamento das operaes em servios
da OMF (Object Management Function) apresentado na tabela 9.1.
Tabela 9.1 Mapeamento das operaes nos servios Pass-Through

Operaes sobre o MO

Pass - Through

Create
Delete
Action
Replace
Add
Remove
Replace-with-Default
Get
Notification

PT-CREATE
PT-DELETE
PT-ACTION
PT-SET
PT-SET
PT-SET
PT-SET
PT-GET
PT-EVENT-REPORT

73

Servios da OMF
seis servios de pass-through
relatrio de Criao de Objeto
relatrio de Remoo de Objeto
relatrio de Mudana de Valor de Atributo

9.3 Funo de Gerenciamento de Estado

Um atributo de Estado representa as condies instantneas de disponibilidade e
operacionalidade do recurso correspondente, sob a viso do gerenciamento.
Esta funo tem como objetivo prover definies genricas que permitam obter
informaes, mudar o estado de gerenciamento de um objeto gerenciado e emitir
notificaes sobre estas mudanas de estado, quando elas forem decorrentes de alguma
operao em um sistema aberto.

Estado operacional: indica se o recurso est ou no fisicamente instalado e em

operao;
Estado de utilizao: indica se o recurso est ou no em uso em um dado instante
e, se est ou no apto a aceitar outros usurios adicionais;
Estado de administrao: indica a permisso ou proibio da utilizao do recurso,
imposta pelos servios de gerenciamento.

O modelo da Funo de Gerenciamento de Estado define atributos que podem ser

utilizados na modelagem dos objetos que representam os recursos gerenciados. Os atributos
e seus respectivos valores so apresentados na tabela 9.2 e os diagramas de estado
representando a mudana de estado administrativo e de utilizao de objetos gerenciados
so apresentados nas figuras 9.1 e 9.2, respectivamente.
Atributo de Estado
Operacional
Utilizao

Administrativo

Tabela 9.2 Atributos de Estado

Valores possveis
Enable
Disable
Idle
Active
Busy
Unknown
Locked
Unlocked
Shutting Down

74

Sada de usurio
Idle

Novo usurio
Busy
Sada do
ltimo Usurio

Novo usurio

Active
Novo usurio
ou Capacidade
diminuida

CI ou
Sada de usurio

Novo usurio
ou CD
Unknow

Sada de usurio
ou Capacidade
aumentada

Figura 9.1 Diagrama de estados de utilizao

Shut Down (se no existir usurio)

Unlocked

Lock

Locked

Unlock

Unlock

Shutting Down

Shut Down

Lock
Sada de ltimo usurio

Figura 9.2 Diagrama de estados administrativo

9.4 Atributos de Status

Status de Reparo: Under Repair / Fault Report Outstanding
Status de Instalao: Not Installed / Initialization Incomplete / Initialization Required
Status de Disponibilidade: In Test / Failed / Power Off / Off Line / Off Duty / Dependency /
Degraded
Status de Controle: Subject to Test / Read Only / Part of Services Locked / Reserved for
Test / Suspended
75

9.5 Atributos para representao de relacionamento

O relacionamento entre objetos gerenciados descrito por um conjunto de regras que
determinam como a operao de uma parte do sistema aberto afeta a operao de outra
parte deste mesmo sistema. Os tipos de relacionamentos, mostrados na figura 9.3, so:
Direto e Indireto
Simtrico e Assimtrico
relacionamento
A

indireto

relacionamento
relacionamento
direto
direto
Figura 9.3 Tipos de relacionamentos considerados

Categorias de Relacionamento

Relacionamento de Incluso
Relacionamento de um Sentido
Relacionamento Recproco

Tipos de Relacionamento Recproco

Relacionamento de Servio:
Servidor e Usurio

Atributos de Relacionamento
Objeto Provedor: GET, REPLACE
Objeto Usurio: GET, REPLACE

Relacionamento Par: Par

Par: GET

Relacionamento Fallback:
Primrio e Secundrio

Primrio: GET, REPLACE

Secundrio: GET, REPLACE

Relacionamento Backup:
Backup e Backed-up

Instncia de Objeto Backup: GET

Instncia de Objeto Backed-up: GET

Relacionamento de Grupo:
Proprietrio e Membro

Membro: GET, REPLACE

Proprietrio: GET, REPLACE

76

Grupo de Atributos de Relacionamento: constitudo de todos os atributos de relacionamento de um

MO.

9.6 Funo de Relatrio de Alarme

Tem como objetivo prover informaes sobre as condies operacionais e a
qualidade de servio do sistema gerenciado bem como definir critrios que permitam
identificar o grau de mau funcionamento do sistema gerenciado e o nvel de degradao da
qualidade de servio.
Um alarme consiste em uma mensagem enviada do sistema Agente para o sistema Gerente,
contendo as seguintes informaes:
Tipo de Alarme, Causas Provveis, Nvel de Severidade, Indicao de Tendncias,
Informao de Valor Limite, Sugestes de Aes de Reparo e Descrio do Problema.
Tipos de Alarme
Alarme de Comunicao
Alarme de Qualidade de Servio
Alarme de Processamento
Alarme de Equipamento
Alarme Ambiental
Causas Provveis(Ver anexo 1)
Nveis de Severidade
Cleared: o alarme ou conjunto de alarmes foi removido.
Indeterminado: no possvel identificar como as condies de funcionamento
foram afetadas.
Crtico: exige ao corretiva imediata do sistema.
Maior: as condies de funcionamento de um sistema esto sendo afetadas exigindo
uma ao corretiva urgente.
Menor: aes corretivas so necessrias para prevenir a ocorrncia de falhas mais
srias.
Alerta: suspeita de ocorrncia de falhas. Devem ser realizados diagnsticos sobre o
recurso gerenciado.
Indicao de tendncias
Indica se existem alarmes pendentes e quais as tendncias demonstradas pelo alarme
emitido, em relao aos anteriores.


Mais Severo

Nenhuma Mudana

Menos Severo
Obs.: Esta informao s tem sentido se existirem alarmes pendentes.
Informao de Valor Limite
Definida atravs de quatro sub-campos:
Valor-Limite Pr-Fixado: identificador do atributo de valor-limite que causou a notificao;

77

Nvel-Limite: valor-limite que, quando ultrapassado, provoca a notificao de um alarme;

Valor Observado: valor que ultrapassou o valor-limite pr-fixado;
Instante de Ultrapassagem: instante de ocorrncia da ultrapassagem do valor-limite.
Registro de Alarme
Representa a informao armazenada em logs, como resultado do relatrio de
eventos recebido, quando o tipo de evento um dos alarmes definidos.
Servio de Relatrio de Alarme
Possibilita que um usurio notifique outro usurio sobre a ocorrncia de um alarme.
Pode ser confirmado ou no-confirmado.
A classe de objeto Registro de Alarme derivada da classe Registro de Log de
Evento que, por sua vez, derivada da classe Registro de Log.

9.7 Funo de Gerenciamento de Relatrio de Evento

Os principais objetivos desta funo referem-se :

Selecionar os relatrios de eventos que devem ser enviados a um sistema de
gerenciamento particular;
Determinar os destinatrios para os quais os relatrios de eventos devem ser
enviados;
Controlar (suspender e retomar) o repasse de relatrios de eventos;
Possibilitar que um sistema de gerenciamento externo modifique as condies de
emisso de relatrios de eventos;
Designar endereos alternativos

O modelo para a funo de Gerenciamento de Relatrio de Evento apresentado na figura

9.4.
Objet os
Gerenciados

Not ificaes

Not ificaes

Processament o
e Det eco de
Event os

Relat rios
de Event os
Pot enciais

Out ros
Discriminador
de Repasse
de Event os

Relat rio
de Event o

Cont roles
Respost as

Figura 9.4. Modelo para a funo de Gerenciamento de Relatrio de Evento

78

O objeto Discriminador estabelece as condies que devem ser satisfeitas para que
um objeto de entrada seja repassado e pode estar associado a um pacote de programao
que determine quando a emisso do evento deve ocorrer.
Atributos do Discriminador de Repasse de Eventos
Destination address: especifica um grupo de endereos primrios;
Backup address list: lista ordenada de endereos a serem usados no caso de falha do
endereo primrio;
Active address: identifica o endereo da Entidade de Aplicao para a qual os
eventos so repassados pelo discriminador;
Outros atributos definidos para o objeto Discriminador so os atributos de estado
administrativo, operacional e de utilizao e o atributo que define o critrio de
discriminao a ser empregado.
O atributo Construtor de Discriminador tem como valor um conjunto de uma ou mais
asseres sobre a presena de valores de atributos. Estas asseres podem ser agrupadas
usando operadores lgicos AND e OR.
A classe de objeto Discriminador tambm pode ser derivada para acomodar
condies especficas em cada sub-classe particular.
Um objeto Discriminador pode ser especificado para testar condies especficas de
igualdade ou desigualdade de atributos, a presena de atributos e a ausncia de qualquer
uma destas condies.
Pacotes de Programao
Permitem que os discriminadores troquem, automaticamente, suas condies de
reporting-on e reporting-off. So definidos trs tipos de Pacotes de Programao:
Pacote de Programao Diria (Daily Scheduling Package) tem um nico atributo:
Intvls
Pacote de Programao Semanal (Weekly Scheduling Package) tem os atributos:
StartTime StopTime e WeekMask (DaysOfWeek e IntvlsOfDay)
Pacote de Programao Externa (External Schedular Scheduling Package) tem um
nico atributo que especifica o nome do MO programador (SchedularName).
Servios
Criao de Relatrio de Repasse de Eventos;
Eliminao de Relatrio de Repasse de Eventos;
Modificao de valores de atributos,
Suspenso e Retomada de atividade de discriminao

9.8 Funo de Controle de Log

Define um objeto que tem como objetivo preservar informaes sobre eventos
ocorridos ou sobre operaes efetuadas sobre objetos. A representao da funo de Log
dada na figura 9.5.

79

registro
registro
registro

Informao a ser
submetida a Log

Informao de controle de Log

Figura 9.5 A Funo de Log
Atributos do Log
Log Id (instncia do log)
Discriminator Constructor
Administrative State (UNLOCKED e LOCKED)
Operational State (ENABLE e DISABLE)
Availability Status
Usage State (ACTIVE, IDLE, BUSY e UNKNOWN)
Max Log Size
Current Log Size
Number of Records
Capacity Alarm Threshold
Log Full Action (wrap ou halt)
Packages
Registros de Log
Representam a informao armazenada no Log. A classe Registro de Log definida
com dois atributos:
Log Record Id (Get)
Logging Time (Get)
Os Registros de Log no podem ser criados explicitamente por operaes de
gerenciamento e s podem ser recuperados ou eliminados.
Servios de Controle de Log
Iniciao de Log;
Remoo de Log;
Modificao de valores de atributos de Log;
Suspenso da atividade de armazenamento;
Retomada da atividade de armazenamento;
Eliminao e recuperao de Registro de Log;

80

9.9 Funes de Gerenciamento de Segurana

O modelo de gerenciamento OSI define trs funes de gerenciamento de segurana
que tm como objetivos principais:
Fornecer relatrios de eventos relativos segurana;
Fornecer informaes estatsticas;
Manter e analisar histricos de registros de segurana;
Selecionar parmetros do servio de segurana;
Ativar e desativar servios de segurana.
Consideraes gerais sobre a gerncia de segurana
Diferentes polticas de segurana podem ser adotadas nos sistemas abertos. Grupos
de entidades que obedecem a uma mesma poltica de segurana formam um Domnio de
Segurana.
As informaes de segurana devem ser distribudas entre todas as entidades que
tm relao com segurana e devem ser armazenadas em uma base especfica (SMIB)
Categorias de atividades de gerenciamento de segurana: Segurana do Sistema,
Servios de Segurana e Mecanismos de Segurana.

Funo de Relatrio de Alarme de Segurana

Esta funo define os tipos de relatrios que podem ser utilizados para informar
sobre atentados e violaes contra a segurana, detectados pelos mecanismos de segurana
do sistema.
As informaes contidas nestes relatrios possibilitam que o usurio seja notificado
sobre a gravidade percebida em relao operaes errneas, atentados e violao de
segurana dos sistemas.
O modelo, apresentado na figura 9.6, segue aquele definido para a funo de
relatrio de evento.
Informaes sobre alarmes
 Tipos de alarmes:
violao de integridade;
violao operacional;
violao fsica;
violao de servio ou mecanismo de segurana;
violao no domnio do tempo.
 Causas de Alarme
 Gravidade do Alarme:
indeterminado, crtico, maior ou menor.

81

82

Modelo de Controle de Acesso

O modelo de controle de acesso descrito pelas figuras 9.7 e 9.8 que mostram,
respectivamente, o controle de acesso na fase de associao e na fase de operaes de
gerenciamento.
Agente
Imposio de
Cont role de
Acesso

Gerente
Processo
de
Iniciao
de
Associao

ACI met a
Cont ext o
Regras da Pol.
de acesso

Funo de Deciso
de Cont role de
Acesso

ACI aceit a

Figura 9.7. Modelo de controle de acesso para Associao de Gerenciamento

agente
Pedido

Resposta

Processo
de Seleo
Processo
de
Resposta

Pedido
Negao

Funo de
Controle

Deciso
de acesso

Objet o
Gerenciado

Pedido de
acesso

Funo de
Deciso
Resposta

Permisses

ACI, Context o
Regras da
Poltica de acesso

Figura 9.8. Modelo de controle de acesso para Operaes de Gerenciamento

9.10 Funo de Medida de Contabilizao

O objetivo desta funo coletar e registrar informaes sobre a utilizao de
recursos do ambiente OSI, associando tarifas s medidas de utilizao.
A funcionalidade de medida de contabilizao definida atravs de dois objetos:
83

Objeto de controle de medida de contabilizao dedicado ao controle do

gerenciamento de contabilizao
Objeto de dados de medida de contabilizao - representa a utilizao de um
recurso por um determinado usurio

Atributos do Objeto de Controle de Medida de Contabilizao

units of usage: unidade de medida da utilizao de um recurso
recording triggers: eventos que causam a atualizao dos dados de medida de
contabilizao;
reporting triggers: eventos que causam a emisso de notificao sobre informaes de
contabilizao;
data object reference: dados de medida de contabilizao sujeitos ao controle de medida de
contabilizao;
resource name: identifica o recurso a ser contabilizado.
Aes e Notificaes de Controle de Medida de Contabilizao
Aes:
Start metering
Suspend metering
Resume metering

Notificaes:
Accounting Started
Accounting Suspended
Accounting Resumed

Atributos do Objeto de Dados de Medida de Contabilizao

requester id

responder id

subscriber id

meter info

service requested

service provided

usage start time

usage meter time

data object state

control object reference

resource name
Servios da funo de Medida de Contabilizao
Gerenciamento de Medida de Contabilizao:
criao e remoo de instncias de objetos de controle de medida de contabilizao;
leitura e modificao de atributos de objetos de controle de medida de
contabilizao.
incio, suspenso e retomada de medida de contabilizao
Servio de Dados de Medida de Contabilizao:
criao e remoo de objetos de dados de medida de contabilizao;
recuperao de valores de atributos de objetos de dados de medida de
contabilizao.

84

9.11 Funo de Monitorao de Carga de Trabalho

O objetivo desta funo avaliar a demanda e a utilizao de recursos do ambiente
OSI e a eficincia das atividades de comunicao.
A execuo desta funo deve possibilitar:
obteno de informaes estatsticas;
manuteno e anlise dos registros de histricos do sistema;
determinao do desempenho do sistema sob condies naturais e artificiais;
alterao do modo de operao do sistema.
Modelos
Modelo de Utilizao: monitorao do uso instantneo de um recurso OSI.
Modelo de taxa de Rejeio: monitorao da rejeio de um pedido de servio.
Modelo de Taxa de Pedido de Recursos: monitorao dos pedidos de uso de recursos OSI.
A figura 9.9 mostra o Modelo genrico para Monitorao de Carga.
Para cada um destes tipos de monitorao so definidos: o valor mximo aceitvel
(threshold), o valor de alerta e o valor em que a situao de alerta removida.

EWT
EWCT

SCT
ST

EWCT - Early Warning Clear Threshold

EWT - Early Warning Threshold
SCT - Severe Clear Threshold
ST - Severe Threshold
Figura 9.9 - Modelo genrico para Monitorao de Carga
Objetos Mtricos
Podem ter os seguintes atributos:

identificao do objeto mtrico;

identificao do objeto gerenciado que est sendo observado e de seus atributos;

identificao do algoritmo mtrico usado nas observaes;

nmero de observaes, frequncia das observaes e instante da ltima observao;

programao das observaes;

indicao dos resultados das observaes;

valores para os quais so gerados alarmes;

estado administrativo.

85

Servios
Iniciao de Monitorao;
Finalizao de Monitorao;
Suspenso da Monitorao;
Retomada da Monitorao;
Modificao dos atributos de um objeto mtrico;
Leitura de atributos de objetos mtricos.

9.12 Funo de Gerenciamento de Teste

Esta funo tem como objetivo o controle remoto de testes e a especificao de testes a
serem realizados sobre os recursos gerenciados. Considera que deva ser aplicvel a
diferentes metodologias de teste:
Testes de loopback
Testes de insero de falhas
Autoteste
Ambiente de teste
Cada teste pode envolver a criao de um ambiente de teste, o controle e a monitorao das
operaes de teste e o retorno ao ambiente normal.
O controle de um teste consiste em suspender, retomar e finalizar o teste.
Os testes podem ser escalonados de forma peridica ou no peridica.
Modelo para a funo de teste

Test
Conductor

operaes
de teste

Test
Performer

Funcionalidade TARR capacidade que um objeto gerenciado possui para receber e

responder a operaes de teste.
MORT: objeto gerenciado usado como referncia das funcionalidades que esto sendo
testadas.
TO: objeto gerenciado que existe somente durante a execuo de um teste controlado.

86

Testes no controlados

MO

pedido de teste

TARR

Test
Performer

Test
Conduct or
relatrio de
resultado

MORT

Teste controlvel

MO
TARR

pedido de teste

Test
Conductor

monitorao e controle

Test
Performer
TO

relatrio de resultado

TO
MORT

TO - Test Object
MO - Managed Object

MORT - Managed Object Referring toTest

TARR - Test Action Request Receive

9.13 Funo de Sumarizao

O objetivo desta funo obter informaes a partir de observaes relativas a
mltiplos objetos gerenciados e seus atributos, em um ou mais instantes distintos no tempo.
O processo de esquadrinhamento especificado por meio de um atributo chamado
esquadrinhador do objeto sumarizador
possvel realizar o esquadrinhamento dos objetos e a emisso de relatrios de
sumarizao em base diria, semanal ou sob programao externa.

87

Modelo da Funo de Sumarizao

Pedidos
de
Sumrios
Objetos
observados
valores de
atributos
observados
atributos de
esquadrinhament
o

Funo de
Relatrio de
Evento

Modelo de
Sum arizao

Objeto
Sumarizador

Prprocessamento
de eventos

Discriminado
rde Repasse
de Eventos
Relatrios de
Eventos
contendo
Notificao
de Sumrio

Respostas
com Sum rios

Objetos
Escalonados

Notificaes
de Sumrios

Prprocessam
ento
de eventos

Log de
Registros

Funo de
Controle de
Log

Relatrios de
Registros pedidos

88

Classes de objetos de sumarizao

t opo
Esquadrinhador
Het erogneo Homogneo

Esquadrinhador
Dinmico
Simples Dinmico
Armazenador

Simples
de Mdia
de Mdia e
Varincia

Est at st ico
Minimax
de Pont o de Amost ragem

10 Caractersticas das arquiteturas de gerenciamento

As arquiteturas de gerenciamento so classificadas em arquiteturas proprietrias e
arquiteturas abertas. Esta classificao realizada considerando-se aspectos relacionados
utilizao de um modelo de informao padronizado bem como aos protocolos utilizados
para a comunicao Gerente-Agente. Alguns exemplos de arquiteturas abertas so:
Internet SNMP: Simple Network Management Protocol
ISO/ITU-T CMIP: Common Management Information Protocol
ODP/OMG CORBA: Common Object Request Broker Architecture
Uma arquitetura dita fechada quando no se tem acesso s definies de seu modelo
de informao ou aos protocolos utilizados na comunicao. A utilizao de plataformas
fechadas dificulta a interoperabilidade com outros sistemas, obrigando, muitas vezes, a uma
dependncia de solues oferecidas por um nico ou um nmero limitado de fornecedores.
As principais diferenas relacionadas com as arquiteturas abertas referem-se a:

orientao a objetos ou a tipos de dados

modelos de informao
protocolo para comunicao
funcionalidades

10.1 A utilizao de plataformas de gerenciamento: mitos e fatos

Uma plataforma de gerenciamento dita aberta quando apresenta uma arquitetura aberta
e interfaces de programas aplicativos (APIs) abertas.
Uma plataforma de software consolida e gerencia funes comuns que so usadas por
aplicaes independentes. composta por comportamentos e servios e prov um conjunto
89

comum de funes que so utilizadas por diferentes aplicaes.

Uma plataforma de gerncia de redes de propsito geral dever prover servios
funcionais comuns aos domnios SNMP, CMISE, TL1 e ASCII
Uma plataforma inclui todos os mdulos que so compartilhados entre diferentes
aplicaes de gerenciamento mas no inclui a funcionalidade de aplicaes especficas.
Portanto, a interface com a plataforma deve ser bem definida para permitir o
desenvolvimento de aplicaes, utilizando de forma transparente os servios da plataforma;
Algumas plataformas so especficas para o gerenciamento da rede, limitando-se
oferta de servios e protocolos de comunicao; outras podem oferecer servios para outras
aplicaes que no so de gerncia. Normalmente esta funcionalidade obtida com um alto
custo, atravs da integrao de diferentes produtos. Se considerarmos a problemtica
existente no setor de telecomunicaes, poderemos observar que os produtos ofertados
esto longe de satisfazer s necessidades deste setor pois, na sua grande maioria, oferecem
uma funcionalidade restrita a apenas uma poro de um nvel funcional TMN (geralmente
referem-se ao nvel de gerencia de elemento de rede).
Atualmente, uma soluo que vem sendo adotada a utilizao de plataformas
integradoras. Estas plataformas geralmente contem servios de comunicao que fornecem
suporte para comunicao sncrona, assncrona, transacional e interativa entre processos de
aplicao de gerncia e entre aplicaes de gerncia e os elementos de rede suportados.
Podem oferecer, ainda, servios de diretrio, acesso de dados e funes de segurana. Os
servios de gerenciamento de dados podem fornecer suporte para a MIB, para a persistncia
de objetos e para sistemas de bases de dados. Os servios de apresentao podem fornecer
uma forma comum de observao entre processos de gerncia divergentes.

10.2 A viso dos dados

O uso de plataformas de integrao, permite a coleta de informaes de vrios sistemas
e elementos da rede. O problema consiste em identificar quais dados so relevantes para
serem recuperados
Muitos dados existem no sistema, mas esto armazenados em formatos incompatveis
para serem utilizados de forma integrada. Alguns dados precisam ser trabalhados e depois
encaminhados para aplicaes de nveis superiores na forma de porcentagens, mdias,
valores mnimo e mximo, etc...
Informaes duplicadas, desconexas, incompatveis proliferam em toda empresa devido
s necessidades de desenvolvimento de aplicaes especficas e urgentes;
A Engenharia de Informao a disciplina utilizada para identificar necessidades de
informao e para desenvolver sistemas de informao que produzem mensagens que
fornecero informao para atender algum objetivo. Ela um processo de manufatura que
utiliza dados como matria prima, para construir e transmitir uma mensagem para um
recipiente. Ela tambm um processo de filtragem de grandes massas de dados para uma
mensagem que prov informao.
O seu nico objetivo pegar o dado certo, para o pessoal certo, no lugar certo, no tempo
90

certo, na forma certa e com o custo certo, de tal forma que eles possam tomar decises
corretas e executar as aes corretas. Para isto, algumas tcnicas tm sido apresentadas e as
mais atuais referem-se ao Data Warehouse e ao Data mining.

10.3 Implantao de um sistema de gerncia

A implantao de um sistema de gerncia no uma tarefa trivial e exige uma certa
competncia de seu coordenador e da equipe encarregada. A principal causa do
descontentamento aps a implantao de um sistema de gerncia devido ao fato desta
tarefa ter sido subestimada e no ter sido dimensionada de forma adequada. Mesmo a
implantao de sistemas simples possuem um custo razovel, seja este custo calculado em
termos de aquisio ou em termos de tempo e de pessoal. Isto porque no existem solues
prontas. Qualquer soluo exigir um esforo de customizao caso se deseje obter um
sistema de gerncia que seja til. Para se alcanar os objetivos globais, muitas aplicaes
devero ser desenvolvidas e integradas plataforma adquirida.
A tarefa exige, portanto, um planejamento cuidadoso das metas a serem alcanadas e
este planejamento exigir uma equipe multidisciplinar com especialistas de vrios
departamentos da empresa e de fora da empresa.
De uma maneira simplificada, podemos estabelecer uma estratgia metodolgica para a
implantao de um sistema de gerncia:
Conhecimento do plano estratgico da empresa a fim de identificar seus objetivos
e prioridades;
Definio dos objetivos a serem alcanados com o sistema a ser implantado;
Especificao dos servios necessrios para o alcance dos objetivos;
Identificao das prioridades para identificar os servios mais urgentes;
Seleo da plataforma de integrao considerando o atendimento aos servios e/ou
facilidades para o desenvolvimento de aplicaes que proporcionem o seu
atendimento;
Modelagem das informaes identificando aquelas que realmente sero teis para
o alcance dos objetivos;
Desenvolvimento de novas aplicaes para complementar o trabalho.
A equipe designada para o planejamento e implantao do sistema de gerncia deve
conter, pelo menos, um tcnico especialista de cada rea da empresa. Com isto procura-se
assegurar uma abrangncia da soluo adotada evitando-se a perda de informaes
estratgicas para a empresa. Alm destes componentes, ser necessrio integrar equipe
(caso esta participao ainda no tenha sido contemplada), pelo menos um especialista em
projeto de bases de dados, um especialista em marketing, um especialista em modelagem de
dados e um especialista no negcio da empresa.
O trabalho de implantao de um sistema de gerncia passa primeiro por uma profunda
conscientizao do problema que se observa na empresa. A partir desta conscientizao
necessria uma tomada de deciso que se constitui a parte mais difcil por envolver
mudanas nos procedimentos e custos.
Uma vez tomada a deciso, o prximo passo consiste em selecionar a equipe
91

cuidadosamente, observando, inclusive, questes como relacionamentos pessoais. Esta

equipe dever, ento, assumir a coordenao dos trabalhos estabelecendo o modelo do
processo e selecionando as ferramentas que podero auxiliar a tarefa do projeto.
Aps cumprir as etapas da metodologia proposta anteriormente, a equipe poder iniciar
a especificao e implantao dos sistemas, sem esquecer de estabelecer um plano de
contingncia e de manuteno.

10.4 Consideraes finais

A deciso de se implantar um sistema de gerenciamento deve estar embasada em
diversos fatores. Muitas empresas desistem da idia logo aps tomarem conhecimento dos
custos e dos riscos de desenvolvimento de um sistema deste porte. Outras optam por
adquirir uma soluo simplificada que, no futuro poder deixar muito a desejar ocasionando
geralmente, a desativao do sistema completamente.
Uma recomendao de poltica a ser seguida consiste em se analisar os riscos de no
optar pelo desenvolvimento deste tipo de sistema. Caso a no adoo desta soluo no
afete a sade da empresa (como, por exemplo, a sua perda de competitividade), ento ela
poder adotar algumas solues paliativas porm, o administrador da empresa deve sempre
considerar que, caso a empresa apresente um crescimento, em muito pouco tempo este
crescimento ir gerar a necessidade de implantao de um sistema de gerncia que seja o
mais abrangente possvel.
Quando o sistema de gerncia implantado de forma consciente, o retorno de
investimento muito claro, isto , a minimizao ou mesmo a ausncia de falhas, o
aumento do desempenho, a integrao e segurana das informaes, a contabilizao de
utilizao de recursos e o controle da configurao de sistemas e processos fornecem um
ambiente extremamente saudvel para a concretizao de bons negcios.

92

11 Bibliografia
[Adams 97] Adams, E., Willetts, K. J., The Lean Communications Provider - Surviving
the shakeout through Service Management Excellence. McGraw-Hill, 1997.
[Harnedy 97] Harnedy, S., Total SNMP - Exploring the Simple Network Management
Protocol, Prentice Hall, Upper Saddle River, NJ, 1997.
LanTimes, diversos exemplares, 1998
[Perkins 97] Perkins, D., McGinnis, E., Understanding SNMP MIBs, Prentice Hall,
Upper Saddle River, NJ, 1997.
[Spec-1 98] Specialski, E., Otimizando a integrao de sistemas gerenciais em
ambientes multifornecedor, Conferncia sobre Tecnologia da Informao em Telecom,
Institute for International Research, So Paulo, maio 1998.
[Spec-2 98] Specialski, E., A complexidade da tarefa de gerenciamento e sua
automao, Workshop de Sistemas Inteligentes para o Gerenciamento de Redes, USP, So
Paulo, junho 1998.
[Spec-3 98] Specialski, E., Aplicando Data Warehouse no ambiente de
Telecomunicaes. Seminrio apresentado no Ps-Graduao em Engenharia de Produo,
UFSC, julho, 1998.
[Tschichholz 95] Tschichholz, M., Hall,J., Abeck, S., Wies, R., Information Aspects
and Future Directions in an Integrated Telecommunications and Enterprise Management
Environment, Journal of Network and System Management, vol.3, Mar 1995.
[Wal 95] Waldbusser, S. Remote Network Monitoring Management Information Base,
RFC 1757. Carnegie Mellon University, February 1995.
Alguns sites:
Tpicos iniciais sobre Gerncia de Redes: http://www.hq.rnp.br/gerencia
IETF Home Page: http://www.ietf.org
IETF Structure and Internet Standards Proccess:
http://www.ietf.org/structure.html
Network Management Area
http://www.ietf.org/html.charters/wg-dir.html#Network_Management_Area
IETF MIB Modules: http://www.simple-times.org/pub/simple-times/html/
Enterprise specific MIBs (The SimpleWeb)
http://wwwsnmp.cs.utwente.nl/ietf/enterprise.html
RFC Editor: http://www.isi.edu/rfc-editor/overview.html
SunNet Manager:http://www.sun.com/sunsoft/solstice/net_mgt.html
SystemView
93

http://www.software.ibm.com/sysman/technology/
http://www.software.ibm.com/sysman/technology/snmpv2wp.html
IBM NetView for Windows Version 2
http://www.raleigh.ibm.com/nvm/nvmover.html
Hp-Openview
http://www.inotech.com/sample/index.html
http://hpcc998.external.hp.com:80/nsmd/ov/rpm/novntpr.htm
http:// hpcc998.external.hp.com:80/nsmd/ov/whatisov/wnm.html
POLYCENTER Manager on Netview (DEC)
http://www.networks.digital.com/npb/html/products_guide/polyntvw.html
Transcend (3COM)
http://www.3com.com/0files/products/dsheets/tnmunix.html
http://www.3com.com/0files/products/dsheets/400195.html
CiscoWorks (Cisco)
http://www.cisco.com/warp/public/734/cworks/index.html
Spectrum (Cabletron)
http://www.ctron.com/spectrum/
Patrol (BMC) - Gerencia aplicaes HTTP, NFS, etc
http://www.bmc.com/products/pat/internet/index.html
Whats UP (sistema monitor de redes -Win95)
http://www.ipswitch.com/pd_whatsup.html
HNMS (Sistema de Gerenciamento)
http://cognac.cosmic.uga.edu/pub/HNMS.html
Netscarf (ferramenta de monitorao de trfego)
http://nic.merit.edu/~netscarf/proposal.html

94

12 Anexo: Informaes sobre alarmes: Causa provvel

This parameter defines further qualification as to the probable cause of the alarm. Probable
cause values for notifications shall be indicated in the behaviour clause of the object class
definition. This Recommendation | International Standard defines, for use within the
Systems management application context defined in CCITT X.701 | ISO/IEC 10040,
standard Probable causes that have wide applicability across managed object classes. These
values are registered in CCITT X.721 | ISO/IEC 10165-2. The syntax of standard Probable
causes shall be the ASN.1 type object identifier. Additional standard Probable causes, for
use within the Systems management application context defined in CCITT X.701 | ISO/IEC
10040, may be added to this Recommendation | International Standard and registered using
the registration procedures defined for ASN.1 object identifier values in CCITT Rec. X.208
| ISO/IEC 8824.
Other Probable causes, for use within the Systems management application context defined
in CCITT X.701 | ISO/IEC 10040, may be defined outside of this Recommendation |
International Standard and registered using the procedures defined for ASN.1 object
identifier values in CCITT Rec. X.208 | ISO/IEC 8824.
Probable causes may be defined for use outside of the Systems management application
context; the syntax of such Probable causes shall be either an ASN.1 object identifier or
ASN.1 type integer.
The managed object class definer should choose the most specific Probable cause
applicable.
This Recommendation | International Standard defines the following Probable causes

adapter error;

application subsystem failure: A failure in an application subsystem has

occurred (an application subsystem may include software to support the
Session, Presentation or Application layers);

bandwidth reduced: The available transmission bandwidth has decreased;

call establishment error: An error occurred while attempting to establish a

connection;

communications protocol error: A communication protocol has been violated;

communications subsystem failure: A failure in a subsystem that supports

communications over telecommunications links, these may be implemented via
leased telephone lines, by X.25 networks, token-ring LAN, or otherwise;

configuration or customization error: A system or device generation or

customization parameter has been specified incorrectly, or is inconsistent with
the actual configuration;

congestion: A system or network component has reached its capacity or is

approaching it;

corrupt data: An error has caused data to be incorrect and thus unreliable;

CPU cycles limit exceeded: A Central Processing Unit has issued an

unacceptable number of instructions to accomplish a task;
95

dataset or modem error: An internal error has occurred on a dataset or modem;

degraded signal: The quality or reliability of transmitted data has decreased;

DTE-DCE interface error: A problem in a DTE-DCE interface, which includes

the interface between the DTE and DCE, any protocol used to communicate
between the DTE and DCE and information provided by the DCE about the
circuit;

enclosure door open;

equipment malfunction: An internal machine error has occurred for which no

more specific Probable cause has been identified;

excessive vibration: Vibratory or seismic limits have been exceeded;

file error: The format of a file (or set of files) is incorrect and thus cannot be
used reliably in processing;

fire detected;

flood detected;

framing error: An error in the information that delimits the bit groups within a
continuous stream of bits;

heating/ventilation/cooling system problem;

humidity unacceptable: The humidity is not within acceptable limits;

I/O device error: An error has occurred on the I/O device;

input device error: An error has occurred on the input device;

LAN error: An error has been detected on a local area network;

leak detected: A leakage of (non-toxic) fluid or gas has been detected;

local node transmission error: An error occurred on a communications channel

between the local node and an adjacent node;

loss of frame: An inability to locate the information that delimits the bit
grouping within a continuous stream of bits;

loss of signal: An error condition in which no data is present on a

communications circuit or channel;

material supply exhausted: A supply of needed material has been exhausted;

multiplexer problem: An
communications signals;

out of memory: There is no program-addressable storage available;

output device error: An error has occurred on the output device;

performance degraded: Service agreements or service limits are outside of

acceptable limits;

power problem: There is a problem with the power supply for one or more
resources;

pressure unacceptable: A fluid or gas pressure is not within acceptable limits;

error

has

occurred

while

multiplexing

96

processor problem: An internal machine error has occurred on a Central

Processing Unit;

pump failure: Failure of mechanism that transports a fluid by inducing pressure

differentials within the fluid;

queue size exceeded: The number of items to be processed (configurable or

not) has exceeded the maximum allowable;

receive failure;

receiver failure;

remote node transmission error: An error occurred on a communication channel

beyond the adjacent node;

resource at or nearing capacity: The usage of a resource is at or nearing the

maximum allowable capacity;

response time excessive: The elapsed time between the end of an inquiry and
beginning of the answer to that inquiry is outside of acceptable limits;

retransmission rate excessive: The number of repeat transmissions is outside of

acceptable limits;

software error: A software error has occurred for which no more specific
Probable cause can be identified;

software program abnormally terminated: A software program has abnormally

terminated due to some unrecoverable error condition;

software program error: An error has occurred within a software program that
has caused incorrect results;

storage capacity problem: A storage device has very little or no space available
to store additional data;

temperature unacceptable: A temperature is not within acceptable limits;

threshold crossed: A limit (configurable or not) has been exceeded;

timing problem: A process that requires timed execution and/or coordination

cannot complete, or has completed but cannot be considered reliable;

toxic leak detected: A leakage of toxic fluid or gas has been detected;

transmit failure;

transmitter failure;
underlying resource unavailable: An entity upon which the reporting object
depends has become unavailable;

version mismatch: There is a conflict in the functionality of versions of two or

more communicating entities which may affect any processing involving those
entities.

97