ES2940469T3

ES2940469T3 - Método de comunicación TCP a través de múltiples rutas entre dos terminales

Info

Publication number: ES2940469T3
Application number: ES15742356T
Authority: ES
Inventors: Mohamed Boucadair; Christian Jacquenet
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2014-06-30
Filing date: 2015-06-29
Publication date: 2023-05-08
Anticipated expiration: 2035-06-29
Also published as: FR3023105A1; EP3162024A1; EP4398555A2; EP4142265A1; US10819830B2; US20170142231A1; WO2016001558A1; EP3162024B1

Abstract

Yb) el dispositivo cliente (T1) o dicho dispositivo repetidor (R) registra (E2) el estado (PATH CHECKED) de dicho camino en cuanto a la posible compatibilidad del mismo con conexiones multicamino. La invención se puede utilizar en el protocolo MPTCP (Multi-Path TCP). (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Método de comunicación TCP a través de múltiples rutas entre dos terminales

La presente invención se refiere al campo de las telecomunicaciones, y en particular, con las redes de comunicaciones capaces de poner en práctica el protocolo IP (Protocolo de Internet). Más en particular, la presente invención se refiere a la prestación de servicios en las redes IP de “valor añadido”, es decir, redes capaces de realizar tratamientos diferenciados en función de la naturaleza del tráfico de datos enrutados en la red.

La invención se aplica a cualquier tipo de dispositivo-cliente, tal como un terminal fijo o móvil, o una pasarela residencial ("Residential Gateway en inglés), o una pasarela ubicada en una empresa, o una pasarela de operador de red ^("Gateway ^{en inglés), o incluso un decodificador de TV (“Set-Top Box”, o STB en inglés). En aras de la brevedad, un}dispositivo-cliente de cualquier tipo a menudo se denominará "terminal" en lo sucesivo.

Los terminales, tales como teléfonos inteligentes ("smartphone" en inglés) y ordenadores personales ("Personal Computer', o PC en inglés) actualmente son capaces de activar y de utilizar varias interfaces lógicas enlazadas a una o varias interfaces físicas. Dichos terminales se denominan “multi-interfaces” (“Multi-Interface", o MIF en inglés). Cuando un terminal dispone de varias interfaces capaces de conectarlo a diferentes redes de acceso (por ejemplo: fija, móvil o WLAN), entonces se beneficia del denominado acceso "híbrido", porque combina diferentes tecnologías de red de acceso.

A continuación, se pueden asignar varias direcciones IP a estos terminales MIF para que puedan conectarse a diferentes tipos de redes, tales como una red fija, una red móvil o una red WLAN (iniciales de las palabras en inglés "Wireless Local Area Network que significa Red de Área Local Inalámbrica, de las que las redes Wi-Fi son un ejemplo emblemático), de forma simultánea o diferida. Estas direcciones IP pueden:

• pertenecer a la misma familia de direcciones o a diferentes familias de direcciones (IPv4, IPv6 o ambas),

• tener diferentes duraciones de vida,

• tener diferentes alcances, por ejemplo, dirección IPv4 privada, dirección IPv6 de dirección local única (Unique Local Address, o ULA en inglés) o dirección IPv6 de ámbito global (Global Unicast Address, o GUA en inglés), y

• ser asignadas a la misma interfaz de red lógica o a diferentes interfaces de red lógica.

Sin embargo, conviene señalar que la característica "MIF" es volátil, ya que la capacidad de utilizar varias interfaces depende de las condiciones de conexión a la(s) red(es), la ubicación del dispositivo, u otros factores. Un dispositivo MIF puede, en particular, utilizar la pluralidad de interfaces a su disposición durante el establecimiento de una conexión simple (es decir, una conexión establecida a lo largo de una única ruta con un corresponsal dado), o incluso después de establecer una conexión simple. También conviene señalar que un dispositivo no conoce a priori si es posible que utilice varias rutas distintas para establecer una conexión con un corresponsal dado; más concretamente, el dispositivo solamente adquiere esta información (si la hubiere) al final de una fase durante la cual intenta establecer una conexión utilizando múltiples rutas con el corresponsal.

Conviene señalar que una "conexión de múltiples rutas" es una conexión que se establece entre dos dispositivos de manera simultánea utilizando una o más rutas entre estos dos dispositivos. Dicha conexión obedece a un protocolo dedicado, tal como MPTCP (Multi-Path TCP, en inglés), que de manera opcional se puede definir como una extensión de un protocolo de transporte previamente definido, tal como TCP (iniciales de las palabras en inglés "Transmission Control Protocol' que significa "Protocolo de Control de Transmisión"). Dicho de otro modo, una conexión de múltiples rutas es un conjunto de una o más conexiones simples que toman la misma ruta o rutas diferentes (parcial o completamente disjuntas).

Conviene señalar asimismo que el protocolo TCP, definido en particular en la especificación RFC 793 del IETF (Grupo de Trabajo de Ingeniería de Internet, “Internet Engineering TaskForce", en inglés), es uno de los principales protocolos utilizados por los terminales conectados a una red IP (por ejemplo, Internet), de manera que la literatura técnica a menudo se refiere al conjunto de protocolos "TCP/IP". El protocolo TCP permite transmitir, de forma fiable, ordenada y sin errores, un flujo de datos digitales entre aplicaciones ejecutadas en terminales conectados a una red local (por ejemplo, Intranet) o a Internet. Funciona en la capa de transporte del modelo OSI. Los navegadores web utilizan el protocolo TCP cuando se conectan a servidores remotos; el protocolo TCP también se utiliza para transmitir el correo electrónico o para transferir archivos desde un lugar a otro. Protocolos tales como HTTP, HTTPS, SMTP, POP3, IMAP, SSH, FTP, Telnet y muchos otros protocolos se transportan a través de conexiones TCP. Una conexión TCP se identifica por la dirección y por el número de puerto del terminal de origen y la dirección y el número de puerto del terminal de destino.

Dos terminales pueden insertar "opciones TCP" en los mensajes TCP intercambiados entre ellos, con el fin, por ejemplo, de optimizar la calidad de la transmisión TCP. Dichas opciones ocupan el espacio disponible al final del encabezado TCP y tienen una longitud (“length”, en inglés) expresada en bytes. El tipo (“kind”, en inglés) es un identificador único que describe la naturaleza de la opción TCP. Por ejemplo, el valor “0” indica el final de la lista de las opciones, y el valor “2” indica el tamaño máximo del segmento TCP (“‘Máximum Segment Size”, o MSS en inglés).

La llegada de los terminales MIF introduce una complejidad adicional para utilizar la totalidad o parte de las direcciones IP asignadas a través de las redes disponibles. En particular, habida cuenta que las conexiones TCP están asociadas a una dirección IP y un número de puerto, cualquier modificación de al menos uno de estos datos puede penalizar el funcionamiento de una conexión TCP en curso y, por lo tanto, el servicio que utiliza dicha conexión TCP. Este cambio es especialmente perjudicial cuando al terminal se le asigna una nueva dirección IP, o porque el terminal se conecta a otra red, o incluso cuando la interfaz, a la que está asociada la dirección IP, ya no está disponible. Por ejemplo, los medios para informar a un corresponsal TCP remoto que una dirección IP ya no es válida, son entonces necesarios para asegurar el mantenimiento de una conexión existente.

El grupo de trabajo mptcp de IETF se encargó en 2009 de especificar extensiones del protocolo TCP capaces de adaptarse a las restricciones impuestas por la posibilidad de asignar varias direcciones IP a las diferentes interfaces lógicas o físicas de un terminal. Este grupo de trabajo publicó las primeras especificaciones del protocolo MPTCP (cf. A. Ford, C. Raiciu y M. Handley, “Extensiones TCP para operaciones de múltiples rutas con múltiples direcciones”, RFC 6824, enero de 2013), que algunos teléfonos inteligentes y algunos sistemas operativos ya son capaces de poner en práctica. El IETF está considerando avanzar en el estado de las especificaciones MPTCP actuales para convertirlas en verdaderos estándares según lo definido por el IETF.

Por lo tanto, el protocolo MPTCP ha sido propuesto para minimizar los riesgos de una interrupción intempestiva de una conexión TCP vinculada a dichas modificaciones de direccionamiento y, de manera más general, para cumplir con los requisitos planteados por un contexto en donde un terminal tiene la capacidad de conectarse a una o más red(es) a través de una o más interfaces. El protocolo MPTCP responde, en particular, a la necesidad de asegurar una continuidad de la sesión en caso de movilidad del terminal. Se pueden considerar diferentes casos de uso para el protocolo MPTCP, tales como:

• reenviar el tráfico entre múltiples puntos de acceso WLAN,

• descargar una red móvil y cambiar el tráfico a un punto de acceso WLAN,

• agregar enlaces de acceso múltiple,

• distribuir la carga entre múltiples rutas, y

• optimizar el uso de los recursos de la red.

Se recuerda a este respecto (cf. Wikipedia) que la "agregación de enlaces" es, en el campo de las redes, un concepto que describe la agrupación de varias interfaces de red como si fuera una sola, con el objetivo de aumentar el rendimiento más allá de los límites de un único enlace, y posiblemente para garantizar que otras interfaces tomen el relevo si falla un enlace de red (principio de redundancia).

Un ejemplo particularmente ventajoso de aplicación del protocolo MPTCP es la transferencia de archivos grandes utilizando los recursos del protocolo FTP (Protocolo de Transferencia de Archivos, “File Transfer Protocol”, en inglés). Un dispositivo que actúa como cliente FTP puede utilizar de manera dinámica el conjunto de rutas disponibles que le permiten acceder a un servidor FTP, siempre que este último sea capaz de poner en práctica las distintas conexiones MPTCP establecidas por el cliente FTP. El tiempo de transferencia de datos se reduce de manera significativa en comparación con una conexión TCP.

En el contexto de MPTCP, se denomina "sub-sesión" (“sub-floW en inglés) a una conexión TCP basada en el uso de uno de los pares (dirección IP, número de puerto) disponibles. Por lo tanto, una conexión MPTCP es un agregado de sub-sesiones TCP. A modo de ejemplo, la Figura 1 muestra una conexión MPTCP entre un terminal A y un terminal B; la sub-sesión inicial se establece entre la dirección A1 del terminal A y la dirección B1 del terminal B; posteriormente, se establece una sub-sesión adicional entre la dirección A2 del terminal A y la dirección B1 del terminal B.

Los sistemas operativos presentan aplicaciones con interfaces dedicadas, denominadas API (Interfaz de Programación de Aplicaciones, “Application Programming Interface" en inglés) para interactuar con las capas TCP e IP. La API clásica que se presenta a las aplicaciones TCP/IP es la interfaz "socket'. Una "socket' se caracteriza por diversos "atributos" tales como "Dirección de Socket Local', "Dirección de Socket Remota" y "Protocolo". El IETF ha especificado nuevas extensiones (API de MPTCP) en el documento RFC 6897 para permitir que las aplicaciones controlen las conexiones de MPTCP. Conviene señalar que la API de MPTCP es una extensión de la API de TCP.

El término "tabla de conexión MPTCP" se refiere a una estructura de software utilizada para agrupar todas las sub sesiones TCP asociadas a una misma conexión MPTCP. Se pueden utilizar varios atributos para caracterizar una tabla de conexiones MPTCP, además de los atributos clásicos de TCP/IP mencionados con anterioridad, se asigna un valor a los atributos específicos del protocolo MPTCP. El valor de estos atributos de la tabla de conexiones se controla mediante la interfaz API de MPTCP.

Una conexión MPTCP se inicializa como cualquier conexión TCP convencional, excepto que la opción MP_CAPABLE (lo que significa que el terminal emisor es compatible con las extensiones MPTCP) se incluye en el mensaje que contiene la señalización de inicialización de la conexión (SYN) y en los mensajes posteriores. Un terminal MPTCP puede notificar al terminal remoto la disponibilidad de una dirección IP adicional mediante la opción ADD_ADDR, sin necesidad de crear una sub-sesión asociada.

Sin embargo, la señalización de varias direcciones IP disponibles y susceptibles de ser utilizadas para comunicarse con un corresponsal puede llevar al fracaso del establecimiento de ciertas sub-sesiones TCP debido a que las direcciones IP externas percibidas por los terminales remotos pueden no ser las mismas que las visibles a nivel local. Por esta razón, la opción ADD_ADDR del protocolo MPTCP incluye un identificador de dirección (Dirección ID "Address ID", en inglés) que se utiliza para identificar, sin ambigüedad, una dirección IP disponible. Esta disposición se supone, según el estado de la técnica, para evitar los problemas inducidos por la presencia de un NAT (siglas de las palabras inglesas "NetworkAddress Translator' que significan "Traductor de Dirección de Red") en la ruta seguida por los paquetes entre los dos terminales que han establecido una conexión MPTCP. La opción ADD_ADDR también se utiliza para transmitir un número de puerto en caso de que una de los terminales MPTCP no utilice el mismo número de puerto para el conjunto de todas las direcciones IP disponibles.

De manera similar, el protocolo MPTCP proporciona disposiciones que se supone que deben permitir, en particular, el cruce de cortafuegos (“firewall” en inglés). Más concretamente, la especificación del protocolo MPTCP establece que los números de secuencia indicados en la cabecera TCP son los específicos de cada sub-sesión, mientras que el número de secuencia indicado en la DSS (Señal de Secuencia de Datos, “Data Sequence Signa!’ en inglés) del protocolo MPTCP se utiliza para asociar estas sub-sesiones a la misma conexión MPTCP.

El protocolo MPTCP pretende así hacer frente a la proliferación masiva de “middle boxes" (equipos intermedios en una cadena de comunicación), tales como los NAT y cortafuegos, en las redes actuales. Además, en el documento RFC 6824 se establece que, si falla un intento de establecimiento de una conexión MPTCP, la conexión cambia de manera automática a una conexión TCP simple.

El documento de D. Wing et al. publicado por el IETF y titulado “Selección de múltiples rutas TCP (MPTCP) mediante PCP; draf-wing-mptcp-pcp-00.txt", páginas 1 a 10, 7 de octubre de 2013, describe un protocolo que permite que una API de MPTCP seleccione una ruta cuando existen varias rutas disponibles a través de las extensiones del Protocolo de Control de Puertos (PCP).

El documento de A. Ford et al. publicado por el IETF y titulado "Extensiones de TCP para operación de múltiples rutas con múltiples direcciones", páginas 1 a 64, enero de 2013, presenta un conjunto de extensiones para el protocolo TCP para admitir la operación con múltiples rutas.

El documento de G. Hampel et al. publicado por el IETF y titulado “Proxies MPTCP y anclajes; draft-hampel-mptcpproxies-anchors-00.txt”, páginas 1 a 30, 8 de febrero de 2012, se refiere al soporte de servidores proxy MPTCP y nodos de anclaje en una red.

Desafortunadamente, a pesar de todas estas precauciones, pueden surgir otros problemas al intentar establecer una conexión MPTCP. Por ejemplo:

- algunas o todas las opciones de MPTCP pueden ser filtradas (es decir, eliminadas) por nodos intermedios (por ejemplo, NAT o un cortafuegos) ubicados a lo largo del flujo entre dos pares de MPTCP, tal como se muestra en la Figura 2;

- incluso si los mensajes SYN MPTCP (mencionados con anterioridad) se intercambian de manera satisfactoria entre dos pares MPTCP, pudiendo los nodos intermedios filtrar las opciones DSS (mencionadas con anterioridad) de los paquetes de datos; en este caso, tal como se ilustra en la Figura 3, el intento de establecer una conexión MPTCP no puede tener éxito, con la consecuencia de volver a una conexión TCP simple como en el caso ilustrado con referencia a la Figura 2;

- puede ocurrir que se establezca de manera satisfactoria una primera sub-sesión TCP, pero que falle el establecimiento de sub-sesiones posteriores por la existencia de múltiples rutas compatibles con las extensiones MPTCP.

Sin embargo, los autores de la presente invención se dieron cuenta de que la presencia de dichos nodos intermedios tenía el efecto de prolongar de manera significativa el retardo de establecimiento de sub-sesiones TCP y, en consecuencia, tenía un impacto negativo en la calidad del servicio de comunicación, según lo percibido por el usuario.

Por tanto, la presente invención se refiere a un método de comunicación según la reivindicación 1.

Conviene señalar que la invención puede ser puesta en práctica por cualquier dispositivo-cliente compatible con TCP. Este dispositivo-cliente puede tener una o más direcciones externas, o una o más interfaces de red (lógicas o físicas). Pero este dispositivo-cliente solamente puede tener una interfaz si está ubicado detrás de un dispositivo de retransmisión (tal como un enrutador o una pasarela residencial) conectado a una o más red(es) y compatible con las opciones TCP de múltiples rutas.

Los dispositivos comunicantes considerados (dispositivos de cliente y dispositivos de retransmisión) pueden ser de cualquier tipo, por ejemplo, un terminal, un enrutador o una pasarela residencial.

Gracias a la invención, estos dispositivos comunicantes pueden descubrir las capacidades de cualquier "equipo intermedio" (tal como se mencionó con anterioridad), y anticipar el fallo de las conexiones de múltiples rutas. Lo que antecede da como resultado una reducción en la demora para establecer conexiones de múltiples rutas y, por lo tanto, de manera obvia, una calidad significativamente mejorada de la experiencia del usuario.

Además, dicho dispositivo comunicante puede:

• ajustar su comportamiento en función de su conexión a la red (por ejemplo, en caso de conexión a una nueva red, indisponibilidad de una interfaz de red o detección de un "dispositivo intermedio"), y

• decidir, sin correr el riesgo de degradar la calidad de la comunicación con su corresponsal, activar una conexión de múltiples rutas, o desactivar una conexión de múltiples rutas en curso o todas sus conexiones de múltiples rutas en curso, o incluso añadir una nueva sub-sesión TCP a una conexión de múltiples rutas en curso.

Además, dicha conexión de múltiples rutas podrá, de manera ventajosa, cumplir con el protocolo MPTCP, para beneficiarse de las disposiciones, brevemente mencionadas con anterioridad, de este protocolo.

De conformidad con la invención, durante la etapa a) de la reivindicación 1, el dispositivo-cliente, respectivamente el dispositivo de retransmisión, recibe dicha información dentro de un mensaje no solicitado emitido por dicho nodo intermedio.

Gracias a estas disposiciones, la recepción de dicha información por el dispositivo-cliente o el dispositivo de retransmisión es automática.

Según características particulares:

- el dispositivo-cliente, respectivamente el dispositivo de retransmisión, transmite una solicitud a otro nodo intermedio colocado en otra ruta que conecta dicho dispositivo-cliente, respectivamente el dispositivo de retransmisión a dicho otro dispositivo-cliente, y

- durante dicha etapa a), recibe información relativa a la compatibilidad o incompatibilidad con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte de dicho otro nodo intermedio dentro de un mensaje de respuesta transmitido por dicho otro nodo intermedio.

Gracias a estas disposiciones, el dispositivo-cliente o el dispositivo repetidor puede obtener dicha información cada vez que la necesita.

Conviene señalar que un dispositivo comunicante (tal como un dispositivo-cliente o un dispositivo de retransmisión) puede ser capaz de poner en práctica las dos variantes brevemente descritas con anterioridad, o solamente una de ellas. Además, un dispositivo comunicante puede utilizar una de estas dos variantes para una parte de las múltiples rutas disponibles, y utilizar cualquier tercera variante para verificar la compatibilidad de las otras rutas con las conexiones de múltiples rutas; el dispositivo comunicante puede proceder de esta manera en particular cuando algunos de los nodos intermedios descubiertos no son capaces de poner en práctica ninguna de las dos variantes brevemente explicadas con anterioridad.

Según otras características particulares, si el dispositivo-cliente, respectivamente dicho dispositivo de retransmisión, constata que ninguno de las rutas que conectan el dispositivo-cliente con dicho otro dispositivo-cliente es compatible con conexiones de múltiples rutas, dicho método comprende, además, una etapa durante la cual el dispositivo-cliente utiliza una conexión TCP simple a:

- establecer una conexión con dicho otro dispositivo-cliente, o

- conectarse al otro dispositivo-cliente, después de recibir un mensaje de establecimiento de conexión de múltiples rutas desde el otro dispositivo-cliente.

Gracias a estas disposiciones, se evita la demora que podría causar un intento de establecer una conexión de múltiples rutas por una ruta incompatible con dicha conexión.

Por otro lado, si el dispositivo-cliente, respectivamente dicho dispositivo de retransmisión, constata que al menos una de las rutas que conectan el dispositivo-cliente con dicho otro dispositivo-cliente es compatible con conexiones de múltiples rutas, dicho método comprende, además, un etapa en donde el dispositivo-cliente, respectivamente el dispositivo de retransmisión, utiliza un protocolo de conexión de múltiples rutas para comunicarse con dicho otro dispositivo-cliente a lo largo de dicha ruta compatible con las conexiones de múltiples rutas.

En particular, los dos pares podrán establecer entre ellos una conexión de múltiples rutas a lo largo de una ruta anteriormente considerada incompatible con dicha conexión si han cambiado las circunstancias que con anterioridad causaron un retroceso a una conexión TCP simple.

Conviene señalar que la invención está dirigida en particular al caso en donde existen al menos dos rutas de comunicación posibles entre un primer dispositivo-cliente y un segundo dispositivo-cliente, incluso si solamente existe una sola ruta utilizable al inicializar una conexión TCP. De manera preferible, la invención se podrá en práctica para cada una de las posibles rutas de comunicación entre los dos dispositivos-cliente, siguiendo el descubrimiento de esta ruta por uno u otro de estos dispositivos-cliente; lo que antecede aprovechará al máximo las posibilidades que ofrecen las conexiones de múltiples rutas.

De manera correlativa, la invención se refiere a varios dispositivos.

Se refiere en consecuencia, en primer lugar, a un dispositivo comunicante según la reivindicación 6.

Según características particulares, dicho dispositivo comunicante comprende, además, medios para:

- enviar una solicitud a otro nodo intermedio ubicado en otra ruta que conecta dicho dispositivo comunicante con dicho otro dispositivo comunicante, y

- recibir información relativa a la compatibilidad o incompatibilidad con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte de dicho otro nodo intermedio dentro de un mensaje de respuesta transmitido por dicho otro nodo intermedio.

Según otras características particulares, dicho dispositivo comunicante comprende un dispositivo-cliente, tal como un terminal de usuario.

Según características aún más particulares, dicho dispositivo comunicante comprende, además, medios para:

- constatar que ninguna ruta que conecta dicho dispositivo comunicante con dicho otro dispositivo-cliente, es compatible con las conexiones de múltiples rutas, y

- utilizar una conexión TCP simple para:

• establecer una conexión con el otro dispositivo-cliente, o

• conectarse al otro dispositivo-cliente, a continuación de recibir un mensaje de establecimiento de conexión de múltiples rutas desde el otro dispositivo-cliente.

Según otras características aún más específicas, dicho dispositivo comunicante comprende, además, medios para: - constatar que al menos una ruta que conecta dicho dispositivo comunicante con dicho otro dispositivo-cliente es compatible con conexiones de múltiples rutas, y

- utilizar un protocolo de conexión de múltiples rutas para comunicarse con el otro dispositivo-cliente a lo largo de dicha ruta compatible con las conexiones de múltiples rutas.

Según otras características particulares, dicho dispositivo comunicante comprende un dispositivo de retransmisión, tal como un enrutador o una pasarela residencial, conectado a un dispositivo-cliente.

- constatar que ninguna ruta que lo conecte a dicho otro dispositivo-cliente es compatible con conexiones de múltiples rutas, y

- si recibe un mensaje de inicio de conexión de múltiples rutas desde dicho dispositivo-cliente al otro dispositivocliente, respondiendo al dispositivo-cliente sin utilizar un protocolo de conexión de múltiples rutas en su respuesta.

En virtud de estas disposiciones, el dispositivo-cliente al que está conectado el dispositivo de retransmisión cambia, sin demora, a una conexión TCP simple.

Las ventajas que ofrecen estos dispositivos comunicantes son esencialmente las mismas que ofrecen los métodos correlativos descritos brevemente con anterioridad.

La invención también se refiere, en segundo lugar, a un nodo de una red IP. Dicho nodo está conforme la reivindicación 13.

En una forma de realización particular, dicho nodo comprende, además, medios para:

- recibir de un dispositivo comunicante, en ausencia de cualquier conexión de múltiples rutas establecida por dicho dispositivo comunicante en una ruta que pasa por dicho nodo, una solicitud relativa a la posible compatibilidad del nodo con conexiones de múltiples rutas, y

- responder a dicho dispositivo comunicante con un mensaje que contiene información sobre la compatibilidad del nodo, en su caso, con conexiones de múltiples rutas.

Estos nodos pueden comprender, por ejemplo, un NAT o un cortafuegos.

Las ventajas que ofrecen estos nodos son esencialmente las mismas que ofrecen los métodos correlativos descritos brevemente con anterioridad.

Conviene señalar que es posible realizar estos diversos dispositivos en el contexto de instrucciones de software y/o en el contexto de circuitos electrónicos.

La invención también se refiere, según la reivindicación independiente 14, a un medio de almacenamiento y según la reivindicación 15 a un programa informático descargable desde una red de comunicaciones y/o almacenado en un medio legible por ordenador y/o ejecutable por un microprocesador. Este programa informático es notable porque comprende instrucciones para la ejecución de las etapas del método de comunicación brevemente descrito con anterioridad, cuando se ejecuta en un ordenador.

Las ventajas ofrecidas por este programa informático son esencialmente las mismas que ofrece dicho método.

Otros aspectos y ventajas de la invención aparecerán con la lectura de la siguiente descripción detallada de formas de realización particulares, dada a título de ejemplos no limitativos. La descripción se refiere a las figuras adjuntas, en las que:

- la Figura 1, descrita con anterioridad, representa un conjunto de sub-sesiones TCP que forman una conexión simple MPTCP,

- la Figura 2, descrita con anterioridad, muestra el fallo de un intento de establecer una sub-sesión MPTCP al terminal B desde el terminal A, a continuación del filtrado de las opciones MPTCP por parte de los nodos intermedios,

- la Figura 3, descrita con anterioridad, muestra el fallo de un intento de establecer una sub-sesión MPTCP al terminal B desde el terminal A, a continuación del filtrado de las opciones de señales DSS por parte de los nodos intermedios,

- la Figura 4 ilustra un ejemplo de aplicación de la invención a una configuración de red que comprende tres terminales T1, T2 y T3,

- la Figura 5 ilustra las sub-sesiones TCP establecidas entre los terminales T1 y T3 de la Figura 4, y

- la Figura 6 ilustra un ejemplo de aplicación de la invención a una configuración de red que comprende un terminal colocado detrás de un dispositivo de retransmisión.

El descubrimiento de las distintas rutas que conectan un determinado terminal con un determinado corresponsal puede realizarse, por ejemplo, mediante un protocolo de asignación dinámica de direcciones IP tal como DHCP (Protocolo de Configuración Dinámica de Concentrador, “Dynamic Host Configuration Protocol, en inglés), o mediante un mecanismo de creación de asignación “mapping", tales como Protocolo de Control de Puertos, PCP (“Port Control Protocol, en inglés), UPnP (Universal Plug and Play), IGD (Dispositivo de Pasarela de Internet, “Internet Gateway Device" en inglés) o el protocolo STUN (Session Traversal Utilities for NAT). En este sentido, se recuerda que la asociación de una dirección IP interna y de un número de puerto interno con una dirección IP externa y un número de puerto externo se denomina “mapping”. En el caso de una función NAT, la dirección IP interna y el número de puerto interno son la información que sirve como datos de entrada, mientras que la función NAT asigna la dirección IP externa y el número de puerto externo. En el caso de un cortafuegos (firewall), las informaciones internas y externas son idénticas. Un mapping puede incluir otra información, tal como la dirección IP y el número de puerto del corresponsal o un identificador del protocolo de comunicación utilizado.

Conviene señalar que la invención puede ser puesta en práctica tanto por un primer dispositivo-cliente como por un segundo dispositivo-cliente con el que el primer dispositivo-cliente desee establecer una conexión de múltiples rutas, o por solamente uno de ellos; en el segundo caso, el otro dispositivo-cliente puede entonces, de manera opcional, poner en práctica otro método diferente al método según la invención para comprobar la compatibilidad de las rutas que conectan estos dos dispositivos-cliente con las conexiones de múltiples rutas.

La invención propone un nuevo atributo a incluir en las tablas de conexiones de múltiples rutas. Este atributo, que se denominará “PATH_CHECKED”, se valora en “1” para indicar que una sub-sesión TCP es compatible con las extensiones a múltiples rutas, y se valora en “0” en caso contrario.

La invención se aplica, en general, a cualquier protocolo relacionado con conexiones de múltiples rutas. A continuación, se describirá la aplicación de la invención al protocolo MPTCP descrito brevemente con anterioridad. En particular, la API MPTCP, mencionada con anterioridad, debe modificarse para que el valor del atributo PATH_CHECKED, según la invención, pueda transmitirse a las aplicaciones.

El protocolo MPTCP de manera convencional incluye una serie de disposiciones, incluida, en particular, la definición de las siguientes opciones de TCP:

• MP_CAPABLE: esta opción se utiliza para señalar al terminal remoto que el terminal emisor es compatible con las opciones de MPTCP;

• ADD_ADDR: esta opción se utiliza para agregar una nueva dirección; incluye un campo opcional de dos bytes que permite proporcionar también un número de puerto, si fuere necesario;

• REMOVEADDR: esta opción se utiliza para eliminar una dirección;

• MP_PRIO: esta opción se utiliza para modificar la prioridad de una conexión;

• MP_JOIN: esta opción se utiliza para identificar la conexión TCP que está asociada al establecimiento de una nueva sub-sesión;

• MP_FAIL: esta opción se utiliza para volver al modo TCP sin opciones MPTCP; y

• MP_FASTCLOSE: esta opción se utiliza para cerrar rápidamente una conexión MPTCP.

El protocolo MPTCP se puede activar en varios modos:

- modo nativo: dos terminales MPTCP establecen todas las sub-sesiones que corresponden a los números de las direcciones/puertos disponibles, y utilizan el conjunto de estas sub-sesiones;

- modo primario: dos terminales MPTCP señalan sub-sesiones, pero solamente un subconjunto de estas sub sesiones se utiliza realmente para la transferencia de datos;

- modo secundario: en caso de indisponibilidad (o sobrecarga) del subconjunto “primario” de sub-sesiones, se solicita entonces a un subconjunto “secundario” de sub-sesiones para garantizar la continuidad de la conexión MPTCP; y

- modo de retroceso: dos terminales MPTCP utilizan una única sub-sesión; en caso de fallo, el tráfico se conmuta a una nueva sub-sesión creada para este propósito.

A continuación, se describirá una forma de realización del método de comunicación según la invención. Esta forma de realización, que se supone puesta en práctica por un terminal T capaz de aprovechar los recursos del protocolo MPTCP, comprende las siguientes etapas.

Durante una etapa E1, el terminal T recibe información relativa a las capacidades, en términos de compatibilidad con las opciones del MPTCP, de los nodos intermedios (por ejemplo, NAT, cortafuegos, y así sucesivamente) colocados en flujo cortado en rutas que permitan llegar al terminal.

Según una primera variante (modo "ANNONCE"), un nodo intermedio difunde información relativa a su posible compatibilidad con las opciones del MPTCP utilizando mensajes del tipo proporcionado, por ejemplo, por el protocolo SLP (Protocolo de Ubicación del Servicio) o del tipo ANNOUNCE PCP (Protocolo de Control de Puertos). Cada mensaje de este tipo contiene un indicador (MPTCP_STATUS) que se utiliza para notificar a los terminales la compatibilidad del nodo intermedio con las conexiones MPTCP. El nodo intermedio transmite estos mensajes, por ejemplo, a intervalos regulares (por ejemplo, 30 minutos), o en caso de arranque o reinicio del nodo intermedio, o en caso de actualización de software o modificación de la configuración del nodo intermedio, o posterior a la detección de la conexión de un terminal a la red.

Según una segunda variante (modo "PULL"), el terminal T en primer lugar procede al descubrimiento de los nodos intermedios, luego transmite una solicitud a cada nodo intermedio así descubierto (por ejemplo, utilizando un protocolo tal como PCP) para recuperar información sobre la posible compatibilidad del nodo intermedio con las opciones del MPTCP. En respuesta a dicha solicitud, el nodo intermedio responde con un mensaje que contiene un indicador (MPTCP_STATUS) que sirve para notificar al terminal solicitante su estado en relación con la compatibilidad de este nodo intermedio con las conexiones MPTCP.

Este indicador MPTCP_STATUS se puede definir, por ejemplo, tal como sigue. El valor de '0' indica que todas las opciones de MPTCP son filtradas (es decir, suprimidas) por el nodo intermedio. El valor de "1" indica que el nodo intermedio puede interpretar todas las opciones de MPTCP. Se pueden definir valores distintos a "0" o "1" para indicar explícitamente la lista de opciones que el nodo intermedio es capaz de interpretar, en caso de que el nodo intermedio solamente filtre algunas de las opciones del MPTCP.

Durante una etapa E2, el terminal registra, para cada nodo intermedio descubierto, si dicha ruta es, o no, compatible con las conexiones MPTCP. En esta forma de realización:

- si MPTCP_STATUS==1, la ruta que pasa por este nodo intermedio se declara compatible con el establecimiento y uso de conexiones MPTCP; el terminal T actualiza su tabla de conexiones MPTCP colocando el atributo PATH_CHECKED en "1" para indicar que esta ruta es compatible con el modo de comunicación de múltiples rutas;

- si MPTCP_STATUS!=1, la ruta que pasa por este nodo intermedio se declara incompatible con las comunicaciones MPTCP; el terminal T actualiza su tabla de conexiones MPTCP colocando el atributo PATH_CHECKED en “0” para indicar que esta ruta no es compatible con el modo de comunicación de múltiples rutas.

A continuación, durante cada conexión a una nueva red o cuando se detecta un nuevo nodo intermedio, el terminal T pone en práctica la siguiente etapa E3:

- si ninguna de las rutas que permiten llegar al terminal T es compatible con conexiones MPTCP (es decir, si el atributo PATH_CHECKED de todas las múltiples rutas está puesto a "0"):

° el terminal T utiliza el modo de transporte TCP simple para establecer conexiones salientes con sus corresponsales TCP (es decir, el modo TCP de múltiples rutas es desactivado por este terminal mientras no se modifiquen de manera favorable las condiciones de conexión a la red), y

° para una conexión de múltiples rutas entrante, el terminal T no incluye opciones MPTCP en sus mensajes destinados a su corresponsal (dicho de otro modo, el terminal se comporta como si no fuera compatible con MPTCP); tras la recepción de un mensaje de este tipo sin opciones MPTCP por parte del corresponsal del terminal T1, el corresponsal cambia sin demora a una conexión TCP simple, de conformidad con el “modo de retroceso” convencional; y

- si existe al menos una ruta compatible con las conexiones MTPCP (es decir, si el atributo PATH_CHECKED de al menos uno de las múltiples rutas está valorado en "1"), el terminal T utiliza las opciones del MPTCP para establecer conexiones de múltiples rutas con un corresponsal a lo largo de las rutas compatibles; al hacerlo, el terminal T se abstiene de anunciar a este corresponsal rutas que sean incompatibles con las conexiones MPTCP, para evitar el fracaso de un intento de establecer una conexión de múltiples rutas a lo largo de una de estas rutas incompatibles.

La Figura 4 ilustra un ejemplo de aplicación de la invención a una configuración de red que comprende tres terminales T1, T2 y T3. En esta Figura se constata que:

• un terminal T1 conectado a una o más redes IP a través de n nodos de conexión (F1, F2, ..., Fn) y n respectivas redes de acceso R1, R2, ..., Rn; estos nodos de conexión pueden alojar funciones NAT, cortafuegos, y así sucesivamente, o ser enrutadores IP que no incorporen ninguna función de servicio avanzada, tal como NAT o cortafuegos;

• un terminal T2 conectado a una red IP a través de un único nodo de conexión; se supone que T2 es compatible con MPTCP y que se le ha asignado una dirección IP única; y

• un terminal T3 conectado a una o más redes IP a través de m nodos de conexión (Fa, Fb, Fm); estos nodos pueden alojar funciones NAT, cortafuegos, y así sucesivamente, o ser enrutadores IP que no incorporen ninguna función de servicio avanzada, tal como NAT o un cortafuegos.

El terminal T1 inicializa el procedimiento de detección de capacidad funcional según esta forma de realización. Al final de este procedimiento, T1 concluye que:

° F1 filtra las opciones de MPTCP,

° F2 solamente filtra las opciones de MPTCP de los paquetes de datos, y

° Fn no filtra ni modifica ninguna de las opciones de MPTCP.

T3 inicializa el procedimiento de detección de capacidad funcional según esta forma de realización. Al final de este procedimiento, T3 concluye que:

° Fa filtra las opciones de MPTCP,

° Fb no filtra ni modifica ninguna de las opciones de MPTCP, y

° Fm no filtra ni modifica ninguna de las opciones de MPTCP.

Las rutas MPTCP válidas entre T1 y T3 son entonces las siguientes:

- la ruta que pasa por Fn y Fb, y

- la ruta que pasa por Fn y Fm.

Los terminales T1 y T3 no podrán utilizar MPTCP si se seleccionan rutas distintas de estas dos rutas para intercambiar datos entre T1 y T3.

Se supone a continuación que el terminal T1 desea establecer una conexión MPTCP con el terminal T3. La Figura 5 ilustra las sub-sesiones TCP establecidas entre T1 y T3.

El terminal T1 indica a su corresponsal que es compatible con conexiones MPTCP, pero solamente anuncia la ruta que implica Fn. El terminal T3 indica a su corresponsal que es compatible con conexiones de múltiples rutas, pero solamente anuncia las rutas que implican a Fb y Fm. De este modo, T1 y T3 pueden establecer:

- una sub-sesión TCP que implique a Fn (lado T1) y Fb (lado T3), y

- una sub-sesión TCP que implique a Fn (lado T1) y Fm (lado T3).

Se supone que el terminal T1 quiere establecer una conexión MPTCP con el terminal T2.

El terminal T1 indica a su corresponsal que es compatible con conexiones MPTCP, pero solamente anuncia la ruta que implica a Fn. El terminal T2 indica a su corresponsal que es compatible con conexiones de múltiples rutas. Por lo tanto, T1 y T2 pueden establecer sub-sesiones TCP que impliquen a Fn (lado T1). T1 y T2 pueden utilizar diferentes números de puerto para crear nuevas sub-sesiones asociadas con la conexión MPTCP de múltiples rutas.

Se supone que el terminal T3 quiere establecer una conexión MPTCP con el terminal T2.

El terminal T3 indica a su corresponsal que es compatible con conexiones MPTCP, pero solamente anuncia las rutas que implican a Fb y a Fm. El terminal T2 indica a su corresponsal que es compatible con conexiones de múltiples rutas. Por lo tanto, T3 y T2 pueden establecer sub-sesiones TCP que impliquen a Fb y a Fm (lado T3).

La Figura 6 ilustra un ejemplo de aplicación de la invención a una configuración de red que comprende un terminal T1 compatible, o no, con MPTCP y colocado detrás de un dispositivo repetidor R, tal como un enrutador o una pasarela residencial, compatible con MPTCP.

Este dispositivo de retransmisión R está conectado a una o más redes IP a través de n nodos de conexión (F1, F2, ..., Fn) y n redes de acceso R1, R2, ..., Rn respectivas; estos nodos de conexión pueden alojar funciones NAT, cortafuegos, y así sucesivamente, o ser enrutadores IP que no incorporen ninguna función de servicio avanzada, tal como NAT o un cortafuegos.

El dispositivo de retransmisión R pone en práctica la presente invención para comunicarse con terminales remotos. El dispositivo de retransmisión R anuncia sus capacidades funcionales al terminal T1, según las capacidades funcionales de las funciones Fi descubiertas por el dispositivo de retransmisión R. Para ello procede de la siguiente manera:

- si al menos una de las múltiples rutas conocidas del dispositivo de retransmisión R es compatible con las conexiones MPTCP (es decir, si el atributo PATH_CHECKED de al menos una de las múltiples rutas está valorado en "1"), el dispositivo de retransmisión R transmite al terminal T1 un mensaje de notificación que comprende la mención: M^pT^cP_STATUS=1 ;

- si ninguno de las múltiples rutas conocidas por el dispositivo de retransmisión R es compatible con las conexiones MPTCP (es decir, si el atributo PATH_CHECKED de todas las múltiples rutas está valorado en "0"), el dispositivo de retransmisión R transmite al terminal T1 un mensaje de notificación que incluye la mención: MPTCP_STATUS!=1.

Cuando el terminal T1 inicializa una conexión de múltiples rutas:

- el dispositivo de retransmisión R enruta los paquetes de datos utilizando la(s) ruta(s) cuyo atributo PATH_CHECKED se establece en "1";

- si el dispositivo de retransmisión R no tiene ninguna ruta compatible con las conexiones MPTCP y si, no obstante, recibe un mensaje de inicialización de conexión de múltiples rutas del terminal T1 (esto puede ocurrir en el caso de que el terminal T1 no sea capaz de interpretar la mención MPTCP_STATUS !=1 recibida previamente desde el dispositivo repetidor R), el dispositivo repetidor R, según la invención, no transmite este mensaje de inicialización a su destinatario; además, el dispositivo de retransmisión R, según la invención, responde al terminal T1 (haciéndose pasar así por el corresponsal del terminal T1) sin incluir ninguna opción MPTCP en su respuesta; a continuación, T1 cambia sin demora a una conexión TCP simple, de conformidad con el clásico "modo de retroceso".

La invención puede ponerse en práctica dentro de los nodos de la red de comunicación, por ejemplo, terminales, enrutadores, pasarelas, NAT o cortafuegos, mediante componentes de software y/o hardware.

Los componentes de software pueden integrarse en un programa informático de gestión de nodos de red convencional. Es por ello que, tal como se indicó con anterioridad, la presente invención también se refiere a un sistema informático. Este sistema informático comprende, de manera convencional, una unidad central de procesamiento que controla una memoria mediante señales, así como una unidad de entrada y una unidad de salida. Además, este sistema informático puede utilizarse para ejecutar un programa informático que comprende instrucciones para la puesta en práctica de cualquiera de los métodos de comunicación según la invención.

De hecho, la invención también se refiere a un programa informático tal como se ha descrito brevemente con anterioridad. Este programa informático puede almacenarse en un medio legible por ordenador y puede ser ejecutable por un microprocesador. Este programa puede utilizar cualquier lenguaje de programación y estar en forma de código fuente, código objeto o código intermedio entre el código fuente y el código objeto, como en forma parcialmente compilada o en cualquier otra forma deseable.

La invención también se refiere a un medio de información no extraíble, o parcial o totalmente extraíble, que comprende instrucciones de un programa informático tal como se ha descrito brevemente con anterioridad.

Este soporte de información puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte de información puede comprender un medio de almacenamiento, tal como una memoria ROM, por ejemplo, un CD ROM o una memoria ROM de circuito microelectrónico, o un medio de grabación magnética, tal como un disco duro, o incluso una memoria USB.

Por otro lado, el medio de información puede ser un medio transmisible tal como una señal eléctrica u óptica, que puede enrutarse a través de un cable eléctrico u óptico, por radio o por otros medios. En particular, el programa informático, según la invención, puede descargarse desde una red de tipo Internet.

Como variante, el medio de información puede ser un circuito integrado en donde se incorpora el programa, estando adaptado el circuito para ejecutar o para ser utilizado en la ejecución de cualquiera de los métodos de comunicación según la invención.

Claims

REIVINDICACIONES

1. Método de comunicación que comprende las etapas siguientes:

a) un dispositivo comunicante (T1,R), siendo dicho dispositivo comunicante un dispositivo-cliente (T1) capaz de poner en práctica una conexión TCP simple, Protocolo de Control de Transmisión, o una conexión de múltiples rutas obedeciendo a un protocolo de transporte del modelo OSI, o un dispositivo de retransmisión (R) conectado a dicho dispositivo-cliente (T1) y capaz de poner en práctica una conexión de múltiples rutas que obedece a dicho protocolo de transporte, que recibe (E1), en ausencia de cualquier conexión de múltiples rutas que obedece a dicho protocolo de transporte entre dicho dispositivo comunicante (T1,R) y algún otro dispositivo-cliente (T2, T3), información (MPTCP_STATUS) relativa a la compatibilidad o la incompatibilidad con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte de al menos un nodo intermedio situado en una ruta que conecta dicho dispositivo comunicante (T1,R) a dicho otro dispositivo-cliente (T2, T3), siendo recibida dicha información por dicho dispositivo comunicante dentro de un mensaje no solicitado emitido por dicho nodo intermedio; y

b) dicho dispositivo comunicante (T1,R) registra (E2) un estado (PATH_CHECKED) de dicha ruta en cuanto a su compatibilidad o su incompatibilidad con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte.

2. Método de comunicación según la reivindicación 1, caracterizado porque dicho dispositivo comunicante (T1,R) transmite, para al menos otro nodo intermedio situado en otra ruta que conecta dicho dispositivo comunicante (T1,R) a dicho otro dispositivo-cliente (T2, T3), una solicitud con destino a dicho otro nodo intermedio, y porque, durante dicha etapa a), recibe información (MPTCP_STATUS) relativa a la compatibilidad o la incompatibilidad con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte de dicho otro nodo intermedio dentro de un mensaje de respuesta transmitido por dicho otro nodo intermedio.

