ES2832813T3 - Procedimiento de comunicación UDP a través de trayectorias múltiples entre dos terminales - Google Patents

Procedimiento de comunicación UDP a través de trayectorias múltiples entre dos terminales Download PDF

Info

Publication number
ES2832813T3
ES2832813T3 ES17737324T ES17737324T ES2832813T3 ES 2832813 T3 ES2832813 T3 ES 2832813T3 ES 17737324 T ES17737324 T ES 17737324T ES 17737324 T ES17737324 T ES 17737324T ES 2832813 T3 ES2832813 T3 ES 2832813T3
Authority
ES
Spain
Prior art keywords
communicating device
udp
communication
communicating
protocol
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES17737324T
Other languages
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Application granted granted Critical
Publication of ES2832813T3 publication Critical patent/ES2832813T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Procedimiento de comunicación en una red IP, que comprende las etapas siguientes: a) un primer dispositivo comunicante, compatible con comunicaciones UDP con trayectorias múltiples, inicializa una comunicación con un segundo dispositivo comunicante, señalando a dicho segundo dispositivo comunicante que dicho primer dispositivo comunicante es compatible con las comunicaciones con trayectorias múltiples que se basan en el protocolo de transporte UDP, User Datagram Protocol, y b) si el segundo dispositivo comunicante es, a su vez, compatible con las comunicaciones UDP con trayectorias múltiples: - el primer dispositivo comunicante envía datos al segundo dispositivo según el protocolo de transporte UDP, incluyendo en los mensajes que contienen estos datos, independientemente de la trayectoria utilizada, un mismo identificador, llamado identificador de contexto, que permite al segundo dispositivo comunicante correlacionar el conjunto de los datagramas UDP asociados a una misma comunicación UDP con trayectorias múltiples, y/o - el segundo dispositivo comunicante envía datos al primer dispositivo según el protocolo de transporte UDP, incluyendo en los mensajes que contienen estos datos, independientemente de la trayectoria utilizada, un mismo identificador, llamado identificador de contexto, que permite al primer dispositivo comunicante correlacionar el conjunto de los datagramas UDP asociados a una misma comunicación UDP con trayectorias múltiples; comprendiendo además dicho procedimiento de comunicación las siguientes etapas: - el primer dispositivo comunicante emite (E1) un mensaje UDP, que es interceptado por un relé integrado en este primer dispositivo comunicante, - dicho relé emite (E2) hacia el segundo dispositivo comunicante, un mensaje de establecimiento de sesión según el protocolo de transporte TCP, Transmission Control Protocol, que contiene una opción dedicada capaz de señalar a dicho segundo dispositivo comunicante que el primer dispositivo comunicante es compatible con las comunicaciones UDP con trayectorias múltiples, y - si el segundo dispositivo comunicante es, a su vez, compatible con las comunicaciones UDP con trayectorias múltiples, emite (E3) un mensaje de respuesta según el protocolo de transporte TCP en el que inserta dicha opción dedicada, a continuación, el primer dispositivo comunicante envía datos al segundo dispositivo comunicante y/o el segundo dispositivo comunicante envía datos al primer dispositivo comunicante, utilizando (E4) una comunicación UDP con trayectorias múltiples.

Description

