RNP > Noticias RNP > Noticias de 2002

"Vamos a activar multicast en todos los PoPs de RNP"

Adenilson Raniery, técnico del Centro de Ingeniería y Operaciones de RNP (CEO), es responsable por el proyecto multicast de la institución. Desde el año pasado el mismo está involucrado en estudios y especificaciones para el uso de la tecnología en el backbone RNP2. La fase de experimentación fue concluida en 2001. Ahora se trata de usar la experiencia acumulada extendiendo el servicio a todo el backbone académico nacional. Desde el núcleo de RNP en Rio de Janeiro, donde trabaja, Raniery concedió esta entrevista a RNP Noticias.

¿Cómo el servicio multicast se implementará en el RNP2?

Adenilson Raniery: El layout inicial será de una red PIM-SM con RP único en el PoP-RJ. Vamos a activar multicast en todos los PoPs [Puntos de Presencia] de RNP. Aquellos PoPs cuyo enrutador de backbone es un 7507 tendrán multicast nativo activado. En el caso de PoPs cuyo router de backbone no soporta multicast, se torna obligatorio el uso de multicast tunelado. En este caso implantaremos un túnel DVMRP entre una estación que funcione en mrouted en el PoP y el enrutador 7507 "más cercano" en la estructura de enrutamiento del backbone. Por ejemplo, tendremos una estación mrouted en el PoP-TO de donde partirá un túnel DVMRP hasta el enrutador 7507 del PoP-DF.

Traducir "red PIM-SM con RP único en el PoP-RJ".

Adenilson Raniery: PIM significa "Protocol Independent Multicast", es decir, es un protocolo de enrutamiento multicast que opera basado en las rotas generadas por protocolos de enrutamiento unicast como OSPF, IS-IS, RIP, etc. Por lo tanto, los enrutadores que utilizan PIM no necesitan una nueva tabla de enrutamiento para multicast. Los mismos utilizan las tablas unicast ya existentes para tomar decisiones de enrutamiento multicast.

La designación SM indica "Sparse Mode", que es uno de los 2 posibles modos de operación del PIM (otro modo posible es el DM, "Dense Mode"). Redes PIM-SM necesitan por lo menos un RP, es decir, un "Rendezvous Point". De manera simplificada, un RP puede ser visto como el elemento central en la infraestructura multicast de las redes PIM-SM.

En resumen: el enrutamiento multicast en el backbone se realizará utilizando el protocolo PIM-SM, con un único enrutador actuando como RP en el PoP de Rio de Janeiro. En una fase futura, implantaremos un segundo RP en el backbone para que podamos tener redundancia de RP's. En el momento actual, esto se podrá descartar en favor de una mayor simplicidad en la estructura del backbone. Además de ello, como la conexión multicast con Internet2 está en el PoP-RJ y buena parte del tránsito multicast accesado en RNP vendrá por medio de la misma, la existencia de otro RP acaba siendo de poca ayuda en la infraestructura del backbone RNP2. Esta situación se podrá alterar el caso que otros backbones (como Embratel) pasen a intercambiar tránsito multicast con RNP en otras localidades.

¿No habrá problemas de compatibilidad entre el PIM-SM y el DVMRP?

Adenilson Raniery: De hecho, los protocolos PIM-SM y DVMRP presentan incompatibilidades debido a sus diferentes filosofías de operación. El PIM-SM es un protocolo sparse-mode, es decir, considera que fuentes y receptores están presentes de forma expandida en la red. De esta forma, su modo de operación se basa en la requisición explícita de tránsito multicast. Los enrutadores sólo enviarán tránsito multicast (de un determinado grupo G) a través de interfaces donde existan receptores que solicitaron este tránsito previamente. En caso contrario, ningún tránsito es transmitido, lo que impide el gasto innecesario de banda pasante en el backbone. Este tipo de protocolo es ampliamente recomendado, principalmente en backbones y redes WAN, donde los costos de los enlaces se elevan y, por lo tanto, no puede haber desperdicio de banda pasante.

