Apostila da Disciplina Gerncia de Redes Docente: Karina Macedo

Julho 2013

GERNCIA DE REDES

Gerncia de Redes

SUMRIO
1 . Conceitos e Princpios de Redes e Gerenciamento de Redes 2 . reas Funcionais de Gerenciamento de Redes 03 11

3. SLA e SLM 15 4 . Modelo OSI de Gerenciamento de Rede 24 5 . Rede de Gerenciamento de Telecomunicaes TMN 30 6 . 7 . 8 . 9 . Simple Network Management Protocol SNMP Gerenciamento de Servios ITIL Acrnimos Referncias
Gerncia de Redes

42 68 72 76
3

1. Conceitos e Princpios de Redes e Gerenciamento de Redes

1.1. Requisitos Fundamentais de Uma Infra-Estrutura para Tratamento da Informao
Os 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

Gerncia de Redes

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

Medida da reduo da incerteza, sobre um determinado estado de coisas, por intermdio de uma mensagem.

Gerncia de Redes

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.

Gerncia de Redes

1.3. Os Cinco Tratamentos da Informao

A 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 Transmisso Analgica Transmisso Digital Codificao Analgica Eltrica Cdigos de Pulsos PCM

Dados

Transmisso Analgica

Chaveamento de Fase PSK

Gerncia de Redes

Dado s

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 Rede

Segundo 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

Gerncia de Redes

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. Agente
O 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 Dados

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

Gerncia de Redes

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 Gerenciamento

Os 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 Gerente O 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

Gerncia de Redes

1 0

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

Gerncia de Redes

1 1

2. reas Funcionais da Gerncia de Rede

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

A 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 Desempenho Na 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

Gerncia de Redes

1 2

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 Falhas

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

Gerncia de Redes

1 3

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 Contabilizao

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

Gerncia de Redes

1 4

2.5. Gerenciamento de Segurana

O gerenciamento da segurana prov facilidades para proteger recursos da rede e informaes dos usurios. Estas facilidades devem estar disponveis apenas para usurios autorizados. necessrio que a poltica de segurana seja robusta e efetiva e que o sistema de gerenciamento da segurana seja, ele prprio, seguro. O gerenciamento de segurana trata de questes como [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. Resumo A 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. Exerccios

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

Gerncia de Redes

1 5

3. SLA e SLM
Proposta de um Modelo de Service Level Agreement Introduo
Este 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

Gerncia de Redes

1 6

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

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

Gerncia de Redes

1 7

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 SLA

O 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

Gerncia de Redes

1 8

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 contexto

A 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 Papis
Primeiro, 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

Gerncia de Redes

1 9

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 pagamento
Os 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 reviso

Gerncia de Redes

2 0

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 mudana
A 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 financeiro

O 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

Gerncia de Redes

2 1

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

Gerncia de Redes

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

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

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

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

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

Gerncia de Redes

2 3

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 Exerccios
1. Repasse o exerccio feito em aula utilizando alguma empresa diferente da original.

3.2 Referncias Especficas e Links

Texto 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 <acesso em 20/03/2009>

Gerncia de Redes

2 4

4. Modelo OSI de Gerenciamento

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

Estruturas de gerenciamento
A estrutura de gerenciamento refere-se aos trs enfoques definidos pela ISO em seu framework [ISO 7498-4]: Gerenciamento de Sistemas, Gerenciamento de Camada e Operao de Camada. O Gerenciamento de Sistemas, conforme apresentado na figura 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
LME LME LME LME

TRANSPORTE
REDE ENLACE FSICO

C M I P SMAE MIB LME LME LME APLICAO APRESENTAO SESSO

SMAE M I B

LME

APLICAO

LME LME LME LME LME LME

APRESENTAO SESSO

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

Gerncia de Redes

2 5

camada N
protocolo de gerenciamento da camada N

camada N

Figura 4.2 Gerenciamento de Camada

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

camada conexo 2

... conexo n

Figura 4.3 Operao de Camada

Componentes de gerncia OSI

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

Gerncia de Redes

26

Gerente Agente

Gerente Agente

Agente

Gerente

Figura 4.4

Componentes do Gerenciamento OSI

Estrutura da informao de gerenciamento

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

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

Gerncia de Redes

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 Modo requisio confirmad o d e Primitivas Semntica

M-CANCEL-GET (operao)

request/indication response/confirm

Cancelar operao de realizada

uma leitur a sobr

e vrios objetos

Gerncia de Redes

2 8
Le r valores atributos de objetos

M-GET (operao)

confirmado

request/indication

de

response/confirm Modificar valores de atributos de objetos

M-SET (operao)

confirmado

request/indication

response/confirm no confirmado request/indication u Cr m iar a de objeto

M-CREATE (operao)

confirmado

request/indication

instnci a

response/confirm u m a

M-ACTION (operao)

confirmado

request/indication

response/confirm

Solicitar que a o pr-definida se executa po ja da r um objeto

no confirmado

request/indication u m Destruir a instncia de objeto

M-DELETE (operao)

confirmado

request/indication response/confirm

no confirmado M-EVENT-REPORT (notificao) confirmado

request/indication request/indication Notificar ocorrnc d ia e evento a um sistema gerente a u m

esponse/confirm

no confirmado

request/indication

Tabela 4.1 Servios de Gerenciamento

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

Gerncia de Redes

2 9

A Informao de Gerenciamento definida seguindo a AOO-Abordagem de Orientao a Objetos e armazenada em uma MIB. 4.1. Exerccios 1. 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 Links Extrado do Cap 6 da Apostila de Gerncia de Redes de Computadores e de Telecomunicaes da Profa. Dra. Elizabeth Sulei Especialski

Gerncia de Redes

3 0

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

Gerncia de Redes

3 1

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.

Gerncia de Redes

3 2

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.

Gerncia de Redes

3 3

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:

Gerncia de Redes

3 4

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 das condies atuais do sistema;

Gerncia de Redes

3 5

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 de

Gerncia de Redes

3 6

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

Gerncia de Redes

3 7

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:

Gerncia de Redes

3 8

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.

Gerncia de Redes

3 9

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;

Gerncia de Redes

4 0

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

Gerncia de Redes

4 1

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

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. Exerccios
1. 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 Links

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

Gerncia de Redes

4 2

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)

Gerente Agente
informar valor de varivel (GET response) informar ocorrncia de evento (TRAP)
Figura 6.1. Troca de mensagens SNMP entre Gerente e 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,

