Gerncia de Redes de Computadores

e de Telecomunicaes

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-9739
Fax: (048) 331-9566
E-mail: beth@inf.ufsc.br

Sumrio

1. NECESSIDADES DE GERENCIAMENTO...........................................................................................2
1.1. GERENCIAMENTO DE FALHAS.................................................................................................................. 3
1.2. GERENCIAMENTO DE CONTABILIZAO...................................................................................................3
1.3. GERENCIAMENTO DE CONFIGURAO..................................................................................................... 4
1.4. GERENCIAMENTO DE DESEMPENHO......................................................................................................... 4
1.5. GERENCIAMENTO DE SEGURANA........................................................................................................... 5
2. MODELOS DE GERENCIAMENTO DE REDE..................................................................................5
2.1. SOFTWARE DE APRESENTAO................................................................................................................ 6
2.2. SOFTWARE DE GERENCIAMENTO............................................................................................................. 8
2.3. SOFTWARE DE SUPORTE AO GERENCIAMENTO..........................................................................................8
3. A ARQUITETURA SNMP......................................................................................................................10
3.1. OBJETIVOS DA ARQUITETURA............................................................................................................... 10
3.2. ELEMENTOS DA ARQUITETURA.............................................................................................................. 10
3.3. MODELO DE INFORMAO.................................................................................................................... 11
3.4. MONITORAO DA REDE...................................................................................................................... 11
3.5. CONTROLE DE REDE............................................................................................................................. 12
3.6. A BASE DE INFORMAES DE GERENCIAMENTO - MIB............................................................................13
3.7. MONITORAO REMOTA - RMON MIB................................................................................................ 16
4. GERNCIA DE REDES DE TELECOMUNICAES......................................................................17
5. A ARQUITETURA DE GERENCIAMENTO OSI..............................................................................19
5.1 ESTRUTURAS DE GERENCIAMENTO......................................................................................................... 19
5.2 COMPONENTES DE GERNCIA OSI.......................................................................................................... 21
5.3. ESTRUTURA DA INFORMAO DE GERENCIAMENTO................................................................................22
5.4. SERVIOS E PROTOCOLOS DE COMUNICAO..........................................................................................22
6. SERVIOS DE SUPORTE COMUNICAO.................................................................................25
6.1. A CAMADA DE APLICAO OSI......................................................................................................... 25
6.1.1. ELEMENTOS DE SERVIO PARA APLICAES DE GERENCIAMENTO.........................................................25
6.2 FLUXO DA INFORMAO DE GERENCIAMENTO.........................................................................................31
6.3. CONHECIMENTO DE GERENCIAMENTO COMPARTILHADO........................................................................34
6.4. DOMNIOS GERENCIAIS......................................................................................................................... 35
7. FUNES E SERVIOS CMISE..........................................................................................................36
7.1. SERVIOS DE GERENCIAMENTO.............................................................................................................. 37
7.2. PROTOCOLO DE GERENCIAMENTO CMIP................................................................................................ 41
8. ARQUITETURA FUNCIONAL DO MODELO OSI...........................................................................44
8.1. SMASE - SYSTEM MANAGEMENT APPLICATION SERVICE ELEMENT ASPECTOS FUNCIONAIS....................46
9. CARACTERSTICAS DAS ARQUITETURAS DE GERENCIAMENTO.......................................62
9.1. A UTILIZAO DE PLATAFORMAS DE GERENCIAMENTO: MITOS E FATOS....................................................62
9.2. A VISO DOS DADOS............................................................................................................................. 63
10.
IMPLANTAO DE UM SISTEMA DE GERNCIA...................................................................64
10.1. ESTRATGIA PARA IMPLANTAO DE UM SISTEMA DE GERNCIA...........................................................64
10.2. CARACTERSTICAS DA EQUIPE:............................................................................................................ 64
10.3. DIMENSIONAMENTO DO TRABALHO..................................................................................................... 65
11.
CONSIDERAES FINAIS...............................................................................................................65
12.
BIBLIOGRAFIA..................................................................................................................................66
13.
ANEXO..................................................................................................................................................68
INFORMAES SOBRE ALARMES: CAUSA PROVVEL......................................................................................68

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.
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.

