ES2979115T3 - Método de comunicación UDP a través de múltiples vías entre dos terminales - Google Patents

Abstract

La invención se refiere a un método para la comunicación en una red IP, que comprende los siguientes pasos: a) un primer dispositivo comunicante inicializa una comunicación con un segundo dispositivo comunicante, señalando al segundo dispositivo comunicante que el primer dispositivo comunicante es compatible con comunicaciones multitrayecto basadas en el Protocolo de Datagramas de Usuario (UDP), y b) si el segundo dispositivo comunicante es también compatible con comunicaciones multitrayecto UDP: el primer dispositivo comunicante transmite datos al segundo dispositivo utilizando el protocolo de transporte UDP, incluyendo en los mensajes que contienen dichos datos, independientemente del camino utilizado, un único identificador, conocido como identificador de contexto (Context_ID), que permite al segundo dispositivo comunicante correlacionar todos los datagramas UDP asociados a la misma comunicación multitrayecto UDP; y/o el segundo dispositivo comunicante transmite datos al primer dispositivo utilizando el protocolo de transporte UDP, incluyendo en los mensajes que contienen dichos datos, independientemente del camino utilizado, un único identificador, conocido como identificador de contexto (Context_ID), que permite al primer dispositivo comunicante correlacionar todos los datagramas UDP asociados a la misma comunicación multitrayecto UDP. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Método de comunicación UDP a través de múltiples vías entre dos terminales

La presente invención se refiere al campo de las telecomunicaciones y, en particular, a las redes de comunicaciones capaces de implementar el protocolo IP (Protocolo de Internet). Más particularmente, la presente invención se refiere a la prestación de servicios en redes IP de "valor añadido", es decir, redes capaces de llevar a cabo un procesamiento diferenciado según la naturaleza del tráfico encaminado en la red.

