Comunicaciones multicast
Resumen
El presente trabajo muestra en detalle las comunicaciones multicast con idea de conocer sus ventajas generales, y a su vez hacer una comparativa con las comunicaciones unicast que se usan principalmente en los sistemas de almacenamiento en red. Así también se describen algunos aspectos importantes en el desarrollo de sistemas de comunicación basados en multicast.
Palabras clave: comunicaciones multicast, protocolo multicast fiable, fiabilidad, control de congestión, NAK.Abstract
This work shows multicast communications in detail with the idea of knowing the general advantages, and in turn makes a comparison with unicast communications that are mainly used in network storage systems. This work also describes some important aspects in the development of communication systems based on multicast.
Keywords: multicast communication, reliable multicast protocol, reliability, congestion control, NAK.Introducción
El intercambio de datos entre computadores es el objetivo principal de las comunicaciones en el campo de la informática. Inicialmente la comunicación implementada permitía sólo la trasferencia entre un único origen y un único destino (comunicación uno-a-uno). La creciente evolución de las tecnologías de comunicación ha permitido alcanzar un progreso notable permitiendo la comunicación de un origen con múltiples destinos simultáneamente (comunicaciones uno-a-muchos y muchos-a-muchos). A esta forma de comunicación se le conoce como comunicación de grupo o alternativamente también conocida como multicast. La utilización y aprovechamiento de estas comunicaciones sigue siendo un tema de interés para los investigadores.
En la actualidad, la comunicación en una red de ordenadores es esencial para las aplicaciones, en especial para las aplicaciones distribuidas, tal como los sistemas de ficheros distribuidos. La comunicación multicast ha estado en el centro de interés en el área de Internet y ha contribuido en algunos éxitos importantes (ver, por ejemplo [11] .
En infraestructura de red con IP (Internet Protocol), se usa IP multicast como método para comunicaciones uno-a-muchos y muchos-a-muchos. Los datos se envían sólo una vez, aunque lo reciban un número elevado de destinos. Los conmutadores de la red se encargan de replicar los datos (paquetes) por las salidas del conmutador necesarias para que alcancen todos los nodos del grupo de destinos. Se utiliza una dirección de grupo IP multicast. Lo utiliza tanto el origen como los destinos. [9] .
Una videoconferencia es un claro ejemplo para mostrar las ventajas que puede ofrecer la comunicación multicast sobre la comunicación uno-a-uno.
Una de las principales ventajas es la eficiencia alcanzada para llegar a todos los miembros de un grupo al mismo tiempo [11].
Tipos de comunicación
Para alcanzar los objetivos planteados en éste trabajo ha sido necesario analizar los tipos de comunicación existentes. El modelo TCP/IP ofrece diversos tipos de comunicación, dónde, en algunos casos permite la fiabilidad en la entrega de los datos.
El enfoque principal de desarrollar un sistema de comunicaciones en esta investigación se deriva de hacer envíos simultáneos a diferentes receptores, de tal modo que, con esta propuesta se logre disminuir el tráfico en la red. En este contexto se pueden diferenciar diversos tipos de comunicación en función del número de emisores y receptores involucrados en la comunicación.
Básicamente podemos encontrar los siguientes tipos de comunicación:
- Unicast.
- Multicast.
- Broadcast.
Aunque en la literatura existen algunos otros tipos de comunicación, en este trabajo sólo nos enfocamos en los tipos anteriormente mencionados y que se describen en las siguientes subsecciones.
Comunicación unicast
La comunicación unicast es una comunicación uno-a-uno o punto-apunto, por lo tanto, se puede utilizar para la comunicación en aplicaciones cliente/servidor en las que hay exactamente un emisor y un receptor.
Estas comunicaciones están principalmente dirigidas por el emisor de datos identificando la dirección IP del receptor. De tal modo que, los paquetes unicast usan la dirección del dispositivo de destino para la entrega de los datos, además estos datos pueden pasar por una interconexión de redes.
Este tipo de comunicación es la forma más común y eficiente de la comunicación con un único nodo. La comunicación no involucra otros nodos que no se han identificado dentro del paquete enviado por el emisor [7].
La Figura 1 muestra un ejemplo donde nodo1 establece conexión con su dirección IP como origen para iniciar envío de datos a la dirección IP de nodo2 como el destino.
Figura 1: Comunicación unicast
En este tipo de comunicaciones se requieren transmisiones de control (reconocimientos positivos o ACK) desde el receptor hacia el emisor para comprobar la entrega de los datos. La comunicación unicast se utiliza únicamente para la comunicación entre dos nodos. Por lo tanto, si se pretende usar unicast para dar soporte de comunicación multicast será necesario establecer un total de canales de comunicación del orden de (n(n*1))/2 para un grupo de tamaño n [11].
Comunicación multicast
Mientras que unicast permite el envío de datos entre un emisor y un receptor, las comunicaciones multicast permiten el envío de datos desde un emisor a muchos receptores (uno-a-muchos), o desde muchos emisores a muchos receptores (muchos-a-muchos) si la gestión de los grupos se realiza de forma adecuada. Los envíos a muchos receptores se realizan de forma simultánea, de tal manera que se puede reducir el número de canales de comunicación que se ha descrito en la subsección 4.2.1. Para identificar los grupos multicast, se utiliza una clase de dirección IP específica que se describe en la sección 4.4. Por ejemplo, en la Figura 2 el nodo1 envía datos a los nodos nodo2 y nodo3 que se han asociado a la dirección multicast 239.5.5.0. En el ejemplo, el nodo1 sólo envía un mensaje a la dirección multicast sin la necesidad de establecer comunicación con cada nodo receptor. Además el nodo4 no recibe el tráfico porque no se ha asociado a la dirección multicast.
Figura 2: Comunicación multicast
Para habilitar comunicaciones multicast, en la capa de red se utiliza el protocolo TCP/IP. De forma más específica esto implica implementar protocolos una capa por encima del protocolo UDP. La desventaja de UDP es que no garantiza la entrega de los datos. Por lo tanto, es necesario agregar mecanismos de detección de pérdida y retransmisión de datos.
En la actualidad los conmutadores que conectan los nodos de una red tienen soporte para administrar los grupos multicast. Estos grupos multicast pueden crecer o disminuir dinámicamente. Los nodos se unen (join) a un grupo multicast si están interesados en recibir tráfico dirigido a la dirección multicast de dicho grupo y lo deja (leave) cuando dejan de estar interesados.
El Internet Group Management Protocol (IGMP) permite llevar a cabo la comunicación entre los nodos y los conmutadores de la red.
Comunicación broadcast
La comunicación broadcast es comparable con la comunicación multicast ya que existe un solo emisor. En cambio, con broadcast un solo mensaje se entrega a todos los potenciales receptores (por ejemplo, en una subred), mientras que con multicast solo lo reciben los nodos interesados en el tráfico.
La manera más común de lograr la comunicación broadcast es utilizar una dirección de difusión especial, en la cual se indica al mecanismo de comunicación que el mensaje debe ser entregado a todos los nodos de la subred. En la Figura 3 se muestra un ejemplo de comunicación broadcast donde el emisor envía un único mensaje a todos los nodos de la misma subred que el emisor. La dirección IP 255.255.255.255 es comúnmente utilizada para la comunicación broadcast. Al enviar un mensaje broadcast, el emisor no necesita conocer el número de receptores.
Figura 3: Comunicación broadcast
Broadcast es menos eficiente porque ocupa más infraestructura de la red al enviarlo a todos los nodos quieran o no quieran los datos, y también porque el emisor no ha identificado el conjunto de receptores. Además, los envíos broadcast puede ser ineficiente porque los nodos reciben el mensaje en la capa de red, esto implica hacer una interrupción para procesar el mensaje y pasarse a la capa superior, incluso puede resultar que ninguno de los nodos de la subred estén interesados en el mensaje. Un claro ejemplo del uso de broadcast se puede encontrar en el protocolo de resolución de direcciones o Address Resolution Protocol (ARP) [8] .
Multicast vs Unicast
Multicast se refiere a la entrega de datos de forma simultánea a un grupo de nodos receptores como destino, desde un emisor como origen. Por el contrario, en unicast un emisor se comunica con un único nodo receptor de destino. De tal manera que con unicast, si un emisor necesita comunicarse con 3 nodos receptores, tiene que establecer 3 canales de comunicación. En cambio, multicast permite crear un sólo canal de comunicación para los 3 nodos receptores. Si se requiere implementar aplicaciones basadas en unicast el propio protocolo TCP, al ser un protocolo orientado a la conexión, permite mantener un control de flujo y de congestión para la entrega fiable de los datos, además mantiene un orden en la entrega de estos. Aunque, también es posible hacer implementaciones unicast basadas en UDP, es responsabilidad del programador en este caso dar soporte de fiabilidad en la entrega de datos según las características de las aplicaciones. UDP permite aprovechar las comunicaciones multicast, que, por lo contrario a unicast, proporcionan soporte de envíos simultáneos. Las desventajas más destacables si se usa UDP en implementaciones multicast son las siguientes:
- Pérdida de paquetes: Se pueden perder paquetes debido a que se trata de un protocolo que no mantiene una conexión con el receptor. Por lo tanto es necesario desarrollar aplicaciones multicast con entrega fiable de datos. En la actualidad, el tema "Reliable multicast " sigue siendo un área de interés para la investigación.
- Congestión: La falta del uso de ventanas de envío como en TCP y de mecanismos para ajustar las tasas de envío puede dar lugar a la congestión de la red. Como consecuencia, estos aspectos también deben ser considerados siguiendo las necesidades de transmisión de las aplicaciones.
Por otra parte, los sistemas distribuidos pueden aprovechar ciertas características destacablemente importantes de multicast, por mencionar algunas:
- Mejora la eficiencia: permite mejor uso ancho de banda de la red disponible y reduce considerablemente la carga de los dispositivos de red y nodos fuente y destino.
- Optimiza el rendimiento: permite eliminar la redundancia del tráfico al disminuir los canales para el envío de datos.
IP multicast
El direccionamiento de tráfico multicast se realiza mediante una IP especial. Mientras que para la comunicación punto a punto se utilizan direcciones IP de la clase A, B y C. En cambio, para establecer comunicaciones multicast se utiliza la dirección IP de la clase D. En la Figura 4 se describen las clases de direcciones IP que componen el conjunto de direcciones de la pila TCP/IP.
Figura 4: Tipos de direcciones IP
La clase de una dirección IP se determina a partir de los bits del orden superior. De la Figura 4, en la clase A, B y C la sección red corresponde a la identificación de la red. El rango de direcciones de red de la clase A comprende de 1.0.0.0 hasta 127.225.255.255, de la clase B de 128.0.0.0 hasta 191.255.255.255, de la clase C de 192.0.0.0 hasta 223.255.255.255. Para estas clases la sección nodo es para administrar las subredes y los nodos finales.
El rango de direcciones multicast comprende de 224.0.0.0 hasta 239.255.255.255. El rango de direcciones de 224.0.0.0 hasta 224.0.0.255 está reservado para asignaciones permanentes de diferentes aplicaciones, en las que se incluyen los protocolos de ruteo.
Algunas direcciones multicast actualmente asignadas se mencionan en la Tabla 1.
Tabla 1: Asignación de direcciones IP
| Dirección IP | Asignación |
| 224.0.0.1 | Todos los sistemas en la subred |
| 224.0.0.2 | Todos los enrutadores en la subred |
| 224.0.0.4 | Todos los enrutadores DVMRP |
| 224.0.0.5 | Todos los enrutadores OSPF |
| 224.0.0.9 | Todos los enrutadores RIP2 |
| 224.0.0.13 | Todos los enrutadores PIM |
| 224.0.0.15 | Todos los enrutadores CBT |
El alcance de los paquetes IP viene dado por el campo TTL (Time to Live ) de la cabecera del paquete. TTL es un mecanismo que contabiliza los saltos y determina el alcance de la red que el paquete puede atravesar.
Inicialmente se define un valor TTL en la aplicación. Por cada salto que el paquete realiza el valor TTL se decrementa una unidad, causando la pérdida del paquete cuando el valor TTL se establece a 0 ya que se ha alcanzado el número máximo de saltos para llegar al destino. Típicamente, el valor asignado para comunicaciones multicast en una red local, se establece un TTL de 1.
La unión de un nodo a un grupo multicast se inicia desde el receptor utilizando el protocolo IGMP. Actualmente existen tres versiones de este protocolo (IGMPv1 [1] , IGMPv2 [3] e IGMPv3 [4] ) que permite la gestión de los grupos multicast desde los enrutadores o desde los conmutadores con soporte IGMP Snooping. Por ejemplo, en la Figura 5, el nodo B envía al conmutador un mensaje join con la dirección multicast del grupo al que desea asociarse, en este caso la dirección 239.5.5.0. Cuando el conmutador recibe esta petición registra el puerto al que está conectado el nodo B en una tabla de entradas multicast. Una vez realizado el registro de éste puerto, el nodo B puede recibir el tráfico multicast que el nodo A envía a la dirección multicast 239.5.5.0. Para abandonar el grupo multicast, el nodo B únicamente tiene que enviar un mensaje leave al conmutador en el que se indica que desea abandonar el grupo. Cuando el conmutador registra el puerto del nodo B asociado a la dirección 239.5.5.0 inicializa un temporizador configurable, que representa el tiempo que tiene el nodo B para permanecer dentro del grupo. De esto se deduce que, a nivel de aplicación, es necesario mantener un mecanismo que permita que el nodo B se mantenga permanentemente dentro del grupo multicast de interés.
Figura 5: Funcionamiento básico del protocolo IGMP (se indica el orden de las acciones)
El mapeo de las direcciones multicast en un entorno IPv4 a nivel de red se realiza sobre las direcciones físicas que corresponde al tipo de red que se utiliza. Por ejemplo, en el caso de direcciones unicast, a nivel de red se obtiene la dirección física asociada a la dirección IP mediante el uso del protocolo ARP. Mientras que, para el caso específico de direcciones físicas Ethernet, en [1] se definen procedimientos para obtener las direcciones físicas de direcciones IP multicast. Dado que las redes Ethernet son las más comunes, el mapeo de direcciones multicast se lleva a cabo como se describe a continuación. En primer lugar se asignan a los 24 bits de mayor peso de la dirección MAC los valores 01:00:5E. El bit posterior siempre lleva un valor de 0 y los 23 bits de menor peso restantes contienen el valor de los 23 bits de menor peso de la dirección multicast IPv4. Por ejemplo la dirección IP multicast 239.5.5.0 utilizada en el ejemplo de la Figura 5, se correspondería con la dirección física Ethernet 01:00:5E:05:05:00.
Aspectos importantes para multicast
En comunicaciones multicast, el intercambio de datos se realiza entre más de dos nodos de una red. En esta sección se explican algunos mecanismos relacionados con la comunicación, especialmente relevantes en comunicaciones multicast, en los que se incluyen: fiabilidad, control de flujo y congestión y gestión de los grupos multicast. En entornos multicast, en ocasiones es más complejo implementar estos mecanismos que para la comunicación unicast. Lo anterior debido a las características particulares de cada nodo dentro de un grupo y, de la cantidad de grupos dentro de la red.
Fiabilidad
En [11] se puede encontrar una definición tradicional de este término: "un servicio fiable es aquel en el que todos los datos se entregan al receptor en el orden correcto, sin errores y sin ninguna duplicación. Si no es posible proporcionar un servicio fiable, por ejemplo, a causa de un fallo de enlace, generalmente se informa al usuario y la comunicación finaliza". Como describe Wittmann, los mecanismos utilizados para proporcionar servicios fiables se basan en la suposición de que existe sólo un emisor y un receptor.
Un protocolo multicast fiable debe asegurar que todos los nodos receptores reciben todos los datos desde los emisores. Esta fiabilidad en la transmisión resulta útil, por ejemplo, en los sistemas de ficheros distribuidos. Los datos y las posteriores actualizaciones deben enviarse a todos los nodos de almacenamiento con el fin de asegurar que la consistencia de los datos se mantiene. Por lo tanto, el protocolo tiene que garantizar la entrega fiable a todos los receptores.
El termino fiabilidad también está relacionado con los mecanismos de detección y recuperación de errores, y por lo tanto deben ser considerados para el desarrollo de un protocolo fiable. Un mecanismo básico para la detección de errores consiste en asignar números de secuencia a los paquetes que se envían a los receptores, de tal modo que los receptores mantengan un mecanismo de comprobación de secuencia para detectar pérdida de paquetes. En cuanto al mecanismo de recuperación de errores, en las implementaciones unicast y en algunos casos multicast cada receptor envía un reconocimiento positivo (ACK) por cada paquete que recibe dando lugar al problema conocido como implosión de ACK. Por ejemplo, en la Figura 6 se muestra un ejemplo en el que un emisor puede aumentar la carga de trabajo causada por los ACK enviados desde los receptores. En el ejemplo se ilustra un emisor que puede ser saturado como consecuencia del envío de un sólo paquete de datos. En entornos donde existen diversos grupos multicast, el incremento del envío de ACK puede ser considerablemente elevado. Como la probabilidad de fallo es baja, sería más eficiente usar para conseguir fiabilidad reconocimientos negativos (NAK) en lugar de reconocimientos positivos (ACK), así se evitaría la implosión de ACK. Este mecanismo permite disminuir la carga de trabajo de los emisores y al mismo tiempo reducir el tráfico de la red, debido a que los receptores únicamente envían al emisor un NAK por cada paquete que no se recibe o que se llega con errores. En la Figura 7 se ilustra la disminución del tráfico generado para mantener la recuperación de paquetes perdidos. Por este motivo se prefiere el uso de AK frente a ACK en aplicaciones o protocolos basados en UDP, especialmente cuando se utilizan comunicaciones multicast.
Figura 6: Saturación por ACKs en emisor (las líneas en verde significa el envío de datos y en rojo los ACK).
Figura 7: Mecanismo de recuperación con NAK (las líneas en verde significa el envío de datos, en amarillo un paquete que no se ha recibido o llega con error y en rojo los paquetes NAK).
Control de flujo y de congestión
Es necesario implementar mecanismos de control de flujo y congestión para regular la tasa de envío de datos entre los nodos que participan en la comunicación. Los mecanismos implementados para unicast (basadas en TCP) están diseñados para la comunicación entre dos nodos. Aunque existen implementaciones de estos mecanismos para UDP (sea para comunicaciones unicast o multicast) es necesario estudiar las necesidades de las aplicaciones para intentar adaptar estos requerimientos a las nuevas implementaciones.
Los mecanismos de detección y recuperación de errores están relacionados con el control de flujo de los datos. El mecanismo de control de flujo permite gestionar la tasa de envío de datos del nodo emisor hacia el (los) receptor (es) con la intención de evitar que un emisor rápido sature a un receptor lento. Existen dos enfoques que se comparan sistemáticamente en [10] , unos basados en el emisor y otros en el receptor. En el segundo enfoque, recae en el receptor la responsabilidad de informar al emisor para ajustar la tasa de envío de acuerdo a su estado de saturación en el búfer de recepción. En esa comparación se manifiesta que el enfoque basado en el receptor mantiene un mejor rendimiento que el enfoque opuesto. Normalmente, el enfoque basado en el receptor utiliza paquetes NAK debido a que permite evitar la saturación por paquetes ACK. En [2] [11] se describen los mecanismos utilizados para ajustar el control de flujo de datos y que son ampliamente utilizados por el protocolo TCP.
El mecanismo de control de congestión puede ayudar a prevenir la saturación de la red o de los búferes de los nodos receptores. Por lo tanto, mantiene una estrecha relación con el control de flujo. Este mecanismo permite regular la tasas de envío de datos de los emisores permitida según el estado de la red. En un entorno multicast, este mecanismo requiere de información detallada de los receptores (capacidad de los búfer de recepción, direcciones multicast a las que se ha asociado, etc.) para facilitar el flujo de datos desde varios emisores. Esta información se puede utilizar como medida preventiva para evitar la congestión, tanto de la red como en los nodos receptores. De tal manera que el protocolo garantice la fiabilidad en la entrega de los datos a todos los receptores de forma transparente. En un sistema de ficheros distribuido, el control de congestión tiene un papel importante debido a que el tráfico generado por estos sistemas suele ser elevado y persistente en la red cuando se trata de envíos muy grandes.
Gestión de grupos multicast
Antes de hacer el envío de datos desde un emisor a una dirección multicast, es necesario que exista la unión de los nodos de la red interesados en recibir el tráfico. Un nodo puede unirse a diferentes direcciones multicast y el emisor puede no pertenecer al grupo multicast donde envía los datos.
El protocolo IGMP permite gestionar, dada una dirección IP multicast, la pertenencia de un nodo a un determinado grupo multicast. Además, a nivel de conmutador las implementaciones de IGMP Snooping en estos dispositivos facilita conocer el estado de uso de direcciones multicast y de los nodos que pertenecen a esta. Un conmutador que implementa IGMP Snooping escucha los mensajes IGMP enviados por los nodos de la red y proporciona una transmisión selectiva de tráfico multicast basado en la información de dirección multicast que contiene cada mensaje. Por tanto, la gestión adecuada de los grupos multicast bajo IGMP Snooping permite hacer una distribución de datos evitando que el tráfico se convierta a envíos similares a broadcast.
Ancho de banda y latencia
Las aplicaciones basadas en multicast tienen requisitos comunes con las aplicaciones unicast. Principalmente cuando se trata de transferir datos de gran tamaño, de tal manera que puede impactar en el consumo de ancho de banda de la red y que además deben mantener una baja latencia. Algunas aplicaciones tienen requisitos de retardo estrictos mientras que otros no.
Algunas aplicaciones consumen un importante ancho de banda, como por ejemplo las aplicaciones de transferencia de ficheros, mientras que otras mantienen un bajo uso de ancho de banda [5] .
En general, las aplicaciones se deben diseñar de tal manera que se puedan adaptar a la variabilidad del estado de la red, principalmente cuando se experimentan momentos de congestión. Además, deben ser adaptables a las condiciones de la red, en el sentido de que es posible que algunas aplicaciones unicast hagan uso del ancho de banda común. Aunque, en un entorno de cluster de computadores los nodos suelen tener una arquitectura homogénea, también es posible que algunos nodos se encuentren más saturados que otros; es decir, puede existir diversidad en la capacidad de procesamiento.
Es importante que las aplicaciones tengan esto cuenta. De igual forma, la tecnología de almacenamiento puede afectar el funcionamiento de las aplicaciones. Si en los nodos se consideran dispositivos de almacenamiento suficientemente rápidos que puedan atender las demandas, por ejemplo, de las transferencias de grandes volúmenes de datos, puede ser posible aprovechar de forma óptima el ancho de banda global de la red.
En entornos de cluster de computadores la latencia de la red puede ser muy baja, de tal manera que puede no ser perceptible por las aplicaciones. Sin embargo, la tecnología de almacenamiento puede penalizar el rendimiento global de las aplicaciones, como ocurre en el siguiente ejemplo. Supongamos un nodo receptor que recibe datos desde dos direcciones multicast, se crean entonces dos hebras de recepción, una por cada dirección multicast. Supongamos además que cada hebra, al mismo tiempo, debe escribir los datos en disco para garantizar fiabilidad. Bajo estas condiciones, el incremento de la latencia de la escritura en disco es considerablemente alta, hasta el punto que el ancho de banda de escritura en disco puede disminuir por debajo del 50 % (en el capítulo 6 se hace un amplio análisis y se muestran algunos resultados importantes).
Aplicaciones multicast
Actualmente el IP multicast juega un papel importante en el entorno de Internet. Las comunicaciones multicast permiten a los desarrolladores añadir, a las aplicaciones o protocolos, mayor funcionalidad sin impactar de forma importante en la red. El desarrollo de aplicaciones o protocolos multicast es aparentemente simple. A nivel de datagrama es posible que cualquier aplicación pueda enviar datos a una dirección multicast. Simplemente a nivel de aplicación es necesario aumentar el valor TTL de tal manera que los datagramas tengan la facilidad de atravesar los enrutadores hasta llegar al destino. Para recibir los datagramas multicast, basta con habilitar la unión a una dirección multicast de forma transparente mediante un informe de pertenencia al grupo multicast común. Sin embargo, la habilitación del soporte multicast en aplicaciones y protocolos es un reto importante, principalmente cuando: el envío de flujos de datos es constante, se requiere una entrega fiable de datos, y hay que gestionar un elevado número de grupos multicast. Estos aspectos requieren pues una consideración especial en este trabajo.
Las aplicaciones multicast se desarrollan con el soporte de la capa de transporte del protocolo UDP. Aunque, TCP proporciona un servicio a las aplicaciones, tal como, recuperación ante la pérdida de paquetes, corrección de errores, una entrega ordenada, etc. Sin embargo, TCP únicamente proporciona servicios de comunicación unicast. En cambio, UDP, aunque proporciona servicios mínimos, por ejemplo, detección de errores (si un paquete se detecta con error, simplemente se descarta), da soporte para las comunicaciones multicast. Por lo tanto, las aplicaciones multicast se deben ejecutar sobre UDP, como ilustra la Figura 8. Para dar fiabilidad a las aplicaciones multicast es necesario establecer mecanismos, como los descritos en la sección 4.5.
Figura 8: Implementación de aplicaciones sobre UDP para dar soporte multicast
En [6] se hace una clasificación de algunas aplicaciones multicast donde se hace distinción entre aplicaciones multimedia y aplicaciones de manipulación de datos, y entre aplicaciones que envían datos en tiempo real y lo contrario a éstas (Figura 9). En esta figura, la columna de la izquierda incluye las aplicaciones de transmisión de datos en tiempo real.
Figura 9: Clasificación de aplicaciones multicast
Las aplicaciones con restricciones de tiempo real requieren baja latencia, lo que supone un mayor reto en sistemas de ficheros con requisitos de fiabilidad debido a que los mismos datos deben ser distribuidos a múltiples nodos.
En cuanto a la columna de la derecha de la misma figura, describe las aplicaciones donde no es necesaria una transmisión en tiempo real. En este caso, aunque no tienen requisitos estrictos de latencia, usualmente necesitan fiabilidad y escalabilidad.
Las aplicaciones multimedia en tiempo real, por su parte, no requieren una fiabilidad estricta. En este caso se requiere asegurar que llegan los datos, no importa que lleguen con retraso, y que los posibles errores no degraden el flujo multimedia a un nivel que pueda ser percibido por el ser humano [6] . En la Figura 9, en particular el recuadro de aplicaciones de datos en tiempo real, se ha agregado los sistemas de ficheros distribuidos. Comúnmente estas aplicaciones requieren hacer la entrega en tiempo real para realizar las operaciones sobre los datos (HDFS puede ser un caso particular, donde el sistema Hadoop primero envía los datos a los nodos de almacenamiento y posteriormente lanza las tareas a realizar por el paradigma MapReduce). Por otra parte, hay aplicaciones multimedia o de datos que requieren una transferencia fiable pero no en tiempo real. Por ejemplo, el sistema DRBD, aunque en esencia hace manipulación de datos, en algunos casos puede ser que la transmisión de datos a los nodos secundarios no sea en tiempo real (de forma particular en DRBD se refiere a los protocolos A y B).
En [9] se hace una descripción de tres categorías de aplicaciones multicast que las diferencia totalmente de las aplicaciones unicast. Uno a muchos (1-M): Un solo nodo envía datos a dos o más receptores.
- Muchos a muchos(M-M): Cualquier número de nodos envían datos al mismo grupo multicast, además de recibir de esa dirección.
- Muchos a uno(M-1): Cualquier número de nodos receptores que envían datos a un emisor a través de unicast o multicast.
De [9] se extrae parte de una clasificación que ha sido adaptada a las necesidades de este trabajo con el fin de simplificar la explicación de los tipos de aplicaciones que hacen uso de comunicaciones multicast. En la Figura 10 (donde S(m) se refiere a envío multicast y R(m) a recepción multicast) se define el tipo de aplicaciones en términos de la combinación de mecanismos de comunicación que utilizan, es decir la relación de la E/S que representan. Por ejemplo, a nivel de IP, la multidifusión de E/S siempre es 1-M o M-M, mientras que para unicast siempre se utiliza 1-1.
Figura 10: Aplicaciones multicast en relación a la E/S y a la distribución de datos
Aplicaciones uno a muchos (1-M)
Las comunicaciones 1-M tienen un solo emisor y muchos receptores simultáneos. Por ejemplo, la relación B1 de la Figura 10, muestra la clásica relación para la comunicación 1-M. En la Figura 11 se hace una representación de la distribución básica en este tipo de aplicaciones.
Algunos ejemplos de este tipo de aplicaciones pueden ser: radio por internet, vídeo bajo demanda, videoconferencia, etc. Por lo tanto, las aplicaciones 1-M se caracterizan por el envío de datos de una vía. Es decir, si se establece esta configuración, un emisor no puede recibir el tráfico de datos generado por él mismo hacia la dirección multicast específica.
Figura 11: Aplicaciones multicast uno a muchos
Aplicaciones muchos a muchos (M-M)
En las aplicaciones muchos a muchos, dos o más receptores también pueden actuar como emisores (relación C1, C2, C3 de la Figura 10). De tal manera que las aplicaciones M-M se pueden caracterizar por el envío de datos de dos vías. En este entorno un nodo emisor puede recibir los datos que el mismo ha enviado a una dirección multicast específica. Con este esquema de comunicación, cada nodo que ejecuta una aplicación M-M puede recibir datos desde múltiples emisores y al mismo tiempo también enviar datos. Por lo tanto, esto puede plantear un reto importante en la gestión de las comunicaciones. De igual forma, este mecanismo permite que el propio nodo emisor, reciba los mismos datos que envía a la dirección multicast. Esto puede suponer en algunos casos que se reciban datos que en realidad no se van a usar. La Figura 12 muestra un ejemplo generalizado del mencionado entorno de comunicación.
Figura 12: Aplicaciones multicast muchos a muchos
Aplicaciones muchos a uno (M-1)
Las aplicaciones muchos a uno pueden ser de una sola vía (al igual que las aplicaciones uno a muchos) o de dos vías si se utiliza un protocolo de petición/respuesta. Esto consiste en que, cualquiera de los emisores o receptores puede generar una solicitud. Las aplicaciones muchos a uno se diferencia de las aplicaciones 1-M y M-M en que no representa un mecanismo de comunicación en la capa IP, de tal modo que, las aplicaciones M-1 tienen múltiples emisores y un receptor [9]. La Figura 13 ilustra las características esenciales en la comunicación.
Figura 13: Aplicaciones multicast muchos a uno
Bibliografía
[1] S. Deering. RFC-1112: Host extension for IP multicasting. Request For Comments, 1989.
[2] K. R. Fall and W. R. Stevens. TCP/IP illustrated, volume 1: The protocols. addison-Wesley, 2011.
[3] W. C. Fenner. Internet Group Management Protocol, Version 2. 1997.
[4] I. Kouvelas, B. Cain, B. Fenner, S. Deering, and A. Thyagarajan. Internet Group Management Protocol, Version 3. 2002.
[5] A. Mankin, V. Paxson, A. Romanow, and S. Bradner. IETF criteria for evaluating reliable multicast transport and application protocols. 1998.
[6] C. K. Miller. Multicast networking and applications. Addison-Wesley Reading, 1999.
[7] H. Osterloh. IP Routing Primer Plus. Sams Publishing, 2001.
[8] D. Plummer. Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48. bit Ethernet address for transmission on Ethernet hardware. 1982.
[9] B. Quinn and K. Almeroth. IP multicast applications: Challenges and solutions. 2001.
[10] D. Towsley, J. Kurose, and S. Pingali. A comparison of sender initiated and receiver-initiated reliable multicast protocols. Selected Areas in Communications, IEEE Journal on, 15(3):398{406, 1997.
[11] R. Wittmann and M. Zitterbart. Multicast Communication: Protocols, Programming, & Applications. Morgan Kaufmann, 2000.
[a] Profesor Investigador de la Universidad Autónoma del Estado de Hidalgo, Escuela Superior de Huejutla.
[b] Profesor de la Universidad Autónoma del Estado de Hidalgo, Escuela Superior de Huejutla.
Compartir en: