Eltt exemplar oorro•.'ol!do t redaçlo flnal da
-
Mrt;Jçio
dtvld"l ento corrigida e dofondldl por._8) rol; ( L, d - · " ~ t llPI'OVtltfP ptle a,nco F.x:tmln~oril.c.mpln<~s.n~o 'V'\.1 < l..V ~}v I J } I
l ( \
COCr,(.ll:N.I\OOR OE PÓS·GRADUAÇÀO CPG·IC
Avaliação de Protocolos de Roteamento Mu/ticast Sobre Redes TCPIIP
Aldecú VIeira S1monac1
Dissertação de Mestrado
-·-
-
-
--
-
-
..
Instituto de Computação
Universidade Estadual de Campmas
Avaliação de Protocolos de Roteamento
Multicast sobre Redes TCPIIP
Aldecir Vieira Simonaci
Fevereiro de 2000Banca Examinadora:
• Prof Dr Ricardo de Oliveira Anido (Orientador) Instituto de Computação- UNICAMP
• Pro f Ora Regina Helena Carlucci Santana
lCMC- USP- São Carlos
• Prof Dr. Célio Cardoso Guimarães
Instituto de Computação- UNICAMP
• Prof Dr Edmundo Roberto Mauro Madeira (Suplente) Lnstituto de Computação- IDJICA.MP
Dissertação apresentada ao Instituto de Computação da
Universidade Estadual de Campinas, como requisito parcial para
a obtenção do título de Mestre em C'iencta da Computação
lJNTC/\M
P
--D.c:-~t
VtJJ
~prnt?
1
.
5
c; CL.,. -.-.
y,l.l:-.3..
6
.:r~e
1o
o.---
•
)
!~l i @... \b l f,D.D \ b - oh .P0
-
·--···----
-1---
--M-00142369-8 SiSSaFICHA CATALOGRÁFICA ELABORADA PELA
BIBLIOTECA CENTRAL DA UNICAMP
Simonaci, Aldecir Vieira
Avaliação de protocolos de roteamento multicast sobre redes TCP/IP I Aldecir Vieira Simonaci. --Campinas, SP : [ s.n.], 2000.
Orientador : Ricardo de Oliveira Anido.
Dissertação (mestrado)- Universidade Estadual de
Campinas, Instituto de Computação.
1. Redes de computação-Protocolos. 2. TCPIIP
(Protocolo de rede de computação). I. Anido, Ricardo
de Oliveira. 11. Universidade Estadual de
Avaliação
de Protocolos de Roteamento
Multicast
Sobre
Redes TCP/IP
Este exemplar corresponde à redação final da
Dissertação devidamente corngida e defendida
por Aldecir V1eira Simonaci e aprovada pela
Banca Examinadora
Camptnas. 28 de fevereiro de 2000
~
G
M
Prof Dr Ricardo de Oliveira Anido (Orientador)
Dissertação apresentada ao Instituto de
Computação. UNICAMP. como requisito
parciaJ para a obtenção do titulo de Mestre em
TERMO DE
APROVAÇÃO
Tese
defendida e
aprovada em 28 de fevereiro de
2000
,
pela
Banca Examinadora composta pelos Professores
Doutores
:
Profa.
Ora
. Regina Helena C. Santana
ICMSC/USP
Prof. Dr.
Célio~uimarães
IC-UNICAMP
Prof.
Dr. Ricardo de Oliveira
Anido
Ao único Deus, Soberano, Criador
,
Doador
de toda a sabedoria,
de
todo o
Agradecimentos
Aos meus queddos pais, que me deram ensinamentos e se esforçaram muito para que eu chegasse até aqui. Mais que um agradecimento: um tributo de honra
Aos meus amados Regina e Gustavo. esposa e filho, apoio firme. compreensão e incentivo em todo o tempo
Ao Prof Antdo. pela paciência na orientação deste trabalho
Aos meus familiares, inclumdo os Kurka, instrumentos divinos no derramar de bençãos
A Guilherme, AJexandre e Marcus que muito colaboraram para a execução deste trabalho
À Marinha do Brasil, nobre instituição que me concedeu esta oportunidade, e aos muitos
amigos de lá que compartilham as minhas alegrias
Resumo
O crescimento da Internet e a necessidade atual de transporte de diferentes tipos de mídias por suas conexões apresentam novas exigências aos protocolos de roteamento existentes Diversos estudos têm sido realizados para adequar as redes TCP!IP aos novos requisitos de utilização da banda passante, visando a melhorar a confiabilidade, a velocidade e a distribuição da carga.
O roteamento multicast surgiu como o resultado do desenvolvimento de soluções mais eficientes para problemas relacionados com a redução de tráfego, propiciando maior flexibilidade e melhor escalabilidade.
Este trabalho apresenta um estudo dos protocolos de roteamento mu/ticast utilizados sobre as redes TCP/IP Algumas modificações foram introduzidas no funcionamento dos
processos de dilúvio e podas do Protocolo de Roteamento Multicast Vetor de D1stància e do Protocol Jndependenl Mulllcast - modo denso As modificações foram analisadas simulando os protocolos em um simulador de redes.
Abstract
The growth of the Internet and the current need to transport different types of medias through its connections present new demands to the existent routing protocols. Severa! studies have been accomplished to adapt the TCP/IP networks to the new requirements of use of the bandwidth, seeking to improve reliability, speed and load dístribution.
Multicast routing appeared as a result ofthe development of more efficient solutions for problems related with the reduction of network traffic, allowing more flexibility and better scalability.
This work presents a study of multicast routing protocols used on the TCP/IP networks. Some modífications were introduced in the operation of the flooding and prunings processes of the Distance Vector Multicast Routing Protocol and Protocol lndependent Multicast -Dense Mode. The modifications were analysed by simulating the protocols on a network simu1ator.
Conteúdo:
Agradecimentos vi
Resumo vii
Abstract viii 1 - Introdução ... ~····-···-··· 1 l l - Objenvos. 3 1.2 - Relevâncta 1.3 - Estrutura da Dissenação.. ... ... ... ... .... .... ... .. 4 2 - Mu/ticast .............. ~···u·ou·~···-··· 5
2 1 -Confiabilidade e Latência... ... . ... . 9
2 2 - Controle de Estado .. .. .. .. .... . . .. . . .. .. .... .. . ... .. .... .. .. ... .. .. ... ... . .... 11
2 3 - Controle de Congestionamento. .. ... .... .. ... .. ... . ... ... ... 12 2 4 - Recuperação de Falhas. . ... .... .. .. ... ... .. ... .. .. .. .... .. 12
2 5 - Gerenciamento de Grupos... .. .. .. . . .. .. 13
3- Redes TCPIIP ···-······-·-···-··· .. ··· 15
3.1 - Internet Protocol 17 3 1 I -Formato dos Datagramas ... . 18
3 1 2- Endereços lP.. ...... ... ... 23
3 2 - Jt,Ju/ttcast em Harm~are..
... ....
....
. . ...
...
...
263
3 - MulucastIP
27
3.3.2-Algoritmos de Roteamento Multicast . .... ... . 31
3.3.2.1 -Dilúvio .. ... . 31 3 3 2.2- Algontmo Baseado em Árvore Geradora ... .. 32
3.3.2.3-Difusão pelo Caminho Inverso ... .. 3.3.2.4- Truncated Reverse Path Broadcastmg .................................. . 35
3.3.2.5 -Multicast pelo Caminho Inverso ... . 35
3.3.2.6- Árvores Baseadas em Núcleos ... . 37
3.3.3 -Multicast Backbone ............................................................... . 38
4 - Roteamento Multicast JP ....................... . 40
4 1 -Protocolos de Roteamento Multicast- Modo Denso ... . 41
4.1 1- Protocolo de RoteamentoMuiticast Vetor de Distância ... . 42
4.1.2 - Mufhcast Open Shorlest Path First. . ... .
47
4.1 3- Protocollndependent Mufticasr- Modo Denso ... ... . 51
4.2-Protocolos de Roteamento Multic-asr- Modo Esparso ... . 54 4.2. 1 - Pro toco/Independem Multicast- Modo Esparso ... . 54
4.2.2-Core Based Trees ...... ... . 58
4 3 - Comparação dos Protocolos de Roteamento Mufllcast.. ... .. 60
5 - Análise de Protocolos Modificados ... ~···-··· .. ···~··· .. ··· 66
5.1 - As Modificações nos Protocolos ... . 67
5.2 - O Método de Avaliação ... .
68
5 2.1 - O Simulador... .. ... . 69
5.2.2-Modificações Efetuadas no Simulador ... .. 70
5 3 I - A Configuração da Rede Simulada . 71
5 2 2 - A Dinâmica da Stmulação. . ... ... .... ... ... .. 72
53 -Analise dos Resultados .. ···-··· .. ··· ... ... 77
6- Conclusão e Trabalhos Futuros ... -... 84
Lista de Figuras:
2 I - Cena rio de rede com transmissão broadcast. . . . . .. .. .... ... . .. .. .. ..
2.2-Transmissões unicast . ... ... . ... .. .. .. . ... . ...
2.3 - Transmissão multicast .. .. ... ... .
3 1 - Camadas de protocolos da arquitetura Internet TCP/IP
3 2 - Encapsulamento de datagramas em quadros
3 3 - Formato de um datagrama IP . .. .. ... . 3 4- Fragmentação de um datagrama ... . 6 7 8 16 17 19 21
3 5 - Formatos de endereços IP das classes A, B e C .. .. .. .. .... ... .... ... 24
3 6- Formato do endereço classe 0 ... ... 25
3 7-Formato do endereço classe E... ... ... 25
3 8 Atuação do protocolo I GMP . . .. .. ... .. . .. .. .. .. . .. .. . .. . .... . .. . . . .. .. . .. .. .. . .. .. . .. .. .. 29 3. 9 - Formato da mensagem
IGMP ..
..
.
...
..
....
.. ..
..
..
.. .. . ..
... .
.. .. .. .. .. ..
. ..
.
.
..
30
3 1 O( a)- Cenário de topologia de rede... ... ... ... ... 33
3 1 O(b) - Arvore Geradora ... ... ... .... . ... ... ... ... .. 33
3 I I - Exemplo de Difusão pelo Caminho Inverso. . ... . 34
3 J 2 - E 'emplo de Multtcast pelo Caminho Inverso .. .. . .. 36
3. J3- E'emplo de arvores baseadas em núcleo... .. .. ... 37
4 l(a)- Sub-rede do roteador A . ... .... -... ... ... ... ... 41
4 I (b) - Árvore geradora do roteador A para o
grupo
1 . ... ... .. .. .... ... . ... .. 414 2(b) - Informações recebidas do roteadorR2 43
4 2(c)- Nova tabela do roteador RI . ... ... ... 43 4 3 - Exemplo de rede .. .. ... . ... ... .... .... .. .. . . . . ..
4 4 - Pacotes de estado de enlace da rede.. . ...
4.5- Exemplo de uma cache de envio MOSPF . 4.6- Exemplo de rede com Rendezv011s Point .
4.7- Exemplo de árvore PIM.-SM transfom1ada para raiz na fonte ...
5 1 - A rede simulada no Network Ammator ..
S 2 - Diluvtos sobre a rede simulada . ... . ... .. ... .
48 48 50 55 57 74 75
S 3 - Vista aproximada da rede simulada.... . ... .... .... ... . . ... . . ... ... . .. 76
5 4 - Gráfico dos tmais de pacotes do tempo de poda padrão . .... . .. ... .. . . 77
S 5- Gráfico dos totais de pacotes do tempo de poda 5.0 (variação por tempo) 78
S 6- Gráfico dos totais de pacotes do tempo de poda 5O (variação por fontes e
recebedores). . ... .... . ... ... ... ... . ... .... .... . ... 79
5 7- Gráfico dos totais de pacotes do modelo sem dilúvios (variação por tempo) 80
58- Gráfico dos totais de pacotes do modelo sem dilúvios (variação por fontes
e recebedores) . .. ... . .... . ... .... .... . . ... . . . . .. .... . .. . . ... 81
5 9 -Gráfico dos totais de mensagens de enxertos.... .... ... .. 82
S I O - Gráfico dos totais de pacotes descartados 82
Lista de Tabelas:
3 I Classe de opções IP. . ... ... ... ... ... .... 23
3 2- Distribuição de endereços nas classes A,B e C ... .
3.3 - Endereços de alguns grupos multicasl conhecidos ... . ...
4 I - Exemplo de tabela inicial de um roteador por distância vetorial ... .
4 2 - Comparação de entradas nas tabelas de rotas das árvores SPT e RPT
5 1 - Quantidades de fontes e recebedores nas simulações
25
28
42
61
Capítulo 1
Introdução
A utilização de computadores interligados por redes é uma facilidade de
comunicação proporcionada a milhões de usuários em todo o planeta. A interligação das redes acrescentou um elevado, e crescente, número de beneficios. A evolução dessa comunicação, aliada às necessidades dos usuários, conduziu a um tráfego intenso nessas ligações. A capacitação de transmissão de áudio e vídeo, um requisito dos utilizadores
atendido por várias aplicações modernas, como videoconferencia, contribuiu para
intensificar esse tráfego.
A transmissão das mensagens efetuadas por um usuário nas ligações inter-redes
envolve, ocasionalmente, recebedores múltiplos e seletos. As tecnologias existentes de
broadcast (difusão) e unicast, para tal utilização, demonstram desvantagens que se
sobressaem no atual confronto entre o tráfego solicitado e a capacidade oferecida pelas redes.
O uso de broadcast obriga todas as estações da rede a processarem a mensagem, independente do seu imeresse. Com o uso do unicasl, para atingir vários destinos, efetua-se
Capítulo 1 - Introdução
repetidas transmissões, para endereços previamente conhecidos, também sobrecarregando os sistemas
A transmissão multicast foi desenvolvida visando a minimizar os problemas enfrentados por estas tecnologias no que tange à transmissão de mensagens para um grupo especlfico, além de oferecer maior disponibilidade de recursos para
as
necessidades modernas [Dee89].Com o uso de multicast, permite-se que cada máquina, voluntariamente. participe de uma transmissão, diferente do uso de broadcast. A associação ou a saida de um receptor de um grupo
é
desconhecida da estação transmissora, diferente do uso do unicasl. A grande economia de recursos em multTcast deriva do fato de que a transmissão é efetuada uma vez para um grupo especifico de recebedores, sendo replicada apenas nos pontos em que haja bifurcações na rota de distribuiçãoEste trabalho aborda os protocolos de multicast básicos que orientam a distribuição da comunicação para múltiplos destinos A visão de suas caracteristicas e de algumas restrições de funcionamento é de suma importância para um estudo comparativo e classifícatório, apropriado ao dinamismo das necessidades e dos modelos atuais.
Os trabalhos pioneiros com relação ao
IP
multicast foram lançados no final dos anos 80, por Stephen E. Deering, sendo padronizados pela IETF (Internei Engmeering TaskForce). As primeiras aplicações foram desenvolvidas no~one (Mulllcast Backbone) para
transmissões de áudio e vídeo gerados nas reuniões da JETF; a primeira transmissão foi de um encontro desse órgão, ocorrida em 1992 .
Atualmente, protocolos como o DVMRP (Distance Vector lvfulticasr Rouzing Protocol), o MOSPF (Multicast Open Shortest Path First), o CBT (Core Based Trees), o PIM-SM (Prorocol lndependent Mu/ticast - Sparse Mode) e o PIM-DM (Protocol /ndependenl Muilicast-Dense Mode), estão sendo aperfeiçoados para realizar o roteamento nas comunicações multicast, a gerência dos grupos multicast é feita pelo IGMP (Internet
Group Management Protocol), com a finalidade de suportar a comunicação aos grupos de receptores, usando exclusivamente a classe D de endereçamento IP, para identificar um grupo multicast específico.
Cap1tuJo I - Introdução
1.1
-Objetivos
Os objetivos desta dissertação são:
Realizar pesquisas e estudos sobre a comunicação de dados com o uso da técnica multicast. incluindo os principais conceitos, definições, protocolos e arquitetura;
2 Estudar as características dos protocolos de roteamento mulucast, abrangendo a filosofia de implementação de cada um,
3 Efetuar alterações nos funcionamento destes protocolos. coletando dados para análise de seus desempenhos sob a influencia de novos parâmetros, e
4. Apresentar uma avaliação inicial de alguns protocolos de roteamento multicast e suas versões modificadas.
1.2 -Relevância
A comunicação de dados através de redes de computadores vem demandando da ciência soluções que pennitam a transferência de grande quantidade de
b
y
z
es
em tempo cada vez menor~ ou mesmo em tempo real, contendo informações das mais variadas, dentre elas áudio e vídeo Nas últimas décadas várias pesquisas foram desenvolvidas com a i menção de otimizar a utilização da banda passante nas redes de computadores. Estes estudos criaram a concepção da difusão com o uso da técnica multicast, dando início à construção de vários protocolos de roteamento que pudessem absorver esta filosofia. Estes protocolos, alguns ainda em desenvolvimento, começam a ser implementados nas redes de computadores, o que torna interessante a análise dos mesmosAJguns trabalhos foram desenvolvidos visando a identificar e avaliar as possíveis melhorias a serem implementadas nos protocolos de roteamento multicast [Nor94] [Kron98], mas pouco tem sido realizado nesta área [Hur97)
Capítulo 1 - Introdução
A observação do funcionamento desses protocolos sob o efeito de alterações em
alguns de seus parâmetros contribuirá para enriquecer o conhecimento dessa técnica e a
adequação de seu emprego.
1.3
-Estrutura da Dissertação
Após esta introdução, a dissertação prossegue organizada com mais 5 (cinco)
capítulos.
-o capítulo 2 apresenta a técnica multicasT, abordando questões e vantagens do seu
uso e, confrontando-a com as técnicas existentes de broadcast e umcast;
-o capitulo 3 apresenta a arquitetura das redes TCP!IP e como ela é utilizada para
difusão das mensagens mult1cast;
-o capítulo 4 aborda o roteamento multicast IP com os protocolos mais conhecidos
para efetuar a transmissão para grupos de recebedores,
- no capítulo 5 são descritas as alterações propostas a protocolos eJcistentes e a
avaliação dessas propostas através de simulações. com a análise comparativa dos resultados
obtidos; e
- no capítulo 6 são apresentadas as conclusões e sugestões de futuros trabalhos
Capítulo 2
Multicast
Neste capítulo, as técnicas tradicionais de broadcast e unicast são resumidamente apresentadas e, em seguida, a técnica multicast é abordada comparativamente às primeiras e
também quanto às questões que envolvem sua evolução e seu emprego.
O envio de mensagens para múltiplos destinos em uma rede simultaneamente é
disponibilizado por muitas tecnologias, em hardware de rede local, e dos seus conceitos derivaram novas tecnologias capacitadas a atender as interligações das redes. A forma mais comum de transmissão para múltiplos pontos é denominada broadcast (difusão). Em transmissões por difusão, uma cópia da mensagem é enviada para todas as estações da rede, utilizando tecnologias próprias de cada rede local. A transmissão broadcast possui, porém, a grande desvantagem de consumir recursos de todas as máquinas, quando, muitas vezes,
várias destas máquinas destino irão descartar as mensagens logo após as receberem, por não
possuírem interesse naquela informação. Outra desvantagem é o consumo da banda
Capítulo 2 -Mull1cast
Na figura 2.l(a) pode ser visto um modelo simples de um cenário de rede com algumas bifurcações, onde a fonte S deseja enviar tráfego para alguns receptores. Pode-se
perceber que na figura 2.l(b) o tráfego da fomeS (representado por círculos preenchidos) para os recebedores A, E e F, por broadcast, obrigaria B, C e D a receberem mensagens
que não têm interesse e que serão processadas e descartadas.
(a) (b)
Figura 2.1- Cenário de rede com transmissão hroadcnst
Um outro modo de se efetuar uma distribuição para diversos destinatários seria o uso de repetidas transmissões umcast, despendendo tempo e inúmeros recursos na transmissão. Para atingir diversos usuários com sucessivas mensagens zmrcast, a fonte da
comunicação é obrigada a conhecer os endereços das estações de destino.
Em comunicações tradicionais unicast envolvendo várias máquinas
simultaneamente, cada mensagem enviada pela máquina origem é replicada de acordo com
a quantidade de destinos. Este modelo gera necessidades computacionais na fonte e
sobrecarga de tráfego na rede, que aumentam linearmente com o número de recebedores. A
carga é idêntica em todas as mensagens, só modificada na identificação do destino.
Utilizando novamente o cenário da figura 2.l(a) corno modelo, pode-se perceber que na figura 2.2 o tráfego da fonte S para os recebedores A (figura 2.2(a)), E (figura
2 2(b)) e F (figura 2 2(c)), por unicast, obriga S a executar uma transmissão para cada um dos destinatários pretendidos. que devem ser conhecidos.
Capítulo 2 -Multicasl
O
•>
(b) (c)Figura 2.2-Transmissões unic~t
As aplicações que atuam sobre redes interligadas prec1sam de capacitação para atender as exigências atuais, tais como escalabilidade; atendimento simultâneo a inumeros solicitantes, grande capacidade de escoamento de tráfego, e requisitos de qualidade de serviços diferenciados. O rápido crescimento da J ntemet, e sua abrangência global, tem permitido que diversos usuàrios façam seus pedidos, instalem e ofenem produtos,
procedam a buscas e enviem tráfego variado. As diferentes demandas ocorrem com intenso paralelismo, exigindo aplicações habilitadas a atendimento concomitante, e que não menosprezem a seletividade. O tráfego gerado tem sido cada vez mais intenso, não só pelos incontáveis acessos, como tambem pelo envio de video e audio. exigindo velocidade de fluxo sobre seus enlaces. Alguns processos requerem serviços que privilegiem determinada qualidade no tráfego de suas mensagens, como por exemplo a preferência pela confiabilidade, ou por um limite específico de retardo.
Tats exigênc1as contribuem para o surgimento de novas tecnicas de utilização das interligações de redes. Os protocolos de roteamento inter-redes exercem um papel fundamental para o atendimento destes requisitos, ou para amenizar os efeitos dos que forem parcialmente atendidos.
Uma técnica atual de transmissão para múltiplos pontos sobre redes interligadas é a multicast (tambem chamada de difusão seletiva [Mel97]). Utilizada anteriormente em hardware de redes como EtherneL, sua abstração para protocolos que efetuam roteamento entre redes visava atender algumas das exigências das aplicações modernas. As vantagens obtidas com o uso de muliicasT decorrem do fato de que apenas uma cópia de cada pacote é
Capítulo 2 - Multicast
enviada, sendo duplicada somente quando houver ramificações a serem percorridas na rota
de remessa, aliviando os recursos computacionais envolvidos e liberando banda passante na rede Mulucast ainda tem a seu favor o fato de não exigir da estação de origem o conhecimento das estações que fazem parte do grupo de recebedores das suas mensagens.
A transmissão multzcast pode ser vista como uma generalização das outras formas
de transmissão. Pode-se pensar, por exemplo, que a forma de transmissão convencional
unicast é uma transmissão multicast onde há apenas um participante no grupo, e, de forma similar, que a transmissão broadcast é uma forma de transmissão mulricast onde todas as máquinas são membros do grupo.
Ainda usando corno modelo a figura 2.l(a), nota-se que na figura 23 o tráfego da
fonteS para os recebedores A, E e F, por mulcicasz, permite que somente os interessados na informação recebam a mensagem .
.Figura 2.3- Transmissão multicast
O uso da comunicação mulzicast atenua os efeitos da escalabilidade requerida, buscando ainda oferecer um ganho no consumo da banda passante e oferecer um melhor
atendimento aos processos que se utilizam das interligações de redes.
Embora sejam muitas as vantagens proporcionadas pelos protocolos de roteamento
multicast, grande parte das redes atuais já funcionava quando do seu surgimento O custo da renovação do parque computacional e o fato de ainda haver muita pesquisa e desenvolvimento em multicast, dentre outras causas, têm motivado a demora na
Capitulo 2 - Mul11cast
O problema enfrentado por tentar enviar tráfego mu/ticast por roteadores que não
oferecem tal serviço é resolvido com a técnica do "encapsulamento", onde as mensagens
mulzicast são colocadas dentro de mensagens umcast com o endereço do próximo roteador
multicast no campo destino. A máquina receptora extrai a mensagem da cápsula e a trata como se fosse recebida de uma intertàce local [Com91]. Nos protocolos, o parâmetro
"Tempo de Vida" (os parâmetros serão descritos no próximo capítulo) da mensagem
unicast delimita o número de passos da rota que ela percorrerá envelopada, sendo decrementado a cada passo, o que ocorre independente do tempo de vida da mensagem
multicast, que sõ voltará a ser decrementado após desencapsulado
Muitas questões têm se apresentado para a obtenção de uma comunicação confiável em um ambiente multicast, dentre as quais pode-se destacar níveis diferenciados de confíabilidade e latência; mecanismos de controle de estado~ controle de congestionamento;
recuperação mediante situações de falhas; e gerenciamento de grupos. Estas questões são
apresentadas nas seções seguintes
2.1 - C
onfiabilidade e Latência
Confiabilidade está ligada à entrega dos dados e à certeza do recebimento pelo destino. Um protocolo de transmissão entrega confiavelmente se pode garantir que fará
chegar à outra extremidade da linha de transmissão todo o tráfego a ela destinado, ou informará à origem uma impossibilidade que extrapola suas capacidades de sucesso. A
ceneza do recebimento ocorre quando, após a chegada dos dados. possíveis falhas de integridade são corrigidas e o serviço receptor toma posse das mensagens.
Em unicast o modelo de confiabilidade é simples. Há apenas duas partes envolvidas
e uma falha entre elas é facilmente detectada. Normalmente, a retransmissão da mensagem
soluciona adequadamente o problema. Confiabilidade em multicast é mais complexa. Está
Capítulo 2-Mult1casr
todos os membros do grupo A falha na transmissão para um membro - que pode fazer parte de um grupo com muitos membros espalhados em pontos distantes - e a detecção desta
falha exigem mecanismos de controle que não causem maiores transtornos à rede
A latêncta é o tempo gasto para a entrega dos dados. Em mu/ticast este requisito eleva-se na proporção que o número de recebedores e suas diferentes distâncias da fonte
variam. A rede onde a fonte está situada é estimulada pela introdução de um fluxo de
mensagens. Nos pontos onde houver bifurcações, as replicações estimularão novas redes. O
tempo de resposta a este estímulo, ou de latência, será o tempo gasto para atingir o último receptor em sempre o último receptor será o mais distante geograficamente, mas o mais lento a ser alcançado
Os requisitos de confiabilidade e latência podem se apresentar como forças em
oposição O conflito entre estes requisitos ocorre quando detenninada aplicação tem uma data limite para que o recebimento dos dados surta os efeitos deseJados O parâmetro Intervalo de Confiabilidade -RI (Reliabtlicy fnlerval) reflete o intervalo de tempo em que a entrega do dado é útil [Zhen97] A cüvulgação de uma lista de endereços ou de notícias pode ter um RI de alguns dias, pois a confíabilidade se sobrepõe à velocidade. enquanto o Rl de uma ferramenta de conversação não excederia a minutos.
As avaliações dos protocolos de comunicação que mensuram as chegadas e as perdas de mensagens fornecem informações de confiabilidade. Esta confiabilidade pode ser
vista como uma medida de eficiência do protoc.olo de comunicação.
Os testes de latência dos protocolos de comunicação são aqueles que coletam medidas baseadas nos retardas das transmissões. Como viu-se, retardes demasiados podem invalidar os efeitos dos dados. assi~ poder-se-ia considerar a informação de Iatênc1a como uma medida da eficácia do protocolo de comunicação
Capítulo 2 -MultLcast
2.2 -
Controle de Estado
O controle de estado abrange as atividades de confirmação, retransmissão e a quem são atribuidas tais tarefas. As aplicações multrcast são classificadas em baseadas nos
remetentes (sender-based) e baseadas nos recebedores (receiver-based), dependendo sobre a quem cabe o controle da conexão e da retransmissão dos pacotes perdidos.
Em unicast,
qualquer destas classes trabalham satisfatoriamente, porém para multicast há diferenças importantes entre elas.No modelo baseado no remetente. as aplicações mu/ticast seriam obrigadas a manter um bloco de controle para cada um dos múltiplos recebedores Neste esquema, o remetente controla o estado mediante recibos positivos (acknowledgements, ou simplesmente acks) enviados pelos endereçados de seus pacotes. Como os grupos são dinàmicos e, normalmente, desconhecidos de quem está enviando, esta tarefa se toma por vezes impossível
Em contraste, o modelo baseado nos recebedores faz com que a tarefa de retransmissão seja dividida entre os endereçados dos pacotes, podendo ainda usar um esquema onde apenas os pacotes não recebidos são informados (negative acks, ou naclcs),
reduzindo o retorno de mensagens de controle (jeedback)
Outro mecanismo importante para a supressão do feedback está na organização dos recebedores em hierarquias, como é usado no Rebable J.v:fulticast Transporr Protocol
-RMTP [Lin96]. Um esquema hierárquico é aquele onde os nós são divididos em regiões, com cada nó capaz de manter as informações de rotas das regiões a que pertence [Soa95].
Neste esquema, os roteadores designados em cada nível da hierarquia são responsáveis pela
transmissão do recibo e se encarregam da retransmissão dos dados para o nivel abaixo. A fonte (e cada nível abaixo) prossegue com a transmissão, e libera a memória da carga de efetuar retransmissões, à medida que, apenas, o nível abaixo comprova o recebimento.
O esquema baseado em recebedores, em especial os hierárquicos, demonstram maior escalabilidade e são melhor adequados para o uso em mu/ticast [Lev96]
Capítulo 2 -Multicast
2.3 - Controle de Congestionamento
A questão do controle de congestionamento requer também um cuidado especial em
mullicast. A fonte pode reduzir sua velocidade de transmissão toda vez que detectar perda de pacotes, como no
TCP
;
entretanto, este procedimento determina uma taxa de transmissão de acordo com o recebedor mais lento. As perdas de pacotes podem ocorrer de forma não relacionada, em diferentes partes da árvore de distribuição, reduzindo a taxa de transmissão ao mínimo. Uma proposta é iniciar a transmissão pela taxa mínima e ir aumentando à medida que nenhum recebedor informe perda de pacotes Esta solução não trabalha eficientemente em apJjcações que exijam uma taxa de transmissão elevada, como as aplicações que usam sinais de áudio.Outra proposta sugerida é a dos múltiplos grupos multicast. A fonte transmite com taxas diferentes para os múltiplos grupos e os recebedores associam-se aos grupos de acordo com o congestionamento suportado. Esta proposta também foge a um dos objetivos principais da estratégia multicast, o de evitar transmissões repetidas.
2.4- Recuperação de Falhas
A recuperação de falhas pode ser realizada com o reenvio para o
grupo
multicastdos pacotes perdidos Todavia, mesmo os recebedores que não tiveram perdas participarão dessa retransmissão. Um grupo de retransmissão também pode ser utilizado para que os recebedores que tiverem pacotes perdidos possam dele participar.
A retransmissão de pacotes perdidos pode ser também realizada numa abrangência mais local, onde os que dela necessitam solicitam-na a outros recebedores mais próximos. num escopo menor. Caso não tenham sucesso, enviam outra solicitação, num escopo maior [Zhen97]
Capitulo 2 -}vfulncasr
2.5- Gerenciamento
de Grupos
Por não se tratar de comunicação entre transmissor e receptor únicos, faci i mente
obtida com a técnica unicasr existente, e nem da difusão indiscriminada que atinge todos os
receptores, como
broadcast,
mas sim, da capacidade de comunicação com um grupo seletode "ouvintes", a transmissão mu!ticast necessita saber gerenciar seu rol de membros.
A criação de um serviço apto a alcançar um grupo discriminado na extremidade de
destino das linhas de transmissão foi um dos objetivos que norteou as pesquisas de
desenvolvimento da difusão por mulncast.
Para tomar a comurucação multicast flexível, os grupos têm que ser dinâmicos, ou
seja, um membro pode associar-se ou desligar-se do grupo quando desejar A fonte do
tráfego não pode ter sua transmissão afetada pelas alterações que ocorrem na lista de
membros do grupo de destino, ou mesmo pelas modificações da estrutura de distribuição
causadas por estes movimentos.
Os roteadores devem estar constantemente adequando-se às alterações de membros do grupo, propiciando a entrega das mensagens aos que tenham interesse ou economizando
recursos ao retirar a distribuição dos que manifestaram sua saída
O gerenciamento de grupos considera a existência de alguns grupos com presença
constante de membros e que devem ser rapidamente reconhecidos. Para tais grupos. uma
identificação permanente facilita a descoberta e o acesso a seus membros Para outros
grupos, com existência transttória, cuja dinâmica de fihação e desligamento e intensa e onde existe a possibilidade de, em algum momento, não possuir membros, será suficiente a atribuição de uma identificação temporária.
Um modo simples de manter os dados sobre os grupos atualizados é através da
consulta periódica enviada aos participantes de uma rede, pedindo que informem os grupos
aos quais seus processos pertencem ou têm interesse em pertencer. As respostas,
padronizadas. são confrontadas com os dados exjstentes, podendo gerar alterações nas tabelas e na distribuição
Capitulo 2 -MultLcasl
O fluxo de solicitações e respostas gera novas exigências no projeto e na utilização dos mecanismos de gerenciamento de grupos. O consumo de banda passante, por exemplo, não pode ser elevado com o controle em detrimento das mensagens de dados propriamente ditas. Uma das variáveis que surge é o tamanho das mensagens de consulta e resposta, que deve conter apenas as informações necessárias para manter o atendimento aos membros Outra variável é a periodicidade: nem muito demorada que cause descontrole, nem tão rápida que ocupe demais os sistemas com seus tráfego e processamento.
O gerenciamento deve ainda ter flexibilidade para permitir a entrada e saída de membros do grupo por manifestações voluntárias extemporâneas, independente da obrigatoriedade de aguardar uma consulta.
Na seção 3.3.1 será visto o protocolo utilizado para o gerenciamento de grupos multicast
Capítulo 3
Redes TCP /IP
este capttulo é abordada a arquitetura das redes conhecidas como TCPIIP, o
formato das mensagens que nelas trafegam e do endereçamento utilizado, inclusive para
trâfego multtcast Explanações sobre multicast em hardware e mulflcast IP, inclumdo
algoritmos e oMbone, completam o conteúdo do capítulo
Tipicamente, estão reservados dentro de cada tecnologia de hardware um grande
conJunto de endereços para uso com difusão seletiva Quando um grupo de máquinas deseja
comunicar-se, elas escolhem um endereço multicast para a sua comunicação As interfaces
de rede são configuradas para reconhecer o endereço selectonado e todas as maquinas
pertencentes ao grupo passam a receber uma cópia de cada quadro enviado para o endereço
mu/nca.\1
Semelhante à difusão seletiva em hardware de rede locaL e:Oste difusão seletiva
para a camada IP da arquitetura Internet TCPIIP [Com91] [Dee89] A forma de
endereçamento mulucasr IP e uma abstraÇão do mulucast em hardware Ela permite que
uma mensagem seJa transmitida para um conjunto de maqumas que fonnam um grupo
Capítulo 3 - Redes TCP/JP
A arquitetura TCPIIP provê basicamente dois conjuntos de serv1ços no nível inferior, um serviço de rede não orientado à conexão, fornecido pelo Internet Protocol (IP), no nivel superior, um serviço de transporte orientado à conexão, fornecido pelo Transmission Contrai Protocol (TCP), ou um serviço sem conexão para transportar as mensagens, fornecido pelo User Dmagram Prowcol (UDP). A figura 3.1 permite uma visualização da distribuição das camadas na arquitetura TCPIIP.
Aplicações
Transmission Control User Datagram Protocol
Protocol (TCP) (UDP)
Internet Protocol (IP)
Redes Locais
Figura 3.1 -Camadas de protocolos da arquitetura Internet TCPIIP
Para permitir ao protocolo UDP efetuar a entrega correta e enviar respostas, as mensagens no formato UDP contêm um número de porta de destino e um número de porta de origem. O UDP usa o IP para transportar uma mensagem com a mesma estratégia não confiável de transmissão de datagrama sem conexão, onde não há recibos, ordenações ou controle de fluxo.
O protocolo de comunicação TCP oferece um serviço de fluxo confiável para transmissões de mensagens na arquitetura TCPIIP O protocolo isola dos programas aplicativos as tarefas de detecção e recuperação de erros causados por perdas, danos, atrasos e duplicações de pacotes. Embora também use as portas de protocolo para a comunicação, sua abstração principal é a conexão. As conexões identificam um par de pomos terminais; e os pontos terminais são identificados pelo endereço da máquina associado ao número da porta TCP Nesta abstração, determinado número de portas TCP pode ser compartilhado por várias conexões em uma mesma máquina [Corn91)
Cap1tulo 3 - Redes TCPIIP
3.1 -Internet Protocol
O Internet Protocol (IP) é um protocolo com um mecanismo de transmissão "
best-effort' e ''não confiável". Best-effon porque o protocolo envida todos os esforços
necessários para efetuar a entrega e "não confiável" resulta do fato de que pode haver
duplicação, atraso ou perda O protocolo IP, tendo o daragrama como unidade básica de
transferência de dados, exerce as funções de roteamento (designando o caminho a ser seguido pelos datagramas), o processamento dos datagramas, a geração das mensagens de erro e o descarte de pacotes
O serviço oferecido pelo (P é sem conexão A comunicação e sem controle de fluxo e sem controle de erros nos dados transmitidos. E efetuado um controle de erros apenas nos dados contidos no cabeçalho através de um campo do datagrama denominado cabeçalho de
''enjicaçào (será visto adiante).
Numa rede fisica, o objeto de transmissão é o quadro que possui um cabeçalho e uma area para dados reconhecidos por hardware. o cabeçalho do quadro, dentre outras informações de controle, estão os endereços fisicos de origem e de destino. A transferência de datagramas IP na interligação em redes é realizada através do seu encapsulamento na área de dados do quadro. A figura 3.2 permite a visualização do encapsulamento·
CABEÇALHO DO ÁREA DE DADOS DO DATAGRAMA DATAGRAMA
I
CABEÇALHO DO ÁREA DE DADOS DO QUADROQUADRO
Figura 3.1 -Encapsulamento de datagramas em quadros
O cabeçalho do datagrama contém os endereços IP de origem e destino, de 32 bits. O formato do datagrama, com seus campos, será visto na próxima seção
Capítulo 3 - Redes TCPIIP
Uma rede TCPIIP é constituída por sub-redes conectadas através de elementos
denominados roteadores. Os roteadores, através do protocolo IP, são responsáveis pelo
encaminhamento dos datagramas, da estação de origem à estação de destino. Os endereços
IP permitem aos roteadores realizar o encaminhamento ao longo do percurso.
O protocolo também fornece o serviço de fragmentação e remontagem de
datagramas longos que podem precisar ser divididos em pacotes menores devido à
limitação de tamanho de pacote imposta por algumas redes por onde o datagrama trafega
até sua chegada ao destino. Nesta camada é realizado também o mapeamento de endereços
IP em endereços fisicos, e vice-versa [Com91]
3
.1.1
-
F
o
r
mato dos Datagrama
s
A figura 3 3 mostra o formato de um datagrama IP com as suas divisões[Com91]
Na parte superior da figura estão representadas as posições dos bits em cada palavra de 32
biLs, facilitando a identificação dos paràmetros. A descrição de cada um dos parâmetros
completa esta seção
Ao receber um quadro, o protocolo de interface de rede desencapsula o datagrama e
o entrega ao protocolo IP para processamento. Em se tratando de um roteador, se o
endereço de destino corresponde ao de sua rede local, ele efetua a entrega, não sendo um
endereço de sua rede, o protocolo IP decrementará o parâmetro Tempo-de-vida e fará o
roteamento. Neste caso, o roteador verifica em sua tabela de roteamento IP o endereço de
rede do próximo roteador na direção do dest1no e devolve à interface de rede o datagrama
para encapsulamento em um quadro e transmissão, fornecendo também o endereço desse
Capitulo 3 - Redes TCP 1P
:
o
7 ; 8 15 : 16 23 : 24 31 :Versão Comp. do Tipo de serviço Comprimento total cabeçalho
Identificação Flags Deslocamento do
fragmento
Tempo de vida
I
Protocolo Verificação da soma do cabeçalhoEndereço IP da or·igem
Endereço IP do destino
Opções IP
I
EnchimentoDados
Fi~!ura 3.3-Formato de um dacagrama lP
O pnmeiro parâmetro. \ ersão, de quatro btts, define a versão do protocolo IP usada pela fonte para gerar o datagrama Com esta informação, os roteadores e o destinatario verificam os pacotes e podem processá-los se a versão do protocolo é conhecida, descartando, e não alterando, os datagramas em versões diferentes das suas
O segundo campo, também de quatro bils, é o Comprimento do Cabeçalho. Ele informa o tamanho do cabeçalho do datagrama em unidades de 32 btts Apos preencher o endereço de destino, um cabeçalho já contém cinco destas unidades, podendo então ser acresctdo das Opções IP e do Enchimemo (Padding), como sera visto a seguir
Os parâmetros da qualidade de serviço desejada são informados atraves dos oito btts do campo Tipo de Serviço Os três primeiros bu do campo, conhecidos como
Precedência. definem a prioridade no processamento dos datagramas Com valores de zero
(normal) a sete (pacote de controle de rede), a Precedência permite que tnformações de controle de congestionamento ultrapassem pacotes de dados Os três birs seguintes solicitam o tipo de transporte para o datagrama e são conhecidos como D, Te R O bit D
Cap1tuJo 3 - Redes TCPIIP
(de Delay) solicita um baixo retardo; O bit T (de Throughput) requer uma alta taxa de
transferência; e o bit R (de Reliability) requisita confiabilidade aJta na entrega Os dois
últimos bits não são utilizados
O campo seguinte é o Comprimento Total de todo o datagrama, incluídos o cabeçalho e os dados, fornecido em unidades de octetos O seu tamanho e de 16 bizs, de
onde pode-se concluir que um datagrama pode ter até 216 octetos. ou 65.536 octetos
Os campos Identificação, Flags e Deslocamento do fl"agmento permitem o controle de fragmentação e remontagem de datagramas. Em uma interligação de redes pode ocorrer
que determinado trecho do caminho percorrido por um pacote não suporte efetuar transferência de pacotes de tamanho semelhante à do trecho inicial, ou seja, a Unidade Máxima de Transferência (MTU, de Maximum Transfer Uni!) em alguma rede por onde o
data grama atravessará pode ser menor do que a MTU da rede de origem Assim, o roteador
na fronteira da rede com MTU menor divide (em múltiplos de 8) o datagrama em
fragmentos, adicionando cabeçalhos TCP e IP a estes fragmentos e, consequentemente,
aumentando o custo [Tan96]
O campo Identificação traz, em seus 16 bits, um número inteiro gerado pela fonte que possibilita ao destino distinguir os datagramas recebidos daquela origem Este número
é incrementado a cada novo datagrama enviado. O roteador que fragmenta um datagrama repete a identificação em todos os fi"agmentos para que o receptor possa remontá-los
O campo
Flags
possui um primeiro bit não utilizado, um segundo denominado DF eum terceiro, chamado de MF. O bit DF ( Don't Fragment, ou ainda, Não Fragmentar)
quando ajustado para 1 informa aos roteadores no caminho do datagrama que ele oão pode
ser fracionado. Se um destes roteadores precisar dividir o datagrama assim ajustado.
descarta-o e envia uma mensagem de erro à fonte [Com9l ], que pode tentar reenviar a mensagem por outro caminho que suporte o tamanho do datagrama. Datagramas inteiros
podem ser úteis para inicialização remota de máquinas cujas RO:M solicitem uma imagem de memória a outra máquina à qual esteja interligada em rede [Tan96].
O protocolo IP não garante a entrega ordenada dos ~omentos e, para garantir ao destino o recebimento de todas as frações e possibilitar a remontagem do datagrama, o
Capitulo 3- Redes TCPIIP
cabeçalho dispõe do terceiro bu do campo Flags, o
MF
(ou Mais Fragmentos) Todos osfragmemos. com exceção do ultjmo, possuem a infonnação de que há mais fragmentos
O campo Deslocamento do Fragmento (Fragmem
Oifser)
,
com 13 blls. informa apos1çào do fragmento, em octetos, no datagrama, possibilitando assim, 8192 fragmentos por datagrama. Este campo tem vaJor zero no primeiro fragmento e em datagramas inteiros.
O recepLOr, quando da chegada de um fragmento, reconhece-o pelo campo
Identificação, o bit de Mais Fragmentos ajustado e o Deslocamento do Fragmento igual a O,
e então. dispara um temporizador de remontagem. A remontagem do datagrama é possível
com a chegada de todos os fragmentos com a mesma identificação. dentre os quais, um
com o NfF desligado e com o maior valor de deslocamento (o último) Se apenas um
fragmento for perdido ou atrasar excessivamente, todo o datagrama sera descartado quando
o temponzador de remontagem expirar
CabeçaJbo Datagrama ldentific:~çiio
=
X DF=O MF=O Cabeçalho Fragmento l Identificação= X DF ... O MF- 1 Deslocamento= O Dados 800 bytes Cabeçalho Fra.:,OJDento 2 Identificação= X DF=O MF=l Deslocamento= 800 Dad~ 2000 b~1es Dados 800 bytes Cabeçalho Fragmento 3 ldentificaçilo=
X DFmO 1\tF• O Deslocamento= 1600Figura 3.4- Fragmentação de um data~rama
Dado 400bytes
Capítulo 3-Redes TCPIIP
A figura 3 4 exemplifica uma fragmentação.
O próximo campo do cabeçalho, Tempo-de-vida ou
TTL
(Time to Live), permiteque a origem determine a duração do datagrama na interligação entre redes. Como o tempo
é medido em segundos e o campo tem 8 bits. sua permanência máxima é de 255 segundos.
Cada roteador no caminho entre a fonte e o receptor decrementará o TTL pelo tempo que o
datagrama aguardar em uma fila para processamento e mais em um durante o
processamento [Com91]. Se o valor do TTL chegar a zero antes da entrega final, o pacote é
descartado e uma mensagem de aviso é enviada à origem O Tempo-de-vida impede que
um datagrama trafegue por tempo indeterminado numa rede que pode estar com falhas de
roteamento, como laços ou congestionamento. O campo TIL tem sido utilizado,
principalmente, para limitar o escopo (threshold) de distribuição de pacotes multicast,
significando o número de roteadores na rota até o destino, sendo reduzido a cada nó
O campo Protocolo define o formato dos dados contidos na área de dados do
datagrama O número inteiro inserido nos 8 bits deste campo é padronizado para toda a
Internet, permitindo a qualquer máquina interligada reconhecer se o protocolo criador da
pacote é o TCP, o UDP, o IGMP ou outro [Rey94]
A seguir, o campo Verificação do cabeçalho (header checkszrm), com um total de 16 bits., serve para identificar erros no datagrama, que podem ter ocorridos durante a
transmissão ou na atualização do cabeçalho nos nós intermediários. Desta forma, este
campo é recalculado e verificado a cada ponto onde o cabeçalho é processado Na
verificação IP o cabeçalho é tratado como uma sequência de números inteiros de 16 bits (na
ordem de bytes da rede), reunindo-os numa aritmética complemento de um, e considerando
o complemento de um como resultado. Para efeito de cálculo, este campo é ajustado para
zero.
Os dois próximos parâmetros são o Endereço IP da Origem e o Endereço IP do
Destino, de 32 bits, indjcando, respectivamente, os endereços da fonte e do recebedor da mensagem.
Em seguida, o campo Opções IP é usado para fornecer informações de segurança,
Capítulo 3 - Redes TCPIIP
variável, de acordo com as opções selecionadas, podendo conter nenhuma ou várias opções.
Cada octeto representativo de opção é dividido em três panes· Cópia, de um bit~ dois brts incticando a Classe da opção; e cinco brts para o Número da opção Quando o b11 Cópia é
ajustado em um, a opção deve ser copiada em todos os fragmentos, caso contrario, somente no primeiro fragmento Com a Classe e o Número pode-se identificar a classe escolhida e a opção específica dentro de cada uma dessas classes. A tabela 3.1 mostra como as classes são atribuídas.
Classe de Opções Discriminação
o
Controle de rede ou de datagrama I Reservado para uso futuro 2 Depuração e avaliação...
..) Reservado para uso futuro
Tabela 3.1- Classe de Opções lP
O campo Enchimento (Paddmg), também de tamanho variável, é usado para
garantir que o comprimento do cabeçalho do datagrama seja sempre um múltiplo inteiro de trinta e dois bits Para tal, é preenchido com zeros.
Por fim, o campo Dados contém a mensagem propriamente dita
3.1.2- Endereços IP
Na Internet, cada máquina, seja uma estação de trabalho ou um roteador, possui seu
endereço IP distinto, de 32 bits, com uma combinação unica de número de identificação da
rede e numero de identificação da máquina, adequados para utilização nos campos
Capítulo 3 - Redes TCP/IP
Os endereços da classe C aplicam-se às redes que possuem um menor número de
hosts, até 28 (256), mas um grande número de sub-redes, ate 221. A classe B ê usada para as
redes com tamanho intermediário, até 2t4 sub-redes> com quantjdade de estações variando entre 28 e 216. A classe A de endereçamento serve para organizações com mais de 216 (65.536) estações e menor número de sub-redes, até 27.
Os diferentes formatos dos endereços IP e o tamanho de suas divisões são most.rados na figura 3.5.
31 :
I
OI
ld. da Rede Identificação da MáquinaEndereço classe A
15 : 16 31
10 ldentiHcação da Rede Identificação da Máquina
Endereço classe B
o
2.
:3 23 :24.
31110 Identificação da Rede ld. da Máquina Endereço classe C
Figura 3.5- Formato-s de endereços JP das classes A, B c C
O endereço IP de interijgação em redes é representado por quatro números decimais inteiros separados por pontos (dotted decimal notation), onde cada número inteiro significa o valor de um octeto, facilitando a representação dos 32 b1ts A notação decimal byte a byte pontuada é usada em documentos técnicos e em programas aplicativos.
Os formatos das classes A, B e C permitem, respectivamente, na notação decimal
com ponto, os endereços de 1.0.0.0 a 223.255 255.255, distribuídos de acordo com a tabela
Capítulo 3-Redes TCPIIP
Classe Menor Endereço Maior Endereço
A 1.0.0.0 127.255.255.255
B 128.0.0.0 191.255.255.255
c
192 0.0.0 223.255 255 255 Tabela 3.2- Distribuição de endereços nas classes A, B e COs endereços da classe A, iniciados com 127, são reservados para teste de loopback.
Os pacotes enviados com esses endereços no destinatário não são transmitidos, não trafegam na rede, são processados localmente como pacotes de entrada [Tan96][Com9l]
Em multrcasT é utilizada a classe D de endereçamento IP, conforme a figura 3 6·
31 Identificação do grupo
Figura 3.6-Formato do endereço classe D
Os primeiros quatro bits do endereço contêm o valor "1110" e identificam o endereço como mu/ticast Os vinte e oito brts seguintes indicam um grupo multicast específico. Expressos na notação decimal byte a byte, os endereços multicast IP variam entre 224 O 0.0 e 239.255.255 255. O endereço 224.0 0.0 é reservado, não podendo ser atribuído a algum grupo, e 224.0.0 1 é relativo ao grupo permanente de todas as máquinas e roteadores em uma rede local
Há ainda o formato de endereços classe E, mostrado na figura 3. 7, abrangendo a faixa de endereçamento de 240.0.0.0 a 247.255.255.255, reservado para uso futuro
o
4
1
5
32 :11110 Reservado para uso futuro
Capítulo 3-Redes TCPIIP
A autoridade central que define a politica de atribuição de números de endereços é a
Jntemez
Assigned
Number Authority (IANA), e cabe àInternet
Network lnfonnation Center(INTERNIC) distribuir os números de identificação de redes Após a obtenção da
Identificação da rede, as organizações podem designar seus números de identificação de
máquinas.
Existem algumas funcionalidades adicionais providas pela camada IP que fazem uso de valores preestabelecidos nos identificadores de sub-redes e de estações no endereço IP
A função direct broadcasl é uma delas [Com91]. Através desta função é possibilitado o
envio de uma mensagem a uma sub-rede destino, de forma que seja feita a sua difusão a todas as estações dessa rede Para isto, o campo identificador da estação é preenchido com
valores "I" para os büs e o identificador da rede contém o identificador da sub-rede destino
Outra função existente e a denominada limited broadcast, que possibilita o envio de uma
mensagem para todas as estações locais, preenchendo ambos os campos do endereço com
valores "1 ''.
3.2
-
Multicast
em
Hardware
A maioria das redes locais, tais como a
Ethernec
e a TokenRing,
suportam osserviços multicast em nível de hardware, o que tem sido útil para muitas aplicações e
sistemas distribuídos. O advento dos protocolos de roteamento mult1cast permitiram que as vantagens oferecidas pela multidifusão em hardware de redes locais fossem estendidas para
a interligação das redes.
Na Ethernet, é utilizado o bit de ordem inferior do octeto de mais alta ordem para
distinguir entre endereços unicast tradicionais (valor O para o bit) e endereços multicast
(valor 1). Utilizando a notação hexadecimal pontuada, o bit de difusão seletiva é dado por:
Capnulo 3 - Redes TCPIIP
Inicialmente, a mterface de rede é configurada para aceitar pacotes destinados para o endereço de difusão Ethemet ou o endereço fisico da maquina Entretanto, a interface pode ser reconfigurada facilmente para reconhecer um pequeno conJunto de endereços de mulucasr [Com91].
3.3 - Multicast IP
A comunicação mulllcast IP é definida como a transm•ssão de um pacote I.P para um grupo de recebedores, utilizando o mesmo método best-effort usado em transmissões umcast, com a diferença de que o pacote gerado pela fonte somente sofrera replicações no cammho aos desunes quando necessário, para possibilitar a recepção por todos os integrantes do grupo ao qual o pacote foi endereçado
A forma de difusão multicast IP é uma abstração da difusão com mult1casr em hardware Ela permite que um datagrama IP seja transmitido para um conJunto de maquinas que formam um grupo identificado por um endereço IP único Os grupos multicast são formados por um conjunto de zero ou mais máquinas, que podem estar espalhadas ao longo de redes fisicas separadas A entrega de um datagrama é realizada com as mesmas caractensticas de confiabilidade que os datagramas umcast regulares IP, o que sign1fica que não ha garantia contra perda, retardo, duplicação ou entrega fora de ordem para qualquer membro do grupo [Corn91]_
Os membros de um grupo são dinâmicos. estações podem entrar ou deixar grupos a qualquer momento [Dee89] ão há restrições para o número de membros de um grupo, e uma estação pode participar de mais de um grupo simultaneamente. Penencer a um grupo determma se o host recebera os datagramas enviados para aquele grupo mullfcast, sendo permitido que uma estação envie daragramas para um grupo mesmo sem pertencer a ele
Um grupo pode ser permanente ou transiente Grupos permanentes são aqueles que possuem um endereço conhecido, fixo. Apenas o endereço é permanente, os membros deste
Capitulo 3 -Redes TCP/IP
grupo não são permanentes, e num dado momento um grupo permanente pode ter qualquer número de membros, inclusive zero. Os endereços com difusão seletiva IP que não são reseJVados para algum grupo permanente estão disponíveis para atribuição dinâmica de grupos temporários que existem somente enquanto possuem membros. Estes grupos são criados quando necessário, e descartados quando o número de membros atinge zero ou seu tempo de vida term1 na.
Alguns dos grupos mais conhecidos estão na tabela 3.3 (Sem97]:
Endereço Grupo
224 0.0.1 Todos os sistemas nesta sub-rede
224.0.0.2 Todos os roteadores nesta sub-rede
224.0.0.4 Todos os roteadores DVMRP
224.0.0.5 Todos os roteadores OSPF
224 0.1.11 Audio IETF
224.0 1.12 Vídeo IETF
224.0.1 7 AUDlONEWS
224.0.1 16 MUSIC-SERVICE
Tabela 3.3-Endereços de alguns grupos multicast conhecidos
O mu/ticast IP pode ser utilizado em um rede fisica simples ou através da Internet. Neste último caso, os datagramas são transmitidos por roteadores com capacidade de trâfego multicast (também conhecidos como mrouters) [Dee89]. Uma estação transmite um datagrama multicast como uma difusão multicast de rede local. Se o datagrama possuir um Tempo-de-vida maior que um1 o roteador multicczst ligado à rede transmite o pacote para
todas as outras redes que possuem membros do grupo. Se estes membros forem atingíveis dentro do Tempo-de-vida, o roteador multicast pertencente à rede que o receber, completa a entrega transmitindo o datagrama como multicast local.
Capitulo 3 - Redes TCP/IP
3.3.1
-Internet Group Management
Protocol
O protocolo de gerenciamento de grupos IGMP (Internet Group Management Protocol) [Fen97] é usado por roteadores multicast (consultando) e máquinas (informando) para comunicarem participações em grupos em uma rede. Os protocolos de roteamento multicast, que será visto mais adiante, atuam nas interligações de redes, enquanto o IGMP atua dentro de cada rede com capacidade de manipular tráfego multicast, como pode ser
visualizado na figura 3 8.
t
IGMP~1
--1llll • IGMP
Figura 3.8- Atuação do protocolo IGMP
Como o ICl\'lP (lntemet Control Message Protocol) [Con98], o lGMP é uma parte integrante do IP, sendo um requisito básico de implementação a todas as estações que desejem enviar e receber pacotes multicast. As mensagens IGMP são encapsuladas em
datagramas lP, com um número de protocolo IP (este paràmetro foi visto na seção 3 .1.1
-formato dos Datagramas) igual a 2 As mensagens importantes, do ponto de vista da
Capitulo 3 - Redes TCPIIP
o
8 16Tipo Tempo máL Soma de verificação
de resp.
Endereço de grupo
Figura 3.9 -Fonn.:tto da mensagem IGMP
Há três formas básicas para o preenchimento do campo Tipo: Oxtl -consulta a membros.
A consulta a membros possui dois subtipos de respostas:
consulta geral - para o roteador informar-se sobre quais grupos têm membros em sua rede;
consulta sobre grupo específico- para o roteador informar-se se há membros de um determinado grupo em sua rede.
O diferencial entre as mensagens de consulta é o campo endereço de grupo que será visto a seguir~
Oxl6-Resposta de membro (versão 2 do IGMP);
Ox17 - Saída de grupo.
Há um outro tipo de mensagem reconhecida pelo IGMP:
Ox12 - Resposta de membro (para compatibilidade com a versão 1 do IGMP).
O campo Tempo máximo de resposta só tem significado em mensagens de consulta a membros (tipo Oxll ), onde especifica o período máximo permitido para o envio de uma mensagem de resposta. O valor é em unidades de décimos de segundo. Nas demais mensagens, este campo é ajustado para zero pelos remetentes e é ignorado pelos receptores
O campo Soma de verificação contém uma soma computada com o mesmo algoritmo usado para o IP, visto anteriormente. Este campo deve ser calculado e preenchido para a transmissão. Na recepção, ele é examinado antes do processamento da mensagem.
Finalmente, o campo Endereço de grupo em uma mensagem de consulta a membros contém apenas zeros quando for uma consulta geral . Quando a consulta for sobre grupo espedfico, o endereço do grupo consultado estará neste campo. Em uma mensagem
Cap1tulo 3-Redes TCP/lP
do tipo resposta de membro, uma máquina informa o grupo que está participando Na
mensagem de saída de grupo, a máquina informa neste campo o grupo ao qual pretende desassocíar -se
O IGMP permite a um roteador perceber que não há mais membros de um determinado grupo temporário em sua rede, podendo assim, enviar uma mensagem ao proximo roteador em direção à fonte, solicitando que não envie mais tráfego.
3.3.2 -Algoritmos
de Roteamento
Multicast
Os roteadores que executam protocolos mullicast utilizam algoritmos de roteamento para a definição dos caminhos entre as redes, por onde as mensagens seguirão até os destinos Com o uso dos algoritmos, os protocolos de roteamento mu/ucast constróern
árvores de entrega dos pacotes buscando alcançar todos os membros dos grupos de
recebedores. .-1\lguns algoritmos são apresentados a seguir, onde poderão ser vistas as
vanragens. desvantagens e a evolução surgida dentre eles. Há uma abordagem abrangente
dos algoritmos aqui apresentados em [Sem97]
3.3.2
.
1
-
Dilúvio
De todos os algoritmos aqui apresentados, o Dilúvio é a técnica mais simples para
efetuar a entrega mult1cas1 É um algoritmo de roteamento estático, onde um roteador que o
execute, ao receber um novo pacote, o replica e envia em todas as interfaces, exceto aquela por onde recebeu. Caso seja um pacote já recebido, o roteador simplesmente o descarta.
Para permitir o controle dos pacotes recebidos, a origem insere um número de identificação sequencial em cada pacote que transmitir. Ao roteador cabe manter uma lista, por origem, de pacotes recebidos. Um contador limita o tamanho máximo desta lista Caso