Prof. Eduardo Parente Ribeiro - UFPR
Disciplina: Comunicação
de Dados
MBONE
Flávia M. Miranda
3.Diferença entre Mbone e Multicastiing
5.Protocolos de Roteamento de Difusão Seletiva
8.Protocolos de Níveis Superiores
9.Sistemas de Videoconferência
11.Ferramentas de anúncio de Sessão
14.Ferramentas de Documentos Compartilhados
15Vantagens Obtidas com o Uso de Multicast
MBONE
O Mbone foi criado como uma rede experimental de multicast para o protocolo IP, desenvolvido e testado na rede de pesquisa DARTnet. Na rede da DARTnet eram transmitidas semanalmente conferências para seus pesquisadores. A primeira grande transmissão MBone, porém, 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 multicast do site IETF para participantes de 20 sites em três continentes, abrangendo 16 zonas horárias .
O evento foi uma demonstração da tecnologia desenvolvida na rede DARTnet, e tem grande significado pelo tamanho da topologia da rede multicast 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. A transmissão do evento foi possível graças a utilização de multicast IP implementado nos roteadores e estações, 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 teriam sido proibitivos.
Poucos roteadores na Internet implementavam roteamento multicast IP. Entre eles, porém, estavam os roteadores da rede experimental DARTnet, que utilizavam o Distance Vector Multicast Routing Protocol (DVMRP). Mas para o evento era desejado atingir sites que não suportassem multicast IP. Deste modo, a fim de suportar multicasting entre redes separadas por roteadores unicast que não suportavam multicast IP, foram utilizados mrouters, que implementavam o conceito de túneis, estabelecendo enlaces virtuais ponto-a-ponto entre os mrouters.
Para transmitir um pacote multicast através de um túnel, o roteador multicast modificava o pacote na opção IP Loose Source Route do cabeçalho IP, colocava o endereço destino multicast na rota de origem e o endereço unicast do roteador no campo IP Destination Address. O pacote era tratado com um pacote normal unicast entre os roteadores e subredes intermediárias ao longo do túnel, e o roteador ao final dos túneis restaurava o endereço destino multicast e deletava 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 backup para o caso de ocorrerem falhas nos enlaces primários ou na DARTnet, associando diferentes métricas para os diferentes enlaces.
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 (audio e vídeo) e participaram das discussões.
Em 1995, existiam na ordem de 1700 roteadores na Internet que possibilitavam MBone.
O que é o multicasting?
Multicasting é uma método ou técnica de transmissão de um pacote de dados para múltiplos destinos ao mesmo tempo, ou seja, quando um pacote com endereço classe D (de 224.0.0.0 a 239.255.255.255) é utilizado, somente as interfaces de rede que tenham previamente se cadastrado no grupo multicast vão receber o pacote. Assim, existe uma diminuição de processamento nas máquinas que não pertencem ao grupo, pois o nível Ethernet não vai passar o pacote ao nível de rede, descartando-o imediatamente. Por outro lado, as interfaces de rede que tenham endereços cadastrados no grupo multicast vão receber os pacotes, enviando-os ao nível 3 para processamento.
Entretanto, para transmitir o mesmo pacote através de uma WAN como a Internet, a forma usual é utlizando protocolos Unicast. Essa técnica envia o pacote do endereço e origem para somente um endereço destino por vez.
Uma grande rede multicast existente atualmente é o MBONE (Multicast Backbone). É possível comparar os equipamentos que realizam a transmissão de pacotes multicast no MBONE à estações de televisão ou rádio. O sinal de televisão ou rádio possui em teoria uma fonte de origem e pode chegar a diversos aparelhos que estejam em seu perímetro de alcance e que sejam capazes de compreender este sinal. Uma estação geradora de sinais propaga ondas de forma broadcast no ar. O sinal será captado por todos os aparelhos de TV ou rádio da área de alcance, bem como passará invisível a tudo que não seja capaz ou não queira captá-lo e decodificá-lo. Logo, não seria possível assistir televisão em uma torradeira ou num aspirador de pó.
Em uma rede de computadores é possível enviar um pacote de um determinado computador para uma distribuição massissa a outros diversos computadores ao mesmo tempo, ao invés de transmitir o mesmo pacote diversas vezes a cada destino. Para se enviar dados em uma rede multicast não é preciso saber todos os endereços dos receptores que se deseja enviar. É preciso simplesmente transmitir de forma broadcast a tudo que seja capaz ou estiver interessado em receber os dados.
Normalmente, as comunicações IP são feitas entre um transmissor e um receptor. Entretanto, para algumas aplicações, é interessante que um processo seja capaz de transmitir dados para um grande número de receptores simultaneamente. Dentre os exemplos dessa estratégia estão a atualização de bancos de dados distribuídos replicados, a transmissão da cotação de ações para vários corretores, o controle de chamadas de teleconferência digital e transmissão de eventos.
O Internet Protocol (IP) aceita multicast, usando endereços classe D que identifica um grupo de hosts. Estão disponíveis 28 bits para identificar grupos; portanto, pode haver mais de 250 milhões de grupos ao mesmo tempo. Quando um processo envia um pacote para um endereço de classe D, é feita uma tentativa de entregá-lo a todos os membros do grupo endereçados, mas não há qualquer garantia de que isso realmente acontecerá. É provável que alguns membros não obtenhamo pacote.
São aceitos dois tipos de endereços de grupos: endereços permanentes e temporários. Um grupo permanente está sempre presente e não precisa ser estabelecido. Cada grupo permanente tem um endereço de grupo permanente. Alguns exemplos de endereços de grupo são os seguintes:
224.0.0.1 - Todos os sistemas de uma LAN 224.0.0.2
- Todos os roteadores de uma LAN
224.0.0.3 - Todos os roteadores OSPF de uma LAN224.0.0.4
- Todos os roteadores OSPFG designados em uma LAN
Para usar um grupo temporário, primeiro você deve criá-lo. Um processo pode solicitar que seu host se conecte a um grupo ou saia dele. Quando o último processo de um host deixa um grupo, o grupo passa a não mais existir no host. Cada host controla os grupos a que pertencem seus processos atuais.
O multicast é implementado
por roteadores multicast especias. Uma vez por minuto aproximadamente,
cada roteador multicast envia um processo de
hardware multicast (ou seja, camada de enlace de dados) para o hosts da
LAN (endereço 224.0.0.1) solicitado que
eles informem os grupos aos quais seus processos pertencem.
Esses pacotes de consulta e resposta utilizam um
protocolo chamado IGPM (Internet Gruop Management Protocol), que évagamente
parecido com o ICMP. Ele possui apenas dois tipos de pacotes: consulta
e resposta; cada um com um formato fixosimples, contendo algumas informações
de controle na primeira palavra do campo de carga útil e um endereço
classe D na segunda palavra. O IGMP é
descrito na RFC 1112. Ele é o responsável pela inclusão
e retirada de um computador em um determinado "host group". Basicamente,
o IGMP contém apenas dois tipos de mensagens: Join_Group e Query_Group.Quando
um computador deseja receber pacotes de um determinado "host group", ele
envia um pacote IGMP_Join_Group para aquele "host group". Todos os computadores
que pertencem a esse "host group" atualizam sua lista de computadores.
De tempos em tempos, o mrouter (se houver algum
na rede) produz uma mensagem IGMP_Query_Group para identificar os computadores
que ainda estão em determinado grupo e manter-se atualizado (no
caso de perda ou inconsistência da tabela decomputadores pertencentes
a um grupo, um computador também pode gerar esta mensagem).
A saída de um computador, na primeira versão do protocolo, apenas negava a recepção de pacotes multicast. Quando um mrouter ou um computador gerava uma IGMP_Query_Group, as tabelas eram atualizadas e este computador era retirado. Na versão 2 [WF97], antes de sair, o computador envia uma mensagem IGMP_Leave_Group; como parâmetro, é enviado o endereço do grupo ao qual ele esta saída. No caso de haver um mrouter na rede, sua tabela é atualizada automaticamente. A versão 3 do protocolo ja está em desenvolvimento.
O roteamento multicast é feito com base no método Spanning Tree. Cada roteador multicast troca informações com seus vizinhos usando um protocolo de vetor de distância modificado. Dessa forma, cada um dos vizinhos é capaz de construir uma Spanning Tree que abrange todos os membros de um grupo. Várias otimizações são usadas para podar a árvore, a fim de eliminar roteadores e redes que não interessam a determinados grupos. O protocolo faz muito uso do tunelamento para não incomodar os nós que estiverem fora da Spanning Tree.
Multicast foi criado, inicialmente,
para redes que tenham como característica a transmissão de
pacotes por um meio onde todos os computadores
estejam conectados e recebam o pacote, cabendo ao computador aceitar ou
não. Como somente
redes ethernet atendem a essa exigência, outros
tipos de redes precisam uma espécie de "emulação"
multicast.
O Multicasting vem sendo desenvolvido na rede virtual MBONE que tem sua base teórica na tradicional estrutura daInternet. O MBONE busca ampliar as atuais pontencialidades da rede mundial, tornando um meio de comunicação de massa efetivo, ou seja, transmissão de informação para diversos pontos ao mesmo tempo. O tradicionais correios eletrônicos esessões de chat, por mais modernos que se encontrem hoje, não mais satisfazem as exigências de uma comunicação completa entre os indivíduos. As pessoas, querem falar e serem ouvidas de forma clara e em tempo real; querem ver e serem vistas também de forma clara e em tempo real.
O vídeo e-mail foi o primeiro passo, onde pode-se enviar pequenos clips a destinos remotos na Internet. Contudo, a recente meta do MBONE e outras ferramentas de multicasting ou comuniação multiponto é tornar viável a conferência em grupo na Internet. Ou seja aperfeiçoar a tecnologia de transmissão de multimídia na Internet. Para o MBONE, a multimídia nos computadores é um pré-requisito, pois é impressindível que áudio e vídeo possam atuar juntos, onde os usuários sejam capazes de ver e ouvir imgens e sons.
MBONE tem como meta levar a Internet
como um todo ao próximo nível tecnológio de sua existência.
A Internet já concretizou todos os propósitos
originais a que foi idealizada. Por que então investir em MBONE
ou redes e tecnologias similares de tráfego de multimídia?
Pelo fato de que hoje existem novas demandas, uma nova exigência
da comunidade de internautas que busca comunicar-se
em tempo real com sons e imagens. O MBONE promete fazer pela Internet o
que o telefone fez pelas cartas escritas, o que as figuras fizeram a leitura
e o que a televisão fez aos jornais e revistas: mudá-loscompletamente
(seja para pior ou para melhor). Vídeo e áudio são
as formas de dissiminação de informação dominante.
Fazer delas veículos interativos levará o MBONE a alcançar
sua meta fundamental. Sabe-se que atualmente as tecnologias queimplementam
a interatividade com o usuário estão em crescente difusão
no mercado. Por conseguinte, é evitende concluir o grande potencial
que possui o MBONE como solução de interatividade distribuída
na rede mundial. Em especial vale ficar atento
ao impacto que o MBONE pode provocar nos negócios, entreterimento
e educação. Contudo, é bom ter claro que pouco deste
potencial já foi concretizado. Quem espera hoje assistir a espetáculos
e shows ao vivo ou participar de videoconferências com vários
indivíduos espalhados no mundo pode ficar decepcionado com as atuais
capacidades de transmissão e recepção de multimídia
na Internet.
3.Diferenças
entre MBONE e Multicasting
Atualmente, a maioria dos roteadores em atividade (equipamemtos que conectam redes de computadores) na Internet não são capazes de receber e retransmitir pacotes multicast. Sua configuração elementar está prevista para interpretar somente os tradicionais pacotes IP unicast que possuem endereço destino único. Entretanto, a família de roteadores que trabalham com informações multicast está crescendo, mas ainda é minoria. Os fabricantes de roteadores estão receosos das vantagens de produtos multicast. Isto torna difícil o crescimento da tecnologia, pois somente com a instalação destes equipamentos é possível incrementar e qualificar esta tecnologia de transmissão. Assim, forma-se um perigoso círculo vicioso que pode estar travando o crescimento das redes de computadores multicast.
Em 1992, a IETF (que é responsável por questões inerentes a Internet como entraves, avanços, mudanças de tecnologia, entre outros) criou o conceito de Vitual Network – uma rede vitual que está implementada sobre a rede mundial Internet. Era a possibilidade de se configurar redes por software sem a necessidade de mudar layouts de hardware. Em seguida, foram desenvolvidos programas capazes de transmitir nestas redes virtuais pacotes de informação de forma multicast. Aqui nascia o MBONE, que visava possibilitar a realização de videoconferências da IETF.
O MBONE é uma rede virtual de computadores, pois compartilha os mesmos meios físicos da Internet (cabeamentos, roteadores e outros equipamentos). Ele permite a transmissão de pacotes multicast através dos tradicionais roteadores unicast.
Os softwares que rodam no MBONE ocultam a característica multicast de seus pacotes. Esta técnica é conhecida como tunneling. Disfarçados de pacotes unicast, os pacotes multicast propagam-se na rede através dos roteadores unicast. Para isso, é feito o encapsulamento do pacote original com a criação de um novo cabeçalho (header), configurando como endereço destino (neste novo cabeçalho) o endereço unicast do próximo roteador.
Os equipamentos que suportam o IP Multicast são chamandas de mrouters. Eles são roteadores comerciais ou em geral estações de trabalho rodando softwares específicos - trabalhando em conjunto com roteadores padrão. Quando os pacotes multicast disfarçados de unicast encontram um roteador ou uma estação de trabalho capaz de interpretar o cabeçalho de encapsulamento, ocorre o tratamento da informação para efetuar sua propagação broadcast na WAN. No futuro, novos roteadores irão suportar pacotes multicast, eliminando a necessidade de executar o tunneling nas informações com destino broadcast.
Podemos então concluir a principal diferença entre Multicasting e MBONE. O primeiro é um método que viabiliza a transmissão de dados de forma broadcast, ou seja, enviar pacotes de dados para diversos destinos ao mesmo tempo. O segundo é um conjunto de equipamentos (estações de trabalho ou roteadores) integrados em uma rede virtual. implementando o IP multicast, isto é, o conhecido Protocolo Internet com habilidades de transmissão broadcast de dados. Assim sendo, podemos dizer que o MBONE é um backbone multicast, que poderá se alastrar no futuro com a substituição dos atuais roteadores unicast por equipamentos de roteamento multicast.
Alternativas ao MBONE
A rede virtual MBONE mostrou-se promissora para o futuro. Porém, exitem outras ferramentas atualmente disponíveis que viabilizam a multimidia na Internet em tempo real. Um exemplo é o CU-SeeMe – uma ferramenta que possibilita a realização de videoconferência para Macintosh e PCs sem rodar em cima do MBONE. Ao invés disto, ela utiliza computadores, conhecidos como Reflectors, que realizam transmissões multiponto – conceitualmente manipuláveis e compreendidas pelo Multicasting. Entretanto, os Reflectors permitem várias pessoas participarem de uma videoconferência sem o Multicasting.
A multimídia na Internet é viabilizada também por softwares que implementam a tecnologia streaming, os quais possibilitam a transmissão e recepção de informação que é rodada a medida que chega ao destino. Ou seja, é possível assistir um vídeo clip, antes que este tenha sido "baixado" por completo da rede. Logo que os primeiros pacotes vão chegando ao destino, já vão compondo a seqüência de imagens ou sons que está sendo apresentada em tempo real. O conteúdo pode estar sendo gerado a partir de uma mídia de armazenamento remota ou de equipamentos de captura de imagem e/ou som, tratando-se assim deuma apresentação em tempo real e ao vivo. Softwares de streaming trabalham de forma equivalente aos programas que rodam no MBONE, porém não necessitam de multicasting bem como não exigem largas bandas de transmissão.
Atualmente, existem mais de 20000 usuários do Mbone, distribuídos em 30 países e 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 multicast DVMRP passou por diversos avanços, como a implantação de prunned trees; novos protocolos foram e estão sendo desenvolvidos, como o MOSPF e o PIM; e muitas outras. Muitos produtos no mercado já suportam multicast IP, como o sistema operacional Solaris 2.x, da SUN;o Irix, da SGI; o Linux; produtos da Cisco Inc, 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. Enfim, o backbone virtual MBone está se transformando em um backbone semi-real, e no futuro possivelmente se tornará um backbone real e permante.
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.
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. 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.
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 . 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 .
O MBONE (Multicast Backbone) é uma rede virtual baseada em uma extensão do protocolo IP chamada IP Multicast. O Multicast é atualmente o método mais indicado para a difusão de dados em tempo real para um grande número de destinatários, e portanto, para aplicações de teleconferência. Nota-se que o MBONE em si não é o que torna possível a transmissão de áudio e vídeo. Muitos pacotes de software permitem a transmissão de imagens e sons através de redes locais. Na verdade, o que o MBONE oferece não é a possibilidade de transmitir áudio e vídeo, mas uma maneira de fazer isso de forma a causar o menor impacto possível na rede.
É importante observar que para aplicações de MBONE é indispensável possuir um link Internet de alta velocidade. Por alta velocidade queremos dizer pelo menos 1 Mbps. O MBONE toma uma largura de tráfego grande e, ao contrário de protocolos como Telnet, FTP e HTTP, o tráfego que normalmente circula na Internet, como videoconferência e shows de áudio e vídeo, exige uma certa largura de banda mínima. Se essa largura de banda mínima não é conseguida, o resultado pode ser decepcionante. As paradas, comuns em FTPs, por exemplo, seriam fatais para alguns décimos de segundos de conversa. Nos Estados Unidos é comum reservar 500 Kbps para o MBONE.
O MBONE é uma rede virtual porque compartilha
o mesmo meio físico da Internet. Esta rede virtual é composta
de LANs que podem suportar IP Multicast, o multicast é um recurso
para transmitir pacotes a mais de um endereço ao mesmo tempo, que
se diferencia do broadcast por transmitir somente para hosts determinados
ao invés de para todos os hosts do segmento. Além disso,
o multicast pode funcionar em WANs, empregando o mínimo de largura
de banda. Por isso, o multicast é o método mais indicado
para a difusão de dados em tempo real para um numero grande de destinatários,
tais como Ethernet e ATM, ligadas através de links ponto-a-ponto
chamados de túnel. Um túnel é uma ligação
entre dois roteadores que suportam multicast, chamados de mrouters. Estes
mrouters, que ligam as redes no MBONE, "conversam" utilizando protocolos
de roteamento multicast, cujos principais tipos são:
PIM - Protocol Independent Multicast; DVMRP - Distance
Vector Multicast Routing Protocol; MOSPF - Multicast Open Shortest Path
First.
Veja a topologia do MBone na figura abaixo:
5.Protocolos
de Roteamento de Difusão Seletiva
Alguns aperfeiçoamentos irão se tornar imprescindíveis com o contínuo crescimento de usuários e sub-redes MBone. Os protocolos de roteamento que serão utilizados pelos roteadores de difusão seletiva terão que ser eficientes tanto para grupos dispersos geograficamente em diferentes regiões como para grupos concentrados em uma região, como acontece com o protocolo PIM, que é provavelmente o que será mais utilizado em um futuro breve. Além dele, protocolos de roteamento como o DVMRP terão que possuir roteamento hierárquico, contornando os problemas deste protocolo para áreas extensas.
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 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.
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.
Existe uma proposta do uso de roteamento hierárquico para o Mbone, 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.
A extensão multicast para o protocolo de roteamento IP Open Shortest Path First (OSPF) é denominada Multicast Open Shortest Path First (MOSPF) . 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.
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) .
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.
Sendo que o PIM parece ser o mais promissor no futuro, mas o DVMRP é o mais empregado no momento).
Graças a essa eficiência na transmissão de pacotes, o MBONE é muito utilizado em atividades como videoconferência e transmissão de áudio e vídeo.
Cada host disposto a receber pacotes de uma fonte se inscreve em um "grupo", utilizando o protocolo IGMP para avisar aos outros hosts. Esses "grupos" são identificados por endereços IP de classe D, ou seja, de 224.0.0.0 a 239.255.255.255. Pacotes enviados para esses endereços por aplicativos, são direcionados para as maquinas que fazem parte do grupo.
O método de envio (se o envio é feito através de um broadcast, por múltiplas conexões ponto-a-ponto, etc) depende do tipo de rede e até mesmo do tipo de adaptador de rede utilizado.
Os mrouters ficam ouvindo a rede procurando mensagens IGMP. Eles conhecem, portanto, os grupos dos quais os hosts locais fazem parte e utilizam essa informação para conversar com outros mrouters, através de protocolos de roteamento multicast TTL é o TLA (three-letter acronim - abreviatura de três letras) para time-to-live. O time-to-live no mbone tem o mesmo papel do time-to-live no IP em geral: impedir que pacotes entrem em loop ou que saiam de determinados limites (como no comando traceroute, que manda pacotes ICMP_ECHO_REQUEST com TTL crescente para que ele alcance roteadores cada vez mais distantes). A cada mrouter pelo qual um pacote multicast passa, o valor do TTL é decrementado. Quando alcança 0, o pacote é descartado. Além disso, para delimitar o trafego entre instituições e países, nos mrouters que estão nas bordas, são estabelecidos limiares de TTL, que impedem que pacotes com um TTL menor que certo valor passem através do túnel. O link LSI<-MCI, por exemplo, tem um TTL de 128. O que significa que se uma transmissão é iniciada com um TTL menor que esse valor, ela não vai ser transmitida para os Estados Unidos. No momento, os TTLS do LSI com instituições de outros estados estão em 64, e estão em 16 para instituições dentro da própria USP.
No IPv6 ou IPng, o broadcast deixa de fazer parte do protocolo IP. Somente se utiliza o multicast. Os roteadores passam a ser também mrouters. Redes locais que já tiverem se convertido a IPv6 poderão se ligar umas as outras através de túneis, como no MBONE.
Em alguns anos, MBONE vai ser igual a Internet.
Prune é uma ordem que um roteador que esteja mais abaixo na árvore de transmissão de dados envia a outro roteador para que este pare de lhe enviar pacotes quando nenhum host serviço por aquele mrouter esta "ouvindo". Isso reduz muito a ocupação de largura de banda é o principal motivo pelo qual não se devem utilizar versões de mrouted anteriores a 3.5. (Existem outros motivos pelos quais não se deve utilizar cada uma das versões anteriores a atual do mrouted. Utilize a mais recente)
8.Protocolos
de Níveis Superiores (Transporte)
Resource Reservation Protocol (RSVP)
O Resource Reservation Protocolo (RSVP) é 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.
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.
Em francês, RSVP significa "Responda, por favor", coloca-se em cartas e convites. No mundo da Internet, RSVP significa Resource Reservation Protocol, ou Protocolo de Reserva de Recursos. Ele serve para permitir algum controle de qualidade de serviço para transmissões de dado baseadas em IP, e ATM.
O RSVP tem de interessante o fato de ser iniciado
pelo host que está recebendo os dados, e não pelo que esta
transmitindo.
Real-Time Transport Protocol (RTP)
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.
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, enquanto 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. O protocolo Real-Time Transport Protocol (RTP) é 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), 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. Na verdade, ele somente especifica alguns dados extras que são enviados no pacote. Esses dados servem principalmente para sincronia.
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 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.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.
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.
9.Sistemas de Videoconferência
Videoconferência não é uma idéia nova, nem original. Disponível desde os anos sessenta, então na forma de sistemas de alto custo em salas de conferência especialmente equipadas, seu objetivo era prover uma nova forma de comunicação entre pessoas dispersas geograficamente e ocupadas o suficiente para não poderem realizar encontros pessoais freqüentemente. Assim, é adequada hoje em dia especialmente para grupos de trabalho distribuídos geograficamente, que encontram dificuldades para realizarem encontros pessoais, levando muitas vezes meses de planejamento para organizarem e conciliarem datas, consumindo tempo e gastos com as viagens dos participantes.
Existe, também, para esses grupos, a possibilidade de se valerem de conferências telefônicas. No entanto, o fato de podermos acrescentar vídeo sincronizado ao som nas sessões de videoconferência, o que não nos é possibilitado nas comunicações telefônicas, representa um grande avanço nas possibilidades de expressividade envolvidas no diálogo uma vez que, sabidamente, a expressão corporal corresponde a 70-80% das impressões de uma conversa .
A videoconferência, além das mídias de áudio e vídeo envolvidas, abre espaço à utilização de ferramentas de compartilhamento de documentos. Essas ferramentas oferecem aos participantes a possibilidade de compartilhar imagens ou documentos, permitindo a visualização e alteração desses aos integrantes do diálogo em tempo real. Alguns sistemas de videoconferência oferecem também compartilhamento de aplicações, onde todos os participantes possuem acesso a uma aplicação sendo executada em um dos microcomputadores participantes; e compartilhamento de informações, viabilizando a transferência de arquivos entre os diversos membros.
Assim, em uma reunião de videoconferência, poderiam existir diversas janelas empregadas para o propósito de se visualizar a pessoa que no momento está com a palavra, ter acesso ao documento ou imagem compartilhado, controlar a transferência de arquivos e, por fim, gerenciar a conferência. Ao observarmos, em nossa tela, os documentos compartilhados, simultaneamente ouvimos o participante da reunião com a palavra salientar pontos e fazer sugestões. Ao comentário de um dos membros, é possível avaliar as faces e julgar as opiniões sobre uma questão. Se solicitado um gráfico ou imagem em especial, esse é transferido para as pessoas que o desejarem.
Além de reuniões de grupos de trabalho, os sistemas de videoconferência são úteis também para empresas que precisam se comunicar com clientes remotos; para empresas que precisam de um funcionário com qualificações específicas para um determinado projeto podendo, desta forma, ser escolhida a pessoa mais indicada não importando sua localização geográfica; para ensino a distância, ao se ministrar aulas e palestras para escolas em locais remotos; para acesso a profissionais da área médica e de áreas especialistas em geral onde é necessário rapidez nas decisões; para pesquisas científicas, viabilizando uma maior e mais rápida divulgação dos resultados obtidos, além de muitas outras aplicações.
Estes sistemas são indicados para reuniões entre grupos de trabalho de organizações, discussões de pesquisa, e outros tipos de conferência que exigem a participação de várias partes.
UNICAST
servidor - cliente - servidor
um fluxo de dados para cada cliente
BROADCAST
servidor - todos os componentes da rede
mesmo fluxo de dados para todos clientes
MULTICAST
servidor - cliente que solicitou os dados
mesmo fluxo de dados só para clientes que solicitaram
Existem diversos sistemas disponíveis para videoconferência, classificados segundo a forma de comunicação que utilizam :
ponto-a-ponto, quando apenas duas pessoas se comunicam;
multiponto, quando há interação recíproca entre muitos participantes;
broadcast (difusão), quando há apresentações para um grupo de pessoas, onde, na maior parte do tempo, apenas uma pessoa está transmitindo e as demais recebendo.
Os sistemas desktop de videoconferência possibilitam a comunicação em tempo real entre grupos de duas ou mais pessoas, independente de suas localizações geográficas, utilizando som e vídeo simultâneamente. Alguns sistemas possibilitam a interação de um grande número de pessoas, todas elas aptas para interagirem entre si. Outros são designados para permitir a comunicação entre apenas duas pessoas, sem a capacidade de comunicações entre grandes grupos.
As comunicações ponto-a-ponto utilizam os sistemas de conferência mais econômicos, freqüentemente executando sobre linhas telefônicas comuns ou linhas ISDN. São sistemas que podem ser utilizados, por exemplo, por pessoas que trabalham fora de seus escritórios, possibilitando a elas a manter contato com seus escritórios e com clientes remotos.
As comunicações multiponto, por sua vez, não podem executar sobre linhas telefônicas normais. Estão disponíveis para linhas ISDN, Internet ou redes locais.
Por fim, nos sistemas de conferência por difusão uma estação transmite o material e um grande grupo de pessoas em diferentes localizações pode receber a transmissão em tempo real simultâneamente. É um método utilizado para transmissões de apresentações comerciais, aulas em ensino a distância, publicações de pesquisas e experimentos, seminários, etc. Estes sistemas são normalmente baseados em Internet, utilizando Multicast Backbone (MBone).
O amplo uso dos sistemas de videoconferência e, em especial, o crescimento de tais sistemas na Internet demandará um volume de recursos computacionais bastante elevado e exigirá, por conseguinte, uma severa política de contenção, a fim de que os recursos atuais não se esgotem brevemente. O MBone surge então como tecnologia capaz de contornar os problemas de demanda através de uma racionalização de gastos, seja salvando largura de banda, seja evitando processamento desnecessário.
Os programas mais populares são o Visual Audio Tool (vat), o Network Video (nv), o Network Voice Terminal (nevot), e o INRIA Videoconferencing System (ivs) para programa de vídeo e áudio, todos eles Freeware.
Além disso novos produtos comerciais para teleconferência usando IP Multicast começaram a emergir, isto inclui o Picture Window, da Bolt Beranek InPerson da Silicon Graphics, e o ShowMe da Sun Microsystems
Uma ferramenta útil para o trabalho interativo de grupos pequenos é o Whiteboard (wb), este mostra um PostSrcip ou um arquivo texto em um espaço de desenho para ser compartilhado, e qualquer dos participantes pode logo a agregar um esboço ou anotações de texto. Todas a anotações são distribuídas e mostradas em tempo real para cada participante. Uma sessão ou aplicação pode ter tools de áudio, vídeo e whiterboard simultaneamente A maioria das sessões públicas transmitidas na Mbone são anunciadas pelo Session Directory (sd). A sessão criadora especifica todos os parâmetros necessários para iniciar as ferramentas para a sessão , incluindo quais programas usar.
Atualmente, existem poucas classes de aplicações no MBone, que se concentram especialmente em áudio, vídeo e documento compartilhado. Entretanto, antes que se possa realizar uma conferência em qualquer um destes cenários, é necessário criar, reservar e anunciar uma sessão de difusão seletiva para transmitir o evento desejado. Para isto, são utilizadas ferramentas de anúncio de sessão.
11.Ferramentas
de Anúncio de Sessão
As ferramentas de anúncio de sessão são utilizadas para criar, reservar e anunciar uma sessão de difusão seletiva que será utilizada para transmitir um evento.
No momento da criação, é reservado um ou mais endereços de difusão seletiva para o evento, podendo ser um endereço para cada classe por onde o evento será transmitido ou um endereço e várias portas, sendo uma porta para cada classe. Estes endereços ficam reservados para o evento por um período de tempo determinado no momento da criação, sendo liberados quando o período de transmissão do evento se encerra. Além de serem utilizadas pelos criadores de uma sessão, estas ferramentas também são utilizadas pelos usuários que desejam participar de grupos específicos. A ferramenta anuncia todos os eventos que estão sendo transmitidos no momento, identificado-os pelos seus nomes, e fornece informações sobre eles, apresentando uma descrição do evento, o período da transmissão, os meios de mídia utilizados pelo evento e os endereços e portas reservados para cada um destes. Em posse destas informações, o usuário pode escolher a quais grupos deseja se participar, e se associar a eles automaticamente pela ferramenta, bastando solicitar que os grupos das mídias desejadas sejam ativadas.
Existem diversas ferramentas deste tipo no MBone, como o Session Directory (SDR) e a Multimidia Conference Control (MMCC).
Será apresentado aqui a Session Directory,
uma das mais utilizadas.
Session Directory (SDR)
A ferramenta SDR é uma substituição para a ferramenta utilizada anteriormente SD. Permite que sejam reservados canais de difusão seletiva de áudio, vídeo e quadro branco para conferências, e que se participe nos diversos grupos anunciados.
A ferramenta possui uma janela principal que mostra quais as sessões estão sendo transmitidas no momento, fornecendo informações sobre elas e executando, caso desejado, as ferramentas de áudio, vídeo, quadro branco e texto nos grupos vinculados ao evento automaticamente
Alguns eventos são constantes, estão sempre acontecendo, como o MBone RTP Audio e o Radio Free Vat (que não aparece nesta porção da janela), por exemplo, que são grupos como estações de rádio do MBone onde todos podem ser disk jockeys. Já outros eventos acontecem temporariamente, transmitindo congressos, apresentações, ou eventos que estão ocorrendo temporariamente. É o caso dos eventos cisco CCIE Forum, Manicoral CBS, NASA-Space Shuttle STS-80 Coverage, e de muitos outros.
Entre as informações da sessão estão os tipos de mídia sendo transmitidos, o endereço classe D utilizado por cada uma destas mídias, o nome e endereço eletrônico originador, o TTL inicial dos datagramas, etc
A ferramenta apresenta também um calendário dos eventos do MBone já anunciados, mostrando os eventos agendados para cada dia. Existe também um site na Internet, denominado MBone Agenda, onde podem ser anunciados previamente os eventos que serão transmitidos em datas futuras, e podem também ser convertidos automaticamente os horários de uma transmissão para os horários locais, já que os horários são anunciados segundo a hora local de cada lugar de origem.
Como já foi dito, a SDR pode ser usada também
para criação de uma sessão, onde devem ser informadas
quais mídias serão utilizadas, o nome e descrição
do evento, o responsável, o escopo do alcance da sessão (definido
pelo TTL), o dia, o horário e a duração.
A ferramenta alocará um endereço livre
por aquele período de tempo, e a sessão será criada.
As ferramentas de áudio do MBone podem ser utilizadas facilmente, necessitando apenas de um alto-falante ou caixas de som para serem utilizadas em estações receptoras. Para transmissão, requerem um microfone conectado a estação transmissora.
Entre as ferramentas de áudio podemos citar
a Visual Audio Tool (VAT), a Network Voice Terminal (Nevot), a INRIA Videoconferencing
System (IVS) e a MAVEN (para Macintosh). Estas ferramentas suportam diversos
padrões de compressão de áudio, tais como o Pulse
Code Modulation (PCM), o Adaptative Differencial Pulse Code Modulation
(ADPCM), o General Special Mobile (GSM) e o Linear Predictive Coder (LPC).
Será apresentada aqui a ferramenta Visual Audio Tool, uma das ferramentas
mais populares.
Visual Audio Tool (VAT)
A Visual Audio Tool (VAT) foi desenvolvida por Van Jacobson e Steve McCanne, no Lawrence Berkeley Labs da University of California, em Berkeley .
Através de sua janela principal, permite que sejam identificados os membros participantes do grupo e o membro transmissor (identificado por um sinal na esquerda do membro) e que seja controlada a ativação do microfone e auto-falante, permitindo regular o volume para ambos. Oferece ainda informações como nome, endereço eletrônico e última transmissão enviada dos membros participantes, obtidas através de um clique sobre o membro. Esta ferramenta oferece uma série de opções de transmissão, permitindo que sejam selecionados o padrão de compressão de dados (PCM, PCM2, PCM4, DVI, DVI2, DVI4, GSM e LPC4) e a prioridade da transmissão, que a sessão seja criptografada e acessada apenas pelos usuários que possuam sua senha, etc.
As ferramentas de vídeo não necessitam de nenhum equipamento adicional na estação para receber vídeo. Utilizam vários algoritmos de compressão, que comprimem os quadros de vídeo de forma bastante significativa numa taxa de até 20:1 .
Entre as ferramentas de vídeo, podemos citar
a VideoConference (VIC), a NetVideo (NV) e a INRIA Videoconferencing System
(utilizada também para áudio).
VideoConference (VIC)
A ferramenta Videoconference foi desenvolvida com arquitetura flexível e extensível para suportar ambientes e configurações heterogêneas. É baseada na versão 2 do protocolo RTP, e esta disponível para a maioria das plataformas Unix, incluindo PCs rodando Linux e BSD/386.
Esta ferramenta apresenta, na janela principal, a imagem em vídeo sendo transmitida, que pode ser aumentada com um clique sobre ela. São fornecidas informações sobre o evento, como originador, taxa de quadros sendo transmitidos e velocidade.
A ferramenta oferece diferentes esquemas de compressão,
utilizando no modo padrão (sem alterações) o esquema
de compressão H.261 e o RTPv2 como o mecanismo de transporte da
aplicação. Oferece ainda controle da velocidade de transmissão
e possibilidade de criptografia. Estas alterações são
feitas na janela Menu, que é acessada com um clique no botão
Menu da janela principal.
NetVideo (NV)
O NV utiliza um algoritmo de compressão de vídeo desenvolvido especialmente para atingir baixa vazão de dados e alta vazão dos quadros, e o protocolo RTP versão 1 no nível de transporte da aplicação.
Assim como na VIC, a janela principal apresenta uma imagem reduzida do vídeo e informações sobre a sessão, tais como nome do originador e TTL inicial dos datagramas. Com um clique sobre a imagem, a janela aumentada da aplicação é disparada.
Na figura abaixo podemos observar uma sessão
do MBONE
14.Ferramentas
de Documentos Compartilhados
As ferramentas de documentos compartilhados permitem que os membros da sessão compartilhem documentos em tempo real, podendo ser efetuadas anotações sobre estes a qualquer momento. São especialmente indicados para transmissões de conferências e aulas de ensino a distância, já que podem ser utilizados como um retro projetor virtual, onde cópias de transparências de uma apresentação para o público local também podem ser apresentadas para os membros virtuais .
Entre as principais ferramentas desta classe podem
ser citadas a WhiteBoard (WB) e o SharedMosaic.
WhiteBoard (WB)
É uma ferramenta que pode ser executada mesmo em condições de baixa quantidade de largura de banda da Internet, atingindo uma vazão muito menor que as aplicações de áudio e vídeo .
A WB permite que várias estações compartilhem documentos em tempo real, podendo ser utilizados documentos em texto ASCII, desenhos, anotações a mão livre e páginas em PostScript.
O controle da sessão é informal, onde todos os participantes podem fazer alterações digitando texto, desenhando gravuras ou fazendo anotações a mão livre sobre a sessão compartilhada. Existem porém características especiais da ferramenta que fornecem algum controle sobre a sessão, como a capacidade de criar uma sessão no modo de conferência (Lecture mode), que garante que nenhuma das alterações efetuadas por estações diferentes da transmissora serão transmitidas para os outros participantes. É oferecido também esquema de criptografia para a sessão.
A ferramenta possui a janela principal, onde é apresentado o documento da sessão, e uma janela adicional que fornece informações sobre o evento tais como participantes, membro que está interagindo no momento, informações sobre os participantes, etc.
15.Vantagens
Obtidas com o Uso de Multicast
Em comunicações tradicionais envolvendo vários sites simultâneamente, para cada pacote do host de origem é feita uma replicação para o número de hosts destinos, e cada pacote é enviado para seu destino separadamente. Este modelo impõe uma limitação no número de máquinas que poderiam estar envolvidas na comunicação, pois o tráfego gerado na rede e as necessidades computacionais do host de origem - que gera cópias de cada pacote - aumentam linearmente com o número de hosts destinos envolvidos.
Por exemplo, um pacote deve ser enviado para os hosts destinos A, B e C. Ele é replicado no host de origem e três cópias são enviadas, consumindo maior desempenho no host X e maior largura de banda na rede, mesmo que alguns dos segmentos de rede sejam comuns aos três.
Existem, porém, tecnologias que tratam estas limitações, sendo chamadas soluções escalares de rede. O uso do multicast IP é uma destas soluções. Utilizando multicast, apenas uma cópia de cada pacote é enviada por linha, sendo copiada apenas quando houver um braço na árvore lógica dos destinos.
A utilização de difusão seletiva
fornece um ganho de processamento de CPU e largura de banda quando vários
sites estão envolvidos simultâneamente.
Figura 1.1 - Serviço unicast
Figura 1.2 - Serviço multicast
Os sistemas interpessoais de videoconferência possibilitam a comunicação em tempo real entre grupos de pessoas, independente de suas localizações geográficas, em áudio e vídeo simultaneamente. Esses sistemas permitem que se trabalhe de forma cooperativa e se compartilhe informações e materiais de trabalho sem a necessidade de locomoção geográfica.
O MBone é uma estratégia de tráfego multimídia que está tendo hoje em dia um crescimento exponencial, graças as vantagens obtidas com o uso de transmissões por difusão seletiva. Isso porque o uso de videoconferência com o MBone proporciona um ganho na utilização de banda e processamento das máquinas envolvidas, já que um único datagrama pode atingir várias sub-redes que possuam uma mesma rota de comunicação com o nodo transmissor, e várias estações nestas sub-redes, sem a necessidade de ser replicado. Como o tráfego de videoconferência, que engloba áudio e vídeo, é bastante intenso, os ganhos obtidos com o uso de difusão seletiva são ainda mais relevantes.
A estratégia MBone está sendo largamente utilizada na Internet para a transmissão de tráfego multimídia devido, em grande parte, a racionalização quanto à utilização dos recursos envolvidos, seja largura de banda, seja tempo de processamento gasto no encaminhamento de pacotes. Como um dos maiores problemas encontrados hoje na Internet é o crescimento incontrolável de máquinas e de usuários ansiosos por terem acesso às facilidades oferecidas nesta rede, é de se acreditar que, futuramente, a fim de contornar esta demanda explosiva por recursos computacionais, o MBone se torne o padrão de fato para transmissão de multimídia.
http://penta2.ufrj.br/redes296/mbone/protocol.htm
http://penta2.ufrgs.br/rc952/trab2/hl_tools.html
http://www.inf.ufrgs.br/~paschoal/multicast_tutorial/tutorial.html
http://www.penta.ufrgs.br/~cristina/mbone/ti/indiceti.htm
http://penta2.ufrgs.br/redes296/mbone/indice.htm
http://www.dcc.ufrj.br/shm/adonis/mbone.htm
http://www.insite.com.br/tech/mbone/.
TAN 96] TANENBAUM, A. Computer Networks. Third Edition, Prentice Hall, 1996