Protocolo de reserva de recursosDe Wikipedia, la enciclopedia libre Saltar a navegacin, bsqueda RSVP redirige aqu. Para la frmula protocolaria y de etiqueta social, vase Rsvp. El protocolo de reserva de recursos (RSVP), descrito en RFC 2205, es unprotocolo de la capa de transporte diseado para reservar recursos de una red bajo la arquitectura de servicios integrados (IntServ). "RSVP no es una aplicacin de transporte, es ms bien unprotocolo de control de internet, como ICMP, IGMP, oprotocolos de enrutamiento" RFC 2205. RSVP reserva los canales o rutas en redes internet para la transmisin por unidifusin y multidifusin con escalabilidad y robustez. RSVP puede ser utilizado tanto por hosts como por routers para pedir o entregar niveles especficos de calidad de servicio (QoS) para los flujos de datos de las aplicaciones. RSVP define cmo deben hacer las reservas las aplicaciones y cmo liberar los recursos reservados una vez que han terminado. Lasoperaciones RSVP generalmente dan como resultado una reserva de recursos en cada nodo a lo largo de un camino. RSVP no es en s mismo unprotocolo de encaminamiento y fue diseado para interoperar con los actuales y futurosprotocolos de encaminamiento. RSVP por s mismo rara vez es desplegado en redes de telecomunicaciones hoy en da pero para RSVP-TE, est comenzando a aceptarse de forma ms comn en muchas redes con QoS.

MensajesHay dos tipos principales de mensajes:

Ruta de los mensajes (ruta) La ruta de los mensajes es enviada por el remitente de acogida a lo largo de la ruta de datos y almacena la ruta estatal en cada nodo a lo largo de la ruta. La ruta estatal incluye la direccin IP del nodo anterior, y algunos objetos de datos: 1. Plantilla remitente para describir el formato de los datos de remitente. 2. Tspec remitente para describir las caractersticas de trfico del flujo de datos. 3. Adspec que lleva la publicidad de datos (vase el RFC 2210 para ms detalles).

Reserva de mensajes (resv) La reserva de mensajes se enva desde el receptor al remitente de acogida a lo largo de la ruta inversa de datos. La reserva de mensajes incluye el flowspec objeto de datos que identifica los recursos del flujo de necesidades.

Los datos sobre los mensajes RSVP se pueden transmitir en cualquier orden. Para la lista completa de los mensajes RSVP y fecha objetos consulte RFC 2205.

[editar] OperacionesEs necesario que una acogida envie un flujo de datos especficos con QoS transmitir a RSVP una va mensaje que viajar a lo largo de las rutas de unidifusin y multidifusin previamente establecido por elprotocolo de enrutamiento de trabajo. Si la ruta mensaje llega a un router que no entiende RSVP, el router enva el mensaje sin interpretar el contenido del mensaje y la no reserva de los recursos para la corriente. Cuando el destino router recibe el camino mensaje:1. Hacer una reserva sobre la base de parmetros de la peticin. Para este control de la admisin y las polticas de control de parmetros de proceso de la solicitud puede encargar el clasificador de paquetes para manejar correctamente el subconjunto seleccionado de paquetes de datos o de negociar con la capa superior de la forma en que el paquete de manejo se debe realizar. 2. Adelante la solicitud aguas arriba (en la direccin del remitente). En cada nodo de la resv mensaje, flowspec puede ser modificado por un nodo de transmisin.

Cada nodo en el camino puede aceptar o rechazar la peticin.

Modo de operacin de RSVP

Protocolo de la gerencia del grupo del Internet (IGMP) es a protocolo de comunicaciones manejaban la calidad de miembro de Internet Protocol multicastgrupos.IGMP se utiliza cerca IP anfitriones y adyacente multicast rebajadoras para establecer calidades de miembro de grupo del multicast.

Es una parte integral de Multicast del IP especificacin, funcionando sobre capa de red, aunque no acta realmente como a protocolo del transporte[1]. Es anlogo a ICMP para unicastconexiones.IGMP se puede utilizar para en lnea vdeo que fluyey el juego, y permite un uso ms eficiente de recursos al apoyar estos tipos de usos.IGMP permite algunos ataques[2][3] [4] [5]

, y los cortafuegos permiten

comnmente que el usuario lo inhabilite si no necesitaron.

2.7 IGMP("Internet Group Management Protocol")IGMP es un protocolo estndar con un nmero STD de 5 que incluye adems a IP(ver IP("Internet Protocol")) e ICMP (ver ICMP("Internet Control Message Protocol")). Su status es recomendado y el RFC 1112 lo describe. Note: IP e ICMP son requeridos. IGMPse considera ms bien como una extensin de ICMP y ocupa el mismo lugar en la pila de protocolos IP. (3) Ver Multicasting para una introduccin al multicasting.2.7.1 Mensajes IGMP

Los mensajes ICMP se envan en datagramas IP. La cabecera IP siempre tendr un nmero de protocolo igual a 2, indicando IGMP y un tipo de servicio cero(rutina). El campo de datos IP contendr el mensaje IGMP de ocho bytes mostrado en Figura - Formato del mensaje ICMP.

Figura: Formato del mensaje ICMP Donde:Vers 4 bits que indican la versin IP. Siempre vale 1. Type Especifica que se trata de una consulta o de un informe. 1 Especifica una consulta enviada por un "router" multicast. 2 Especifica un informe enviado por un host. Checksum

Un checksum de 16 bits calculado de igual forma que con ICMP. Class D Address Es cero para una solicitud, y es una direccin de grupo multicast vlida para un informe. 2.7.2 Funcionamiento de IGMP

Los sistemas que participan en IGMP se clasifican en dos tipos: host y "routers" multicast. Como se describi en Multicasting, con el fin de recibir datagramas de multicast, un host se debe unir a un grupo. Cuando un host es "multi-homed"(multipuerto), puede unirse a cualquier grupo por una o ms de sus interfaces(redes a las que est conectado). Los mensajes multicast que recibe el host del mismo grupo en dos subredes distintas pueden ser distintos tambin. Por ejemplo, 244.0.0.1 es el grupo para "todos los host de esta subred", por lo que los mensajes recibidos en una subred siempre sern diferentes para este grupo que para los de otra subred. Puede haber mltiples procesos en un host a la escucha de mensajes para un grupo de multicast. Si es este el caso, los host se unen slo una vez al grupo, y llevan la cuenta internamente de qu procesos estn interesados en ese grupo. Para unirse a un grupo, el host enva un informe acerca de una interfaz. El informe se dirige al grupo multicast interesado. Los "routers" multicast de la misma red reciben el informe y activan un flag para indicar que al menos un host de esa red es miembro de ese grupo. Todo host pertenece al grupo 224.0.0.1 de forma automtica. Los "routers" multicast tienen que escuchar a todas las direcciones de multicast(todos los grupos) con el fin de detectar tales informes. Las alternativas seran el uso del broadcast para los informes o para configurar host con direcciones unicast para "routers" multicast. Los "routers" multicast envan regularmente(el RFC 1112 menciona intervalos de 1 minuto) una consulta a la direccin de multicast "todos los hosts". Cada host que an desee ser miembro de uno o ms grupo replica una vez por cada grupo en el que est interesado(nunca al grupo "todos los hosts", al que pertenece de modo automtico). Cada respuesta se enva tras un intervalo de tiempo aleatorio para evitar aglomeraciones en el trfico. Como a los "routers" no les importa cuntos hosts son miembro de un grupo y como todos los miembros de ese grupo pueden or las respuestas de cada uno de los dems hosts, cualquier host que escuche a otro host proclamar su pertenencia a mismo grupo cancelar su respuesta para ahorrar recursos. Si ningn host responde dentro de un intervalo de tiempo dado, el "router" multicast decide que ningn host pertenece a ese grupo. Cuando un host o un "router" multicast recibe un datagrama multicast, su accin depende del valor TTL y de la direccin IP de destino.0 Un datagrama enviado con un valor TTL de cero se restringe el host emisor.

1 Un datagrama con un TTL de uno alcanza todos los hosts de la subred que son miembros del grupo. Los "router" multicast decrementan el valor a cero, pero a diferencia de los datagramas unicast, no lo informan con un mensaje ICMP "Time Exceeded". La expiracin de un datagrama multicast se considera un evento normal. 2+ Todos los hosts que sean miembros del grupo y todos los "routers" multicast reciben el datagrama. La accin de los "router" depende de la direccin del grupo multicast. 224.0.0.0 - 224.0.0.255 Este rango se emplea slo para aplicaciones multicast que hagan uso de un nico salto. Los "routers" multicast no retransmitirn datagramas con direcciones IP en este rango. A primera vista puede parecer como si un no tuviera que molestarse en informar de la pertenencia a un grupo en este rango ya que los "router" no le retransmitirn los de otras subredes. Sin embargo, el informe indica adems a otros host de la subred que el host informante es miembro del grupo. El nico grupo del que nunca se da parte es el 224.0.0.1. other El "router" retransmite normalmente los datagramas con otros valores para la direccin de destino: el valor TTL se decrementa en al menos un segundo, como es habitual. Esto permite a un host localizar al servidor ms cercano que est escuchando sobre un direccin multicast usando lo que se llama "expanding ring search"(bsqueda expansiva en anillo). El host enva un datagrama con un valor TTL de 1(misma subred) y espera una respuesta. Si no se recibe ninguno, prueba con un TTL de 2, luego de 3, etc. Al final encontrar al servidor ms cercano. (4)

1.- IntroduccinMBone (Multicast Backbone On Internet) existe desde 1992 como una red virtual para la experimentacin del uso del IP Multicast en Internet. Esta red se ha empleado mayoritariamente para el estudio de herramientas de audio/vdeo conferencias multipunto, aunque en principio puede ser empleada para el intercambio de cualquier tipo de informacin multimedia. Su principal ventaja, o debiramos decir caracterstica, es la de proporcionar el intercambio de informacin de uno a muchos, pero sin los inconvenientes de tener que duplicar dicha informacin para cada uno de los receptores y en funcin del nmero de ellos.

Si esta red virtual se implant inicialmente hace bastantes aos, Por qu no ha abandonado an su calidad de experimental y se ha convertido en un servicio operativo? Pues principalmente por ser una `red virtual'; una red creada como la unin de mltiples `islas' interconectadas entre s. Esto es as debido bien a que la mayor parte de equipos de comunicaciones que interconectan la infinidad de redes que forman Internet aun no hablan el lenguaje del MBone, es decir, el IP Multicast, o lo hacen de forma incompatible con otros. Pese a que el panorama est cambiando muy rpidamente y que un gran nmero de ingenieros, tanto de empresas privadas como pertenecientes al mbito acadmico y/o investigador, se estn esforzando conjuntamente para convertir este experimento global en un servicio operativo, an existen ciertas complicaciones que apuntan a que MBone seguir siendo por el momento una red experimental en la Internet. Esto, evidentemente, no quiere decir que los conceptos de MBone no puedan ser empleados con xito y de manera totalmente funcional dentro de redes corporativas o incluso entre distintas intranets, sino que el objetivo final, el hacer de las comunicaciones multicast algo inherente a Internet, es algo que an est lejano. Ms adelante volveremos sobre este tema, pero antes debemos presentar ciertos conceptos que forman la base tecnolgica de MBone.

