Saltar al contenido

Cómo funciona IP multicast. Todos los protocolos relacionados

Hasta ahora, hemos asumido que las comunicaciones tienen un emisor y un receptor y que los paquetes que generan se encaminando usando IP y se comprueba los errores mediante TCP. En esta lección, introduciremos el caso de un emisor, que desea enviar la misma información a mútilples destino.

De momento, solo conocemos dos soluciones a este problema:

  • Mandar mediante unicast con una sesión por cada destino
  • Mandar mediante broadcast a todos los vecinos, lo cual es un desperdicio de recursos, pues la mayoría de nodos no van a querer esos datos.
https://s3-us-west-2.amazonaws.com/secure.notion-static.com/c5804dbe-3c07-4e21-b2aa-b269dbf594c7/Screenshot_2020-04-30_at_16.14.01.png
Funcionamiento de Multicast

Ventajas:

  • Reducción del consumo de ancho de banda
  • Reducción de la carga de los servidores y de la red

Inconvenientes:

  • Transmisión no fiable basada en UDP, pues con TCP sería inviable devido al alto número de ACK
  • No se usan mecanismos de control de la congestión (Tema 4)

En resumen, en multicast:

  • No existe requisito alguno para transmitir, pues se designan IP especiales de tipo multicast
  • Los receptores deben unirse al grupo multicast para recibir los datagramas
  • Los routers se coordinan para hacer que los datagrmas lleguen a los receptores.

Direccionamiento y control de ámbito

Las direcciones IP Multicast son las direcciones que especifican a un conjunto arbitrario de usuarios. Usan las direcciones de clase D que van desde la 224.0.0.0 a la 239.255.255.255:

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/ad0f5085-6dfa-44db-bc3e-e72c7f387c0f/Screenshot_2020-04-30_at_16.20.50.png

Existen una serie de direcciones reservadas por la IANA y otras que se utilizan únicamente para ámbito local, como las famosas 192.168.X.Y. El resto pueden ser utilizadas de forma dinámica y libre.

Control de ámbito

¿Cómo controlar hasta dónde viaja un paquete multicast? Porque claro, cualquier pueda transmitir el paquete sin permiso explícito y cualquier host en Interner puede suscribirse a un grupo multicast cualquiera.

Las solcuiones que se proponen son:

  • TTL Scoping: consiste en limitar el alcance de este valor de TTL, los routers descartan el paquete: configurar aplicaciones multicast privadas con valores de TTL inferior a ese threshold para impedir que los paquetes salgan al exterior.
  • Administrative Scoping: consiste en reservar determinados rangos de direcciones multicast para que solo sean distribuidos internamente. Los routers multicast se encagarán de no distribuir los datagramas con esas direcciones como destinos.

Actualmente se utiliza más TTL Scooping por ser más intuitivo.

Protocolos de gestión de grupos

Para la gestión de grupos, se utiliza el protocolo IGMP o Internet Group Management Protocol. Solo funciona en redes donde hay algún host.

Su funcionalidad básica es la siguiente: un router necesita saber en qué redes conectadas a sus interfaces existen hosts unidos a determiandos grupo G multicast. Da igual cuantos hosts estén suscritos al grupo G, solo interesa saber si hay alguno.Los mensajes IGMP se envían sobre protocolo IP con TTL = 1, de host a router y sin reenvíos.

IGMPv1

Operación básica

IGMP no es parte integra de IP, por lo que se manda encapsulado.

Podemos encontrar dos tipos de mensajes:

  • IGMP Query: Los routers los envían de forma periódica por cada una de sus interfaces para saber si hay algún host interesado en unirse a algún grupo.
  • IGMP Report: Enviada cuando un host quiere unirse a un grupo multicast por primera vez o cuando responde a un IGMP Query. Se envía a la dirección IP Multicast a la que desea unirse.

Para unirse al grupo, el host debe mandar de forma asíncrona un mensaje IGMP Report.

Para mantenerse en el grupo, uno de los host (y solo uno) deberá responder de forma periódica al IGMP Query que manda el router. El router solo necesita saber si hay alguien interesado, no cuántos ni quienes.

Para abandonar el grupo no hay que hacer nada. Cuando no quede ningún host contestando los IGMP Query del router, este supone que no hay ningún host interesado.

