2.4.

REENVIO DE CARGA MULTICAST Multicast en la subred local, no requiere un router de multidifusin o el uso de un algoritmo de encaminamiento de multidifusin: en una subred de media compartida un host de origen, que no necesariamente tiene que ser un miembro del grupo, slo transmite un paquete de datos de multidifusin, el paquete es recibido por cualquier miembro conectado al medio. Para multidifusiones que se extiende ms all de la subred local, la subred debe estar conectada a un enrutador de multidifusin, que a su vez se une a otros routers con capacidades multicast. Se requiere tres mecanismos: la capacidad de construir rboles de distribucin; la presencia de un protocolo de enrutamiento de multidifusin (por ejemplo,PIM), y la presencia de un protocolo de gestin de grupo en los bordes que habilita el router de las subredes multicast para vigilar la presencia de su pertenencia al grupo unidos directamente, de tal manera que si llegan datos de multidifusin, el router sabe sobre el cual de sus enlaces debe enviar una copia del paquete.

2.4.1. MULTICAST ENTRE SEGEMENTOS DE RED Los protocolos de enrutamiento de multidifusin se han desarrollado para transmitir paquetes a travs de una red enrutada y al mismo tiempo evitar los bucles de enrutamiento. Existen dos funciones para soportar la transmisin multicast a travs de una red enrutada: La determinacin de los participantes en multicast: Se refiere a una capacidad para determinar si un datagrama multicast necesita ser enviado en una red especfica.

La determinacin del mbito en multicast: El campo TTL (time to live) en un datagrama multicast se utiliza para determinar el alcance de una transmisin. El valor contenido en este campo se decrementa por cada router que recorre.

Cuando un router

de host o multicast recibe un datagrama, el

procesamiento de los datagramas depende tanto de la direccin IP de destino como el valor TTL: TTL=0, el datagrama se limita a la fuente de acogida. TTL=1, el datagrama llega a todos los usuarios / hosts de la subred que son miembros del grupo. TTl > 1, el datagrama llega a todos los usuarios / hosts de la subred que son miembros del grupo. La accin realizada por los routers depende de la direccin del grupo: Las direcciones dentro del bloque 224.0.0.0-224.0.0.255: Los routers multicast no reenvan datagramas con direcciones de destino en este rango ya que este conjunto de direcciones est diseado para aplicaciones de multidifusin de un solo salto. Sin embargo, incluso aunque el enrutador multidifusin no transmita estos datagramas, un host debe todava reportar pertenencia a un grupo dentro de este rango, el informe se utiliza para informar otros hosts de la subred que el host es un miembro del grupo. Las direcciones fuera del bloque 224.0.0.0-224.0.0.255: Estos datagramas son enviado por el router multidifusin pero el valor TTL se decrementa por 1 en cada salto. Este mecanismo permite a un host localizar el host ms cercano que multicast

buscan una determinada direccin de multicast. El host origen enva un datagrama con un valor TTL de 1 y espera una respuesta. Si no se recibe respuesta, el host de origen reenva el datagrama con un valor de TTL de 2. Si no se recibe respuesta, el anfitrin sigue incrementando el valor TTL hasta que el usuario ms cercano se encuentre. 2.4.2. RBOLES DE DISTRIBUCIN MULTICAST Los routers con capacidad de multidifusin crean rboles de distribucin lgicos que controlan el camino que el trfico de multidifusin IP lleva a travs de la red con el fin de entregar trfico a todos los receptores. Existen mecanismos para crear y para mantener los rboles de distribucin.

