1999_05_rodrigues

MARCUS ANTONIO ALMEIDA RODRIGUES
UM FRAMEWORK PARA A PROVISÃO DE SERVIÇO DE
MULTICAST EM AMBIENTES GENÉRICOS DE COMUNICAÇÃO
DE DADOS
DISSERTAÇÃO DE MESTRADO
Departamento de Informática
Rio de Janeiro, 21 de Maio de 1999

MARCUS ANTONIO ALMEIDA RODRIGUES
UM FRAMEWORK PARA A PROVISÃO DE SERVIÇO DE
MULTICAST EM AMBIENTES GENÉRICOS DE COMUNICAÇÃO
DE DADOS
Dissertação de Mestrado apresentada ao
Departamento de Informática da PUC/RJ, como
parte dos requisitos para obtenção do título de
Mestre em Informática: Ciência da Computação
Orientador: Luiz Fernando Gomes Soares
Departamento de Informática
Pontifícia Universidade Católica do Rio De Janeiro
Rio de Janeiro, 21 de Maio de 1999

Dedicatória
Este trabalho é dedicado
A minha família, pelo esforço de me
proporcionar as melhores condições para o meu
desenvolvimento intelectual, e pelo amor e
carinho a mim sempre dedicados.

Agradecimentos
• Ao meu Orientador, Professor Luiz Fernando Gomes Soares, pelo exemplo
profissional, pela paciência e palavras de apoio nos momentos de dificuldade (pessoais
e profissionais), e acima de tudo pelo amigo que tem sido.
• Ao Laboratório TeleMídia, pelo ótimo ambiente de trabalho, em especial aos amigos
Sérgio Colcher, pela atenção, ajuda e orientação indispensáveis para a conclusão deste
trabalho, Rogério Rodrigues e Débora Muchaluat, pela ajuda e atenção sempre
presente.
• Ao Acadêmicos do TeleMídia®
, pela amizade, acolhida, e pela honra e alegria de ter
aprendido que nascemos e estamos prontos pra morrer. Caminha TeleMídia!
• Ao professores e funcionários do Departamento de Informática da PUC-Rio, pela
formação e ajuda na elaboração desta dissertação, em especial a Professora Noemi
Rodriguez e Professor Hugo Fuks.
• Aos professores da Universidade Estadual do Ceará, em especial a José Everardo
Bessa Maia, Marcos Negreiros, Marcelo Aragão e José Neuman de Souza pelos
conhecimentos transmitidos, e palavras de incentivo na escolha do meu caminho.
Gostaria também de fazer um agradecimento especial ao professor e amigo Mauro
Oliveira (“Aaaaêêêê!”), pela amizade, confiança, e pelo despertar da investigação
científica.

• À República Federativa da Farinha, pela amizade, e por me trazer um pedacinho do
Ceará nas várias mensagens trocadas em nossa lista. Obrigado a todos!
• A todos os meus amigos, em especial aos “irmãos” Roberto Façanha, Antônio Tadeu
Azevedo Gomes, Romulo Martins de Menezes, Gabriel Paillard, Bruno Muniz,
Cláudio Prata Santiago e Rafael Castro de Andrade, que me acompanharam nas
diversas fases da elaboração deste trabalho, pela paciência nos momentos de estresse e
imaturidade, pela força sempre presente nos momentos de dificuldade, e pala alegria
constante nos momentos de alegria... E acima de tudo, por termos formado uma
família. Gostaria também de agradecer a Família Martins de Menezes (Sr. Rafael V. de
Menezes, D. Leda Martins de Menezes, Romulo, Denise e Rafael Jr.), por sempre me
receberem em sua casa como membro da família, e palas agradáveis reuniões de
família.
• A Andréa Serpa, pelo carinho sempre presente, apoio incondicional, e força na decisão
de buscar meus sonhos. Obrigado, Andréa! Dedico também a ti esse trabalho!
• A toda minha Família, especialmente ao meu Painho (Gerardo Bandeira Rodrigues),
Mainha (Maria de Almeida Rodrigues), Maninhos (Gerardo Bandeira Rodrigues Júnior
e Ana Christine Almeida Rodrigues), e minhas sobrinhas (Edianne Christine Rodrigues
Moura, Germana Rodrigues Moura e Luiza Helena Almeida Rodrigues), pelo apoio
sempre presente e confiança incondicional, que foram importantíssimos durante todas
as fases do meu trabalho, e pelo amor infinito. Vocês foram fonte de paz, estímulo,
força e inspiração. Amo vocês!
• Ao CNPq, Embratel e PUC pelo suporte financeiro dado a este trabalho, sem o qual
sua realização não teria sido possível.
• A Deus, pela luz e por ter tornado possíveis todos os agradecimentos anteriores.
“Escrevi demais por não ter tempo de escrever menos…”

Citação
“Good frameworks are usually the result of many
design interactions and a lot of hard work.”
Wirfs-Brock and Johnson, 1990

Resumo
Reconhecendo que a maioria das soluções que têm sido apresentadas como candidatas à
implementação do serviço de multicast tem sido projetadas tendo em mente determinadas condições
da infra-estrutura utilizada para a distribuição de mensagens, ou requisitos de aplicações de mais
alto nível, esse trabalho apresenta a proposta de um framework para a definição de um serviço de
multicast cuja principal característica é a sua generalidade e independência em relação aos
possíveis sistemas de comunicação, e aplicações. Partindo-se desse framework, é possível
implementar serviços de multicast específicos de uma forma organizada e rápida através do reuso
de toda a estrutura genérica apresentada, aliada a configuração de determinados componentes do
serviço. O framework proposto é composto por dois serviços básicos: um serviço de gerenciamento
de grupo, e um serviço de suporte a construção da infra-estrutura de distribuição multicast. A
utilização do framework é ilustrada na implementação de um agente mediador para comunicação
de grupo centralizado, utilizado em um serviço de distribuição de vídeo.
Palavras-Chave: Framework, Serviço Multicast, gerenciamento de grupo, roteamento multicast,
especificação de protocolo.
Abstract
Since most of the solutions available as candidates to the implementation of a multicast service
have been designed to fit specific infrastructure conditions or service characteristics to which they
are aimed, or, still, to fit management politics for user groups, the present work introduces a
framework for designing a multicast service whose main features are its generality and
independence toward possible communication systems and applications. This framework allows the
implementation of specific multicast services in a fast and organized way, by reusing the whole
generic structure presented, in addition to the configuration of some service components. The
framework consists of two basic services: a group management service, and a support service to
the construction of the multicast distribution infrastructure. Its use is illustrated by the
implementation of broker agent for centralized group communication, applied to a video
distribution service.
Keywords: Framework, Multicast Service, group management, multicast routing, protocol
specification.

i
Conteúdo
1.1 OBJETIVO.................................................................................................................................... 4
1.2 ORGANIZAÇÃO DA DISSERTAÇÃO.................................................................................................. 6
2.1 MODELO DE SERVIÇO MULTICAST ................................................................................................ 8
2.1.1 Multicast, Multiponto ou Multiway ?................................................................................11
2.1.2 Grupos .............................................................................................................................11
2.1.3 Associações de Grupo e Conversação ..............................................................................15
2.1.4 Modelo de Serviço de Operação de Grupo .......................................................................16
2.1.4.1 Estabelecimento do Grupo .........................................................................................................16
2.1.4.2 Registro de Grupo......................................................................................................................16
2.1.4.3 Adesão ao Grupo .......................................................................................................................16
2.1.4.4 Estado do Grupo........................................................................................................................17
2.1.5 Modelo de Serviço de Operação da Associação de Grupo................................................17
2.1.5.1 Estabelecimento e Liberação......................................................................................................17
2.1.5.2 Adesão (Join) e Abandono (Leave).............................................................................................18
2.1.5.3 Transferência de Dados..............................................................................................................19
2.1.6 Procedimentos para o estabelecimento de uma comunicação multicast ............................19
2.1.6.1 Diagrama de Estados .................................................................................................................19
2.1.6.2 Tabela de Primitivas e Parâmetros .............................................................................................21
2.1.6.3 Descrição dos Procedimentos do Diagrama de Estados...............................................................22
2.2 REQUISITOS E CARACTERÍSTICAS DE UM SERVIÇO DE MULTICAST .................................................27
2.2.1 Gerenciamento de Grupo .................................................................................................28
2.2.2 Transmissão Multicast......................................................................................................29
2.3 RESUMO.....................................................................................................................................31
3.1 SERVIÇOS E PROTOCOLOS DE MULTICAST ....................................................................................32
3.1.1 IP Multicast......................................................................................................................33
3.1.2 Backbone Multicast da Internet (MBone) .........................................................................35
3.1.3 Suporte a IP Multicast em Redes ATM .............................................................................36
3.1.4 Transporte Multicast ........................................................................................................37
3.2 GERENCIAMENTO DE GRUPO DE MULTICAST ................................................................................38
3.2.1 Gerenciamento de Grupo Distribuído...............................................................................39
3.2.2 Gerenciamento de Grupo Centralizado ............................................................................40

3.3 ROTEAMENTO MULTICAST ..........................................................................................................43
3.3.1 Árvore Baseada na Origem ..............................................................................................43
3.3.2 Árvore Baseada em um Núcleo.........................................................................................46
3.4 REDES CONFIGURÁVEIS...............................................................................................................52
3.4.1 ANTS – Active Network Tookit .........................................................................................53
3.4.2 AMSA - Active Multicast Service Architecture..................................................................54
4.1 PATTERNS E FRAMEWORKS E CONCEITOS DE ORIENTAÇÃO A OBJETOS NO PROJETO E CONFIGURAÇÃO
DE SERVIÇOS .......................................................................................................................................57
4.2 ARQUITETURA GENÉRICA DO FRAMEWORK..................................................................................59
4.2.1 Interface do Serviço .........................................................................................................61
4.2.2 Gerenciamento de Grupo e Agrupamento.........................................................................63
4.2.3 Gerenciamento de Endereço.............................................................................................65
4.2.4 Construção da Infra-Estrutura de Transmissão Multicast.................................................66
4.3 DESCRIÇÃO DO FRAMEWORK.......................................................................................................68
4.3.1 Casos de Utilização..........................................................................................................69
4.4 SERVIÇO DE GERENCIAMENTO DE GRUPO.....................................................................................70
4.4.1 Componentes do Serviço de Gerenciamento de Grupo......................................................71
4.4.1.1 Base de Informações de Grupo...................................................................................................71
4.4.1.2 Modelo de Gerenciamento de Grupo..........................................................................................73
4.4.1.3 Modelo de Gerenciamento e Resolução de Endereço..................................................................78
4.4.2 Exemplos de Aplicação do Framework de Serviço de Gerenciamento de Grupo...............83
4.4.2.1 Configuração de um Serviço de Gerenciamento de Grupo e Resolução de Endereço Centralizado
83
4.4.2.2 Configuração de um Serviço de Gerenciamento de Grupo e Resolução de Endereço Distribuído.85
4.5 CONSTRUÇÃO DA INFRA-ESTRUTURA DE DISTRIBUIÇÃO ................................................................86
4.6 RESUMO.....................................................................................................................................88
5.1 DESCRIÇÃO DO SERVIÇO .............................................................................................................90
5.1.1 Publicar Canais ...............................................................................................................91
5.1.2 Consulta de Canais ..........................................................................................................92
5.1.3 Assinar um Canal.............................................................................................................92
5.1.4 Seleção de Canais ............................................................................................................92
5.2 ARQUITETURA DO SERVIÇO.........................................................................................................93
5.2.1 Definição do Serviço........................................................................................................95
5.2.1.1 Primitivas de Interface...............................................................................................................95
5.2.1.2 Gerenciamento de Canais.........................................................................................................101
5.2.1.3 Gerenciamento de Grupo .........................................................................................................102
5.3 PLATAFORMA DE PROTOTIPAÇÃO ..............................................................................................103
6.1 CONTRIBUIÇÃO.........................................................................................................................107
6.2 EXTENSÕES E TRABALHOS FUTUROS..........................................................................................108
A.1 DIAGRAMA DE CLASSES.............................................................................................................112
A.2 DIAGRAMAS DE SEQÜÊNCIA.......................................................................................................116
B.1 VISÃO COMPUTACIONAL...........................................................................................................119

