Vous êtes sur la page 1sur 72

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

INFORMAES SOBRE ALARMES: CAUSA PROVVEL ................................................................................................70

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 6

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

AGENTE ROTEADOR AGENTE

GERENTE

HUB AGENTE


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

2.1. Software de apresentao


A interface de usurio, em um sistema de gerenciamento, permite que o usurio monitore e controle a rede. Normalmente ela est localizada no sistema hospedeiro gerente. Em alguns casos comum existir uma interface em alguns agentes a fim de permitir a execuo de testes e tambm a visualizao ou alterao de alguns parmetros localmente. 8

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

Aplicao de gerenciamento de rede


elemento de aplicao elemento de aplicao elemento de aplicao

(b) Servio de transporte de dados de gerenciamento de rede

Mdulo de acesso MIB

Pilha de protocolos de comunicao

(c)

MIB

rede gerenciada

Figura 2.2. Arquitetura de um sistema de gerenciamento de rede. O principal, em qualquer sistema de gerenciamento, que a interface seja unificada, isto , que ela seja a mesma em qualquer nodo, permitindo que o usurio gerencie uma rede heterognea com um mnimo de treinamento. Um dos perigos em qualquer sistema de gerenciamento a sobrecarga de informaes. Dependendo da configurao estabelecida, uma grande quantidade de 9

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.

10

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

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

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

11

3. A arquitetura SNMP
O modelo arquitetural SNMP 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; a definio dos relacionamentos administrativos entre entidades de 12

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. A escolha da nfase depende de um nmero de fatores, incluindo os seguintes: 13

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

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

14

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 1 org 3 dod 6 internet 1 mgmt 2 mib 1 system 1 sysDescr 1

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

15

configurao.
TOP C C IT T (0 ) JO IN T -IS O -C C IT T (2 )

IS O (1 )

S T D (0 ) REG A U T H O R IT Y (1 )

M EM BER B O D Y (2 )

O R G (3 ) D O D (6 ) IN T E R N E T (1 )

D IR E C T O R Y (1 )

M G M T (2 ) E X PE R IM E N T A L(3 )

PR IV A T E (4 )

M IB (1 )

E N T E R PR IS E S [1 ]

E G P (8 ) TC P (6 ) IN T E R F A C E (2 ) IP (4 ) IC M P (5 ) S Y S T E M (1 ) AD DRESS T R A N S LA T IO N (3 ) U D P (7 ) IB M (2 ) PR O TE O N (1 ) R E S E R V E D (0 )

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 subrede; at(address translation; deprecated): descreve a tabela de translao de endereos para mapeamento de endereos internet para endereos de sub-rede; ip: informao relativa a experincias de implementao e execuo do protocolo IP (internet protocol) no sistema; icmp: informao relativa a experincias de implementao e execuo do protocolo ICMP (internet control message protocol) no sistema; tcp: informao relativa a experincias de implementao e execuo do protocolo TCP (transmission control protocol) no sistema; udp: informao relativa a experincias de implementao e execuo do 16

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 (mib-2 1) sysDescr(1) sysObjectID(2) sysUpTime(3) sysContact(4) sysName(5) sysLocation(6) sysServices(7) Fig. 3.2. Grupo System da MIB-II

17