Gerncia de Redes

4 3

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;

Gerncia de Redes

4 4

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

set-request get-response Trap

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

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.

Gerncia de Redes

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;

Gerncia de Redes

4 6

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 no modelo SNMP, sendo que os principais so: o RFC 1155 - Estrutura da Informao de Gerenciamento (SMI), o RFC 1213 - Base de Informao de Gerenciamento (MIB) e o RFC 1157 Protocolo Simples de Gerenciamento de Rede (SNMP). A SMI (Structure and Identification of Management Information for TCP/IP-Based Internets) descreve como os objetos gerenciados contidos na MIB so definidos. A MIB (Management Information Base) descreve quais so os objetos contidos na MIB. O SNMP (Simple Network Information Protocol) define o protocolo usado para gerenciar estes objetos. 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.

Gerncia de Redes

4 7

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 sysDesc r 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) ISO (1)

JOINT-ISO-CCITT (2)

STD(0) R E G AUTHORITY(1)

MEMBER BODY(2)

O R G

(3 )

DOD (6)

INTERNET (1)

DIRECTORY (1)

MGMT (2)

PRIVA TE

( 4 )

MIB (1)

EXPERIMENTA L(3)

ENTERPRISE S[1]

EGP (8)

TCP (6) INTERFACE (2) IP (4)

IBM (2)

UDP (7) ICMP (5)

PROTEON (1)

SYSTEM(1)

ADDRE SS RESERVED (0) TRANSLATION (3)

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

Gerncia de Redes

4 8

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 <nome de um tipo, ex.: INTEGER, IpAddress,

ACCESS STATUS DESCRIPTION

etc.> <read-only, write-only, read-write, not-accessible > <se obrigatrio ou no: mandatory ou optional> <um texto explicativo escrito entre aspas>

::= {<nome usado para acessar o objeto via SNMP>} Exemplos: tcpConnTable OBJECT-TYPE SYNTAX ACCESS STATUS SEQUENCE OF TcpConnEntry not-accessible mandatory

DESCRIPTION A table containing TCP connection-specific information. ::= {tcp 13} tcpConnEntry OBJECT-TYPE

Gerncia de Redes

4 9

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 INTEGER, IpAddress, INTEGER (0..65535), IpAddress, INTEGER (0..65535)}

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

Gerncia de Redes

5 0

DESCRIPTION

The state of this TCP connection.

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

ACCESS STATUS

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 nodo, lendo os valores dos objetos na MIB e pode controlar os recursos de um nodo, modificando estes valores. Os objetos da mib-2 so subdivididos nos seguintes grupos: system: informaes gerais sobre o sistema; interfaces: informaes sobre cada uma das interfaces do sistema para a sub-rede; at(address translation; deprecated): descreve a tabela de translao de endereos para mapeamento de endereos internet para endereos de sub-rede; ip: informao relativa a experincias de implementao e execuo do

Gerncia de Redes

5 1

protocolo IP (internet protocol) no sistema; icmp: informao relativa a experincias de implementao e execuo do protocolo ICMP (internet control message protocol) no sistema; tcp: informao relativa a experincias de implementao e execuo do protocolo TCP (transmission control protocol) no sistema; udp: informao relativa a experincias de implementao e execuo do protocolo UDP (user datagram protocol) no sistema; egp: informao relativa a experincias de implementao e execuo do protocolo EGP (external gateway protocol) no sistema; cmot: informaes para sistemas de gerncia OSI; transmission: fornece informaes sobre esquemas de transmisso e protocolos de 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 6.4 ilustra a estrutura do grupo system e a tabela 6.2 fornece a sintaxe do objeto, a forma de acesso permitida e uma descrio sucinta da semntica.

system (mib-2 1) sysDescr(1) sysObjectID(2) sysUpTime(3) sysContact(4) sysName(5) sysLocation(6) sysServices(7)

Fig. 6.4. Grupo System da MIB-II

Gerncia de Redes

52

Objeto sysDescr

Sintaxe DisplayStri ng

Acesso RO

