PIM Sparse Mode

Introducción

Hemos estado hablando de IP Multicast. Este mes voy a empezar a cubrir el modo PIM Sparse. Artículos anteriores que pueden ser de interés:

  • Los protocolos de la multidifusión IP
  • Modo denso PIM

Modo disperso frente a modo denso

Recordemos que el modo denso PIM se utiliza (en principio) cuando se desea la multidifusión en la mayoría de los lugares. Así, los paquetes iniciales de multidifusión se inundan en todas partes, con la poda cortando el tráfico a las ubicaciones que no necesitan la alimentación de multidifusión. Hasta hace poco, el modo denso PIM sufría de re-inundaciones periódicas cada 3 minutos, pero en la versión 12.1(5)T, la función PIM Dense Mode State Refresh alivió esto. Con esta función, el modo denso PIM es posiblemente adecuado para la implementación sencilla de la multidifusión. Especialmente cuando el control adicional del Modo PIM Sparse no es necesario, y donde la inundación «accidental» ocasional no sería muy perjudicial.

El Modo PIM Sparse utiliza un enfoque de solicitud explícita, donde un router tiene que pedir la alimentación de multidifusión con un mensaje PIM Join. El modo PIM Sparse está indicado cuando se necesita un control más preciso, especialmente cuando se tienen grandes volúmenes de tráfico de multidifusión IP en comparación con el ancho de banda. El modo PIM Sparse escala bastante bien, porque los paquetes sólo van a donde se necesitan, y porque crea estado en los routers sólo cuando es necesario. Debido a esto, ha sido escrito como un Protocolo Experimental de Internet.

El precio que pagamos por este control extra es una leve complejidad extra. El modo Sparse de PIM utiliza un router especial llamado Punto de Encuentro (RP) para conectar la fuente de flujo o el árbol de multidifusión con el router próximo al aspirante a receptor. El RP se suele utilizar sólo temporalmente, como veremos más adelante.

Puede haber diferentes RP para diferentes grupos multicast, que es una forma de repartir la carga. Normalmente hay un RP por grupo multicast. La redundancia de RP’s es un tema avanzado, y requiere una experiencia un poco más profunda. Una forma de hacerlo es con el protocolo MSDP (posible artículo posterior en la serie).

Recordemos que un mensaje Join de PIM se envía hacia una Fuente (o para PIM-SM, posiblemente hacia un RP), basado en el enrutamiento unicast. El mensaje Join dice en efecto «necesitamos una copia de los multicasts por aquí». Conecta al remitente del Join y a los routers que intervienen con cualquier árbol multicast existente, hasta llegar al objetivo del Join si es necesario. Un mensaje Prune dice en efecto «ya no necesitamos esto por aquí». Un router que recibe un Prune ve si tiene otras interfaces que requieran el flujo multicast, y si no, envía su propio mensaje Prune. Una técnica avanzada consiste en organizar una copia separada y quizás diferente de la información de enrutamiento unicast sólo para fines de multidifusión. Esto permite «dirigir» los mensajes Join. El MultiProtocolo BGP, MBGP, para multicast, es una forma de hacerlo (posible artículo posterior en la serie).

Punto de Encuentro Básico (RP)

Hemos visto hasta ahora que PIM-SM utiliza un Punto de Encuentro (RP), para conectar fuente y receptores. Sólo puede haber un RP por grupo de multidifusión, y la implementación más sencilla utiliza un RP para todos los grupos de multidifusión.

Vamos a hablar de los fundamentos de cómo se utiliza el RP. Supongamos que la fuente comienza a enviar antes de que haya receptores. Si las cosas suceden al revés, algunos de los detalles cambian ligeramente, pero no es muy diferente.