Diferentes algoritmos multicast (por ejemplo, PIM, CBT, DVMRP) utilizan diferentes tcnicas para establecer el rbol de la distribucin. Podemos clasificar los algoritmos en los algoritmos de rbol de fuentes basadas en algoritmos y compartida de rboles. Diferentes algoritmos tienen diferentes caractersticas de escala, y las caractersticas de los rboles resultantes difieren demasiado, por ejemplo, desde una perspectiva retardo de extremo a extremo. Los miembros de grupos de multidifusin pueden unirse o abandonar (dejoin) en cualquier punto en el tiempo, por lo tanto, los rboles de distribucin deben ser actualizados dinmicamente. Cuando todos los receptores activos en una parada rama particular, solicitar al trfico de un grupo multicast concreto, los routers con capacidades multicast podar la rama del rbol de la distribucin y detener el reenvo de trfico a lo largo de esa rama. Si el receptor de esa rama se activa y pide al trfico multicast , el router multidifusin modificar dinmicamente el rbol de la distribucin y comenzar de nuevo el trfico de reenvo [ CIS200701 ] . Tenga en cuenta que multicast IP no requiere remitentes sean miembros del grupo de ese grupo. Los dos tipos bsicos de rboles de distribucin multicast son rboles de cdigo fuente [ tambin conocidos como rboles de ms corta trayectoria ( SPT ) o rboles basados en fuentes ] y rboles compartidos (tambin conocidos como rboles sharebased ) . Los mensajes slo se replican en las ramas de los rboles . Ambos tubos sin soldadura y rboles comunes son la forma ms sencilla topologies.The libre de bucles de un rbol de distribucin multicast es el rbol tree.Asource fuente tiene su raz en la fuente multicast y tiene ramas que forman un rbol de expansin en la red para los receptores. El rbol hace uso de la ruta ms corta a travs de la red y por lo que un SPT separada puede existir para cada fuente individual enviando a cada grupo . La notacin de ( S , G ) se utiliza para describir un SPT , donde S es la direccin IP de la fuente y G es la direccin de grupo multicast . La Figura 3.2 muestra un ejemplo de un SPT para el grupo 239.1.1.1 arraigada en la fuente, el host A , y la conexin de tres receptores , los ejrcitos B , C, y D. Usando la notacin ( S , G ), el SPT

es ( 92.1.1.1 , 239.1.1.1 ) . SPT lograr , por definicin, la topologa de la ruta ptima entre la fuente y los receptores en trminos del nmero de saltos , lo que resulta en la cantidad mnima de latencia de la red de distribucin de trfico multicast . Sin embargo , se requiere que los routers multicast con capacidad para mantener la informacin de la ruta para cada fuente. En redes grandes , ya sea con muchas fuentes y / o muchos grupos , esta informacin de estado puede sobrecarga en los routers , en particular para los recursos de memoria necesarios para almacenar la tabla de encaminamiento de multidifusin . Tenga en cuenta que Deering.s algoritmos multicast [ RFC988 , RFC1054 , RFC1112 ] construir rboles de entrega de races de origen , con un rbol de entrega por remitente subred [ RFC2201 ] . La Figura 3.3 representa una simple IPTVexample ; en este ejemplo se emplea el SPT para distribuir eficientemente vdeo a los usuarios remotos . La figura 3.4 muestra la poda en tiempo real que se lleva a cabo . rboles compartidas usan una sola raz comn colocado en un punto seleccionado en la red. Esta raz compartida se denomina un punto de encuentro ( RP ) ( tambin llamado ncleo o centro ) . La Figura 3.5 muestra un rbol compartido para el grupo 239.1.1.1 junto con la raz comn. Al hacer uso de un rbol compartido , fuentes de enviar su trfico a la raz ( RP ) y luego el trfico se reenva a lo largo del rbol compartido para llegar a todos los receptores activos . En este ejemplo , el trfico de multidifusin a partir de fuentes 1 y 2 se desplaza a el router en la raz compartida y luego a lo largo del rbol compartido a los tres receptores , anfitriones B , C , y D. Todas las fuentes en el grupo de multidifusin usan el rbol comn compartido . La notacin ( * , G ) se utiliza para representar el rbol . En este caso , " * " es un comodn que significa todas las fuentes . El rbol compartido se muestra en la Figura 3.5 se escribe como (* , 239.1.1.1 ) . rboles compartidas requieren una cantidad mnima de informacin de estado en cada router, minimizando de este modo los requisitos de memoria para los routers y los mecanismos para mantener la informacin de estado hasta la fecha. Sin embargo , los caminos entre la