Semntica Descrio de uma entidade (hardware,

sysObjectID

sysUpTime

(Size (0..255) OBJECT IDENTIFIE R TimeTicks DisplayStri ng (Size (0..255) DisplayStri ng (Size (0..255) DisplayStri ng (Size (0..255) INTEGER (0..127)

RO

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

RO

sysContact

RW

sysName

RW

pa ra

sysLocation

RW

Localizao fsica do nodo

sysServices

RO

Valor indicando o conjunto de servios oferecidos pela entidade

Tabela 6.2 - Objetos do grupo System da MIB-II Monitorao Remota - RMON MIB A medida em que as redes foram crescendo e se tornando geogrfica e logicamente distribudas, o gerenciamento de redes tornou-se mais desafiador. Utilizando apenas informaes da MIB-II, o gerente de redes no consegue ter uma idia do trfego existente nas redes onde os recursos gerenciados esto instalados porque estas informaes referem-se apenas ao prprio recurso onde o agente est executando. Em uma grande rede, com vrios ns gerenciados e no gerenciados, fica praticamente impossvel inspecionar variveis da MIB-II de todos os agentes da rede para se ter uma idia do trfego entre eles. Uma soluo encontrada foi a instalao de dispositivos remotos de gerenciamento, denominados probes, nos segmentos remotos. A mais importante adio ao conjunto de padres SNMP foi a MIB RMON (Remote Network Monitoring MIB) que padronizou as informaes de gerenciamento enviadas para e recebidas desses probes na RFC1757 [Wal 95]. Outro problema com os agentes SNMP tradicionais que estes no so capazes de analisar seus prprios dados e, por exemplo, serem programados para enviarem notificaes quando certos limiares nas variveis forem atingidos. Isto fora a estao de gerenciamento a ficar inspecionando (fazendo polling) as variveis das diversas entidades de gerenciamento, causando um trfego excessivo na rede. A tecnologia de RMON consiste na presena de um monitor instalado na rede que se deseja estudar, coletando informaes e, eventualmente, enviando notificaes sobre a ocorrncia de eventos. O monitor pode ser tanto um dispositivo dedicado captura de dados e sua anlise, como tambm pode estar implementado em estaes de trabalho, em servidores, roteadores, hubs, etc. Essencialmente, a RMON uma extenso da MIB Internet. Atravs da escrita em variveis desta MIB, o gerente pode programar o monitor para coletar dados e

armazen-los em tabelas para serem recuperados posteriormente.

Gerncia de Redes

5 3

O RMON divide o processo de captao de dados em duas partes. Os dados so coletados pelo agente RMON que pode estar em um segmento prximo ao dispositivo ou implementado no dispositivo. Uma ou mais estaes de gerenciamento falam com o agente RMON (usando SNMP) em lugar de falar diretamente com o dispositivo gerenciado. Por terminologia, um sistema que implementa a MIB RMON chamado de probe RMON. Mesmo que a estao de gerenciamento perca conexo ao probe a coleta de dados continua, uma vez que o probe est conectado diretamente rede sendo monitorada. A RMON foi projetada para atingir os seguintes objetivos: operao off-line: o monitor coleta e armazena estatsticas que podem ser recuperadas pela estao gerente a qualquer momento; monitorao preemptiva: o monitor est sempre ativo, continuamente rodando diagnsticos e armazenando dados; deteco e alerta de problemas: o monitor pode verificar continuamente determinadas condies e comunic-las quando ocorrerem; resumo dos dados: o monitor capaz de realizar algum processamento como, por exemplo, descobrir os 10 hosts mais ativos na rede; mltiplos gerentes: o monitor deve suportar vrias estaes gerentes.

A figura 6.6 mostra o cenrio de gerenciamento de uma rede utilizando RMON.

Figura 6.6 Utilizao do RMON na gerncia de rede. Para implementar um agente RMON em um dispositivo, ele deve ser capaz de

Gerncia de Redes

5 4

operar no modo promscuo, isto , dever poder aceitar dados no endereados especificamente para ele. As metas definidas pelo grupo de trabalho para a definio das MIBs RMON so definidas nos RFCs 1757 e 2021. So elas: operao off-line o probe acumula estatsticas e executa diagnsticos continuamente, mesmo que a comunicao com a estao gerente no seja possvel ou eficiente. As notificaes podem ser enviadas para o gerente quando eventos excepcionais ocorrerem. Alm disso o gerente pode recuperar informaes do probe RMON quando melhor lhe aprouver, utilizando o protocolo SNMP; monitoramento pr-ativo - se o monitor tiver recursos suficientes, pode executar continuamente diagnsticos e logar performance da rede. Em uma falha na rede, pode notificar a estao gerente da falha e prover informaes proveitosas no diagnstico da falha; deteco e registro de problemas - O monitor pode passivamente reconhecer certas condies de erro e outros, como congestionamento, no trfego observado. Quando uma condio configurada ocorrer, pode registrar e tentar notificar a estao gerente; anlise de dados - o monitor pode executar anlises especficas sobre os dados coletados na sub-rede. Por exemplo, pode determinar qual host gera a maior parte do trfego ou dos erros na sub-rede; mltiplos gerentes - uma configurao de rede pode ter mais do que uma estao gerente como medida de redundncia, que podem executar funes diferentes e prover capacidades de gerncia para unidades diferentes na organizao. O RMON prov informaes estatsticas e de diagnstico, minimiza o trfego de gerenciamento, reduz o impacto de perda de conectividade, serve vrias estaes de gerenciamento simultaneamente e fornece, ainda, um conjunto padro de mtricas que pode ser usado por vrios dispositivos que suportam RMON. A MIB RMON possui OID {1.3.6.1.2.1.16} e foi originalmente definida para redes ethernet em novembro de 1991 no RFC 1271, em 1995 foi substituda pelo RFC 1757, que foi, em maio de 2000, substitudo pelo RFC 2819. Originalmente a MIB RMON s contemplava redes ethernet, mas em setembro de 1993 foi desenvolvido o RFC 1513, que trazia extenses para redes token ring. A MIB RMON contm 10 grupos. A figura 6.6 mostra a localizao da MIB RMON com os grupos definidos:

Gerncia de Redes

5 5

Figura 6.6 Grupos RMON

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

Gerncia de Redes

5 6

event (rmon 9) - controla a gerao e notificao de eventos, o que pode incluir mensagens de trap SNMP; tokenRing (rmon 10) prov parmetros adicionais para redes token ring. Subramanian [Subramanian 2000] (p.327) enquadra os grupos RMON em trs grandes categorias: a maior a dos grupos que analisam as informaes e geram estatsticas. Nesta categoria enquadram-se os grupos statistics, history, host e host top N. A segunda categoria trata de eventos da rede e funes de gerao de relatrios. Estes so os grupos de alarm e event. A terceira categoria trata com filtragem e captura de pacotes. Nesta categoria enquadram-se os grupos filter e packet capture. A figura 6.7 ilustra esta classificao.

Figura 6.7 Classificao dos grupos RMON

Todos os grupos so opcionais, mas a implementao de alguns grupos requer outros grupos. Existem as seguintes dependncias: o grupo alarm requer a implementao do grupo event; o grupo hostTopN requer a implementao do grupo host; o grupo capture requer a implementao do grupo filter. Tipicamente, um monitor remoto necessitar ser configurado para coletar dados. A configurao dita o tipo e forma de dados para serem coletados. A MIB organizada em grupos funcionais. Cada grupo ter uma ou mais tabelas de controle e uma ou mais tabelas de dados. Uma tabela de Controle contm parmetros que descrevem o dado na tabela de Dados, que somente para leitura. Assim, a estao gerente seta os parmetros apropriados para configurar o monitor remoto para coletar os dados desejados. Os parmetros so setados pela adio de um novo registro na tabela, ou alterando uma existente. Desse

Gerncia de Redes

5 7

modo, funes para serem executadas pelo monitor so definidas e implementadas na tabela. Por exemplo, uma tabela Controle pode conter objetos que especifiquem a origem dos dados coletados, tipos de dados, hora/data da coleta etc... A RMON2 A MIB RMON original se preocupava basicamente com operao e gerenciamento das camadas fsica e de enlace, de uma rede remota. O RMON2 definido no RFC2021, estende as capacidades do RMON s camadas superiores, adicionando 10 novos grupos, conforme mostra a figura 7.8: (Miller 1997,

Subramanian 2000) protocol directory (rmon 11) - identifica os protocolos que o probe pode monitorar. Os protocolos que podem ser monitorados foram definidos no RFC2074; protocol distribution (rmon 12) - prov informao relativa ao trfego de diferentes protocolos, tanto em bytes quanto em pacotes. Ele coleta estatsticas que ajudam o administrador de rede a gerenciar a banda alocada para cada protocolo; address map (rmon 13) - correlaciona os endereos de rede com endereos MAC, armazenando-os em uma tabela. A traduo de endereos permite a gerao de mapas topolgicos aprimorados e a deteco de endereos ip duplicados; network-layer host (rmon 14) coleciona estatsticas sobre o volume de trfego de entrada e sadas das estaes com base no endereo de nvel de rede. Como conseqncia, o gerente pode observar alm dos roteadores que interligam as sub-redes e identificar as reais estaes que esto se comunicando; network-layer matrix (rmon 15) prov estatsticas sobre o volume de trfego entre pares de estaes com base no endereo do nvel de rede; application-layer host (rmon 16) agrega estatsticas sobre o volume de trfego por protocolo de nvel superior gerado de ou para cada endereo de rede; application-layer matrix (rmon 17) coleciona estatsticas sobre o volume de trfego, por protocolo, trocados por pares de endereos de rede; user history collection (rmon 18) - combina mecanismos vistos nos grupos alarm e history para prover informaes de coleo de dados histricos especificados pelo usurio; probe configuration (rmon 19) define parmetros de configurao padres para probes RMON. Deste modo, a estao de gerenciamento com software

Gerncia de Redes

5 8

de um fabricante capaz de configurar, remotamente, um probe de outro fabricante; rmon conformance (rmon 20) descreve os requisitos de conformidade para a MIB RMON2.

Figura 6.8 Grupos RMON2

Stallings [Stallings 1999], (p.277) cita duas implicaes importantes decorrentes do fato de que o RMON2 decodifica pacotes das camadas 3 a 7 do modelo OSI: o probe RMON2 pode monitorar o trfego baseado nos endereos e protocolos de camada de rede, incluindo o IP. Isto possibilita que o probe veja acima da rede local ao qual est conectado; como o RMON2 pode decodificar e monitorar trfego da camada de aplicao, o probe pode gravar trfego para aplicaes especficas. A figura 6.9 mostra o nvel de visibilidade que RMON e RMON2 provem dentro de um segmento LAN ou de uma rede em cada uma das camadas do OSI.

Gerncia de Redes

5 9

Figura 6.9 Visibilidade RMON1 x RMON2

As restries com relao performance para implementao do RMON1 so ainda maiores no RMON2, pois ele necessita ainda de mais recursos de memria e processamento para ser implementado. Para atender a estas demandas, os fabricantes de dispositivos RMON2 esto oferecendo probes stand-alone que executam em plataformas de hardware de alta capacidade de memria e processamento. (Stallings 1999, p.326) O SNMPv2 O SNMP foi desenvolvido como uma soluo temporria para prover um gerenciamento mnimo da rede, a soluo definitiva viria com o gerenciamento baseado no modelo OSI. Alguns motivos fizeram que esta transio no acontecesse da forma planejada, principalmente porque: o modelo OSI usava a abordagem orientada a objeto que era mais complexa do que o que se planejava implementar no SNMP que implementou um MIB escalar, o que tornava a transio mais complexa. o desenvolvimento de padres OSI de gerenciamento e subseqente disponibilizao de sua implementao em dispositivos de rede demorou muito mais do que o esperado, abrindo uma janela de oportunidade que foi aproveitada pelo SNMP. A verso 2 do SNMP (SNMPv2) foi desenvolvida quando se tornou bvio que o

Gerncia de Redes

6 0

padro de gerenciamento OSI no seria implementado em um futuro prximo. Os maiores fabricantes de dispositivos de rede j haviam incorporado mdulos SNMP em seus equipamentos e estava claro para todos que o SNMP necessitava de melhoramentos. O primeiro projeto do SNMPv2 no foi amplamente aceito pelo mercado. As razes, para esta falta de aceitao, so a complexidade dos melhoramentos de segurana e administrao do framework. Vrias tentativas de simplificao foram tentadas, entretanto no se chegou a nenhum consenso. Como resultado ocorreram trs aes (Miller 1997, p.201): os documentos que tinham atingido consenso foram publicados em janeiro de 1996 como RFCs 1902-1908; modificaes menores no modelo de administrao e segurana do SNMPv2, denominados comunit-based SNMPv2 (SNMPv2c), foram publicados em janeiro de 1996, documento RFC 1901; o trabalho continuou em outras reas: segurana, framework administrativo, MIB de configurao remota e comunicao gerente-gerente. Vrias mudanas significativas deveriam ser introduzidas no SNMPv2. Uma das mais significativas seria a de prover funes de segurana, que inexistiam no SNMPv1. Infelizmente, depois de muito esforo, no houve consenso, ento a feature de segurana foi retirada da especificao final. Apesar do modelo organizacional permanecer praticamente inalterado e a despeito da falta de melhorias na parte de segurana, vrias melhorias foram feitas na arquitetura SNMPv2: novos tipos de dados, novas macros, convenes textuais, operaes que facilitam a transferncia de grandes quantidades de dados (bulk), transferncia de blocos de dados (bulk), cdigos de erro mais detalhados, suporte a multiprotocolos na camada de transporte, incluso de mensagem de gerente para gerente, definio de uma nova estrutura de informaes de gerenciamento (SMIv2 definida nas RFCs 1902 a 1904), comandos de conformidade, melhorias em tabelas e incluso de dois novos grupos na MIB , security e SNMPv2. [Subramanian 2000], [Miller 1997] O SNMPv2 prov trs tipos de acesso s informaes de gerenciamento de redes. O primeiro tipo de interao chamado request-response, quando o gerente SNMP envia uma solicitao a um agente SNMPv2 que responde. O segundo tipo de interao um request-response onde ambas as entidades so gerentes SNMP. O terceiro tipo uma interao no confirmada, onde um agente SNMPv2 envia uma mensagem no solicitada, ou trap, para o gerente e nenhuma resposta retornada. Somente a segunda forma nova no SNMPv2, as outras duas j existiam no SNMPv1. A figura 6.10 mostra a arquitetura de gerenciamento utilizando o SNMPv2.

Gerncia de Redes

6 1

Figura 6.10 Arquitetura de gerenciamento de rede SNMPv2

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

Gerncia de Redes

6 2

Figura 6.11 Formato de PDUs do SNMPv2

As PDUs GetRequest e GetNextRequest so idnticas s do SNMPv1 em formato e semntica. A diferena que no SNMPv1 as operaes eram atmicas: ou todos os valores eram retornados ou nenhum valor retornava. No SNMPv2 a lista de variable -bindings preparada, mesmo se valores no podem ser recuperados para todas as variveis. Se uma condio de exceo encontrada para uma varivel ento a varivel retornada com a indicao da exceo em lugar do valor. A verso 1 do SNMP foi originalmente definida para transmisso sobre o UDP e IP. Pesquisas subseqentes exploraram o uso do SNMP com outros protocolos de transporte, incluindo o OSI (RFC 1418), appletalk (RFC 1419) e IPX (RFC 1420). O SNMPv2 formalmente define implementaes sobre outros protocolos de transporte no RFC 1906. apesar de definido para vrios protocolos de transporte, o RFC 1906 sugere que agentes continuem ouvindo o UDP na porta 161 e gerem notificaes na porta 162 do UDP. O grupo de trabalho do IETF responsvel pelo SNMPv2 props dois esquemas de migrao (RFC 1908) do SNMPv1 para o SNMPv2: o gerente bilnge que falaria com o agente SNMP na verso que ele entendesse e o SNMP proxy server que receberia as mensagens SNMPv2 e, atuando como proxy, as transmitiria para o agente como SNMPv1. Algumas modificaes foram introduzidas na MIB internet, conforme ilustrado na figura 7.12: o grupo system do SNMPv2 composto pelos mesmos objetos do SNMPv1 expandindo com a incluso de novos objetos que permitem a uma entidade SNMPv2 agindo como agente descrever seus recursos dinamicamente. Alm disso, o grupo SNMP na verso do SNMPv2 comparado com o originalmente definido da MIBII tem muito menos objetos. A razo que as

estatsticas detalhadas definidas na MIB II no auxiliam na soluo de problemas e adicionam complexidade desnecessria aos agentes. Apesar das vantagens apresentadas pelo SNMPv2 ele apresenta algumas

Gerncia de Redes

6 3

limitaes: pouqussimo utilizado, sua complexidade implica em dificuldades de implementao e no foi bem recebido pela comunidade de gerncia.

Figura 6.12 rvore do SNMPv2

O SNMPv3 Depois de muita controvrsia, o SNMv2 foi liberado como um framework SNMP, SNMPv2C, sem qualquer implementao adicional de segurana. Esta deficincia

foi solucionada no SNMPv3. Os documentos do grupo de trabalho do SNMPv3 no so de fato especificaes completas de um protocolo de gerenciamento de redes. Na verdade estes documentos definem um conjunto de caractersticas de segurana e um framework que poderia ser utilizado com as capacidades funcionais do SNMPv2 ou SNMPv1. (Stallings 1999, Subramanian 2000) Uma das caractersticas chave do SNMPv3 a modularidade da documentao e arquitetura. O projeto da arquitetura integrada das especificaes SNMPv1 e SNMPv2 com as do SNMPv3. Esta integrao permite a continuao de uso do legado de SNMP por agentes e gerentes SNMPv3. A RFC 2571, documento que definiu a arquitetura do SNMPv3, define os seguintes objetivos que guiaram seu desenvolvimento: utilizar o trabalho existente. Os conceitos de segurana do SNMPv3 se baseiam fortemente no SNMPv2u e SNMPv2*; resolver o problema de segurana, principalmente para a operao setrequest, considerada a deficincia mais importante no SNMPv1 e SNMPv2C; ser modular para possibilitar o desenvolvimento de parte da arquitetura, mesmo que o consenso no tenha sido atingido no todo;

Gerncia de Redes

6 4

definir uma arquitetura que permita longevidade ao framework SNMP que j tenha sido definido e que venha a ser definido no futuro; manter o SNMP o mais simples possvel; projetar uma arquitetura modular que permita a implementao sobre diversos ambientes operacionais; e acomodar modelos de segurana alternativos. Um dos principais objetivos do SNMPv3 foi a rea de segurana. Autenticao, privacidade, bem como a autorizao e controle de acesso foram incorporados na especificao SNMPv3. O SNMPv3 projetado para prover segurana conta as seguintes ameaas: modificao da informao uma entidade poderia alterar uma mensagem em trnsito gerada por uma entidade autorizada; masquerade uma entidade no autorizada assumir a identidade de uma entidade autorizada; modificao de stream de mensagem como o SNMP projetado para operar sobre um protocolo no orientado conexo, existe a ameaa de que as mensagens SNMP possam ser reordenadas, atrasadas ou duplicadas;

descoberta uma entidade poderia observar trocas de mensagens entre gerentes e agentes e aprender o valor de objetos gerenciados e eventos notificados. O SNMPv3 no contm mecanismos de segurana contra duas ameaas: denial of service uma pessoa poderia impossibilitar trocas de mensagens entre gerente e agente; anlise de trfego uma pessoa poderia observar o padro de trfego entre gerentes e agentes. A arquitetura SNMP, conforme definida no RFC 2571, consiste de uma coleo de entidades SNMP distribudas e interagindo. Cada entidade implementa uma parte das caractersticas do SNMP e pode atuar como um n agente, um n gerente ou uma combinao dos dois. Cada entidade SNMP consiste de uma coleo de mdulos que interagem entre si para prover servios. A figura 7.13, definida no RFC 2571, mostra detalhes de uma entidade SNMP e seus componentes: dispatcher permite o suporte concorrente a mltiplas verses de mensagens SNMP no engine SNMP; message processing subsystem responsvel por preparar mensagens para envio e extrair dados de mensagens recebidas;

Gerncia de Redes

6 5

security subsystem prov servios de segurana tais como autenticao e privacidade de mensagens. Este subsistema pode conter mltiplos modelos de segurana; access control subsystem prov um conjunto de servios que uma aplicao pode usar para checagem de direitos de acesso; command generator inicializa as PDUs SNMP (get, getnext; getbulk, setrequest) e processa a resposta gerada para uma requisio; command responder recebe as PDUs SNMP destinadas para o sistema local. A aplicao command responder executar a operao apropriada do protocolo, usando o controle de acesso, e gera a mensagem de resposta a ser enviada; notification originator monitora o sistema por eventos e condies particulares e gera mensagens (trap/inform) baseado nos eventos e condies. Devem existir mecanismos para determinar para onde enviar as mensagens, qual verso do SNMP utilizar e quais parmetros de segurana devem ser utilizados; notification receiver ouve as mensagens de notificao e gera mensagens de resposta quando uma mensagem contendo uma PDU inform recebida;

proxy forwarder repassa mensagens SNMP. Sua implementao opcional;

Figura 6.13 Entidade SNMPv3 (RFC 2571) O formato das mensagens SNMPv3 consiste de quatro grupos, mostrados na figura 6.14. O primeiro grupo um campo simples, que o nmero da verso e

Gerncia de Redes

6 6

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

Figura 6.14 Formato de mensagens SNMPv3 O modelo de segurana do SNMPv3 um modelo de segurana baseado em usurios (USM User-based Security Model) que reflete o conceito tradicional de nome de usurios e senhas. A base de segurana no uso de esquemas de autenticao e privacidades so chaves secretas. A chave secreta para autenticao derivada de uma senha escolhida pelo usurio. O controle de acesso trata de quem pode acessar os componentes de gerenciamento das redes e o que pode ser acessado. Nas verses anteriores do SNMP, este tpico era coberto pela poltica de acesso baseada em nomes de comunidade. No SNMPv3, o controle de acesso tornou-se muito mais seguro e flexvel pela introduo do modelo de controle de acesso baseado em viso (VACM View-based Access Control Model). O VCAM define um conjunto de servios que uma aplicao em um agente podem usar para validar comandos de requisio e notificao. O SMON Um switch um dispositivo de rede utilizado para reduzir a conteno e o congestionamento da rede, comumente verificados em redes compartilhadas. Os switches permitem tambm a comutao entre diferentes tecnologias (ethernet, token ring, fast ethernet, etc.). Alm disso, comum a implementao de VLANs (Virtual LAN ou Redes Locais Virtuais) em switches, de tal forma que diferentes redes locais possam coexistir em um mesmo equipamento e uma mesma rede local virtual possa ser implementada por vrios equipamentos, desde que os

Gerncia de Redes

6 7

mesmos obedeam a um padro. Neste sentido foi desenvolvido o padro de identificao de VLAN IEE 802.1Q. A principal diferena entre gerenciar uma rede local compartilhada e uma rede com switches o nvel de granularidade necessrio. Em redes tradicionais, o monitoramento de desempenho, segurana e contabilizao pode ser feito monitorando-se uns poucos pontos na rede, por onde flui o trfego. Em redes que utilizam switches, aumenta enormemente o nmero de pontos, onde se faz necessrio o monitoramento, porque cada switch pode conter vrios segmentos de rede. Para contornar os problemas gerados pela excessiva segmentao de redes baseadas em switch, pela implementao de priorizao de trfego e tambm pela criao de VLANs, foi definido no RFC 2613 um padro que estende o RMON para adequ-lo melhor ao gerenciamento de redes com switch. Este padro foi inicialmente definido pela Lannet e denominado de SMON.

O SMON estende o conceito de fonte de dados, que na MIB II e RMON eram somente instncias das interfaces, acrescentando VLANs e entidades fsicas, conforme definido no RFC 2037, como a sub rvore 22 do RMON. Dessa forma, os grupos host e matrix do RMON e seus similares do RMON 2, devem ser estendidos para suportar as novas fontes de dados definidas no SMON.

6.4. Exerccios
1. A verso 1 do protocolo SNMP (Simple Network Management Protocol) apresenta 5 mensagens: get-request, set-request, get-response, get-next-request e trap, para a comunicao entre o Gerente e o Agente. Explique a funcionalidade de cada uma delas e identifique qual das duas entidades gera a mensagem (se o gerente ou o agente). 2. Descreva uma justificativa para o desenvolvimento de novas verses do SNMP e identifique uma melhoria que foi introduzida no SNMPv2. 3. Qual a vantagem que se obtm quando se utiliza a monitorao remota (RMON) no processo de gerenciamento de redes? 4. Explique a MIB e desenhe um diagrama.

6.5. Referncias Especficas e Links

Extrado do Cap 3 da Apostila de Gerncia de Redes de Computadores e de Telecomunicaes da Profa. Dra. Elizabeth Sueli Especialski

Gerncia de Redes

6 8

7. Gerenciamento de Servios - ITIL

Information Technology Infrastructure Library (ITIL) uma biblioteca de boas prticas (do ingls best practices) desenvolvida no final dos anos 80 pela CCTA (Central Computer and Telecommunications Agency) e atualmente sob custdia da OGC (Office for Government Commerce) da Inglaterra. Criado em 1989. Seu desenvolvimento foi motivado pelo reconhecimento da dependncia de TI pelas organizaes, o que levou ao aumento da necessidade de qualidade de servio no setor. O ITIL se tornou a base padro para a norma BS 15000, que se tornou um anexo da norma ISO 20000. O ITIL um conjunto de livros que busca promover a gesto com foco no cliente e

na qualidade dos servios de tecnologia da informao (TI). O ITIL enderea estruturas de processos para a gesto de uma organizao de TI apresentando um conjunto compreensivo de processos e procedimentos gerenciais organizados em disciplinas com os quais uma organizao pode fazer sua gesto ttica e operacional em vista de alcanar o alinhamento estratgico com os negcios. Os objetivos do ITIL so: Guiar a gesto estratgica, ttica e operacional da infra-estrutura de TI; Melhorar a eficincia; Reduzir riscos; Prover compatibilidade com os requerimentos da ISO9001. As melhores prticas do ITIL cobrem cinco processos que suportam os servios: Gesto de incidentes; Gesto de problemas; Gesto de mudanas; Gesto de configuraes; Gesto de fornecimento. O ITIL tambm inclui cinco processos de fornecimento de servio: 1) Gesto de capacidade; 2) Gesto financeira; 3) Gesto de disponibilidade;

Gerncia de Redes

6 9

4) Gesto de nvel de servio; 5) Gesto de continuidade de servios de TI. O ITIL viabiliza um vocabulrio comum compartilhado pelos profissionais de TI das empresas usurias e dos fornecedores de software. Isso reduz confuses, aumenta o entendimento e aperfeioa a comunicao entre eles. As equipes e gerentes passam a entender o funcionamento dos processos de trabalho de servios de TI a partir de uma mesma fonte. Em meados de 1990, a ITIL foi reconhecida como um "padro de facto" (expresso

de origem latina que significa "na prtica"), no Gerenciamento de Servios de TI (GSTI) ou IT Service Management (ITSM) como internacionalmente se conhece a denominao. O itSMF o nico frum destinado a profissionais especializados em ITIL totalmente independente e reconhecido mundialmente. Estabelecido no Brasil em Setembro de 2003, o frum nacional itSMF Brasil tem como principal meta consolidar o conhecimento dessas melhores prticas, promover a integrao de profissionais da rea de TI em torno desse tema e auxiliar na criao e reviso de processos voltados Gerncia de Servios de TI. Quando falamos na melhoria da maturidade dos servios prestados, o mais adequado implementarmos na empresa os processos preconizados pelo ITIL (Infrastructure Technology Information Library). Principalmente os processos de Service Support e Service Delivery, que tratam especificamente do gerenciamento dos servios de TI, observando o alinhamento com as perspectivas de negcio e adotando a infra-estrutura adequada para tal. O ITIL nos traz algumas mudanas de paradigma, tais como: faz com que o negcio foque no valor e no no custo; nos faz pensar em toda a cadeia que envolve a prestao de servios (end-to-end service) e no uma viso fragmentada; e internamente transfere o olhar para processos e pessoas e no apenas na tecnologia. Incident Management reduzir o tempo de indisponibilidade dos servios; Problem Management minimizar o impacto no negcio, dos incidentes e problemas causados pelos erros na infra -estrutura de TI e prevenir incidentes recorrentes desses mesmos erros; Configuration Management identificar e controlar os ativos de TI e itens de configurao (CIs) existentes na organizao, estabelecendo o relacionamento dos mesmos aos servios prestados; Change Management minimizar o impacto da mudana, requerida para resoluo do incidente ou problema, mantendo a qualidade dos servios, bem como melhorar a operacionalizao da infra-estrutura;