Entonces: la fuente multicast comienza a enviar. Como ya hemos apuntado, no hay ningún protocolo ni nada para registrar las fuentes con la multidifusión IP. La fuente envía y es el router o routers vecinos los que tienen que hacer lo correcto. Con PIM-SM, el router vecino conoce el RP. (El router vecino reenvía los datos multicast al RP encapsulándolos en un mensaje o mensajes de registro unicast. El enrutamiento normal entrega el Registro al RP. El RP desencapsula la multidifusión y reenvía copias hacia abajo de cualquier Árbol Compartido (hay uno pre-construido si había receptores unidos antes de que la Fuente comenzara a enviar). Si hay receptores (interfaces de salida del estado del árbol compartido), el RP envía un Join PIM de vuelta hacia la Fuente. Esto conecta la Fuente al RP con un Árbol de Origen, el (S, G) Árbol de Ruta Más Corta (SPT). Una vez que el RP recibe multicasts a lo largo de este SPT, envía un Register-Stop para indicar al router de la Fuente que deje de enviar paquetes Register. La razón de este comportamiento es que no se pierden paquetes multicast, si hay receptores ya presentes.

Por cierto, si no hay receptores presentes, se envía el mensaje Register-Stop. Entonces, cuando un receptor aparece posteriormente (IGMP al router vecino, PIM Join del router vecino de vuelta al RP), entonces el RP envía el PIM Join a la fuente en ese momento.

La siguiente figura asume que hay una fuente y receptores activos (no mostrados). El receptor mostrado envía un IGMP Report al router D. El router D entonces envía un PIM Join hacia el RP. Como hay otros receptores, el RP ya está unido al árbol de origen (mostrado en azul) y está recibiendo el flujo multicast. Pasa los paquetes del flujo del Árbol de Origen a través del Árbol Compartido, mostrado en verde.

Bueno, ahora tenemos los paquetes que van de la Fuente al RP a lo largo del Árbol de Origen (Árbol de Ruta Corta, SPT), y del RP al receptor a lo largo del Árbol Compartido. Cuando la tasa de bits agregada (*, G) de los paquetes (de todas las fuentes) supera un umbral en Kbps, esto hace que el router más cercano al receptor intente unirse al Árbol de Origen. Envía un Join hacia el origen del flujo multicast. Nótese que el Join anterior que envió fue hacia el RP. El Join hacia la fuente va router por router hacia la Fuente hasta que encuentra un router que ya está en el Árbol de la Fuente. Esto añade el router cercano al receptor al árbol de la fuente. Cuando se recibe un paquete a lo largo de ese árbol, se envía un Prune hacia el RP. En efecto, «gracias, pero ahora estoy recibiendo mi multidifusión al por mayor, no al por menor», ya que este proceso corta el RP en el medio.

La siguiente figura muestra cómo funciona esto. Las flechas rojas de arriba a la izquierda muestran el Join hacia el Source. Esto hace que el flujo azul superior se ponga en marcha, los paquetes se reenvían a lo largo del árbol de origen. Las flechas rojas de abajo a la derecha son los Prunes, ya que el flujo del Árbol Compartido ya no es necesario (mostrado como línea verde discontinua). Obsérvese que los paquetes del Árbol de Origen llegan al Receptor por un camino más directo, generalmente con menor latencia.

Por cierto, nosotros controlamos el umbral. Es configurable. Por defecto es cero Kbps: recibimos un paquete, y pasamos al árbol de fuentes. Si tenemos muchas fuentes para un determinado grupo de multidifusión (pensemos en una conferencia telefónica, VoIP), entonces hay una entrada (S, G) de Source Tree para cada una. Si configuramos el umbral para que nunca se active, entonces todos los paquetes pasan por el RP (algo así como un puente de llamadas de conferencia), utilizando sólo el (*, G) Árbol Compartido. El umbral también se utiliza para el switchback así como para el switchover. Los árboles de origen de baja tasa (S, G) se conmutan de nuevo al árbol compartido. El volumen de tráfico se comprueba cada minuto.

Si un receptor desea unirse, y su router vecino está en el SPT (Árbol de Origen), entonces la entrada del Árbol Compartido de la interfaz saliente se copia en la entrada del Árbol de Origen, lo que protege de tener que enviar el tráfico al RP y luego «volver» al router en el SPT.

Por cierto, te estarás preguntando, ¿qué sentido tiene tener el RP aquí? Debido al mecanismo de umbral, el RP nos da una forma de utilizar el Árbol Compartido, y controlar la creación explosiva de información de estado en los routers si muchos receptores se unen al mismo tiempo.

Árboles Compartidos Versus Árboles de Origen

El Modo Sparse de PIM (PIM-SM) puede utilizar tanto los Árboles Compartidos (que pasan por el RP) como los Árboles de Origen (para una entrega directa eficiente a lo largo del camino «más corto» desde la fuente al receptor). Normalmente, puede utilizar ambos. Si la entrega eficiente es menos importante para usted, y la disminución de la cantidad de información de estado mantenida por los routers es más importante, entonces PIM puede ser configurado para utilizar sólo un Árbol Compartido.

Cuando un router PIM-SM recibe un paquete de multidifusión, comprueba el Árbol de Origen para esa dirección de origen y grupo de multidifusión (destino) en particular. Si no hay ninguna entrada presente, entonces comprueba si hay una entrada del Árbol Compartido (*, G) para el grupo multicast. Si hay entradas para ambos árboles, la interfaz de entrada indica al router qué árbol debe utilizar. Si ambos árboles tienen la misma interfaz de entrada, entonces el bit RP para una entrada (S, G) evita la duplicación de paquetes: esto indica que la interfaz RPF se encuentra a lo largo del Árbol Compartido.

Para un flujo de multidifusión con al menos un receptor activo, la ruta entre el origen y el RP será parte del Árbol de Origen. (Tenga en cuenta que «el camino entre» es un poco vago aquí, estoy tratando de mantenerse alejado de dar demasiados detalles.)

Las entradas del Árbol Compartido conectarán el RP con algunos de los receptores. La interfaz RPF para el (*, G) Shared Tree es la interfaz en la dirección del RP, no la fuente del grupo multicast. Por eso existe la posibilidad de que los Árboles Compartidos (S, G) Fuente y (*, G) tengan diferentes interfaces RPF.

Las entradas del Árbol Compartido (*, G) muestran las interfaces en las que se recibió una unión al RP, o las interfaces con miembros del grupo conectados directamente (configurados o recibidos por IGMP). Las entradas del árbol de origen (S, G) muestran dónde se recibió un Join o un Prune o un Register.

Configuración del modo Sparse de PIM

La parte básica de lo que se necesita es:

ip multicast-routing

interface ethernet 0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
interface ethernet 1
ip address 10.1.2.1 255.255.255.0
ip pim sparse-mode

También es necesario indicar a cada router el RP, ya sea para todos los grupos o para grupos seleccionados (utilizando listas de acceso para especificar qué RP para qué grupos). Esto se puede hacer de forma estática con:

ip pim rp-address 1.2.3.4

Veremos las otras opciones para gestionar el RP en el próximo artículo.

En Conclusión

El mes que viene veremos las distintas formas de trabajar con los Puntos de Encuentro. También es posible que toquemos ligeramente un par de otros temas de multidifusión IP más avanzados.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.