Tópicos relacionados

Para entender o quanto o multicast pode ajudar na videoconferência, é bom entender todo transporte secundário e os mecanismos usados por aplicações "normais" ou "unicast" como o H.323.

Como o tráfico H.323 viaja pela Internet

As sessões de videoconferência H.323 viajam pela rede no topo de uma camada de transporte da rede chamada IP. O padrão H.323 usa dois tipos de transporte de IP: TCP e UDP. O TCP é projetado para garantir que os dados cheguem completos, na sua condição original. O UDP é projetado para obter o maior número de dados para o destino na maior parte do tempo. Quando você compra alguma coisa pela Internet, você está utilizando o transporte TCP. Tanto você como o vendedor querem ter certeza de que seu pedido será recebido corretamente e precisamente. Você não ficaria contente se alguns bits fossem mudados na parte da quantia do seu cartão de crédito. Nas vezes em que um erro ocorre durante a transferencia de dados, a transação pode ser repetida várias vezes até que seja feita corretamente. Em contrapartida, suponhamos que você esteja assistindo a uma transmissão ao vivo de um evento de esporte. Se houver uma pequena falha e alguns quadros sejam perdidos, você provavelmente não se importará. Se você tivesse o último quadro enviado inúmeras vezes até que fosse entregado corretamente, o que você faria com eles? Assistiria fora de ordem? Pararia a gravação ao vivo e esperaria? Esse tipo de transmissão é conhecida por UDP.

O padrão H.323 requer o uso tanto do transporte TCP como do UDP. O TCP é usado para controle e compartilhamento de dados como uma transferencia de arquivos. Você definitivamente quer ter certeza que a sessão está configurada corretamente e você quer garantir que não haja erros na transmissão de um documento. O UDP é usado quando é enviada informações sobre a situação, vídeo e áudio. Na maior parte do tempo, a maioria desses tipos de arquivos chega corretamente; quando não, nós não nos importamos, ao menos que a porcentagem de informação perdida seja suficientemente grande para ser notada.

Transporte Eficiente de Rede

As sessões H.323 são tipicamente "unicast", significando que uma cópia da transmissão é criada e endereçada para cada usuário final único. Se há 5 participantes em uma sessão, 5 cópias devem ser enviadas, cada uma endereçada a um usuário final diferente. Os dados são desconstruídos em pacotes, cada um carregando o número de IP do usuário final como endereço de destino. Como os números de IP são únicos, uma cópia separada deve ser enviada para cada usuário final. Em qualquer fluxo de dados, incluindo um fluxo de dados de vídeo, o codificador real do dado pode ser separado dos detalhes do mecanismo de transporte usado. Hoje, o padrão H.323 exige transporte de TCP de controle e dados; então, unicast é requerido. Entretanto, é possível substituir um mecanismo de transporte diferente por TCP. Nenhum efeito é notado na substituição de um mecanismo de transporte por outro (do ponto de vista do usuário final) na qualidade ou na sessão de videoconferência; o que a rede vê é um modelo de tráfico completamente diferente.

O que é IP Multicast?

IP multicast é uma maneira eficiente da largura de banda de entregar os dados, como voz e vídeo, para receptores múltiplos usando uma cópia de todos ao invés de uma cópia de cada. A rede pode entregar as informações com mais eficiência enviando uma única cópia dos dados através de cada parte do equipamento da rede. Ao invés de endereçar a um dispositivo único, pacotes de multicast são endereçados para um grupo especial de endereços de IP, conhecido como endereços Classe D (o bloco de números de IP de 224.0.0.0 a 239.255.255.255). Esse "grupo de endereços multicast" serve como um canal virtual; o usuário final faz a seleção do canal selecionando o endereço apropriado, a rede (esperançosamente) se configura para entregar o tráfico multicast, e o usuário, então, recebe o fluxo de dados.

Para a rede "se configurar" para a entrega do tráfico multicast, ela requer o uso de algum protocolo específico de multicast. Eles estão descritos abaixo.