Gerncia de Redes

7 0

Release Management prevenir a indisponibilidade do servio, garantindo que as instalaes de verses de hardware e software estejam seguras, autorizadas e devidamente testadas. Service Level Management (SLM) garantir o acordo de nvel de servio (SLAs) previamente estabelecido entre o fornecedor e o cliente;

Financial Management for IT Service demonstrar ao cliente o custo real dos servios prestados e gerenci-los de forma profissional; Availability Management garantir a disponibilidade e confiabilidade dos recursos de TI, a fim de assegurar a satisfao do cliente e a reputao; Capacity Management assegurar que a capacidade da infra-estrutura de TI est adequada s demandas do negcio conforme a necessidade e no tempo esperado, observando sempre o gerenciamento do custo envolvido; IT Service Continuity management (ITSCM) atender todo o processo de gerenciamento da continuidade do negcio, assegurando que os recursos tcnicos e sistemas de TI sejam recuperados quando requeridos, no tempo desejado.

5.1. Exerccios
1. Qual das seguintes uma atividade do Service Desk? A Funcionar como primeiro ponto de contato do cliente B Investigar a causa das interrupes do servio ao cliente C Procurar a causa de incidentes 2. Qual o papel da ITIL dentro do Gerenciamento de Servios de TI? A Oferecer uma abordagem baseada nos melhores exemplos obtidos na prtica B Servir como um padro internacional para o Gerenciamento de Servios de TI C Servir como modelo padro para a proviso de servios de TI D Servir como quadro terico para o projeto de processos 3. Os gerentes de rede tm cargas de trabalho excessivas e no tm tempo para gerenciar a rede de forma proativa. Um dos fatores que contribuem para essas intensas cargas de trabalho a freqncia com que os usurios contatam esses gerentes diretamente. Qual processo ITIL melhoraria essa situao? A Gerenciamento de Mudanas B Gerenciamento da Configurao C Gerenciamento de Incidentes D Gerenciamento de Problemas

