NewsGeneration: um serviço oferecido pela RNP desde 1997


ISSN 1518-5974
Boletim bimestral sobre tecnologia de redes
produzido e publicado pela  RNP – Rede Nacional de Ensino e Pesquisa
21 de maio de 2002 | volume 6, número 3

volta à página inicial de NewsGeneration

Nesta edição:

Piloto de serviço IPv6: procedimento de configuração de DNS

Multicast nativo no backbone RNP2: panorama atual de implantação

Considerações acerca do estabelecimento de QoS no RNP2

Bookmarks



NewsGeneration:



Artigos publicados

Autores

FAQ

Assine

Página inicial

Multicast nativo no backbone RNP2: panorama atual de implantação

Adenilson Raniery <>

Centro de Engenharia e Operações (CEO)
Rede Nacional de Ensino e Pesquisa (RNP)

Resumo
1. Introdução
2. Infra-estrutura multicast intradomínio
2.1 Rendezvous Point
3. Multicast interdomínio: conexão à Internet2
4. Experimentos realizados
4.1 Transmissão multicast do SBRC 2001 (Simpósio Brasileiro de Redes de Computadores)
4.2 AccessGrid
4.3 IMPA
5. Distribuição regional de multicast
5.1 Interconexão PIM-SM/DVMRP
6. Recursos para monitoração
7. Considerações finais
Anexo A - Configurações de multicast nos roteadores
Referências bibliográficas

Resumo

Este artigo descreve o estágio atual da infra-estrutura de multicast no backbone RNP2. São apresentados aspectos relativos à topologia, protocolos utilizados para roteamento multicast e resultados gerais verificados com a implantação e uso desta infra-estrutura. O artigo inclui trechos de configuração de roteadores do backbone para ilustrar de forma mais efetiva os conceitos discutidos neste artigo.

^

1. Introdução

Durante o ano de 2001, a RNP realizou diversos testes com a tecnologia multicast em seu backbone. Eles fizeram parte de um projeto piloto na área de multicast, cujo objetivo principal era adquirir conhecimento técnico necessário para fornecer esta tecnologia como um serviço de produção no backbone RNP2.

Os testes envolveram Pontos de Presença (PoPs) da RNP em várias localidades. Foi feita a configuração de multicast nativo em roteadores de produção do backbone RNP2, cuja operação foi avaliada em termos de estabilidade no roteamento unicast e desempenho nas funções relativas ao roteamento multicast.

O projeto piloto forneceu subsídios para a implantação de um serviço multicast de produção na RNP. É nesta fase de implantação que a RNP encontra-se atualmente, e cujo estágio mais recente será descrito nas seções seguintes.

Na seção 2 é feita uma descrição detalhada da estrutura multicast intradomínio da RNP, incluindo trechos de configuração dos roteadores em operação. A descrição é estendida na seção 3 para abordar as conexões multicast interdomínio entre a RNP e os backbones AMPATH (1) e Abilene (2) (Internet2). Na seção 4, é apresentado um resumo dos eventos em que a estrutura multicast da RNP foi utilizada em grande escala e as conclusões obtidas. A seção 5 é voltada para a questão da distribuição multicast até os usuários finais, incluindo problemas envolvidos e possíveis alternativas. Como fonte de referência, a seção 6 apresenta ferramentas gratuitas utilizadas para monitoração da rede multicast da RNP e fóruns de discussão nacionais sobre multicast. A seção 7 apresenta as considerações finais deste artigo.

No decorrer de todo texto serão apresentados trechos de configurações de roteadores da RNP, como forma de ilustrar de forma efetiva os procedimentos operacionais em uso no backbone. Estas configurações encontram-se reunidas no Anexo A.

1 - Americas Path Network - O projeto AMPATH é uma iniciativa em conjunto da Florida International University (FIU) e da Global Crossing para interconectar as redes de pesquisa e educação na América Latina e no Caribe à Internet2.
2 - Lançado em 1998, o Abilene é um dos principais backbones de IP nativo disponível para as universidades que participam do projeto Internet2.

^

2. Infra-estrutura multicast intradomínio

O backbone atual da RNP é composto de roteadores Cisco de diversos modelos, interconectados através de enlaces ATM ou Frame Relay. A figura 1 ilustra a atual topologia de interconexão dos PoPs no backbone RNP2.

Topologia do backbone RNP2

Figura 1 - Topologia do backbone RNP2

Com a implantação do backbone RNP2 nos anos de 2000/2001, 13 dos 27 PoPs da RNP receberam roteadores da linha 7507 da Cisco. Tais roteadores possuíam desempenho muito superior a seus antecessores no PoP e incluíam suporte para realizar roteamento multicast nativo. Este suporte era basicamente garantido pela versão de IOS (Internetwork Operating System) fornecida com estes roteadores (IOS 12.0(8)S) que garantia funcionalidades básicas para multicast nativo, como PIM (Protocol Independent Multicast) e IGMPv2 (Internet Group Management Protocol).