DESCRIPCIÓN
Procedimiento de comunicación UDP a través de trayectorias múltiples entre dos terminales
La presente invención se refiere al campo de las telecomunicaciones, y en concreto las redes de comunicación capaces de implementar el protocolo IP (Internet Protocol). Más particularmente, la presente invención se refiere a la provisión de servicios en las redes IP "con valor añadido", es decir las redes capaces de efectuar procesamientos diferenciados según la naturaleza del tráfico encaminado en la red.
La invención se aplica en particular a todo tipo de dispositivo-cliente ("User Equipment" en inglés) tal como un terminal fijo o móvil, una "TV conectada", o una pasarela residencial (es decir una pasarela doméstica o situada en una empresa), o una pasarela de operador de red ("Gateway" en inglés), o incluso un decodificador TV ("Set-Top Box", o STB en inglés). En aras de la concisión, un dispositivo-cliente de cualquier tipo se denominará a menudo "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) hoy en día son capaces de activar y de explotar varias interfaces lógicas vinculadas a una o varias interfaces físicas. Dichos terminales se denominan "multi-interfaz" ("Multi-lnterface", 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 entonces de un acceso llamado "híbrido", porque combina diferentes tecnologías de redes de acceso.
Varias direcciones IP pueden ser atribuidas entonces 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 (acrónimo de la expresión en inglés "Wireless Local Area Network' que significa "Red de área local inalámbrica", de la cual las redes 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 ambas),
• tener periodos de vida diferentes,
• tener alcances diferentes, por ejemplo, dirección IPv4 privada, dirección IPv6 única de alcance local (Unique Local Address, o ULA en inglés), o dirección IPv6 de alcance 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ógicas.
Cabe destacar, sin embargo, 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 o a las redes, de la ubicación del dispositivo, o de otros factores. Un dispositivo se puede convertir en MIF durante el establecimiento de una comunicación simple (es decir, una comunicación establecida a lo largo de una trayectoria única con un interlocutor dado), o incluso después del establecimiento de una comunicación simple. Cabe destacar también que un dispositivo no sabe a priori si le es posible utilizar varias trayectorias distintas para establecer una comunicación con un interlocutor dado; más concretamente, el dispositivo solamente adquiere esta información (llegado el caso) al concluir una fase durante la cual intenta establecer una comunicación utilizando trayectorias múltiples con el interlocutor.
Se recuerda que una "comunicación con trayectorias múltiples" es una comunicación establecida entre dos dispositivos que toman simultáneamente una o varias trayectorias entre estos dos dispositivos. El establecimiento y el mantenimiento en actividad de dicha comunicación se basan en la utilización de un protocolo dedicado, tal como MPTCP (Multi-Path TCP), que se puede definir eventualmente como una extensión de un protocolo de transporte definido anteriormente, tal como TCP (acrónimo de la expresión en inglés "Transmission Control Protocol" que significan "Protocolo de control de transmisión"). Dicho de otra manera, una comunicación con trayectorias múltiples es un agregado de una o varias comunicaciones simples que toman una misma trayectoria o trayectorias diferentes (parcial o completamente separadas).
Se recuerda también que, en el campo de las redes, se denomina "agregación de enlaces" al agrupamiento de varios enlaces a tantas interfaces (lógicas) como si se tratara de un solo enlace asociado a una sola interfaz, en concreto con el objetivo de aumentar la velocidad de transferencia más allá de los límites de un solo enlace, pero también de aplicar los mismos procedimientos de explotación al conjunto de los enlaces así agregados (noción de "fate sharing" en inglés). En particular, las ofertas de servicios que conciernen a un terminal que dispone de un acceso híbrido se basan en la introducción en la red de funciones que permitan agregar el conjunto de las comunicaciones de red de un terminal (por ejemplo: WLAN y 3G, o ADSL, W lA n y 4G).
La agregación de enlaces permite también tratar de que otras interfaces tomen el relevo si un enlace de red falla (principio de redundancia). La agregación de enlaces se aplica a todo tipo de tráfico encaminado a lo largo de estos enlaces, incluyendo tráfico IP.
La agregación de enlaces también puede utilizarse para distribuir el tráfico en varios enlaces. En este caso, la distribución de tráfico entre enlaces que son objeto de un agregado depende de diversos parámetros; la distribución de tráfico puede depender, de este modo, de la política de ingeniería de tráfico (por ejemplo dar preferencia al encaminamiento de un tráfico particular en un enlace cuyas características en términos de robustez o de disponibilidad son 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, dar preferencia a ciertos enlaces en un contexto de priorización de tráfico.
A modo de ejemplo, se ha representado en la figura 1a un terminal T que comunica con un servidor S a través de varias redes IP denotadas R1,..., Rm y O, implementando un protocolo de comunicación con trayectorias múltiples. La naturaleza de las diferentes redes de acceso R1,..., Rm puede ser alámbrica, inalámbrica, u otra. Por otra parte, el terminal T puede tener la capacidad de conectarse a diferentes redes de acceso de manera simultánea o no.
Asimismo, se ha representado en la figura 1b un terminal T colocado detrás de un equipo, llamado dispositivo-relé R; este dispositivo-relé R comunica con un servidor S a través de varias redes IP denotadas r 1,..., Rm y O, implementando un protocolo de comunicación con trayectorias múltiples.
De manera general, se denominará "dispositivo-relé" un equipo ubicado en la red y que actúa en nombre de uno o de varios dispositivos-clientes, tales como un terminal o una pasarela. Esta configuración permite al dispositivo-cliente beneficiarse de un uso optimizado de los recursos de red disponibles, y también establecer comunicaciones con trayectorias múltiples en un plazo reducido.
Cabe destacar que la agregación de enlaces no establece ninguna hipótesis en cuanto a la configuración de la máquina remita. De este modo, una máquina fuente puede solicitar una función de agregación de enlaces sin que la máquina remota utilice dicha función.
Se pueden prever diversos modos de agregación, entre los cuales los tres modos siguientes:
• modo de respaldo ("backup" en inglés): este modo consiste en utilizar trayectorias secundarias en caso de indisponibilidad de trayectorias primarias, y esto, para mejorar la disponibilidad de red y, en consecuencia, la robustez y la 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 todo o parte de las trayectorias disponibles, pudiendo los flujos IP asociados a una misma aplicación distribuirse entre varias trayectorias; la elección de explotar la totalidad de las trayectorias, o solamente una parte de entre ellas, puede estar, por ejemplo, condicionada por la naturaleza del tráfico o las características de disponibilidad o de fiabilidad asociadas a cada trayectoria, las cuales pueden variar fuertemente de una trayectoria a otra; todas las trayectorias seleccionadas para este modo asociativo se considera que son trayectorias primarias; y
• modo llamado de "confort": este modo es similar al modo asociativo, salvo que los flujos de una aplicación dada no se distribuyen entre varias trayectorias, sino que son enviados en una sola trayectoria.
Cabe destacar que estos modos no son mutuamente excluyentes, y no son específicos de un tipo particular de tráfico. De este modo, se pueden implementar independientemente de la naturaleza del tráfico que será encaminado a lo largo de las trayectorias agregadas según uno u otro de los diferentes modos.
Los protocolos de transporte mayoritariamente utilizados por las aplicaciones de software para comunicarse en Internet son TCP (mencionado anteriormente) y UDP (acrónimo de la expresión en inglés "User Datagram Protocol" que significa "Protocolo de datagrama de usuario"). A este respecto, los medios técnicos que permiten a un dispositivocliente/dispositivo-relé optimizar el uso de los recursos de red disponibles en función de las necesidades y de las restricciones de las aplicaciones que se basan en TCP o UDP son de naturaleza para aportar una mejora significativa del nivel de calidad asociado a la utilización de dichas aplicaciones. Además, ciertos actores de Internet están experimentando a gran escala soluciones alternativas a TCP que se basan en UDP (y, más concretamente, en un esquema de encapsulación). Desde este punto de vista, los proveedores de servicio y operadores de redes IP están comprometidos a proporcionar un nivel de calidad de utilización comparable entre aplicaciones que se basan en TCP y las que se basan en UDP.
Es deseable, por lo tanto, disponer de una paridad funcional lo más grande posible entre TCP y UDP. En particular, sería útil poder establecer comunicaciones UDP a través de las trayectorias múltiples 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 las trayectorias múltiples.
En el marco de la presente invención, se denomina "datagrama UDP" un paquete IP transportado según el protocolo UDP.
Una solución a este problema se ha propuesto en el documento ("draft-Internet") de M. Boucadair et al. enviado a la IETF (Internet Engineering Task Force) y titulado "An MPTCP Option forNetwork-Assisted MPTCP Deployments: Plain Transport Mode". Esta solución utiliza el protocolo MPTCP para encaminar en particular tráfico UDP en el contexto de una conexión MPTCP. En el caso del tráfico UDP, la solución consiste en transformar datagramas UDP en paquetes TCP. Para esto, 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 concreto indicar explícitamente que los datos encaminados son datagramas UDP. De este modo, una función representante (proxy) MPTCP transforma un datagrama UDP en un paquete TCP procediendo de la siguiente manera:
- reemplazo de la cabecera UDP por una cabecera TCP, y
- inserción de una opción TCP cuyo campo "Protocol" está valorado en "17", lo que indica que el contenido del paquete TCP corresponde a datos UDP.
Tras la recepción de un paquete TCP que contiene dicha opción TCP, la función representante MPTCP procede de la siguiente manera:
- reemplazo de la cabecera TCP por una cabecera UDP, y
- transferencia del datagrama UDP construido de este modo hacia el próximo salto.
Esta solución permite ventajosamente utilizar las mismas funciones para establecer comunicaciones con trayectorias múltiples a la vez para el tráfico TCP y para el tráfico UDP.
El inconveniente de esta solución es que ofrece rendimientos degradados debido a la diferencia de tamaño entre la cabecera TCP (20 octetos sin contar las opciones, véase la figura 2a) y la cabecera UDP (8 octetos, 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 (acrónimo de la expresión en inglés "Máximum Transfer Unit'), que corresponde al tamaño máximo de los paquetes que pueden ser transmitidos en un enlace dado: si el tamaño de un paquete excede el valor de la MTU, entonces la fuente emisora del paquete es informada de este exceso y se le invita a fragmentar dicho paquete de tamaño superior al valor de MTU. Ahora bien, la modificación de dichos parámetros no siempre es posible en ciertos contextos, por ejemplo, debido a limitaciones tecnológicas. Además, el transporte fiable de datos característica del protocolo TCP puede inducir una degradación de servicio para aplicaciones UDP.
La presente invención se refiere, por lo tanto, a un procedimiento de comunicación en una red IP, según la reivindicación 1.
En efecto, los autores de la presente invención han constatado que los datagramas UDP enviados por un dispositivo comunicante emisor a un dispositivo comunicante receptor, utilizando diferentes direcciones IP fuente o diferentes números de puertos fuente, deben ser identificados de manera adecuada si se quiere permitir al dispositivo comunicante receptor correlacionar el conjunto de los datagramas UDP asociados a una misma comunicación UDP con trayectorias múltiples. Dicha identificación permite, en efecto, preservar la integridad del intercambio de los datos entre los dos dispositivos. Según la presente invención, el dispositivo comunicante emisor inserta en los datagramas UDP que emite un identificador de contexto, que se denominará "ContextJD"; dicha comunicación UDP con trayectorias múltiples se denominará "MPUDP".
Cabe destacar que, al contrario que 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 Boucadair et al. descrita sucintamente anteriormente), la presente invención se basa en el encaminamiento nativo de datagramas UDP.
Gracias a estas disposiciones, se obtiene una paridad funcional entre TCP y UDP para la gestión de trayectorias múltiples, estableciendo sesiones UDP a través de trayectorias múltiples de forma comparable al establecimiento de conexiones TCP a través de trayectorias múltiples, para procesar con la misma eficacia el conjunto del tráfico encaminado por Internet y que se basan indistintamente en el protocolo TCP o en el protocolo UDP.
Además, ventajosamente, la invención:
• no impone ninguna modificación a las aplicaciones de software que se basan en UDP;
• permite, para beneficiarse de las ventajas de la agregación de enlaces, evitar la utilización de túneles (como en las tecnologías "GTP bonding" o "GRE bonding" por ejemplo), cuya ingeniería, establecimiento y mantenimiento son fuentes de complicaciones y de una naturaleza que penaliza el nivel de calidad asociado a las comunicaciones que se basan en túneles;
• permite optimizar la utilización de los recursos de red disponibles sin ningún coste protocolario, y sin ruptura protocolaria que consiste, por ejemplo, en transformar datagramas UDP en paquetes transportados por medio de otros protocolos de transporte (por ejemplo, TCP); y
• permite desplegar una sola solución para todas las aplicaciones de software transportadas por medio del protocolo UDP, al contrario que las soluciones que necesitan la integración de la lógica de agregación en la propia aplicación. De este modo, se mejora significativamente la calidad de experiencia del usuario.
Un ejemplo típico de aplicación de la invención es la transferencia de archivos que utiliza los recursos del protocolo TFTP (Trivial File Transfer Protocol), o incluso la gestión optimizad de flujos de recopilación de estadísticas que se basan en el protocolo SNMP (acrónimo de la expresión en inglés "Simple Network Management Protocot'), que utiliza los puertos UDP 161 y 162. Un terminal que dispone de varias uniones red que actúan como cliente TFTp podrá explotar dinámicamente el conjunto de las trayectorias disponibles que le permiten acceder al servidor TFTP. El tiempo de transferencia de los datos mejorará de este modo en beneficio de una experiencia cliente optimizada. En el caso del tráfico SNMP, la invención permite, en particular, fiabilizar el encaminamiento del tráfico permitiendo utilizar una trayectoria de respaldo en caso de indisponibilidad de la trayectoria primaria.
Cabe destacar que los dispositivos comunicantes implicados en una comunicación según la invención pueden ser cualesquiera dispositivos compatibles con el protocolo IP. Dicho dispositivo comunicante puede ser de cualquier tipo, por ejemplo, un dispositivo-cliente, o un servidor de contenido accesible por Internet, o incluso un concentrador de tráfico (se recuerda que un "concentrador de tráfico" es una función red, física o virtual, que permite agregar las comunicaciones que explotan las diferentes trayectorias susceptibles de ser utilizadas por un dispositivo dado para establecer una comunicación con un dispositivo remoto). Puede disponer de una o varias direcciones IP asignadas a cada una de sus interfaces físicas o lógicas. También puede disponer solamente de una sola interfaz, en cuyo caso se supondrá que está situado detrás un dispositivo-relé (tal como un encaminador o una pasarela residencial) conectado a un o varias redes y compatible con un mecanismo de agregación de enlaces.
Según características particulares, el primer dispositivo comunicante y/o el segundo dispositivo comunicante inserta, además, en dichos mensajes un testigo de seguridad que permite al receptor de estos mensajes autentificar su emisor. Gracias a estas disposiciones, se puede evitar, por ejemplo, que un terminal tercero inserte datos en un mensaje con destino a un terminal T1 o a un terminal T2, mientras que no forma legítimamente parte de un intercambio en curso entre el terminal T1 y el terminal T2.
Según otras características particulares, el primer dispositivo comunicante y/o el segundo dispositivo comunicante inserta, además, en dichos mensajes una información que permite al receptor de estos mensajes procesarlos en su orden de emisión.
Gracias a estas disposiciones, se corrige un desfase eventual entre el orden de emisión y el orden de llegada de los datagramas UDP, desfase que puede ser provocado en concreto por una distorsión del nivel de calidad relativo a las diferentes trayectorias utilizadas.
Según también otras características particulares, dicho procedimiento comprende las siguientes etapas:
- un primer dispositivo comunicante, compatible con las comunicaciones UDP con trayectorias múltiples, emite un mensaje UDP, que es interceptado por un relé integrado en este primer dispositivo comunicante,
- dicho relé emite hacia un segundo dispositivo comunicante un mensaje de establecimiento de sesión según el protocolo de transporte TCP (Transmission Control Protocol) que contiene una opción dedicada capaz de señalar a dicho segundo dispositivo comunicante que el primer dispositivo comunicante es compatible con las comunicaciones UDP con trayectorias múltiples, y
- si el segundo dispositivo comunicante es, a su vez, compatible con las comunicaciones UDP con trayectorias múltiples, emite un mensaje de respuesta según el protocolo de transporte TCP en el que inserta dicha opción dedicada, a continuación, el primer dispositivo comunicante envía datos al segundo dispositivo comunicante y/o el segundo dispositivo comunicante envía datos al primer dispositivo comunicante, utilizando una comunicación UDP con trayectorias múltiples.
Gracias a estas disposiciones, se garantiza, gracias al protocolo TCP o MPTCP, la fiabilidad de los intercambios de datos (incluyendo por ejemplo el intercambio de direcciones IP, de números de puerto, o de testigos de seguridad) que permite el establecimiento de comunicaciones UDP con trayectorias múltiples.
Correlativamente, la invención se refiere a un dispositivo comunicante, llamado primer dispositivo según la reivindicación 4.
Según características particulares, dicho dispositivo comunicante comprende además medios para insertar en los mensajes que emite un testigo de seguridad que permite al receptor de estos mensajes autentificar su emisor.
Según otras características particulares, dicho dispositivo comunicante comprende además medios para insertar en los mensajes que emite una información que permite al receptor de estos mensajes procesarlos en su orden de emisión.
Inversamente, según también otras características particulares, dicho dispositivo comunicante comprende además medios para:
- tener en cuenta, en un mensaje de establecimiento de sesión según el protocolo de transporte TCP (Transmission Control Protocol) recibido desde otro dispositivo comunicante, llamado tercer dispositivo comunicante, una opción dedicada capaz de señalar a dicho primer dispositivo comunicante que dicho tercer dispositivo comunicante es compatible con las comunicaciones UDP con trayectorias múltiples,
- emitir un mensaje de respuesta según el protocolo de transporte TCP que contiene dicha opción dedicada, y - enviar datos al tercer dispositivo comunicante y/o recibir datos emitidos por el tercer dispositivo comunicante, utilizando una comunicación UDP con trayectorias múltiples.
Las ventajas ofrecidas por estos dispositivos comunicantes son esencialmente las mismas que las ofrecidas por los procedimientos de comunicación expuestos sucintamente anteriormente.
Cabe destacar que es posible realizar estos dispositivos comunicantes 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 de ordenador descargable desde una red de comunicación y/o almacenado en un soporte legible por ordenador y/o ejecutable por un microprocesador. Este programa de ordenador es destacable ya que comprende instrucciones para la ejecución de las etapas de uno de los procedimientos de comunicación expuestos sucintamente anteriormente, cuando se ejecuta en un ordenador.
Las ventajas ofrecidas por este programa de ordenador, son esencialmente las mismas que las ofrecidas por los procedimientos de comunicación expuestos sucintamente anteriormente.
Surgirán otros aspectos y ventajas de la invención con la lectura de la descripción detallada a continuación 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 1a, mencionada anteriormente, representa un terminal T que comunica con un servidor S a través de varias redes IP implementando un protocolo de comunicación con trayectorias múltiples,
- la figura 1b, mencionada anteriormente, representa un terminal T colocado detrás de un dispositivo-relé R que comunica con un servidor S a través de varias redes IP implementando un protocolo de comunicación con trayectorias múltiples,
- 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 con trayectorias múltiples conectado a un servidor S compatible, a su vez, con las comunicaciones con trayectorias múltiples,
- 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 datagrama UDP que contiene datos útiles, así como un identificador de contexto y datos suplementarios según la invención,
- la figura 7 representa un agregado de subsesiones TCP que forman una única conexión MPTCP,
- la figura 8 representa la opción MPTCP "FalIbackUDPCapable" según la invención,
- la figura 9 representa la opción TCP "FalIback UDP Capable" según la invención,
- la figura 10 ilustra una comunicación según la invención entre un terminal T y un servidor S,
- la figura 11 ilustra la emisión según la invención de datagramas UDP por un servidor S con destino a un terminal T, a través de un concentrador de tráfico C y una pasarela residencial CPE, y
- la figura 12 ilustra la emisión según la invención de datagramas UDP por un terminal T con destino a un servidor S, a través de una pasarela residencial CPE y un concentrador de tráfico C.
Se recuerda para empezar que una comunicación UDP simple es identificada por el conjunto de parámetros siguiente: dirección IP fuente, número de puertos fuente, dirección IP de destino, y número de puerto de destino. Una comunicación UDP con trayectorias múltiples es, de manera general, una comunicación asociada a varios conjuntos de parámetros {dirección IP fuente, número de puertos 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 trayectoria diferente (comunicación simple diferente). De este modo, una comunicación UDP con trayectorias múltiples está compuesta por varias comunicaciones UDP simples.
La figura 3 representa, a modo de ejemplo, un terminal T compatible con las comunicaciones con trayectorias múltiples, conectado, a través de una pasarela residencial CPE (acrónimo de la expresión en inglés "Customer Premises Equipment"), tres redes de acceso N1, N2 y N3 (alámbricas o inalámbricas) e Internet, a un servidor S compatible, también él, con las comunicaciones con trayectorias múltiples. El terminal T utiliza m direcciones IP distintas (denotadas IP@ti, donde i = 1,..., m), mientras que el servidor S utiliza una misma dirección IP (denotada IP@s1) pero n números de puerto distintos (denotados pj, donde j = 1,...n).
Como se mencionó anteriormente, según la presente invención, un primer dispositivo comunicante inserta, en los paquetes IP enviados según un modo de transporte UDP a un segundo dispositivo comunicante, un identificador de contexto llamado "Context_ID". El identificador de contexto debe ser único para cada comunicación MPUDP establecida entre dos dispositivos comunicantes. Un dispositivo comunicante puede reutilizar, no obstante, un identificador de contexto que se habría utilizado en el marco de una comunicación anterior, pero ya terminada, si no hay 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 con trayectorias múltiples, es preferible que el identificador de contexto se genere aleatoriamente.
Cabe destacar que un identificador de contexto puede ser elegido por el dispositivo comunicante receptor, o ser el resultado de la asociación de un identificador elegido por el dispositivo comunicante emisor con otro identificador elegido por el dispositivo comunicante receptor; estas variantes solamente son posibles si una etapa de intercambio de informaciones entre los dos dispositivos se ha establecido antes del envío efectivo de los datagramas UDP a través de trayectorias múltiples. El identificador de contexto también puede ser elegido por otra entidad, tal como un gestor de red que controla el dispositivo comunicante emisor, o el dispositivo comunicante receptor, o los dos dispositivos. Cabe destacar también que, si la comunicación es bidireccional, identificadores de contexto distintos pueden ser utilizados por cada uno de los dos dispositivos comunicantes.
La figura 4 ilustra una comunicación MPUDP entre un terminal T y un servidor S. En este ejemplo, los datagramas UDP son enviados utilizando tres comunicaciones UDP simples. Para permitir al terminal T asociar estas comunicaciones simples a una misma sesión UDP con trayectorias múltiples, el servidor S inserta el identificador de contexto ID#1 en los paquetes que envía a T.
Además del identificador de contexto, informaciones suplementarias, tales como un testigo de seguridad, pueden ser insertadas ventajosamente en los mensajes intercambiados entre los dos dispositivos comunicantes. La figura 5 ilustra una comunicación MPUDP entre un terminal T1 y un terminal T2 utilizando el identificador de contexto ID#1, y en la que un terminal T3 intenta insertar datos (por ejemplo, usurpando 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 tiene en cuenta los datos transmitidos por T3.
El identificador de contexto, así como datos suplementarios pueden ser insertados en un paquete IP, y están, según una primera variante, situados inmediatamente después de los datos UDP. Como se ilustra en la figura 6, el valor "Longitud IP" indica el tamaño global del paquete IP incluyendo el de la cabecera IP (20 octetos en IPv4, 40 octetos en Ipv6), mientras que el valor "Longitud UDP" indica el tamaño total de la cabecera UDP y de los datos útiles ("payload' en inglés). Sustrayendo 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 suplementarios. Según una segunda variante, el identificador de contexto es transportado en el campo que contiene los datos útiles ("payload") UDP.
Según una tercera variante, se definen nuevas opciones IPv4 dedicadas (en cuyo caso los datos suplementarios se pueden consignar cómodamente en el campo "Options" 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 eventuales datos suplementarios (por ejemplo, un testigo de seguridad).
Obviamente, es importante que la utilización de comunicaciones UDP con trayectorias múltiples no induzca degradación de la Calidad de servicio (por ejemplo, una pérdida de paquetes) en comparación con el modo UDP convencional.
En particular, una distorsión del nivel de calidad asociado a las trayectorias múltiples es de una naturaleza que pone en cuestión la integridad de la comunicación provocando un desfase entre el orden de emisión y el orden de llegada de los datagramas UDP. Incluso aunque ciertas aplicaciones UDP están diseñadas para minimizar dicho riesgo (que también se presenta para comunicaciones simples), un dispositivo comunicante UDP emisor pueden insertar ventajosamente en los mensajes que emite, además del identificador de contexto Context_ID, una información suplementaria que permite a un dispositivo comunicante UDP receptor procesar estos mensajes en su orden de emisión. Esta información suplementaria se denominará "Order_Rank". Este elemento de información puede estar, por ejemplo, estructurada como un número entero no nulo cuyo valor se incrementa; de este modo, un datagrama UDP cuyo valor Order_Rank es igual a "7" es una indicación de que este datagrama UDP es el séptimo de 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 generado aleatoriamente.
Un terminal compatible con las comunicaciones UDP con trayectorias múltiples debe, preferentemente, disponer de mecanismos fiables que le permitan asegurarse de que el terminal remoto es, a su vez, compatible con las comunicaciones con trayectorias múltiples. Para esto se pueden prever varios métodos, por ejemplo:
• utilizar el recurso DNS SRV (acrónimo de la expresión en inglés "Domain Name System Service Record"): este enfoque solo se aplica para aplicaciones que implican un intercambio de DNS; no se aplica a las aplicaciones (tales como las aplicaciones P2P) que intercambian informaciones de conectividad llamadas referentes ("referrals", en inglés) (una información referente puede estar estructurada, 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-carpenter-behave-referral- obiect-00#sect¡on-4); • utilizar un nuevo número de protocolo para identificar la versión UDP con trayectorias múltiples: este enfoque puede estar previsto en un entorno controlado, pero no se puede desplegar a gran escala a causa de la proliferación de NAT (acrónimo de la expresión en inglés "Network Address Translatof que significa "Traductor de dirección de red") y cortafuegos;
• definir extensiones aplicativas (FTP, por ejemplo): este enfoque solo se aplica a ciertos protocolos, y no se puede generalizar; o
• definir una nueva aplicación por encima de UDP; esta aplicación estará dedicada en parte a la verificación del soporte de MPUDP por el terminal remoto.
A continuación, se describirá un modo de realización de la invención, que combina ventajosamente los protocolos de transporte UDP y TCP.
Se recuerda que el protocolo TCP (definido en concreto en el documento RFC 793) es uno de los principales protocolos utilizados por los terminales conectados a una red IP (por ejemplo, Internet), de modo que la bibliografía menciona a menudo la serie de protocolos "TCP/IP". El protocolo TCP permite encaminar de manera fiable, ordenada y sin errores un flujo de datos digitales entre aplicaciones ejecutadas en terminales conectadas a una red local (por ejemplo, Intranet) o a Internet. El protocolo TCP funciona a nivel de la capa de transporte del modelo OSI. Los navegadores Web utilizan el protocolo TCP cuando se conectan a servidores remotos; el protocolo TCP se utiliza también para encaminar correo electrónico o para transferir archivos de un lugar a otro. Protocolos como HTTP, HTTPS, SMTP, POP3, IMAP, SSH, FTP, Telnet, así como muchos otros protocolos son transportados en conexiones TCP. Una conexión TCP se identifica por la dirección y el número de puerto del terminal fuente, así como por la dirección y el número de puerto del terminal de destino.
El presente modo de realización se basa en la utilización de opciones TCP o de opciones IPv4 para establecer comunicaciones UDP a través de trayectorias múltiples. Para esto, se puede utilizar el campo "Options" (descrito en el documento RFC 791 de la IETF) de la cabecera de un paquete Ipv4.
Convencionalmente, dos terminales pueden insertar "opciones TCP" en los mensajes TCP intercambiados entre ellos, con el fin, por ejemplo, de optimizar la calidad de la conexión TCP. Dichas opciones ocupan el espacio disponible al final de cabecera TCP, y tienen una longitud ("length" en inglés) expresada en octetos. El tipo ("kind" en inglés) de opción es un identificador único descriptivo de la naturaleza de la opción TCP. Por ejemplo, el valor "0" indica el final de la lista de opciones, y el valor "2" indica el tamaño máximo del segmento TCP ("Maximum Segment Size", o MSS en inglés).
El término "opción" se utiliza también para designar, por ejemplo, una cabecera de extensión ("Extension Headef en inglés) IPv6, una opción IPv4, el o los campos "dirección fuente/número de puertos fuente" de un paquete encapsulado, el o los campos "dirección de destino/número de puerto de destino" de un paquete encapsulado, uno o varios campos de un paquete encapsulado, uno o varios campos de un paquete que encapsula otro paquete, o una extensión de un esquema de encapsulación, así como una opción del protocolo TCP o de otro protocolo de transporte, o bien incluso una combinación de estos diferentes medios.
La llegada de los terminales MIF introduce la posibilidad de explotar los recursos de varias trayectorias a través de las redes disponibles para establecer una conexión TCP, utilizando todas o parte de las direcciones IP asignadas a las diferentes interfaces de las terminales MIF. Sin embargo, esta posibilidad introduce una complejidad característica del modo de funcionamiento del protocolo TCP: dado que las conexiones TCP están asociadas a una dirección IP y un número de puerto, cualquier modificación de al menos una de estas informaciones es de una naturaleza que penaliza el funcionamiento de la conexión TCP en curso, y, en consecuencia, el servicio que utiliza dicha conexión t Cp . Este cambio es particularmente perjudicial cuando al terminal se le atribuye una nueva dirección IP, o cuando el terminal se conecta a otra red, o incluso cuando la interfaz a la cual la dirección IP está asociada ya no está disponible. Por ejemplo, medios para informar a un interlocutor TCP remoto de que una dirección IP ya no es válida son entonces necesarios para garantizar el mantenimiento de una conexión TCP existente sin interrumpir los servicios ofrecidos por esta conexión TCP.
Al grupo de trabajo "mptcp" de la IETF se le encomendó la misión 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 ha publicado las primeras especificaciones del protocolo MPTCP (véase A. Ford, C. Raiciu y M. Handley, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, enero de 2013) — que ciertos teléfonos "inteligentes" y ciertos sistemas de exploración son, además, ya capaces de implementar. El protocolo MPTCP responde en particular a la necesidad de garantizar una continuidad de sesión IP en caso de movilidad del terminal. La IETF prevé hacer progresar el estado de las especificaciones MPTCP actuales, para hacer de ellas auténticas normas en el sentido de la IETF.
El protocolo MPTCP ha sido propuesto, por lo tanto, para minimizar los riesgos de ruptura intempestiva de una conexión TCP, vinculados por ejemplo a dichas modificaciones de direccionamiento, y más generalmente para responder a las exigencias planteadas por un contexto donde un terminal tiene la capacidad de conectarse a una o varias redes a través de una o varias interfaces. Además, está previsto en el documento RFC 6824 que, en caso de fracaso de un intento de establecimiento de una conexión MPTCp , la comunicación se transfiere automáticamente a una conexión TCP simple.
El presente modo de realización se aplica de manera general a cualquier protocolo de la serie TCP/IP que rige comunicaciones con trayectorias múltiples. Con fines puramente ilustrativos, se describirá a continuación la aplicación de la invención al protocolo MPTCP, después de varios recordatorios de ciertas propiedades de este protocolo. Según el protocolo MPTCP, se denomina "subsesión" ("sub-floW en inglés) una conexión TCP que se basa en la utilización de uno de los pares (dirección IP, número de puerto) disponibles. Debido a esto, una conexión MPTCP es un agregado de subsesiones TCP. A modo de ejemplo, la figura 7 muestra una conexión MPTCP entre un terminal A y un terminal B; la subsesión inicial se establece entre la dirección A1 del terminal A y la dirección B1 del terminal B; posteriormente, una subsesión adicional se establece entre la dirección A2 del terminal A y la dirección B1 del terminal B. Un terminal MIF puede conectarse de este modo a nuevas redes, o desconectarse de ciertas redes, todo manteniendo una misma conexión con trayectorias múltiples.
Diferentes casos de uso pueden estar previstos para el protocolo MPTCP, tales como:
• intercambiar datos entre varias redes de acceso inalámbricas,
• reducir la carga de una red móvil, transfiriendo una parte del tráfico hacia una red de acceso inalámbrica,
• optimizar la utilización de los recursos de red explotando de manera simultánea los recursos de varios enlaces de acceso y distribuyendo la carga de tráfico de una o varias conexiones MPTCP en estos diferentes enlaces, lo que permite aumentar significativamente el ancho de banda asociado al establecimiento de una conexión MPTCP, o • fiabilizar una conexión MPTCP transfiriendo el tráfico encaminado a lo largo de una trayectoria primaria hacia una trayectoria auxiliar en caso de ruptura de la trayectoria primaria, y esto, de manera transparente para el usuario (es decir sin interrupción de servicio).
Una conexión MPTCP se inicializa como cualquier conexión TCP convencional, a excepción de que una opción TCP llamada MP_CAPABLE (lo que significa que el terminal emisor es compatible con las extensiones MPTCP) está incluida en el mensaje que contiene el indicador de inicialización de subsesión (SYN) y en los mensajes posteriores. Un terminal MPTCP puede señalar al terminal remoto la disponibilidad de una dirección IP suplementaria con ayuda de una opción TCP llamada ADD_ADDR, sin crear necesariamente una subsesión asociada.
La señalización de varias direcciones IP disponibles y susceptibles de ser utilizadas para comunicar con un interlocutor puede conducir al fracaso del establecimiento de ciertas subsesiones TCP, porque las direcciones IP externas tal como son percibidas por los terminales remotos pueden no ser las mismas que las visibles localmente. Por esta razón, la opción ADD_ADDR del protocolo MPTCP comprende un identificador de dirección, llamado "Address ID", utilizado para identificar sin ambigüedad una dirección IP disponible. Se supone que esta disposición evita los problemas inducidos por la presencia de un NAT en la trayectoria seguida por los paquetes entre los dos terminales que han establecido una conexión MPTCP. La opción ADD ADDR se utiliza también para transmitir un número de puerto en el caso en el que uno de los terminales MPTCP no utiliza el mismo número de puerto para el conjunto de las direcciones IP disponibles.
Asimismo, el protocolo MPTCP prevé disposiciones que se supone que permiten, en concreto, atravesar cortafuegos ("firewall" en inglés). Más concretamente, la especificación del protocolo MPTCP estipula que los números de secuencia tal como se indican en la cabecera TCP son específicos para cada subsesión, mientras que el número de secuencia indicado en la opción DSS ("Data Sequence Signal") del protocolo MPTCP sirve para asociar estas subsesiones a la misma conexión MPTCP.
El protocolo MPTCP pretende de este modo librarse de las restricciones impuestas por la proliferación masiva de "middle boxes" (funciones intermedias en una cadena de comunicación), como los NAT y los cortafuegos desplegados en las redes actuales.
El protocolo MPTCP utiliza en concreto las siguientes opciones TCP:
• MP_CAPABLE: esta opción, mencionada anteriormente, se utiliza para señalar al terminal remoto que el terminal emisor es compatible con las opciones MPTCP;
• ADD_ADDR: esta opción, mencionada anteriormente, se utiliza para añadir una nueva dirección; comprende un campo opcional de dos octetos que permite proporcionar también un número de puerto, llegado el caso;
• REMOVE_ADDR: esta opción se utiliza para suprimir una dirección;
• MP_PRIO: esta opción se utiliza para modificar la prioridad de una conexión TCP;
• MP_JOIN: esta opción se utiliza para identificar la conexión TCP que está asociada al establecimiento de una nueva subsesió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 según varios modos:
- modo nativo: dos terminales MPTCP establecen todas las subsesiones que corresponden a los números de las direcciones/puertos disponibles, y utilizan el conjunto de estas subsesiones;
- modo primario: dos terminales MPTCP señalan subsesiones, pero solo un subconjunto de estas subsesiones se utiliza efectivamente para la transferencia de datos;
- modo secundario: en caso de indisponibilidad (o de sobrecarga) del subconjunto "primario" de subsesiones, un subconjunto "secundario" de subsesiones se solicita entonces para garantizar la continuidad de la conexión MPTCP; y
- modo de respaldo: dos terminales MPTCP utilizan una subsesión única; en caso de avería, el tráfico se transfiere a una nueva subsesión creada a tal efecto.
Para ser compatible con el presente modo de realización, un dispositivo comunicante debe integrar un dispositivo relé, que se llamará "relé UDP/TCP", encargado de transmitir hacia una conexión TCP o MPTCP los mensajes UDP emitidos por una aplicación de software asociada al dispositivo comunicante. Cabe destacar que, desde el punto de vista del rendimiento aplicativo, la utilización de una conexión MPTCP para transmitir los mensajes UDP es más eficaz que una conexión TCP simple; además, MPTCP permite intercambiar las direcciones múltiples y/o números de puertos.
A continuación, se describirán las etapas de un procedimiento de comunicación entre dos dispositivos comunicantes, de los cuales al menos uno (que se llamará "primer dispositivo comunicante") es compatible con MPUDP. Además, se supone en este caso que las diversas trayectorias utilizables para esta comunicación son compatibles con MPTCP. Durante una etapa E1, dicha aplicación de software asociada a dicho primer dispositivo comunicante emite un mensaje UDP, que es interceptado por el relé UDP/TCP integrado en este primer dispositivo comunicante.
Durante una etapa E2, este relé UDP/TCP emite destinado a un segundo dispositivo comunicante un mensaje SYN que contiene una opción dedicada, que se llamará "FalIbackUDPCapable", y que señala al segundo dispositivo comunicante que el primer dispositivo comunicante es compatible con MPUDP.
Según una primera variante, esta opción FalIback UDP Capable es una opción MPTCP, tal como la ilustrada en la figura 8. Según una segunda variante, esta opción FalIback UDP Capable es una opción TCP, tal como la ilustrada en la figura 9 — en cuyo caso la utilización de una señalización MPTCP no es obligatoria.
Durante una etapa E3, el segundo dispositivo comunicante responde por medio de un mensaje SYN/ACK. Dos casos son entonces posibles:
• si el segundo dispositivo comunicante tiene, a su vez, la capacidad de establecer una comunicación UDP a través de trayectorias múltiples, inserta la opción FalIback UDP Capable en dicho mensaje SYN/ACK; los dos dispositivos comunicantes intercambian entonces datos, durante una etapa E4, datos por medio de una comunicación MPUDP, sin solicitar de ahora en adelante el relé UDP/TCP integrado en cada uno de estos dispositivos comunicantes; opcionalmente, el relé puede incluir la opción FalIback UDP Capable en el mensaje ACK que emite hacia el segundo dispositivo en respuesta al mensaje SYN/ACK; la inclusión de la opción en el mensaje ACK permite indicar explícitamente al segundo dispositivo que el relé UDP/TCP ha recibido correctamente la opción FalIbackUDPCapable;
• si, por el contrario, el segundo dispositivo comunicante no tiene la capacidad de establecer una comunicación UDP a través de trayectorias múltiples, los dos dispositivos comunicantes intercambian entonces, durante una etapa E'4, datos según el modo de transporte UDP (simple) convencional, o según el modo TCP simple, o según el modo MPTCP, resultando el modo elegido en este caso de una configuración previa de los dispositivos comunicantes.
A continuación, dos ejemplos de implementación de este modo de realización.
Según un primer ejemplo, ilustrado en la figura 10, el primer dispositivo comunicante es un terminal T compatible con MPTCP, abonado a cierta red, y el segundo dispositivo comunicante es un servidor de contenidos S (o un segundo terminal), a su vez, compatible con MPTCP, alcanzable a través de esta red. En relación con cada uno de estos dos dispositivos comunicantes, la interfaz entre la aplicación UDP y el relé UDP/TCP no se ilustra en la figura 10, estando reproducidos solamente los intercambios externos.
Según un segundo ejemplo de implementación, ilustrado en las figuras 11 y 12, el primer dispositivo comunicante es una pasarela residencial CPE, compatible con MPTCP, detrás de la cual se encuentra un terminal T que comunica con un servidor de contenidos S (o con un segundo terminal). El segundo dispositivo comunicante es un concentrador de tráfico C compatible con MPTCP, situado en las trayectorias de comunicación entre la pasarela CPE y el servidor S. Como en el ejemplo anterior, la interfaz de cada uno de estos dispositivos comunicantes entre la aplicación UDP y el relé UDP/TCP no se ilustra en las figuras 11 y 12, estando reproducidos solamente los intercambios externos.
En el caso de la figura 11, tras el establecimiento de la comunicación como se ha descrito anteriormente, los datagramas UDP recibidos del servidor S son distribuidos por el concentrador de tráfico C entre las diferentes trayectorias disponibles y enviadas a la pasarela residencial CPE. Tras la recepción de estos datagramas UDP por la pasarela residencial CPE, esta los transmite al terminal T.
En el caso de la figura 12, tras el establecimiento de la comunicación como se ha descrito anteriormente, los datagramas UDP recibidos del terminal T son distribuidos por la pasarela residencial CPE entre dos trayectorias disponibles y enviados al concentrador de tráfico C. Tras la recepción de estos datagramas UDP por el concentrador de tráfico C, este último los transmite al servidor S.
En el caso ilustrado en la figura 12, la pasarela residencial CPE inserta la información Order_Rank descrita anteriormente (además del identificador de contexto Context_ID). Supongamos, por ejemplo, que los datagramas "1", "2" y "5" son enviados por la pasarela residencial CPE a través de la primera trayectoria, mientras que los datagramas "3", "4", "g" y "7" son enviados a través de la segunda trayectoria. Tras 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 se debe transmitir inmediatamente hacia el servidor S, o si debe esperar a la llegada de otros datagramas antes de transmitirlo. Para evitar que la función de reordenamiento no induce un retardo importante, se puede prever que el concentrador transmite los paquetes puestos en espera tras el paso de un periodo REORDER_MAX. Por ejemplo, si el orden de llegada de los paquetes a través de las dos trayectorias es {"1", "2", "5", "3", "4", "6", "7"}, el concentrador de tráfico C debe procesar en primer lugar los paquetes "1" y "2"; el paquete cuyo valor de la información Order_Rank es igual a "5" se pone en espera hasta la recepción de los paquetes "3" y "4"; una vez recibidos estos paquetes, el concentrador de tráfico C transmite el datagrama "5". Suponiendo que los paquetes "3" y "4" no son recibidos en un plazo REORDER_MAX, el paquete "5" es entonces transmitido hacia su destino sin esperar a los paquetes faltantes. Cabe destacar que, en este segundo ejemplo de implementación (ilustrado en las figuras 11 y 12), el terminal T y el servidor S se comportan como dispositivos comunicantes UDP convencionales; por consiguiente, no es necesario que sean compatibles con las comunicaciones UDP con trayectorias múltiples.
La invención se puede implementar dentro de nodos de redes de comunicación, por ejemplo, terminales, servidores, pasarelas residenciales o concentradores de tráfico, por medio de componentes de software y/o hardware. Dichos componentes de software podrán integrarse en un programa de ordenador convencional de gestión de nodo de red. Esto es por lo que, como se ha indicado anteriormente, la presente invención también se refiere a un sistema informático. Este sistema informático consta, de manera convencional, de una unidad central de procesamiento que controla mediante señales una memoria, así como una unidad de entrada y una unidad de salida. Además, este sistema informático se puede utilizar para ejecutar un programa de ordenador que consta de instrucciones para la implementación de cualquiera de los procedimientos de comunicación de la carga de un concentrador de tráfico según la invención.
En efecto, la invención también se refiere a un programa de ordenador tal como se ha descrito sucintamente anteriormente. Este programa de ordenador puede almacenarse en un soporte legible por ordenador y puede ser ejecutable por un microprocesador. Este programa puede utilizar cualquier lenguaje de programación y presentarse en forma de código fuente, código objeto o código intermedio entre código fuente y código objeto, tal como en una forma parcialmente compilada o en cualquier otra forma deseable.
La invención también se refiere a un soporte de información fijo, o parcial o totalmente extraíble, que consta de instrucciones de un programa de ordenador tal como se ha descrito sucintamente anteriormente.
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 r Om , por ejemplo un CD ROM o una ROM de circuito microelectrónico o un medio de registro magnético, tal como disco duro, o incluso una llave USB ("USB flash drive" en inglés).
Por otra parte, el soporte de información puede ser un soporte transmisible tal como una señal eléctrica u óptica, que puede encaminarse a través de un cable eléctrico u óptico, por radio o por otros medios. El programa de ordenador según la invención se puede descargar en particular en una red tal como Internet.
Como variante, el soporte de información puede ser un circuito integrado en el que está incorporado el programa, estando el circuito adaptado para ejecutar o para ser utilizado en la ejecución de uno cualquiera de los procedimientos de comunicación según la invención.

Claims (10)

REIVINDICACIONES
1. Procedimiento de comunicación en una red IP, que comprende las etapas siguientes:
a) un primer dispositivo comunicante, compatible con comunicaciones UDP con trayectorias múltiples, inicializa una comunicación con un segundo dispositivo comunicante, señalando a dicho segundo dispositivo comunicante que dicho primer dispositivo comunicante es compatible con las comunicaciones con trayectorias múltiples que se basan en el protocolo de transporte UDP, User Datagram Protocol, y
b) si el segundo dispositivo comunicante es, a su vez, compatible con las comunicaciones UDP con trayectorias múltiples:
- el primer dispositivo comunicante envía datos al segundo dispositivo según el protocolo de transporte UDP, incluyendo en los mensajes que contienen estos datos, independientemente de la trayectoria utilizada, un mismo identificador, llamado identificador de contexto, que permite al segundo dispositivo comunicante correlacionar el conjunto de los datagramas UDP asociados a una misma comunicación UDP con trayectorias múltiples, y/o - el segundo dispositivo comunicante envía datos al primer dispositivo según el protocolo de transporte UDP, incluyendo en los mensajes que contienen estos datos, independientemente de la trayectoria utilizada, un mismo identificador, llamado identificador de contexto, que permite al primer dispositivo comunicante correlacionar el conjunto de los datagramas UDP asociados a una misma comunicación UDP con trayectorias múltiples;
comprendiendo además dicho procedimiento de comunicación las siguientes etapas:
- el primer dispositivo comunicante emite (E1) un mensaje UDP, que es interceptado por un relé integrado en este primer dispositivo comunicante,
- dicho relé emite (E2) hacia el segundo dispositivo comunicante, un mensaje de establecimiento de sesión según el protocolo de transporte TCP, Transmission Control Protocol, que contiene una opción dedicada capaz de señalar a dicho segundo dispositivo comunicante que el primer dispositivo comunicante es compatible con las comunicaciones UDP con trayectorias múltiples, y
- si el segundo dispositivo comunicante es, a su vez, compatible con las comunicaciones UDP con trayectorias múltiples, emite (E3) un mensaje de respuesta según el protocolo de transporte TCP en el que inserta dicha opción dedicada, a continuación, el primer dispositivo comunicante envía datos al segundo dispositivo comunicante y/o el segundo dispositivo comunicante envía datos al primer dispositivo comunicante, utilizando (E4) una comunicación UDP con trayectorias múltiples.
2. Procedimiento de comunicación según la reivindicación 1, caracterizado por que el primer dispositivo comunicante y/o el segundo dispositivo comunicante inserta, además, en dichos mensajes que contienen los datos, un testigo de seguridad que permite al receptor de estos mensajes autentificar su emisor.
3. Procedimiento de comunicación según la reivindicación 1 o la reivindicación 2, caracterizado por que el primer dispositivo comunicante y/o el segundo dispositivo comunicante inserta, además, en dichos mensajes que contienen los datos, una información que permite al receptor de estos mensajes procesarlos en su orden de emisión.
4. Dispositivo comunicante, llamado primer dispositivo comunicante, caracterizado por que comprende medios para: - inicializar una comunicación con otro dispositivo comunicante, llamado segundo dispositivo comunicante, dentro de una red IP, señalando a dicho segundo dispositivo comunicante que dicho primer dispositivo comunicante es compatible con las comunicaciones UDP, User Datagram Protocol, con trayectorias múltiples,
- enviar datos según el protocolo UDP al segundo dispositivo comunicante, incluyendo en los mensajes que contienen estos datos, independientemente de la trayectoria utilizada, un mismo identificador, llamado identificador de contexto, que permite al segundo dispositivo comunicante correlacionar el conjunto de los datagramas UDP asociados a una misma comunicación UDP con trayectorias múltiples, y
- recibir datos según el protocolo UDP desde el segundo dispositivo comunicante, detectando en los mensajes que contienen estos datos, independientemente de la trayectoria utilizada, un mismo identificador, llamado identificador de contexto, que permite al primer dispositivo comunicante correlacionar el conjunto de los datagramas UDP asociados a una misma comunicación UDP con trayectorias múltiples;
integrando dicho primer dispositivo comunicante un relé que comprende medios para emitir con destino al segundo dispositivo comunicante, un mensaje de establecimiento de sesión según el protocolo de transporte TCP, Transmission Control Protocol, que contiene una opción dedicada capaz de señalar a dicho segundo dispositivo comunicante que el primer dispositivo comunicante es compatible con las comunicaciones UDP con trayectorias múltiples.
5. Dispositivo comunicante según la reivindicación 4, caracterizado por que comprende además medios para insertar en los mensajes que emite un testigo de seguridad que permite al receptor de estos mensajes autentificar su emisor.
6. Dispositivo comunicante según la reivindicación 4 o la reivindicación 5, caracterizado por que comprende además medios para insertar en los mensajes que emite una información que permite al receptor de estos mensajes procesarlos en su orden de emisión.
7. Dispositivo comunicante según una cualquiera de las reivindicaciones 4 a 6, caracterizado por que comprende además medios para:
- tener en cuenta, en un mensaje de establecimiento de sesión según el protocolo de transporte TCP recibido desde otro dispositivo comunicante, llamado tercer dispositivo comunicante, una opción dedicada capaz de señalar a dicho primer dispositivo comunicante que dicho tercer dispositivo comunicante es compatible con las comunicaciones UDP con trayectorias múltiples,
- emitir un mensaje de respuesta según el protocolo de transporte TCP que contiene dicha opción dedicada, y - enviar datos al tercer dispositivo comunicante y/o recibir datos emitidos por el tercer dispositivo comunicante, utilizando una comunicación UDP con trayectorias múltiples.
8. Dispositivo comunicante según una cualquiera de las reivindicaciones 4 a 7, caracterizado por que comprende un dispositivo-cliente (T), un servidor de contenidos (S), o un concentrador de tráfico (C).
9. Medio de almacenamiento de datos fijo, o parcialmente o totalmente extraíble, que consta de instrucciones de código de programa informático para la ejecución de las etapas de un procedimiento de comunicación según una cualquiera de las reivindicaciones 1 a 3.
10. Programa de ordenador descargable desde una red de comunicación y/o almacenado en un soporte legible por ordenador y/o ejecutable por un microprocesador, caracterizado por que comprende instrucciones para la ejecución de las etapas de un procedimiento de comunicación según una cualquiera de las reivindicaciones 1 a 3, cuando se ejecuta en un ordenador.
ES17737324T 2016-06-24 2017-06-16 Procedimiento de comunicación UDP a través de trayectorias múltiples entre dos terminales Active ES2832813T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1655907A FR3053196A1 (fr) 2016-06-24 2016-06-24 Procede de communication udp via des chemins multiples entre deux terminaux
PCT/FR2017/051570 WO2017220893A1 (fr) 2016-06-24 2017-06-16 Procédé de communication udp via des chemins multiples entre deux terminaux

Publications (1)

Publication Number Publication Date
ES2832813T3 true ES2832813T3 (es) 2021-06-11

Family

ID=56787606

Family Applications (2)

Application Number Title Priority Date Filing Date
ES17737324T Active ES2832813T3 (es) 2016-06-24 2017-06-16 Procedimiento de comunicación UDP a través de trayectorias múltiples entre dos terminales
ES20185234T Active ES2929278T3 (es) 2016-06-24 2017-06-16 Procedimiento de comunicación UDP a través de trayectorias múltiples entre dos terminales

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES20185234T Active ES2929278T3 (es) 2016-06-24 2017-06-16 Procedimiento de comunicación UDP a través de trayectorias múltiples entre dos terminales

Country Status (6)

Country Link
US (1) US10841406B2 (es)
EP (2) EP3739843B1 (es)
CN (1) CN109644190B (es)
ES (2) ES2832813T3 (es)
FR (1) FR3053196A1 (es)
WO (1) WO2017220893A1 (es)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9607336B1 (en) * 2011-06-16 2017-03-28 Consumerinfo.Com, Inc. Providing credit inquiry alerts
FR3053197A1 (fr) 2016-06-24 2017-12-29 Orange Procede de communication udp via des chemins multiples entre deux terminaux
FR3067550A1 (fr) * 2017-06-27 2018-12-14 Orange Procede de communication quic via des chemins multiples
FR3072529B1 (fr) * 2017-10-17 2019-10-18 Sagemcom Broadband Sas Routage de donnees dans une passerelle residentielle mettant en œuvre l'agregation de liens
FR3079987A1 (fr) * 2018-04-06 2019-10-11 Orange Procede de traitement d'une transaction entre un terminal source et un terminal destinataire, systeme de services bancaires, terminal et programme d'ordinateur correspondants.
US11064384B2 (en) * 2019-02-19 2021-07-13 Mediatek Inc. Apparatuses and methods for multipath communications using a plurality of wireless technologies
US11323552B2 (en) * 2019-04-19 2022-05-03 EMC IP Holding Company LLC Automatic security configurations in disaster recovery
CN113014483B (zh) * 2019-12-19 2023-04-18 华为技术有限公司 一种多路径传输的方法及设备
CN112398943B (zh) * 2020-11-13 2022-10-21 Oppo广东移动通信有限公司 信息互通方法、装置、存储介质及电子设备
JPWO2022157846A1 (es) * 2021-01-20 2022-07-28
CN112954063A (zh) * 2021-02-25 2021-06-11 福州创实讯联信息技术有限公司 一种tftp内网穿透方法及tftp服务端
CN115915108A (zh) * 2021-08-05 2023-04-04 维沃移动通信有限公司 多路径通信方法、装置及终端
CN117135754A (zh) * 2022-05-27 2023-11-28 华为技术有限公司 一种信息传输方法和装置

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5737328A (en) 1995-10-04 1998-04-07 Aironet Wireless Communications, Inc. Network communication system with information rerouting capabilities
FI108692B (fi) 1999-12-30 2002-02-28 Nokia Corp Menetelmä ja laite datapakettien prosessoinnin ajoittamiseksi
US20050264581A1 (en) 2004-05-21 2005-12-01 Bea Systems, Inc. Dynamic program modification
US20060274899A1 (en) * 2005-06-03 2006-12-07 Innomedia Pte Ltd. System and method for secure messaging with network address translation firewall traversal
US7978725B2 (en) 2006-03-06 2011-07-12 Cisco Technology, Inc. Dynamic modification of contention-based transmission control parameters achieving load balancing scheme in wireless mesh networks
JP2011147002A (ja) * 2010-01-15 2011-07-28 Kyocera Corp 通信装置および通信方法
CN101895466B (zh) * 2010-07-02 2013-03-20 北京交通大学 一种降低sctp多路径传输数据包乱序影响的方法
US8630291B2 (en) 2011-08-22 2014-01-14 Cisco Technology, Inc. Dynamic multi-path forwarding for shared-media communication networks
US20130064198A1 (en) * 2011-09-14 2013-03-14 Qualcomm Incorporated Multipath transport tunnel over multiple air interfaces connecting wireless stations
US9264353B2 (en) * 2011-09-22 2016-02-16 Qualcomm Incorporated Dynamic subflow control for a multipath transport connection in a wireless communication network
US9998569B2 (en) * 2012-12-14 2018-06-12 Telefonaktiebolaget Lm Ericsson (Publ) Handling multipath transmission control protocol signaling in a communications network
EP2972864B1 (en) * 2013-03-15 2019-12-11 Michelle Effros Method and apparatus for improving communication performance through network coding
US9843522B2 (en) * 2014-04-09 2017-12-12 Hcl Technologies Ltd. Efficient mechanism to improve data speed between systems by MPTCP and MIMO combination
CN104023006B (zh) * 2014-05-09 2017-02-15 东北大学 一种基于应用层中继的多径传输系统及方法
WO2016049609A1 (en) * 2014-09-25 2016-03-31 Hughes Network Systems, Llc Application-aware multihoming for data traffic acceleration in data communications networks
US10038741B1 (en) 2014-11-24 2018-07-31 Amazon Technologies, Inc. Selective enabling of sequencing for encapsulated network traffic
CN104618236A (zh) * 2015-01-21 2015-05-13 网宿科技股份有限公司 一种加速网络的并行数据传输系统及方法
US10069719B2 (en) 2015-06-16 2018-09-04 Samsung Electronics Co., Ltd. Method and apparatus for multipath media delivery
EP3459217B1 (en) * 2016-05-16 2020-07-08 Telefonaktiebolaget LM Ericsson (PUBL) Transporting udp packets over an mptcp connection
FR3053197A1 (fr) 2016-06-24 2017-12-29 Orange Procede de communication udp via des chemins multiples entre deux terminaux

Also Published As

Publication number Publication date
EP3739843B1 (fr) 2022-07-27
FR3053196A1 (fr) 2017-12-29
EP3476096B1 (fr) 2020-08-26
US20190273809A1 (en) 2019-09-05
WO2017220893A1 (fr) 2017-12-28
CN109644190B (zh) 2022-01-11
EP3476096A1 (fr) 2019-05-01
CN109644190A (zh) 2019-04-16
ES2929278T3 (es) 2022-11-28
US10841406B2 (en) 2020-11-17
EP3739843A1 (fr) 2020-11-18

Similar Documents

Publication Publication Date Title
ES2832813T3 (es) Procedimiento de comunicación UDP a través de trayectorias múltiples entre dos terminales
US11088942B2 (en) Method of QUIC communication via multiple paths
CN109644186B (zh) 用于在两个终端之间经由多路径进行udp通信的方法
US10021034B2 (en) Application aware multihoming for data traffic acceleration in data communications networks
US10630813B2 (en) Transporting UDP packets over an MPTCP connection
US10333831B2 (en) Method of optimizing the load of a network connection concentrator
CN107534605B (zh) 用于选择网络连接集中器的方法
US10356013B2 (en) Method of emulating a multipath connection
CN111262772B (zh) 用于安置在网络环境中的节点的方法及节点
US11824685B2 (en) Method for implementing GRE tunnel, access point and gateway
EP4000231A1 (en) Method and system for in-band signaling in a quic session
WO2021009554A1 (en) Method and system for secured information exchange between intermediate and endpoint nodes in a communications network
US10868796B2 (en) Method of communication by multiple paths between two terminals
US11863655B2 (en) Method and system for reliable application layer data transmission through unreliable transport layer connections in a network
ES2940469T3 (es) Método de comunicación TCP a través de múltiples rutas entre dos terminales
WO2020048622A1 (en) A method, apparatus & computer program
WO2017138851A1 (en) Methods and devices for providing a secure end-to-end communication
Zhu et al. INTAREA S. Kanugovi Internet-Draft S. Vasudevan Intended status: Standards Track Nokia Expires: July 24, 2017 F. Baboescu Broadcom
Zhu et al. INTAREA S. Kanugovi Internet-Draft S. Vasudevan Intended status: Standards Track Nokia Expires: September 28, 2017 F. Baboescu Broadcom
Zhu et al. INTAREA S. Kanugovi Internet-Draft S. Vasudevan Intended status: Standards Track Nokia Expires: September 11, 2017 F. Baboescu Broadcom
Zhu et al. INTAREA S. Kanugovi Internet-Draft S. Vasudevan Intended status: Standards Track Nokia Expires: March 31, 2018 F. Baboescu Broadcom
Zhu INTAREA S. Kanugovi Internet-Draft S. Vasudevan Intended status: Standards Track Nokia Expires: April 24, 2017 F. Baboescu Broadcom