4. Qual tarefa de responsabilidade do Gerenciamento de Problemas? A Coordenar todas as modificaes feitas na infra-estrutura de TI B Registrar incidentes para estudo posterior C Aprovar todas as modificaes feitas na base de dados de Erros Conhecidos D Identificar as necessidades do usurio e modificar a infra-estrutura de TI com base nessas necessidades 5. Os dados no Banco de Dados do Gerenciamento da Configurao (CMDB) somente podem ser modificados aps ter sido concedida uma permisso para modificar a infra-estrutura.
Qual processo concede essa permisso? A Gerenciamento de Mudanas B Gerenciamento da Configurao C Gerenciamento de Incidentes

D Gerenciamento do Nvel de Servio 6. Que conceito faz parte do Gerenciamento de Mudanas?

A Reviso Ps-Implementao B Liberao de Emergncia

C Solicitao de Servio. D Solues provisrias de contorno. 7. Um novo computador em rede instalado para substituir um PC existente. O PC antigo instalado como servidor de impressora da rede local.

Gerncia de Redes

71
maior dos sistemas de informao, uma empresa imobiliria nacional decide que dever haver garantias para a proviso de servios de TI aps uma interrupo no servio. Que processo deve ser implementado para fornecer essa garantia? A Gerenciament o da Disponibilidad e B Gerenciament o da Continuidade dos Servios de TI C Geren ciame nto do Nvel de Servi oD Geren ciame nto dos Servi os 9. Os dados fornecidos administrao financeira de XYZ somente devem poder ser acessados por usurios autorizados. O Gerenciament o de Segurana