B.2 VISÃO DE ENGENHARIA.............................................................................................................121
B.2.1 Modelo Específico do Nível de Cluster...........................................................................122
B.2.2 Modelo Específico do Nível de Cápsula .........................................................................122
B.2.3 Modelo Específico do Nível de Camada .........................................................................123

iv
Índice de Figuras
FIGURA 1.1: APLICAÇÃO DO FRAMEWORK .................................................................................................. 5
FIGURA 2.1: MODELO DO SERVIÇO DE MULTICAST ..................................................................................... 9
FIGURA 2.2: EXEMPLO DE IMPLEMENTAÇÕES DO SERVIÇO DE MULTICAST....................................................10
FIGURA 2.1: DIAGRAMA DE ESTADOS........................................................................................................20
FIGURA 2.1: ARQUITETURA DO SISTEMA DE COMUNICAÇÃO .......................................................................30
FIGURA 3.1: BACKBONE INTERNET MULTICAST .........................................................................................36
FIGURA 3.1: ÁRVORE CBT .......................................................................................................................48
FIGURA 3.2: ADESÃO A UM GRUPO DE MULTICAST E CONSTRUÇÃO DA ÁRVORE DE ENTREGA COMPARTILHADA
......................................................................................................................................................50
FIGURA 3.3: EXEMPLO DE TRANSMISSÃO A UM GRUPO.............................................................................51
FIGURA 3.4: EXEMPLO DE COMUTAÇÃO DE UMA ÁRVORE COMPARTILHADA PARA UMA ÁRVORFE DE MENOR
CAMINHO ........................................................................................................................................52
FIGURA 4.1: ARQUITETURA GERAL DO SERVIÇO DE MULTICAST .................................................................61
FIGURA 4.1: DIAGRAMA DE ESTADOS DO GERENCIAMENTO DE GRUPO........................................................64
FIGURA 4.1: CASOS DE UTILIZAÇÃO DO SERVIÇO DE MULTICAST................................................................70
FIGURA 4.1: MODELO DE GERENCIAMENTO DE GRUPO...............................................................................71
FIGURA 4.1: DIAGRAMA DE COLABORAÇÃO DO PATTERN OBSERVER PARA A ADESÃO A GRUPO.....................73
FIGURA 4.1: DIAGRAMA DE SEQUÊNCIA DE REGISTRO DE GRUPO .................................................................75
FIGURA 4.1: DIAGRAMA DE SEQUÊNCIA DA CRIAÇÃO DE GRUPO...................................................................76
FIGURA 4.1: DIAGRAMA DE SEQUÊNCIA DA ADESÃO DE GRUPO....................................................................77
FIGURA 4.1: MAPEAMENTO ENTRE ENDEREÇO DE CLASSE D E E ENDEREÇO MULTICAST IEEE-802 ...............79
FIGURA 4.2: EXEMPLO DE ESPECIALIZAÇÃO DO MÉTODO RESOLV() PARA RESOLUÇÃO POR VINCULAÇÃO
DINÂMICA E POR TABELA DE MAPEAMENTO .......................................................................................82
FIGURA 4.3: DIAGRAMA DE SEQUÊNCIA DE RESOLUÇÃO DE ENDEREÇO POR VINCULAÇÃO DINÂMICA..............82
FIGURA 4.1: EXEMPLO DE CONFIGURAÇÃO DO SERVIÇO DE GERENCIAMENTO DE GRUPO CENTRALIZADO .......84
FIGURA 4.1: EXEMPLO DE CONFIGURAÇÃO DO SERVIÇO DE GERENCIAMENTO DE GRUPO DISTRIBUÍDO ...........85

FIGURA 4.1: FRAMEWORK DO SERVIÇO DE ROTEAMENTO MULTICAST ........................................................87
FIGURA 5.1: EXEMPLO DE SERVIÇO DE TRANSMISSÃO DE VÍDEO .................................................................91
FIGURA 5.1: ARQUITETURA DE APLICAÇÃO DO FRAMEWORK.......................................................................94
FIGURA 5.1: HIERARQUIA DE CLASSES DO SERVIÇO PARA O TRANSMISSOR E RECEPTORES DO GRUPO..............97
FIGURA 5.2: DIAGRAMA DE SEQUÊNCIA DA PUBLICAÇÃO DE CANAIS ............................................................98
FIGURA 5.3: DIAGRAMA DE SEQUÊNCIA DA ASSINATURA DE UM CANAL........................................................99
FIGURA 5.1: HIERARQUIA DE CLASSES DO GERENCIADOR DO SERVIÇO .......................................................102
FIGURA 5.1: ESTRUTURA DOS COMUTADORES VIRTUAIS ...........................................................................103
FIGURA 5.2: PLATAFORMA DE SIMULAÇÃO ..............................................................................................104
FIGURA A.1: CLASSES UML ...................................................................................................................113
FIGURA A.2: RELACIONAMENTOS UML ..................................................................................................114
FIGURA A.3: ADORNOS UML .................................................................................................................115
FIGURA A.4: DIAGRAMA DE CLASSES EXEMPLO .......................................................................................116
FIGURA A.1: DIAGRAMA DE SEQUÊNCIA UML .........................................................................................116
FIGURA B.1: COMPONENTES DA VISÃO COMPUTACIONAL.........................................................................119
FIGURA B.2: COMPOSIÇÃO DE OBJETOS E PIPES. .......................................................................................120
FIGURA B.1: CÁPSULA COMO CONJUNTO DE CLUSTERS. ............................................................................123
FIGURA B.1: ARQUITETURA GENÉRICA DE COMUNICAÇÃO ........................................................................124

1
Capítulo 1
1.Introdução
O gradual aumento de disponibilidade das redes de alta velocidade vem
possibilitando cada vez mais o desenvolvimento de aplicações multimídia, como
videoconferência, transferência de documentos, trabalho cooperativo, ensino a distância,
correio eletrônico multimídia, vídeo sob demanda e distribuição de vídeo e/ou Áudio.
Essas aplicações, além de exigirem a manipulação de objetos de dados não convencionais
(que exigem taxas de transferência altas e contínuas e apresentação sincronizada dos
dados) têm como requisito comum a necessidade de transmissão de dados para múltiplos
usuários [Soares et al 95]. Essas características requerem atributos dos sistemas de
comunicações1
que ainda não estão plenamente disponíveis nas tecnologias mais comuns
em utilização, como a eficiência na comunicação de grupos de multicast2
.
1
O sistema de comunicação compreende os meios de transmissão e as regras empregadas para a
interligação das entidades participantes.
2
O termo em inglês “multicast” é utilizado no contexto de todo este trabalho, por não encontrarmos uma
boa tradução para português do mesmo, e por ter seu uso amplamente difundido na área de redes de
computadores.

2
Comunicação de grupo em sistemas de computação corresponde à troca de
dados de diferentes mídias entre múltiplas entidades. Essas entidades podem utilizar
diferentes sistemas de comunicação para a sua comunicação: sistemas operacionais e redes
de computadores são alguns exemplos. Em comunicação de grupo, unidades de dados
idênticas de um ou mais transmissores devem ser transmitidas para um grupo de
receptores. Nesse contexto, multicast pode ser utilizado como um eficiente mecanismo de
transferência de dados entre entidades do grupo.
Na literatura, pode-se encontrar um conjunto de definições de serviço de
multicast. Kompella [Kompella et al 93] e Deering [Deering et al 90], por exemplo,
definem multicast como a transmissão simultânea de dados para múltiplos usuários.
Partridge [Partridge 93], define multicast como um serviço inter-rede que permite que
origens enviem uma única cópia de um datagrama (ou célula) para um endereço de grupo,
de modo que o datagrama seja entregue a múltiplos receptores. Nesse trabalho, um
serviço de multicast é definido como um conjunto de procedimentos e interfaces que
permitem enviar mensagens para um grupo de participantes em um ambiente de
processamento e comunicação. A definição de um serviço multicast pode ser realizada de
forma independente da implementação da infra-estrutura de distribuição de mensagens e
das aplicações específicas às quais o serviço é destinado. Um serviço de multicast provê
uma forma primitiva de comunicação de grupo que pode ser utilizado como base para o
oferecimento de serviços mais complexos, destinados a diversas áreas específicas como
trabalho cooperativo, por exemplo. Unicast pode ser definido como um caso particular de
multicast, onde existe apenas um transmissor e um receptor, caracterizando assim uma
comunicação ponto-a-ponto. Outro caso particular de multicast é quando temos uma
transmissão para todos os participantes, caracterizando uma transmissão por difusão
(broadcast).
A arquitetura genérica de um serviço de multicast pode ser dividida em
duas partes: o gerenciamento de grupo e a construção de uma infra-estrutura de
distribuição. Um grupo é definido como um subconjunto de usuários para o qual é
possível a transmissão de mensagens, estando associado a um endereço de multicast

3
[Deering et al 90]. O conceito de grupo permite que várias entidades sejam definidas
como se fossem uma só, pois têm um nome e endereço únicos, denominados
respectivamente de nome do grupo e de endereço de grupo. A existência de um grupo é
independente de qualquer instância de comunicação, ou seja, o grupo existe, independente
de haver troca de informação [ISO 95a]. O gerenciamento de grupo diz respeito a todas
as ações relacionadas a composição do grupo, como manipulação de informações sobre os
seus participantes e o controle sobre a entrada e saída de participantes ao grupo. A
construção da infra-estrutura de distribuição está relacionada à forma de coordenação de
recursos de processamento e comunicação para que a distribuição das mensagens possa
ser efetuada. Em geral, a construção dessa infra-estrutura é efetuada de forma a tentar
minimizar as replicações de mensagens desnecessárias e aumentar o desempenho dos
recursos. Protocolos de roteamento são, em geral, responsáveis por grande parte desse
trabalho no que concerne ao sistema de comunicação propriamente dito. Além disso, a
criação dessa infra-estrutura está intimamente ligada aos mecanismos de provisão da
qualidade de serviço (Quality of Service  QoS) solicitada pelos usuários.
A maioria das soluções que têm sido apresentadas como candidatas à
implementação do serviço de multicast foram projetadas tendo em mente determinadas
condições específicas de infra-estrutura para distribuição de mensagens, ou características
do serviço às quais são destinadas, ou ainda, a forma de gerenciamento dos grupos de
usuários. Com relação à infra-estrutura de distribuição, serviços tem sido implementados,
em geral, de forma totalmente dependente de fatores como a “topologia virtual” do
sistema comunicação. Em relação às características do serviço às quais são destinadas,
muitas propostas são dependentes de características ou propósitos específicos tais como
confiabilidade, ou garantias de retardo máximo e variação de retardo. Em relação ao
gerenciamento dos grupos de usuários, a forma de distribuição e armazenamento das
informações relativas aos grupos determina, muitas vezes, toda a arquitetura e
implementação do serviço.
Técnicas de orientação a objetos (OO) têm sido recentemente aplicadas
com sucesso ao projeto e à implementação de software de comunicação e no