O multicast faz um uso eficiente da rede se certificando que poucos ou nenhum pacote de multicast seja enviado para um roteador, ao menos que um usuário final por trás do roteador tenha feito um pedido para enviar ou receber. Essa propriedade garante que somente permitidos que programas requisitados passem pelo roteador. Selecionar uma transmissão multicast é conhecido como juntar-se a um grupo de multicast. Quando você se junta a um grupo de multicast, o seu pedido é enviado de volta pelo seu roteador, que envia um pedido em direção a fonte(s). Essa ação constrói uma "árvore" de entregas, através da qual uma única cópia do multicast é entregue. O usuário final pode presenciar uma pausa entre a requisição para juntar-se ao grupo de multicast e o início do fluxo de dados requeridos devido ao tempo que leva para construir a "árvore" de entregas.

Por que as universidades, assim como outros IPSs, estão interessadas em converter a largura de banda? Mesmo se a universidade pode fornecer "largura de banda ilimitada" no campus, as conexões fora do campus são normalmente arranjadas por algum provedor de serviços de Internet, e essa conexão é cara. Acesso a Internet de fome geral, mesmo para Internet2, é normalmente um obstáculo na rede (do ponto com a maior limitação de largura de banda). A videoconferência pode ser usada pelo campus, mas a aplicação mais comum é para se comunicar com os colegas distantes - fora do campus.

Sessões Multiponto sem um MCU

Anteriormente nesse livro de receitas, nós descrevemos sessões ponto a ponto e multiponto. Nós afirmamos que sessões multiponto requerem um MCU para receber e re-transmitir a sessão para cada participante individual da conferência multiponto. Entretanto, o IP multicast torna possível se juntar a conversações multiponto sem o uso de um MCU. Como o MCU é muito caro, aparentemente o multicast oferece uma abordagem de custo mais efetivo para a videoconferência multiponto, usando a infra-estrutura do roteador existente.

Em uma conferência multicast, um endereço de Classe D é designado antecipadamente. Como não há um depósito global de quem usou determinado endereço, há algumas questões interessantes em definir, tipo como saber se um endereço é "novo" ou não. Há vários esquemas de distribuição de endereços em uso, mas nenhum obteve uma aceitação global. Algumas ferramentas, como o Session DiRectory (SDR), possuem um mecanismo semi-aleatório embutido que funciona muito bem. Dado o tamanho do espaço do endereço, e os poucos usuários atuais do multicast, a chance de uma colisão é pequena e se acontecer, as pessoas percebem rapidamente e escolhem um novo endereço.

Ok, suponhamos que você queira criar uma sessão multicast. Todos os participantes da conferência enviam pacotes de rede que estão endereçados para o mesmo endereço Classe D. quando usando um MCU, cada participante da videoconferência é transmitido para o MCU que age como um servidor, re-transmitindo os dados para todos os participantes conectados. No multicast, os dados de cada usuário é transmitido diretamente por seu próprio sistema de videoconferência para todos os outros participantes, sem precisar de um servidor central.

Há algumas trocas de largura de banda, aqui. Se todos os participantes de uma conferência estão fazendo multicast para todos os outros, então cada terminal recebe stream de vídeo de todos os outros. Isso pode causar problemas no tráfico da rede nos terminais. Se um MCU é usado, também deve administrar todos os streams de uma vez, mas pode ser colocado em um local de rede central que é projetado para administrar essa carga de tráfico.

Como um usuário final de multicast, esses detalhes são omitidos de você. Em algumas aplicações, o que você vê é a interface amigável do usuário que apresenta a você uma lista de transmissões disponíveis, muito semelhante a um guia de TV. Você vê qual sessão está rodando no momento e, também, qual sessão está agendada para o futuro. Se você quer criar ou anunciar uma nova sessão, você clica um botão e preenche alguns campos. Para entrar em uma sessão, você clica em uma das entradas do "guia de TV".

Sem um MCU ou mecanismo de autorização central, os participantes estão livres para se adicionar ou se remover das conferências multicast, sem ter que ser pré-autorizado por um gatekeeper. Atualmente, você ainda não pode criar uma conferência multicast global privada verdadeira; na verdade, você não pode restringir receptores ou pedidos para participar da multicast de nenhuma forma em escala global. Há uma variedade de pesquisas nessa direção, mas elas tem algumas formas de mover-se. Algumas ferramentas comerciais que usam multicast também fornecem um mecanismo de senha para acessar um serviço de diretório, mas essa segurança é fraca e normalmente implementada de uma forma particular.