Que processo responsvel por registrar essa modificao na Base de Dados do Gerenciamento da Configurao (CMDB)? A Ge ren cia me nto de Mu da na sB Ge ren cia me nto da Co nfig ura o C Ge ren cia me nto de Pro ble ma sD Ge ren cia me nto de Lib era o 8. Devido sua dependncia cada vez

toma medidas para garantir isso. Tomando essas medidas, que aspecto dos dados pode ser garantido?

A Disponibilid
ade

B Integridade C Estabilidad
e

D Confidencia
lidade

10. Um
operador de computador observa que a capacidade de armazenamen to de seu disco logo chegar ao mximo. A qual processo ITIL essa situao dever ser informada?
A Gere ncia ment o da Disp onibil idade B Gere ncia ment o da Capa cidad e C G e r e n c i a m e n t o d e M

u d a n a s D G e r e n c i a m e n t o d e I n c i d e n

t e s

11. Que
atividade de responsabilidad e do Gerenciamento de liberao? A Verificar se h softwares ilegais nos computadores da organizao B Armazenar as verses originais de todo o software autorizado na organizao C Registrar onde cada verso de software est disponvel Respostas 1A2A3C4 C5A6A7B 8 B 9 D 10 D 11 B

Gerncia de Redes

72

8. Acrnimos
ACSE Association Control Service Element AE Application Entity AMF Accounting Metering Function ANSI American National Standards Institute AP Application Process APDU Application Protocol Data Unit API Application Program Interface ARF Alarm Report Function ARR Attibu tes for Repr esent ing Relati onshi ps ASE Appli catio n Servi