Os 13 PoPs que receberam roteadores multicast foram: RJ, SP, DF, MG, RS, SC, PR, BA, PE, CE, RN, GO e PB. Uma vez que todos estes apresentam condições de realizar roteamento multicast nativo, todos foram incluídos em uma topologia multicast utilizando PIM-SM (PIM Sparse Mode). O uso de PIM-SM é muito recomendado para uso em backbones e redes WAN por suas características em termos de escalabilidade e economia de banda [1]. Além disso, seu uso pode ser considerado padrão de facto nas atuais implantações de multicast nativo, incluindo grandes backbones americanos como o da Sprint [2].

A figura 2 mostra quais PoPs estão conectados nesta malha PIM-SM, assim como quais enlaces ATM estão com multicast nativo habilitado.

Multicast nativo no backbone RNP2

Figura 2 - Multicast nativo no backbone RNP2

Conforme ilustrado na figura acima, percebe-se que a topologia é em estrela, partindo do PoP-RJ. De fato, é no PoP-RJ que foi configurado o RP (Rendezvous Point) da rede PIM-SM (vide seção 2.1).

A implantação desta estrutura multicast foi bastante simples, com o uso de três comandos:

Durante a implantação, não houve nenhum tipo de alteração no desempenho global dos roteadores, o que garantiu estabilidade na operação do backbone. Este fato foi ajudado pelo baixo volume de tráfego multicast no backbone durante esta fase inicial.

Em testes realizados com PIM-DM, o impacto no roteador foi superior, com um grande aumento na tabela de rotas multicast (e, portanto, no uso de memória). Este efeito era esperado pela filosofia de operação dense-mode, que obriga os roteadores a manterem informações sobre todos os grupos multicast ativos.

Um detalhe a ser mencionado é que a atual estrutura PIM-SM está montada em em sub-interfaces ATM ponto-a-ponto. Cada sub-interface possui um único PVC e endereçamento IP próprio, o que as torna similares a interfaces Seriais. Este tipo de configuração é mais recomendado para implantação de multicast se comparado às alternativas com interfaces ATM multiponto (redes NBMA) [3].

A atual estrutura PIM-SM atinge basicamente roteadores de backbone, ou seja, apenas as instituições mantenedoras dos PoPs têm acesso direto ao serviço multicast. Para que outros clientes dos PoPs acessem a rede multicast, será necessária uma estrutura de distribuição multicast estadual, possivelmente baseada em DVMRP (via estações com software mrouted). A seção 5 trata de algumas questões relacionadas à montagem desta estrutura.

3 - O termo "indicação estática" é usado em oposição às alternativas de definição dinâmica do RP como Auto-RP ou Bootstrap Router.

^

2.1 Rendezvous Point

O roteador RP do backbone está implantado em um roteador 7507 no PoP-RJ. A razão principal para o estabelecimento deste RP no PoP-RJ é a posição central deste na estrutura de roteamento do backbone RNP2. Assim, o RP encontra-se diretamente (em termos de hops de roteamento) conectado a quase todos os roteadores na estrutura de multicast nativo da RNP, o que reduz o retardo no registro de grupos pelas fontes.

No entanto, em geral o posicionamento do RP não é crítico pois ele é primariamente usado para iniciar novas sessões com fontes e receptores. A partir disso, o tráfego pode ser redirecionado por outros caminhos mais adequados através da operação de switchover automático [4] [5].

Em um estágio futuro, é prevista a implantação de um segundo RP no backbone para fins de redundância. No momento atual, isto pode ser desprezado em favor de uma maior simplicidade na estrutura do backbone.

Além disso, é interessante perceber que esta redundância seria voltada para tráfego multicast interno à RNP. Caso o roteador RP do PoP-RJ fique inoperante, nenhum acesso ao tráfego internacional (unicast ou multicast) da Internet2 poderá ser feito. Portanto a redundância de RPs em nada ajudaria com relação ao tráfego multicast internacional. Esta situação pode mudar caso outros backbones nacionais passem a trocar tráfego multicast com a RNP.

As configurações de PIM-SM no roteador RP são idênticas às existentes nos demais roteadores da estrutura: habilitação global de multicast, habilitação de PIM-SM nas interfaces e indicação estática do RP.

Este último detalhe é particularmente importante. Segundo algumas documentações da Cisco (vide por exemplo [6]), a indicação estática do RP deve ser feita em todos os roteadores da rede com exceção do RP. Mais recentemente, este requisito foi alterado e a indicação do endereço do RP tornou-se obrigatória também no roteador RP (4) .

Como precaução, o registro de grupos ativos no RP é filtrado para impedir grupos indevidos e/ou fontes pertencentes a redes reservadas. Isto é feito através do comando "ip pim accept-register list", como mostrado abaixo:

        ip pim accept-register list pim-register-filter

        ip access-list extended pim-register-filter
          deny   ip any 224.0.0.0 0.0.0.255
          deny   ip any 232.0.0.0 0.255.255.255
          deny   ip 10.0.0.0 0.255.255.255 any
          deny   ip 127.0.0.0 0.255.255.255 any
          deny   ip 172.16.0.0 0.15.255.255 any
          deny   ip 192.168.0.0 0.0.255.255 any
          permit ip any any

A lista de acesso "pim-register-filter" impede o registro de grupos na faixa 224.0.0.0/24 (Local Network Control Block), 232/8 (SSM) e fontes em redes reservadas.