Por otro lado, el protocolo DVMRP es un protocolo dense-mode. La filosofía del protocolo considera que existen muchos transmisores y receptores en la red, y por lo tanto es más ventajoso transmitir todos los flujos multicast en todos los enlaces de la red. En el caso que un enrutador verifique que no posee "clientes" interesados en un determinado grupo multicast G, el mismo contesta (en el sentido inverso del tránsito multicast) indicando que no desea recibir tránsito del grupo G. Esto se realiza a través de un mensaje de prune (poda). Note que, además del desperdicio de banda implícito en ese abordaje, existen también consecuencias para los enrutadores, que son obligados a mantener informaciones sobre todos los grupos activos en la red, y no sólo de aquellos para los cuales haya clientes interesados en la recepción. Además el enrutador necesita más memoria para mantener estos datos y más CPU para realizar todo este proceso.

Debido a las diferentes filosofías de operación del PIM-SM y del DVMRP, podrán ocurrir problemas en la interacción entre ambos. Estos problemas ocurren cuando una estación en la nube DVMRP desea recibir tránsito multicast de un grupo multicast cuya fuente se encuentra en la nube PIM-SM. Del lado DVMRP, el receptor queda aguardando que el tránsito multicast lo alcance, pues por la filosofía dense-mode todos los flujos activos van a llegar al receptor (excepto cuando explícitamente rechazados por el mensaje de prune). Al lado de la red PIM-SM, los enrutadores permanecen esperando que se haga una requisición explícita solicitando el tránsito de ese grupo multicast, algo que solamente puede venir de "adentro" de la red PIM-SM. En este momento ocurre un impase y el cliente en la red DVMRP puede quedar sin acceso al flujo multicast deseado. Aunque ya hayan ocurrido esfuerzos para implementar un protocolo de interconexión entre redes DM y SM (RFC 2715), poco se ha evolucionado en la cuestión. Las ventajas evidentes en la utilización de PIM-SM prácticamente lo tornaron estándar como protocolo multicast en grandes backbones. Como consecuencia, el uso de DVMRP quedó estancado (sino reducido) mundialmente, mientras cada vez más enrutadores han incluido soporte para PIM-SM y cada vez más redes han implementado PIM-SM.

En el caso de RNP y sus clientes, aún existen varias redes cuyos enrutadores no tienen capacidad para ejecutar multicast nativo. En estas situaciones, el uso de DVMRP es la única solución, ya que se puede implementar sin muchos problemas en estaciones Unix comunes a través del software mrouted. Para estos casos, estaremos aplicando algunos workarounds [soluciones en que se contorna un problema sin solucionarlo; ajustes] propuestos por Cisco (fabricante de los actuales enrutadores de RNP) para resolver las cuestiones de incompatibilidad entre DVMRP y PIM-SM. En determinados casos estos workarounds se aplican y en otros casos no. La única solución de largo plazo para el problema es el reemplazo del hardware/software de los enrutadores por equipos/versiones más nuevas. Esto fatalmente ocurrirá en los próximos años.

¿Existe alguna alternativa para evitar el conflicto entre los protocolos?

Adenilson Raniery: Entre las posibles soluciones tenemos:

1-Montar túneles DVMRP directamente para el RP de la red, en el PoP-RJ. Como en la red PIM-SM todos los grupos multicast tienen que ser registrados en el RP, túneles DVMRP conectados al mismo pasarían a tener acceso a todos los grupos activos de la red.

2-Considerar que todos los receptores en la red DVMRP también serán transmisores. En este caso, el tránsito generado por el cliente en la nube DVMRP alcanza la red PIM-SM, que pasa a "reconocer" la existencia de este cliente y comienza a mandar tránsito para el mismo también. Esta situación ocurre por ejemplo con aplicaciones de videoconferencia.