2.- Qu es y cmo funciona el IP Multicast?Internet es una red en la que el intercambio de informacin entre equipos locales o remotos se hace a travs de datagramas IP Internet Protocol). Un datagrama IP (o paquete IP) podramos decir que es la unidad mnima de informacin en el lenguaje que hablan todos los equipos que forman parte de Internet. Estos datagramas IP estn formados principalmente por una direccin origen y una direccin destino, y cada equipo de comunicaciones situado en la ruta entre ambos se encarga de enviar dicho datagrama por el camino adecuado. Esto implica que cada estacin conectada a Internet debe tener una direccin que la identifique, lo que se llama direccin IP, y constituye un sello de identidad global y nico para cada equipo en Internet. Pueden clasificarse en tres tipos en funcin de la direccin de destino:

IP unicast: La direccin corresponde a un solo receptor y ser ste el nico que procese los datagramas IP con ese destino (conexin uno-a-uno). IP broadcast: La direccin corresponde a todos los equipos conectados en un mismo tramo de red local y el datagrama IP es procesado por todos ellos (conexin uno-a-todos dentro de la misma subred). IP multicast: La direccin corresponde a un grupo de equipos, y slo estos procesarn los datagramas IP con ese destino (conexin uno-a-muchos, o uno-a-varios).

Cuando un equipo enva un datagrama IP a una determinada direccin IP multicast, slo es recibida por aquellos equipos que estn a la escucha de esa direccin y, que por tanto, son capaces de entender las direcciones multicast. El concepto de direcciones multicast fue una idea original de Steve Deering que describi en su tesis doctoral en la Universidad de Stanford, y que ms tarde continu desarrollando en el Centro de Investigacin de Xerox en Palo Alto (Xerox PARC). Van Jacobson, de los laboratorios Lawrence Berkeley (LBL), Steve Casner, del ISI (Information Science Institute) as como varios ingenieros ms, se interesaron por continuar el estudio iniciado por Steve Deering y su implantacin experimental en Internet. Resultado de estas investigaciones fue la publicacin del RFC 1112, en el que se definen los requisitos necesarios que debe cumplir un equipo para poder `hablar' IP multicast. En 1992, durante una de las reuniones peridicas de coordinacin del grupo de trabajo de redes (Network Working Group) del IETF (Internet Engineering Task Force), se adopt la implantacin experimental del IP multicast en Internet, reservndose un rango de direcciones IP para el mismo (clase D de direcciones). Este fue el nacimiento del MBone. En los comienzos del MBone, pocos ordenadores eran capaces de entender dichas direcciones multicast. La mayor parte de estos equipos han sido aquellos basados en el sistema operativo UNIX (en

cualquiera de sus variantes) dada la gran flexibilidad del mismo para realizar modificaciones a bajo nivel, al ser este un sistema operativo compilado del que se puede disponer de los cdigos fuentes con cierta facilidad, o al menos las partes necesarias para acceder directamente a los dispositivos de comunicaciones. En la actualidad, estos requisitos estn implementados (o al menos estn disponibles las herramientas para activarlos) en la gran mayora de sistemas operativos que incluyen soporte de comunicaciones para redes TCP/IP: Windows95, WindowsNT, UNIX (todas sus variantes), MacOS, etc. Es muy probable que, en un futuro no muy lejano, la posibilidad multicast sea un requerimiento bsico de cualquier equipo conectado a Internet. Volviendo al tema de cmo funciona el IP multicast, decamos que cuando un ordenador enva un datagrama IP multicast, este slo lo recibe un grupo determinado de equipos, mientras que el resto sencillamente lo ignoran. Para ello es necesario que el ordenador permita, a las aplicaciones que hacen uso del multicast, configurar el dispositivo de red para recibir, no slo los datagramas que van destinados a su direccin IP, como es habitual, sino tambin aquellos que van destinados a una determinada direccin multicast. Del mismo modo, se debe poder indicar al dispositivo de red, que deje de recibir los datagramas de una determina direccin multicast. Estas acciones de unirse (join) o abandonar (leave) una determinada direccin multicast, tambin son significativas para los dispositivos que encaminan los datagramas multicast entre varias subredes (mrouters) y son realizadas por medio de un protocolo sencillo llamado IGMP (Internet Group Management Protocol), del que hablaremos ms adelante. Las direcciones IP multicast se suelen denominar `grupo multicast', ya que no estn asignadas a un equipo concreto de forma permanente, sino a un grupo determinado y de forma temporal. Por otro lado, no es necesario que un equipo pertenezca a un grupo concreto multicast para enviar datagramas al mismo. Las direcciones IP multicast, que todo equipo conectado a MBone debe saber reconocer (adems de ser capaces de hablar IGMP, que describiremos ms adelante, y de poder enviar y recibir datagramas UDP a una direccin multicast), forman una clase de direccionamiento llamada clase D, que se caracteriza porque todas estas direcciones comienzan con el prefijo binario 1110. La siguiente tabla muestra las diferentes clases de direcciones IP en Internet tanto en binario como en la clsica notacin decimal de cuatro octetos decimales separados por puntos

Tipo Direccin en binario Rango en decimal ---------------------------------------------------------------------------------Clase A 0bbbbbbb bbbbbbbb bbbbbbbb 0.0.0.0 a 127.255.255.255 Clase B 10bbbbbb bbbbbbbb bbbbbbbb 128.0.0.0 a 191.255.255.255 Clase C 110bbbbb bbbbbbbb bbbbbbbb 192.0.0.0 a 223.255.255.255 Clase D 1110bbbb bbbbbbbb bbbbbbbb 224.0.0.0 a 239.255.255.255 Clase E 11110bbb bbbbbbbb bbbbbbbb 240.0.0. a 247.255.255.255De todas las direcciones IP multicast posibles, algunas estn reservadas para uso interno por equipos de comunicaciones que intercambian informacin sobre multicast (u otros usos), otras para uso local dentro de Intranets, otras para controlar el alcance de distribucin de multicast en base a criterios administrativos, y las comprendidas en el rango: 224.2.0.0.0 - 224.2.255.255 son las que forman el conjunto de direcciones IP multicast usadas en el MBone para las conferencias globales multimedia. Dentro de este rango hay ciertas direcciones reservadas para los anuncios de sesiones multimedia (de las que hablaremos cuando expliquemos el funcionamiento del SDR o directorio de sesiones MBone).

Una lista completa de las asignaciones de direcciones multicast se puede encontrar en el RFC 1700 sobre asignacin de nmeros en Internet publicado por la IANA (Internet Asigned Numbers Authority), o sus sucesores. Tambin se puede consultar en la siguiente direccin: http://www.iana.org/iana/assignments.html Los datagramas multicast son enviados hacia los miembros del grupo destino usando la misma fiabilidad `best effort' que los datagramas IP unicast. Esto quiere decir que no existe garanta de que los datagramas lleguen a su destino, ni de que lo hagan de forma ordenada. El protocolo de transporte empleado es el UDP (User Datagram Protocol) que ofrece la ventaja de que al ser un protocolo ligero, los datagramas sufren menos retrasos en alcanzar su destino. Sin embargo la demanda de aplicaciones en tiempo real, como son las conferencias de audio y vdeo, si bien son tolerantes a perdidas de paquetes, no lo son en cuanto a que estos lleguen de forma desordenada. Ms adelante veremos como se ha resuelto este problema en MBone. Hasta ahora nos hemos podido hacer una idea de cmo funciona el IP multicast dentro de un segmento de red local, pero Cmo se propaga esta informacin a travs de distintos tramos de red? o ampliando el concepto Cmo se aplica esto a la Internet dando forma a lo que se llama MBone?. Pues bien, esto se realiza a travs de los encaminadores (routers) que interconectan tanto mltiples segmentos de red, como las mltiples redes que forman la Internet. Cuando un router esta cualificado para intercambiar datagramas IP multicast con otro u otros, decimos que es un router multicast, o abreviadamente un mrouter. Un mrouter debe cumplir dos requisitos bsicos:

Debe tener un mecanismo para conocer en todo momento los equipos que pertenecen a un determinado grupo multicast en cada una de las redes que interconecta. Para cada pareja {direccin IP origen (o fuente), grupo multicast} debe saber cmo encaminar los datagramas, originados en esa direccin IP, a los segmentos de red donde haya otros miembros de ese grupo multicast.

Lo primero se consigue con un determinado dilogo entre mrouters y ordenadores segn un determinado lenguaje, o tcnicamente, un protocolo de comunicaciones. Este protocolo es el IGMP (Internet Group Management Protocol), que debe implementar cualquier equipo que `hable' multicast (ordenadores y mrouters). Lo segundo se refiere a los criterios de encaminamiento multicast (multicast routing protocol) de los que debe disponer el mrouter, y que presentaremos en la siguiente seccin. La primera implementacin del IGMP fue publicada por Steve Deering en el RFC 1112 que hemos mencionado antes, a mediados de 1989. Este fue remplazado, en noviembre de 1997, por el RFC 2236 que define la versin 2 del protocolo (IGMPv2), y en la actualidad el grupo de trabajo idmr (InterDomain Multicast Routing) del IETF est trabajando en una nueva versin del mismo (versin 3). Del mismo modo que el ICMP (Internet Control Message Protocol )(RFC 792), el IGMP (Internet Group Membership Protocol) es una parte integral del IP. Los mensajes IGMP son transmitidos en datagramas IP y tienen un tamao fijo de 8 bytes. La siguiente figura muestra el formato de los mensajes IGMP.

El campo Tipoespecifica los diferentes mensajes IGMP posibles. El campo MRT(Maximun Response Time) ha sido introducido en el IGMPv2 e indica el tiempo mximo de respuesta permitido a ciertos mensajes. El checksumes un valor calculado en funcin de los valores de el mensaje IGMP en su conjunto y se emplea para comprobar que no se hayan producido errores en la transmisin del mismo. El ltimo campo es la direccin del grupo multicast. Los tipos de mensajes IGMP que utilizan ordenadores y mrouters para mantener informados a estos ltimos de la permanencia de los primeros dentro de cada grupo multicast, son los siguientes:

Valor (hex.) Tipo de mensaje Especfico de... ------------------------------------------------------------------ 0x11 Consulta de filiacin (Membership Query) IGMPv1,v2 y v3 0x12 Informe de filiacin (Membership Report) IGMPv1 0x16 Informe de filiacin (Membership Report) IGMPv2 0x17 Abandono de grupo (Leave group) IGMPv2 0x22 Informe de filiacin (Membership Report) IGMPv3El primero de ellos lo emplean los mrouters para consultar la filiacin a cualquier grupo multicast, y lo envan peridicamente por a un determinado grupo multicast: el 224.0.0.1. En caso de que existan varios mrouters dentro de una determinada subred, ser slo uno de ellos el encargado de enviar los mensajes IGMP de consulta de filiacin (querier mrouter),este ser el que tenga una direccin IP menor. La direccin multicast 224.0.0.1 es una direccin reservada (asignada por la IANA), que se refiere a todos los equipos multicast dentro de una misma subred, a la que pertenecen por defecto todos los equipos que `hablan' multicast. El resto de los mensajes son enviados por los ordenadores con destino a cada grupo multicast al que pertenecen, para informar de su filiacin a ese determinado grupo. Para evitar una avalancha de respuestas por parte de los ordenadores miembros de cada grupo, se utiliza una tcnica que consiste en emplear una serie de temporizadores, inicializados a un valor aleatorio, que cada ordenador mantiene para cada uno de los grupos multicast a los que pertenece. Slo se responder a las consultas de filiacin enviadas por los mrouters cuando dichos temporizadores se anulen, y en caso de que otro ordenador responda antes, el resto de los que pertenecen a dicho grupo volvern a inicializar sus temporizadores a unos valores aleatorios. De esta forma se consigue, sin colapsar la subred, que el mrouter conozca si existen miembros activos en la misma. En caso de que el ordenador no pertenezca a ningn grupo multicast, sencillamente ignora todos los mensajes IGMP. Para eludir prolongados tiempos de espera entre la emisin de las consultas de filiacin por parte de los mrouters y su correspondientes respuestas por parte del resto de los equipos, en la versin 2 del IGMP se introdujo en los mensajes el valor MRT, o tiempo de respuesta mximo para cada consulta. Esto evita, por otro lado, que se prolongue el tiempo que continan envindose datagramas multicast a un segmento de red en el que no permanecen receptores activos. En la versin 3 de este protocolo, que actualmente est en fase de estudio por parte del grupo de trabajo idmr del IETF, se aade la funcionalidad de filtrado por origen, es decir, se permite la opcin de que los equipos multicast puedan expresar su inters en recibir datagramas multicast que provienen slo desde determinadas direcciones IP, o de cualquiera excepto de un nmero limitado de ellas. Hay que remarcar que los mensajes IGMP se envan dentro de los datagramas IP con un valor de TTL (Time To Live) igual a 1, para evitar que sean propagados por otros routers tradicionales (routers unicast) ms all de la subred en la que se emiten, dado que por su definicin, su utilidad es mantener informados a los mrouters de los miembros activos dentro de una subred. Los detalles de cmo se comportan ordenadores y mrouters en el dilogo IGMP estn especificados en las referencias [6] y [7] de las notas bibliogrficas de este documento.