4. A indicação do endereço do RP no próprio RP foi particularmente importante para concluir a conexão da RNP com a Internet2 (vide seção 3). Enquanto o RP não foi configurado desta forma, não foi possível receber qualquer seção multicast do exterior.

^

3. Multicast interdomínio: conexão à Internet2

Com a conclusão da infra-estrutura PIM-SM no backbone (no âmbito intradomínio), foram iniciadas as atividades envolvendo multicast interdomínio. Estas atividades foram alavancadas pela conexão estabelecida em agosto/2001 entre RNP e AMPATH, permitindo o acesso ao backbone Abilene e portanto, à rede Internet2.

Inicialmente, foram estabelecidos peerings BGP tradicionais entre RNP e AMPATH e entre RNP e Abilene. Posteriomente, estas trocas de tráfego foram estendidas para incluir tráfego multicast, através de peerings MBGP e MSDP.

A figura 3 demonstra a configuração atual de roteadores no PoP-RJ, indicando o link internacional para AMPATH/Internet2:

Diagrama da estrutura multicast no POP-RJ

Figura 3 - Diagrama da estrutura multicast no PoP-RJ

A configuração de MBGP é bastante simples e baseia-se nos comandos tradicionais para peering BGP unicast. Foi necessário, apenas, incluir as palavras-chave "nlri unicast multicast" no estabelecimento de peering BGP, via comando "neighbor remote-as" (5) .

    router bgp 1916
      neighbor 198.32.252.237 remote-as 20080 nlri unicast multicast
      neighbor 198.32.252.254 remote-as 11537 nlri unicast multicast

Com isto, foi criada uma nova tabela de roteamento MBGP, basicamente alimentada pelos prefixos existentes na Internet2 (cerca de 3300 entradas na ocasião). Partindo da RNP, alguns prefixos passaram a ser anunciados também na tabela MBGP global, utilizando o comando "network" e as mesmas palavras-chave usadas acima:

    router bgp 1916
      network 200.143.192.0 mask 255.255.192.0 nlri unicast multicast

Em termos de MSDP, foram estabelecidas sessões MSDP envolvendo os mesmos endereços utilizados para o peering MBGP, através do comando "ip msdp peer":

    ip msdp peer 198.32.252.237 ip msdp peer 198.32.252.254

Um ponto importante no estabelecimento deste tipo de peering consiste na filtragem de mensagens SA (source active) entre os peers MSDP. Estes filtros são aplicados tanto no envio quanto na recepção de mensagens SA, através do comando "ip msdp sa-filter":

    ip msdp sa-filter in 198.32.252.237 list msdp-sa-filter
    ip msdp sa-filter out 198.32.252.237 list msdp-sa-filter
    ip msdp sa-filter in 198.32.252.254 list msdp-sa-filter
    ip msdp sa-filter out 198.32.252.254 list msdp-sa-filter

A definição de quais grupos devem ser incluídos na lista "msdp-sa-filter" é definida e atualizada com base nas recomendações da Cisco [8] e Internet2 [9]. Os endereços filtrados incluem grupos com escopo limitado administrativamente (RFC 2365), fontes provenientes de redes reservadas (RFC1918) e grupos na faixa SSM.

    ip access-list extended msdp-sa-filter deny
    ip any host 224.0.2.2 deny
    ip any host 224.0.1.3 deny
    ip any host 224.0.1.24 deny
    ip any host 224.0.1.22 deny
    ip any host 224.0.1.2 deny
    ip any host 224.0.1.35 deny
    ip any host 224.0.1.60 deny
    ip any host 224.0.1.39 deny
    ip any host 224.0.1.40 deny
    ip any host 234.42.42.42 deny
    ip any host 229.55.150.208 deny
    ip any host 234.142.142.142 deny
    ip any 224.0.0.0 0.0.0.255 deny
    ip any 232.0.0.0 0.255.255.255 deny
    ip any 239.0.0.0 0.255.255.255 deny
    ip 10.0.0.0 0.255.255.255 any deny
    ip 127.0.0.0 0.255.255.255 any deny
    ip 172.16.0.0 0.15.255.255 any deny
    ip 192.168.0.0 0.0.255.255 any permit
    ip any any

O filtro acima não impede que anúncios de fontes provenientes de redes válidas (mas não pertencentes à RNP) sejam indevidamente anunciadas para o exterior. Um exemplo deste problema ocorre quando, em algum ponto do backbone, é criado um tunel DVMRP para o MBone. Nesta caso, fontes ativas no MBone são incorretamente anunciadas para o backbone, e por sua vez para a Abilene, que recebe anúncios inconsistentes partindo da RNP. Como decorrência, ocorrem loops de roteamento e roteamento sub-ótimo, entre outros problemas. Em breve será mantido um controle estrito de quais fontes serão anunciadas nos PoPs para dentro do backbone multicast da RNP.

Uma das vantagens resultantes da conexão com a Internet2 foi o acesso às sessões do MBone. Todas as sessões do MBone são transmitidas para o backbone Abilene e, portanto, podem ser acessadas dentro da infra-estrutura multicast da RNP. Com isto, fica garantida a recepção de diversas sessões de conteúdo técnico como reuniões da NANOG e do IETF, entre outras. A figura 4, obtida em uma estação de trabalho no Núcleo de Coordenação da RNP no Rio de Janeiro, ilustra o uso de uma conhecida aplicação para acesso a sessões multicast: o SDR. Os softwares VIC (Video Conferencing Tool) e VAT (Visual Audio Tool) também são mostrados em operação na figura 4.

Recepção de sessões multicast no NC-RJ/RNP

Figura 4 - Recepção de sessões multicast no NC-RJ/RNP. Visualização com os software SDR, VIC e VAT

Para facilitar a verificação do multicast, existe a possibilidade de executar um cliente SDR dentro dos roteadores, utilizando o comando:

    ip sdr listen

Ao habilitar este comando, o roteador pode receber e armazenar anúncios de sessão via SDP (Session Description Protocol) e SAP (Session Announcement Protocol). Assim, é possível verificar quais sessões estão sendo recebidas no roteador, utilizando o comando "show ip sdr":

    rj-bb3>sh ip sdr
    SDR Cache - 153 entries

      20011018 Live GR
      Aberdeen Uni, UK
      AEGEANEDU Alice 92.8
      Amel playin'
      Amel testing
      Amel testing
      APAN-KR/KOREN NOC
      Archaeology Channel (MPEG-1)
      Aural Abuse
      Broadway Local MPEG-2
      BUSY: My Name
      CDH (private session)
      CDL (private session)
      CDL - Campus Neo (private session)
      CDT (private session)
      CDT - Alipes (private session)
      CDT - Echo Session 
      CDT - Internet Live
      CDT - low bandwidth video (private session)
      CDT - mediaSite
      --More--

Em versões mais recentes de IOS (12.2) o comando "ip sdr listen" foi substituído pelo comando "ip sap listen".

É interessante lembrar que o peering multicast com a Abilene também garante a acessibilidade multicast da RNP para receptores no exterior. Portanto, o tráfego multicast gerado por fontes internas à RNP poderá ser visualizado em outros backbones, caso os receptores possuam acesso à Internet2 ou ao MBone.

5. A sintaxe deste comando foi alterada a partir das versões de IOS 12.0T e 12.1, vide [ 7] .

^

4. Experimentos realizados

Desde o início do projeto piloto de multicast em 2001, houve três eventos importantes em que a estrutura multicast da RNP pôde ser testada de forma bastante realística. Durante estes testes, houve a participação de vários PoPs do backbone, permitindo avaliar a confiabilidade da estrutura multicast nativa em proporções amplas. Descrevemos abaixo cada um destes testes.

^

4.1 Transmissão multicast do SBRC 2001 (Simpósio Brasileiro de Redes de Computadores)

Em maio de 2001, foi realizado o IX Simpósio Brasileiro de Redes de Computadores em Florianópolis-SC. Durante o evento, foram transmitidas diversas sessões técnicas através de mecanismos unicast e multicast. As transmissões em multicast foram injetadas no backbone RNP2 sobre uma estrutura multicast nativa com a participação de 6 PoPs: SC, RS, RJ, MG, PE e DF.

Na ocasião, foi montada a primeira versão de estrutura PIM-SM nativa no backbone RNP2. A estrutura era significativamente mais complexa que a atualmente em uso na RNP, com a existência de domínios PIM-SM separados para cada PoP e interligados através de MSDP. Como conseqüência, havia um RP para cada PoP, definido através do mecanismo dinâmico Auto-RP. A figura 5 demonstra esta estrutura, mostrando três PoPs participantes.

Diagrama de parte da estrutura multicast montada no SBRC'2001

Figura 5 - Diagrama de parte da estrutura multicast montada no SBRC'2001

A existência de domínios PIM-SM "estaduais" era particularmente vantajosa no sentido de tornar o RP "mais próximo" das fontes: ao invés de um único RP para todo o backbone, existe um RP local para cada PoP, o que reduz a latência de registro de grupos no RP. Além disso, existe a possibilidade de reutilização de endereços de escopo limitado administrativamente (RFC 2365) em cada PoP.

No entanto, a gerência desta estrutura foi considerada complexa. Cuidados devem ser tomados com os filtros entre os domínios PIM-SM ("multicast boundaries"), assim como no envio de mensagens SA que são trocadas entre RPs. Finalmente, o troubleshooting em sistemas com RP dinâmico é mais complexo. Foi a partir destas conclusões que houve o direcionamento para a atual estrutura multicast da RNP, com um único domínio PIM-SM e RP estaticamente definido.

No que se refere às transmissões, a estrutura multicast se mostrou estável, garantindo o transporte do conteúdo multicast para todos os PoPs envolvidos no experimento.

Contudo, uma questão estrutural importante foi delineada: a interconexão entre domínios PIM-SM e DVMRP. Estruturas de distribuição multicast utilizando DVMRP estavam presentes em alguns PoPs, como RS e MG. Existem problemas na interconexão de domínios sparse mode (como em redes PIM-SM) e dense mode (como em redes DVMRP). Durante os experimentos foi possível identificar tais problemas, que impedem que o tráfego multicast alcance receptores na rede DVMRP. A seção 5 descreve com mais detalhes este caso.