3. Método de comunicación según la reivindicación 1 o la reivindicación 2, caracterizado porque, si dicho dispositivo comunicante (T1,R) constata que ninguna ruta que conecta el dispositivo-cliente (T1) con dicho otro dispositivo-cliente (T2, T3) no es compatible con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte, el método comprende, además, una etapa (E3), durante la cual el dispositivo-cliente (T1) utiliza una conexión TCP simple para:

- establecer una conexión con dicho otro dispositivo-cliente (T2, T3), o

- conectarse con el otro dispositivo-cliente (T2, T3), tras la recepción de un mensaje de establecimiento de una conexión de múltiples rutas, obedeciendo dicho protocolo de transporte enviado por el otro dispositivo-cliente (T2, T3).

4. Método de comunicación según la reivindicación 1 o la reivindicación 2, caracterizado porque, si el dispositivo comunicante (T1,R) constata que al menos una ruta que conecta el dispositivo-cliente (T1) con dicho otro dispositivocliente (T2, T3), es compatible con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte, el método comprende, además, una etapa (E3) durante la cual el dispositivo comunicante (T1,R) utiliza un protocolo de conexión de múltiples rutas para comunicarse con dicho otro dispositivo-cliente (T2, T3) a lo largo de dicha ruta compatible con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte.

