apostila gerencia de redes unc

UNIVERSIDADE DO CONTESTADO ENGENHARIA EM TELECOMUNICAES ELETIVA PROFISSIONAL III - GERNCIA DE REDES

GERNCIA DE REDES

Semestre 2010/1

Gerncia de Redes 2010/1

2

SUMRIO1. Conceitos e Princpios de Redes e Gerenciamento de Redes 2. reas Funcionais de Gerenciamento de Redes 3. SLA e SLM 4. Modelo OSI de Gerenciamento de Rede 03 11 15 24

5. Rede de Gerenciamento de Telecomunicaes TMN 30 6. Simple Network Management Protocol - SNMP 7. Gerenciamento de Servios ITIL 8. Acrnimos 9. Referncias 42 68 72 76

Engenharia em Telecomunicaes - UnC


3

1. Conceitos e Princpios Gerenciamento de Redes

de

Redes

e

1.1. Requisitos Fundamentais de Uma Infra-Estrutura para Tratamento da InformaoOs requisitos a seguir apresentados so considerados fundamentais, embora possam ser apresentados outros que certamente contribuiriam para ficar mais abrangente os objetivos que esta infra-estrutura deve atender. ABRANGNCIA (UBIQIDADE - UNIVERSALIZAO) o A infra-estrutura de comunicaes deve ter como requisito permitir que os servios e aplicaes possam estar presentes o mais prximo do usurios em qualquer lugar que ele esteja e em qualquer momento. ACESSIBILIDADE o A infra-estrutura de comunicaes deve ter como requisito permitir que qualquer usurio possa ter acesso a qualquer outro usurio e que restries de acesso possam ser controladas em funo das necessidades dos prprios usurios e no por restries da infraestrutura. DISPONIBILIDADE o A infra-estrutura de comunicaes deve ter como requisito permitir que o acesso aos servios estejam disposio dos usurios elevada taxa de tempo. Os meios e recursos devem ter alta confiabilidade e tempos de interrupes minimizadas atravs de um eficiente gerenciamento do desempenho desta infra-estrutura. GRAU DE SERVIO o A infra-estrutura de comunicaes deve ter como requisito permitir que as ligaes tenham uma elevada probabilidade que sejam completadas, uma vez que por razes econmicas, muitos meios podem ser compartilhados por muitos usurios podendo existir bloqueios por congestionamentos ou por motivo que o outro usurio destino esteja utilizando seu terminal. o Cabe aqui no confundir grau de servio com disponibilidade e acessibilidade. Pode-se ter um grau de servio no muito satisfatrio embora se tenha alto grau de disponibilidade (rede sem defeito) e acessibilidade plena. INTELIGIBILIDADE



4

o A infra-estrutura de comunicaes deve ter como requisito permitir que os sinais que transportam as informaes tenham minimizados as distores e erros de transmisso ou qualquer outro fator que prejudique a sua compreenso. OPERACIONALIDADE o A infra-estrutura de comunicaes deve ter como requisito permitir que o acesso aos servios sejam amigveis na sua utilizao. Aspectos ergonmicos precisam ser considerados alem da simplicidade de uso que deve ser a mais natural para o usurio e portanto, assimilvel. Deve tambm ser amigvel para os operadores da empresas concessionrias dos servios INTEROPERABILIDADE o A infra-estrutura de comunicaes deve ter como requisito permitir que diferentes terminais conectados em redes distintas possam se intercomunicar. PORTABILIDADE o A infra-estrutura de comunicaes deve ter como requisito permitir que os acessos aos servios sejam padronizados de modo a permitir que os terminais e equipamentos dos usurios possam ser ligados esta infra-estrutura em qualquer ponto da rede com o mesmo nmero de identificao. ECONOMICIDADE o A infra-estrutura de comunicaes deve ter como requisito permitir que os meios e recursos sejam eficientemente arquitetados, projetados e utilizados de modo a permitir servios a preos cada vez mais acessveis aos usurios que a utilizam e rentabilidade para as empresas operadoras. SEGURANA o A infra-estrutura de comunicaes deve ter como requisito oferecer segurana s comunicaes permitindo sigilo e proteo contra fraudes. Inclui neste requisito a segurana fsica para os usurios quanto proteo eltrica e eletromagntica dos equipamentos e redes.

1.2. Conceitos de Informao e ComunicaoINFORMAO Medida da reduo da incerteza, sobre um determinado estado de coisas, por intermdio de uma mensagem.Engenharia em Telecomunicaes - UnC


5

MENSAGEM Estrutura organizada de sinais que serve de suporte comunicao. COMUNICAO Transmisso de mensagem entre uma fonte e o destinatrio distintos no tempo e/ou no espao. As trs definies sobre Informao, Mensagem e Comunicao precisam ser bem compreendidas pois estes conceitos sero de grande valia no decorrer dos prximos captulos. Segundo a definio sobre Informao ela uma medida relativa da utilidade que serve a um determinado propsito diminuindo, porm no eliminando, as incertezas de quem a usa. O conceito de informao sempre est associado ao valor agregado que leva queles que se valem dela e necessita de uma mensagem para tangibiliz-la. A mensagem uma forma organizada de sinais previamente definidos que podem ser interpretados e que podem ser transportados servindo de suporte comunicao. O conceito de comunicao traz a transmisso como a estrada que permite o transporte da mensagem entre um emitente e um destinatrio separados no tempo quando no existe a presena simultnea de ambos na comunicao e separados no espao quer prximos ou muito distantes. Alguns exemplos servem como medida para diminuir as incertezas destes conceitos: Carta familiar: A informao que ela contem est levando ao destinatrio uma diminuio das incertezas a respeito do emitente separados tanto no espao como no tempo atravs da mensagem escrita: uma forma organizada de sinais e smbolos com morfologia e sintaxe previamente conhecida pelas partes e transportada por malotes. Ligao telefnica: As informaes so trocadas atravs de sinais da linguagem falada codificados, por exemplo, digitalmente e transportados por meio eltrico, eletromagntico ou ptico at o destinatrio praticamente ao mesmo tempo e separados por grandes distncias. Televiso: As informaes que podem ser notcias, novas seqncias dos captulos das novelas, telecurso, receitas, dicas, etc. so transmitidas via sinais codificados a partir da imagem e do som entre as emissoras e os telespectadores por radio difuso. Gene: As informaes hereditrias so armazenadas em cdigos qumicos e transmitidas atravs das geraes dos seres vivos. O teste de paternidade pelos genes reduz a incerteza sobre quem so os pais biolgicos.



6

1.3. Os Cinco Tratamentos da InformaoA informao pode ser tratada dos seguintes modos: CODIFICAO: A informao pode ser medida pela quantidade de bits. Bit a menor unidade que uma informao pode ser decomposta e pode ser representado por dois smbolos: 0 e 1. Pode-se agrupar bits para representar um caracter ou um elemento de imagem. Um conjunto de oito bits com uma determinada codificao recebe o nome de byte. A Codificao o tratamento que se d para que a informao possa ser colocada na forma de mensagem, ou seja, uma forma organizada de sinais e smbolos previamente definidos atravs dos quais outros tratamentos da informao possam ser efetuados. A Codificao pode ser simples ou complexa. Podem ser necessrias novas codificaes em cima de codificaes j existentes dependendo do tratamento que se quer dar informao. A voz, por exemplo, sofre uma codificao atravs do aparelho fonador provocando ondas sonoras que podem ser transmitidas at o aparelho auditivo de outra pessoa. A onda sonora (sinal mecnico), que se propaga por variaes de presso do ar, pode novamente ser codificada em sinal eltrico analgico que se propaga em meio eltrico ou eletromagntico e, ainda, pode ser mais uma vez codificada em sinal digital que se propaga em meios digitais e assim por diante. Existem codificaes mais complexas como o so os protocolos de comunicao resistentes a erros de transmisso como nos casos de sinais codificados de naves espaciais como a Voyager que chegam extremamente fracos com distores e rudos de toda a sorte e que podem ser recuperados com uma qualidade inacreditvel. TRANSMISSO A Transmisso o tratamento que se d para que a informao possa ser transportada entre o emitente e o destinatrio formando desta maneira um sistema simples de comunicao. A transmisso necessita que a informao esteja codificada adequadamente conforme o meio de transmisso que se vai utilizar. A tabela 1.1 fornece alguns exemplos de codificao versus meios de transmisso. Sinal Voz Voz Meio de transmisso Codificao

Transmisso Analgica Analgica Eltrica Transmisso Digital Cdigos de Pulsos PCM

Dados Transmisso Analgica Chaveamento de Fase PSK



7

Dados Transmisso Digital

Protocolo V35

Tabela 1.1 - Exemplos de codificao versus meios de transmisso

COMUTAO OU ROTEAMENTO Comutao ou roteamento o tratamento que se d para que a informao possa ser encaminhada entre mltiplas origens e mltiplos destinos. Este tratamento o que permite que um mesmo meio de transmisso possa ser utilizado para mltiplos pares origem - destino de comunicao aumentando em muito a eficincia de utilizao do meio. Exemplos: Centro de triagem de cartas, Mesas de telefonistas, Centrais telefnicas, Roteadores Internet, etc. ARMAZENAMENTO E RECUPERAO Armazenamento e Recuperao o tratamento que se d para que a informao possa ser guardada para posterior recuperao. Existem inmeras formas de armazenamento podendo ser mecnico, magntico, tico, digital, qumico, etc. Exemplos: Livro, disco fonogrfico, memria a rel, memria de ferrita, fita magntica, disco magntico, disco laser, memrias digitais, genes, etc. PROCESSAMENTO Processamento o tratamento que se d para que as informaes passem por operaes lgicas com o fim de produzir aes ou novas informaes. Exemplos: Automao, processamento de ligaes nas centrais telefnicas, processamento de imagens, injeo eletrnica nos automveis, cruzamento gentico, etc.

1.4. Elementos de Gerncia de RedeSegundo a ISO: o gerenciamento de redes prov mecanismos para a monitorao, controle e coordenao de recursos em um ambiente OSI e define padres de protocolos OSI para a troca de informaes entre estes recursos [ISO 10040]. Segundo a Telebrs: o gerenciamento de redes o conjunto de funes que visa promover a produtividade da planta e dos recursos disponveis para integrar de forma organizada, as funes de operao, administrao e manuteno de todos os elementos da rede e dos servios de telecomunicaes

1.4.1. Gerente



8

O gerente compreende um tipo de software que permite a obteno e o envio de informaes de gerenciamento junto aos mecanismos gerenciados, mediante comunicao com um ou mais agentes. As informaes de gerenciamento podem ser obtidas com o uso de requisies efetuadas pelo gerente ao agente, como tambm, mediante envio automtico disparado pelo agente a um determinado gerente. Tipicamente um gerente esta presente em uma estao de gerenciamento de rede.

1.4..2. AgenteO agente compreende um tipo de software presente junto aos dispositivos gerenciados. A funo principal de um agente compreende o atendimento das requisies enviadas por um software gerente e o envio automtico de informaes de gerenciamento ao gerente, indicando a ocorrncia de um evento previamente programado. Tambm compete ao agente efetuar a interface entre os diferentes mecanismos usados na instrumentao das funcionalidades de gerenciamento inseridos em um determinado dispositivos gerenciado. Em alguns roteadores, hubs, e switches (que possuem capacidade de serem gerenciados) o agente vem pr-pronto para ser utilizada, basta habilitarmos e configura-los. Ms em estaes de trabalho/servidores como Linux ou Windows, devem-se, configurar e habilitar o agente.

1.4.3. Base de DadosAs informaes de gerenciamento de segurana so armazenadas numa MIB (Management Information Base). Basicamente, so definidos quatro tipos de MIBs: MIB l, MIB II, MIB experimental e MIB privada. Compreende um conjunto de variveis usadas para representar informaes estticas ou dinmicas vinculadas a um determinado dispositivo gerenciado. Grande parte das funcionalidades de um software gerente/agente destina-se a troca de dados existente na base de informaes de gerenciamento, (Figura 03), conhecida na literatura como Management Information Base MIB. A MIB possui uma estrutura em rvore padronizada que contm os objetos gerenciveis de um determinado dispositivo de rede. Essa estrutura no tem limites e, de acordo com a necessidade, pode ser atualizada e expandida. Um objeto gerencivel uma viso abstrata de um recurso de um dispositivo da rede. Ele corresponde a uma estrutura de dados e operaes obtida a partir do modelamento dos recursos desse dispositivo de rede. Cada objeto possui as seguintes caractersticas [8]: Um rtulo (label), em formato texto, e uma identificao nica denominada OID (Object IDentification), que composta por uma seqncia de nmeros que identifica a posio do objeto na rvore da MIB (por exemplo: 1.3.6.1.4.1.2682.1).



9

Atributos: tipo de dado, descrio e informaes de status, configurao e estatsticas, entre outras. Operaes que podem ser aplicadas ao objeto: leitura (read), escrita (write) e comando (set).

A figura 1.1 apresenta a estrutura da MIB-II.

Figura 1.1 - Estrutura da MIB-ll.

1.4.4. Protocolos de GerenciamentoOs agentes se comunicam com os gerentes atravs de um protocolo de gerenciamento de redes em nvel de aplicaes, que utiliza a arquitetura de comunicao de rede. Protocolos de gerenciamento de redes descrevem um formato para o envio de informaes de gerenciamento. Para que seja possvel a comunicao entre um gerente e um agente, necessrio que ambos compartilhem o mesmo esquema de conceitual de informaes. O gerente deve ter ento uma viso conceitual dos elementos gerenciados que o agente interage. Informaes teis para o monitoramento de redes so coletadas e armazenadas por agentes e disponibilizadas para um ou mais gerentes. So utilizadas duas tcnicas para disponibilizar tais informaes: polling e event report (relato de eventos ou notificaes). Polling: uma interao do tipo pergunta e resposta entre gerentes e agentes. utilizada para se obter periodicamente informao armazenada nas MIBs associada aos agentes pelos gerentes. Relato de eventos: uma interao em que os agentes enviam informaes a gerentes. O gerente aguarda at que tais informaes cheguem.

-

1.4.5. Relacionamento Agente e GerenteO gerente pode efetuar a solicitao de um dado ao agente e a resposta a este pedido pode ser enviada pelo agente. H tambm a possibilidade de notificao



10

do gerente pelo agente em caso de alguma anomalia na rede. As linhas tracejadas representam operaes opcionais (que eventualmente podem nem ser utilizadas), que so escritas de atributos e a leitura destes pelo gerente. O diagrama da figura 1.2 ilustra o relacionamento.

Figura 1.2 Diagrama de Gerenciamento.

A figura 1.3 ilustra o relacionamento entre agente, gerente, protocolo e base de dados.

Figura 1.3 - Principais Componentes

1.5. Exerccios1) Cite trs benefcios/necessidade da gerncia de redes e comente sobre eles. 2) Quais os elementos que compe um sistema de gerncia de redes. Comente sobre eles. 3) Como o relacionamento entre o gerente e o agente. Cite exemplos desta comunicao. 4) Diferencie MIB de trap. 5) O que MIB? Explique a sua estrutura (diagrama bem vindo).



11

2. reas Funcionais da Gerncia de RedeA arquitetura de gerenciamento OSI define cinco reas funcionais para prover as necessidades do usurio no gerenciamento de suas redes: Gerenciamento de Configurao; Gerenciamento de Desempenho; Gerenciamento de Falhas; Gerenciamento de Segurana; Gerenciamento de Contabilizao.

Muitas vezes as reas funcionais possuem funes de gerenciamento que se sobrepem, isto , so utilizadas no somente em uma, ms at mesmo em vrias reas de gerenciamento, apesar de terem finalidades diferentes em cada uma. Por outro lado, algumas funes servem de suporte para as funes das outras reas.

2.1. Gerenciamento de ConfiguraoA gerncia de configurao correspondente a um conjunto de facilidades que permitem controlar os objetivos gerenciados. O objetivo da gerncia de configurao o permitir a preparao, a iniciao, a partida, a operao contnua e a posterior suspenso dos servios de interconexo entre os sistemas abertos, tendo ento a funo de manuteno e monitoramento da estrutura fsica e lgica de uma rede. Inclui-se a verificao da existncia dos componentes e a verificao da conectividade entre estes componentes. Portanto, para a manuteno, adio e atualizao de relacionamentos entre componentes e do status dos componentes durante a operao de rede, e a modificao da configurao em resposta a avaliaes de desempenho, recuperao de falhas, problemas de segurana, atualizao da rede ou a fim de atender s necessidades dos usurios podemos identificar as seguintes funes. Atribuio de valores iniciais aos parmetros de um sistema aberto; Inicio e encerramento das operaes sobre os objetos gerenciados; Alterao da configurao do sistema aberto; Associao de nomes a conjuntos de objetos gerenciados.

2.2. Gerenciamento de DesempenhoNa gerencia de desempenho tem-se a possibilidade de monitorar as atividades da rede e controlar os recursos atravs de ajustes e trocas. Tambm avalia-se o comportamento dos recursos num ambiente de gerenciamento para verificar se este comportamento eficiente, ou seja, preocupa-se com o desempenho



12

corrente da rede, atravs de parmetros estatsticos como atrasos, vazo, disponibilidade e o nmero de retransmisses realizadas. O gerenciamento de desempenho um conjunto de funes responsveis por garantir que no ocorram insuficincias de recursos quando sua utilizao se aproximar da capacidade total do sistema. Para atingir estes objetivos, devem-se monitorar as taxas de utilizao dos recursos, as taxas em que estes recursos so pedidos e as taxas em que os pedidos a um recurso so rejeitados. Para cada tipo de monitoramento, define-se um valor mximo aceitvel (threshold), um valor de alerta, e um valor em que se remove a situao de alerta. 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.

2.3. Gerenciamento de FalhasUma falha uma condio anormal cuja recuperao exige ao de gerenciamento, e normalmente causada por operaes incorretas ou um nmero excessivo de erros. O impacto e a durao de falha podem ser minimizados pelo uso de componentes redundantes e rotas de comunicao alternativa [3].



13

A gerncia de falhas tem a responsabilidade de monitorar os estado dos recursos, dar manuteno a cada um dos objetos gerenciados, e tomar decises para restabelecer as unidades do sistema que venham a dar problemas, para garantir o seu perfeito funcionamento. As informaes que so coletadas sobre os vrios recursos da rede podem ser usadas em conjunto com um mapa desta rede, para indicar quais elementos esto funcionando, quais esto em mau funcionamento, e quais no esto funcionados. Opcionalmente, podem-se gerar um registro das ocorrncias na rede, um diagnstico das falhas e uma relao dos resultados deste diagnstico com as aes posteriores a serem tomadas para o reparo dos objetos que geram falhas. O ideal que as falhas que possam vir a ocorrer em um sistema sejam detectadas antes que os efeitos significativos decorrentes desta falha sejam percebidos. Pode-se conseguir este ideal atravs do monitoramento das taxas de erros do sistema, e da evoluo do nvel de severidade gerado pelos alarmes (funo de relato de alarme), que permitem a emisso das notificaes de alarme ao gerente, que pode definir as aes necessrias para corrigir o problema e evitar as situaes crticas [2].

2.4. Gerenciamento de ContabilizaoPara evitar que um usurio ou grupo de usurios abuse de seus privilgios de acesso e monopolize a rede em detrimento de outros usurios e tambm evitar que faam uso ineficiente da rede, assistindo-os na troca de procedimentos e garantindo o desempenho da rede usamos o gerenciamento de contabilizao que possibilita estabelecer taxas a serem utilizadas pelos recursos no ambiente OSI e os custos a serem identificados na utilizao daqueles recursos [3]. Outras consideraes incluem informaes dos custos dos usurios e recursos gastos, estipulando limites e incorporando informaes de tarifas em todo o processo de contabilidade. Atualmente, contabilidade significa tratar com pessoas usando os reais recursos de rede com despesas e operao real. Exemplos desses custos incluem uso do espao em disco e dados armazenados, despesas de telecomunicaes para acesso a dados remotos e taxas de envio de e-mail. Pode-se tambm usar o gerenciamento de contabilizao para determinar se as utilizaes dos recursos da rede esto aumentando com o crescimento, o que deve indicar a necessidade de adies e reajustamentos num futuro prximo. 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 e os algoritmos usados no calculo da utilizao, conhecendo as atividades dos usurios com detalhes suficientes para planejar o crescimento da rede.



14

2.5. Gerenciamento de SeguranaO gerenciamento da segurana prov facilidades para proteger recursos da rede e informaes dos usurios. Estas facilidades devem estar disponveis apenas para usurios autorizados. necessrio que a poltica de segurana seja robusta e efetiva e que o sistema de gerenciamento da segurana seja, ele prprio, seguro. O gerenciamento de segurana trata de questes como [3]: * 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.6. ResumoA gerncia de redes a forma de ao remota em uma rede de telecomunicaes. Um sistema de gerncia composto pelo agente, gerente, base de dados e protocolo de comunicao.

2.7. Exerccios1) Quais so as cinco reas funcionais da gerncia de rede? Descreva cada uma delas. 3) Pensando em algum servio especfico, possvel que uma rea funcional seja de maior importncia? Por qu? 4) Continuando a questo 03, relacione as reas funcionais em ordem de importncia (para um servio de banda larga residencial, por exemplo) e justifique a sua resposta. 5) Descreva brevemente uma empresa e seu servio. Relacione as reas funcionais em ordem de importncia para este servio e justifique a sua resposta.



15

3. SLA e SLMProposta de um Modelo de Service Level AgreementPor: Ivan Luizio Magalhes e Walfrido Brito Pinheiro http://www.via6.com/artigo.php?aid=6929

IntroduoEste artigo detalha o processo de desenvolvimento de um Service Level Agreement (SLA), visando a apresentao de um modelo a partir do qual possam ser desenvolvidos SLAs mais especficos. Para a elaborao do modelo apresentado, tomou-se por base a relao entre uma organizao (cliente) e um prestador de servios de outsourcing (fornecedor). Diversas exigncias especficas foram supostas e documentadas neste artigo. Para a especializao do modelo proposto, estas exigncias devero ser revistas e/ou substitudas pelas do caso em questo. O objetivo um modelo que permita s organizaes de um modo geral comearem a trabalhar com SLAs. H duas partes principais em um SLA: a) Instrumento - geralmente est ligado relao legal entre a organizao (cliente) e um prestador de servios de outsourcing (fornecedor), ou seja, faz parte do contrato celebrado entre as partes. O instrumento descreve os servios e os nveis de servio exatos, com detalhes sobre todos os acordos. b) Processo - representa os mtodos que o fornecedor dos servios de outsourcing utilizar para suportar o instrumento do SLA. Os mtodos de suportar o instrumento do SLA so deixados geralmente para definio por parte do fornecedor, entretanto, mais e mais organizaes clientes tm definido estes mtodos, haja vista os inmeros problemas enfrentados na hora da validao dos dados. Estes mtodos devero ser discutidos e definidos durante a negociao do instrumento do SLA. importante que ambas as partes compreendam o processo e todos os mtodos a serem utilizados.

O processo do SLA representa um tero da soluo total. Ele s se tornar aplicvel aps o fornecedor e o cliente definirem os integrantes da equipe que controlaro o sistema e a tecnologia que ser utilizada para este controle. A equipe envolvida no controle do processo do SLA dever tambm ser capaz de controlar a tecnologia utilizada para este controle e compreender a importncia em monitorar o sistema inteiro e relatar qualquer anormalidade encontrada. A gerncia de sistema e a tecnologia da automatizao do processo do SLA



16

devem fornecer um ambiente que permita suportar o monitoramento, a notificao, o escalonamento e a gerncia dos valores dos indicadores de nvel de servio. Tambm devem ser adotadas avaliaes peridicas da satisfao dos usurios dos servios na ponta, visando obteno de dados que possam ajudar a definio e o alcance de nveis de servio apropriados, dentro de custos realistas. Os SLAs so classificados geralmente em: a) Bsico: um nico SLA est definido e em operao. Os indicadores so estabelecidos e medidos, requerendo possivelmente a obteno de dados de forma manual para a gerao do relatrio gerencial (Service Level Report SLR). O objetivo justificar a operao tcnica de suporte aos servios prestados; b) Intermedirio: existe a automatizao da coleta dos dados a serem utilizados para o clculo dos indicadores, permitindo a gerao de um SLR mais detalhado e com menor esforo. J possvel a coexistncia de diversos SLAs em operao e a introduo da recuperao de custo, a qual relaciona os ndices de servio alcanados com os resultados obtidos em termos de receita pela organizao cliente. SLA multi-nveis podem ser implementados, permitindo combinar nveis do servio e custos com os objetivos de elevao dos nveis de servio e de diminuio dos custos no longo prazo; c) Avanado: os SLAs so encaixados em processos totais da organizao, permitindo a alocao dinmica de recursos externos ou internos, objetivando encontrar as melhores condies de prestao dos servios paralelo com as mudanas do negcio. O objetivo fornecer uma mistura sem emenda dos servios, dos custos e dos fornecedores de servio em taxas melhores do que as obtidas pelos competidores da organizao. Freqentemente as organizaes neste nvel esto prontas para estender seus servios ao mercado aberto.

O cenrioPara o objetivo desta discusso, o restante deste artigo examina as consideraes de um avaliador da organizao que deva elaborar um instrumento de SLA para a prestao de servios de suporte a um sistema de correio eletrnico corporativo. Este avaliador ter que negociar o SLA com um ou mais prestadores de servio, objetivando a redao final do instrumento. So apresentadas recomendaes e sugestes baseadas em padres da indstria e na experincia em gerncia de projeto dos autores.

ObjetivosO objetivo preliminar do instrumento do SLA identificar corretamente as exigncias de nvel de servio para a organizao da infra-estrutura de correio eletrnico corporativo.



17

O avaliador da organizao sozinho no pode determinar os detalhes apropriados para o SLA. As potencialidades da gerncia, da experincia e de projeto dos fornecedores de servios de outsourcing fornecero a informao e a orientao requeridas. Em muitos casos, sero necessrias reunies com as reas usurias da infra-estrutura de correio eletrnico corporativo para o estabelecimento dos aspectos a serem monitorados e dos nveis a serem exigidos dos servios a serem prestados. Alm disso, aconselhvel a coleta de dados e sugestes de outras reas da organizao, como por exemplo, a equipe atual de help-desk. Em outros casos, os prprios fornecedores devero ser envolvidos, visando detectarem pontos internos organizao que possam estar obscuros ao avaliador.

Instrumento do SLAO processo de criao do instrumento do SLA o ponto-chave para facilitar a gerncia do projeto. As primeiras quatro tarefas requerem a participao da gerncia e, em alguns casos, das reas usurias da infra-estrutura de correio eletrnico da organizao. As quatro tarefas seguintes podem requer a participao do fornecedor atual de servios ou dos futuros fornecedores, de forma a assegurar que todas as exigncias foram identificadas. Em seguida, o avaliador dever redigir um documento com os dados coletados de modo a ser facilmente lido e compreendido. A seguir, so enumeradas as diversas tarefas necessrias para a confeco do instrumento do SLA: 1. Identificao do objeto contratual, da forma de relatrio gerencial, das bonificaes e penalidades financeiras. 2. Determinao dos servios a serem prestados 3. Determinao dos nveis dos servios 4. Identificao dos requisitos de disponibilidade dos servios 5. Determinao da infra-estrutura de suporte 6. Identificao dos ciclos de atualizao dos softwares e do hardware 7. Determinao dos requisitos de help-desk 8. Determinao dos requisitos de capacitao/treinamento de usurios 9. Redao do instrumento do SLA 10. Negociao com os fornecedores 11. Definio do SLA 12. Implementao do SLA



18

As ltimas trs tarefas so desenvolvidas com a participao direta dos fornecedores envolvidos. Geralmente, um contrato ser celebrado para ligar as partes a um SLA. Muitas sees podero ser removidas ou adicionadas ao texto final do instrumento do SLA em relao verso elaborada pelo avaliador, conforme a evoluo das negociaes.