Mais informações sobre a transmissão multicast do SBRC 2001 podem ser vistas em
http://www.rnp.br/noticias/2001/not-010608a.html
http://www.rnp.br/wrnp2/2001/palestras_engenharia/pal_engen_14.pdf
http://www.rnp.br/wrnp2/2001/palestras_engenharia/pal_engen_16.pdf

^

4.2 AccessGrid

O conceito de Grid abrange uma infra-estrutura que permita o uso integrado e colaborativo de computadores de alto desempenho, redes, bases de dados e instrumentos científicos pertencentes a diversas organizações. O projeto Access Grid [10] aplica este conceito aos indivíduos, isto é, permite que grupos de pessoas interajam com os recursos do Grid.

Em novembro de 2001, foi montado um site Access Grid pela Universidade Federal do Rio Grande do Sul (UFRGS), para participação na conferência global Supercomputing 2001 [11]. Uma vez que era necessária conectividade multicast internacional, este foi o primeiro evento em que a conexão multicast com a Internet2 pôde ser verdadeiramente avaliada.

Para a conexão da UFRGS, a RNP estabeleceu um circuito ATM dedicado de 10Mbps, entre o PoP-RJ e o PoP-RS. Este PVC foi estendido através da rede ATM da UFRGS até o local onde foi estabelecido o site Access Grid.

A RNP também cedeu um roteador Cisco 7200 para o evento, o qual foi instalado na UFRGS para receber o canal de 10Mbps. Este roteador foi configurado para realizar roteamento multicast nativo, tornando-se parte da rede PIM-SM da RNP durante o evento.

Os testes foram realizados com bastante sucesso (vide referências abaixo). A conexão internacional mostrou-se estável durante todo o evento, sem a ocorrência de problemas com MBGP e MSDP. Este fato mostrou a estabilidade da atual estrutura de conexão multicast internacional da RNP.

Maiores referências sobre este experimento podem ser vistas em:
http://www.rnp.br/noticias/2001/not-011123b.html
http://www.inf.ufrgs.br/procpar/hetnos/grid/scglobal01/
http://si3.inf.ufrgs.br/informa/Edicao20/proj_dez01.htm

^

4.3 IMPA

Entre janeiro e fevereiro de 2002, a RNP participou ativamente na transmissão do curso de aperfeiçoamento para professores de matemática do ensino médio, realizado pelo Instituto de Matemática Pura e Aplicada (IMPA). As aulas foram filmadas e transmitidas em tempo real no backbone RNP2, atingindo salas de aula em Fortaleza, Recife, Belo Horizonte e Porto Alegre. As aulas também foram recebidas fora do backbone RNP2, na Unicamp (Campinas). Para isto, foi criado um túnel multicast entre o IMPA e o IMECC na Unicamp.

Uma das razões para utilização de multicast foi a conexão entre o IMPA e o PoP-RJ, limitada a 2Mbps. Caso se optasse por servidores de streamings unicast, rapidamente a banda poderia ser esgotada com a replicação dos fluxos para mais do que 10 clientes no Brasil (o fluxo possuía aproximadamente 200kbps). Além disso, o circuito em questão também é compartilhado com as aplicações Internet tradicionais do IMPA (6) (tráfego web, DNS, downloads etc.) e da RNP (gerência do backbone, coleta de estatísticas de tráfego, tráfego web, intranet, entre outros).

Ao utilizar multicast, foi necessário gerar apenas um único fluxo de dados, enviando-o para um grupo multicast. Os roteadores do backbone eram responsáveis por realizar a replicação deste fluxo para os clientes interessados.

Para transmissão das aulas, foi utilizado um servidor Windows Media Server, que recebia os fluxos de áudio e vídeo unicast (gerados em uma estação com o Windows Media Encoder) e convertidos para multicast, utilizando um endereço de grupo e porta definidos pela RNP. Esta abordagem teve a grande vantagem de permitir a recepção das aulas através de um software cliente bastante popular: o Windows Media Player. O envio de perguntas da audiência era realizado através de chat.

Durante o curso, foram detectados problemas na transmissão, cuja causa principal foi o correto ajuste nos parâmetros de operação dos servidores responsáveis pela codificação/streaming multicast. Em particular, mesmo com a transmissão de um único fluxo multicast, foi possível verificar perdas de pacotes na origem, entre IMPA e PoP-RJ. Entre as causas pode-se citar a interferência de outros tráfegos intensos para o IMPA, como grandes downloads. Outro causa de problemas foi a existência do túnel multicast para Campinas, criado no roteador de saída do IMPA. O túnel multicast passava obrigatoriamente através do circuito de saída do IMPA, e recebia uma réplica do fluxo multicast, resultando em duplicação de streams no mesmo circuito.

Dentro do backbone RNP2, a rede PIM-SM operou de modo correto e estável conforme esperado. Informações adicionais sobre o evento podem ser verificadas em
http://www.rnp.br/noticias/2002/not-020204.html

6. O IMPA abriga, atualmente, o Núcleo de Coordenação (NC-RJ) da RNP.

^

5. Distribuição regional de multicast

De fato, a infra-estrutura multicast no backbone RNP2 tem-se mostrado estável desde o início de sua implantação. Sua configuração simples com RP único estaticamente definido tem garantido simplicidade na gerência. No entanto, o acesso ao serviço multicast RNP encontra-se ainda concentrado no backbone, sem alcançar boa parte dos clientes finais da RNP, como universidades e institutos de pesquisa.

Isto se deve às atuais condições das redes em operação nestas instituições. Caso as instituições clientes estivessem equipadas com roteadores atualizados (em termos de software e hardware), a rede PIM-SM poderia ser facilmente estendida até elas, com pouco ou nenhum esforço. Infelizmente, essa facilidade não está ao alcance de muitas universidades e institutos de pesquisa, cujas redes ainda são compostas por equipamentos antigos e de baixo desempenho.

Em virtude deste panorama, uma alternativa para distribuição regional multicast é a implantação de redes DVMRP, baseadas principalmente em estações UNIX rodando o software mrouted (vide por ex. [12] ). De fato, alguns estados já possuem este tipo de infra-estrutura DVMRP, como MG e RS. A vantagem recai sobre a possibilidade de utilizar servidores UNIX para realizar o roteamento multicast (embora com alguma perda de desempenho), ao invés da exigência de upgrade/substituição de roteadores. O uso de redes DVMRP surge como alternativa de transição até que as instituições disponham de redes totalmente capazes de rotear multicast nativamente.

O protocolo DVMRP já é bastante conhecido e maduro. Seu uso foi particularmente intenso no MBone, cuja estrutura era montada em sua maioria sobre túneis multicast entre estações rodando mrouted.

A estutura geral multicast na RNP pode, então, ser estendida como na fig 6(a). O backbone RNP2 utiliza roteamento multicast PIM-SM e, quando necessário, nuvens DVMRP seriam estabelecidas a partir dos PoPs para clientes incapazes de rotear multicast nativamente. Note que isto não impede que redes de distribuição local PIM-SM sejam montadas em paralelo, para instituições capazes de rotear este protocolo. Ambas as redes PIM-SM e DVMRP podem coexistir, sendo que o roteador do PoP assume a função de gateway entre elas.

Esquemas para distribuição multicast fim-a-fim utilizando DVMRP

Figura 6 - Esquemas para distribuição multicast fim-a-fim utilizando DVMRP

Isto também se aplica a certos PoPs onde o roteador de backbone não suporta multicast nativo (7) . Nestes casos será implantado um túnel DVMRP entre uma estação rodando mrouted no PoP e o roteador 7507 "mais próximo" na estrutura de roteamento do backbone. A fig. 6(b) demonstra este tipo de configuração.

7. Conforme descrito na seção 2, existem atualmente 13 PoPs da RNP com multicast nativo habilitado. Este número será expandido para a totalidade do backbone, através da substituição gradual de roteadores antigos.

^

5.1 Interconexão PIM-SM/DVMRP

Infelizmente, a interconexão de domínios sparse-mode (ex.: PIM-SM) e dense-mode (ex: DVMRP) não é trivial, devido às suas diferentes filosofias de operação. Em particular, pode-se verificar a ocorrência do chamado "problema do receptor dense-mode" [13] [14] [15]. Neste problema, estações dentro da rede dense-mode que ajam apenas como receptoras de tráfego multicast (ou seja, não transmitem nada para o grupo a que se vincularam) podem não conseguir acesso a certos fluxos multicast na rede sparse-mode.

Embora já tenham havido esforços para implantar um protocolo de interconexão entre redes DM e SM (RFC 2715), pouco se tem evoluído na questão. As vantagens evidentes na utilização de PIM-SM praticamente tornaram-no padrão como protocolo multicast em grandes backbones. Como conseqüência, o uso de DVMRP ficou estagnado (senão reduzido) mundialmente, enquanto cada vez mais roteadores têm incluído suporte para PIM-SM, e cada vez mais redes têm implantado PIM-SM.

No caso da RNP e de seus clientes, serão utilizadas algumas das alternativas propostas em [13] para evitar o problema do receptor dense-mode. Em certos casos, estes workarounds são aplicáveis, em outros casos não. A única solução de longo prazo para o problema é a substituição do hardware e software dos roteadores por versões mais novas, o que fatalmente ocorrerá no próximos anos.

Os roteadores do backbone RNP2 são capazes de interoperar com redes DVMRP automaticamente, bastando apenas que o roteador receba uma mensagem de probe DVMRP de algum outro equipamento (como de uma estação mrouted). Todavia, por precaução, os roteadores de backbone da RNP são configurados com filtros para evitar que a interoperação PIM/DVMRP seja indevidamente ativada. A conexão com nuvens DVMRP deverá ser permanentemente monitorada e a interoperação deve ocorrer apenas com estações pré-determinadas pelo PoP. A filtragem de probes DVMRP indesejados é feita com o comando "ip dvmrp accept-filter", conforme mostrado abaixo:

    ip dvmrp accept-filter any-source-acl neighbor-list deny-dvmrp-acl

    ip access-list standard any-source-acl permit any ip access-list standard
      deny-dvmrp-acl deny   any

^

6. Recursos para monitoração

http://www.abilene.iu.edu/tools.html

