RNP > Notícias RNP > 2002

"Vamos ativar multicast em todos os PoPs da RNP"

Entrevista com Adenilson Raniery, técnico do CEO

Adenilson Raniery, técnico do Centro de Engenharia e Operações da RNP (CEO), é responsável pelo projeto multicast da instituição. Desde o ano passado ele está envolvido em estudos e especificações para o uso da tecnologia no backbone RNP2. A fase de experimentação foi concluída em 2001. Agora trata-se de usar a experiência acumulada estendendo o serviço a todo o backbone acadêmico nacional. Do núcleo da RNP no Rio de Janeiro, onde trabalha, Raniery concedeu esta entrevista ao RNP Notícias.

Como o serviço multicast será implantado no RNP2?

Adenilson Raniery: O layout inicial será de uma rede PIM-SM com RP único no PoP-RJ. Vamos ativar multicast em todos os PoPs [Pontos de Presença] da RNP. Aqueles PoPs cujo roteador de backbone é um 7507 terão multicast nativo habilitado. No caso de PoPs cujo router de backbone não suporta multicast, torna-se obrigatório o uso de multicast tunelado. Neste caso implantaremos 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. Por exemplo, teremos uma estação mrouted no PoP-TO de onde partirá um túnel DVMRP até o roteador 7507 do PoP-DF.

Traduza "rede PIM-SM com RP único no PoP-RJ".

Adenilson Raniery: PIM significa "Protocol Independent Multicast", ou seja, é um protocolo de roteamento multicast que opera baseado nas rotas geradas por protocolos de roteamento unicast como OSPF, IS-IS, RIP, etc. Logo, roteadores utilizando PIM não necessitam de uma nova tabela de roteamento para multicast. Eles utilizam as tabelas unicast já existentes para tomar decisões de roteamento multicast.

A designação SM indica "Sparse Mode", que é um dos 2 possíveis modos de operação do PIM (o outro modo possível é o DM, "Dense Mode"). Redes PIM-SM necessitam de ao menos um RP, ou seja, um "Rendezvous Point". De maneira simplificada, um RP pode ser visto como o elemento central na infra-estrutura multicast das redes PIM-SM.

Em resumo: o roteamento multicast no backbone será realizado utilizando o protocolo PIM-SM, com um único roteador atuando como RP no PoP do Rio de Janeiro. Em um estágio futuro, implantaremos um segundo RP no backbone para possuirmos redundância de RP's. No momento atual, isto pode ser desprezado em favor de uma maior simplicidade na estrutura do backbone. Além disso, como a conexão multicast com a Internet2 está no PoP-RJ e boa parte do tráfego multicast acessado na RNP virá por meio dela, a existência de um outro RP acaba sendo de pouca ajuda na infra-estrutura do backbone RNP2. Esta situação pode mudar caso outros backbones (como a Embratel) passem a trocar tráfego multicast com a RNP em outras localidades.

Não haverá problemas de compatibilidade entre o PIM-SM e o DVMRP?

Adenilson Raniery: De fato, os protocolos PIM-SM e DVMRP apresentam incompatibilidades devido a suas diferentes filosofias de operação. O PIM-SM é um protocolo sparse-mode, ou seja, considera que fontes e receptores estão presentes de forma esparsa na rede. Assim, seu modo de operação baseia-se na requisição explícita de tráfego multicast. Os roteadores somente enviarão tráfego multicast (de um determinado grupo G) através de interfaces onde existam receptores que solicitaram este tráfego previamente. Caso contrário, nenhum tráfego é transmitido, o que impede o gasto desnecessário de banda passante no backbone. Este tipo de protocolo é amplamente recomendado, principalmente em backbones e redes WAN, onde os custos dos links são elevados e, portanto, não pode haver desperdício de banda passante.

Em contrapartida, o protocolo DVMRP é um protocolo dense-mode. A filosofia do protocolo considera que existem muitos transmissores e receptores na rede, de forma que é mais vantajoso transmitir todos os fluxos multicast em todos os links da rede. Caso um roteador verifique que não possui "clientes" interessados em um certo grupo multicast G, ele responde (no sentido inverso do tráfego multicast) indicando que não deseja receber tráfego do grupo G. Isto é realizado através de uma mensagem de prune (poda). Note que, além do desperdício de banda implícito nessa abordagem, existem também conseqüências para os roteadores, que são obrigados a manter informações sobre todos os grupos ativos na rede, e não somente daqueles para os quais haja clientes interessados na recepção. Assim o roteador precisa de mais memória para manter estes dados e mais CPU para realizar todo este processamento.

