Académique Documents
Professionnel Documents
Culture Documents
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.
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
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.
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.
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.
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.
Um software de gerenciamento genrico composto por: Elementos gerenciados Agentes Gerentes Bancos de Dados de Informaes Protocolos para troca de informaes de gerenciamento Interfaces para programas aplicativos Interfaces com o usurio
HOSPEDEIRO CONTROLADOR
GERENTE
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)
A figura 2.2 (a) mostra os dois blocos que representam o software de apresentao das informaes de gerncia.
elemento de aplicao elemento de aplicao elemento de aplicao
(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.
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.
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.
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
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.
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
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.
SMAE MIB LME LME LME LME LME LME LME APLICAO APRESENTAO SESSO
CMIP
SMAE
MIB
TRANSPORTE
REDE ENLACE FSICO
TRANSPORTE
REDE ENLACE FSICO
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
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.
operao de camada
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
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.
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
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
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
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
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
servio oferecido Estabelece uma associao Libera uma conexo Encerramento iniciado pelo usurio Encerramento iniciado pelo provedor
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.
outras camadas
...P-
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
CMISE
ROSE local
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
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
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.
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.
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.
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.
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 }
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,
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
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.
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.
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
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
Novo usurio ou CD
Unknow Sada de usurio n ou Capacidade aumentada Figura 8.1 Diagrama de estados de utilizao
50
Shutting Down
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
Categorias de Relacionamento
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
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.
53
Notificaes
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
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;
56
Alarme de segurana
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
ACI aceita
Pedido Negao
Objeto Funo de Permisses Gerenciado Controle Pedido de acesso ACI, Contexto Regras da Poltica de acesso
Deciso de acesso
Resposta
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.
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.
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
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
Objetos observados
Objeto Sumarizador
Objetos Escalonados
Pr-processamento de eventos
Notificaes de Sumrios
Pr-processamento de eventos
Log de Registros
63
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.
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.
66
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
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