Tabela 3.1 - Objetos do grupo System da MIB-II Objeto sysDescr sysObjectID sysUpTime sysContact sysName sysLocation sysServices Sintaxe DisplayString (Size (0..255) OBJECT IDENTIFIER TimeTicks DisplayString (Size (0..255) DisplayString (Size (0..255) DisplayString (Size (0..255) INTEGER (0..127) Acesso RO RO RO RW RW RW RO Semntica
Descrio de uma entidade (hardware, sistema operacional, etc. Identificao do sub-sistema contido na entidade Tempo decorrido desde a ltima reinicializao Identificao da pessoa de contato para este nodo gerenciado Nome atribudo administrativamente para este nodo Localizao fsica do nodo 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:

18

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:

19

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 20

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 MIB LME LME LME LME LME LME LME APLICAO APRESENTAO SESSO

CMIP

SMAE

LME LME LME LME LME LME LME

APLICAO APRESENTAO SESSO

MIB

TRANSPORTE
REDE ENLACE FSICO

TRANSPORTE
REDE ENLACE FSICO

Figura 5.1 Gerenciamento de Sistemas

21

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

cam ada N

p r o t o c o l o d e g e r e n c i a m e n to d a cam ada N

cam ada 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 22

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 23

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

24

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.

25

Tabela 5.1 Servios de Gerenciamento


Tipo de servio M-CANCEL-GET (operao) M-GET (operao) M-SET (operao) M-CREATE (operao) M-ACTION (operao) M-DELETE (operao) M-EVENTREPORT (notificao) Modo de requisio 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

confirmado confirmado no confirmado confirmado confirmado no confirmado confirmado no confirmado confirmado no confirmado

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.

26

6. Servios de suporte comunicao


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

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 M-SET M-SET M-SET

PT-SET PT-SET PT-SET

PT-GET M-GET PT-EVENT-REPORT 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.

28

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

Aplicao de gerenciamento A SMASE 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; Identificador de Invocao do AP Chamador;

29

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 negativamente ao pedido de finalizao da associao. Este um servio confirmado e possui os seguintes parmetros: Razo; Informao do Usurio; Resultado.

30

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 A-ASSOCIATE. Request A-ASSOCIATE. Response A-RELEASE. Request A-RELEASE.response A-ABORT. Request APDU AARQ AARE RLRQ 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 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. Tabela 6.3 Primitivas do ACSE

31

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

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

tipo de servio confirmado confirmado n confirmado no 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 Operao classe 3 assncrona relatando somente falha Operao classe 4 assncrona relatando somente sucesso Operao classe 5 assncrona 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. 32

Tabela 6.5 - Primitivas de servio do ROSE Primitiva Significado Tipo de servio RO-INVOKE Invoca uma operao no confirmada RO-RESULT Resultado de operao bem sucedida no confirmada RO-ERROR Resultado de operao sem sucesso no confirmada RO-REJECT-U Rejeio iniciada pelo usurio no confirmada RO-REJECT-P 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 PConnect.req

outras camadas

ACSE remoto MIS-User remoto

...P-

Connect.ind A-Assoc.ind A-Assoc.resp PConnect.resp PConnect.conf A-Assoc.conf

33

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.

34

MIS-User SMASE local PT-Get. request M-GET. request

CMISE

ROSE local

outras ROSE camadas remoto

CMISE SMASE MIS-User remoto

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

35

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 executada sobre ele. Multiple Reply (opcional) permite que vrias respostas sejam emitidas a partir de uma 36

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

B Agente objetos gerenciados

unidades funcionais: Multiple Objects Selection, Scoping e Multiple Reply

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. formas de controle consistentes devem ser estabelecidas, isto , o agrupamento de objetos gerenciados em um domnio de gerenciamento deve permitir, por exemplo, a

37

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

38

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 comparao associadas com o tipo do atributo. So definidas as seguintes regras de comparao:

39

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

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

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

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] funcional Units accessControl userInfo [1] [2] [3] IMPLICIT ProtocolVersion IMPLICIT FuncionalUnits EXTERNAL OPTIONAL, EXTERNAL OPTIONAL } DEFAULT {version1}, DEFAULT { },

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

43

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 argument Exemplo: m-Get OPERATION ::= localValue 3 ROIV-m-Get ::= ROIVapdu ( WITH COMPONENTS { invokeID linked-ID operation-value argument Operao M-GET M-Get OPERATION ARGUMENT RESULT GetArgument GetResult PRESENT, ABSENT, (m-Get), (INCLUDES GetArgument) } ) [0] operation-value InvokeIDType, IMPLICIT InvokeIDType OPTIONAL, OPERATION, ANY DEFINED BY operation-value OPTIONAL }

InvokeIDType ::= INTEGER

ERRORS (accessDenied, classInstanceConflict, complexityLimitation, operationCancelled, getListError, invalidFilter, invalidScope, noSuchObjectClass, noSuchObjectInstance, processingFailure, syncNotSupported) LINKED (m-Linked-Reply) ::= localValue 3 GetArgument ::= SEQUENCE { COMPONENTS OF BaseManagedObjectId, accessControl scope [5] AccessControl OPTIONAL, [7] Scope DEFAULT baseObject, synchronization [6] IMPLICIT CMISSync DEFAULT bestEffort,

44

filter attributeIdList

CMISFilter DEFAULT and { }, [12] IMPLICIT SET OF AttributeId OPTIONAL } baseManagedObjectClass ObjectClass,

BaseManagedObjectId ::= SEQUENCE { 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 and or not [8] FilterItem, [9] IMPLICIT SET OF CMISFilter, [10] IMPLICIT SET OF CMISFilter, [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 localForm [0] IMPLICIT OBJECT IDENTIFIER, [1] IMPLICIT INTEGER } [2] IMPLICIT DistinguishedName, [3] IMPLICIT OCTET STRING,

ObjectInstance ::= CHOICE { distinguishedName nonSpecificForm

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 45

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

46

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

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

48

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
Create Delete Action Replace Add Remove Replace-with-Default Get Notification

Pass - Through
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;

49

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. Atributo de Estado Operacional Utilizao Tabela 8.2 Atributos de Estado Valores possveis Enable Disable Idle Active Busy Unknown Locked Unlocked Shutting Down Sada de usurio Idle Novo usurio Novo usurio Busy Sada do ltimo Usurio CI ou Sada de usurio

Administrativo

Active Novo usurio ou Capacidade diminuida

Novo usurio ou CD

Unknow Sada de usurio n ou Capacidade aumentada Figura 8.1 Diagrama de estados de utilizao

50

Shut Down (se no existir usurio) Unlocked Lock Unlock Locked

Unlock Shut Down

Shutting 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 relacionamento direto B relacionamento direto indireto C

Categorias de Relacionamento

Relacionamento de Incluso Relacionamento de um Sentido Relacionamento Recproco

51

RA A B

AB

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 Relacionamento Fallback: Primrio e Secundrio Relacionamento Backup: Backup e Backed-up Relacionamento de Grupo: Proprietrio e Membro Par: GET Primrio: GET, REPLACE Secundrio: GET, REPLACE Instncia de Objeto Backup: GET Instncia de Objeto Backed-up: GET 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. 52

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.

53

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) Pacote de Programao Externa (External Schedular Scheduling Package) tem um nico atributo que especifica o nome do MO programador (SchedularName).

54

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 Registros de Log Representam a informao armazenada no Log. A classe Registro de Log definida com dois atributos: Log Record Id (Get)

55

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

56

Objetos Gerenciados Notificaes Notificaes Outros discriminadores

Processamento e Deteco de alarmes de segurana

Relatrios de Eventos Potenciais

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.

57

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 Gerente Processo de Iniciao de Associao Imposio de Controle de Acesso 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 Processo de Seleo Processo de Resposta

Pedido Negao

Objeto Funo de Permisses Gerenciado Controle Pedido de acesso ACI, Contexto Regras da Poltica de acesso

Deciso de acesso

Resposta

Funo de Deciso Resposta

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

58

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. Modelos Modelo de Utilizao: monitorao do uso instantneo de um recurso OSI. 59

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

60

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.

61

Testes no controlados

pedido de teste

MO Test Performer TARR

Test Conductor
relatrio de resultado

MORT

Teste controlvel

pedido de teste

Test Conductor

monitorao e controle

MO TARR
Test Performer TO TO MORT

relatrio de resultado

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.

62

Modelo da Funo de Sumarizao


Pedidos de Sumrios Respostas com Sumrios Modelo de Sumarizao

Objetos observados

valores de atributos observados atributos de esquadrinhamento

Objeto Sumarizador

Objetos Escalonados

Funo de Relatrio de Evento

Pr-processamento de eventos

Notificaes de Sumrios

Pr-processamento de eventos

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

Log de Registros

Funo de Controle de Log

Relatrios de Registros pedidos

63

Classes de objetos de sumarizao


topo Esquadrinhador Heterogneo Homogneo Simples de Mdia de Mdia e Varincia Esquadrinhador Dinmico Simples Dinmico Armazenador 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. Uma plataforma de software consolida e gerencia funes comuns que so

64

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, no tempo certo, na forma certa e com o custo certo, de tal forma que eles possam tomar 65

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.

66

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.

67

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)

68

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

69

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;

70

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; error has occurred while multiplexing

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;

71

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.

72

Vous aimerez peut-être aussi