Diseño del protocolo multicast.
(Sobre redes híbridas)
1. Introducción.
2. ¿Por que nos basamos en el CBT?
3. Especificaciones del protocolo.
4. IGMP -Internet Group Membership Protocol-.
5. Medidas en la ejecución de un protocolo multicast.
Para extender los protocolos multicast al caso de redes híbridas vamos a utilizar una versión modificada del CBT, al cuál nos referiremos como HCBT (Hybrid Core-Based Trees). La estructura del HCBT se basa en el escenario mostrado en la figura 1, donde tenemos:
Figura 1. Diagrama ilustrativo de la arquitectura HCBT
Vamos a considerar dos tipos de tráfico: todo el tráfico
por debajo de cierto umbral (T bits/seg) lo consideraremos tráfico
lento, mientras que el que supere ese umbral lo consideraremos tráfico
rápido. Todos lo HHs se unirán a un árbol multicast
a través de una pasarela híbrida multicast (MHGW). Necesariamente
todo el tráfico encaminado hacia y desde los HHs será encaminado
por el MHGW. Cuando enviamos paquetes a un grupo (multicasting) que posea
HHs, el MHGW observará el ancho de banda requerido y en función
de éste les enviará los datos vía terrestre o vía
satélite.
Debido a que los paquetes enviados por satélite son difundidos
de forma broadcast, éstos paquetes son disponibles para todos de
forma que algún mecanismo de autentificación se requiere
para permitir que reciban los paquetes sólo los HHs que pertenecen
al grupo. Cuando un HH se registra con el MHGW para formar parte de algún
grupo multicast, el MHGW le envia una llave especial que se usará
para recibir mensages. La otra alternativa es que el MHGW envíe
una copia unicast a cada miembro del grupo, lo cual desaprovecha claramente
el ancho de banda del enlace descendente del satelite.
Los HHs que están unidos a una LAN, tendrán que ejecutar
un proxy para permitirles actuar como un router multicast a efectos de
la LAN.
2. ¿Por que nos basamos en el CBT?
Si pensamos en un protocolo de encaminamiento para ser usado sobre redes híbridas, hay que observar con cuidado las características únicas que poseen este tipo de redes, y hacer uso de su naturaleza asimétrica. La mejor forma de empezar podría ser modificar un protocolo existente con el fin de acomodarlo a leste tipo de redes. El protocolo de encaminamiento multicast más utilizado es el DVMRP; pero la naturaleza asimétrica del tráfico en redes híbridas elimina prácticamente la posibilidad de utilizar un protocolo basado en la distancia de vectores. De los protocolos existentes el que mejor se adapta a las características que queremos es el CBT (Core-Based Trees; protocolo basado en árboles de distribución); veamos esas características del CBT que lo hacen deseable frente a otros protocolos:
Para la arquitectura del HCBT propuesta, todo el encaminamiento multicast
hacia y desde los terminales híbridos se hace a través del
MHGW. Los HHs deben de ejecutar una versión modificada del IGMP
para permitir al MHGW saber los miembros de cada grupo. Además,
aquellos HHs que actúen como routers dentro de su LAN, deberán
ejecutar un proxy para conocer la información de los miembros del
grupo de su LAN y pasarla al MHGW. Estos HHs especiales serán también
los responsables de que los paquetes multicast lleguen a los miembro de
su LAN. El MHGW debe de poder soportar el protocolo CBT para poder unir
al correspondiente árbol multicast a los HHs.
La elegancia de la arquitectura propuesta recae en su capacidad de
hacer un encaminamiento inteligente dependiendo del tipo de tráfico.
Para poder soportar esta característica deseable, el MHGW debe de
implementar un mecanismo que encamine los paquetes del tráfico rápido
a través del satélite y los paquetes del tráfico lento
a través de los enlaces de cable terrestres; esto será equivalente
a mantener dos árboles multicast de entrega separados.
Para establecer un mecanismo de entrega multicast fiable que garantice
"al menos una" entrega de los paquetes multicast, el MHGW debe mantener
una copia de todos los paquetes hasta que le llegue el reconocimiento de
todos los HHs. Esto se desvía de los esquemas típicos del
multicast sobre IP (IGMP), donde los routers multicast sólo guardan
información de la red ligada a los miembros del grupo y no de los
miembros del grupo individualmente.
El IGMP (Internet Group Membership Protocol) lo usan los routers para
aprender la información de los miembros de un grupo en su subred
local. Este protocolo no está enfocado hacia una red híbrida
(satélite-terrestre) porque algunas de las suposiciones hechas no
son validas para este escenario. Por ejemplo, el IGMP supone que todos
los hosts miembros de una subred local se pueden escuchar unos a otros;
pero en una red híbrida los HHs no tienen un enlace directo con
los demás ya que el enlace con el satélite es unidireccional.
Por tanto, habrá que modificar el IGMP para que pueda ser usado
en este contexto. Quitamos la opción de interrogación por
parte del IGMP y hacemos que todos los HHs manden una petición al
MHGW cuando quieran unirse o dejar un grupo. Para cubrir el caso de paquetes
perdidos, la petición se mandará por duplicado si la confirmación
(de la primera petición) no llega en un tiempo de espera especificado.
Este método puede causar problemas en la fase de inicialización
o en la fase de cierre de la sesión multicast (cuando todos los
HHs intenten unirse o dejar el grupo) porque el MHGW se verá inundado
de mensajes de grupo, así que esta técnica es aconsejable
sólo para grupos con un número pequeño de miembros
HHs.
Por otra parte, si no es necesaria la fiabilidad en la entrega de paquetes,
el MHGW puede reenviar las petición recibidas a través del
satélite y de esta forma algunos HHs se pueden ahorrar sus peticiones.
5. Medidas en la ejecución de un protocolo multicast.
Para evaluar la ejecución de un protocolo multicast se suelen
usar algunos indicadores para estimar lo bien que funciona el protocolo
sobre diferentes escenarios. Para un encaminamiento dinámico multicast,
es importante determinar la latencia introducida al unirse a un grupo multicast,
siendo deseable que esa latencia sea la mínima posible. Pero el
indicador más importante que se suele usar es el tiempo que le cuesta
a cada miembro del grupo recibir los paquetes enviados, es decir, el tiempo
de transferencia. Con el fin de controlar la pérdida de paquetes
se han hecho muchos estudios para determinar la correlación de los
paquetes perdidos dentro de una red multicast, y se observa que las perdidas
en la MBONE están temporalmente correlacionadas, es decir, la mayoría
de perdidas ocurren en los receptores y en los routers; y no en los enlaces.
La topología de la distribución multicast (en forma de árbol)
afecta también a la pérdida de paquetes y, consecuentemente,
al tiempo de transferncia.
La concentración del tráfico en los enlaces del árbol
de distribución también se usa como indicador. Debido al
gran retardo introducido por el enlace del satélite, el indicador
más importante es la demora de transferencia en la entrega de paquetes
multicast hasta todos los Hosts Híbridos.