3. A Rede Virtual MBone

O MBone é uma rede virtual rodando sobre a Internet. Esta rede é composta de sub-redes que suportam difusão seletiva, denominados ilhas, conectadas umas as outras através de enlaces ponto-a-ponto virtuais. Cada uma das ilhas é composta por uma ou mais redes locais conectando um número de nodos clientes e por um nodo que implementa o mrouted - multicast routing daemon, denominado mrouter, que são os roteadores de difusão seletiva.

A comunicação entre estes roteadores é realizada utilizando o conceito de túneis, enlaces virtuais ponto-a-ponto entre os roteadores, que possibilitam a transmissão de pacotes de difusão seletiva entre os roteadores que não suportam esta forma de endereçamento, encapsulando pacotes de difusão seletiva dentro de pacotes unicast IP. É denominado túnel a conexão entre estes roteadores [ERI 94].

Os mrouters têm a responsabilidade de replicar e distribuir os quadros de dados de difusão seletiva para os túneis que conduzem a hosts participantes do grupo e para a rede local, caso exista um host membro do grupo nela. A topologia de mrouters do MBone é realizada de maneira a possibilitar uma distribuição de pacotes eficiente sem congestionar nenhum nodo ou enlace de rede inadequadamente. Desta forma, utilizando roteamento baseado em difusão seletiva IP, é possível conseguir comunicações em tempo real sobre redes IP WAN.

Quando um pacote de difusão seletiva é enviado por um cliente, que o coloca na rede local, ele é apanhado pelo mrouter da sub-rede. O roteador irá consultar sua tabela de roteamento e transmitir o pacote para os túneis correspondentes. No outro lado do túnel, o outro roteador receberá o pacote e consultará sua tabela de roteamento para decidir se o pacote deve ser enviado para algum outro túnel, verificando também se há algum cliente em sua sub-rede que está inscrito neste endereço de difusão seletiva e, caso houver, colocando-o na sub-rede para ser recebido pelo cliente. O funcionamento da difusão seletiva é descrito em detalhes no capítulo 2.

Figura 3.1. - Principais túneis do MBone no Brasil

O MBone possui uma topologia em malha e em árvore. Entre os maiores provedores de serviços da Internet as conexões formam uma topologia em malha, formando os backbones principais e enlaces de reserva. Nas extremidades, a topologia é geralmente em árvore. Entre os continentes existem um ou dois túneis para a interligação [KUM 95]. Na figura 3.1, acima, podem ser vistos os principais túneis do MBone no Brasil. Além destes túneis, existem também túneis secundários, para laboratórios das instituições ou para outras organizações de menor porte nas cidades. Na figura 3.2, a seguir, são apresentados os principais enlaces mundiais [CAS 94].

Figura 3.2. - Os maiores roteadores e enlaces do MBone no mundo

3.1Histórico

O conceito de endereçamento com difusão seletiva para comunicações de grupo foi inventado por Steve Deering em sua tese de doutorado na Stanford University, USA, e depois desenvolvido na Xerox PARC. O projeto e desenvolvimento do MBone foi ajudado por Van Jacobson e seu grupo no Lawrence Berkely Labs (LBL) e Steve Casner no Information Science Institute (ISI), além de muitos outros engenheiros [KUM 95].

O MBone foi criado como uma rede experimental de difusão seletiva para o protocolo IP, desenvolvido e testado na rede de pesquisa DARTnet. Na rede da DARTnet eram transmitidas semanalmente conferências para seus pesquisadores, porém, a primeira grande transmissão MBone ocorreu somente em março de 1992, durante o encontro do Internet Engineering Task Force (IETF) em San Diego, USA, quando muitas sessões do encontro foram transmitidas em áudio utilizando transmissões de pacotes de difusão seletiva do site IETF para participantes de 20 sites em três continentes, abrangendo 16 zonas horárias [CAS 92]. O evento foi uma demonstração da tecnologia desenvolvida na rede DARTnet, e tem grande significado pelo tamanho da topologia da rede de difusão seletiva IP envolvida.

Foram transmitidas todas as sessões gerais do encontro e também algumas sessões de grupos de trabalho. Os participantes remotos tinham a possibilidade de falar, participando das discussões e fazendo perguntas, e embora a transmissão não fosse perfeita, foi razoável em ambas as direções. A transmissão do evento foi possível graças a utilização de difusão seletiva IP implementado nos roteadores e hosts, onde uma cópia simples é enviada de cada pacote, sendo replicada apenas quando houver um braço na árvore lógica dos destinos. Se fosse necessário enviar uma cópia de cada pacote para cada destino, a largura de banda e processamento requerido seriam proibitivos.

No evento foram utilizados equipamentos e softwares já testados na DARTnet. No site do IETF e na maioria dos sites remotos foi utilizada a ferramenta VAT, Visual Audio Tool, desenvolvida por Van Jacobson e Steve McCanne, do Lawrence Berkeley Laboratory. Foi usado a velocidade de 64 kbps para áudio codificado com PCM, cada pacote contendo 180 amostras de voz PCM, que correspondem a um intervalo de 22,5 milisegundos e uma velocidade de 44,4 pacotes por segundo. Como o pacote possui um overhead de 32 bytes, não contando o cabeçalho MAC, a velocidade de dados possui um pico de 75 kbps. Porém, como em intervalos de silêncio os pacotes não são transmitidos, a velocidade dos dados média é menor que os 75 kbps referidos [CAS 92].

O MBone utiliza o protocolo UDP na camada de transporte. Como este protocolo não garante ordenação dos datagramas e filtro de duplicações, necessárias à transmissão, é necessário o emprego de um protocolo de outro nível para suprir estas deficiências. Na transmissão de março de 1992 foi utilizado o cabeçalho do Network Voice Protocol (NVP­II) para os pacotes de dados. Neste cabeçalho, um campo de timestamp era incrementado em todos intervalos de 22,5 milisegundos (equivalentes a um pacote), inclusive quando os pacotes não eram transmitidos (durante momentos de silêncio), o que fornecia sequenciação e detecção de duplicação em pacotes com tempo de vida de 20 segundos. Um campo número de seqüência, incrementado a cada pacote transmitido, possibilitava a detecção de pacotes perdidos contra os pacotes não transmitidos durante o silêncio.