4
desenvolvimento de sistemas distribuídos. Diferentes abordagens têm sido utilizadas
durante os últimos anos, correspondendo a diferentes visões ou enfatizando diferentes
aspectos de utilização da tecnologia OO. Todas essas visões são baseadas na idéia
genérica de que técnicas de implementação e projeto orientado a objetos podem ser
utilizadas para aumentar a modularidade e extensibilidade através da definição de
interfaces estáveis, que encapsulam os detalhes da implementação [Schimidt 93].
Aliados à tecnologia de OO, designs patterns representam soluções
documentadas para problemas de desenvolvimento dentro de um contexto particular
[Gamma et al 95]. Design patterns capturam experiências consagradas de
desenvolvimento e ajudam a promover uma boa prática de projeto. Frameworks [Gamma
et al 95] são aplicações reusáveis “semi-completas” que podem ser especializadas para
produzir aplicações particulares. Designs patterns e frameworks têm sido aplicados em
conjunto para melhorar a qualidade de software de comunicação, como exemplificado no
framework ACE [Schimidt 97].
1.1 Objetivo
Este trabalho visa a apresentar a especificação de um framework para a
implementação de serviços de multicast cuja principal característica é a generalidade e
independência em relação aos possíveis sistemas de comunicação, aplicações e formas de
armazenamento e gerenciamento de grupos. Partindo-se desse framework, é possível
implementar serviços de multicast específicos de uma forma organizada e rápida através
do reuso de toda a estrutura genérica apresentada, aliada a configuração de determinados
componentes do serviço. Esses pontos de configuração do framework são denominados
pontos de flexibilização (ou hot spots) [Pree 95], conforme apresentados no Capítulo 4.
Os pontos de flexibilização do framework para o gerenciamento de grupo
dizem respeito à escala de distribuição das informações do grupo, além da estrutura do
esquema de endereçamento utilizado pelo sistema de comunicação específico, como
descrito na Seção 4.4. No serviço de roteamento, descrito na Seção 4.5, utiliza-se uma

5
única estrutura para a construção do protocolo de roteamento, a partir da qual aplicações
ou serviços específicos podem configurar a estratégia de construção da infra-estrutura de
distribuição multicast.
O framework proposto deverá poder ser utilizado em qualquer nível de
comunicação, quer seja no nível de objetos dentro de uma mesma thread, quer seja de
threads dentro de um processo, quer seja de processos em um nó, ou de entidades em uma
camada de protocolo de uma rede e inter-redes, e assim por diante. Objetiva-se que o
framework seja genérico e recursivo, de forma que possa ser empregado independente do
nível das entidades participantes. A Figura 1.1 mostra possíveis cenários de aplicação do
framework. A figura exemplifica a estruturação recursiva (a existência do serviço de
multicast em um nível permite a sua utilização nos níveis adjacentes), uma vez que o
framework pode ser aplicado para construção do sistema de comunicação no nível de
objetos em uma thread, e no nível de threads em um processo, e assim em diante.
Inter-Rede
Objeto
Thread
Processo
Nó
Figura 1.1: Aplicação do Framework
É importante salientar que o framework especificado não propõe inovações
no roteamento, ou gerenciamento e alocação de endereços de grupo, limitando-se à

6
descrição dos design patterns necessários para a provisão de um serviço de multicast
genérico.
Este trabalho faz parte do Modelo de Referência Unificado [Colcher et al
98] em desenvolvimento no Laboratório TeleMídia da Pontifícia Universidade Católica do
Rio de Janeiro, cuja finalidade principal é oferecer suporte à construção de arquiteturas de
protocolos de comunicação e aplicações distribuídas3
. Maiores detalhes sobre o Modelo
de Referência Unificado podem ser encontrados no APÊNDICE B, e em [Colcher et al
98].
1.2 Organização da Dissertação
O presente trabalho é organizado com se segue. No Capítulo 2 são
apresentadas as características gerais de um ambiente que oferece um serviço de multicast,
além de um conjunto de termos, princípios, definições e características do serviço. Nesse
capítulo, é apresentado, com base em um conjunto de princípios relacionados à provisão
do serviço de multicast, um modelo genérico de operações de grupo e associações de
grupo, bem como os procedimentos básicos para o estabelecimento de uma comunicação
multicast, baseado em um conjunto de recomendações definidas pelo ITU-T [ITU-T X.6]
e pela ISO [ISO 95a, ISO 95b]. Com base nessa terminologia de comunicação multicast,
são traçados os requisitos mínimos para a provisão de um serviço de comunicação
multicast, divididos em duas categorias: gerenciamento de grupo e transmissão multicast.
A partir desses requisitos foi extraído o núcleo dos serviço providos pelo framework
proposto nesse trabalho.
3
O trabalho encontra-se inserido na Experiência de Campo de Faixa Larga do Projeto RAVEL -
Redes de Alta Velocidade. Esse projeto é baseado no convênio de pesquisa existente entra a PUC-Rio e a
Empresa Brasileira de Telecomunicações (EMBRATEL), cujos objetivos incluem o estudo de novos
serviços para redes de banda larga.

7
No Capítulo 3 é feito um levantamento dos principais serviços e protocolos
relacionados a provisão do serviço de gerenciamento de grupo e roteamento multicast. É
feito também nesse capítulo uma revisão geral sobre redes ativas, e de alguns serviços
implementados para a provisão de multicast, de acordo com a filosofia de redes ativas.
A seguir, no Capítulo 4, é feita uma breve introdução a conceitos de
orientação a objetos, e aplicação de patterns e frameworks no desenvolvimento e
implementação de sistemas de comunicação e aplicações distribuídas. Em seguida,
considerando os vários trabalhos apresentados no Capítulo 3, e nos requisitos descritos na
Seção 2.2, é apresentada uma arquitetura genérica para a provisão do serviço de multicast.
Finalmente, ainda nesse capítulo, é feita a descrição do Framework para Provisão do
Serviço de Multicast. Essa descrição é feita detalhando-se os serviços e patterns
componentes do serviço de multicast. Esse capítulo apresenta ainda, para cada
componente do serviço, um exemplo de aplicação do framework. A arquitetura do
framework é apresentada através da utilização da Linguagem de Modelagem Unificada
(UML - Unified Modeling Language) [Booch et al 96].
No Capítulo 5, é apresentada a aplicação do framework como um todo,
juntamente com o Framework para Provisão de Serviço de Qualidade de Serviço (QoS)
[Gomes et al 99], para a implementação de um serviço de transmissão de vídeo para um
grupo de assinantes com diferentes requisitos de qualidade de serviço, em uma rede ATM.
Finalmente, no Capítulo 6 são apresentadas algumas conclusões do
trabalho, e suas principais contribuições, bem como pontos ainda em aberto, que poderão
ser tratados em trabalhos futuros.
A dissertação apresenta ainda um apêndice com detalhes de UML
relevantes a descrição do framework, utilizado no Capítulo 4.

8
Capítulo 2
2.Serviço de Multicast
Neste capítulo são apresentadas as características gerais de um ambiente
que oferece um serviço de multicast, além de definições e características do serviço. Após
essas definições, serão apresentados os requisitos mínimos para a provisão do serviço.
2.1 Modelo de Serviço Multicast
O serviço de multicast é responsável por prover os meios para que uma
única mensagem transmitida pela origem alcance todos os participantes do grupo. O
modelo de serviço multicast é ilustrado na Figura 2.1.
Define-se um ambiente de processamento e comunicação como sendo
formado por um conjunto de entidades usuárias do serviço e por um provedor de serviço,
responsável pelo processamento dessas entidades, assim como pela comunicação entre
elas. Esse ambiente pode ser tão simples quanto um ambiente para a troca de mensagem
entre objetos, presente em uma linguagem de programação OO, ou tão complexo quanto
um ORB [OMG 96], um ambiente de processamento distribuído, formado por um
conjunto de ambientes locais de execução de objetos e pela infra-estrutura de
comunicação entre esses ambientes.

9
MG
MG
MG
MG
Provedor
do Serviço
MG
Membro de Grupo /
Usuário do Serviço Multicast
Serviço Multicast
Figura 2.1: Modelo do Serviço de Multicast
O modelo de multicast descreve o serviço como uma entidade lógica única.
Na prática, esse serviço pode ser provido por entidades internas ao provedor de serviço de
modo centralizado ou distribuído. Estas entidades podem pertencer ou não ao sistema de
comunicação utilizado. Estas entidades podem ainda pertencer ao mesmo sistema de
comunicação, ou a diferentes sistemas de comunicação. A Figura 2.2 ilustra alguns
exemplos de implementação do serviço de multicast, descritos a seguir. Esses exemplos
não pretendem ser exaustivos, uma vez que outras implementações são possíveis.
A provisão do serviço de multicast depende muito do suporte à
comunicação multicast oferecido pelo sistema de comunicação utilizado. Em sistemas que
não possuem capacidade de comunicação multicast, entidades internas ao provedor de
serviço podem se responsabilizar por prover o encaminhamento dos dados aos membros
do grupo, ocultando do usuário todos os procedimentos necessários para o
encaminhamento dos dados (resolução de endereço, criação e manutenção da infra-
estrutura de distribuição, etc.), como pode ser visto na Figura 2.2 a). Por outro lado, se o
sistema de comunicação já oferecer um suporte à comunicação multicast (ou broadcast),
cabe ao provedor do serviço apenas mapear os mecanismos de multicast exigidos pelo
usuário, para os mecanismos oferecidos pelo sistema de comunicação (nativos), como por

10
exemplo, mapear um endereço de grupo do nível do usuário para um endereço de grupo
equivalente do nível do sistema de comunicação. Dessa forma, cabe às entidades internas
ao sistema de comunicação, prover os mecanismos do serviço de multicast, como
mostrado na Figura 2.2 b).
Sistema de Comunicação
MG
Provedor
do Serviço
MG
MGMG
Servidor de Multicast
MG
Provedor
do Serviço
MG
MGMG
Entidade interna ao
sistema de comunicação
a) b)
Provedor
do Serviço
MG
MG
MG
c)
MG
MG
MG
Entidade de interconexão
Figura 2.2: Exemplo de implementações do Serviço de multicast
O serviço de multicast pode requerer uma capacidade de comunicação
entre entidades internas do provedor de serviço ligadas a diferentes sistemas de
comunicação, como ilustrado na Figura 2.2 c). A comunicação entre as entidades internas
ao provedor de serviço é provida de tal forma que usuários externos (membros de grupo)
vêem o serviço como provido por uma única entidade lógica.
O modelo de serviço multicast aqui descrito é baseado em um conjunto de
recomendações definidas pelo ITU-T [ITU-T X.6] e pela ISO [ISO 95a, ISO 95b].