Especificaes contratuais e contextoA gerncia do SLA uma parte crtica do suporte aos usurios finais. Antes que se possam determinar os objetivos a serem atingidos, necessrio conhecer as especificaes contratuais e os indicadores determinados para a monitorao dos servios prestados.

Contatos e PapisPrimeiro, nomeie o responsvel por ser o ponto de contato nico por parte da organizao para o SLA e atribua as atividades de gerenciamento a outro responsvel, de modo a evitar conflitos de interesse. Alm do responsvel e do gerente do SLA por parte da organizao, devero ser definidos os responsveis pela gerncia de interconexo da infra-estrutura de email corporativo com outras organizaes e pela gerncia de desenvolvimento de aplicaes que utilizem a infra-estrutura de e-mail corporativo. Pelo lado do fornecedor devero ser nomeados os responsveis pelo ponto nico de contato e pelos diversos servios oferecidos.

Relatrio Gerencial (Service Level Report SLR)A freqncia e o detalhe dos relatrios devem ser identificados no instrumento do SLA. O Service Level Report (SLR) poder ser gerado atravs de duas tcnicas: Automatizado o relatrio automtico do sistema de monitoramento deve ser executado a fim fornecer dados atuais e histricos. Estes dados devem estar disponveis aos responsveis nomeados em uma freqncia regular. Os mtodos para fornecer relatrios aos responsveis nomeados podem incluir um stio na INTRANET/EXTRANET ou atravs da utilizao de correio eletrnico. Dever ser previsto o fornecimento tambm de cpias em mdia. Estes relatrios devero ser detalhados, com anlise de dados e clculo da tendncia para o ms. Alm disso, devem incluir dados histricos que permitam o acompanhamento da evoluo dos nveis de servios; Manual - pode ser necessrio para os gerentes das reas usurias receberem um sumrio do SLR, acrescido de grficos que descrevam a disponibilidade e o tempo de resposta da infra-estrutura de correio eletrnico corporativo que os suportam. Geralmente a periodicidade destes relatrios mensal. A organizao cliente deve requerer um mecanismo automtico de notificao dos nveis de servio e escalonamento entre os responsveis designados tanto por



19

sua parte como por parte do fornecedor, sendo a escala definida no instrumento do SLA. Deve ser definido o processo de avaliao dos servios prestados por parte dos usurios das reas clientes, bem como estabelecida a periodicidade, formas de coleta e apurao e pblico-alvo, como parte da iniciativa total de prestao de servios aos clientes.

Condies de pagamentoOs termos relacionados com o pagamento e a durao do contrato so negociados com o fornecedor dos servios de outsourcing. A organizao pode preferir uma durao de seis meses, mas considerar propostas com durao anual, por exemplo. As renovaes podem ser asseguradas de diversas formas, incluindo uma extenso automtica de seis meses, caso no haja manifestao das partes em contrrio. Tanto a organizao cliente, quanto fornecedora, devem poder pedir formalmente a renovao, bem como a renegociao do SLA ou mesmo de determinadas clusulas contratuais de forma cavalheira. No caso da existncia de conflitos, deve-se tentar solucion-los em concordncia com as clusulas contratuais. Para os casos omissos ou de litgio, deve-se implementar um mecanismo de comit gestor do contrato, formado por representantes formalmente designados pelas partes. O encerramento do contrato pode se d por duas maneiras: 1. O trmino do contrato motivado pela solicitao de uma das partes envolvidas. Neste caso, deve ser previsto um mecanismo de transferncia da tecnologia para a organizao cliente, incluindo o suporte para transferncia dos servios para outra organizao fornecedora. 2. O trmino do contrato motivado pela descontinuidade da necessidade dos servios contratados. Em relao ao encerramento do contrato, devem ser observados os fatores a seguir: A organizao cliente pode reservar o direito de cancelar o contrato para uma ou outra opo da terminao com a observao de 60 dias organizao prestadora dos servios de outsourcing; A organizao cliente compreende que pode haver penalidades financeiras que motivem o trmino do contrato, advindas do fato das metas de nveis de servios no terem sido alcanadas pela organizao fornecedora; A organizao fornecedora pode reservar-se o direito de trmino do contrato faa a solicitao com um prazo mnimo de 180 dias, arcando com os custos de transferncia dos servios para um outro fornecedor.

Processo de revisoEngenharia em Telecomunicaes - UnC


20

Deve haver um processo de reviso formal e peridico para avaliar os nveis dos servios prestados, bem como da equipe de funcionrios alocada. Uma periodicidade trimestral indicada.

Gerncia de mudanaA mudana do nvel de servio realizada negociando uma mudana ou um adicional a um acordo existente de nvel de servio. Para os projetos novos a gerncia de mudana no necessria, uma vez que em cada processo de reviso podem ser renegociados os nveis de servio. Diversos fatores podem requer um processo de gerncia de mudana ou at mesmo um addendum a um SLA existente: mudana no processo de trabalho; adio de novos servios; perda de desempenho; perda de clientes; novas aplicaes de terceiros;

As mudanas no so feitas diretamente no instrumento do SLA, geralmente so efetuadas atravs de aditivos contratuais e quando da renovao contratual, passam a serem incorporados no texto do novo contrato.

Plano de incentivo financeiroO incentivo financeiro pode ser atrelado superao das metas estabelecidas para os nveis de servios ou a reduo dos custos totais de operao, como por exemplo, atravs da diminuio das perdas decorrentes das indisponibilidades da infra-estrutura de processamento. No exemplo que est sendo detalhado, determinam-se a aplicao de bnus para a superao dos nveis de servios determinados no SLA para determinadas reas usurias da organizao, consideradas crticas para o suporte ao negcio. Tambm foram definidas penalidades, para o caso dos resultados dos nveis de servios ficarem abaixo dos estabelecidos no SLA. Os custos decorrentes das melhorias para elevao dos nveis de servios ficaram a cargo da organizao prestadora dos servios de outsourcing, uma vez que os bnus a serem obtidos justificariam os investimentos a serem realizados. Bnus e penalidades so creditados e debitados diretamente das faturas mensais a serem pagas pela organizao cliente, sendo que no oramento do projeto de outsourcing levou-se em considerao para a sua viabilidade econmica a aplicao do mximo de bnus.

Sugestes de nveis de desempenho



21

Como exemplos de indicadores de desempenho, pode-se ter: 1. Transferncia de mensagens entre stios Como a organizao prestadora de servios no detm total controle sobre a rede utilizada para a interconexo de stios da organizao cliente, no foi exigida a garantia dos tempos de recebimento das mensagens eletrnicas originadas de outros stios. No caso de mensagens recebidas pela Internet e com endereo de destino legtimo, ficou estabelecido no poder haver perda, independentemente das condies da rede interna organizao cliente. 2. Transferncia de mensagens internas a um stio A organizao cliente requer que qualquer mensagem originada no mesmo stio, seja entregue a caixa de entrada de seu destinatrio em no mximo 15 minutos. 3. Sincronizao Remota A atualizao da lista de endereos eletrnicos dos equipamentos dos usurios remotos no pode exceder 10 minutos, quando este usurio estiver conectar a 56 Kbits/s. 4. Replicao da Caixa Postal Os usurios devem possuir caixas postais com capacidade determinada pela sua categorizao funcional, conforme relao a seguir: Operacionais (25 MBytes); Administrativos (50 MBytes); Executivos (100 Mbytes).

Requisitos de disponibilidadeA disponibilidade da infra-estrutura de correio eletrnico corporativa pode ser extremamente cara. importante identificar claramente os nveis requeridos e estabelecer a relao custo/benefcio, de modo a viabilizar o seu alcance. 1. Acesso remoto Deve ser estudada a disponibilidade de rotas alternativas de acessos, com fins de viabilizar a continuidade do acesso em caso de falhas na rota principal. 2. Acesso s caixas postais Devem ser especificados os perodos de disponibilidade de acesso dos usurios as suas caixas postais bem como a quantidade de horas em que cada usurio poder permanecer conectado sua caixa postal. Para este ultimo requisito, os



22

usurios sero classificados em classes: Classe 1 os usurios podem acessar suas caixas postais por at seis horas dentro do horrio comercial definido de operao da organizao; Classe 2 os usurios podem acessar suas caixas postais por at 24 horas nos dias teis de operao da organizao. 3. Disponibilidade dos servidores Os servidores de correio eletrnico devem ficar disponveis 99,5 % do tempo durante o horrio comercial de operao da organizao e 90 % for a do horrio comercial.

Requisitos de suporte aos equipamentos1. Acesso e segurana Devem ser providos o controle de acesso e a segurana aos equipamentos da infra-estrutura de correio eletrnico corporativo em esquema 24 x 7 (24 horas, sete dias por semana). 2. Disastre Recovery Deve existir plano detalhado para recuperao da infra-estrutura de correio eletrnico corporativo e das mensagens armazenadas que garanta a retomada do seu funcionamento em no mximo 1 hora. 3. Recuperao de mensagens A poltica de backup das mensagens deve garantir a possibilidade de recuperao de mensagens apagadas a pelo menos 30 dias.

EquipeOs profissionais alocados para administrao e suporte da infra-estrutura de correio eletrnico corporativo por parte da organizao fornecedora dos servios dever possuir certificao na soluo de gerenciamento de correio eletrnico utilizada e pelo menos dois anos de experincia na plataforma utilizada.

EquipamentosTodos os equipamentos a serem empregados na operao da infra-estrutura de correio eletrnico corporativo devero ser de fornecedores homologados previamente pela organizao contratante.