Figura 3.3. - Formato dos pacotes de áudio

O cabeçalho NVP é eficiente, possuindo apenas 32 bits, mas tem alguns campos que são muito pequenos para suportar os requisitos atuais. O cabeçalho do NVP é apresentado na figura abaixo.


Figura 3.4. - Formato do cabeçalho NVP

Poucos roteadores na Internet implementavam roteamento de difusão seletiva IP. Entre eles, porém, estavam os roteadores da rede experimental DARTnet, que utilizavam o Distance Vector Multicast Routing Protocol (DVMRP), o que possibilitava para os usuários desta rede realizarem suas teleconferências semanalmente. Para o evento, porém, era desejado atingir sites que não suportassem difusão seletiva IP. Assim, a fim de suportar difusão seletiva entre redes separadas por roteadores unicast, que não suportavam difusão seletiva IP, foram utilizados mrouters, que implementavam o conceito de túneis, estabelecendo enlaces virtuais ponto-a-ponto entre os mrouters. Para transmitir um pacote de difusão seletiva através de um túnel, o roteador de difusão seletiva modificava o pacote na opção IP Loose Source Route do cabeçalho IP, colocava o endereço destino de difusão seletiva na rota de origem e o endereço unicast do roteador no campo destination address. O pacote era tratado com um pacote normal unicast entre os roteadores e sub-redes intermediárias ao longo do túnel, e o roteador ao final dos túneis restaurava o endereço destino de difusão seletiva e removia a rota de origem antes de remeter o pacote.

Assim, foi utilizado para o evento a rede DARTnet como backbone e uma rede de túneis que estabeleciam os enlaces virtuais para os sites externos a DARTnet. Foram utilizados enlaces primários e também enlaces de reserva para o caso de ocorrerem falhas nos enlaces primários ou na DARTnet, associando diferentes métricas para os diferentes enlaces. A figura a seguir apresenta a topologia da transmissão do encontro do IETF de 1992 [CAS 92].

Figura 3.5. - Topologia do MBone no IETF de março de 1992

Desde o evento, o MBone tem experimentado um enorme crescimento, de forma exponencial. Como foi dito, no encontro do IETF em março de 1992 vinte sites participaram do evento. Dois anos mais tarde, no encontro do IETF em Seattle, 567 hosts em quinze países receberam os dois canais paralelos (áudio e vídeo) e participaram das discussões [ERI 94]. Em 1995, existiam na ordem de 1700 roteadores na Internet que possibilitavam MBone. Atualmente, existem mais de 20000 usuários do MBone, distribuídos em 30 países [TRE 96]. A figura a seguir indica o crescimento do MBone, em termos do número de sub-redes na Internet que suportam MBone [DEE 95b].

Figura 3.6. - Crescimento do MBone em número de sub-redes

Atualmente, a maioria das redes locais do MBone são redes Ethernet, mas existem também alguns outros tipos de redes, como FDDI e enlaces ponto-a-ponto [DEE 94]. Dezenas de eventos são transmitidos, abrangendo encontros, como o do IETF; seminários, como o PARC&MICE, Microsoft, Lotus; informações públicas, como lançamentos da NASA, imagens de tempo de satélites, visitas importantes de autoridades; diversão, como filmes experimentais, estações de rádio e TV de diversos países, etc.

O MBone sofreu diversas modificações desde o IETF de San Diego: o esquema de tunneling passou a usar encapsulamento IP, ao invés da opção LSRR; o protocolo de roteamento de difusão seletiva DVMRP passou por diversos avanços, como a implantação do esquema de prunning, que será descrito no item 3.4; novos protocolos foram e estão sendo desenvolvidos, como o MOSPF e o PIM; e muitas outras.

Muitos produtos no mercado já suportam difusão seletiva IP, como algumas versões dos sistemas operacionais Solaris 2.x, da SUN; Irix, da SGI; Linux; e alguns produtos da Cisco, da BayNetworks, da 3Com. Além destes, muitos outros produtos possuem patches para difusão seletiva IP, incluindo o SunOS 4.x, da SUN;o HP-UX, da HP;o Ultrix e o OSF1, da DEC. Assim, como muitos roteadores disponíveis no mercado suportam difusão seletiva, e quase todos os sistemas operacionais vem equipados com suporte a difusão seletiva, o MBone está se transformando de um backbone virtual para um semi-real, que irá se tornar um futuro backbone real e permanente.

3.2. Mecanismos de Tunneling

Para enviar um pacote através de um túnel, os pacotes devem ser empacotados dentro de pacotes IP unicast, de modo a serem compreendidos pelos nodos físicos pertencentes a um túnel. O MBone utiliza duas formas de tunnelling dos pacotes de difusão seletiva IP. Uma, utilizando a opção IP Loose Source and Record Route (LSRR), criando o chamado source routed tunnel. Outra, utilizando encapsulamento IP, denominada encapsulated tunneling.

A forma LSRR foi utilizada nas primeiras implementações de mrouters, até março de 1993 [CAS 95]. Os roteadores modificavam o datagrama de difusão seletiva originário de um cliente acrescentando a opção IP LSRR para o cabeçalho do pacote IP, movendo o endereço destino de difusão seletiva para a source route e modificando o endereço IP destino para o endereço unicast do mrouter no outro lado do túnel. No final do túnel, o roteador restaurava o endereço de difusão seletiva destino original e removia a source route antes de enviar o pacote adiante.

Esta forma de implementação apresentava algumas deficiências. Pacotes com opções IP, incluindo LSRR, são geralmente enviados para a CPU principal para serem tratados, o que não acontece com modernas tecnologias de roteamento, que tratam os pacotes nas placas de interfaces sempre que possível [ERI 94]. O grande problema ocorreu durante o encontro do IETF em novembro de 1992, em Washington, quando ocorreram problemas com a NFSnet que foram atribuídos ao tráfego da difusão seletiva originário do encontro do IETF.

O evento estava gerando dois canais de áudio de aproximadamente 75 kbps e dois canais de vídeo de aproximadamente 130 kbps, representando um tráfego de 400 pacotes por segundos sendo enviados do site do IETF para o roteador de Cornell. Este roteador, por sua vez, processava um número de túneis tal que o tráfego era acima de 1000 pacotes por segundo, pacotes que tinham que ser tratados pela CPU principal. Adicionado a isso, um grande número de mensagens ICMP unreachable foram geradas, levando a CPU a apresentar deficiências quando atualizações de roteamento regulares eram acrescentadas.

Para contornar estes problemas durante o evento, um canal de vídeo do evento foi desabilitado para diminuir a carga e algumas ineficiências das atualizações de roteamento foram fixadas, como as rotas derivadas do EGP (External Gateway Protocol) que foram agregadas a mensagens de atualização BGP (Border Gateway Protocol). E, por fim, foi estudado e implantado no MBone o uso de encapsulamento real ao invés da opção LSRR para a tunneling.

Neste novo método o pacote com difusão seletiva original é colocado dentro da parte de dados de um datagrama IP normal, que é endereçado para o mrouter no outro lado do túnel, com o campo protocol configurado para 4, indicando que o próximo protocolo é IP. Este roteador, por sua vez, retira o encapsulamento e envia o datagrama adiante. Esta forma de implementação é utilizada na maioria dos túneis na Internet hoje, que são, porém, compatíveis com os roteadores que usam source routed [KUM 95].

3.3. Métrica e Threshold

Cada túnel possui associado a ele uma métrica, que especifica o custo de roteamento que é usado no Distance Vector Multicasting Routing Protocol (DVMRP) para configuração de túneis primários ou túneis reserva. A figura a seguir exemplifica uma topologia onde existem túneis primários e secundários:



Figura 3.7. - Rede com túneis de diferentes métricas

Em túneis primários, a métrica associada é 1; em túneis reserva, a métrica possui valor superior. Assim, quando um roteador recebe um pacote de um de seus clientes, ele analisa o caminho de menor custo para cada um dos túneis associados a ele e envia o datagrama pelo caminho de menor custo. O túnel reserva é utilizado quando um dos túneis primários caem. Na figura acima, pode ser visualizada uma rede que possui túneis com diferentes métricas. Em situações normais, mensagens do mrouter R1 para o R2 serão enviadas através do túnel que os interliga diretamente. Se, porém, ocorrer uma falha neste túnel, as mensagens serão enviadas pelos túneis que são ligados ao roteador R3. O protocolo DVMRP, entretanto, é lento para propagação de mudanças na topologia da rede, e mudanças rápidas podem ocasionar problemas.

Além da métrica, os túneis possuem também um threshold associados a eles, a fim de limitar o escopo de distribuição dos pacotes de difusão seletiva. O threshold é o time-to-live mínimo (TTL) que um datagrama precisa para ser transmitido por um dado túnel. Cada pacote que é enviado de um cliente para a rede possui um TTL específico, que é decrementado em uma unidade a cada mrouter que o pacote passa. Se o TTL de um pacote apresentar um valor menor que o threshold do túnel pelo qual o protocolo DVMRP deseja enviar o pacote, o pacote é descartado. O campo TTL de um pacote pode ser também decrementado por grandes valores sobre um esquema de thresholding global fornecido para limitar a difusão seletiva para algumas regiões ou sites se desejado [MAC 94][KUM 95].

Pelo esquema padrão, quando é criado um grupo de difusão seletiva, os datagramas de difusão seletiva IP são enviados com um TTL de 1, que impede que eles sejam enviados para além da sub-rede local [KUM 95]. Para permitir uma distribuição maior, deve ser especificado o novo valor para o TTL do grupo.

Por exemplo, o valor 16 para o campo TTL de um grupo limita o tráfego da difusão seletiva para redes dentro de organizações, enquanto que os valores de 127 ou 255 são usados para quando é desejado enviar os pacotes com difusão seletiva para a rede MBone da Internet inteira. Valores entre 16 e 127 também são permitidos. Estes números não são selecionados randomicamente, são reservados para o uso restrito do MBone e possuem padrões que são geralmente seguidos para limitar o escopo das transmissões, valores relacionados aos thresholds geralmente utilizados nos túneis[KUM 95].

Para o encontro do IETF de novembro de 1992, foram convencionados TTLs para serem utilizados nas aplicações, que são mostrados na tabela 3.1. A coluna TTL define o valor de TTL original a ser usado por cada aplicação e a coluna threshold especifica o valor configurado para o threshold de um mrouter necessário para permitir a passagem dos pacotes da aplicação correspondente e das aplicações acima na tabela.

Tabela 3.1. - TTLs e Thresholds utilizados no IETF de Novembro de 1992

velocidade pico

TTL

threshold

IETF chan 1 low-rate GSM audio

16 kbps

255

224

IETF chan 2 low-rate GSM vídeo

16 kpbs

223

192

IETF chan 1 PCM audio

70 kbps

191

160

IETF chan 2 PCM vídeo

70 kpbs

159

128

IETF chan 1 vídeo; nv ou ivs

128 kbps

127

96

IETF chan 2 vídeo; nv ou ivs

128 kbps

95

64

local event audio PCM

70 kpps

63

32

local event vídeo; nv ou ivs

128 kbps

31

1

3.4. Truncated Broadcast e Prunning

Como foi visto, através do uso do campo TTL dos datagramas e do threshold, configurado para cada túnel, é possível estabelecer um controle sobre a distribuição dos pacotes com difusão seletiva pela Internet. Existe, porém, uma outra forma de limitar esta distribuição, que está sendo hoje em dia utilizada em muitos túneis: o uso de prunning (poda).

Nas primeiras fases do MBone, os pacotes eram roteados utilizando apenas o controle oferecido pelo campo TTL dos pacotes, e enquanto os pacotes tinham o valor mínimo estabelecido pelo campo eram transmitidos para todos roteadores de difusão seletiva vizinhos. O único controle por interesse que havia era feito nos nodos folhas da árvore de difusão seletiva, onde o mrouter local somente colocava o datagrama na rede local se um host cliente participava do grupo do datagrama com difusão seletiva. Eram os chamados túneis truncados, numa forma de transmissão denominada truncated broadcast. Como resultado, muitos nodos mrouter que não expressavam interesse em receber o tráfego MBone associado a um certo grupo de difusão seletiva recebiam todo um tráfego desnecessário, consumindo uma grande largura de banda desnecessariamente. Assim, foi estudado um mecanismo mais eficiente, onde o interesse em receber pacotes de um grupo fosse considerado, criando os chamados túneis prunned (podados).

Prunning em difusão seletiva é também denominado difusão seletiva verdadeira, pois os pacotes somente são enviados para sites ou mrouters que tenham expressado interesse no grupo, o que é implementado através de mensagens IGMP [KUM 95]. Quando um mrouter recebe um pacote que nenhum cliente ou mrouter vizinho participa do grupo, ele descarta o pacote e envia um sinal para o roteador no nível acima na árvore de difusão seletiva (o mrouter do qual ele recebeu o datagrama) informando que não deseja os pacotes com aquele endereço. O roteador acima interpreta a mensagem e para de enviar os pacotes por aquele túnel. Se, posteriormente, o mrouter detecta um cliente que participa do grupo de difusão seletiva que foi eliminado, ele envia um sinal para o roteador do nível acima informando que deseja receber os pacotes novamente, e a transmissão é reiniciada normalmente, desde que o controle fornecido pelo valor do campo TTL seja respeitado. Este esquema é utilizado em muitos túneis hoje em dia, sendo suportado pelos roteadores de difusão seletiva DVMRP de versões 3.x e superiores.

3.5. Protocolos

3.5.1 Protocolos de Roteamento de Difusão Seletiva

Como o uso de difusão seletiva não é compreendido em todos os roteadores na Internet, a topologia do MBone difere da topologia da Internet. Com isso, os roteadores de difusão seletiva precisam executar um protocolo para descobrir sua própria topologia, um protocolo de roteamento, a fim de identificar para onde enviar os datagramas de difusão seletiva. O protocolo mais utilizado no MBone é o Distance Vector Multicasting Routing (DVMRP). Porém, em algumas partes do MBone, os roteadores usam protocolos de roteamento de difusão seletiva diferentes, especialmente o Multicast Open Shortest Path First (MSOPF) e o Protocol Independent Multicasting (PIM), que interoperam com os roteadores DVMRP graças a implementação de um subconjunto do DVMRP. A seguir serão apresentados estes protocolos de roteamento de difusão seletiva.

3.5.2 Distance Vector Multicasting Routing (DVMRP)

Muitos esquemas de roteamento tem sido proposto e desenvolvido para rotear os pacotes de difusão seletiva no MBone. O primeiro mecanismo de roteamento foi desenvolvido por Steve Deering, da Xerox PARC, e é chamado Distance Vector Multicasting Routing Protocol (DVMRP). Uma versão anterior do DVMRP é especificada em [DEE 88a]. A versão utilizada nos mrouters, entretanto, é diferente da versão especificada neste documento, possuindo diferente formato do pacote, diferente formato do túnel, tipos de pacotes adicionais, etc.

O roteador de difusão seletiva baseado no DVMRP mantém o conhecimento topológico através de um protocolo de roteamento distance-vector, como o Routing Information Protocol (RIP) [MAL 94], sobre o qual é implementado um algoritmo de transmissão de difusão seletiva chamado Truncated Reverse Path Broadcasting.

3.5.2.1 Hierarchical Distance-Vector Multicast Routing

Os roteadores DVMRP tratam a topologia do MBone como um domínio único. Cada roteador mantém uma entrada na tabela de roteamento para cada sub-rede no MBone e troca mensagens de roteamento periodicamente com cada um de seus vizinhos identificando todas as sub-redes. Como o número de sub-redes tem crescido exponencialmente, o custo de roteamento cresce também exponencialmente, e os recursos de memória e processamento dos atuais roteadores DVMRP ficarão insuficientes.

Este problema já é conhecido no roteamento unicast, e tem como solução o uso de roteamento hierárquico. No roteamento hierárquico, o topologia é particionada logicamente em um número de domínios separados, cada um executando sua própria instância do protocolo de roteamento. Outro protocolo de roteamento, ou mesmo outra instância do mesmo protocolo, é utilizado para o roteamento entre domínios. A informação da topologia de cada domínio é mantida somente pelo protocolo de roteamento daquele domínio, enquanto que o protocolo inter-domínio mantém informações somente sobre as interconexões dos domínios, não tendo conhecimento das topologias internas. Com a aplicação de particionamento hierárquico recursivamente, é possível realizar o roteamento de uma grande área topológica com pequena quantidade de informação topológica mantida em cada roteador.

Existe uma proposta do uso de roteamento hierárquico para o MBone, proposta por Thyagarajan e Deering em [DEE 95a], usando inicialmente hierarquia de dois níveis de regiões contendo sub-redes. No roteamento com difusão seletiva dentro das regiões seria utilizado uma série de protocolos, inclusive o DVMRP, enquanto que no roteamento inter-regiões seria utilizado uma versão modificada do DVMRP que calcularia rotas de difusão seletiva entre as regiões ao invés de entre as sub-redes.

O uso de roteamento hierárquico traz uma série de outros benefícios além da diminuição de informação topológica armazenada por cada roteador. Diferentes protocolos podem ser utilizados dentro das regiões, que utilizarão uma interface clara entre eles, eliminando os problemas gerados pela mistura de dois protocolos de roteamento e permitindo que novos protocolos sejam testados e desenvolvidos. Mudanças da topologia, como a falha de um enlace ou roteador, são detectados somente entre os roteadores da mesma região, da mesma forma que mudanças na topologia das interconexões das regiões são limitadas aos roteadores inter-regiões, o que é particularmente benéfico para o uso do DVMRP, que pode demorar longo tempo para detectar as mudanças topológicas. E, por fim, o limite de diâmetro máximo de topologia, imposto por alguns protocolos de roteamento, como o DVMRP, pode ser relaxado, já que diferentes instâncias do protocolo são utilizadas para diferentes partes da rede e o limite se relaciona somente com estas partes.

4.5.1.2 Multicast Open Shortest Path First (MOSPF)

Existe também uma extensão de difusão seletiva IP para o protocolo de roteamento IP Open Shortest Path First (OSPF), denominada Multicast Open Shortest Path First (MOSPF) [MOY 94][MOY 94a]. O protocolo OSPF é baseado no estado dos enlaces, diferente do RIP, que é baseado somente na contagem dos nodos. Uma rede de roteadores rodando MOSPF podem enviar pacotes de difusão seletiva IP diretamente, enviando não mais que uma cópia por cada enlace, e sem a necessidade de túneis.

O MOSPF transmite os datagramas IP de difusão seletiva da origem para os vários membros do grupo sem formar laços, gerando uma árvore. Esta árvore tem como raiz o nodo origem do datagrama, e todos os braços terminam em membros do grupo. Seguindo a filosofia da difusão seletiva, o datagrama é replicado apenas quando surge uma divisão, um braço, na árvore.

Este esquema de roteamento, onde o caminho dos datagramas depende da origem e dos destinos dos datagramas, já que a árvore possui raiz na origem, é denominado source/destination routing. Ele é diferente da maioria dos algoritmos de roteamento unicast, incluindo o OSPF, que se baseiam somente no destino do datagrama para o roteamento. A necessidade de considerar a origem para tomar as decisões do roteamento causa maior quantidade de cálculos de roteamento, porém resulta em melhores caminhos em termos de utilização da rede e menor retardo para membros individuais do grupo. O protocolo, porém, não necessariamente otimiza o uso da rede como um todo.

A figura abaixo apresenta uma rede onde é realizada uma transmissão de um datagrama originado do nodo O para os membros do grupo G, onde o caminho dos datagramas está indicado com as flechas. Se fosse, porém, utilizado o caminho que otimizasse mais a rede, o datagrama seria transmitido do roteador R4 para o roteador R2, onde seria enviado para a rede local e para o roteador R3, que o transmitiria para as redes locais D e E.




Figura 3.8. - Transmissão de um datagrama no MOSPF

No MOSPF, assim como no OSPF, os datagramas são marcados com a sua classificação do Type of Service (TOS), baseada em um dos cinco valores mutuamente exclusivos minimize delay, maximize throughput, maximize reliability, minimize monitary cost e normal service. O caminho do datagrama de difusão seletiva no MOSPF pode variar de acordo com a classificação TOS utilizada [MOY 94]. Por exemplo, um tráfego de uma difusão seletiva sensitivo ao retardo pode seguir rotas diferentes de uma aplicação de difusão seletiva de alta vazão. A classificação TOS no protocolo MOSPF é, assim como no OSPF, opcional, e roteadores que a suportam podem ser misturados livremente como os que não a suportam.

Os roteadores MOSPF podem ser misturados com roteadores OSPF sem difusão seletiva. Quando isso é feito, todos os roteadores irão interoperar no roteamento de datagramas unicast, que não é afetado pelos roteadores MOSPF. Esta possibilidade de misturar ambos tipos de roteadores habilita a fase de introdução da capacidade de difusão seletiva em um rede. O MOSPF suporta todos os tipos de rede que são suportadas pelo protocolo OSPF: redes com difusão seletiva (como Ethernet), redes ponto-a-ponto e redes de multiacesso que não suportam difusão seletiva. Estas últimas, porém, não poderão possuir membros locais.

O MOSPF possui algoritmos para transmitir datagramas de difusão seletiva entre áreas OSPF e um algoritmo para importar datagramas de difusão seletiva de outro Sistema Autônomo. O compartilhamento de carga, enviando datagramas através de múltiplos caminhos com mesmo custo, não é suportado, já que entre a origem de um datagrama e um particular membro do grupo deve existir apenas um caminho. Isto ocorre pela natureza do roteamento da difusão seletiva: a fim de evitar replicação dos datagramas, cada roteador deve conhecer por qual interface um dado datagrama será recebido, e deve descartar os datagramas recebidos por outras interfaces.

3.5.1.2.1 Mecanismo do protocolo

O protocolo MOSPF utiliza o protocolo IGMP para estabelecer a localização de membros de grupos, enviando mensagens IGMP do tipo Host Membership Query e recebendo mensagens Host Membership Report como resposta. Em posse destas informações , o roteador MOSPF as distribui por todo o Sistema Autônomo através do envio de um novo tipo anúncio de estado de enlace, o group-membership-LSA, que indica os pedaços do mapa da rede que possuem membros do grupo.

Utilizando o mapa, o roteador MOSPF calcula, na primeira vez que um datagrama de difusão seletiva com uma dada origem e destino é recebido, a árvore com raiz na origem de menor caminho para o datagrama. As ramificações da árvore que não possuem membros são eliminadas, de modo que o datagrama não é enviado para onde não é necessário. O resultado deste cálculo da árvore é então armazenado para uso nos datagramas do grupo em questão que forem recebidos posteriormente.

O cálculo de roteamento do MOSPF é muito similar ao cálculo do roteamento unicast utilizado no OSPF, ambos utilizando o algoritmo Dijkstra para calcular as árvores de menor caminho. No MOSPF, entretanto, existem potencialmente muitas diferentes árvores calculadas, possivelmente uma para cada combinação da origem do datagrama e destino. Assim, existem mecanismos para garantir que, dado datagrama, todos os roteadores MOSPF calculem a árvore de menor caminho absolutamente iguais, o que é essencial para a correta transmissão de datagramas de difusão seletiva.

Para transmissões além do limite de uma área OSPF, novos mecanismos são necessários. Isto acontece porque um mapa de uma área OSPF não é visível externamente a aquela área, complicando a construção das árvores baseadas na origem, além de que um membro de um grupo não pode ser livremente anunciado além dos limites da área.

As áreas OSPF podem ser vistas como organizadas em uma hierarquia de dois níveis, onde o nível superior corresponde à área do backbone. Para distribuir os group-membership-LSAs MOSPF, o grupo é anunciado para a área do backbone, de forma que o backbone possua completo conhecimento dos grupos de todas as áreas. Entretanto, a informação de associação aos grupos não é anunciada de volta para as áreas que não são backbone, que desta forma não possuem conhecimento dos grupos das outras áreas. Isso reduz o tamanho do banco de dados dos estados dos enlace da área. Para compensar, o conceito de roteadores recebedores de anúncios de difusão seletiva é introduzido. Com o mecanismo, tais roteadores recebem todos os datagramas de difusão seletiva, independente do destino. Assim, para habilitar a entrega dos datagramas além dos limites da área, todos roteadores MOSPF conectando áreas não-backbone ao backbone se anunciam como recebedores de anúncios de difusão seletiva para as áreas não-backbone.

O cálculo de caminhos para os datagramas que ultrapassam os limites do Sistema Autônomo é realizado de forma análoga. Quando um datagrama é originado de um outro Sistema Autônomo, sua vizinhança é aproximada pelos AS-external-LSAs. Adicionalmente, roteadores desejando enviar datagramas para outro Sistema Autônomo se anunciam como recebedores de anúncios de difusão seletiva, e recebem assim os datagramas independentes dos destinos destes.

3.5.1.2.2. O uso de MOSPF no MBone

No MBone, é freqüentemente utilizado túneis entre roteadores de difusão seletiva, transmitindo os datagramas encapsulados dentro de datagramas unicast. Entretanto, o esquema de tunneling não é sempre eficiente, podendo resultar em múltiplas cópias de um datagrama sendo transmitidas por um mesmo segmento. Na figura 3.8, por exemplo, se o roteador R3 não possuísse capacidades de difusão seletiva, para enviar o datagrama originado de O para os membros das redes D e E, os dois túneis teriam que ser configurados vindos do roteador R4, o que resultaria em duas cópias idênticas sendo transmitidas por um mesmo segmento de rede (no exemplo, o segmento entre R4 e R3).

A necessidade de túneis em uma rede, e como conseqüência sua ineficiência, é removida com a introdução de roteadores com capacidades de roteamento de difusão seletiva na rede. Assim, algumas implementações do protocolo MOSPF, como a da Proteon Inc., por exemplo, incluem a implementação do protocolo DVMPR, utilizado na maioria dos roteadores pertencentes ao MBone, e possibilitam que as informações de roteamento sejam passadas entre os dois protocolos de roteamento de difusão seletiva. Desta forma, os Sistemas Autônomos executando o MOSPF podem fazer parte do MBone, sem a necessidade de criar túneis do DVMRP sobre eles nem túneis do MOSPF sobre o resto da Internet [MOY 94].

O MOSPF possui como vantagem sobre o DVMRP um aumento de estabilidade. A tecnologia de estado dos enlaces do MOSPF converge mais rapidamente e com menos inclinação a laços durante o tempo de convergência que o DVMRP, que sofre dos mesmos problemas que o protocolo RIP quando em face de mudanças na topologia de uma rede com topologia redundante.

3.5.1.3. Protocol Independent Multicasting (PIM)

Os mecanismos de roteamento de difusão seletiva anteriores são apropriados para uso em regiões onde os grupos possuem muitos participantes ou em redes onde há vasta largura de banda disponível. Porém, quando membros de um grupo e transmissores para este grupo estão distribuídos esparsamente numa ampla área, os esquemas utilizado pelo DVMRP e pelo MOSPF não são muito eficientes. O tráfego de dados de difusão seletiva (no DVMRP) ou o relatório de informação dos membros do grupo (no MOSPF) são periodicamente enviados sobre muitos enlaces que não conduzem a membros do grupo. Além disso, estes esquemas de roteamento foram desenvolvidos para uso dentro de regiões onde um grupo é amplamente representado, ou vasta largura de banda é disponível.

Existe um protocolo que foi desenvolvido com o objetivo se estar apto para rotear pacotes de difusão seletiva sem ser dependente dos esquemas de roteamento IP unicast básicos como o DVMRP (baseado no RIP) e o MOSPF (baseado no OSPF). Denominado Protocol Independent Multicasting (PIM) [DEE 95d][DEE 95e], é um recente desenvolvimento do IETF Network Working Group. Além do já citado objetivo, o PIM trata também algumas das questões de escalamento com respeito ao esparsamento de áreas amplas usado no MBone. Ele possui dois modos: o Sparse Mode PIM, um protocolo de difusão seletiva que é otimizado para um grupo que está distribuído em diferentes regiões da Internet, e o Dense Mode PIM, que é otimizado para grupos localizados próximos.

O modo Dense Mode PIM utiliza uma técnica denominada Reverse Path Multicasting (RPM), onde um datagrama de difusão seletiva é transmitido apenas se a interface de recebimento do datagrama é a interface que seria utilizada para enviar datagramas unicast para o nodo origem do pacote. Nestes casos, o datagrama de difusão é enviado para todas as outras interfaces [DEE 95e].

Este modo é dirigido a dados: um nodo cria uma entrada de transmissão de difusão seletiva para uma particular árvore de distribuição com raiz na origem quando o pacote de dados vindo daquela origem para aquele grupo chega pela primeira vez. Na criação desta entrada é assumido que todos os nodos inferiores a eles na árvore de transmissão desejam receber os datagramas, e este é enviado para todos eles.

Em grupos com muitos participantes ou em redes onde há largura de banda abundante esta linha de comportamento, que supões interesse dos nodos inferiores pelo grupo, é eficiente. As áreas da rede onde não houverem membros do grupo, assim como as áreas onde os participantes deixarem o grupo, a árvore de transmissão terá os seus braços correspondentes a estas áreas podados, graças ao esquema de poda do protocolo.

O Dense Mode PIM, como apresentado acima, utiliza distribuição dos dados para todos os roteadores da rede para estabelecer as árvores de distribuição dos grupos. Diferente deste, o modo Sparse Mode PIM prefere tentar conter a distribuição dos dados para o número mínimo de roteadores da rede. Este modo difere dos outros esquemas de difusão seletiva IP em dois pontos fundamentais [DEE 95e].

O primeiro ponto diz respeito ao envio explícito de mensagens de associação a grupos feitos pelos roteadores que possuem membros do grupo em sua rede local ou em roteadores inferiores. Estas mensagens inserem o roteador na árvore de distribuição, e só assim este passa a receber os datagramas.

A segunda diferença se situa no fato de que enquanto a construção da árvore de difusão seletiva do Dense Mode PIM é orientada aos dados, a construção da árvore do modo Sparse Mode PIM deve ser feita através do grupo para que os recebedores identifiquem novas origens para os datagramas do grupo. Pontos de associação são utilizados pelos nodos remetentes de um novo datagrama anunciar sua existência e pelos nodos recebedores para aprenderem sobre estas novas origens.

As informações relacionadas a árvore de menor custo mantida pelos roteadores é parecida com as informações de transmissão mantidas pelos roteadores de outros protocolos de difusão seletiva IP, como o MOSPF, englobando o nodo origem, o endereço do grupo, o conjunto de interfaces de saída e a interface de recebimento dos datagramas.

Alguns vendedores de roteadores IP, como a Cisco Systems e a 3Com Corporation, estão a frente de um grupo de desenvolvimento e distribuição de roteadores de difusão seletiva baseados em PIM no MBone. Estes roteadores entendem pacotes IP de difusão seletiva no seu modo natural, além de que túneis não são mais necessários para rotear tráfego entre eles. O uso de túneis será utilizado apenas quando forem integrados roteadores DVMRP[KUM 95].

3.5.2 Protocolos de Transporte

O MBone utiliza o protocolo User Datagram Protocol (UDP) na camada de transporte, diferente do tradicionalmente usado para aplicações interativas Transmission Control Protocol (TCP). O TPC é um protocolo orientado-a-conexão confiável, enquanto que o UDP não fornece quase nenhum controle. O motivo para o uso do UDP, porém, é exatamente que o controle de fluxo e a confiabilidade oferecidos pelo TCP não são adequados para, por exemplo, transmissão de áudio ao vivo.

A transmissão de quadros de dados multimídia em tempo real requer transporte baixo com baixo overhead. A perda de pacotes ocasional gerada pelos usuários do UDP é aceitável, enquanto que o retardo de retransmissão, ocasionada pelo uso do TCP, não é aceitável para conferências interativas. Além disso, o protocolo TCP não pode ser facilmente utilizado para realizar difusões seletivas IP.

O uso do UDP, protocolo não confiável, leva a não garantia de ordenação e confiabilidade na entrega. Porém, como tem sido demonstrado em diversas aplicações MBone, com um apropriado suporte de programação no nível de aplicação, a ordenação e confiabilidade de entrega podem ser atingidas sem maiores problemas [ERI 94].

A seguir, será descrito o protocolo RTP, que é utilizado pelas aplicações para se efetuar ordenação dos pacotes e controle da transmissão.

3.5.2.1. Real-Time Transport Protocol (RTP)

O protocolo Real-Time Transport Protocol (RTP) [SCH 96] é utilizado por aplicações que transmitem dados em tempo real, como áudio e vídeo, em transmissões unicast ou com difusão seletiva. Fornece funções de transporte de rede fim-a-fim tais como identificação da carga, numeração de seqüência e carimbo de temporização (timestamp). Não efetua, porém, reserva de recursos, nem garante a qualidade para serviços de tempo real.

Junto a ele, é utilizado o protocolo RTP Control Protocol (RTCP) [SCH 96], que possibilita a monitoração da entrega de dados de forma escalável para grandes redes de difusão seletiva e fornece funcionalidades de identificação e controle mínimas.

O protocolo RTP é utilizado geralmente pelas aplicações sobre o protocolo UDP, a fim de utilizar os serviços de multiplexação e controle de erro. Ambos protocolos, assim, contribuem para funcionalidades de protocolo de transporte.

Na Internet, assim como em outras redes de pacotes, ocasionalmente ocorrem perdas e desordenação dos pacotes, assim como atrasos de entrega em intervalos variáveis. O protocolo RTP não fornece nenhum mecanismo para garantir tempo de entrega, nem efetua reordenação de pacotes. Porém, com as informações de temporização e número de seqüência incluídas no cabeçalho do protocolo, a aplicação recebedora dos datagramas pode reconstruir a temporização da origem e a seqüência de pacotes enviada, podendo também estimar a quantidade de pacotes perdidos. Com a numeração de seqüência, é possível também que seja determinada a correta localização de um pacote sem necessariamente decodificar os pacotes em seqüência, como em decodificações de vídeo.

O RTCP se baseia na transmissão periódica de pacotes de controle de todos os participantes de uma sessão, utilizando o mesmo mecanismo de distribuição dos pacotes de dados. Os protocolos inferiores devem fornecer multiplexação dos dados e controle dos pacotes, utilizando por exemplo número de portas separadas para o UDP.

Na utilização do RTP para conferências com transmissões de áudio com difusão seletiva IP, é selecionado um endereço de difusão seletiva para o grupo e duas portas, uma utilizada para os datagramas de dados de áudio e outra utilizada para controle dos pacotes, com o protocolo RTCP. Este controle é utilizado para identificar os participantes de uma sessão a cada momento, assim como identificar como estes participantes estão recebendo os dados, fatores necessários em conferências de difusão seletiva já que os membros de um grupo entram e saem deste grupo durante a transmissão.

Assim, cada aplicação de áudio na conferência envia periodicamente, com difusão seletiva na porta de controle, uma notificação de que está recebendo os dados, informando o nome do usuário participante e como esta a qualidade dos dados recebidos. Quando uma estação deixa o grupo da conferência, envia um pacote do tipo RTCP BYE para a origem, notificando que não é mais participante do grupo.

Em conferências onde é utilizado áudio e vídeo, os meios são transmitidos como sessões separadas. Os pacotes RTCP são transmitidos para cada meio utilizando dois endereços classe D e dois pares de portas UDP diferentes. Não há ligação direta no nível RTP entre as sessões de áudio e vídeo, exceto que o participante em ambas as sessões deveria utilizar o mesmo nome (nome que distingue a conferência) nos pacotes RTCP para áudio e vídeo, de modo que as sessões possam ser associadas.

Algumas vezes, participantes da conferência de uma área utilizam enlaces de baixa velocidade, enquanto que a maioria dos participantes utiliza acesso a rede com alta velocidade. Em vez de forçar todos os membros a utilizar uma baixa largura de banda, com métodos de codificação de dados de áudio de baixa qualidade, pode ser colocado próximo a área de baixa velocidade um retransmissor do nível RTP chamado mixer. O mixer ressincroniza os pacotes de áudio que chegam para reconstruir o espaçamento constante de 20 ms gerado pela origem, mistura estes quadros reconstruídos em um quadro simples, traduz a codificação de áudio para uma de menor largura de banda e envia os quadros com menor largura de banda para o enlace de baixa velocidade. Estes pacotes podem ser enviados para um destino único utilizando unicast ou transmitidos para múltiplos destinos com difusão seletiva com um endereço classe D diferente. O cabeçalho do RTP inclui um meio para os mixers identificarem a origem do pacote misturado, de modo que os recebedores tenham a indicação correta do originador dos dados.

O protocolo RTP foi designado inicialmente para atender às necessidades de conferências multimídia, porém não é limitado para estas aplicações em particular. O RTP é também aplicável para aplicações tais como as aplicações de armazenamento contínuo de dados, de simulação distribuída interativa e de controle e medida.

3.5.3. Resource Reservation Protocol (RSVP)

O Resource Reservation Protocolo (RSVP) [ZHA 93] é um protocolo utilizado para criar e manter reservas de recursos em cada enlace ao longo do caminho utilizado pelos quadros de dados. A reserva de recursos garante que seja escolhida a qualidade de serviços apropriada para uma aplicação, deixando de lado o modelo de serviços onde se é fornecido o melhor serviço disponível para o dado momento e permitindo que o tráfego dos quadros de dados possuam reserva de recursos na rede e a qualidade seja definida.

O protocolo RSVP é um protocolo simplex, isto é, a reserva de recursos se dá apenas em uma direção. O protocolo é orientado ao recebedor, onde o recebedor dos dados é o responsável pela inicialização da reserva de recursos. O projeto do protocolo permite que sejam acomodados recebedores heterogêneos em grupos de difusão seletiva, podendo cada recebedor reservar diferentes quantidades de recursos.

São fornecidos diversos estilos de reserva, que permitem que as aplicações especifiquem como a reserva para um mesmo grupo de difusão será acomodada para os comutadores intermediários. O protocolo suporta também mudanças em associações a grupos dinamicamente e automaticamente se adapta para as mudanças de roteamento. Estas características tornam o RSVP apto para trabalhar de modo eficiente com grandes grupos de difusão seletiva.

Os protocolos de reserva de recursos almejam estabelecer e manter o estado dos comutadores na rota utilizada pelos dados. Como a reserva de recursos é efetuada pelo recebedor, o protocolo deve garantir que as mensagens de reserva deste nodo sigam exatamente o caminho inverso dos quadros de dados de todos os grupos no qual o recebedor participa. Para isso, deve ser estabelecida uma árvore invertida do recebedor para todos os grupos para enviar as suas mensagens de reserva, árvore formada pelo caminho inverso definido pelo protocolo de roteamento de difusão seletiva. Periodicamente mensagens de rotas são transmitidas para as árvores de roteamento pelo protocolo de roteamento, e mensagens de atualização de reserva são transmitidas nas árvores invertidas para manter a reserva do estado corrente.

Cada comutador usa o estado do caminho para manter uma tabela de entradas e saídas das interfaces para cada grupo de difusão. Cada entrada na interface mantém a informação sobre o fluxo enviado para o nível acima na árvore, informação necessária nas requisições de reserva que forem recebidas. Para cada enlace de saída há uma lista de nodos remetentes de dados, sendo associado a cada um o endereço do nodo anterior pelo qual os dados deste remetente chega no comutador corrente.

Há também um conjunto de reservas, onde cada uma é formada pelo nodo que efetuou a reserva, um filtro e uma quantidade de recursos reservadas. Para reservas sem filtro não são necessários os dois primeiros campos, assim como para reservas com filtro fixo o primeiro campo não é necessário.


Capítulo 3 - A Rede Virtual MBone (Parte 4 de 7) de
MELCHIORS, Cristina - Sistemas Interpessoais de
Videoconferência (MBone).
Trabalho Individual n. 596 CPGCC-UFRGS. Jan. 1997