IGMPv2

La v2 incorpora

  • Mejora aspectos referentes al abandono de un grupo
  • Soluciona cuestiones de interoperabilidad
  • Es la versión más utilizada

IGMP no es parte integra de IP, por lo que se sigue mandando encapsulado.

Se incorporan algunas nuevas funcionalidades:

  • En las Group Specific Queries el router puede preguntar por el interés en un grupo específico.
  • Con los Leave Group Message se notifica de forma explícita el abandono de un grupo.
  • Con el mecanismo Query Election cuando en una red hay varios routers solo uno envía queries. El router con menor IP se elige como Querier y el resto como non-Querier. Si por alguna razón no escuchan al Querier mandar peticiones durante un par de iteraciones, se reinicia la elección.
  • Se añade el Query-Interval Response Time que es un tiempo máximo que espera un router para dar un grupo por vacío.

Al igual que en la v1, para unirse, los host mandan de forma explícita un IGMP Report. Para el mantenimiento en el grupo, el Querier manda IGMP Query (pueden ser para un grupo específico) de forma periódica que responde un miembro del grupo por cada Grupo Specific Query que se manda.

Para abandonar el grupo es diferente. Si ese host no fue quien respondió al último Query, simplemente abandona el grupo sin notificar. Si fue quien respondió el último Query, manda un mensaje Leave.

IGMPv3

Aporta posibilidad de unirse solo a determinadas fuentes de un grupo multicast

Encaminamiento Multicast

Árboles multicast y fowarding y multicast fowarding

IGMP permite a los routers conocer qué subredes tienen hosts interesados en un grupo para reenviar tráfico por esa interfaz. Pero, ¿cómo llega el flujo multicast desde la fuente hasta ese último router? Es necesario contar con protocolos de enrutamiento para propagar esta información de modo que el tráfico emitido a un grupo multicast llegue a todas las redes donde haya un receptor interesado.

Se crea un árbol de distribución desde la fuente hasta los diferentes hosts interesados en recibir dicho tráfico, los árboles pueden ser de 3 tipos:

  • Árboles multicast de coste mínimo (Steiner): la suma de todos los costes de los enlaces del árbol es mínima. Son lo más eficientes, pero son muy complejos de calcular, además de ser imposible saber si ese árbol es mínimo o no (NP-completo). NO SE USA.
  • Árboles de comino más corto (SPT): unión de caminos más cortos de la fuente a cada destino. Las rutas hacia los destinos se comparten hasta que éstas divergen.
  • Árboles compartidos (ST). Existe un router central de encuentro entre emisores y recpetores (RP). Cuenta con las rutas más cortas entre distintas fuentes y el router raíz, y entre el router raiz y los receptores.

Una vez construido el árbol, hay que enviar los datagramas mediante multicast forwarding. En multicast, el routing se preocupa por el origen del paquete, en vez del destino del paquete.

  1. Le llega un paquete desde una fuente hacia un grupo.
  2. El router comprueba que el datagrama ha llegado por la interfaz correcta mediante RPF Check (interfaz más corta hasta llegar a la fuente).
  3. El router reenvía por las interfaces almacenadas en la entrada para dicho grupo en su multicast forwarding cache.

Tipos de protocolos de encaminamiento

  • Modo denso. Asumen que existe un gran número de receptores para cada grupo. Siguen un comportamiento de inundación y poda. Funcionan mejor cuando hay alta probabilidad de que haya receptores interesados.
  • Modo dispreso. Los routers donde hay receptores interesados solicitan la creación del camino correspondiente. Funcionan mejor cuando los receptores son excasos y se encuentran muy dispersos.
  • Algoritmos híbridos.

Protocolo DVMRP (Dense mode)

Inundación y poda. Cada minuto se olvidan las ramas podadas y se vuelve a inundar. Mantiene una tabla de routing multicast usada para hacer kis RPF checks.

Los mensajes utilizados son los siguientes:

  • DVMRP Probe. Mensaje para descubrir a los routers vecinos que hablan DVMRP.
  • DVMRP Report. Comunica a sus vecinos su vector distancia a las subredes IP conocidas
  • DVMRP Prune. Indica a su vecino que no teine interesados y que por lo tanto no quiere recibir tráfico.
  • DVMRP Graft. Indica a su vecino que pese haberle dicho antes que no tenía interesados, ahora sí los tiene.
  • DVMRP Graft Ack. Asentimiento del mensaje anterior.