ConclusoUm SLA deve ser planejado visando atender aos requisitos de negcios impostos pelas reas usurias dos servios alvos do outsourcing e os objetivos estratgicos da prpria rea contratante.Engenharia em Telecomunicaes - UnC


23

Um bom SLA o que atende aos interesses da organizao contratante e ao mesmo tempo bem negociado com a organizao prestadora dos servios de outsourcing. Na maioria dos casos, so princpios que regero relaes de mdio e longo prazo e portanto, de extrema importncia, devendo conter em seu prprio corpo mecanismos que permitam sua adaptao s mudanas no ambiente em que est inserida a organizao contratante, bem s mudanas tecnolgicas e seus respectivos ganhos de produtividade. Foi apresentada uma metodologia simplificada para o desenvolvimento e implementao de SLAs, a qual pode ser igualmente utilizada como ponto de partida para o desenvolvimento de SLA mais especficos. Apresentou-se um modelo de SLA para a contratao de servios de infra-estrutura de correio eletrnico corporativo, o qual pode ser adaptado para diversos outros tipos de servio, uma vez que exps os itens fundamentais de um SLA, permitindo s organizaes de qualquer natureza a iniciarem a aplicao do SLA em seus processos de outsourcing ou mesmo nas relaes entre reas internas.

3.1 Exerccios1. Repasse o exerccio feito em aula utilizando alguma empresa diferente da original.

3.2 Referncias Especficas e LinksTexto extrado literalmente de Proposta de um Modelo de Service Level Agreement. Ivan Luizio Magalhes e Walfrido Brito Pinheiro http://www.via6.com/artigo.php?aid=6929



24

4. Modelo OSI de GerenciamentoA 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

Estruturas de gerenciamentoA 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 4.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

TRANSPORTEREDE ENLACE FSICO

TRANSPORTEREDE ENLACE FSICO

Figura 4.1 Gerenciamento de Sistemas

O Gerenciamento de Camada consiste na monitorao e controle dos recursos de uma camada de forma isolada e independente, conforme ilustrado na figura 4.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).



25

cam N ada protocolodegerenciam ento da cam N adaFigura 4.2 Gerenciamento de Camada

cam N ada

A estrutura de Operao de Camada, mostrada na figura 4.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

conexo 1 conexo 2 ... conexo n

Figura 4.3 Operao de Camada

Componentes de gerncia OSIO ambiente de gerenciamento OSI composto por elementos gerenciados, agentes e gerentes. Os elementos gerenciados so representados por objetos gerenciados, seguindo o paradigma da Abordagem de Orientao a Objetos. Os agentes e gerentes so entidades usurias do servio de gerenciamento OSI e so denominados de MIS-Users (Management Information Service - Users). Os papis assumidos por estas entidades no so fixos, isto , um MIS-User pode executar o papel de gerente em um contexto, definido por uma associao, e um papel de agente em outro contexto, definido por outra associao. A figura 4.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.



26

Gerente Agente

Gerente Agente

Agente

Gerente

Figura 4.4 Componentes do Gerenciamento OSI

Estrutura da informao de gerenciamentoAs informaes de gerenciamento so organizadas em bases de dados. O conjunto das bases de dados de informaes de gerenciamento denominado MIB (Management Information Base), e a sua implementao no est sujeita padronizao. As informaes so definidas segundo uma SMI (Structure Management Information). No modelo de 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.

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



27

MIS-User (papel de gerente)

Operaes de gerenciamento Notificaes

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

Figura 4.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 MEVENT-REPORT, definido no CMIS. Na figura 5.5, pode-se observar a funo de disseminao de notificaes que consiste em um suporte funcional ao MIS-User agente para a identificao dos destinatrios para os quais devem ser repassadas as notificaes geradas pelos objetos gerenciados. A tabela 4.1 mostra as primitivas de servio de gerenciamento definidas pelo CMIS. Embora uma notificao possa ser gerada como efeito colateral de uma operao de gerenciamento, ela no pode ser considerada como uma resposta a uma operao. As operaes de gerenciamento so emitidas por iniciativa de um gerente. Se uma operao de gerenciamento for solicitada no modo confirmado, ento ela ser respondida atravs das primitivas response e confirm; caso contrrio, nenhuma resposta ser gerada. Uma notificao emitida por iniciativa do MIS-User agente que, por sua vez, pode solicitar este servio no modo confirmado ou no confirmado.Tipo de servio M-CANCEL-GET (operao) Modo requisio confirmado de Primitivas request/indication response/confirm Semntica Cancelar uma operao de leitura realizada sobre vrios objetos



28Ler valores de atributos de objetos Modificar valores de atributos de objetos

M-GET (operao)

confirmado

request/indication response/confirm

M-SET (operao)

confirmado


no confirmado M-CREATE (operao) M-ACTION (operao) confirmado

request/indication request/indication response/confirm Criar uma instncia de objeto Solicitar que uma ao pr-definida seja executada por um objeto

confirmado


no confirmado M-DELETE (operao) confirmado

request/indication request/indication response/confirm Destruir uma instncia de objeto

no confirmado M-EVENT-REPORT (notificao) confirmado

request/indication request/indication esponse/confirm Notificar a ocorrncia de um evento a um sistema gerente

no confirmado

request/indication

Tabela 4.1 Servios de Gerenciamento

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



29

A Informao de Gerenciamento definida seguindo a AOO-Abordagem de Orientao a Objetos e armazenada em uma MIB.

4.1. Exerccios1. Como so feitas as definies das notificaes na arquitetura OSI de gerenciamento? 2. Como est estruturada a camada de aplicao OSI para suportar aplicaes de gerncia? 3. Qual a finalidade bsica do ROSE e quais so as suas primitivas? 4. Qual a diferena entre o CMISE e o SMASE? 5. O que uma funo de gerenciamento OSI? 6. Quais so os comandos/servios e suas funes oferecidos pelo CMISE para atuao em entidades remotas?

4.2. Referncias Especficas e LinksExtrado do Cap 6 da Apostila de Gerncia de Redes de Computadores e de Telecomunicaes da Profa. Dra. Elizabeth Sulei Especialski



30

5. Rede de Gerncia de Telecomunicaes (TMN)Extrado da Apostila de Rede de Gerncia de Telecomunicaes - TMN da Professora Linnyer Beatrys Ruiz.

Em 1985, o ITU (International Telecommunications Union) iniciou estudos sobre a padronizao da gerncia das redes de telecomunicaes, criando um conceito bsico denominado Rede de Gerncia de Telecomunicaes (TMN Telecommunications Management Network). A TMN foi definida como uma rede de gerncia, independente da rede de telecomunicaes (ver figura 5.1), cujo objetivo coletar, distribuir e processar as informaes de gerncia. Uma das primeiras tarefas para definio da TMN foi especificar uma arquitetura para esta rede de gerncia, incluindo a identificao dos diferentes tipos de componentes e das interfaces que existiriam entre eles.

Figura 5.1 - Relacionamento entre a Rede de Gerncia e a Rede de Telecomunicaes.

Em 1988, os estudos dos grupos de trabalho do ITU-T, resultaram nas recomendaes M.3000 que definem os princpios bsicos da TMN. Estas recomendaes fornecem uma estrutura organizada que permite interconectar sistemas de suporte a operao e diversos tipos de equipamentos de telecomunicaes possibilitando a interoperabilidade entre sistemas de gerncia. A interoperabilidade na gerncia dos recursos foi um requisito fundamental na definio desta estrutura, pois sua ausncia reduzia a eficincia da monitorao dos equipamentos, aumentando consideravelmente os custos de manuteno e dificultando a implementao de medidas de segurana. A elaborao de uma arquitetura comum que possibilite a interoperabilidade entre sistemas de gerncia , portanto, um dos principais ramos de atuao do



31

processo de elaborao de modelos para a Gerncia de Rede. Os grupos de trabalho envolvidos com TMN devem conhecer esta srie de recomendaes e encontrar solues onde ferramentas e plataformas disponveis comercialmente sero usadas para implementar a rede de gerncia. Algumas redes e servios que podem ser gerenciadas pela TMN so: redes pblicas e privadas, incluindo a RDSI, redes de telefonia mvel, redes privativas de voz e redes inteligentes; elementos de transmisso (multiplexadores, roteadores, crossconnects, equipamentos SDH); sistemas de transmisso analgica e digital baseados em cabos coaxiais, fibra ptica, rdio e enlace de satlite; mainframes, processadores front-end, controladoras remotas, servidores de arquivos, etc; redes locais, geogrficas e metropolitanas (LAN, MAN e WAN); redes de comutao de circuito e pacotes; a prpria TMN; terminais e sistemas de sinalizao incluindo Pontos de Transferncia de Sinalizao (STP) e bases de dados em tempo real; servios de suporte e teleservios; sistemas de infra-estrutura e suporte, como mdulos de teste, sistemas de energia, unidades de ar condicionado, sistemas de alarme, etc.

Camadas Funcionais O ITU-T adotou um modelo em camadas funcionais para o gerenciamento de um ambiente de telecomunicaes, conforme apresenta a figura 5.2. O objetivo principal deste modelo quebrar a complexidade do ambiente em partes mais compreensveis.



32

Figura 5.2 - Camadas de Gerenciamento