1.1. 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.

1.2. 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.

1.3. 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. 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 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
requisies de usurios.

1.4. 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.

1.5. 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.

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 , a maioria do hardware
e software necessrio para o gerenciamento da rede 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
6

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

elemento de
aplicao

Servio de transporte de dados de gerenciamento de rede

Mdulo de acesso
MIB

(c)

Aplicao de gerenciamento de
rede

MIB

Pilha de protocolos
de comunicao

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
7

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 funes de propsito geral que servem de
suporte 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.

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 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.

3. A arquitetura SNMP
O modelo arquitetural SNMP uma coleo de estaes de gerenciamento e
elementos de rede. As estaes de gerenciamento executam aplicaes de gerenciamento
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, 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.

3.1. Objetivos da Arquitetura

O modelo proposto busca minimizar o nmero e a complexidade de funes de
gerenciamento realizadas 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.2. Elementos da Arquitetura

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;
10

 a definio dos relacionamentos administrativos entre entidades de gerenciamento;

a forma e o significado das referncias s informaes de gerenciamento.

3.3. Modelo de informao

Dois documentos definem a informao de gerenciamento no modelo SNMP: o
RFC 1065 Estrutura da Informao de Gerenciamento e o RFC 1066- Base de Informao
de Gerenciamento. Os dois documentos foram projetados para serem compatveis tanto com
o SNMP quanto com o modelo de gerenciamento OSI, porm, o modelo de informao de
gerenciamento OSI utiliza definies mais complexas.
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.

3.4. Monitorao da Rede

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.

11

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;
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.

3.5. 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

12

3.6. 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.
A informao de gerenciamento representada de acordo com um sub-conjunto
da linguagem ASN.1, que especificada para a definio de tipos no agregados na SMI.
Tambm, para efeitos de simplicidade, o SNMP utiliza um sub-conjunto das regras bsicas
de codificao ASN.1. Todas as codificaes utilizam a forma de tamanho definido. Alm
disso, quando permitido, so usadas codificaes de no construtores, preferencialmente
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 identificado, 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.1 mostra a rvore de registro utilizada para nomeao de objetos

13

definidos na MIB.
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.
TOP
CCITT (0)

JOINT-ISO-CCITT (2)

ISO (1)

STD(0)

MEMBER
BODY(2)

ORG (3)

REG

DOD (6)

AUTHORITY(1)
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.1 - rvore de registro de tipos de objetos

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;

14

 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;
transmission: fornece informaes sobre esquemas de transmisso e protocolos de
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.2 ilustra a estrutura do grupo system e a tabela 3.1 fornece a sintaxe do
objeto, a forma de acesso permitida e uma descrio suscinta da semntica.
system
system(mib-2
(mib-21)
1)
sysDescr(1)
sysObjectID(2)
sysUpTime(3)
sysContact(4)
sysName(5)
sysLocation(6)
sysServices(7)
Fig. 3.2. Grupo System da MIB-II

15

Tabela 3.1 - Objetos do grupo System da MIB-II

Objeto

Sintaxe

Acesso

Semntica

sysDescr

DisplayString (Size (0..255)

RO

Descrio de uma entidade

(hardware, sistema operacional, etc.

sysObjectID

OBJECT IDENTIFIER

RO

Identificao do sub-sistema contido

na entidade

sysUpTime

TimeTicks

RO

Tempo decorrido desde a ltima

reinicializao

sysContact

DisplayString (Size (0..255)

RW

Identificao da pessoa de contato

para este nodo gerenciado

sysName

DisplayString (Size (0..255)

RW

Nome atribudo administrativamente

para este nodo

sysLocation

DisplayString (Size (0..255)

RW

Localizao fsica do nodo

sysServices

INTEGER (0..127)

RO

Valor indicando o conjunto de

servios oferecidos pela entidade

3.7. Monitorao Remota - RMON MIB

A mais importante adio ao conjunto de padres SNMP foi a RMON MIB
(Remote Monitoring MIB), descrita no documento RFC 1757 [Wal 95].
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 referem-se 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.
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 pode estar implementado em estaes de trabalho, 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.
A RMON foi projetada para atingir os seguintes objetivos:

16

operao off-line: o monitor coleta e armazena estatsticas que podem

ser recuperadas pela estao gerente a qualquer momento;

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.

4. 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 4.1:

17

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 4.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, considerandose 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.
Uma vez instalado, um servio de telecomunicao deve ser constantemente
observado para a identificao de fatores que possam influenciar em seu desempenho. A
18

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.

5. 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

5.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.
processo gerente

processo agente

SMAE

CMIP

SMAE

MIB
LME
LME
LME
LME

APLICAO

LME

APRESENTAO

LME

SESSO

LME

TRANSPORTE

LME

APLICAO

MIB

APRESENTAO
SESSO

TRANSPORTE

LME

REDE

LME

REDE

LME

ENLACE

LME

ENLACE

LME

FSICO

LME

FSICO

Figura 5.1 Gerenciamento de Sistemas

19

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

protocolo de gerenciamento
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.

conexo 1
conexo 2
...
conexo n

operao de
camada

Figura 5.3 Operao de Camada

5.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
20

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 MIS-User 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

5.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 sua implementao no est sujeita padronizao. As
informaes so definidas segundo uma SMI (Structure Management Information). No
modelo de 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.

5.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
21

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
Objetos
MIS-User
(papel de agente) 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 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-EVENTREPORT, 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 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

22

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.

23

Tabela 5.1 Servios de Gerenciamento

Tipo de servio
M-CANCEL-GET
(operao)
M-GET
(operao)
M-SET
(operao)

Modo de
requisio
confirmado

confirmado
confirmado
no confirmado
confirmado

M-CREATE
(operao)
M-ACTION
(operao)

confirmado
no confirmado
confirmado

M-DELETE
(operao)
M-EVENT-REPORT
(notificao)

no confirmado
confirmado
no confirmado

Primitivas
request/indication
response/confirm
request/indication
response/confirm
request/indication
response/confirm
request/indication
request/indication
response/confirm
request/indication
response/confirm
request/indication
request/indication
response/confirm
request/indication
request/indication
response/confirm
request/indication

Semntica
Cancelar uma
operao de leitura
realizada sobre
vrios objetos
Ler valores de
atributos de objetos
Modificar valores
de atributos de
objetos
Criar uma instncia
de objeto
Solicitar que uma
ao pr-definida
seja executada por
um objeto
Destruir uma
instncia de objeto
Notificar a
ocorrncia de um
evento a um
sistema gerente

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.

24

6. Servios de suporte comunicao

6.1. A camada de aplicao OSI
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).
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.
6.1.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
25

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.
Tabela 6.1 - Servio de Pass-throught
Servio solicitado

Servio de passthrought da OMF

Criao de objeto: Create
PT-CREATE
Destruio de objeto: Delete
PT-DELETE
Ao sobre um objeto: Action
PT-ACTION
Modificao de valor de atributo: PT-SET
Replace
Modificao de valor de atributo:
Replace-with-default
Modificao de valor de atributo: Add
Modificao de valor de atributo:
Remove
Leitura de valor de atributo: Get
Notificao

Servios do CMISE
M-CREATE
M-DELETE
M-ACTION
M-SET

PT-SET

M-SET

PT-SET
PT-SET

M-SET
M-SET

PT-GET
PT-EVENT-REPORT

M-GET
M-EVENT-REPORT

Na figura 6.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 6.1.1.1 e 6.1.1.2 apresentam
aspectos importantes dos elementos de servio ACSE e ROSE.

26

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

CMIP - PDU

Aplicao de
gerenciamento
SMASE A
C
CMISE
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 6.1 Elementos de Servio para o suporte s aplicaes de gerenciamento

6.1.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) 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;
27

 Identificador de Invocao do AP Chamador;

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) 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

28

negativamente ao pedido de finalizao da associao. Este um servio confirmado e

possui os seguintes parmetros:
Razo;
Informao do Usurio;
Resultado.
b) 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.
c) 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 6.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
A-ABORT. Request

RLRE
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
RM-OSI 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

29

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.
Os servios do ACSE so alcanados pela invocao de suas primitivas de
servio, relacionadas na tabela 6.3.