Descubrimiento de vecinos. Al arrancar, un R2 no conoce ningún vecino, por lo que manda a R1 una lista de vecinos vacía. Al recibir R1 este mensaje, sabe que tiene como vecino R2, por lo que lo añade a su lista de vecinos y se la manda a R2. Ahora R2 sabe que tiene como vecino también a R1 y lo añade su lista de vecinos.

Intercambio de rutas. Una vez conocidos los vecinos, mediante el mensaje DVMRP Report se intercambian sus vectores distancias. Aquí se usa Poisson Reverse para anunciar coste infinito para rutas cuando el router al que le mandamos el vector es el mejor camino para llegar a dicha ruta. De esta manera se crea el árbol de rutas.

Poda. Una vez creado el árbol inicial, los routers que no tienen ningún host interesado en dicho tráfico multicast, ni tinenen ningún router vecino en su OIL (es decir, no tengo a nadie a quien reenviar los datagramas), solicito un DVMRP Prune indicando la fuente y el grupo al cual deseo desuscribirme.

Injerto. En este caso se envía un DVMRP graft indicando la fuente y el grupo. El router padre añade este router hijo a su OIL, y si estaba vacía, repite este proceso hacia arriba. Confirma al hijo con DVMRP Ack.

Protocolo PIM-SM (Sparse mode)

El objetivo es evitar la inundación periódica de la red que e produce con los protocolos en modo denso

  • Asume que hay pocos receptores

Se elige un router que actúa como punto de encuentro (RP o Rendevouz Point) para cada grupo multicast. Las fuentes se registran en el RP para hacer llegar los mensajes y los receptores se unen hacia el RP para recibir estos datagramas (Explicit Join).

El tráfico podrá fluir mediante un árbol ST o un SPT. En un principio lo hace por el árbol compartido y según un valor denominado SPT-Threeshold dependerá lo rápido que un camino pasará del árbol compartido (ST) al arbol de caminos cortos (SPT). Si SPT-Threeshold = 0, significa que cambiará lo antes posible y si SPT-Threeshold = infinito, nunca se cambia.

  • La elección del RP es crucial para el funcionamiento del servicio
  • Sólo puede elegirse un RP por grupo
  • El RP puede no ser el mismo para distintos grupos

Procesos y Mensajes PIM-SM

Descubrimiento de vecinos. Se envían de forma periódica mensajes Hello por cada una de las interfaces con TTL = 1. Mediante este mensaje, si hay varios routers en la red, se designa un router designado (DR) que será el encargado de registrar en el RP las fuentes que se localicen en dicha red.

Unión al grupo multicast. Cuando aparece un receptor interesado en una red, el router envía un mensaje Join(*,G)por aquella interfaz que según la tabla de rutas unicast le da el camino más corto hasta el RP de dicho grupo. Si la entrada no existe, el mensaje se propaga hasta llegar a un router que si disponga de dicha entrada para tener una conexión con el RP.

Registro de nuevas fuentes. Cuando un router recibe tráfico multicast de una fuente y es el DR de la red, envía un mensaje Register en IP con dirección origen la del DR y dirección destino la de RP. Cuando el RP recibe este mensaje, se desencapsula de IP y se emite como tráfico multicast. Para evitar tener que estar encapsulando tráfico multicast en unicast, el RP manda un Join(S,G) hasta la fuente para crear así una ruta multicast. Una vez que se ha creado la ruta y para evitar seguir recibiendo tráfico por duplicado, el RP manda un mensaje Register-Stop a la fuente para que ya solo emita el tráfico por el nuevo canal.

Proceso de poda. Se realiza mandando el mensaje Prune(*,G). Si queremos realizar una poda en el árbol compartido, se envía el mensaje de poda hacia el RP. Si por el contrario estamos ya en modo SPT, el mensaje de poda se deberá enviar hacia la fuente (DR de la red).

Mantenimiento del estado. Para evitar que los routers se queden con información anticuada, cada 3 minutos se elimina la información que no haya sido actualizada. Para mantener actualizadas las tablas, se envían mensajes Join y Prunecada minuto.