Camada de Elemento de Rede Corresponde s entidades de telecomunicaes (software ou hardware) que precisam ser efetivamente monitorados e/ou controlados. Estes equipamentos devem possuir agentes para que possam fornecer as informaes necessrias ao sistema de gerncia, como coleta de dados de performance, monitorao de alarmes, coleta de dados de trfego, etc. Camada de Gerncia do Elemento da Rede Esta camada responsvel pelo gerenciamento dos equipamentos na forma de sub-redes, ou seja, pequenas partes da rede completa devem ser gerenciadas e suas informaes sintetizadas para poderem ser aproveitadas pela Gerncia de Rede do sistema, que tem assim a viso completa da rede. Camada de Gerncia de Rede Esta camada gerencia o conjunto de elementos (sub-redes) como um todo, tendo uma viso fim-a-fim da rede. Para isso, ela recebe dados relevantes dos vrios sistemas de Gerncia de Elemento de Rede e ao processa-os para obter uma viso consisa da rede completa. Camada de Gerncia de Servio Esta camada relaciona os aspectos de interface com os clientes, e realiza funes como provisionamento de servios, abertura e fechamento de contas, resoluo de reclamaes dos clientes (inclusive relacionados tarifao), relatrios de falhas e manuteno de dados sobre qualidade de servio (QoS). Camada de Gerncia de Negcio um ponto onde ocorrem as aes executivas, ou seja, responsvel pela gerncia global do empreendimento. neste nvel em que so feitos os acordos entre as operadoras e onde so definidos os objetivos.



33

reas Funcionais De forma a se englobar toda a funcionalidade necessria ao gerenciamento de uma rede de telecomunicaes (planejamento, instalao, operao, manuteno e provisionamento), identificaram-se cinco reas funcionais: Gerenciamento de Desempenho Gerenciamento de Falhas Gerenciamento de Configurao Gerenciamento de Tarifao Gerenciamento de Segurana

Gerenciamento de Desempenho O gerenciamento de desempenho envolve as funes relacionadas com a avaliao e relato do comportamento dos equipamentos de telecomunicaes e a eficincia da rede. Estas funes se dividem basicamente em dois grupos: Medidas de Trfego: capacitam o usurio a definir e controlar a entrega de relatrios de medidas de trfego; Monitorao de Desempenho: informaes que permitem usurio obter, avaliar e relatar parmetros de desempenho rede. Estas informaes podem ser utilizadas como apoio diagnstico de falhas, planejamento de rede e qualidade servio. ao da ao de

Algumas funes relativas ao gerenciamento de desempenho so: manter informaes estatsticas; manter logs de histricos de estados; determinar a performance do sistema sob condies naturais e artificiais; alterar os modos de operao do sistema com o propsito de conduzir atividades de gerenciamento de desempenho.

Gerenciamento de Falhas O gerenciamento de falhas engloba as funes que possibilitam a deteco, isolao e correo de operaes anormais na rede de telecomunicaes. As falhas impedem os sistemas de cumprir seus objetivos operacionais e podem ser transientes ou persistentes. As funes de gerenciamento de falhas podem ser divididas em:



34

Superviso de Alarmes: gerenciamento de informaes sobre as degradaes de desempenho que afetam o servio; Teste: o usurio pode solicitar a execuo de um teste especfico, podendo inclusive estabelecer os parmetros deste. Em alguns casos, o tipo e os parmetros do teste podem ser designados automaticamente; Relatrio de Problemas: utilizado para rastrear e controlar as aes tomadas para liberar alarmes e outros problemas.

Algumas funes do gerenciamento de falhas so: manter logs de erros; receber e agir sobre notificaes de erros; rastrear e identificar falhas; gerar seqncias de testes de diagnstico; corrigir falhas.

Gerenciamento de Configurao O gerenciamento de configurao habilita o usurio a criar e modificar recursos fsicos e lgicos da rede de telecomunicaes. Suas funes so divididas em: Gerenciamento de Ordem de Servio: possibilita a identificao e o controle do provisionamento de novos recursos necessrios para a rede de telecomunicaes. Uma Ordem de Servio pode ser utilizada para solicitar novos recursos, fsicos ou lgicos; Configurao de Recursos: funes que tm como finalidade possibilitar que os recursos da rede possam ser criados, roteados, controlados e identificados; Informao de Recursos: funes que tm por finalidade apresentar a lista de recursos alocados, verificar a consistncia da informao e obter informao sobre os recursos disponveis.

Algumas funes relativas ao gerenciamento de configurao so: setar parmetros de controle de rotinas de operao do sistema; associar nomes aos objetos gerenciados e configur-los; inicializar e deletar objetos gerenciados; coletar informaes em tempo real a respeito atuais do sistema;Engenharia em Telecomunicaes - UnC

das condies


35

obter avisos a respeito de modificaes significativas nas condies do sistema; modificar a configurao do sistema.

Gerenciamento de Tarifao O gerenciamento de tarifao prov um conjunto de funes que possibilitam a determinao do custo associado ao uso da rede de telecomunicaes. Algumas funes associadas ao gerenciamento de tarifao so: informar aos usurios os custos associados aos recursos consumidos; habilitar limites de tarifao e setar agendamentos a serem associados com a utilizao dos recursos; combinar custos quando um requisito de comunicao exigir mltiplos recursos combinados.

Gerenciamento de Segurana As principais funes que devem se encaixar no gerenciamento de segurana so: criao e controle de servios e mecanismos de segurana; distribuio de informaes relevantes segurana; armazenamento de eventos relativos segurana.

Arquitetura TMN A arquitetura TMN prov meios de transportar e processar informaes relacionadas ao gerenciamento de uma rede de telecomunicaes. A elaborao de uma arquitetura comum que possibilite a interoperabilidade entre sistemas de gerncia , portanto, um dos principais ramos de atuao do processo de elaborao de modelos para a Gerncia de Rede. As recomendaes ITU-T [M.3010] abordam trs aspectos no planejamento e no projeto da TMN: Arquitetura de Informao; Arquitetura Fsica; Arquitetura Funcional.

A introduo da TMN fornecer s empresas operadoras a possibilidade de alcanar uma srie de objetivos gerenciais como diminuio do tempo de reao aos eventos da rede atravs da localizao e correo automtica de falhas, provimento de mecanismos para acesso seguro dos operadores aos sistemas de operao, minimizao da carga causada pelo trfego das informaes deEngenharia em Telecomunicaes - UnC


36

gerenciamento e, finalmente, possibilidade de independncia da localizao de um centro de gerncia em relao disperso geogrfica dos elementos componentes da rede. Arquitetura de Informao A arquitetura de informaes descreve um modelo orientado a objeto para a modelagem da informao de gerncia trocada entre blocos funcionais da TMN. Desse modo, a arquitetura de informao possui os fundamentos para a utilizao dos princpios e conceitos do gerenciamento de sistemas OSI, como agente/gerente, domnios e conhecimento de gerenciamento compartilhado, necessrios para a organizao e o interfaceamento de sistemas de gerenciamento complexos. Uma aplicao de gerncia uma atividade na qual ocorre um processamento de informaes de forma distribuda entre dois ou mais processos cooperantes que trocam informaes entre si. Esta troca de informaes baseia-se em um sistema gerenciador (controle e monitorao) e um sistema gerenciado (recursos fsicos ou lgicos), como mostra a figura 5.3. Para que haja possibilidade de troca de informaes entre os dois sistemas (agente/gerente), existe a necessidade de uma viso compartilhada das informaes de gerncia trocadas e das regras de comunicao empregadas.

Figura 5.3 - Conceito de agente/gerente

Para se garantir a perfeita operabilidade das comunicaes agente/gerente, faz-se uso do modelamento das informaes trocadas entre os sistemas em termos de objetos gerenciados. Um objeto gerenciado uma abstrao de um recurso fsico ou lgico de um sistema gerenciado, definido atravs de suas caractersticas inerentes, ou atributos (ATTRIBUTES), operaes de gerenciamento que suporta (ACTIONS), notificaes que emite (NOTIFICATIONS) e do seu comportamento (BEHAVIOUR) diante de estmulos externos e internos. As interaes entre o gerente e o agente so realizadas em termos de operaes e notificaes trocadas entre eles. Estas trocas de operaes e notificaes so realizadas atravs do uso do servio CMIS (Common Management Information Service) [X.710] e transportadas atravs do protocolo CMIP (Common Management Information Protocol) [X.711] (ver figura 5.4).



37

Figura 5.4 - Exemplo de comunicao entre sistemas TMN

Na figura 5.4, o sistema A possui um gerente que utiliza o servio CMIS e o protocolo CMIP para trocar operaes e notificaes com o agente do sistema B. O sistema A tambm tem uma viso da MIB do sistema B. Da mesma forma, o gerente do sistema B utiliza o servio CMIS e o protocolo CMIP para trocar operaes e notificaes com o agente do sistema C e tambm possui uma viso da MIB do sistema C. Arquitetura Funcional Descreve a distribuio apropriada da funcionalidade (blocos funcionais) dentro da rede de gerncia. Um bloco funcional ou agrupamento de funes gerais TMN a base da arquitetura funcional. Atravs da distribuio adequada dos blocos de funo na rede pode-se implementar uma rede TMN de qualquer complexidade. A definio destes blocos funcionais e dos pontos de referncia (fronteiras entre os blocos funcionais atravs das quais ocorrem as trocas de informaes entre eles) entre os blocos, leva especificao de interfaces padres de TMN. Os blocos funcionais podem ser implementados como sistemas a parte e conectados diretamente TMN ou atravs de uma rede de comunicao de dados. importante notar que a arquitetura TMN pretende ser flexvel e suportar muitas possibilidades de implementaes. Os blocos funcionais se comunicam atravs da Funo de Comunicao de Dados (DCF) que implementa as camadas 1 a 3 do modelo OSI (Open Systems Interconnection), podendo suportar vrios tipos de sub-rede. Os blocos funcionais da TMN e as suas funes associadas so:



