FERNANDEZ GUTIERREZ ALVARO (ES)
| US20040177124A1 | 2004-09-09 | |||
| EP1370025B1 | 2006-10-04 | |||
| US20040015619A1 | 2004-01-22 | |||
| US20060031543A1 | 2006-02-09 |
| REIVINDICACIONES
1. Procedimiento para monitorizar o gestionar equipos (1 10, 120, 130) conectados a una red de datos (150) caracterizado porque: - dicha red de datos (150) dispone de una estación de control (100) que monitoriza o gestiona dichos equipos (1 10, 120,130), y; cada uno de dichos equipos puede estar en uno o en varios estados diferentes, y; dichos equipos (1 10,120,130) envían mensajes en un protocolo de ruteo multicast para solicitar recibir tráfico multicast, y; - dicho tráfico multicast solicitado consiste en grupos multicast y canales multicast que se corresponden con los estados de cada equipo, y; dicha estación de control (100) conoce el estado o los estados de cada equipo a partir de los grupos multicast y canales multicast solicitados por cada equipo.
2. Procedimiento según Ia reivindicación 1 caracterizado porque en dicha red de datos hay como mínimo un router multicast (220, 230) conectado a dichos equipos (240, 250, 260, 270, 280), y; dichos equipos envían dichos mensajes en un protocolo de ruteo multicast a un dicho router multicast (220, 230), y; - un router multicast (210, 220, 230) transmite dicha información de grupos multicast y canales multicast solicitados por cada equipo a dicha estación de control (200)
3. Procedimiento según cualquiera de las reivindicaciones 1 y 2 caracterizado porque dicha estación de control (100, 200) envía como mínimo a uno de dichos equipos una información para configurar o modificar el estado de dicho equipo.
4. Procedimiento según cualquiera de las reivindicaciones 2 y 3, cuando dicho router multicast es un router IGMP (220, 230) conectado dichos equipos.
5. Procedimiento según cualquiera de las reivindicaciones 2 y 3 cuando dicho router multicast que transmite Ia información a dicha estación de control es un router PIM-SM (210).
6. Procedimiento según cualquiera de las reivindicaciones 2, 3, 4 y 5 cuando dicho router multicast (310,320,330) que transmite dicha información a dicha estación de control (300) incluye un agente SNMP (316, 326, 336) y dicha información se almacena en una base de datos MIB (317, 327, 337) y se transmite a Ia estación de control mediante el protocolo SNMP.
7. Procedimiento según cualquiera de las reivindicaciones 2, 3, 4 y 6 cuando dicho router IGMP (220, 230) almacena en unos registros asociados con el protocolo IGMP Ia información de los grupos y canales multicast solicitados por cada equipo asociando dichos grupos y canales multicast solicitados por cada equipo con un identificador de cada equipo.
8. Procedimiento según Ia reivindicación 7 cuando dicho router IGMP (320, 330) almacena dicha información de grupos y canales multicast solicitados por cada equipo en una base de datos MIB (327, 337)
9. Procedimiento según Ia reivindicación 8 cuando dicho router IGMP (320, 330) transmite dicha información almacenada en dicha base de datos MIB (327, 337) a Ia estación de control (300).
10. Procedimiento según Ia reivindicación 9 cuando dicho router IGMP (320, 330) transmite dicha información almacenada en dicha base de datos MIB (327, 337) utilizado el protocolo SNMP.
1 1. Procedimiento según cualquiera de las reivindicaciones 2, 3, 5 y 6 cuando dicho router PIM-SM (210) almacena en unos registros asociados con el protocolo PIM-SM Ia información de los grupos y canales multicast solicitados por cada router multicast asociando dichos grupos y canales multicast con un identificador de cada router que solicita dichos grupos y canales multicast.
12. Procedimiento según Ia reivindicación 1 1 cuando dicho router PIM-SM (310) almacena dicha información de grupos y canales multicast solicitados por cada router multicast en una base de datos MIB (317)
13. Procedimiento según Ia reivindicaciones 12 cuando dicho router PIM-SM (310) transmite dicha información almacenada en dicha base de datos MIB (317) a Ia estación de control (300).
14. Procedimiento según Ia reivindicación 13 cuando dicho router PIM-SM (310) transmite dicha información utilizado el protocolo SNMP. |
Procedimiento para monitorizar o gestionar equipos conectados a una red de datos.
DESCRIPCIóN
Campo de Ia invención
La invención se sitúa en el campo de Ia tecnología de Ia monitorización, Ia gestión y Ia configuración de equipos conectados en redes de datos.
Más concretamente, Ia invención se refiere a un procedimiento de monitorización y gestión de equipos en red donde una pluralidad de equipos o dispositivos utilizan mensajes de protocolos de ruteo multicast para comunicarse con una estación de control de equipos.
La invención también se refiere a unos equipos de red que aplican dicho procedimiento.
Estado de Ia técnica
A medida que las redes de datos han ido creciendo en número de equipos, ha aumentado su complejidad y Ia heterogeneidad de los equipos conectados. Esto ha provocado un aumento en Ia dificultad y el coste de Ia monitorización, Ia gestión y Ia configuración de las redes de datos.
Para controlar este tipo de redes son necesarias herramientas estandarizadas que puedan ser utilizadas en equipos de diferentes fabricantes, incluyendo routers, switches y otros equipos de telecomunicaciones además de los ordenadores u otros equipos finales de Ia red como PDAs y teléfonos móviles. En adelante utilizaremos los términos host o dispositivo para referirnos a los equipos finales de Ia red de datos.
En respuesta a esta necesidad se desarrolló el protocolo "Simple Network Management Protocol" o SNMP, que es una herramienta que permite el mantenimiento y Ia configuración de equipos de red de diferentes fabricantes.
SNMP es un conjunto de estándares para Ia gestión de equipos de red. SNMP fue adoptado hace años como estándar para redes TCP/IP y se ha convertido en Ia herramienta más utilizada para Ia gestión de redes y dispositivos conectados a redes.
En 1991 , se añadió un suplemento a SNMP, denominado Remote Network Monitoring (RMON). RMON extiende las capacidades de SNMP para incluir Ia gestión de redes de área local (LANs) además de Ia gestión de los dispositivos conectados a dichas redes.
Hay varias actualizaciones o nuevas versiones del protocolo SNMP. En 1995 se publicó una actualización denominada SNMPv2. En 1998 se publicó Ia última versión de este conjunto de estándares, denominada SNMPv3 que mejoró todos los aspectos relacionados con Ia seguridad.
Un sistema de gestión SNMP contiene los siguientes elementos:
• Al menos una estación de control o estación de gestión, tradicionalmente llamada
"SNMP manager" o "management station". En adelante utilizaremos el término estación de control para referirnos a este elemento.
• Varios nodos (potencialmente muchos), cada uno de los cuales utiliza una aplicación, tradicionalmente llamada agente SNMP, para comunicarse con Ia estación de control. Cada agente SNMP tiene acceso a Ia información de configuración de su nodo y puede enviar mensajes y recibirlos de Ia estación de control.
• Un protocolo de comunicaciones para Ia comunicación entre Ia estación de control y los agentes SNMP.
Los agentes SNMP gestionan los recursos de cada nodo utilizando unos objetos que representan a estos recursos. Cada objeto, es una variable con datos que representa un aspecto del nodo gestionado. El conjunto de estos objetos para un determinado nodo de Ia red se denomina "Management Information Base" o MIB.
Los MIB son estandarizados para cada clase de dispositivo de red. Por ejemplo un determinado MIB se utiliza para varios switches de diferentes fabricantes.
Una estación de control SNMP monitoriza el funcionamiento de un equipo recuperando el valor de los objetos contenidos en el MIB de dicho equipo. Para ello Ia estación de control SNMP se comunica con el agente SNMP y Ie solicita dicha información.
Una estación de control SNMP también puede modificar valores de los objetos contenidos en el MIB de un equipo enviando un mensaje al agente SNMP de dicho equipo para que modifique dichos valores.
Los MIB son especificaciones que contienen definiciones para Ia gestión y el mantenimiento de Ia información para una determinada clase de equipos de red de forma que dichos equipos de red, aunque sean de diferentes fabricantes, puedan ser monitorizados, configurados y controlados remotamente.
Las reglas que definen el lenguaje utilizado para escribir los MIB están definidas en las especificaciones RFC2578 (McCIoghrie et al. , Internet Engineering Task Forcé, Request for Comments 2578, "The structure of Management Information Versión 2, SMIv2", abril de 1999, actualmente disponible en Ia dirección de Internet http://www3.tools.ietf.org/html/rfc2578) y las especificaciones RFC2579 (McCIoghrie et al. , Internet Engineering Task Forcé, Request for Comments 2579, "Textual Conventions for SMIv2", abril de 1999, actualmente disponible en Ia dirección de Internet http://www3.tools.ietf.org/html/rfc2579 ).
SMIv2 utiliza una pequeña parte de las instrucciones de un lenguaje denominado Abstract Syntax Notation One (ASN.1 ).
ASN.1 es un lenguaje formal estandarizado y es importante en el protocolo SNMP por varios motivos. En primer lugar, se utiliza para definir Ia sintaxis de los datos. También se utiliza para definir los mensajes del protocolo SNMP, también denominados "Protocol Data Units" (PDUs). Por último se utiliza para definir los MIB.
Aunque SNMP es el protocolo más extendido para Ia gestión de dispositivos de red y redes, presenta algunos inconvenientes.
Un primer inconveniente es Ia complejidad. Una visión conjunta del funcionamiento del pro- tocólos SNMP y los equipos que Io implementan se describe en las especificaciones RFC341 1 (D. Harrington et al., Internet Engineering Task Forcé, Request for Comments 341 1 , "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", diciembre de 2002, actualmente disponible en Ia dirección de Internet http://www3.tools.ietf.org/html/rfc341 1 ). En el apartado 10, referencias, de dichas especificaciones RFC341 1 se enumeran otros 22 documentos de tipo RFC ("Request For Comments") que describen dicho funcionamiento del protocolo SNMP.
Una muestra de Ia complejidad del protocolo SNMP es el proyecto de software libre "Net- SNMP" disponible en Ia dirección de Internet http://net-snmp.sourceforge.net/ donde está disponible el código fuente de un agente SNMP. Dicho código fuente puede ser descargado libremente, y Ia versión disponible en enero de 2008 de dicho agente SNMP consta de un total de 878 archivos de código fuente en lenguaje C (archivos cuya terminación es "c" o "h") que incluyen un total de 316.435 líneas de código.
Esta complejidad es un problema por dos motivos. Un primer problema es económico por el tiempo, los conocimientos y los recursos humanos necesarios para implementar un agente SNMP. Un segundo problema es técnico por Ia capacidad de almacenamiento y de proceso necesaria en los dispositivos que deben incorporar agentes SNMP. Este último problema de recursos técnicos no es un problema en equipos como routers, switches u ordenadores que disponen de suficiente capacidad de procesamiento para implementar agentes SNMP. Sin embargo esta complejidad técnica sí es un problema en muchos otros equipos que disponen de una capacidad de procesamiento menor y donde además el consumo de energía puede ser un factor importante en el diseño de dichos equipos, como por ejemplo en teléfonos móviles o en sistemas controlados mediante microcontroladores con una capacidad limitada de memoria y procesamiento.
Otra limitación del protocolo SNMP es que Ia estación de control SNMP debe establecer una comunicación directa con cada agente SNMP. Esto supone varios problemas a medida que aumenta el número de agentes SNMP que debe controlar. El primer problema es que
Ia estación de control SNMP puede gestionar un número limitado de agentes SNMP y puede no tener suficiente capacidad de procesamiento si el número de agentes es de varios miles o cientos de miles. El segundo problema es el tráfico que se genera en Ia red por culpa de los mensajes SNMP entre Ia estación de control SNMP y los agentes SNMP a medida que crece el número de dispositivos gestionados.
Una tecnología que es posible utilizar para solucionar estas limitaciones de SNMP es Ia tecnología multicast. Hay algunos estudios científicos que estudian el uso de Ia tecnología multicast en el protocolo SNMP.
El siguiente documento describe el uso de envío de paquetes multicast entre agentes SNMP: Ehab Al-Hshaer, Yongning Tang. "Toward lntegrating IP Multicasting in Internet Network Management Protocols". Computer Communications, Volumen 24, Numero 5, 15 Marzo 2001 , pp. 473-485, Publisher: Elsevier, actualmente disponible en Ia dirección de internet http://citeseer.ist.psu.edu/447658.html.
La tecnología multicast hace posible enviar datos desde una única fuente a muchos destinatarios a través de una red de datos, sin que sea necesario establecer una comunicación unicast, es decir una comunicación individual uno a uno entre Ia fuente y cada uno de los destinatarios. Para ello, Ia fuente envía datos, en forma de paquetes de datos, a una única dirección asociada a un grupo multicast al que pueden suscribirse los equipos interesados en ser destinatarios de dicha emisión de datos. Esta dirección, denominada dirección multicast o también dirección de grupo multicast, es una dirección IP (Internet Protocol) escogida dentro de un rango que está reservado para las aplicaciones multicast. Los paquetes de datos que han sido enviados por Ia fuente a Ia dirección multicast son entonces replicados en los diferentes routers de Ia red para que lleguen a los destinatarios que se han unido al grupo multicast.
Los mensajes intercambiados entre un dispositivo y el router más cercano para gestionar Ia pertenencia a un grupo multicast utilizan el protocolo IGMP (Internet Group Management Protocol) o bien el protocolo MLD (Multicast Listener Discovery), según si el router funciona con Ia versión 4 (IPv4) o con Ia versión 6 (IPv6) del protocolo IP (Internet Protocol), respectivamente.
Cuando hay un proxy entre el host y el router, el proxy también utiliza los protocolos IGMP/MLD para intercambiar con el host, el router más cercano u otro proxy intermedio los mensajes de pertenencia al grupo multicast. En estos casos, el proxy puede recibir de distintos hosts peticiones de suscripción o de baja a un grupo multicast, y las agrupa para reducir así el tráfico de mensajes IGMP/MLD que envía al router. En adelante, para designar a un proxy que utiliza los protocolos IGMP/MLD se utilizará el término genérico "proxy IGMP".
Por otra parte, los routers intercambian entre ellos unos mensajes con Ia finalidad de definir el ruteo que permita encaminar de forma eficiente los datos desde las fuentes hasta los dispositivos que se han suscrito a un grupo multicast. Para ello, los routers utilizan unos protocolos específicos, entre los cuales el más extendido es el PIM-SM (Protocol Independent Muticast - Sparse Mode).
Todos los protocolos mencionados están definidos y documentados por Ia Internet Engineering Task Forcé (IETF).
La versión del protocolo IGMP que se utiliza actualmente es Ia IGMPv3, que está descrita en las especificaciones RFC 3376 editadas en línea por Ia IETF (B. Cain et al., Engineering Task Forcé, Network Working Group, Request for Comments 3376, octubre de 2002; actualmente disponibles en Ia dirección Internet http://tools.ietf.org/html/rfc3376).
En cuanto al protocolo MLD, Ia versión que se utiliza actualmente es Ia MLDv2, que está descrita en las especificaciones RFC 3810 editadas en línea por Ia IETF (R. Vida et al., Engineering Task Forcé, Network Working Group, Request for Comments 3810, junio de 2004; actualmente disponibles en Ia dirección Internet http://tools.ietf.org/html/rfc3810).
El funcionamiento de un proxy IGMP está descrito en las especificaciones RFC 4605 editadas en línea por Ia IETF (B. Fenner et al., Engineering Task Forcé, Network Working Group, Request for Comments 4605, agosto de 2006; actualmente disponibles en Ia dirección Internet http://tools.ietf.org/html/rfc4605).
El protocolo PIM-SM utilizado para Ia comunicación entre los routers está descrito en las especificaciones RFC 4601 editadas en línea por Ia IETF (B. Fenner et al., Engineering
Task Forcé, Network Working Group, Request for Comments 4601 , agosto de 2006; actualmente disponibles en Ia dirección Internet http://tools.ietf.org/html/rfc4601 ).
Inicialmente, Ia tecnología multicast se implemento principalmente para aplicarla al modelo de comunicación muchos-a-muchos, conocido como ASM ("Any Source Multicast"), en el cual muchos usuarios se comunican entre sí y cualquiera de ellos puede emitir datos y también recibir datos de todos los demás. Una aplicación típica de ASM es Ia multiconferencia a través de Internet.
Posteriormente, Ia tecnología musticast se implemento para aplicarla al modelo de comunicación uno-a-muchos, conocido como SSM ("Source Specific Multicast"), en el cual una sola fuente emite datos para muchos destinatarios. La radio y Ia televisión a través de Internet son aplicaciones de SSM. Por esta razón, el SSM presenta actualmente un gran interés.
En las primeras versiones del protocolo IGMP un dispositivo no podía elegir las fuentes emisoras de datos a las que quería suscribirse dentro de un grupo multicast, si no que sólo podía suscribirse o darse de baja al grupo para todas las fuentes. Los mensajes que enviaba un dispositivo a un router eran muy sencillos: Join(G) para recibir tráfico del grupo multicast G y Leave (G) para dejar de recibirlo. Por Io tanto, las primeras versiones del protocolo IGMP no permitían el SSM ("Source Specific Multicast") en el cual los dispositivos eligen las fuentes emisoras de datos multicast.
Para permitir el SSM, en Ia versión IGMPv3 del protocolo IGMP se introdujo Ia posibilidad de que los dispositivos pudieran escoger las fuentes dentro de un grupo multicast. Para ello, un dispositivo puede enviar mensajes IGMP que contienen unos bloques de datos denominados "Group Record" en los cuales el dispositivo define las fuentes de las que desea recibir tráfico para cada grupo multicast. Estos bloques de datos "Goup Record" en un mensaje IGMP pueden ser de varios tipos:
Un bloque de datos "Group Record" de tipo INCLUDE, que contiene información sobre direcciones IP de las fuentes de las cuales el dispositivo sí desea recibir Ia emisión de datos. Siguiendo Ia terminología de las especificaciones RFC 3376, a las fuentes
elegidas mediante un mensaje IGMP que contiene un "Group Record" de tipo INCLUDE se las denomina fuentes INCLUDE.
Un bloque de datos "Group Record" de tipo EXCLUDE, que contiene información sobre direcciones IP de las fuentes de las cuales el dispositivo no desea recibir Ia emisión de datos. En este caso, se interpreta que el dispositivo desea recibir los datos emitidos por todas las fuentes de dicho grupo multicast menos las fuentes indicadas como excluidas en el mensaje. Siguiendo Ia terminología de las especificaciones RFC 3376, a las fuentes excluidas mediante un mensaje IGMP que contiene un "Group Record" de tipo EXCLUDE se las denomina fuentes EXCLUDE.
Para simplificar, en Io que sigue se utilizará el término "mensaje INCLUDE" para designar a un mensaje IGMP que contiene un "Group Record" de tipo INCLUDE, y el término "mensaje EXCLUDE" para designar a un mensaje IGMP que contiene un "Group Record" de tipo EXCLUDE.
Para ahorrar memoria, tráfico de datos o por otros motivos, en Ia versión IGMPv3 se decidió que cada interfaz de red podría funcionar para cada grupo multicast sólo en uno de los dos modos siguientes, pudiendo pasar de uno a otro: un modo INCLUDE en el cual Ia interfaz de red define una lista de fuentes INCLUDE o un modo EXCLUDE en el cual Ia interfaz de red define una lista de fuentes EXCLUDE.
Cada interfaz de red y grupo multicast tiene un registro de estado que almacena Ia información sobre dicha interfaz y grupo y dicho registro de estado contiene un campo denominado "filter-mode" que sólo puede ser de tipo INCLUDE, que contiene fuentes INCLUDE, o bien de tipo EXCLUDE, que contiene fuentes EXCLUDE. Cuando el registro de una interfaz de red debe resultar de Ia combinación de diferentes registros, se aplican las reglas que se transcriben a continuación:
Regla 1. Si alguna de las fuentes de datos de un grupo G1 es EXCLUDE, entonces Ia interfaz de red tendrá un "filter-mode" EXCLUDE para el grupo G1 y Ia lista de fuentes de Ia interfaz de red es Ia intersección de las listas de fuentes EXCLUDE menos las fuentes de Ia listas INCLUDE.
Regla 2. Si todas las fuentes son de tipo INCLUDE, entonces Ia interfaz de red tendrá un "filter-mode" INCLUDE para el grupo G1 y Ia lista de fuentes es Ia unión de todas las fuentes INCLUDE.
Estas reglas se aplican en una interfaz de red de un equipo que funciona como proxy IGMP y que recibe mensajes INCLUDE o mensajes EXCLUDE provenientes de diferentes hosts o bien de diferentes proxys IGMP situados del lado "downstream" de dicha interfaz de red (es decir en Ia dirección que va desde el router hacia los hosts) . Estas mismas reglas también se aplican en una interfaz de red de un equipo, como por ejemplo un ordenador personal, provista de varios "sockets" que reciben diferentes peticiones de fuentes INCLUDE o de fuentes EXCLUDE provenientes de diferentes aplicaciones.
En Io que sigue, y siguiendo Ia nomenclatura común en Ia tecnología SSM, se denomina canal (S, G) a Ia emisión de Ia fuente S del grupo multicast G.
En el estado de Ia técnica actual, para ahorrar memoria los routers que utilizan el protocolo IGMPv3 almacenan sólo Ia información mínima del tráfico multicast que deben transmitir. Esta información mínima consiste en almacenar, para cada interfaz de red del router y grupo multicast, un estado que refleja si para un determinado canal (S, G) o grupo multicast ( * ,G) hay como mínimo un host interesado en recibir dicho tráfico multicast.
Sumario de Ia invención
La invención tiene como finalidad principal proporcionar un sistema mejorado de gestión de dispositivos en una red de datos.
Un objetivo de Ia invención es reducir significativamente Ia complejidad de los sistemas en los dispositivos que son controlados.
Otro objetivo de Ia invención es reducir Ia memoria y Ia capacidad de procesamiento necesarios en dichos dispositivos para utilizar el presente sistema de monitorización y gestión de dispositivos.
Otro objetivo de Ia invención es reducir el consumo de ancho de banda que se produce en las redes de datos como consecuencia de Ia utilización de sistemas de gestión de dispositivos.
Con este fin, se ha desarrollado un procedimiento para monitorizar o gestionar equipos conectados a una red de datos caracterizado porque: dicha red de datos (150) dispone de una estación de control (100) que monitoriza o gestiona dichos equipos (1 10, 120,130), y; cada uno de dichos equipos puede estar en uno o en varios estados diferentes, y; - dichos equipos (1 10,120,130) envían mensajes en un protocolo de ruteo multicast para solicitar recibir tráfico multicast, y; dicho tráfico multicast solicitado consiste en grupos multicast y canales multicast que se corresponden con los estados de cada equipo, y; dicha estación de control (100) conoce el estado o los estados de cada equipo a partir de los grupos multicast y canales multicast solicitados por cada equipo.
La invención también contempla que: en dicha red de datos hay como mínimo un router multicast (220, 230) conectado a dichos equipos (240, 250, 260, 270, 280), y; - dichos equipos envían dichos mensajes en un protocolo de ruteo multicast a un dicho router multicast (220, 230), y; un router multicast (210, 220, 230) transmite dicha información de grupos multicast y canales multicast solicitados por cada equipo a dicha estación de control (200)
Preferentemente dicha estación de control (100, 200) envía como mínimo a uno de dichos equipos una información para configurar o modificar el estado de dicho equipo.
En una realización ventajosa, el router conectado a dichos equipos es un router IGMP.
En otra realización ventajosa, dicho router que transmite Ia información a dicha estación de control es un router PIM-SM.
La invención también se refiere al procedimiento según cualquiera de los procedimientos antes mencionados cuando dicho router multicast que transmite dicha información a dicha
estación de control incluye un agente SNMP y dicha información se almacena en una base de datos MIB y se transmite a Ia estación de control mediante el protocolo SNMP.
Preferentemente, dicho router IGMP almacena en unos registros asociados con el protocolo IGMP Ia información de los grupos y canales multicast solicitados por cada equipo asociando dichos grupos y canales multicast solicitados por cada equipo con un identificador de cada equipo.
En una realización preferente, dicho router IGMP almacena dicha información de grupos y canales multicast solicitados por cada equipo en una base de datos MIB.
En una forma de realización ventajosa, dicho router IGMP transmite dicha información almacenada en dicha base de datos MIB a Ia estación de control.
Preferentemente, dicho router IGMP transmite dicha información almacenada en dicha base de datos MIB utilizado el protocolo SNMP.
La invención también contempla una forma de realización en Ia cual un router PIM-SM que transmite Ia información a dicha estación de control es un router PIM-SM mejorado que almacena en unos registros asociados con el protoclo PIM-SM Ia información de los grupos y canales multicast solicitados por cada router multicast asociando dichos grupos y canales multicast con un identificador de cada router que Ie solicita dichos grupos y canales multicast.
Preferentemente dicho router PIM-SM almacena dicha información de grupos y canales multicast solicitados por cada router multicast en una base de datos MIB.
En una forma de realización ventajosa dicho router PIM-SM transmite información almacenada en dicha base de datos MIB a Ia estación de control.
Preferentemente dicho router PIM-SM transmite dicha información utilizado el protocolo SNMP.
La invención se refiere asimismo a unos equipos de red aptos para aplicar el procedimiento según Ia invención.
Breve descripción de los dibujos
Otras ventajas y características de Ia invención se aprecian a partir de Ia siguiente descripción en Ia que, sin ningún carácter limitativo, se relatan unas formas preferentes de realización de Ia invención haciendo mención de los dibujos que se acompañan.
La Fig. 1 muestra un ejemplo de una estación de control que monitoriza y gestiona dispositivos en el que Ia presente invención es aplicable.
La Fig. 2 muestra un ejemplo de Ia presente invención funcionando en una red de datos multicast donde hay routers IGMP y routers PIM-SM del estado de Ia técnica actual.
La Fig. 3 muestra un ejemplo de Ia presente invención funcionando en un sistema que utiliza también el protocolo SNMP.
La Fig 4 muestra un ejemplo simplificado de un sistema de comunicaciones multicast.
Descripción detallada de unas formas de realización de Ia invención
Primera forma de realización de Ia invención
La presente invención describe un nuevo procedimiento de gestión de dispositivos conectados en red desde una estación de control conectada a dicha red mediante un nuevo uso de los protocolos de ruteo multicast.
El nuevo procedimiento se caracteriza porque Ia estación de control conoce el estado de los dispositivos a partir de los grupos y canales multicast que ha solicitado recibir cada dispositivo. Es decir, Ia presente invención utiliza como medio de comunicación desde los dispositivos hacia Ia estación de control mensajes pertenecientes a protocolos de ruteo multicast.
En Ia presente invención unos dispositivos envían mensajes de protocolos de ruteo multicast que solicitan recibir un tráfico multicast a una estación de control que recibe Ia información de qué tráfico multicast ha solicitado cada dispositivo, pero dicha estación de control no necesita transmitir dicho tráfico multicast a los dispositivos porque Ia función de dichas solicitudes de tráfico multicast es transmitir a Ia estación de control una información del estado de cada dispositivo.
Los protocolos de ruteo multicast han sido pensados y diseñados para transmitir tráfico multicast y no para que unos dispositivos informen a una estación de control de cual es su estado y dicha estación de control conozca el estado de cada dispositivo a partir de los grupos y canales multicast que cada dispositivo solicita. Sin embargo, este nuevo uso de los protocolos multicast tiene algunas ventajas como reducir Ia complejidad en los sistemas de control que incorporan los dispositivos, reutilizar redes ya existentes y reducir el tráfico de gestión que circula por las redes.
En Ia presente descripción se utilizan los dos protocolos de ruteo multicast más extendidos en Ia actualidad: el protocolo IGMP para los mensajes de ruteo multicast host-router y el protocolo PIM-SM para los mensajes de ruteo multicast entre routers. Sin embargo, otros protocolos de ruteo multicast son igualmente aplicables.
En Io que sigue utilizaremos los términos "monitorizar" y "gestionar" de acuerdo con Ia siguiente explicación.
Diremos que Ia estación de control "monitoriza" un dispositivo cuando Ia estación de control recibe información de dicho dispositivo que Ie informa del estado del dispositivo pero Ia estación de control no envía información al dispositivo con Ia finalidad de configurarlo o modificar su estado. Durante un proceso de monitorización de un dispositivo, Ia estación de control también puede enviar información al dispositivo para que el dispositivo reciba una confirmación de que sus mensajes de solicitud de tráfico multicast han llegado a Ia estación de control. Sin embargo dicha información no se utiliza para configurar el dispositivo sino para informarle de que sus mensajes han llegado correctamente.
Diremos que Ia estación de control "gestiona" un dispositivo cuando Ia estación de control no sólo recibe información de dicho dispositivo sino que además Ia estación de control envía información al dispositivo con Ia finalidad de configurarlo o para que el dispositivo cambie de estado.
La figura 1 muestra un ejemplo de realización de Ia presente invención. En dicha figura hay tres dispositivos 110, 120 y 130 conectados a una red de datos multiacceso 150, por ejemplo ethernet.
Una estación de control 100 se haya conectada igualmente a dicha red 150. La dirección IP de dicho sistema de control 100 es IP100. El sistema de control 100 incluye un router IGMP 101 que se encarga de solicitar Ia información a los dispositivos de acuerdo con el procedimiento estándar del protocolo IGMPv3. El sistema de control 100 también dispone de varias interfaces de red 102, 103 y 104. La interfaz de red 102 está conectada a Ia red 150.
Dichos dispositivos incorporan un sistema que implementa Ia presente invención. Dicho sistema pueda ser implementado, por ejemplo, mediante un hardware especializado incluido en los dispositivos en comunicación con una tarjeta de red para permitir el acceso a Ia red multiacceso 150, que puede ser una red física que utilice cables o una red inalámbrica, como por ejemplo WIFI o WIMAX.
Los dispositivos de Ia figura 1 pueden ser cualquier tipo de dispositivos, pero en este ejemplo los dispositivos 1 10,120 y 130 son semáforos cuya utilidad es regular el tráfico de coches.
En dicho sistema se han definido varios estados con el objetivo de gestionar el correcto funcionamiento de los dispositivos. La siguiente tabla 1 explica los estados definidos, su significado, y el grupo multicast o canal multícast asociado a cada estado.
HOJA DE REEMPLAZO (Regla 26)
Estado Significado Grupo o Canal
0 El semáforo tiene todas sus luces apagadas Gi
1 El semáforo tiene encendida una luz de color verde (Si, G1)
2 El semáforo tiene encendida una luz de color naranja (Si, G2)
3 El semáforo tiene encendida una luz de color roja (Si, G3)
Los dispositivos 110, 120 y 130 de Ia figura 1 envían mensajes IGMPv3 a Ia estación de control 100. Dichos mensajes incluyen los grupos multicast y canales multicast correspondientes a los estados en los que se encuentra cada dispositivo. Gracias a estos mensajes, Ia estación de control 100 conoce el estado de cada dispositivo.
Un determinado dispositivo i (en Ia figura 1 , i puede ser 120, 130 o 140) puede enviar seis tipos de mensajes IGMP distintos de acuerdo con Ia presente invención: mensajes IGMP solicitando cuatro tipos de canales multicast y mensajes IGMP solicitando dos tipos de grupos multicast:
• Mensajes del tipo (Si , Gi), donde Ia fuente de datos Si y el grupo multicast Gi sólo son utilizados por el dispositivo i.
• Mensajes del tipo (Si , G1 ) donde Ia fuente de datos Si sólo es utilizada por el dispositivo i pero el grupo multicast G1 se utiliza por varios dispositivos.
• Mensajes del tipo (S1 ,G¡) donde Ia fuente S1 es utilizada por varios dispositivos pero el grupo Gi sólo es utilizado por el dispositivo i.
• Mensajes del tipo (S1 ,G7) donde tanto Ia fuente de datos S1 como el grupo G7 son utilizados por todos los dispositivos. • Mensajes del tipo Gi, donde el grupo multicast Gi sólo Io utiliza el dispositivo i.
HOJA DE REEMPLAZO (Regla 26)
• Mensajes del tipo G9, donde el grupo multicast G9 es utilizado por todos los dispositivos.
El tipo de mensajes que se utiliza para cada estado se puede elegir en función de los dispositivos y también en función de Ia red de datos multicast en Ia que están conectados los dispositivos. La correcta elección del tipo de mensaje permite que el sistema de control funcione de forma jerárquica en redes multicast que usan diferentes tipos de equipos multicast como routers PIM-SM, routers IGMP y Proxys IGMP.
En Ia tabla 1 , el estado 0 utiliza un grupo multicat Gi que es único para el dispositivo. Los dispositivos 1 10, 120 y 130 tienen asignados los grupos multicast G1 10, G120 y G130 respectivamente.
El concepto de unicidad se debe entender en el sentido del dominio de ruteo multicast. Por ejemplo, redes de datos no conectadas entre sí que pueden utilizar el mismo Gi, ya que aunque sea el mismo grupo multicast, es único en cada red.
En los estados 1 a 6, Ia fuente Si del canal multicast es distinta para cada dispositivo. Los dispositivos 110, 120 y 130 tienen asignados las fuentes de datos multicast S1 10, S120 y S130 respectivamente.
En el estado 7 se utiliza el canal multicast (S1 , G7), donde tanto Ia fuente S1 como el grupo multicast G7 son los mismos en todos los dispositivos.
En el estado 8 todos los dispositivos utilizan el mismo canal multicast (S1 ,G8), donde S1 es una dirección IP de Ia red de datos elegida de tal forma que las solicitudes de tráfico multicast lleguen siempre a Ia estación de control.
En el estado 9 cada dispositivo tiene asignado un grupo multicast G9 común para todos los dispositivos y un canal multicast (IP100,Gi) donde IP 100 es Ia dirección IP de Ia estación de control 100 y es por Io tanto común a todos los dispositivos y Gi es diferente en cada dispositivo. Los dispositivos 1 10, 120 y 130 tienen asignados los grupos multicast G1 10, G120 y G130 respectivamente.
En los estados 0 a 8 Ia explicación de Ia tabla 1 es suficiente para su comprensión. El estado 9 Io utilizan los dispositivos para indicar al sistema de gestión 100 que el dispositivo incorpora Ia presente invención y que está funcionando correctamente. Por Io tanto los dispositivos que ejecutan Ia presente invención siempre solicitan recibir el canal multicast (IP100,Gi) y el grupo multicast G9 cuando funcionan correctamente.
Esta propiedad puede ser utilizada por el sistema de control 100 para enviar datos a todos los dispositivos o a un único dispositivo concreto. El sistema de control 100 puede enviar datos individualizados a unos dispositivos 1 10, 120 o 130 enviando paquetes IP mediante los canales multicast (IP100.G110), (IP100, G120) y (IP100, G130) respectivamente.
Si el sistema de control desea enviar datos a todos los dispositivos de Ia red 150, por ejemplo una nueva tabla 1 , puede enviar paquetes IP usando el grupo multicast G9 como dirección IP de destino de los paquetes IP. Esto es igualmente aplicable a una red con miles o millones de dispositivos y supone un ahorro de tráfico de datos en Ia red ya que el sistema de control sólo tiene que enviar los paquetes multicast una sola vez independientemente del número de dispositivos que estén conectados a Ia red 150.
Sin embargo, de acuerdo con las anteriores definiciones de monitorizar y gestionar, en un sistema de control que sólo monitorice los dispositivos no es necesario el envío de paquetes desde Ia estación de control hacia los dispositivos monitorizados. Dicho envío de información es necesario cuando Ia estación de control desea gestionar los dispositivos, por ejemplo para actualizar su configuración.
En Ia tabla de estados hay unos estados que son incompatibles entre sí y otros que son compatibles entre sí. Por ejemplo el estado 0, todas las luces apagadas, es incompatible con los estados 1 , 2 y 3. Sin embargo los estados 1 y 5 son compatibles ya que un dispositivo puede tener al mismo tiempo ambos estados, es decir Ia luz verde encendida y Ia luz naranja estropeada.
Gracias a Ia asignación de grupos y canales multicast que se corresponden con los diferentes estados de un dispositivo, Ia presente invención permite monitorizar y gestionar dispositivos conectados en red de una forma mucho más sencilla que Ia utilizada en el protocolo SNMP.
También es posible que un dispositivo quiera recibir un tráfico multicast (Sx, Gy) por medio de Ia red de datos, por ejemplo para recibir una tabla de configuración necesaria para el funcionamiento dispositivo, o por cualquier otro motivo. En este caso Ia estación de control conoce que el dispositivo quiere recibir el canal multicast (Sx 1 Gy) que no se corresponde con ninguno de los estados definidos en Ia tabla 1 de dicho dispositivo y deja que los procedimientos de ruteo multicast de Ia red de datos hagan llegar el canal multicast (Sx 1 Gy) de Ia fuente Sx a dicho dispositivo. Aún así, Ia estación de control está monitorizando también este tráfico multicast que recibe el dispositivo. Si el router IGMP 101 implementado en Ia estación de control es el "Designated Router", en el sentido utilizado en las especificaciones IGMPv3, en Ia red 150, entonces el propio router 101 transmite el tráfico multicast (Sx 1 Gy).
El protocolo IGMPv3 es un protocolo sencillo y se puede implementar en un dispositivo Ia funcionalidad necesaria para enviar mensajes IGMPv3 con pocas líneas de código adicionales a las necesarias para implementar el protocolo IP. El protocolo IP es necesario porque los mensajes IGMPv3 se encapsulan en paquetes IP.
La figura 2 muestra un ejemplo de Ia presente invención funcionando en una red de datos multicast donde hay routers IGMP y routers PIM-SM del estado de Ia técnica actual.
En Ia figura 2 hay una serie de dispositivos de red que son monitorizados y gestionados desde una estación de control 200 que implementa Ia presente invención y que está conectada a Ia red 205 mediante una interfaz de red 201.
Un router multicast 210 utiliza el protocolo PIM-SM y se comunica con Ia estación de control 200 mediante su interfaz de red 211 conectada a Ia red 205. Dicho router multicast 210 dispone de otras dos interfaces de red 212 y 213 mediante las cuales se conecta con los routers 220 y 230 respectivamente.
Los routers 220 y 230 son routers multicast que utilizan el protocolo PIM-SM en sus comunicaciones con el router 210 y utilizan el protocolo IGMPv3 en sus comunicaciones con los dispositivos 240, 250, 260, 270 y 280.
Los dispositivos 240, 250 y 260 están conectados a una red multiacceso 245, por ejemplo una red ethernet, que a su vez está conectada a una interfaz de red del router 220. Dichos dispositivos envían solicitudes de tráfico multicast utilizando mensajes IGMPv3 a Ia interfaz de red 222 del router multicast 220 a través de Ia red 245. Otro dispositivo 270 está conectado a otra interfaz de red 223 del router 220 mediante Ia red 275.
El dispositivo 280 está conectado a Ia interfaz de red 233 del router 230 mediante Ia red 285.
Los dispositivos 240, 250, 260, 270 y 280 implementan Ia presente invención y transmiten su estado a Ia estación de control 200 enviando solicitudes de tráfico multicast en el protocolo IGMPv3.
Los routers 220 y 230 reciben dichas solicitudes de tráfico multicast en el protocolo IGMPv3 y las envían al router 210 utilizando el protocolo PIM-SM.
El router 210 transmite las peticiones de tráfico multicast a Ia estación de control 200 utilizando el protocolo PIM-SM y de esta forma Ia estación de control 200 conoce el estado de cada dispositivo a partir de los grupos y canales multicast que cada dispositivo ha solicitado recibir.
Segunda forma de realización de Ia invención
Aunque Ia presente invención puede funcionar sin necesidad del protocolo SNMP, dicho protocolo está ampliamente extendido y es el estándar que se utiliza actualmente para gestionar dispositivos de red.
Por ello es interesante que Ia presente invención se pueda integrar en una red de datos que utiliza el protocolo SNMP, especialmente en Ia parte de Ia red en contacto con dispositivos finales como ordenadores, teléfonos móviles, PDAs o cualquier otro dispositivo conectado a Ia red de datos.
La figura 3 muestra un ejemplo de Ia presente invención funcionando en una red que utiliza el protocolo SNMP.
Normalmente, para hacer compatible un nuevo protocolo de control con un sistema de control SNMP se suelen utilizar unos sistemas denominados "Proxys SNMP". La función de un Proxy SNMP es hacer de intermediario entre Ia estación de control que utiliza el sistema de gestión SNMP y el nuevo dispositivo que utiliza un protocolo de control distinto o propio. Para ello los diferentes mensajes y datos del nuevo protocolo de control deben convertirse a mensajes SNMP y viceversa, es decir, los mensajes y datos del protocolo SNMP deben también convertirse al sistema de control propio del dispositivo.
La presente invención también puede adaptar su funcionamiento a un sistema SNMP mediante un Proxy SNMP. Los Proxys SNMP son conocidos por un experto en Ia materia y no profundizaremos más en su explicación.
Sin embargo, hay otra forma de integrar Ia presente invención en un sistema de gestión de redes que utiliza el protocolo SNMP sin necesidad de crear un Proxy SNMP. Esto se consigue utilizando los agentes SNMP de los routers multicast. Tanto los routers multicast IGMPv3 como los routers multicast PIM-SM del estado de Ia técnica actual suelen disponer de agentes SNMP.
El funcionamiento de un agente SNMP para routers IGMP está descrito en el documento "Multicast Group Membership Discovery MIB" editado en línea por Ia IETF (J. Chesterfield et al., Internet Engineering Task Forcé, Magma Working Group, Request for Comments 4601 , diciembre de 2007; actualmente disponible en Ia dirección Internet http://www.ietf.org/internet-drafts/draft-ietf-magma-mgmd-mi b-1 1.txt).
El funcionamiento de un agente SNMP para routers PIM-SM está descrito en el documento "Protocol Independent Multicast MIB draft-ietf-pim-mib-v2-10.txt" editado en línea por Ia IETF ( R. Sivaramu et al., Internet Engineering Task Forcé, PIM Working Group, septiembre de 2007, actualmente disponible en línea en Ia dirección de Internet ftp://ftp.rfc- editor.org/in-notes/internet-drafts/draft-ietf-pim-mib-v2-10 .txt).
La presente invención utiliza agentes SNMP para almacenar Ia información del estado de los dispositivos, en forma de grupos y canales mutlicast solicitados por cada dispositivo, y
transmitir dicha información mediante el protocolo SNMP a Ia estación de control SNMP o "SNMP manager". La figura 3 ilustra dicho funcionamiento.
En Ia figura 3 hay una estación de control SNMP 300 que se comunica mediante el protocolo SNMP con un router PIM-SM 310 y dos routers IGMP 320 y 330. La comunicación entre Ia estación de control 300 y el router PIM-SM tiene lugar por medio de Ia red 315. La comunicación entre Ia estación de control 300 y los dos routers IGMP 320 y 330 tiene lugar mediante las redes 305 y 335 respectivamente.
El router PIM-SM se comunica con los dos routers IGMP 320 y 330 mediante una red multiacceso 345 utilizando el protocolo PIM-SM.
El router 310 dispone de un agente SNMP 316 que incluye una base de datos MIB 317 que almacena información relativa al protocolo PIM-SM. Una fuente de tráfico multicast 318 está conectada al router PIM-SM 310 por medio de su interfaz de red 312 y puede transmitir tráfico multicast a Ia red de datos.
Los dos routers 320 y 330 disponen de agentes SNMP 326 y 336 respectivamente. Cada uno de estos agentes SNMP almacena información relativa al protocolo IGMP en su base de datos MIB 327 y 337 respectivamente.
El router IGMP 330 se comunica con un Proxy IGMP 340, que a su vez dispone de un agente SNMP 346 que almacena información relativa al protocolo IGMP en una base de datos MIB 347. Dicho Proxy IGMP 340 está en comunicación con dos dispositivos 380 y 390 que Ie informan de su estado mediante mensajes IGMP que solicitan recibir grupos multicast y canales multicast tal como se ha explicado anteriormente. El Proxy IGMP 340 agrupa Ia información de los grupos y canales multicast solicitados por los dispositivos 380 y 390 y envía unos mensajes IGMP al router 330 con Ia información agrupada tal como establecen las especificaciones RFC 4605.
El router IGMP 320 se comunica con tres dispositivos 350, 360 y 370 mediante una red multiacceso 325. Dichos dispositivos informan de su estado enviando mensajes IGMP al router 320 en los cuales solicitan grupos multicast y canales multicast.
La información del estado de los dispositivos 350, 360 y 370 puede llegar a Ia estación de control SNMP 300 por medio del agente SNMP 326 del router 320 o por medio del agente 316 del router 310. Esto permite establecer un control de los dispositivos que solicitan grupos multicast y canales multicast de forma jerárquica, permitiendo un control distribuido de los dispositivos de Ia red. Esta es otra ventaja de Ia presente invención que utiliza el propio árbol de comunicaciones multicast para establecer este control jerárquico.
De forma similar, Ia información del estado de los dispositivos 380 y 390 puede llegar a Ia estación de control SNMP 300 por medio del agente SNMP 346 del Proxy IGMP 340, por medio del agente SNMP 336 del router IGMP 330 o por medio del agente SNMP 316 del router PIM-SM 310. Esto permite a Ia estación de control 300 controlar los dispositivos 380 y 390 desde cualquiera de estos tres niveles de Ia red.
La estación de control SNMP 300 incorpora una aplicación que permite mostrar el estado de cada dispositivo a partir de Ia información de los grupos multicast y canales multicast solicitados por cada dispositivo.
La figura 3 también muestra una fuente de datos multicast 318 conectada al router PIM-SM 310. Si alguno de los dispositivos 350, 360, 370, 380 o 390 envía mensajes IGMP para recibir tráfico multicast de Ia fuente 318, el sistema descrito también permite monitorizar dicho tráfico multicast solicitado por los dispositivos.
De forma similar a Io explicado en Ia primera forma de realización, Ia estación de control puede enviar paquetes IP de datos multicast a un único dispositivo, utilizando un canal multicast que sólo ha solicitado dicho dispositivo, o a todos los dispositivos, utilizando un grupo multicast que han solicitado todos los dispositivos. Estos paquetes IP de datos pueden contener, por ejemplo, información para configurar los dispositivos, información para que los dispositivos sepan a qué router deben enviar los mensajes IGMP o cualquier otra información que sea útil a los dispositivos.
Tercera forma de realización de Ia invención
El funcionamiento del sistema de Ia figura 3 puede presentar sin embargo varios problemas debido a Ia forma en que están definidos los protoclos IGMPv3 y PIM-SM en el estado de Ia
técnica actual. Esta puede ser una causa por Ia que no se esté utilizando Ia tecnología multicast para el control de dispositivos en red.
Un primer problema en Ia figura 3 es que exista en Ia red 325 algún dispositivo que solicite tráfico multicast de alguno de los grupos multicast utilizados en los dispositivos mediante mensajes IGMP de tipo EXCLUDE para un determinado grupo multicast. En este caso, de acuerdo con el protocolo IGMPv3, se pierde en el router 320 Ia información de todos los canales multicast asociados a dicho grupo multicast solicitados por los dispositivos y Ia información del estado de los dispositivos no llega a Ia estación de control.
Por ejemplo, si el dispositivo 350 envía un mensaje IGMPv3- de tipo EXCLUDE ({},G5), de acuerdo con el protocolo IGMPv3, el router IGMP sólo almacena Ia petición del grupo multicast G5 y no almacena ninguna petición de canales multicast correspondiente al grupo G5 y por Io tanto se pierde Ia información de los canales multicast del grupo G5 solicitados por los dispositivos 360 y 370 y dicha información no llega a Ia estación de control.
El dispositivo 350 que envía el mensaje IGMP de tipo EXCLUDE puede ser un dispositivo que no implementa Ia presente invención. También puede suceder que el dispositivo 350 tenga algún virus u otro tipo de software que pretende interferir en el correcto funcionamiento de los dispositivos 360 y 370
Para evitar este problema es conveniente separar en los routers 320 y 330 las peticiones IGMPv3 de tipo INCLUDE y las peticiones IGMPv3 de tipo EXCLUDE. La solicitud de patente española número 200701 1775 presentada por el solicitante el 26 de junio de 2007 y titulada "Procedimiento de gestión de tráfico multicast en una red de datos y dispositivos que utilizan dicho procedimiento" describe un router IGMPv3 que separa los mensajes INCLUDE y los mensajes EXCLUDE y puede aplicarse para resolver este problema.
Aplicando dicho procedimiento a los routers 320 y 330 de esta tercera forma de realización, se elimina dicho problema.
Un segundo problema relativo al protocolo IGMPv3 es que los routers IGMP no almacenan Ia información del tráfico multicast solicitado por cada equipo. Si hay varios dispositivos que solicitan el mismo grupo multicast, por ejemplo el grupo G9 para transmitir el estado 9 en Ia
tabla 1 del semáforo del ejemplo anterior, o varios dispositivos que solicitan el mismo canal multicast, por ejemplo el canal multicast (S1 ,G8) para transmitir Ia información del estado 8 de dicha tablai , el router IGMP sólo almacena en cada interfaz de red si debe transmitir o no dicho tráfico, pero no almacena qué dispositivos han solicitado dicho tráfico. Esto puede suceder, por ejemplo, en los dispositivos 350, 360 y 370 de Ia figura 3 que están conectados a Ia misma interfaz de red 323 del router IGMP 320 mediante una red multiacceso, como por ejemplo una red ethernet.
Un problema similar al explicado en las redes multiacceso que conectan hosts con routers o routers con routers sucede cuando dichos equipos se comunican mediante un switch, ya que el switch es un equipo de nivel 2 que no sabe a qué puertos debe enviar los paquetes IP multicast y, por defecto, envía los paquetes multicast a todos los puertos.
Para evitar este problema, los routers IGMP 320 y 330 de Ia presente invención almacenan de forma separada Ia información del tráfico multicast solicitada por cada dispositivo.
Una primera forma de almacenar dicho tráfico multicast solicitado por cada dispositivo es hacerlo directamente en Ia base de datos MIB del agente SNMP del router IGMP y no tener en cuenta dicha información en el funcionamiento del router IGMP y en sus comunicaciones con los dispositivos que Ie envían mensajes IGMP solicitando tráfico multicast. Esta implementación es posible pero no es óptima.
Una segunda forma especialmente ventajosa de que los routers IGMP almacenen Ia información del tráfico multicast que solicita cada dispositivo es que Io hagan en los propios registros que utilizan para el ruteo IGMPv3. Esto tiene Ia ventaja de optimizar el funcionamiento del router IGMP, reduciendo Ia latencia y eliminando mensajes IGMP innecesarios.
La solicitud de patente española número 200702687 presentada por el solicitante el 15 de octubre de 2007 que tiene por título "Procedimiento de gestión de tráfico multicast en una red de datos y equipos de red que utilizan dicho procedimiento" resumida más adelante, describe un router IGMP mejorado que almacena Ia información del tráfico multicast solicitado por cada dispositivo y dicho funcionamiento de un router IGMP mejorado puede aplicarse a Ia presente invención para almacenar Ia información del tráfico multicast que
solicita cada dispositivo. Para que el agente SNMP puede enviar dicha información, sólo es necesario que además de guardar dicha información en los registros de ruteo, el router IGMP Ia almacene también en Ia base de datos MIB mejorada del agente SNMP del router mejorado.
La descripción de Ia base de datos MIB del router IGMP mejorado que almacena Ia información del tráfico multicast solicitado por cada dispositivo está al alcance de un experto en Ia materia que conozca el lenguaje SMIv2 ("Structure for Management Information") y no profundizaremos más en su explicación.
De esta forma, los routers IGMP 320 y 330 de Ia figura 3 son routers mejorados que almacenan el tráfico multicast solicitado por cada dispositivo y dicha información se almacena en Ia base de datos MIB del agente SNMP de cada router. Lo mismo sucede con el Proxy IGMP 340.
Un problema similar ocurre con el protocolo PIM-SM. En Ia figura 3 el router 310 se comunica con los routers 320 y 330 utilizando el protocolo PIM-SM en una red multiacceso 345. El protocolo PIM-SM del estado de Ia técnica tampoco almacena Ia información del tráfico solicitado por cada router PIM-SM y sólo almacena si debe transmitir o no un determinado tráfico por una deteminad interfaz de red del router. En Ia figura 3 este problema se presenta en Ia red multiacceso 345.
De Ia misma forma que con el protocolo IGMP, un router PIM-SM puede almacenar Ia información del tráfico solicitado por cada router de dos formas distintas: una primera forma poco óptima es hacerlo directamente en Ia base de datos MIB del agente SNMP y una segunda forma es almacenar dicha información en los registros de ruteo PIM-SM para optimizar el funcionamiento del router PIM-SM. En este segundo caso sólo es necesario que también se incluya dicha información en las base de datos MIB del agente SNMP del router PIM-SM.
La solicitud de patente española número 200702849 presentada por el solicitante el 30 de octubre de 2007, titulada "Procedimiento de gestión de tráfico multicast entre routers que se comunican mediante un protocolo que integra el protocolo PIM; y router y switch que intervienen en dicho procedimiento" y resumida más adelante, describe el funcionamiento
de un router PIM-SM mejorado que almacena Ia información del tráfico multicast que Ie solicita cada router PIM-SM y puede aplicarse a Ia presente invención.
De esta forma, el router PIM-SM 310 de Ia figura 3 es un router PIM-SM mejorado que almacena el tráfico multicast solicitado por cada router 320 y 330 en Ia red multiacceso 345 y dicha información se almacena también en Ia base de datos MIB del agente SNMP de cada router.
La descripción de Ia base de datos MIB del router PIM-SM mejorado que almacena Ia información del tráfico multicast solicitado por cada dispositivo está al alcance de un experto en Ia materia que conozca el lenguaje SMIv2 ("Structure for Management Information") y no profundizaremos más en su explicación.
También, de forma similar a Io explicado en Ia segunda forma de realización, si alguno de los dispositivos 350, 360, 370, 380 o 390 envía mensajes IGMP para recibir tráfico multicast de Ia fuente 318, Ia presente invención permite monitorizar dicho tráfico multicast solicitado por los dispositivos.
A continuación se muestra de forma resumida Ia información más relevante para Ia presente invención de las solicitudes de patentes españolas 2007011775, 200702687 y 200702849 que son incorporadas aquí por referencia.
Resumen de Ia patente española 200702687.
En el siguiente resumen, Ia palabra invención se refiere a Ia invención descrita en Ia solicitud de patente 200702687.
La segunda forma de realización de Ia solicitud de patente española 200702687 describe las principales características de Ia solicitud de patente española 200701775 por Io que se considera que Ia presente explicación es suficiente para entender Ia separación de registros INCLUDE y EXCLUDE.
1. Funcionamiento de un equipo de red perteneciente al estado de Ia técnica anterior que utiliza el protocolo IGMPv3 .
Para poner de relieve las características y ventajas de Ia invención, se expone en primer lugar el funcionamiento de un equipo de red que aplica el protocolo IGMPv3 de acuerdo con el estado de Ia técnica.
Para explicar Ia forma de agrupar los mensajes en un proxy que utiliza el protocolo IGMPv3, las especificaciones RFC 4605 que definen el funcionamiento del proxy IGMP se remiten al apartado 3.2 de las RFC 3376 que definen el protocolo IGMPv3. Las reglas son las mismas para deducir el estado de una interfaz de red de un host a partir de varios registros. A continuación se reproducen estas reglas adaptadas al funcionamiento en un proxy IGMP :
Regla 1. Para una determinada interfaz de red y grupo multicast, si alguna de las fuentes de datos de los mensajes recibidos del grupo es EXCLUDE, entonces se envía un mensaje de tipo EXCLUDE para el grupo y Ia lista de fuentes del mensaje es Ia intersección de las listas de fuentes EXCLUDE menos las fuentes de los mensajes INCLUDE.
Regla 2. Para una determinada interfaz de red y grupo multicast, si todas las fuentes de datos de los mensajes recibidos del grupo son de tipo INCLUDE, entonces se envía un mensaje de tipo INCLUDE para el grupo y Ia lista de fuentes de Ia interfaz de red es Ia unión de todas las fuentes INCLUDE.
Por Io tanto, el método que aplica un proxy IGMP consiste en agrupar las fuentes de los diferentes mensajes de cada grupo multicast recibidos en cada interfaz de red del proxy sin tener en cuenta cual es el host que envía el mensaje: el proxy almacena en qué interfaz de red ha recibido el mensaje IGMP, pero no almacena Ia identificación del host que ha solicitado cada fuente.
Lo mismo sucede en un router IGMP, cuyo funcionamiento se explica en el apartado 6 de las RFC 3376. Para cada interfaz de red del router IGMP y para cada grupo multicast, el router IGMP almacena Ia información de los canales y grupos multicast solicitados pero no almacena Ia identificación del host que solicita cada canal o cada grupo multicast.
Los routers IGMP envían periódicamente a los hosts unos mensajes denominados "Membership Query", para que los hosts contesten informando de los grupos y fuentes de los que desean recibir tráfico multicast. Los hosts también pueden enviar mensajes al router para solicitar tráfico multicast sin esperar a que el router IGMP envíe un mensaje "Membership Query".
Los routers IGMP ejecutan el protocolo IGMP en todas las redes a las que están directamente conectados. Si un router IGMP tiene más de una interfaz de red conectada a Ia misma red sólo necesita ejecutar el protocolo en una de dichas interfaces de red.
Para cada tarjeta de red o interfaz de red, y para cada grupo multicast los routers IGMP almacenan Ia información de las fuentes INCLUDE y EXCLUDE multicast en un registro:
Registro : (multicast-address, group-timer, filter-mode, {(source-address, source-timer)})
donde
"multicast-address" es el grupo multicast.
{(source-address, source-timer)} es una lista de elementos (source-address, source-timer), siendo "source-address" Ia dirección IP de una fuente y siendo "source-timer" un timer asociado a dicha fuente.
"filter-mode" puede ser INCLUDE o EXCLUDE y tiene el mismo funcionamiento que el que se describe en las RFC 3376: indicar si las fuentes de Ia lista de fuentes y timers son fuentes INCLUDE o fuentes EXCLUDE.
"group-timer" es un timer que se utiliza como mecanismo para Ia transición del "filter-mode" de un registro de estado del router del modo EXCLUDE al modo INCLUDE. Cuando el "group-timer" de un determinado grupo multicast e interfaz de red llega a cero, el router asume que ya no quedan hosts con "filter-mode" EXCLUDE conectados a dicha interfaz de red y cambia al modo INCLUDE.
El valor de los timers va disminuyendo con el tiempo y cuando el router recibe de un host un mensaje "Membership Report" reinicializa los timers que correspondan.
Si el registro tiene un filter-mode INCLUDE los timers funcionan de Ia manera siguiente: para una determinada interfaz de red, un determinado grupo multicast y una determinada fuente incluida "source-address", mientras el "source-timer" sea mayor que cero el router continuará transmitiendo por dicha interfaz de red el tráfico multicast del canal (fuente, grupo multicast); cuando el "source-timer" llegue a cero, el router dejará de transmitir dicho tráfico y eliminará Ia fuente de Ia lista de fuentes INCLUDE de ese grupo multicast.
Si el registro tiene un filter-mode EXCLUDE los timers funcionan de forma parecida, pero con Ia diferencia de que las fuentes EXCLUDE se clasifican en dos listas: una primera lista denominada "Requested List" que contiene las fuentes cuyo timer "source-timer" tiene un valor mayor que cero y una segunda lista denominada εxclude List" que contiene las fuentes cuyo timer "source-timer" tiene valor cero.
Si un registro tiene un filter-mode EXCLUDE para un determinado grupo multicast, el router transmite todo el tráfico de todas las fuentes de dicho grupo multicast excepto las fuentes EXCLUDE de Ia lista "Exelude List".
El router utiliza también los timers para asegurarse de que, tras haber enviado un mensaje "Group Specific Query" o un mensaje "Group and Source Specific Query", todos los hosts han tenido tiempo suficiente para contestar a dicho mensaje.
Hay varios motivos para que exista una lista "Requested List" en IGMPv3. Uno de ellos es que en una red con varios hosts enviando mensajes a un router IGMP, puede darse el caso de que haya un conflicto entre las peticiones de los diferentes hosts. Esto sucede, por ejemplo, cuando un host solicita tráfico de una determinada fuente y otro host solicita tráfico excluyendo dicha fuente. Por ejemplo, un host H1 envía un primer mensaje EXCLUDE({S1},G1 ) y otro host H2 en Ia misma red ethernet envía después al mismo router un segundo mensaje EXCLUDE({S1 ,S2,S3},G1 ). Si el router, al recibir el segundo mensaje pusiera las fuentes del segundo mensaje {S1 ,S2,S3} en Ia lista "Exelude List", el host H1 dejaría de recibir el tráfico de las fuentes S2 y S3 que sí quería recibir ya que quería recibir todo el tráfico menos el de Ia fuente S1. Para evitar este problema, el router IGMP pone
únicamente en Ia lista "Exelude List" Ia intersección del conjunto de fuentes del nuevo mensaje con el conjunto de fuentes que había en Ia lista "Exelude List" antes de recibir dicho mensaje. El resto de fuentes EXCLUDE pasan a Ia lista "Requested List" y, opcionalmente, el router envía un mensaje "Group-And-Source Specific Query" a los hosts para preguntar si hay algún host que todavía esté interesado en recibir el tráfico de las fuentes S2 y S3 del grupo G1
La Tabla 2 (al final del presente documento), extraída de las RFC 3376, resume el funcionamiento de un router según el protocolo IGMPv3.
En Ia Tabla 2, Ia primera columna "Estado 1 " muestra el estado inicial del registro del router IGMP; Ia segunda columna "Mensaje" muestra el contenido de un mensaje "Membership Report" recibido por el router IGMP; Ia tercera columna "Estado 2" muestra el estado de dicho registro del router IGMP tras haber recibido el mensaje "Membership Report"; Ia cuarta y última columna "Acciones" muestra las acciones que el router IGMP realiza tras haber recibido dicho mensaje "Membership Report". La Tabla 2 contiene 12 filas que corresponden respectivamente a 12 ejemplos que ilustran cada uno el funcionamiento del router según su estado inicial (columna 1 ) y según los mensajes que ha recibido (columna 2). Cada fila de Ia Tabla 2 está separada de otra fila por una línea punteada.
La Tabla 2 se refiere a una determinada interfaz de red del router IGMP que ejecuta el protocolo IGMPv3 y un determinado grupo multicast G. Cada interfaz de red y grupo multicast G tendrá sus propios registros de estado que se verán afectados por los mensajes que reciba el router IGMP por dicha interfaz de red referidos a dicho grupo G.
En Ia Tabla 2 se ha utilizado Ia nomenclatura siguiente:
(A+B) significa Ia unión de los conjuntos de fuentes A y B.
(A * B) significa Ia intersección de los conjuntos de fuentes A y B.
(A-B) significa el conjunto de fuentes A menos las fuentes de A que también se encuentran en B.
INCLUDE (A), indica que el router IGMP tiene un registro con "filter-mode" INCLUDE con un conjunto de fuentes A.
EXCLUDE (X,Y) indica que el router IGMP tiene un registro con "filter-mode" EXCLUDE porque hay fuentes EXCLUDE, siendo:
X Ia lista "Requested List" de fuentes EXCLUDE Y Ia lista "Exclude List" de fuentes EXCLUDE
GMI es un parámetro denominado "Group Membership Interval" que contiene un valor de tiempo. Por defecto, toma un valor de 260 segundos.
T (S) es el timer "source timer" de Ia fuente S.
GT es el "Group Timer", es decir el timer del registro para cambiar de modo EXCLUDE a modo INCLUDE.
SEND Q(G, S) significa que el router IGMP envía un mensaje "Group-And-Source specific Query" a los host para comprobar si todavía hay algún host interesado en recibir las emisiones de las fuentes S del grupo multicast G. Cuando realiza esta acción, el router IGMP también reduce los timers de las fuentes S al valor LMQT. Si el router IGMP recibe en respuesta un mensaje mostrando interés en alguna de las fuentes S, entonces inicializa el valor de los timers de dichas fuentes, para las que hay un host interesado, a un valor inicial igual a GMI.
DEL(A) significa que el router IGMP suprime del registro las fuentes de Ia lista A.
LMQT es un parámetro denominado "Last Member Query Time" que contiene un valor de tiempo. Es el tiempo que tiene un host para contestar a un mensaje del tipo "Group-And- Source Specific Query" enviado por el router IGMP. Pasado este tiempo, si ningún host contesta que tiene interés en recibir los canales especificados en dicho mensaje, el router IGMP deja de transmitirlos. El valor por defecto de LMQT en el protocolo IGMPv3 es 20 segundos.
Los mensajes que aparecen en Ia columna 2 de Ia Tabla 2 son los seis tipos de mensajes IGMP definidos en el protocolo IGMPv3 para indicar al router las fuentes de las que se desea obtener tráfico multicast. El significado de estos seis mensajes IGMP está descrito en las RFC 3376 (capítulo 4.2.12) y es el siguiente:
ISJN (Z), IS_EX (Z) indican que Ia interfaz de red del host que ha enviado el mensaje tiene un "filter-mode" INCLUDE o bien EXCLUDE, respectivamente, para las fuentes de Ia lista Z.
TCHN (Z), TO_EX (Z) indican que Ia interfaz de red del host que ha enviado el mensaje ha pasado el "filter-mode" de modo EXCLUDE a modo INCLUDE, o bien de modo INCLUDE a modo EXCLUDE, respectivamente, para las fuentes de Ia lista Z.
ALLOW (Z) indica que Ia interfaz de red del host que ha enviado el mensaje desea recibir el tráfico de las nuevas fuentes de Ia lista Z. Estas fuentes son las que dicha interfaz de red añadirá a su lista de fuentes INCLUDE o bien las que suprimirá de su lista de fuentes EXCLUDE.
BLOCK (Z) indica que Ia interfaz de red del host que ha enviado el mensaje ya no desea recibir el tráfico de las fuentes de Ia lista Z. Estas fuentes son las que dicha interfaz de red suprimirá de su lista de fuentes INCLUDE o bien las que añadirá a su lista de fuentes EXCLUDE.
Se observará que las 12 filas de Ia Tabla 2 corresponden a las 12 posibles combinaciones de un registro de estado inicial del router (columna 1 ) y de un tipo de mensaje IGMP recibido (columna 2).
El router siempre consulta a los hosts mediante un mensaje "Group-And-Source-Specific- Query" (mensajes SEND en Ia columna 4 de Ia Tabla 2) para comprobar si hay algún host interesado en recibir aquellas fuentes cuyo tráfico se estaba transmitiendo inicialmente (columna 1 de Ia Tabla 2) y ya no se desea recibir según las fuentes indicadas en el último mensaje IGMPv3 recibido (columna 2 de Ia Tabla 2). Este funcionamiento es ineficiente, porque se envían mensajes de tipo "Group-And-Source-Specific-Query" innecesarios y, además, se transmite tráfico de fuentes que ningún host desea ya recibir. Además,
gestionar estas situaciones en los doce casos de Ia Tabla 2 supone una gran complejidad técnica.
Por otra parte, es usual que los usuarios de un sistema multicast, que actúan a través de los hosts, tengan un comportamiento conocido como "zapping", que consiste en cambiar de canal rápida y sucesivamente. Cuando un host solicita un nuevo canal, el router IGMP inicia Ia transmisión de dicho canal pero no Ia detiene cuando el host cambia otra vez de canal, si no que el router envía un mensaje "Group-And-Source-Specific-Query" y mantiene
Ia transmisión durante el tiempo LMQT. Si esto sucede repetidas veces en un corto espacio de tiempo, el router IGMP tiene que gestionar todos estos mensajes y, además, estará emitiendo inútilmente toda Ia serie de canales por los que el usuario ha pasado haciendo
"zapping".
La Tabla 3 (al final del presente documento) muestra un ejemplo concreto que ilustra estas ineficiencias. El ejemplo de Ia Tabla 3 se refiere al caso de un host que va cambiando de canal dentro de un grupo multicast G. La columna 1 de Ia tabla muestra los sucesivos mensajes IGMP enviados por el host, Ia columna 2 muestra Ia lista de fuentes cuyo tráfico envía el router tras haber recibido dicho mensaje IGMP, y Ia columna 3 muestra las acciones realizadas por el router tras haber recibido dicho mensaje IGMP. Los dos mensajes SEND Q(G, S1 ) y SEND Q(G, S2) (mensajes "Group-And-Source-Specific-Query" enviados por el router) que aparecen en Ia columna 3 de Ia Tabla 3 son innecesarios porque el host ya no desea recibir el tráfico emitido por las fuentes S1 y S2 que se indican respectivamente en dichos mensajes. También es innecesario que el router transmita los canales (S 1 , G) y (S2, G) durante el tiempo LMQT.
La gestión de mensajes innecesarios por parte el router implica un consumo considerable de capacidad de cálculo que podría evitarse. Además, Ia transmisión de tráfico no deseado consume innecesariamente ancho de banda. Cuando hay miles de hosts realizando cambios de canal estas ineficiencias se multiplican en el router.
2. Primera forma de realización de Ia invención de Ia patente 200702687.
El funcionamiento de los equipos de red que aplican el protocolo IGMP según Ia invención es similar al de los equipos de red del estado de Ia técnica que aplican los protocolos
IGMPv3 y MLDv2. Por ello, para facilitar Ia comprensión, en Io que sigue se ha adoptado Ia misma nomenclatura que en las especificaciones RFC 3376 (protocolo IGMPv3) y RFC 3810 (protocolo MLDv2) mencionadas al principio.
Por otra parte, como el funcionamiento del protocolo IGMP según Ia invención es similar al del protocolo IGMPv3, no se explican todas las características que son comunes al IGMPv3.
La característica principal de Ia invención consiste en que los equipos de red que reciben mensajes IGMPv3 mediante los cuales los hosts solicitan tráfico multicast, como son un router IGMPv3, un switch y un proxy IGMPv3, almacenan en una tabla Ia información separada de las fuentes que solicita cada host que envía mensajes IGMPv3 solicitando tráfico multicast junto con un identificador único del host que ha enviado cada mensaje.
Para ello, estos equipos de red mantienen un registro de estado para cada interfaz de red, grupo multicast y host que envía el mensaje, con Io cual conocen con exactitud cuales son las fuentes de tráfico multicast solicitadas por cada host de forma independiente.
Al almacenar Ia información por separado identificando las peticiones de cada host, ya no hay conflictos entre las fuentes solicitadas en los mensajes de diferentes hosts, ya que cuando un host envía un mensaje para dejar de recibir un determinado canal (S, G) a una interfaz de red de un router IGMP, dicho router conoce con exactitud si hay otro host conectado a esa misma interfaz de red e interesado en recibir ese mismo canal (S, G). Si hay otro host interesado, el router IGMP continúa transmitiendo el canal (S, G), pero si no hay ningún otro host interesado deja de emitir el canal (S, G) en el mismo momento en que recibe el mensaje que Ie pide que deje de transmitirlo, sin necesidad de enviar un mensaje
"Group-And-Source-Specific Query" y esperar Ia respuesta.
Tal como indican las RFC 3376, al inicio del apartado 4, los mensajes IGMP se encapsulan en datagramas IPv4, con número de protocolo 2. Un datagrama IPv4 contiene un campo que indica Ia dirección IP del equipo que envía dicho datagrama.
Una forma particularmente eficaz para implementar Ia presente invención consiste en utilizar, como identificador del equipo que envía cada mensaje IGMP, Ia dirección IP de
dicho equipo. Es posible que algunos equipos que envían mensajes IGMP no dispongan de una IP propia. Esto sucede, por ejemplo, en algunos tipos de DSLAM que envían los mensajes IGMP usando Ia IP 0.0.0.0. En estos casos es posible asignar una dirección IP al DSLAM y que éste Ia utilice en sus mensajes IGMP.
También puede utilizarse como identificador de dicho host Ia dirección MAC Address ("Media Access Control Address") de Ia trama de datos que encapsula el paquete de datos IP que transporta el mensaje IGMP enviado por el host. El uso de este identificador es particularmente útil en los switches que implementan Ia presente invención pues los switches son equipos de nivel 2 que conocen en qué puerto se halla conectado cada equipo identificándolo por su MAC Address y no por su dirección IP.
A continuación se describe en detalle el funcionamiento del protocolo IGMP según Ia invención en cada uno de los equipos de red: el router IGMP mejorado, el proxy IGMP mejorado y un switch mejorado que realiza Ia función IGMP "snooping".
2.1 ) Funcionamiento de un router IGMP mejorado.
La principal diferencia con respecto a los routers IGMP del estado de Ia técnica que aplican los protocolos IGMPv3 y MLDv2 es que el router IGMP mejorado según Ia invención tiene un registro de estado para cada interfaz de red, grupo multicast y host de origen, donde almacena las fuentes solicitadas por cada host:
Registro : (interface, multicast-address, hostID, group-timer, filter-mode {(source-address, source-timer)})
donde
"interface" indica Ia interfaz de red del router por Ia cual el router IGMP ha recibido el mensaje IGMP.
"multicast-address" es el grupo multicast.
"hostID" es un identificador del host que ha enviado el mensaje IGMP.
{(source-address, source-timer)} es una lista de elementos (source-address, source-timer), siendo "source-address" Ia dirección IP de una fuente y siendo "source-timer" un timer asociado a dicha fuente.
"filter-mode" puede ser INCLUDE o EXCLUDE y tiene el mismo funcionamiento que-el que se describe en las RFC 3376: indicar si las fuentes de Ia lista de fuentes y timers son fuentes INCLUDE o fuentes EXCLUDE.
En los registros de estado que tienen un "filter-mode" EXCLUDE las fuentes EXCLUDE se clasifican en dos listas: una primera lista denominada "Requested List" que contiene las fuentes cuyo timer "source-timer" tiene un valor mayor que cero y una segunda lista denominada εxclude List" que contiene las fuentes cuyo timer "source-timer" tiene valor cero.
El principio de clasificación de las fuentes EXCLUDE en dos listas "Requested List" y εxclude List" según el valor del timer "source-timer" es análogo al que se aplica en los protocolos IGMPv3 y MLDv2. Las especificaciones RFC 3810 (protocolo MLDv2) citadas al principio contienen una explicación de este principio.
Cada mensaje que recibe el router IGMP por una determinada interfaz de red, de un determinado host y referido a un determinado grupo multicast, sólo afecta al registro de estado de dichos interfaz de red, host y grupo multicast.
Gracias a que el router IGMP mejorado identifica el origen de cada mensaje IGMP, puede comportarse de una forma determinista para cada host, es decir que los mensajes de cada host determinan el estado de los registros del router asociados a dicho host y no es necesario realizar consultas a otros hosts ni tener en cuenta otros hosts.
Este comportamiento determinista del router IGMP queda claramente reflejado en Ia Tabla 4 (al final del presente documento), que es análoga a Ia Tabla 2 pero para un router IGMP mejorado según Ia invención.
La Tabla 2 se refiere a una determinada interfaz de red del router, mientras que Ia Tabla 4 se refiere a una determinada interfaz de red del router y un determinado host que envía mensajes IGMP.
Ambas tablas muestran las mismas combinaciones de estados iniciales (columna 1 ) y mensajes IGMP recibidos (columna 2), pero como puede verse, los estados finales (columna 3) y las acciones del router IGMP (columna 4) son diferentes. En particular, puede apreciarse que en Ia Tabla 4, Ia columna 4 (acciones realizadas por el router IGMP) no contiene ningún mensaje SEND Q(G 1 S), ya que el router IGMP mejorado según Ia invención no necesita enviar mensajes "Group-And-Source-Specific Querys" para comprobar si queda algún host interesado en recibir el canal (S, G).
Cuando el router IGMP mejorado tiene que decidir si debe transmitir un determinado canal por una determinada interfaz de red, el algoritmo de dicho router tiene en cuenta los diferentes registros de estado de los hosts que hacen referencia a dicho grupo multicast y dicha interfaz de red.
Para una determinada interfaz de red, un determinado grupo multicast G, y una determinada fuente S INCLUDE, mientras exista un registro de estado de algún host referido a dicha interfaz de red y dicho grupo multicast G cuyo "filter-mode" sea INCLUDE y cuyo "source-timer" asociado a dicha fuente S INCLUDE sea mayor que cero, el router IGMP mejorado transmitirá por dicha interfaz de red el tráfico multicast del canal (S, G). Además, si para dichos interfaz de red y grupo multicast G, existen registros de estado cuyo "filter-mode" sea EXCLUDE, el router IGMP mejorado transmitirá además por dicha interfaz de red el tráfico multicast de todas las fuentes excepto las del conjunto que resulta de Ia intersección de todas las listas εxclude List" de dichos registros de estado con "filter- mode" EXCLUDE para dicha interfaz de red y grupo multicast G.
Cuando el timer asociado a una determinada fuente S INCLUDE de un registro de estado con "filter-mode" INCLUDE llega a cero, dicha fuente S se elimina de Ia lista de fuentes INCLUDE de dicho registro de estado.
Cuando un registro de estado con "filter-mode" INCLUDE no contiene ninguna fuente en su lista INCLUDE, dicho registro de estado es eliminado.
La lista "Requested List" sigue siendo necesaria en el router IGMP mejorado para cambiar un registro de estado de "filter-mode" EXCLUDE a "filter-mode" INCLUDE, tal como se explica en el apartado 3 del apéndice A de las RFC 3376.
Otra ventaja de mantener Ia lista "Requested List" es que permite gestionar de forma eficaz Ia situación que se produce cuando el router IGMP mejorado tiene un registro con un "filter- mode" EXCLUDE para una determinada interfaz de red de dicho router, un determinado grupo multicast y un determinado host, y dicho router recibe de ese mismo host un segundo mensaje que Ie indica que desea recibir tráfico de una determinada fuente S1 , por ejemplo un mensaje ALLOW (S1 ). En este caso si el router elimina Ia fuente S1 de Ia εxclude List", y no existiera Ia lista "Requested List", dicho router perdería Ia información de Ia dirección IP de Ia fuente S1 y tendría que utilizar algoritmos de ruteo de tipo ASM para recibir el tráfico de Ia fuente S1. Al mantener en Ia "Requested List" Ia información de S1 , dichas información no se pierde y puede ser utilizada por el router para acceder directamente a Ia fuente S1.
3) Segunda forma de realización de Ia invención de Ia patente 200702687
La forma de realización de Ia invención que se describe a continuación implementa una modificación del protocolo IGMP que permite que un router o un proxy IGMP no esté obligado a combinar las peticiones de tráfico que recibe referidas a un mismo grupo multicast en un solo mensaje IGMP de tipo INCLUDE o de tipo EXCLUDE, como exige actualmente el protocolo IGMPv3, si no que pueda combinarlas en un mensaje de tipo INCLUDE y en un mensaje de tipo EXCLUDE y enviar ambos mensajes.
Para que los routers IGMP y los proxys IGMP puedan funcionar de esta forma, es decir agrupando separadamente los mensajes INCLUDE y los mensajes EXCLUDE y enviando mensajes PIM-SM independientes para cada grupo multicast y filter-mode del protocolo IGMP, se han desarrollado unas modificaciones adicionales al protocolo IGMP, además de las explicadas en el primer ejemplo de realización.
El protocolo IGMP modificado según Ia invención se diferencia del protocolo explicado anteriormente en que las interfaces de red, además de hacer un seguimiento individual de
las fuentes que solicita cada host de origen que envía cada mensaje, pueden funcionar en modo dual: pueden almacenar y transmitir por separado Ia información de las fuentes contenidas en los mensajes IGMP de tipo INCLUDE y Ia información de las fuentes contenidas en los mensajes IGMP de tipo EXCLUDE.
Para ello, el protocolo IGMP modificado guarda dos registros: uno para el "filter-mode" EXCLUDE y otro para el "filter-mode" INCLUDE para cada interfaz de red y grupo multicast. Así, un proxy o router IGMP que utiliza el protocolo IGMP modificado puede guardar, para cada interfaz de red y grupo multicast, dos registros separados:
Registro INCLUDE: (interface, multicast-address, hostID, group-timer, filter-mode =1 NCLU DE, {(source-address, source-timer)})
Registro EXCLUDE: (interfaz, multicast-address, hostID, group-timer, filter-mode =EXCLUDE, {(source-address, source-timer)})
donde
"interface" indica Ia interfaz de red del router por Ia cual el router IGMP ha recibido el mensaje IGMP.
"multicast-address" es el grupo multicast.
"hostID" es un identificador del host que ha enviado el mensaje IGMP.
{(source-address, source-timer)} es una lista de elementos (source-address, source-timer), siendo "source-address" Ia dirección IP de una fuente y siendo "source-timer" un timer asociado a dicha fuente.
"filter-mode" puede se INCLUDE o EXCLUDE y tiene el mismo funcionamiento que-el que se describe en las RFC 3376: indicar si las fuentes de Ia lista de fuentes y timers son fuentes INCLUDE o fuentes EXCLUDE.
Cuando el router o el Proxy IGMP mejorado tiene que decidir si debe transmitir un determinado canal por una determinada interfaz de red, el algoritmo de dicho router o proxy tiene en cuenta los diferentes registros de estado de los hosts que hacen referencia a dicho grupo multicast y dicha interfaz de red, pero con Ia diferencia de que ahora los hosts pueden tener dos registros de estado con diferentes filter-mode INCLUDE y EXCLUDE, para un mismo grupo multicast. El algoritmo aplica las reglas siguientes:
Para una determinada interfaz de red, un determinado grupo multicast G, y una determinada fuente S INCLUDE, mientras exista un registro de estado de algún host referido a dicha interfaz de red y dicho grupo multicast G cuyo filter-mode sea
INCLUDE y cuyo source-timer asociado a dicha fuente S INCLUDE sea mayor que cero, el router IGMP mejorado transmitirá por dicha interfaz de red el tráfico multicast del canal (S, G).
- Además, si para dichos interfaz de red y grupo multicast G, existen registros de estado cuyo filter-mode sea EXCLUDE, el router IGMP mejorado transmitirá además por dicha interfaz de red el tráfico multicast de todas las fuentes excepto las del conjunto que resulta de Ia intersección de todas las listas εxclude List" de dichos registros de estado con filter-mode EXCLUDE para dicha interfaz de red y grupo multicast G.
En Ia Tabla 5 (al final del presente documento) se ilustra el funcionamiento de un router mejorado que aplica el protocolo IGMP modificado según Ia invención. En su estado inicial, el router dispone, para una determinada interfaz de red, un determinado grupo multicast G y un determinado host, de dos registros de estado para dicho grupo multicast G porque tiene tanto fuentes INCLUDE como fuentes EXCLUDE.
Al igual que Ia Tabla 4, Ia Tabla 5 se refiere a una determinada interfaz de red del router y un determinado host que envía mensajes IGMP.
Como se puede observar en Ia Tabla 5, el uso de dos registros separados para almacenar las fuentes INCLUDE y EXCLUDE junto con el seguimiento individual de las peticiones de tráfico de cada host, permite eliminar Ia lista "Requested-List" que ya no es necesaria. Las listas EXCLUDE(Y), representan las Exclude-List y las fuentes EXCLUDE ya no necesitan timers, Io que simplifica su funcionamiento.
El Group-Timer o GT se sigue utilizando para eliminar el registro EXCLUDE cuando dicho timer llega a cero.
También se puede observar en Ia Tabla 5 que se han definido cuatro nuevos mensajes IGMP. Los dos primeros ALLOWIN (B) y BLOCKIN (B) modifican las fuentes del registro INCLUDE y los dos últimos ALLOWEX (B) y BLOCKEX (B) modifican las fuentes del registro EXCLUDE.
De Ia misma forma, el mensaje ISJN(B) sólo afecta al registro INCLUDE y el mensaje IS_EX(B) sólo afecta al registro EXCLUDE. Esta separación de los mensajes que afectan a los registros INCLUDE y EXCLUDE aporta una gran simplicidad. Comparando Ia Tabla 5 con Ia Tabla 2, resulta evidente que Ia Tabla 5 es mucho más sencilla que Ia Tabla 2. Además de haber simplificado Ia gestión de los timers y eliminado el envío de mensajes "Group-And-Source-Specific-Query", se ha conseguido que el router IGMP sólo tenga que gestionar los seis casos que corresponden a las seis filas de Ia Tabla 5, en lugar de los doce casos que aparecen en Ia Tabla 2. La comparación entre las Tablas 2 y 5 pone pues de manifiesto que el protocolo IGMP mejorado facilita considerablemente Ia implementación y programación de los algoritmos en los routers, además de solucionar los problemas de ineficiencia antes mencionados.
Para las comunicaciones entre un host y un router IGMP, el protocolo IGMP modificado utiliza los mismos mensajes que el protocolo IGMPv3, que se describen en el apartado 4 de las RFC 3376. La única diferencia está en el formato interno de los bloques de datos denominados "Group Record" que están contenidos en cada mensaje "Membership Report": en el protocolo IGMP modificado, cuando hay fuentes INCLUDE y también fuentes EXCLUDE para el mismo grupo multicast se incluyen en el mensaje "Membership Report" dos "Group Record": uno para las fuentes INCLUDE y otro para las fuentes EXCLUDE.
Resumen de Ia solicitud de patente española número 200702849
En el siguiente resumen, Ia palabra invención se refiere a Ia invención de Ia solicitud de patente española 200702849.
En Io que sigue, y siguiendo Ia nomenclatura común en Ia tecnología SSM, se denomina canal (S, G) a Ia emisión de Ia fuente S del grupo multicast G, donde S es una dirección IP que identifica Ia fuente que emite los datos y G es una dirección IP, dentro del rango reservado para grupos multicast, que identifica el grupo multicast.
Asimismo, en Io que sigue se utilizarán las expresiones "upstream" y "dowstream" para indicar unas ubicaciones relativas desde un equipo de red: Ia expresión "upstream" se refiere a una ubicación en dirección a Ia fuente multicast y Ia expresión "downstream" se refiere a una ubicación en Ia dirección contraria.
En los primeros protocolos de ruteo multicast, como por ejemplo el protocolo DVMRP ("Distance Vector Multicast Routing Protocol"), los routers intercambiaban entre sí unos mensajes denominados "DVMRP Route Reports" con información para construir Ia base de datos de topología multicast. La base de datos de topología multicast es donde los routers almacenan Ia información de todos los routers multicast que hay en Ia red y cómo están conectados entre sí. En el protocolo DVMRP, cada router enviaba cada 60 segundos estos mensajes.
El protocolo PIM-SM funciona de una forma diferente. Los routers PIM-SM no envían mensajes para crear Ia base de datos de topología multicast, sino que utilizan Ia base de datos unicast del router para deducir a partir de ella Ia base de datos de topología multicast y Io hacen independientemente del protocolo unicast que utilice el router. De aquí viene el nombre de "Protocol Independent Multicast". De esta forma, PIM-SM no depende de ningún protocolo unicast concreto y puede crear Ia base de datos de topología multicast en los routers independientemente del protocolo unicast que utilice cada router.
En el protocolo PIM-SM Ia base de datos de topología multicast es almacenada en una tabla denominada MRIB ("Multicast Routing Information Base") que se usa, entre otras cosas, para decidir a qué router deben ser enviados los mensajes JOIN/PRUNE. Estos mensajes JOIN/PRUNE del protocolo PIM-SM, que son de sobra conocidos por el experto en Ia materia, son los mensajes que envía un router PIM-SM a otro router PIM-SM para indicar que desea recibir tráfico multicast (mensajes JOIN) o que desea dejar de recibir tráfico multicast (mensajes PRUNE). Los datos multicast se transmiten hacia el router que
ha solicitado el tráfico multicast siguiendo Ia misma dirección que los mensajes JOIN, pero en el sentido contrario.
Un primer problema que afecta al protocolo PIM-SM es el retraso en transmitir los mensajes de tipo "PRUNE" que envía un router PIM-SM a otro router PIM-SM para indicarle que no desea seguir recibiendo un determinado tráfico multicast. Cuando un router PIM- SM recibe un mensaje de tipo PRUNE, por ejemplo PRUNE (S, G), no deja de transmitir inmediatamente el tráfico del canal multicast (S, G), sino que espera un tiempo determinado antes de dejar de transmitir el canal multicast (S, G) por su interfaz de red donde ha recibido el mensaje de tipo PRUNE. En Ia configuración por defecto del protocolo PIM-SM este tiempo de espera es de 3 segundos. El motivo de este tiempo de espera es que puede haber otros routers PIM-SM compartiendo una red multiacceso y es posible que haya otro router PIM-SM que desee seguir recibiendo el canal multicast (S, G), para Io cual dicho router debe enviar un mensaje JOIN(S 1 G) de forma inmediata para cancelar el efecto del anterior mensaje PRUNE(S 1 G).
Si el número de routers es alto y hay miles de usuarios realizando cambios de canales multicast, Ia consecuencia es que hay una enorme cantidad de ancho de banda ocupado en Ia red por Ia latencia o retraso en suprimir Ia transmisión de canales multicast no deseados. Si además los canales multicast (S, G) transmiten video o canales IPTV que requieren un ancho de banda de entre 4 Mbits/s en resolución normal y 20 Mbits/s en alta resolución, el problema se agrava considerablemente.
Las RFC 4601 , en el apartado 4.3.3 "Reducing PRUNE Propagation Delay on LANs", proponen una solución al problema de latencia que consiste en utilizar los mensajes "Helio" que utilizan los routers PIM-SM para intercambiar información entre ellos y negociar varios parámetros. Los mensajes "Helio" se utilizan, por ejemplo, para negociar si hay o no supresión de mensajes PIM-SM, el tiempo de retardo en los mensajes PRUNE y otros parámetros. Los routers PIM-SM envían estos mensajes "Helio" de forma periódica, por cada interfaz de red del router donde esté ejecutándose el protocolo PIM-SM, a una dirección multicast denominada "ALL-PIM-ROUTERS". Gracias a estos mensajes "Helio", cada router PIM-SM conoce Ia existencia de otros routers PIM-SM conectados en cada una de sus interfaces de red. Todos los routers almacenan además Ia información de configuración de los demás routers que se ha intercambiado mediante mensajes "Helio".
Sin embargo, los mensajes "Helio" utilizados en el protocolo PIM-SM no transmiten información sobre Ia topología de routers multicast. Esta información Ia deduce el router PIM-SM a partir de las tablas de ruteo unicast.
Como se ha dicho anteriormente, cuando un router PIM-SM recibe un mensaje de tipo PRUNE(S 1 G) espera un tiempo para ver si hay otro router que envía un mensaje JOIN(S 1 G) que cancele el primer mensaje PRUNE. El tiempo de espera es Ia suma de dos variables denominadas εffective_Propagation_Delay" y εffective_Override_lnterval", que por defecto toman los valores de 0,5 segundos y 2,5 segundos, respectivamente. El motivo de utilizar como retardo esta suma de dos variables es el siguiente: si hay un router R1 que está recibiendo el tráfico del canal multicast (S, G) de un router R2, y el router R1 ve que otro router R3 envía un mensaje PRUNE(S 1 G), el router R1 debe enviar un mensaje de tipo JOIN(S 1 G) al router R2 para cancelar el efecto del mensaje PRUNE (S, G) antes del tiempo εffective_Override_lnterval". Como εffective_Override_lnterval" siempre es menor que Ia suma de εffectivejDverrideJnterval" y εffective_propagation_Delay", el mensaje JOIN(S;G) del router R1 llegará al router R2 antes de que el router R2 deje de enviar el tráfico del canal multicast (S, G).
La solución que proponen las RFC 4601 para reducir el tiempo de latencia consiste en que los routers PIM-SM utilicen los mensajes "Helio" para reducir los valores de las variables "Effective_Propagation_Delay" y "Effective_Override_lnterval". Para ello, todos los routers PIM-SM anuncian sus propios parámetros "Propagation_Delay" y "Override_lnterval" en los mensajes "Helio". Estos parámetros están contenidos en los mensajes "Helio" en un bloque de datos denominado "LAN_PRUNE_Delay". Cuando todos los routers que ejecutan el protocolo PIM-SM en una red han enviado mensajes "Helio" incluyendo el bloque de datos "LAN_PRUNE_Delay", todos los routers conectados a una misma red multiacceso utilizan como valores de "Effective_Propagation_Delay" y εffectivejDverrideJnterval" los valores máximos de los parámetros "Propagation_Delay" y "Override_lnterval", respectivamente, que han sido anunciados por dichos routers en los mensajes "Helio".
Sin embargo, este mecanismo tiene varias limitaciones.
En primer lugar, las propias RFC 4601 indican que si las variables "Effective_Propagation_Delay" y εffectivejDverrideJnterval", toman valores muy bajos es posible que, siguiendo con el ejemplo anterior, el router R2 suprima el tráfico del canal (S, G) antes de que el router R1 tenga tiempo de enviar su mensaje JOIN o antes de que el router R2 tenga tiempo de procesar dicho mensaje. Para evita este problema, las RFC 4601 recomiendan no bajar demasiado los valores de estas variables. Esta es una grave limitación de este mecanismo de reducción de latencia.
Además, otra limitación o problema que tiene este mecanismo de reducción de latencia es que es necesario que todos los routers que ejecutan el protocolo PIM-SM en una red envíen mensajes incluyendo el bloque de datos "LAN_PRUNE_Delay". Si hay un router que no incluye este bloque de datos en sus mensajes "Helio", ya no se puede utilizar este mecanismo de reducción de latencia y las variables εffective_Propagation_Delay" y
εffectivejDverrideJnterval" toman sus valores por defecto, que son de 2,5 segundos y 0,5 segundos respectivamente, en todos los routers de Ia red multiacceso, causando por Io tanto una latencia de 3 segundos en cada router.
Por otra parte, al final del mencionado apartado 4.3.3 de las RFC 4601 dedicado a Ia reducción de Ia latencia, se explica que es posible que un router PIM-SM upstream lleve un control o seguimiento individual de las peticiones de tráfico multicast de varios routers downstream. Aunque no explica cómo implementar dicho seguimiento individual ni qué utilidad tiene, sí indica que para hacerlo es imprescindible que todos los routers de Ia misma red multiacceso se pongan primero de acuerdo en cancelar Ia supresión de mensajes. El apartado mencionado 4.3.3 de las RFC 4601 incluye incluso el código que se puede utilizar para comprobar que todos los routers se han puesto de acuerdo en cancelar Ia supresión de mensajes.
Un segundo problema que afecta al protocolo PIM-SM es Ia complejidad del mecanismo de supresión de mensajes JOIN. Básicamente, Ia supresión de mensajes JOIN consiste en que si un router downstream R1 ve que otro router downstream R2 envía un mensaje JOIN solicitando el mismo tráfico multicast que el que iba a pedir, dicho router R1 puede suprimir su propio mensaje JOIN, pues basta con que el router upstream reciba una única solicitud para que transmita el tráfico multicast solicitado.
En Ia última versión del protocolo multicast IGMP (versión IGMPv3), mediante el cual los hosts solicitan tráfico multicast a un router, se ha cancelado Ia supresión de mensajes, que existía en las versiones anteriores de IGMP. En cambio, en el protocolo PIM-SM, mediante el cual un router solicita tráfico multicast a otro router, todavía existe Ia supresión de mensajes. De hecho, Ia supresión de mensajes es Ia configuración por defecto que debe aplicarse según las RFC 4601. Existe una opción de configuración para que no se realice Ia supresión de mensajes, pero sólo se aplica en determinadas circunstancias y requiere una implementación compleja.
El mecanismo de supresión de mensajes que se aplica en el protocolo PIM-SM, según las RFC 4601 , es muy complicado. También es muy complicado el mecanismo para cancelar Ia supresión de mensajes, según las RFC 4601. Por ello, cualquier modificación del protocolo PIM-SM relacionada con Ia supresión de mensajes es muy complicada. Probablemente esto explica Ia falta de investigación de mejoras en el protocolo PIM-SM relacionadas con Ia supresión de mensajes . Por otra parte, al final del mencionado apartado 4.3.3 de las RFC 4601 se indica que para hacer un seguimiento individual del tráfico multicast que solicita cada router dowsntream, es necesario cancelar Ia supresión de mensajes. Según las RFC 4601 , si hay routers que suprimen mensajes no es posible hacer el seguimiento individual del tráfico multicast que solicita cada router.
La descripción siguiente ilustra Io complejos que son el mecanismo de supresión de mensajes y las condiciones para cancelar dicha supresión de mensajes, según las RFC 4601.
Para explicar el mecanismo de supresión de mensajes un experto en Ia materia tiene que analizar y entender en detalle Ia máquina de estados denominada "upstream" (S, G), mediante Ia cual las RFC 4601 especifican el funcionamiento del envío "upstream" de mensajes de tipo JOIN (S, G). Esta máquina de estados se encuentra ilustrada en forma de una tabla en el apartado "4.5.7 Sending (S, G) Join/Prune messages" de las RFC 4601.
Cada máquina de estados "upstream" (S, G) es independiente para cada interfaz de red del router y para cada canal multicast (S, G) y tiene sólo dos estados: el estado "Not_Joined", que significa que el router no necesita recibir el canal multicast (S, G) por dicha interfaz de red, y el estado "Joined", que significa que el router necesita recibir el canal multicast (S, G)
por dicha interfaz de red.
Si Ia máquina de estados está en el estado "Not_Joined", y por tanto el router no está recibiendo el canal multicast (S, G), y se produce un evento "JoinDesired(S,G)->true", que indica que el router ha recibido una petición de tráfico del canal (S, G) por parte de otro router "downstream", Ia máquina de estados del router ejecuta las acciones siguientes: cambiar el estado a "Joined", enviar un mensaje JOIN (S, G) a otro router "upstream" que figura en su tabla MRIB como apto para enviarle el tráfico del canal (S, G), e inicializar un timer denominado "Join_Timer" a un valor inicial denominado "t_periodic".
En el estado "Joined", cuando sucede el evento "Timer_Expires", que indica que el timer "Join_Timer" ha llegado a cero, el router envía ("Send Join(S,G)") un nuevo mensaje JOIN (S, G) y vuelve a inicializar el timer "Join_Timer" al valor "t_periodic".
Por Io tanto, en el estado "Joined" el router vuelve a enviar de forma periódica los mensajes JOIN (S, G) para seguir recibiendo el tráfico del canal multicast (S, G).
Cuando sucede el evento "See Join(S,G) to RPF'(S,G)", que indica que el router ha visto en Ia red multiacceso a Ia que está conectado que otro router ha enviado un mensaje similar al mensaje JOIN (S, G) que tiene que enviar cuando el timer "Join_Timer" llegue a cero, el router incrementa el valor del timer "Join_Timer" para retrasar el envío de su propio mensaje JOIN (S, G). Esto se explica con mayor detalle en Ia página 74 de las RFC 4601 , que indica que si el timer "Join_Timer" tiene un valor menor que una variable denominada "tjoinsuppress" entonces se inicializa dicho timer "Join_Timer" con el valor de esta variable "tjoinsuppress". Si en cambio el timer "Join_Timer" tiene un valor mayor que Ia variable "tjoinsuppress", entonces el timer "Join_Timer" no se modifica.
Por Io tanto, el mecanismo de supresión de mensajes del protocolo PIM-SM consiste en aumentar el valor del timer "Join_Timer" que controla el envío periódico de mensajes JOIN (S, G). Como el aumento del timer "Join_Timer" al valor "tjoinsuppress" se realiza cada vez que el router ve en Ia red multiacceso un mensaje JOIN (S, G) de otro router, el timer "Join_Timer" se vuelve a inicializar al valor "tjoinsuppress" de forma periódica y nunca llega a cero. Esto es Io que hace que el router no envíe su propio mensaje JOIN (S, G), es decir que suprima su propio mensaje JOIN (S, G) periódico mientras haya otro router en Ia
misma red multiacceso que esté enviando un mensaje JOIN (S, G) equivalente.
Hasta aquí se ha explicado cómo funciona Ia supresión de mensajes en el protocolo PIM- SM. Ahora se va explicar cómo funciona el mecanismo que cancela dicha supresión de mensajes.
El mecanismo para cancelar Ia supresión de mensajes en el protocolo PIM-SM, según se deduce de las RFC 4601 , consiste en hacer que el valor de Ia variable "tjoinsuppress" sea cero. Cuando el router ve un mensaje JOIN (S, G) comprueba si el timer "Join_Timer" es menor que Ia variable "tjoinsuppress", que es igual a cero, Io cual obviamente nunca sucede, y deja dicho timer "Join_Timer" sin modificar. De esta forma, el router envía su propio mensaje JOIN (S, G) cuando su timer "Join_Timer", que no se ve modificado por los mensajes de los demás routers, llega a cero.
La variable "tjoinsuppress" toma el valor menor entre el valor de otra variable denominada "t_suppressed" y un parámetro denominado "holdtime" que es transmitido en los mensajes JOIN (S, G) y que indica durante cuánto tiempo el router que ha envía el mensaje JOIN (S, G) desea estar recibiendo el canal (S, G). La variable "t_suppressed" toma un valor diferente en función de si está o no habilitada Ia supresión de mensajes. Hay una función denominada "Suppression_Enabled(l)" que es específica para cada interfaz de red I y que devuelve el valor TRUE si Ia supresión de mensajes está permitida, y el valor FALSE si Ia supresión de mensajes está cancelada:
Si Ia función "Supression_Enabled(l)" devuelve un valor TRUE entonces Ia variable "t_suppressed" toma un valor aleatorio dentro del rango [ 1 ,1 * "t_periodic"; 1 ,4 * "t_periodic"], donde "t_periodic" es una variable que por defecto toma el valor de 60 segundos.
Si Ia función "Supression_Enabled(l)" devuelve el valor FALSE, Ia variable "t_suppresed" es cero, y también es cero Ia variable "tjoinsuppress", que toma el valor menor entre "t_suppressed" y el parámetro "holdtime". De esta forma se evita modificar el timer "Join_Timer" cuando Ia función "Supression_Enabled(l)" devuelve un valor FALSE y así cada router envía sus mensajes periódicos JOIN (S, G) sin tener en cuenta los mensajes JOIN (S, G) que envían los demás routers, con Io cual se ha cancelado Ia supresión de
mensajes.
Este mecanismo de cancelación de Ia supresión de mensajes definido en las RFC 4601 es innecesariamente complicado. Además, es ineficiente porque si Ia función "Supression_Enabled(l)" devuelve un valor FALSE, el router, antes de tomar Ia decisión de modificar o no el timer "Join_Timer", habrá comprobado dos veces si una cantidad positiva es menor que cero, algo que no puede suceder.
Como el protocolo PIM-SM es un protocolo complejo, los programadores de aplicaciones que implementan dicho protocolo siguen las especificaciones RFC 4601 de Ia forma más exacta posible para evitar enfrentarse a nuevos problemas de diseño que no estén previstos en dichas especificaciones. Como consecuencia de ello, las aplicaciones que implementan el protocolo PIM-SM presentan las limitaciones expuestas anteriormente.
Estas limitaciones, junto a Ia complejidad que supone Ia supresión de mensajes en el protocolo PIM-SM, son los motivos por los cuales hasta ahora no se ha desarrollado ninguna solución satisfactoria al problema de Ia latencia en el protocolo PIM-SM.
Descripción detallada de unas formas de realización de Ia patente española número 200702849
1 ) Router mejorado
La Fig. 4 muestra un ejemplo simplificado de un sistema de comunicaciones multicast en el cual operan seis routers PIM-SM 410, 420, 430, 440, 450 y 470. Una fuente 400 que emite un canal multicast (S, G) está conectada al router 410, que transmite dicho canal multicast por medio de los routers PIM-SM 410, 420, 430 y 440, hasta llegar al router 450 que está conectado a un host 460 que desea recibir dicho canal (S, G). El host 460 indica al router 450 el tráfico multicast que desea recibir. Para ello, el host 460 y el router 450 se comunican mediante el protocolo IGMPv3 o el protocolo MLDv2.
El router 440 y el router 450 están conectados entre sí mediante una red local multiacceso 445, por ejemplo una red Ethernet, a Ia que pueden estar conectados otros routers PIM-
SM. En Ia figura se muestra sólo otro router PIM-SM 470 conectado a Ia red multiacceso 445, pero evidentemente pueden haber más routers PIM-SM conectados a dicha red 445. De Ia misma forma, hay otra red local multiacceso 435 entre los routers 440 y 430, otra red multiacceso 425 entre los routers 430 y 420 y otra red multiacceso 415 entre los routers 420 y 410. En cada una de estas redes multiacceso 415, 425 y 435 pueden haber otros routers PIM-SM conectados, que no se muestran en Ia figura para simplificarla.
En el ejemplo, cada router 410, 420, 430, 440 y 450 tiene una interfaz de red "upstream", respectivamente 41 1 , 421 , 431 , 441 y 451 , y una interfaz de red "downstream", respectivamente 412, 422, 432, 442 y 452.
El canal multicast (S, G) se transmite desde Ia fuente 400 hacia el host 460 siguiendo el camino 480 indicado con una línea discontinua que atraviesa los routers 410, 420, 430, 440 y 450 de Ia figura hasta llegar al host 460.
Los mensajes PIM-SM siguen el mismo camino 480, pero en sentido contrario de los datos que van desde Ia fuente 400 al host 460 que recibe dicho tráfico, y se transmiten desde el router 450 hacia el router 410 pasando por los routers intermedios 440, 430 y 420. En el caso del canal multicast (S, G) emitido por Ia fuente 400 de Ia figura 4, los mensajes PIM- SM pueden ser mensajes de tipo JOIN(S 1 G) para solicitar recibir el tráfico de Ia fuente 400 o mensajes de tipo PRUNE (S, G) para solicitar dejar de recibir el tráfico de Ia fuente 400.
Suponiendo que inicialmente el host 460 está recibiendo el canal multicast (S, G) transmitido por Ia fuente 400, a continuación se analizara el proceso que tiene lugar cuando el host 460 envía un mensaje IGMPv3 o MLDv2 al router 450 para indicar que desea dejar de recibir el tráfico de dicho canal (S, G). Cuando esto sucede, el router 450 envía un mensaje PRUNE(S 1 G) al router 440 para indicarle que ya no desea recibir el canal (S, G). Dicho mensaje PRUNE(S 1 G) se transmite por Ia interfaz de red 451 del router 450 por medio de Ia red multiacceso 445 y es recibido por Ia interfaz de red 442 del router 440.
En el estado de Ia técnica anterior, el router 440 espera 3 segundos para ver si hay algún router que todavía esté interesado en recibir el (S, G), en cuyo caso dicho router interesado deberá enviar inmediatamente al router 440 un mensaje JOIN (S, G) antes de que transcurran los tres segundos, para que así el router 440 continúe transmitiendo el tráfico
(S, G). Si transcurren los tres segundos sin que ningún router conectado a Ia red 445 envíe un mensaje JOIN(S 1 G), el router 440 dejará de transmitir el canal multicast (S, G) por su interfaz de red 442 y transmitirá otro mensaje PRUNE (S, G) hacia el router 430 por medio de Ia red multiacceso 435. El mismo proceso se repite en los siguientes routers 430 y 420, que envían sucesivos mensajes PRUNE (S, G). En cada router se añaden tres segundos de espera para comprobar si en cada red multiacceso 435, 425 hay algún otro router interesado en recibir el canal (S, G). El resultado final es que, en el estado de Ia técnica anterior, desde que el router 450 envía el primer mensaje PRUNE(S 1 G) hasta que el router 410 deja de transmitir el canal (S, G), hay un retardo total de 12 segundos (3 segundos sucesivamente en cada uno de los routers) durante los cuales el router 410 ha continuado transmitiendo el tráfico del canal (S, G) de forma innecesaria.
La solución adoptada por Ia presente invención para eliminar completamente este problema de latencia consiste en que el router PIM-SM que recibe por una interfaz de red un mensaje PIM-SM de otro router solicitando tráfico multicast, identifica y almacena Ia dirección IP del router de origen de dicho mensaje PIM-SM. La dirección IP de origen de los mensajes PIM-SM se obtiene del campo "Source Address" de los paquetes IP que transportan dichos mensajes PIM-SM. De esta forma, el router de Ia presente invención conoce con exactitud, para cada una de sus interfaces de red, qué equipos están interesados en recibir cada tipo de tráfico multicast en cada momento. Al llevar un control individual del tráfico solicitado por cada router, cuando el router PIM-SM según Ia invención recibe un mensaje de tipo PRUNE para dejar de transmitir un determinado trafico multicast, dicho router ya no necesita esperar un tiempo para ver si otro router envía un mensaje de tipo "JOIN" referido al mismo tráfico multicast, pues conoce con exactitud el tráfico multicast solicitado por cada router. Si el router sabe que no hay ningún otro router que desea recibir dicho tráfico multicast, puede cancelar de inmediato Ia transmisión del mismo, con Io cual se elimina completamente Ia latencia.
Un router mejorado según Ia invención realiza una función que las especificaciones RFC 4601 , al final de su apartado 4.5.7, afirman que es imposible, esto es, hacer un seguimiento individual de las peticiones de tráfico multicast de los routers "downstream" sin eliminar primero Ia supresión de mensajes en todos los routers de Ia red multiacceso. De esta forma Ia presente invención cambia Ia importancia que tiene Ia supresión de mensajes en el control individual de las peticiones de tráfico de los routers "downstream": pasa de ser
algo imprescindible para un experto en Ia materia, que sigue las especificaciones RFC 4601 debido a Ia complejidad del protocolo PIM-SM, a ser algo relativamente poco importante para un experto en Ia materia que aplica Ia presente invención.
De acuerdo con Io que establecen las RFC 4601 , si se realiza una supresión de mensajes un router PIM-SM no puede hacer un seguimiento individual del tráfico multicast que Ie ha solicitado cada router "dowsntream". Siguiendo esta idea establecida, un experto en Ia materia pensará que si se realiza una supresión de mensajes, un router PIM-SM según Ia invención no podrá mantener actualizada Ia información del tráfico multicast que Ie ha solicitado cada router "downstream".
El router PIM-SM mejorado según Ia invención, que almacena Ia dirección IP de todos los equipos que Ie solicitan tráfico multicast y lleva un seguimiento exacto del tráfico multicast que Ie ha solicitado cada equipo, tiene que solucionar el problema que supone Ia supresión de mensajes para mantener actualizada dicha información. La presente invención soluciona este problema gracias a que explota unas características del protocolo PIM-SM que no se explican en las especificaciones RFC 4601 pero que el solicitante ha deducido a partir de una observación detallada de Ia máquina de estados "upstream" (S, G) que figura en el apartado 4.5.7 de dichas especificaciones. A continuación se explica brevemente en qué consisten estas características.
Un router PIM-SM tiene una máquina de estados "upstream" (S, G) independiente para cada interfaz de red del router y para cada canal multicast (S, G). Esta máquina de estados "upstream" (S, G) tiene sólo dos estados: un estado Not_Joined (NJ) que significa que el router no necesita recibir el canal multicast (S, G) por dicha interfaz de red, y un estado Joined (J) que significa que el router necesita recibir el canal multicast (S, G) por dicha interfaz de red. No se considera necesario explicar en detalle el funcionamiento de Ia máquina de estados "upstream" (S, G) que se utiliza para enviar mensajes Join(S;G) en el protocolo PIM-SM, pues ya está explicado en el mencionado apartado 4.5.7 de las RFC 4601. Las características del protocolo PIM-SM que el solicitante ha deducido a partir de un análisis detallado de dicha máquina de estados "upstream" (S, G), y que son explotadas por Ia presente invención, son las siguientes:
- Al pasar de un estado "Not Joined" (NJ) a un estado "Joined" (J), un router PIM-SM siempre envía un mensaje JOIN(S 1 G).
- Al pasar de un estado "Joined" (J) a un estado "Not Joined" (NJ) un router PIM-SM siempre envía un mensaje PRUNE (S, G).
Como consecuencia de estas dos características resulta Ia característica siguiente:
- A cada mensaje inicial de tipo JOIN que envía un determinado router PIM-SM para solicitar un determinado tráfico multicast, Ie corresponde siempre un mensaje final de tipo PRUNE procedente del mismo router cuando éste quiere dejar de recibir dicho tráfico multicast.
Por Io tanto, un router que ejecuta el protocolo PIM-SM siempre envía un mensaje inicial JOIN (S, G) cuando el router desea empezar a recibir el tráfico del canal multicast (S, G) y siempre envía un mensaje final PRUNE (S, G) cuando dicho router desea dejar de recibir dicho canal multicast. Los mensajes de tipo JOIN (S, G) que puede suprimir el router PIM-
SM son únicamente los mensajes de tipo JOIN (S, G) periódicos que se vuelven a enviar cuando expira el timer denominado "Join_Timer", pero nunca se suprime el mensaje inicial JOIN (S 1 G).
Además, esto es así independientemente de que esté activada o no Ia supresión de mensajes. Gracias a estas características de Ia máquina de estados "upstream" de PIM- SM, el router según Ia presente invención puede hacer el seguimiento exacto del tráfico multicast que quiere cada router PIM-SM tanto si está activada Ia supresión de mensajes como si no, y no hace falta que todos los routers se pongan de acuerdo en eliminar Ia supresión de mensajes tal como requieren las RFC 4601.
El router según Ia invención explota estas características de Ia manera siguiente: realiza el seguimiento individual del tráfico multicast que solicita cada router "downstream", por ejemplo el tráfico (S, G), usando el mensaje inicial JOIN(S 1 G) que recibe de cada router y el mensaje final PRUNE(S 1 G) que recibe de cada router. Gracias a ello, un router según Ia invención que aplica el protocolo PIM-SM es capaz de realizar dicho seguimiento individual
del tráfico multicast aunque se supriman los mensajes JOIN(S 1 G) periódicos que los otros routers envían entre un mensaje inicial JOIN (S, G) y un mensaje final PRUNE (S, G).
Por Io tanto, un router según Ia invención que aplica el protocolo PIM-SM puede hacer un seguimiento del tráfico multicast solicitado por cada router "downstream" tanto si está activada Ia supresión de mensajes como si no, contrariamente a Io que establecen las RFC 4601. Además, asimismo contrariamente a Io que establecen las RFC 4601 , para ello no hace falta que todos los routers se pongan de acuerdo en cancelar Ia supresión de mensajes.
En resumen, un router según Ia invención es apto para funcionar en una red de comunicaciones según el protocolo PIM-SM en Ia cual los otros routers pueden ser tanto routers según Ia invención como routers según el estado de Ia técnica anterior, y dicho router según Ia invención puede realizar un seguimiento individualizado del tráfico multicast solicitado por los otros routers independientemente de si los routers según el estado de Ia técnica anterior han cancelado o no Ia supresión de mensajes.
En el estado de Ia técnica anterior, los routers que aplican el protocolo PIM-SM envían los mensajes JOIN (S, G) periódicos para evitar que, si se pierde un mensaje final PRUNE (S, G), el router "usptream" que no ha recibido dicho mensaje PRUNE (S, G) perdido continúe transmitiendo el canal (S, G) de forma indefinida hacia una red aunque no haya ningún router interesado en recibir dicho canal. El router "upstream" actualiza un timer denominado εxpiry_Timer" cada vez que recibe un mensaje JOIN (S, G), ya sea el inicial o uno de los periódicos. Cuando el timer εxpiry_Timer" llega a cero, el router deja de transmitir el canal (S, G).
En el router de Ia presente invención que realiza un seguimiento individual del tráfico multicast que solicita cada router, por ejemplo el tráfico (S, G), usando el primer mensaje JOIN (S, G) que recibe de cada router y el mensaje PRUNE (S, G) que recibe de cada router, también es conveniente utilizar un timer que evite que un determinado tráfico multicast se siga transmitiendo de forma indefinida si se pierde un paquete IP que transporta un mensaje PRUNE. El funcionamiento en detalle de este timer que implementa Ia presente invención se explica más adelante.
Aunque las explicaciones que preceden se refieren al tipo de tráfico multicast (S, G) y a los mensajes PIM-SM correspondientes, de tipo JOIN/PRUNE (S, G), Io explicado es aplicable a los otros tres tipos de tráfico multicast y a sus mensajes PIM-SM correspondientes que, como es conocido por el experto en Ia materia, son los siguientes:
- Tráfico (Y 1 RP) ; mensajes de tipo JOIN / PRUNE (Y 1 RP)
- Tráfico C 1 G) ; mensajes JOIN / PRUNE ( * ,G)
- Tráfico (S,G,rpt) ; mensajes JOIN / PRUNE (S,G,rpt)
En Ia Tabla 6 se muestra el funcionamiento de Ia máquina de estados "downstream" (S, G) de un router según Ia invención, es decir Ia máquina de estados que gestiona el control del estado del tráfico multicast (S, G) en función de los mensajes JOIN / PRUNE (S, G) recibidos por cada interfaz de red de dicho router. El experto en Ia materia comprenderá sin dificultad que los conceptos que se explican a continuación para Ia máquina de estados (S, G) y los mensajes de tipo JOIN / PRUNE (S, G) también son aplicables a los otros tres tipos de tráfico multicast y a sus mensajes PIM-SM correspondientes.
La máquina de estados de Ia Tabla 6 almacena Ia información de estado de cada tipo de tráfico multicast solicitado en unos registros que tienen Ia forma siguiente:
REGISTRO (Interface, Trafic_Type=(S,G) , Expiry_Timer, {(IP_Router, IP_Timer)} )
donde:
- Interface es Ia interfaz de red del router en Ia que se reciben los mensajes PIM-SM.
Trafic_Type es un parámetro que indica el tipo de tráfico multicast. La máquina de estados de Ia Tabla 6 se refiere al tipo de tráfico (S, G), donde S es Ia dirección IP de origen de Ia fuente y G Ia dirección IP del grupo multicast. Por eso se ha indicado Trafic_Type = (S, G). Sin embargo, podría ser igualmente cualquier otro entre los cuatro tipos de tráfico multicast mencionados anteriormente.
Expiry_Timer o ET es un timer que se reinicia cada vez que llega a Ia interfaz de red indicada en el campo Interface un mensaje de tipo JOIN referido al tipo de tráfico
indicado en el campo Trafic_Type. Si el timer Expiry_Timer llega a cero, el router deja de transmitir el tráfico indicado en el campo Trafic_Type (en este caso el tráfico (S, G)) por Ia interfaz de red indicada en el campo Interface.
- {(IP_Router, IP_Timer)} es una lista de elementos (IP_Router, IP_Timer), siendo
"IP_Router" Ia dirección IP del router que ha enviado el mensaje PIM-SM y siendo IP_Timer un timer asociado a cada IP_Router que se reinicia cada vez que Ia interfaz de red indicada en el campo Interface recibe un mensaje de tipo JOIN proveniente del router cuya IP es IP_Router. El valor que se utiliza para reiniciar el timer IP_Timer es el valor del parámetro "Holdtime" contenido en el mensaje
JOIN(S 1 G). El parámetro "holdtime" es un parámetro que se transmite en los mensajes JOIN(S 1 G) del protocolo PIM-SM 1 de forma conocida por un experto en Ia materia, y que indica el tiempo que el router que envía el mensaje Join(S,G) desea estar recibiendo el canal (S, G). La dirección IP del router que ha enviado el mensaje PIM-SM se extrae de Ia dirección de origen del datagrama IP que encapsula dicho mensaje PIM-SM.
En Ia máquina de estados de Ia Tabla 6, que como se ha dicho se refiere a una determinada interfaz de red del router y un determinado tipo de tráfico multicast (en este caso el tráfico de tipo (S, G)), Ia primera columna contiene un estado inicial del router, Ia segunda columna contiene un mensaje o evento, Ia tercera columna contiene el estado final del router como resultado de dicho mensaje o evento de Ia segunda columna y Ia cuarta columna contiene las acciones que realiza el router en cada caso.
Los estados en los que puede estar una interfaz de red "downstream" del router para un determinado canal multicast (S, G) son los dos siguientes:
Nl ("Nojnfo"). Este estado indica que Ia interfaz de red del router no tiene ninguna información que indique al router que debe transmitir el canal (S, G) por dicha interfaz de red. Por Io tanto, en el estado Nl el router no transmite el canal (S, G).
- JOIN ({IP}), donde {IP} es una lista de direcciones IP de routers PIM-SM que han enviado al router mensajes de tipo JOIN(S 1 G). En este estado, el router está
transmitiendo el canal (S, G) por dicha interfaz de red, porque hay un una serie de routers que Io han solicitado (los routers de Ia lista {IP}).
La Tabla 6 describe ocho procesos, numerados del 1 al 8 y separados entre sí por líneas discontinuas. Estos ocho procesos constituyen Ia máquina de estados "Downstream" (S, G) del router de Ia presente invención.
El proceso 1 se ejecuta cuando el router está en estado Nl y recibe un mensaje JOIN(S 1 G) de un router cuya IP es IP1. El router cambia al estado JOIN (IP1 ) e inicializa el timer T(IPI ) asociado Ia dirección IP1 y el timer Expiry_Timer o ET con el valor del parámetro "Holdtime" contenido en el mensaje JOIN(S 1 G) recibido. El router empieza a transmitir el canal multicast (S, G) por Ia interfaz de red por Ia cual ha recibido dicho mensaje JOIN(S 1 G).
El parámetro "Holdtime" de los mensajes PIM-SM 1 está descrito en el apartado "4.9.5 Join/Prune Message Format", de las RFC 4601 , e indica el tiempo en segundos durante el cual el router que recibe el mensaje debe mantener el estado "Joined" o "Pruned".
En el proceso 2, el router ya está transmitiendo el canal (S, G) y recibe un nuevo mensaje JOIN(S 1 G) de un router cuya IP 1 indicada como IP2, no está en su lista de direcciones IP del registro asociado al canal (S 1 G). En este caso, el router añade Ia dirección IP2 a su lista e inicia el valor del timer T(IP2) con el valor del parámetro "Holdtime" del mensaje recibido. Si el valor del timer ET es mayor que el parámetro "Holdtime" contenido en el mensaje JOIN(S 1 G) recibido, el timer ET no se modifica. En caso contrario, es decir cuando el timer ET tiene un valor menor que "Holdtime", se pone este valor "Holdtime" en el timer ET. Este funcionamiento se ha indicado en Ia tabla 6 mediante Ia expresión "ET -> HT". En este segundo proceso, el router continúa transmitiendo el canal (S, G).
En el proceso 3 el router recibe un mensaje JOIN(S 1 G) de un router cuya IP 1 que en este caso es IP1 , ya está en su lista. En este caso simplemente actualiza los timers T(IPI ) y ET tal como se ha explicado en el proceso 2, y continúa trasmitiendo el canal (S 1 G)
En el proceso 4, el router recibe un mensaje PRUNE(S 1 G) de un router cuya dirección IP 1 que en este caso es IP2, está en su lista, pero IP2 no es el único elemento de su lista. El router elimina IP2 de su lista y continúa transmitiendo el canal (S, G).
En el proceso 5, el router recibe un mensaje PRUNE(S 1 G) de un router cuya dirección IP, que en este caso es IP1 , es Ia última dirección que queda en el registro asociado al canal (S, G). En este caso el router elimina Ia dirección IP1 de Ia lista, deja de transmitir el canal (S, G) y cambia al estado Nl.
En el proceso 6, el timer T(IPI ) asociado a IP1 , que es el único elemento que hay en Ia lista IP, llega al valor cero. En este caso, el router elimina IP1 de Ia lista, deja de transmitir el canal (S, G) y cambia al estado Nl.
En el proceso 7, el timer T(IP2) asociado a una IP2, que no es el único elemento de Ia lista, llega al valor cero. En este caso, el router debe tener en cuenta si el router que envía los mensajes PIM-SM desde Ia dirección IP2 es un router que ha cancelado Ia supresión de mensajes o no. En el primer caso, el router elimina Ia dirección IP2 de Ia lista y en el segundo caso mantiene Ia dirección IP2 aunque el timer T(IP2) sea cero. Más adelante se describe cómo un router que implementa Ia presente invención sabe si los otros routers han cancelado Ia supresión de mensajes.
El proceso 8 muestra Io que sucede cuando el timer ET llega a cero. En este caso, el router elimina todas las IP de Ia lista, cambia al estado Nl y deja de transmitir el canal (S, G).
Los routers que implementan Ia presente invención pueden configurarse para cancelar siempre Ia supresión de mensajes periódicos, aunque existan routers en Ia red que no hayan anunciado su capacidad de cancelar Ia supresión de mensajes.
Además, los routers que implementan Ia presente invención disponen de un mecanismo para saber si los otros routers de una red implementan Ia presente invención o no. Esto es conveniente por dos motivos.
En primer lugar, un router "downstream" que implementa Ia presente invención necesita saber si un router "upstream" al cual envía mensajes PIM-SM implementa o no Ia presente invención. Por ejemplo, si un router R1 que implementa Ia presenta invención envía mensajes JOIN a un router R2, el router R1 necesita saber si el router R2 implementa Ia presente invención pues si el router R2 es del estado de Ia técnica anterior y otro router R3
envía un mensaje PRUNE al router R2 referido a un tráfico multicast que el router R1 desea seguir recibiendo, el router R1 debe enviar inmediatamente un mensaje JOIN para anular el efecto del mensaje PRUNE del router R3. En cambio, si el router R2 implementa Ia presente invención, el router R1 no tiene que preocuparse de los mensajes que envíen los demás routers, ya que el router R2 hace un seguimiento individual de las peticiones de cada router.
En segundo lugar, un router "upstream" que implementa Ia presente invención necesita saber si un router "downstream" que Ie envía mensajes PIM-SM implementa o no Ia presente invención y si el router "downstream" ha cancelado Ia supresión de mensajes aunque no todos los routers se hayan puesto de acuerdo para cancelar Ia supresión de mensajes.
En el mecanismo por defecto del estado de Ia técnica anterior, tal como se describe en las RFC 4601 , los routers no anuncian si han cancelado o no Ia supresión de mensajes, Io que anuncian es si tienen Ia capacidad de anular Ia supresión de mensajes. Sólo cuando todos los routers de una red han anunciado que tienen Ia capacidad de anular Ia supresión de mensajes proceden todos los routers de forma común a cancelar Ia supresión de mensajes.
En el proceso 7 de Ia Tabla 6, el router "upstream" sabe que el router "downstream" ha cancelado Ia supresión de mensajes si se da cualquiera de las dos circunstancias siguientes:
a) el router "downstream" ha comunicado que es un router que implementa Ia presente invención y si cancela o no los mensajes periódicos.
b) todos los routers de Ia red han anunciado su capacidad de cancelar Ia supresión de mensajes.
Para comunicar que implementan Ia presente invención y si suprimen o no los mensajes periódicos, los routers de Ia presente invención pueden anunciarlo en sus mensajes "Helio" que envían de forma periódica por todas sus interfaces de red donde ejecutan el protocolo PIM-SM.
Una primera forma de anunciarlo consiste en definir un nuevo bloque de datos de los denominados "Option" con un nuevo valor de OptionType en el mensaje "Helio". Los diferentes valores del parámetro OptionType de los mensajes "Helio" se explican en el apartado 4.9.2 de las RFC 4601 y actualmente varían de 1 a 20. Se puede utilizar un valor fuera de este rango, por ejemplo OptionType = 30, para anunciar que un router implementa Ia presente invención y utilizar uno de los campos o parámetros del nuevo mensaje para indicar si el router ha cancelado Ia supresión de mensajes periódicos.
Una segunda forma de anunciarlo consiste en utilizar el bloque de datos "LAN_PRUNE_Delay" y poner un valor especial en el parámetro Overridejnterval, por ejemplo los valores 0 y 1 que tienen poco sentido como valor de espera en milisegundos.
De esta forma, por ejemplo, cuando los routers de Ia presente invención reciben un mensaje "Helio" cuyo valor Overridejnterval es 0 saben que Io envía un router que implementa Ia presente invención y que ha cancelado Ia supresión de mensajes. Si reciben el valor 1 interpretan que el router que ha enviado el mensaje implementa Ia presente invención pero no ha cancelado Ia supresión de mensajes.
Volviendo al ejemplo de Ia Fig.4, supongamos que los routers 410, 420, 430, 440 y 450 son routers que implementan Ia presente invención. Cuando el host 460 envía un mensaje IGMPv3 o MLDv2 al router 450 para indicar que desea dejar de recibir el tráfico del canal (S, G), el router 450 envía un mensaje PRUNE(S 1 G) al router 440. Según Ia invención, el router 440 mantiene un registro del tráfico (S, G) solicitado en su interfaz de red 442 por cada uno de los routers de Ia línea de red multiacceso 445 que han solicitado tráfico enviando mensajes PIM-SM a dicho router 440. Gracias a ello, el router 440 sabe si hay algún router que todavía desea recibir el canal (S;G). Si no es el caso, cuando el router 440 recibe el mensaje PRUNE (S, G) enviado por el router 450, realiza inmediatamente las acciones siguientes: deja de transmitir tráfico multicast por su interfaz de red "downstream" 442 y envía al router 430 un mensaje PRUNE (S, G). El mismo proceso se produce sucesivamente en los routers 430, y 420: cuando cada uno de ellos recibe el mensaje PRUNE (S, G) del router "downstream", si su registro para el tráfico (S, G) solicitado en su interfaz de red "downstream", respectivamente 432 y 422, indica que no queda ningún router interesado en recibir el canal (S, G), de forma inmediata dicho router 430, 420 deja de enviar tráfico por su dicha interfaz de red "downstream" y envía un mensaje PRUNE (S, G) al router "upstream" siguiente. Cuando el router 410 recibe el mensaje PRUNE (S, G)
del router 420, realiza el mismo proceso que los routers 440, 430 y 420, con Ia diferencia de que no envía un mensaje PRUNE (S, G), ya que está conectado directamente a Ia fuente 400. Por Io tanto, a partir del momento en que el router 450 envía el primer mensaje PRUNE(S 1 G), si en las líneas de red multiacceso 445, 435, 425 y 415 no queda ningún otro router interesado en recibir el canal (S, G), el router 410 deja de transmitir el canal (S, G) de forma prácticamente inmediata. En efecto, el único retraso que se produce, además del inherente a Ia transmisión de los mensajes PRUNE a través de Ia red, que se realiza en un tiempo muy corto y de todas formas es inevitable, es el que corresponde al tiempo necesario para que cada router actualice y compruebe sus registros del tráfico multicast solicitado, según Ia invención. Pero éstas son operaciones que un router puede realizar en tiempos extremadamente cortos, como bien sabe un experto en Ia materia.
El seguimiento individual de las peticiones de cada router PIM-SM que se realiza gracias al router según Ia invención, además de las ventajas ya explicadas, tiene otras aplicaciones importantes. Por ejemplo, permite contabilizar o autorizar el tráfico multicast, Io que generalmente se denomina AAA ("Authentication, Autorization and Acounting"). Esto puede realizarse ventajosamente, por ejemplo, asociando información relativa a Ia AAA a cada elemento (IP_Router, IP_Timer) de Ia lista {(IP_Router, IP_Timer)} del registro de tráfico multicast de cada router. De esta forma, un router mejorado según Ia invención puede aplicar unas condiciones específicas relativas a Ia contabilización y/o a Ia autorización de transmisión de un tipo de tráfico multicast a un router determinado, identificado por Ia dirección IP_Router y para el cual dicho router mejorado tiene almacenada una información relativa a Ia AAA.
Tabla 2 (ESTADO DE LA TéCNICA): ejemplo de funcionamiento de un router IGMP del estado de Ia técnica que aplica el protocolo IGMPv3.
MENSAJE FUENTES CUYO ACCIONES QUE REALIZA ENVIADO POR TRáFICO EL ROUTER EL HOST TRANSMITE EL ROUTER
INCLUDE (Si; Sl T (Sl) =GMI ALLOW (S2) Sl, S2 T (Sl)=GMI BLOCK (Sl) Sl, S2 T (Sl)=LMQT ; SEND Q (G, Sl) ALLOW (S3) Sl, S2, S3 T (S3)=GMI BLOCK (S2) Sl, S2, S3 T (S2)=LMQT ; SEND Q (G, S2)
Tabla 3 (ESTADO DE LA TéCNICA): ejemplo de funcionamiento de un router IGMP del estado de Ia técnica que aplica el protocolo IGMPv3, cuando un host cambia de canal sucesivamente.
Tabla 4 : ejemplo de funcionamiento de un router IGMP mejorado según una primera forma de realización de Ia invención.
ESTADO 1 MENSAJE ESTADO 2 ACCIONES
1. INCLUDE (A) IS IN (B) INCLUDE (B) T (B)=GMI EXCLUDE (Y) EXCLUDE (Y) DEL (A-B)
2. INCLUDE (A) IS EX (B) INCLUDE (A) DEL (Y-B) EXCLUDE (Y) EXCLUDE (B) GT = GMI
3. INCLUDE (A) ALLOWIN (B) INCLUDE (A+B) T (B)=GMI EXCLUDE (Y) EXCLUDE (Y)
4. INCLUDE (A) BLOCKIN (B) INCLUDE (A-B) DEL (B) EXCLUDE (Y) EXCLUDE (Y)
5. INCLUDE (A) ALLOWEX (B) INCLUDE (A) DEL (B) EXCLUDE (Y) EXCLUDE (Y-B)
6. INCLUDE (A) BLOCKEX (B) INCLUDE (A) EXCLUDE (Y) EXCLUDE (Y+B)
Tabla 5: ejemplo de funcionamiento de un router IGMP mejorado según una segunda forma de realización de Ia invención.
ESTADO 1 MENSAJE ESTADO 2 ACCIONES
/ EVENTO
1. NI JOIN(S, G) JOIN (IPl) T (IPl) = HT FROM(IPl) ET = HT
2. J(IPl) JOIN(S, G) JOIN(IPl, IP2) T (IP2) = HT FROM ( I P2) ET -> HT
3. J(IPl) JOIN(S, G) JOIN (IPl) T (IPl) = HT FROM(IPl) ET -> HT
4. J(IPl, IP2) PRUNE (S, G) JOIN(IPl) DEL (IP2) FROM ( I P2)
5. J(IPl) PRUNE (S, G) NI DEL (IPl) FROM (IPl)
6. J(IPl) T (IPl) = O NI DEL (IPl)
7. J(IPl, IP2) T(IP2) = O JOIN(IP) IF [NSP (IP2) ] JOIN(IPl, IP2) DEL (IP2)
8. J(...) ET = O NI DEL ALL IP
Tabla 6 : Máquina de estados "dowstream" (S, G) de un router PIM-SM según Ia invención El significado de las abreviaciones en Ia Tabla 6 es el siguiente:
NI estado "Nojnfo"
J estado "JOIN" referido a las direcciones IP indicadas
T timer asociado a Ia dirección IP indicada ET timer εxpiry_Timer"
HT valor del parámetro "Holdtime" en el mensaje JOIN recibido
FROM mensaje enviado desde Ia dirección IP indicada
DEL borrar del registro Ia dirección IP indicada
DELL ALL IP borrar del registro todas las direcciones IP NSP el router de Ia dirección IP indicada no suprime mensajes
I F Ia acción se realiza si se cumple Ia condición indicada
Next Patent: PRE-CHAMBER ARRANGEMENT