fuente y los receptores pueden no ser las rutas ptimas en trminos de lpulo y, en consecuencia , la latencia . Esta situacin requiere una evaluacin detallada de donde el RP debe estar ubicado en la red en la aplicacin de un diseo compartido -tree. rboles de multidifusin basado en la fuente se construyen mediante un algoritmo de vector de distancia basado , que puede implementarse por separado del algoritmo de enrutamiento unicast ( como es el caso con DVMRP ) ; alternativamente , el rbol de multidifusin tambin puede ser construido usando la informacin presente en la tabla de enrutamiento unicast subyacente ( por ejemplo , con PIM DM ) . El otro algoritmo utilizado para la construccin de rboles basadas en cdigo fuente es el algoritmo de estado de enlace ( un ejemplo es M- OSPF) . La mayora de los algoritmos de rbol de multidifusin basados en fuente se denominan tpicamente como algoritmos " de modo denso " . Estos algoritmos asumen que la poblacin receptor rellena densamente el dominio de la operacin , y por lo tanto la sobrecarga de acompaamiento en los algoritmos ( en trminos de costos para el estado , uso de ancho de banda , y / o de procesamiento ) es aceptable . Esto tiende a ser el caso en un entorno local y para una serie de aplicaciones de rea amplia , incluyendo IPTVand DVB - H . Para otras aplicaciones (por ejemplo , la red informtica , difusin de datos ) , pertenencia a un grupo tiende a ser distribuida escasamente en toda la red institucional, la red de transporte , o por Internet , con estas aplicaciones puede haber "bolsas" de densidad , sino tambin a nivel mundial , con los los grupos del rea tienden a ser escasamente distribuido [ RFC2201 ] . Una arquitectura de comparticin rbol ofrece una mejora en la escalabilidad sobre arquitecturas de fuente de rboles por un factor del nmero de fuentes activas . Fuente rboles escala S ( S G) , ya que un rbol de reparto distinto se construye por fuente activa. rboles compartidos eliminan la fuente S factor de escala ; todas las fuentes utilizan el mismo rbol compartido , por lo tanto , un rbol compartido escalas O (G ) . La implicacin de esto es que las aplicaciones con muchos emisores activos, tales como aplicaciones de simulacin

interactivos distribuidos y los juegos de video distribuida ( donde la mayora de los receptores son tambin emisores ), tienen mucho menos impacto sobre subyacentes de enrutamiento multicast si los rboles compartidos se utilizan [ RFC2201 ] . Observe que en la fuente de IPTV es tpicamente nico porque la fuente ( llaman un SuperSource ) en s agregados muchos canales de contenido ( de varios proveedores , por ejemplo , proveedores de 200 ) en un nico flujo de multidifusin IP con el fin de aplicar un esquema de codificacin coherente ( por ejemplo , convertir de MPEG - 2 y MPEG - 4 , convierte de analgico a digital MPEG - 4 , convertir de vdeo por componentes para vdeo MPEG-4 ) y para aplicar un acceso condicional constante ( gestin de derechos digitales ) disciplina. Para aplicaciones generales ( tal como, pero no limitado a la difusin de datos y de computacin grid ) , rboles compartidos incurren en ancho de banda significativa y ahorros para el estado en comparacin con rboles de cdigo fuente . La primera razn es que el rbol slo abarca a los grupos receptores ( incluidos los enlaces / routers guiando a los receptores ) , no hay ningn costo para routers / enlaces en otras partes de la red . La segunda razn de esto es que los routers entre un remitente que no es miembro y el rbol de entrega no son incurrir en ningn tipo de gastos relacionados con multidifusin , y, de hecho , estos routers no necesitan an ser capaces - paquetes de multidifusin de remitentes que no son miembros estn encapsulados y transmiten en un modo de unidifusin a un ncleo en el rbol [ RFC2201 ] . Algunos algoritmos multicast , especficamente el algoritmo CBT , hacer uso de un CBT . Un TCC es un "rbol compartido bidireccional " donde el estado de enrutamiento es " bidireccional ", es decir , los paquetes pueden fluir tanto hacia abajo el rbol de distancia desde el ncleo y el rbol hacia el ncleo , dependiendo de la ubicacin de la fuente en la red , y el rbol es " compartida " de todas las fuentes para el grupo. Figura 3.6 ilustra un CBT .

2.4.3. REVERSE PATH FORWARDING El algoritmo de propagacin de trayectoria inversa (Reverse Path Forwarding, RPF) le permite a los Routers que conforman los arboles de distribucin en la red, seleccionar la interface de entrada por donde llegar el trafico entrante, con el propsito de usar esta caracterstica como

condicin para replicar dicho trfico a las respectivas interfaces de salida (grupos Multicast) destino. Esto se lleva a cabo en el Router a travs de una tabla de enrutamiento en donde se estipula la interface de entrada, la direccin IP origen (fuente de trafico entrante), las interfaces de salida y sus correspondientes direcciones IP destino; en caso de que ocurra lo