38

OSF - Bloco de Funo de Sistemas de Suporte Operaes: processa informaes de gerncia com o propsito de monitorar, coordenar e controlar funes de telecomunicaes, inclusive as prprias funes de gerenciamento (a prpria TMN). NEF - Bloco de Funo Elemento de Rede: representa para a TMN as funes de telecomunicaes e suporte requeridas pela rede de telecomunicaes gerenciada. Essas funes no fazem parte da TMN, mas so representadas para ela atravs do NEF. A parte da NEF que representa as funes de telecomunicaes para a TMN parte da TMN, enquanto as funes de telecomunicaes propriamente ditas no fazem parte da TMN. O bloco NEF possui, ainda, as seguintes funes:

1. Funo Entidade de Telecomunicaes (TEF) - relativa aos processos de telecomunicaes, como comutao e transmisso; 2. Funo Entidade de Suporte (SEF) - funo relativa a equipamentos de suporte, como infra-estrutura e energia, comutao para proteo de canais de transmisso etc. QAF - Bloco de Funo Adaptador de Interface Q: conecta a TMN a entidades no TMN. Realiza uma adaptao entre um ponto de referncia no TMN (por exemplo, interface proprietria) e um ponto de referncia "Q3" ou "Qx" da TMN. MF - Bloco de Funo de Mediao: atua modificando a informao trocada entre a NEF ou QAF e a OSF, de acordo com as caractersticas da informao esperada por cada um deles. Os MF podem adaptar, armazenar, filtrar e condensar as informaes. WSF - Bloco de Funo Estao de Trabalho: o bloco WSF prov os meios para o usurio interpretar e acessar as informaes de gerenciamento, incluindo o suporte para interface homem/mquina (apesar desta no ser considerada parte da TMN).

Alm disso, cada um dos blocos funcionais formado por outros componentes funcionais, listados a seguir: Funo de Aplicao de Gerenciamento (MAF): tem a funo de implementar o servio de gerenciamento, podendo ser mapeadas nos sistemas gerentes ou nos sistemas agentes. Base de Informao de Gerenciamento (MIB): representa o conjunto de objetos gerenciados pelo sistema. A estrutura e implementao da MIB no esto sujeitas padronizao dentro da TMN.



39

Funo de Converso de Informao (ICF): a funo responsvel pela traduo entre os modelos de informao das diversas interfaces previstas na arquitetura TMN. Funo de Apresentao (PF): responsvel pela traduo de informaes TMN para interfaces homem-mquina e vice-versa. Funo de Adaptao Homem-mquina (HMA): responsvel pela converso do modelo de informao das aplicaes para o modelo de informao apresentado pela TMN atravs da funo de apresentao e vice-versa. Funo de Comunicao de Mensagens (MCF): a funo relacionada aos blocos funcionais que possuem interface fsica, permitindo a ligao com a conexo com a funo de comunicao de dados.

Os blocos funcionais permitem que as informaes sejam trocadas atravs de pontos de referncia, que se dividem em classes diferentes dependendo da categoria dos blocos os quais esto sendo interligados. Na arquitetura TMN so definidas trs classes de pontos de referncia: 1. Q: para ligao entre os blocos OSF, QAF, MF, e NEF; 2. F: para a ligao de estaes de trabalho (WSF) TMN; 3. X: para a ligao entre os blocos OSF de TMN distintas. So definidas ainda outras duas classes de pontos de referncia que no pertencem TMN mas tambm so muito importantes (veja a figura 5.5):

Figura 5.5 - Pontos de referncia entre blocos funcionais 4. G: entre a estao de trabalho e o usurio;



40

5. M: entre QAF e entidades no TMN. Arquitetura Fsica O ltimo estgio, chamado de arquitetura fsica, implementa fisicamente as funes da TMN representando sua topologia. A Arquitetura Fsica fornece os meios para a implementao dos blocos funcionais definidos pela arquitetura funcional. Os blocos que fazem parte da arquitetura possuem blocos funcionais correspondentes na arquitetura funcional. Os blocos da arquitetura fsica so: Rede de Comunicao de Dados (DCN): uma rede de dados que utiliza protocolos padronizados (deve, sempre que possvel, seguir o modelo OSI) e permite a comunicao dos elementos de rede com os sistemas de suporte operao. Pode ser composta de vrias sub-redes de comunicao de dados, como X-25, RDSI, LAN, etc. Elementos de Rede (NE): bloco que corresponde s entidades de telecomunicaes (equipamentos ou facilidades) que so efetivamente monitorados e/ou controlados. Sistema de Operao (OS): engloba as funes que permitem realizar o processamento e o armazenamento das informaes relacionadas com a operao, a administrao a manuteno e o provisionamento das redes e servios de telecomunicaes. Dispositivo de Mediao (MD): o bloco que age sobre as informaes trocadas entre os NE e os OS, visando tornar a comunicao mais transparente e eficiente. Pode envolver vrias categorias de processo: processos de converso de informao entre diferentes modelos de informao; processos envolvendo interfuncionamento entre protocolos de alto nvel; processo de tratamento de dados; processo de tomadas de decises; processo de armazenamento de dados. Estaes de Trabalho (WS): o bloco que engloba os recursos para o acesso de operadores aos blocos NE, OS e MD. Este terminal deve ser capaz de traduzir o modelo de informao usado na TMN, disponvel no ponto de referncia f, em um formato apresentvel ao usurio, no ponto de referncia g. As funes das WS devem prover



41

ao usurio do terminal as funes gerais para executar entrada e sada de dados. Geralmente incluem: segurana de acesso e login; reconhecimento e validao de entradas; formatao e validao de sadas; suporte para "menus", telas, janelas e paginao; acesso TMN; ferramentas para modificao de lay-out. Adaptador Q (QA): permite a interconexo de equipamentos ou interfaces no TMN s interfaces Qx ou Q3.

5.1. Exerccios1. Qual o instituto que padronizou o TMN? 2. Faa um diagrama mostrando o relacionamento entre a Rede de Gerncia e a Rede de Telecomunicaes, conforme o TMN. 3. Cite algumas redes e servios que podem ser gerenciadas pela tmn. 4. Cite as camadas funcionais do TMN e discorra sobre elas. 5. Quais so as reas funcionais do TMN? 6. As recomendaes ITU-T [M.3010] abordam trs aspectos no planejamento e no projeto da TMN: Arquitetura de Informao; Arquitetura Fsica e Arquitetura Funcional. Fale sobre elas.

5.2. Referncias Especficas e LinksExtrado da Apostila de Rede de Gerncia de Telecomunicaes - TMN da Professora Linnyer Beatrys Ruiz.



42

6. Simple Network Management Protocol (SNMP)Extrado do Cap 3 da Apostila de Gerncia de Redes de Computadores e de Telecomunicaes da Profa. Dra. Elizabeth Sueli Especialski

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

Gerenteinformar valor de varivel (GET response) informar ocorrncia de evento (TRAP)Figura 6.1. Troca de mensagens SNMP entre Gerente e Agente

Agente

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,



43

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. Servios e protocolos de gerncia O primeiro dos protocolos de gerncia de rede foi o SGMP (Simple Gateway Monitoring Protocol) que surgiu em novembro 1987. Entretanto, o SGMP era restrito monitorao de gateways. A necessidade crescente de uma ferramenta de gerenciamento de rede mais genrica fez emergirem mais algumas abordagens: High-Level Entity Management System HEMS generalizao do HMP Host Management Protocol; SNMP Simple Network Management Protocol um melhoramento do SGMP; CMOT (CMIP over TCP/IP) uma tentativa de incorporar o mximo possvel o protocolo (CMIP), servios e estrutura de base de dados que estava sendo padronizada pela ISO para gerenciamento de redes.

No incio de 1988 a IAB (Internet Architecture Board) revisou os protocolos e escolheu o SNMP como uma soluo de curto prazo e o CMOT como soluo de longo prazo para o gerenciamento de redes. O sentimento era que, em um perodo de tempo razovel, as instalaes migrariam do TCP/IP para protocolos baseados em OSI. Entretanto, como a padronizao do gerenciamento baseado no modelo OSI apresentava muita complexidade de implementao e o SNMP, devido sua simplicidade, foi amplamente implementado nos produtos comerciais, o SNMP tornou-se um padro de fato. Posteriormente, pela existncia de lacunas funcionais (devido exatamente simplicidade do SNMP), foram definidas novas verses do protocolo SNMP chamadas de SNMPv2 e SNMPv3, e o SNMP original ficou conhecido como SNMPv1. A primeira verso da arquitetura de gerenciamento SNMP foi definida no RFC 1157 de maio de 1990. A RFC 1157 define que a arquitetura SNMP consiste de uma soluo para o problema de gerenciamento de redes, em termos de: o escopo da informao de gerenciamento comunicada pelo protocolo; a representao da informao de gerenciamento comunicada pelo protocolo; operaes sobre a informao de gerenciamento, suportadas pelo protocolo;Engenharia em Telecomunicaes - UnC


44