Se uma sessão requer segurança, quem quer que seja que estabeleça a sessão pode estabelecer a segurança e enviar as senhas, chaves de codificação efetivamente, para selecionar os participantes. Outras pessoas podem entrar na conferencia, mas não podem decodificar o conteúdo. A segurança é, então, tão forte quanto o esquema de codificação escolhido e a chave de codificação.

Quais hardware, software e infra-estrutura de rede requeridos para suportar IP multicast?

Se o IP multicast poupa largura de banda e elimina a administração central, por que razão ninguém a usa? Há três área de maiores problemas: a área de rede ampla, a rede do campus/local e outras ferramentas.

Na área ampla somente alguns transportadores comerciais oferecem serviços de multicast, e em alguns desses você tem que achar a pessoa certa para falar! Inversamente, a maioria das pesquisas globais e redes de educação oferecem serviços de multicast.

Nos campus, a rede pode ser habilitada para multicast, mas poucos fizeram isso. Há uma cautela geral sobre multicast, a maioria (mas não todos) sem fundamento, e os campus geralmente não tem os equipamentos de rede mais modernos requeridos (veja abaixo). Muito poucos campus podem entregar tráfico multicast “em qualquer lugar”, mas os números estão crescendo vagarosamente.

Muitos campus que oferecem serviços multicast “para todos lugares” fazem isso usando protocolos de rede proprietários.

Como os protocolos H.323 proprietários permitem que você alcance níveis sofisticados de videoconferência H.323 pelo custo de perder a interoperabilidade, as implementações proprietárias de multicast permitem que você entregue o tráfico multicast, mas ao custo de perder a interoperabilidade. Em condições ideais, a implementação de uma rede de suporte de multicast seria neutra de fornecedores. Grandes compras de equipamentos de rede pelos campus em um período de tempo, geralmente de fornecedores diferente, e, assim, contando com a participação de padrões para assegurar compatibilidade entre fornecedores em algum nível previsível. Mesmo que o seu campus tenha conseguido obter um único fornecedor, compra de equipamentos de uma única geração, você estará se comunicando com colegas de outras instituições que talvez tenha se padronizado em algum equipamento de outro fornecedor. A participação de padrões pode limitá-lo a performances de denominador comum, mas é previsível e confiável.