contrario, (el mismo paquete intente entrar por otra interface no habilitada) este ser rechazado. El propsito fundamental de este algoritmo es evitar loops en la red, dado que en el instante en que este se presente, intentara enviar el mismo paquete(s) a travs de todos los dominios de Broadcast hasta llegar hasta el Router destino, lo cual implica tener el mismo paquete en varias interfaces de entrada del dispositivo.

Fig. 5 Modo de operacin del algoritmo RPF

2.4.4. ALGORITMO DEL ARBOL BASADO EN EL CENTRO Este algoritmo fundamenta su operacin en la asignacin de un Router principal denominado Core, el cual se encarga de construir un rbol con la ruta ms corta (Reverse Shortest Path, RSP) con el resto de Routers de la red, de tal forma que el Core se convierte en el punto central (RFC 2201, Core Based Trees (CBT) Multicast Routing Architecture, September 1997), cada vez que una fuente desea transmitir un paquete hacia cierto grupo Multicast, lo har a travs del Core. Cuando el paquete alcanza a este Router principal, este lo reenva usando RSP.

Fig. 6 Construccin de rboles

La construccin empieza cuando los Routers "locales" (R3, R5, R7 y R8 segn la figura 6) de cada grupo Multicast envan un mensaje "Join" al Core a travs de una interface etiquetada como RPF (Reverse Path

Forwarding, RPF) respecto al Core, en este instante puede ocurrir dos cosas:

Si este Router "local" no est asociado al Core, este lo vincula a su tabla de enrutamiento, asociando la interface del Router por donde llego el mensaje "Join", como una interface de entrada tipo RPF.

Si el Router ya forma parte del rbol compartido, el Core adhiere la interface por donde llego el mensaje a su lista de interfaces de salida sin replicar dicho mensaje.

Fig. 7 Transmisin de paquetes Multicast sobre un rbol basado en CBT

En la Fig. 7. se observa el proceso de transmisin de paquetes Multicast desde la fuente (H1) hasta los clientes (H2, H3, H4, H5): la fuente

establece el camino ms corto hasta el Core en forma Unicast (Unicast Shortest Path), en este caso H1R2R4, cuando el paquete alcanza al Core, este replica una copia del mismo, a todos los Routers de las ramas del rbol (R3, R5, R6 y R7). Las ramas de este tipo de rbol poseen

sentido bidireccional, lo cual se puede apreciar al intentar enviar un paquete desde H1 hasta H5, tomando como enrutamiento los Routers R1, R3 y R4: el camino a tomar seria R1R3R4R3R6R8H5. Esta caracterstica bidireccional hace que la seleccin del Router escogido como Core dentro de la red juegue un papel fundamental por parte del algoritmo CBT, ya que de acuerdo a la ubicacin de este Router las rutas desde la fuente hasta los Routers "locales" a travs del Core puede ser ms larga que la conexin directa entre los mimos. La ventaja principal de este algoritmo es que un nico rbol de distribucin es requerido para cada grupo Multicast, lo cual reduce la complejidad de las tablas de enrutamiento.

2.4.5. IMPLEMENTANDO IP MULTICAST EN UNA RED Las direcciones multicast tienen una estructura plana, no jerarquica adems solo pueden aparecer como direcciones de destino, nunca de origen. No pueden aparecer en los campos opcionales source route o record route Anlogamente a como ocurra con las direcciones MAC multicast las direcciones IP multicast no pueden aparecer en el campo direccin de origen de un datagrama. Tampoco pueden aparecer en los campos opcionales source route o record route. Los datagramas multicast no pueden dar lugar a mensajes ICMP del tipo Destination Unreachable. Por otro lado el campo TTL de los datagramas multicast se decrementa de la misma forma que el de los datagramas unicast y cuando vale cero el datagrama se destruye, pero no se envan mensajes ICMP Time Exceeded al emisor. Los mensajes ICMP ECHO REQUEST enviados a direcciones multicast producen mensajes unicast ICMP ECHO REPLY de todos los miembros del grupo; en la respuesta cada miembro pondr como direccin de origen la suya propia y como direccin de destino la del emisor del ICMP ECHO REQUEST; por tanto las respuestas a un ping multicats son mensajes unicast.