a forma e o significado das trocas entre entidades de gerenciamento; a definio dos relacionamentos administrativos entre entidades de gerenciamento; a forma e o significado das referncias s informaes de gerenciamento. O RFC 1157 define ainda trs objetivos a serem alcanados pelo SNMP: minimizar o nmero e complexidade das funes de gerenciamento, ser flexvel o suficiente para permitir expanses futuras e ser independente da arquitetura e mecanismo dos dispositivos gerenciados. Elementos da Arquitetura O SNMP foi projetado para ser um protocolo de camada de aplicao da famlia TCP/IP e trabalhar sobre UDP, que um protocolo no orientado conexo. A comunicao de informaes de gerenciamento feita no SNMPv1 utilizando somente cinco mensagens de protocolo, conforme mostrado na figura 6.2. Trs delas (get-request, get-next-request e set-request) so iniciadas pelo processo de aplicao gerente, as outras duas (get-response e trap) so geradas pelo processo agente. A gerao de mensagens chamada de um evento. No esquema de gerenciamento SNMP, o gerente monitora a rede, indagando os agentes sobre seu estado e caractersticas. Entretanto a eficincia aumentada quando agentes enviam mensagens no solicitadas chamadas de traps. Um trap ocorre quando o agente observa a ocorrncia de um parmetro pr-configurado no mdulo agente.Operao get-request get-next-request Funo Solicitao de recuperao do valor de uma ou um conjunto de variveis informados na solicitao Solicitao de recuperao do valor de uma ou um conjunto de variveis que sucedem lexicograficamente quelas informadas na solicitao Solicitao para atribuio de valor a uma ou um conjunto de variveis Resposta s operaes get-request, get-next-request e setrequest Envio de um evento no solicitado para uma ou vrias estaes de gerenciamento. Tipos de traps definidos no RFC 1215: cold start, warm start, link down, link up, authentication failure, egp neighbor loss e enterprise specific.

set-request get-response Trap

Tabela 6.1 Operaes Suportadas no SNMPv1

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



45

Figura 7.2 Formato de Mensagens SNMPv1

O SNMPv1 tem um processo de autenticao fraca. Ele se baseia em um string de caracteres chamado community contido no cabealho do pacote SNMP e que trafega em modo legvel pela rede. So definidas duas communities, uma para acesso somente de leitura e outra para acesso de leitura e gravao. O SNMP no prov mecanismos especficos para que um gerente d comandos para que um agente execute uma ao. Entretanto, possvel utilizar a operao set para contornar esta deficincia. Um objeto pode ser utilizado para representar um comando, ento uma ao especfica executada se o valor do objeto alterado para um valor especfico (ex: objeto reboot). Apesar de amplamente difundido e utilizado no gerenciamento de redes de computadores, o SNMPv1 possui as seguintes limitaes: no apropriado para o gerenciamento de redes muito grandes, devido limitao de performance de polling; traps SNMP no so reconhecidos, pois so implementados sobre protocolos sem reconhecimento/conexo; o padro SNMPv1 prov somente autenticao trivial; o modelo da MIB limitado e no suporta aplicaes que questionam o gerenciamento baseado em valores ou tipos de objetos; no possvel ter uma idia do trfego existente nas redes onde os recursos gerenciados esto instalados pois estas informaes referem-se ao prprio recurso onde o agente est executando;



46

incapacidade de analisar seus prprios dados e enviarem notificaes quando alguns limiares forem atingidos; e no suporta a comunicao gerente-gerente. no suporta a comunicao gerente-gerente. Modelo de informao Atualmente vrios documentos definem a informao de gerenciamento modelo SNMP, sendo que os principais so: o RFC 1155 - Estrutura Informao de Gerenciamento (SMI), o RFC 1213 - Base de Informao Gerenciamento (MIB) e o RFC 1157 Protocolo Simples de Gerenciamento Rede (SNMP). no da de de

A SMI (Structure and Identification of Management Information for TCP/IP-Based Internets) descreve como os objetos gerenciados contidos na MIB so definidos. A MIB (Management Information Base) descreve quais so os objetos contidos na MIB. O SNMP (Simple Network Information Protocol) define o protocolo usado para gerenciar estes objetos. 6.1 Estrutura da Informao de Gerenciamento (SMI)

A SMI especifica as estruturas que representam os recursos a serem gerenciados, usando um subconjunto da sintaxe denominada ASN.1 (Abstract Syntax Notation One) [ISO8824, 1987]. Tambm, para efeitos de simplicidade, utilizado um subconjunto das regras bsicas de codificao ASN.1. Todas as codificaes utilizam a forma de tamanho definido. Alm disso, quando permitido, so usadas codificaes de no construtores, preferencialmente s codificaes de construtores. Esta restrio se aplica a todos os aspectos de codificao ASN.1, tanto para as unidades de dados do protocolo, quanto para os objetos de dados que elas contm. Os nomes para todos os tipos de objetos contidos na MIB, so definidos explicitamente na MIB padro Internet ou em outros documentos que seguem as convenes de nomeao definidas na SMI. A SMI requer que todos os protocolos de gerenciamento definam mecanismos para identificar instncias individuais dos tipos de objetos de um elemento de rede particular. Cada instncia de tipo de objeto definido na MIB identificada, nas operaes SNMP, por um nome nico chamado nome de varivel. Geralmente, o nome de uma varivel SNMP um OBJECT IDENTIFIER da forma x.y, onde x o nome de um tipo de objeto no agregado definido na MIB e y um fragmento de OBJECT IDENTIFIER que, de uma forma especfica para o tipo de objeto nomeado, identifica a instncia desejada.



47

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 6.3 mostra a rvore de registro utilizada para nomeao de objetos definidos na MIB.TOP CCITT (0) JOINT-ISO-CCITT (2)

ISO (1)

STD(0) REG AUTHORITY(1)

MEMBER BODY(2)

ORG (3) DOD (6) INTERNET (1)

DIRECTORY (1)

MGMT (2) EXPERIMENTAL(3)

PRIVATE (4)

MIB (1)

ENTERPRISES[1]

EGP (8) TCP (6) INTERFACE (2) IP (4) ICMP (5) SYSTEM(1) ADDRESS TRANSLATION (3) UDP (7) IBM (2) PROTEON (1) RESERVED (0)

Figura 6.3 - rvore de registro de tipos de objetos

A sub-rvore MGMT contm a definio das bases de informao de gerenciamento que foram aprovadas pelo IAB. Atualmente, existem duas verses



48

da MIB: mib-1 e mib-2. A mib-2 uma extenso da primeira. As duas possuem o mesmo identificador na sub-rvore porque apenas uma das duas estar presente em qualquer configurao. A SMI identifica os tipos de dados que podem ser usados na construo de uma base de informao de gerenciamento e como os recursos dentro desta base podem ser representados e nomeados. So definidos apenas dois tipos de dados simples: escalar (variveis simples) e array bidimensional de escalares (tabelas). Os tipos de dados ASN.1 que podem ser utilizados na definio dos objetos da MIB so basicamente: UNIVERSAL: INTEGER, OCTET STRING, SEQUENCE e SEQUENCE OF. APPLICATION: NetworkAddress, IpAddress, Counter, Gauge, TimeTicks e Opaque. NULL, OBJECT IDENTIFIER,

Cada objeto na MIB possui um nome, um tipo, um valor, uma forma de acesso, um status e uma descrio, e sua definio, de acordo com a SMI, segue a seguinte estrutura: nome do objeto OBJECT-TYPE SYNTAX ACCESS STATUS

DESCRIPTION

::= {} Exemplos: tcpConnTable OBJECT-TYPE SYNTAX ACCESS STATUS SEQUENCE OF TcpConnEntry not-accessible mandatory A table containing TCP connection-specific

DESCRIPTION information. ::= {tcp 13}

tcpConnEntry OBJECT-TYPE



49

SYNTAX ACCESS STATUS

TcpConnEntry not-accessible mandatory

DESCRIPTION Information about a particular current TCP connection. An object of this type is transient, in that it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state. ::= {tcpConnTable 1} TcpConnEntry SEQUENCE {tcpConnState tcpConnLocalAddress tcpConnLocalPort tcpConnRemAddress tcpConnRemPort tcpConnState SYNTAX OBJECT-TYPE INTEGER {closed (1), listen (2), synSent (3), synReceived (4), established (5), finWait1 (6), finWait2 (7), closeWait (8), lastAck (9), closing (10), timeWait (11), deleteTCB (12) } ACCESS STATUS read-write mandatory INTEGER, IpAddress, INTEGER (0..65535), IpAddress, INTEGER (0..65535)}



50

DESCRIPTION

The state of this TCP connection.

The only value which may be set by a management station is deleteTCB(12). Accordingly, it is appropriate for an agent to return a bad value response if a management station attempts to set this object to any other value. If a management station sets this object to the value deleteTCB(12), then this has the effect of deleting the TCB (as defined in RFC 793) of the corresponding connection on the managed node, resulting in immediate termination of the connection. As an implementation-specific option, a RST segment may be sent from the managed node to the other TCP end point (note however that RST segments are not sent reliably). ::= {tcpConnEntry 1} tcpConnRemPort OBJECT-TYPE SYNTAX ACCESS STATUS INTEGER (0..65535) read-only mandatory The remote port number for this TCP connection.

DESCRIPTION

::= {tcpConnEntry 4}

6.2

A base de informaes de gerenciamento - MIB

A MIB uma coleo estruturada de objetos gerenciados. Objetos gerenciados representam os recursos sujeitos ao gerenciamento. Cada nodo do sistema de gerenciamento mantm uma MIB que reflete o estado dos recursos gerenciados naquele nodo. Uma entidade de gerenciamento pode monitorar os recursos de um

apostila gerencia de redes unc

Documents