11
2.1.1 Multicast, Multiponto ou Multiway ?
É importante notar a diferença entre os termos multicast, multiponto e
multiway. Na terminologia IP, a comunicação entre um grupo de participantes é
refenciado como multicast [Deering et al 90]. O ATM Forum tem adotado o termo
multiway uma vez que multicast pode ser confundido com comunicação ponto-a-
multiponto. Algumas pesquisas [Mauthe et al 95, Pasquale et al 98, Szyperski et al 93]
argumentam que uma vez que o termo multicast foi visto originalmente como uma
restrição de comunicação broadcast em um meio de transmissão por difusão, não é
apropriado para uso em situações que se utilizem de infra-estruturas que não forneçam
suporte a comunicação por difusão, como é o caso das redes ATM. Por isso, argumentou-
se que tanto os termos multiponto como multiway deveriam ser usados para evitar esse
tipo de confusão. Multiponto é uma generalização de ponto a ponto para indicar múltiplos
participantes de uma mesma comunicação, e multiway é um conceito similar que enfatiza
que múltiplos participantes podem comunicar-se entre sim ao mesmo tempo.
Nesse trabalho, independente do suporte a comunicação por difusão dado
pelo sistema de comunicação, multicast será usado para descrever o serviço de suporte a
comunicação de grupo. Mas em alguns pontos os três termos serão usados alternadamente
para preservar os termos usados em algumas referências. O termo ponto a multiponto será
usado para descrever conexões ou canais de comunicação em que existe apenas um
transmissor enviando dados para um grupo de receptores.
2.1.2 Grupos
O conceito de grupo permite que várias entidades sejam definidas como se
fossem uma só, pois têm um nome e endereço únicos denominados respectivamente de
nome do grupo e de endereço de grupo. A existência de um grupo é independente de
qualquer instância de comunicação, ou seja, o grupo existe independente de haver troca de
informação [ISO 95a].

12
Uma instância de um grupo é composta de n entidades, chamadas
membros. A criação de um grupo é necessária para identificar o subconjunto de membros
que estejam participando de uma comunicação. Essas entidades podem ser alcançadas
pelo endereço (ou nome) do grupo, após terem passado pelos processos de registro, e
adesão, explicados mais adiante.
Grupos de multicast podem ser classificados de acordo com algumas
caraterísticas, como a dinâmica de seus membros, ou seu grau de distribuição. Abaixo são
listadas algumas caraterísticas que definem os grupos:
• Dinâmico – a sua população (membros) muda dinamicamente;
• Estático – a população do grupo não muda;
• Definido – quando é possível definir a lista completa de participantes.
Um grupo definido é dito completamente conhecido se todos os
participantes se conhecem, caso contrário é dito parcialmente
conhecido;
• Indefinido – quando não é possível determinar uma lista completa de
participantes4
.
De acordo com a distribuição de seus membros através do sistema de
comunicação, grupos multicast podem ser divididos em três categorias [Deering et al 90].
Grupos difundidos possuem membros em todos ou quase todos os enlaces
ou redes na inter-rede. Exemplos de grupos difundidos são serviços de diretório
distribuídos. Tais grupos tendem a ter um tempo de vida muito longo, tendo endereços
multicast bem conhecidos.
4
Dentro de um grupo indefinido, um participante pode ser conhecido por apenas alguns dos outros
participantes. Nesse caso, os membros são chamados de membros conhecidos.

13
Grupos esparsos têm membros em apenas um pequeno número de enlaces.
Exemplos de grupos esparsos são conferências de tempo-real, ou bancos de dados
replicados. Tais grupos podem ter um tempo de vida longo ou passageiro.
Grupos locais possuem membros em apenas um único enlace ou um
conjunto de enlaces dentro de um subdomínio administrativo da inter-rede. Exemplos de
grupos locais são aplicações paralelas distribuídas ou jogos executados dentro de um
único domínio5
. Tais grupos tendem a ser passageiros, existindo apenas enquanto
necessário para a execução de um único programa.
Para um grupo difundido, uma facilidade de broadcast eficiente que
transporte um pacote multicast para todos os enlaces através de uma árvore de entrega de
menor caminho pode oferecer um custo de entrega significantemente menor e retardos de
entrega menores do que enviar pacotes unicast individuais para cada membro do grupo.
Para alguns grupos difundidos, tais como grupos de servidores de diretório,
é essencial que um pacote multicast não seja entregue para todos os membros do grupo,
mas apenas para vizinhos mais próximos. Isso é obtido pela facilidade de controle de
escopo6
, que permite que um transmissor limite a distância de propagação de um pacote
multicast. Não apenas é crucial para a escalabilidade de serviços difundidos, tais como
serviço de diretório, como também permite que estações evitem ser bombardeadas por
respostas de grupos “populares” [Deering et al 90].
A distinção entre grupos difundidos e esparsos é baseada no custo relativo
de entrega broadcast, comparada a entrega multicast seletiva. Entrega broadcast implica
no custo de entrega para todos os enlaces, independente se membros do grupo estão
presentes ou não nesse enlaces (caro para grupos esparsos), ao passo que entrega seletiva
5
Um domínio está associado a um espaço homogêneo de endereçamento, além de definir o espaço de
transmissão broadcast [Cecilio 97].
6
Um exemplo de controle de escopo pode ser conseguido através do campo TTL de um pacote IP.

14
recai no custo de tráfego de controle no qual os roteadores “aprendem” onde os membros
do grupo estão localizados (caro para grupos difundidos). O custo exato depende da
topologia particular da inter-rede, as distribuições dos tráfegos multicast, e os algoritmos
de roteamento em uso. Assim, o limite entre grupos difundidos e esparsos varia de inter-
rede para inter-rede.
Grupos locais são eficientemente tratados por um serviço de entrega
multicast seletiva. Se todos os transmissores para um grupo local estão na mesma
localidade, controle de escopo combinado com entrega broadcast pode prover multicast
com baixo overhead.
Independente do tipo de grupo, é importante que as características de
entrega de pacotes multicast sejam as mesma para pacotes unicast. Em particular, um
pacote multicast deve ser entregue para cada membro de seu grupo destino (dentro do
escopo especificado) com probabilidade e retardo muito próximos de um pacote unicast
enviado para aquele mesmo membro. Essa propriedade dá aos protocolos de mais alto
nível uma base para o tratamento de perda de pacotes por retransmissão. Baixo retardo é
uma importante propriedade para um número de aplicações multicast, tais como
conferências distribuídas, computação paralela e reserva de recursos. Além do retardo de
entrega básico, a facilidade de multicast deve minimizar o retardo entre o tempo que uma
estação une-se a um grupo e o tempo que ele começa a receber pacotes endereçados para
aquele grupo, conhecido como latência de união7
. Baixa latência de união é importante
para minimizar a perda de pacotes após a união e para facilitar sincronização com a
entrega unicast.
7
Em uma rede local multiponto, por exemplo, esse tempo é geralmente apenas o necessário para atualizar
o filtro de endereço local.

15
2.1.3 Associações de Grupo e Conversação
A partir do estabelecimento de um grupo, pode-se fazer associações entre
membros deste grupo, denominadas de associações de grupos8
, com o propósito de
transferir dados [ISO 95a]. O conceito de associação de grupo engloba ambos os modos
de transmissão, com ou sem conexão. Os membros que aceitam participar de uma
associação de grupo são denominados de participantes desta associação.
Conversações são efetivamente os canais criados num grupo para que haja
troca de informações entre membros do grupo [ISO 95a]. Um grupo pode ter várias
conversações ocorrendo simultaneamente, e cada membro pode também realizar diferentes
conversações ao mesmo tempo. Conversações podem ser classificadas em simplex
multicast, duplex multicast, N-plex multicast, ou unicast. Em conversações simplex
multicast, um membro manda informações para todos os outros membros do grupo, que
só recebem dados. Em conversações duplex multicast um único membro pode mandar
mensagens para todos os outros membros da conversação, e esses membros podem enviar
dados de volta somente para esse membro central. Conversações N-plex multicast
permitem que todos os membros mandem e recebam dados dos outros membros, isto é,
todo mundo se comunica com todo mundo. Conversações em que apenas um membro
comunica-se com um outro, um a um, são conversações unicast.
Uma associação pode ser vista como composta de várias sub-associações,
cada qual composta por n conversações.
8
Associação de grupo, segundo a recomendação proposta pelo ITU-T [ITU-T X.6], é conhecida também
como conexão de grupo, ou chamada multicast, com a diferença de que o serviço previsto pelo ITU é
orientado a conexão.

16
2.1.4 Modelo de Serviço de Operação de Grupo
O modelo de serviço de operação de grupo define um conjunto de
operações (e as respectivas operações inversas) necessárias para a constituição e
manutenção de grupos (controle de entrada e saída de membros ao grupo) [ISO 95a].
2.1.4.1 Estabelecimento do Grupo
Esta primeira operação refere-se a fase de criação de um grupo, sendo
realizada através da criação de estruturas de grupo. Este procedimento permite a um
criador de grupo9
especificar um conjunto de regras que definem o perfil dos futuros
membros do grupo.
2.1.4.2 Registro de Grupo
Procedimento de iniciação que permite a uma entidade vir a ser instanciada
como membro de um grupo. A entidade se torna conhecida pela gerência do grupo, o que
permite depois passar por uma operação de adesão e assim vir a se tornar um membro
deste grupo. Antes de ser registrada, a entidade tem que se submeter as regras que
definem o grupo. Para isso, a entidade precisa apresentar suas caraterísticas ao grupo, por
exemplo, fornecendo o endereço para ser incluído nos diretórios e tabelas do grupo, e os
parâmetros que caracterizam suas capacidades para que sejam aplicadas a ela em
comunicações posteriores.
2.1.4.3 Adesão ao Grupo
Torna uma entidade já registrada membro de um grupo. Pode-se fazer uma
analogia entre a operação de adesão com a facilidade de um recurso passar de off-line a
on-line (e vice-versa), sem que o sistema ache que o recurso deixou de existir. Um grupo
é portanto composto por entidades que passaram pelas fases de registro e adesão.
9
O criador de grupo definido pelo ITU-T [ITU-T X.6] é chamado de Controlador de grupo de multicast.

17
Adesões a grupos podem, opcionalmente, gerar eventos de notificação para
indicar a entrada do novo participante ao grupo. Essas notificações podem ser utilizadas,
por exemplo, para que transmissores que tenham criado uma associação possam adicionar
o novo membro do grupo à associação.
2.1.4.4 Estado do Grupo
O estado do grupo provê informações sobre o grupo de multicast.
As seguintes informações podem ser providas pelos procedimentos de
consulta ao estado do grupo:
• Lista de membros do grupo de multicast;
• Informações de mapeamento de endereço de grupo, quer seja para um
endereço de grupo do sistema de comunicação do nível inferior, quer
seja para os endereços unicast de todos os membros do grupo;
• Que membro é o controlador do grupo;
• Atributos de qualidade de serviço do grupo, ou de membros do grupo;
• Associações de grupo ativas.
2.1.5 Modelo de Serviço de Operação da Associação de Grupo
O modelo de serviço de operação de associação define um conjunto de
operações para a criação e manutenção de associações para a transferência de informações
entre os membros de um grupo de multicast.
2.1.5.1 Estabelecimento e Liberação
Na operação de estabelecimento, um membro de um grupo cria uma
associação entre os membros desse grupo. Nessa operação são definidas todas as
características da associação, como por exemplo, a qualidade de serviço (QoS) da

