Como probablemente sepa, el conjunto de las direcciones IP está divido en «clases» basado en los bits de mayor orden en una dirección IP de 32 bits.
Bit -> 31 0 Rango de direcciones:
+-+----------------------------+
|0| Direcciones de clase A | 0.0.0.0 - 127.255.255.255
+-+----------------------------+
+-+-+--------------------------+
|1 0| Direcciones de clase B | 128.0.0.0 - 191.255.255.255
+-+-+--------------------------+
+-+-+-+------------------------+
|1 1 0| Direcciones de clase C | 192.0.0.0 -
223.255.255.255
+-+-+-+------------------------+
+-+-+-+-+----------------------+
|1 1 1 0| Direcciones MULTICAST| 224.0.0.0 -
239.255.255.255
+-+-+-+-+----------------------+
+-+-+-+-+-+--------------------+
|1 1 1 1 0| Reservadas | 240.0.0.0 - 247.255.255.255
+-+-+-+-+-+--------------------+
La que nos interesa es la «Clase D». Cada datagrama de IP cuya dirección destino empieza por «1110» es un datagrama IP de Multicast.
Los 28 bits restantes identifican el «grupo» multicast al que se envía el datagrama. Siguiendo con la analogía anterior, debe sintonizar su radio para oír un programa que se transmite a una frecuencia determinada, del mismo modo debe «sintonizar» su kernel para que reciba paquetes destinados a un grupo de multicast específico. Cuando hace esto, se dice que el ordenador se ha unido a aquél grupo en el interfaz especificado. Esto se verá más adelante.
Hay algunos grupos especiales de multicast, o «grupos de multicast bien conocidos», y no debería usar ninguno de estos en una aplicación determinada dado que están destinados a un propósito en particular:
Todos estos grupos especiales de multicast son publicados cada cierto tiempo en el RFC de «Números asignados».
En cualquier caso, el conjunto de direcciones de la 224.0.0.0 a 224.0.0.255 están reservados localmente (para tareas administrativas y de mantenimiento) y los datagramas enviados a estos nunca se envían a los encaminadores multicast. De manera similar, el conjunto 239.0.0.0 a 239.255.255.255 ha sido reservado para ámbitos administrativos [administrative scoping, n. del t.] (para más información ver la explicación sobre el TTL más abajo).
Los ordenadores pueden estar en tres niveles en lo que se refiere al cumplimiento de la especificación de Multicast, de acuerdo con los requisitos que cumplen.
Se está en Nivel 0 cuando no hay soporte para Multicast en IP. Un buen número de los ordenadores y los encaminadores de Internet están en este nivel, ya que el soporte de multicast no es obligatorio en IPv4 (sí lo es, sin embargo, en IPv6). No es necesaria mucha explicación aquí: los ordenadores en este nivel no pueden enviar ni recibir paquetes multicast. Deben ignorar los paquetes enviados por otros ordenador con capacidades de multicast.
En el Nivel 1 hay soporte para envío pero no para recepción de datagramas IP de multicast. Nótese, por tanto, que no es necesario unirse a un grupo multicast para enviarle datagramas. Se añaden muy pocas cosas al módulo IP para convertir un ordenador de «Nivel 0» a «Nivel 1», como muestra la sección Envío de Datagramas multicast.
El Nivel 2 es el de completo soporte a multicast en IP. Los ordenadores de nivel 2 deben ser capaces de enviar y recibir tráfico multicast. Tienen que saber la forma de unirse o dejar grupos multicast y de propagar ésta información a los encaminadores multicast. Es necesario incluir, por tanto, una implementación del Protocolo de Gestión de Grupos de Internet (Internet Group Management Protocol, IGMP) en su pila TCP/IP.
Por ahora debe ser evidente que el tráfico multicast es manipulado en el nivel de transporte con UDP, ya que TCP provee de conexiones punto a punto que no son útiles para tráfico multicast. (Se está llevando a cabo una fuerte investigación para definir e implementar nuevos protocolos de transporte orientados a multicast. Ver la sección Protocolos de transporte Multicast para más detalles).
En principio, una aplicación sólo necesita abrir un socket UDP y poner como dirección de destino la dirección multicast de clase D donde quiere enviar sus datos. Sin embargo, hay algunas operaciones que el proceso emisor debe ser capaz de controlar.
El campo TTL (Time To Live, Tiempo de vida) en la cabecera IP tiene un doble significado en multicast. Como siempre, controla el tiempo de vida de un datagrama para evitar que permanezca por siempre en la red debido a errores en el encaminamiento. Los encaminadores decrementan el TTL de cada datagrama que pasa de una red a otra y cuando este valor llega a 0 el paquete se destruye.
El TTL del multicast en IPv4 tiene también el significado de «barrera». Su uso se hace evidente con un ejemplo: supongamos que tiene una vídeo conferencia larga, que consume mucho ancho de banda, entre todos los ordenadores que pertenecen a su departamento. Así que quiere que esa gran cantidad de tráfico permanezca en su LAN y no salga fuera. Quizás su departamento es suficientemente grande para tener varias LANs. En este caso quieres que los ordenadores que pertenecen a cada una de sus LANs atiendan la conferencia, pero en ningún caso quiere colapsar todo Internet con su tráfico multicast. Es necesario limitar hasta dónde se expandirá el tráfico multicast entre encaminadores. Para esto se utiliza el TTL. Los encaminadores tienen una barrera TTL asignada a cada uno de sus interfaces, de forma que sólo los datagramas con un TTL mayor que la barrera del interfaz se reenvían. Sin embargo, cuando un datagrama atraviesa un encaminador con una barrera determinada, el TTL del datagrama no se ve decrementado por el valor de la barrera. Sólo se hace una comparación (como antes, el TTL se decrementa en uno cada vez que un datagrama pasa por un encaminador).
Una lista de las barreras de TTL y su ámbito asociado es la siguiente:
TTL ámbito
.........................................................
0 Restringido al mismo ordenador. No se enviará por ningún
interfaz.
1 Restringido a la misma subred. No será reenviada por ningún
encaminador.
<32 Restringido al mismo «sitio», la misma organización o
departamento.
<64 Restringido a la misma región. <128 Restringido al mismo
continente. <255 Sin ámbito restringido. Global.
Nadie sabe qué significa exactamente «sitio» o «región». Es tarea de los administradores decidir qué límite tienen estos ámbitos.
El truco-TTL no es siempre suficientemente flexible para todas las necesidades, especialmente cuando se trata con regiones solapadas o se desea establecer límites geográficos, topológicos o de ancho de banda de manera simultanea. Para resolver estos problemas, se definieron regiones de multicast de IPv4 con ámbito administrativo en 1994 (ver el borrador de Internet de D. Meyer: «administratively Scoped IP Multicast»). Se definen los ámbitos basándose en direcciones de multicast en lugar de en TTLs. El rango 239.0.0.0 a 239.255.255.255 se reserva para estos ámbitos administrativos.
Cuando el ordenador emisor es de nivel 2 y también miembro del grupo al que se envían los datagramas, por defecto se envía una copia también a sí mismo, lo que se conoce con el nombre de loopback. Esto no significa que la tarjeta interfaz relea sus propias transmisiones, reconociéndolas como dirigidas al grupo al que pertenece y las recoja de nuevo de la red. Al contrario, es la capa IP la que, por defecto reconoce el datagrama que va a enviar y lo copia y encola en la cola de entrada de IP antes de enviarlo.
Este comportamiento es deseable en algunos casos, pero no en otros. Así que el proceso emisor puede activarlo o desactivarlo según desee.
Los ordenadores conectados a más de una red deberían ofrecer la posibilidad a las aplicaciones para que estas puedan decidir qué interfaz de red será usado para enviar las transmisiones. Si no se especifica, el kernel escogerá uno por defecto basándose en la configuración realizada por el administrador.
El broadcast es (en comparación) más sencillo de implementar que el multicast. No necesita que ningún proceso le dé ninguna regla al kernel para que éste sepa qué hacer con los paquetes de broadcast. El kernel ya sabe que hacer: leer y entregar todos ellos a las aplicaciones apropiadas.
Con multicast, sin embargo, es necesario avisar al kernel cuáles son los grupos multicast que nos interesan. Esto es, debemos pedir al kernel que se «una» a estos grupos multicast. Dependiendo del hardware que haya por debajo, los datagramas de multicast son filtrados por el hardware o por la capa IP (y en algunos casos por ambos). Y sólo aquellos con un grupo destino previamente registrado son aceptados.
Esencialmente, cuando nos unimos a un grupo le estamos diciendo al kernel: «Vale. Sé que, por defecto, ignoras datagramas multicast, pero recuerda que estoy interesado en este grupo multicast. Así que lee y entrega (a cualquier proceso interesado en estos, no sólo a mí) cualquier datagrama que veas en este interfaz de red con este grupo de multicast como su dirección destino».
Algunas consideraciones: en primer lugar, destacar que no sólo se une uno a un grupo. Se une a un grupo en un interfaz de red determinado. Por supuesto, es posible unirse al mismo grupo en más de un interfaz. Si no se especifica un interfaz en concreto entonces el kernel lo elegirá en base a sus tablas de encaminamiento cuando se vayan a enviar datagramas. Es también posible que más de un proceso se una al mismo grupo multicast en el mismo interfaz. Todos ellos recibirán los datagramas enviados a ese grupo vía ese interfaz.
Como se ha dicho antes, los ordenadores con capacidades multicast se unen al grupo todos los ordenadores en el arranque, así que «pingeando» a 224.0.0.1 nos devolverá todos los ordenadores de la red que tienen el multicast habilitado.
Finalmente, un proceso que desee recibir datagramas multicast tiene que pedir al kernel que se una al grupo y hacer un «bind» al puerto al que se dirigen los datagramas. La capa UDP utiliza tanto la dirección de destino como el puerto para demultiplexar los paquetes y decidir a qué socket/s entregarlos.
Cuando un proceso ya no está interesado en un grupo multicast, informa al kernel que él quiere abandonar este grupo. Es necesario entender que esto no significa que el kernel no acepte más datagramas multicast dirigidos a ese grupo multicast. Seguirá haciéndolo si hay más procesos que hicieron una petición «unirse en multicast» a ese grupo y siguen interesados. En este caso el ordenador recuerda los miembros del grupo, hasta que todos los procesos deciden dejarlo.
Aún más: si abandonas el grupo, pero se permanece unido al puerto donde se recibe el tráfico multicast, y hay más procesos que se unieron al grupo, seguirás recibiéndose las transmisiones multicast.
La idea es que unirse a un grupo multicast sólo dice al nivel de IP y de enlace (que en algún caso se lo dirá explícitamente al hardware) que acepten datagramas multicast para ese grupo. Quienes son realmente miembros de un grupo son los ordenadores, no los procesos que corren en esos ordenadores.
Tanto en Ethernet como en FDDI, las tramas tienen un campo de dirección destino de 48 bits. Para permitir un tipo de ARP multicast que proyecte las direcciones de multicast IP sobre las Ethernet/FDDI, el IANA reservó un conjunto de direcciones para multicast: cada trama Ethernet/FDDI con su dirección destino en el rango 01-00-5e-00-00-00 a 01-00-53-ff-ff-ff (hexadecimal) contiene datos para un grupo multicast. El prefijo 01-00-5e identifica la trama como de multicast, el siguiente bit es siempre 0, y así sólo se dejan 23 bits para la dirección multicast. Ya que los grupos de multicast IP son de 28 bits la proyección no puede ser uno a uno. Sólo los 23 bits menos significativos del grupo multicast IP se ponen en la trama. Los 5 bits más significativos son ignorados, dando lugar a 32 grupos de multicast que se proyectan a la misma dirección Ethernet/FDDI. Esto significa que el nivel de Ethernet actúa como un filtro imperfecto, y el nivel IP tendrá que decidir si aceptar o no los datagramas que el nivel de enlace le ha entregado. El nivel IP actúa como el filtro definitivo perfecto.
Los detalles de Multicasting IP sobre FDDI se dan en el RFC 1390:
«Transmission of IP and ARP over FDDI Networks». Para más
información en la proyección de direcciones multicast IP sobre
Ethernet puede consultar
draft-ietf-mboned-intro-multicast-03.txt: «Introduction
to IP Multicast Routing».
Si está interesado en Multicast IP sobre redes de área local de Token-Ring mirar el RFC 1469 para más detalles.