ce Elem ent ASK Amplitude Shift Keying ASN.1 Abstract Syntax Notation One ATM Assynchronous Transfer Mode BER Basic Encode Rules CCITT Comit Consultatif International Tlgraphique et Tlphonique CF Control Function CLNS ConncectionLess Network Service CMIP Common Management Information Protocol CMIS Common Management Information Service CMISE Common Management Information Service Element CONS Conncection-Oriented Network Service CRC Cyclic Redundancy Checks CSMA/CD Carrier-Sense Multiple Access with Colision Detection DCN Data Communication Netwok DLPDU Data Link Protocol Data Unit DLSDU Data Link Service Data Unit

Gerncia de Redes

73

DU Data Unit ERMF Event Report Management Function ETSI European Telecommunications Standards Institute FCS Frame Check Sequence FDAU File Access Data Unit FDDI Fiber Distributed Data Interface FDM Frequency Division Multiplexing FSK Frequency Shift Keying FTAM File Transfer, Access and Management HDLC High-Level Data Link Protocol ICI Interface Control Information IDU Interface Data Unit IEC International Electrotechnical Commision IEEE Institute of Electrical and Eletronics Engineers IP Internetwork Protocol ISDN Integrated Service Digital Network ISO International Organization for Standarlization ITU-T

International Telecommunications Union LAN Local Area Netwok LAP Link Access Procedure LAPB Link Access Procedure Balanced LAPD Link Access Procedure D LCF Log Control Function LLC Logical Link Control LME Layer Management Entity MAC Medium Access Control MCF Message Communication Function

Gerncia de Redes

74

MD Mediation Device MIB Management Information Base MIS-User Management Information Service User NE Network Element NRZI Non-Return-to-Zero Inverted NS Network Service NSAP Network Service Access Point OAAC Objects and Attibutes for Access Control OMF Object Management Function OS Operations Systems OSF Operation System Function PDN Public Data Network PDU Protocol Data Unit PI-TPDU Protocol Identification - TPDU PLP Packet Level Protocol PLS Physical Layer Signalling PPDU Presentation Protocol Data Unit PSDU Presentation Service Data Unit PSK Phase Shift Keying

PSPDN Packet Switched PDN PSTN Packet Switched Telephone Network QA Q Adaptor QoS Quality of Service RDSI Rede Digital de Servios Integrados RM-OSI Reference Model for Open Systems Interconnection ROSE Remote Operations Sevice Element RPC Remote Procedure Call

Gerncia de Redes

75

RTSE Reliable Transfer Service Element SAP Service Access Point SAR Sistema de Arquivo Real SARF Security Alarm Reporting Function SATF Secutity Audit Trail Function SA V Sist em a de Arq uivo Virt ual SD U Ser vice Dat a Unit SF Summarization Function SMAE Systems Management Application Entity SMASE System Management

Application Service Element SMFA System Management Functional Areas SMTP Simple Mail Transfer Protocol SNMP Simple Network Management Protocol SSCC Signalling System Common Channel STMF State Management Function TCP Transport Control Protocol TMF Test Management Function TMN Telecommunications Management Network TPDU Transport Protocol Data Unit UDP User Datagram Protocol WAN Wide Area Network WMF Workload Management Function

Gerncia de Redes

9. Referncias

[1] SUBRAMANIAN, Mani. Network management: principles and practice. Reading, MA: AddisonWesley, c2000. 644p. ISBN 0201357429 [2] STALLINGS, William. SNMP, SNMPv2, SNMPv3, and RMON 1 and 2. 3. ed. Boston: Addison-Wesley, 2005. 619 p. ISBN 0201485346 [3] KUROSE, James F.; ROSS, Keith W., Computer networking: a top-down approach featuring the internet. Boston: AddisonWesley, 2001. 712p. ISBN 0201477114 [4] BLUM, Richard. Network Performance Open Source Toolkit. Indianapolis: Wiley, 2003. ISBN 0-471-43301-2. [6] CLEMM, Alexander. Network Management Fundamentals. Indianpolis: Cisco Press, 2007. ISBN 1587201372 [6] PSCHVOSNE, Marcio. Anlise de Ferramentas Gratuitas para Medio de Desempenho de Conexes Banda Larga: Aplicao em ADSL. 2008. 74 f. Monografia (Trabalho de Concluso de Curso Superior de Engenharia em Telecomunicaes) Universidade do Contestado, Canoinhas, 2008.

9.1. Links
Tutorial on Internet Monitoring & PingER at SLAC http://www.slac.stanford.edu/c omp/net/wan-mon/tutorial.html

IETF Home Page: http://www.ietf.org rk_Management_Area IETF MIB Modules: http://www.simpletimes.org/pub/simpletimes/html/ Enterprise specific MIBs (The SimpleWeb) http://wwwsnmp.cs.utwente.nl/ ietf/enterprise.html RFC Editor: http://www.isi.edu/rfceditor/overview.html SunNet Manager:http://www.sun.com/s unsoft/solstice/net_mgt.html SystemView http://www.software.ibm.com/s ysman/technology/ http://www.software.ibm.com/s ysman/technology/snmpv2wp. html IBM NetView for Windows Version 2

Gerncia de Redes

77

http:// www. raleig h.ibm .com/ nvm/ nvmo ver.ht ml HpOpen view http:// www.i notec h.co m/sa mple/ index. html http://hpcc998.external .hp.com:80/nsmd/ov/rp m/novntpr.htm http:// hpcc998.external.hp.co m:80/nsmd/ov/whatiso v/wnm.html POLYCENTER

Manager on Netview (DEC) http://www.networks.digital.co m/npb/html/products_guide/pol yntvw.html Transcend (3COM) http://www.3com.com/0files/pr oducts/dsheets/tnmunix.html http://www.3com.com/0files/pr oducts/dsheets/400195.html CiscoWorks (Cisco) http://www.cisco.com/warp/pub lic/734/cworks/index.html

S p e c t r u m

( C a b l e t

r o n )

h t t p : / / w w w . c t r o n . c o m / s p e

c t r u m /

Patrol (BMC) Gerencia aplicaes HTTP, NFS, etc http://www. bmc.com/pr oducts/pat/i nternet/inde x.html Whats UP (sistema monitor de redes -Win95) http://www.i pswitch.co m/pd_whats up.html HNMS (Sistem a de

Gerenci amento) http://co gnac.co smic.ug a.edu/p ub/HN MS.htm l Netscar f (ferram enta de monitor ao de trfego) http://ni c.merit. edu/~ne tscarf/pr oposal. html