18
associação. O membro que inicia o estabelecimento da associação é chamado de iniciador.
A operação de estabelecimento da associação é feita através de um pedido aos membros
do grupo, podendo estes aceitarem ou não.
Define-se como condições de estabelecimento, as condições mínimas
especificadas pelo iniciador para que a associação seja criada, tendo que ser coerente com
as caraterísticas do grupo. Se as condições mínimas forem alcançadas, uma nova
associação é criada e os participantes dessa associação formam um grupo ativo.
A operação de liberação é utilizada para encerrar uma associação, podendo
ser iniciada pelo usuário ou pelo provedor (quando as condições de integridade da
associação não mais forem alcançadas).
2.1.5.2 Adesão (Join) e Abandono (Leave)
A operação de adesão a uma associação permite que uma entidade se junte
a uma associação de acordo com as regras da associação. Existem dois tipos de adesão:
• Adesão por convite – onde os participantes podem convidar uma
entidade a se juntar à associação;
• Adesão por chamada – a entidade requisita a participação numa
associação existente. Essa operação assume que a entidade sabe que a
associação foi previamente estabelecida.
A operação de abandono de uma associação permite que o participante
deixe a associação, podendo ser iniciado pelo participante que quer deixar a associação ou
por outro participante. A operação também pode ser iniciada pelo provedor do serviço,
quando ele não puder mais satisfazer à qualidade do serviço negociada durante o
procedimento de estabelecimento da associação.
Opcionalmente, notificações podem ser feitas para indicar aos outros
membros do grupo sobre a adesão ou saída de um membro a uma dada associação.

19
2.1.5.3 Transferência de Dados
Transferência de (N-1)SDUs entre os participantes de uma associação do
nível N de acordo com alguns parâmetros de qualidade de serviço (QoS) negociados entre
os participantes da associação. A transferência de dados só é permitida se as condições de
integridade da associação são satisfeitas.
2.1.6 Procedimentos para o estabelecimento de uma comunicação
multicast
Na comunicação multicast, um usuário manda dados para um determinado
grupo de usuários, e também pode receber dados dos mesmos. Para isso são formados
grupos de multicast. Nesta seção são expostos os procedimentos necessários para a
transferência de dados multicast, considerando que o grupo já foi criado.
2.1.6.1 Diagrama de Estados
Para que uma entidade possa participar de uma comunicação multicast, é
necessário que se associe um grupo já formado com o qual ela deseja trocar dados.
Considerando que o grupo já esteja formado, e registrado, temos duas fases no diagrama
de estados: (i) a fase de adesão (onde a entidade se une a determinado grupo), e (ii) a fase
de transferência de dados.
O primeiro estado, no início da fase de adesão, é o estado de grupo criado.
Nesse estado, assume-se que:
• Já existe uma associação criada entre os membros do grupo;
• As condições de integridade da associação estão determinadas e não
são negociáveis;
• Existe uma lista de conversações no grupo;

20
• Existe uma lista de QoS, descrevendo a qualidade de serviço de cada
conversação em curso.
A Figura 2.2 apresenta o diagrama de estados de uma comunicação
multicast, cuja descrição é realizada no próximo item. As transições do diagrama estão
descritas na Tabela 2-1.
Espera_bind
OUT
Grupo criado
Espera_bind
IN
Bound
Espera_join
IN
Espera_join
OUT
Alocado
Transferência9
1
19
19
20
22
4
21
3
2
8
17
7
5
15
16
6
15 18
13
11
12
10
14
Figura 2.3: Diagrama de Estados

21
2.1.6.2 Tabela de Primitivas e Parâmetros
Tabela 2-1: Tabela de Primitivas para o estabelecimento de uma comunicação multicast
Fase Primitiva de Serviço Parâmetros
1 BIND.requestor.submit Endereço chamador, end. Chamado, condições, QoS
2 BIND.requestor.deliver Endereço chamador, end. Chamado, condições, QoS
3 BIND.acceptor.submit Endereço chamador, end. Chamado, condições, QoS
4 BIND.acceptor.deliver Endereço chamador, end. Chamado, condições, QoS
5 JOIN.requestor.submit Endereço chamador, end. Chamado, condições, QoS
6 JOIN.requestor.deliver Endereço chamador, end. Chamado, condições, QoS
7 JOIN.acceptor.submit Endereço chamador, end. Chamado, condições, QoS
8
Adesão
JOIN.acceptor.deliver endereço chamador, end. Chamado, condições, QoS
9 DATA.requestor.submit referência chamador, ref. Chamado, dados do
usuário
10 DATA.acceptor.deliver referência chamador, ref. Chamado, dados do
usuário
11 PAUSE.requestor.submit endereço chamador, razão
12 PAUSE.acceptor.deliver endereço chamador, razão
13 READY.acceptor.submit endereço chamador
14
Dado
REPORT.acceptor.deliver endereço chamador
15 LEAVE.requestor.submit endereço chamador, endereço chamado, razão
16 LEAVE.requestor.deliver endereço chamador, endereço chamado, razão
17 LEAVE.acceptor.submit endereço chamador, endereço chamado, razão
18 LEAVE.acceptor.deliver endereço chamador, endereço chamado, razão
19 UNBIND.requestor.submit endereço chamador, endereço chamado
20 UNBIND.requestor.deliver endereço chamador, endereço chamado
21 UNBIND.acceptor.submit endereço chamador, endereço chamado
22
Saída
UNBIND.acceptor.deliver endereço chamador, endereço chamado
As primitivas requestor são iniciadas pelo próprio usuário, e as primitivas
acceptor são iniciadas pelo provedor do serviço. Existem quatro estados principais: grupo
criado, bound, alocado, e transferência.

22
2.1.6.3 Descrição dos Procedimentos do Diagrama de Estados
Fase de Adesão
• BIND:
No caso de um usuário iniciar o pedido de entrada na associação:
1. Quando um usuário deseja iniciar ou se juntar a uma
associação, ele manda ao provedor um
BIND.requestor.submit(endereço chamador, endereço
chamado, condições de associação, QoS), e entra no estado
espera_Bind OUT. A associação é identificada pelo endereço
chamado (passado como parâmetro da primitiva). Essa
primitiva também manda a QoS, pois ela pode ter sido
modificada pelo usuário em algum momento depois que ele se
tornou integrante do grupo.
2. Em resposta a um BIND.requestor.submit, o provedor obtém
informações sobre essa associação através de troca de PDUs
internas com os participantes da associação. Em seguida, o
provedor responde ao usuário com um BIND.requestor.deliver,
levando como parâmetros as condições de integridade e QoS
mais recentes na associação, e fazendo com que o usuário passe
para o estado bound.
No caso do provedor pedir ao usuário que se associe
1. O provedor manda ao usuário2 uma primitiva
BIND.acceptor.deliver (ao iniciar uma associação após o
pedido feito por um usuário1). Essa primitiva contém os
parâmetros de QoS que o usuário1 mandou ao fazer o pedido,
ou a QoS modificada de acordo com a capacidade do provedor.

23
2. O usuário2 vai então para o estado espera_bind IN. Se o
usuário2 aceitar as condições, ele manda ao provedor uma
primitiva BIND.acceptor.submit com a QoS que ele pode
manter e entra no estado espera_bind OUT. Nesse estágio, o
usuário2 ainda não sabe qual será a QoS final negociada.
3. O Provedor passa ao usuário2 a QoS final, conhecida através de
negociações com os outros usuário da associação, através da
primitiva BIND.requestor.deliver e o usuário2 passa ao estado
Bound.
• JOIN
No caso do usuário iniciar o pedido:
1. Quando o usuário está no estado Bound e aceita as condições
de integridade e QoS definidas pelo provedor, ele se une à
associação mandando ao provedor um JOIN.requestor.submit,
sem mais negociações de QoS e passa para o estado
espera_join OUT.
2. O provedor troca PDUs internas com os componentes da
associação, para saber das atuais condições de integridade da
associação. Caso sejam satisfeitas, ele responde ao usuário com
uma primitiva JOIN.requestor.deliver, contendo o valor da QoS
final negociada. O usuário passa então para o estado Alocado.
No caso do pedido iniciado pelo provedor:
1. O provedor convida um usuário a entrar na associação
mandando uma primitiva JOIN.accept.deliver e o usuário entra
no estado espera_join IN.

24
2. Se o usuário aceita as condições, manda uma primitiva
JOIN.acceptor.submit e passa para o estado alocado.
A negociação de QoS é feita durante o BIND, e a negociação das
condições de integridade do grupo feita durante o JOIN.
O estado final da fase de alocação é o estado alocado. Desse estado, são
iniciadas as tentativas de transferência de dados. Nesse estado podem ou não existir
conversações abertas. Nesse caso, provedor é quem decide estabelecer conexões
multiponto para uma conversação dependendo das condições de QoS.
Fase de Liberação
• UNBIND
Pode acorrer mediante as seguintes condições: (i) no caso do usuário
querer remover o seu binding; (ii) no caso do provedor querer remover o binding do
usuário ou (iii) no caso do provedor indicar ao usuário que seu binding à associação de
grupo não é possível.
Procedimentos para a condição (i):
1. Caso o usuário queira remover o seu binding (após ter enviado
a primitiva BIND.requestor.submit) e passado ao estado
espera_bind OUT, ele envia ao provedor a primitiva
UNBIND.requestor.submit e retorna ao estado de grupo criado.
2. Caso o usuário não queira fazer o binding após receber do
provedor o BIND.acceptor.deliver, no estado espera_bind IN,
ele envia ao provedor o UNBIND.acceptor.submit e retorna ao
estado de grupo criado.
3. Caso o usuário queira fazer um UNBIND quando se encontra
no estado bound, ele envia uma primitiva

25
UNBIND.requestor.submit ao provedor e retorna ao estado de
grupo criado.
Procedimentos para a condição (ii):
1. Se o usuário estiver no estado espera_bind OUT, tanto devido
a uma iniciativa do usuário através do envio da primitiva
BIND.requestor.submit, tanto por iniciativa do provedor
através do envia da primitiva BIND.acceptor.deliver, (e
confirmado pelo usuário através de um BIND.acceptor.submit),
o provedor pode enviar uma primitiva
UNBIND.requestor.deliver, indicando que não foi possível o
bind à associação, provocando um retorno ao estado grupo
criado.
Procedimentos para a condição (iii):
1. Se o usuário estiver no estado bound, o provedor pode solicitar
o seu UNBIND enviando uma primitiva
UNBIND.acceptor.deliver, provocando uma transição ao
estado de grupo criado.
• LEAVE
Pode ocorrer de acordo com as seguintes condições: (i) quando um usuário
desejar sair da associação; (ii) no caso do provedor querer remover algum usuário, e (iii)
quando o provedor avisa ao usuário que não foi possível realizar o JOIN à associação.
Procedimentos para a condição (i):
1. Caso o usuário queira remover o seu pedido de adesão à
associação a partir do estado espera_join OUT (alcançado após
o envio da primitiva JOIN.requestor.submit), ele envia ao

26
provedor a primitiva LEAVE.requestor.submit e retorna ao
estado bound.
2. Caso o usuário não queira fazer o JOIN após receber do
provedor um JOIN.acceptor.deliver (estando no estado
espera_join IN), ele envia ao provedor o
LEAVE.acceptor.submit e retorna ao estado bound.
3. Caso o usuário queira fazer um LEAVE quando se encontra no
estado alocado, ele envia uma primitiva
LEAVE.requestor.submit ao provedor, e retorna ao estado
bound.
Procedimentos para a condição (ii):
1. Se o usuário estiver no estado espera_join OUT, alcançado
depois de enviar a primitiva JOIN.requestor.submit ao
provedor, o mesmo pode enviar uma primitiva
LEAVE.requestor.deliver, indicando que não foi possível a
adesão à associação, retornando o usuário ao estado bound.
Procedimentos para a condição (iii):
1. Se o usuário estiver no estado alocado, o provedor pode
solicitar o sua saída enviando a ele a primitiva
LEAVE.acceptor.deliver, passando então ao estado bound.
Fase de Transferência de Dados
1. Quando o provedor determina que a transferência de dados
pode ser feita de uma forma segura e as condições de
integridade do grupo são satisfeitas, ele manda ao usuário uma
primitiva READY.acceptor.deliver e o usuário entra no estado
de transferência.

27
2. No estado de transferência, o usuário requisita transferência de
dados através da primitiva DATA.requestor.submit.
3. O provedor então envia os dados para o destino usando
DATA.requestor.deliver.
4. Quando ocorre uma falha nas condições de integridade do
grupo ou QoS, o provedor envia aos usuários uma primitiva
PAUSE.acceptor.deliver e suspende a transferência de dados. O
usuário volta ao estado alocado.
5. O usuário pode suspender a transferência de dados enviando ao
provedor uma primitiva PAUSE.requestor.submit. O usuário
volta ao estado alocado.
6. Se os valores de threshold de um ou mais parâmetros de QoS
são alcançados, o provedor avisa o usuário através da primitiva
REPORT.acceptor.deliver.
2.2 Requisitos e Características de um Serviço de
Multicast
Aplicações de grupo adicionam uma série de novas funções às arquiteturas
de sistemas de computação (incluindo sistemas operacionais, redes e seus protocolos de
comunicação, etc.). Embora os requisitos de aplicações sejam muitas vezes específicos,
certas funções genéricas para o suporte a comunicação de grupo podem ser identificadas.
Nessa sessão, serão listados alguns desses requisitos, visando a especificação de um
serviço genérico de multicast.

28
2.2.1 Gerenciamento de Grupo
Nesse trabalho, o termo gerenciamento de grupo é utilizado para descrever
todas as ações relacionadas à composição do grupo, como manipulação de informações
sobre os seus participantes, e o controle de acesso ao grupo, isto é, controle sobre a
entrada e saída de participantes ao grupo.
Grupos devem ser administrados por um gerenciador de grupo. O
gerenciador de grupo deve ser distribuído por todas as camadas da arquitetura do sistema
(abstrações do sistema de comunicação), isto é, cada nível da arquitetura deve possuir um
gerenciador. Em cada nível o gerenciador pode ser centralizado, com um gerenciador de
grupo executando todas as funções relacionadas à administração dos grupos, ou
descentralizado.
O gerenciador de grupo é ativado pelo iniciador da comunicação de grupo.
Ele deve negociar um único identificador de grupo que será associado ao grupo.
Dependendo da localização da comunicação de grupo, isso pode envolver outros
gerenciadores de grupo e gerenciadores de endereço. Se o grupo for destruído, o
gerenciador de grupo deve liberar o endereço de grupo e possivelmente notificar outras
entidades que o grupo não mais existe.
O gerenciamento de grupo envolve o gerenciamento de seus integrantes,
seus papéis e estados, além do gerenciamento das características do grupo. Para grupos
dinâmicos, deve ser possível adicionar e remover membros ao grupo, alterar seus papéis, e
as características do grupo.
O gerenciamento de grupo deve oferecer um serviço de diretório, isto é,
prover um serviço de informações sobre o grupo e seus integrantes. Informações sobre
endereços, estado e características do grupo e dos membros do grupo devem ser
fornecidas aos membros do grupo e entidades que não pertençam ao grupo.

29
O gerenciamento do grupo deve também gerenciar uma lista de
notificações. Notificações sobre adesões e abandonos de grupo é uma tarefa do
gerenciador do grupo.
As ações relacionadas ao gerenciamento de grupo dependem da natureza
da aplicação. No entanto, algumas funções podem ser consideradas genéricas. Dentre elas
podemos destacas:
• Criação e extinção de grupo e a associação das características de grupo
são funções básicas necessárias. Durante a criação do grupo, um único
identificador de grupo deve ser associado ao mesmo.
• Gerenciamento de grupos e membros do grupos, e manutenção de suas
características também se fazem necessárias. Isso inclui o suporte a
adesões e saída de membros de grupo, e alterações dinâmicas das
características do grupo e seus membros. Nesse contexto, um requisito
chave para aplicações de grupo diz respeito a sua escalabilidade.
• Gerenciamento de informações sobre os membros do grupo. A instância
de gerenciamento deve ser capaz de fornecer informações sobre o
grupo e responder a consultas a respeito de seus membros. Isso inclui o
mapeamento do endereço do grupo e aos vários endereços dos
participantes do grupo.
2.2.2 Transmissão Multicast
Para um serviço de transmissão multicast, o provedor do serviço pode
utilizar diversos sistemas de comunicação interligados e estruturados em diversos níveis de
abstração, como mostrado na Figura 2.2c). Uma outra visão dessa arquitetura pode ser
vista na Figura 2.4. Nesse contexto, é necessário a definição de um eficiente mecanismo
de resolução de endereços entre níveis adjacentes, bem como para a construção da infra-
estrutura de distribuição e roteamento.

30
Resolução de endereço é definida como o mapeamento entre endereços de
níveis adjacentes de uma arquitetura de comunicação, isto é, o mapeamento entre um
endereço de nível N e o endereço do nível N-1 associado a uma entidade do nível N [X200
97]. É função da entidade do nível N fazer esse mapeamento.
UUNN
UUNN
EENN EENN EENN
Sistema de ComunicaçãoSistema de Comunicação (N)(N)
Sistema de ComunicaçãoSistema de Comunicação (N-1)(N-1)
N-SAP N-SAP
N-1-SAP N-1-SAP N-1-SAP
EENN Entidade do Serviço (N)UUNN Usuário do Serviço (N)
Figura 2.4: Arquitetura do Sistema de Comunicação
Os sistemas de comunicação podem ser formados pela interconexão de
diferentes sistemas de comunicação. Para permitir a comunicação entre entidades ligadas a
diferentes sistemas de comunicação pode-se fazer uso de entidades intermediárias. Para
isso, é necessário definir um caminho através dessas entidades intermediárias, formando
assim uma árvore de distribuição. Uma árvore de multicast (ou canal de comunicação
multicast) é definida por uma comunicação 1 x n entre uma entidade origem e n destinos.
Um protocolo de roteamento multicast é responsável pela construção de
árvores de distribuição multicast e por habilitar a transmissão de dados multicast
[Kompella et al 93]. Existem algumas técnicas exploradas por protocolos de roteamento.
Flooding e Árvore Geradora [Maufer et al 97] são dois algoritmos que podem ser usados
para construir protocolos de roteamento primitivos. As técnicas são primitivas porque
tendem a desperdiçar banda passante ou requerem uma grande quantidade de recursos
computacionais entre as entidades de roteamento envolvidas. Técnicas de construção de

31
árvores baseadas na origem do fluxo de dados [Maufer et al 97] mostram-se mais
eficientes, uma vez que fundamentam-se na construção de uma árvore para cada
transmissor de um grupo. A diferença entre as técnicas baseadas na origem encontra-se na
eficiência de construção da árvore, na demanda de banda passante e de recursos das
entidades de roteamento requeridos para construí-las. As técnicas de transmissão
multicast mais recentes baseiam-se em uma árvore de entrega compartilhada [Ballardie
97a]. Diferentemente dos algoritmos de árvore de menor caminho [Maufer et al 97], que
constroem uma árvore para cada origem ou par (origem, grupo), algoritmos de árvore
compartilhada constroem uma única árvore de entrega que é compartilhada por todos os
membros do grupo. No capítulo seguinte, veremos em mais detalhes alguns desses
protocolos.
Após a criação da infra-estrutura de comunicação, o processo de
transmissão pode ser iniciado, de acordo com os parâmetros da qualidade de serviço
exigidos pelas entidades.
2.3 Resumo
Neste capítulo, a terminologia básica a ser usada na descrição do serviço de
comunicação multicast foi apresentado. Também foi apresentado, com base em um
conjunto de princípios relacionados à provisão do serviço de multicast, um modelo
genérico de operações de grupo e associações de grupo, bem como os procedimentos
básicos para o estabelecimento de uma comunicação multicast.
Com base nessa terminologia de comunicação multicast, foram traçados os
requisitos mínimos para a provisão de um serviço de comunicação multicast, divididos em
duas categorias: gerenciamento de grupo e transmissão multicast.

32
Capítulo 3
3.Trabalhos Relacionados: Soluções
Presentes
3.1 Serviços e Protocolos de Multicast
Serviços de multicast são oferecidos em diferentes sistemas e diferentes
níveis de arquitetura. Usuários desses serviços também variam de acordo com a
característica do ambiente em que o serviço é oferecido. Em um sistema operacional, por
exemplo, um grupo pode ser definido como um conjunto de processos, que se comunicam
através da troca de mensagens [Tanenbaum 92]. No sistema ANSA (Advanced Network
Systems Architecture), grupos de objetos são introduzidos como uma abstração para
comunicação de grupo [Mauthe et al 95]. Grupos possuem uma interface de
gerenciamento que oferece funções para a adesão e abandono de grupo, adição e remoção
de categorias de policiamento, etc. Em sistemas de comunicação, multicast é oferecido
por protocolos de uma camada a entidades das camadas imediatamente superiores.

33
Em redes locais, a comunicação de grupo depende, em geral, da capacidade
da rede subjacente para a difusão de mensagens. Os protocolos padronizados pelo IEEE
802.x e FDDI suportam transmissão multicast [Soares et al 95].
3.1.1 IP Multicast
O trabalho de Deering , IP Multicast [Deering 89], foi um dos primeiros a
considerar o suporte a multicast num ambiente composto por diversas redes.
Essencialmente, Deering projetou um método para roteadores determinarem,
dinamicamente, como datagramas IP devem ser transmitidos para grupos de multicast.
Quando um roteador recebe um pacote endereçado a um grupo, envia-o por todas as
interfaces que levam a membros do grupo. Se um grupo multicast estende-se por múltiplas
redes, informações de membros de grupo são trocadas entre os roteadores pelo Protocolo
de Gerenciamento de Grupo Inter-rede (IGMP – Internet Group Management Protocol)
[Fenner 97].
Modificações que permitem uma estação transmitir IP Multicast não são
difíceis. O software IP deve permitir que um programa de aplicação especifique um
endereço de multicast como endereço de destino IP, e o software de interface de rede
deve ser capaz de mapear um endereço IP Multicast para o endereço de multicast do
hardware correspondente (ou usar broadcast se o hardware não suportar multicast).
Extensões ao software da estação para receber datagramas IP Multicast são
um pouco mais complexas. O software IP da estação deve ter uma interface que permita a
um programa de aplicação declarar que ele quer fazer parte de um grupo particular de
multicast, ou abandoná-lo. Desta forma, a interface do serviço IP deve prover duas novas
operações: JoinHostGroup(group_address, interface), que requisita que a estação se
torne membro do grupo identificado por “group_address” na interface de rede dada; e
LeaveHostGroup(group_address, interface), que requisita que estação abandone o grupo.
Se múltiplos programas de aplicação unem-se a um mesmo grupo, o software IP deve
passar a cada um deles uma cópia dos datagramas recebidos destinados a este grupo. Se
todas os programas de aplicação deixarem o grupo, a estação não mais deve fazer parte

