tipo: Documentos
publicado em: 27 de junho de 1999
por: CGI.br
idiomas:
publicado em: 27 de junho de 1999
por: CGI.br
idiomas:
Comitê Gestor da Internet/Brasil
Grupo de Trabalho de Engenharia e Operação de Redes (GT-ER)
Sub-grupo de Trabalho em IP-Multicast e MBone-BR
Autor: João Carlos Mendes Luís
Coordenador do Sub-grupo
jonny@jonny.eng.br
Resumo
O uso de IP-Multicast vem se difundindo desde a criação do MBone, uma rede de túneis interligando sub-redes com suporte a IP-Multicast nativo. O IP-Multicast é muito importante do ponto de vista tecnológico por suas vantagens em relação à utilização eficiente de recursos de comunicação em rede, bem como à escalabilidade de comunicações multiponto. Este artigo apresenta o IP-Multicast e propõe regras para a criação e manutenção de uma seção Brasileira do MBone, o MBone-BR.
1. Introdução
O uso de IP-Multicast vem se difundindo na Internet desde a primeira transmissão pública em 1994 [MBONE], quando uma conferência do IETF (Internet Engineering Task Force) foi transmitida ao vivo para dezenas de participantes em todo o mundo. Essa transmissão foi realizada através do MBone, uma rede de túneis interligando várias sub-redes locais com suporte a IP-Multicast.
A tecnologia de IP-Multicast já vem sendo utilizada no Brasil, desde 1994, onde um congresso internacional no Rio de Janeiro divulgou suas sessões através do MBone [ITS94]. Na época a transmissão foi realizada apenas para o exterior, devido à baixa capacidade dos canais de comunicação nacionais.
Com o aumento da capacidade dos canais de comunicação nacionais, algumas iniciativas regionais de ligação ao MBone foram realizadas no país. Essas redes regionais, entretanto, não se falavam, por não haver uma coordenação nacional com este objetivo.
Pouco depois, por iniciativa de alguns usuários, pequenas redes locais foram interligadas via túneis MBone, ao longo de boa parte do território brasileiro. Essa malha de redes foi chamada à época de MBone-BR. Essas iniciativa, entretanto, não dispunha de apoio oficial e terminou por ruir.
Este documento apresenta a tecnologia de IP-Multicast e propõe uma estrutura inicial para uma implementação oficial do MBone-BR.
2. IP-Multicast
O IP-Multicast é uma tecnologia que permite a um transmissor enviar informações para vários receptores simultaneamente, de forma eficiente. Esse tipo de comunicação, conhecida também como comunicação multiponto ou de grupo, é mais eficiente que uma comunicação broadcast por permitir a recepção dos dados apenas por membros de um grupo previamente definido, em vez de inundar os dados para toda a rede. É mais eficiente que várias comunicações unicast (ponto a ponto) simultâneas por fazer melhor uso do meio de comunicação, evitando redundância de informação trafegada.
A principal vantagem do uso de IP-Multicast reside no fato deste permitir a implementação eficiente de sistemas de comunicação multiponto, com uma ocupação efetiva do canal de comunicação bem menor em comparação a uma comunicação multiponto realizada com várias conexões unicast. Além de proporcionar uma maior economia de recursos de rede, esta característica ressalta as possibilidades de uso escalável de aplicações multiponto.
Os sistemas de aplicações multiponto podem ser divididos nos seguintes tipos principais: Sistemas de difusão (broadcasting), sistemas distribuídos e sistemas tolerantes a falhas.
Entre as aplicações existentes mais comuns podemos citar as aplicações de conferência, tanto de áudio [VAT, IVS] e vídeo [VIC, IVS, NV] como de outras mídias: texto [NTE], imagem [IMM, WB], etc. Temos ainda aplicações de anúncio de sessões [SDR], sincronização de relógio [NTP], roteamento [RIPv2, OSPF], WWW cache distribuído (Squid) [ICP], e várias outras [MERIT].
Aplicações futuras podem incluir sistemas de processamento de dados distribuído e/ou redundante, sistemas de distribuição de arquivos (espelhamento de ftp, news feed, etc), e até mesmo outras aplicações ainda não imaginadas.
Algumas aplicações já existentes poderiam ser melhor utilizadas se tivessem sido criadas com o IP-Multicast em mente. Estas aplicações acabaram sendo feitas sobre unicast por falta de suporte global para IP-Multicast na infraestrutura de Internet mundial. Os exemplos mais clássicos deste problema são o WebPush e aplicações tipo RealAudio e RealVideo.
2.1. Desvantagens do IP-Multicast
As desvantagens do IP-Multicast podem ser resumidas da seguinte forma:
Primeiro, por ser um padrão ainda não estabelecido, em fase de estudos, as técnicas para uso em roteamento, transporte e aplicações ainda estão em desenvolvimento.
Além disso, a tecnologia ainda não é universal. Vários sistemas operacionais ainda não possuem suporte a IP-Multicast. Equipamentos de roteamento de alta capacidade utilizados no núcleo da Internet, e que não suportam Multicast, são de difícil atualização, em vista de seu custo.
Finalmente, os programadores de aplicações não se interessam em criar aplicações para este tipo de comunicação por que não há infraestrutura disponível para os usuários. Da mesma forma, não há interesse em se criar essa infraestrutura por que não existem aplicações, criando assim um círculo vicioso.
2.2. Fatos e Mitos
Existem vários comentários técnicos contra a implementação de IP Multicast. Alguns são reais, mas outros são apenas fruto do desconhecimento.
Fato: O IP-Multicast possui controle de fluxo ineficiente. A maioria das aplicações atuais se utiliza do protocolo UDP como mecanismo de transporte. Esse protocolo não apresenta nenhum tipo de controle de fluxo, deixando esse controle por conta da aplicação. Efetivamente, o tráfego de aplicações sem controle de fluxo provoca um congestionamento nos pontos de maior gargalo de comunicação. O uso de novos protocolos de transporte, ou de mecanismos de reserva e controle de uso de recursos deve melhorar este problema, mas estes mecanismos ainda não estão em larga escala de uso.
Fato: O roteamento do IP-Multicast consome muita memória nos roteadores. Esse problema ocorre devido à forma com que o roteamento multicast foi criado, necessitando manter o estado de cada fluxo em cada roteador. Esse problema pode ser minimizado ou controlado utilizando máquinas dedicadas para o roteamento multicast, independente do roteamento unicast. Além disso, com o surgimento de novas tecnologias tanto de roteamento como de equipamentos esse problema deve ser minimizado rapidamente.
Mito: O MBone consome muita largura de banda apenas por existir. Existem sim problemas de controle de largura de banda, mas esses problemas não são inerentes ao uso de IP-Multicast. Eles se devem em sua totalidade a bugs de software e problemas de gerenciamento. Uma rede bem configurada pode obter um overhead de tráfego devido ao uso do Multicast praticamente nulo. Já existem vários relatos de usuários ao redor do mundo que se interligam ao MBone através de modems domésticos.
Mito: Somente o sistema operacional Unix suporta IP-Multicast. Vários sistemas operacionais já apresentam suporte ao IP-Multicast, incluindo a família Microsoft Windows(TM).
3. Instalação
Antes de se iniciar uma proposta de instalação do MBone-BR, é necessário se fazer uma análise da sua viabilidade. Em primeiro lugar, para se criar uma infraestrutura de comunicação, é necessário que todas as partes envolvidas estejam interessadas, ou o serviço não será universal. Além disso, como as principais aplicações atualmente em uso no MBone são do tipo vídeo-conferência, deve-se avaliar a existência de largura de banda disponível nos canais de comunicação envolvidos. Mesmo que não haja tal disponibilidade, ainda assim o MBone pode ser útil para outro tipo de aplicação. Finalmente, devem haver condições de gerenciamento e monitoração constante do tráfego multicast e da configuração do MBone-BR.
A proposta de implementação do MBone-BR deve começar com a caracterização de pessoas-chave para contato tanto em caso de problemas, como de novas conexões e alterações na configuração dos pontos de maior problema.
A instalação do MBone-BR, assim como foi com a Internet, não deve se dar de forma instantânea, sendo necessárias várias etapas consecutivas de implementação e análise dos resultados. Este documento apresenta uma proposta inicial para esta instalação.
3.1. Proposta de Instalação
Esta seção apresenta algumas recomendações individuais para a instalação do MBone-BR. Estas recomendações podem ser modificadas ao longo do tempo, por aprovação do sub-grupo de trabalho, em função de resultados de análise realizados durante a operação.
3.1.1. Roteamento e túneis
Inicialmente, para as funções de roteamento recomenda-se o uso de estações Unix utilizando mrouted 3.9beta3 ou superior [MROUTED]. Nos pontos onde o roteamento for executado por equipamentos dedicados a essa função, devem ser utilizados túneis DVMRP [DVMRP]. Com a estabilização desta etapa, monitoração e avaliação positiva da mesma, podem ser feitas experiências no sentido de utilizar outros protocolos de roteamento.
As principais vantagens do uso deste método residem no fato de não ser necessário mexer nos roteadores principais, utilizar um protocolo mais conhecido e necessitar apenas de hardware de baixo custo. Para uma implementação destas, um pequeno microcomputador, possivelmente já sem uso, pode ser aproveitado para roteador multicast utilizando apenas software de dominio publico, como o FreeBSD ou o Linux.
3.1.2. Acesso internacional ao MBone
Nesta etapa inicial da instalação do MBone-BR deve-se utilizar um único acesso ao MBone internacional. Esta recomendação tem por objetivo iniciar a instalação sem maiores problemas referentes a loops e configuração de rotas internacionais. Recomenda-se para este acesso o uso dos canais internacionais da rede ANSP, pois os maiores usuários da primeira etapa serão basicamente acadêmicos, e em sua maioria localizados no estado de São Paulo.
3.1.3. Configuração métrica dos túneis
As recomendações comuns para TTL de pacotes IP-Multicast são as seguintes:
Os mesmo valores utilizados para o TTL inicial de uma restrição eram utilizados na configuração do threshold dos roteadores de borda da região. Esta recomendação é baseada em considerações antigas, e relativas a configurações de redes utilizadas em outros países. Uma proposta mais coerente para o tipo de configuração da rede nacional é a seguinte:
Propostas mais recentes sugerem o controle do threshold em função da largura de banda disponível, e não da região de divulgação. Esta proposta deve ser analisada pelo sub-grupo levando em consideração a experiência obtida com as primeiras instalações.
O valor da métrica utilizada deve ser unitário, exceto sob condições de loops controlados (a serem aprovados pelo sub-grupo de trabalho). Um caso especial de condição de loop controlado é a ligação de mais de um acesso internacional e dos acessos inter-regionais.
3.1.4. Monitoração
As redes regionais devem ser monitoradas pelos responsáveis regionais. Uma pessoa responsável deve ser indicada pelo Comitê Gestor para a gerência e monitoração dos túneis nacionais. A gerência, tanto regional como nacional, deve se encarregar de manter mapas atualizados da malha de túneis e roteadores, monitorando o crescimento dos ramos e sub-ramos, evitando loops, duplicações, rotas ineficientes e outros problemas de gerenciamento.
Deve haver uma monitoração gráfica do tráfego nos pontos principais da rede. Uma forma simples e gratuita de monitoração é através da utilização do software MRTG, que constrói gráficos de utilização através de informações obtidas via SNMP ou outras formas configuráveis [MRTG].
Estas informações devem estar disponíveis publicamente, no website do sub-grupo, ou em outra página a ser definida.
3.2. Manutenção e evolução
A evolução do MBone-BR a partir da instalação inicial deve ser constante. O coordenador regional ou nacional deve especificar o ponto de ligação de novos membros do MBone-BR. O sub-grupo de trabalho deve analisar os resultados obtidos, baseando-se nas medidas e nas experiências dos usuários e gerentes de redes, e propor novas recomendações.
Em particular estudos no sentido de avaliar a possibilidade de uso de outros protocolos de roteamento [PIM-SM, MBGP, BGMP] e a migração do roteamento para os roteadores centrais devem ser incentivados. Também é importante a análise da viabilidade do uso de múltiplos acessos internacionais, tendo especial cuidado com o controle de rotas utilizadas e loops de comunicação através do exterior.
Também deve ser estudado pelo sub-grupo de trabalho as possíveis implicações de segurança geradas pelo MBone-BR.
4. Apoio e Incentivos
Para garantir a continuidade do MBone-BR, devem ser incentivados projetos nacionais de pesquisa e uso do MBone.
Um serviço NTP em multicast seria de grande utilidade para os sistemas de gerência de rede, facilitando a sincronização entre os equipamentos da Internet Brasil. Isso é de grande importância para análise de relatórios de segurança, de forma a melhor identificar os padrões de ataques e tentativas de invasão espalhados pelo país. O Grupo de Trabalho em Segurança de Redes do Comitê Gestor tem especial interesse nesta implementação.
Também seria interessante do ponto de vista do usuário final o incentivo ao provimento de conteúdo. É bastante fácil se criar uma estação transmissora de áudio e vídeo utilizando-se apenas de um Micro com capacidade de multimídia ligado ao MBone. Determinadas estações de Rádio e TV educativas poderiam ser contactadas para incentivar a sua participação neste projeto piloto.
Finalmente, devem ser incentivados os estudos de novas tecnologias e aplicações utilizando IP-Multicast. Já faz algum tempo que a comunidade acadêmica brasileira vem apresentando interesse em comunicações multiponto, e a presença de um "testbed" onde poderiam fazer novas experiências viria a facilitar muito estas pesquisas. Novos projetos de cunho mais prático podem agora ser colocados em pauta, sendo importante o financiamento destes projetos. Entre as áreas mais promissoras para as aplicações multiponto podem ser destacadas as áreas de Realidade Virtual distribuída e entretenimento (jogos).
5. Conclusão
Este documento apresentou a motivação para o uso de IP-Multicast, e uma proposta para a implementação do MBone-BR.
6. Referências
[NTP]
Dave L. Mills, "Network Time Protocol (Version 3)
Specification, Implementation", Network Working Group Request for Comments: 1305, University of Delaware, Mar 1992.
[MBONE]
Michael R. Macedonia and Donald P. Brutzman, "MBone Provides Audio and Video Across the Internet", IEEE Computer, Apr 1994, Vol. 27, No. 4, pp. 30-36.
[ITS94]
Luís F. M. de Moraes e Stephen B. Weinstein, "The Internet Multicast from ITS: How it was Done and Implications for the Future", IEEE Communications Magazine, Jan 1995, pp. 6-8.
[MRTG]
Multi Router Traffic Grapher.
http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html
[VAT]
Visual Audio Tool.
http://mice.ed.ac.uk/
[IVS]
INRIA Videoconferencing System.
http://www-sop.inria.fr/rodeo/ivs.html
[VIC]
Video Conferencing Tool.
http://mice.ed.ac.uk/
[NV]
Network Video Tool.
http://mice.ed.ac.uk/
[NTE]
NetText Tool.
http://mice.ed.ac.uk/
[IMM]
Image Multicaster Client.
http://mice.ed.ac.uk/
[WB]
Shared Whiteboard.
http://mice.ed.ac.uk/
[SDR]
Session Directory.
http://mice.ed.ac.uk/
[RIPv2]
G. Malkin, "RIP Version 2", Network Working Group Request for Comments: 2453, Bay Networks, Nov 1998.
[OSPF]
J. Moy, "Open Shortest Path First (OSPF) TCP/IP internet routing protocol, Version 2", Network Working Group Request for Comments: 2328, Apr 1998.
[ICP]
D. Wessels and K. Claffy, "Application of Internet Cache Protocol (ICP), version 2", Network Working Group Request for Comments: 2187, National Laboratory for Applied Network Research/UCSD, Sep 1997.
[MERIT]
MBone Software Archives, Index of MBone Software by Category.
http://nic.merit.edu/~mbone/index/titles.html (conteúdo não disponível)
[MROUTED]
Multicast Routing Daemon.
ftp://parcftp.xerox.com/pub/net-research/ipmulti/beta-test/
[DVMRP]
D. Waitzman and C. Partridge, "Distance Vector Multicast Routing Protocol", Network Working Group Request For Comments: 1075, Nov 1988.
[PIM-SM]
D. Estrin et al, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol", Network Working Group Request for Comments: 2362, Jun 1998.
[MBGP]
Multicast Border Gateway Protocol (MBGP); MBGP is based on RFC 2283, Multiprotocol Extensions for BGP-4.
http://ftp.univ-lyon1.fr/reseau/ip/multicast/pim/mbgp.html
[BGMP]
D. Thaler et al, "Border Gateway Multicast Protocol (BGMP): Protocol Specification", Internet Engineering Task Force, IDMR Working Group, draft-ietf-idmr-gum-03, Aug 1998.
Grupo de Trabalho de Engenharia e Operação de Redes (GT-ER)
Sub-grupo de Trabalho em IP-Multicast e MBone-BR
Autor: João Carlos Mendes Luís
Coordenador do Sub-grupo
jonny@jonny.eng.br
Resumo
O uso de IP-Multicast vem se difundindo desde a criação do MBone, uma rede de túneis interligando sub-redes com suporte a IP-Multicast nativo. O IP-Multicast é muito importante do ponto de vista tecnológico por suas vantagens em relação à utilização eficiente de recursos de comunicação em rede, bem como à escalabilidade de comunicações multiponto. Este artigo apresenta o IP-Multicast e propõe regras para a criação e manutenção de uma seção Brasileira do MBone, o MBone-BR.
1. Introdução
O uso de IP-Multicast vem se difundindo na Internet desde a primeira transmissão pública em 1994 [MBONE], quando uma conferência do IETF (Internet Engineering Task Force) foi transmitida ao vivo para dezenas de participantes em todo o mundo. Essa transmissão foi realizada através do MBone, uma rede de túneis interligando várias sub-redes locais com suporte a IP-Multicast.
A tecnologia de IP-Multicast já vem sendo utilizada no Brasil, desde 1994, onde um congresso internacional no Rio de Janeiro divulgou suas sessões através do MBone [ITS94]. Na época a transmissão foi realizada apenas para o exterior, devido à baixa capacidade dos canais de comunicação nacionais.
Com o aumento da capacidade dos canais de comunicação nacionais, algumas iniciativas regionais de ligação ao MBone foram realizadas no país. Essas redes regionais, entretanto, não se falavam, por não haver uma coordenação nacional com este objetivo.
Pouco depois, por iniciativa de alguns usuários, pequenas redes locais foram interligadas via túneis MBone, ao longo de boa parte do território brasileiro. Essa malha de redes foi chamada à época de MBone-BR. Essas iniciativa, entretanto, não dispunha de apoio oficial e terminou por ruir.
Este documento apresenta a tecnologia de IP-Multicast e propõe uma estrutura inicial para uma implementação oficial do MBone-BR.
2. IP-Multicast
O IP-Multicast é uma tecnologia que permite a um transmissor enviar informações para vários receptores simultaneamente, de forma eficiente. Esse tipo de comunicação, conhecida também como comunicação multiponto ou de grupo, é mais eficiente que uma comunicação broadcast por permitir a recepção dos dados apenas por membros de um grupo previamente definido, em vez de inundar os dados para toda a rede. É mais eficiente que várias comunicações unicast (ponto a ponto) simultâneas por fazer melhor uso do meio de comunicação, evitando redundância de informação trafegada.
A principal vantagem do uso de IP-Multicast reside no fato deste permitir a implementação eficiente de sistemas de comunicação multiponto, com uma ocupação efetiva do canal de comunicação bem menor em comparação a uma comunicação multiponto realizada com várias conexões unicast. Além de proporcionar uma maior economia de recursos de rede, esta característica ressalta as possibilidades de uso escalável de aplicações multiponto.
Os sistemas de aplicações multiponto podem ser divididos nos seguintes tipos principais: Sistemas de difusão (broadcasting), sistemas distribuídos e sistemas tolerantes a falhas.
Entre as aplicações existentes mais comuns podemos citar as aplicações de conferência, tanto de áudio [VAT, IVS] e vídeo [VIC, IVS, NV] como de outras mídias: texto [NTE], imagem [IMM, WB], etc. Temos ainda aplicações de anúncio de sessões [SDR], sincronização de relógio [NTP], roteamento [RIPv2, OSPF], WWW cache distribuído (Squid) [ICP], e várias outras [MERIT].
Aplicações futuras podem incluir sistemas de processamento de dados distribuído e/ou redundante, sistemas de distribuição de arquivos (espelhamento de ftp, news feed, etc), e até mesmo outras aplicações ainda não imaginadas.
Algumas aplicações já existentes poderiam ser melhor utilizadas se tivessem sido criadas com o IP-Multicast em mente. Estas aplicações acabaram sendo feitas sobre unicast por falta de suporte global para IP-Multicast na infraestrutura de Internet mundial. Os exemplos mais clássicos deste problema são o WebPush e aplicações tipo RealAudio e RealVideo.
2.1. Desvantagens do IP-Multicast
As desvantagens do IP-Multicast podem ser resumidas da seguinte forma:
Primeiro, por ser um padrão ainda não estabelecido, em fase de estudos, as técnicas para uso em roteamento, transporte e aplicações ainda estão em desenvolvimento.
Além disso, a tecnologia ainda não é universal. Vários sistemas operacionais ainda não possuem suporte a IP-Multicast. Equipamentos de roteamento de alta capacidade utilizados no núcleo da Internet, e que não suportam Multicast, são de difícil atualização, em vista de seu custo.
Finalmente, os programadores de aplicações não se interessam em criar aplicações para este tipo de comunicação por que não há infraestrutura disponível para os usuários. Da mesma forma, não há interesse em se criar essa infraestrutura por que não existem aplicações, criando assim um círculo vicioso.
2.2. Fatos e Mitos
Existem vários comentários técnicos contra a implementação de IP Multicast. Alguns são reais, mas outros são apenas fruto do desconhecimento.
Fato: O IP-Multicast possui controle de fluxo ineficiente. A maioria das aplicações atuais se utiliza do protocolo UDP como mecanismo de transporte. Esse protocolo não apresenta nenhum tipo de controle de fluxo, deixando esse controle por conta da aplicação. Efetivamente, o tráfego de aplicações sem controle de fluxo provoca um congestionamento nos pontos de maior gargalo de comunicação. O uso de novos protocolos de transporte, ou de mecanismos de reserva e controle de uso de recursos deve melhorar este problema, mas estes mecanismos ainda não estão em larga escala de uso.
Fato: O roteamento do IP-Multicast consome muita memória nos roteadores. Esse problema ocorre devido à forma com que o roteamento multicast foi criado, necessitando manter o estado de cada fluxo em cada roteador. Esse problema pode ser minimizado ou controlado utilizando máquinas dedicadas para o roteamento multicast, independente do roteamento unicast. Além disso, com o surgimento de novas tecnologias tanto de roteamento como de equipamentos esse problema deve ser minimizado rapidamente.
Mito: O MBone consome muita largura de banda apenas por existir. Existem sim problemas de controle de largura de banda, mas esses problemas não são inerentes ao uso de IP-Multicast. Eles se devem em sua totalidade a bugs de software e problemas de gerenciamento. Uma rede bem configurada pode obter um overhead de tráfego devido ao uso do Multicast praticamente nulo. Já existem vários relatos de usuários ao redor do mundo que se interligam ao MBone através de modems domésticos.
Mito: Somente o sistema operacional Unix suporta IP-Multicast. Vários sistemas operacionais já apresentam suporte ao IP-Multicast, incluindo a família Microsoft Windows(TM).
3. Instalação
Antes de se iniciar uma proposta de instalação do MBone-BR, é necessário se fazer uma análise da sua viabilidade. Em primeiro lugar, para se criar uma infraestrutura de comunicação, é necessário que todas as partes envolvidas estejam interessadas, ou o serviço não será universal. Além disso, como as principais aplicações atualmente em uso no MBone são do tipo vídeo-conferência, deve-se avaliar a existência de largura de banda disponível nos canais de comunicação envolvidos. Mesmo que não haja tal disponibilidade, ainda assim o MBone pode ser útil para outro tipo de aplicação. Finalmente, devem haver condições de gerenciamento e monitoração constante do tráfego multicast e da configuração do MBone-BR.
A proposta de implementação do MBone-BR deve começar com a caracterização de pessoas-chave para contato tanto em caso de problemas, como de novas conexões e alterações na configuração dos pontos de maior problema.
A instalação do MBone-BR, assim como foi com a Internet, não deve se dar de forma instantânea, sendo necessárias várias etapas consecutivas de implementação e análise dos resultados. Este documento apresenta uma proposta inicial para esta instalação.
3.1. Proposta de Instalação
Esta seção apresenta algumas recomendações individuais para a instalação do MBone-BR. Estas recomendações podem ser modificadas ao longo do tempo, por aprovação do sub-grupo de trabalho, em função de resultados de análise realizados durante a operação.
3.1.1. Roteamento e túneis
Inicialmente, para as funções de roteamento recomenda-se o uso de estações Unix utilizando mrouted 3.9beta3 ou superior [MROUTED]. Nos pontos onde o roteamento for executado por equipamentos dedicados a essa função, devem ser utilizados túneis DVMRP [DVMRP]. Com a estabilização desta etapa, monitoração e avaliação positiva da mesma, podem ser feitas experiências no sentido de utilizar outros protocolos de roteamento.
As principais vantagens do uso deste método residem no fato de não ser necessário mexer nos roteadores principais, utilizar um protocolo mais conhecido e necessitar apenas de hardware de baixo custo. Para uma implementação destas, um pequeno microcomputador, possivelmente já sem uso, pode ser aproveitado para roteador multicast utilizando apenas software de dominio publico, como o FreeBSD ou o Linux.
3.1.2. Acesso internacional ao MBone
Nesta etapa inicial da instalação do MBone-BR deve-se utilizar um único acesso ao MBone internacional. Esta recomendação tem por objetivo iniciar a instalação sem maiores problemas referentes a loops e configuração de rotas internacionais. Recomenda-se para este acesso o uso dos canais internacionais da rede ANSP, pois os maiores usuários da primeira etapa serão basicamente acadêmicos, e em sua maioria localizados no estado de São Paulo.
3.1.3. Configuração métrica dos túneis
As recomendações comuns para TTL de pacotes IP-Multicast são as seguintes:
| Restrição | TTL Inicial |
| Máquina | 0 |
| Sub-Rede | 1 |
| Sítio | 32 |
| Região | 64 |
| Continente | 128 |
Os mesmo valores utilizados para o TTL inicial de uma restrição eram utilizados na configuração do threshold dos roteadores de borda da região. Esta recomendação é baseada em considerações antigas, e relativas a configurações de redes utilizadas em outros países. Uma proposta mais coerente para o tipo de configuração da rede nacional é a seguinte:
| Restrição | Threshold |
| Laboratório | 8 |
| Instituição | 16 |
| Região | 32 |
| Backbone Nacional | 64 |
| País | 128 |
Propostas mais recentes sugerem o controle do threshold em função da largura de banda disponível, e não da região de divulgação. Esta proposta deve ser analisada pelo sub-grupo levando em consideração a experiência obtida com as primeiras instalações.
O valor da métrica utilizada deve ser unitário, exceto sob condições de loops controlados (a serem aprovados pelo sub-grupo de trabalho). Um caso especial de condição de loop controlado é a ligação de mais de um acesso internacional e dos acessos inter-regionais.
3.1.4. Monitoração
As redes regionais devem ser monitoradas pelos responsáveis regionais. Uma pessoa responsável deve ser indicada pelo Comitê Gestor para a gerência e monitoração dos túneis nacionais. A gerência, tanto regional como nacional, deve se encarregar de manter mapas atualizados da malha de túneis e roteadores, monitorando o crescimento dos ramos e sub-ramos, evitando loops, duplicações, rotas ineficientes e outros problemas de gerenciamento.
Deve haver uma monitoração gráfica do tráfego nos pontos principais da rede. Uma forma simples e gratuita de monitoração é através da utilização do software MRTG, que constrói gráficos de utilização através de informações obtidas via SNMP ou outras formas configuráveis [MRTG].
Estas informações devem estar disponíveis publicamente, no website do sub-grupo, ou em outra página a ser definida.
3.2. Manutenção e evolução
A evolução do MBone-BR a partir da instalação inicial deve ser constante. O coordenador regional ou nacional deve especificar o ponto de ligação de novos membros do MBone-BR. O sub-grupo de trabalho deve analisar os resultados obtidos, baseando-se nas medidas e nas experiências dos usuários e gerentes de redes, e propor novas recomendações.
Em particular estudos no sentido de avaliar a possibilidade de uso de outros protocolos de roteamento [PIM-SM, MBGP, BGMP] e a migração do roteamento para os roteadores centrais devem ser incentivados. Também é importante a análise da viabilidade do uso de múltiplos acessos internacionais, tendo especial cuidado com o controle de rotas utilizadas e loops de comunicação através do exterior.
Também deve ser estudado pelo sub-grupo de trabalho as possíveis implicações de segurança geradas pelo MBone-BR.
4. Apoio e Incentivos
Para garantir a continuidade do MBone-BR, devem ser incentivados projetos nacionais de pesquisa e uso do MBone.
Um serviço NTP em multicast seria de grande utilidade para os sistemas de gerência de rede, facilitando a sincronização entre os equipamentos da Internet Brasil. Isso é de grande importância para análise de relatórios de segurança, de forma a melhor identificar os padrões de ataques e tentativas de invasão espalhados pelo país. O Grupo de Trabalho em Segurança de Redes do Comitê Gestor tem especial interesse nesta implementação.
Também seria interessante do ponto de vista do usuário final o incentivo ao provimento de conteúdo. É bastante fácil se criar uma estação transmissora de áudio e vídeo utilizando-se apenas de um Micro com capacidade de multimídia ligado ao MBone. Determinadas estações de Rádio e TV educativas poderiam ser contactadas para incentivar a sua participação neste projeto piloto.
Finalmente, devem ser incentivados os estudos de novas tecnologias e aplicações utilizando IP-Multicast. Já faz algum tempo que a comunidade acadêmica brasileira vem apresentando interesse em comunicações multiponto, e a presença de um "testbed" onde poderiam fazer novas experiências viria a facilitar muito estas pesquisas. Novos projetos de cunho mais prático podem agora ser colocados em pauta, sendo importante o financiamento destes projetos. Entre as áreas mais promissoras para as aplicações multiponto podem ser destacadas as áreas de Realidade Virtual distribuída e entretenimento (jogos).
5. Conclusão
Este documento apresentou a motivação para o uso de IP-Multicast, e uma proposta para a implementação do MBone-BR.
6. Referências
[NTP]
Dave L. Mills, "Network Time Protocol (Version 3)
Specification, Implementation", Network Working Group Request for Comments: 1305, University of Delaware, Mar 1992.
[MBONE]
Michael R. Macedonia and Donald P. Brutzman, "MBone Provides Audio and Video Across the Internet", IEEE Computer, Apr 1994, Vol. 27, No. 4, pp. 30-36.
[ITS94]
Luís F. M. de Moraes e Stephen B. Weinstein, "The Internet Multicast from ITS: How it was Done and Implications for the Future", IEEE Communications Magazine, Jan 1995, pp. 6-8.
[MRTG]
Multi Router Traffic Grapher.
http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html
[VAT]
Visual Audio Tool.
http://mice.ed.ac.uk/
[IVS]
INRIA Videoconferencing System.
http://www-sop.inria.fr/rodeo/ivs.html
[VIC]
Video Conferencing Tool.
http://mice.ed.ac.uk/
[NV]
Network Video Tool.
http://mice.ed.ac.uk/
[NTE]
NetText Tool.
http://mice.ed.ac.uk/
[IMM]
Image Multicaster Client.
http://mice.ed.ac.uk/
[WB]
Shared Whiteboard.
http://mice.ed.ac.uk/
[SDR]
Session Directory.
http://mice.ed.ac.uk/
[RIPv2]
G. Malkin, "RIP Version 2", Network Working Group Request for Comments: 2453, Bay Networks, Nov 1998.
[OSPF]
J. Moy, "Open Shortest Path First (OSPF) TCP/IP internet routing protocol, Version 2", Network Working Group Request for Comments: 2328, Apr 1998.
[ICP]
D. Wessels and K. Claffy, "Application of Internet Cache Protocol (ICP), version 2", Network Working Group Request for Comments: 2187, National Laboratory for Applied Network Research/UCSD, Sep 1997.
[MERIT]
MBone Software Archives, Index of MBone Software by Category.
http://nic.merit.edu/~mbone/index/titles.html (conteúdo não disponível)
[MROUTED]
Multicast Routing Daemon.
ftp://parcftp.xerox.com/pub/net-research/ipmulti/beta-test/
[DVMRP]
D. Waitzman and C. Partridge, "Distance Vector Multicast Routing Protocol", Network Working Group Request For Comments: 1075, Nov 1988.
[PIM-SM]
D. Estrin et al, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol", Network Working Group Request for Comments: 2362, Jun 1998.
[MBGP]
Multicast Border Gateway Protocol (MBGP); MBGP is based on RFC 2283, Multiprotocol Extensions for BGP-4.
http://ftp.univ-lyon1.fr/reseau/ip/multicast/pim/mbgp.html
[BGMP]
D. Thaler et al, "Border Gateway Multicast Protocol (BGMP): Protocol Specification", Internet Engineering Task Force, IDMR Working Group, draft-ietf-idmr-gum-03, Aug 1998.
O conteúdo publicado no site CGI.br está licenciado com a Licença Creative Commons - Atribuição-CompartilhaIgual 4.0 Internacional a menos que condições e/ou restrições adicionais específicas estejam claramente explícitas na página correspondente.