algoritimos de roteamento

8/4/2019 Algoritimos de roteamento

http://slidepdf.com/reader/full/algoritimos-de-roteamento 1/118

Frank Meylan

ANÁLISE COMPARATIVA DE ALGORITMOS DE

ROTEAMENTO M ULTICAST PARA

COMUNICAÇÃO MULTIMÍDIA EM REDES DE

ALTA VELOCIDADE

São Paulo

1998

Dissertação apresentada à Escola

Politécnica da Universidade deSão Paulo para obtenção do títulode Mestre em Engenharia



Frank Meylan

ANÁLISE COMPARATIVA DE ALGORITMOS DE

ROTEAMENTO M ULTICAST PARA

COMUNICAÇÃO MULTIMÍDIA EM REDES DE

ALTA VELOCIDADE

São Paulo1998

Área de Concentração:Engenharia Eletrônica

Orientador:

Prof. Dr. Sérgio Takeo Kofuji



i

Meylan, Frank

Análise Comparativa de Algoritmos de Roteamento Multicast para ComunicaçãoMultimídia em Redes de Alta Velocidade. São Paulo, 1998. 114p.

Dissertação (Mestrado) – Escola Politécnica da Universidade de São Paulo.Departamento de Engenharia Eletrônica.

1. Transmissões Multicast 2. Algoritmos de Roteamento 3. Redes de AltaVelocidade I. Universidade deSão Paulo. Escola Politécnica. Departamento de EngenhariaEletrônica



ii

Aos meus paisÀs minhas irmãs

e à Cecília



iii

AGRADECIMENTOS

Em primeiro lugar, agradeço a DEUS por todas asgraças recebidas ao longo de minha vida.

Aos meus pais, Jean Claude e Mirtes, por todo amor,incentivo e esforços realizados para que euconseguisse atingir meus ideais, meu humildeobrigado.

Às minhas irmãs Gabi e Nati, pelo carinho efraternidade que une nossa família.

À minha namorada Cecília pelo carinho, apoio ecompanheirismo em todos os momentos destacaminhada.

Ao meu orientador, Prof. Dr. Ségio Takeo Kofujipela orientação competente e por todo apoiorecebido.

Ao Prof Dr. Marcelo Zuffo, pelo acompanhamento econhecimentos transmitidos, meus agradecimentos.

Ao Prof. Dr. Pedro Frosi Rosa, pela ilustre eenriquecedora presença na banca, meu respeito eadmiração.

À professora Roseli Lopes de Deus que sempre meincentivou e me apoiou para o término destetrabalho.

Aos grandes amigos Zanoni e Kiatake pelasdiscussões técnicas, pela colaboração no trabalho esobretudo pela extrema amizade. Muito obrigado!

Aos amigos Borges, Rafaelle e Tadeu, pelacompreensão e colaboração, meus agradecimentos.

Meus agradecimentos a ABC BULL S/ATELEMATIC pelo suporte ao projeto conjunto LSI-USP/ABC BULL em “Gerenciamento de Sistemasde Alto Desempenho”, no qual estive inserido emuito contribuiu para realização deste trabalho.

A todos os meus amigos que, de alguma forma,contribuíram nesta caminhada, meus sincerosagradecimentos.



iv

ANÁLISE COMPARATIVA DE ALGORITMOS DE ROTEAMENTO

M ULTICAST PARA COMUNICAÇÃO MULTIMÍDIA EM REDES DE

ALTA VELOCIDADE

Resumo

Durante muito tempo, a qualidade das aplicações multimídia distribuídas esteve

restringida às limitações da tecnologia de rede utilizada para a interligação dos

computadores. Este cenário mudou bastante com a introdução das redes de alta

velocidade. Características como garantia de qualidade de serviço (QdS), suporte a

diferentes tipos de tráfego (voz, vídeo e dados), alta escalabilidade, entre outras, fazem do

ATM (Asynchronous Transfer Mode) uma das alternativas mais adequadas para a

implantação das chamadas redes multisserviço.

Porém, a disseminação de aplicações multimídia, que demandam grandes quantidades de

banda de transmissão e atrasos controlados, a utilização de atributos de QdS, o

crescimento de transmissões multicast, tornam a tarefa de roteamento muito mais

complexa.

Assim, esta dissertação abordará em detalhes a questão do roteamento multicast com

restrição de QdS, apresentando um estudo comparativo sobre as soluções que estão sendo

propostas para tratar deste novo problema. Este estudo será conduzido através de

simulações entre quatro heurísticas, onde parâmetros relativos à ordem de complexidade,

qualidade da árvore multicast gerada, tempo de execução, etc., serão avaliados e

analisados.



v

COMPARATIVE ANALYSIS OF MULTICAST ROUTING

ALGORITHMS FOR MULTIMEDIA COMMUNICATIONS IN HIGH

SPEED NETWORKS

Abstract

For a long time, the quality of the distributed multimedia applications has been restricted

to the limitation of network technology used in computer communication. This scenario

has suffered a great change with the introduction of the high-speed networks. Attributes

like quality of service (QoS), support for different kind of traffic and high scalability,

among others, makes ATM (Asynchronous Transfer Mode), one of the most appropriate

choices for multiservice networks.

However, the dissemination of multimedia applications which require high bandwidth as

well as controlled delays, the use of QoS parameters and increase of multicast

communication are characteristics which require routing to be a much more complex task

than it is presently.

So, this thesis will discuss, in detail, the multicast routing with restriction of QoS,

presenting a comparative study of solutions that are being proposed to deal with this new

problem. This study will be done through simulations of four heuristics, where parameters

like complexity, quality of the multicast tree generated, execution time, etc., will be

evaluated and analyzed.



vi

Sumário

1 -Introdução____________________________________________________________ 1

1.1. Motivações_____________________________________________________________ 3

1.2. Objetivos ______________________________________________________________ 3

1.3. Metodologia____________________________________________________________ 4

1.4. Justificativa____________________________________________________________ 6

1.5. Trabalhos Correlatos ____________________________________________________ 6

1.6. Contribuições __________________________________________________________ 7

1.7. Sumário Estruturado ____________________________________________________ 8

2 -Redes ATM __________________________________________________________ 10

2.1. Introdução____________________________________________________________ 10

2.2. Conceitos Básicos ______________________________________________________ 112.2.1 Células ATM _____________________________________________________________ 122.2.2 Conexões ATM ___________________________________________________________ 132.2.3 O modelo de camadas ATM _________________________________________________ 152.2.4 O Endereçamento ATM_____________________________________________________ 19

3 -Soluções de Integração IP/ATM _________________________________________ 22

3.1. Introdução____________________________________________________________ 22

3.2. Classical IP ___________________________________________________________ 223.2.1 Servidor ATMARP ________________________________________________________ 23

3.2.2 Comunicação na solução Classical IP __________________________________________ 24

3.3. Lan Emulation_________________________________________________________ 253.3.1 Comunicação na solução Lan Emulation________________________________________ 28

3.4. Comparação entre o Lan Emulatione o Classical IP para ComunicaçãoMultimídia _________________________________________________________________ 32

4 -Comunicação Multicast ________________________________________________ 35

4.1. Introdução____________________________________________________________ 35

4.2. Conceitos Básicos ______________________________________________________ 36

4.3. Taxonomia de Conexões Multiponto ______________________________________ 384.3.1 Plano de controle __________________________________________________________ 384.3.2 Plano de Dados ___________________________________________________________ 394.3.3 ATM e Multicast IP segundo a Taxonomia ______________________________________ 39

4.4. Algoritmos de Roteamento Multicast ______________________________________ 404.4.1 Inundação (Flooding)_______________________________________________________ 404.4.2 Árvores de Espalhamento (Spanning Trees) _____________________________________ 414.4.3 RPB ( Reverse Path Broadcasting)_____________________________________________ 424.4.4 TRPB (Truncated Reverse Path Broadcasting)___________________________________ 434.4.5 RPM ( Reverse Path Multicasting) _____________________________________________ 444.4.6 Árvores de Steiner _________________________________________________________ 464.4.7 CBT (Core Based Trees) ____________________________________________________ 47

4.5. Multicast IP ___________________________________________________________ 484.5.1 Endereçamento Multicast IP _________________________________________________ 484.5.2 Multicast IP sobre Ethernet __________________________________________________ 49

4.6. Protocolos de Roteamento Multicast_______________________________________ 50



vii

4.6.1 IGMP ( Internet Group Management Protocol) ___________________________________ 50

4.7. Protocolos de Roteamento Multicast IP em Redes de Longa Distância___________ 544.7.1 DVMRP _________________________________________________________________ 54

4.7.2 MOSPF _________________________________________________________________ 564.7.3 PIM ____________________________________________________________________ 57

4.8. MBONE______________________________________________________________ 60

4.9. Multicast IP sobre ATM_________________________________________________ 614.9.1 MARS __________________________________________________________________ 634.9.2 Malha de VC’s (VC Mesh) __________________________________________________ 654.9.3 MCS ( Multicast Server)_____________________________________________________ 664.9.4 Comparativo entre o MCS e malha de VC’s _____________________________________ 684.9.5 Comentários______________________________________________________________ 68

4.10. Conclusões __________________________________________________________ 70

5 -Algoritmos de Roteamento Multicast com QdS____________________________ 715.1. Introdução____________________________________________________________ 71

5.2. Classificação dos Algoritmos de Roteamento Multicast _______________________ 72

5.3. Parâmetros Relevantes e Metodologia para Comparação de Algoritmos Multicast 74

5.4. Algoritmos de Roteamento Multicast ______________________________________ 755.4.1 Heurística KPP____________________________________________________________ 755.4.2 Heurística CSPT __________________________________________________________ 785.4.3 Heurística CCET __________________________________________________________ 785.4.4 Heurística Híbrida _________________________________________________________ 80

5.5. Conclusões____________________________________________________________ 81

6 -Simulações e Análises _________________________________________________ 82

6.1. Introdução____________________________________________________________ 82

6.2. Simulador ____________________________________________________________ 82

6.3. Adaptações feitas no simulador___________________________________________ 84

6.4. Configuração das Simulações ____________________________________________ 85

6.5. Resultados e Análises ___________________________________________________ 866.5.1 Estudo da complexidade dos algoritmos ________________________________________ 866.5.2 Custo total da árvore gerada__________________________________________________ 876.5.3 Atraso da árvore multicast ___________________________________________________ 89

6.5.4 Número de comutadores em cada caminho ______________________________________ 906.5.5 Tempo de execução dos algoritmos ____________________________________________ 926.5.6 Número de sessões estabelecidas com sucesso ___________________________________ 93

6.6. Conclusões____________________________________________________________ 95

7 -Conclusões e Trabalhos Futuros _________________________________________ 97

7.1. Conclusões____________________________________________________________ 98

7.2. Trabalhos Futuros _____________________________________________________ 99

Anexo A – O Gerador Aleatório de Enlaces _________________________________ 101

Anexo B – Interface do Simulador MCRSIM ________________________________ 103

Referências Bibliográficas _______________________________________________ 104

Lista de Acrônimos _____________________________________________________ 107



viii

Lista de FigurasFigura 1 - Estrutura de uma rede ATM _______________________________________ 12Figura 2 – A célula ATM e a estrutura de seu cabeçalho _________________________ 13Figura 3 – Comutação das células ATM[Alles95] ______________________________ 14Figura 4 – Modelo simplificado de camadas ATM______________________________ 16Figura 5 – Classificação de serviços para as AAL’s _____________________________ 18Figura 6 – Modelo de camadas ATM ________________________________________ 19Figura 7 – Formato dos endereços ATM______________________________________ 20Figura 8 – Mapeamento IP sobre ATM utilizando Classical IP ____________________ 23Figura 9 – Duas redes IP sobre uma mesma rede ATM utilizando Classical IP _______ 24Figura 10 – Modelo de camadas do Lan Emulation _____________________________ 26Figura 11 – Componentes de uma rede emulada________________________________ 27

Figura 12 – Comunicação entre o LEC e o LECS para obtenção das informações dasELAN’s configuradas _________________________________________________ 29Figura 13 – Processo de filiação a uma ELAN _________________________________ 30Figura 14 – Establecimento de conexão entre LEC’s ____________________________ 32Figura 15 – Comunicação Multicast _________________________________________ 35Figura 16 – Tabela comparativa entre Multicast IP e ATM, segundo taxonomia proposta 39Figura 17 – Árvore de Espalhamento ________________________________________ 42Figura 18 – Árvores geradas a partir do RPB ( Reverse Path Broadcasting) __________ 43Figura 19 – Árvore multicast gerada pelo algoritmo RPM ________________________ 45Figura 20 – Árvore de Steiner ______________________________________________ 46Figura 21 – Árvore CBT __________________________________________________ 47

Figura 22 – Mapeamento de endereços IP classe D em endereços MAC Ethernet______ 49Figura 23 – Encapsulamento de mensagem IGMP em um datagrama IP _____________ 51Figura 24 – Tabela sobre a abrangência da transmissão multicast __________________ 56Figura 25 – Inserção de uma estação no grupo multicast , através do PIM-SM ________ 59Figura 26 – Envio de mensagens multicast através dos pontos de encontro___________ 59Figura 27 – Árvore RP e Árvore de Menor Caminho dividindo o tráfego, segundo

implementa o protocolo PIM-SM ________________________________________ 60Figura 28 – Estrutura de um cluster administrado por um MARS __________________ 64Figura 29 – Representação da estrutura da malha de VC’s________________________ 65Figura 30 – Arquitetura do servidor de transmissão multicast _____________________ 67Figura 31 – Comparativo entre a malha de VC’s e o MCS________________________ 68

Figura 32 – Árvore de menor caminho _______________________________________ 72Figura 33 – Árvore Steiner Mínima__________________________________________ 73Figura 34 – Evolução da solução KPP________________________________________ 77Figura 35 – Estágios do algoritmo CCET _____________________________________ 80Figura 36 – Tabela referente à ordem de complexidade dos algoritmos______________ 87Figura 37 – Custo das árvores geradas pelos algoritmos__________________________ 88Figura 38 – Atraso médio das árvores geradas _________________________________ 90Figura 39 – Número de médio de comutadores nos caminho da árvore multicast ______ 91Figura 40 – Tempo de execução dos algoritmos _______________________________ 92Figura 41 – Número de sessões multicast estabelecidas com sucesso _______________ 94Figura 42 – Interface gráfica do simulador MCRSIM___________________________ 103



Capítulo 1 - Introdução 1

1

CCaappí í ttuulloo 11 -- IInnttrroodduuççããoo

Os recentes avanços nas tecnologias de comutadores e a disseminação da fibra ótica como

meio de transmissão, têm possibilitado o desenvolvimento de uma geração de redes de alta

velocidade, cujas taxas de transmissão já estão na ordem de gigabits por segundo e com

baixas taxas de erro. Além disso, o progresso das técnicas de armazenagem e transmissão

de áudio, vídeo e dados contribuem para o surgimento de novas aplicações multimídia

distribuídas.

Tais aplicações, como por exemplo: vídeo sob demanda, ensino a distância,

videoconferência, etc., possuem características e necessidades especiais que devem ser

consideradas pela rede de transmissão, de forma a se obter um serviço com a qualidade

esperada. A transmissão de voz e vídeo numa videoconferência, por exemplo, exige certa

quantidade de banda disponível e garantida durante a duração da sessão, além de atraso

controlado dentro de limites conhecidos. Estas características ou exigências impostas pelas

aplicações são chamadas de parâmetros de qualidade de serviço (QdS). A rede, ao tomar

conhecimento destes parâmetros, avalia segundo a disponibilidade de recursos de todos os

equipamentos intermediários, a possibilidade de prestação do serviço requisitado pelaaplicação.

Estas aplicações envolvem, em muitos casos, vários participantes simultâneos (por

exemplo cinco pessoas discutindo através de uma videoconferência) numa mesma sessão,

o que exige da rede um mecanismo eficiente de comunicação multicast . Percebe-se, então,

a concepção de um novo paradigma: a interação entre a aplicação e seu meio de

transmissão visando a negociação da prestação de um serviço.




2

Com o objetivo de prover recursos necessários, permitindo diferenciação de classes de

serviços e qualidade de serviço garantida, foi concebido o modo de transmissão assíncrona

(ATM ou Asynchronous Transfer Mode). Esta tecnologia é orientada a conexão, sendo que

durante o estabelecimento desta, os recursos são alocados, nos equipamentos

intermediários até o destinatário, garantindo assim, a continuidade do serviço negociado

durante a existência da conexão.

A rede ATM tem nas células sua unidade básica de transmissão, onde seu tamanho fixo e

pequeno garante um baixo tempo de comutação implicando num menor atraso fim-a-fim.

Além disso, esta característica facilita o transporte e a administração de recursos para os

diferentes tipos de tráfego. As antigas tecnologias de redes, também conhecidas como

redes convencionais, eram baseadas em pacotes de tamanho variável e não ofereciam

qualquer garantia de banda de transmissão ou controle de atraso.

O roteamento nestas redes era uma tarefa relativamente simples, uma vez que as aplicações

utilizavam uma quantidade modesta de banda de transmissão e não impunham exigências

de qualidade de serviço. Além disso, poucas eram as aplicações que utilizavam o conceito

de multicast . Logo, os algoritmos de roteamento eram bastante simplificados, porém

suficientes.

Este cenário mudou bastante nas redes de alta velocidade. A introdução do conceito de

qualidade de serviço, o crescimento de transmissões multicast , a disseminação de

aplicações multimídia utilizando grandes quantidades de banda de transmissão e exigindo

atrasos controlados, tornaram a tarefa de roteamento muito mais complexa e com vários

parâmetros influindo sobre a escolha das rotas.




3

Assim, esta dissertação abordará em detalhes a questão do roteamento multicast com

restrição de QdS, ou também conhecido como roteamento multicast restrito, apresentando

um estudo comparativo sobre as soluções que estão sendo propostas para tratar deste novo

problema.

1.1. Motivações

Com a consolidação da tecnologia ATM e principalmente devido à sua grande aceitação no

mercado, diversas empresas e entidades de pesquisa investiram no desenvolvimento de

novas técnicas de roteamento multicast , levando em consideração as características

específicas que as aplicações multimídia de tempo real exigem. Assim, muitos trabalhos

surgiram inovando os algoritmos de roteamento e aperfeiçoando os antigos. Entretanto, são

escassos os trabalhos que comparam estes algoritmos aplicando técnicas de simulação

baseadas nas situações observadas num cenário real de redes de computadores.

Visando a disseminação desta nova classe de aplicações, é necessário que as novas técnicas

de roteamento sejam estudadas, comparadas e aperfeiçoadas. Assim, dentro de algum

tempo, serviços de videoconferência, ensino a distância, tele-medicina, farão parte do

cotidiano das pessoas da mesma forma que hoje fazem o telefone, a televisão, o fax, etc.

1.2. Objetivos

Este trabalho tem como principal objetivo analisar uma nova heurística de roteamento

multicast que considera aspectos de qualidade de serviço, proposta originalmente por

Waters e Crawford [Waters97]. A fim de que esta avaliação seja consistente, a heurística

será implementada no simulador de redes ATM MCRSIM, e comparada com três outras

abordagens de comportamento e desempenho já descritos na literatura.




4

1.3. Metodologia

Para que os objetivos descritos fossem atingidos, procurou-se , numa primeira etapa, fazerum levantamento bibliográfico referente ao assunto, buscando o estado da arte do mesmo.

Este levantamento resultou na identificação dos principais autores e seus respectivos

artigos e teses.

Através desta pesquisa inicial, tomou-se conhecimento da tese de doutorado de Hussein

Salama apresentada à Universidade da Carolina do Norte em 1996. Com o auxilio deste

trabalho [Salama96], foi possível destacar os principais algoritmos de roteamento multicast

disponíveis na época e uma metodologia proposta para analisá-los e compará-los. Para a

validação da parte prática das simulações, Salama desenvolveu um simulador de

algoritmos multicast sobre redes ATM, chamado MCRSIM, que será aproveitado e

aprimorado nesta dissertação.

O simulador, foi escrito utilizando a linguagem C++, interface gráfica baseada no Motif e

compilado, segundo o autor, em algumas plataformas: Sun, Dec, RS6000. Como parte

deste trabalho, este simulador foi portado para a plataforma PC/Linux, uma vez que esta

plataforma é aberta e tem conquistado considerável prestígio ultimamente no meio

acadêmico.

Dentre as diversas novas propostas de algoritmos de roteamento multicast restrito, uma em

especial: “A Hybrid Approach to Quality of Service Multicast Routing”, elaborada por

John Crawford e Gill Waters [Waters97] da Universidade de Kent, Inglaterra, apresenta

uma nova abordagem de algoritmo de roteamento multicast . Esta abordagem tem como

mérito utilizar propostas otimizadas, já existentes, para casos específicos do problema de

roteamento multicast , de forma a agregar num único algoritmo as vantagens relativas a




5

cada uma das propostas anteriores, resultando em um algoritmo de roteamento multicast

restrito genérico.

A partir do estudo detalhado desta nova heurística, foi possível sua implementação no

simulador. Seguindo a metodologia de análise utilizada por [Salama96] e [Tobagi94], a

heurística foi simulada e comparada com três abordagens já descritas na literatura.

Este estudo consistiu na análise teórica dos algoritmos, ou mais especificamente, na ordem

de complexidade de cada um e aspectos relativos às simulações, onde os principais

parâmetros foram identificados:

• Gerenciamento eficiente dos recursos da rede;

• Parâmetros de QdS considerados;

• Aplicabilidade para redes simétricas e assimétricas;

• Escalabilidade;

• Tempo de execução;

• Número de falhas.

As redes utilizadas nas simulações foram geradas aleatoriamente segundo um modelo