34
do grupo. Além disso, como será visto na próxima sessão, a estação deve executar um
protocolo que informe os roteadores de multicast locais o seu estado de participação em
grupos.
Muito da complexidade da recepção vem da idéia básica de que “estações
unem-se a grupos de multicast IP específicos em redes específicas”. Isto é, uma estação
com múltiplas conexões de rede pode unir-se a um grupo de multicast particular em uma
rede (interface), e não em uma outra10
. Porque associação a grupos é relacionada com
redes particulares, o software deve manter listas separadas de endereços de multicast para
cada rede a qual a máquina está ligada. Além disso, um programa de aplicação deve
especificar uma rede particular quando requisita uma adesão ou saída de um grupo de
multicast. Para suportar a recepção de datagramas de IP Multicast, o módulo IP deve ser
estendido para manter uma lista de membros de grupos associados a cada interface de
rede.
Em estações com mais de uma interface de rede, se um datagrama chegar
por uma interface, destinado a um grupo que a estação pertence associado a uma outra
interface, o datagrama é descartado, da mesma forma que um datagrama destinado a um
grupo que a estação não pertence.
A lista de membros de grupos (protocolos de alto nível) é atualizada em
resposta as requisições JoinHostGroup e LeaveHostGroup dos protocolos dos níveis
superiores. Na primeira requisição para o “join”, ou a última para o “leave” a um grupo
em uma dada interface, o módulo de rede local para aquela interface é notificada de modo
a atualizar seus filtros de recepção multicast.
10
Note que é possível usar IP Multicast entre conjuntos de máquinas locais. A estação pode querer usar
uma aplicação multicast para interagir com máquinas em uma rede física, mas não com máquinas em uma
outra.

35
O módulo IP deve também ser estendido para implementar o protocolo
IGMP (Internet Group Management Protocol), usado para manter os roteadores de
multicast vizinhos informados sobre as estações membros dos grupos em uma rede
particular. Para suportar IGMP, toda estação (de nível 2) deve unir-se ao grupo “all-
hosts” (224.0.0.1) em cada interface de rede em tempo de iniciação, e permanecer
enquanto a estação estiver ativa.
Para permitir que o módulo IP diga ao módulo de rede local quais pacotes
multicast receber, a interface de serviço de rede local deve ser estendida para prover duas
novas operações: JoinLocalGroup(group_address), que requisita ao módulo de rede que
receba e entregue ao módulo IP pacotes destinados aos grupo endereçado por
group_adress; e LeaveLocalGroup(group_address), que requisita ao módulo de rede que
pare de receber pacotes destinados ao grupo endereçado por group_address.
3.1.2 Backbone Multicast da Internet (MBone)
O Backbone Multicast da Internet (MBone - Multicast Backbone)
[Kumar 96] é um conjunto interconectado de subredes e roteadores que suportam a
entrega de tráfego IP Multicast. O objetivo do MBone é construir um testbed de IP
multicast para habilitar o desenvolvimento de aplicações multicast sem esperar pelo
desenvolvimento de roteadores com capacidade de multicast na Internet.
MBone é uma rede virtual situada acima das sessões da Internet física. É
composta de ilhas de capacidade de roteamento multicast conectadas a outras ilhas por
enlaces ponto-a-ponto virtuais chamados “túneis”. Os túneis permitem tráfego multicast
através de algumas partes da Internet sem capacidade de multicast. Pacotes de IP
Multicast “entunelados” são encapsulados como IP-sobre-IP11
de modo que eles parecem
pacotes IP unicast normais para os roteadores. O encapsulamento é adicionado na entrada
11
O número do protocolo é configurado para 4.

36
de um túnel, e retirado na saída. Esse conjunto de roteadores multicast, suas subredes
diretamente conectadas, e os túneis de interconexão compreendem o MBone.
Uma vez que o MBone e a Internet tenham diferentes topologias,
roteadores multicast executam um protocolo de roteamento separado para decidir como
transmitir pacotes multicast. A maioria dos roteadores MBone atualmente usam o
protocolo de roteamento multicast DVMRP (Distance Vector Multicast Routing
Protocol), embora algumas porções do MBone executem OSPF Multicast (MOSPF) ou
Multicast Independente de Protocolo (PIM).
Ilha A
Ilha C
Túnel
Ilha E
Ilha B Ilha D
Figura 3.1: Backbone Internet Multicast
3.1.3 Suporte a IP Multicast em Redes ATM
Em redes ATM, a implementação do serviço de multicast e broadcast não é
trivial. Um transmissor precisa obter os endereços de todos os receptores para o
estabelecimento de uma conexão ponto-a-multiponto. Para solucionar este problema, a
IETF definiu, no documento RFC 2022 [Armitage 96], um mecanismo de registro e
resolução de endereços e distribuição de informações de membros de grupo que permite
oferecer suporte a um serviço de multicast sobre redes ATM baseadas nas versões UNI
3.0/3.1. O mecanismo é baseado na existência de Servidores de Resolução de Endereços
de Multicast (MARS – Multicast Address Resolution Server), que associam endereços de
grupos de multicast a interfaces ATM representando membros dos grupos. Entidades de

37
resolução de endereços nos sistemas finais solicitam a um MARS um conjunto de
endereços ATM (que formam um grupo), no momento em que um endereço de grupo de
multicast precisa ser resolvido. Os sistemas finais, por sua vez, mantêm o MARS
informado de sua entrada ou saída em um grupo (o esquema de gerenciamento de grupo é
mostrado adiante).
Duas abordagens podem ser utilizadas para a construção da infra-estrutura
de distribuição para redes ATM: malhas de VCs ponto-a-multiponto ou servidores de
multicast (MCSs – Multicast Servers). Na abordagem da malha de VCs, cada origem
estabelece um VC ponto-a-multiponto com o conjunto de destinos que são membros do
grupo com o qual ela deseja se comunicar, criando assim uma malha de VCs. Na
abordagem baseada em servidores de multicast, cada origem estabelece um VC ponto-a-
ponto com um nó intermediário, denominado de MCS, responsável pelo estabelecimento e
gerenciamento de uma única VC ponto-a-multiponto com os membros do grupo ao qual
ele gerência.
A arquitetura do MARS permite que tanto malhas de VCs quanto MCSs
sejam usados simultaneamente para grupos diferentes. Apesar da especificação do MARS
ser independente do protocolo utilizado, ele apresenta as mesmas características e
interfaces providas pelo IGMP, implementado, porém, de modo centralizado.
3.1.4 Transporte Multicast
Os protocolos de transporte mais tradicionais como OSI-TP4 e TCP
(Transmission Control Protocol) não suportam comunicação de dados multiponto. Novos
protocolos como VMTP (Versatile Message Transaction Protocol) [Cherinton 88] e XTP
(Xpress Transport Protocol) oferecem suporte ao serviço de multicast. O XTP [Rezende
et al 96] é um protocolo de transporte12
que oferece suporte a um serviço de transmissão
12
Alguns autores classificam o XTP como um protocolo de transferência, uma vez que ele incorpora
funcionalidades tanto da camada de rede como da camada de transporte do modelo de referência OSI.

38
com confiabilidade limitada. XTP é um protocolo orientado a conexão, mas suporta
também um serviço não orientado a conexão. Não há nenhum mecanismo para o
estabelecimento e gerenciamento de grupos multicast.
RMTP (Reliable Multicast Transport Protocol) [Paul et al 96] é um
protocolo de transporte multicast confiável baseado em uma estrutura hierárquica, na qual
receptores são agrupados em regiões locais (também denominados domínios), nas quais
um receptor especial (receptor designado) é responsável por enviar reconhecimentos
periódicos ao transmissor, processar reconhecimentos de receptores daquele domínio, e
retransmitir pacotes perdidos para os receptores apropriados. RMTP é um protocolo
bastante geral, uma vez que ele pode ser construído sobre qualquer rede, seja ela orientada
ou não à conexão. Apesar disso, o RMTP espera que a rede subjacente seja capaz de gerar
e estabelecer uma árvore de multicast do transmissor para os receptores.
3.2 Gerenciamento de Grupo de Multicast
O termo gerenciamento de grupo é utilizado para descrever todas as ações
relacionadas à composição do grupo, como manipulação de informações sobre os seus
participantes, e o controle de acesso ao grupo, isto é, controle sobre a entrada e saída de
participantes do grupo.
Os esquemas de gerenciamento de grupo podem ser classificados em dois
tipos: o gerenciamento de grupo distribuído, no qual as informações e o controle dos
grupos estão distribuídos pelo sistema de comunicação, como é o caso do IGMP [Fenner
97]; e o gerenciamento de grupo centralizado, no qual existe a figura de um gerenciador
de grupo centralizado, que controla todas as atividades de gerenciamento do grupo, como
acontece com o MARS [Armitage 96].

39
3.2.1 Gerenciamento de Grupo Distribuído
Para participar do IP Multicast em uma rede, uma estação deve ter
software que permita enviar e receber datagramas multicast. Para participar do multicast
que pode espalhar-se por várias redes, a estação deve informar os roteadores de multicast
de cada rede. Os roteadores por sua vez contatam outros roteadores, passando
informações de grupo e estabelecimento de rotas. A idéia é bastante similar a propagação
de rota local através de roteadores inter-redes convencionais.
Antes que um roteador multicast possa propagar informações dos membros
de grupos de multicast, é preciso determinar que estações em sua rede fazem parte de um
grupo. Para isso, roteadores multicast e estações que implementam multicast devem usar o
Protocolo de Gerenciamento de Grupo Inter-rede (IGMP) [Fenner 97] para comunicar
as informações de membros dos grupos.
IGMP é análogo ao ICMP. Como ICMP, ele usa datagramas IP para
carregar mensagens. Também como ICMP, ele provê um serviço usado pelo IP. Portanto,
embora IGMP use datagramas IP para carregar mensagens, IGMP é considerado parte
integral do IP, não um protocolo a parte. Além disso, IGMP é um padrão para TCP/IP;
isto é, ele é necessário em todas as máquinas que participam do IP Multicast no nível 213
.
Conceitualmente, IGMP tem duas fases. Na fase 1, quando uma estação
junta-se a um novo grupo de multicast (JoinLocalGroup), ela envia uma mensagem IGMP
para o endereço de grupo “all hosts” declarando sua entrada no grupo14
. Roteadores de
multicast locais recebem a mensagem e estabelecem as rotas necessárias propagando as
informações do membro do grupo para outros roteadores multicast através da Internet. Na
13
Uma estação participa do IP Multicast de um dos três níveis possíveis. No nível 2, uma estação pode
tanto transmitir como receber IP Multicast.
14
Para cobrir a possibilidade do relatório inicial ser perdido ou corrompido, é recomendado que a
mensagem seja repetida uma ou duas vezes após um pequeno retardo.

40
fase 2, devido à dinamicidade dos grupos, roteadores de multicast locais periodicamente
questionam as estações na rede local para determinar que estações permanecem como
membros de quais grupos. Cada estação mantém uma lista dos grupos de IP multicast que
ele tenha aderido. Quando um roteador multicast envia uma consulta IGMP para um
endereço, cada estação inicia um processo para envio de respostas para cada um dos
endereços que ela esteja associada. Essas respostas são enviadas para o endereço de
multicast, para que outros membros do mesmo grupo na mesma rede não precisem mais
enviar respostas para esse grupo. Se nenhuma estação responder para um determinado
grupo, após algumas solicitações de informação, o roteador de multicast assume que
nenhuma estação na rede permanece no grupo, e para então de anunciar as informações do
grupo para outras estações. Na versão 2 do IGMP [Fenner 97], foi criada a mensagem
IGMP_leave, cuja função é a de informar sobre o desligamento de uma estação de um
determinado grupo. Assim, o roteador multicast fica sabendo imediatamente se deve
continuar a replicar as mensagens multicast para a rede a qual a estação que acaba de se
desligar do grupo.
O esquema de gerenciamento de grupo distribuído apresenta uma grande
flexibilidade no gerenciamento de membros de um grupo. No IGMP, por exemplo, esse
esquema facilita a implementação de um esquema de endereçamento multicast flexível,
que permite que qualquer estação envie mensagens para um grupo sem necessitar
conhecer todos os participantes. Por outro lado, esse esquema torna a verificação de
segurança dos membros do grupo mais complexa. Além disso, o IGMP não possui um
esquema de alocação de endereços onde endereços são associados ou por uma autoridade
externa, ou por cada aplicação. Isso pode levar a contenção de endereços entre várias
aplicações.
3.2.2 Gerenciamento de Grupo Centralizado
O esquema de gerenciamento centralizado tem sido adaptado por vários
protocolos multicast, como no PIM [Deering et al 96] de Deering, onde o Rendezvous
Point (RP) é usado pelo transmissores para anunciar sua existência e pelo receptores para

41
conhecer os novos transmissores de um grupo. Recentemente, vários trabalhos foram
propostos na implementação de protocolos multicast em redes baseadas em ATM
[Armitage 96, Guerin et al 96, Szyperski et al 93, Talpade et al 96], usando
gerenciamento centralizado.
O mapeamento de mecanismos de multicast e broadcast em redes ATM não
é trivial, uma vez que especificações recentes do ATM Forum (UNI 3.0 [ATMF 93] e
UNI 3.1 [ATMF 94]) não provêm uma abstração flexível para endereços de multicast. A
limitação reside no fato de que a estação origem deve conhecer a priori todas as estações
destino, para o estabelecimento de uma VC ponto-a-multiponto.
Em redes IP convencionais, mecanismos de multicast são providos através
do protocolo IGMP, como mostrado na seção anterior. Este protocolo possibilita uma
abstração dos mecanismos de multicast nativos (geralmente encontrados nos níveis de
enlace das LANs convencionais) para multicast inter-redes, através da utilização de um
subconjunto dos endereços IP de classe D (224.0.0.0 à 239.255.255.255), reservados para
grupos de multicast. A comunicação multicast IP entre estações pertencentes a redes
distintas é feita através de roteadores multicast. Nas LANs convencionais, os meios de
comunicação são geralmente compartilhados por todas as estações, facilitando a definição
de mecanismos de multicast no nível de enlace. Por isso, o IGMP pressupõe o uso de
meios de comunicação compartilhados. Como se sabe, este conceito não existe em ATM.
Para solucionar esse problema, Armitage propôs um esquema para suporte
a IP multicast sobre redes ATM [Armitage 96]. Nesse trabalho, um Servidor de
Resolução de Endereço de Multicast (MARS) age como um gerenciador de registro e
resolução de endereço de grupo. O conceito de MARS é uma extensão análoga ao
conceito de servidor ATMARP (ATM Address Resolution Protocol) [Laubach 94]. Ele
associa endereços IP de classe D (ou no caso de qualquer outro protocolo de nível de
rede, identificadores de grupos de multicast) a interfaces ATM representando membros
dos grupos. Enquanto o servidor ATMARP mantém uma tabela de pares de endereços
(IP, ATM) para todos os sistemas finais IP pertencentes a uma subrede lógica IP, o

42
MARS mantém tabelas de endereços (IP classe D; ATM.1, ATM.2, ..., ATM.n). Um
MARS pode residir em qualquer sistema final que possa ser diretamente endereçado via
ATM pelos sistemas finais que requerem o serviço de multicast. Estes, por sua vez, devem
ser configurados com o endereço ATM do nó onde o MARS (ao qual o agrupamento
desejado está ligado) reside.
As mensagens de controle dos MARSs suportam a distribuição de
informações sobre grupos de multicast IP entre outros MARSs e sistemas finais (estações
ou roteadores). Entidades de resolução de endereços dos sistemas finais perguntam a um
MARS (MARS_REQUEST) quando um endereço IP precisa ser resolvido em um conjunto
de endereços ATM que formam um grupo. Os sistemas finais, por sua vez, mantém os
MARSs informados da entrada ou saída deles de um grupo. Após receber informações
sobre os membros de um grupo (MARS_MULTI), o transmissor pode estabelecer uma
conexão ponto-a-multiponto com todos os membros do grupo, ou usar um servidor de
multicast para distribuir os pacotes multicast.
A entrada e saída de participantes de um grupo é obtida através de
mensagens MARS_JOIN e MARS_LEAVE, respectivamente. A mensagem de adesão
contém o endereço de grupo de multicast e o endereço unicast do participante. Quando a
mensagem é recebida pelo MARS, ele adiciona o endereço ATM especificado a entrada na
tabela para o grupo especificado. A exclusão de um participante de um grupo é
processada removendo-se o endereço ATM especificado da tabela para o endereço de
grupo especificado. As mensagens MARS_JOIN e MARS_LEAVE são retransmitidas para
todos os membros do agrupamento para garantir que as alterações do grupo serão
refletidas em todas as conexões existentes para o grupo. Para prover mensagens de
notificação de mudança na composição de um grupo a todas as estações (dentro e fora do
grupo modificado), os MARSs gerenciam conexões ATM ponto-a-multiponto (VC de
Controle de Agrupamento) com todas as estações que desejam suportar multicast,
definindo agrupamentos de multicast.

43
Gerenciamento de grupo centralizado tem pontos fracos que precisam ser
solucionados. Primeiro, todas as atividades de gerenciamento de grupo são conduzidas
por uma única entidade de genciamento, o que pode introduzir retardos significantes de
comunicação. Além disso, uma única entidade de gerenciamento se torna um ponto de
falha em todo o esquema. Uma solução óbvia para esses problemas seria criar várias
cópias de entidades de gerenciamento de grupo.
3.3 Roteamento Multicast
Um protocolo de roteamento multicast é responsável pela construção da
infra-estrutura de distribuição multicast. Roteamento multicast é facilitado em algumas
redes locais, tais como Ethernet que provê um esquema eficiente de entrega por difusão
[Deering et al 90]. No entanto, para prover um serviço de entrega multicast, é necessário
definir um mecanismo eficiente de roteamento multicast.
Várias estratégias de roteamento e implementações tem sido propostas.
Dentre elas, a Árvore Baseada na Origem (SBT – Source Based Tree) [Deering et al
90, Deering et al 97, Moy 94b, Pusateri 97] e a Árvore Baseada em um Núcleo (CBT –
Core Based Tree) [Ballardie 97a] têm recebido muita atenção em trabalhos recentes.
Desenvolvimentos recentes na Internet tem enfatizado a importância de suportar ambos os
tipos de árvores [Deering et al 97]. Outros tipos de esquemas de roteamento multicast são
também propostos, como árvores de Steiner [Kompella et al 93].
3.3.1 Árvore Baseada na Origem
Árvores baseadas na origem (SBT) são árvores de entrega de menor
caminho criadas para cada grupo, entre o transmissor e os correspondentes receptores do
grupo. Para construir árvores baseadas na origem vários algoritmos tem sido propostos.
Entre eles, o roteamento multicast baseado em um vetor de distância e o roteamento
multicast baseado no estado do enlace tem recebido maior atenção.

44
O roteamento baseado em um vetor de distância tem sido usado em muitas
redes como algoritmo de roteamento unicast [Comer 95]. Roteadores que usam o
algoritmo de roteamento baseado em um vetor de distância mantêm uma tabela de
roteamento contendo uma entrada para cada destino alcançável na rede. Cada roteador
envia periodicamente pacotes de roteamento para seus vizinhos. Ao receber um pacote de
roteamento de um roteador vizinho, o roteador (receptor) pode atualizar sua tabela de
roteamento se o vizinho oferece uma caminho mais curto para um dado destino, ou se o
vizinho não mais oferece uma rota usada pelo roteador. Dessa forma, roteadores podem
manter rotas mais curtas para todos os destinos na rede.
Dois algoritmos de roteamento multicast baseados no roteamento baseado
em um vetor de distância são Transmissão por caminho reverso (RPF) e Difusão por
caminho reverso (RPB). Esses algoritmos são implementados pela difusão de mensagens
através da árvore de distribuição de menor caminho baseada na origem, cabendo a cada
receptor selecionar os pacotes realmente destinados a eles. Para cada origem, se um
pacote chegar por um enlace que o roteador acredite ser o menor caminho de volta para a
origem do pacote, então o roteador transmite o pacote por todas as interfaces, exceto a
interface por onde chegou o pacote. Se o pacote chegar por uma interface que não é a
mais curta de volta para a origem, o pacote é descartado. Uma das principais limitações
desses algoritmos é que eles não levam em consideração os membros de um grupo
multicast na construção de uma árvore de distribuição para uma origem. Como resultado,
datagramas podem ser desnecessariamente transmitidos para subredes que não tem
membros em um grupo destino.
Uma abordagem mais sofisticada pode ser encontrada no Protocolo de
Roteamento Multicast baseado em um Vetor de Distância (DVMRP), que utiliza um
algoritmo RPF modificado para prover um esquema de poda por demanda da árvore de
multicast de menor caminho. No DVMRP, o primeiro pacote multicast é transmitido por
difusão através da árvore de difusão de menor caminho para todos os membros da inter-
rede. Quando um pacote alcança um roteador no qual todos os enlaces filhos são folhas e
nenhum deles possui membros do grupo destino, uma mensagem de poda (NRM – Non

45
Membership Report) é enviada para o roteador em direção a origem. Se um roteador
receber uma mensagem de poda de todos os seus roteadores filhos, e se ele não possui
nenhum membro em qualquer uma de suas subredes, a mensagem de poda é retransmitida
ao seu roteador pai. Dessa forma, uma árvore de poda é criada e mensagens subsequentes
para aquele grupo não mais serão enviadas por caminhos que não levam a membros do
grupo. Após um período de tempo, o estado de poda para cada par (origem, grupo)
expira para reforçar um atualização do estado de poda (de grupos que não mais
permanecem ativos). Se estes grupos ainda estão em uso, um datagrama do par (origem,
grupo) será transmitido por toda a rede através de todos os roteadores “downstream”.
Essa inundação resultará em novo conjunto de mensagens de poda, regenerando a árvore
de menor caminho para esse par (origem, grupo).15
DVRP também implementa um mecanismo para rapidamente incluir de
volta um ramo previamente podado de uma árvore de entrega para um grupo. Se um
roteador que tenha mandado uma mensagem de poda para o par (origem, grupo) descobre
novos membros do grupo em uma subrede folha, ele envia uma mensagem de inclusão
para o roteador em direção a essa origem. Quando um roteador acima recebe uma
mensagem de inclusão, ele cancela a mensagem de poda previamente recebida. Mensagens
de inclusão são propagadas (de modo confiável) salto-a-salto em direção a origem, até
que elas encontrem o ramo ativo mais próximo da árvore de entrega. Dessa forma, ramos
previamente podados são rapidamente restaurados em uma árvore de entrega multicast.
Um outro algoritmo para a construção de árvores multicast é baseado no
roteamento baseado no estado de enlace. Nesse algoritmo, todos os roteadores monitoram
o estado de cada um de seus enlaces diretamente conectados. Sempre que o estado de um
enlace é alterado, o roteador distribui o novo estado do enlace para todos os roteadores
da rede usando um protocolo de inundação. Dessa forma, todos os roteadores recebem
15
Na implementação atual do RPF, mensagens de poda são transmitidas de modo não confiável. Assim o
tempo de vida da poda deve ser pequeno o suficiente para compensar a perda de mensagens de poda.

1999_05_rodrigues

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a 1999_05_rodrigues

Semelhante a 1999_05_rodrigues (20)

1999_05_rodrigues