5. Método de comunicación según cualquiera de las reivindicaciones 1 a 4, caracterizado porque dicha conexión de múltiples rutas, que obedece a dicho protocolo de transporte, pone en práctica el protocolo MPTCP, Multi-Path TCP.

6. Dispositivo comunicante que posee medios para poner en práctica una conexión TCP simple, Protocolo de Control de Transmisión, o una conexión de múltiples rutas que obedezca a un protocolo de transporte del modelo OSI, de modo que también disponga de medios para:

- recibir, en ausencia de cualquier conexión de múltiples rutas que obedezca a dicho protocolo de transporte entre dicho dispositivo comunicante y algún otro dispositivo-cliente, información (MPTCP_STATUS) relativa a la compatibilidad o incompatibilidad con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte de al menos un nodo intermedio situado en una ruta que conecta dicho dispositivo comunicante con dicho otro dispositivo-cliente, siendo recibida dicha información por dicho dispositivo comunicante dentro de un mensaje no solicitado transmitido por dicho nodo intermedio; y

- registrar un estado (PATH_CHECKED) de dicha ruta en cuanto a su compatibilidad o incompatibilidad con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte.

7. Dispositivo comunicante según la reivindicación 6, caracterizado porque comprende, además, medios para: - enviar una solicitud a otro nodo intermedio ubicado en otra ruta que conecta dicho dispositivo comunicante con dicho otro dispositivo-cliente, y