Primitiva
A-ASSOCIATE
A-RELEASE
A-ABORT
A-P-ABORT

Tabela 6.3 Primitivas do ACSE

servio oferecido
Estabelece uma associao
Libera uma conexo
Encerramento iniciado pelo usurio
Encerramento iniciado pelo provedor

tipo de servio
confirmado
confirmado
nno confirmado
s indicao

6.1.1.2.Operaes Remotas (ROSE)

O elemento de servio ROSE oferece servios de suporte 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 6.4 ilustra as possveis classes de operaes no ROSE.
Tabela 6.4 - Classes de operao definidas no ROSE
Classe de operao Tipo de interao
Forma de resposta
Operao classe 1 sncrona
relatando sucesso ou falha
Operao classe 2 assncrona
relatando sucesso ou falha
30

Operao classe 3
Operao classe 4
Operao classe 5

assncrona
assncrona
assncrona

relatando somente falha

relatando somente sucesso
resultado no relatado

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.

Primitiva
RO-INVOKE
RO-RESULT
RO-ERROR
RO-REJECT-U
RO-REJECT-P

Tabela 6.5 - Primitivas de servio do ROSE

Significado
Tipo de servio
Invoca uma operao
no confirmada
Resultado de operao bem sucedida no confirmada
Resultado de operao sem sucesso
no confirmada
Rejeio iniciada pelo usurio
no confirmada
Rejeio iniciada pelo provedor
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.

6.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
A-ASSOCIATE.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 6.2 mostra um exemplo de fluxo de informaes em uma associao entre duas
entidades de aplicao de gerenciamento.

MIS-User
local
A-Assoc.req

ACSE local

outras
camadas

ACSE remoto MIS-User remoto

PConnect.req

31

...P-

Connect.ind
A-Assoc.ind
A-Assoc.resp
PConnect.resp
PConnect.conf
A-Assoc.conf
Figura 6.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 6.3 mostra o cenrio de comunicao entre dois MISUsers, na solicitao de uma leitura de valor de atributo.

32

MIS-User SMASE
local

CMISE

ROSE
local

outras
ROSE
camadas remoto

CMISE SMASE MIS-User

remoto

PT-Get.
request
M-GET.
request
RO-INVOKE.
request
P-Data.
request
P-Data.
indic
RO-INVOKE.
indic
M-Get.
indic
PT-Get.
indic
PT-Get.
response
M-Get.
response
RO-INVOKE.
request
P-Data.
request
P-Data.
indication
RO-INVOKE.
indication
M-Get.
confirm
PT-Get.
confirm
Figura 6.3 Cenrio de comunicao para a operao de leitura de valor de atributo

33

6.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
MIS-Users 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 considerando-se uma
sub-rvore completa ou apenas um nvel particular da sub-rvore. 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

34

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 6.4, trs unidades funcionais foram negociadas para
utilizao: Multiple Objects Selection, Scoping e Multiple Reply.

A
Gerente

CMIP

unidades funcionais:
Multiple Objects Selection,
Scoping e Multiple Reply

B
Agente
objetos
gerenciados

Figura 6.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.

6.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 necessidades geogrficas. Os
domnios gerenciais devem ser definidos, portanto, com base nos seguintes critrios:
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).
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.
35

 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:
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;
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.

7. 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
36

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.

7.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 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
37

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
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.
7.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

38

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.
7.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 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.
7.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.
7.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),
39

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.
7.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
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.
7.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.

40

7.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 sequncia da requisio a ser
cancelada.

7.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:
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, so especificadas usando uma
sintaxe denominada ASN.1 (Abstract Syntax Notation One).
7.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

41

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):
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 {

42

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
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,

43

localDistinguishedName [4] IMPLICIT RDNSequence }

7.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

8. 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 AASSOCIATE (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 A-ASSOCIATE, 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

ReasonOPTIONAL,
44

-- 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
-- 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 de um conjunto de funes que oferecem servios de suporte para as aplicaes
de gerenciamento. Embora nem todas as funes sejam obrigatrias, importante que se
conhea cada uma delas no sentido de se ter parmetros para selecionar produtos de
gerenciamento no mercado.

8.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;

45

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;
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.

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

46

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 8.1.
Tabela 8.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

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

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;
47

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 8.2 e os diagramas de estado
representando a mudana de estados administrativo e de utilizao de objetos gerenciados
so apresentados nas figuras 8.1 e 8.2, respectivamente.
Tabela 8.2 Atributos de Estado
Valores possveis
Enable
Disable
Idle
Active
Busy
Unknown
Locked
Unlocked
Shutting Down

Atributo de Estado
Operacional
Utilizao

Administrativo

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
n
ou Capacidade
aumentada
Figura 8.1 Diagrama de estados de utilizao

48

Shut Down (se no existir usurio)

Lock

Unlocked

Locked

Unlock

Unlock

Shutting Down

Shut Down

Lock
Sada de ltimo usurio

Figura 8.2 Diagrama de estados administrativo

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

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 considerados so:
Direto e Indireto
Simtrico e Assimtrico
relacionamento
A

indireto

B
relacionamento
direto

C
relacionamento
direto

Categorias de Relacionamento

Relacionamento de Incluso
Relacionamento de um Sentido
Relacionamento Recproco

49

AB

RA A
B

RA B
A

Relacionamento Recproco entre os objetos A e B

Tipos de Relacionamento Recproco
Atributos de Relacionamento
Relacionamento de Servio:
Objeto Provedor: GET, REPLACE
Servidor e Usurio
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

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

MO.

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.
50

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.

L
Mais Severo
K
Nenhuma Mudana
J
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;
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.

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

8.3.

51

Objetos
Gerenciados

Notificaes

Notificaes

Processamento
e Deteco de
Eventos

Relatrios
de Eventos
Potenciais

Outros
discriminadores
Discriminador
de Repasse
Relatrio
de Eventos
de Evento
Controles
Respostas

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

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)

52

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

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 8.4.

registro
registro
registro

Informao a ser
submetida a Log

Informao de controle de Log

Figura 8.4 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

53

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;

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 8.5, segue aquele definido para a funo de
relatrio de evento.

54

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.
Objetos
Gerenciados
Notificaes
Notificaes

Processamento
e Deteco de
alarmes de
segurana

Relatrios
de Eventos
Potenciais

Outros discriminadores

Discriminador
de Repasse
de alarmes

Alarme de
segurana

Controles
Respostas
Figura 8.5. Funo de Relatrio de Alarme de Segurana

Funo de Registro para Auditoria de Segurana

Esta funo define tipos de relatrios que podem ser utilizados para registrar todos
os eventos relevantes segurana, com o objetivo de:
detectar desvios e atentados com relao s normas estabelecidas pela poltica de
segurana;
descobrir pontos vulnerveis ou problemas na concretizao da poltica de segurana
adotada.
Informaes sobre Auditoria de Segurana
Tipos de registros:

Relatrio de servio

Relatrio estatstico
Causas do Relatrio de Servio:

requisio de servio;

negao de servio;

resposta de servio;

falha de servio;

recuperao de servio;

outra razo.

Funo de Controle de Acesso

Busca prevenir contra o acesso no-autorizado aos recursos de gerenciamento OSI alm de
evitar que notificaes de gerenciamento sejam encaminhadas a destinatrios noautorizados. Visa, ainda, proteger as informaes de gerenciamento contra divulgao
indesejvel e impedir que entidades no autorizadas tenham acesso s operaes de
gerenciamento.
A poltica de controle de acesso parte da poltica de segurana do sistema.

55

Modelo de Controle de Acesso

O modelo de controle de acesso descrito pelas figuras 8.6 e 8.7 que mostram,
respectivamente, o controle de acesso na fase de associao e na fase de operaes de
gerenciamento.
Para Associao de Gerenciamento
Agente
Imposio de
Controle de
Acesso

Gerente
Processo
de
Iniciao
de
Associao

ACI meta
Contexto
Regras da Pol.
de acesso

Funo de Deciso
de Controle de
Acesso

ACI aceita

Figura 8.6. 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

Objeto
Gerenciado

Pedido de
acesso

Funo de
Deciso
Resposta

Permisses

ACI, Contexto
Regras da
Poltica de acesso

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

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:
Objeto de controle de medida de contabilizao dedicado ao controle do
gerenciamento de contabilizao

56

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.

Funo de Monitorao de Carga de Trabalho

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.

57

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.
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.
Modelo genrico para Monitorao de Carga
EWT

SCT

EWCT

ST

EWCT - Early Warning Clear Threshold

EWT - Early Warning Threshold
SCT - Severe Clear Threshold
ST - Severe Threshold
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.

58

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.

Funo de Gerenciamento de Teste

Controle remoto de testes e especificao de testes a serem realizados sobre os recursos
gerenciados.
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.

59

Testes no controlados

MO

pedido de teste

Test
Performer

Test
Conductor
relatrio de
resultado

TARR

MORT

Teste controlvel

MO
TARR

pedido de teste

Test
Conductor

monitorao e controle

relatrio de resultado

Test
Performer
TO TO
MORT

TO - Test Object
MO - Managed Object
MORT - Managed Object Referring toTest TARR - Test Action Request Receive

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.

60

Modelo da Funo de Sumarizao

Pedidos
de
Sumrios

Objetos
observados

Modelo de Sumarizao

valores de atributos
observados
atributos de
esquadrinhamento

Funo de
Relatrio de
Evento

Respostas
com Sumrios

Objeto
Sumarizador

Pr-processamento
de eventos

Discriminador
de Repasse
de Eventos
Relatrios de Eventos
contendo Notificao de
Sumrio

Objetos
Escalonados

Notificaes
de Sumrios

Pr-processamento
de eventos

Log de
Registros

Funo de
Controle de
Log

Relatrios de
Registros pedidos

61

Classes de objetos de sumarizao

topo
Esquadrinhador
Heterogneo Homogneo

Esquadrinhador
Dinmico
Simples Dinmico
Armazenador

Simples
de Mdia
de Mdia e
Varincia

Estatstico
Minimax
de Ponto de Amostragem

9. 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

9.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.

62

Uma plataforma de software consolida e gerencia funes comuns que so

usadas por aplicaes independentes. composta por comportamentos e servios e prov
um conjunto 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.

9.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,
63

no tempo 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. 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
terefa 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.

10.1. Estratgia para implantao de um sistema de gerncia

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.

10.2. Caractersticas da equipe:

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.

64

10.3. Dimensionamento do trabalho

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
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.

11. 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.

65

12. 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:
1. Tpicos iniciais sobre Gerncia de Redes
http://www.hq.rnp.br/gerencia
2. IETF Home Page
http://www.ietf.org
3. IETF Structure and Internet Standards Proccess
http://www.ietf.org/structure.html
4. Network Management Area
http://www.ietf.org/html.charters/wgdir.html#Network_Management_Area
5. IETF MIB Modules
http://www.simple-times.org/pub/simple-times/html/
6. Enterprise specific MIBs (The SimpleWeb)

66

http://wwwsnmp.cs.utwente.nl/ietf/enterprise.html
7. RFC Editor
http://www.isi.edu/rfc-editor/overview.html
8. SunNet Manager
http://www.sun.com/sunsoft/solstice/net_mgt.html
9. SystemView
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
10. 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
11. POLYCENTER Manager on Netview (DEC)
http://www.networks.digital.com/npb/html/products_guide/polyntvw.html
12. Transcend (3COM)
http://www.3com.com/0files/products/dsheets/tnmunix.html
http://www.3com.com/0files/products/dsheets/400195.html
13. CiscoWorks (Cisco)
http://www.cisco.com/warp/public/734/cworks/index.html
14. Spectrum (Cabletron)
http://www.ctron.com/spectrum/
15. Patrol (BMC) - Gerencia aplicaes HTTP, NFS, etc
http://www.bmc.com/products/pat/internet/index.html
16. Whats UP (sistema monitor de redes -Win95)
http://www.ipswitch.com/pd_whatsup.html
17. HNMS (Sistema de Gerenciamento)
http://cognac.cosmic.uga.edu/pub/HNMS.html
18. Netscarf (ferramenta de monitorao de trfego)
http://nic.merit.edu/~netscarf/proposal.html

Anexo

67

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;

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;

68

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;

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;

error

has

occurred

while

multiplexing

69

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.

70