O NOC da Abilene inclui diversas ferramentas públicas (acessíveis via web) para avaliar a conectividade multicast entre instituições participantes ou ligadas à Internet2. Entre as ferramentas disponíveis, vale citar:

Existem inúmeros sites e referências na Internet ligadas à tecnologia multicast e suas aplicações. Neste seção, apresentamos um subconjunto destas referências, cujo enfoque é mais direcionado para a operação da rede multicast incluindo ferramentas de monitoração e fóruns de discussão. A lista abaixo é, obviamente, não exaustiva.

^

7. Considerações finais

Neste artigo foi descrita a infra-estrutura IP multicast implantada no backbone RNP2. O enfoque utilizado foi voltado para o detalhamento tecnológico desta infra-estrutura, incluindo o uso extensivo de configurações exemplo. As soluções implantadas no backbone RNP2 não devem ser vistas como recomendações de qualquer tipo, mas sim como referência para posteriores implementações a serem realizadas em outros backbones e em redes de um modo geral.

Vale destacar que a arquitetura multicast da RNP poderá vir a sofrer modificações posteriores à publicação deste texto. No entanto, a experiência acumulada indica uma consistência do direcionamento tomado até o momento.

Após o período de implantação e avaliação da rede multicast nativa no backbone, a RNP inicia uma nova fase de atuação, em que passará a enfocar mais diretamente as redes de distribuição multicast regionais. O objetivo é claro: levar o serviço multicast até seus clientes finais, disponibilizando novos conteúdos digitais e acesso a tecnologias inovadoras. Como vantagem indireta, a RNP também se beneficia através do uso mais inteligente dos recursos de seu backbone.

^

Anexo A - Configurações de multicast nos roteadores

As configurações abaixo foram incluídas para permitir uma visão consolidada de todos os trechos de configurações citados no artigo. A configuração (1) apresenta os comando relativos a multicast que encontram-se habilitados nos roteadores 7507 do backbone RNP2. A configuração (2) apresenta comandos adicionais existentes apenas no roteador RP da RNP.

(1) Roteador genérico no backbone (não-RP):

    ! Hardware: Cisco 7507
    ! Cisco RSP4 (R5000) processor
    ! 2 VIP2 R5K controllers (2 FastEthernet)(1 ATM).
    ! Software: IOS Version 12.2(2)T2,
    !
    !
    !
    ! Habilitando o multicast global
    !
    ip multicast-routing distributed
    ip multicast cache-headers
    !
    !
    ! Inserindo loopback na malha PIM-SM, e habilitando
    ! a escuta de anuncios SDP e SAP
    !
    interface Loopback0
     ip pim sparse-mode
     ip sap listen
    !
    !
    ! Habilitando PIM-SM nas interfaces de acesso e
    ! inserindo filtros para neighbors DVMRP inesperados
    !
    interface FastEthernet1/0/0
     ip pim sparse-mode
     ip dvmrp accept-filter any-source-acl neighbor-list deny-dvmrp-acl
    !
    !
    ! Habilitando PIM-SM na interface de backbone. Em particular,
    ! a interface ATM foi definida como ponto-a-ponto o que dispensa
    ! o uso de PIM NBMA mode
    !
    interface ATM4/0/0.106 point-to-point
     ip pim sparse-mode
    !
    !
    ! Indicacao estática do RP
    !
    ip pim rp-address 198.32.252.238
    !
    !
    ! Listas de acesso referenciadas acima
    !
    ip access-list standard any-source-acl
     permit any
    ip access-list standard deny-dvmrp-acl
     deny   any
    !
    !
    (2) Roteador RP do backbone:
   
    ! Hardware: Cisco 7507
    ! Cisco RSP4 (R5000) processor
    ! 1 FSIP controller (8 Serial).
    ! 2 VIP2 R5K controllers (2 FastEthernet)(1 ATM).
    ! 1 FEIP controller (2 FastEthernet).
    ! Software: IOS Version 12.0(18)ST
    !
    !
    ! Habilitando o multicast global
    !
    ip multicast-routing distributed
    !
    ! Inserindo loopback na malha PIM-SM, e habilitando
    ! a escuta de anuncios SDP e SAP (note a diferenca do comando
    ! na listagem 1, devido a versao de IOS mais antiga)
    !
    !
    interface Loopback0
     ip pim sparse-mode
     ip sdr listen
    !
    !
    ! O circuito internacional para o AMPATH tambem roda PIM-SM.
    ! Comandos especificos sao utilizados para delimitar a fronteira
    ! do dominio PIM-SM da RNP.
    !
    interface ATM4/0/0.45 point-to-point
     description Conexao DS3 para AMPATH
     ip pim bsr-border
     ip pim sparse-mode
     ip multicast boundary multicast-boundary
    !
    !
    ! Configuracao de BGP:
    ! no estabelecimento dos peerings com AMPATH e Abilene, a keyword
    ! multicast habilita a troca de anuncios via MBGP.
    ! Também são mostradas algumas redes que
    ! sao anunciadas no MBGP global
    !
    router bgp 1916
     network 147.65.0.0 nlri unicast multicast
     network 200.17.48.0 mask 255.255.240.0 nlri unicast multicast
     network 200.143.192.0 mask 255.255.192.0 nlri unicast multicast
     neighbor 198.32.252.237 remote-as 20080 nlri unicast multicast
     neighbor 198.32.252.237 description AMPATH
     neighbor 198.32.252.254 remote-as 11537 nlri unicast multicast
     neighbor 198.32.252.254 description Abilene connection
    !
    !
    ! Indicacao estática do RP e uso de filtros
    ! para registro de grupos/fontes no RP
    !
    ip pim rp-address 198.32.252.238
    ip pim accept-register list pim-register-filter
    !
    !
    ! Comandos para estabelecimento dos peerings MSDP
    ! com AMPATH e Abilene e implantacao de filtros
    ! para mensagens SA (source active)
    !
    ip msdp peer 198.32.252.237
    ip msdp sa-filter in 198.32.252.237 list msdp-sa-filter
    ip msdp sa-filter out 198.32.252.237 list msdp-sa-filter
    ip msdp peer 198.32.252.254
    ip msdp sa-filter in 198.32.252.254 list msdp-sa-filter
    ip msdp sa-filter out 198.32.252.254 list msdp-sa-filter
    ip msdp cache-sa-state
    !
    !
    ! Listas de acesso referenciadas acima
    !
    ip access-list standard multicast-boundary
     deny   224.0.1.39
     deny   224.0.1.40
     deny   239.0.0.0 0.255.255.255
     permit any
    !
    ip access-list extended msdp-sa-filter
     deny   ip any host 224.0.2.2
     deny   ip any host 224.0.1.3
     deny   ip any host 224.0.1.24
     deny   ip any host 224.0.1.22
     deny   ip any host 224.0.1.2
     deny   ip any host 224.0.1.35
     deny   ip any host 224.0.1.60
     deny   ip any host 224.0.1.39
     deny   ip any host 224.0.1.40
     deny   ip any host 234.42.42.42
     deny   ip any host 229.55.150.208
     deny   ip any host 234.142.142.142
     deny   ip any 224.0.0.0 0.0.0.255
     deny   ip any 232.0.0.0 0.255.255.255
     deny   ip any 239.0.0.0 0.255.255.255
     deny   ip 10.0.0.0 0.255.255.255 any
     deny   ip 127.0.0.0 0.255.255.255 any
     deny   ip 172.16.0.0 0.15.255.255 any
     deny   ip 192.168.0.0 0.0.255.255 any
     permit ip any any
    !
    ip access-list extended pim-register-filter
     deny   ip any 224.0.0.0 0.0.0.255
     deny   ip any 232.0.0.0 0.255.255.255
     deny   ip 10.0.0.0 0.255.255.255 any
     deny   ip 127.0.0.0 0.255.255.255 any
     deny   ip 172.16.0.0 0.15.255.255 any
     deny   ip 192.168.0.0 0.0.255.255 any
     permit ip any any