- recibir información (MPTCP_STATUS) relativa a la compatibilidad o incompatibilidad con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte de dicho otro nodo intermedio dentro de un mensaje de respuesta transmitido por dicho otro nodo intermedio.

8. Dispositivo comunicante según la reivindicación 7, caracterizado porque comprende un dispositivo-cliente (T1, T2, T3).

9. Dispositivo comunicante según la reivindicación 8, caracterizado porque comprende, además, medios para: - constatar que ninguna ruta que conecta dicho dispositivo comunicante con dicho otro dispositivo-cliente es compatible con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte, y

- utilizar una conexión TCP simple para:

• establecer una conexión con el otro dispositivo-cliente, o

• conectarse al otro dispositivo-cliente, previa recepción de un mensaje de establecimiento de conexión de múltiples rutas, que obedece a dicho protocolo de transporte, enviado por el otro dispositivo-cliente.

10. Dispositivo comunicante según la reivindicación 8 o la reivindicación 9, caracterizado porque comprende, además, medios para:

- constatar que al menos una ruta que conecta dicho dispositivo comunicante a dicho otro dispositivo-cliente es compatible con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte, y

- utilizar un protocolo de conexión de múltiples rutas para comunicarse con el otro dispositivo-cliente a lo largo de dicha ruta compatible con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte.