Devido às diferentes filosofias de operação do PIM-SM e do DVMRP, podem haver problemas na interação entre ambos. Estes problemas ocorrem quando uma estação na nuvem DVMRP deseja receber tráfego multicast de um grupo multicast cuja fonte encontra-se na nuvem PIM-SM. Do lado DVMRP, o receptor fica aguardando que o tráfego multicast alcance-o, pois pela filosofia dense-mode todos os fluxos ativos vão chegar ao receptor (a não ser quando explicitamente recusados pela mensagem de prune). Do lado da rede PIM-SM, os roteadores ficam aguardando que seja feita uma requisição explícita solicitando o tráfego daquele grupo multicast, algo que só pode vir de "dentro" da rede PIM-SM. Neste momento ocorre um impasse e o cliente na rede DVMRP pode ficar sem acesso àquele fluxo multicast desejado.

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 seus clientes, ainda existem varias redes cujos roteadores não têm capacidade para rodar multicast nativo. Nestas situações, o uso de DVMRP é a única solução, visto que pode ser implantado sem muitos problemas em estações Unix comuns através do software mrouted. Para estes casos, estaremos aplicando alguns workarounds [soluções em que se contorna um problema sem resolvê-lo; ajustes] propostos pela Cisco (fabricante do atuais roteadores da RNP) para resolver as questões de incompatibilidade entre DVMRP e PIM-SM. Em certos casos estes workarounds são aplicáveis e em outros casos não. A única solução de longo prazo para o problema é a substituição do hardware/software dos roteadores por equipamentos/versões mais novas. Isto fatalmente ocorrerá nos próximos anos.

Existe alguma alternativa para evitar o conflito entre os protocolos?

Adenilson Raniery: Entre as possíveis soluções temos:

1-Montar túneis DVMRP diretamente para o RP da rede, no PoP-RJ. Como na rede PIM-SM todos os grupos multicast têm de ser registrados no RP, túneis DVMRP ligados a ele passariam a ter acesso a todos os grupos ativos da rede.

2-Considerar que todos os receptores na rede DVMRP também serão transmissores. Neste caso, o tráfego gerado pelo cliente na nuvem DVMRP alcança a rede PIM-SM, que passa a "saber" da existência deste cliente e começa a mandar tráfego para ele também. Esta situação ocorre por exemplo com aplicações de videoconferência.

3-Utilizar um protocolo DM (como o PIM-DM) no caminho entre a nuvem DVMRP e o RP. Neste caso, ambas as redes possuem a mesma filosofia dense-mode de operação e os problemas de incompatibilidade são eliminados. Entretanto, o backbone volta a sofrer os problemas tradicionais de um protocolo dense mode, como ineficiência.

Todas as soluções apresentam vantagens e desvantagens. Ainda estamos analisando a gravidade deste problema e as alternativas para resolvê-lo ou ao menos reduzir seus efeitos. Até que tenhamos condições de levar PIM-SM ao usuário final, por meio de roteadores capazes de fazer isto, a interoperação entre PIM-SM e DVMRP terá de ser mantida.

Em quanto tempo o serviço estará implantado em todos os PoPs?

Adenilson Raniery: A implantação de multicast nos PoPs propriamente ditos poderá ser realizada em pouco tempo. Atualmente, todos os 13 PoPs equipados com roteadores 7507 já estão rodando multicast nativo. Nos demais PoPs, como já disse, teremos que implantar uma máquina rodando mrouted para receber um túnel multicast e realizar o roteamento multicast. Embora trabalhosa, esta segunda etapa também não deverá se estender muito, pois já temos o know-how para isso. Espero que possamos concluir esta segunda fase em alguns meses.

A questão principal consiste em estender o serviço multicast aos clientes dos PoPs. Esta fase será a mais longa e complicada de todas, pois envolverá uma variedade grande de equipamentos, como roteadores, firewalls e switches diversos que podem complicar a implantação. A participação ativa dos PoPs e instituições clientes nesse processo será muito importante para difundir o serviço multicast fornecido pela RNP. Note que também será necessário que disponhamos de aplicações atraentes para que haja interesse pelo serviço multicast. Em particular, considero que a transmissão de eventos importantes (como o Simpósio Brasileiro de Redes de Computadores, reuniões do IETF e da NANOG, entre outras) via multicast pode ser um bom caminho para tornar o serviço conhecido e utilizado na RNP.

O tráfego do MBone pode ser recebido pela rede da RNP?

Adenilson Raniery: Sim. Todas as sessões ativas do MBone estão disponíveis na Internet2 e portanto, a RNP pode acessar este tráfego através de sua conexão internacional com a Internet2. É interessante lembrar que esta conexão 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 no exterior, caso os receptores possuam acesso ao backbone da Internet2.

Você poderia citar alguns PoPs que tomaram a dianteira configurando o equipamento para implantação do serviço multicast por conta própria?

Adenilson Raniery: Rio Grande do Sul e Minas Gerais já têm infra-estruturas de redistribuição multicast locais, baseadas em DVMRP. A interconexão dessas nuvens DVMRP com o backbone PIM-SM é feito nos 7507 dos respectivos PoPs. Já obtivemos êxito na transmissão de conteúdo multicast para clientes nestas redes, como no "Curso de Aperfeiçoamento para Professores de Matemática do Ensino Médio", transmitido a partir do Instituto de Matemática Pura e Aplicada (Impa) no início deste ano [veja reportagem RNP usou multicast em transmissão de curso do Impa ].

Como será feita a distribuição de conteúdo multicast para os clientes dos PoPs?

Adenilson Raniery: Poderá ser feita de duas maneiras: em modo nativo, caso o PoP disponha de outros roteadores capazes de realizar esta função em termos de hardware e software; ou em modo tunelado, através do uso de túneis DVMRP e estações Unix (preferencialmente FreeBSD) rodando mrouted. No caso de PoPs que recebem a transmissão em modo tunelado, a distribuição para os clientes só poderá ser feita através de túneis DVMRP.

[RNP, 09.04.2002]