Presumindo que você tenha os dois primeiros resolvidos, e há muita ajuda disponível por aí (veja abaixo e em outros lugares), isso deixa as ferramentas. A maioria desses vieram da comunidade universitária no passado, e refletem um grande esforço de engenheiros – exceto na interface do usuário, documentação e estabilidade. Felizmente, o mundo comercial começou a trabalhar em ferramentas de multicast e desenvolveu algo que pode ser oferecido confortavelmente aos usuários. A maioria desses produtos não usam o H.323, embora alguns interoperem com produtos H.323. alguns fornecedores, incluindo VCON (http://www.vcon.com/ ) e Lucent (http://www.lucent.com/enterprise/ipapps/conferencing/), vendem sistemas H.323 que suportam IP multicast. Essas ofertas tem todas as artimanhas e limitações que você esperaria na Versão 1 de qualquer produto, mas eles melhorarão no futuro. Um versão livre de um visualizador de IP/TV multicast, com uma licença de 1 ano, está disponível na instituição de membros do Internet2 em http://netaid.uoregon.edu/. O IP/TV permite que você assista e escute em uma conferência multicast, mas eles não permite que você contribua ; pode operar em resolução mais alta do que os clientes de domínios públicos. Um bom pacote de ferramentas MBONE para Windows (MASH) está disponível na UB Berkeley no site http://bmrc.berkeley.edu/bibs/download/index.html. Outro pacote conhecido como Shrimp está disponível em http://www.ja.net/development/video/shrimp/. A comunidade Linux/Unix achará ferramentas em University of Oregon Video Lab and the Internet2(tm) Networks Multicast Trial e Setting up MBone Tools for Windows95/NT, Macintosh and Unix.

Eu quero multicast no meu campus – do que eu preciso?

Você precisa falar com a sua equipe de rede.

Comece com a subnet local. Usar uma conexão comutada ou invés de uma Ethernet compartilhada é preferível. Em uma conexão compartilhada (um hub Ethernet), todo tráfico que entra no hub é transmitido para TODOS os dispositivos conectados. Se você tiver tráfico de vídeo chegando ou saindo, ele será enviado para todas as estações conectadas, que terá que decidir se mantém ou joga a transmissão. Uma conexão de rede comutada é melhor porque o tráfico é enviado somente para o destinado do PC, e não para todos os dispositivos conectados. Há um pequeno problema, porém, Na camada Ethernet os endereços de multicast são “desconhecidos” para o comutador, então, ele transmite o tráfico para “todo mundo”, daí o multicast de fato pode transformar o seu comutador em um hub compartilhado!

Para evitar esse problema, é usado o protocolo IGMP (Internet Group Membership Protocol). O IGPM permite que o usuário final de um PC faça um pedido para ENTRAR a uma sessão multicast ou SAIR de uma sessão multicast. Se o comutador comportar IGMP, ele saberá enviar tráfico de multicast somente para portas onde o usuário final tenha pedido para ENTRAR, e o comutador irá ignorar as portas não entraram ou que tenham saído de uma sessão multicast. Em resumo, o comutador deve estar ciente do IGMP para ser verdadeiramente útil. O IGMP está atualmente na versão 2 em desenvolvimento geral. Uma nova forma de multicast chamada Source-Specific Multicast (SSM) levou ao desenvolvimento do IGMPv3, mas nenhum fornecedor de comutador Ethernet o suporta até esse momento.

Conexões Ethernet comutadas podem ter o usuário final e o hub compartilhado plugados nele. Como afirmado acima, a transmissão de multicast através de um hub compartilhado pode ser intratável, portanto pode ser desejável permitir que o tráfico de multicast através de um comutador para os usuários finais individuais, mas que seja bloqueado de passar através do hub. A habilidade de controlar o multicast no nível da porta é uma característica desejável do comutador.

No limite da rede do seu campus, os roteadores precisam interfacear com as amplas áreas das redes e trocar tráfico de multicast, e , então, distribuí-lo através do campus de uma maneira efetiva. Ao menos que você tenha uma rede Ethernet estável no campus, os seus roteadores precisarão administrar o tráfico multicast. Os atuais padrões recomendam o uso MBGP/BGP4+ e MSDP no limite da rede do seu campus e PIM, particularmente o modo PIM-sparse (ou PIM-SM) pelo campus.

O MBGP ou BGP4+ é o protocolo de rota mais amplamente usado pela Internet hoje com melhoramentos para o multicast. Ele permite que engenheiros de rede identifiquem apropriadamente os caminhos para o tráfico multicast pegar e para o roteador entender que precisa manipular o tráfico de multicast corretamente. O MSDP fornece efetivamente um serviço de “descoberta de canais” entre domínios de administração (ou “sistema autônomos/SA”), que não é fornecido pelos protocolos multicast de área local mais rudimentares. O PIM-SM (e o amigo "modo-denso" PIM-DM) funciona na verdade na entrega do tráfico de multicast a rede, usando informações fornecidas pelo MBGP, MSDP e IGMP no limite máximo.

As recomendações do grupo de pesquisa Internet2 Multicast e NLANR são configurar o roteador do limite do seu campus para aceitar tráfico Modo PIM-Sparse (somente transmissão requerida de passagem pelo seu campus). Configurações do campus recomendadas incluem o PIM-Sparse Mode e o PIM-Dense Mode. O PIM-DM é adequado onde os usuários finais povoam a rede densamente e há muita largura de banda para gastar.À direita, você encontrará um gráfico indicando o impacto do tráfico de multicast na infra-estrutura do campus da University of Alabama at Birmingham (UAB) no PIM Dense Mode. O PIM-DM é uma configuração que permite que TODO o tráfico disponível flua ("FLOOD") para vários pacotes (um pacote por fonte), então qualquer conexão que não esteja sendo vigiada dentro do campus será parada ("PRUNE") por alguns minutos. Um gráfico do resultado da utilização da largura de banda na rede aparece sendo um fluxo contínuo de 3-10Megabits por segundo de tráfico para uma rede Internet2 conectada. O PIM Sparse Mode envia tráfico de multicast somente para usuários finais que tenham entrado em uma sessão. O PIM-SM é recomendado quando há somente alguns poucos receptores de multicast e a largura de banda tem que ser conservada. Informações muito boas sobre IP Multicast e problemas de arquitetura de redes associadas podem ser encontradas no site de engenharia da NLANR (http://www.ncne.nlanr.net/faq/multicast.html).