consolidado na literatura [Waxman88]. O tamanho das redes simuladas e o número de

participantes do grupo multicast foram variados, procurando salientar o desempenho dos

algoritmos em relação a grupos pequenos de até vinte nós e a grupos grandes de até

duzentos nós. Os resultados obtidos das simulações foram apresentados em gráficos e

analisados segundo os parâmetros relevantes para a transmissão de fluxos multimídia.




6

1.4. Justificativa

A comparação entre as heurísticas de roteamento multicast é essencial para ressaltar asfalhas, vantagens e desvantagens de cada uma, de forma a direcionar os trabalhos futuros

em busca de novas abordagens, caso as existentes não atenderem às necessidades, ou

evidenciar os pontos em que estas devam ser aperfeiçoadas.

Os estudos teóricos (complexidade, quantidade de memória para armazenar as

informações) e as simulações (tempo de execução, número de falhas, recursos consumidos,

etc.) permitem avaliar a viabilidade de se implementar protocolos ou mesmo equipamentos

que se utilizem destes algoritmos.

1.5. Trabalhos Correlatos

Na literatura, encontra-se um grande número de algoritmos propostos para muitas

variações do problema de roteamento multicast . Conforme a situação, diferentes ambientes

de rede foram criados ou simulados e consequentemente diferentes parâmetros analisados.

A existência de estudos comparativos entre as diferentes abordagens dos algoritmos,

entretanto, é bastante escassa.

Em 1983, foi realizado um estudo teórico comparando árvores de menor caminho e árvores

mínimas de Steiner [Kadaba83]. Os autores não levaram em consideração aspectos

relativos ao atraso e ao custo das ligações. Isto porque, nesta época, gerenciamento de

recursos e requisições de qualidade de serviço não tinham sido definidas ainda.

Posteriormente, Tanaka e Huang [Tanaka93] compararam o desempenho de diversos

algoritmos de árvore de Steiner mínima não restritos. As simulações foram executadas

sobre redes simétricas de 20 nós e foi assumido que o custo de uma ligação era

proporcional ao comprimento da mesma.




7

O algoritmo de atraso mínimo sobre árvores de menor caminho e a heurística KMB foram

estudadas por Wei e Estrin [Wei94]. Neste trabalho foram utilizadas redes de 50 e 200 nós

geradas aleatoriamente através do modelo de Waxman [Waxman88]. As redes eram

formadas por ligações assimétricas, contendo atraso e custo. Os resultados demonstraram

que a heurística KMB produziu árvores cujo custo era de aproximadamente 20% menor do

que aquelas produzidas pelo algoritmo de menor atraso. Porém, o atraso máximo fim-a-fim

ficou em até 60% maior.

Os trabalhos elaborados por Hussein Salama [Salama96] e Tobagi [Tobagi94] foram os

únicos que consideraram aspectos de QdS (Qualidade de Serviço), indispensáveis para

aplicações multimídia de tempo real, durante suas análises. Nestes trabalhos foram

estudados algoritmos restritos e irrestritos tanto de árvores de menor caminho quanto de

árvores mínimas de Steiner. Tal estudo se baseou na análise do desempenho dos

algoritmos em termos das características da árvore gerada, como por exemplo: custo,

atraso máximo fim-a-fim, número de tentativas antes de obter uma árvore que satisfizesse a

condição de atraso máximo, complexidade do algoritmo, etc. Para tanto, foram realizadas

simulações baseadas em redes reais ou geradas aleatoriamente, onde foi definida uma

função de custo e estimado o atraso nas ligações, considerando sempre o congestionamento

através de políticas de admissão de novas conexões. Percebe-se, assim, que a metodologia

utilizada procurou aproximar as simulações do contexto real com o maior grau de detalhes

possível.

1.6. Contribuições

Este trabalho posicionará o leitor frente a um novo problema decorrente do

desenvolvimento das tecnologias de rede e aplicações multimídia distribuídas: roteamento

multicast com QdS. Em função disso, apresentará as diversas soluções existentes




8

atualmente para a comunicação multimídia, ressaltando a falta de habilidade destas em

lidar com as questões de reserva de banda e restrições de atraso. Como possíveis soluções

para este problema, traçará um perfil do estado da arte em termos de algoritmos de

roteamento multicast que consideram aspectos de QdS.

Através das simulações e análises, apontará em termos quantitativos a eficiência dos

algoritmos propostos assim como a nova heurística, visando avaliar sua possível

implementação em protocolos ou equipamentos de roteamento.

A implementação do novo algoritmo no simulador, contribuirá para a sua atualização e

também terá seus recursos estendidos em função dos novos módulos de simulação criados

para a avaliação de outros parâmetros igualmente relevantes.

1.7. Sumário Estruturado

Esta dissertação será composta por sete capítulos, estruturados de forma a propiciar ao

leitor um conhecimento básico sobre características e funcionamento de redes de alta

velocidade, em particular redes ATM. Este estudo será conduzido no capítulo 2. As

transmissões multicast IP sobre redes locais e multicast IP sobre redes de longa distância

serão detalhadas nos capítulos 3 e 4. Então, será apresentado o panorama atual das

aplicações multimídia distribuídas, salientando suas características e exigências,

justificando a necessidade do desenvolvimento de novas soluções de roteamento multicast .

As principais soluções de roteamento multicast que consideram aspectos de QdS

encontradas na literatura, juntamente com a nova heurística, serão apresentadas no capítulo

5, e os resultados respectivos a seus testes serão analisados no capítulo 6. Encerrando a

dissertação, serão formuladas as conclusões e apontadas as possíveis extensões deste

trabalho.




9

Seguindo esta linha de raciocínio, os seguintes capítulos são propostos:

• Capítulo 1 – Introdução;

• Capítulo 2 – Redes ATM;

• Capítulo 3 – Soluções de Integração IP/ATM;

• Capítulo 4 – Comunicação Multicast;

• Capítulo 5 –Algoritmos de Roteamento Multicast com QdS;

• Capítulo 6 – Simulações e Análises;

• Capítulo 7 – Conclusões e Trabalhos Futuros



Capítulo 2 - Redes ATM 10

10

CCaappí í ttuulloo 22 -- RReeddeess AATTMM

2.1. Introdução

O modo de transmissão assíncrona (ATM – Asynchronous Transfer Mode) é uma

tecnologia de redes de computadores que foi concebida devido o interesse de companhias

telefônicas (Telecom) e companhias de redes de computadores (Datacom) em estabelecer

um padrão único de transmissão de voz, vídeo e dados. Entretanto, esta idéia de integração

não apareceu com o ATM. Desde as redes RDSI (Redes Digitais de Serviços Integrados),

ou ISDN( Integrated Services Digital Network ), já se falava em um meio único de

transmissão multiserviços, porém a restrição de banda impediu que esta tecnologia

escalasse para níveis globais de utilização. A partir da padronização da RDSI-FL (Redes

Digitais de Serviços Integrados de Faixa Larga), também conhecida como B-ISDN

( Broadband Integrated Services Digital Network ), esta restrição foi superada com a adoção

do ATM como tecnologia de comutação. Portanto, o ATM aparece, desde sua concepção

no final da década de 80, intimamente associado ao B-ISDN.

Com o objetivo de acelerar a padronização e consequentemente a utilização do ATM, foi

criado um consórcio industrial formado por fabricantes, fornecedores e usuários. Este

consórcio ficou conhecido como ATM Forum. Conceitualmente, o papel do ATM Forum é

de esclarecer aspectos da utilização dos padrões desenvolvidos pelos organismos

padronizadores, como o ITU-T ( International Telecommunication Union –

Telecommunication Standardization Sector ) e o ANSI (American National Standards

Institute). Porém, na prática, o ATM Forum tem gerado grandes extensões a esses padrões




11

e tem produzido especificações inteiramente novas, que acabam se constituindo em

padrões de facto para as redes ATM privadas.

Apesar de sua elevada complexidade, o ATM tem atraído grande interesse de empresas e

instituições de pesquisa, principalmente devido aos seus diferenciados mecanismos de

aprimoramento do uso da banda (diferentes classes de serviços em função do tipo do

tráfego utilizado), confiabilidade, garantias de qualidade de serviços (QdS), recursos de

gerenciamento e tarifação diferenciados. Este interesse é facilmente verificado a partir do

grande número de trabalhos acadêmicos e produtos comerciais que têm sido desenvolvidos

a partir desta tecnologia.

2.2. Conceitos Básicos

Uma rede ATM é composta por um conjunto de comutadores ATM interligados através de

interfaces ou links (ligações) ATM. Os comutadores ATM suportam dois tipos de

interfaces: UNI (User-Network Interface) e NNI ( Network-Network Interface). A UNI

conecta estações finais, roteadores, etc. a um comutador ATM, enquanto a NNI serve para

conectar dois comutadores ATM. A figura 1 mostra a estrutura geral de uma rede ATM.

Existem dois tipos de redes ATM: as redes privadas e as redes públicas. Tradicionalmente,

esses conceitos estão relacionados com o uso de circuitos compartilhados (rede pública) ou

dedicados (rede privada), mesmo quando, no segundo caso, a posse e a manutenção das

linhas sejam de uma operadora pública de telecomunicações.




12

Figura 1 - Estrutura de uma rede ATM

2.2.1 Células ATM

A unidade básica de transmissão em redes ATM é a célula, conforme é mostrado na figura

2. A célula ATM tem seu tamanho fixo em 53 bytes, onde 5 bytes destes são de cabeçalho

e 48 bytes são de dados. O fato das células terem tamanho pequeno e fixo otimiza a

comutação das mesmas nos comutadores, diminuindo assim o atraso da transmissão fim-a-

fim. Além disso, este mesmo tamanho fixo, facilita a especificação do tamanho de buffers

nos comutadores e consequentemente o controle da utilização dos mesmos, prevenindo

situações de congestionamento e facilitando os mecanismos de priorização (QdS).

Uma desvantagem da utilização de células é o overhead introduzido devido ao seu

cabeçalho, que se aproxima dos 10% de seu tamanho total.

Estação ATM ComutadorATM Privado

ComutadorATM Público


UNI

Privada

UNI

Pública

NNI

Privada

Estação ATMComutador

ATM PrivadoUNI

Privada

NNIPrivada

Provedor 1



NNI

Privada

Provedor 2

NNIPública




13

Figura 2 – A célula ATM e a estrutura de seu cabeçalho

2.2.2 Conexões ATM

O ATM é dito uma tecnologia de rede orientada a conexão, ou seja, antes de se transmitir

qualquer dado é necessário que se estabeleça uma conexão entre os dois (ou mais no caso

de multicast ) sistemas. Estas não são conexões físicas, como no sistema telefônico

tradicional, ao invés disso, são conexões lógicas ou também chamadas de virtuais. Após a

transmissão dos dados a conexão pode ser liberada. Uma conexão ATM possui atributos

(tipo do tráfego utilizado, parâmetros de qualidade de serviço, etc.) que são negociados

durante o estabelecimento da conexão. Estes atributos devem ser aceitos não só pelo

sistema final, mas também por todos os comutadores intermediários envolvidos na

comunicação.

UNI NNI

Cabeçalho Dados

Célula ATM

5 bytes 48 bytes

GFC VPI VPI

• GFC – Generic Flow Control. Usado para controle de fluxo• VPI – Virtual Path Indentifier . Identificador do caminho virtual• VCI – Virtual Channel Identifier . Identificador do canal virtual• PTI – Payload Type Identifier . Tipo do dado transportado

• CLP – Cell Loss Priority. Indica a prioridade de descarte da célula

• HEC – Header Error Control. Informação sobre a consistência docabeçalho da célula

VPI VCI

VCI

VCI PTI CLP

HEC

VPI VCI

VCI

VCI PTI CLP

HEC




14

As conexões ATM, também conhecidas como VCC’s (Virtual Channel Connection),

possuem um identificador VCI (Virtual Channel Identifier ). Estas conexões são agrupadas

em caminhos virtuais, ou VP’s (Virtual Path), estes identificados pelos VPI’s (Virtual Path

Identifier ). Assim, o par VPI/VCI identifica unicamente uma conexão em um enlace ATM.

É através deste par que as células ATM são comutadas. A comutação ocorre devido a

existência de tabelas que mapeam o par VPI/VCI de uma determinada porta do comutador

em outro par VPI/VCI (pode ou não ser o mesmo) em uma outra porta deste mesmo

comutador. A troca de identificadores, durante a comutação, pode ocorrer somente nos

VPI’s, somente nos VCI’s ou ainda, em ambos simultaneamente. É bom ressaltar que estes

identificadores só tem significado local. A figura 3 mostra exemplos de comutação de VP,

Figura 3 – Comutação das células ATM[Alles95]

VC e ambos, em função da tabela contida no comutador.




15

Dois tipos principais de conexões são definidas em redes ATM: conexões virtuais

permanentes (PVC – Permanent Virtual Connection) e conexões virtuais comutadas (SVC

– Switched Virtual Connection).

• PVC – As conexões permanentes são estabelecidas normalmente por um agente

ou mecanismo externo, como um sistema de gerenciamento ou uma

intervenção direta do operador no(s) comutador(es). As conexões são criadas

através da configuração das tabelas de VPI/VCI das portas dos comutadores.

• SVC – As conexões comutadas são criadas automaticamente através de um

protocolo de sinalização específico (por exemplo o ILMI – Interim Local

Management Interface). Se a conexão ficar um certo tempo sem uso, é

automaticamente desfeita, liberando os recursos utilizados. Pelo fato de serem

automáticas, as SVC’s são mais utilizadas que as PVC’s.

2.2.3 O modelo de camadas ATM

Sempre que se estuda um protocolo de redes de computadores, procura-se dividi-lo em

camadas para se obter uma melhor organização das funções e serviços oferecidos por cada

entidade do protocolo. O modelo OSI (Open Systems Interconnection), instituído pela ISO

( International Organization for Standardization) é tido como referência e amplamente

aceito tanto no meio acadêmico como industrial. Existem na literatura diversas proposta de

mapeamento das camadas do modelo ATM para as camadas do modelo OSI, porém estas

nem sempre são conciliáveis o que dá margem a discussões e polêmica. Para não tomar

partido de uma ou outra proposta, este autor se limitará a apresentar o modelo ATM e a

explicar as funções de cada camada. A figura 4 apresenta o modelo de camadas ATM

simplificado.




16

Figura 4 – Modelo simplificado de camadas ATM

A seguir serão explicadas as principais funcionalidades das camadas e subcamadas do

modelo ATM.[Cereda97]

• Camada Física

ü Subcamada de Meio Físico – Especifica as características mecânicas, elétricas e

óticas dos meios de transmissão adotados, bem como o sincronismo necessário à

transmissão e recepção dos bits.

ü Subcamada de Convergência de Transmissão – Especifica as funções destinadas

à geração e composição dos conjuntos de bits, à geração e verificação dos bits de

controle de erro, ao delineamento dos conjuntos de bits, ao desacoplamento entre as

taxas de transferência e ao transporte dos conjuntos especiais de bits destinados às

tarefas de operação, administração e manutenção.

• Camada ATM – No caso de estações finais, esta camada é responsável por receber os

dados da camada de adaptação e encapsulá-los em células (gerando o cabeçalho com as

informações de controle: VPI, VCI, CLP, HEC, etc.) enviando, em seguida, à camada

física. Também realiza o trabalho inverso, de receber as células da camada física,

extrair os dados das células e enviá-los à camada de adaptação. Em comutadores, esta

Subcamada de convergência

Subcamada de segmentaçãoe recomposição

Camada de

Ada ta ão ATM

Camada ATM

Camada

Física

Subcamada de convergênciade transmissão

Subcamada de meio físico




17

camada é responsável também por analisar o par VPI/VCI da célula e sua porta de

entrada, consultar nas tabelas o VPI/VCI destino, gerar o novo cabeçalho e devolver à

camada física a nova célula. Ou seja, é responsável pela comutação de nível 2. O

gerenciamento do tráfego, priorização das células, controle de fluxo e

congestionamento também são funções desta camada.

• Camada de Adaptação ao ATM

Como foi estudado, a camada ATM é responsável pelo transporte das células nas redes

de tecnologia ATM. As camadas superiores podem, então, ser adaptadas de forma a

otimizar a transmissão dos diversos tipos de tráfego gerados pelas aplicações. Por

exemplo: nem todas as aplicações necessitam de garantia de atraso constante na

transmissão, porém, em outras esta característica é fundamental. Assim sendo, a

camada de adaptação foi definida para adaptar as necessidades das aplicações ou

camadas superiores em relação à camada ATM. A camada de adaptação ao ATM,

também chamada de AAL ( ATM Adaptation Layer ) é dividida em duas subcamadas:

ü Subcamada de Segmentação e Recomposição – Especifica as funções dedicadas

a decompor as mensagens oriundas da subcamada de convergência, de forma a

adaptá-las em células de 48 bytes de carga útil e recompor as mensagens oriundas

da concatenação da carga útil das células da camada ATM para posterior envio à

subcamada de convergência.

ü Subcamada de Convergência – Esta subcamada recebe os dados das aplicações

ou protocolos superiores e em função das características do tráfego, gera o

cabeçalho dos pacotes contendo ou não informações sobre freqüência de

transmissão, temporização, etc.




18

Tendo em vista a proliferação de protocolos associados à camada de adaptação, o ITU-T

propôs uma organização em função dos conjuntos de características das aplicações que os

futuros protocolos deveriam exibir, criando, então, o conceito de classes de serviços. Como

exemplos de características destacam-se: sincronismo entre emissor e receptor, taxa de bit

transmitida/recebida (fixa ou variável), seqüencialização dos pacotes, funções de controle

de fluxo, comunicação com ou sem conexão, etc. A figura 5 esclarece o uso das AAL em

relação às classes de serviços e alguns exemplos de aplicações.

Figura 5 – Classificação de serviços para as AAL’s

Apesar da literatura apresentar a figura 5 como modelo clássico, é bom ressaltar que os

fabricantes têm dado grande ênfase ao desenvolvimento sobre AAL5. Diversas propostas

existem para a criação de AAL’s específicas, por exemplo, para a transmissão de fluxos de

vídeo MPEG-2, porém ainda não foram criados padrões para isso.

Vista a estrutura de funcionamento do modelo básico, que é de fácil entendimento, é hora

de estudar o real modelo de operação do ATM. Para isso o ITU-T, segundo a

recomendação I.321, definiu o modelo de rede ATM conforme apresentado na figura 6.

Camada deAdaptação

AAL1 AAL2AAL3/4AAL5

Modo de

Conexão

Taxa detransmissão Constante

RestriçõesTemporais

Existente

Classe A Classe B Classe C Classe D

Exemplosde

serviços

Inexistente

Variável

Nãoorientado a

conexão

Orientado a conexão

AAL3/4AAL5

Emulação decircuito,

vídeo a taxaconstante

Vídeo e áudioa taxa

variável

Transferênciade dados

orientados aconexão

Transferênciade dados nãoorientados aconexão




19

Figura 6 – Modelo de camadas ATM

O modelo utiliza o conceito de planos distintos a fim de separar funções de usuário, de

gerenciamento e de controle. O plano de gerenciamento é responsável pela manutenção da

rede e execução de funções operacionais, gerenciando os demais planos e a si próprio; o

plano do usuário é responsável pelo transporte de informações do usuário; por fim, o plano

de controle é responsável pelas informações de sinalização da rede [Black95]. A

sinalização utilizada para o estabelecimento, alteração e encerramento de conexões, dentro

do plano de controle, utiliza uma camada de adaptação especial denominada SAAL

(Signaling ATM Adaptation Layer ). A forma de como são estabelecidas as conexões será

explicado a seguir.

2.2.4 O Endereçamento ATM

O usuários ATM (protocolos superiores ou aplicações) comunicam-se através das

conexões virtuais, identificadas unicamente em um enlace, através do par VPI/VCI,

durante a fase de transmissão dos dados. Com o intuito de estabelecer uma nova conexão,

os comutadores necessitam identificar o(s) destinatário(s) para que o protocolo de

roteamento descubra uma rota entre o emissor e o(s) receptor(es). Para suprir esta

necessidade foram definidos os endereços ATM, de modo que as entidades de sinalização




20

(plano de controle) possam requisitar uma conexão à rede, fornecendo o endereço ATM do

destinatário e os parâmetros de qualidade de serviço desejados.

O endereçamento ATM foi definido a partir do NSAP (OSI Network Service Access Point )

cujo padrão se encontra nos documentos ISO 8348 e ITU-T X.213 [NSAP94]. Existem três

tipos de endereços ATM, todos com tamanho de 20 bytes, cujos esquemas são

apresentados na figura 7. O endereço é composto por três partes: identificador de formato e

autoridade (AFI – Authoriry and Format Identifier ), identificador inicial de domínio (IDI –

Initial Domain Identifier ) e campo específico de domínio (DSP – Domain Specific Part ). O

AFI determina a interpretação do resto do endereço. O DSP é dividido em: DSP de ordem

alta (HO-DSP – High Order DSP), identificador de sistema final (ESI – End System

Identifier) e o byte seletor(SEL).

Figura 7 – Formato dos endereços ATM

O formato DCC ( Data Country Codes) segue a especificação ISO 3166, enquanto o

formato ICD ( International Code Designator ) é mantido pelo British Stardards Institute e

por último, o formato E.164 é o padrão utilizado pelas redes RDSI.

Independente do formato de endereçamento utilizado, três campos básicos podem seridentificados:

SEL

SEL

SEL

AFI

AFI

AFI

DCC HO-DSP

HO-DSP

HO-DSPE.164

ESI

ESI

ESI

DSP

DSP

DSP

IDP

IDP

IDP

IDI

IDI

IDI

Formato DCC