11. Dispositivo comunicante según la reivindicación 6 o la reivindicación 7, caracterizado porque comprende un dispositivo de retransmisión (R) conectado a un dispositivo-cliente (T1).

12. Dispositivo comunicante según la reivindicación 11, caracterizado porque comprende, además, medios para: - constatar que ninguna ruta que lo conecta a dicho otro dispositivo-cliente es compatible con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte, y

- si recibe un mensaje de inicialización de conexión de múltiples rutas obedeciendo a dicho protocolo de transporte desde dicho dispositivo-cliente (T1) con la intención del otro dispositivo-cliente, responder al dispositivo-cliente (T1) sin utilizar un protocolo de conexión de múltiples rutas que obedezca a dicho protocolo de transporte en su respuesta.

13. Nodo para una red IP, Protocolo Internet, y que comprende medios para la difusión de mensajes no solicitados que contienen información (MPTCP_STATUS) sobre la compatibilidad o incompatibilidad de dicho nodo con conexiones de múltiples rutas que obedezcan a un protocolo de transporte del modelo OSI.

14. Medio de almacenamiento de datos no extraíble, o parcial o totalmente extraíble, que comprende instrucciones de código de programa informático que, cuando son ejecutadas por un ordenador, hacen que se pongan en práctica las etapas de un método de comunicación según cualquiera de las reivindicaciones 1 a 5.

15. Programa informático descargable desde una red de comunicaciones y/o almacenado en un medio legible por ordenador y/o ejecutable por un microprocesador, tal que comprende instrucciones para la ejecución de las etapas de un método de comunicación según cualquiera de las reivindicaciones 1 a 5, cuando se ejecuta en un ordenador.