3.- Cmo se encaminan los datagramas multicast?Las ventajas de la idea del IP multicast se hacen patentes cuando podemos extender el esquema de funcionamiento entre varias subredes, es decir, cuando los miembros de un determinado grupo multicast estn distribuidos en varios segmentos de red distintos, interconectados a travs de mrouters. Para que el concepto multicast funcione, no basta con que los routers multicast conozcan, por medio del IGMP (como se ha explicado antes), qu equipos pertenecen a un determinado grupo multicast en los segmentos de red que este conecta, sino que deben saber tomar las decisiones necesarias para encaminar los datagramas multicast entre dichas subredes, asegurando que los enviados por un determinado equipo lleguen a todos los miembros de cada grupo multicast, y procurar, por otro lado, que no se produzcan bucles, esto es, que cada datagrama llegue a sus destinatarios slo una vez (y, preferiblemente, por el camino ms corto). Es decir, debe existir una determinada poltica de encaminamiento multicast, o dicho de otra forma, estos routers deben implementar un protocolo de encaminamiento (routing) multicast. Un protocolo de encaminamiento multicast es el que se encarga de la construccin de los rboles de distribucin (delivery trees) y habilitar la remisin (forwarding) de datagramas multicast. La caracterstica diferencial entre el encaminamiento unicast y el multicast, es que los datagramas multicast deben ser remitidos acull de su origen. Si un datagrama IP multicast es remitido hacia su origen, se podra producir un bucle de remisin, que podra dar lugar a una `avalancha' multicast. Todos los protocolos de encaminamiento multicast hacen uso del protocolo IGMP para conocer la filiacin de los equipos finales a cada determinado grupo multicast, pero difieren en la forma de intercambiar dicha informacin entre mrouters vecinos, as como en las tcnicas empleadas en la construccin de los rboles de distribucin. En cuanto a los tipos de protocolos de encaminamiento podemos distinguir, del mismo modo que para el encaminamiento unicast, dos grandes familias:

Protocolos de vector distancia:Basados en el algoritmo de "camino ms corto" del BellmanFord, en el que cada nodo distribuye todo el mapa de encaminamiento a sus vecinos de forma peridica, de tal forma que cada nodo se va haciendo una imagen de la red en su conjunto. Cada nodo asigna un "peso" o mtrica a cada ruta en funcin de los saltos necesarios para alcanzar a otro nodo. Su principal ventaja es su sencillez de operacin y por ende, de implementacin. Mientras que su mayor desventaja es su problema de escalabilidad. A medida que la red se hace mayor y ms compleja, el algoritmo se vuelve menos eficiente y se produce un mayor consumo de ancho de banda en los enlaces por la diseminacin de las tablas de encaminamiento. Por otro lado tambin es posible la formacin de bucles de encaminamiento (aunque existen implementaciones de este tipo de protocolo que evitan, en gran medida, este inconveniente). Protocolos de estado del enlace: Se basan en el concepto de un "mapa distribuido", es decir, que todos los nodos tienen una copia del mapa de la red, que se actualiza peridicamente. Se han desarrollado a partir de un algoritmo ms eficiente que el de Bellman-Ford, propuesto por E.W. Dijkstra, llamado "el camino ms corto primero" (shortest path first). Sin entrar en ms detalles comentaremos que algunas de sus principales ventajas son: la rpida convergencia a la descripcin real del estado de la red, la ausencia de creacin de bucles, el soporte de mtricas (costes asociados a un determinado enlace) mltiples, soporte de mltiples rutas a un mismo destino, etc.. Como contrapartida requieren mayor poder de procesamiento en los routers y son complejos de implementar y/o configurar.

En cuanto a los algoritmos empleados por los protocolos de encaminamiento multicast, su descripcin es compleja y est fuera del propsito de este artculo el proporcionar una explicacin de los mismos. Se puede hallar esta informacin en las referencias [2] y [8]de la bibliografa. Tan slo indicaremos que se podran dividir en dos grandes categoras:

Basados en tcnicas simples

Inundacin (flooding). MAC-layer Spanning Trees. Basados en tcnicas de rboles centrados en la fuente (Source-based trees) Reverse Path Broadcasting (RPB). Truncated Reverse Path Broadcasting (TRPB). Reverse Path Multicasting (RPM).

Hay que resaltar que los protocolos de encaminamiento multicast son, por lo general, bastante ms complejos que sus homlogos en unicast, y por otro lado su desarrollo ha sido ms tardo, por lo que an presentan mayores deficiencias, sobre todo cuando se aplican a redes complejas y no digamos a toda la Internet. Sin embargo su evolucin ha sido ms rpida, debido en gran medida, al gran inters que ha despertado, en funcin de sus enormes posibilidades de aplicacin, tanto en redes acadmicas como entre las grandes y pequeas empresas relacionadas con el sector de las telecomunicaciones. Tambin, por qu no, por la presin de usuarios finales y empresas que hacen uso de Internet en demanda de un medio multicast que permita ampliar sus horizontes de oferta de servicios multimedia de forma eficaz y econmica. Uno de los primeros protocolos de encaminamiento multicast fue el DVMRP (Distance Vector Multicast Routing Protocol), desarrollado por Steve Deering en la Universidad de Stanford en 1988, y que se encuentra definido en el RFC 1075. El DVMRP es un protocolo del tipo `vector distancia' que usa la tcnica `Reverse Path Multicasting' (este es un refinamiento de la tcnica `Reverse Path Forwarding' empleada originalmente en este protocolo), para construir rboles de encaminamiento multicast basados en la fuente (Source-based multicast delivery trees). De acuerdo con esta tcnica, el primer datagrama recibido para cualquier pareja {origen,grupo multicast} es remitido a todas las interfaces de red del mrouter, excepto a aquella por la que ha sido recibido, siempre que sea esta interfaz la usada por el protocolo de encaminamiento unicast para enviar datagramas a dicho origen, o en caso contrario ser descartado el datagrama. Tras recibir estos datagramas, los mrouters de los extremos del rbol de distribucin, o mrouters hojas (leaf nodes), podran transmitir mensajes de `podado' (pruning) hacia el origen de los mismos, en el caso de que no existiesen equipos finales conectados a dicho grupo multicast en la sub-red. Por otro lado, se implementa el mecanismo de `injerto' (graft) que es remitido por cada mrouter a sus vecinos ascendentes, en caso de que existan equipos que se hayan unido a un grupo multicast en una rama del rbol de distribucin previamente `podada'. El DVMRP construye su propia tabla de encaminamiento unicast de una forma similar al RIP (Routing Information Protocol), que es un protocolo unicast, tambin del tipo vector distancia. Con esta tabla de encaminamiento guarda la informacin de la interfaz que conduce a la fuente de un determinado datagrama multicast. Para poder extender el mbito de distribucin del multicast a travs de encaminadores que no son capaces de entender este tipo de trfico, se desarroll el concepto de tneles. De esta forma se pueden interconectar entre s las distintas sub-redes o `islas' multicast a travs de medios fsicos de transporte convencional unicast. Cada tnel tiene asociado un umbral (threshold) que permite limitar el mbito de distribucin de los datagramas multicast en funcin del campo TTL asociado a los mismos. Cada datagrama multicast recibido por un mrouter decrementa el valor del TTL del mismo y posteriormente lo compara con los umbrales definidos en sus tneles. Si el TTL resultante es mayor que dicho umbral, el datagrama ser distribuido a travs de dicho tnel y en caso contrario ser descartado. Este mtodo de limitacin del mbito de distribucin de los datagramas multicast tiene sus limitaciones. Por ejemplo, aparecen conflictos cuando se trata de aplicar lmites simultneamente en base a criterios topolgicos, geogrficos y de ancho de banda. En particular, este esquema no es vlido cuando se trata de aplicar a regiones que se solapan. Con la intencin de resolver estos problemas se desarroll un mtodo de limitacin del alcance en base a criterios administrativos (Administratively Scoped IP Multicast), ya sea localmente, a un determinado centro u organizacin, o a un conjunto de ellas. Para ello ha sido reservado por la IANA un determinado rango de direcciones multicast (239.0.0.0 a 239.255.255.255).

Estas extensiones an estn en proceso de desarrollo dentro del grupo de trabajo mboned del IETF (en el momento de escribir este artculo el ltimo borrador databa de noviembre de 1997). La primera implementacin de este protocolo fue desarrollada por el grupo de Van Jacobson del LBL (Lawrence Berkeley Laboratoy, USA) en 1992, como una aplicacin diseada para funcionar en mquinas UNIX (mrouted). Esta primera implementacin del protocolo DVMRP slo comprobaba la filiacin de miembros a un determinado grupo multicast en los extremos de la red. Como consecuencia de ello, los datagramas multicast eran distribuidos por toda la red. En 1993 sali a la luz una nueva versin del mrouted que implementaba correctamente los mecanismos de podado de ramas (pruning). De hecho, mltiples variaciones se han desarrollado sobre la implementacin del mrouted hasta el momento, alejndose ligeramente de las especificaciones definidas en el RFC 1075, en gran parte para solventar ciertas deficiencias que la implementacin de la definicin original presentaba, y en parte para adaptarlo a nuevas extensiones al protocolo IGMP. Esta implementacin convierte a la computadora en la que opera, en un router multicast que puede intercambiar informacin DVMRP con otros routers multicast similares a travs de tneles definidos por los administradores de los mismos. Estos tneles encapsulan los datagramas IP multicast en otros datagramas IP unicast que son enviados por los caminos habituales y a travs de routers convencionales desde el mrouter origen al destino. Cuando el mrouter destino recibe un datagrama IP de estas caractersticas, se encarga de eliminar las cabeceras sobrantes, obteniendo el datagrama IP multicast original, e inyectarlo en la red local o re-enviarlo a travs de otros tneles en funcin de los algoritmos de distribucin implementados en el protocolo DVMRP antes mencionados. Estos tneles constan de cuatro variables a configurar por el administrador: La direccin de destino del tnel (y la origen, en el caso de que la estacin disponga de varias interfaces de red); la mtrica, que asocia un coste a cada uno de los caminos alternativos que tenga el mrouter definidos (otros tneles, si los hay); el threshold (umbral), que establece una barrera para limitar el mbito de distribucin de los datagramas en funcin del TTL asociado a los mismos; y el rate_limit, o ancho de banda mximo permitido a travs de dicho tnel. El desarrollo de esta primera implementacin del DVMRP fue la que permiti el nacimiento de lo que hoy es MBone. En marzo de 1992 se produjo la primera transmisin de audio y vdeo en tiempo real a travs del recin creado troncal experimental multicast. Desde las apenas 40 redes conectadas en 1992, MBone ha experimentado un crecimiento sin precedentes hasta las ms de 4.300 redes conectadas, a lo ancho del mundo, en 1997. La interconexin de estos mrouters de fcil instalacin, ha ido incrementndose con el paso del tiempo dando lugar al entramado de routers multicast que forman el MBone. La ventaja de disponer de tneles de multicast corriendo sobre estaciones de trabajo, es el no comprometer las comunicaciones de cada centro, de tal forma que cualquier mal funcionamiento de dichos equipos no suponga un detrimento grave de las comunicaciones del mismo, sino tan slo de aquellas referentes al trfico multicast. Aparte del DVMRP existen otros protocolos de encaminamiento multicast, que han ido surgiendo con el tiempo en la bsqueda de una solucin de ms fcil implementacin y que resolviese los problemas de escalabilidad de que adolece el DVMRP (como cualquier protocolo de vector distancia). El MOSPF (Multicast Open Shortest Path First), definido en el RFC 1584, es una extensin al protocolo de encaminamiento unicast OSPF (RFC 1583). Este ltimo es un protocolo del tipo `estado del enlace', que permite un clculo rpido de las rutas con un mnimo de intercambio de informacin entre routers. El MOSPF es una simple extensin al anterior, que incluye la posibilidad del encaminamiento del trfico multicast. La ventaja de este esquema es que el protocolo de encaminamiento multicast se aprovecha del protocolo unicast, y no tiene que construir sus propias tablas de encaminamiento independientemente. El MOSPF slo aade la informacin de origen y grupo multicast a los mensajes de estado del enlace, con los que el OSPF crea su mapa de la topologa de red. El disponer de una descripcin del estado del enlace con la informacin de filiacin de miembros a los distintos grupos

multicast, permite la construccin de las rboles de envo de camino ms corto en la memoria de los mrouters, esto es, no necesita, como DVMRP, diseminar el primer datagrama recibido hacia todas las interfaces. Por otro lado, la construccin del diagrama de distribucin,se realiza "bajo demanda" cuando un mrouter recibe el primer datagrama para una determinada pareja {fuente, grupo}. Este esquema presenta la desventaja de que puede sobrecargar la CPU del router en los casos en los que varias parejas {fuente,grupo} aparecen al mismo tiempo, o cuando concurran muchas circunstancias que fuercen la reconstruccin de las cachs de remisin (forwarding caches). El MOSPF, al igual que su homlogo unicast (el OSPF) es un protocolo diseado para operar dentro del mbito de la intra-red (intranet), y no soporta el uso de tneles. Otros dos protocolos ms han sido definidos por el grupo de trabajo idmrdel IETF: el PIM-DM (Protocol Independent Multicast-Dense Mode) y el PIM-SM (Protocol Independent Multicast-Sparse Mode). Ambos comparten parte del nombre y emplean mensajes de control similares, pero son dos protocolos diferentes. PIM recibe su nombre de la independencia que presenta de los mecanismos de encaminamiento unicast subyacentes. Sencillamente asume que estos mecanismos existen y delega en ellos la tarea de determinar el camino hacia la fuente de los datagramas multicast, a la hora de construir el rbol de distribucin para cada pareja {fuente, grupo}. PIM-DM usa, del mismo modo que el DVMRP, el algoritmo de `Reverse Path Multicasting', pero a diferencia de este ltimo, el protocolo PIM-DM remite los datagramas recibidos para cada pareja {fuente,grupo} a todas las interfaces de red, excepto a aquella por la que se ha recibido el datagrama multicast, y slo son eliminados aquellos caminos por los se han recibido explcitamente mensajes de `podado' (pruning) porque no existan miembros de ese grupo. Este modelo de funcionamiento presenta una mayor eficiencia en el caso de que los miembros de los grupos multicast estn prximos entre s y el ancho de banda no sea un recurso escaso. La razn principal del desarrollo del PIM-SM, ha sido el intentar paliar las deficiencias presentadas por el DVMRP y MOSPF en los casos en que los enlaces entre mrouters estn dispersos a lo largo de amplias zonas y que los miembros de cada grupo multicast no estn concentrados en las proximidades de los mrouters, situacin que se presenta en las topologas de red extensa (WAN). Todos los protocolos mencionados hasta el momento (a excepcin del PIM-SM), se comportan ms o menos eficientemente en condiciones de una distribucin poblada de receptores dentro de la intranet. Sin embargo, fallan cuando se aplican a entornos de red extensa o de poblacin esparcida, en las que el nmero de receptores puede considerarse, en trminos generales, escaso. Para cubrir estos supuestos, estn en desarrollo dos nuevos protocolos de encaminamiento multicast: el PIM-SM (PIM Sparse mode) y los de rbol basado en el ncleo o `Core-based trees' (CBT). El protocolo PIM-SM (documentado en el RFC 2117), puede usar simultneamente las tcnicas de rbol basado en la fuente (source-based tree) o de rbol compartido (shared tree). Por defecto se utilizan diagramas de rbol compartido centrados en un mrouter principal o `Rendezvous Point', pero con independencia de la tcnica en uso, no se produce la remisin, por defecto, de datagramas multicast. Para que esto ocurra es necesario que estos RP reciban un mensaje de sus mrouters vecinos con una peticin explcita de filiacin a un determinado grupo. En la actualidad la mayor parte de estos protocolos cohabitan en el MBone y la tnica general es la implantacin de PIM-DM, DVMRP o MOSPF en entornos corporativos, y la conexin de estas `islas' multicast a travs de tneles DVMRP. Sin embargo, es preciso resaltar que la interrelaccin de estos protocolos de encaminamiento multicast est an en perodo de estudio y experimentacin. Existe un trabajo en progreso dentro del grupo de trabajo idmrdel IETF, que pretende definir los requisitos que se deben cumplir en la interaccin de distintos protocolos de encaminamiento multicast.

4.- Qu ventajas ofrece el IP multicast?La ventaja del IP multicast frente a otros tipos de comunicaciones, es la transmisin de informacin en tiempo real para mltiples receptores. En estos casos la utilizacin del multicast permite un ahorro

substancial de los recursos de red consumidos, y por ende una mejora en la transmisin de esta informacin y -porqu no?- una mejor relacin calidad/costes. La ventaja de aprovechar el multicast para la transmisin de datos multimedia frente a las comunicaciones uno-a-uno, es el ahorro de recursos telemticos y por tanto la eficiencia de las aplicaciones a iguales gastos en infraestructura. Pongamos un ejemplo sencillo: En una conferencia basada en comunicaciones uno-a-uno, la eficiencia de la misma es inversamente proporcional al nmero de receptores en un extremo dado de la red. Cada nuevo receptor en un mismo extremo de la red obliga a que los paquetes de informacin enviados por el emisor se dupliquen. En el caso de las comunicaciones uno-a-muchos (IP multicast o MBone) la eficiencia no se ve afectada por este factor. A cada extremo de la red en la que existen receptores de la misma, slo llegan una vez los paquetes que contienen la informacin, independientemente del nmero de receptores. Los protocolos de encaminamiento subyacentes en MBone se encargan de asegurar que la informacin que viaja entre el emisor y los receptores no pase ms de una vez por el camino entre ambos, y que slo sea enviada en el caso de que existan receptores de la misma.

5.- Cules son sus inconvenientes y cmo resolverlos?MBone, como red experimental, existe desde 1992 y ha evolucionado hacia algo ms que un simple experimento. De hecho es un experimento de dimensiones impresionantes que interconecta a decenas de miles de usuarios de todo el mundo. En todos los sentidos esto puede ser considerado como un enorme xito. Por un lado hemos visto como existe una fuerte demanda por los tipos de aplicaciones que permiten las transmisiones multicast. Por otro lado es difcil la investigacin cuando no se cuenta con usuarios e infraestructuras reales, pero si los experimentos resultan satisfactorios, los propios usuarios demandan su utilizacin como un servicio operativo. Existen un cierto nmero de inconvenientes que impiden hacer de MBone un servicio operativo en la actualidad. Algunos de ellos constituyen un defecto intrnseco de la propia filosofa de diseo de MBone como un experimento en nuevos protocolos de comunicaciones. Otros, por el contrario, son resultado del estado primitivo an de estos protocolos, o de la falta de algunas piezas en este complejo rompecabezas. La implementacin real del MBone como un servicio operativo global, requerir un cambio topolgico esencial en el que, las cada vez ms numerosas islas multicast interconectadas entre s, dejen paso a un medio completamente multicast integrado dentro del encaminamiento IP. Esto no implica que se deba producir de una forma radical, sino ms bien tendr lugar de una forma progresiva. Para que esto pueda tener lugar, se requieren muchos esfuerzos encaminados a acabar de perfilar los protocolos existentes hasta adaptarlos a un modelo que ofrezca las cualidades de escalabilidad que una red tan compleja como la Internet requiere, o descubrir otras vas alternativas que ofrezcan una solucin global a la integracin del encaminamiento unicast y multicast. Mientras tanto, MBone ofrece numerosas ventajas dentro de cada una de estas `islas' multicast que lo forman. En cuanto a los protocolos de encaminamiento y algoritmos de creacin de rboles de distribucin, existen ciertas deficiencias que deben ser corregidas antes de que se puedan considerar aptos para su implementacin masiva. Cualquier protocolo escalable debe tender a minimizar los requisitos del estado de remisin (forwarding state). En el caso de protocolos orientados a distribuciones pobladas de fuentes/receptores (DVMRP, PIM-DM), los mrouters deben guardar la informacin de estado de remisin o `podado' para cada pareja {fuente,grupo} en la Internet. Es obvio que si el multicast se escala al tamao de la Internet, el mantenimiento de tal informacin se hace insostenible. Los protocolos de rbol compartido (PIM-SM, CBT) carecen de este problema, pero sin embargo, pueden dar lugar a la remisin de datagramas por parte de Rendezvous Points o Cores situados en las fronteras de reas que se solapan y que estn dentro del rbol compartido para las mismas, an cuando no haya receptores en su propia subred. Tambin pueden presentar problemas de congestin de red debido a las concentraciones de trfico en los rboles compartidos, lo que da lugar a un incremento de la latencia o prdida de paquetes.

En cuanto al nivel de transporte, en el primer apartado de este artculo, habamos indicado que una de las grandes desventajas del uso del protocolo UDP para el transporte de contenidos multimedia en tiempo real, es la imposibilidad de garantizar la llegada ordenada de los paquetes de informacin a sus destinos. Este problema, inherente a la propia tecnologa empleada, ha sido resuelto con la definicin de un nuevo protocolo orientado a este tipo de transmisiones. Este es el protocolo de transporte en tiempo real o RTP (Real Time Protocol). La implementacin de este protocolo est documentada en el RFC 1889, publicado por el IETF en enero de 1996. El RTP fue pensado para satisfacer las necesidades de multi-conferencias multimedia, sin embargo su uso no esta limitado a estas aplicaciones. Puede emplearse del mismo modo en el almacenamiento continuo de datos, la simulacin distribuida, control y medida en tiempo real, etc. El RTP permite la distribucin de informacin a mltiples receptores usando multicast si este modo de distribucin es soportado por la infraestructura de red subyacente. Sin embargo, el protocolo RTP, no garantiza la entrega a tiempo de la informacin, sino que confa en el medio subyacente para este propsito. Por otro lado incluye su propia secuenciacin de fragmentos que permite reconstruir ordenadamente la informacin en su destino, con independencia de que exista un medio fiable o no de transmisin. El problema que se presenta entonces es el de poder garantizar una calidad de servicio aceptable en las transmisiones multimedia. Esta quizs sera una de las ltimas piezas que haran funcionar el engranaje de MBone como un servicio operativo, en cuanto a nivel de transporte se refiere, es decir, sin tener en cuenta la problemtica del encaminamiento multicast descrita anteriormente. Para poder garantizar la calidad del servicio es necesario disponer de un mecanismo que nos permita reservar los recursos necesarios, tanto a nivel del equipo transmisor (tiempo de CPU, ancho de banda de acceso a disco, etc.), como en el camino entre ste y el(los) receptores (ancho de banda mantenido en la ruta entre ellos). Gran parte de estas caractersticas se han definido dentro de un protocolo llamado `Resource ReSerVation Protocol' (RSVP), documentado en sus mltiples aspectos en los RFCs 2205 a 2216. El RSVP lo usan los equipos finales para solicitar una determinada calidad de servicio de la red, para un flujo de datos de una aplicacin especfica. Tambin lo emplean los routers para distribuir estas peticiones de calidad de servicio a todos los nodos intermedios en el camino de dicho flujo y para establecer y mantener el estado que permita prever el servicio solicitado. Este protocolo no se encarga de transmitir la informacin, sino que es un protocolo de control como el ICMP, IGMP o los de encaminamiento.

6.- Cmo sacar provecho al MBone ?Se han desarrollado gran cantidad de herramientas para experimentar diferentes intercambios multimedia a travs de MBone ya sea en modo interactivo: editores de texto y pizarras electrnicas compartidas, intercambio de hipertextos; o de procesos no interactivos: sincronizacin de equipos (NTP multicast) o distribucin de archivos a mltiples receptores simultneamente (FTP multicast) por poner algunos ejemplos. Algunas de estas aplicaciones experimentales, como son las de transmisin de audio y vdeo, se han convertido prcticamente en estndares de facto y son ampliamente utilizadas por un elevado nmero de usuarios con cierta regularidad. Las misiones del transbordador de la agencia espacial americana (NASA), las reuniones peridicas de los grupos de trabajo del IETF, as como emisiones de radio por multicast, son algunas de las sesiones disponibles con regularidad en MBone y seguidas por un gran nmero de usuarios en todo el mundo. Gran parte de las aplicaciones aqu enumeradas estn disponibles para casi cualquier plataforma informtica: desde un simple PC con Windows95, hasta una estacin de trabajo con UNIX (en casi cualquiera de sus variantes), lo cual ha contribuido a la popularidad de las mismas. De este modo cualquier PC multimedia bsico, es decir, que disponga de una tarjeta de audio y un micrfono, nos permitir convertirnos en un nodo receptor de MBone y ser capaces de bien asistir a cualquiera de las videoconferencias que se emiten, o intervenir en aquellas en las que se permita la participacin remota. Con una pequea inversin, que consistir en adquirir una cmara digital de bajo coste, podremos convertirnos en una estacin de emisin y recepcin de videoconferencias. No es necesario decir que sto ofrece unas ventajas substanciales en el desempeo de nuestras actividades profesionales y/o

acadmicas. Siguiendo esta lnea se estn produciendo estudios a varios niveles, como es en el campo de la educacin y la medicina, sobre la viabilidad y el impacto social y/o laboral de estas nuevas tecnologas. Dentro del amplio abanico de aplicaciones que han aparecido en estos ltimos aos (gran parte de ellas continan en desarrollo), las ms populares en MBone han sido las que permiten la realizacin de conferencias de audio y vdeo. Dentro de este grupo el rat y el vat son las ms empleadas para la transmisin/recepcin de audio, y el vic para la transmisin/recepcin de vdeo. En el apndice describiremos brevemente estas y otras herramientas existentes, e indicaremos los localizadores en Internet (URLs) para conseguirlas. Una utilidad fundamental en MBone, que permite la integracin de todas las anteriores, es el SDR (Session Directory Tool), o directorio de sesiones MBone que nos permite conocer las sesiones que estn activas en todo momento, conectarnos a cualquiera de ellas, o definir nuestra propia sesin MBone. La primera implementacin del SDR, llamado SD, fue desarrollada por Van Jacobson en el LBNL (Lawrence Berkeley National Laboratory). El desarrollo posterior de la misma ha sido llevado a cabo dentro del proyecto europeo de investigacin en herramientas multimedia MERCI (antes MICE), dando lugar al actual SDR. Ciertos cambios en fundamentales en su estructura han hecho que ambas versiones sean incompatibles y en la actualidad los anuncios de sesiones, se hacen de forma generalizada con la nueva versin desarrollada por el MERCI, el SDR. El SDRemplea una direccin multicast asignada por la IANA, la 224.2.127.254 y un puerto UDP especfico (el 9875) para retransmitir los anuncios de sesiones multimedia. Esto se implementa por medio de un protocolo muy simple, en el que los datos de la sesin van incluidos en forma de texto ASCII tras una breve cabecera UDP. Esta simple implementacin, permite que estos datos puedan ser capturados fcilmente por una aplicacin y puedan emplearse para lanzar las aplicaciones necesarias para unirse a una determinada conferencia. Otras aplicaciones de gran utilidad, y empleadas principalmente como complemento a las anteriores, en la realizacin de videoconferencias, son la pizarra electrnica (wb) y el editor de textos compartido. Con la primera de ellas nos encontramos ante una aplicacin que nos proporciona el acceso a una pizarra en la que disponemos de una serie de utilidades tanto para escribir textos con varios tamaos y formas, como para realizar dibujos a mano alzada y formas geomtricas sencillas. Cualquier diseo que creemos en esta pizarra virtual, ser automticamente visto por todos los participantes en la sesin, y cualquiera podr hacer modificaciones sobre dichas imgenes. Tambin tenemos la posibilidad de incorporar archivos en formato PostScript a dicha pizarra. Por otro lado, el editor de texto compartido (Network Text editor) o nt, permite a mltiples usuarios trabajar en tiempo real sobre un mismo documento de texto: crear nuevos prrafos, borrar, cambiar y mover los existentes, etc. El ivs (INRIA Videoconference System), desarrollado por el INRIA (Institut National de Recherche en Informatique et en Automatique), permite la integracin de los canales de audio y vdeo sobre una misma aplicacin. Esta aplicacin fue desarrollada en 1992 y actualmente ha dejado de ser mantenida para dar paso a otras nuevas aplicaciones como el Rendez Vous (nueva generacin del ivs) y FreePhone . Todas las aplicaciones que hemos descrito aqu son fruto del trabajo desarrollado por varios grupos de investigacin y han sido puestas a disposicin de todos los pobladores de Internet como software de dominio pblico. Muchas de ellas estn an en fase de desarrollo, pero an as permiten obtener unos resultados cuando menos sorprendentes.

Mensajes de Error

Losmensajes de errorde ICMPv6 son similares a losmensajes de errorde ICMPv4. Se dividen en 4 categoras:destino inaccesible, paquetedemasiado grande, tiempo excedido y problemasde parmetros.1 Destination Unreachable (Destino Inalcanzable) 2 Packet Too Big (PaqueteDemasiado Grande) 3 Time Exceeded (Tiempo Agotado) 4 Parameter Problem (Problemade Parmetros)

Contenido 1 Arquitectura 2 Estndares

3 Puestas en prctica del anfitrin y de la rebajadora 4 Vea tambin 5 Referencias

6 Acoplamientos externos

ArquitecturaUna red dise entregar un servicio del multicast (como el vdeo) que usabaIGMP pudo utilizar esta arquitectura bsica:

IGMP es utilizado por la computadora del cliente y el adyacente interruptores de la red para conectar a cliente con una rebajadora local del multicast. Multicast de la independiente delprotocolo (PIM) entonces se utiliza entre las rebajadoras locales y alejadas del multicast, dirigir trfico del multicast del servidor video a muchos clientes del multicast.

EstndaresHay tres versiones deIGMP, segn lo definido por Request For CommentsDocumentos (RFC) del Internet Engineering Task Force(IETF).IGMP v1 se define cerca RFC 1112,IGMP v2 se define cerca RFC 2236eIGMP v3 se define cerca RFC 3376.

Puestas en prctica del anfitrin y de la rebajadoraElprotocolo deIGMP se pone en ejecucin como un lado del anfitrin y lado de la rebajadora. Un lado del anfitrin divulga su calidad de miembro de un grupo a su rebajadora local, y un lado de la rebajadora escucha los informes de los anfitriones y envi peridicamente preguntas.

Linux sistema operativoayudasIGMP. Ncleo de Linuxen la base del sistema operativo pone solamenteIGMP en ejecucin como lado del anfitrin, no lado de la rebajadora, al menos a demoniopor ejemplo mrouted puede ser utilizado actuar como rebajadora deIGMP Linux. Hay tambin habitaciones enteras de la encaminamiento (por ejemplo XORP), que dan vuelta a una computadora ordinaria en una rebajadora hecha y derecha del multicast.

Vea tambinIGMP snooping

Referencias1. 2. 3. 5. 4.^ Brujera de la red -IGMP

^ Spoofed Negacin del informe deIGMP del servicio vulnerabilidad.

^ Paquete hecho fragmentos deIGMP puede promover la negacin ataque del servicio. ^ Declaracin y requisitos del problema de la seguridad deIGMP.

^ Boletn MS06-007 de la seguridad de Microsoft: La vulnerabilidad en el TCP/IP podra permitir la negacin del servicio (913446).

Acoplamientos externos Brujera de la red -IGMP

Herramientas y ajustes del Multicasting IPv4 en Microsoft TechNet Diversos versin y detalles enIGMP

Multidifusin IP en Internet: Protocolo IGMP de gestin de grupos de InternetIPIGMPInterfaz de RedHardwareACCESO A REDINTERNETMdulo IGMPMdulo IP Figura 1.- Ubicacin del protocolo IGMP en la arquitectura TCP/IP.

En el escenario de las transmisiones IP de multidifusin, los sistemas finales de usuario comunican sus pertenencias a grupos de multidifusin en Internet al router de multidifusin local1 de la propia organizacin mediante el protocolo IGMP (Internet Group Management Protocol) de Gestin de Grupos de Internet (RFC2236). Mediante dicho protocolo IGMP, el propio router de multidifusin local de

la organizacin puede encontrar mquinas vecinas con miembros activos de cualquier grupo de multidifusin que haya en Internet en el escenario de la propia red de rea local de la organizacin en cuestin. Desde el punto de vista de su ubicacin en la arquitectura de comunicaciones TCP/IP, y segn se muestra en la anterior Figura 1, el protocolo IGMP ocupa al igual que el protocolo ICMP, un mismo subnivel de comunicaciones por encima de IP en el nivel de red o Internet. Adems, y al igual que el protocolo ICMP, el protocolo IGMP est tan ntimamente ligado al protocolo IP2, que de hecho se puede ver como una parte integral3 de IP, es decir, un mdulo ms dentro del propio mdulo o proceso IP.1 Que 2 Se

est conectado a la misma red de rea local (Ethernet o IEEE 802). ejecuta directamente sobre IP. En el campo PROTOCOLO de la cabecera IP, aparece el valor 2 en decimal (por ejemplo, para ICMP el valor en decimal es 1). 3 No como un protocolo separado.

-1CabeceraIGMPDatosCabeceraIPCabeceraIPCabeceratrama MENSAJE IGMP DE DIFUSINDATAGRAMA IPDatosDatosTRAMA MAC Ethernet

Figura 2.- Encapsulacin de un mensaje IGMP.

Segn se describe en la anterior Figura 2, el protocolo IGMP encapsula un mensaje IGMP en un datagrama IP. De ah que IGMP ocupe un subnivel superior al ocupado por el protocolo IP en el mismo nivel de Internet o red de la arquitectura TCP/IP. Se resalta que las direcciones de multidifusin (clase D) slo pueden emplearse como direcciones IP de destino. stas nunca aparecen en el campo de direccin del origen de un datagrama. Asimismo, no se generan mensajes de error ICMP relacionados con datagramas de multidifusin. Cuando se encapsula un mensaje IGMP en un datagrama IP para su transmisin, la direccin de destino en la cabecera IP es la direccin de multidifusin del grupo, por ejemplo, 224.0.0.14, 224. 0.1.75, etc. MAC Ethernetde unidifusinTCP/UDPAplicacinAplicacinmultidifusinmultidifusinGrupo 1Grupo1AplicacinAplicacinmultidifusinmultidifusinGrupo 2Grupo 2Direcciones IP de unidifusinde redes y mquinas conocidas(incluida M1)Hardware

EthernetMAC Ethernetde difusin

Aplicacinunidifusin1AplicacinunidifusinnMquinaconocidas (incluidas las de Grupo 1 y Grupo 2)

M1Direcciones IP de difusin conocidas (limitada y dirigida(s)

MAC EthernetEthernetde de multidifusinmultidifusinDirecciones Direcciones IP de multidifusinmultidifusinconocidas

Figura 3.- Un ejemplo de correspondencias de direcciones IP y MAC.

Los datagramas IP que transportan mensajes IGMP o mensajes especifcos de una aplicacin de multidifusin se transmiten finalmente por la red de acceso a travs de4 Asignada 5 Asignada

permanentemente a todas las mquinas en esta red de rea local. permanentemente para noticias de audio (audionews).

-2tramas MAC Ethernet6 mediante el correspondiente software de multidifusin del interfaz de la red de acceso. Dicho software transforma o adapta una direccin IP de multidifusin en la correspondiente direccin MAC de multidifusin (ver niveles implicados en la anterior Figura 3). Consecuentemente, aquellas mquinas que no soporten el software de multidifusin IP en el nivel del interfaz de la red de acceso de la arquitectura TCP/IP, nunca transmitirn ni recibirn mensajes de multidifusin. En este contexto, es importante resaltar que toda mquina TCP/IP conectada, por ejemplo, a la clsica red de acceso de rea local del tipo Ethernet; tiene que tener

potencialmente la capacidad de transmitir y recibir tanto tramas de unidifusin como de difusin (limitada y dirigida) y, obviamente, de multidifusin. Para ello, es imprescindible que los datagramas IP que transportan, por ejemplo, mensajes de unidifusin se transmitan, finalmente, por la red de acceso a travs de tramas MAC Ethernet de unidifusin mediante el correspondiente software de unidifusin del interfaz de la red de acceso. Dicho software transforma una direccin IP de unidifusin en la correspondiente direccin MAC de unidifusin. En la siguiente Figura 4 se muestra el envo de una trama de unidifusin (encapsulando al pertinente datagrama IP de unidifusin 128.1.1.2), a la mquina cuya direccin IP es 128.1.1.2 y cuya direccin MAC Ethernet de destino comienza con los tres primeros octetos (en hexadecimal) 08-00-4E7. 6 Suponiendo

que la red de acceso es una red de rea local del tipo Ethernet. Por consiguiente, una red de rea local del tipo Ethernet (IEEE 802.3) soporta multidifusin en el protocolo del interfaz de acceso a dicha red. 7 Propios, en este ejemplo, del fabricante 3COM EUROPE LTD de tarjetas de red Ethernet, segn la normalizacin realizada por IEEE al respecto para distinguir a un fabricante de otro. Se resalta que el bit menos significativo del primer octeto si es un 0 denota una direccin Ethernet y si es un 1 una direccin de multidifusin. A continuacin de esos tres primeros octetos seguiran los restantes tres octetos asignados por 3COM a la tarjeta en cuestin y que identifica a sta de cualquier otra tarjeta de dicho fabricante y, obviamente, de otros fabricantes.

-3128.1.1.0/255.255.255.0Origen1Direccin destino MAC=08004E08004ETrama EthernetDireccin destino IP=128128.1.1.2.1.1.2 128128.1.1.2.1.1.2

DatagramaIPDireccin Ethernet DatagramaIP128.1.1.2

Figura 4.- Ejemplo de unidifusin mediante tramas.

A su vez, los datagramas IP que transportan mensajes de difusin han de transmitirse, finalmente, por la red de acceso a travs de tramas MAC Ethernet de difusin mediante el correspondiente software de difusin del interfaz de la red de acceso. Dicho software transforma, en este caso, una direccin IP de difusin en la correspondiente direccin MAC de difusin. En la siguiente Figura 5 se muestra el envo de una trama de difusin limitada (encapsulando al pertinente datagrama IP de difusin limitada 255.255.255.255), a todas las mquinas de la red 128.1.1.0 cuyas direcciones MAC Ethernet de destino constan siempre de los mismos 6 octetos o 48 bits todos a unos en binario (FFFFFFFFFFFF en hexadecimal). 128.1.1.0/255.255.255.0Origen1Direccin destino MAC=FFFFFFFFFFFFFFFFFFFFFFFFTrama EthernetDireccin destino IP=255255.255.255.255.255.255.255DatagramaIPDireccin Ethernet255255.255.255.255.255.255.255DatagramaIPFigura 5.- Ejemplo de difusin limitada mediante tramas

En la siguiente Figura 6 se muestra el envo de una trama de difusin dirigida (encapsulando al pertinente datagrama IP de difusin dirigida 128.1.255.255), a todas las mquinas de las redes 128.1.1.0 y 128.1.2.0 cuyas direcciones MAC Ethernet de destino constan siempre de los mismos 6 octetos o 48 bits todos a unos en binario (FFFFFFFFFFFF en hexadecimal). -4128.1.1.0255.255.255.0128.1.2.0255.255.255.0OrigenRouter1Router3Router2Direccin destino

EthernetDireccin destino IP=128128.1.255.255.1.255.255 DatagramaIPDireccin Ethernet128128.1.255.255.1.255.255DatagramaIPMAC=FFFFFFFFFFFFFFFFFFFFFFFFTrama

Figura 6.- Ejemplo de difusin dirigida mediante tramas-

Para terminar, los datagramas IP que transportan mensajes de multidifusin deben enviarse, finalmente, por la red de acceso a travs de tramas MAC Ethernet de multidifusin mediante el correspondiente software de multidifusin del interfaz de la red de acceso. Dicho software transforma, en este ltimo caso, una direccin IP de multidifusin en la correspondiente direccin MAC de multidifusin. En la siguiente Figura 7 se muestra el envo de una trama de multidifusin (encapsulando al pertinente datagrama IP de multidifusin para el grupo 224.0.1.7), a todas las mquinas de las redes 128.1.1.0 y 128.1.2.0 cuyas direcciones MAC Ethernet de destino comienzan siempre con los tres primeros octetos (en hexadecimal) 01-005E. 128.1.1.0255.255.255.0128.1.2.0255.255.255.0OrigenRouter1Router3Router2Direccin destinoEthernetDireccin destino IP=224224.0.1.7.0.1.7DatagramaIPDireccin Ethernet224224.0.1.7.0.1.7DatagramaIPMAC=01005E01005ETrama

Figura 7.-Ejemplo de multidifusin mediante tramas

En la siguiente Figura 8 se muestra, ms en concreto, la transformacin, traslacin o correspondencia (mapping) de una direccin IPv4 clase D de multidifusin en una direccin de trama de multidifusin MAC Ethernet o IEEE 8028. La citada transformacin o adaptacin se ajusta al siguiente procedimiento:8 Una

direccin MAC Ethernet o IEEE 802 consta de 48 bits.

-5 Se incluyen los 23 bits de menor orden o menos significativos de la direccin IP de multidifusin9 en los 23 bits de menor orden de la direccin MAC Ethernet de multidifusin. En este contexto, los diseadores utilizaron 23 de los 28 bits para una direccin MAC porque en este conjunto de bits se incluyen la mayor parte de las direcciones de multidifusin. Por consiguiente, el conjunto de direcciones IP definidos en esos 23 bits es lo suficientemente extenso10 como para que la posibilidad de coincidencia11 en el nivel IP sea muy pequea. Por otro lado, dicha coincidencia ser resuelta en el nivel de red ya que IP sabe qu direcciones de multidifusin estn activas en su mquina. La consecuencia de este diseo es que algunos datagramas IP de multidifusin pueden recibirse en una mquina, aunque dichos datagramas no estn destinados a tal mquina. Ser la entidad IP quien verifique cuidadosamente las direcciones en todos los datagramas IP de multidifusin entrantes y elimine cualquier datagrama IP de multidifusin no esperado perteneciente a un grupo inexistente en la propia mquina.00000001000000000 010111101110xxxxxxxxxxxxxxxxxxxxxxxxxxxx23 bits de menor orden de la direccinIP de multidifusincopiados en la direccin Ethernet5 bits de la direccin IP de multidifusinno usados en la direccin Ethernet

01005EHEXADECIMAL48 bits de una direccin Etherneto IEEE

802Direccin IPv4Clase D00000001000000000 D

Figura 8.- Transformacin IPv4 Clase D en MAC Ethernet o IEEE 802.

Todas las direcciones Ethernet o IEEE 802 de multidifusin disponen de los mismos 25 primeros bits, 00000001 00000000 01011110 0. Ms en concreto, 0x01-00-5E9 Se

recuerda que una direccin IP de multidifusin (clase D) comienza por 1110 y, a continuacin, aparecen los 28 bits restantes de identificacin del grupo. 10 Quedan 5 bits sin usar (exceptuando los 4 bits, 1110, del prefijo clase D); quiere decir esto, que potencialmente puede haber como mximo 25 32 grupos o combinaciones idnticas; es decir, que al menos 2 de esos 32 grupos seleccionen una misma combinacin de los 223 bits restantes. 11 Que dos o ms grupos seleccionen seleccionen direcciones MAC idnticas.

-6-

(00000001 00000000 01011110) es la notacin en hexadecimal de los tres primeros octetos que se correponden con el identificador12 nico del fabricante de la tarjeta. El bit a continuacin, que siempre est a cero, pertenece en direcciones de unidifusin al siguiente bloque de 24 bits que identifican a la tarjeta del fabricante en cuestin. Por consiguiente, el rango completo de direcciones MAC Ethernet o IEEE 802 de multidifusin es de 01:00:5e:00:00:00 a 01:00:5e:7f:ff:ff. Se resalta que la correspondencia entre las direcciones IP clase D de multidifusin y las direccin de trama de multidifusin MAC Ethernet o IEEE 802 no es biunvoca, ya que existen 32 direcciones IP de multidifusin diferentes por cada direccin MAC de multidifusin. As, por ejemplo, las direcciones IP de multidifusin 224.0.0.1 y 224.128.0.1 tienen iguales los 23 ltimos bits y se corresponden ambas con la direccin MAC de multidifusin 01.00.5E.00.00.8013. Por consiguiente, puede suceder que, por ejemplo, en una misma red Ethernet, al menos dos grupos de multidifusin diferentes utilicen la misma direccin MAC Ethernet de multidifusin; en este caso, algunas mquinas capturarn tramas MAC de multidifusin que luego al examinar la cabecera IP, descubrirn que no iban dirigidas a ellas. Evidentemente, hay una pequea prdida de eficiencia por el tiempo que el nivel de red emplea en analizar una informacin de control que no iba dirigida al nivel IP de dicha mquina; pero la probabilidad de que esto ocurra en la prctica es tan pequea que la prdida de eficiencia es despreciable14. Obviamente, se recuerda que para poder participar en una multidifusin IP, una mquina debe poseer el software que le permita enviar y recibir datagramas IP de multidifusin. El software de IP debe permitir a una aplicacin especificar una direccin de multidifusin como una direccin IP de destino. Asimismo, como ya se ha indicado, el software del interfaz de la red de acceso debe ser capaz de transformar una direccin IP de multidifusin en la correspondiente direccin MAC de multidifusin15. En el escenario de IPv6; actualmente, para transformar una direccin IPv6 de multidifusin en una direccin MAC Ethernet o IEEE 802, se cogen los 32 bits de menor orden de dicha direccin IPv6.12 OUI 13 Se

(Organizationally Unique Identifier). resalta que las direcciones MAC en Ethernet se representan empezando por el bit menos significativo de cada octeto. 14 Suponiendo un reparto aleatorio, la probabilidad de coincidencia entre dos grupos de multidifusin ser de 25/228 = 0,0000001. 15 O utilizar la difusin si el software del interfaz de la red de acceso no soporta multidifusin.

-7Bits11111111000 TAlcance44Identificador de grupo808T (transitorio o transient) = 0: Direccin notransitoriao asignada permanentemente por IANA/ICANNT (transitorio o transient) = 1:Direccin transitoriao no asignada permanentementeAlcance o lmite del grupo de multidifusin: Nmero entero de 4 bits.0: reservado; 1: Nodo local o en la propia mquina; 2: enlace local; ; 5: sitio local;; 8: organizacin local (compuestas de varios sitios); 000..032Todo a ceros

Figura 9.- Formato actual de la direccin IPv6 de multidifusin.

Pero de esos 32 bits, slo se puede incluir los 23 bits16 anteriormente citados en la direccin MAC Ethernet de multidifusin. Como ya se ha indicado, ser la entidad IP quien verifique cuidadosamente las direcciones de grupo de todos los datagramas IP de multidifusin entrantes y elimine cualquier datagrama perteneciente a grupos de multidifusin inexistentes en la correspondiente mquina.

Antes de seguir avanzando, es importante diferenciar entre el protocolo de distribucin y actualizacin de la informacin de pertenencias a grupos de multidifusin17 empleado entre routers de multidifusin locales e intermedios18 en Internet y el protocolo IGMP utilizado, como ya se ha indicado, en la red de rea local (Ethernet o IEEE 802) de una organizacin entre el router de multidifusin local y los sistemas finales vecinos. Concretamente, los mecanismos de IGMP permiten llevar a cabo dos acciones fundamentales: 1. Que las mquinas destinatarias o sistemas finales de una red de rea local (Ethernet o IEEE 802) informen a su router de multidifusin local de que desean unirse a un grupo especfico de multidifusin; es decir, desean recibir datagramas IP de multidifusin dirigidas a dicho grupo.16 Por

consiguiente, al igual que con IPv4, quedan 5 bits sin usar; quiere decir esto, que potencialmente puede haber 25 32 grupos potenciales que selecciones idnticas direcciones MAC. 17 Como ya se estudiar ms adelante, tambin, denominado protocolo de encaminamiento dinmico de multidifusin, el cual se utiliza en Internet por los propios routers de multidifusin. Se resalta que IGMP es un estndar en Internet, no ocurre lo mismo con los protocolos de encaminamiento dinmico de multidifusin existentes y que ya se analizarn. 18 O directamente con routers de multidifusin locales de otras organizaciones si entre medias no hay routers de multidifusin intermedios.

-82. Que el router de multidifusin local19 interrogue o sondee peridicamente a los sistemas finales de su red de rea local (Ethernet o IEEE 802) para saber si los miembros, de un grupo conocido, continan an activos. En este contexto, el protocolo IGMP consta de dos fases: Fase I.- Cuando una mquina o sistema final se une a un nuevo grupo de multidifusin, enva un mensaje o informe IGMP (tipo 2) de pertenencia a grupo (Host Membership Report) con la direccin de destino IP conteniendo la direccin de multidifusin del grupo al que pertenece la mquina de origen. Este mensaje IGMP tambin lo escucha el router de multidifusin local, que est conectado a la misma red, para realizar el correspondiente registro de pertenencia. Asimismo, el datagrama IP que encapsula dicho informe lleva un TTL = 1 para indicar expresamente que este tipo de mensaje IGMP se transmite directamente a la red de acceso y no debe ser reenviado por ningn otro router de multidifusin. A su vez, el router de multidifusin local se pone en contacto con otros routers de multidifusin vecinos por Internet, pasando20 la correspondiente informacin y registrando, en sus tablas, las oportunas rutas en funcin de dichas pertenencias para la posterior fase de transferencia de datos. Un sistema final slo tiene que emitir un informe IGMP de pertenencia por cada grupo al que pertenezca. Cuando una mquina final o destinataria se une a un determinado grupo de multidifusin, enva inmediatamente un informe de pertenencia sin esperar al siguiente sondeo. Fase II.- Debido a que la pertenencia es dinmica, el router de multidifusin local sondea de forma peridica, mediante un mensaje IGMP (tipo 1) de solicitud de pertenencia a grupos (Host Membership Query message) a las mquinas vecinas de su red de rea local para determinar aqullas que se mantienen como miembros activos de grupos. Este mensaje IGMP de solicitud o sondeo se enva en un datagrama IP con la direccin de destino conteniendo la direccin reservada de multidifusin, 224.0.0.1, que semnticamente quiere decir a todas las mquinas

en esta red de rea local. Asimismo, dicho datagrama IP lleva un TTL = 1 para indicar que este tipo de mensaje IGMP no debe ser reenviado a ninguna otra red por ningn otro router de multidifusin local que pudiera haber. En este 19 Si

hay ms de un router de multidifusin, uno de ellos se selecciona como emisor de este tipo de mensajes. 20 Mediante otro protocolo diferente a IGMP, denominado protocolo de distribucin y actualizacin de la informacin de pertenencias a grupos de multidifusin o de encaminamiento dinmico de multidifusin.

-9escenario, para que un router de multidifusin local pueda difundir alguna informacin de pertenencia a otros routers de multidifusin intermedios por Internet, debe determinar si una o ms mquinas, en su red de rea local, han decidido unirse a un grupo de multidifusin. Si para un determinado grupo, no se reciben informes de miembros despus de varios sondeos, el router de multidifusin asume que no hay destinatarios activos en su red y deja de anunciar miembros del grupo a otros routers de multidifusin vecinos en Internet. Cuando una mquina destinataria recibe una solicitud, debe responder con un informe por cada grupo al que pertenece. Asimismo, una mquina destinataria no emite ningn informe si quiere abandonar21 el grupo. Se resalta, adems, que un router de multidifusin local no tiene porqu conocer cuntas mquinas pertenecen a un grupo particular; slo le debe interesar saber que al menos una mquina pertenece a un determinado grupo. Como se puede ver, intercambiando solicitudes IGMP (entre routers y mquinas destinatarias en la misma red) e informes IGMP (entre mquinas destinatarias y routers en la misma red), un router de multidifusin local puede conocer los grupos de multidifusin que estn activos en su propias redes. De esta manera, dicho router puede reenviar un datagrama IP de multidifusin entrante a la mquina o mquinas destinatarias, pertenecientes al grupo en cuestin. Versin4Bits16Suma decomprobacinTipoDireccin de grupo clase D (cero en solicitud)031 Sin uso8

Figura 10.- Formato de un mensaje IGMP.

Como se puede apreciar en la anterior Figura 10, el formato de un mensaje IGMPv2 (8 octetos) es muy simple: Versin (4 bits).- Identifica el nmero de versin22.21 Cuando

una mquina desea darse de baja de un grupo, simplemente desactiva la aplicacin. existen tres versiones (1, 2 y 3), de las cuales, la versin 1 es la base fundamental de las otras dos que se mencionan ms adelante en este libro. Las versiones 2 y 3 son las versiones incorporadas en la mayora de los sistemas operativos. Por tanto, la ltima versin de IGMP es la 3 que se apoya en las versiones anteriores, fundamentalmente en la 2 (la ms extendida), incorporando nuevas funcionalidades que se comentarn ms adelante. Consecuentemente, para centrarse en lo fundamental de IGMP, ste libro describe la versin 2.22 Actualmente,

- 10 Tipo (4 bits).- Indica el tipo de mensaje. Existen dos tipos de mensaje: Tipo 1.- Indica un mensaje, de solicitud de pertenencia a grupo, enviado por un router de multidifusin local a todas las mquinas vecinas conectadas a la misma red de acceso. Tipo 2.- Indica un informe de pertenencia a grupo enviado por una mquina destinataria incluida en dicho grupo al resto de mquinas, tambin, pertenecientes al citado grupo en la misma red de acceso.

Sin uso (8 bits).- Todo a ceros. Suma de comprobacin (16 bits).- Se aplica a todo el mensaje IGMP (8 octetos). Se aplica el mismo algoritmo utilizado por IP. Direccin de grupo (32 bits).- Esta es la direccin IPv4 de la clase D. Contiene todo a ceros en un mensaje de solicitud, o bien una direccin de grupo en un mensaje de informe. Asimismo, el protocolo IGMP se ha diseado con el objetivo de evitar congestiones en una red de rea local en funcin de los siguientes apartados: Toda la comunicacin entre mquinas destinatarias y el router de multidifusin local utiliza multidifusin IP. Un router de multidifusin local no enva mensajes de solicitudes individuales para cada grupo de multidifusin, sino un mensaje de solicitud (sondeo) para solicitar informacin relacionada con la pertenencia en todos los grupos. Las mquinas que son miembros de varios grupos no envan respuestas mltiples al mismo tiempo. Cuando un mensaje de solicitud de IGMP llega desde un router de multidifusin local, la mquina asigna un retardo23 aleatorio entre 0 y 10 segundos para cada grupo, y enva una respuesta al correspondiente grupo despus del retardo. As, una mquina separa sus respuestas aleatoriamente dentro de un lapso de 10 segundos. Resumiendo, cuando un router de multidifusin local enva un mensaje de solicitud, todas las mquinas destinatarias, en la misma red de rea local, asignan un retardo aleatorio para las respuestas. Mediante una tcnica de supresin de informes IGMP de pertenencias a grupos, las mquinas escuchan las respuestas o informes de otras mquinas y23 Para

dar tiempo a que responda la mquina que haya recibido antes el sondeo.

- 11 no envan respuestas innecesarias. Es importante resaltar que un router de multidifusin local no necesita conservar un registro exacto de los miembros de un grupo porque todas las transmisiones hacia el grupo se envan mediante el software de multidifusin del interfaz de la red de acceso. El router de multidifusin local slo tiene que saber si existe al menos una mquina de un grupo en particular. Cuando la mquina con el retardo ms pequeo24 enva su respuesta mediante multidifusin, otras mquinas participantes reciben una copia. Cada mquina asume que el router de multidifusin local tambin recibi una copia de la primera respuesta y cancela su respuesta. Resumiendo, se puede mejorar la eficiencia si las mquinas monitorizan si otra enva el mismo informe antes de la transmisin programada. Si otra mquina ha enviado el mismo informe, la primera cancela el suyo. As en la prctica, slo una mquina de cada grupo responde a un mensaje de solicitud enviado por el router de multidifusin local. R1R1M3G3M1G1Solicitud de pertenencia agruposOrigen IP=R1Destino IP=224.0.0.1TTL=1Grupo IGMP=0M4M2G1G2Me callo porque he escuchado el informe de M1Informe de pertenencia a G1Origen IP=M1Destino IP=G1TTL=1Grupo IGMP=G1

Figura 11.- Envo de solicitudes e informes de pertenencias a grupos.

En el ejemplo de la anterior Figura 11, el router de multidifusin local R1 enva un mensaje IGMP de solicitud de pertenencia a grupos. Suponiendo que M1 dispone de un retardo de respuesta inferior a M4, M1 responde con un mensaje IGMP que contiene un informe de pertenencia al grupo G1. Este ltimo mensaje se transmite slo al grupo G125, al que pertenece la mquina de origen, con el objetivo de que el

resto de mquinas de dicho grupo escuchen el mensaje y desactiven sus temporizadores de respuesta para no tener que mandar otro 24 O

lo que es lo mismo, la primera mquina que recibe un mensaje Tipo 1 de sondeo es la primera en responder. 25 En el campo destino de la cabecera IP se pone la direccin IP de multidifusin del grupo G1.

- 12 informe repetido. Por consiguiente, aparte de R1, este ltimo mensaje tambin lo escucha la mquina M4; pero sta no transmite otro mensaje similar ya que a R1 le basta con saber26 que al menos una mquina (en este caso M1) pertenece a G1. Actualmente, existen tres versiones del protocolo IGMP: IGMP Versin 1 (RFC-1112).- Recoge todo lo que se ha estudiado hasta el momento. IGMP Versin 2 (RFC-2236).- Es la versin actualizada y mejorada de IGMPv1. Mantiene la compatibilidad con IGMPv1. IGMP Versin 3 (RFC-3376).- Es la versin actualizada y mejorada de IGMPv1 e IGMPv2. Aborda algunas debilidades de anteriores versiones como, por ejemplo, la transmisin de informacin no deseada a grupos de multidifusin. Para ello, permite a los sistemas finales especificar la lista de mquinas desde las que quieren recibir datagramas IP de multidifusin y que dicho trfico sea bloqueado por los routers27 de multidifusin locales. Finalmente, conviene recordar que IGMP se dise para operar con IPv4. Obviamente, IPv6 requiere tambin las mismas funcionalidades, las cuales se han aadido, no en otro IGMP para IPv6, sino en los correspondientes mensajes del protocolo ICMPv6. Por consiguiente, el protocolo de envo de mensajes de control en Internet, ICMPv6, incluye toda la funcionalidad del protocolo IGMP a travs de los dos mensajes fundamentales que se han estudiado para IGMP: un mensaje de sondeo o consulta de pertenencia a grupos y otro de informe de pertenencia a grupo. Dichos mensajes ICMPv6, se usan de la misma manera que en IGMP.26 El

contenido del campo direccin de grupo clase D (Grupo IGMP en la anterior Figura 11). 27 Y como alternativa por los propios sistemas finales.

- 13

Sho Suppo Commun p rt ity

Principio del form

Final del formular

Support Home Page

Manuals

Regresar a la pginade contenido Configuracinde la multidifusin IP Dell PowerConnect serie 6200 Guadel usuario DVMRP IGMP Multidifusin PIM-DM PIM-SM

Losprotocolosde multidifusin se utilizan para entregar paquetesde multidifusinde un origen a varios receptores. Facilitan un mejor usode la amplitudde banda y un menor procesamientodel host ydel enrutador, con lo que su uso es idneo en aplicacionesde conferenciade vdeo y audio herramientasde pizarra o tablerosde cotizaciones, entre otras.

Las aplicacionesde multidifusin envan una copiade un paquete y la dirigen a un grupode receptores (direccindel grupode multidifusin) quedesea recibirla, en lugarde a un nico recep (direccinde difusin nica). La multidifusindepende de la red para reenviar los paquetes

nicamente a las redes y hosts quedeben recibirlos.

Los enrutadores que admiten la multidifusin o que la tienen activada reenvan paquetesde multidifusin segn las rutas especificadas en la basede datosde informacinde enrutamientod multidifusin (MRIB). Losprotocolosde multidifusin que se ejecutan en el enrutador crean estas rutas en la MRIB durante el procesode creacinde rbolesde distribucinde multidifusin. Los distintosprotocolosde enrutamientode multidifusin IP utilizan tcnicas diferentes para crear dichos rboles.

Si el trficode multidifusin va a direccionarse a travsde partede una red que no admite la multidifusin (enrutadores que no la admiten), los paquetesde multidifusin se encapsulan en u datagrama IP y se envan como paquetesde difusin nica. Cuando el enrutadorde multidifusindel extremo remotodel tnel recibe el paquete, extrae la encapsulacin IP y reenv el paquete como paquetede multidifusin IP. Este procesode encapsulacinde paquetesde multidifusin IP sedenomina tunelado. Para ver la pginade men IP Multicast (Multidifusin IP), haga clic en IP Multicast(Multidifusin en la vistade rbol. La pginade men IP Multicast (Multidifusin IP) contiene enlaces a los procedimientos siguientes: DVMRP IGMP Multidifusin PIM-DM PIM-SM DVMRP

DVMRP intercambia paquetes sonda con todos los enrutadores que lo tienen activado, establec relaciones bidireccionales entre vecinos y genera una tablade vecinos. Intercambia paquetesde informe y crea una tablade topologade difusin nica, con la que genera la tablade enrutamientode multidifusin. Esta tabla se utiliza para direccionar los paquetesde multidifusi Dado que todos los enrutadores DVMRP utilizan el mismoprotocolo de enrutamientode difusin nica, se evitan los buclesde enrutamiento.

La pginade men DVMRPcontiene enlaces a pginas web que permitendefinir y visualizar los parmetros y datosde DVMRP. Para visualizar esta pgina, haga clic en IP Multicast (Multidifusi IP) DVMRP en la vistade rbol. A continuacin figuran las pginas web a las que se puede accederdesde esta pginade men: Configuracin globalde DVMRP

Configuracinde la interfaz DVMRP Resumende la configuracinde DVMRP Resumendel siguiente salto Resumende poda Resumende rutas Configuracin globalde DVMRP Utilice la pgina DVMRP Global Configuration(Configuracin globalde DVMRP) paradefinir los valores globalesde DVMRP. Para visualizar la pgina, haga clic en IP Multicast (Multidifusin IP) DVMRP Global Configuration(Configuracin global) en la vistade rbol. Ilustracin 13-1. Configuracin globalde DVMRP

La pgina DVMRP Global Configuration(Configuracin globalde DVMRP) contiene los campos siguientes: Admin Mode(Modode administracin): seleccione Enable (Activar) o Disable (Desactivar) en el mendesplegable.De este modo, sedefine el estadode administracinde DVMRP como activo o inactivo. El valor predeterminado es Disable (Desactivar).

Version(Versin): valor actualde la cadenade caracteresde la versinde DVMRP. Total Number of Routes(Nmero totalde rutas): nmerode rutas especificadas en la tablade enrutamientode DVMRP.

Reachable Routes(Rutas accesibles): nmerode rutas especificadas en la tablade enrutamiento DVMRP que tienen una mtrica no infinita. Definicindel modode administracinde DVMRP Abra la pgina DVMRP Global Configuration(Configuracin globalde DVMRP). Defina Admin Mode(Modode administracin) como Enable (Activar) o Disable (Desactivar) para activar odesactivar DVMRP. Haga clic en Apply Changes (Aplicar cambios). Se guarda la configuracinde DVMRP y se actualiza el dispositivo. Configuracinde DVMRP mediante los comandosde la CLI Para obtener informacin sobre los comandosde la CLI que realizan esta funcin, consulte el captulo siguientede la Guade referenciade la CLI: Comandosde DVMRP Configuracinde la interfaz DVMRP Utilice la pgina DVMRP Interface Configuration(Configuracinde la interfaz DVMRP) para configurar una interfaz DVMRP.Debe configu