5.1 Protocolos de Roteamento Multicast
Como o uso de multicast não é compreendido em todos os roteadores na Internet, a topologia do MBone difere da topologia da Internet. Com isso, os roteadores multicast precisam executar um protocolo de roteamento multicast para descobrir sua própria topologia, a fim de identificar para onde enviar os datagramas. O protocolo mais utilizado no MBone é o Distance Vector Multicasting Routing (DVMRP). Porém, em algumas partes do MBone, os roteadores usam outros protocolos de roteamento multicast, especialmente o Multicast Open Shortest Path First (MSOPF) e o Protocol Independent Multicast (PIM), que interoperam com os roteadores DVMRP graças a implementação de um subconjunto do DVMRP.
Distance Vector Multicasting Routing Protocol (DVMRP)
O DVMRP[KUM 95][DEE 88] foi um dos primeiros mecanismos de roteamento multicast desenvolvidos, criado por Steve Deering. Existe uma versão anterior do DVMRP, especificada na RFC-1075, porém a versão utilizada nos mrouters é diferente da versão especificada neste documento, possuindo diferenças quanto ao formato do pacote, ao formato do túnel, aos tipos de pacotes adicionais, etc.
O roteador multicast baseado no DVMRP mantém o conhecimento topológico através de um protocolo de roteamento de vetor de distâncias, como o Routing Information Protocol (RIP) descrito na RFC-1058, sobre o qual é implementado um algoritmo de transmissão multicast chamado Truncated Reverse Path Broadcasting.
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 subrede no Mbone e troca mensagens de roteamento periodicamente com cada um de seus vizinhos identificando todas as subredes. Como o número de subredes tem crescido exponencialmente, o custo de roteamento cresce também exponencialmente, e os recursos de memória e processamento dos atuais roteadores DVMRP deverão ficar insuficientes.
Este problema já é conhecido no roteamento unicast, e tem como solução o uso de roteamento hierárquico. No roteamento hierárquico, a 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 são utilizados 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 interdomí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 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. No roteamento multicast 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 multicast 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 elas, eliminando os problemas gerados pela mistura de diferentes 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 entre 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.
Multicast Open Shortest Path First (MOSPF)
A extensão multicast 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 na contagem dos nodos. Uma rede de roteadores utilizando MOSPF pode enviar pacotes multicast 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 multicast 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 multicast, 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, 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 ao fazer 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 atraso para membros individuais do grupo.
No MOSPF, 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 multicast no MOSPF pode variar de acordo com a classificação TOS utilizada. Por exemplo, um tráfego multicast sensitivo ao delay(retardo) pode seguir rotas diferentes de uma aplicação multicast de alto throughput (vazão). A classificação TOS no protocolo MOSPF é, como no OSPF, opcional, e roteadores que a suportam podem ser misturados livremente como os que não a suportam.
Algumas implementações do protocolo MOSPF 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 multicast. Desta forma, os Sistemas Autônomos executando o MOSPF podem fazer parte do MBone.
Protocol Independent Multicast (PIM)
Quando membros de um grupo e transmissores para este grupo estão distribuídos esparsamente numa ampla área, o esquema utilizado pelo DVMRP e pelo MOSPF não são muito eficientes. O tráfego de dados multicast (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 clientes 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 de estar apto para rotear pacotes multicast sem ser dependente dos esquemas de roteamento IP unicast básicos como o DVMRP (baseado no RIP) e o MOSPF (baseado no OSPF): o Protocol Independent Multicasting (PIM) [DEE 95b][DEE 95c].
Recente desenvolvimento do IETF Network Working Group, o PIM trata também algumas das questões de escalabilidade relacionadas à distribuição esparsa de amplas áreas 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 com membros próximos.
Alguns vendedores de roteadores IP, como a Cisco Systems e a 3Com Corporation, estão à frente de um grupo de desenvolvimento e distribuição de roteadores multicast baseados em PIM no Mbone. Estes roteadores entendem pacotes IP multicast 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.
5.2 Protocolos de níveis superiores
O MBone utiliza o protocolo User Datagram Protocol (UDP) na camada de transporte. Este protocolo, diferente do Transmission Control Protocol (TCP), que é orientado a conexão, não oferece confiabilidade. O uso do UDP é explicado pelas características de tráfego multimídia: a transmissão de quadros de dados multimídia em tempo real requer transporte baixo com baixo overhead. Assim, a perda de pacotes ocasional gerada pelos usuários do UDP é aceitável para as transmissões do MBone, enquanto que o atraso de retransmissão, ocasionado pelo uso do TCP, não é aceitável para conferências interativas.
Como o UDP é um protocolo não confiável, não há garantia de ordenação e não duplicação dos pacotes, problema que precisa ser resolvido nos níveis superiores.
Real Time Protocol (RTP)
Muitas aplicações utilizam o protocolo Real Time Protocol (RTP)[SCH 96] sobre o protocolo UDP. Este protocolo foi desenvolvido pelo Audio-Video Transport Working Group dentro do IETF. Atualmente, encontra-se na versão 2, sendo que associado a ele existe um protocolo de controle denominado RTP Control Protocol (RTCP).
O RTP fornece funções de transporte de rede fim a fim para aplicações que transmitem dados em tempo real. O RTP não garante a qualidade para serviços em tempo real, não fornecendo sozinho nenhum mecanismo para assegurar a entrega ou a ordenação dos pacotes. Mas permite que sejam adicionados mecanismos de segurança, quando necessários, bem como controle de fluxo e congestionamento[TRE 96].
O protocolo RTCP fornece uma série de funções de controle para os dados multimídia que são transportados pelo RTP. Permite que seja monitorada a entrega de dados de forma escalável para grandes redes multicast, provendo um controle mínimo e funcionalidades de identificação.
O RTP é responsável pelo transporte de dados, enquando o RTCP transporta as informações de controle que refletem a qualidade dos dados que estão sendo recebidos por cada estação participante no MBone. Ambos os protocolos foram projetados para serem independentes das camadas de rede e de transporte subjacentes.