Formato ICD

Formato E.164

Identificador de Comutador

13 b tes

Identificador de Sistema Final

6 b tes




21

• Identificador de Comutador: (13 bytes) A codificação deste campo depende do formato

de endereço utilizado, ICD, DCC ou E.164. Seu conteúdo pode possuir informações

sobre topologia da rede, o que facilita o roteamento nas redes ATM.

• ESI ( End System Identifier ): (6 bytes) Identificador de Sistema Final: Usado para

identificar cada interface, presentes em estações finais ou equipamentos de borda,

dentro da rede ATM.

• Byte Seletor (Selector Byte): (1 byte) Utilizado para identificar entidades das camadas

superiores ao modelo ATM.



Capítulo 3 - Soluções de Integração IP/ATM 22

22

CCaappí í ttuulloo 33 -- SSoolluuççõõeess ddee IInntteeggrraaççããoo IIPP / / AATTMM

3.1. Introdução

É de conhecimento geral que, hoje, a pilha de protocolos TCP/IP é a mais utilizada quando

se trata de protocolos de redes de computadores. Como implicação direta deste fato, pode-

se afirmar que grande parte das aplicações desenvolvidas se utilizam destes protocolos para

a sua comunicação. Assim é natural esperar que estas aplicações devam continuar

funcionando quando uma nova tecnologia de rede é adotada.

Com este propósito, duas especificações de integração de IP sobre ATM foram criadas: o

Lan Emulation, padronizado pelo ATM Forum em janeiro de 1995 [LANE1] e o Classical

IP, solução do IETF (Internet Engineering Task Force) publicada em janeiro de 1994.

[RFC1577].

As duas soluções permitem a comunicação entre equipamentos ATM, sejam eles estações

finais, comutadores ou dispositivos de borda, pertencentes sempre à mesma sub-rede IP. A

comunicação entre diferentes sub-redes IP mantém a estrutura convencional, ou seja,

através de roteadores IP.

A seguir serão descritas as características e o funcionamento básico de cada uma das

soluções.

3.2. Classical IP

O Classical IP é uma solução indicada para ambientes onde o IP é o único protocolo de

rede utilizado. Destaca-se pela simplicidade de configuração e funcionamento. Pode ser

configurado para trabalhar utilizando tanto PVC’s quanto SVC’s.




23

O princípio básico desta solução de integração é o de encapsular datagramas IP em pacotes

AAL5, através do encapsulamento LLC/SNAP, para serem transportados até o destinatário

através da rede ATM. No destinatário os pacotes IP são extraídos e entregues à aplicação

ou às camadas superiores, de forma que para estas é transparente o mecanismo utilizado

para a transmissão, seja Ethernet ou Token Ring convencional ou ATM. A figura 8

representa este esquema:

Figura 8 – Mapeamento IP sobre ATM utilizando Classical IP

3.2.1 Servidor ATMARP

Um problema que aparece nas redes convencionais é o de tradução dos endereços lógicos

(endereços IP) para endereços físicos (endereços MAC no caso de redes Ethernet ou Token

Ring). Este problema é resolvido através do protocolo ARP ( Address Resolution Protocol)

que se encarrega de gerar uma mensagem de broadcast contendo o endereço IP desejado.

A estação possuidora deste endereço reconhece a mensagem e responde com seu endereço

físico. A comunicação entre as duas é efetuada, a partir deste ponto, através de mensagens

contendo os endereços lógico e físico de ambas.

Em redes ATM, utilizando Classical IP, não existe a funcionalidade de broadcast . Logo,

uma entidade de rede especial foi criada para a tradução de endereços lógicos (endereços

Estações finaisE thernet

ComutadorATM

Estaçõesfinais ATM

Dispositivode borda

Camada Física

ATM

AAL5

Classical IP

IP

Apl. Existentes

AAL5

Física Física

ATM

CLIPCamadaMAC

IP

Camada Física

Camada MAC

IP

Apl. Existentes

Física Física

ATM




24

IP) para endereços físicos (endereços ATM). Esta entidade de rede é chamada de servidor

ATMARP e pode ser implementado num comutador ou numa estação. Cada sub-rede IP,

também conhecida como LIS (Logical IP Subnet), deve possuir seu servidor ATMARP. A

figura 9 representa duas sub-redes IP em uma mesma rede ATM interligadas através de um

roteador:

Figura 9 – Duas redes IP sobre uma mesma rede ATM utilizando Classical IP

3.2.2 Comunicação na solução Classical IP

Sempre que uma estação é iniciada, ela deve registrar-se no servidor ATMARP para que

possa ser “localizada” por outras estações. Este processo de registro, consiste em enviar ao

servidor ATMARP seu endereço IP e seu endereço ATM. Para que as estações localizem o

servidor ATMARP correspondente à LIS que pertencem, devem ter previamente

configurado o endereço ATM deste servidor. Conforme as estações pertencentes a uma

RedeATM

LIS BLIS A

ServidorATMARP A

ServidorATMARP B

192.168.100.1192.168.200.1

192.168.100.4

192.168.200.4

192.168.200.2

192.168.200.3192.168.100.3

192.168.100.2 Roteador




25

mesma LIS vão se cadastrando junto ao servidor ATMARP, este cria uma tabela de

conversão de endereços IP para endereços ATM.

A partir do seu cadastro junto ao servidor ATMARP, quando uma estação deseja se

comunicar com outra, ela requisita ao servidor ATMARP o endereço ATM do destinatário,

fornecendo o endereço IP do mesmo. O servidor ATMARP responde com o endereço

ATM do destinatário. De posse deste, o emissor estabelece uma conexão (SVC)

diretamente com o receptor.

Quando se utiliza PVC’s, as estações possuem em sua memória uma tabela contendo os

endereços IP’s e os respectivos VPI’s e VCI’s configurados, de modo que fica dispensada

a consulta ao servidor ATMARP.

3.3. Lan Emulation

O Lan Emulation, ou simplesmente LANE, é a solução proposta pelo ATM Forum em

janeiro de 1995 [LANE1] para integração das redes convencionais sobre redes ATM.

Diferentemente do Classical IP, no modelo LANE, o pacote Ethernet ou Token Ring é

encapsulado, com algumas alterações, num quadro AAL5. Desta forma, esta solução não

se restringe ao uso do IP, uma vez que, em princípio, qualquer protocolo de rede (por

exemplo: IPX, AppleTalk, etc.) que seja implementado sobre o Ethernet ou o Token Ring

poderia ser transportado em redes ATM através do LANE. Está fora do escopo deste

trabalho, entretanto, a análise de outros protocolos a não ser o IP. O modelo a seguir,

figura 10, apresenta este conceito:




26

Figura 10 – Modelo de camadas do Lan Emulation

O Lan Emulation, solução mais sofisticada do que o Classical IP, tem seu funcionamento

baseado na arquitetura cliente-servidor. Basicamente, os clientes estão presentes nas

estações finais e equipamentos de borda, enquanto os servidores podem ser

implementados, teoricamente, em qualquer equipamento pertencente à rede ATM. As

funcionalidades do cliente e dos servidores serão descritas abaixo para que se entenda,

posteriormente, o funcionamento da rede como um todo. A figura 11 mostra os

componentes de uma rede emulada.

LEC ( Lan Emulation Client) – Representa a entidade cliente de uma rede emulada. É o

LEC que fornece a interface de emulação da camada de enlace, possuindo inclusive um

endereço MAC. Desta forma, as aplicações operam como se estivessem trabalhando em

uma rede Ethernet ou Token Ring convencional. Este componente está presente nas

estações finais ou em dispositivos de borda (um roteador por exemplo). É responsável pela

comunicação entre estações ou dispositivos de borda e destes com outras entidades da rede

emulada (LES, LECS, BUS, outros LEC’s).

Proxy LEC – O Proxy LEC é um caso especial do LEC, implementado em equipamentos

que conectam estações pertencentes à redes convencionais em redes emuladas ATM. Estes

Camada Física

ATM

AAL5

Lan Emulation

Ethernet/Token Ring

Apl. Existentes

IP / IPX / AppleTalk

Apl. Existentes

Camada Física

Sub-camada MAC

Física Física

ATM

AAL5

Física Física

ATM

LANESub-camadaMAC

Ponte

Comutador ATMEstaçõesfinais ATM

Dispositivode Borda

Estações finaisEthernet/Token

Ring

Ethernet/Token Ring

IP / IPX / AppleTalk




27

equipamentos que implementam o Proxy LEC também são conhecidos como dispositivos

de borda. O exemplo mais comum de Proxy LEC ocorre em comutadores Ethernet (ou Fast

Ethernet) com uma ou mais portas ATM.

LECS ( Lan Emulation Configuration Server) – O servidor de configuração da rede

emulada é responsável por fornecer a configuração inicial ao LEC. Ele provê informações

relativas às ELAN’s (Emulated LAN ou rede emulada) disponíveis, assim como o

endereço ATM do LES de cada uma.

Figura 11 – Componentes de uma rede emulada

LES ( Lan Emulation Server) – O servidor de emulação de rede é responsável pelas

funções de organização e controle de uma ELAN. É a entidade responsável pelo registro e

tradução de endereços MAC em endereços ATM.

BUS ( Broadcast and Unknown Server) – O servidor de broadcast ou destinatário

desconhecido foi concebido de forma a possibilitar a transmissão de mensagens broadcast ,

multicast e de destinatário desconhecido, ou seja, mensagens de endereço não resolvido

pelo LES. Para isso, o BUS mantém uma conexão ponto-multiponto com todos os

LUNI LNNI

LUNI

LECLECLEC

LECProxy

LES 2BUS 2LECS

Rede EthernetRede ATM

ComutadorATM

LES 1BUS 1

LUNILUNI




28

participantes da ELAN. Portanto, sempre que uma mensagem é transmitida ao BUS, ela é

replicada a todas as estações e dispositivos de borda da rede emulada.

A especificação do Lan Emulation não define onde cada de seus servidores deve ser

implementado. Em princípio, eles podem estar localizados em qualquer equipamento

pertencente à ELAN (estações, dispositivos de borda, comutadores, etc.), porém, por

motivos relacionados com a segurança de funcionamento e desempenho dos serviços,

existe uma preferência por parte dos fabricantes em implementar os servidores em

equipamentos de rede (comutadores ATM e roteadores).

3.3.1 Comunicação na solução Lan Emulation

A comunicação entre entidades pertencentes a uma mesma rede emulada realiza-se através

de duas interfaces básicas sobre as quais são implementadas os protocolos. Estas interfaces

são:

LUNI ( Lan Emulation User to Network Interface) – É a interface utilizada para a

comunicação entre um LEC e a rede provedora do serviço de emulação, ou seja, entre dois

LEC’s pertencentes a uma mesma ELAN ou entre um LEC e um dos servidores: LECS,

LES, BUS da correspondente ELAN.

LNNI ( Lan Emulation NNI ) – Interface de comunicação entre provedores de serviço de

uma rede emulada. Basicamente este protocolo é utilizado para prover a troca de

informações relativas à redundância e a distribuição de carga entre as várias instâncias dos

servidores LES e BUS de uma mesma ELAN. Esta interface só foi especificada na versão

LANE 2.0 [LANE2].

Será explicado a seguir como se dá a comunicação numa ELAN, através da interface

LUNI, seguindo os vários estágios de operação de um LEC. [Alles95]




29

I. Registro e Configuração

Ao iniciar a estação, o LEC obtém seu próprio endereço ATM quando do registro junto ao

comutador ao qual está conectado. O endereço ATM do LEC é formado, associando os 13

bytes iniciais do endereço ATM obtido do comutador com os 6 bytes (ESI) codificados na

placa ATM presente na estação. Feito isso, estabelece uma conexão com o LECS e através

de um protocolo específico, obtém a configuração das ELAN’s disponíveis, endereços dos

respectivos servidores LES, tipo da rede emulada (Ethernet ou Token Ring), tamanho

máximo da unidade de transmissão (MTU), nome da ELAN, etc. Vide figura 12.

Existem três procedimentos possíveis para que o LEC seja capaz de localizar o LECS:

pode ser feita através de VCC pré-definido (VPI=0, VCI=17), endereço fixo padrão ou

através de um protocolo chamado ILMI ( Interim Local Management Interface).

Figura 12 – Comunicação entre o LEC e o LECS para obtenção das informações das

ELAN’s configuradas

II. Filiação a uma ELAN

Dado que o LEC estabeleceu conexão com o LECS e recebeu deste as informações sobre

as redes emuladas configuradas, ele pode agora se filiar a uma ou mais ELAN’s. Para isso

ele deve se conectar ao LES de cada ELAN, onde será cadastrado. O LES cadastra cada

LEC 0

LESBUS

LEC 1LEC 2

LECS

ELAN USPMTU 1500End. ATM LES




30

LEC através de um identificador único (LECID), associando a este os endereços MAC e

Figura 13 – Processo de filiação a uma ELAN

ATM do LEC. Passo 1 da figura 13. No caso de se tratar de um proxy LEC, podem existir

mais de um MAC associado a um mesmo LECID e consequentemente a um mesmo

endereço ATM.

Uma vez cadastrado junto ao LES, o LEC deve obter o endereço ATM do BUS. Para isso,

envia ao LES uma mensagem requisitando a tradução do endereço MAC de broadcast . O

LES retorna, ao receber esta mensagem, o endereço ATM do BUS. De posse do endereço

ATM do BUS, o LEC estabelece uma conexão com o BUS, e este adiciona o novo LEC à

sua conexão ponto-multiponto. Passos 2 e 3 da figura 13.

Conhecendo o LES, para a tradução de endereços, e o BUS para a transmissão

multicast / broadcast , o LEC encontra-se pronto para a transmissão de dados.

LEC 0

LESBUS

LEC 1LEC 2

LECS

1

3

12MAC LEC 0

ATM LEC 0

LECID End. MAC End. ATM0 MAC LEC 1 ATM LEC 11 MAC LEC 2 ATM LEC 22 MAC LEC 0 ATM LEC 0




31

III. Transmissão dos Dados

O LEC, basicamente, recebe pacotes da camada de rede (IP,IPX, etc.), “gera” os quadros

da camada de enlace (Ethernet, Token Ring) com algumas diferenças e os encapsula em

pacotes AAL5 para a transmissão sobre o ATM. Para que a transmissão ocorra, é

necessário que exista uma conexão entre o emissor e o receptor. Neste momento três

possibilidades podem ocorrer:

• Já existe a conexão entre o emissor e o receptor – basta então, iniciar a transmissão dos

dados

• Não existe a conexão, mas o emissor possui em sua memória cache o endereço ATM

referente ao MAC destino – estabelece-se um nova conexão e inicia-se a transmissão.

• Não existe a conexão e não se conhece o endereço ATM do destinatário – é necessário

que se execute o processo de tradução de endereços para em seguida estabelecer a

conexão e só então transmitir os dados.

Processo de tradução de endereços MACèATM

O processo de tradução de endereços MAC para endereços ATM deve ser utilizado quando

um LEC deseja comunicar-se com outro LEC, porém não possui o endereço ATM do

mesmo. O LEC formula., então, uma requisição de endereço ATM, chamada LE_ARP

( Lan Emulation ARP) e a envia ao LES.

Enquanto aguarda a respota do LES e com o objetivo de diminuir o atraso inserido, o LEC

inicia a transmissão dos dados através do BUS. Como já foi visto, o BUS mantém uma

conexão ponto-multiponto com todos os participantes da ELAN, logo pode-se garantir que

o destinatário vai receber as mensagens. Esta solução é temporária, pois todos os membros




32

estão recebendo os pacotes e consequentemente consumindo tempo de processamento com

a recepção de pacotes que serão descartados, a não ser o receptor propriamente dito.

Ao receber a resposta LE_ARP do LES, contendo o endereço ATM do destinatário, o LEC

estabelece uma conexão direta com o LEC receptor. Antes, porém, de transmitir através

desta nova conexão, o LEC pára de transmitir através do BUS e envia uma mensagem de

flush, garantindo, portanto, a sequência das células. A figura 14 demonstra a sequência do

procedimento.

Figura 14 – Establecimento de conexão entre LEC’s

3.4. Comparação entre o Lan Emulation e o Classical IP para

Comunicação Multimídia

Vale ressaltar que não é objetivo deste trabalho analisar aspectos específicos de cada

solução, mas avaliar, de forma geral, o desempenho destas em relação ao transporte de

tráfegos com características especiais, como são os tráfegos gerados por aplicações

multimídia.

LEC 0

LESBUS

LEC 1LEC 2

LECS

2 – Dados5 - Flush

1- MAC LEC 1

LECID End. MAC End. ATM0 MAC LEC 1 ATM LEC 11 MAC LEC 2 ATM LEC 22 MAC LEC 0 ATM LEC 0

3- ATM LEC 1

4-Conexão Lec0 Lec 1

6-Dados




33

Segundo os parâmetros analisados: tamanho de buffer , tamanho de mensagem, capacidade

de processamento, [Kiatake98] e [Meylan98] concluem que o Classical IP oferece uma

maior quantidade de banda disponível para a aplicação quando da utilização dos protocolos

de transporte TCP e UDP. Esta maior quantidade de banda disponível se deve a um menor

nível de encapsulamento desta solução, ou seja, a relação carga útil/overhead é maior no

Classical IP.

Além da quantidade de banda disponível, um ponto bastante importante na transmissão

multimídia é a forma como se estabelece a transmissão. Neste ponto, o Classical IP

apresenta um fator limitante bastante restritivo: a incapacidade de transmissão

broadcast / multicast . O Lan Emulation, por sua vez, possui um servidor específico para

este tipo de transmissão. A partir da segunda versão do Lan Emulation [LANE2], é

possível a implementação de servidores redundantes, eliminando, portanto, o problema de

um servidor ser um ponto único de falhas. Também nesta versão foi introduzido o conceito

de servidor multicast , criado especificamente para tratar das conexões multicast . Esta

solução será melhor explorada nos próximos capítulos.

Em se tratando de interconexão de redes, as duas soluções seguem o modelo de roteamento

IP convencional. Segundo [Santos98], as soluções de comutação IP, por exemplo: IP

Switching, MPOA, etc., apresentam um melhor desempenho no que diz respeito ao atraso

inserido, podendo servir de base para aprimorar futuras implementações do Lan Emulation

ou do Classical IP.

Em relação aos parâmetros de qualidade de serviço, ambas as soluções são falhas. Tanto o

Classical IP quanto o Lan Emulation utilizam conexões do tipo UBR (Unspecified Bit

Rate), não sendo possível, portanto, reservar banda, definir atraso máximo suportado,

restringir variação do atraso, etc. Portanto, o ATM, quando da utilização destas soluções,




34

fornece apenas uma maior quantidade de banda disponível, o que não significa nenhuma

garantia de utilização para a aplicação. Aplicações com restrições temporais e que

demandam grande quantidade de banda estariam concorrendo diretamente com as

aplicações convencionais, degradando a qualidade das transmissões.

Concluindo o que foi dito acima, percebe-se que as soluções de integração de IP e ATM

atualmente padronizadas, não tiram proveito dos recursos disponibilizados pela tecnologia

ATM. Além disso, já existem definições de novas interfaces (por exemplo o WinSock2),

que permitem o acesso ao ATM de forma nativa, dispondo de todos os recursos que a

tecnologia fornece.

O projeto de novas aplicações multímidia sobre redes ATM deve considerar aspectos de

compatibilidade com aplicações já existentes, pois a base instalada é muito grande e deve

ser substituída gradualmente. Por este motivo as soluções de integração de IP e ATM

continuarão a existir por algum tempo e favorecerão a implantação de novas redes ATM

em ambientes que se utilizam de redes convencionais. No entanto, a utilização destas

soluções restringe o uso dos recursos fornecidos pelo ATM em sua plenitude. Logo, o

desenvolvimento de aplicações que acessem o ATM de forma nativa, terá como grande

vantagem a possibilidade de explorar os recursos de QdS fornecidos por esta tecnologia,

resultando em transmissões de voz, vídeo e dados de elevada qualidade e com atrasos

controlados.



Capítulo 4 - Comunicação Multicast 35

35

CCaappí í ttuulloo 44 -- CCoommuunniiccaaççããoo M M uul l t tii c c a a s s t t

4.1. Introdução

As aplicações multimídia têm, em sua maioria, a característica de possuir vários

participantes simultâneos, ou seja, existem um emissor e vários receptores, ou ainda, vários

emissores para vários receptores. Uma forma simples de implementar estes sistemas é

manter uma conexão para cada par emissor/receptor. Fica óbvio, porém, a ineficiência do

sistema, uma vez que cada mensagem a ser transmitida, deverá ser replicada pelo emissor

para cada um de seus receptores.

Com o crescimento da necessidade de uma forma de comunicação que atingisse vários

destinatários de maneira eficiente, surgiu o conceito de multicast . O multicast pode ser

explicado como: forma de comunicação onde, através de uma única operação de

transmissão, resulta no envio simultâneo para vários destinatários. A figura 15, mostra

graficamente este conceito.

Figura 15 – Comunicação Multicast

Uma forma simples de entender o funcionamento da comunicação multicast é a

transmissão de mensagens broadcast numa rede Ethernet de meio compartilhado. Imagine

que o “Elemento de Rede” da figura 15 seja um Hub Ethernet e que o emissor esteja

Emissor

Receptor 1

Receptor 2

Receptor n

Elementode Rede

.

.

.

.

.

.




36

transmitindo mensagens do tipo broadcast . Através de uma única operação de envio, o

Hub replicará a mensagem para todas as estações conectadas a ele. Como a mensagem é

destinada a todas as estações, todas a recebem e processam.

Fica claro, a partir do exemplo anterior, que comunicação broadcast (os destinatários são

todos os elementos da rede) e unicast (existe um único destinatário) são subcasos da

comunicação multicast .

Este capítulo apresentará as diversas formas de utilização da comunicação multicast em

redes Ethernet quando da utilização do TCP/IP e as propostas para sua utilização em redes

de alta velocidade (ATM).

4.2. Conceitos Básicos

Para viabilizar o estudo da comunicação multicast em redes de computadores, é necessário

que se introduza uma linguagem de representação do modelo em questão. Assim como na

maioria dos trabalhos encontrados na literatura, uma rede de computadores será

representada como um grafo conectado N=(V,E), onde V representa um conjunto de nós e

E representa um conjunto de ligações entre estes nós. A existência de uma ligação e=(u,v)

do nó u até o nó v, implica também na existência de uma ligação e’=(v,u) para qualquer u,e

∈ E , ou seja, está sendo assumido que as ligações são full-duplex.

Como em redes reais, é necessário que se defina uma função custo C(e) e uma função de

atraso A(e) para toda ligação e=(u,v)∈ E . As funções custo e atraso podem tomar qualquer

valor real não negativo. A função custo pode ser entendida como custo monetário ou custo

em função do tráfego existente em uma ligação. Nesta dissertação a função custo estará

associada ao tráfego existente na ligação, uma vez que o objetivo é de estudar o

gerenciamento eficiente dos recursos da rede. A função atraso A(e), expressa o atraso que

os pacotes adquirem ao passar por uma ligação e. Este atraso pode ser atribuído ao tempo




37

de transmissão ou propagação, devido ao enfileiramento, roteamento ou comutação. Neste

trabalho também é assumido que as ligações são assimétricas, ou seja , C(e) ≠ C(e’), dado

que este é um fato real em redes de computadores.

Chama-se de caminho uma sequência alternada de nós e ligações. Assim define-se um

caminho P(v0 , vk ) = v0 ,e1 ,v1 ,e2 ,…,vk-1 ,ek ,vk onde todo ei = (vi-1 , vi) ∈ E, 1 ≤ ι ≤ k . Um

caminho contém loops se algum dos nós se repete. Se não houver repetição de nós diz-se

que o caminho é livre de loops. Para simplificar, um caminho será representado como uma

seqüência de ligações : P(v0 , vk ) = {v0 , v1 , v2 , …, vk }.

O custo de um caminho P(v0 , vk ) é definido como a soma dos custos das ligações que

constituem o caminho:

Analogamente, define-se o atraso fim-a-fim do caminho P(v0 , vk ) como sendo a soma dos

atrasos parciais em cada ligação que constitui o caminho:

As definições apresentadas aplicam-se para uma sessão multicast com uma única fonte.

Um grupo multicast G = {g1 , g2 , …, gn } ⊆ V , onde n = |G| ≤ |V|, é formado por um

conjunto de nós participantes de uma sessão, sendo identificados por um único endereço de

grupo i. Um nó s ∈ V é uma fonte transmissora de um grupo multicast G. Uma fonte s de

um grupo multicast pode ou não pertencer ao grupo multicast . Uma árvore multicast T(s,

G) ⊆ E com uma fonte específica é uma árvore com uma única fonte s (também chamada

raiz) que transmite a todos os membros do grupo multicast G.

∑∈

=),(

0

0

)()),((k vvPe

k eC vvPCusto

∑∈

=),(

0

0

)()),((k vvPe

k e AvvP Atraso




38

O custo total da árvore é dado pela soma dos custos das ligações da árvore:

O atraso fim-a-fim máximo de uma árvore multicast é o atraso máximo da fonte até os

membros do grupo multicast :

onde PT (s, g) é o caminho de s até g sobre a árvore T(s, G).

4.3. Taxonomia de Conexões Multiponto

É importante que se estabeleça uma taxonomia entre as possíveis formas de implementação

de conexões multiponto, para que a discussão e comparação das soluções que

implementam este tipo de conexão, sejam coerentes. Assim, segundo [Winsock2], esta

taxonomia será detalhada a seguir.

Em primeiro lugar é necessário que se diferenciem dois planos da conexão multiponto:

plano de controle e plano de dados.

4.3.1 Plano de controle

O plano de controle é responsável pela forma de como a conexão multiponto é criada. Dois

tipos podem ser identificados: rooted e non-rooted , ou seja, com ou sem a presença de uma

raiz, respectivamente. No caso do plano de controle rooted , existe um participante especial,

chamado de root (raiz), responsável por iniciar a conexão multiponto. O root deve

permanecer presente durante todo o tempo de vida da conexão, caso contrário a conexão é

desfeita. Ele pode adicionar e remover folhas (leaves, ou estações receptoras) a qualquer

momento. Em algumas implementações, as folhas podem incluir-se a uma determinada

∑∈= ),( )()),(( GsT e

eC GsT Custo

= ∑

∈∈ ),(

)()),((_ maxgsPeGg T

e AGsT Atraso Max




39

conexão. Em implementações que se utilizem de plano de controle non-rooted , todos os

membros pertencentes a uma sessão multiponto são folhas, ou seja, não existe nenhum

elemento especial responsável por iniciar e manter a conexão. Cada participante, precisa

incluir-se na sessão multiponto já existente.

4.3.2 Plano de Dados

O plano de dados trata da transferência dos dados entre os participantes da sessão. Para a

transmissão de dados, novamente dois tipos são diferenciados: rooted e non-rooted .

Na transmissão de dados rooted , existe um elemento especial chamado de root (raiz). Toda

a transmissão de dados ocorre entre o root e os outros participantes (folhas). Não existe

comunicação, através da sessão multiponto, entre as folhas diretamente. O tráfego pode ser

unidirecional ou bidirecional, dependendo de cada implementação. No plano de dados non-

rooted , todos os participantes são iguais, isto é, não existe nenhum elemento especial. Em

outras palavras, isto quer dizer que todos têm a capacidade de enviar dados à sessão

multiponto e estes dados serão recebidos por todos os participantes desta mesma sessão.

4.3.3 ATM e Multicast IP segundo a Taxonomia

A seguir é apresentada uma tabela, figura 16, comparativa do ATM e do Multicast IP em

relação às definições descritas anteriormente.

Plano de Dados Plano de Controle

Tecnologia Rooted Non-Rooted Rooted Non-Rooted

Multicast IP X X

ATM X X

Figura 16 – Tabela comparativa entre Multicast IP e ATM, segundo taxonomia proposta




40

Na tecnologia ATM, até versão do UNI 3.1, apenas o root podia acrescentar novos

participantes à conexão multicast . A partir da versão do UNI 4.0, qualquer participante

pode incluir-se numa conexão multicast já existente.

4.4. Algoritmos de Roteamento Multicast

Diversos algoritmos de roteamento multicast foram propostos de forma que árvores

multicast fossem construídas e consequentemente aplicações pudessem transmitir à vários

destinatários simultaneamente e sem desperdício de recursos dos elementos de rede.

É fundamental o conhecimento destes algoritmos, uma vez que é a partir deles que são

projetados e implementados os protocolos de roteamento multicast . Sendo assim, nesta

seção serão apresentados dois algoritmos simples: Inundação (Flooding) e Árvores de

Espalhamento (Spanning Trees) e quatro de maior complexidade: RPB ( Reverse Path

Broadcasting), TRPB (Truncated Reverse Path Broadcasting), RPM ( Reverse Path

Multicasting), Árvores de Steiner (ST – Steiner Trees) e por último o CBT (Core Based

Trees).

4.4.1 Inundação (Flooding)

O algoritmo de Inundação, utilizado no protocolo de roteamento IP unicast OSPF (Open

Shortest Path First ), é a técnica mais simples para a distribuição de pacotes multicast IP

em uma rede interligada por roteadores. Neste algoritmo, quando o roteador recebe um

datagrama multicast IP em uma determinada interface, é verificado se é a primeira vez que

este datagrama é recebido. Se for a primeira vez, o roteador replica o datagrama em todas

as suas interfaces, exceto naquela por onde foi recebido. Caso não seja a primeira vez que

aquele datagrama atinge o roteador, este simplesmente o descarta. Desta forma, é possível

garantir que todos os roteadores da rede receberão ao menos uma cópia de cada datagrama

enviado.




41

Apesar da simplicidade do algoritmo, algumas desvantagens aparecem. O algoritmo de

Inundação gera um grande número de mensagens duplicadas o que desperdiça grande

quantidade de banda dos enlaces. Além disso, cada roteador deve manter um registro dos

pacotes que já recebeu, de forma a poder identificar e descartar pacotes repetidos. Esta

restrição causa um ineficiente uso da memória dos roteadores.

4.4.2 Árvores de Espalhamento (Spanning Trees)

Este algoritmo é amplamente utilizado em pontes (bridges) IEEE-802 MAC devido à sua

facilidade de implementação e pela economia dos recursos necessários. Basicamente, seu

funcionamento consiste em escolher alguns enlaces de forma a montar uma estrutura de

árvore, ou seja, formar um conjunto de roteadores e enlaces que não possuam loops e que

entre dois roteadores quaisquer só exista um único caminho que os interligue. Esta árvore é

construída de forma a atingir todos os roteadores da rede, por isso o nome: Árvore de

Espalhamento. Uma vez construída a árvore, ao receber um pacote multicast IP, cada

roteador o replicará apenas nas interfaces cujos enlaces pertençam à árvore, exceto naquela

de onde ele foi recebido. Este procedimento garante que todos os roteadores recebam uma

cópia do pacote. Percebe-se neste método a economia de recursos gastos em relação ao

algoritmo anterior. Logo, basta que cada roteador mantenha a informação de quais de suas

interfaces pertencem à árvore.

A figura 17 mostra o processo de criação de uma árvore de espalhamento. O custo de cada

enlace é ilustrado sobre o próprio.




42

Figura 17 – Árvore de Espalhamento

Como desvantagem principal deste algoritmo destaca-se o fato de ele centralizar o tráfego

em um conjunto mínimo de enlaces. Caso tenha-se uma situação de congestionamento ou

queda de um enlace, todos os roteadores subsequentes são prejudicados.

4.4.3 RPB ( Reverse Path Broadcasting)

O RPB surgiu como um aprimoramento da Árvore de Espalhamento e é bastante utilizado

no MBone ( Multicast Backbone). Ao invés de criar uma árvore de espalhamento que cobre

todos os roteadores da rede, o RPB cria uma árvore de espalhamento implícita para cada

fonte emissora. Assim sendo, suponha que um roteador receba um pacote multicast IP em

sua interface I0 e que o endereço origem contido neste pacote indica que a fonte

transmissora seja F. De posse destas informações, o roteador irá verificar se o menor

caminho entre ele e a fonte F utiliza a interface I0. Caso a resposta seja afirmativa, o

roteador replicará o pacote em todas as suas interfaces, exceto naquela por onde ele foi

recebido. Caso contrário o pacote é descartado. Segundo o que foi explicado, percebe-se

que a árvore de espalhamento é construída dinamicamente em função do transmissor do

pacote. Portanto, várias árvores podem existir simultaneamente. A figura 18 mostra duas

árvores de espalhamento numa mesma rede.

D

A

E

B

C

1

3

6

2

5

4

D

A

E

B

C

1

3

6

2

5

4

Rede formada por roteadoes Árvore de Espalhamento a partir da fonte C




43

Figura 18 – Árvores geradas a partir do RPB ( Reverse Path Broadcasting)

Este algoritmo tem como principais vantagens o fato de ser fácil de implementar e de

eficiência satisfatória. Pelo fato dos roteadores não precisarem conhecer toda a árvore de

espalhamento, existe economia de recursos. Como várias árvores são construídas

simultaneamente, não existe o problema de concentração, logo o tráfego é distribuído pela

rede, fornecendo mais segurança (a queda de um enlace não paralisa todas as transmissões

multicast ) e diminuindo a possibilidade de congestionamentos. Como desvantagem

salienta-se o fato do algoritmo não considerar as informações de participação de membros

do grupo multicast .

4.4.4 TRPB (Truncated Reverse Path Broadcasting)

O TRPB foi concebido com o objetivo de aprimorar o RPB em relação às suas restrições.

Como será visto na descrição do protocolo IGMP ( Internet Group Management Protocol),

um roteador tem condições de tomar conhecimento sobre a existência de membros

participantes de um grupo multicast qualquer, em uma determinada sub-rede IP, a qual

também pertence. Logo, se o roteador descobre que não existe nenhuma estação

D

A

E

B

C

1

3

6

2

5

4

D

A

E

B

C

1

3

6

2

5

4

Rede formada por roteadores

Árvore de Espalhamento a partir da fonte C

D

A

E

B

C

1

3

6

2

5

4

Árvore de Espalhamento a partir da fonte A




44

pertencente a um determinado grupo multicast , e ele é o único roteador desta sub-rede,

pode parar de transmitir os pacotes multicast relacionados a este grupo.

Apesar da informação de participação de grupos multicast ser utilizada pelo TRPB e com

isso, ser possível retirar sub-redes finais da árvore de espalhamento, as sub-redes

intermediárias continuarão a participar da árvore de espalhamento, mesmo que não tenham

nenhum participante pertencente ao grupo.

4.4.5 RPM ( Reverse Path Multicasting)

O algoritmo RPM, também conhecido como RPB com desligamentos, é um

aprimoramento dos algoritmos RPB e TRPB. Ele constrói uma árvore que transmite

somente para:

I. sub-redes que tenham membros pertencentes ao grupo multicast ;

II. roteadores e/ou sub-redes que façam parte do menor caminho até uma sub-rede que

possua pelo menos um membro do grupo.

Dado o par (fonte, grupo) o primeiro pacote é transmitido através do algoritmo TRPB. Os

roteadores que não possuírem outros roteadores “abaixo” deles na árvore, serão chamados

de roteadores terminais. Se um roteador terminal receber um pacote multicast para um par

(fonte, grupo) e não possuir nenhum membro deste grupo nas sub-redes das quais faz

parte, enviará uma mensagem de desligamento ( prune) ao roteador responsável pela

transmissão deste pacote. A mensagem de desligamento indica que os pacotes multicast

relacionados com um determinado par (fonte, grupo) não devem mais ser retransmitidas

para aquele enlace.

É importante esclarecer que as mensagens de desligamento são enviadas apenas ao

roteador imediatamente anterior e este deve armazenar esta informação em sua memória.

Caso o roteador que acabou de receber uma mensagem de desligamento, proveniente de




45

um roteador “abaixo” dele, perceba que não existem sub-redes ou roteadores interessados

em receber pacotes multicast para um dado par (fonte, grupo), ele gerará uma nova

mensagem de desligamento e enviará ao roteador através do enlace por onde estas

mensagens foram recebidas. Este efeito cascata garante que os pacotes multicast sejam

enviados apenas através dos enlaces que façam parte do caminho até estações pertencentes

ao grupo. A figura 19 ilustra uma rede onde o algoritmo RPM é aplicado.

Figura 19 – Árvore multicast gerada pelo algoritmo RPM

As informações sobre a participação de membros do grupo e a topologia da rede podem ser

alteradas, logo o estado de desligamento dos enlaces deve ser renovado em intervalos

regulares. O algoritmo RPM resolve este problema, removendo a informação de

desligamento dos roteadores. Com isso, o roteador passa a retransmitir os pacotes de

multicast para todas as suas interfaces e o processo de desligamento é repetido caso seja

necessário. Esta é uma das desvantagens deste algoritmo. Outra desvantagem é quantidade

de memória do roteador utilizada para armazenar o estado das interfaces em relação a cada

par (fonte, grupo) existente.

R

R

R

R

R

R

Caminho das mensagens multicast

Mensagens de desligamento (prune)

Caminhos desligados da árvore multicast

Estação pertencente ao grupo multicast

R Roteador IP




46

4.4.6 Árvores de Steiner

Os algoritmos pertencentes à família do RPB (RPB, TRPB, RPM) utilizam a técnica de

calcular o menor caminho entre o emissor e cada um dos receptores para transmissão dos

pacotes multicast , garantindo que estes são entregues o mais rápido possível. Entretanto,

nenhum destes algoritmos procura minimizar a utilização dos recursos da rede.

O algoritmo Árvore de Steiner tem por objetivo minimizar a utilização dos enlaces da rede,

mantendo o compromisso de entregar os pacotes a todos os participantes do grupo

multicast . A figura 20 demonstra a melhor utilização dos enlaces por este algoritmo em

comparação ao RPB.

Figura 20 – Árvore de Steiner

Como pode ser observado pela figura 20, a árvore gerada pelo algoritmo de Steiner possuium número menor de enlaces, porém, pode-se dizer que é uma árvore mais lenta, uma vez

que para atingir o nó D é necessário passar por mais roteadores. A elevada complexidade

de implementação deste algoritmo o tornou de pouca importância prática. Outra

desvantagem é a dificuldade de incluir ou retirar elementos da árvore, uma vez que esta

deve ser inteiramente recalculada.

D

A

E

B

C

1

3

6

2

5

4

D

A

E

B

C

1

3

6

2

5

4

C Fonte transmissora

Membro do grupo multicast

Árvore gerada pelo RPB Árvore de Steiner




47

4.4.7 CBT (Core Based Trees)

O último algoritmo proposto para construir árvores multicast é chamado de CBT (Core

Based Tree). Ao contrário dos outros algoritmos, este cria uma única árvore para cada

grupo, ou seja, não depende da localização da fonte emissora dos pacotes multicast . Um

roteador ou um conjunto de roteadores são escolhidos para formarem o centro de

distribuição dos pacotes multicast . Todas as mensagens destinadas a um determinado

grupo são replicadas através do centro de distribuição como se fossem mensagens unicast ,

até encontrarem um roteador que faça parte da árvore de distribuição correspondente. Os

pacotes são, então, replicados em todas as interfaces deste roteador, exceto aquela por onde

foi recebido. A figura 21 ilustra este procedimento.

Figura 21 – Árvore CBT

Como o algoritmo CBT constrói apenas uma árvore para cada grupo multicast , os

roteadores guardam uma quantidade menor de informação em relação aos algoritmos

anteriores. Porém, por concentrar todo o tráfego relativo a um grupo num único centro de

distribuição, podem ser gerados pontos de congestionamento.

R

R

R

R

R

RR

Core R Core R

Core R Roteador do centro de distribuição

Roteador

Direção dos pacotes multicast

Centro de distribuição




48

4.5. Multicast IP

A pilha de protocolos TCP/IP é hoje, sem dúvida, a mais utilizada em todos os ambientesde redes de computadores (acadêmico, industrial, comercial, doméstico). Portanto, como é

de se esperar, as aplicações são desenvolvidas sobre este modelo. As aplicações multimídia

disponíveis atualmente, que se utilizam de recursos multicast , não fogem a esta regra, logo

se faz necessário conhecer o funcionamento dos recursos de IP multicast implementados

sobre redes convencionais (Ethernet), para depois verificar as soluções correspondentes

sobre redes ATM.

4.5.1 Endereçamento Multicast IP

Está fora do escopo desta dissertação explicar em detalhes o funcionamento do protocolo

TCP/IP. Caso haja a necessidade deste conhecimento prévio, [Stevens97] e [Commer97]

são algumas referências indicadas. Normalmente, em uma rede TCP/IP, cada estação tem

seu próprio endereço IP e quando uma estação envia uma mensagem para outra, deve-se

gerar um pacote contendo o endereço IP do destinatário de forma que este seja capaz de, ao

receber o pacote, identificar que deva aceitar o mesmo. Esta regra simples não se aplica,

entretanto, quando se trata de comunicação multicast . Neste caso, existe um endereço IP de

grupo, onde cada participante deve, além do seu próprio endereço IP, estar apto a receber

pacotes destinados ao IP do grupo. A classe D do endereçamento IP foi especificada para

servir aos grupos multicast e compreende a faixa de endereços 224.0.0.0 até

239.255.255.255. Esta faixa é decorrente do fato de que é padronizado que os 4 bits de

maior ordem são fixos (1110) e os 28 bits restantes compõe os endereços de grupo

multicast .




49

4.5.2 Multicast IP sobre Ethernet

O processo de transmissão de pacotes IP sobre Ethernet, funciona da seguinte maneira:

dado um endereço IP, através do ARP, descobre-se o endereço MAC correspondente para

formar o pacote Ethernet e efetuar a transmissão. Porém no caso de uma transmissão

multicast , não existe uma única estação com o endereço MAC correspondente ao endereço

IP de grupo. Logo se faz necessário um mapeamento dos endereços de IP de grupo em

endereços MAC de grupo.

O endereço MAC Ethernet é composto por 6 bytes, onde ficou estabelecido que o bit de

menor ordem do primeiro byte deve ser 1 para indicar que se trata de endereço de grupo.

Assim sendo, o IANA ( Internet Assign Number Authority) estabeleceu que a faixa

01:00:5e:00:00:00 - 01:00:5e:7f:ff:ff destina-se ao uso de quadros multicast . O

mapeamento dos endereços IP classe D para endereços multicast Ethernet é mostrado na

figura 22.

Figura 22 – Mapeamento de endereços IP classe D em endereços MAC Ethernet

Como pode ser observado na figura 22, apenas os 23 bits de ordem mais baixa do endereço

IP multicast (classe D) são utilizados para o mapeamento em endereços MAC – Ethernet,

implicando num mapeamento não único. Observe o exemplo a seguir. Suponha que os

Estes 5 bits não são usadospara formar o endereço MAC

48 bits do endereço MAC

0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0

1 1 1 0

0 7 8 15 16 23 24 31

23 bits de ordem mais baixa do endereço multicast IP

copiados para o endereço MAC




50

endereços 224.128.64.32 (e0.80.40.20 em hexadecimal) e 224.0.64.32 (e0.00.40.20 em

hexadecimal) sejam utilizados para a transmissão multicast em uma rede Ethernet. Pelas

regras acima descritas ambos seriam mapeados no endereço Ethernet: 01:00:5e:00:40:20.

Logo, mesmo que a camada de enlace possa filtrar pacotes Ethernet que não sejam

endereçadas à estação, este filtro pode não ser suficiente, exigindo que o pacote seja

enviado para a camada de rede para ser analisado.

Conclui-se então, que a transmissão multicast em redes Ethernet pode ser feita de maneira

simples, uma vez que esta possui suporte nativo para este tipo de comunicação.

4.6. Protocolos de Roteamento Multicast

O início do desenvolvimento de protocolos multicast ocorreu no final da década de 80,

quando observou-se um grande crescimento da Internet e a aparição das primeiras

aplicações multi-usuário. Como já foi visto anteriormente, a implementação de

comunicação multicast sobre o IP ( Internet Protocol) utiliza o endereçamento classe D,

conforme determinado pela Internet Society. O IGMP ( Internet Group Management

Protocol) [IGMP96] é um protocolo também baseado no endereçamento classe D, e

responsável pela manutenção da informação sobre os participantes dos grupos multicast

em redes locais. Para o roteamento multicast IP em redes de longa distância existem

protocolos já consolidados e novas propostas. Estes serão discutidos a seguir.

4.6.1 IGMP ( Internet Group Management Protocol)

É fundamental o estudo do protocolo IGMP para um melhor entendimento do

funcionamento do conceito do multicast em redes TCP/IP. Através do IGMP, todos os

sistemas pertencentes a uma mesma rede física podem tomar conhecimento sobre as

estações que pertencem aos grupos multicast existentes. Esta informação é essencial aos




51

roteadores multicast , uma vez que, desta maneira, os roteadores multicast tomam a decisão

sobre quais datagramas IP devem ser replicados e para quais interfaces.

O protocolo IGMP é implementado sobre a camada IP do modelo de referência do TCP/IP,

assim sendo, as mensagens IGMP são transmitidas através de datagramas IP.

Diferentemente de outros protocolos, o IGMP possui mensagens de tamanho fixo, como

pode ser observado na figura 23.

Figura 23 – Encapsulamento de mensagem IGMP em um datagrama IP

O primeiro campo indica a versão do protocolo IGMP em uso (pode ser versão 1 ou 2). O

campo “tipo” indica do que se trata a mensagem: se for 1 indica que é uma consulta

realizada pelo roteador multicast , se for 2 trata-se de uma resposta enviada por uma

estação. O checksum é utilizado para garantir a consistência da mensagem. O endereço IP

de grupo multicast indica para qual sessão multicast a mensagem está sendo direcionada ou

é 0 quando se realiza uma consulta dos grupos existentes.

Operações Básicas sobre o IGMP

Os participantes de um grupo multicast são dinâmicos, ou seja, seus membros podem ser

incluídos ou retirados de uma sessão a qualquer momento, sem afetar o resto do grupo.

Header IP MensagemIGMP

Datagrama IP

20 bytes 8 bytes

0 3 4 7 8 15 16 31

versão ti onão

utilizado checksum

Endereço IP de grupo multicast (classe D)

8 bytes




52

Assim sendo, é necessário entender o modo de admissão, retirada e a pesquisa dos

membros participantes de uma sessão multicast .

Manutenção do grupo Multicast

As mensagens IGMP são utilizadas para que os roteadores multicast mantenham controle

sobre a participação de estações nos grupos multicast existentes em cada uma de suas

interfaces. Para que se mantenha este controle foram estabelecidas algumas regras

referentes ao protocolo:

• Uma estação deverá enviar uma mensagem IGMP-report sempre que o

primeiro processo de uma estação filiar-se a um determinado grupo multicast .

Se existirem vários processos em uma mesma estação filiados a um mesmo

grupo, apenas uma mensagem deverá ser enviada.

• Uma estação não deve enviar uma mensagem quando um processo se desliga

do grupo. Apenas deixa de responder às mensagens IGMP-query geradas pelo

roteador multicast .

• O roteador multicast envia mensagens IGMP-query em intervalos regulares

para verificar se existem processos pertencentes à grupos multicast . O roteador

realiza esta tarefa em cada uma de suas interfaces. Nesta mensagem o endereço

IP de grupo utilizado é 0, uma vez que é esperada uma resposta de cada grupo

existente com pelo menos um participante.

• Apenas uma estação de cada grupo que contenha pelo menos um participante,

responde a uma consulta feita pelo roteador, enviando uma mensagem IGMP-

report referente ao seu grupo.




53

Admissão ao grupo multicast

Quando um processo em execução numa estação deseja juntar-se a um grupo multicast , ele

gera uma mensagem IGMP-report , informando o endereço de grupo multicast que deseja

fazer parte. Neste momento a camada de enlace desta estação é configurada de tal forma a

receber quadros cujo endereço destino é do grupo multicast (por exemplo quadros

multicast Ethernet) e a enviá-los à camada de rede (IP). A partir daí, a estação passa a

possuir dois endereços MAC (o próprio da interface e um do grupo multicast ) e dois

endereços IP (o próprio da estação e o do grupo multicast ).

Através do IGMP-report , todas as estações pertencentes à mesma rede física, inclusive o

roteador multicast , ficam sabendo que um novo participante foi incluído na sessão

multicast .

Desligamento do grupo multicast

Quando o último processo membro de um determinado grupo desliga-se do mesmo, dois

diferentes procedimentos existem para a estação informar o roteador multicast de que não

recebe mais mensagens multicast . Estes procedimentos diferenciam-se em função da

versão do IGMP.

Na versão 1 deste protocolo, o desligamento de uma estação resume-se a uma operação

local, ou seja, a estação reconfigura a camada de enlace de tal forma a não receber mais

pacotes multicast e, portanto, não os enviar mais à camada de rede. Esta última, por sua

vez, deixa de ter o endereço IP referente ao grupo multicast a que pertencia. Supondo que

esta fosse a última estação desta sub-rede a receber as mensagens multicast , o roteador

toma conhecimento de seu desligamento após enviar uma mensagem de consulta

( IGMP_query) e não receber nenhuma resposta, fazendo com que pare de replicar as

mensagens multicast para esta sub-rede.




54

Na versão 2 deste protocolo, além da reconfiguração da camada de enlace, foi criada uma

mensagem IGMP_leave, cuja função é a de informar os elementos da rede sobre o

desligamento de uma estação, transportando o endereço IP do grupo ao qual a estação

estava filiado. Desta forma o roteador multicast fica sabendo imediatamente se deve

continuar a replicar as mensagens multicast para a sub-rede a qual pertencia a estação que

acaba de se desligar do grupo.

4.7. Protocolos de Roteamento Multicast IP em Redes de Longa

Distância

Da mesma forma que nas transmissões de pacotes unicast são necessários protocolos de

roteamento (por exemplo: RIP – Routing Information Protocol, OSPF – Open Shortest

Path First , etc.) para redirecionar as mensagens nos devidos enlaces, nas transmissões

multicast este fato se repete. Nesta seção serão discutidos os principais protocolos de

roteamento multicast IP em redes de longa distância e como estes utilizam os conceitos dos

algoritmos de roteamento multicast apresentados. Também será descrito o mecanismo

utilizado para viabilizar as transmissões multicast quando existirem roteadores

intermediários que não implementam nenhum protocolo de roteamento multicast .

4.7.1 DVMRP

O DVMRP ( Distance Vector Multicast Routing Protocol) foi o primeiro protocolo

padronizado para o roteamento multicast [RFC1075]. Foi concebido tendo como base o

RIP ( Routing Information Protocol), com a diferença de que o RIP replica os pacotes

unicast em função da informação do próximo roteador em direção ao destino, enquanto o

DVMRP constrói a árvore de distribuição em função da informação obtida a partir do

roteador anterior.




55

O funcionamento deste protocolo está intimamente ligado ao algoritmo RPM. Assim

sendo, o primeiro pacote de uma transmissão multicast é transmitida em todas as interfaces

dos roteadores. A partir deste ponto, mensagens de desligamento são geradas de forma a

isolar as sub-redes que não possuem membros do grupo. Uma nova mensagem (graft

message) foi criada com o objetivo de rapidamente reestabelecer um enlace que havia sido

retirado da árvore de distribuição. Esta mensagem é utilizada quando um novo membro,

pertencente a uma sub-rede desligada da árvore de distribuição, desejar incluir-se num

determinado grupo. O mecanismo de inundação de tempos em tempos é mantido no

DVMRP, de forma que as informações sobre os desligamentos sejam atualizadas

periodicamente.

Quando existirem mais de um roteador presente na mesma sub-rede, aquele que estiver

mais próximo da fonte é eleito para retransmitir os pacotes multicast , enquanto que os

outros simplesmente descartarão tais pacotes. Se a distância for a mesma, aquele que tiver

o menor endereço IP será o eleito.

O DVMRP permite ainda, a configuração de túneis. Os túneis permitem a interligação de

dois roteadores multicast através de roteadores intermediários que não possuem nenhum

protocolo de rotemento multicast implementado. Esta técnica encapsula os pacotes

multicast em pacotes unicast convencionais para poderem percorrer o túnel.

A abrangência da transmissão multicast pode ser definida através do campo TTL (Time to

Live) do cabeçalho IP. Desta forma a figura 24 relaciona o valor do TTL com a

abrangência da transmissão.




56

TTL

(Time to Live ouTempo de Vida)

Escopo

0 Restrito à mesma estação

1 Restrito à mesma sub-rede

15 Restrito ao mesmo sítio

63 Restrito à mesma região

127 Abrangência Global

191 Abrangência Global, com banda limitada

255 Sem restrição

Figura 24 – Tabela sobre a abrangência da transmissão multicast

4.7.2 MOSPF

O MOSPF ( Multicast Extensions to OSPF), definido em [RFC1584], é uma extensão ao

protocolo de roteamento unicast OSPF (Open Shortest Path First ) versão 2 [RFC1583].

Ele se utiliza das informações sobre a participação das estações nos grupos multicast

obtidas através do protocolo IGMP e das tabelas construídas pelo OSPF para criar a árvore

de distribuição. Estas árvores são de menor caminho e construídas sob demanda para cada

par (fonte, grupo).

O MOSPF possui uma estrututra de roteamento hierárquico. Os elementos de rede global

são divididos em sistemas autônomos (AS – Autonomous Systems). Cada AS é então

dividido em subgrupos chamados de áreas. Existem diferentes procedimentos para o

roteamento dentro de uma mesma área, entre áreas diferentes e entre sistemas autônomos

diferentes.

Como o OSPF é um protocolo baseado no estado dos enlaces, sua base de dados concentra

informações sobre toda a rede. Assim é possível criar uma árvore de distribuição utilizando

o algoritmo de Dijkstra (algoritmo de menor caminho). Acrescentando as informações




57

relativas aos membros do grupo multicast , é possível desligar os segmentos de redes que

não possuem membros do grupo multicast .

Pelo fato do MOSPF, assim como o OSPF, manter em todos os roteadores o estado

completo dos enlaces da rede, esta informação deve ser periodicamente renovada,

degradando a utilização da banda disponível e, consequentemente, sua escalabilidade.

4.7.3 PIM

Os protocolos estudados até agora tinham como base protocolos de roteamento unicast .

Assim, o DVMRP surgiu a partir do RIP e o MOSPF a partir do OSPF. O PIM ( Protocol

Independent Multicast ) [PIM96] está sendo concebido de forma a não depender dos

protocolos de roteamento unicast já existentes. Pode ser dividido em dois protocolos

diferentes, conforme a distribuição do grupo pela rede:

I. Quando a disposição do grupo multicast apresentar uma alta densidade, o PIM-DM

(PIM – Dense Mode) é utilizado.

II. Já quando o grupo encontra-se com baixa densidade pela rede, o mais indicado é o

PIM-SM (PIM – Sparsely Mode).

PIM-DM

O PIM-DM é muito semelhante ao DVMRP e utiliza o algoritmo RPM para a construção

da árvore multicast . Neste protocolo também existem as mensagens de desligamento e

reestabelecimento de enlaces, de forma a retirar sub-redes da árvore de distribuição que

não possuam membros do grupo multicast e reintegrá-las caso venham a ter,

respectivamente.




58

PIM-SM

O PIM-SM, definido em [RFC2117], possui duas diferenças principais em relação aos

protocolos descritos anteriormente. Utilizando este protocolo, os roteadores devem

informar explicitamente sua intenção de receber mensagens multicast , enquanto os

protocolos de modo denso assumem que todos os roteadores devem receber as mensagens

a não ser que enviem uma mensagem de desligamento. A outra diferença se refere à

introdução do conceito de “ponto de encontro” (RP - Rendezvous Point ).

Cada domínio possui um conjunto de roteadores atuando como RP’s, onde cada grupo

multicast possui um único RP. O roteador que tiver a intenção de receber mensagens

multicast destinadas a um determinado grupo, deve enviar uma mensagem de inclusão ao

RP deste grupo. As estações devem possuir configurado o “roteador designado” (DR –

Designated Router ) que é um roteador pertencente à mesma sub-rede IP com o “maior”

endereço IP. Quando um DR recebe uma mensagem IGMP indicando a inclusão de uma

estação a um determinado grupo, localiza o RP deste grupo através de uma função de

espalhamento determinística sobre o conjunto de RP’s do domínio. Localizado o RP

responsável pelo grupo em questão, o DR envia a ele uma mensagem PIM-Join, de forma

que este passe a replicar as mensagens de multicast destinada ao grupo através dos

roteadores intermediários até encontrar o DR. Consequentemente, o DR replicará estas

mensagens para a sub-rede que contém a estação que acabou de se filiar ao grupo.

A figura 25 ilustra este procedimento.




59

Figura 25 – Inserção de uma estação no grupo multicast , através do PIM-SM

Quando uma fonte inicia uma transmissão multicast para um determinado grupo, o DR da

fonte encapsula a primeira mensagem em um pacote de registro PIM-SM (PIM-SM

Register ) e o envia ao RP do grupo através de uma mensagem unicast . Ao receber esta

mensagem especial, o RP devolve uma mensagem de PIM-Join ao DR da fonte. Desta

forma, todos os roteadores intermediários adicionam em suas tabelas de replicação

multicast uma nova entrada contendo o par (fonte, grupo). Assim, os próximos pacotes

multicast podem ser facilmente replicados para o RP correspondente. É interessante notar

que à medida que os roteadores intermediários são informados sobre o RP, transmitem as

mensagens multicast encapsuladas em mensagens unicast até o RP. A figura 26 ilustra este

procedimento.

Figura 26 – Envio de mensagens multicast através dos pontos de encontro

DR R

R R

RP

R

PIM Join

Fonte

Receptor

RP Roteador RP (Rendezvous Point)

DR Roteador DR (Designated Router)

R Roteador

PIM Join

DR R

R R

RP

R

Fonte

Receptor

RP Roteador RP ( Rendezvous Point )

DR Roteador DR ( Designated Router )

R Roteador

DR

Receptor

PIM-SM Register

PIM-SM Join

Mensagens para osmembros do grupo




60

Apesar da árvore RP ser suficiente para a entrega de pacotes multicast , o aumento do

número de participantes pode sobrecarrega-la com um tráfego excessivo. Tendo em vista

este problema, o PIM-SM fornece um procedimento alternativo utilizando árvores de

menor caminho para alguns ou todos os receptores. Logo, os roteadores que implementam

o PIM-SM utilizam a árvore RP, mas também têm a opção de transmitir através de árvores

de menor caminho entre uma fonte e os destinatários. Nesta última situação, o roteador

envia uma mensagem de inclusão à estação fonte. Assim que a árvore de menor caminho é

construída, o roteador pode enviar uma mensagem de desligamento para o RP, retirando-se

da árvore RP. A figura 27 apresenta duas árvores convivendo simultaneamente, sendo uma

árvore de menor caminho e uma árvore RP.

Figura 27 – Árvore RP e Árvore de Menor Caminho dividindo o tráfego, segundo

implementa o protocolo PIM-SM

4.8. MBONE

Em 1992, um conjunto de roteadores capazes de replicar mensagens multicast foi

interligado de forma a testar a transmissão multicast pela primeira vez. Este ambiente de

testes foi chamado de Multicast Backbone ou simplesmente Mbone. Estabeleceu-se como

marco do início da utilização do Mbone, a primeira transmissão de voz (audiocast ) para

vinte localidades espalhadas por três continentes, realizada em março deste mesmo ano.

Nesta transmissão os participantes podiam ouvir o interlocutor e também era possível fazer

DR R

R R

RP

R

Fonte

Receptor

RP Roteador RP (Rendezvous Point)

DR Roteador DR (Designated Router)

R Roteador

Árvore RP (compartilhada)

Árvore de menor caminho(baseada na fonte)




61

perguntas a ele. O Mbone começou com cerca de 40 sub-redes localizadas em quatro

países, porém estima-se que existam hoje cerca de 3400 sub-redes em 25 países.

Pode-se dizer que o Mbone é uma rede virtual implementada sobre a Internet. Assim, ilhas

de roteadores capazes de transmitir pacotes multicast são interligados através de túneis. É

através destes túneis que as mensagens multicast são transmitidas entre os roteadores.

Como os túneis são formados por roteadores intermediários que não possuem a capacidade

de transmissão multicast , estas mensagens são encapsuladas em pacotes unicast .

No início de sua utilização, apenas o protocolo DVMRP era utilizado para a conexão de

roteadores multicast . Atualmente, porém, encontram-se disponíveis em roteadores

comerciais protocolos como MOSPF e PIM, mas o DVMRP continua sendo o mais

utilizado. Com o aumento da disponibilidade destes protocolos, a tendência é que estes

sejam empregados com mais frequência, reduzindo a necessidade da implementação dos

túneis.

Hoje em dia, o Mbone é utilizado no transporte de fluxos multicast de áudio e vídeo,

transmitindo as reuniões do IETF ( Internet Engineering Task Force), as missões da

NASA, e muitos cursos e seminários espalhados por todo o mundo.

4.9. Multicast IP sobre ATM

O funcionamento da comunicação multicast em redes TCP/IP sobre Ethernet e a estrutura

da rede ATM foram estudados anteriormente. Agora é hora de estudar ambos em conjunto.

Quando se fala em multicast IP sobre ATM, três questões devem ser levadas em

consideração:

• Resolução de endereços IP classe D em endereços ATM;




62

• Onde na rede, e por qual entidade, deve ser feita a replicação dos dados numa

transmissão multicast ;

• Administração dos grupos multicast.

As duas soluções apresentadas para a integração de redes IP em infra-estrutura ATM:

Classical IP over ATM e Lane Emulation, possuem diferentes procedimentos para a

transmissão de pacotes multicast .

O Lan Emulation, solução que simula uma rede de meio físico compartilhado, adota oBUS para a transmissão de tráfego multicast . Assim sendo, todas as estações pertencentes

a uma ELAN receberão os pacotes multicast , o que representa um problema se for

considerada a escalabilidade do sistema. Como nem sempre todas as estações pertencem à

grupos multicast , existe um desperdício de recursos na transmissão de pacotes multicast

para as estações que não pertençam ao grupo. Apesar disso, o ATM Forum adotou esta

solução como padrão, considerando que é a mais simples de ser implementada. Dado que

esta solução é padronizada pelo ATM Forum e não se tem conhecimento de novas

propostas, esta não será aprofundada neste trabalho.

Na especificação do Classical IP sobre ATM, a questão da transmissão do tráfego

multicast IP foi deixada de lado propositadamente. A razão principal deste fato, é a

dificuldade de converter um endereço de grupo IP (classe D) para uma conexão ponto-

multiponto ATM. Desta forma, este é um campo aberto para pesquisas e diversos trabalhos

surgiram para solucionar esta limitação. O MARS [RFC2022] é a especificação mais

completa atualmente e serve de base para novas propostas.

Além da resolução dos endereços IP em endereços ATM, a forma de como será

estabelecida a conexão ponto-multiponto entre a fonte geradora e os clientes participantes,

também deve ser estudada. Duas abordagens são apresentas: Malha de VC’s e Servidor de




63

Multicast (MCS – Multicast Server ). Estas abordagens serão estudadas e comparadas a

seguir.

4.9.1 MARS

Como visto anteriormente, o ATM possui um esquema de endereçamento próprio. As

especificações de sinalização padronizadas pelo ATM Forum (UNI 3.0, UNI 3.1, UNI 4.0),

não provêem nenhuma abstração para o endereçamento multicast ATM, logo se faz

necessária uma solução para o mapeamento de endereços multicast de camada 3 (camada

de rede: IP) para um conjunto de endereços ATM correspondente. Uma possível solução

para este mapeamento está na utilização de um servidor de resolução de endereços

multicast IP.

O servidor de resolução de endereços multicast (MARS – Multicast Address Resolution

Server ) [RFC2022] é uma extensão do ATMARP SERVER definido em [RFC1577],

sendo utilizado para gerenciar o mapeamento entre os endereços de camada 3 e os

endereços ATM. Estações utilizando TCP/IP sobre redes ATM, acessam o MARS para

obter os endereços ATM destino a partir de um endereço de grupo IP classe D.

A arquitetura do MARS é baseada no esquema cliente/servidor. A estrutura de um cluster

baseado no MARS é apresentada na figura 28.




64

Figura 28 – Estrutura de um cluster administrado por um MARS

Sua função é de gerenciar um agrupamento de estações pertencentes a uma rede ATM.

Este agrupamento (cluster ) pode ser definido como um conjunto de estações ATM que

estão associadas a um mesmo MARS, informando a este a intenção de receber ou enviar

pacotes multicast IP.

As informações relativas aos grupos existentes e os participantes destes são trocadas

através de mensagens MARS. Uma estação, antes de iniciar a transmissão de dados

multicast , envia uma mensagem MARS_request contendo o endereço IP do grupo desejado.

O MARS ao receber esta mensagem, responde com uma lista de endereços ATM dos

participantes do grupo. De posse dos endereços, a estação estabelece uma conexão ponto-

multiponto com os participantes e só então passa a transmitir os dados. Caso o MARS não

tiver conhecimento sobre o grupo questionado, ele devolve uma mensagem MARS_NAK .

Durante a transmissão o emissor pode adicionar ou retirar membros participantes da

conexão em função das mensagens de atualização recebidas do MARS. Se para a

transmissão multicast estiver sendo utilizado um servidor específico de transmissão

multicast (MCS – Multicast Server ), então a estação ao enviar um MARS_request , receberá

Mensagens MARS (Join, Leave, Query)

Canal de controle do cluster

MARS




65

o endereço ATM do servidor responsável pelo grupo requisitado. O MCS, ao fazer a

mesma consulta receberá a lista de endereços ATM referentes ao grupo.

Para participar de uma sessão multicast , a estação deve requisitar ao MARS a inclusão de

seu endereço ATM em um determinado grupo. Para isso foi especificada uma mensagem

MARS_join. Quando a estação desejar sair do grupo ela envia uma mensagem

MARS_leave.

O MARS mantém uma conexão ponto-multiponto de controle com todos os participantes.

Assim, as alterações referentes a um grupo, inclusão ou exclusão de um elemento, são

informadas aos participantes do grupo. Quando MCS’s são utilizados, existem, também,

conexões de controle para com estes, cuja funcionalidade é análoga.

4.9.2 Malha de VC’s (VC Mesh)

Nesta abordagem, cada estação emissora estabelece uma conexão com o MARS para

traduzir um endereço multicast IP para um grupo de endereços ATM. De posse deste

conjunto de endereços, o emissor cria uma conexão ponto-multiponto com todas as

Figura 29 – Representação da estrutura da malha de VC’s

estações pertencentes ao grupo e então transmite os dados. A figura 29 mostra um cluster

utilizando o MARS e malha de VC’s.

MARS

Troca de mensagens com o MARS

Transmissão multicast




66

São apresentadas a seguir algumas vantagens deste sistema :

• Não existe um ponto único de falhas

• Conexão ponto-multiponto direta entre o emissor e os membros do grupo ( sem

intermediários )

• Não existe a reflexão de pacotes. O emissor não recebe os pacotes que envia numa

conexão ponto-multiponto

• Não existe problema em se ter vários emissores ao mesmo tempo (mistura de

células ), uma vez que as conexões são independentes.

Destacam-se as seguintes desvantagens:

• Uso de um número excessivo de conexões (VC’s).

• Dificuldade para inserir e remover participantes dos grupos. Uma alteração no

grupo deve ser atualizada na conexão de cada emissor.

• Grande overhead de sinalização para criar e remover as conexões de cada emissor.

4.9.3 MCS ( Multicast Server)

O servidor multicast MCS ( Multicast Server ) está definido em [RFC2149]. Ele foi

projetado para concentrar todas as transmissões relativas a um ou mais grupos multicast ,

minimizando assim o uso de VC’s. Deste modo, a estação emissora estabelece uma

conexão com o MARS, enviando o endereço IP de multicast e recebe como resposta o

endereço ATM do MCS responsável pelo grupo desejado. O emissor estabelece, então,

uma conexão ponto-a-ponto com o MCS e passa a transmitir. O MCS possui uma conexão

ponto-multiponto com todos os participantes do grupo e retransmite as mensagens para os

mesmos. A figura 30 mostra a arquitetura do MCS.




67

Figura 30 – Arquitetura do servidor de transmissão multicast

Destacam-se as seguintes vantagens deste método:

• Cada estação necessita de uma ou duas conexões somente (Duas quando o

participante é emissor e receptor );

• Facilidade para adicionar ou remover participantes. Somente o MCS precisa ser

informado sobre as alterações;

• Baixo consumo de recursos nos comutadores.

Algumas desvantagens:

• MCS torna-se um possível gargalo na rede;

• MCS, quando não é tolerante a falhas, pode comprometer toda a transmissão

multicast;

• Maior distância entre o emissor e os receptores(Existência de retransmissores

intermediários);

• Os pacotes AAL5 devem ser remontados a fim de se evitar a mistura de células de

dois emissores diferentes, aumentando assim o atraso da transmissão;

MARSMCS

Comunica ão com o MARS

Dados multicast




68

• MCS enviará os pacotes para todos os participantes do grupo, que pode incluir o

próprio emissor, fazendo necessário, então, filtros no emissor para absorver o

conteúdo da sua própria transmissão.

4.9.4 Comparativo entre o MCS e malha de VC’s

Duas possíveis soluções para transmissão multicast em ATM foram apresentadas e as

respectivas vantagens e desvantagens destacadas. É importante agora, que se faça um

estudo comparativo entre as duas, com o objetivo de se esclarecer a importância

quantitativa de alguns parâmetros quanto ao suporte de um único grupo.

A figura 31 [Talpade96] apresenta a comparação das duas abordagens em função do

número de VCC’s utilizados pelos membros do grupo, número de VCC’s ponto-

multiponto, número de VCC’s por membro do grupo e a carga de sinalização gerada por

cada alteração no grupo.

m = número de membros de um grupo G

n = número de emissores para um grupo G

MCS VC-mesh

Número total de VCC’s para membros do grupo n+m n*m

VCC’s ponto-multiponto n+1 N

Número de VCC’s para cada membro 1 N

Sinalização gerada para cada alteração no grupo 1 N

Figura 31 – Comparativo entre a malha de VC’s e o MCS

4.9.5 Comentários

Analisando as vantagens e desvantagens de cada abordagem, juntamente com a tabela

comparativa, algumas conclusões podem ser formuladas:




69

• O uso de VC’s é melhor aproveitado no caso do MCS. O maior uso de VC’s no

caso da malha de VC’s implica num grande consumo de recursos do

comutador, como por exemplo: memória para manter o estado das conexões,alocação de buffer por conexão, e os próprios VC’s que são de número

limitado.

• A freqüência das alterações provocadas pela admissão ou exclusão de membros

de um grupo devem ser consideradas na escolha de uma abordagem. Isto

porque gera-se uma carga considerável de sinalização em cada uma dessas

operações. No caso do MCS este problema é minimizado, dado que apenas o

MCS deve adicionar ou remover membros de suas conexões ponto-multiponto.

Logo o tráfego de sinalização somente existirá entre o MCS e o comutador, não

interferindo nas outras conexões existentes. No caso da malha de VC’s, a

sinalização ocorreria entre cada emissor e o comutador, uma vez que cada

emissor teria de inserir/remover membros de suas conexões. Este fato

evidencia-se em grupos com diversos transmissores, ou muito dinâmicos em

relação aos participantes.

• O MCS provê um controle centralizado do uso da banda pelo tráfego multicast

em redes ATM. Este fato pode ser útil quando se deseja especificar um limite

de uso da banda disponível para a transmissão de tráfego multicast . Em suma,

as atividades de gerenciamento, tarifação e outras tornam-se bastante

simplificadas.

• O uso do MCS aumenta a latência fim-a-fim do sistema e a vazão dos dados,

uma vez que eles devem ser recebidos pelo servidor de multicast , analisados e

redistribuídos para os membros do grupo. Sendo o concentrador único dos

dados multicast , torna-se, além de gargalo do sistema, comprometedor de todo

o serviço de transmissão multicast , dado que também é sujeito a falhas.

• Quando o MCS é utilizado e o emissor também faz parte do grupo ao qual está

transmitindo, é necessário que se estabeleça um filtro de forma a impedir que

ele (o emissor) receba, através do servidor multicast , o conteúdo de sua própria

transmissão.




70

• A questão da diferenciação dos parâmetros de qualidade de serviço (QdS) é

melhor tratada na malha de VC’s. Cada emissor estabelece sua própria conexão

ponto-multiponto com os membros do grupo, conferindo a esta os parâmetrosque julgar necessário. Já na abordagem do MCS o emissor tem a flexibilidade

de estabelecer a conexão com o servidor de multicast , porém a conexão com os

membros do grupo é administrada pelo MCS, sendo, portanto, comum a todos.

4.10. Conclusões

Como foi visto neste capítulo, existem diversas implementações de multicast IP sobre

redes convencionais, tanto em termos de algoritmos quanto de protocolos já disponíveis

em equipamentos comerciais. Estes, porém, não atendem por completo as exigências das

aplicações multimídia modernas, uma vez que não levam em consideração aspectos de

QdS das mesmas.

Em relação à adaptação do multicast IP sobre redes de alta velocidade, foi visto que não

existem padrões definidos, consequentemente as soluções se resumem a possíveis

propostas ainda em desenvolvimento. Dentre as propostas estudadas, concluiu-se que não

existe uma melhor. Dependo da aplicação tanto o MCS quanto VC Mesh podem e devem

ser considerados.

No próximo capítulo, serão estudados os algoritmos de roteamento multicast que

consideram aspectos de QdS na formação das rotas que comporão a árvore de distribuição.



Capítulo 5 - Algoritmos de Roteamento Multicast com QdS 71

71

CCaappí í ttuulloo 55 -- AAllggoorriittmmooss ddee RRootteeaammeennttoo M M uul l t tii c c a a s s t t

ccoomm QQddSS

5.1. Introdução

O problema do roteamento surgiu a partir do momento que várias redes, antes isoladas,

precisaram ser interligadas. Assim, criou-se uma entidade de rede responsável pelo

roteamento das mensagens cujos destinatários não pertenciam à rede local e retransmissão

das mensagens “externas” cujos destinatários pertenciam à rede local. A esta entidade

chamou-se de roteador. As técnicas de roteamento são, portanto, um assunto estudado e

pesquisado há muitos anos. As transmissões multicast , entretanto, não eram implementadas

em redes de longa distância até poucos anos atrás. Como já foi dito, a primeira experiência

de transmissão multicast em redes de longa distância ocorreu em 1992, quando foi

realizado pelo IETF ( Internet Engineering Task Force) um audiocast para vinte

participantes simultâneos em três continentes [Deering92]. A partir de então muitas

pesquisas estão sendo desenvolvidas no sentido de desenvolver e aperfeiçoar algoritmos e

protocolos de roteamento multicast que satisfaçam as seguintes características:

• Considerem os parâmetros de Qualidade de Serviço exigidos pelas aplicações

multimídia de tempo real;

• Gerenciamento eficiente dos recursos da rede;

• Escalabilidade (devido ao grande crescimento das redes).

Este capítulo apresentará os conceitos necessários para a avaliação de algoritmos multicast

assim como uma proposta de classificação destes. Algumas das principais abordagens




72

contidas na literatura serão descritas e analisadas com base nos parâmetros relevantes para

uma implementação em situação real.

5.2. Classificação dos Algoritmos de Roteamento Multicast

Para um melhor entendimento dos algoritmos de roteamento multicast , será proposta uma

classificação dos mesmos. Duas categorias de algoritmos podem ser destacadas, quando se

analisa o tipo de árvore multicast :

• Algoritmos de menor caminho: Estes algoritmos constroem uma árvore multicast que

minimiza o tamanho do caminho a partir da fonte até cada membro do grupo multicast .

Vide figura 32.

Figura 32 – Árvore de menor caminho

• Algoritmos de árvore Steiner mínima. O objetivo destes algoritmos é o de minimizar

o custo total da árvore multicast . Este problema é conhecido como sendo NP-completo.

Vide figura 33.

D3 D4

D2

D1

S

Custo total: ………………………….…..7Tamanho do caminho máximo: ………...3Tamanho médio dos caminhos: ……..2.25




73

Figura 33 – Árvore Steiner Mínima

Em relação às restrições que os algoritmos podem ou não considerar durante a criação da

árvore multicast , também duas categorias se destacam:

• Algoritmos de atraso restrito. São os algoritmos que levam em consideração as

requisições de atraso máximo garantido pelas aplicações durante a elaboração da

árvore multicast ;

• Algoritmos irrestritos. São os algoritmos que não consideram nenhum parâmetro de

qualidade de serviço (QdS) requisitado pela aplicação.

Outra característica importante a ser considerada pelos algoritmos consiste no dinamismo

do grupo multicast . Assim:

• Algoritmos dinâmicos são aqueles que permitem a inclusão ou exclusão departicipantes, criando, portanto, novos caminhos dos emissores a todos os participantes

do grupo multicast ;

• Algoritmos estáticos são os que determinam todos os caminhos necessários no início

da sessão multicast e estes permanecem fixos durante a existência da sessão multicast .

Quanto à computação dos algoritmos duas possibilidades aparecem:

D3 D4

D2

D1

S

Custo total: ………………………….…..5Tamanho do caminho máximo: ………...4Tamanho médio dos caminhos: ……..2.75




74

• Algoritmos distribuídos calculam a árvore multicast de forma distribuída. Com isso

diminui-se o custo de computação em cada nó da rede, porém aumenta-se o número de

mensagens trocadas entre os mesmos;

• Algoritmos centralizados concentram toda computação necessária para a formação da

árvore multicast num único nó. Para isto, as informações sobre a topologia completa da

rede devem estar disponível para qualquer nó.

5.3. Parâmetros Relevantes e Metodologia para Comparação de

Algoritmos Multicast

É necessário que se defina um critério para realizar a comparação dos algoritmos de

roteamento multicast . Para a definição deste critério, é preciso levantar os parâmetros

relevantes e adotar uma métrica aplicável a todos os algoritmos. Neste sentido, destacam-

se os principais pontos que devem ser considerados na análise de um algoritmo:

• Gerenciamento eficiente dos recursos da rede (custo da árvore gerada);

• Parâmetros de QdS considerados (restrições de atraso máximo);

• Complexidade do algoritmo;

• Quantidade de informações armazenadas necessárias;

• Aplicabilidade para redes simétricas e assimétricas.

Como nem sempre é possível a utilização de redes reais para o desenvolvimento e

aperfeiçoamento destes algoritmos, as simulações têm se mostrado o método preferido

pelos pesquisadores para a análise dos mesmos.

Para que as simulações representem as condições reais das redes de computadores, énecessário que se execute o algoritmo em diferentes topologias e tamanhos de redes,




75

utilizando cenários reais ou gerados aleatoriamente. Condições de congestionamento,

atrasos, diferentes tipos de tráfego, etc. devem se aproximar o quanto possível do que se

observa na realidade. Alguns autores, mais detalhistas, chegam a considerar o custo

monetário da utilização dos caminhos.

Não se tendo o cuidado apresentado acima, os resultados obtidos através de simulações,

podem expressar uma aparente eficiência ou ineficiência para casos especiais e, portanto,

não podendo ser generalizados.

5.4. Algoritmos de Roteamento Multicast

Dentro dos diversos algoritmos existentes, este trabalho se restringirá à análise dos

algoritmos de atraso restrito, mais adequados para as aplicações multimídia de tempo real.

Os algoritmos de atraso restrito têm como objetivo criar uma árvore multicast ligando

todos os participantes do grupo, sendo que esta árvore tenha o custo mínimo e ao mesmo

tempo respeite o limite de atraso máximo definido. Numa linguagem mais formal:

É de conhecimento geral que estes algoritmos são NP-completos, logo algumas heurísticas

foram desenvolvidas. A seguir as principais heurísticas serão apresentadas.

5.4.1 Heurística KPP

Kompella, Pasquale e Polyzos propuseram em [Kompella93] uma heurística baseada no

modelo de Árvore de Steiner Restrita, que será denominada neste trabalho de KPP.

=∆≤

mínimoGsT Custo

GsT Max Atraso

)),((

)),((_




76

O primeiro passo que o algoritmo executa é encontrar o fechamento do grafo formado

pelos caminhos de menor custo e que respeitam o limite de atraso, entre todos os pares de

elementos do grupo multicast . Este procedimento exige que se percorra todos os valores de

atraso a partir de 1 até o limite máximo ∆ (assumindo que ∆ possui um valor inteiro) e,

para cada um destes valores, deve-se encontrar o menor caminho entre todos os pares.

Encontra-se, então uma árvore restrita a partir do fechamento do grafo, utilizando um

algoritmo do tipo greedy baseado na função custo. Existem, também, mecanismos de

seleção alternativos, baseados tanto na função custo quanto na função atraso, ou em ambas.

As ligações da árvore de espalhamento (spanning tree) são, então, os menores caminhos da

árvore de espalhamento restrita.

A computação dos menores caminhos restritos durante a primeira fase do algoritmo é a que

consome mais tempo, tendo uma complexidade de O(∆n3), onde n é o número de vértices

do grafo. O segundo passo do algoritmo tem complexidade de O(∆m3), onde m é o número

de nós do grupo multicast . O último passo tem uma complexidade de no máximo O(n 2).

Portanto a complexidade total do algoritmo é dada por O(∆n3).

Melhor do que explicar um algoritmo é visualizar seu funcionamento através de um

exemplo. Para isso observe a figura 34:




77

Figura 34 – Evolução da solução KPP

A comunicação multicast tem como origem o emissor F e os membros do grupo multicast

estão identificados na figura com os rótulos B e D. O atraso máximo permitido é 12. O

primeiro passo do KPP é construir um fechamento do grafo utilizando os caminhos de

menor custo, que respeitam o limite de atraso imposto, entre os elementos do grupomulticast . É através deste fechamento que o algoritmo selecionará a solução. No exemplo

acima a solução será as ligações FB e FD somando um custo de 22 e um atraso de 11. Esta

é uma solução válida, dado que satisfaz a restrição de atraso. O estágio final do KPP

consiste em mapear a solução do fechamento do grafo novamente no grafo original,

resultando nas ligações FA, AB, e FC, CD.

FA

C

B

D

(5,3)

(6,8)

(10,3)

(8,2) (3,2)F

A

C

B

D

(5,3)

(6,8)

(10,3)

(8,2) (3,2)

[11,11]

[11,4]

[13,5]

FA

C

B

D

(11,4)

(11,11)

A - Grafo original B – Grafo completo

C – Solução escolhida do fechamento

FA

C

B

D

D – Solução KPP

(22,11)




78

5.4.2 Heurística CSPT

Quan Sun e Horst Langendörfer publicaram em [Sun95] a heurística CSPT (Constrained

Shortest Path Trees). Esta é composta por três fases, as quais serão descritas. A primeira

fase constrói uma árvore de espalhamento de baixo custo, através do algoritmo de Dijkstra,

composta pelo maior número possível de componentes pertencentes ao grupo multicast ,

sem que exista nenhum caminho que exceda o limite máximo de atraso. Como nem sempre

todos os membros do grupo serão cobertos por esta árvore, uma segunda execução do

algoritmo de Dijkstra procurará criar uma árvore formada por caminhos de menor atraso,

abrangendo os elementos não cobertos pelo passo anterior. A última fase consistem em

juntar estas duas árvores, removendo os eventuais loops e tomando o cuidado de nenhum

caminho exceder o limite máximo de atraso.

Tanto o primeiro quanto o segundo passo dependem basicamente do algoritmo de Dijkstra

com algumas alterações. Logo a complexidade destas fases será da ordem de O(n2

). A

última fase, de concatenação das árvores, limita-se a O(n). Portanto, a heurística tem a

complexidade total da ordem de O(n2).

5.4.3 Heurística CCET

A heurística CCET (Constrained Cheapest Edge Tree) foi descrita pela primeira vez em

[Waters94]. Alguns aperfeiçoamentos foram feitos desde então. Na proposta original a

restrição de atraso estava relacionado com o atraso mínimo de broadcast, ou do grupo

multicast. Na versão abordada neste trabalho, esta restrição pode ter um valor arbitrário.

A heurística consiste em, num primeiro passo, atualizar, através do algoritmo de Dijkstra, o

valor do atraso de cada nó a partir da fonte, criando um grafo dirigido. Durante essa fase,as arestas cujo atraso inserido ultrapasse o limite definido, são removidas da árvore. Os nós




79

são, então, ordenados inversamente em relação ao seu atraso. Iniciando pelo nó de maior

atraso, o algoritmo procura o enlace de menor custo, criando um caminho de volta à fonte.

É bom ressaltar que, como as redes são assimétricas, o enlace é escolhido em relação ao

seu custo sempre na direção da fonte para o nó. Estes caminhos são inseridos numa árvore

de broadcast . Ao final deste processo, os nós que não pertencem ao grupo multicast são

retirados da árvore. Existem algumas variações deste algoritmo [Salama94][Crawford94]

que propõe ao invés de escolher o enlace de menor custo, escolher o caminho de menor

custo.

Em relação à ordem de complexidade deste algoritmo, verifica-se que no primeiro estágio,

algoritmo de Dijkstra, mantém-se em O(n2). Para a criação da árvore de broadcast , é

necessário, para cada nó, executar uma busca em profundidade na árvore até a fonte, o que

consome O(max(N, |E|)), onde N representa o número de nós e E o conjunto de arestas da

árvore de busca, sendo esta formada por todas as possíveis rotas de volta à

fonte[Gibbons89]. Portanto a ordem de complexidade total do algoritmo será de O(n2).

A sequência mostrada na figura 35 apresentam os estágios de funcionamento do algoritmo.

D

C

BA

E H

G

F

(3,2)

(7,1)

(10,1

(2,1

(5,1)

(8,1)

(6,1

(1,2

(2,1)

(1,3

(10,2)

(9,1

D

C

BA

E H

G

F

3

4

3

3

2

4

1

2

3

52

4

43

3

1- Grafo Original (custo, atraso) 2- Grafo Dirigido




80

Figura 35 – Estágios do algoritmo CCET

5.4.4 Heurística Híbrida

A heurística híbrida foi proposta por John Crawford e Gill Waters em [Waters97]. Esta

heurística é formada basicamente pela integração do algoritmo de Dijkstra, a heurística

CCET e a heurística CSPT. O cálculo da árvore multicast é realizado através da aplicação

do algoritmo de Dijkstra criando simultaneamente as árvores de menor atraso e menor

custo. Obtidas as árvores, aplicam-se os métodos de seleção utilizados nos algoritmos

CCET e CSPT para gerar as respectivas árvores multicast . Neste ponto existem três

possíveis árvores para serem consideradas. Logo a análise procede da seguinte forma:

• Se alguma árvore conter um caminho que ultrapasse o limite de atraso máximo, é

automaticamente descartada do processo de análise;

• Calcula-se o custo total das árvores e aquela que possuir o menor custo será

selecionada.

A ordem de complexidade deste algoritmo é dominado pelo CCET, o que resulta em O(n2).

D

C

BA

E H

G

F

D

C

BA

E H

G

F

4- Árvore de Multicast3- Árvore de Broadcast




81

5.5. Conclusões

Este capítulo procurou estabelecer uma classificação entre diversos algoritmos deroteamento multicast para, então, introduzir formalmente o conceito de roteamento

multicast com restrições de QdS. Também foram identificados os principais parâmetros

relevantes para a comparação entre os algoritmos desta classe.

Preparando o leitor para o capítulo das simulações, os principais algoritmos encontrados na

literatura foram apresentados e explicados, inclusive a nova heurística proposta por Waters

[Waters97]. Esta apresentação prévia dos algoritmos teve por objetivo possibilitar ao leitor

um melhor entendimento das técnicas de obtenção de árvores multicast de baixo custo e

com restrição de atraso, para que, assim que entre em contato com os resultados e análises

obtidos através das simulações, estes possam ser melhor assimilados e compreendidos.



Capítulo 6 - Simulações e Análises 82

82

CCaappí í ttuulloo 66 -- SSiimmuullaaççõõeess ee AAnnáálliisseess

6.1. Introdução

O estudo comparativo entre algoritmos de qualquer natureza requer que se faça uma

avaliação de diversos parâmetros relevantes ao objeto da pesquisa. Alguns destes

parâmetros como a ordem de complexidade, a quantidade de informações de estado

armazenadas, etc. devem ser avaliados através de modelos analíticos teóricos. Porém,

visando estudar o desempenho dos mesmos em casos reais, onde outros parâmetros,

também importantes, como tempo de execução, número de falhas, escalabilidade, etc.

devem ser analisados, a simulação é a técnica mais utilizada pelos pesquisadores.

Este capítulo apresentará o simulador utilizado para a avaliação dos algoritmos, assim

como os procedimentos e definições criados para reproduzir o ambiente real de

transmissão de fluxos gerados por aplicações multimídia em redes de alta velocidade. Com

os resultados produzidos pelas simulações serão formuladas as análises e conclusões,

sempre mantendo o compromisso de comparar a nova heurística implementada com

aquelas já existentes.

6.2. Simulador

O simulador utilizado neste trabalho foi originalmente desenvolvido por Hussein Salama

como parte de sua tese de doutorado [Salama96] apresentado à Universidade Estadual da

Carolina do Norte – Estados Unidos. O código deste simulador está disponível através do

seguinte endereço eletrônico: ftp.csc.ncsu.edu/pub/rtcomm.

Seguindo o modelo de rede ATM, o simulador considera que as ligações são full-duplex, e

com capacidade de transmissão de 155Mbits (OC-3). Foi definido que os nós da rede




83

seriam gerados aleatoriamente dentro de um retângulo de 4000x2400 Km2 de área,

correspondendo à área territorial dos Estados Unidos.

Um ponto importante que deve ser tratado com muito cuidado quando se trabalha com

simulações diz respeito ao gerador aleatório utilizado. Neste trabalho foi utilizado um

gerador aleatório baseado no modelo de gerador de Waxman [Waxman88] para a geração

das redes (nós e ligações). O gerador foi otimizado de forma que a rede resultante fosse

composta por nós cujos graus sempre fossem maior ou igual a dois. Alguns parâmetros do

gerador foram ajustados para que, assim como em redes reais, a probabilidade da

existência de uma ligação de menor distância seja maior do que uma de maior distância, e

que a média dos graus dos nós seja 4, como é encontrado hoje na Internet. Vide Anexo A

para maiores informações sobre o gerador aleatório utilizado.

Cada nó da rede representa um comutador ATM não bloqueante. A velocidade de

propagação das ligações foi estimada em dois terços da velocidade da luz. Não foram

considerados atrasos relativos ao enfileiramento de células, assim pode-se dizer os atrasos

de uma dada ligação são simétricos, ou seja, A(u,v) = A(v,u).

Para a simulação do tráfego multicast , foi utilizado o VBR (Variable Bit Rate), supondo o

transporte de fluxos de vídeo. Para cada fluxo de vídeo que passa por uma dada ligação, é

reservada uma fração da banda desta ligação correspondente à necessidade do fluxo. Neste

trabalho foi assumido que os fluxos necessitam de uma banda mínima de 7 Mbps,

representando fluxos MPEG-2 de alta resolução. Desta forma a função custo de uma

ligação foi associada à utilização da ligação, ou seja, quanto maior for a utilização de uma

ligação, maior será o custo da mesma. O custo de uma ligação varia, então, conforme as

sessões que a utilizam são estabelecidas ou liberadas. Uma ligação pode aceitar novas

sessões até que a soma das reservas de banda atinja 85% da capacidade da ligação. A partir




84

deste ponto, a ligação torna-se saturada e rejeita novas sessões. Esta política de controle de

admissão, apesar de simples, permite multiplexação estatística e uma utilização eficiente

dos recursos da rede, além de ser suficiente para os estudos em questão.

As sessões de vídeo e voz interativos, têm exigências rígidas em relação ao atraso máximo

suportado. Tendo isso em vista, foi adotado uma valor para ∆ (atraso máximo entre fonte e

receptor) de 0,03 segundos que representa um limitante superior para o tempo de

propagação fim-a-fim através da rede. Este valor relativamente baixo foi utilizado de

forma que os protocolos de camadas superiores tenham tempo suficiente de processar as

informações transmitidas sem que o serviço seja prejudicado. Além disso, espera-se que

este valor sirva de diferencial para os algoritmos mais eficientes.

Reproduzindo ambientes reais, o simulador gera um tráfego de fundo nas ligações, também

de forma aleatória. Este tráfego não tem uma característica definida, apenas estabelece uma

banda mínima Bmin e uma banda máxima Bmax de utilização. Assim quando do

estabelecimento de uma nova conexão, além dos tráfegos gerados por conexões já

existentes, o tráfego de fundo também deverá ser considerado pelos mecanismos de

controle de tráfego.

6.3. Adaptações feitas no simulador

De forma a viabilizar a comparação da nova heurística apresentada no capítulo anterior

com aquelas já implementadas no simulador, foram executadas algumas alterações no

programa original.

O primeiro passo consistiu em portar o simulador, escrito originalmente para as

plataformas Sun, DEC, RS6000, para a plataforma Linux/Intel, mais acessível e de melhor

conhecimento deste autor. Em seguida foi necessário escrever a nova heurística, proposta

por Waters, no simulador mantendo a estrutura de dados já existente e utilizada pelos




85

outros algoritmos. Esta preocupação de manter a mesma estrutura de dados, já utilizada

pelos outros algoritmos, teve por objetivo criar a coerência de implementação necessária

para que os dados obtidos expressassem fielmente a situação em teste, possibilitando uma

comparação justa.

Finalizando as alterações, foram desenvolvidos alguns módulos que implementam testes

específicos que foram utilizados durante as simulações.

6.4. Configuração das Simulações

Como já foi amplamente explorado na literatura, os resultados das simulações de

algoritmos de roteamento variam bastante em função do tamanho da rede considerada.

Logo, uma tendência muito encontrada em trabalhos deste tipo é a divisão em redes

pequenas de até vinte nós e redes grandes de até duzentos nós, onde o comportamento dos

algoritmos é analisado em ambos os casos separadamente. Em cada caso, é estudada a

influência do tamanho do grupo multicast sobre o desempenho do algoritmo utilizado.

Em cada execução do simulador, os algoritmos são analisados em função da qualidade da

árvore multicast gerada, ou seja, o seu custo total, o atraso médio imposto, número médio

de comutadores presente em cada caminho, tempo de execução e número de falhas. A falha

de um algoritmo pode ser causada pela existência de um caminho que exceda a restrição do

limite máximo de atraso entre a fonte e um receptor, ou por não encontrar um enlace com

banda disponível para a transmissão do fluxo de vídeo.

Para que os resultados apresentados demonstrem a confiabilidade esperada, cada

configuração é executada trezentas vezes, ou seja, são geradas trezentas redes aleatórias

cada uma com um diferente tráfego de fundo e grupo multicast . Estudos anteriores

[Salama96], demonstram que em simulações deste tipo, entre duzentos e cinquenta e

trezentas execuções, atinge-se uma confiança de 95% com uma variação máxima de 5%




86

em relação aos resultados obtidos. O tráfego de fundo, também gerado aleatoriamente, de

cada enlace é definido através de um valor de banda entre Bmin e Bmax, e pode ser

diferente em cada direção, ressaltando a característica de assimetria das redes.

A seguir serão apresentados os resultados relativos à análise teórica da complexidade dos

algoritmos, o custo médio das árvores geradas, o atraso médio inserido pela árvore, o

número médio de comutadores presentes nos caminhos da árvore, o tempo de execução dos

algoritmos e o número de falhas detectados durante a construção das árvores multicast em

cada algoritmo.

6.5. Resultados e Análises

Os próximos parágrafos demonstrarão os resultados e análises das simulações realizadas

com os algoritmos de roteamento multicast que consideram aspectos de qualidade de

serviço na escolha das rotas. Os algoritmos escolhidos para as simulações são os mesmos

descritos no capítulo anterior, de forma que o leitor possa entender a relação entre a

complexidade do algoritmo, seu tempo de execução e a qualidade dos resultados gerados.

Ainda em relação à escolha dos algoritmos, estes foram selecionados de forma a

possibilitar uma comparação abrangente com a nova heurística apresentada por Waters e

sua aplicabilidade em redes de alta velocidade.

6.5.1 Estudo da complexidade dos algoritmos

O estudo da complexidade dos algoritmos tem como objetivo avaliar a escalabilidade e

estimar o tempo de execução dos mesmos em função do número de nós que compõe a

rede. Desta forma é possível prever se um determinado algoritmo tem condições de ser

empregado em implementações de protocolos ou equipamentos. Como o foco desta

dissertação é o roteamento multicast para aplicações multimídia, a questão do tempo de




87

execução do algoritmo é essencial para um desempenho eficiente do cálculo das rotas. A

tabela abaixo resume os resultados de cada algoritmo.

Algoritmo Ordem de complexidade

KPP O(n3)

CSPT O(n2)

CCET O(n2)

Híbrida O(n2)

Figura 36 – Tabela referente à ordem de complexidade dos algoritmos

Independente dos resultados práticos, é possível prever, em função da figura 36, que o

algoritmo KPP terá um tempo de execução mais alto que os outros algoritmos. Além disso,

este tempo de execução aumentará, em função do aumento do número de nós da rede,

segundo uma taxa maior que os outros. Sua escalabilidade fica bastante comprometida,

uma vez que em paralelo ao tempo de execução, existe o problema de armazenamento de

dados processados que também cresce à mesma taxa.

6.5.2 Custo total da árvore gerada

O custo total da árvore multicast construída pelo algoritmo demonstra sua habilidade em

alocar os recursos dos comutadores de maneira inteligente e transmitir sobre enlaces de

baixa utilização.




88

Redes pequenas (até 20 nós)

Redes grandes (até 200 nós)

Figura 37 – Custo das árvores geradas pelos algoritmos

Pelos gráficos da figura 37, observa-se que a heurística KPP gera as árvores de menor

custo total em todos os casos testados, o que já era esperado, pois é de conhecimento geral

que heurísticas que implementam a técnica de árvore de Steiner produzem melhores

resultados. Entre as heurísticas de menor caminho (Híbrida, CCET e CSPT), a híbrida foi a

que apresentou os melhores resultados quando aplicada em redes pequenas, até 5% melhor

que a CSPT e 20% melhor que a CCET. Em redes grandes, a Híbrida praticamente se

iguala à CSPT, e estas obtiveram resultados até 28% melhores que a CCET.

Um comportamento interessante que pode ser percebido pelos gráficos, é a diferença de

desempenho dos algoritmos em relação à maior assimetria dos enlaces. Neste caso, em

Custo das árvores geradas pelos AlgoritmosBmin = 5 Bmax= 125 Mbps

0.00

200.00

400.00

600.00

800.00

1000.00

1200.00

1 5 10 15 20Número de participantes no grupo Multicast

Híbrida

CCET

CSPT

KPP

Custo das árvores geradas pelos Algoritmos

Bmin = 5 Bmax = 125 Mbps

0.00

2000.00

4000.00

6000.00

8000.00

10000.00

12000.00

1 10 50 100 150 200Número de participantes do grupo Multicast

HíbridoCCETCSPTKPP

Custo das árvores geradas pelos Algoritmos


0.00

2000.00

4000.00

6000.00

8000.00

10000.00

12000.00

14000.00


Híbrido

CCET

CSPT

KPP

Custo das árvores geradas pelos AlgoritmosBmin = 45 Bmax = 85 Mbps

0.00

200.00

400.00

600.00

800.00

1000.00

1200.00

1 5 10 15 20Número de participantes no grupo Multicast

Híbrida

CCET

CSPT

KPP




89

redes pequenas, a diferença entre a Híbrida e a CSPT diminui bastante, enquanto a

diferença destas com a CCET aumenta.

6.5.3 Atraso da árvore multicast

O atraso inserido pela árvore multicast é um parâmetro importante de comparação entre os

algoritmos, pois através dele é possível avaliar a capacidade do algoritmo em utilizar

enlaces que insiram o menor atraso na transmissão dos fluxos de vídeo. Apesar de todos os

algoritmos restringirem o atraso máximo, é interessante que se tenha este parâmetro com o

menor valor possível, pois, em se tratando de tráfegos gerados por aplicações multimídia,

além da restrição temporal natural destas aplicações, deve-se ter em mente que estas

consomem muito tempo de processamento das estações receptoras para receberem os

fluxos, desencapsular os pacotes de dados e apresenta-los ao usuário.

A seguir são apresentados os resultados referentes às simulações dos algoritmos

observando o atraso médio das árvores geradas.


Atraso Médio (s)


0.0100

0.0110

0.0120

0.0130

0.0140

0.0150

0.0160

1 5 10 15 20Número de participantes do grupo Multicast

Híbrida

CCET

CSPT

KPP

Atraso Médio (s)


0.0100

0.0110

0.0120

0.0130

0.0140

0.0150

0.0160


Híbrida

CCET

CSPT

KPP




90


Figura 38 – Atraso médio das árvores geradas

Pelos gráficos da figura 38, conclui-se que a heurística KPP demonstrou ser a mais

ineficiente em relação ao atraso médio das árvores geradas tanto em redes pequenas quanto

em grandes. Das heurísticas de menor caminho pode-se dizer que em redes pequenas cujos

enlaces possuem pouca assimetria, ou seja, a utilização do enlace é quase a mesma em

ambos os sentidos, a CCET mostrou-se mais eficiente, porém com o aumento da

assimetria, a Híbrida e a CSPT foram melhores. Este comportamento praticamente se

inverteu ao utilizar-se redes de até duzentos nós.

De uma forma geral, conclui-se que o atraso médio das árvores aumenta em função do

crescimento do número de nós da rede, e que os algoritmos apresentam diferentes

comportamentos em função do estado de simetria dos enlaces. Seria necessário um estudo

mais aprofundado para explicar os motivos do comportamento dos algoritmos em relação à

maior ou menor simetria dos enlaces da rede.

6.5.4 Número de comutadores em cada caminho

O número médio de comutadores presentes nos caminhos que formam a árvore multicast é

um importante parâmetro para determinar o consumo de recursos da rede pelos algoritmos,

assumindo que um comutador também é um recurso da rede. Apesar desta dissertação não

estar avaliando o atraso imposto pela comutação em cada equipamento, este trabalho pode

Atraso médio (s)


0.01200.01300.01400.01500.01600.01700.01800.01900.02000.0210


Híbrido

CCET

CSPT

KPP

Atraso médio (s)


0.01200.01300.01400.01500.01600.01700.01800.01900.02000.0210


Híbrido

CCET

CSPT

KPP




91

servir de ponto de partida para um estudo mais detalhado em relação a todos os atrasos

envolvidos na transmissão de fluxos de voz ou vídeo.



Figura 39 – Número de médio de comutadores nos caminho da árvore multicast

Com relação ao número médio de comutadores alocados nos caminhos da árvore multicast

gerada pelos algoritmos, pode-se concluir, através da figura 39, que a CSPT foi a heurística

que apresentou o melhor desempenho, ou seja, alocou o menor número de comutadores. A

Híbrida obteve um desempenho de até 19% pior que a CSPT em redes pequenas e

praticamente igual em redes grandes com grande assimetria. A heurística CCET obteve o

pior resultado entre as de menor caminho, cerca de 42% maior em comparação com a

CSPT em redes grandes com pouca assimetria. A única heurística que implementa a

Número Médio de Hops


0.00

1.00

2.00

3.004.00

5.00

6.007.00

8.00


Híbrido

CCETCSPT

KPP



0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00


Híbrido

CCETCSPT

KPP



1.70

1.90

2.10

2.30

2.50

2.70

2.90

3.10

3.30

1 5 10 15 20

Número de Participantes do grupo Multicast

Híbrida

CCET

CSPT

KPP



1.701.90

2.10

2.30

2.50

2.70

2.90

3.10

3.30

1 5 10 15 20

Número de Participantes do grupo Multicast

Híbrida

CCET

CSPT

KPP




92

técnica de árvore de Steiner testada (KPP) obteve resultados crescentes em função do

número de participantes do grupo multicast , e em geral maiores que as de menor caminho.

6.5.5 Tempo de execução dos algoritmos

A análise do tempo de execução dos algoritmos é essencial para comparar os resultados

por eles produzidos com o “custo” (tempo de processamento) necessário para seu cálculo.

Não menos importante, este estudo serve de base para o estudo da viabilidade de

implementação do algoritmo em protocolos ou equipamentos específicos, tanto em redes

de pequeno porte quanto em redes de alcance global. É bom lembrar, entretanto, que nem a

heurística Híbrida nem as já existentes no simulador foram implementadas visando

otimizar o tempo de execução.



Figura 40 – Tempo de execução dos algoritmos

Tempo de Execução (s)


0.0000

0.0100

0.0200

0.0300

0.0400

0.0500

0.0600

0.0700


Híbrida

CCET

CSPT

KPP

Tempo de Execução (s)


0.0000

0.0100

0.0200

0.0300

0.0400

0.0500

0.0600

0.0700


Híbrida

CCET

CSPT

KPP

Tempo de Execução (s)Bmin = 45 Bmax = 85 Mbps

0.0005.000

10.00015.00020.00025.00030.00035.00040.00045.000


HíbridoCCETCSPTKPP

Tempo de Execução (s)Bmin = 5 Bmax = 125 Mbps

0.0005.000

10.00015.00020.00025.00030.00035.00040.00045.000


Híbrido

CCET

CSPT

KPP




93

O resultados descritos na figura 40, foram obtidos executando o simulador em um Pentium

II com o sistema operacional Linux. Porém, o que interessa para este estudo não são os

valores propriamente, mas a diferença entre eles.

Fica claro, em todos os casos analisados, que a heurística KPP possui um tempo de

execução muito superior em relação às heurísticas de menor caminho. Este fato, já descrito

na literatura, ratifica a tese de que algoritmos que implementam a técnica de árvore mínima

de Steiner não são aplicáveis às redes grandes, apesar de seus resultados serem melhores.

Entre os algoritmos de menor caminho, a heurística Híbrida apresentou o maior tempo de

execução, próximo da soma dos tempos de execução das duas outras heurísticas. Isto pode

ser explicado pelo seu mecanismo de funcionamento que após criar a árvore de broadcast ,

utiliza os dois mecanismos de seleção, um utilizado na CCET e o outro na CSPT, para

criar duas árvores multicast , para então comparar o custo de ambas e escolher aquela que

possuir o menor custo. De qualquer forma, o custo da Híbrida ainda é muito inferior ao da

KPP, possibilitando sua utilização tanto em redes pequenas quanto em redes globais.

6.5.6 Número de sessões estabelecidas com sucesso

Com o objetivo de avaliar a eficiência dos algoritmos em relação à alocação de recursos

dos comutadores e sua habilidade em lidar com situações de saturação de enlaces, foram

conduzidos os testes de número máximo de sessões de vídeo simultâneas.

A simulação consiste em gerar uma rede aleatória, sem qualquer tipo de tráfego de fundo.

Sobre esta rede serão criados seqüencialmente, também de forma aleatória, grupos

multicast com uma respectiva fonte emissora de fluxo (VBR) de vídeo, formando assim

uma sessão multicast . Vale lembrar, que a sessão multicast só é estabelecida se houver

recursos disponíveis em todos os comutadores intermediários pertencentes à árvoremulticast . As sessões são criadas continuamente até que os algoritmos falhem em encontrar




94

rotas que possuam banda suficiente para o tráfego de vídeo ou ainda que não respeitem o

limite de atraso máximo imposto.

Para cada tamanho de grupo multicast , são geradas trezentas redes diferentes, onde, em

cada uma destas, tenta-se estabelecer mil sessões multicast . Os resultados descritos a

seguir representam a média dos valores obtidos nas simulações.


Figura 41 – Número de sessões multicast estabelecidas com sucesso

As simulações referentes à heurística KPP não puderam ser realizadas devido ao seu

elevado tempo de execução. Entre as heurísticas de menor caminho, tanto a CSPT quanto a

Híbrida demonstraram resultados semelhantes, onde a principal causa de falha foi devido à

saturação dos enlaces. Já a heurística CCET demonstrou estabelecer um número até 39 %

menor de sessões simultâneas. Este fato se deve ao grande número de falhas devido à

violação do atraso máximo imposto (0,03 segundos), além de sua menor habilidade em

selecionar enlaces menos congestionados.

Número de sessões multicast estabelecidas

com sucesso

0

100

200

300

400

500

600

700

800

1 5 10 15 20Número de participantes do grupo multicast

Híbrido

CCET

CSPT




95

Fica claro, a partir da figura 41, que conforme o número de participantes do grupo

multicast cresce, menor é o número de sessões que os algoritmos conseguem estabelecer

antes da saturação da rede. Isto pode ser explicado relacionando o tamanho do grupo

multicast com o tamanho da árvore multicast necessária para cobrir todos os elementos do

grupo.

6.6. Conclusões

Este capítulo procurou descrever detalhadamente o simulador utilizado neste trabalho,

assim como todos os procedimentos utilizados para a condução das simulações e análises

dos resultados obtidos.

Em relação à qualidade das árvores geradas, ficou claro que a heurística KPP apresentou os

melhores resultados de custo total da árvore multicast . Também ficou claro que o preço

que se paga por este excelente desempenho é um tempo de execução muito alto, que

praticamente inviabiliza sua utilização em redes com um grande número de nós. Seu

elevado tempo de execução é justificado pela também elevada complexidade do algoritmo,

O(n3), característica dos algoritmos que implementam árvores mínimas de Steiner. A

heurística Híbrida não apresentou resultados tão bons quanto a KPP, porém a relação

custo/tempo de execução faz com que ela tenha mais condições de gerar protocolos ou

equipamentos de roteamento multicast com QdS.

O atraso médio inserido pela árvore de multicast foi o único parâmetro onde a heurística

CCET obteve alguma vantagem em relação às concorrentes. Isto se deve ao fato de ela

criar sua árvore de broadcast , durante o primeiro passo do algoritmo, em função dos

enlaces de menor atraso, e não de menor custo. As heurísticas Híbrida e CSPT obtiveram

resultados muito próximos, enquanto a KPP introduziu os maiores atrasos.




96

A heurística CSPT obteve o menor número de comutadores intermediários nos caminhos

formadores da árvore multicast , seguido de perto pela Híbrida, ressaltando a habilidade

destas em relação ao menor consumo de recursos da rede. Este mesmo resultado se repetiu

em relação ao número máximo de sessões multicast simultâneas. Nesta simulação, vale

lembrar que a heurística KPP não pôde ser avaliada devido ao seu elevado tempo de

execução.



Capítulo 7 - Conclusões e Trabalhos Futuros 97

97

CCaappí í ttuulloo 77 -- CCoonncclluussõõeess ee TTrraabbaallhhooss FFuuttuurrooss

Este capítulo final consolidará as conclusões formuladas no decorrer desta dissertação. O

resultado desta dissertação foi o de apresentar ao leitor o panorama atual das soluções de

transmissão multicast para a comunicação multimídia, em termos de conceitos, algoritmos

e protocolos.

Nesta dissertação, foram estudadas as soluções de transmissão multicast existentes sobre

redes convencionais utilizando a pilha de protocolos TCP/IP, onde procurou-se ressaltar

sua falta de habilidade em tratar dos requisitos básicos das aplicações multimídia de tempo

real, em especial os requisitos temporais e de disponibilidade mínima de banda garantida.

Abordou-se tanto soluções para redes locais quanto redes de longa distância.

Em relação às redes de alta velocidade, o ATM foi a tecnologia explorada em função da

sua aceitação tanto no meio acadêmico quanto no industrial. As soluções de integração de

IP/ATM, importantes por manterem a compatibilidade com as aplicações atuais e

promoverem a disseminação desta tecnologia, foram enumeradas e analisadas visando seu

funcionamento, mecanismos de transmissão e aproveitamento dos recursos de QdS. Dado

que estas soluções não possuem recursos que otimizem a comunicação multicast IP sobre

redes ATM, as principais propostas que estendem estas soluções, implementando este

importante conceito, foram comparadas segundo seu desempenho, escalabilidade e

consumo de recursos da rede.

Por fim, foi formulado formalmente o problema de roteamento multicast com restrições de

QdS. Problema que esta dissertação procurou esclarecer e apontar as heurísticas existentes

desenvolvidas para a sua solução. Além disso, apresentou, através de simulações, um




98

estudo comparativo envolvendo a qualidade dos resultados, o grau de complexidade e a

viabilidade de implementação das mesmas. A seguir serão apresentadas as principais

conclusões relativas a este estudo e os possíveis trabalhos futuros.

7.1. Conclusões

Com relação à análise teórica dos algoritmos estudados, todos os de menor caminho

apresentaram resultados semelhantes, mantendo sua ordem de complexidade em O(n2

). Aheurística KPP, que implementa a técnica de árvore mínima de Steiner, destacou-se pela

sua elevada complexidade: O(n3), já indicando a dificuldade de executá-la em redes com

um elevado número de nós. Esta análise possibilitou também, prever que a heurística KPP

teria elevados tempos de execução quando comparada com suas concorrentes.

O custo da árvore multicast gerada é um dos parâmetros mais importantes analisados, pois

reflete a habilidade do algoritmo em selecionar enlaces com menor utilização para a

formação da árvore multicast de distribuição. Neste sentido, a proposta da heurística

Híbrida alcançou seu objetivo principal, dado que, entre as heurísticas de menor caminho,

obteve os melhores resultados. Este fato foi mais visível em redes de até vinte nós onde seu

desempenho chegou a ser 20% superior à CCET e 5% superior à CSPT. É fato, entretanto,

que em todos os casos simulados, a heurística KPP obteve resultados superiores.

As análises referentes ao número médio de comutadores intermediários e número máximo

de sessões multicast simultâneas, demonstraram um comportamento muito próximo entre

as heurísticas Híbrida e CSPT, onde estas demonstram significativa vantagem sobre as

outras duas. No item atraso médio inserido pela árvore multicast houve uma inversão, onde

a heurística CCET aparece como a melhor qualificada.




99

A análise do tempo de execução de cada algoritmo é de fundamental importância para o

estudo da viabilidade de implementação destes algoritmos em protocolos ou equipamentos.

Através desta, comprovou-se o que já era esperado: a heurística KPP obteve resultados que

inviabilizam sua utilização em redes com elevado número de nós, conforme fora previsto

na análise teórica da mesma.

Portanto, em função dos resultados observados, conclui-se que a heurística Híbrida,

demonstrou resultados iguais ou superiores às concorrentes na maioria dos parâmetros

avaliados, mantendo, porém, um tempo de execução que não inviabiliza sua utilização.

7.2. Trabalhos Futuros

Até a presente data, o ATM Forum não dispõe de nenhuma padronização referente ao

roteamento multicast com restrição de QdS. Este fato significa que existe nesta área, muito

espaço para pesquisas. Logo o estudo de novos algoritmos ou, como foi abordado nesta

dissertação, a integração de abordagens já estudadas, servirão para que, num futuro

próximo, seja possível especificar protocolos ou até mesmo equipamentos com

funcionalidades de roteamento multicast com QdS.

Os algoritmos analisados neste trabalho consideraram que os grupos multicast eram fixos,

ou seja, não houve a preocupação quanto às alterações de rotas necessárias quando da

inclusão ou exclusão de novos elementos do grupo multicast . Uma possível continuação

deste trabalho seria a análise dos algoritmos em relação a este problema.

Também foi assumido durante as simulações que as transmissões de vídeo utilizavam a

categoria de serviço VBR. Uma análise comparativa com o CBR ou o ABR em relação à




100

alocação de banda nos enlaces poderia originar resultados sobre o comportamento dos

algoritmos quanto a diferentes políticas de reserva de recursos.

Por fim, foi visto que os algoritmos que implementam a técnica de árvore mínima de

Steiner possuem como grande desvantagem, o seu tempo de execução. Logo, poderia se

pensar em modificar estes algoritmos de forma que seu processamento pudesse ser feito de

forma distribuída ou paralela.



Anexo A – O Gerador Aleatório de Enlaces 101

101

AAnneexxoo AA –– OO GGeerraaddoorr AAlleeaattóórriioo ddee EEnnllaacceess

Dado que o gerador aleatório é o ponto mais importante de um estudo baseado em

simulações, este anexo será dedicado inteiramente à sua explicação e aos parâmetros

utilizados para a representação das redes de computadores utilizadas nesta dissertação.

O gerador utilizado no simulador segue o modelo criado por Waxman [Waxman88], cuja

função probabilística para criar os enlaces é dada por:

Onde L representa a distância máxima entre quaisquer dois nós da rede e l(u,v) define a

distância entre u e v. O parâmetro α controla a taxa de existência de enlaces curtos e

compridos, enquanto o parâmetro β controla o grau médio dos nós da rede. Conforme

aumenta-se o valor de α, aumenta-se a probabilidade de existência de enlaces compridos.

O maior valor de β implica em nós de grau maior.

Seguindo o modelo original de Waxman, a sua função probabilística é aplicada para cada

par de nós. A rede resultante pode, porém, não ser conexa, o que não é desejável. Além

disso, fixando valores para α e β não garante que as redes resultantes, ao aplicar-se o

algoritmo várias vezes, conservará o mesmo grau médio dos nós. Logo para que se obtenha

uma rede com um certo grau médio de seus nós, pode ser necessária a execução do

algoritmo por algumas vezes, até que a rede seja criada. A execução do gerador aleatório

repetidamente para que se obtenha uma única rede formada por nós com um certo grau,

não parece ser uma solução eficiente, dado que centenas de redes derão ser geradas em

cada simulação.

αβ

L

vulvuPe

),(exp),(

−=



Anexo A – O Gerador Aleatório de Enlaces 102

102

Tendo isto em vista, Salama [Salama96] desenvolveu um gerador aleatório baseado no

modelo de Waxman, porém que gera uma rede conectada em uma única execução e com a

média dos graus dos nós desejada garantida. O algoritmo proposto utiliza a mesma função

probabilística de Waxman. A seguir será explicado seu funcionamento.

O algoritmo começa selecionando um nó qualquer e interligando este a dois outros nós

quaisquer através de dois enlaces. O resultado deste operação é uma sub-rede formada por

três nós conectados por dois enlaces. O algoritmo repete, então, o seguinte passo para cada

nó da rede: se o grau do nó é menor ou igual a dois, o algoritmo cria enlaces aleatórios

onde uma das pontas é o próprio nó. Isto acontece até que o nó obtenha grau igual a dois.

Se este mesmo nó não estiver conectado à sub-rede existente, o algoritmo providencia que

pelo menos um dos enlaces gerados o conecte com a mesma. A rede resultante ao final

deste loop é conexa e com os graus de seus nós maior ou igual a dois. A partir deste ponto,

o gerador continua a criar novos enlaces até que a média dos graus dos nós desejada seja

atingida.

Esta técnica foi utilizada para gerar redes cujos nós possuiam em média grau igual a

quatro, conforme encontra-se hoje na Internet. Os valores de α foram ajustados de forma a

representar, com a maior proximidade possível, as redes reais de computadores. Já os

valores de β permaneceram fixos, uma vez que ficou a cargo do algoritmo gerenciar a

média dos graus dos nós.



Anexo B – Interface do Simulador MCRSIM 103

103

AAnneexxoo BB –– IInntteerrf f aaccee ddoo SSiimmuullaaddoorr MMCCRRSSIIMM

A título de ilustração, apresentamos abaixo a interface do simulador MCRSIM, após sua

implementação no Linux.

Figura 42 – Interface gráfica do simulador MCRSIM

No exemplo acima, temos uma fonte de vídeo transmitindo, utilizando a categoria de

serviço VBR, a partir do nó de número 69, identificada por um quadrado ao seu redor. Os

membros do grupo multicast são identificados pelas circunferências de maior raio. A

árvore multicast gerada a partir da fonte, pode ser visualizada através de seus enlaces de

maior espessura enquanto seu custo é apresentado na parte superior da janela.



Referências Bibliográficas 104

104

RReef f eerrêênncciiaass BBiibblliiooggrrááf f iiccaass

[Alles95] A. Alles, “ATM Internetworking”, Cisco Systems Inc, WhitePaper,Maio de 1995

[Black95] U. Black. “ATM Foundation for Broadband Networks”, Prentice Hall,New Jersey, 1995

[Cereda97] R. L. D. Cereda, M. A. C. Cruz, L. S. V. Dutra e R. R. Sewaybriquer,“ATM O Futuro das Redes”, BRISA – Sociedade Brasileira paraInterconexão de Sistemas Abertos, MAKRON, 1997

[Commer97] D. E. Commer, “Computer Networks and Internets”, Prentice Hall,New Jersey, 1997

[Crawford94] J. S. Crawford, “Multicast Routing: Evaluation of a New Heuristic”,dissertação de mestrado, Universidade de Kent, Inglaterra, 1994

[Deering92] S. Casner e S. Deering, “First IETF Internet AudioCast”, inProceedings of ACM SIGCOMM, Computer CommunicationsReview, vol. 22, no.3, Julho de 1992

[Gibbons89] Alan Gibbons, “Algorithmic Graph Theory”, Cambridge UniversityPress, 1989

[IGMP96] W. Fenner, “Internet Group Management Protocol, Version 2.”,Internet Draft, Maio de 1996

[Kadaba83] K. Barath-Kumar e J. Jaffe, “Routing to Multiple Destinations inComputer Networks”, IEEE Transactions on Communications, vol.COM-31, no.3, pp. 353-360, 1996

[Kiatake98] L.G.G. Kiatake, “Transmissão de fluxos MPEG-2 em soluções IP sobreATM”, dissertação de mestrado apresentada à Escola Politécnica daUniversidade de São Paulo, Junho de 1998

[Kompella93] V. Kompella, J. Pasquale e G. Polyzos, “ Multicast Routing forMultimedia Communications”, IEEE/ACM Transactions onNetworking, 1(3):286-292, 1993

[LANE1] “LAN Emulation over ATM,” The ATM Forum, version 1.0, Janeirode 1994

[LANE2] “LAN Emulation over ATM – LUNI Specification,” The ATM Forum,version 2.0, Julho de 1997




105

[Meylan98] F. Meylan, L. G. G. Kiatake, M. Z. Santos. “An experimental study fortransmmiting MPEG-2 streams over ATM networks”, 1st IEEEInternational Congress on ATM – ICATM’98, Colmar, France,

Junho de 1998

[NSAP94] Colella, Callon, Gardner e Rekhter, “Guidelines for OSI NSAPallocation in the Internet”, RFC 1629, IETF, Maio de 1994

[PIM96] S. Deering, D. Estrin, et al, “The PIM Architecture for Wide-AreaMulticast Routing”, IEEE/ACM Transactions on Networking, vol.4, no 2, pp 153-162, Abril de 1996

[RFC1075] D. Waitzman, C. Partridge e S. Deering, “Distance Vector MulticastRouting Protocol”, Internet RFC 1075, Novembro de 1988

[RFC1583] J. Moy, “OSPF Version 2”, Internet RFC 1583, Março 1994

[RFC1584] J. Moy, “Multicast Extension to OSPF”, Internet RFC 1584, Maio 1994

[RFC1577] M. Laubach, “Classical IP and ARP over ATM”, RFC 1577, HewlettPackard Laboratories, Janeiro de 1994

[RFC2022] G. Armitage, “Support for Multicast over UNI 3.0/3.1 based ATMNetworks”, RFC 2022, Bellcore, Novembro de 1996

[RFC2117] D. Estrin, D, Farinacci et al., “Protocol Independent Multicast-SparseMode (PIM-SM): Protocol Specification”, Internet RFC, Junho de1997

[RFC2149] R. Talpade e M. Ammar, “ Multicast Server Architectures for MARSbased ATM multicast ing”, RFC 2149, Georgia Institute of Technology, Maio de 1997

[Salama94] H. F. Salama, D. Reeves, Y. Viniotis e T. L. Sheu, “Comparison of Multicast Routing Algoritms for High Speed Networks”, Tech.

Rep. TR 29.1930, IBM, Setembro de 1994[Salama96] H. F. Salama, “ Multicast Routing for Real-Time Communication on

High-Speed Networks", Ph.D. dissertation , Department of Electrical and Computer Engineering, N. C. State University,Novembro de 1996

[Santos98] M. Z. Santos, “Simulação e Análise de Soluções de Comunicação entreSub-redes IP sobre ATM”, dissertação de mestrado apresentada àEscola Politécnica da Universidade de São Paulo, Julho de 1998

[Stevens97] W. R. Stevens, “TCP/IP Illustrated”, Vol.1, Addison-Wesley,Massachusetts, 1997




106

[Sun95] Q. Sun e H. Langendoerfer, “Eficient Multicast Routing for DelaySensitive Applications”, in Proceedings of the Second Workshopon Protocols for Multimedia Systems (PROMS ’95), pp. 452-458,

Outubro de 1995

[Talpade96] R. Talpade, M. Ammar e G. Armitage, “Experience with Architecturesfor Suporting IP Multicast over ATM”, Bellcore, Agosto de 1996

[Tanaka93] Y. Tanaka e P.Huang, “Multiple Destination Routing Algorithms”,IEICE Transactions on Communications, vol E76-B, no.5, pp. 544-552, Maio de 1993

[Tobagi94] C. Noronha e F. Tobagi, “Evaluation of Multicast Routing Algorithmsfor Multimedia Streams”, in Proceedings of the IEEE International

Telecommunications Symposium, Agosto de 1994

[Waters94] G. Waters, “A New Heuristic for ATM Multicast Routing”, in 2nd IFIPon performance Modelling and Evaluation of ATM Networks,pages 8/1-8/9, Julho 1994

[Waters97] G. Waters e J. Crawford, “A Hybrid Approach to Quality of Service Multicast Routing”, Fifth IFIP Workshop on PerformanceModelling and Evaluation of ATM Networks, 1997

[Waxman88] B. Waxman, “Routing of Multipoint Connections”, IEEE Journal onSelected Areas in Communications, vol 6, no. 9, pp. 1617-1622,Dezembro de 1988

[Wei94] L. Wei e D. Estrin, “The Trade-offs of Multicast Trees andAlgorithms”, in Proceedings of the Third International Conferenceon Computer Communications and Networking (IC3N ‘94), pp. 17-24,1994

[WinSock2] “Windows Sockets 2 Application Programming Interface”, TheWinSock Group, Maio de 1997



Lista de Acrônimos 107

107

LLiissttaa ddee AAccrrôônniimmooss

AAL ATM Adaptation LayerABR Available Bit Rate

ANSI American National StandardsInstitute

ARP Address Resolution Protocol

AS Autonomous Systems

ATM Asynchronous Transfer Mode

B-ISDN Broadband Integrated ServicesDigital Network

BUS Broadcast and Unknown Server

CBR Constant Bit Rate

CBT Core Based Trees

CCET Constrained Cheapest EdgeTree

CLP Cell Loss Priority

CLIP Classical IP

CSPT Constrained Shortest Path Trees

DCC Data Country Code

DVMRP Distance Vector MulticastRouting Protocol

ELAN Emulated LAN

ESI End System IdentifierGFC Generic Flow Control

HEC Header Error Control

IANA Internet Assign NumberAuthority

ICD International Code Designator

IETF Internet Engineering TaskForce

IGMP Internet Group ManagementProtocol

ILMI Interim Local Management

InterfaceIP Internet Protocol

IPX Internetwork Packet Exchange

ISDN Integrated Services DigitalNetwork

ITU-T InternationalTelecommunication Union –TelecommunicationStandardization Sector

LANE LAN Emulation

LEC LAN Emulation Client

LECS LAN Emulation Configuration

ServerLES LAN Emulation Server

LIS Logical IP Subnetwork

LLC Logical Link ControlLNNI Lan Emulation Network to

Network Interface

LUNI Lan Emulation User to NetworkInterface

MAC Medium Access Control

MARS Multicast Address ResolutionServer

MBONE Multicast Backbone

MCS Multicast Server

MOSPF Multicast Extensions to OSPF

MPEG Moving Picture Experts GroupMPOA Multiprotocol over ATM

MTU Maximum Transmission Unit

NSAP Network Service Acess Point

NNI Network-to-Network Interface

OSI Open Systems Interconnection

OSPF Open Shortest Path First

PIM Protocol Independent Multicast

PTI Payload Type Identifier

PVC Permanent Virtual Circuit

QdS Qualidade de ServiçoRDSI Redes Digitais de Serviços

Integrados

RDSI-FL Redes Digitais de ServiçosIntegrados de Faixa Larga

RFC Request for Comments

RIP Routing Information Protocol

RPB Reverse Path Broadcasting

RPM Reverse Path Multicasting

SAAL Signaling ATM AdaptationLayer

SVC Switched Virtual Calls

TCP Transmission Control Protocol

TTL Time To Live

TRPB Truncated Reverse PathBroadcasting

UBR Unspecified Bit Rate

UNI User to Network Interface

VBR Variable Bit Rate

VC Virtual Channels

VCC Virtual Channel Connection

VCI Virtual Cannel IdentifierVP Virtual Path

VPI Virtual Path Identifier



Lista de Acrônimos 108

algoritimos de roteamento

Documents