Multicast: Conceptos Generales

¿Por qué es necesario multicast?

 

En términos generales, las aplicaciones usan dos modelos de transmisión de datos sobre redes IP: unicast y multicast.

 

El modelo unicast requiere una conexión uno-a-uno entre los receptores interesados en recibir un determinado flujo de datos y la fuente. Este requerimiento implica que los recursos de red próximos a la fuente han de estar correctamente dimensionados para ser capaces de transportar tantos flujos como receptores interesados en dicho contenido puedan existir.

 

Diseñar la red teniendo en cuenta ese tipo de dimensionamiento no tendría mucho sentido en la mayor parte de los casos ya que dependería del número y localización de los receptores, parámetros dinámicos que probablemente serán desconocidos con antelación y pueden seguir patrones ligados a hábitos de consumo de los usuarios.

 

El dimensionamiento del ancho de banda es un parámetro importante a la hora de diseñar una red de distribución de contenidos unicast y puede limitar enormemente la escalabilidad de un determinado diseño, pero es sólo uno de los factores a considerar.

 

El modelo multicast, por el contrario, cuenta con un modelo de conectividad mucho más flexible y se adapta a modelos de distribución de contenidos uno-a-muchos, muchos-a-muchos y otras variantes. En una red habilitada para tráfico multicast la red transporta un único flujo de datos por cada fuente, siendo ‘la red’ la responsable de entregar el flujo de datos a los receptores que previamente señalen a la misma el interés en recibirlo. Este modelo de diseño permite mejorar enormemente la escalabilidad que podríamos conseguir con el modelo unicast.

 

Algunas de las ventajas de una solución multicast de distribución de contenidos son:

 

  • Escalabilidad: ya que los requisitos de ancho de banda ya no son proporcionales al número de receptores.

  • Rendimiento: debido a que el procesamiento de un único flujo de datos por fuente siempre será más eficiente que procesar un flujo por receptor.

  • Menor gasto de capital (CAPEX): debido a la relajación en las especificaciones de los elementos de red necesarios para proporcionar el servicio.

 

Casos de uso

 

El diseñador de red debería tener en cuenta una solución de distribución de contenidos basada en multicast siempre que las necesidades de negocio requieran una solución escalable que permita entregar flujos de datos de una o más fuentes a ‘habitualmente’ muchos receptores.

 

Aunque los casos típicos son uno-a-muchos y muchos-a-muchos, existen algunas variantes que tienen sus propias características y requisitos de diseño, como son las variantes de muchos-a-uno, pocos-a-muchos o pocos-a-pocos.

 

La tabla resume algunos ejemplos de casos de uso para cada modelo.

 

 

Uno-a-muchos

Muchos-a-muchos

Muchos-a-uno

Pocos-a-muchos

Pocos-a-pocos

IPTV, Radio

Juegos en red

Pujas

Publicación compartida

Video conferencia

Distribución de software

Video conferencia

Votaciones

Resultados deportivos

Audio conferencia

Noticias de trading

Trading

Video vigilancia

Sensores emergencias

Dispositivos IoT

 

 

Transporte

 

Hoy en día, el modo más común de transportar flujos de datos con direccionamiento multicast pasa por UDP. UDP no es, por diseño, ni orientado a conexión ni fiable como es TCP. UDP proporciona servicio en modo best effort, o lo que es lo mismo, la red hará lo posible por entregar el tráfico al destino sin ninguna garantía.

 

Manteniendo la capa de transporte de datos simple, la complejidad del diseño de un servicio de entrega fiable de datagramas se traslada directamente al lado del desarrollo de aplicaciones. Los desarrolladores deberían tener en cuenta las demandas de funcionalidad adicional de las aplicaciones de negocio para poder suplir aquellas que no proporcione la red y que sean fundamentales desde el punto de vista empresarial.

 

Los puntos principales que debieran ser abordados por los desarrolladores de aplicaciones por la falta de un protocolo de transporte como TCP son:

 

  • Transporte de datos ordenado (duplicados, entrega desordenada)

  • Retransmisión de datagramas perdidos (debido a descartes)

  • Detección de errores

  • Control de flujo (diferentes velocidades entre emisor o fuente y receptor)

  • Control de congestión (condiciones puntuales de congestión en la red)

 

Es importante comprobar las necesidades de negocio con el objetivo de identificar aquellas funcionalidades que tengan sentido para el negocio o servicio, ya que, dependiendo del mismo, habrá algunas que tengan sentido en un caso de uso, como la distribución de software, pero no en otro, como la retransmisión de audio o vídeo en directo.

 

Enrutamiento

 

El enrutamiento en multicast es en sentido contrario al del enrutamiento unicast de tal modo que el estado de forwarding se define desde el receptor hacia la fuente.

 

En el caso de enrutamiento unicast tradicional, la dirección de destino indica explícitamente a donde enviar los paquetes de datos, y cada dispositivo a lo largo del camino determina el siguiente salto e interfaz de salida basándose en la información que cada nodo tiene disponible localmente.

 

En el caso de multicast, la dirección destino es una dirección multicast que identifica a un determinado “Grupo multicast”. La dirección de grupo no indica a los elementos de red donde reenviar los datos recibidos y será necesario crear información de estado adicional con antelación para habilitar el flujo de datos desde fuentes a receptores.

 

  • El receptor muestra interés en recibir datos de un determinado grupo (*,G) y quizás de una fuente en particular (S,G).

  • La red construye un árbol de distribución multicast (MDT) para ser capaz de entregar el flujo de datos desde la fuente al receptor.

 

La distribución de contenidos multicast utiliza protocolos específicos con objeto de definir la información de forwarding necesaria y su estado asociado en los dispositivos de red.

 

 

Ámbito

Protocolos

Host-Router

MLD

Router-Router

PIM (ASM, SSM, BiDir)

 

 

Una vez que el árbol de distribución multicast se encuentra constituido, los datos fluyen desde la fuente a los receptores siguiendo el árbol. La figura adjunta muestra una visión general simplificada de los protocolos del plano de control involucrados en la construcción del árbol multicast y la señalización de los receptores a su elemento de enrutamiento más cercano el interés en recibir datos de un determinado grupo y posiblemente fuente.



mcast-general-arch.png