^

Referências bibliográficas

[1] Cisco IOS Software: Beyond Basic IP Volume I, Issue 11.
http://www.cisco.com/warp/public/779/servpro/promotions/bbip/volume_01_issue11.html

[2] Deploying Native Multicast across the Internet, © 2000 - Sprint Corporation.
http://www.sprintlink.net/multicast/whitepaper.html

[3] Using IP Multicast over Frame Relay Networks, Cisco Systems, Inc.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/frm_rlay.htm

[4] Configuring a Rendezvous Point, Cisco Systems, Inc.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/rps.htm

[5] PIM-SM - Traning Module 5, Cisco Systems, Inc.
ftp://ftp-eng.cisco.com/ipmulticast/training/Module5.pdf

[6] Multicast Quick-Start Configuration Guide, Cisco Systems, Inc.
http://www.cisco.com/warp/public/105/48.html

[7] Changes in MBGP Commands Between 12.0S and 12.0T/12.1, Cisco Systems, Inc.
http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/mcb12_an.htm

[8] Multicast Source Discovery Protocol SA Filter Recommendations, Cisco Systems, Inc.
http://www.cisco.com/warp/public/105/49.html

[9] Enabling IP Multicast with Abilene, Abilene NOC at Indiana University.
http://www.abilene.iu.edu/mccook.html

[10] Access Grid
http://www-fp.mcs.anl.gov/fl/accessgrid/

[11] SC Global Event - SC2001
http://www-fp.mcs.anl.gov/scglobal/

[12] FreeBSD System Manager's Manual, FreBSD.org
http://www.FreeBSD.org/cgi/man.cgi?query=mrouted&sektion=8

[13] Interconnecting PIM & DVMRP Multicast Networks, Beau Williamson, Cisco Systems, Inc., Slides 33 a 36
http://www.urec.cnrs.fr/fmbone/Jres99/FMbone-pim-dvmrp/

[14] Native Multicast and Inter Domain Routing on TEN-155, DANTE.
http://www.dante.net/mbone/mcast99/migration.html

[15] Projetos especiais - entrevista sobre implantação de Multicast, CI/RNP.
http://www.rnp.br/noticias/2002/not-020409-coord.html

[16] Projetos especiais - Multicast Beacon, CI/RNP.
http://www.rnp.br/multicast/multicast-beacon.html

^

NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004