La invención se aplica en particular a cualquier tipo de dispositivo cliente('User Equipment'en inglés) tal como un terminal fijo o móvil, “TV conectada”, o una pasarela residencial (es decir una pasarela doméstica o ubicada en una empresa), o una pasarela de un operador de red ("Gatewayen inglés), o incluso un decodificador de TV("Set-Top Box",o STB en inglés). Para más concisión, un dispositivo cliente de cualquier tipo a menudo se denominará “terminal” en lo sucesivo.

Los terminales, tales como los teléfonos inteligentes("smartphone"en inglés) y los ordenadores personales("Personal Computer’,o PC en inglés), son ahora capaces de activar y operar múltiples interfaces lógicas vinculadas a una o más interfaces físicas. Este tipo de 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), se beneficia de un acceso denominado "híbrido", ya que combina diferentes tecnologías de redes de acceso.

Se pueden entonces asignar varias direcciones IP a un terminal MIF. Estas direcciones se utilizan cuando se conecta 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 Networkque significan "Red Local Inalámbrica", cuya red Wi-Fi son un ejemplo emblemático), de manera simultánea o diferida. Estas direcciones IP pueden:

• pertenecer a la misma familia de direcciones o a familias de direcciones distintas (IPv4, IPv6 o las dos),

• tener diferentes duraciones de vida,

• tener diferentes alcances, por ejemplo, dirección IPv4 privada, dirección Ipv6 única de alcance local(Unique LocalAddress,o ULA en inglés) o dirección Ipv6 de alcance global(Global UnicastAddress,o GUA en inglés), y

• asignarse a la misma interfaz de red lógica o a diferentes interfaces de red lógicas.

Cabe señalar no obstante que la característica "MIF" es volátil, ya que la capacidad de utilizar múltiples interfaces depende de las condiciones de conexión a la o las redes, de la ubicación del dispositivo, u de otros factores. Un dispositivo puede volverse MIF durante el proceso de establecer una comunicación simple (es decir, una comunicación establecida a lo largo de una única vía con una parte determinada), o incluso después de establecer una comunicación simple. Cabe también señalar que un dispositivo no sabe a priori si es posible utilizar varias vías distintas para establecer una comunicación con un correspondiente determinado; más precisamente, el dispositivo sólo adquiere esta información (llegado el caso) al final de una fase durante la cual intenta establecer comunicación usando múltiples vías con el correspondiente.

Se recuerda que una "comunicación de múltiples vías" es una comunicación establecida entre dos dispositivos que toman simultáneamente una o más vías entre estos dos dispositivos. El establecimiento y mantenimiento en actividad de dicha comunicación se basa en el uso de un protocolo dedicado, tal como MPTCP (Multi-Path TCP), que puede eventualmente definirse como una extensión de un protocolo de transporte previamente definido, tal como TCP (iniciales de las palabras en inglés"Transmission Control Protoco"que significan "Protocolo de Control de Transmisión"). En otras palabras, una comunicación de múltiples vías es un agregado de una o más comunicaciones simples que toman la misma vía o vías diferentes (parcial o completamente separadas).

Se recuerda también que, en el ámbito de las redes, se denomina "agregación de enlaces" a la agrupación de varios enlaces asociados a tantas interfaces (lógicas) como si se tratara de un único enlace asociado a una única interfaz, en particular con el objetivo de incrementar el caudal más allá de los límites de un único enlace, pero también aplicar los mismos procedimientos operativos al conjunto de los enlaces así agregados (noción de"fate sharingen inglés). En particular, las ofertas de servicios relativas a un terminal que dispone de un acceso híbrido se basan en la introducción en la red de funciones que permiten agregar el conjunto de las comunicaciones de red de un terminal (por ejemplo: WLAN y 3G, o ADSL, WLAN y 4G).

La agregación de enlaces también permite que otras interfaces tomen el control si falla un enlace de red (principio de redundancia). La agregación de enlaces se aplica a cualquier tipo de tráfico transportado a lo largo de estos enlaces, incluyendo el tráfico IP.

La agregación de enlaces también se puede utilizar para distribuir el tráfico entre varios enlaces. En este caso, la distribución del tráfico entre enlaces que son objeto de un agregado depende de varios parámetros; la distribución del tráfico puede así depender de la política de ingeniería de tráfico (por ejemplo, favorecer el encaminamiento de un determinado tráfico en un enlace cuyas características en términos de robustez o disponibilidad sean compatibles con la naturaleza de dicho tráfico), o de la política de Calidad de Servicio("Quality of Service",o QoS en inglés) que puede, por ejemplo, favorecer determinados enlaces en un contexto de priorización del tráfico.

Como ejemplo, se ha representado en la Figura 1 a un terminal T que se comunica con un servidor S a través de varias redes IP denominadas R1, ..., Rm y O, implementando un protocolo de comunicación de múltiples vías. La naturaleza de los diferentes redes de acceso R1,..., Rm pueden ser cableadas, inalámbricas, u otras. Además, el terminal T puede tener capacidad para conectarse a diferentes redes de acceso simultáneamente o no.

Asimismo, se ha representado en la Figura 1b un terminal T colocado detrás de un equipo, denominado dispositivo relé R; este dispositivo relé R se comunica con un servidor S a través de varias redes IP denominadas R1,..., Rm y O, implementando un protocolo de comunicación de múltiples vías.

De manera general, se denominará "dispositivo relé" a un equipo ubicado en la red y que actúa en nombre de uno o más dispositivos clientes, tales como un terminal o una pasarela. Esta configuración permite que el dispositivo cliente se beneficie de un uso optimizado de los recursos de red disponibles y también establezca comunicaciones de múltiples vías con un plazo reducido.

Cabe señalar que la agregación de enlaces no hace suposiciones sobre la configuración de la máquina remota. Así, una máquina fuente puede solicitar una función de agregación de enlaces sin que la máquina remota utilice tal función.

Se pueden considerar varios modos de agregación, entre los cuales los tres modos siguientes:

• modo de apoyo ("backup" en inglés): este modo consiste en utilizar vías secundarias en caso de indisponibilidad de las vías primarias, con el fin de mejorar la disponibilidad de la red y, por lo tanto, la robustez y fiabilidad de las comunicaciones IP establecidas en los diferentes enlaces;

• modo asociativo ("bonding" en inglés): este modo consiste en utilizar los recursos asociados a todas o parte de las vías disponibles, pudiendo los flujos IP asociados a una misma aplicación ser distribuidos entre varias vías; la elección de explotar la totalidad de las vías, o sólo una parte de ellas, puede estar condicionada, por ejemplo, por la naturaleza del tráfico o por las características de disponibilidad o fiabilidad asociadas a cada vía, que pueden variar mucho de una vía a otra; todas las vías seleccionadas para este modo asociativo se consideran caminos siendo vías primarias; y

• modo denominado de "comodidad": este modo es similar al modo asociativo, excepto que los flujos de una determinada aplicación no se distribuyen entre varias vías, sino que se envían por una sola vía.

Cabe señalar que estos modos no son mutuamente excluyentes y no son específicos de un tipo de tráfico en particular. Así, pueden implementarse independientemente de la naturaleza del tráfico que será encaminado a lo largo de las vías agregadas según uno u otro de los diferentes modos.

Los protocolos de transporte utilizados principalmente por las aplicaciones de software para comunicarse en Internet son TCP (mencionado anteriormente) y UDP (iniciales de las palabras en inglés"User Datagram Protoco!'que significan "Protocolo de Datagrama de Usuario"). Como tal, los medios técnicos que permiten a un dispositivo cliente/dispositivo relé optimizar el uso de los recursos de red disponibles en función de las necesidades, y limitaciones de las aplicaciones basadas en TCP o UDP son de naturaleza a proporcionar una mejora significativa del nivel de calidad asociado con el uso de tales aplicaciones. Además, algunos actores de Internet están experimentando a gran escala soluciones alternativas a TCP basadas en UDP (y, más precisamente, en un esquema de encapsulación). Desde este punto de vista, los proveedores de servicios y operadores de redes IP desean proporcionar un nivel de calidad de uso comparable entre las aplicaciones basadas en TCP y las basadas en UDP.

Por lo tanto, es deseable disponer de una paridad funcional lo más amplia posible entre TCP y UDP. En particular, sería útil poder establecer comunicaciones UDP a través de múltiples vías de manera funcionalmente comparable a las soluciones técnicas conocidas, tales como el protocolo MPTCP mencionado anteriormente, que permiten el establecimiento de conexiones TCP a través de múltiples vías.

En el contexto de la presente invención, se denomina "datagrama UDP" un paquete IP transportado según el protocolo UDP.

Una solución a este problema fue propuesta en el documento ("draft-Internet") de M. Boucadair et al. presentado al IETF (Internet Engineering Task Force) y titulado "An MPTCP Option for Network-Assisted MPTCP Deployments: Plain Transport Mode". Esta solución utiliza el protocolo MPTCP para enviar específicamente el tráfico UDP en el contexto de una conexión MPTCP. En el caso del tráfico UDP, la solución consiste en transformar los datagramas UDP en paquetes TCP. Para ello, los autores han definido una opción TCP específica, que permite indicar explícitamente la naturaleza de los datos transportados dentro de la conexión MPTCP y, en particular, indicar explícitamente que los datos enviados son datagramas UDP. Así, una función mandataria(proxy)MPTCP transforma un datagrama UDP en un paquete TCP procediendo de la siguiente manera:

• reemplazar la cabecera UDP con una cabecera TCP, y

• insertar una opción TCP cuyo campo "Protocolo" esté configurado en "17", lo que indica que el contenido del paquete TCP corresponde a los datos UDP.

Tras la recepción de un paquete TCP que contiene dicha opción TCP, la función mandataria MPTCP procede de la siguiente manera:

• reemplazar la cabecera TCP con una cabecera UDP, y

• transferir el datagrama UDP así construido hacia el siguiente salto.

Esta solución permite ventajosamente utilizar las mismas funciones para establecer comunicaciones de múltiples vías tanto para el tráfico TCP como para el tráfico UDP.

El inconveniente de esta solución es que ofrece un rendimiento degradado debido a la diferencia de tamaño entre la cabecera TCP (20 bytes sin contar las opciones, véase la Figura 2a) y la cabecera UDP (8 bytes, véase la Figura 2b). En particular, esta diferencia de tamaño puede provocar la fragmentación de los datagramas UDP. Esta fragmentación obliga a los operadores de red a modificar ciertos parámetros tales como el valor de la MTU (iniciales de las palabras inglesas"Máximum Transfer Unit'),que corresponde al tamaño máximo de paquetes que se pueden transmitir en un determinado enlace: si el tamaño de un paquete excede el valor de la MTU, entonces se informa a la fuente que transmite el paquete de este exceso y se le invita a fragmentar dicho paquete de un tamaño mayor que el valor de la MTU. Ahora bien, modificar tales parámetros no siempre es posible en determinados contextos, por ejemplo debido a limitaciones tecnológicas. Además, el transporte de datos confiable característico del protocolo TCP puede inducir una degradación del servicio para las aplicaciones UDP.

El documento US 2016/0094467 describe un enfoque en un contexto de conexiones múltiples ("multi-homing") basado en protocolos de tunelización ("tunnelling protocols").

El documento de W. Lei et al, titulado "A Framework of Multipath Transport System Based on Application-Level Relay (MPTS-AR) draft-leiwm-tsvwg-mpts-ar-05", 19 de julio de 2016, define un sistema de comunicación en el que se implementan relés a nivel de aplicación para proporcionar las condiciones necesarias para el establecimiento de múltiples vías entre una fuente y un destino. Por lo tanto, la presente invención se refiere a un procedimiento de comunicación en una red IP, que comprende las siguientes etapas:

a) un primer dispositivo de comunicación inicia una comunicación con un segundo dispositivo de comunicación, señalando a dicho segundo dispositivo de comunicación que dicho primer dispositivo de comunicación es compatible con las comunicaciones de múltiples vías basadas en el protocolo de transporte UDP (User Datagram Protocol), y

b) si el segundo dispositivo de comunicación también es compatible con las comunicaciones UDP de múltiples vías:

- el primer dispositivo de comunicación envía datos al segundo dispositivo según el protocolo de transporte UDP, incluyendo en los mensajes que contienen estos datos, sea cual sea la vía utilizada, un mismo identificador, denominado identificador de contexto, que permite al segundo dispositivo de comunicación correlacionar todos los datagramas UDP asociados con una misma comunicación UDP de múltiples vías, y/o

- el segundo dispositivo de comunicación envía datos al primer dispositivo según el protocolo de transporte UDP, incluyendo en los mensajes que contienen estos datos, sea cual sea la vía utilizada, un mismo identificador, denominado identificador de contexto, que permite al primer dispositivo de comunicación correlacionar todos los datagramas UDP asociados con una misma comunicación UDP de múltiples vías.

De hecho, los autores de la presente invención se han dado cuenta de que los datagramas UDP enviados por un dispositivo de comunicación transmisor a un dispositivo de comunicación receptor, utilizando diferentes direcciones IP de origen o diferentes números de puerto de origen, deben identificarse adecuadamente si se quiere permitir al dispositivo de comunicación receptor correlacionar el conjunto de los datagramas UDP asociados con una misma comunicación de múltiples vías. Tal identificación permite, en efecto, preservar la integridad del intercambio de datos entre los dos dispositivos. Según la presente invención, el dispositivo comunicador transmisor inserta en los datagramas UDP que transmite un identificador de contexto, al que se denominará "ContextJD"; tal comunicación UDP de múltiples vías se denominará "MPUDP".

Cabe señalar que, a diferencia de las soluciones existentes que se basan en la explotación de campos específicos de una cabecera de encapsulación (por ejemplo, IP-in-IP o GRE), o soluciones específicas al protocolo TCP (por ejemplo, MPTCP), o incluso soluciones que transportan datos UDP en un paquete TCP (tal como la solución de Boucadairet al.descrita brevemente anteriormente), la presente invención se basa en el envío nativo de datagramas UDP.

A través de estas disposiciones, se obtiene una paridad funcional entre TCP y UDP para la gestión de múltiples vías, estableciendo sesiones UDP a través de múltiples vías de una manera comparable al establecimiento de conexiones TCP a través de múltiples vías, con el fin de tratar con la misma eficiencia todo el tráfico enviado en Internet y que se basa indiferentemente en el protocolo TCP o en el protocolo UDP.

Además, ventajosamente, la invención:

• no impone ninguna modificaciones a las aplicaciones de software basadas en UDP;

• permite, para beneficiarse de las ventajas de la agregación de enlaces, evitar el uso de túneles (como en las tecnologías de "GTP bonding" o "GRE bonding", por ejemplo), incluida la ingeniería, el establecimiento y el mantenimiento son fuentes de complicaciones y pueden penalizar el nivel de calidad asociado a las comunicaciones basadas en tales túneles;

• permite optimizar el uso de los recursos de red disponibles sin ningún coste de protocolo y sin ruptura de protocolo consistente, por ejemplo, en transformar datagramas UDP en paquetes transportados mediante otros protocolos de transporte (por ejemplo, TCP); y

• permite implementar una única solución para todas las aplicaciones de software transportadas mediante el protocolo UDP, a diferencia de las soluciones que requieren la integración de la lógica de agregación en la propia aplicación.

Se mejora significativamente así la calidad de la experiencia del usuario.

Un ejemplo típico de aplicación de la invención es la transferencia de archivos usando los recursos del protocolo TFTP (Trivial File Transfer Protocol), o la gestión optimizada de los flujos de recopilación de estadísticas basada en el protocolo SNMP (iniciales de las palabras en inglés"Simple Network Management Protocol',que utiliza los puertos UDP 161 y 162. Un terminal que dispone de varios archivos enlaces de red que actúa como cliente TFTP podrá utilizar dinámicamente todas las vías disponibles que le permitan acceder al servidor TFTP. De este modo, se mejorará el tiempo de transferencia de datos en beneficio de una experiencia de cliente optimizada. En el caso del tráfico SNMP, la invención permite en particular hacer más fiable el envío del tráfico permitiendo utilizar una vía de reserva en caso de indisponibilidad de la vía primaria.

Cabe señalar que los dispositivos de comunicación implicados en una comunicación según la invención pueden ser cualquier dispositivo compatible con el protocolo IP. Tal dispositivo de comunicación puede ser de cualquier tipo, por ejemplo un dispositivo cliente o un servidor de contenidos accesible a través de Internet. Puede disponer de una o más direcciones IP asignadas a cada una de sus interfaces físicas o lógicas. También puede disponer de una sola interfaz, en cuyo caso se asumirá que está ubicada detrás de un dispositivo relé (tal como un enrutador o una pasarela residencial) conectado a una o más redes y compatible con un mecanismo de agregación de enlaces.

Según características particulares, dicho primer dispositivo de comunicación y/o dicho segundo dispositivo de comunicación inserta además en dichos mensajes un testigo de seguridad que permite al receptor de estos mensajes autentificar al transmisor.

Gracias a estas disposiciones, se puede evitar, por ejemplo, que un terminal de un tercero inserte datos en un mensaje destinado a un terminal T1 o a un terminal T2, cuando no forma parte legítimamente de un intercambio en curso entre el terminal T1 y el terminal T2.

Según otras características particulares, dicho primer dispositivo de comunicación y/o dicho segundo dispositivo de comunicación inserta además en dichos mensajes una información que permiten al receptor de estos mensajes procesarlos en su orden de transmisión.

Gracias a estas disposiciones, se corrige una posible diferencia entre el orden de transmisión y el orden de llegada de los datagramas UDP, diferencia que puede ser provocada en particular por una distorsión del nivel de calidad en relación con las diferentes vías utilizadas.

Según otras características particulares más, siendo dicho primer dispositivo de comunicación y/o dicho segundo dispositivo de comunicación un concentrador de tráfico, dicho procedimiento comprende además las siguientes etapas:

• dicho concentrador de tráfico recibe un datagrama UDP enviado en una vía utilizada por una comunicación UDP de múltiples vías, y

• el concentrador de tráfico envía este datagrama UDP a su destinatario según el modo de transporte UDP simple.

A la inversa, según todavía otras características particulares, siendo dicho primer dispositivo de comunicación y/o dicho segundo dispositivo de comunicación un concentrador de tráfico capaz de distribuir datagramas UDP recibidos según el modo de transporte UDP simple y asociados a una determinada sesión, entre diferentes vías de una comunicación UDP de múltiples vías que permite llegar al destinatario de estos datagramas UDP, dicho procedimiento comprende además las siguientes etapas:

• después de la recepción de un datagrama UDP, el concentrador de tráfico consulta una tabla de registro que lista el conjunto de las direcciones y/o números de puerto del destinatario del datagrama UDP recibido,

• el concentrador de tráfico asigna un identificador de contexto si ya no se ha procesado ningún paquete para esta sesión o reutiliza un identificador de contexto ya asignado para esta sesión, y

• el concentrador de tráfico envía el datagrama UDP hacia la dirección IP y/o el número de puerto de dicho destinatario asociado con la vía elegida para enviar este datagrama UDP.

Gracias a estas disposiciones, los operadores de red pueden permitir que sus clientes se beneficien de las ventajas de la presente invención sin requerir que los dispositivos de comunicación de estos clientes (incluyendo servidores remotos y aplicaciones) sean necesariamente capaces de establecer una comunicación UDP de múltiples vías.

Correlativamente, la invención se refiere a un dispositivo de comunicación. Dicho dispositivo de comunicación, denominado primer dispositivo de comunicación, destaca ya que comprende medios para:

• iniciar una comunicación con otro dispositivo de comunicación, denominado segundo dispositivo de comunicación, dentro de una red IP, señalando a dicho segundo dispositivo de comunicación que dicho primer dispositivo de comunicación es compatible con comunicaciones UDP (User Datagram Protocol) de múltiples vías,

• enviar datos según el protocolo UDP al segundo dispositivo de comunicación, incluyendo en los mensajes que contienen estos datos, sea cual sea la vía utilizada, un mismo identificador, denominado identificador de contexto, que permite al segundo dispositivo de comunicación correlacionar el conjunto de los datagramas UDP asociados a una misma comunicación UDP de múltiples vías, y

• recibir datos según el protocolo UDP por parte del segundo dispositivo de comunicación, detectando en los mensajes que contienen estos datos, sea cual sea la vía utilizada, un mismo identificador, denominado identificador de contexto, que permite al primer dispositivo de comunicación correlacionar el conjunto de los datagramas UDP asociados a una misma comunicación UDP de múltiples vías.

Según características particulares, dicho dispositivo de comunicación comprende además medios para insertar en los mensajes que transmite un testigo de seguridad que permite al receptor de estos mensajes autentificar el transmisor.

Según otras características particulares, dicho dispositivo de comunicación comprende además medios para insertar en los mensajes que transmite informaciones que permiten al receptor de estos mensajes procesarlos en su orden de transmisión.

Según otras características particulares más, dicho dispositivo de comunicación comprende un concentrador de tráfico que tiene medios para, cuando recibe un datagrama UDP enviado por una vía utilizada por la comunicación UDP de múltiples vías, enviar este datagrama UDP a su destinatario según el modo de transporte UDP simple.

Según otras características particulares más, dicho dispositivo de comunicación comprende un concentrador de tráfico que tiene medios para distribuir datagramas UDP recibidos según el modo de transporte UDP simple y asociados a una determinada sesión, entre diferentes vías de una comunicación UDP de múltiples vías que permite alcanzar el destinatario de estos datagramas UDP, así como los medios para, después de la recepción de un datagrama UDP:

• consultar una tabla de registro que lista el conjunto de las direcciones y/o números de puerto del destinatario del datagrama UDP recibido,

• asignar un identificador de contexto si ya no se ha procesado ningún paquete para esta sesión o reutiliza un identificador de contexto ya asignado para esta sesión, y

• enviar el datagrama UDP hacia la dirección IP y/o el número de puerto de dicho destinatario asociado con la vía elegida para enviar este datagrama UDP.

Las ventajas que ofrecen estos dispositivos de comunicación son esencialmente las mismas que las que ofrecen los procedimientos de comunicación explicados brevemente anteriormente.

Se observará que es posible realizar estos dispositivos de comunicación en el contexto de instrucciones de software y/o en el contexto de circuitos electrónicos.

La invención también se refiere a un programa informático descargable desde una red de comunicaciones y/o almacenado en un medio legible por ordenador y/o ejecutable mediante un microprocesador. Este programa informático destaca ya que comprende instrucciones para llevar a cabo las etapas de uno de los procedimientos de comunicación descritos brevemente anteriormente, cuando se ejecuta en un ordenador.

Las ventajas que ofrece este programa informático son esencialmente las mismas que las que ofrecen los procedimientos de comunicación brevemente descritos anteriormente.

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

- la Figura 1 a, mencionada anteriormente, representa un terminal T que se comunica con un servidor S a través de varias redes IP implementando un protocolo de comunicación de múltiples vías,

- la Figura 1b, mencionada anteriormente, representa un terminal T colocado detrás de un dispositivo relé R que se comunica con un servidor S a través de varias redes IP implementando un protocolo de comunicación de múltiples vías,

- la Figura 2a, mencionada anteriormente, representa la cabecera UDP,

- la Figura 2b, mencionada anteriormente, representa la cabecera TCP,

- la Figura 3 representa un terminal T compatible con las comunicaciones de múltiples vías conectado a un servidor S también compatible con las comunicaciones de múltiples vías,

- la Figura 4 ilustra una comunicación MPUDP entre un terminal T y un servidor S que utiliza un identificador de contexto según la invención,

- la Figura 5 ilustra una comunicación MPUDP entre un terminal T1 y un terminal T2 que utiliza un identificador de contexto y un testigo de seguridad según la invención,

- la Figura 6 representa un ejemplo de un datagrama UDP que contiene datos útiles, así como un identificador de contexto y datos adicionales según la invención,

- las Figuras 7a, 7b y 7c ilustran varios tipos de arquitecturas asociadas con concentradores de tráfico,

- la Figura 8 representa un terminal T compatible con MPUDP, que intercambia mensajes con un servidor S compatible con UDP, a través deNconcentradores de tráfico(P1 ,P<2>, ... ,Pn)ubicados en m redes de acceso R1, ..., Rm, y a través de una red O,

- la Figura 9 ilustra los intercambios entre una pasarela residencial CPE y un concentrador C, según una primera variante de una realización de la invención,

- la Figura 10 ilustra los intercambios entre una plataforma de mediación y un concentrador C, según una segunda variante de dicha realización de la invención,

- la Figura 11 representa un terminal T, compatible con MPUDP, intercambiando mensajes con un servidor S compatible con UDP, a través de un concentrador C y tres redes N1, N2 y N3, así como, opcionalmente, a través de una pasarela residencial CPE, según un primer ejemplo de dicha realización de la invención,

- la Figura 12a representa un terminal T, compatible con MPUDP, que distribuye el tráfico UDP entre varias vías que permiten llegar a un concentrador C, según un segundo ejemplo de dicha realización de la invención,

- la Figura 12b representa un concentrador C que distribuye el tráfico UDP entre varias vías que permite llegar a un terminal T compatible con MPUDP, según un tercer ejemplo de dicha realización de la invención,

- las Figuras 13a y 13b representan un terminal T colocado detrás de una pasarela residencial CPE compatible con MPUDP e intercambiando datagramas UDP con un servidor S no compatible con MPUDP, a través de la pasarela residencial CPE y de un concentrador C, según un cuarto ejemplo de dicha realización. de la invención,

- las Figuras 14a y 14b representan un terminal T colocado detrás de una pasarela residencial CPE compatible con MPUDP e intercambiando datagramas UDP con dos terminales S1 y S2 no compatibles con MPUDP, a través de la pasarela residencial CPE y un concentrador C, según un quinto ejemplo de dicha realización de la invención, y

- la Figura 15 representa un datagrama UDP utilizado para transmitir el conjunto de los datos recibidos dentro de varios datagramas UDP clásicos.

Para empezar, se recuerda que una comunicación UDP simple se identifica mediante el siguiente conjunto de parámetros: dirección IP de origen, número de puerto fuente, dirección IP de destino, y número de puerto de destino. Una comunicación UDP de múltiples vías es, de manera general, una comunicación asociada a varios conjuntos de parámetros {dirección IP fuente, número de puerto fuente, dirección IP de destino, número de puerto de destino}; la variación de al menos uno de estos cuatro parámetros identifica una vía diferente (comunicación simple diferente). Así, una comunicación UDP de múltiples vías se compone de varias comunicaciones UDP simples.

La Figura 3 representa, a modo de ejemplo, un terminal T compatible con comunicaciones de múltiples vías, conectado, a través de una pasarela residencial CPE (iniciales de las palabras inglesas"Customer Premises Equipment'),tres redes de acceso N1, N2 y N3 (cableadas o inalámbricas) e Internet, a un servidor S también compatible con comunicaciones de múltiples vías. El terminal T usamdirecciones IP distintas (anotadas IP@ti, en el quei= 1, ..., m), mientras que el servidor S usa la misma dirección IP (anotada IP@s1) peronnúmeros de puerto distintos (anotados py, en el quej= 1, ... n).

Como se mencionó anteriormente, según la presente invención, un primer dispositivo de comunicación inserta, en los paquetes IP enviados según un modo de transporte UDP a un segundo dispositivo de comunicación, un identificador de contexto denominado "Context_ID". El identificador de contexto debe ser único para cada comunicación MPUDP establecida entre dos dispositivos de comunicación. Sin embargo, un dispositivo de comunicación puede reutilizar un identificador de contexto que se habría utilizado en el contexto de una comunicación anterior, pero que ya ha finalizado, si no existe riesgo de colisión con el identificador de contexto de una comunicación en curso. Además, para mejorar el nivel de seguridad de las comunicaciones UDP de múltiples vías, es preferible que el identificador de contexto se genere aleatoriamente.

Cabe señalar que un identificador de contexto puede ser elegido por el dispositivo de comunicación receptor, o ser el resultado de la asociación de un identificador elegido por el dispositivo de comunicación transmisor con otro identificador elegido por el dispositivo de comunicación receptor; estas variantes sólo son posibles si se ha establecido una etapa de intercambio de informaciones entre los dos dispositivos antes de que se envíen realmente los datagramas UDP a través de múltiples vías. El identificador de contexto también se puede elegir por otra entidad, tal como un administrador de red que controla el dispositivo de comunicación transmisor, o el dispositivo de comunicación receptor, o ambos dispositivos.

También cabe señalar que, si la comunicación es bidireccional, identificadores de contexto distintos pueden ser utilizados por cada uno de los dos dispositivos de comunicación.

La Figura 4 ilustra una comunicación MPUDP entre un terminal T y un servidor S. En este ejemplo, los datagramas UDP se envían utilizando tres comunicaciones UDP simples. Para permitir que el terminal T asocie estas comunicaciones simples con la misma sesión UDP de múltiples vías, el servidor S inserta el identificador de contexto ID#1 en los paquetes que envía a T.

Además del identificador de contexto, se puede insertar ventajosamente informaciones adicionales, tales como por ejemplo un testigo de seguridad en los mensajes intercambiados entre los dos dispositivos en comunicación. La Figura 5 ilustra una comunicación MPUDP entre un terminal T1 y un terminal T2 usando el identificador de contexto ID#1, y en la que un terminal T3 intenta insertar datos (por ejemplo, falsificando una dirección IP de T2). Si el testigo de seguridad "Authentication_Token" incluido por T3 no es idéntico al utilizado por T2, entonces T1 no toma en cuenta los datos transmitidos por T3.

El identificador de contexto, así como datos adicionales, se pueden insertar en un paquete IP y, según una primera variante, se colocan inmediatamente después de los datos UDP. Como se ilustra en la Figura 6, el valor de "Longitud IP" indica el tamaño total del paquete IP, incluido el de la cabecera IP (20 bytes en IPv4, 40 bytes en IPv6), mientras que el valor de "Longitud UDP" indica el tamaño total de la cabecera UDP y de los datos útiles("payload'en inglés). Al restar la longitud de la cabecera IP y la longitud UDP de la longitud IP, el receptor del paquete IP puede determinar la posición del identificador de contexto y de los eventuales datos adicionales.

Según una segunda variante, el identificador de contexto se transporta en el campo que contiene la carga útil("payload")UDP.

Según una tercera variante, se definen nuevas opciones IPv4 dedicadas (en cuyo caso los datos adicionales pueden registrarse cómodamente en el campo "Opciones" de la cabecera de un paquete IPv4), o una cabecera de extensión IPv6 dedicada. Estas opciones se utilizan para transportar el identificador de contexto, así como posibles datos adicionales (por ejemplo, un testigo de seguridad).

Es importante por supuesto que el uso de comunicaciones UDP de múltiples vías no induzca una degradación de la Calidad del Servicio (por ejemplo, pérdida de paquetes) en comparación con el modo UDP clásico.

En particular, una distorsión del nivel de calidad asociada con múltiples vías es de naturaleza a poner en duda la integridad de la comunicación al provocar una diferencia entre el orden de transmisión y el orden de llegada de los datagramas UDP. Incluso si determinadas aplicaciones UDP están diseñadas para minimizar tal riesgo (lo que también se ha demostrado para comunicaciones simples), un dispositivo de comunicación UDP transmisor puede ventajosamente insertar en los mensajes que transmite, además del identificador de contexto Context_ID, una información adicional que permita a un dispositivo de comunicación UDP receptor procesar estos mensajes en su orden de transmisión. Esta información adicional se denominará "Order_Rank". Este elemento de información puede estructurarse, por ejemplo, como un número entero distinto de cero cuyo valor se incrementa; así, un datagrama UDP con un valor Order_Rank de "7" es una indicación de que este datagrama UDP es el séptimo en una secuencia.

Para mejorar la seguridad de las comunicaciones, el valor Order_Rank inicial (es decir, el del primer paquete) puede ser no nulo y generarse aleatoriamente.

Un terminal compatible con las comunicaciones UDP de múltiples vías debe, preferentemente, disponer de mecanismos fiables que le permitan garantizar que el terminal remoto también es compatible con las comunicaciones de múltiples vías. Se pueden considerar varios métodos para este propósito, por ejemplo:

• utilizar el recurso DNS SRV (iniciales de las palabras en inglés"Domain Name System Service Record'): este enfoque sólo se aplica a aplicaciones que implican un intercambio de DNS; no se aplica a aplicaciones (tales como aplicaciones P2P) que intercambian informaciones de conectividad denominadas de referencia ("referrals"en inglés)(una información de referencia puede estructurarse, por ejemplo, como un nombre de dominio, una dirección IP o un número de puerto; véase https://tools.ietf.org/html/draft-carpenterbehave-referral-ob¡ect-00#section-4);

• utilizar un nuevo número de protocolo para identificar la versión UDP de múltiples vías: este enfoque puede considerarse en un entorno controlado, pero no puede implementarse a gran escala debido a la proliferación de NAT (iniciales de las palabras en inglés"Network Address Translater'que significan "Traductor de direcciones de Red") y de cortafuegos;

• definir extensiones de aplicación (FTP, por ejemplo): este enfoque sólo se aplica a ciertos protocolos y no se puede generalizar; o

• definir una nueva aplicación por encima de UDP; esta aplicación se dedicará en parte a verificar el soporte MPUDP por parte del terminal remoto.

Se describirá a continuación una realización de la invención, que se basa en el uso de concentradores de tráfico compatibles con comunicaciones UDP de múltiples vías.

Se recuerda a este respecto que, para permitir que terminales, pasarelas residenciales (por ejemplo, pasarelas domésticas o de empresa), decodificadores de TV y otros dispositivos cliente se beneficien de comunicaciones de múltiples vías, los operadores de red utilizan dispositivos denominados "concentradores de tráfico". Un "concentrador de tráfico" (se usará ocasionalmente simplemente el término "concentrador" en aras de la brevedad) es una función de red, física o virtual, que permite agregar comunicaciones UDP explotando las diferentes vías susceptibles de ser utilizadas por un dispositivo para establecer una comunicación UDP con un dispositivo remoto.

La función concentrador puede estar alojada en un centro de procesamiento de datos("data centefen inglés) o integrado en un equipo de la red de transporte. Un concentrador puede ser una función integrada en una pasarela residencial, coexistir con una función relé MPTCP("proxyen inglés) o SCTP (Stream Control Transmission Protocol) o con un punto de terminación de túnel GRE (Generic Routing Encapsulation), o también ser un punto final de túneles IP-in-IP o de túneles de nivel 2. Llegado el caso, la agregación de todos las múltiples vías mediante un concentrador puede dar lugar a la creación de uno o más túneles virtuales, por ejemplo para facilitar las operaciones de gestión (aislando el tráfico intercambiado en las diferentes vías así agregadas, y mejorando el proceso de detección de fallos) vinculadas al establecimiento de esta comunicación.

Las Figuras 7a, 7b y 7c ilustran, a modo de ejemplo, varios tipos de arquitecturas asociadas con concentradores de tráfico.

Estas figuras muestran un terminal T conectado a una o más redes IP R1, ..., Rm u O a través deNnodos(P1 ,P<2>, ... ,Pn)que incorpora una función de concentrador de tráfico. Tal nodo puede ser, por ejemplo, una pasarela (doméstica o de empresa) o un enrutador IP. Se puede ver en las figuras que:

- el terminal se puede conectar a una única red O gestionada por un único proveedor de conectividad IP que haya desplegado al menos un concentrador de tráfico (Figura 7a), o

- el terminal se puede conectar a m redes R1, ..., Rm que albergan al menos un concentrador de tráfico (Figura 7b), o también

- el terminal se puede conectar a m redes R1, ..., Rm, parte de las cuales alberga varios concentradores de tráfico (Figura 7c).

Ahora bien, ventajosamente, la intervención de un concentrador de tráfico tiene en particular el efecto de que una comunicación que es vista por un dispositivo local como siendo una comunicación de múltiples vías, puede ser vista por un dispositivo remoto como siendo una comunicación simple, tal como se ilustra en la Figura 8.

Pero un proveedor de conectividad IP puede también decidir utilizar un concentrador de tráfico en la o las vías a través de las cuales se establece la comunicación, incluso si el dispositivo remoto es compatible con las comunicaciones de múltiples vías. En efecto, la utilización de un concentrador permite ventajosamente controlar permanentemente la calidad de la comunicación agregada. Por otro lado, la presencia de un concentrador facilita la activación de los filtros necesarios para fines de intercepción legal, ya que la totalidad del tráfico pasa por el concentrador.

La implementación de dicha realización requiere las siguientes etapas preliminares, durante las cuales un dispositivo cliente (tal como un terminal o una pasarela residencial) señala su compatibilidad con MPUDP a uno o más concentradores.

Según una primera etapa, dicho dispositivo cliente adquiere informaciones (una o más direcciones IP, típicamente) que le permitirá enviar datagramas UDP a uno o más concentradores. Esta operación se puede llevar a cabo mediante configuración o de manera dinámica utilizando un protocolo tal como DHCP (o cualquier otro protocolo capaz de enviar la información característica del o de los concentradores hacia el dispositivo cliente). El dispositivo cliente dispone así de una o más direcciones IP de concentradores.

Según una segunda etapa, se comunica al concentrador las informaciones descriptivas de las condiciones de conexión a las redes (así como, llegado el caso, otras informaciones útiles). Esta operación es necesaria durante cualquier alteración de las condiciones de conexión a las redes (por ejemplo, reinicio del dispositivo cliente, conexión del dispositivo cliente a una nueva red, pérdida de conexión del dispositivo cliente a una red). Se entenderá que no es necesario realizar esta operación para cada nueva comunicación UDP de múltiples vías, sino en función de las condiciones de conexión a la red.

Según una primera variante, denominada modo "Registro", e ilustrada en la Figura 9, en el caso particular en el que el dispositivo cliente es una pasarela residencial CPE, el dispositivo cliente envía al concentrador un mensaje REGISTER() que incluye las diferentes direcciones, y eventualmente los diferentes números de puertos asignados al dispositivo cliente. Este mensaje REGISTER() se puede enviar, por ejemplo, a una plataforma de mediación, que se encargará de informar el o los concentradores a los que está asociado el dispositivo cliente. El dispositivo cliente puede eventualmente incluir claves de seguridad en el mensaje REGISTER() para evitar que un concentrador malicioso se inserte en una comunicación. El dispositivo cliente también puede indicar una vida útil asociada con al menos una dirección o al menos un número de puerto entre los que comunica al concentrador. El dispositivo cliente puede utilizar los contratos DHCP para informar la duración durante la cual se puede utilizar una dirección IP. Una vida útil establecida en "0" indica que esta dirección ya no es válida y el concentrador ya no debe utilizarla para comunicaciones UDP de múltiples vías. La clave de seguridad se utiliza para calcular un valor resumen ("hash" en inglés) para determinar si un datagrama se transmite desde un concentrador legítimo (es decir, autorizado para procesar el tráfico UDP recibido, o hacia el destino, del dispositivo cliente).

Después de recibir este mensaje REGISTER(), el concentrador responde al dispositivo cliente con un mensaje OK() si la operación se ha desarrollado exitosamente, o con un mensaje ERROR(Código) en caso contrario. Este mensaje OK() debe incluir el conjunto de las direcciones IP y/o números de puerto tales como mantiene el concentrador.

En caso de conflicto entre las informaciones devuelta por el concentrador y las mantenidas localmente por el dispositivo cliente, este último puede tomar acciones para eliminar direcciones no válidas o agregar nuevas direcciones. Esto da como resultado la transmisión de nuevos mensajes REGISTER() a destino del concentrador. El "Código" del mensaje ERROR() indica el motivo de fracaso de tratamiento de la solicitud REGISTER(). El dispositivo cliente debe adaptar su comportamiento al Código devuelto por el concentrador. Por ejemplo, no debe solicitar el concentrador si el Código indica que el concentrador no dispone de recursos suficientes para procesar el tráfico UDP transmitido por, o a destino de, el dispositivo cliente, o si el Código indica un rechazo de autorización.

Según una segunda variante, denominada modo "Mediación", e ilustrada en la Figura 10, en el caso particular en el que el dispositivo cliente es una pasarela residencial CPE, no se requiere ninguna acción por parte del dispositivo cliente. Se informa al concentrador de los dispositivos cliente que tienen la capacidad de establecer comunicaciones UDP de múltiples vías, así como de las direcciones asociadas y eventualmente de los números de puerto, a través de una plataforma de mediación operada por el proveedor del servicio. Típicamente, la plataforma de mediación se basa en contratos de adjuntos a las diferentes redes para proporcionar las informaciones correspondientes a uno o varios concentradores. Las mismas primitivas (REGISTER(), OK(), etc.) que para el modo "Registro" se pueden utilizar para el modo "Mediación".

En los ejemplos que se describen a continuación de dicha realización de la invención se pueden distinguir dos tipos de situaciones.

La primera situación se refiere a las comunicaciones durante las que un concentrador de tráfico recibe un datagrama UDP enviado según el modo de transporte UDP de múltiples vías, y transmite después ese datagrama UDP a su destinatario según el modo de transporte UDP simple (clásico). En este caso, de manera general, las informaciones relativas a la comunicación de múltiples vías (en particular el identificador de contexto Context_ID) se eliminan del datagrama UDP transmitido al destinatario final. Sin embargo, bajo ciertas condiciones (por ejemplo, si el identificador de contexto Context_ID está codificado de tal manera que su presencia en los datagramas UDP no interrumpe el establecimiento de una comunicación UDP simple), el concentrador puede enviar este datagrama UDP a su destinatario sin eliminar el identificador de contexto Context_ID; el concentrador puede aplicar este procedimiento para todas las comunicaciones UDP, o sólo para una parte de estas comunicaciones.

La segunda situación se refiere a las comunicaciones durante las cuales los datagramas UDP recibidos por un concentrador de tráfico según el modo de transporte UDP simple y asociados a una determinada sesión son distribuidos por el concentrador entre las diferentes vías de una comunicación UDP de múltiples vías que permite llegar al destinatario de estos datagramas UDP. Esta distribución del tráfico obedece entonces a una lógica preconfigurada; por ejemplo, se agregan todos los recursos asociados con todas las vías, o bien el tráfico se distribuye según los pesos de distribución, o incluso sólo se utilizan determinadas vías; cuando el concentrador recibe un datagrama UDP, consulta una tabla de registro que lista todas las direcciones y/o números de puerto del destinatario del datagrama UDP recibido, identifica si hay varias vías disponibles para esta sesión, asigna un identificador de contexto Context_ID si ninguno de los paquetes ya ha sido procesado para esta sesión o reutiliza un identificador de contexto Context_ID ya asignado para esta sesión, y después envía el datagrama UDP a la dirección IP y/o número de puerto de dicho destinatario asociados con la vía elegida para enviar este datagrama UDP.

Según un primer ejemplo, ilustrado en la Figura 11, un terminal T compatible con MPUDP intercambia mensajes con un servidor S no compatible con MPUDP, a través de un concentrador C y tres redes N1, N2 y N3, así como, opcionalmente, a través de una pasarela residencial CPE.

Según un segundo ejemplo, ilustrado en la Figura 12a, un terminal T compatible con MPUDP envía mensajes UDP a dos terminales remotos S1 y S2 no compatibles con MPUDP a través de un concentrador C, distribuyendo el tráfico UDP entre varias vías. Identificadores de contexto diferentes son asignados por el terminal T para cada una de las comunicaciones en curso (dos comunicaciones con el mismo terminal S1 y una comunicación con el terminal S2).

Según un tercer ejemplo, ilustrado en la Figura 12b, un terminal T compatible con MPUDP recibe mensajes UDP por parte de dos terminales remotos S1 y S2 no compatibles con MPUDP a través de un concentrador C, que distribuye el tráfico UDP entre varias vías. Identificadores de contexto diferentes son asignados por el concentrador C para cada una de las comunicaciones en curso (dos comunicaciones con el mismo terminal S1 y una comunicación con el terminal S2).

Los siguientes ejemplos involucran una pasarela CPE y un concentrador de tráfico que son ambos compatibles con MPUDP Además, la pasarela CPE alberga un terminal T que puede ser compatible, o no compatible, con MPUDP; es por tanto esta pasarela CPE la que se encarga aquí de gestionar las comunicaciones UDP del terminal T; ventajosamente, en esta realización, no se impone ninguna restricción (por ejemplo, actualización de software) al terminal T.

En estos ejemplos, los datagramas UDP recibidos por la pasarela CPE por parte del terminal T se distribuyen entre las diferentes vías múltiples según una lógica de distribución de tráfico preconfigurada; por ejemplo, se agregan todos los recursos asociados con todas las vías, o el tráfico se distribuye según los pesos de distribución, o sólo se utilizan determinadas vías.

Después de recibir un datagrama UDP transmitido por el terminal T en el ámbito de una determinada comunicación UDP, la pasarela CPE consulta una tabla de registro que lista el conjunto de las direcciones (y/o números de puerto) del concentrador, determina si hay múltiples vías disponibles para esta sesión, recupera una o más direcciones IP o números de puerto, asigna un identificador de contexto Context_ID si ya no se han procesado ningún paquete para esta sesión, o reutiliza un identificador de contexto ya asignado para esta sesión, y después envía el datagrama UDP a la dirección IP y el número de puerto del concentrador C asociados con la vía elegida para enviar este datagrama UDP.

En el caso particular en el que el terminal T es compatible con MPUDP, puede transmitir datagramas UDP hacia la pasarela CPE utilizando una comunicación UDP de múltiples vías para la cual el terminal T ha elegido un determinado identificador de contexto "ID#1". Si la pasarela CPE ya utiliza este identificador de contexto ID#1 para otra comunicación MPUDP que involucra al concentrador C (y por ejemplo otro terminal en su red privada), la pasarela CPE asigna otro identificador de contexto "ID#2" a los datagramas UDP recibidos del terminal T y transmitido al concentrador C, y mantiene en memoria la correspondencia entre los identificadores de contexto ID#1 e ID#2 en relación con el terminal T.

Según un cuarto ejemplo de dicha realización, ilustrado en las Figuras 13a y 13b, un terminal T transmite datagramas UDP hacia un servidor S no compatible con MPUDP, a través de una pasarela residencial CPE, dos redes N1 y N2, y un concentrador C.

En este ejemplo, la pasarela residencial CPE inserta la información Order_Rank descrita anteriormente (además del identificador de contexto Context_ID). Se supone, por ejemplo, que los datagramas "1", "2" y "5" son enviados por la pasarela residencial CPE a través de la primera vía, mientras que los datagramas "3", "4", "6" y "7" se envían a través de la segunda vía. Después de la recepción de estos diferentes paquetes por el concentrador de tráfico C, este último utiliza la información Order_Rank para decidir si un datagrama debe transmitirse inmediatamente al servidor S o si debe esperar la llegada de otros datagramas antes de transmitirlo. Para evitar que la función de reordenación induzca un retraso significativo, se puede esperar que el concentrador transmita los paquetes puestos en espera después de la expiración de una duración REORDER_MAX. Por ejemplo, si el orden de llegada de los paquetes a través de ambas vías es {"1", "2", "5", "3", "4", "6", "7"}, el concentrador de tráfico C debe primero procesar los paquetes "1" y "2"; el paquete cuyo valor de la información "Order_Rank" es igual a "5" se pone en espera hasta que se reciban los paquetes "3" y "4"; una vez recibidos estos paquetes, el concentrador transmite el datagrama "5". Suponiendo que los paquetes "3" y "4" no se reciben dentro de un plazo REORDER_MAX, entonces el paquete "5" se transmite a su destino sin esperar los paquetes que faltan.

Según un quinto ejemplo, ilustrado en las Figuras 14a y 14b, un terminal T colocado detrás de una pasarela residencial CPE compatible con MPUDP intercambia datagramas UDP con dos terminales S1 y S2 no compatibles con MPUDP, a través de una pasarela residencial CPE y un concentrador C.

En la Figura 14a, la pasarela CPE distribuye el tráfico UDP recibido desde el terminal T y destinado a los terminales remotos S1 y S2 entre dos vías que permiten llegar al concentrador C. Identificadores de contexto Context_ID diferentes son asignados por la pasarela CPE para cada una de las comunicaciones en curso.

En la Figura 14b, el concentrador C intercepta el tráfico UDP transmitido por los terminales S1 y S2 con destino al terminal T, y distribuye este tráfico entre dos vías que permiten llegar a la pasarela CPE. En este caso, el concentrador C "transforma" cada sesión UDP simple en una sesión UDP de múltiples vías. Identificadores de contexto Context_ID diferentes son asignados por el concentrador C para cada una de las comunicaciones en curso. Finalmente, la pasarela CPE, tras recibir un datagrama UDP enviado por una vía utilizada por la comunicación de múltiples vías, lo envía al terminal T según el modo de transporte UDP (simple) clásico: de manera general (véanse las excepciones anteriores), las informaciones que se refieren a las múltiples vías son entonces eliminas de este datagrama, en particular el identificador de contexto Context_ID.

Para evitar recurrir a túneles y optimizar mejor los recursos de red disponibles, las informaciones adicionales se transportan preferiblemente en un datagrama UDP dentro de una comunicación UDP establecida a través de múltiples vías. Estas informaciones (véanse las Figuras 12a, 12b, 14a y 14b) comprende, en particular:

• una información de "Origin Source” (ORSC): esta información contiene la dirección IP o el número de puerto fuente tal como se proporciona por la fuente del tráfico UDP;

• una información de "Ultimate Destination" (UDST): esta información contiene la dirección IP o el número de puerto de destino tal como se proporciona por la fuente del tráfico UDP.

Un concentrador de tráfico UDP puede utilizar estas informaciones ORSC y UDST de la siguiente manera.

° Después de la intercepción de un datagrama UDP destinado a una pasarela CPE, el concentrador copia la dirección fuente del paquete (o número de puerto fuente) en una instancia ORSC, inserta esta instancia ORSC en el datagrama UDP y reemplaza la dirección fuente con una de las direcciones del concentrador. El concentrador puede eventualmente reescribir el número de puerto fuente. El concentrador activa al menos un mecanismo para distribuir el tráfico entre varias vías. Por ejemplo, para mejorar los rendimientos de la transmisión de datagramas UDP, el concentrador puede decidir agregar los datos enviados por uno o más datagramas UDP en un único datagrama UDP, que será enviado a la pasarela CPE en el contexto de un sesión UDP de múltiples vías. El datagrama UDP así construido se transmite a continuación a una de las direcciones de la pasarela CPE. Cabe señalar que el orden de ejecución de las etapas anteriores se proporciona únicamente con fines ilustrativos y que, además, estas etapas no son exhaustivas.

° Después de recibir un datagrama UDP desde una pasarela CPE, el concentrador reemplaza la dirección de destino con la dirección (o el número de puerto) tal como se especifica en la instancia UDST; después, el concentrador elimina las informaciones UDST así como el identificador de contexto Context_ID del paquete. El concentrador puede reescribir la dirección fuente o el número de puerto fuente del paquete. El datagrama UDP así construido se transmite al siguiente salto IP.

Una pasarela residencial CPE puede utilizar las informaciones ORSC y UDST de la siguiente manera.

° Después de la intercepción de un datagrama UDP destinado a un concentrador, la pasarela CPE copia la dirección de destino del paquete (o el número de puerto de destino) en una instancia UDST, inserta esta instancia UDST en el datagrama UDP y reemplaza la dirección de destino con una de las direcciones del concentrador. La pasarela CPE puede eventualmente reescribir el número de puerto de destino. La pasarela CPE activa al menos un mecanismo de distribución de tráfico entre múltiples vías. Por ejemplo, para mejorar los rendimientos de la transmisión de datagramas UDP, la pasarela CPE puede decidir agregar los datos enviados por uno o más datagramas UDP en un único datagrama UDP que se enviará al concentrador en el contexto de una comunicación UDP de múltiples vías. El datagrama UDP así construido se transmite entonces al concentrador.

° Después de recibir un datagrama UDP de un concentrador, la pasarela CPE reemplaza la dirección fuente con la dirección (o el número de puerto) tales como se especifica en la instancia OSRC, después elimina las informaciones ORSC y el identificador de contexto enviado en el datagrama UDP recibido. El datagrama UDP así construido se transmite al siguiente salto IP.

Según una realización particular de la invención, un datagrama UDP recibido en el ámbito de una comunicación MPUDP puede ser transformado por un dispositivo de comunicación compatible con MPUDP, tal como un concentrador o una pasarela CPE, en uno o más datagramas UDP "clásicos", es decir datagramas UDP característicos de una comunicación UDP establecida en una única vía. Los datos transportados por varios (N) datagramas UDP clásicos de una misma comunicación pueden ser incluidos por un concentrador o una pasarela CPE en un mismo paquete, o en diferentes paquetes a través de múltiples vías.

En particular, si se utiliza un mismo datagrama UDP para transmitir datos recibidos dentro de varios datagramas UDP clásicos, el concentrador o la pasarela CPE debe, además de las operaciones ya mencionadas anteriormente, incluir un objeto UDLL (UDP Datagram Length List) en el datagrama UDP así construido, como se ilustra en la Figura 15. El objeto UDLL está estructurado de la siguiente manera: {Count, L<1>, ..., L<count>}. El campo "Count" indica el número de datagramas UDP "clásicos" cuyos datos se incluyen en un mismo datagrama UDP así construido. El campo L<i>{i=1, count} indica la longitud de cada segmento de datos que corresponde a un datagrama UDP clásico cuyo contenido está incluido en el datagrama UDP así construido; esta longitud no incluye la cabecera UDP de 8 bytes, sino que sólo identifica los datos útiles transportados en un datagrama UDP clásico. Por ejemplo, si el concentrador o la pasarela CPE decide agregar en un mismo datagrama UDP los datos contenidos en tres datagramas UDP clásicos y cuyos respectivos tamaños UDP (es decir, sin la cabecera UDP) son L1, L2 y L3, el concentrador o la pasarela CPE insertará un objeto UDLL{3, L1, L2, L3} en el datagrama UDP transmitido.

Después de la recepción de un datagrama UDP que contiene un objeto UDLL, el concentrador o la pasarela CPE transforma este mensaje en un número de "Count" de datagramas UDP clásicos, de tamaño UDP 8 L<i>, en el que {i=1, ..., Count} incluyendo la cabecera UDP de 8 bytes. Por ejemplo, si el concentrador o la pasarela CPE recibe un datagrama UDP con un objeto UDLL{3, L1, L2, L3}, el concentrador o la pasarela CPE transforma este paquete recibido en tres datagramas UDP clásicos; el tamaño UDP del primer datagrama UDP es "L1+8", el del segundo es "L2+8" y el del tercero es "L3+8".

La invención se puede implementar dentro de nodos de redes de comunicación, por ejemplo dispositivos cliente, pasarelas residenciales o concentradores de tráfico, mediante componentes de software y/o hardware. Dichos componentes de software pueden integrarse en un programa informático clásico de gestión de nodos de red. Por lo tanto, como se indicó anteriormente, la presente invención también se refiere a un sistema informático. Este sistema informático comprende clásicamente 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 se puede utilizar para ejecutar un programa informático que comprende instrucciones para implementar cualquiera de los procedimientos de comunicación según la invención.

En efecto, la invención también se refiere a un programa informático como se describió brevemente anteriormente. Este programa informático puede almacenarse en un soporte legible por un ordenador y puede ejecutarse mediante un microprocesador. Este programa puede usar cualquier lenguaje de programación y presentarse en forma de código fuente, código objeto, o código intermedio entre el código fuente y el código objeto, tal como en forma parcialmente compilada o en cualquier otra forma deseable.

La invención también se refiere a un soporte de informaciones inamovible, o parcial o totalmente amovible, que comprende instrucciones para un programa informático como se describió brevemente anteriormente.

Este soporte de informaciones puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte de informaciones puede comprender un medio de almacenamiento, tal como una ROM, por ejemplo un CD-ROM o una ROM de circuito microelectrónico, o un medio de grabación magnético, tal como un disco duro, o incluso una llave USB('USB flash drive")en Inglés).

Por otro lado, el soporte de informaciones puede ser un soporte transmisible tal como una señal eléctrica u óptica, que puede transmitirse a través de un cable eléctrico u óptico, por radio o por otros medios. El programa informático según la invención se puede descargar en particular en una red tal como Internet.

Alternativamente, el soporte de informaciones puede ser un circuito integrado en el que se incorpora el programa, estando adaptado el circuito para ejecutar o ser usado en la ejecución de cualquiera de los procedimientos de comunicación según la invención.

Claims (13)

REIVINDICACIONES

1. Procedimiento de comunicación en una red IP, que comprende las siguientes etapas:

a) un primer dispositivo de comunicación inicia una comunicación con un segundo dispositivo de comunicación, señalando a dicho segundo dispositivo de comunicación que dicho primer dispositivo de comunicación es compatible con las comunicaciones de múltiples vías basadas en el protocolo de transporte UDP, User Datagram Protocol, una comunicación UDP a múltiples vías establecida entre el primer y el segundo dispositivo de comunicación se compone de varias comunicaciones UDP simples y es susceptible de tomar simultáneamente varias vías distintas entre estos dos dispositivos de comunicación, y

b) si el segundo dispositivo de comunicación también es compatible con las comunicaciones UDP de múltiples vías:

- el primer dispositivo de comunicación envía datos útiles al segundo dispositivo según el protocolo de transporte UDP, incluyendo en los datagramas UDP que contienen estos datos útiles, sea cual sea la vía utilizada, un mismo identificador, denominado identificador de contexto (Context_ID), que permite al segundo dispositivo de comunicación correlacionar el conjunto de dichos datagramas UDP asociados con una misma comunicación UDP de múltiples vías que han tomado vías distintas, y/o

- el segundo dispositivo de comunicación envía datos útiles al primer dispositivo según el protocolo de transporte UDP, incluyendo en los datagramas UDP que contienen estos datos útiles, sea cual sea la vía utilizada, un mismo identificador, denominado identificador de contexto (Context_ID), que permite al primer dispositivo de comunicación correlacionar el conjunto de dichos datagramas UDP asociados con una misma comunicación UDP de múltiples vías y que han tomado vías distintas.

2. Procedimiento de comunicación según la reivindicación 1, caracterizado por que dicho primer dispositivo de comunicación y/o dicho segundo dispositivo de comunicación inserta además en dichos datagramas UDP un testigo de seguridad (Authentication_Token) que permite al receptor de estos datagramas UDP autenticar al transmisor.

3. Procedimiento de comunicación según la reivindicación 1 o la reivindicación 2, caracterizado por que dicho primer dispositivo de comunicación y/o dicho segundo dispositivo de comunicación inserta además en dichos datagramas UDP una información (Order_Rank) que permite al receptor de estos mensajes procesarlos en su orden de transmisión.

4. Procedimiento de comunicación según una cualquiera de las reivindicaciones 1 a 3, caracterizado por que, siendo dicho primer dispositivo de comunicación y/o dicho segundo dispositivo de comunicación un concentrador de tráfico, dicho procedimiento comprende además las siguientes etapas:

- dicho concentrador de tráfico recibe un datagrama UDP enviado en una vía utilizada por una comunicación UDP de múltiples vías, y

- el concentrador de tráfico envía este datagrama UDP a su destinatario según el modo de transporte UDP simple.

5. Procedimiento de comunicación según una cualquiera de las reivindicaciones 1 a 4, caracterizado por que dicho primer dispositivo de comunicación y/o dicho segundo dispositivo de comunicación un concentrador de tráfico capaz de distribuir datagramas UDP recibidos según el modo de transporte UDP simple y asociados a una determinada sesión, entre diferentes vías de una comunicación UDP de múltiples vías que permite llegar al destinatario de estos datagramas UDP, dicho procedimiento comprende además las siguientes etapas:

- después de la recepción de un datagrama UDP, el concentrador de tráfico consulta una tabla de registro que lista el conjunto de las direcciones y/o números de puerto del destinatario del datagrama UDP recibido,

- el concentrador de tráfico asigna un identificador de contexto (Context ID) si ya no se ha procesado ningún paquete para esta sesión o reutiliza un identificador de contexto (Context ID) ya asignado para esta sesión, y

- el concentrador de tráfico envía el datagrama UDP hacia la dirección IP y/o el número de puerto de dicho destinatario asociado con la vía elegida para enviar este datagrama UDP.

6. Dispositivo de comunicación, denominado primer dispositivo de comunicación, caracterizado por que comprende medios para:

- iniciar una comunicación con otro dispositivo de comunicación, denominado segundo dispositivo de comunicación, dentro de una red IP, señalando a dicho segundo dispositivo de comunicación que dicho primer dispositivo de comunicación es compatible con comunicaciones las UDP, User Datagram Protocol, de múltiples vías, una comunicación UDP de múltiples vías establecida entre el primer y el segundo dispositivo de comunicación está compuesta por varias comunicaciones UDP simples y susceptible de tomar simultáneamente varias vías distintas entre estos dos dispositivos de comunicación,

- enviar datos útiles según el protocolo UDP al segundo dispositivo de comunicación, incluyendo en los datagramas UDP que contienen estos datos útiles, sea cual sea la vía utilizada, un mismo identificador, denominado identificador de contexto (Context_ID), permitiendo al segundo dispositivo de comunicación correlacionar el conjunto de dichos datagramas UDP asociados con una misma comunicación UDP de múltiples vías y que han tomado vías distintas, y

- recibir datos útiles según el protocolo UDP por parte del segundo dispositivo de comunicación, detectando en los datagramas UDP que contienen estos datos útiles, sea cual sea el camino utilizado, un mismo identificador, denominado identificador de contexto (Context_ID), permitiendo al primer dispositivo de comunicación correlacionar el conjunto de los datagramas UDP asociados con una misma comunicación UDP de múltiples vías que han tomado vías distintas.

7. Dispositivo de comunicación según la reivindicación 6, caracterizado por que comprende además medios para insertar en los datagramas UDP que emite un testigo de seguridad (Authentication_Token) que permiten al receptor de estos mensajes autentificar al transmisor.

8. Dispositivo de comunicación según la reivindicación 6 o 7, caracterizado por que comprende además medios para insertar información en los datagramas UDP que transmite una información (Order_Rank), permitiendo al receptor de estos mensajes procesarlos en su orden de emisión.

9. Dispositivo de comunicación según una cualquiera de las reivindicaciones 6 a 8, caracterizado por que comprende un concentrador de tráfico que tiene medios para, cuando recibe un datagrama UDP enviado por una vía utilizada por la comunicación UDP de múltiples vías, enviar este datagrama UDP a su destinatario según el modo de transporte UDP simple.

10. Dispositivo de comunicación según una cualquiera de las reivindicaciones 6 a 9, caracterizado por que comprende un concentrador de tráfico que tiene medios para distribuir datagramas UDP recibidos según el modo de transporte UDP simple y asociados a una determinada sesión, entre diferentes vías de una comunicación UDP de múltiples vías que permite alcanzar el destinatario de estos datagramas UDP, así como los medios para, después de la recepción de un datagrama UDP:

- consultar una tabla de registro que lista el conjunto de las direcciones y/o números de puerto del destinatario del datagrama UDP recibido,

- asignar un identificador de contexto (Context ID) si ya no se ha procesado ningún UDP para esta sesión o reutiliza un identificador de contexto (Context ID) ya asignado para esta sesión, y

- enviar el datagrama UDP hacia la dirección IP y/o el número de puerto de dicho destinatario asociado con la vía elegida para enviar este datagrama UDP.

11. Dispositivo de comunicación según una cualquiera de las reivindicaciones 6 a 10, caracterizado por que comprende un dispositivo cliente (T), una pasarela doméstica o de empresa (CPE) o un concentrador de tráfico (C).

12. Medios de almacenamiento de datos inamovible, o parcial o totalmente amovible, que comprenden instrucciones de código de programa informáti

cualquiera de las reivindicaciones 1 a 5.

13. Programa informático descargable desde una red de comunicaciones y/o almacenado en un soporte legible por ordenador y/o ejecutable por un microprocesador, caracterizado por que comprende instrucciones para ejecutar las etapas de un procedimiento de comunicación según una cualquiera de las reivindicaciones 1 a 5, cuando se ejecuta en un ordenador.