EP3646557A1 - Procédé de communication quic via des chemins multiples - Google Patents

Procédé de communication quic via des chemins multiples

Info

Publication number
EP3646557A1
EP3646557A1 EP18749456.2A EP18749456A EP3646557A1 EP 3646557 A1 EP3646557 A1 EP 3646557A1 EP 18749456 A EP18749456 A EP 18749456A EP 3646557 A1 EP3646557 A1 EP 3646557A1
Authority
EP
European Patent Office
Prior art keywords
gateway
paths
communicating device
connection identifier
quic
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.)
Pending
Application number
EP18749456.2A
Other languages
German (de)
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
Publication of EP3646557A1 publication Critical patent/EP3646557A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H04L12/2869—Operational details of access network equipments
    • H04L12/2898—Subscriber equipments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • 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]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64707—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless for transferring content from a first network to a second network, e.g. between IP and wireless
    • 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/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures

Definitions

  • the present invention relates to the field of telecommunications, including communication networks capable of implementing the IP (Internet Protocol). More particularly, the present invention relates to the provision of services in "value added" IP networks, that is to say networks capable of performing differentiated processing according to the nature of the traffic carried in the network.
  • the invention applies to any type of client device ("User Equipment” in English), such as a fixed or mobile terminal, or a "connected TV", or a set-top box, or STB in English), or a media server, said client device being located behind a residential gateway (that is to say a home gateway or located in a company).
  • client device User Equipment
  • the invention applies when a first residential gateway is located behind a second residential gateway; in this case, the first residential gateway will be considered a client device.
  • a client device of any type will often be referred to as the "terminal" below.
  • Terminals such as smartphones (“smartphones”) and personal computers ("personal computers” or PCs in English) are now able to activate and operate multiple logical interfaces related to one or more physical interfaces .
  • Such terminals are called “multi-interfaces” (“multi-interface” or MIF in English).
  • MIF multi-interface
  • IP addresses can then be assigned to a MIF terminal. These addresses are used when it connects to different types of networks such as a fixed network, a mobile network or a WLAN (initials of the words "Wireless Local Area Network” meaning “Local Wireless Network”, whose Wi-Fi networks are an iconic example), simultaneously or delayed. These IP addresses can: • belong to the same family of addresses or to different families of addresses (IPv4, IPv6 or both),
  • MIF "MIF" characteristic is volatile because the ability to use multiple interfaces depends on the conditions of connection to the network (s), the location of the device, or other factors.
  • a device may become MIF in the process of establishing a simple call (i.e., a call established along a single path with a given caller), or even after establishing a call simple.
  • a device does not know a priori if it is possible for him to use several different paths to establish a communication with a given correspondent; more specifically, the device acquires this information (if any) only after a phase in which it attempts to establish a communication using multiple paths with the correspondent.
  • a “multipath communication” is a communication established between two devices simultaneously using one or more paths between these two devices.
  • the establishment and maintenance of such communication is based on the use of a dedicated protocol, such as MPTCP (Multi-Path TCP), which may possibly be defined as an extension of a previously defined transport protocol. , such as TCP (initials of the words “Transmission Control Protocol” meaning “Transmission Control Protocol”).
  • MPTCP Multi-Path TCP
  • TCP transmission Control Protocol
  • a multipath communication is an aggregate of one or more simple communications taking the same path or different paths (partially or completely disjoint).
  • link aggregation refers to the grouping of several links associated with as many (logical) interfaces as if it were a single link associated with a single interface, in particular with the aim of increasing the throughput beyond the limits of a single link, but also to apply the same operating procedures to all the links thus aggregated (notion of "fate sharing" in English).
  • service offerings relating to a terminal having a hybrid access are based on the introduction into the network of functions making it possible to aggregate all the network communications of a terminal (for example: WLAN and 3G, or ADSL , WLAN and 4G).
  • Link aggregation also allows other interfaces to take over if a network link goes down (redundancy principle). Link aggregation applies to any type of traffic carried along these links, including IP traffic.
  • Link aggregation can also be used to split traffic across multiple links.
  • the distribution of traffic between links that are aggregated depends on various parameters; the distribution of traffic may thus depend on the traffic engineering policy (for example, privileging the routing of a particular traffic on a link whose characteristics in terms of robustness or availability are compatible with the nature of said traffic), or the Quality of Service (QoS) policy, which can for example privilege certain links in a context of traffic prioritization.
  • the traffic engineering policy for example, privileging the routing of a particular traffic on a link whose characteristics in terms of robustness or availability are compatible with the nature of said traffic
  • QoS Quality of Service
  • link aggregation makes no assumptions about the configuration of the remote machine.
  • a source machine can request a link aggregation function without the remote machine using such a function.
  • Backup mode this mode consists in using secondary paths in the event of unavailability of the primary paths, and this, in order to improve the network availability and, consequently, the robustness and the reliability of the communications IP established on the different links;
  • associative mode (“bonding" in English): this mode is to use the resources associated with all or part of the available paths, the IP flows associated with the same application can be divided between several paths; the choice to use all the paths, or only a part of them, can for example be conditioned by the nature of the traffic or the availability or reliability characteristics associated with each path, which can vary greatly from one path to another; all the paths selected for this associative mode are considered to be primary paths; and
  • this mode is similar to the associative mode, except that the flows of a given application are not distributed among several paths, but are sent on a single path.
  • the transport protocols mainly used by software applications to communicate on the Internet are TCP (mentioned above) and UDP (initials of the words "User Datagram Protocol” meaning “User Datagram Protocol”).
  • the transport functions are defined as the list of services offered by a protocol used to multiplex connections at the transport layer. This list contains, for example, the orderly data transmission, reliable transmission, congestion control, or integrity check.
  • a working group, called "Transport Services" (TAPS) was created by the Internet Engineering Task Force (IETF) to help developers define the interfaces to invoke the different services offered by transport protocols specified by IETF.
  • TCP Stream Control Transmission Protocol
  • SCTP Stream Control Transmission Protocol
  • DCCP Datagram Congestion Control Protocol
  • UDP-lite is a simplified version of UDP that has been proposed for applications that do not require all the features offered by UDP (for example, integrity checking).
  • DTLS Datagram Transport Layer Security
  • TLS protocols have been defined to meet the application-level encryption requirements at the transport layer.
  • TCP extensions are intended to satisfy new application constraints (for example, increase resilience in the event of an IP address change), but also to coping with new IP network conditions (for example, increasing the throughput of TCP connections), and new user requirements (for example, improving security or reducing the time it takes to establish the session).
  • the QUIC protocol Quick UDP Internet Connection
  • QUIC Quick UDP Internet Connection
  • IETF draft-tsvwg-quic-protocol-02, January 2016 is an IETF-based protocol in process of being UDP-based, and which aims to reduce the latency generally observed during the recovery of HTTP connections.
  • the QUIC protocol was originally proposed by Google, which integrated it into its "Chrome" web browser.
  • a QUIC connection makes it possible to multiplex different channels, called "streams", in the same connection.
  • the QUIC protocol makes it possible to relieve the operating system of the constraints imposed by the transport layer, such as the cyclic redundancy check intended to verify the integrity of the communication.
  • QUIC In the QUIC protocol, most packet headers are encrypted to improve the security and robustness of the communication. Unlike TLS (the initials for Transport Layer Security), QUIC not only encrypts the valuable data exchanged, but also the control information. connection. QUIC information sent in the clear is limited to the bare minimum (for example, the version number or a login ID).
  • UDP makes it possible to accommodate the presence of intermediate devices ("middleboxes" in English), such as firewalls or NAT, on the path taken by a communication QUIC.
  • the QUIC protocol aims to limit the handshake procedure to zero RTT (Round Trip Time), which means that the useful data can be sent immediately, that is to say as soon as the first one is sent.
  • packet of a QUIC connection without the QUIC client having to wait for its correspondent's response.
  • a specific "stream” is dedicated to the encryption of handshake exchanges and the negotiation of QUIC options.
  • QUIC signaling integrates information to control congestion and recover lost packets in a mode of operation comparable to that of TCP.
  • a QUIC client has the ability to send frames called "WINDOW UPDATE” which allow to adjust the limit of "offset" for a given "stream", which allows to improve the packet transmission efficiency, like the TCP window characteristic window size control function ("the offset” is a parameter that allows a QUIC receiver to calibrate the size of the receive window).
  • the receiver sends WINDOW UPDATE frames that increase the value of the offset to allow the sender to send more data on that data.
  • QUIC includes a connection control mode that makes it possible to manage the size of buffers allocated by a QUIC client to all of the characteristic "streams" of a connection.
  • the protocol does not rely on transport addresses (source IP address, source port number, destination IP address, destination port number ), but on an identifier called CID (Connection IDentifier, or login ID). This identifier is generated randomly by a QUIC client.
  • CID Connection IDentifier, or login ID
  • QUIC does not distinguish the migration of a connection to a new path, or the simultaneous use of a set of known paths
  • a terminal using QUIC does not have the ability to dynamically discover multiple paths when this terminal is located in a residential or enterprise local area network (LAN);
  • a terminal using QUIC which would have discovered by any means the availability of several paths does not have the possibility of forcing the packets sent by this terminal to follow one of these paths which would be chosen by the terminal;
  • traffic distribution policies via multiple paths as activated by a QUIC terminal may not be optimal for the operator; for example, the typical distribution policy in a hybrid access environment (that is, an environment that allows a device to exploit the resources of multiple wired and wireless access networks) is to not use radio resources only if the primary link (fixed access, usually) is saturated; a terminal using QUIC is not aware of these policies; moreover, in the context of hybrid access, the delegation of management of the terminal traffic distribution policy may lead to saturation of some radio cells while the fixed network can be used for the flow of traffic;
  • a terminal attached to an access network is unable to use the resources associated with that network if only IPv6 prefixes are allocated to establish communications on that network while the remote server with which a QUIC call is established is not accessible only with the use of IPv4 addresses; in fact, the IPv4 and IPv6 protocols are incompatible by design, and it is therefore impossible to establish a QUIC communication between a terminal that only has an IPv6 address and a server that is accessible only to an IPv4 address. .
  • said gateway associates a respective connection identifier C_ID # i with each of said paths Pi, and
  • the gateway when the gateway receives from the communicating device a data packet, the gateway transmits this data packet on one of the paths Pi taking into account the connection identifier C_ID # i associated with this path Pi.
  • a QUIC communication will benefit from the resources associated with multiple paths, even if these multiple paths are not visible from the endpoints of the communication.
  • establishing a multi-path QUIC communication will have improved robustness and performance, which will improve the use of resources in the network, but also improve the quality of experience. as perceived by the client (thanks in particular to the ability to aggregate the bandwidth likely to be used by the QUIC communication, or the ability to switch the traffic to another path in case of failure for example).
  • network operators will be able to better control certain functions (notably the management of multipath communications for a deterministic traffic distribution) which will enable them to optimize the use of network resources at their disposal, and therefore to offer QUIC connectivity with added value.
  • said method first comprises the following steps:
  • said communicating device discovers said plurality of paths Pi
  • the communicating device sends to said gateway one or more messages specifying a respective connection identifier C_ID # i for each of said respective paths Pi.
  • the gateway when the gateway receives from the communicating device a data packet comprising a connection identifier C_ID # i, the gateway transmits this data packet on the path Pi associated with this connection identifier C_ID # i.
  • a QUIC client can force the selection of a specific path to route certain packets, if necessary despite the decision to select paths executed by a node further down the network and able to establish a path.
  • QUIC communication on multiple paths; a QUIC client can thus influence the traffic distribution policy between several paths, even if the traffic distribution decision is executed by a node located further down the network.
  • said gateway sends to said communicating device a message containing the list of known paths Pi of the gateway.
  • a QUIC client can dynamically discover the existence of multiple paths (not visible locally).
  • connection identifier QUIC allows the traceability of the QUIC connections during the attachment of the client QUIC to new networks. This is why, according to other particular characteristics, when said gateway receives from said communicating device a data packet comprising a connection identifier C_ID # 0, the gateway transmits this data packet on one of said paths Pi, replacing said connection identifier C_ID # 0 by said connection identifier C_ID # i associated with this path Pi if the connection identifiers C_ID # 0 and C_ID # i are different from each other.
  • said gateway when said data packet received from said communicating device is sent in response to a message sent by its correspondent, said gateway transmits this data packet to the correspondent on the path on which said message reached the gateway.
  • the gateway knows in this case on which way it must transmit said packet of data received from the communicating device.
  • said communicating device and / or said gateway send to the correspondent of the communicating device a message comprising the list of known paths of the communicating device and / or the gateway.
  • said correspondent is informed of the paths that he can use to send data to the communicating device. This is particularly useful for communicating to the correspondent of the addresses to be used to send data to the communicating device without the latter having used one of these addresses beforehand to communicate with this correspondent.
  • said gateway implements a traffic distribution policy comprising traffic distribution rules between the different available networks.
  • the quality of customer experience is improved without the QUIC customers adopting an aggressive behavior compared to the (x) network (s) of access, that is to say a behavior that would result in phagocyting all the resources of the access network for the sole benefit of the QUIC communications and to the detriment of other applications likely to use these same resources.
  • said gateway sends the communicating device a message describing the traffic distribution policy to be observed.
  • a QUIC client can dynamically discover the traffic distribution policies executed by a node located further in the network, observe these policies, and optionally inform its correspondent.
  • the invention relates to various devices.
  • the communicating devices involved in a communication may be any devices compatible with the IP protocol.
  • a communicating device may be of any type, for example a client-device (terminal) or a content server. It can have one or more IP addresses assigned to each of its physical or logical interfaces. It may also have only one interface, in which case the home gateway, to which the client device is connected, is a relay device connected to one or more networks and compatible with the protocol QUIC.
  • said communicating device further comprises means for receiving from said gateway, and taking into account, a message containing the list of known paths Pi of the gateway.
  • said residential gateway further comprises means for:
  • said residential gateway further comprises means for:
  • connection identifier C_ID # 0 by said connection identifier C_ID # i associated with this path Pi if these connection identifiers C ID # 0 and C ID # i are different from each other.
  • the invention also relates to a computer program downloadable from a communications network and / or stored on a computer readable medium and / or executable by a microprocessor.
  • This computer program is notable in that it includes instructions for performing the steps of one of the communication methods succinctly set forth above, when executed on a computer.
  • FIG. 1 schematically represents a conventional QUIC connection comprising several "streams" (channels),
  • FIG. 2 represents a gateway connected to a plurality of paths and able to associate a respective connection identifier with each of said paths
  • FIG. 3 schematically represents a procedure for discovering multiple paths according to a first embodiment of the invention
  • FIG. 4 shows the sending by a terminal of three packets within the same connection QUIC according to an example of said first embodiment
  • FIG. 5 represents a communication QUIC between a client C and a server S according to a second embodiment of the invention
  • FIG. 6 represents an exemplary format for an UPDATE CID frame for updating the connection identifier QUIC
  • FIG. 7 represents, according to a variant of said update procedure, the replacement of the identifier of a QUIC connection between a client C and a server S,
  • FIG. 8 represents an exemplary format for an MP POLICY frame used to notify a traffic distribution policy to a correspondent
  • FIG. 9 represents a QUIC communication between a client T1 and a server S, according to a first variant of use of the MP POLICY frame,
  • FIG. 10 shows a QUIC communication between a client T1 and a server S, according to a second variant of use of the MP POLICY frame
  • FIG. 11 represents a network-assisted multiple-path QUIC communication.
  • a residential gateway denoted CPE (initials of the English words "Customer Premises Equipment") connected to one or more networks N1, N2, N3, and so on, by one or more paths P1, P2, is considered. P3, and so on.
  • the CPE associates a connection identifier C_ID # 1 with a path connecting it to the network N1, a connection identifier C_ID # 2 to a path connecting it to the network N2, a connection identifier C_ID # 3 to a path connecting it to the N3 network, and so on.
  • these connection identifiers are not necessarily all different from each other; in some cases, the same connection identifier may be used for all packets sent or sent by the CPE on each of the paths as part of the same communication QUIC.
  • the CPE can, for example, serve as an intermediate in a QUIC communication between a server S and a terminal T1 (single-interface, or multi-interface) located behind the CPE.
  • a T1 terminal located behind a CPE and able to implement a multipath discovery procedure is considered. This discovery procedure is shown schematically in FIG.
  • the terminal T1 can send messages, called DISCOVER_PATH (); such a message can be sent on all or only certain active network interfaces of the terminal.
  • a given path Pi can be identified by:
  • a physical address for example a MAC (Medium Access Control) address
  • the ADVERT PATHS (Pi) message can be sent by a CPE following a request from a terminal behind the CPE, or spontaneously, ie without the CPE having been explicitly requested by a terminal.
  • the CPE can send an ADVERT PATHS (Pi) message:
  • the terminal T1 sends one or more MAP messages (C_ID # i, Pi).
  • the MAP () message also optionally makes it possible to announce the characteristics of the traffic (in particular, the IP addresses and the source and destination port numbers), in order to be able to identify a QUIC connection capable of routing said traffic.
  • the MAP () message can be sent before or after the establishment of a QUIC connection with a correspondent of the terminal T1.
  • the CPE Following receipt of one or more MAP messages (C_ID # i, Pi), the CPE installs the associations as indicated by the terminal T1. If an association is already present for this terminal and for the same connection identifier, the CPE replaces it with a new instruction received from the terminal T1.
  • the CPE uses a stable identifier, such as a MAC address, to identify the associations of the same terminal. Associations can have a limited life.
  • the CPE can complete the characteristic information of an association by information received from the correspondent of the terminal T1.
  • the CPE may indicate to the terminal T1 another connection identifier to be used in the event, for example, of a conflict between a C_ID # i identifier and an identifier already chosen by another terminal.
  • Other login credentials policies can be executed by the CPE.
  • the allocation of the connection identifier by the CPE is intended to facilitate the identification of QUIC connections. Indeed, the CPE anticipates receipt of QUIC packets by installing traffic templates according to the previously known connection identifier. It should be noted in this regard that this possibility for an entity other than a client or a server to allocate a connection identifier is not known in the state of the art.
  • the CPE sends the terminal T1 an acknowledgment message MAP_ACK () which provides an inventory of the installed associations.
  • the CPE can also return the other known associations for this terminal.
  • the CPE In order to allow the CPE to distribute the traffic via the multiple paths according to a known policy of the terminal T1, the latter must naturally use the appropriate identifier in accordance with the associations previously programmed on the CPE.
  • the CPE may divide the traffic received from a terminal between several available paths without said terminal having communicated to the CPE traffic distribution instructions, or even that the terminal is informed of the existence of multiple paths.
  • the CPE executes a traffic distribution algorithm according to preconfigured policies.
  • FIG. 4 illustrates, by way of example, the sending by a terminal T1 of three packets within the same connection QUIC; each of these packets is identified by a dedicated connection identifier C_ID # i.
  • the CPE consults its association table to determine the path to use to send the packet to its destination.
  • a packet whose connection identifier is C_ID # 1 is transmitted via the network N1
  • a packet whose connection identifier is C_ID # 2 is transmitted via the network N2
  • a packet whose identifier of connection is C_ID # 3 is transmitted via the N3 network.
  • the transmitted packets are associated with the same connection identifier (noted C_ID # a in Figure 4); this identifier can be generated by the CPE, but also, alternatively, by the terminal T1 or by its correspondent.
  • connection identifiers QUIC may be created by one or the other of the participants in a communication QUIC.
  • a client C located behind a CPE.
  • This client C sends data packets including a connection identifier QUIC noted C_ID # 0 generated by the client C.
  • connection identifiers C_ID # i alias
  • the CPE sets up associations between connection identifiers C_ID # i (alias) and the respective paths Pi, for example by configuring an association table in a database.
  • an alias may be generated by the CPE, but also, alternatively, by the client C or by the server S. For example, if said first packet is received by the CPE from the server S on a path Pi , and that this packet includes a connection identifier C_ID # i, the CPE preferably associates this alias C_ID # i to this path Pi.
  • any two alias C_ID # i and C_ID # j, with i different from j, may have identical or different values between them.
  • the CPE then transmits said first packet to its recipient (server S or client C).
  • the CPE transmits this packet to the server S on one of the paths Pi, after consultation of its association table and modification in this packet (if any) of the value of the connection identifier QUIC, ie replacement of C_ID # 0 by the alias C_ID # i associated with the path Pi (if C_ID # i is different from C_ID # 0).
  • the CPE can notably implement this procedure of rewriting the original QUIC connection identifier C_ID # 0 in order to contribute to the preservation of the confidentiality of the data exchanged between the client C and the server S.
  • the CPE can decide to update the connection identifier if it connects to a new network, or if the data is distributed via multiple paths known to the CPE and / or the server S. These aliases are then preferably known than the CPE and the server S.
  • CJD QUIC connection identifier
  • the migration of CJD may be initiated by the CPE, the client or the server;
  • CJD migration can occur at any time during a QUIC connection; thus, CJD migration can take place just before a connection is migrated to a new path (or network attachment), or just after a connection is migrated to a new path (or new network attachment) ); and
  • the client or the server sends a frame of type "CIDJJPDATE".
  • An example format for this CIDJJPDATE frame is shown in FIG. 6.
  • This frame is sent in a QUIC message whose identifier is that of the QUIC connection already established between the participants.
  • This frame can be sent together with other data, or sent in a dedicated QUIC message.
  • the message QUIC which contains a frame CIDJJPDATE by a correspondent, it performs the standard QUIC validations to ensure that the message comes from a legitimate terminal. Once the message has been validated, the correspondent extracts the information contained in the frame CIDJJPDATE.
  • traffic distribution can be configured on the CPE, in order to allow it to distribute the traffic between the different available networks; these policies can be configured by a service provider or a user; an example of a policy is to use the radio resources only in the event of unavailability of a fixed access network or when the available resources (maximum) of the main access network (typically the wired network) no longer allow to dispose of the characteristic traffic of a given application; traffic distribution policies are critical, as improper use of available resources can lead to rapid consumption of the available quota on a given access link, or even a significant increase in the amount of the bill to be paid by the user; Controlling a traffic distribution policy is also critical for an operator because it helps to minimize the risk of congestion of certain links (for example, the excessive use of a cellular connection by a multi-interface CPE may congest a cell to the detriment of single-interface mobile terminals).
  • the CPE can adjust its traffic distribution
  • the CPE can communicate to the terminal / client the traffic distribution policy to be observed, by means of the MAP primitive (C_ID # i, Pi, POLICY).
  • the POLICY object can include, for example:
  • a traffic distribution ratio for example, 10% for P1, 80% for P2, 10% for P3
  • the terminal / customer must comply with the traffic distribution policy as indicated by the CPE. Since the traffic distribution policy does not only concern outgoing traffic but also incoming traffic, a new frame, called MP POLICY, is used to notify a correspondent of the terminal / client.
  • MP POLICY a new frame
  • a terminal / client capable of exchanging data via multiple paths may include an MP POLICY frame in a QUIC message sent to its correspondent.
  • This frame makes it possible to announce to the correspondent the list of known paths of the terminal / client (in particular, the addresses to be used to send data to the terminal / client without the latter having used one of these addresses beforehand to communicate with this terminal. corresponding), as well as, optionally, the policy of distribution of incoming traffic (from the correspondent to the terminal / customer).
  • FIG. 8 A possible format for this MP POLICY frame is shown in FIG. 8. In this figure:
  • the "Sub-type” field can indicate for example the following values: o "0": list the multiple paths known to the issuer; the field “Data” must then include a list of known paths of the transmitter of the frame; for example, the "Data” field may include a list of IP addresses (or ports) to be used to send packets to the same terminal under the same multipath connection; o "1”: traffic distribution policy between the different multiple paths; the available paths can be used simultaneously; o "2”: a maximum volume of data is to be sent by path; the "Data” field specifies the volume and the path concerned;
  • o "3" indicates a usage ratio per path; the "Data” field specifies this policy, for example 10% for P1, 80% for P2, and 10% for P3; o "4": Indicates that the best RTT algorithm should be used.
  • the MP POLICY frame can be sent by one of the participants, or by all participants in a QUIC connection. It can be sent at any time from a QUIC connection. It can be sent together with other control data or useful data. One or more frames MP POLICY can be included in the same QUIC message. An MP POLICY frame can be used to signal that a path is no longer available.
  • a QUIC correspondent who receives an MP POLICY frame saves a copy of the contents of the frame in his QUIC connection table.
  • this table contains login identifiers (C_ID). If the frame mentions other IP addresses (or ports), the correspondent can use this information to communicate via multiple paths, that is to say to send packets having as destination address (destination port) one addresses indicated in the MP POLICY frame.
  • the traffic distribution policies indicated in the MP POLICY frame inform the correspondent of the approach to follow to send the data of the same connection QUIC to the various available paths.
  • FIG. 9 represents a QUIC communication between a terminal T1 and a server S, according to a first variant in which the terminal T1 announces to the server S the list of available paths using an MP POLICY frame.
  • the frame is sent via the path that passes through the N1 network.
  • the server can send the data of this same connection via the other paths to the terminal T1 (N2 or N3) without the terminal T1 having used these paths to communicate with S.
  • FIG. 10 represents a QUIC communication between a terminal T1 and a server S, according to a second variant in which an MP POLICY frame is inserted by the CPE.
  • the content of the MP POLICY frame can be controlled and possibly modified by the CPE.
  • This variant makes it possible to increase the list of multiple paths and to indicate the policy of distribution of traffic in coherence with that of the operator, in particular in the case where the CPE is operated by the operator.
  • the CPE can remove the connection identifier from the public (ie unencrypted) header, if another connection identifier is included in the encrypted portion of the message QUIC.
  • connection identifier QUIC used by a terminal is encrypted
  • a new identifier called "Provider Connection Identifier”, and noted PCJD can be exploited by a operator to control the use of different access networks accessible from a CPE to establish QUIC connections.
  • a device called "QUIC Provider Proxy” (denoted P in FIG. 11) is introduced into the operator's network to control the routing of the data along the various multiple paths, but also to remove said PCJD identifier before routing the data to their final destination.
  • Provider Connection Identifier information is:
  • the MP POLICY frame defined above can be used both by the CPE and by the "QUIC Provider Proxy" device to announce the different paths as well as the traffic distribution policy to be applied for both the uplink and the downlink, as required.
  • FIG. 11 shows how the "QUIC Provider Proxy" (P) device makes it possible to use the resources of the various multiple paths without altering the connection identifier QUIC chosen by a terminal T1 located behind this CPE.
  • the QUIC packets sent by T1 are intercepted by the CPE, which injects a unique identifier PC_ID # a and an MP POLICY frame on the various available paths.
  • this device On receipt of these packets by a "QUIC Provider Proxy” device, this device saves the information contained in the MP POLICY frame in the local connection table, then removes the PC_ID # a and MP POLICY objects from the packets before sending them to their destination. final destination.
  • the invention can be implemented within nodes of communications networks, for example terminals, routers or residential gateways, by means of software and / or hardware components.
  • the present invention also relates to a computer system.
  • This computer system conventionally comprises a central processing unit controlling by signals a memory, as well as a input unit and an output unit.
  • this computer system may be used to execute a computer program including instructions for implementing any of the communication methods of the invention.
  • This invention also relates to a computer program as briefly described above.
  • This computer program may be stored on a computer readable medium and may be executable by a microprocessor.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any another desirable form.
  • the invention also relates to an immovable information carrier, or partially or totally removable, comprising instructions of a computer program as briefly described above.
  • This information carrier can be any entity or device capable of storing the program.
  • the information carrier may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, such as a hard disk, or a USB flash drive ("USB flash drive").
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the computer program according to the invention can in particular be downloaded to an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of any of the communication methods according to the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de communication, dans lequel un dispositif communicant est situé derrière une passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1,…,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus dudit dispositif communicant, et recevoir des paquets de données destinés audit dispositif communicant. Ledit procédé comprend les étapes suivantes : ladite passerelle associe un identifiant de connexion respectif C_ID#i à chacun desdits chemins Pi; et, lorsque la passerelle reçoit du dispositif communicant un paquet de données, la passerelle transmet ce paquet de données sur l'un des chemins Pi en prenant en compte l'identifiant de connexion C_ID#i correspondant à ce chemin Pi.

Description

PROCEDE DE COMMUNICATION QUIC VIA DES CHEMINS MULTIPLES
La présente invention concerne le domaine des télécommunications, et notamment les réseaux de communications aptes à mettre en œuvre le protocole IP (Internet Protocol). Plus particulièrement, la présente invention concerne la fourniture de services dans les réseaux IP « à valeur ajoutée », c'est-à-dire les réseaux capables d'effectuer des traitements différenciés selon la nature du trafic acheminé dans le réseau.
L'invention s'applique à tout type de dispositif-client (« User Equipment » en anglais), tel qu'un terminal fixe ou mobile, ou une « TV connectée », ou un décodeur TV (« Set-Top Box », ou STB en anglais), ou encore un serveur média, ledit dispositif-client étant situé derrière une passerelle résidentielle (c'est-à-dire une passerelle domestique ou située dans une entreprise),. En corollaire, l'invention s'applique lorsqu'une première passerelle résidentielle est située derrière une deuxième passerelle résidentielle ; dans ce cas, la première passerelle résidentielle sera considérée comme un dispositif-client. Par souci de concision, un dispositif-client de n'importe quel type sera souvent appelé « terminal » ci-après.
Les terminaux, tels que les téléphones intelligents (« smartphone » en anglais) et les ordinateurs personnels (« Personal Computer », ou PC en anglais) sont désormais capables d'activer et d'exploiter plusieurs interfaces logiques liées à une ou plusieurs interfaces physiques. De tels terminaux sont dits « multi- interfaces » (« Multi-lnterface », ou MIF en anglais). Lorsqu'un terminal dispose de plusieurs interfaces capables de le raccorder à différents réseaux d'accès (par exemple : fixe, mobile, ou WLAN), il bénéficie alors d'un accès dit « hybride », parce qu'il combine différentes technologies de réseaux d'accès.
Plusieurs adresses IP peuvent alors être attribuées à un terminal MIF. Ces adresses sont utilisées lorsqu'il se connecte à différents types de réseaux tels qu'un réseau fixe, un réseau mobile ou un réseau WLAN (initiales des mots anglais « Wireless Local Area Network » signifiant « Réseau Local Sans-Fil », dont les réseaux Wi-Fi sont un exemple emblématique), de manière simultanée ou différée. Ces adresses IP peuvent : • appartenir à la même famille d'adresses ou à des familles d'adresses distinctes (IPv4, IPv6 ou les deux),
• avoir des durées de vie différentes,
• avoir des portées différentes, par exemple adresse IPv4 privée, adresse IPv6 unique de portée locale (Unique Local Address, ou ULA en anglais), ou adresse IPv6 de portée globale (Global Unicast Address, ou GUA en anglais), et
• être affectées à la même interface réseau logique ou à différentes interfaces réseau logiques.
On notera toutefois que la caractéristique « MIF » est volatile, car la capacité d'utiliser plusieurs interfaces dépend des conditions de raccordement au(x) réseau(x), de la localisation du dispositif, ou d'autres facteurs. Un dispositif peut devenir MIF en cours d'établissement d'une communication simple (c'est-à- dire, une communication établie le long d'un chemin unique avec un correspondant donné), ou même après l'établissement d'une communication simple. On notera également qu'un dispositif ne sait pas a priori s'il lui est possible d'utiliser plusieurs chemins distincts pour établir une communication avec un correspondant donné ; plus précisément, le dispositif n'acquiert cette information (le cas échéant) qu'à l'issue d'une phase au cours de laquelle il tente d'établir une communication utilisant des chemins multiples avec le correspondant.
On rappelle qu'une « communication à chemins multiples » est une communication établie entre deux dispositifs empruntant simultanément un ou plusieurs chemins entre ces deux dispositifs. L'établissement et le maintien en activité d'une telle communication reposent sur l'utilisation d'un protocole dédié, tel que MPTCP (Multi-Path TCP), qui peut éventuellement être défini comme une extension d'un protocole de transport défini antérieurement, tel que TCP (initiales des mots anglais « Transmission Control Protocol » signifiant « Protocole de Contrôle de Transmission »). Autrement dit, une communication à chemins multiples est un agrégat d'une ou plusieurs communications simples empruntant un même chemin ou des chemins différents (partiellement ou complètement disjoints). On rappelle également que, dans le domaine des réseaux, on appelle « agrégation de liens » le regroupement de plusieurs liens associés à autant d'interfaces (logiques) comme s'il s'agissait d'un seul lien associé à une seule interface, notamment dans le but d'accroître le débit au-delà des limites d'un seul lien, mais également d'appliquer les mêmes procédures d'exploitation à l'ensemble des liens ainsi agrégés (notion de « fate sharing » en anglais). En particulier, les offres de services concernant un terminal disposant d'un accès hybride reposent sur l'introduction dans le réseau de fonctions permettant d'agréger l'ensemble des communications réseau d'un terminal (par exemple : WLAN et 3G, ou ADSL, WLAN et 4G).
L'agrégation de liens permet aussi de faire en sorte que d'autres interfaces prennent le relais si un lien réseau tombe en panne (principe de redondance). L'agrégation de liens s'applique à tout type de trafic acheminé le long de ces liens, y compris du trafic IP.
L'agrégation de liens peut également être utilisée pour répartir le trafic sur plusieurs liens. Dans ce cas, la répartition de trafic entre des liens qui font l'objet d'un agrégat dépend de divers paramètres ; la répartition de trafic peut ainsi dépendre de la politique d'ingénierie de trafic (par exemple privilégier l'acheminement d'un trafic particulier sur un lien dont les caractéristiques en termes de robustesse ou de disponibilité sont compatibles avec la nature dudit trafic), ou de la politique de Qualité de Service (« Quality of Service », ou QoS en anglais) qui peut par exemple privilégier certains liens dans un contexte de priorisation de trafic.
On notera que l'agrégation de liens ne fait aucune hypothèse quant à la configuration de la machine distante. Ainsi, une machine source peut solliciter une fonction d'agrégation de liens sans que la machine distante n'utilise une telle fonction.
Divers modes d'agrégation peuvent être envisagés, parmi lesquels les trois modes suivants :
« mode de repli (« backup » en anglais) : ce mode consiste à utiliser des chemins secondaires en cas d'indisponibilité des chemins primaires, et ce, afin d'améliorer la disponibilité réseau et, partant, la robustesse et la fiabilité des communications IP établies sur les différents liens ; • mode associatif (« bonding » en anglais) : ce mode consiste à utiliser les ressources associées à tout ou partie des chemins disponibles, les flux IP associés à une même application pouvant être répartis entre plusieurs chemins ; le choix d'exploiter l'intégralité des chemins, ou seulement une partie d'entre eux, peut par exemple être conditionné par la nature du trafic ou les caractéristiques de disponibilité ou de fiabilité associées à chaque chemin, lesquelles peuvent varier fortement d'un chemin à l'autre ; tous les chemins sélectionnés pour ce mode associatif sont considérés comme étant des chemins primaires ; et
• mode dit de « confort » : ce mode est similaire au mode associatif, si ce n'est que les flux d'une application donnée ne sont pas répartis entre plusieurs chemins, mais sont envoyés sur un seul chemin.
On notera que ces modes ne sont pas mutuellement exclusifs, et ne sont pas spécifiques à un type particulier de trafic. Ainsi, ils peuvent être mis en place indépendamment de la nature du trafic qui sera acheminé le long des chemins agrégés selon l'un ou l'autre des différents modes.
Les protocoles de transport majoritairement utilisés par les applications logicielles pour communiquer sur Internet sont TCP (mentionné ci-dessus) et UDP (initiales des mots anglais « User Datagram Protocol » signifiant « Protocole de Datagramme Utilisateur »).
Cependant, plusieurs protocoles de transport ont été proposés, normalisés et mis en œuvre par la communauté Internet pour satisfaire les nouveaux besoins des applications. Par exemple, certaines nouvelles applications nécessitent plus de fonctions transport comparées à celles offertes par TCP et UDP, alors que d'autres considèrent que les fonctions transport offertes par TCP ou UDP ne sont pas (toutes) nécessaires pour leur besoins.
Les fonctions transport sont définies comme étant la liste des services offerts par un protocole utilisé pour multiplexer des connexions au niveau de la couche transport. Cette liste contient, par exemple, la transmission ordonnée des données, la transmission fiable, le contrôle de congestion, ou le contrôle d'intégrité. Un groupe de travail, appelé « Transport Services » (TAPS), a été créé par l'IETF (Internet Engineering Task Force) pour aider les développeurs à définir les interfaces permettant d'invoquer les différents services offerts par les protocoles de transport spécifiés par l'IETF. C'est ainsi que le protocole SCTP (Stream Control Transmission Protocol) a été spécifié pour satisfaire les besoins des applications qui nécessitent plus de fonctions transport que ce qui est possible avec TCP, comme la préservation de la structure des données telle que générée par l'application, ou les communications à chemins multiples. Le protocole DCCP (Datagram Congestion Control Protocol) est un autre protocole de transport qui a été spécifié pour des applications qui requièrent plus de fonctions transport que ce qui est possible avec UDP, comme le contrôle de congestion, mais sans forcément hériter des contraintes d'un protocole orienté connexion comme TCP (par exemple, la contrainte d'assurer une transmission fiable). Le protocole UDP-lite est une version simplifiée du protocole UDP qui a été proposée pour des applications qui ne nécessitent pas toutes les fonctions offertes par UDP (par exemple, le contrôle d'intégrité). Les protocoles DTLS (Datagram Transport Layer Security) et TLS ont été définis pour satisfaire les besoins de chiffrement des applications au niveau de la couche transport.
Malgré ces efforts pour spécifier et mettre en œuvre d'autres protocoles de transport, le déploiement de TCP reste hégémonique. Les principales raisons qui pénalisent l'introduction de nouveaux protocoles de transport à grande échelle face à l'hégémonie de TCP sont :
· la prolifération des fonctions NAT (Network Address Translation), pare- feu, et accélération TCP, et
• le manque de compatibilité avec les systèmes d'exploitation (« Operating Systems » en anglais) embarqués dans les terminaux.
Aussi, différentes approches peuvent être considérées pour l'introduction de nouvelles fonctions transport facilitant l'acheminement de certains trafics dans l'Internet :
• encapsulation au-dessus de TCP ou UDP ; cette approche consiste à transporter les primitives d'un nouveau protocole de transport au-dessus d'un protocole existant, en s'affranchissant des contraintes imposées par la traversée de NAT/pare-feu ;
• définition de nouvelles extensions TCP ; ces extensions TCP ont pour objectif de satisfaire de nouvelles contraintes applicatives (par exemple, augmenter la résilience en cas de changement d'adresse IP), mais également de composer avec de nouvelles conditions des réseaux IP (par exemple, augmenter le débit des connexions TCP), et de nouveaux besoins des utilisateurs (par exemple, améliorer la sécurité ou réduire le délai d'attente avant établissement de la session).
Ce faisant, les fournisseurs de service et opérateurs de réseaux IP ont à cœur de fournir un niveau de qualité d'utilisation comparable entre des applications reposant sur TCP et celles reposant sur UDP. Il est donc souhaitable de disposer d'une parité fonctionnelle aussi large que possible entre TCP et UDP. En particulier, il serait utile de pouvoir établir des communications UDP via des chemins multiples de manière fonctionnellement comparable aux solutions techniques connues, telles que le protocole MPTCP mentionné ci- dessus, qui permettent l'établissement de connexions TCP via des chemins multiples.
Ainsi, le protocole QUIC (Quick UDP Internet Connection), décrit dans l'article de R. Hamilton et al. intitulé « QUIC : A UDP-Based Secure and Reliable Transport for HTTP/2 » (IETF draft-tsvwg-quic-protocol-02, janvier 2016), est un protocole en cours de normalisation à l'IETF qui repose sur UDP, et qui a pour ambition de réduire les temps de latence généralement observés lors de rétablissement de connexions HTTP. Le protocole QUIC a été initialement proposé par la société Google, qui l'a intégré dans son navigateur Web « Chrome ».
Comme illustré sur la figure 1 , qui représente schématiquement une connexion QUIC entre un client C et un serveur S, une connexion QUIC permet de multiplexer différents canaux, appelés « streams », dans une même connexion. Le protocole QUIC permet de décharger le système d'exploitation des contraintes imposées par la couche transport, telles que le contrôle de redondance cyclique destiné à vérifier l'intégrité de la communication.
Dans le protocole QUIC, la plupart des en-têtes de paquets sont chiffrés afin d'améliorer la sécurité et la robustesse de la communication. A la différence du protocole TLS (initiales des mots anglais « Transport Layer Security » signifiant « sécurité de la couche transport »), QUIC ne chiffre pas seulement les données utiles échangées, mais également les informations de contrôle de connexion. Les informations QUIC envoyées en clair sont limitées au strict minimum (par exemple, le numéro de version ou un identifiant de connexion).
L'usage d'UDP permet de s'accommoder de la présence de dispositifs intermédiaires (« middleboxes » en anglais), tels que pare-feux ou NAT, sur le chemin emprunté par une communication QUIC. Le protocole QUIC ambitionne de limiter la procédure d'établissement de connexion (Handshake) à zéro RTT (Round Trip Time), ce qui signifie que les données utiles peuvent être envoyées immédiatement, c'est-à-dire dès l'envoi du premier paquet d'une connexion QUIC, sans que le client QUIC doive attendre la réponse de son correspondant. Un « stream » spécifique est dédié au chiffrement des échanges d'établissement de connexion (Handshake) et à la négociation des options QUIC. La signalisation QUIC intègre des informations qui permettent de contrôler la congestion et de récupérer des paquets perdus, selon un mode de fonctionnement comparable à celui de TCP.
En termes de contrôle de flux, un client QUIC a la capacité d'envoyer des trames appelées « WINDOW UPDATE » qui permettent d'ajuster la limite de « l'offset » pour un « stream » donné, ce qui permet d'améliorer l'efficacité de la transmission des paquets, à l'image de la fonction de contrôle de taille de fenêtre caractéristique du protocole TCP (« l'offset » est un paramètre qui permet à un récepteur QUIC de calibrer la taille de la fenêtre de réception des données ; à mesure que les données sont reçues sur un « stream » donné, le récepteur envoie des trames WINDOW UPDATE qui permettent d'augmenter la valeur de l'offset afin de permettre à l'émetteur d'envoyer encore plus de données sur ce « stream »). De plus, QUIC comprend un mode de contrôle de connexion qui permet de gérer la taille des mémoires-tampon (« buffers » en anglais) allouée par un client QUIC à l'ensemble des « streams » caractéristiques d'une connexion.
Afin de pouvoir accepter tout changement d'adresse IP sans avoir à clôturer une connexion QUIC en cours, le protocole ne s'appuie pas sur les adresses de transport (adresse IP source, numéro de port source, adresse IP destination, numéro de port destination), mais sur un identifiant appelé CID (Connection IDentifier, ou identifiant de connexion). Cet identifiant est généré de façon aléatoire par un client QUIC. Cela étant, le protocole QUIC dans sa définition actuelle présente certains inconvénients, notamment :
• QUIC ne permet pas de découvrir la liste des adresses IP utilisées par un terminal distant ;
« QUIC ne permet pas de distinguer la migration d'une connexion vers un nouveau chemin, ou l'utilisation simultanée d'un ensemble de chemins connus ;
• un terminal utilisant QUIC n'a pas la possibilité de découvrir dynamiquement des chemins multiples lorsque ce terminal est situé dans un réseau d'accès local (LAN) résidentiel ou d'entreprise ;
· un terminal utilisant QUIC qui aurait découvert par un moyen quelconque la disponibilité de plusieurs chemins n'a pas la possibilité de forcer les paquets émis par ce terminal à suivre l'un de ces chemins qui serait choisi par le terminal ;
• même si l'identifiant de connexion QUIC est unique, un serveur distant ne peut pas envoyer des données vers un client en utilisant un quelconque chemin tant que le client n'a pas utilisé ce chemin au préalable pour communiquer avec le serveur ;
• QUIC ne permet pas à un point de terminaison d'indiquer à un correspondant les politiques de distribution de trafic avec lesquelles il est compatible ou qu'il souhaite activer ; en l'absence de telles politiques, une utilisation abusive de certains chemins pourrait par exemple avoir des incidences sur la qualité d'expérience du correspondant en cas d'atteinte d'un plafond lié à la charge maximum d'un lien (quota), telle que permise par l'offre de service ;
• les politiques de distribution de trafic via des chemins multiples telles qu'activées par un terminal QUIC peuvent ne pas être optimales pour l'opérateur ; par exemple, la politique de distribution typique dans un environnement d'accès hybride (c'est-à-dire un environnement permettant à un terminal d'exploiter les ressources de plusieurs réseaux d'accès filaire et sans fil) est de n'utiliser les ressources radio que si le lien principal (l'accès fixe, habituellement) est saturé ; or un terminal utilisant QUIC n'a pas connaissance de ces politiques ; de plus, dans le contexte d'un accès hybride, la délégation de gestion de la politique de distribution de trafic aux terminaux peut entraîner la saturation de certaines cellules radio alors que le réseau fixe peut être utilisé pour l'écoulement du trafic ;
• un terminal rattaché à un réseau d'accès est incapable d'utiliser les ressources associées à ce réseau si seuls des préfixes IPv6 sont alloués pour établir des communications sur ce réseau alors que le serveur distant avec lequel une communication QUIC est établie n'est accessible qu'avec l'utilisation d'adresses IPv4 ; en effet, les protocoles IPv4 et IPv6 sont incompatibles par conception, et il est donc impossible d'établir une communication QUIC entre un terminal qui ne disposerait que d'une adresse IPv6 et un serveur qui n'est accessible qu'à une adresse IPv4.
La présente invention concerne donc un procédé de communication, dans lequel un dispositif communicant est situé derrière une passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1 ,...,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus dudit dispositif communicant, et recevoir des paquets de données destinés audit dispositif communicant, ledit procédé comprenant les étapes suivantes :
a) ladite passerelle associe un identifiant de connexion respectif C_ID#i à chacun desdits chemins Pi, et
b) lorsque la passerelle reçoit du dispositif communicant un paquet de données, la passerelle transmet ce paquet de données sur l'un des chemins Pi en prenant en compte l'identifiant de connexion C_ID#i associé à ce chemin Pi.
Grâce à ces dispositions, une communication QUIC pourra bénéficier des ressources associées à des chemins multiples, même si ces chemins multiples ne sont pas visibles des points d'extrémité de la communication. Plus précisément, l'établissement d'une communication QUIC sur des chemins multiples bénéficiera d'une robustesse et de performances améliorées, ce qui permettra d'améliorer l'usage des ressources dans le réseau, mais également d'améliorer la qualité d'expérience telle que perçue par le client (grâce notamment à la capacité d'agréger la bande passante susceptible d'être utilisée par la communication QUIC, ou à la capacité de basculer le trafic vers un autre chemin en cas de panne par exemple). Par ailleurs, les opérateurs réseau pourront mieux contrôler certaines fonctions (notamment la gestion des communications à chemins multiples pour une distribution de trafic déterministe) qui leur permettront d'optimiser l'usage des ressources réseau à leur disposition, et donc de proposer des services de connectivité QUIC à valeur ajoutée.
Selon des caractéristiques particulières, ledit procédé comprend préalablement les étapes suivantes :
- ledit dispositif communicant découvre ladite pluralité de chemins Pi, et
- le dispositif communicant envoie à ladite passerelle un ou plusieurs messages spécifiant un identifiant de connexion respectif C_ID#i pour chacun desdits chemins respectifs Pi.
Ainsi, lorsque la passerelle reçoit du dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#i, la passerelle transmet ce paquet de données sur le chemin Pi associé à cet identifiant de connexion C_ID#i.
Grâce à ces dispositions, un client QUIC peut forcer la sélection d'un chemin spécifique pour acheminer certains paquets, le cas échéant en dépit de la décision de sélection de chemins exécutée par un nœud situé plus loin dans le réseau et capable d'établir une communication QUIC sur des chemins multiples ; un client QUIC peut ainsi influencer la politique de distribution de trafic entre plusieurs chemins, même si la décision de distribution de trafic est exécutée par un nœud situé plus loin dans le réseau.
On notera que cette procédure ne requiert aucune modification des éléments réseau situés entre le client et le nœud apte à utiliser des chemins multiples pour établir une communication QUIC.
Selon des caractéristiques encore plus particulières, ladite passerelle envoie audit dispositif communicant un message contenant la liste des chemins Pi connus de la passerelle.
Grâce à ces dispositions, un client QUIC peut découvrir dynamiquement l'existence de chemins multiples (non visibles localement).
On notera que l'utilisation d'un même identifiant de connexion QUIC permet la traçabilité des connexions QUIC lors de l'attachement du client QUIC à de nouveaux réseaux. C'est pourquoi, selon d'autres caractéristiques particulières, lorsque ladite passerelle reçoit dudit dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#0, la passerelle transmet ce paquet de données sur l'un desdits chemins Pi, en remplaçant ledit identifiant de connexion C_ID#0 par ledit identifiant de connexion C_ID#i associé à ce chemin Pi si les identifiants de connexion C_ID#0 et C_ID#i sont différents entre eux.
Grâce à ces dispositions, on améliore la confidentialité de la communication QUIC, et l'on minimise les risques de piratage de données à partir de la connaissance de l'identifiant de connexion. De plus, la traçabilité d'un client QUIC qui change de réseau d'accès est rendue plus difficile.
Selon des caractéristiques encore plus particulières, lorsque ledit paquet de données reçu dudit dispositif communicant est émis en réponse à un message émis par son correspondant, ladite passerelle transmet ce paquet de données au correspondant sur le chemin sur lequel ledit message est parvenu à la passerelle.
Grâce à ces dispositions, la passerelle sait dans ce cas sur quel chemin elle doit transmettre ledit paquet de données reçu de la part du dispositif communicant.
Selon encore d'autres caractéristiques particulières, ledit dispositif communicant et/ou ladite passerelle envoient au correspondant du dispositif communicant un message comprenant la liste des chemins connus du dispositif communicant et/ou de la passerelle.
Grâce à ces dispositions, ledit correspondant est informé des chemins qu'il peut utiliser pour envoyer des données au dispositif communicant. Cela est notamment utile pour communiquer au correspondant des adresses à utiliser pour envoyer des données au dispositif communicant sans que ce dernier ait utilisé l'une de ces adresses au préalable pour communiquer avec ce correspondant.
Selon encore d'autres caractéristiques particulières, ladite passerelle met en œuvre une politique de distribution de trafic comprenant des règles de répartition du trafic entre les différents réseaux disponibles.
Grâce à ces dispositions, la qualité d'expérience client est améliorée sans que les clients QUIC n'adoptent un comportement agressif par rapport au(x) réseau(x) d'accès, c'est-à-dire un comportement qui aurait pour conséquence de phagocyter l'ensemble des ressources du réseau d'accès au seul profit des communications QUIC et au détriment des autres applications susceptibles d'employer ces mêmes ressources.
Selon des caractéristiques encore plus particulières, ladite passerelle envoie au dispositif communicant un message décrivant la politique de distribution de trafic à observer.
Grâce à ces dispositions, un client QUIC peut découvrir dynamiquement les politiques de distribution de trafic exécutées par un nœud situé plus loin dans le réseau, observer ces politiques, et optionnellement en informer son correspondant.
Corrélativement, l'invention concerne divers dispositifs.
Elle concerne ainsi, premièrement, un dispositif communicant situé derrière une passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1 ,...,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus dudit dispositif communicant, et recevoir des paquets de données destinés audit dispositif communicant, ledit dispositif communicant comprenant des moyens pour :
- découvrir ladite pluralité de chemins Pi, et
- envoyer à ladite passerelle un ou plusieurs messages spécifiant un identifiant de connexion respectif C_ID#i pour chacun desdits chemins respectifs Pi.
On notera que les dispositifs communicants impliqués dans une communication selon l'invention peuvent être n'importe quels dispositifs compatibles avec le protocole IP. Un tel dispositif communicant peut être de type quelconque, par exemple un dispositif-client (terminal) ou un serveur de contenu. Il peut disposer d'une ou plusieurs adresses IP affectées à chacune de ses interfaces physiques ou logiques. Il peut aussi ne disposer que d'une seule interface, auquel cas la passerelle résidentielle, à laquelle le dispositif-client est connecté, est un dispositif-relais connecté à un ou plusieurs réseaux et compatible avec le protocole QUIC. Selon des caractéristiques particulières, ledit dispositif communicant comprend en outre des moyens pour recevoir de ladite passerelle, et prendre en compte, un message contenant la liste des chemins Pi connus de la passerelle.
L'invention concerne aussi, deuxièmement, une passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1 ,...,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus d'un dispositif communicant situé derrière ladite passerelle, et recevoir des paquets de données destinés audit dispositif communicant, ladite passerelle comprenant des moyens pour :
- associer un identifiant de connexion respectif C_ID#i à chacun desdits chemins Pi, et
- lorsqu'elle reçoit du dispositif communicant un paquet de données, transmettre ce paquet de données sur l'un des chemins Pi en prenant en compte l'identifiant de connexion C_ID#i associé à ce chemin Pi.
Selon des caractéristiques particulières, ladite passerelle résidentielle comprend en outre des moyens pour :
- recevoir dudit dispositif communicant un ou plusieurs messages spécifiant un identifiant de connexion respectif C_ID#i pour chacun desdits chemins respectifs Pi, et
- lorsqu'elle reçoit du dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#i, transmettre ce paquet de données sur le chemin Pi associé à cet identifiant de connexion C_ID#i.
Selon d'autres caractéristiques particulières, ladite passerelle résidentielle comprend en outre des moyens pour :
- recevoir dudit dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#0, et
- transmettre ce paquet de données sur l'un desdits chemins Pi, en remplaçant ledit identifiant de connexion C_ID#0 par ledit identifiant de connexion C_ID#i associé à ce chemin Pi si ces identifiants de connexion C ID#0 et C ID#i sont différents entre eux. Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés de communication succinctement exposés ci- dessus.
On notera qu'il est possible de réaliser ces dispositifs communicants dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques.
L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communications et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes d'un des procédés de communication succinctement exposés ci-dessus, lorsqu'il est exécuté sur un ordinateur.
Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par les procédés de communication succinctement exposés ci-dessus.
D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, dans lesquelles :
- la figure 1 , mentionnée ci-dessus, représente schématiquement une connexion QUIC classique comprenant plusieurs « streams » (canaux),
- la figure 2 représente une passerelle connectée à une pluralité de chemins et apte à associer un identifiant de connexion respectif à chacun desdits chemins,
- la figure 3 représente schématiquement une procédure de découverte de chemins multiples selon un premier mode de réalisation de l'invention,
- la figure 4 représente l'envoi par un terminal de trois paquets au sein d'une même connexion QUIC selon un exemple dudit premier mode de réalisation,
- la figure 5 représente une communication QUIC entre un client C et un serveur S selon un deuxième mode de réalisation de l'invention,
- la figure 6 représente un exemple de format pour une trame CID UPDATE servant à la mise à jour de l'identifiant de connexion QUIC, - la figure 7 représente, selon une variante de ladite procédure de mise à jour, le remplacement de l'identifiant d'une connexion QUIC entre un client C et un serveur S,
- la figure 8 représente un exemple de format pour une trame MP POLICY utilisée pour notifier une politique de distribution de trafic à un correspondant,
- la figure 9 représente une communication QUIC entre un client T1 et un serveur S, selon une première variante d'utilisation de la trame MP POLICY,
- la figure 10 représente une communication QUIC entre un client T1 et un serveur S, selon une deuxième variante d'utilisation de la trame MP POLICY, et - la figure 1 1 représente une communication QUIC à chemins multiples assistée par le réseau.
On va décrire à présent plusieurs modes de réalisation de l'invention. Dans ces modes de réalisation, on considère une passerelle résidentielle notée CPE (initiales des mots anglais « Customer Premises Equipment ») raccordée à un ou plusieurs réseaux N1 , N2, N3, et ainsi de suite, par un ou plusieurs chemins P1 , P2, P3, et ainsi de suite. Comme représenté schématiquement sur la figure 2, le CPE associe un identifiant de connexion C_ID#1 à un chemin la reliant au réseau N1 , un identifiant de connexion C_ID#2 à un chemin la reliant au réseau N2, un identifiant de connexion C_ID#3 à un chemin la reliant au réseau N3, et ainsi de suite. On notera que ces identifiants de connexion ne sont pas nécessairement tous différents entre eux ; dans certains cas, un même identifiant de connexion peut être utilisé pour tous les paquets envoyés ou émis par le CPE sur chacun des chemins dans le cadre d'une même communication QUIC.
Comme illustré sur la figure 2, le CPE peut par exemple servir d'intermédiaire dans une communication QUIC entre un serveur S et un terminal T1 (mono-interface, ou multi-interfaces) localisé derrière le CPE.
Selon un premier mode de réalisation, on considère un terminal T1 localisé derrière un CPE et apte à mettre en œuvre une procédure de découverte de chemins multiples. Cette procédure de découverte est représentée schématiquement sur la figure 3.
Pour découvrir les chemins multiples connus du CPE en plus des chemins visibles localement, le terminal T1 peut émettre des messages, appelés DISCOVER_PATH() ; un tel message peut être envoyé sur toutes ou seulement certaines interfaces réseau actives du terminal.
Si des chemins multiples sont connus du CPE, ce dernier envoie une liste des chemins disponibles à l'aide de la primitive ADVERT PATHS(Pi). Un chemin donné Pi peut être identifié par :
• un index de chemin local au CPE (Path identifier), par exemple, « 1 », « 2 », « 155467 »,
• un index d'interface local au CPE (Interface Index), par exemple, « Ifindexl », « Ifindex2 », « Ifindexl 5 »,
« un nom d'interface, par exemple, « cellular », « adsl », « fiber »,
• une adresse ou un préfixe IP externe, par exemple « 1 .2.3.4 » ou « 2001 :db8::/56 »,
• une adresse physique, par exemple une adresse MAC (Médium Access Control),
· une combinaison d'un index et d'une adresse IP externe, ou
• tout autre identifiant, y compris toute combinaison des éléments d'information mentionnés ci-dessus.
Le message ADVERT PATHS(Pi) peut être envoyé par un CPE suite à une sollicitation de la part d'un terminal situé derrière le CPE, ou de manière spontanée, c'est-à-dire sans que le CPE ait été explicitement sollicité par un terminal. A titre d'exemple, le CPE peut envoyer un message ADVERT PATHS(Pi) :
• au redémarrage du CPE,
• de façon périodique sur le ou les réseaux local(ux) au(x)quel(s) différents terminaux sont connectés,
• lorsqu'un nouveau terminal se connecte au CPE via le réseau local,
• lorsque le CPE se connecte à un nouveau réseau d'accès,
• lorsque le CPE est déconnecté d'un réseau d'accès de manière intempestive ou non, ou
· lors du changement d'adresse/préfixe IP alloués par un réseau d'accès.
Quand donc un terminal T1 découvre une pluralité de chemins Pi, où i=1 ,..., N, il détermine un identifiant de connexion respectif C_ID#i pour chaque chemin respectif Pi. Le terminal T1 contacte ensuite le CPE pour programmer des politiques de distribution de paquets sur les différents chemins disponibles.
Pour ce faire, le terminal T1 envoie un ou plusieurs messages MAP(C_ID#i, Pi).
Le message MAP() permet aussi optionnellement d'annoncer les caractéristiques du trafic (notamment, les adresses IP et numéros de port source et destination), afin de pouvoir identifier une connexion QUIC susceptible d'acheminer ledit trafic.
On notera que le message MAP() peut être envoyé avant, ou après l'établissement d'une connexion QUIC avec un correspondant du terminal T1 .
Suite à la réception d'un ou plusieurs message(s) MAP(C_ID#i, Pi), le CPE installe les associations telles qu'indiquées par le terminal T1 . Si une association est déjà présente pour ce terminal et pour un même identifiant de connexion, le CPE la remplace par une nouvelle instruction reçue du terminal T1 .
Le CPE utilise un identifiant stable, tel qu'une adresse MAC, pour identifier les associations d'un même terminal. Les associations peuvent avoir une durée de vie limitée.
Le CPE peut compléter les informations caractéristiques d'une association par des informations reçues du correspondant du terminal T1 .
Le CPE peut indiquer au terminal T1 un autre identifiant de connexion à utiliser en cas, par exemple, de conflit entre un identifiant C_ID#i et un identifiant déjà choisi par un autre terminal. D'autres politiques de sélection d'identifiants de connexion peuvent être exécutées par le CPE. L'allocation de l'identifiant de connexion par le CPE (ou par un dispositif installé par l'opérateur) a pour but de faciliter l'identification des connexions QUIC. En effet, le CPE anticipe la réception de paquets QUIC en installant des gabarits de trafic selon l'identifiant de connexion connu au préalable. On notera à cet égard que cette possibilité pour une entité autre qu'un client ou un serveur d'allouer un identifiant de connexion n'est pas connue dans l'état de la technique.
Ensuite, le CPE envoie au terminal T1 un message d'acquittement MAP_ACK() qui fournit un inventaire des associations installées. De manière optionnelle, le CPE peut aussi retourner les autres associations connues pour ce terminal.
Afin de permettre au CPE de distribuer le trafic via les différents chemins multiples selon une politique connue du terminal T1 , ce dernier doit naturellement utiliser l'identifiant adéquat conformément aux associations programmées au préalable sur le CPE.
On notera que le CPE peut répartir le trafic reçu d'un terminal entre plusieurs chemins disponibles sans pour autant que ledit terminal ait communiqué au CPE des instructions de distribution de trafic, ni même que le terminal soit informé de l'existence de chemins multiples. A cet effet, le CPE exécute un algorithme de distribution de trafic selon des politiques préconfigurées.
La figure 4 illustre, à titre d'exemple, l'envoi par un terminal T1 de trois paquets au sein d'une même connexion QUIC ; chacun de ces paquets est identifié par un identifiant de connexion C_ID#i dédié. A réception de ces paquets par le CPE, ce dernier consulte sa table d'associations pour déterminer le chemin à utiliser pour envoyer le paquet vers sa destination. Dans cet exemple, un paquet dont l'identifiant de connexion est C_ID#1 est transmis via le réseau N1 , un paquet dont l'identifiant de connexion est C_ID#2 est transmis via le réseau N2, et un paquet dont l'identifiant de connexion est C_ID#3 est transmis via le réseau N3. On notera que les paquets transmis sont associés au même identifiant de connexion (noté C_ID#a sur la figure 4) ; cet identifiant peut être généré par le CPE, mais aussi, en variante, par le terminal T1 ou par son correspondant.
Comme mentionné ci-dessus, l'utilisation d'un même identifiant de connexion CJD sur les divers réseaux traversés permet la traçabilité des connexions QUIC lors d'attachement à de nouveaux réseaux, ce qui met en danger la confidentialité des échanges. On va décrire à présent des modes de réalisation de l'invention dans lesquels, pour résoudre ce problème, des « alias » d'identifiants de connexion QUIC peuvent être crées par l'un ou l'autre des participants à une communication QUIC.
Considérons par exemple, selon un deuxième mode de réalisation de l'invention illustré sur la figure 5, un client C localisé derrière un CPE. Ce client C émet des paquets de données comprenant un identifiant de connexion QUIC noté C_ID#0 généré par le client C.
Suite à la réception du premier paquet de données caractéristique d'une nouvelle communication entre le client C et le serveur S, le CPE met en place des associations entre des identifiants de connexion C_ID#i (alias) et les chemins Pi respectifs, par exemple en configurant une table d'associations dans une base de données.
On notera qu'un alias peut être généré par le CPE, mais aussi, en variante, par le client C ou par le serveur S. Par exemple, si ledit premier paquet est reçu par le CPE en provenance du serveur S sur un chemin Pi, et que ce paquet comprend un identifiant de connexion C_ID#i, le CPE associe de préférence cet alias C_ID#i à ce chemin Pi.
On notera également que divers schémas sont possibles pour les valeurs attribuées aux alias par rapport à la valeur de l'identifiant de connexion « originel » C_ID#0, par exemple :
• C_ID#i identique à C_ID#0 quel que soit i=1 ,...,N, ou
• C_ID#i identique à C_ID#0 pour une seule valeur de i, ou encore
• C_ID#i différent de C_ID#0 quel que soit i=1 ,. , .,Ν.
Par ailleurs, deux alias quelconques C_ID#i et C_ID#j, avec i différent de j, peuvent avoir des valeurs identiques ou différentes entre elles.
Le CPE transmet ensuite ledit premier paquet à son destinataire (serveur S ou client C).
Dès lors, pour chaque réception par le CPE d'un paquet caractéristique de cette communication en provenance du client C, le CPE transmet ce paquet au serveur S sur l'un des chemins Pi, après consultation de sa table d'associations et modification dans ce paquet (le cas échéant) de la valeur de l'identifiant de connexion QUIC, c'est-à-dire remplacement de C_ID#0 par l'alias C_ID#i associé au chemin Pi (si C_ID#i est différent de C_ID#0).
Le CPE peut notamment mettre en œuvre cette procédure de réécriture de l'identifiant de connexion QUIC originel C_ID#0 afin de contribuer à la préservation de la confidentialité des données échangées entre le client C et le serveur S. Pendant la communication, le CPE peut décider de mettre à jour l'identifiant de connexion s'il se connecte à un nouveau réseau, ou si les données sont distribuées via des chemins multiples connus du CPE et/ou du serveur S. Ces alias ne sont alors, de préférence, connus que du CPE et du serveur S. Pour qu'un client ou un serveur puisse informer son correspondant de la migration de l'identifiant de connexion QUIC (CJD), il est proposé une procédure de migration de CJD (par exemple pendant une connexion active ou lors d'un changement de l'attachement au réseau), dans laquelle :
« la migration de CJD peut être à l'initiative du CPE, du client ou du serveur ;
• la migration de CJD peut avoir lieu à n'importe quel moment au cours d'une connexion QUIC ; ainsi, la migration de CJD peut avoir lieu juste avant la migration d'une connexion vers un nouveau chemin (ou un nouvel attachement réseau), ou avoir lieu juste après la migration d'une connexion vers un nouveau chemin (ou un nouvel attachement réseau) ; et
• les mêmes clés de sécurité sont utilisées pour valider la migration de
CJD.
Pour ce faire, le client ou le serveur envoie une trame de type « CIDJJPDATE ». Un exemple de format pour cette trame CIDJJPDATE est représenté sur la figure 6. Cette trame est envoyée dans un message QUIC dont l'identifiant est celui de la connexion QUIC déjà établie entre les participants. Cette trame peut être envoyée conjointement avec d'autres données, ou être envoyée dans un message QUIC dédié. A réception du message QUIC qui contient une trame CIDJJPDATE par un correspondant, celui-ci procède aux validations QUIC classiques pour s'assurer que le message provient d'un terminal légitime. Une fois le message validé, le correspondant extrait les informations contenues dans la trame CIDJJPDATE.
Si le champ « Event » est valorisé à « 0 » (MIGRATE), il s'agit alors d'une mise à jour immédiate de l'identifiant de connexion, comme illustré sur la figure 7 où un identifiant de connexion, noté « OLD CID » sur cette figure, est remplacé par un nouvel identifiant de connexion, noté « NEW CID ». Tout échange QUIC au titre de cette connexion doit alors utiliser ce nouvel identifiant.
Si le champ « Event » est valorisé à « 1 » (ALIAS), il s'agit alors de définir un alias de l'identifiant de connexion CJD#0 pour chaque chemin. Plusieurs alias peuvent être indiqués dans une même trame.
Quel que soit le mode de réalisation, l'opérateur peut souhaiter appliquer une politique de distribution de trafic. On supposera ici que des politiques de distribution de trafic peuvent être configurées sur le CPE, afin de lui permettre de répartir le trafic entre les différents réseaux disponibles ; ces politiques peuvent être configurées par un fournisseur de service ou par un utilisateur ; un exemple de politique consiste à n'utiliser les ressources radio qu'en cas d'indisponibilité d'un réseau d'accès fixe ou lorsque les ressources disponibles (maximums) du réseau d'accès principal (typiquement le réseau filaire) ne permettent plus d'écouler le trafic caractéristique d'une application donnée ; les politiques de distribution de trafic sont critiques, car une utilisation non adéquate des ressources disponibles peut induire une consommation rapide du quota disponible sur un lien d'accès donné, voire provoquer une augmentation sensible du montant de la facture à payer par l'utilisateur ; la maîtrise d'une politique de distribution du trafic est également critique pour un opérateur car elle permet notamment de minimiser le risque de congestion de certains liens (par exemple, l'utilisation abusive d'une connexion cellulaire par un CPE multi-interfaces peut congestionner une cellule au détriment des terminaux mobiles mono-interfaces). Avantageusement, le CPE peut ajuster ses politiques de distribution de trafic en fonction des conditions réseau observées.
Le CPE peut communiquer au terminal/client la politique de distribution de trafic à observer, au moyen de la primitive MAP(C_ID#i, Pi, POLICY). L'objet POLICY peut comprendre, par exemple :
• un volume maximum de données à envoyer par chemin,
• un ratio de distribution de trafic (par exemple, 10% pour P1 , 80% pour P2, 10% pour P3),
• un ordre de priorité d'invocation des ressources associées à chaque chemin (par exemple, utiliser d'abord P1 puis P2 en cas de congestion),
• un chemin qui ne sera utilisé que pour secourir un chemin principal (par exemple, P2 est désigné comme chemin de secours de P1 ),
• une indication selon laquelle le chemin présentant le meilleur RTT doit être utilisé,
· une indication selon laquelle les chemins présentant un RTT similaire doivent être utilisés,
• une indication selon laquelle les « streams » avec une priorité haute doivent être acheminés via un chemin donné. Le terminal/client doit respecter la politique de distribution de trafic telle qu'indiquée par le CPE. Etant donné que la politique de distribution de trafic ne concerne pas que le trafic sortant mais aussi le trafic entrant, une nouvelle trame, appelée MP POLICY, est utilisée pour notifier un correspondant du terminal/client.
Un terminal/client apte à échanger des données via des chemins multiples peut inclure une trame MP POLICY dans un message QUIC envoyé à son correspondant. Cette trame permet d'annoncer au correspondant la liste des chemins connus du terminal/client (notamment, des adresses à utiliser pour envoyer des données au terminal/client sans que ce dernier ait utilisé l'une de ces adresses au préalable pour communiquer avec ce correspondant), ainsi que, optionnellement, la politique de distribution de trafic entrant (du correspondant vers le terminal/client).
Un format possible pour cette trame MP POLICY est représenté sur la figure 8. Sur cette figure :
• le champ « Type » indique qu'il s'agit d'une trame « MP POLICY »,
• le champ « Sub-type » peut indiquer par exemple les valeurs suivantes : o « 0 » : liste les chemins multiples connus de l'émetteur ; le champ « Data » doit alors inclure une liste de chemins connus de l'émetteur de la trame ; à titre d'exemple, le champ « Data » peut inclure une liste d'adresses IP (ou de ports) à utiliser pour envoyer des paquets vers un même terminal au titre d'une même connexion à chemins multiples ; o « 1 » : politique de distribution de trafic entre les différents chemins multiples ; les chemins disponibles peuvent être utilisés simultanément ; o « 2 » : un volume maximum de données est à envoyer par chemin ; le champ « Data » précise le volume ainsi que le chemin concerné ;
o « 3 » : indique un ratio d'utilisation par chemin ; le champ « Data » précise cette politique, par exemple 10% pour P1 , 80% pour P2, et 10% pour P3 ; o « 4 » : Indique que l'algorithme du meilleur RTT doit être utilisé.
La trame MP POLICY peut être envoyée par l'un des participants, ou par tous les participants à une connexion QUIC. Elle peut être envoyée à n'importe quel moment d'une connexion QUIC. Elle peut être envoyée conjointement avec d'autres données de contrôle ou des données utiles. Une ou plusieurs trames MP POLICY peuvent être incluses dans un même message QUIC. Une trame MP POLICY peut être utilisée pour signaler qu'un chemin n'est plus disponible.
Un correspondant QUIC qui reçoit une trame MP POLICY sauvegarde une copie du contenu de la trame dans sa table de connexions QUIC. Typiquement, cette table contient des identifiants de connexion (C_ID). Si la trame mentionne d'autres adresses IP (ou ports), le correspondant peut utiliser ces informations pour communiquer via des chemins multiples, c'est-à- dire envoyer des paquets ayant comme adresse de destination (port de destination) l'une des adresses indiquées dans la trame MP POLICY. Ainsi, les politiques de distribution de trafic indiquées dans la trame MP POLICY informent le correspondant de l'approche à suivre pour envoyer les données d'une même connexion QUIC vers les différents chemins disponibles.
La figure 9 représente une communication QUIC entre un terminal T1 et un serveur S, selon une première variante dans laquelle le terminal T1 annonce au serveur S la liste des chemins disponibles à l'aide d'une trame MP POLICY. La trame est envoyée via le chemin qui traverse le réseau N1 . Le serveur peut envoyer les données de cette même connexion via les autres chemins vers le terminal T1 (N2 ou N3) sans que le terminal T1 ait utilisé ces chemins pour communiquer avec S.
La figure 10 représente une communication QUIC entre un terminal T1 et un serveur S, selon une deuxième variante dans laquelle une trame MP POLICY est insérée par le CPE.
Selon une troisième variante (non représentée), le contenu de la trame MP POLICY peut être contrôlé et éventuellement modifié par le CPE. Cette variante permet d'augmenter la liste des chemins multiples et d'indiquer la politique de distribution de trafic en cohérence avec celle de l'opérateur, notamment dans le cas où le CPE est exploité par l'opérateur. Ainsi, le CPE peut retirer l'identifiant de connexion de l'en-tête public (c'est-à-dire non chiffré), si un autre identifiant de connexion est inclus dans la partie chiffrée du message QUIC.
Quel que soit le mode de réalisation, dans le cas où l'identifiant de connexion QUIC utilisé par un terminal est chiffré, un nouvel identifiant appelé « Provider Connection Identifier », et noté PCJD, peut être exploité par un opérateur pour contrôler l'utilisation des différents réseaux d'accès accessibles depuis un CPE pour établir des connexions QUIC. En outre, comme illustré sur la figure 11 , un dispositif appelé « QUIC Provider Proxy » (noté P sur la figure 1 1 ) est introduit dans le réseau de l'opérateur pour contrôler l'acheminement des données le long des différents chemins multiples, mais aussi pour retirer ledit identifiant PCJD avant l'acheminement des données vers leur destination finale.
L'information « Provider Connection Identifier » est :
• injectée par un CPE ou par un « QUIC Provider Proxy »,
• retirée par le CPE avant de procéder à l'acheminement des paquets vers le terminal, et
• retirée par le dispositif QUIC Provider Proxy avant de procéder à l'acheminement des paquets vers la destination S.
La trame MP POLICY définie ci-dessus peut être utilisée à la fois par le CPE et par le dispositif « QUIC Provider Proxy » pour annoncer les différents chemins ainsi que la politique de distribution de trafic à appliquer aussi bien pour la voie montante que descendante, selon les besoins.
La figure 1 1 montre comment le dispositif « QUIC Provider Proxy » (P) permet d'utiliser les ressources des différents chemins multiples sans altération de l'identifiant de connexion QUIC choisi par un terminal T1 localisé derrière ce CPE. Les paquets QUIC envoyés par T1 sont interceptés par le CPE, qui injecte un identifiant unique PC_ID#a et une trame MP POLICY sur les divers chemins disponibles. A réception de ces paquets par un dispositif « QUIC Provider Proxy », ce dispositif sauvegarde les informations contenues dans la trame MP POLICY dans la table de connexions locale, puis retire les objets PC_ID#a et MP POLICY des paquets avant de les envoyer vers leur destination finale.
L'invention peut être mise en œuvre au sein de nœuds de réseaux de communications, par exemple des terminaux, des routeurs ou des passerelles résidentielles, au moyen de composants logiciels et/ou matériels.
Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de nœud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en œuvre de l'un quelconque des procédés de communication selon l'invention.
En effet, l'invention vise aussi un programme d'ordinateur tel que décrit succinctement ci-dessus. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur. Ce programme peut utiliser n'importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations inamovible, ou partiellement ou totalement amovible, comportant des instructions d'un programme d'ordinateur tel que décrit succinctement ci-dessus.
Ce support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support d'informations peut comprendre un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou un moyen d'enregistrement magnétique, tel qu'un disque dur, ou encore une clé USB (« USB flash drive » en anglais).
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un quelconque des procédés de communication selon l'invention.

Claims

R E V E N D I C A T I O N S
1 . Procédé de communication, dans lequel un dispositif communicant est situé derrière une passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1 ,...,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus dudit dispositif communicant, et recevoir des paquets de données destinés audit dispositif communicant, ledit procédé comprenant les étapes suivantes :
a) ladite passerelle associe un identifiant de connexion respectif C_ID#i à chacun desdits chemins Pi, et
b) lorsque la passerelle reçoit du dispositif communicant un paquet de données, la passerelle transmet ce paquet de données sur l'un des chemins Pi en prenant en compte l'identifiant de connexion C_ID#i associé à ce chemin Pi.
2. Procédé de communication selon la revendication 1 , caractérisé en ce qu'il comprend préalablement les étapes suivantes :
- ledit dispositif communicant découvre ladite pluralité de chemins Pi, et
- le dispositif communicant envoie à ladite passerelle un ou plusieurs messages (MAP(C_ID#i, Pi)) spécifiant un identifiant de connexion respectif
C_ID#i pour chacun desdits chemins respectifs Pi,
et en ce que, lorsque la passerelle reçoit du dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#i, la passerelle transmet ce paquet de données sur le chemin Pi associé à cet identifiant de connexion C_ID#i.
3. Procédé de communication selon la revendication 2, caractérisé en ce que ladite passerelle envoie audit dispositif communicant un message (ADVERT PATHS(Pi)) contenant la liste des chemins Pi connus de la passerelle.
4. Procédé de communication selon la revendication 1 , caractérisé en ce que, lorsque ladite passerelle reçoit dudit dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#0, la passerelle transmet ce paquet de données sur l'un desdits chemins Pi, en remplaçant ledit identifiant de connexion C_ID#0 par ledit identifiant de connexion C_ID#i associé à ce chemin Pi si ces identifiants de connexion C_ID#0 et C_ID#i sont différents entre eux.
5. Procédé de communication selon la revendication 4, caractérisé en ce que, lorsque ledit paquet de données reçu dudit dispositif communicant est émis en réponse à un message émis par son correspondant, ladite passerelle transmet ce paquet de données au correspondant sur le chemin sur lequel ledit message est parvenu à la passerelle.
6. Procédé de communication selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit dispositif communicant et/ou ladite passerelle envoient au correspondant du dispositif communicant un message (MP POLICY) comprenant la liste des chemins connus du dispositif communicant et/ou de la passerelle.
7. Procédé de communication selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite passerelle met en œuvre une politique de distribution de trafic comprenant des règles de répartition du trafic entre les différents réseaux disponibles.
8. Procédé de communication selon la revendication 7, caractérisé en ce que ladite passerelle envoie au dispositif communicant un message (MAP(C_ID#i, Pi, POLICY)) décrivant la politique de distribution de trafic à observer.
9. Dispositif communicant situé derrière une passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1 ,...,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus dudit dispositif communicant, et recevoir des paquets de données destinés audit dispositif communicant, ledit dispositif communicant comprenant des moyens pour :
- découvrir ladite pluralité de chemins Pi, et - envoyer à ladite passerelle un ou plusieurs messages (MAP(C_ID#i, Pi)) spécifiant un identifiant de connexion respectif C_ID#i pour chacun desdits chemins respectifs Pi.
10. Dispositif communicant selon la revendication 9, caractérisé en ce qu'il comprend en outre des moyens pour recevoir de ladite passerelle, et prendre en compte, un message (ADVERT PATHS(Pi)) contenant la liste des chemins Pi connus de la passerelle.
1 1 . Passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1 ,...,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus d'un dispositif communicant situé derrière ladite passerelle, et recevoir des paquets de données destinés audit dispositif communicant, ladite passerelle comprenant des moyens pour :
- associer un identifiant de connexion respectif C_ID#i à chacun desdits chemins Pi, et
- lorsqu'elle reçoit du dispositif communicant un paquet de données, transmettre ce paquet de données sur l'un des chemins Pi en prenant en compte l'identifiant de connexion C_ID#i associé à ce chemin Pi.
12. Passerelle résidentielle selon la revendication 1 1 , caractérisée en ce qu'elle comprend en outre des moyens pour :
- recevoir dudit dispositif communicant un ou plusieurs messages (MAP(C_ID#i, Pi)) spécifiant un identifiant de connexion respectif C_ID#i pour chacun desdits chemins respectifs Pi, et
- lorsqu'elle reçoit du dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#i, transmettre ce paquet de données sur le chemin Pi associé à cet identifiant de connexion C_ID#i.
13. Passerelle résidentielle selon la revendication 1 1 , caractérisée en ce qu'elle comprend en outre des moyens pour :
- recevoir dudit dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#0, et - transmettre ce paquet de données sur l'un desdits chemins Pi, en remplaçant ledit identifiant de connexion C_ID#0 par ledit identifiant de connexion C_ID#i associé à ce chemin Pi si ces identifiants de connexion C_ID#0 et C_ID#i sont différents entre eux.
14. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de communication selon l'une quelconque des revendications 1 à 8.
15. Programme d'ordinateur téléchargeable depuis un réseau de communications et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de communication selon l'une quelconque des revendications 1 à 8, lorsqu'il est exécuté sur un ordinateur.
EP18749456.2A 2017-06-27 2018-06-26 Procédé de communication quic via des chemins multiples Pending EP3646557A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1755872A FR3067550A1 (fr) 2017-06-27 2017-06-27 Procede de communication quic via des chemins multiples
PCT/FR2018/051561 WO2019002754A1 (fr) 2017-06-27 2018-06-26 Procédé de communication quic via des chemins multiples

Publications (1)

Publication Number Publication Date
EP3646557A1 true EP3646557A1 (fr) 2020-05-06

Family

ID=60182661

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18749456.2A Pending EP3646557A1 (fr) 2017-06-27 2018-06-26 Procédé de communication quic via des chemins multiples

Country Status (5)

Country Link
US (1) US11088942B2 (fr)
EP (1) EP3646557A1 (fr)
CN (1) CN110999252B (fr)
FR (1) FR3067550A1 (fr)
WO (1) WO2019002754A1 (fr)

Families Citing this family (25)

* 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
FR3067545A1 (fr) * 2017-06-21 2018-12-14 Orange Procede d'activation de traitements appliques a une session de donnees
FR3067550A1 (fr) * 2017-06-27 2018-12-14 Orange Procede de communication quic via des chemins multiples
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.
EP3791548B1 (fr) * 2018-05-09 2022-07-06 Netsurion LLC Protocole de datagramme utilisateur à trajets multiples
US11245753B2 (en) * 2018-08-17 2022-02-08 Fastly, Inc. User space redirect of packet traffic
US10791485B2 (en) * 2018-10-16 2020-09-29 Cisco Technology, Inc. Systems and methods for quick user datagram protocol internet connection (QUIC) with multipath
CN112738004B (zh) * 2019-10-14 2021-11-16 上海哔哩哔哩科技有限公司 基于quic传输协议的通信方法和系统
US11412375B2 (en) 2019-10-16 2022-08-09 Cisco Technology, Inc. Establishing untrusted non-3GPP sessions without compromising security
US11985062B2 (en) * 2020-02-14 2024-05-14 Interdigital Patent Holdings, Inc. Methods and apparatuses for enabling multi-host multipath secure transport with QUIC
KR20220148820A (ko) * 2020-02-28 2022-11-07 레노보 (싱가포르) 피티이. 엘티디. 상이한 액세스 네트워크들을 통한 복수의 조향 접속을 이용한 액세스 트래픽 조향
CN111865940B (zh) * 2020-07-01 2022-10-11 四川速宝网络科技有限公司 一种传输优化的方法及装置
CN114205425A (zh) * 2020-09-02 2022-03-18 中国移动通信有限公司研究院 一种报文传输方法、装置、设备及可读存储介质
CN114928616A (zh) * 2021-02-03 2022-08-19 上海哔哩哔哩科技有限公司 对等网络的传输方法和系统
CN112994974A (zh) * 2021-02-09 2021-06-18 北京金山云网络技术有限公司 集群节点探测方法、装置、集群、设备和介质
CN113114701B (zh) * 2021-04-30 2023-02-28 网络通信与安全紫金山实验室 一种quic数据传输方法及装置
US11811880B2 (en) 2021-06-22 2023-11-07 Adaptiv Networks Inc. Edge link redundancy
CN113676741B (zh) * 2021-07-19 2024-04-12 Oppo广东移动通信有限公司 数据传输方法、装置、存储介质及电子设备
CN113783942B (zh) * 2021-08-24 2023-01-31 中国科学院计算技术研究所 基于优先分级队列的mpquic数据包快速传输方法和系统
US20230083582A1 (en) * 2021-09-15 2023-03-16 Cisco Technology, Inc. Policy expressions using quic connection identifiers
CN115866075A (zh) * 2021-09-27 2023-03-28 华为技术有限公司 一种数据的传输方法及设备
CN114143386A (zh) * 2021-11-23 2022-03-04 广州三七极创网络科技有限公司 一种基于quic协议的通信方法、系统、设备及存储介质
WO2023179891A1 (fr) * 2022-03-23 2023-09-28 Lenovo (Singapore) Ltd. Envoi de données à l'aide d'une direction dans une connexion quic sélectionnée
CN115277560B (zh) * 2022-09-28 2023-01-17 鹏城实验室 基于mptcp和mpquic的异构网络融合传输方法及系统
CN117938550B (zh) * 2024-03-21 2024-05-24 北京火山引擎科技有限公司 一种内容分发网络中的路径验证方法及设备

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6904037B2 (en) * 1996-11-05 2005-06-07 Cisco Technology, Inc. Asymmetric implementation of DSVD for voice/data internet access
US6003088A (en) * 1997-08-29 1999-12-14 International Business Machines Corporation Blocking IP datagrams in a multi-path channel point-to-point environment
US6018770A (en) * 1997-10-13 2000-01-25 Research In Motion Limited System and method for managing packet-switched connections
US7003571B1 (en) * 2000-01-31 2006-02-21 Telecommunication Systems Corporation Of Maryland System and method for re-directing requests from browsers for communication over non-IP based networks
FR2895621A1 (fr) * 2005-12-23 2007-06-29 France Telecom Procede et passerelle de raccordement d'entites de communication ip par l'intermediaire d'une passerelle residentielle
US7639625B2 (en) * 2007-03-02 2009-12-29 Cisco Technology, Inc. Tracing connection paths through transparent proxies
US8792487B2 (en) * 2007-08-21 2014-07-29 Cisco Technology, Inc. Communication path selection
WO2010044714A1 (fr) * 2008-10-16 2010-04-22 Telefonaktiebolaget L M Ericsson (Publ) Passerelle résidentielle permettant d'offrir une interface de secours à un réseau externe
CN101895458B (zh) * 2009-05-18 2013-05-15 电信科学技术研究院 一种分组数据网络连接的释放方法、系统和数据网关
US8730870B2 (en) * 2009-10-29 2014-05-20 At&T Intellectual Property I, L.P. Systems and methods for wireless transmission of packet-based data to one or more residential gateways
US8811152B2 (en) * 2009-10-29 2014-08-19 At&T Intellectual Property I, L.P. System and method to support secondary channel connection from residential gateway to service provider network
EP2522106A1 (fr) * 2010-01-04 2012-11-14 Telefonaktiebolaget LM Ericsson (publ) Procédé et appareil pour le routage sûr de paquets de données
JP5665849B2 (ja) * 2010-03-26 2015-02-04 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 移動無線システム、アクセスポイント装置及びハンドオーバ処理方法
US8824480B2 (en) * 2012-01-31 2014-09-02 Alcatel Lucent Method and apparatus for end-host based mobility, multi-homing and multipath protocols
WO2014090329A1 (fr) * 2012-12-14 2014-06-19 Telefonaktiebolaget L M Ericsson (Publ) Sélection de passerelle réseau dans une communication multivoie
US9634919B2 (en) * 2014-06-27 2017-04-25 Cisco Technology, Inc. Multipath data stream optimization
FR3024004A1 (fr) * 2014-07-21 2016-01-22 Orange Procede de communication tcp via des chemins multiples entre deux terminaux
EP3016347B1 (fr) * 2014-10-27 2019-02-13 Cisco Technology, Inc. Approvisionnement multivoies de trafic l4-l7 dans un réseau
EP3257318B1 (fr) * 2015-02-13 2018-11-14 British Telecommunications public limited company Restauration d'accès réseau
US10069719B2 (en) * 2015-06-16 2018-09-04 Samsung Electronics Co., Ltd. Method and apparatus for multipath media delivery
US10097465B2 (en) * 2015-12-08 2018-10-09 Nicira Inc. Data transfer between endpoints using a multipath connection
US10129372B2 (en) * 2015-12-08 2018-11-13 Nicira, Inc. Transferring multiple data sets using a multipath connection
US10200277B2 (en) * 2015-12-08 2019-02-05 Nicira, Inc. Influencing path selection during a multipath connection
EP3459217B1 (fr) * 2016-05-16 2020-07-08 Telefonaktiebolaget LM Ericsson (PUBL) Transport de paquets udp sur une connexion mptcp
FR3053196A1 (fr) * 2016-06-24 2017-12-29 Orange Procede de communication udp via des chemins multiples entre deux terminaux
FR3053197A1 (fr) * 2016-06-24 2017-12-29 Orange Procede de communication udp via des chemins multiples entre deux terminaux
US10742541B2 (en) * 2016-07-26 2020-08-11 Nokia Of America Corporation Systems and methods for multi-path communication over multiple radio access technologies
EP3531631A4 (fr) * 2016-11-11 2019-08-28 Huawei Technologies Co., Ltd. Procédé et appareil de transmission de données
CN106792936B (zh) * 2016-12-08 2020-04-03 上海华为技术有限公司 一种保持业务连续性的pgw切换方法及通信设备
FR3067550A1 (fr) * 2017-06-27 2018-12-14 Orange Procede de communication quic via des chemins multiples
CN109218186B (zh) * 2017-07-05 2021-02-23 华为技术有限公司 一种多路径数据传输处理方法及网络设备
FR3072527B1 (fr) * 2017-10-17 2019-10-18 Sagemcom Broadband Sas Gestion de la connexion avec d'autres passerelles residentielles d'une passerelle residentielle mettant en œuvre l'agregation de liens

Also Published As

Publication number Publication date
CN110999252B (zh) 2022-04-12
US11088942B2 (en) 2021-08-10
WO2019002754A1 (fr) 2019-01-03
US20200120015A1 (en) 2020-04-16
CN110999252A (zh) 2020-04-10
FR3067550A1 (fr) 2018-12-14

Similar Documents

Publication Publication Date Title
EP3646557A1 (fr) Procédé de communication quic via des chemins multiples
EP3476095B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
EP3476096B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
EP3284224B1 (fr) Procédé d'émulation dune connexion à chemins multiples
EP3318023B1 (fr) Procédé d'optimisation de la charge d'un concentrateur de connexions réseau
EP3162027B1 (fr) Procede de communication tcp via des chemins multiples entre deux terminaux
WO2016128644A1 (fr) Procede de selection de concentrateurs de connexions reseau
EP3127295B1 (fr) Procede de communication par chemins multiples entre deux terminaux
EP3172887A1 (fr) Procédé de communication tcp via des chemins multiples entre deux terminaux
EP3732829B1 (fr) Procédé d'acheminement de données d'une session initialisée entre un terminal et un serveur
EP3991391A1 (fr) Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé
WO2009125158A2 (fr) Procede de routage d'un paquet de donnees dans un reseau et dispositif associe
EP3162024B1 (fr) Procede de communication tcp via des chemins multiples entre deux terminaux
WO2024068725A1 (fr) Procédé de gestion du trafic de données entre une entité source et une entité destinataire, entité et programme d'ordinateur correspondants

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20200121

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20201215

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE