4. Esquema 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 multicast 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 multicast originário de um cliente acrescentando a opção IP LSRR para o cabeçalho do pacote IP, movendo o endereço destino multicast 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 multicast destino original e removia a source route antes de enviar o pacote adiante. Esta forma de implementação apresentava, porém, algumas deficiências, que foram detectadas durante o encontro do IETF em novembro de 1992, em Washington [ERI 94]. Foi estudado então um novo esquema de tunneling, onde é utilizado encapsulamento real ao invés da opção LSRR.

Neste método, o pacote multicast 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 preenchido com o valor 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 route[KUM 95].

4.1 Métrica e Threshold

4.2 O Uso de Prunning

4.1 Métrica e Threshold

Os túneis possuem associadas a eles algumas variáveis, que são responsáveis pela configuração do tipo de túnel, velocidade associada, etc. As principais variáveis são a métrica e o threshold.

A métrica é usada para definir o custo de roteamento que é usado no Distance Vector Multicasting Routing Protocol (DVMRP) para configuração de túneis primários ou túneis backup. Em túneis primários, a métrica associada é 1; em túneis backup, 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 por este caminho. O túnel backup é utilizado quando um dos túneis primários caem.

O threshold, por sua vez, tem como função limitar o escopo de distribuição dos pacotes multicast. O threshold corresponde ao 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.

Por default, quando é criado um grupo multicast, os datagramas multicast IP são enviados com um TTL de 1, que impede que eles sejam enviados para além da subrede local. 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 multicast para redes dentro de organizações, enquanto que os valores de 127 ou 255 são usado para quando é desejado enviar os pacotes multicast 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 randômicamente, 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. Para o encontro do IETF de novembro de 1992, foram convencionados os valores de TTLs a serem utilizados nas aplicações, utilizados muitas vezes nas transmissões atuais:

Tabela - TTLs e Thresholds utilizados no IETF de Novembro de 1992. A coluna TTL especifica 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 nas linhas acima na tabela.

4.2 O uso de Prunning

Além do uso do campo TTL dos datagramas e do threshold configurado para cada túnel, existe uma outra forma de controlar a distribuição dos pacotes multicast pela Internet, que está sendo hoje em dia utilizada em muitos túneis: o uso de prunning.

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 multicast vizinhos. O único controle por interesse que havia era feito nos nodos folhas da árvore de multicast, onde o mrouter local somente colocava o datagrama na rede local se um host cliente participava do grupo do datagrama multicast[ERI 94]. 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 multicast recebiam todo um tráfego desnecessário, consumindo uma grande largura de banda desnecessariamente. Foi estudado então um mecanismo mais eficiente, onde o interesse em receber pacotes de um grupo fosse considerado, criando os chamados túneis prunned.

Prunning em difusão seletiva é também denominado difusão seletiva verdadeira, pois os pacotes somente são enviados para os 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 multicast (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 multicast 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 multicast DVMRP de versões 3.x e superiores.