3-Utilizar un protocolo DM (como el PIM-DM) en el camino entre la nube DVMRP y el RP. En este caso, ambas redes poseen la misma filosofía dense-mode de operación y los problemas de incompatibilidad son eliminados. Sin embargo, el backbone vuelve a sufrir los problemas tradicionales de un protocolo dense mode, como ineficacia.

Todas las soluciones presentan ventajas y desventajas. Aún estamos analizando la gravedad de este problema y las alternativas para solucionarlo o por lo menos reducir sus efectos. Hasta que tengamos condiciones de llevar PIM-SM al usuario final, por medio de enrutadores capaces de hacer esto, se tendrá que mantener la interoperación entre PIM-SM y DVMRP.

¿En cuánto tiempo el servicio estará implementado en todos los PoPs?

Adenilson Raniery: La implementación de multicast en los PoPs propiamente dichos se podrá realizar en poco tiempo. Actualmente, todos los 13 PoPs equipados con enrutadores 7507 ya están funcionando en multicast nativo. En los demás PoPs, como ya dije, tendremos que implementar una máquina funcionando en mrouted para recibir un túnel multicast y realizar el enrutamiento multicast. Aunque laboriosa, esta segunda etapa también no deberá extenderse mucho, pues ya tenemos el know-how para eso. Espero que podamos concluir esta segunda fase en algunos meses.

La cuestión principal consiste en expandir el servicio multicast a los clientes de los PoPs. Esta fase será la más extensa y complicada de todas, pues involucrará una gran variedad de equipos, como enrutadores, firewalls y switches diversos que podrán complicar la implementación. La participación activa de los PoPs e instituciones clientes en ese proceso será muy importante para difundir el servicio multicast suministrado por RNP. Note que también será necesario que dispongamos de aplicaciones atrayentes para que haya interés por el servicio multicast. En particular, considero que la transmisión de eventos importantes (como el Simposio Brasileño de Redes de Computadoras, reuniones del IETF y de NANOG, entre otras) vía multicast puede ser un buen camino para tornar el servicio conocido y utilizado en RNP.

¿El tránsito del MBone se podrá recibir por la red de RNP?

Adenilson Raniery: Sí. Todas las sesiones activas del MBone están disponibles en Internet2 y por lo tanto, RNP puede acceder a este tránsito a través de su conexión internacional con Internet2. Es interesante recordar que esta conexión también garantiza la accesibilidad multicast de RNP para receptores en el exterior. Por lo tanto, el tránsito multicast generado por fuentes interiores a RNP se podrá visualizar en el exterior, en el caso que los receptores posean acceso al backbone de Internet2.

¿Usted podría mencionar algunos PoPs que tomaron la delantera configurando el equipo para implementación del servicio multicast por cuenta propia?

Adenilson Raniery: Rio Grande do Sul y Minas Gerais ya tienen infraestructuras de redistribución de multicast locales, basadas en DVMRP. La interconexión de esas nubes DVMRP con el backbone PIM-SM se hace en los 7507 de los respectivos PoPs. Ya logramos éxito en la transmisión de contenido multicast para clientes en estas redes, como en el "Curso de Perfeccionamiento para Profesores de Matemática del Enseño Medio", transmitido a partir del Instituto de Matemática Pura y Aplicada (Impa) al inicio de este año [ver reportaje RNP usó multicast en transmisión de curso del Impa].

¿Cómo se efectuará la distribución de contenido multicast para los clientes de los PoPs?

Adenilson Raniery: Se podrá hacer de dos maneras: en modo nativo, en el caso que el PoP disponga de otros enrutadores capaces de realizar esta función en términos de hardware y software; o en modo tunelado, a través del uso de túneles DVMRP y estaciones Unix (de preferencia FreeBSD) funcionando en mrouted. En el caso de PoPs que reciben la transmisión en modo tunelado, la distribución para los clientes sólo se podrá hacer a través de túneles DVMRP.

[RNP, 09.04.2002]