En la primera versión del modelo de PIM‐SM sobre INET se ha simulado este
protocolo con las características originales definidas en la RFC 4602. Dada la
complejidad de realización de una implementación completa y las limitaciones de
tiempo y ámbito de este proyecto se ha optado por una simulación simplificada. En
ésta se mantiene la estructura, tipos de paquetes y cabeceras, pero no se
implementan ni rellenan dichas cabeceras con información. No obstante los tamaños
de las cabeceras están implementados para ocupar el espacio asociado a cada
protocolo en cada nivel de la pila TCP/IP, por lo cual sí ocupan tiempo de proceso y conllevan retardos de transmisión. Esto hace que el modelo sea más realista.
El desarrollo de los modelos y modificaciones adopta un enfoque incremental, partiendo de la base para todos los modelos de PIM‐SM descrita en el apartado anterior y añadiendo o modificando aspectos de alto nivel, como tipos de mensajes y secuencia de interacción de los elementos (físicos y lógicos) del protocolo. En los
apartados de modificaciones se justifican éstas, pero se puede adelantar que en
ausencia de protocolos de soporte que provean y procesen información de rutas, el protocolo PIM‐SM no opera correctamente en el ámbito inter‐dominio.
Para aclarar y ver más fácilmente el proceso de interacción básico se incluye la figura 5.3‐5, que ilustra la estructura funcional general de intercambio de mensajes y los componentes físicos implicados en la operación del modelo de PIM‐SM original. La adaptación de este modelo general a las características estructurales integradas en la pila TCP/IP de INET permite su implementación en el simulador.
Fig. 5.3‐5 Diagrama de actividad de PIM‐SM original
El patrón de interacción presentado es el siguiente:
o La fuente multicast (video server) se registra en el punto de cita (RP) mediante un mensaje PIM‐Register, indicando su dirección y el grupo multicast al cual sirve (flecha verde).
o Los miembros en los diferentes dominios solicitan la unión a un grupo multicast mediante el envío de un mensaje IGMP‐Join (flechas azules) con dirección IP la del RP. Al llegar a router designado de cada subred, éste traduce el IGMP‐Join a un mensaje PIM‐Join que reenvía hacia el RP. En su avance hacia el RP el mensaje PIM‐Join construye a través del algoritmo Reverse Path Forwarding (RPF) las entradas en las interfaces de red de los routers que indican que se ha generado una rama del árbol multicast compartido para el grupo al que se está realizando la unión.
o Al recibir el mensaje PIM‐Join, el RP comprueba si hay alguna fuente registrada que sirva al grupo solicitado. De ser así el RP reenvía la petición de unión a una de las fuentes multicast (flecha azul punteada) que sirven al grupo (se selecciona una aleatoriamente) con dirección origen la suya propia (la del RP).
o Al recibir el mensaje de unión la fuente crea una entrada en sus tablas y comienza a reenviar el flujo multicast al RP en forma de flujo unicast encapsulado en mensajes de tipo PIM‐Register (flecha amarilla).
o Cuando el flujo encapsulado llega al RP éste elimina la encapsulación y reenvía el paquete en modo multicast a través del árbol compartido (flechas rojas). El flujo multicast se va replicando en las ramas de bifurcación del árbol y alcanza a todos los miembros unidos al grupo en cuestión.
Para no saturar textualmente la descripción que sigue se van a listar
únicamente los cambios de cada modificación respecto del modelo base de PIM‐SM
expuesto anteriormente, junto con diagramas de secuencia UML y diagramas de
actividad que muestran la interacción de los elementos.
En la figura 5.3‐6 se muestra el diagrama de secuencia UML que detalla el patrón de interacción que se acaba de describir, pero particularizado para la estructura de clases, módulos simples y objetos del modelo de PIM‐SM original en INET.
Fig. 5.3‐6 Diagrama de secuencia UML de PIM‐SM estándar en INET
En el diagrama se han representado los siguientes objetos. En púrpura la única instancia de la clase Envir, a través del objeto ev. Este objeto es el gestor de toda la simulación, coordinando las llamadas a los objetos del núcleo, los contextos de cada elemento y zonas de memoria reservadas, así como las operaciones de intercambio de mensajes, FES, etc., en INET.
En amarillo se tienen dos instancias de la clase Router.cc a través de dos objetos PIM_Router. En el modelo puede existir un número cualquiera de routers entre cada par de nodos extremo (elementos servidor y cliente de video streaming). El punto de cita se representa en color naranja con un objeto de la clase Rendezvous_Point.cc. Pueden existir hasta cuatro puntos de cita en todo el escenario, pero sólo uno por grupo multicast.
En color rosado y verde se tienen dos instancias de UDPVideoStreamCli.cc y
UDPVideoStreamSvr.cc respectivamente. Son los objetos correspondientes a los
elementos miembro y fuente multicast.
La única instancia de la clase GlobalStatsManager.cc está representada por el
objeto de color rojo. Representa el elemento global recolector de estadísticas que se ha descrito previamente.
La secuencia de interacción es la siguiente. Inicialmente el objeto ev inicializa todos los elementos del modelo, a través de la inicialización de sus objetos. En la cola de eventos futuros (FES) se programan los primeros mensajes, que mediante su flujo
desencadenarán acciones sucesivas, mensajes y continuidad de la simulación. Los
miembros multicast envían una petición PIM‐Join cada 5 segundos hacia el punto de cita que tienen configurado estáticamente. En su camino, el mensaje PIM‐Join crea anotaciones en las tablas de las interfaces de entrada de los routers PIM, para establecer un soft‐state que da lugar al árbol de encaminamiento multicast. Este estado expira con un temporizador en los routers PIM cada 3 segundos, por lo cual se refresca periódicamente y se mantienen activas las ramas o se autopodan las que carezcan de miembros. Por otro lado y previamente, la fuente multicast ha debido
registrarse en el punto o puntos de cita con mensajes PIM_Register nada más
comenzar la simulación. Para mantener el estado de actividad de la fuente, ésta reenvía periódicamente el PIM_Register cada 3 segundos.
Al llegar al punto de cita, el mensaje PIM_Join es procesado por éste. El punto de cita busca en sus bases de datos por fuentes que estén registradas y sirviendo al grupo que demanda el PIM_Join recibido. Si ya se está enviando el flujo para ese grupo hacia el árbol compartido, el mensaje se descarta. En caso contrario, se envía una petición tunelada con dicho mensaje hacia la fuente multicast. La fuente ante la recepción desencapsula la petición y crean un hilo que comenzará a servir un flujo de video multicast para el grupo en cuestión. El flujo multicast se envía en un túnel hacia el punto de cita dentro de mensajes PIM_Register. Al ser recibidos en el punto de cita, a los mensajes PIM_Register se les extraen los paquetes multicast del flujo de video, que son reenviados mediante multicast a través del árbol compartido y alcanzan a todos los miembros suscritos al grupo. El flujo multicast está formado por segmentos
UDP de tamaño determinado que se envían a razón de un paquete cada waitInterval segundos, ambos valores configurados como parámetros en el fichero de inicialización
omnetpp.ini
Paralelamente a sucesión eventos propios de PIM‐SM en la simulación, la
instancia de GlobalStatsManager va recopilando los valores de parámetros de QoS y las estadísticas que le van siendo enviadas por los miembros multicast y los puntos de cita y routers PIM, a intervalos de un segundo. La circulación de mensajes y recopilación de datos finaliza cuando el objeto ev ejecuta la llamada a la función miembro shutdown(), que graba los valores escalares de parámetros y estadísticas de elementos, cierra los vectores, destruye los objetos y finaliza la simulación.