UNIVERSIDADE FEDERAL DE SANTA CATARINA
GRADUAC
¸ ˜
AO EM CI ˆ
ENCIA DA COMPUTAC
¸ ˜
AO
Daniel Moro de Andrade
Proposta de um Framework para Desenvolvimento de
Aplicac¸˜oes de Gerˆencia de Redes
Trabalho de Conclus˜ao de Curso submetido `a Universidade Federal de Santa Ca-tarina como parte dos requisitos para a obtenc¸˜ao do grau de Bacharel em Ciˆencia da Computac¸˜ao.
Prof. Lu´ıs Cl´audio Gubert, M. Sc (Orientador)
gubert@urisan.tche.brAplicac¸˜oes de Gerˆencia de Redes
Daniel Moro de Andrade
Este Trabalho de Conclus˜ao de Curso foi julgado adequado para a obtenc¸˜ao do t´ıtulo de Bacharel em Ciˆencia da Computac¸˜ao.
Prof. Jos´e Mazzucco J´unior, D. Sc Coordenador do Curso
mazza@inf.ufsc.br
Banca Examinadora
Prof. Lu´ıs Cl´audio Gubert, M. Sc (Orientador) gubert@urisan.tche.br
Prof. Carlos Becker Westphall, D. Sc (Co-orientador) westphal@lrg.ufsc.br
Prof. Vitorio Bruno Mazzola, D. Sc mazzola@inf.ufsc.br
Prof. Ricardo Pereira e Silva, D. Sc ricardo@inf.ufsc.br
iii
“Good frameworks are usually the result of many design interactions and a lot of hard work”. Wirfs-Brock and Johnson, 1990
Este trabalho ´e dedicado a minha fam´ılia e amigos que sempre estiveram ao meu lado, me proporcionando boas condic¸˜oes de desenvolvimento e apoio.
Agradecimentos
Agradec¸o principalmente aos meus Pais, pelo investimento, carinho, compreens˜ao e amor a mim conferidos nestes ´arduos anos de curso, sem vocˆes nada disso seria poss´ıvel.
Agradec¸o o apoio dado por todos da minha fam´ılia, principalmente pelo apoio da minha av´o Irma e do meu avˆo Jo˜ao, o seu Joanim, que sempre me dava forc¸as para continuar e sempre quis me ver formado. Pena que o destino n˜ao o deixou me ver na situac¸˜ao que me encontro hoje.
Agradec¸o ao meu Orientador, Professor Lu´ıs Cl´audio Gubert, pelo exem-plo profissional, pela paciˆencia e acima de tudo pelo amigo que tem sido. Apesar da grande distˆancia, sua orientac¸˜ao n˜ao deixou nada a desejar.
Agradec¸o ao meu Co-orientador, Professor Carlos Becker Westphall, por ter acreditado na proposta do trabalho e ter aceito ser respons´avel pelo projeto.
Agradec¸o aos Professores Vitorio Bruno Mazzola e Ricardo Pereira e Silva, por terem aceitado serem membros da banca e por sanarem algumas das muitas d´uvidas que tive quando estava desenvolvendo este trabalho.
Agradec¸o a futura Mestre Lisiane C´ezar de Oliveira, que muito me ajudou a estruturar bem este trabalho, assim como toda a ajuda em desvendar alguns mist´erios do LATEX. Como diz o ditado: ”Por tr´as de um grande homem h´a uma grande
mulher..”, poderia dizer que por tr´as do meu grande Orientador, tamb´em havia uma grande mulher.
Agradec¸o a Universidade Federal de Santa Catarina, em particular ao Departamento de Inform´atica e Estat´ıstica, pelo suporte oferecido para minha formac¸˜ao
acadˆemica.
Agradec¸o a secret´aria do Curso de Ciˆencias da Computac¸˜ao da UFSC, Elizabeth Chaves de Souza Ulbrich, a Beth, por n˜ao ter medido esforc¸os em resolver os problemas que surgiram durante minha vida acadˆemica.
Agradec¸o aos meus professores, pelo conhecimento a mim transmitido e pelas relac¸˜oes de amizade que acabaram sendo criadas.
Agradec¸o aos meus colegas de faculdade, principalmente aos ilustres membros da turma CCO/002. Paulo Cesar, Gabriel Beletti, Ciro, Thaiza, Maria Tereza (TeTˆe), Rafael Gaebler (Paran´a), ´Italo (Bahiano), Augusto Castoldi, Ademir (Chicaum), Thiago Ribeiro (Tsiago), Geraldo, Tales (Panxacon), Alex Zis (BeiSSo), Helion (Pacato), Michel Durante (Miguelito), Sandra e outros, obrigado pelos momentos de alegria, de pura curtic¸˜ao, de adrenalina e de festa. Sempre estar˜ao em meu corac¸˜ao e far˜ao parte das minhas lembranc¸as.
Agradec¸o aos amigos de fora da faculdade pelo apoio, forc¸a a motivac¸˜ao. Robson (Robinho), Daniel (chooper), Gilberto (Giba), valeu a forc¸a!
Agradec¸o a minha namorada por ter me compreendido e me ajudado em momentos dif´ıceis.
Agradec¸o a todos que por algum motivo participaram da minha vida durante esses quatro anos de Faculdade.
Agradec¸o a Deus, por poder estar aqui...
Agradec¸o, por ´ultimo, as mulheres... Afinal, o que seria o mundo se n˜ao houvessem as mulheres para torn´a-lo t˜ao bom de se viver!
Sum´ario
Lista de Figuras x
Lista de Siglas e Abreviaturas xii
Resumo xiv
Abstract xvi
1 Introduc¸˜ao 1
1.1 Justificativas . . . 2
1.2 Objetivos . . . 3
1.3 Estrutura dos Cap´ıtulos do Trabalho . . . 4
2 Gerˆencia de Redes de Computadores 5 2.1 Paradigma Gerente - Agente . . . 7
2.2 Areas de Gerenciamento de Redes . . . .´ 8
2.3 Protocolos de Gerenciamento . . . 9
2.3.1 SNMP . . . 10
2.3.2 CMIP . . . 11
2.4 Padr˜oes do Modelo de Referˆencia OSI da ISO . . . 12
2.5 Arquiteturas de Gerenciamento . . . 12
2.6 Estrutura e Identificac¸˜ao da Informac¸˜ao de Gerenciamento . . . 15
2.7 Base de Informac¸˜ao Gerencial (MIB) . . . 16
2.8.1 Operac¸˜oes Orientadas a Atributos . . . 18
2.8.2 Operac¸˜oes sobre Objetos Gerenciados como um Todo . . . 20
2.9 Conclus˜ao . . . 20
3 Multicast 22 3.1 IP Multicast . . . 23
3.2 Vantagens Uso Multicast . . . 26
3.3 Protocolos . . . 28
3.3.1 Protocolos de Roteamento Multicast (Modo Denso) . . . 28
3.3.2 Protocolos de n´ıveis superiores (Modo Esparso) . . . 32
3.4 Gerˆencia Multicast . . . 33
3.5 Conclus˜ao . . . 34
4 Frameworks 36 4.1 Caracter´ısticas B´asicas e Qualidades de Frameworks . . . 38
4.2 Diferenc¸as entre um Framework e uma Biblioteca de Classes Orientada a Objetos. . . 40
4.3 Padr˜oes de Projeto (Design Patterns) . . . 43
4.3.1 Definic¸˜ao . . . 45
4.3.2 Elementos de um Pattern . . . 46
4.3.3 Classificac¸˜ao dos Design Patterns . . . 46
4.4 Diferenc¸as entre Frameworks e Design Patterns (Padr˜oes de Projeto) . . . 47
4.5 Vantagens e Desvantagens do uso de Frameworks . . . 47
4.6 Classificac¸˜ao de Frameworks . . . 48
4.7 Conclus˜ao . . . 50
5 Frameworks para Web 52 5.1 Frameworks e Web . . . 52
5.2 Conceito de Gerˆencia via Web . . . 54
5.3 Frameworks de Gerˆencia via Web . . . 56
ix
5.3.2 Proxy . . . 58
5.3.3 Gateway . . . 59
5.4 Benef´ıcios da Gerˆencia via Web . . . 59
5.5 Conclus˜ao . . . 61
6 Proposta de um Framework para Gerenciamento de Redes 62 6.1 A implementac¸˜ao do Framework Proposto . . . 63
6.2 As Classes . . . 69
6.3 Aspectos do Framework . . . 73
6.4 Estrutura do Framework . . . 74
6.5 Validac¸˜ao do Framework Proposto . . . 75
6.5.1 Aplicac¸˜oes Propostas . . . 76 6.6 Conclus˜ao . . . 84 7 Conclus˜ao 86 7.1 Trabalhos Futuros . . . 87 8 Anexo A 89 8.1 Classe FWAgente . . . 89 8.2 Classe FWGerente . . . 100 8.3 Classe FWGrafico . . . 110 8.4 Classe FWRelatorio . . . 112 8.5 Classe FWProcessamento . . . 113 8.6 Classe FWMain . . . 114 Referˆencias Bibliogr´aficas 116
Lista de Figuras
2.1 Modelo Gerente - Agente[ARA 02] . . . 7
2.2 Estrutura de Acesso . . . 16
3.1 Comparativo entre Redes Unicast e Multicast [MEL 96] . . . 25
3.2 Classe D de enderec¸amento IP [MEL 96] . . . 25
3.3 Comunicac¸˜ao tradicional para m´ultiplos hosts [MEL 96] . . . 26
3.4 Comunicac¸˜ao entre um grupo de hosts utilizando difus˜ao seletiva [MEL 96] 27 4.1 Funcionalidades Comuns de Frameworks[SAU 02] . . . 37
4.2 Diferenc¸a entre Frameworks e Bibliotecas [SAU 02] . . . 41
4.3 Framework chamando o c´odigo da aplicac¸˜ao[SAU 02] . . . 42
4.4 Lista de diferenc¸as entre Frameworks e Bibliotecas de Classes . . . 42
4.5 Framework Horizontal[SAU 02] . . . 50
4.6 Framework Vertical[SAU 02] . . . 51
5.1 Modelo Gen´erico de Gerˆencia via Web[CAR 00] . . . 56
5.2 Modelo de Framework Nativo[CAR 00] . . . 57
5.3 Modelo de Framework Proxy[CAR 00] . . . 58
5.4 Modelo de Framework Gateway[CAR 00] . . . 59
6.1 Classe FWGerente . . . 64
6.2 Classe FWAgente . . . 65
6.3 Diagrama de classes do framework proposto . . . 67
xi
6.5 Estrutura do framework proposto . . . 74 6.6 Diagrama de Classes da Aplicac¸˜ao de Gerenciamento de Tr´afego . . . 77 6.7 Diagrama de Sequˆencia N´umero 1 da Aplicac¸˜ao de Gerenciamento de
Tr´afego . . . 78 6.8 Diagrama de Sequˆencia N´umero 2 da Aplicac¸˜ao de Gerenciamento de
Tr´afego . . . 79 6.9 Diagrama de Classes da Aplicac¸˜ao de Gerenciamento de Grupos Multicast 80 6.10 Diagrama de Sequˆencia N´umero 1 da Aplicac¸˜ao de Gerenciamento de
Grupos Multicast . . . 81 6.11 Diagrama de Sequˆencia N´umero 2 da Aplicac¸˜ao de Gerenciamento de
Grupos Multicast . . . 82 6.12 Diagrama de Classes da Aplicac¸˜ao de Gerenciamento de Configurac¸˜ao de
Redes . . . 83 6.13 Diagrama de Sequˆencia da Aplicac¸˜ao de Gerenciamento Configurac¸˜ao de
Lista de Siglas e Abreviaturas
API - Application Programming Interface ASN.1 - Abstract Syntax Notation One
CASE - Computer Aided Software Engineering CGI - Common Gateway Interface
CMIP - Common Management Information Protocol CMIS - Common Management Information Service CORBA - Common Object Request Broker Architecture CPU - Central Processing Unit
DME - Distributed Management Environment DVMRP - Distance Vector Multicasting Routing FDDI - Fiber Distributed Data Interface
FTP - File Transfer Protocol GUI - Graphical User Interface
HTML - HyperText Markup Language HTTP - HyperText Transfer Protocol IETF - Internet Engineering Task Force IGMP - Internet Group Management Protocol IP - Internet Protocol
IRC - Internet Relay Chat
ISO - International Organization for Standardization JSP - Java Server Pages
xiii
MBONE - Multicast Backbone MIB - Management Information Base
MIME - Multipurpose Internet Mail Extensions MOSPF - Multicast Open Shortest Path First NNTP - Network News Transfer Protocol NMS - Network Management System NSAPI - Netscape Server API
OO - Orientado a Objetos
OSF - Open Software Foundation OSI - Open System Interconnection OSPF - Open Shortest Path First PIM - Protocol Independent Multicast RFC - Request For Comments
RIP - Routing Information Protocol RPC - Remote Procedure Call RTP - Real Time Protocol RTCP - RTP Control Protocol
SMI - Structure Management Information SMTP - Simple Mail Transfer Protocol
SNMP - Simple Network Management Protocol TCP - Transmission Control Protocol
ToS - Type of Service
UDP - User Datagram Protocol UML - Unified Modeling Language URL - Universal Resource Locator
VRML - Virtual Reality Modeling Language WWW - World Wide Web
Resumo
O presente trabalho descreve a abordagem de frameworks orientados a objetos no desenvolvimento de software bem como a importˆancia da utilizac¸˜ao de padr˜oes de projetos no desenvolvimento de frameworks. Este ir´a definir o que ´e um framework orientado a objetos, suas principais caracter´ısticas, os benef´ıcios que esta abordagem ofe-rece, o que s˜ao padr˜oes de projetos e os benef´ıcios de sua utilizac¸˜ao.
Este trabalho tamb´em se reserva a uma explicac¸˜ao sobre v´arios concei-tos da ´area de gerˆencia de redes, assim como uma explicac¸˜ao sobre o tipo espec´ıfico de redes usado, o Multicast.
A finalidade de um framework orientado a objeto ´e reutilizar c´odigo e projeto. Para que isto seja poss´ıvel, o framework deve ser t˜ao flex´ıvel e extens´ıvel quanto poss´ıvel para que possa dar suporte ao desenvolvimento de diferentes aplicac¸˜oes bem como evoluir `a medida que as aplicac¸˜oes desenvolvidas sob o framework evoluem. Neste contexto a utilizac¸˜ao de padr˜oes de projetos torna-se de suma importˆancia. Um framework projetado atrav´es do uso de padr˜oes de projeto tem muito maior probabilidade de atingir altos n´ıveis de reusabilidade de projeto e c´odigo, comparado com um que n˜ao usa padr˜oes de projeto. Os padr˜oes ajudam a tornar a arquitetura do framework adequada a muitas aplicac¸˜oes diferentes, sem necessidade de reformulac¸˜ao.
O framework proposto no presente trabalho ´e um framework orientado a objetos para o desenvolvimento de aplicac¸˜oes de gerenciamento de redes. Ele ´e um framework de baixa complexidade e alta extensibilidade, o que faz com que sua curva de aprendizado seja pequena e permite ao desenvolvedor agregar facilmente novas funciona-lidades ao framework. Um dos objetivos do framework proposto ´e justamente facilitar o
xv
desenvolvimento de aplicac¸˜oes de gerˆencia de redes para os usu´arios atrav´es das facilida-des permitidas pela internet.
O presente trabalho ir´a descrever como o framework proposto foi estru-turado e projetado, suas principais classes e relacionamentos.
Palavras-chave: frameworks orientados a objetos, padr˜oes de projeto,
Abstract
This work presents the object oriented approach of frameworks for soft-ware development, and also the importance of using design pattners on framework deve-lopment. It will define what is a object oriented framework, its major features, the benefits this approach leads to, what are design patterns and the benefits of their utilization.
This work also is reserved to an explanation on some concepts of the area of network management, as well as an explanation on used the specific type of network, the multicast.
The finality of an object oriented framework is code and project reuse. To make it possible, the framework must be as flexible and extensible as it cans be, so it cans both give support to the development of different applications and evolves while applications developed under the framework evolve. In this context, the utilization of design patterns is turned in a very important matter. One framework projected trough design patterns has much more probability of reaching high levels of code and project reuse, comparing with another one wich do not use design patterns. Design patterns help to turn the framework architecture suitable for many different applications without reformulation.
The framework considered on this work is an object oriented framework to applications of network management development. It is a framework with low comple-xity and high extensibility, what makes its learning curve little and permits the developer to aggregate new functionality to the framework. One of the objectives of framework con-sidered is exactly to facilitate the development of applications of management of networks of the users through the easinesses allowed for the Internet.
xvii
o desenvolvimento de aplicac¸˜oes de gerˆencia de redes para os usu´arios atrav´es das facilidades permitidas pela internet.
This work will describe how the considered framework was structured, its major classes and relations.
Key-words: object-oriented frameworks, design patterns, software reuse,
Cap´ıtulo 1
Introduc¸˜ao
Com a popularizac¸˜ao das redes, surgiram novas aplicac¸˜oes com requi-sitos diferentes de aplicac¸˜oes usuais, como maior largura de banda e menor atraso, al´em disso, aumentou-se consideravelmente o n´umero de perif´ericos dispon´ıveis em uma rede, e que precisam ser monitorados e administrados remotamente. Em vista disso, foram desenvolvidas aplicac¸˜oes de Gerˆencia de Redes.
Entretanto, desenvolver aplicac¸˜oes destinadas ao gerenciamento de re-des n˜ao ´e uma tarefa f´acil[SAM 97]. As plataformas de gerˆencia, APIs (Application Pro-gramming Interfaces) e linguagens de programac¸˜ao dispon´ıveis n˜ao oferecem as devidas abstrac¸˜oes para que um programador possa construir tais aplicac¸˜oes sem que tenha que se envolver com outros detalhes, como por exemplo, estruturas de dados complexas, ca-racter´ısticas pertinentes ao protocolo de gerˆencia utilizado, forma como as informac¸˜oes de gerˆencia est˜ao armazenadas e maneira de ter acesso a elas, entre outras. Tais aspectos est˜ao ligados mais com programac¸˜ao do que propriamente com o dom´ınio do problema [SAN 01].
Assim sendo, ´e importante desenvolver softwares reutiliz´aveis para que com isso haja um aumento tanto de produtividade quanto de qualidade na construc¸˜ao dos mesmos. A meta ´e desenvolver produtos de software possuidores de caracter´ısticas gen´ericas e extens´ıveis para que possam ser reutilizadas na construc¸˜ao de outros produ-tos de software. Com isso o desenvolvedor n˜ao precisa, sempre que deseja fazer uma
2
nova aplicac¸˜ao, comec¸ar do ponto “zero”1. Tendo em m˜aos estas aplicac¸˜oes reutiliz´aveis,
o desenvolvedor apenas teria de fazer as adaptac¸˜oes necess´arias ao caso especifico que estaria desenvolvendo. Com isso, tem-se a vantagem de que o tempo necess´ario para consolidac¸˜ao da aplicac¸˜ao diminua. Outra vantagem seria o fato de, por usar partes de outros programas e estas j´a terem sido testadas, a aplicac¸˜ao possivelmente ter´a um grau maior de confiabilidade.
Uma das t´ecnicas empregadas para a construc¸˜ao de software reutiliz´avel ´e a t´ecnica de framework orientado a objeto (framework Orientado a Objetos [ROB 96]). “Um framework Orientado a Objetos ´e um sistema de software (ou parte dele) que ´e com-posto por um conjunto de classes (concretas e abstratas) que colaboram entre si, de forma
a compor um projeto reutiliz´avel para um dom´ınio de problema espec´ıfico”[ROG 97]. Conseq¨uentemente, um framework nada mais ´e do que uma aplicac¸˜ao “quase completa”, sendo que as partes n˜ao implementadas, o usu´ario preenche de acordo com as necessida-des oriundas de seu projeto.
1.1
Justificativas
Sobre `a utilizac¸˜ao de frameworks, estes est˜ao se tornando muito impor-tantes no processo de desenvolvimento de software. Dentre algumas das mais variadas aplicac¸˜oes de framework podem ser citadas: a construc¸˜ao de aplicac¸˜oes, o projeto de interfaces gr´aficas (GUI - Graphical User Interface), editorac¸˜ao gr´afica, plataformas de gerˆencia de rede, dentre outras [SAN 01].
Em Freire[FRE 00], encontra-se um exemplo de utilizac¸˜ao de framework para a construc¸˜ao de aplicac¸˜oes para Gerˆencia de Falhas em redes de computadores denominado fwGF. O fwGF tem como objetivo prover, ao programador deste tipo de aplicac¸˜oes (o usu´ario do fwGF), transparˆencia de detalhes de mais baixo n´ıvel, ligados `a programac¸˜ao, como por exemplo, estruturas de dados complexas, protocolos de gerˆencia, tratamento de erros, etc. Dessa forma, o programador disp˜oe de abstrac¸˜oes mais
adequa-1Comec¸ar do ponto zero significa comec¸ar um software sem ter base alguma. E comec¸ar desde o´
das para construir aplicac¸˜oes apenas envolvendo-se com o dom´ınio do problema em si, sem se preocupar com os detalhes citados anteriormente
Por outro lado, WebFrameworks [PIN 00], ou seja, um framework vol-tado para web se utiliza de todos os conceitos de construc¸˜ao de frameworks e das facili-dades providas pela www (World Wide Web), proporcionando vantagens inerentes `a esta tecnologia.
O uso da uni˜ao entre frameworks e web traz benef´ıcios. O simples fato de se poder fazer um gerenciamento de modo remoto j´a ´e um deles. Outro benef´ıcio que poderia ser citado ´e o fato de um gerente de rede poder fazer seu pr´oprio programa de gerenciamento atrav´es da web utilizando-se do framework.
Com isso, haveria uma maior liberdade para o gerente da rede. Usu-fruindo de ferramentas pr´oprias e adequadas para a situac¸˜ao de criac¸˜ao de aplicac¸˜oes de gerenciamento de redes, o mesmo poderia obter uma melhor utilizac¸˜ao de tempo para desenvolvimento dessas aplicac¸˜oes.
1.2
Objetivos
O trabalho tem como principais objetivos:
• Estudar os conceitos de gerenciamento de redes, com ˆenfase em gerenciamento via
web;
• Estudar frameworks, suas aplicac¸˜oes e vantagens;
• Verificar a interac¸˜ao entre essas duas tecnologias, procurando novas soluc¸˜oes para
o gerenciamento de redes.
• Propor um framework para desenvolvimento de aplicac¸˜oes de gerenciamento de
4
1.3
Estrutura dos Cap´ıtulos do Trabalho
O trabalho est´a assim estruturado:
No cap´ıtulo 2 apresenta-se uma vis˜ao geral sobre gerenciamento de re-des. Comenta-se sobre protocolos (OSI e SNMP) e sobre quais operac¸˜oes s˜ao feitas quando se gerencia uma rede. Aborda tamb´em a arquitetura de gerenciamento e a estru-tura e identificac¸˜ao da informac¸˜ao de gerenciamento.
No cap´ıtulo 3, discute-se sobre redes multicast. Aborda-se desde suas definic¸˜oes e vantagens at´e os protocolos usados na mesma. Por fim, comenta-se sobre a gerˆencia em redes multicast.
No cap´ıtulo 4, mostra-se informac¸˜oes sobre frameworks. Aborda-se desde os conceitos de framework, at´e suas aplicac¸˜oes, vantagens, desvantagens e classificac¸˜ao. Discuti-se padr˜oes de projeto, tendo-se uma introduc¸˜ao sobre o mesmo, algumas definic¸˜oes, seus elementos e suas classificac¸˜oes. H´a tamb´em algumas comparac¸˜oes que visam um es-clarecimento melhor sobre t´opicos explicados no cap´ıtulo.
No capitulo 5, s˜ao abordados conceitos sobre a Internet e faz-se o elo de ligac¸˜ao entre frameworks, gerenciamento de redes e web. Aborda-se suas facilidades e vantagens.
No cap´ıtulo 6, ´e apresentada a proposta de trabalho, juntamente com seus objetivos e justificativas. Mostra-se a parte de projeto do framework proposto, seus aspectos, algumas poss´ıveis aplicac¸˜oes para sua validac¸˜ao e sua estrutura final.
No cap´ıtulo 7 tˆem-se a conclus˜ao do trabalho realizado.
No cap´ıtulo 8, ´e apresentado como anexos, toda a implementac¸˜ao da proposta do framework atrav´es do seu c´odigo fonte.
Cap´ıtulo 2
Gerˆencia de Redes de Computadores
Atualmente, devido ao fato de as redes de computadores estarem se tor-nando indispens´aveis para as instituic¸˜oes, ´e imprescind´ıvel que se fac¸a um gerenciamento eficiente sobre essas redes, com o intuito de se minimizar a ocorrˆencia de falhas. Por outro lado, com o crescente aumento no tamanho das redes, as soluc¸˜oes de gerˆencia centralizada existentes n˜ao s˜ao escal´aveis para gerenciar estas redes eficientemente.
Uma das principais caracter´ısticas e o principal objetivo de uma rede ´e o compartilhamento de recursos. Consiste na multi-utilizac¸˜ao de perif´ericos, os quais esta-riam dispon´ıveis somente a um computador se n˜ao houvesse uma rede para proporcionar o compartilhamento. Assim, levando-se em conta que as redes crescem muito rapidamente, as mesmas servem como uma ferramenta que oferece recursos e servic¸os permitindo as-sim a interac¸˜ao e um significativo aumento de produtividade aos seus usu´arios. [LOP 02] Levando-se em considerac¸˜ao o fato citado acima, do crescimento f´ısico e do crescimento de uso de redes, torna-se necess´ario uma pol´ıtica para manipular todos esses artefatos de maneira a garantir a utilizac¸˜ao das mesmas. A necessidade de qua-lidade, a diversificac¸˜ao e a complexidade cada vez maior dos servic¸os implica em uma necessidade t˜ao vital quanto o pr´oprio servic¸o: a sua gerˆencia.
Gerenciar uma rede n˜ao ´e uma tarefa simples. A complexidade se d´a por conseq¨uˆencia do crescimento acelerado das mesmas, tanto em desempenho quanto em suporte a um grande conjunto de servic¸os. Este conjunto de componentes, juntamente
6
com os problemas associados, somente poder´a ser gerenciado se for bem definida toda uma estrutura a ser seguida. Admitindo-se que as ferramentas para gerˆencia de redes n˜ao abrangem a gama de problemas que possam ocorrer numa rede e que estas nem sempre s˜ao usadas nas organizac¸˜oes que possuem redes, faz-se necess´ario a utilizac¸˜ao de outros mecanismos de gerˆencia para que com isso possa suprir-se suas carˆencias mais evidentes [SAM 97].
As informac¸˜oes que circulam em uma rede de computadores devem ser transportadas de modo confi´avel e r´apido. Para tanto ´e necess´ario e importante que os dados e os elementos f´ısicos da rede (hubs1, switchs2, por exemplo) estejam sob monitorac¸˜ao, de maneira que os problemas que possam surgir sejam solucionados rapi-damente. N˜ao havendo essa monitorac¸˜ao, ou seja, uma rede sem mecanismo de gerˆencia, poder´a apresentar problemas como recursos mal utilizados ou sobrecarregados, congesti-onamento do tr´afego, problemas com seguranc¸a, entre outros.
O objetivo da Gerˆencia de Redes ´e monitorar e controlar os elemen-tos da rede (sejam eles f´ısicos ou l´ogicos), assegurando um certo n´ıvel de qualidade de servic¸o. Para realizar esta tarefa, os gerentes de redes s˜ao geralmente auxiliados por um sistema de gerˆencia de redes. Este pode ser definido como uma colec¸˜ao de ferramentas integradas para a monitorac¸˜ao e controle da rede, oferecendo uma interface ´unica, com informac¸˜oes sobre a rede e oferecendo tamb´em um conjunto poderoso e amig´avel de co-mandos que s˜ao usados para executar quase todas as tarefas da gerˆencia da rede [LOP 02]. Pode-se dizer que as tarefas b´asicas da gerˆencia s˜ao obter informac¸˜oes da rede, a partir disso tratar estas informac¸˜oes, possibilitando assim um diagn´ostico e propor poss´ıveis soluc¸˜oes dos problemas. Para que sejam cumpridos todos estes objeti-vos, as func¸˜oes de gerˆencia devem ser embutidas nos diversos componentes de uma rede, possibilitando assim, a descoberta, a prevenc¸˜ao e reac¸˜ao a problemas.
1E um ponto comum de conex˜ao para dispositivos numa rede. Hubs s˜ao geralmente usados para conectar´
segmentos de uma LAN. Um hub cont´em m´ultiplas portas. Quando um pacote chega a uma das portas, ele ´e copiado pra outras portas e assim todos os segmentos da rede podem ver todos os pacotes[WEB 04]
2Em redes, switch ´e um dispositivo que filtra e encaminha pacotes entre segmentos de redes
Neste cap´ıtulo s˜ao apresentados conceitos sobre gerenciamento de re-des. Na sec¸˜ao 2.1 aborda o paradigma Gerente - Agente, na sec¸˜ao 2.2 comenta sobre as ´areas de gerenciamento de redes, a sec¸˜ao 2.3 aborda os protocolos de gerenciamento, na sec¸˜ao 2.4 s˜ao apresentados os Padr˜oes do Modelo de Referˆencia OSI da ISO.
J´a na sec¸˜ao 2.5 est˜ao t´opicos sobre Arquiteturas de Gerenciamento, na sec¸˜ao 2.6 s˜ao mostradas a Estrutura e Identificac¸˜ao da Informac¸˜ao de Gerenciamento. Na sec¸˜ao 2.7 s˜ao abordados conceitos de MIB’s e por ´ultimo na sec¸˜ao 2.8 ser˜ao abordados t´opicos sobre operac¸˜oes de gerenciamento.
2.1
Paradigma Gerente - Agente
Devido `a natureza distribu´ıda dos recursos (elementos da rede) a serem gerenciados, a gerˆencia de redes ´e uma aplicac¸˜ao distribu´ıda. Os processos usados nas ati-vidades de gerˆencia destes recursos distribu´ıdos s˜ao classificados como processo Gerente e processo Agente [GUB 02].
Figura 2.1: Modelo Gerente - Agente[ARA 02]
Os processos gerente s˜ao os processos que s˜ao executados nas m´aquinas que gerenciam as redes. Ele possui a tarefa de gerenciar, enviando comandos, os objetos gerenci´aveis (Agentes), podendo receber dos mesmos, respostas aos comandos enviados.
8
Tal interac¸˜ao pode ser vista na Figura 2.1.
Os processos agentes s˜ao m´odulos de software que compilam informac¸˜oes no dispositivo gerenciado, armazenando-as em bancos de dados de gerenciamento e ca-pacitando o dispositivo, reativa ou proativamente, a atuar dentro de um Sistema de Ge-renciamento de Redes. Eles executam os comandos enviados pelo gerente e mandam informac¸˜oes, de acordo com cada solicitac¸˜ao, para os mesmos processos gerentes.
2.2
Areas de Gerenciamento de Redes
´
Os requisitos que s˜ao estabelecidos pelos usu´arios do sistema de geren-ciamento OSI e que devem ser satisfeitos pelas atividades de gerengeren-ciamento de sistema, s˜ao classificados em cinco ´areas funcionais: Gerenciamento de Configurac¸˜ao, Gerencia-mento de Falhas, GerenciaGerencia-mento de Desempenho, GerenciaGerencia-mento de Seguranc¸a e Geren-ciamento de Contabilizac¸˜ao. Dentro de cada uma destas ´areas existem func¸˜oes de geren-ciamento espec´ıficas, estas fornecidas por mecanismos de gerengeren-ciamento OSI [CAR 93]. O Gerenciamento de Configurac¸˜ao refere-se aos ajustes e mudanc¸as das configurac¸˜oes das redes e seus componentes (conex˜oes l´ogicas e f´ısicas entre dispositi-vos), diz respeito tamb´em ao modo de operac¸˜ao de cada sistema, podendo ser separada em trˆes aspectos: Inventory, Configuration e Provisioning.
O Gerenciamento de Falhas cuida da detecc¸˜ao e isolamento dos problemas que causam falhas na rede. Um Sistema de Gerenciamento de Redes (NMS -Network Management System) constantemente monitora a rede e exibe em tempo real os alarmes. As falhas s˜ao eliminadas t˜ao cedo quanto poss´ıvel, podendo, para isso, mudar a configurac¸˜ao da rede que ´e responsabilidade do gerenciamento de configurac¸˜ao. V´arias falhas podem ser resolvidas automaticamente atrav´es da troca ou reparo de componentes. O Gerenciamento de Desempenho preocupa-se com o comportamento da rede. Um sistema monitor mostra o estado da rede, medindo o tr´afego e estat´ısticas que refletem o desempenho da rede. As estat´ısticas incluem os tr´afego de dados, atraso na rede, dentre outras. Essas podem ajudar nas decis˜oes das pol´ıticas usadas que afetam o gerenciamento das aplicac¸˜oes como email, transferˆencia de arquivos, tr´afego da web,
entre outros. Dados hist´oricos podem ser importantes.
O Gerenciamento de Seguranc¸a envolve uma gama de aspectos referen-tes a seguranc¸a. Ele engloba seguranc¸a nas comunicac¸˜oes da rede, acesso a recursos da mesma, criar e examinar e manter “log files”3, etc. Existem firewalls4 que protegem as redes corporativas e seus recursos de pessoas n˜ao autorizadas e programas contendo v´ırus. A criptografia possui um papel fundamental no gerenciamento de seguranc¸a. Importante em sistemas abertos e essencial a hosts conectados a internet.
O Gerenciamento de Contabilizac¸˜ao controla os privil´egios dos usu´arios da rede, bem como administra os custos, estabelecendo m´etricas para estabelecer o uso de recursos e servic¸os.
2.3
Protocolos de Gerenciamento
Um protocolo ´e uma linguagem para a comunicac¸˜ao entre dois compu-tadores distantes geograficamente, permitindo a troca de mensagens entre os dois com-putadores, para a transmiss˜ao de dados [SZT 96]. Um protocolo ´e um conjunto de regras sobre o modo como se dar´a a comunicac¸˜ao entre as partes envolvidas [TAN 97].
Apesar de existirem alguns protocolos desenvolvidos para gerencia-mento de redes, dar-se-´a ˆenfase no protocolo padronizado na internet, o SNMP. Este, por sua vez, tem se firmado como soluc¸˜ao para gerenciamento de grandes redes, pois com o aumento de aplicac¸˜oes rodando em ambientes distribu´ıdos, o seu uso tornou-se indispens´avel[CAR 93].
No modelo tradicional, as redes s˜ao compostas por m´ultiplos compo-nentes. Al´em das m´aquinas nas quais as aplicac¸˜oes est˜ao efetivamente executando,
rote-3Um arquivo que lista ac¸˜oes ocorridas. Por exemplo, servidores web mant´em log files listando todas as
requisic¸˜oes feitas ao servidor. Com ferramentas de an´alise de log files, ´e poss´ıvel ter uma boa id´eia de onde os visitante vˆem, com que freq¨uˆencia eles retornam e como navegam atrav´e do site[WEB 04].
4Firewall ´e um sistema ou grupo de sistemas, que reforc¸a a pol´ıtica de seguranc¸a entre uma rede interna
10
adores, bridges5, gateways6e modems s˜ao componentes importantes. Sua importˆancia se
d´a pelo fato deles fazerem parte da comunicac¸˜ao entre as m´aquinas da rede. No tocante ao software, v´arios outros componentes est˜ao envolvidos, especialmente em ambientes multifornecedores e, em alguns casos, seria extremamente confort´avel que componentes de software pudessem ser gerenciados [SZT 96]. A tarefa de gerenciamento deve basear-se na combinac¸˜ao entre entidades chamadas de gerentes e agentes. No que diz respeito a um agente, este ´e constitu´ıdo por uma func¸˜ao de gerenciamento - contadores, rotinas de teste, temporizadores, dentre outros - que permite o controle e gerenciamento do objeto gerenciado. no caso da instrumentac¸˜ao de gerenciamento, se associa a uma estrutura par-ticular de gerenciamento, especificando as regras empregadas para definir a informac¸˜ao referente a um objeto referenciado, e com isso se permite que este possa ser monitorado e gerenciado.
A SMI (Structure Management Information), como ´e chamada esta instrumentac¸˜ao, ´e an´aloga `a linguagem de programac¸˜ao usada para construir estruturas de dados e permitir operac¸˜oes que possam ser executadas sobre essas estruturas. A combinac¸˜ao de uma SMI com um protocolo particular ´e denominada framework [SZT 96].
2.3.1
SNMP
Este protocolo tem como premissa `a flexibilidade e a facilidade de implementac¸˜ao, tamb´em em relac¸˜ao aos produtos futuros. Sua especificac¸˜ao est´a contida no RFC 1157
[FAQ 04a].
O SNMP ´e um protocolo de gerˆencia definido a n´ıvel de aplicac¸˜ao, ´e utilizado para obter informac¸˜oes de servidores SNMP - agentes espalhados em uma rede baseada na pilha de protocolos TCP/IP. Os dados s˜ao obtidos atrav´es de requisic¸˜oes de um gerente a um ou mais agentes utilizando os servic¸os do protocolo de transporte UDP (User Datagram Protocol) para enviar e receber suas mensagens atrav´es da rede. Dentre as vari´aveis que podem ser requisitadas utilizaremos as MIBs podendo fazer parte da MIB
5Um dispositivo que conecta duas redes locais (LANs), ou dois segmentos da mesma LAN que usam o
mesmo protocolo, como a Ethernet ou Token-Ring.[WEB 04]
II, da experimental ou da privada [DIA 02].
O gerenciamento da rede atrav´es do SNMP permite o acompanhamento simples e f´acil do estado, em tempo real, da rede, podendo ser utilizado para gerenciar diferentes tipos de sistemas.
Este gerenciamento ´e conhecido como modelo de gerenciamento SNMP, ou simplesmente, gerenciamento SNMP. Por tanto, o SNMP ´e o nome do protocolo no qual as informac¸˜oes s˜ao trocadas entre a MIB e a aplicac¸˜ao de gerˆencia como tamb´em ´e o nome deste modelo de gerˆencia [ITW 04].
Os comandos s˜ao limitados e baseados no mecanismo de busca/alterac¸˜ao. No mecanismo de busca/alterac¸˜ao est˜ao dispon´ıveis as operac¸˜oes de alterac¸˜ao de um valor de um objeto, de obtenc¸˜ao dos valores de um objeto e suas variac¸˜oes.
A utilizac¸˜ao de um n´umero limitado de operac¸˜oes, baseadas em um mecanismo de busca/alterac¸˜ao, torna o protocolo de f´acil implementac¸˜ao, simples, est´avel e flex´ıvel. Como conseq¨uˆencia reduz o tr´afego de mensagens de gerenciamento atrav´es da rede e permite a introduc¸˜ao de novas caracter´ısticas [STA 99].
O funcionamento do SNMP ´e baseado em dois dispositivos o agente e o gerente. Cada m´aquina gerenciada ´e vista como um conjunto de vari´aveis que represen-tam informac¸˜oes referentes ao seu estado atual, estas informac¸˜oes ficam dispon´ıveis ao gerente atrav´es de consulta e podem ser alteradas por ele. Cada m´aquina gerenciada pelo SNMP deve possuir um agente e uma base de informac¸˜oes MIB [DIA 02].
2.3.2
CMIP
Num ambiente de gerenciamento OSI, usa-se o protocolo CMIP para definir as regras de comunicac¸˜ao entre os processos gerente e agente. O protocolo CMIP implementa as primitivas oferecidas pelo servic¸o de informac¸˜ao de gerenciamento CMIS (Common Management Information Service). Este ambiente tamb´em prop˜oe uma estru-tura de gerenciamento para permitir a definic¸˜ao dos conceitos necess´arios `a construc¸˜ao de classes de objetos gerenciados, os princ´ıpios necess´arios `a nomeac¸˜ao dos objetos e dos seus componentes, e como ´e definido o inter-relacionamento entre os objetos [TAR 95].
12
A ISO especifica o CMIP (Common Management Information Protocol) e o CMIS (Commom Management Information Services) como sendo o protocolo e o servic¸o de gerenciamento de rede do n´ıvel de aplicac¸˜ao do modelo OSI, respectivamente. A utilizac¸˜ao dos padr˜oes da ISO para gerenciamento tˆem sido aplica-dos em boa parte pela OSF, que est´a comprometida, atrav´es do OSF/DME (Open Soft-ware Foundation/Distributed Management Environment), em suportar os padr˜oes OSI de gerenciamento [SZT 96]. A func¸˜ao do DME ´e fornecer facilidades para permitir uma integrac¸˜ao entre o gerenciamento de sistemas em ambientes que n˜ao sejam homogˆeneos, satisfazendo trˆes requisitos b´asicos: interoperabilidade, consistˆencia e flexibilidade.
2.4
Padr˜oes do Modelo de Referˆencia OSI da ISO
Segundo Sztajnberg [SZT 96], para resolver os problemas associados `a gerˆencia em redes, a ISO atrav´es do OSI/MN propˆos trˆes modelos:
• O Modelo Organizacional estabelece a hierarquia entre sistemas de gerˆencia em
um dom´ınio de gerˆencia, dividindo o ambiente a ser gerenciado em v´arios dom´ınios
• O Modelo Informacional define os objetos de gerˆencia, as relac¸˜oes e as operac¸˜oes
sobre esses objetos. Uma MIB ´e necess´aria para armazenar os objetos gerenciados.
• O Modelo Funcional descreve as funcionalidades de gerˆencia: gerˆencia de falhas,
gerˆencia de configurac¸˜ao, gerˆencia de desempenho, gerˆencia de contabilidade e gerˆencia de seguranc¸a.
2.5
Arquiteturas de Gerenciamento
V´arios produtos tˆem surgido com a finalidade de gerenciar a rede, quase que em sua totalidade baseados no padr˜ao SNMP e CMIP.
O CMIP possui recursos de criptografia e autenticac¸˜ao, que permitem uma garantia relativa de seguranc¸a das informac¸˜oes de gerenciamento. Este ´e significa-tivamente mais complexo do que o SNMP. Entretanto, muitas das vantagens oferecidas
por ele serviram de base para inovac¸˜oes propostas nas vers˜oes posteriores `a primeira do SNMP. Contudo, sua complexidade praticamente o inviabiliza como protocolo para ge-renciamento de redes de computadores, o que restringe sua utilizac¸˜ao. Por isto, temos o SNMP implementado na Internet e o CMIP, em algumas aplicac¸˜oes de telefonia, por exemplo [DEL 98].
O sucesso do SNMP baseia-se no fato de ter sido ele o primeiro proto-colo de gerenciamento n˜ao propriet´ario, p´ublico, f´acil de ser implementado e que possi-bilita o gerenciamento efetivo de ambientes heterogˆeneos. Geralmente, estes produtos de gerenciamento de redes incorporam func¸˜oes gr´aficas para o gerente da rede [SZT 96].
No gerenciamento SNMP, adiciona-se um componente ao hardware (ou software) o qual ser´a controlado, sendo que este recebe o nome de Agente. Este agente tem como tarefa coletar dados dos dispositivos e armazenar os mesmos em uma estrutura padr˜ao denominada MIB. Al´em desta base de dados, normalmente ´e desenvolvido um software aplicativo que tem a habilidade de sumarizar estas informac¸˜oes e exib´ı-las nas estac¸˜oes encarregadas das tarefas de monitorar a rede chamado Gerente.
Basicamente, s˜ao definidas quatro tipos de MIBs: MIB I, MIB II, MIB experimental e MIB privada [SZT 96]. As MIBs do tipo I e II fornecem informac¸˜oes mais gerais sobre o equipamento que est´a sendo gerenciado, n˜ao levando em conta as caracter´ısticas espec´ıficas deste equipamento. A MIB II, que nada mais ´e do que uma evoluc¸˜ao da MIB I, e assim introduziu novas informac¸˜oes al´em daquelas encontradas na MIB I.
Portanto, atrav´es das MIBs do tipo I e II ´e poss´ıvel obter informac¸˜oes como tipo e status de interface (Ethernet, FDDI, Token-Ring), n´umero de pacotes trans-mitidos, n´umero de pacotes com erro, informac¸˜oes de protocolos de transmiss˜ao etc [SAM 97].
As MIBs experimentais s˜ao aquelas que est˜ao em fase de testes, tendo uma perspectiva de serem adicionadas ao padr˜ao e que, em geral, fornecem caracter´ısticas um tanto quanto mais espec´ıficas sobre a tecnologia dos meios de transmiss˜ao e equipa-mentos empregados.
possi-14
bilitando que detalhes mais minuciosos e espec´ıficos a um determinado equipamento pos-sam ser obtidos. ´E desta forma que se pode obter informac¸˜oes sobre colis˜oes, configurac¸˜ao, swap7de portas, e muitas outras, de um hub, por exemplo. Tamb´em ´e poss´ıvel fazer testes,
reinicializar ou desabilitar uma ou mais portas do hub atrav´es de MIBs propriet´arias. Os pioneiros na implantac¸˜ao dos protocolos SNMP foram os forne-cedores de gateways, bridges e roteadores. Normalmente, o fornecedor desenvolve o agente SNMP e posteriormente desenvolve uma interface para a estac¸˜ao gerente da rede [SZT 96]. Em geral, estes produtos funcionam n˜ao s´o para um, mas para v´arios sistemas operacionais, sendo assim muito comum que estes fornecedores incluam bibliotecas e uti-lit´arios, permitindo assim, a criac¸˜ao de aplicac¸˜oes de gerenciamento com caracter´ısticas espec´ıficas para alguns componentes da rede.
As implementac¸˜oes b´asicas do SNMP permitem monitorar e isolar fa-lhas, enquanto que as aplicac¸˜oes mais sofisticadas permitem gerenciar o desempenho da rede e a configurac¸˜ao da mesma. Estas aplicac¸˜oes, geralmente, possuem incorporadas a si, menus e alarmes. Isso facilita a interac¸˜ao com o profissional que est´a gerenciando a rede [CAR 93].
O esquema dos produtos desenvolvidos com o protocolo SNMP ´e um pouco diferentes dos produtos que utilizam o protocolo CMIP [DEL 98]. Os fornecedores de produtos que utilizam o protocolo CMIP possuem a mentalidade de que os fabricantes possuam algum tipo de gerenciamento em seus equipamentos, assim estas informac¸˜oes podem ser disponibilizadas para um integrador via protocolo CMIP. O conceito de inte-grador foi definido em trˆes n´ıveis: o mais baixo, que cont´em os agentes e os elementos gerenciadores, o intermedi´ario, que consiste em elementos do sistema de gerenciamento, e finalmente o n´ıvel mais alto, que consiste no integrador dos sistemas de gerenciamento [SZT 96].
A maior dificuldade para uma aplicac¸˜ao integradora ´e que nem sempre os fornecedores tˆem as mesmas vari´aveis de gerenciamento e as mesmas operac¸˜oes em seus servidores de objetos.
7Tem como objetivo substituir p´aginas ou segmentos dos dados na mem´oria. Um swap de porta consiste
Na escolha entre um ou outro protocolo de gerenciamento se deve levar em considerac¸˜ao o tipo de rede e os produtos a ela agregados, sendo poss´ıvel o fato de se utilizar de dois protocolos mesclados.
O SNMP e seu Internet Standard Network Management Framework [SOA 95] s˜ao adequados a agentes simples e f´aceis de implementar, enquanto o CMIP e o seu Framework Network Management Forum Release 1.0 [SOA 95] s˜ao adequados para agentes com um ou mais servidores de objetos dentro da modalidade cliente-servidor orientado para objeto, dentre os quais inclui-se o RPC8[TAR 96].
2.6
Estrutura e Identificac¸˜ao da Informac¸˜ao de
Gerenci-amento
Um dos componentes conceituais de importˆancia nos sistemas de ge-renciamento ´e a forma com que as informac¸˜oes sobre os elementos b´asicos que se quer gerenciar s˜ao armazenados [SZT 96]. Tais informac¸˜oes precisam estar dispon´ıveis de forma que seja padronizada, pois assim estando, qualquer aplicac¸˜ao de gerenciamento pode resgat´a-las e torn´a-las ´uteis de alguma forma.
O acesso a objetos gerenciados faz-se via uma informac¸˜ao virtual arma-zenada, denominada Base de Informac¸˜ao Gerencial (Management Information Base) ou MIB. A especificac¸˜ao dos objetos de uma MIB ´e feita usando a Notac¸˜ao Sint´atica Abs-trata (Abstract Syntax Notation One - ASN.1)[TAR 96]. Pode-se ver uma demonstrac¸˜ao desse acesso na Figura 2.2.
ASN.1 ´e uma notac¸˜ao que permite definir tipos de dados simples e com-plexos e especificar valores que estes tipos podem assumir. Os valores que s˜ao transmiti-dos podem ser de diversos tipos. Existem os tipos simples e outros, mais complexos, que
8Abreviac¸˜ao de Remote Procedure Call, um tipo de protocolo que permite que um programa em um
computador execute um programa em um outro computador de usu´ario. Usando o RPC, um desenvolvedor de sistema n˜ao necessita desenvolver procedimentos espec´ıficos para o usu´ario. O programa do cliente emite uma mensagem ao usu´ario com argumentos apropriados e o usu´ario retorna uma mensagem que cont´em os resultados do programa executado[MAR 99]
16
Figura 2.2: Estrutura de Acesso
s˜ao formados de v´arios tipos simples combinados. Cada tipo recebe uma denominac¸˜ao que o distingue, de forma inequ´ıvoca de todos os demais tipos. Algumas das maneiras de definir novos tipos s˜ao uma seq¨uˆencia (ordenada) de tipos existentes, uma seq¨uˆencia n˜ao ordenada de tipos existentes e uma selec¸˜ao de um dentre um conjunto de tipos [TAR 95]. A sintaxe para um tipo de objeto define uma estrutura abstrata de dados correspondente para este tipo de objeto. Por exemplo, a estrutura de um dado tipo de objeto pode ser um Inteiro (Integer) ou uma String de Octetos (Octet String) ou ainda qualquer construc¸˜ao ASN.1 a ser avaliada para uso na definic¸˜ao da sintaxe de um tipo de objeto.
Uma codificac¸˜ao de um tipo de objeto ´e simplesmente como se fossem instˆancias daquele tipo de objeto e s˜ao representados usando a sintaxe deste mesmo tipo de objeto. Implicitamente ligado `a notac¸˜ao de uma sintaxe de objeto e codificac¸˜ao ´e como o objeto est´a representado quando estamos transmitindo em uma rede [STA 99].
2.7
Base de Informac¸˜ao Gerencial (MIB)
Todo sistema complexo necessita armazenar as informac¸˜oes manipu-ladas em algum tipo de base de dados. A Base de Informac¸˜ao Gerencial (MIB -
Ma-nagement Information Base) ´e o nome conceitual para a informac¸˜ao de gerenciamento,
incluindo os objetos gerenciados e seus atributos. Pode-se considerar as informac¸˜oes para a configurac¸˜ao do sistema como tamb´em pertencentes a MIB [SZT 96].
A SMI (especificada na RFC 1155 [FAQ 04b]) descreve o cen´ario no qual a Base de Informac¸˜ao Gerencial pode ser definida. A SMI, baseada em uma abor-dagem orientada a objetos, introduz os conceitos de hierarquia, heranc¸a, nomeac¸˜ao e registros usados na caracterizac¸˜ao e identificac¸˜ao de objetos gerenciados. Al´em disso, ela define o conjunto de operac¸˜oes que pode ser realizado sobre os objetos gerenciados da MIB e o comportamento desses objetos mediante a execuc¸˜ao destas operac¸˜oes [CAR 93]. Dentro deste contexto, a MIB ´e definida como um conjunto de objetos gerenciados dentro de um Sistema Aberto, na qual um objeto gerenciado ´e a vis˜ao abstrata de um recurso real dentro deste sistema.
2.8
Operac¸˜oes de Gerenciamento
As operac¸˜oes de gerenciamento executadas na fronteira (fronteira entre um recurso e o objeto gerenciado que o representa) do objeto gerenciado s˜ao primitivas. Para se ter sucesso na realizac¸˜ao de uma operac¸˜ao, o sistema de gerenciamento invocador deve possuir os direitos de acesso necess´arios e as restric¸˜oes de consistˆencia, associadas `a classe do objeto gerenciado a quais n˜ao devem ser violadas. O sistema de gerenciamento pode ser requisitado para a execuc¸˜ao de uma operac¸˜ao em v´arios objetos gerenciados com sincronizac¸˜ao atˆomica, isto ´e, ou esta operac¸˜ao ´e efetivamente realizada sobre todos os objetos sem excec¸˜ao, ou n˜ao ´e realizada [STA 99].
A definic¸˜ao da classe de objetos deve especificar, para cada operac¸˜ao sobre o objeto gerenciado, o crit´erio para suportar pedidos de operac¸˜oes de gerenciamento com sincronizac¸˜ao atˆomica com outros objetos gerenciados [CAR 93]. A execuc¸˜ao s´o est´a sujeita a restric¸˜oes existentes na definic¸˜ao de classes que s˜ao realmente relevantes.
Existem dois tipos b´asicos de operac¸˜oes de gerenciamento que podem ser realizados sobre os objetos gerenciados:
18
• Operac¸˜oes orientadas a atributos;
• Operac¸˜oes sobre objetos gerenciados como um todo.
2.8.1
Operac¸˜oes Orientadas a Atributos
Segundo Soares [SOA 95],o comportamento descrito a seguir ´e comum a todas as operac¸˜oes orientadas a atributos:
• Todos os atributos envolvidos como parte de uma ´unica operac¸˜ao devem estar
dis-pon´ıveis, sem excec¸˜ao, para o objeto gerenciado;
• Todas as operac¸˜oes falham se e somente se o comportamento do objeto gerenciado
´e tal que a operac¸˜ao n˜ao ´e realizada em alguns dos atributos deste objeto;
• Quando uma operac¸˜ao de leitura ou modificac¸˜ao sobre uma lista de valores de
atri-butos ´e solicitada atrav´es de um ´unico pedido, a forma em que estas leituras ou modificac¸˜oes s˜ao sincronizadas entre os atributos depende da definic¸˜ao do com-portamento da classe do objeto gerenciado e da lista de atributos especificados na operac¸˜ao;
• Quando uma sincronizac¸˜ao atˆomica est´a em efeito, os estados intermedi´arios
re-sultantes da operac¸˜ao n˜ao s˜ao vis´ıveis por outras operac¸˜oes de gerenciamento. A utilizac¸˜ao de sincronizac¸˜ao atˆomica pode levar a resultados inesperados, se os atri-butos da lista n˜ao estiverem sincronizados entre si no objeto.
As seguintes informac¸˜oes devem estar dispon´ıveis para execuc¸˜ao de operac¸˜oes orientadas a atributos:
• Identificador de atributo; • Filtros;
Ap´os a execuc¸˜ao da operac¸˜ao, os seguintes resultados est˜ao dispon´ıveis na fronteira do objeto gerenciado:
• Identificador de atributo e valores dos atributos que sofreram operac¸˜oes;
• Indicac¸˜ao de erro para os atributos que n˜ao puderam ser submetidos `a operac¸˜ao.
Os seguintes tipos de erros devem ser identificados:
• Identificadores de atributos desconhecidos, isto ´e, n˜ao encapsulado dentro do objeto
gerenciado;
• Classe de objeto especificada que n˜ao ´e parte do conjunto alom´orfico do objeto
gerenciado;
• Falha geral no processamento da operac¸˜ao.
De acordo com Sztajnberg [SZT 96], a operac¸˜ao de gerenciamento so-bre um atributo de objeto gerenciado pode provocar efeitos diretos e/ou indiretos . Os efeitos diretos s˜ao definidos pela operac¸˜ao de gerenciamento Substituic¸˜ao do Valor do Atributo (Replace Attribute Value). Os efeitos indiretos s˜ao resultados de relac¸˜oes do objeto gerenciado em quest˜ao.
Como exemplos de efeitos indiretos pode-se citar:
• Modificac¸˜ao de um atributo dentro do mesmo objeto; • Mudanc¸a de comportamento do objeto gerenciado;
• Alterac¸˜ao de um atributo de um objeto gerenciado relacionado;
• Mudanc¸a no comportamento de um objeto gerenciado relacionado causado pela
20
2.8.2
Operac¸˜oes sobre Objetos Gerenciados como um Todo
Estas operac¸˜oes aplicam-se a objetos gerenciados como um todo e seus efeitos geralmente n˜ao se limitam a modificar os valores dos seus atributos. S˜ao definidas as seguintes operac¸˜oes: CREATE, DELETE e ACTION [LOP 02].
Operac¸˜oes adicionais podem ser definidas por meio da operac¸˜ao AC-TION. A semˆantica destas operac¸˜oes faz parte da definic¸˜ao da classe de objeto gerenci-ado.
Os objetos gerenciados s˜ao criados e removidos por meio de operac¸˜oes de gerenciamento ou como efeito colateral de uma outra operac¸˜ao.
2.9
Conclus˜ao
Atualmente as redes de computadores s˜ao de extrema importˆancia para as empresas, pois normalmente junto com sua utilizac¸˜ao vem a efic´acia e a competiti-vidade. Essa relevˆancia vem crescendo de tal forma que as empresas tem se tornado altamente dependentes destas redes, sentindo imediatamente o impacto quando os seus recursos n˜ao est˜ao dispon´ıveis.
Cientes desse problema, a soluc¸˜ao passou a ser buscada na atividade de gerenciamento. Esta atividade passou a evoluir de forma r´apida e concisa, sendo hoje uma das especialidades da ´area de redes de computadores que mais cresce [SAM 97] APUD IN [GUB 02].
A Gerˆencia de Redes de Computadores pode ser definida como a coordenac¸˜ao e monitorac¸˜ao das atividades dos recursos computacionais, tais como, modens, roteado-res, dentre outros, que est˜ao fisicamente distribu´ıdos na rede, assegurando na medida do poss´ıvel, a confiabilidade, o tempo de resposta e a seguranc¸a nas informac¸˜oes. Dessa maneira, fornecendo aos usu´arios da rede um funcionamento com Qualidade de Servic¸o [OLI 98].
O resultado esperado ap´os a implantac¸˜ao de um sistema de gerenci-amento de redes ´e um controle mais efetivo dos recursos f´ısicos e/ou l´ogicos da rede,
acarretando com isso o correto funcionamento destes recursos e mantendo a rede de com-putadores dispon´ıvel o maior tempo poss´ıvel a servic¸o dos usu´arios.
Cap´ıtulo 3
Multicast
A grande parte das aplicac¸˜oes tradicionais utilizadas na internet, tais como web browsers e e-mail, funcionam entre um emissor e um receptor. O desenvol-vimento da internet nos ´ultimos anos est´a relacionado diretamente com o aumento das aplicac¸˜oes que se utilizam de sua infra-estrutura. Este aumento ´e acompanhado de uma grande demanda, tanto em termos de quantidade (referente ao n´umero de usu´arios que est´a crescendo) quanto em termos de qualidade (referente ao tipo de dados utilizados na rede). A transmiss˜ao de dados n˜ao convencionais como v´ıdeo, ´audio entre outros tem ocupado um espac¸o cada vez maior nas necessidades dos usu´arios, gerando uma enorme demanda por largura de banda. Muitos tˆem sido os estudos para equacionar este problema, e uma das soluc¸˜oes encontradas ´e o servic¸o multicast [FAR 00] e [NAS 00] APUD IN [GUB 02]. O servic¸o de transmiss˜ao multicast se caracteriza pela existˆencia de gru-pos, onde cada destes grupos possui um enderec¸o ´unico que o identifica. ´E feita uma associac¸˜ao destes membros dinamicamente aos grupos e assim trocam mensagens entre si. Uma mensagem enderec¸ada ao grupo ´e transmitida para todos os membros do mesmo. Um transmissor n˜ao precisa necessariamente ser membro para enviar uma mensagem para um grupo em particular e, neste caso, o grupo ´e denominado aberto, em contraste com grupos fechados onde apenas os membros podem trocar de mensagens.
A grande vantagem desta soluc¸˜ao reside no roteamento usado para im-plementar essa comunicac¸˜ao. Os protocolos foram criados para evitar replicac¸˜oes de
pacotes em um mesmo enlace e assim utilizar melhor os recursos dispon´ıveis [ROD 99]. Neste cap´ıtulo ser˜ao abordados t´opicos sobre redes multicast. Na sec¸˜ao 3.1 fala-se sobre IP Multicast, na sec¸˜ao 3.2 as vantagens do uso de multicast e na sec¸˜ao 3.3 os protocolos das redes multicast. Por fim, na sec¸˜ao 3.4, o assunto ´e gerˆencia em redes multicast.
3.1
IP Multicast
Muitas tecnologias em hardware de rede local cont´em mecanismos para enviar quadros para m´ultiplos destinos na rede simultaneamente. A forma mais comum para transmiss˜ao para m´ultiplos pontos ´e denominada broadcast (difus˜ao). Em trans-miss˜oes por difus˜ao, uma c´opia do quadro ´e enviada para todos os nodos da rede, utili-zando tecnologias pr´oprias de cada rede local [MEL 96].
Outra forma de transmiss˜ao existente para transmiss˜ao para m´ultiplos pontos ´e o multicast (difus˜ao seletiva). Diferente do uso de broadcast, com multicast se permite que cada m´aquina escolha se deseja participar de uma transmiss˜ao. Tipicamente, est˜ao reservados dentro de cada tecnologia de hardware um grande conjunto de enderec¸os para uso com difus˜ao seletiva. Quando um grupo de m´aquinas deseja se comunicar, elas escolhem um enderec¸o multicast para utilizarem para a sua comunicac¸˜ao. As interfaces de rede s˜ao configuradas para reconhecer o enderec¸o selecionado, e todas as m´aquinas per-tencentes ao grupo passam a receber uma c´opias de cada quadro enviado para o enderec¸o multicast.
O enderec¸amento multicast pode ser visto como uma generalizac¸˜ao de todas as outras formas de enderec¸amento. Pode-se pensar, por exemplo, que a forma de enderec¸amento convencional unicast ´e um enderec¸amento multicast onde apenas uma m´aquina participa do grupo e, de forma similar, que o enderec¸amento broadcast ´e uma forma de enderec¸amento multicast onde todas as m´aquinas s˜ao membros do grupo multi-cast.
Assim como difus˜ao seletiva em hardware de rede local, existe difus˜ao seletiva para a camada IP da arquitetura Internet TCP/IP [DEE 89]. A forma de
24
enderec¸amento multicast IP ´e uma abstrac¸˜ao do multicast em hardware. Ela permite que um datagrama IP seja transmitido para um conjunto de m´aquinas que formam um grupo multicast identificado por um enderec¸o IP ´unico. Os grupos multicast s˜ao formados por um conjunto de zero ou mais estac¸˜oes, que podem estar espalhadas ao longo de redes f´ısicas separadas. A entrega de um datagrama multicast ´e realizada com as mesmas ca-racter´ısticas de confiabilidade dos datagramas unicast regulares IP, o que significa que n˜ao h´a garantia contra perda, atraso, duplicac¸˜ao ou desordenac¸˜ao para nenhum dos membros do grupo. O conceito de enderec¸amento multicast [DEE 89], foi criado por Steve Deering e mais tarde desenvolvido na Xerox PARC.
Os membros de um grupo multicast IP s˜ao dinˆamicos: estac¸˜oes podem entram ou deixar grupos a qualquer momento. N˜ao existem restric¸˜oes para o n´umero de membros de um grupo, e uma estac¸˜ao pode participar de mais de um grupo
simultaneamente, assim como pode enviar datagramas a um grupo mesmo sem pertencer a ele.
Existem grupos que possuem um enderec¸o conhecido, fixo, denomina-dos grupos permanentes. Mas apenas o enderec¸o ´e permanente: os membros deste grupo n˜ao s˜ao fixos, e num dado momento um grupo permanente pode ter qualquer n´umero de membros, inclusive nenhum. Os enderec¸os multicast IP que n˜ao s˜ao reservados para nenhum grupo permanente est˜ao dispon´ıveis para atribuic¸˜ao dinˆamica de grupos tem-por´arios que existem somente enquanto possuem membros, denominados grupos transi-entes. Estes grupos s˜ao criados quando s˜ao necess´arios, e eliminados quando o n´umero de membros chega a zero [MEL 96].
Pode ser utilizada difus˜ao seletiva em uma rede f´ısica simples ou atrav´es de uma internet. Neste ´ultimo caso, que ´e onde se enquadra o MBone1, os datagramas
s˜ao transmitidos por gateways multicast especiais denominados roteadores multicast, ou mrouters. Uma estac¸˜ao transmite um datagrama multicast como um multicast de rede lo-cal, que atingir´a todos os membros do grupo pertencentes a rede local. Na Figura 3.1, h´a a demonstrac¸˜ao de tr´afego unicast e multicast, mostrando que o unicast necessitaria de um
1Abreviac¸˜ao de Multicast Backbone na internet, MBone ´e uma extens˜ao da internet para suporte ao IP
Figura 3.1: Comparativo entre Redes Unicast e Multicast [MEL 96]
maior consumo de banda para enviar os mesmos pacotes do que numa rede multicast. Se o datagrama possuir um IP time-to-live (correspondente ao campo time-to-live do data-grama IP) maior que um, o roteador multicast ligado a rede transmite o pacote para todas as outras redes que possuem membros do grupo, desde que sejam ating´ıveis dentro do seu time-to-live. Os roteadores multicast pertencentes as redes destinos completam a entrega, transmitindo o datagrama como multicast local.
Assim como na difus˜ao seletiva em hardware, o multicast IP utiliza o enderec¸o destino do datagrama para indicar entrega com difus˜ao seletiva. Utiliza a classe D de enderec¸amento IP, conforme a Figura 3.2:
Figura 3.2: Classe D de enderec¸amento IP [MEL 96]
Os primeiros quatro bits do enderec¸o cont´em o valor “1110”e identifi-cam o enderec¸o como multicast. Os vinte e oito bits seguintes indiidentifi-cam um grupo multicast espec´ıfico. Expressados na notac¸˜ao decimal pontual, os enderec¸os multicast IP variam entre 224.0.0.0 e 239.255.255.255. O enderec¸o 224.0.0.0 ´e reservado, n˜ao podendo ser
26
atribu´ıdo para nenhum grupo [JOH 97] APUD IN [GUB 02].
Uma estac¸˜ao, para participar de multicast IP em uma rede local, deve possuir um software que permita enviar e receber datagramas multicast. Para participar de um grupo multicast que atravesse v´arias redes, a estac¸˜ao deve informar o roteador multicast local. Os roteadores locais entram em contato com outros roteadores multicast, passando a informac¸˜ao de associac¸˜ao a um grupo e estabelecendo rotas.
As estac¸˜oes e roteadores multicast comunicam informac¸˜oes de associac¸˜oes em grupos utilizando o protocolo Internet Group Management Protocol (IGMP) [DEE 89].
3.2
Vantagens Uso Multicast
Em comunicac¸˜oes tradicionais envolvendo v´arios sites simultaneamente, para cada pacote do host de origem ´e feita uma replicac¸˜ao para o n´umero de hosts des-tinos, e cada pacote ´e enviado para seu destino separadamente. Este modelo imp˜oe uma limitac¸˜ao no n´umero de m´aquinas que poderiam estar envolvidas na comunicac¸˜ao, pois o tr´afego gerado na rede e as necessidades computacionais do host de origem - que gera c´opias de cada pacote - aumentam linearmente com o n´umero de hosts destinos envolvi-dos [DEE 88].
A Figura 3.3 exemplifica uma transmiss˜ao tradicional. No exemplo, um pacote deve ser enviado para os hosts destinos A, B e C. Ele ´e replicado no host de origem e trˆes c´opias s˜ao enviadas, consumindo maior desempenho no host X e maior largura de banda na rede, mesmo que alguns dos segmentos de rede sejam comuns aos trˆes.
Segundo Cristina [MEL 96], existem por´em, tecnologias que tratam es-tas limitac¸˜oes, sendo chamadas soluc¸˜oes escalares de rede. O uso do multicast IP ´e uma destas soluc¸˜oes. Utilizando multicast, apenas uma c´opia de cada pacote ´e enviada por linha, sendo copiada apenas quando houver um brac¸o na ´arvore l´ogica dos destinos. A utilizac¸˜ao de difus˜ao seletiva fornece um ganho de processamento de CPU e largura de banda quando v´arios sites est˜ao envolvidos simultaneamente, conforme Figura 3.4.
Figura 3.4: Comunicac¸˜ao entre um grupo de hosts utilizando difus˜ao seletiva [MEL 96]
Na Figura 3.4, o host X n˜ao mais replica os datagramas para cada host destino, participante do grupo Z, no exemplo A, B e C, enviando apenas uma c´opia com enderec¸o do grupo. O tr´afego sobre o enlace L1 permanece sempre mesmo, indepen-dente do n´umero de participantes do grupo. O datagrama ser´a replicado apenas quando houver destinos com diferentes destinos, sendo replicado no ´ultimo roteador multicast comum aos dois caminhos. Na Figura 3.4, os roteadores multicast que s˜ao respons´aveis por replicar os datagramas est˜ao representados por R1 e R2 [DEE 88].
28
3.3
Protocolos
Os protocolos de roteamento IP Multicast geralmente se encaixam em uma das duas categorias, citadas abaixo, dependendo da distribuic¸˜ao esperada dos mem-bros do grupo multicast atrav´es da rede.
Segundo Gubert [GUB 02], a primeira ´e chamada modo-denso (dense-mode) e assume que os membros do grupo multicast est˜ao densamente distribu´ıdos atrav´es da rede e que, a disponibilidade de largura de banda da rede ´e grande. Os protocolos de ro-teamento multicast modo-denso baseiam-se em uma t´ecnica chamada “inundac¸˜ao”(flooding), para propagar informac¸˜oes para todos os roteadores da rede, isto ´e, periodicamente inun-dam a rede com tr´afego multicast para configurar e manter a ´arvore de distribuic¸˜ao (span-ning tree2).
A segunda categoria, chamada modo-esparso (sparse-mode), assume que os membros do grupo est˜ao esparsamente distribu´ıdos pela rede e a largura de banda n˜ao est´a, necessariamente, amplamente dispon´ıvel. Por exemplo, se os usu´arios est˜ao dispersos em v´arias regi˜oes da internet ou se est˜ao conectados via linhas ISDN. O modo esparso n˜ao significa que o grupo tenha poucos membros, mas que eles estejam ampla-mente dispersos. Neste caso, a t´ecnica de “inundac¸˜ao”desperdic¸aria largura de banda e, conseq¨uentemente, causaria s´erios problemas de performance. Assim, protocolos de rote-amento modo-esparso baseiam-se em t´ecnicas para construir e manter ´arvores multicast.
3.3.1
Protocolos de Roteamento Multicast (Modo Denso)
Como o uso de multicast n˜ao ´e compreendido em todos os roteadores na Internet, a topologia do MBone difere da topologia da internet. Com isso, os roteadores multicast precisam executar um protocolo de roteamento multicast para descobrir sua pr´opria topologia, a fim de identificar para onde enviar os datagramas. O protocolo mais utilizado no MBone ´e o Distance Vector Multicasting Routing (DVMRP). Por´em, em algumas partes do MBone, os roteadores usam outros protocolos de roteamento multicast,
2Spanning Tree ou STP, um protocolo de gerenciamento que ´e parte do padr˜ao IEEE 802.1 para controle
especialmente o Multicast Open Shortest Path First (MSOPF) e o Protocol Independent Multicast (PIM), que interoperam com os roteadores DVMRP grac¸as a implementac¸˜ao de um subconjunto do DVMRP.
Distance Vector Multicasting Routing Protocol (DVMRP)
O DVMRP [KUM 95] foi um dos primeiros mecanismos de roteamento multicast desenvolvidos, criado por Steve Deering. Existe uma vers˜ao anterior do DVMRP, especificada na RFC1075 [FAQ 04c], por´em a vers˜ao utilizada nos mrouters ´e diferente da vers˜ao especificada neste documento, possuindo diferenc¸as quanto ao formato do pacote, ao formato do t´unel, aos tipos de pacotes adicionais, etc.
O roteador multicast baseado no DVMRP mant´em o conhecimento to-pol´ogico atrav´es de um protocolo de roteamento de vetor de distˆancias, como o Routing Information Protocol (RIP) descrito na RFC1058 [FAQ 04d], sobre o qual ´e implemen-tado um algoritmo de transmiss˜ao multicast chamado Truncated Reverse Path Broadcas-ting.
Os roteadores DVMRP tratam a topologia do Mbone como um dom´ınio ´unico. Cada roteador mant´em uma entrada na tabela de roteamento para cada subrede no Mbone e troca mensagens de roteamento periodicamente com cada um de seus vizinhos identificando todas as subredes. Como o n´umero de subredes tem crescido exponencial-mente, o custo de roteamento cresce tamb´em exponencialexponencial-mente, e os recursos de mem´oria e processamento dos atuais roteadores DVMRP dever˜ao ficar insuficientes.
Este problema j´a ´e conhecido no roteamento unicast, e tem como soluc¸˜ao o uso de roteamento hier´arquico. No roteamento hier´arquico, a topologia ´e particionada logicamente em um n´umero de dom´ınios separados, cada um executando sua pr´opria instˆancia do protocolo de roteamento. Outro protocolo de roteamento, ou mesmo ou-tra instˆancia do mesmo protocolo s˜ao utilizados para o roteamento entre dom´ınios. A informac¸˜ao da topologia de cada dom´ınio ´e mantida somente pelo protocolo de rotea-mento daquele dom´ınio, enquanto que o protocolo interdom´ınio mant´em informac¸˜oes somente sobre as interconex˜oes dos dom´ınios, n˜ao tendo conhecimento das topologias internas. Com a aplicac¸˜ao de particionamento hier´arquico recursivamente, ´e poss´ıvel rea-lizar o roteamento de uma grande ´area topol´ogica com pequena quantidade de informac¸˜ao
30
mantida em cada roteador [MEL 96].
Existe uma proposta do uso de roteamento hier´arquico para o Mbone, proposta por Thyagarajan e Deering em [DEE 89], usando inicialmente hierarquia de dois n´ıveis de regi˜oes. No roteamento multicast dentro das regi˜oes seria utilizado uma s´erie de protocolos, inclusive o DVMRP, enquanto que no roteamento inter-regi˜oes seria utilizado uma vers˜ao modificada do DVMRP que calcularia rotas multicast entre as regi˜oes ao inv´es de entre as sub-redes.
O uso de roteamento hier´arquico traz uma s´erie de outros benef´ıcios al´em da diminuic¸˜ao de informac¸˜ao topol´ogica armazenada por cada roteador. Diferen-tes protocolos podem ser utilizados dentro das regi˜oes, que utilizar˜ao uma interface clara entre elas, eliminando os problemas gerados pela mistura de diferentes protocolos de ro-teamento e permitindo que novos protocolos sejam testados e desenvolvidos. Mudanc¸as da topologia, como a falha de um enlace ou roteador, s˜ao detectados somente entre os ro-teadores da mesma regi˜ao, da mesma forma que mudanc¸as na topologia das interconex˜oes das regi˜oes s˜ao limitadas aos roteadores entre regi˜oes, o que ´e particularmente ben´efico para o uso do DVMRP, que pode demorar longo tempo para detectar as mudanc¸as to-pol´ogicas. E, por fim, o limite de diˆametro m´aximo de topologia imposto por alguns pro-tocolos de roteamento, como o DVMRP, pode ser relaxado, j´a que diferentes instˆancias do protocolo s˜ao utilizadas para diferentes partes da rede e o limite se relaciona somente com estas partes [KUM 95].
Multicast Open Shortest Path First (MOSPF)
A extens˜ao multicast para o protocolo de roteamento IP Open Shortest Path First (OSPF) ´e denominada Multicast Open Shortest Path First (MOSPF) [MOY 94]. O protocolo OSPF ´e baseado no estado dos enlaces, diferente do RIP, que ´e baseado na contagem dos nodos. Uma rede de roteadores utilizando MOSPF pode enviar pacotes multicast diretamente, enviando n˜ao mais que uma c´opia por cada enlace, e sem a neces-sidade de t´uneis.
O MOSPF transmite os datagramas IP multicast da origem para os v´arios membros do grupo sem formar lac¸os, gerando uma ´arvore. Esta ´arvore tem como raiz o nodo origem do datagrama, e todos os “brac¸os”terminam em membros do grupo.
