EP3991358A1 - Procede de gestion d'au moins une communication d'un equipement terminal dans un reseau de communication, procedes de traitement d'une communication etablie avec un equipement terminal dans un reseau de communication, dispositifs, equipement terminal, equipement proxy et programmes d'ordinateur correspondants - Google Patents

Procede de gestion d'au moins une communication d'un equipement terminal dans un reseau de communication, procedes de traitement d'une communication etablie avec un equipement terminal dans un reseau de communication, dispositifs, equipement terminal, equipement proxy et programmes d'ordinateur correspondants

Info

Publication number
EP3991358A1
EP3991358A1 EP20747035.2A EP20747035A EP3991358A1 EP 3991358 A1 EP3991358 A1 EP 3991358A1 EP 20747035 A EP20747035 A EP 20747035A EP 3991358 A1 EP3991358 A1 EP 3991358A1
Authority
EP
European Patent Office
Prior art keywords
communication
resource
terminal equipment
address
path
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
EP20747035.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 EP3991358A1 publication Critical patent/EP3991358A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/251—Translation of Internet protocol [IP] addresses between different IP versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/255—Maintenance or indexing of mapping tables
    • H04L61/2553—Binding renewal aspects, e.g. using keep-alive messages

Definitions

  • TITLE Method for managing at least one communication of terminal equipment in a communication network, methods for processing a communication established with terminal equipment in a communication network, devices, terminal equipment, proxy equipment and programs of 'computer matching
  • the field of the invention is that of a communication network and more particularly of the management of communications of terminal equipment in such a network.
  • the invention finds an application in particular in communication networks implementing value-added IP services.
  • the communication protocol was designed to reduce the latency times observed during communications based on the transport protocol TCP (for "Transport Control Protocol") and in particular the time for establishing a communication. between a first terminal equipment, called the client or the sending terminal or even simply the terminal, and a second terminal equipment, called the server or the receiving terminal, via the communication network. It is for this reason that the QUIC protocol is based on the UDP transport protocol (for “User Datagram Protocol”). Indeed, the UDP transport protocol, unlike the TCP protocol, does not use a signaling mechanism of the three-step handshake type (for "3-way handshake", in English), so that the terminals can in particular adapt the frequency of data transmission as a function of network bandwidth conditions for example.
  • the QUIC protocol makes it possible in particular to transmit, under certain conditions, useful data as soon as the first packet of a communication is sent, without the QUIC client having to wait for the response from its correspondent. Latency and signaling times between clients are thus reduced.
  • the QUIC transport protocol does not rely on transport addresses, and more particularly on the quadruplet ⁇ source IP address, source port number, destination IP address, destination port number ⁇ but on a connection identifier called CID (for “Connection Identifier”)
  • CID connection identifier
  • the QUIC specification defines two types of CID: Destination CID and Source CID.
  • connection migration for "Connection migration" which allows a QUIC communication to be maintained in the event of a modification of one of the addresses (or port numbers) of the participants (including the changes related to the use of addresses allocated by intermediate address translation or NAT (for "Network Address Translation”) equipment. Receipt of a message as part of an ongoing communication with a new source address is an indication of connection migration.
  • a connection migration consists of going from one quadruplet ⁇ source address, source port number, destination address, destination port number ⁇ to another.
  • stateful functions such as NAT, firewall or proxy functions on a network path used by QUIC communication constitutes a source of problems likely to compromise quality. of communication.
  • stateful functions are generally hosted by intermediate equipment, and maintain a table comprising entries associating in particular an internal source address and an external source address for an outgoing data packet. They use this table to filter incoming packets by rejecting those that do not match a valid entry in the table.
  • An entry is generally maintained for a period, known as the predetermined lifetime, beyond which, in the absence of a new outgoing data packet or of an adequate control message to extend the lifetime, it is invalidated and deleted. Table. This lifespan can be short, of the order of a second.
  • the communication protocols use a mechanism to "keep alive" a communication which makes it possible, in particular, to verify that the link on which the communication is established is still active or to prevent this link from being broken.
  • a mechanism consists for a terminal equipment, in sending at regular frequency a signaling message to the remote terminal equipment, so that the entries of the tables maintained by said intermediate equipment are not deleted unexpectedly, at the risk of breaking off the communication between the terminals while the data exchange has not yet been completed.
  • the IPsec protocol uses a message called "NAT-Keepalive" whose default sending frequency is 20 seconds.
  • this "keepalive" mechanism characteristic of some communication protocols including the QUIC protocol, is applied indifferently by a terminal equipment to all the paths available to this terminal equipment to access the communications network, as a state function either present or not on the way.
  • the deactivation of this “keepalive” mechanism makes it possible to multiply by 5 or 6 the operating time of a terminal equipment on battery, such as a mobile terminal for example. It will also be noted that reducing the frequency of sending “keepalive” messages significantly contributes to increasing the life of the battery of the terminal equipment. Indeed, the terminal equipment potentially embeds several applications, each sending its own “keepalive” messages. The potential gain is all the greater as the sending of the “keepalive” messages required by the application embedded in the terminal equipment is reduced.
  • the invention responds to this need by proposing a method for managing at least one communication established on a transport protocol of a terminal equipment in a communication network, said terminal equipment being able to access said communication network via at least an IP resource, each IP resource comprising an IP address and a port number, comprising:
  • the invention relates to the management of communications of a terminal equipment in a communication network comprising intermediate equipment that embeds stateful functions, such as NATs or firewalls. These stateful functions allow the data packets exchanged by the terminal equipment via the communication to pass only for those which correspond to a valid entry in their state table, such validity being guaranteed only for a determined period of time. As a result, the management of communications of terminal equipment established on such a network can be complicated. To improve the situation, the invention is based on a completely new and inventive approach, which consists in discovering the presence of stateful functions on the paths interconnecting the various resources available to the terminal equipment to access the network. communications and taking into account the result of this discovery to decide on the communications management actions to be triggered.
  • stateful functions such as NATs or firewalls.
  • a principle of the invention is to send a message from at least a first IP resource of the terminal equipment to a second IP resource of this terminal equipment, and to decide on the presence of a state function on the path connecting the first and second resources as a function of data received by the terminal equipment on its second IP resource, following the transmission of the message.
  • the invention proposes to discover the presence of possible stateful functions by relying on the local IP resources of the terminal equipment. The detection of a stateful function on one of the paths making it possible to reach the second IP address of the terminal equipment is taken into account for the management of a communication involving this second IP address of the terminal equipment.
  • the invention also applies when the terminal equipment has only a single IP address to access the network (the first and second IP resources are then characterized by identical IP addresses but different port numbers).
  • the invention is suitable for any type of transport protocol, in particular the QUIC protocol.
  • the presence of at least one stateful function on the path is decided when the data received includes an error message or when no data is received by the second IP resource in response to the transmission of the first message by at least unedite first IP resource.
  • the first message comprises a request for establishment of a communication between said at least one first IP resource and the second IP resource of the terminal equipment and a decision of absence of a stateful function. on the path connecting said at least one first IP resource to the second IP resource via said network is taken when the data received by the second IP resource of the terminal equipment includes the first message.
  • One principle of the invention is to use the different network access resources available to the terminal equipment to discover the stateful functions present on the paths connecting these resources.
  • new communications are established from resources comprising IP addresses of this terminal equipment to a resource comprising this second IP addresses. These new communications do not correspond to any valid entry in the tables maintained by any stateful functions present on the path of the messages exchanged.
  • the detection step comprises the masking of routing information associated with said second IP resource and contained in said request for establishing said communication, prior to its transmission.
  • One advantage is to emulate terminal equipment having only one interface.
  • the second IP resource is not recognized as a local address of the sending terminal equipment item and the communication request is sent via the output interface of the terminal equipment item.
  • the detection step comprises, prior to the transmission of the communication establishment request, the recording of identification information of at least one routing device of the communication network associated with said to. minus a first IP resource.
  • Another option for forcing the transmission of the communication request in the network is source routing, i.e. the explicit designation of a router equipment of the communication network in charge of routing the packets of data sent by the first terminal equipment on the path corresponding to the first IP resource.
  • a communication being established between said at least one first IP resource of the terminal equipment and an IP resource of a second terminal equipment said first message is sent via said communication to said resource IP of the second terminal equipment, said first message comprises at least one command for sending a response to the second IP resource and a command for inserting security information into said at least one response and a decision to The absence of a stateful function on the path making it possible to reach via said communication network said terminal equipment on the second IP resource is taken when the data received on said second IP resource from the terminal equipment (T1) includes said response.
  • the method comprises determining a time period for sending a hold message. alive of a state of a communication established on said at least one path by said at least one stateful function, the storage of the determined period and the taking into account of the determined period in the decision of a management action on a communication via said path.
  • One advantage of knowing this period is that it enables the management of communications to be optimized. For example, we can choose the communication on the path whose state function has the highest period and activate the keep-alive mechanism by configuring a sending of messages according to said period, to limit the energy consumption of the equipment. terminal.
  • said determination comprises:
  • the value of the chosen parameter is equal to half of the current value of the time interval.
  • the method comprises updating a status representative of a configuration of a mechanism for keeping a state function alive, said status being associated with said at least one path allowing to join via said communication network said terminal equipment on the IP address of the second IP resource of the terminal equipment according to said at least one decision taken for said at least one path.
  • the status is set to an “optimized” value when no stateful function has been detected on the path, since it is not necessary in this case to activate the mechanism. keeping tables alive, or following the determination of a lifetime associated with the detected state function. On the contrary, it is set to a value "not optimized” otherwise, in particular when a state function has been detected, to indicate that the mechanism for keeping the state function tables alive must be activated and that its function must be optimized. configuration.
  • An advantage of associating such a status with an IP resource of the terminal equipment is to facilitate the management of communications via the network and in particular to allow the terminal equipment to set up communications that are more efficient in terms of resources.
  • the triggered management action comprises the establishment of a communication via said path of the terminal equipment without activating a mechanism for keeping a state associated with the communication alive when a stateful function has not been detected on said path and the establishment of the communication via said path by activating a mechanism for keeping said state associated with the communication alive when a stateful function has been detected on said path .
  • the triggered management action comprises the transmission in the request for establishment of said communication or during said communication of the status of said at least one path associated with said IP address and / or of the determined time period.
  • a terminal equipment includes its own table of paths (typically identified by local IP addresses of the terminal equipment) and a copy of that of the other terminal equipment with which it communicates (typically identified by IP addresses of the remote terminal equipment). It is understood that the statuses and lifetimes associated with the paths on which the communication is established may be different. Their mutual knowledge enables the terminals to negotiate between themselves the best choice of path and lifetime to be applied to a mechanism for keeping the states maintained by the state functions possibly present on the communication path alive. In doing so, optimization is more efficient because it is implemented by all participants in a communication.
  • the invention also relates to a computer program product comprising program code instructions for implementing a method for managing at least one communication as described above, when it is executed by a processor.
  • the invention also relates to a recording medium readable by a computer on which is recorded a computer program comprising program code instructions for executing the steps of the management method according to the invention as described above.
  • Such a recording medium can be any entity or device capable of storing the program.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a USB key or a hard disk.
  • such a recording medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means, so that the program computer it contains can be executed remotely.
  • the program according to the invention can in particular be downloaded over a network, for example the Internet.
  • the recording medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned management method.
  • the invention also relates to a device for managing at least one communication of terminal equipment in a communication network, said terminal equipment being able to access said communication network via at least one IP resource, characterized in that it is configured for:
  • such a device is able to implement a method for managing at least one communication as described above.
  • said device is integrated into terminal equipment capable of accessing a communication network from at least one IP resource, comprising an IP address and a port number.
  • the device can also be integrated into proxy equipment of a communication network, able to relay the data sent by terminal equipment connected to said network.
  • the terminal equipment, the device for managing at least one communication and the corresponding computer program mentioned above have at least the same advantages as those conferred by the management method according to the present invention.
  • the invention also relates to a method of processing a communication established on a transport protocol between a first terminal equipment and a second terminal equipment in a communication network via at least one IP resource of the first terminal equipment, each IP resource comprising an IP address and a port number, comprising:
  • said message comprising a send command d 'a response to at least a second IP resource of the first terminal equipment, distinct from the first and comprising a second IP address and a second port number, and a command for inserting security information in the response ;
  • This response from the second terminal equipment to the message sent by the first terminal equipment is exploited by the method for managing at least one communication implemented by said first terminal equipment item to detect the presence of a state function on the path associated with the second IP address.
  • an acknowledgment message is transmitted to the first terminal equipment. Said first terminal equipment thus receives confirmation that the second terminal equipment has indeed received its order. Therefore, if it does not receive the response comprising the security information, the first terminal equipment will be able to deduce therefrom the presence of a state function on the path tested.
  • the invention also relates to a method of processing a communication on a transport protocol between a first terminal equipment item and a second terminal equipment item in a communication network via at least one IP resource of the first terminal equipment item, each IP resource comprising an IP address and a port number, characterized in that that it includes:
  • an IP resource of the second terminal equipment called the destination IP resource
  • a message relating to a communication established or to be established from an IP resource of the first terminal equipment, called the source IP resource said message comprising a status representative of a configuration of a mechanism for keeping an entry of a table maintained by a stateful function alive, said entry associating a state with a communication on a path making it possible to reach via said communication network said first device terminal on the IP address of the source IP resource for a predetermined lifetime, said status being associated with said IP address, and a period of time representative of a transmission frequency of a keep alive message of a communication status;
  • the two terminal equipments negotiate the activation / deactivation of the “keepalive” mechanism and the optimum frequency of transmission of the state keep alive messages.
  • the invention also relates to a computer program product comprising program code instructions for implementing a method of processing a communication as described above, when it is executed by a processor.
  • the invention also relates to a recording medium readable by a computer on which is recorded a computer program comprising program code instructions for the execution of the steps of the processing method according to the invention as described above. .
  • Such a recording medium can be any entity or device capable of storing the program.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a USB key or a hard disk.
  • such a recording medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means, so that the program computer it contains can be executed remotely.
  • the program according to the invention can in particular be downloaded over a network, for example the Internet.
  • the recording medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned management method.
  • the invention also relates to a device for processing a communication between a first terminal equipment item and a second terminal equipment item via a communication network on a transport protocol, characterized in that it is configured to implement a processing method. of the aforementioned communication.
  • said device is integrated into terminal equipment capable of accessing a communication network from at least one IP resource, comprising an IP address and a port number. It can also be integrated into the aforementioned proxy equipment.
  • the terminal equipment, the processing device of at least one communication and the corresponding computer program mentioned above have at least the same advantages as those conferred by the processing method according to the present invention.
  • the invention finally relates to a node device of a communication network capable of receiving, on at least one IP resource comprising an IP address and a port number, data from a communication between an IP resource, called the source IP resource, d. 'a first terminal equipment and an IP resource of a second terminal equipment, called the destination IP resource, and to retransmit them from said at least one IP resource.
  • Such equipment is configured for:
  • FIG. 1 this figure schematically represents an example of terminal equipment having several paths for connecting to a communication network
  • FIG. 2 this figure represents in the form of a logic diagram the various steps of the method for managing at least one communication of a terminal equipment item in a communication network according to one embodiment of the invention
  • FIG. 3A this figure diagrammatically represents a first example of construction of a list of candidate communications between two distinct addresses of the same terminal equipment
  • FIG. 3B this figure schematically represents a second example of construction of a list of candidate communications between two distinct addresses of the same terminal equipment
  • FIG. 4 this figure details in the form of a flowchart the different sub-steps of the step of discovering at least one stateful function on a path of the terminal equipment according to a first embodiment of the method for managing at least one. less one communication according to the invention;
  • FIG. 5 this figure schematically represents a first example of a stateful function present on a path of the terminal equipment in the communication network;
  • FIG. 6 this figure schematically represents a second example of a stateful function present on a path of the terminal equipment in the communication network
  • FIG. 7 this figure schematically represents a third example of a state function present on a path of the terminal equipment in the communication network;
  • FIG. 8A this figure schematically represents a first option of the invention for forcing the sending of a communication request intended for an address of the transmitting terminal equipment in the communication network;
  • FIG. 8B this figure schematically illustrates the reception of the communication request to the address of the sending terminal equipment according to this first option
  • FIG. 9 this figure schematically represents a second option of the invention for forcing the sending of a communication request intended for an address of the transmitting terminal equipment in the communication network
  • FIG. 10 this figure schematically represents the direct communications established by a terminal equipment between two of its own interfaces according to a first exemplary embodiment of the invention
  • FIG. 11 this figure schematically represents the direct communications established by a terminal equipment item between two of its own interfaces according to a second exemplary embodiment of the invention
  • FIG. 12 this figure schematically represents the direct communications established by terminal equipment between two of its own interfaces according to a third exemplary embodiment of the invention, when the terminal equipment is connected to the network via access equipment;
  • FIG. 13 this figure represents an example of implementation of the invention when the terminal equipment has been configured with a proxy equipment located in the communication network;
  • FIG. 14 this figure details in the form of a flowchart the various sub-steps of the step of discovering at least one stateful function on a path of the terminal equipment according to a second embodiment of the method for managing at least one. less one communication according to the invention;
  • FIG. 15 this figure schematically represents an example of the structure of a control message, called mirror, sent by a terminal equipment to a second terminal equipment via a communication already established according to an embodiment of the invention. ;
  • FIG. 16 this figure schematically represents a first example of implementation of a detection of the presence of stateful functions on a path of a first terminal equipment item by using a communication already established with a second terminal equipment item according to the second mode realization of the invention
  • FIG. 17 this figure schematically represents a second example of implementation of a detection of the presence of stateful functions on a path of a first terminal equipment item by using a communication already established with a second terminal equipment item according to the second mode realization of the invention
  • FIG. 18 this figure schematically represents the determination of a lifetime of an input of a state function detected on a path of a terminal equipment item according to a third embodiment of the invention
  • FIG. 19A this figure schematically represents a first example of the structure of a control message of a lifetime of a state function detected on a path of a terminal equipment, according to the third embodiment of the invention
  • FIG. 19B this figure schematically represents a second example of the structure of a control message of a lifetime of a state function detected on a path of a terminal equipment, according to the third embodiment of the invention
  • FIG. 20 this figure diagrammatically represents an example of transmission of a control message by a terminal equipment item to a second terminal equipment item according to this third embodiment of the invention
  • FIG. 21 this figure represents a block diagram of a device for managing at least one communication of terminal equipment in a communication network according to the invention.
  • FIG. 22 this figure represents a block diagram of a device for processing a communication of a terminal equipment item in a communication network according to the invention.
  • the general principle of the invention is based on the discovery of stateful functions present on one or more paths making it possible to join an interface of a terminal equipment via a communication network and on the decision to trigger an action for managing a communication. with another terminal equipment on one of these paths according to said discovery.
  • one possible action is the establishment of a communication by choosing a path which does not have an intermediate state function and without activating a mechanism for keeping alive an entry of a table maintained by such a state function. .
  • the invention thus makes it possible to manage more effectively the communications of a terminal equipment via a communications network and to optimize the energy resources brought into play by these communications.
  • the invention applies to any type of terminal equipment: a single interface terminal equipment or a multi-interface and multi-use terminal equipment capable of establishing communications on multiple paths while preserving the continuity of the service (s) ( s) correspondent (s) when the terminal equipment is in a mobile situation.
  • terminal equipment denotes any entity capable of establishing or accepting the establishment of a communication based on the use of one or more communication protocols.
  • transport such as TCP, UDP, or QUIC. It can be a physical entity, a virtual entity, or a software application embedded in the terminal equipment.
  • QUIC protocol or abbreviated “QUIC” is meant any protocol conforming to a version of the specification of the QUIC protocol or draft specification, such as the draft specification of the IETF entitled “QUIC: A UDP -Based Multiplexed and Secure Transport ”, or the specification of the “Quick UDP Internet Connections” protocol, known as the “QUIC” protocol, including the existing versions of these specifications or draft specifications and their evolutions. More generally, QUIC here denotes any transport protocol encapsulated on another UDP or UDP-lite transport protocol (standing for “Lightweight User Datagram Protocol”) but whose primitives and payload are encrypted.
  • the invention applies to any type of terminal equipment, fixed or mobile, comprising one or more communication interfaces with a communication network.
  • These interfaces can be wired, such as for example an interface of ADSL or fiber type, or non-wired, such as for example an interface of WLAN, BlueTooth, Zigbee, or other type.
  • the term “communication network” is used to denote a communication network of the Internet type which can be accessed by the terminal equipment via one or more networks for accessing this network.
  • the terminal equipment which initiates the establishment of a communication is generally referred to as the sending or client terminal, while that for which the establishment request is intended is called the remote terminal or the server.
  • a single terminal can therefore act both as client and server.
  • one or more paths of a terminal can be used to establish a communication and that a communication can be established via one or more paths.
  • NAT functions can be of different types, such as for example NAT44, NAT64, DS-Lite, NPTv6, L2NAT, NAT 66, etc.
  • NAT functions can be present on a given path, as for example in the case of a so-called "double NAT" deployment.
  • a network path can involve both NAT functions and firewalls, without any restrictive assumption as to the number of functions present or the order in which they operate.
  • incoming state function denotes a state function located in the access network to which a terminal to which a communication is addressed is connected.
  • An outgoing stateful function denotes a stateful function located on the contrary in the access network to which the terminal equipment sending the request to set up a communication is connected.
  • a stateful function can act as an incoming state function or an outgoing state function depending on the direction of traffic.
  • IP resource denotes a pair comprising an IP address and a port number.
  • a terminal equipment Tl having several paths to access, via interfaces which allow the terminal Tl to be connected to different access networks to a communication network RC, such as the Internet network: a first path C1 associated with an IP address @ T11 of the terminal equipment Tl via an access network Nil to the network RC, a second path C2 associated with an address @ T12 of the terminal equipment Tl via an access network N12 , an i th path Ci associated with an address @Tli of the terminal equipment T1 via an access network Nli, with i non-zero integer.
  • a communication network RC such as the Internet network: a first path C1 associated with an IP address @ T11 of the terminal equipment Tl via an access network Nil to the network RC, a second path C2 associated with an address @ T12 of the terminal equipment Tl via an access network N12 , an i th path Ci associated with an address @Tli of the terminal equipment T1 via an access network Nli, with i non-zero integer.
  • FIG. 2 illustrates the main steps implemented by a method for managing at least one communication of the terminal equipment in the communication network RC.
  • a step 20 it is checked, for example when starting the terminal T1, whether it has several network paths Cli to access the network RC and an ACAL list is obtained (for “Address Candidate List”). addresses associated with these paths.
  • an ACAL list comprises, for an IP address @Tli of the terminal T1, an entry associating at least one status value STATUS with the address @Tli.
  • this parameter is set to OKOFF, which means that for this address, no optimization of management of a volume of messages sent by a keepalive mechanism for stateful functions is implemented.
  • a list of candidate communications CC is constructed from the ACAL list between two distinct resources of the terminal equipment T1, that is to say. say between a first pair (first IP address, first port number) and a second pair (second IP address, second port number). It will be understood that these candidate communications are intended to connect two distinct resources of the same terminal equipment T1.
  • the PCL list can exclude private IPv4 addresses as described in RFC 1918, published by the IETF in February 1996 and accessible via the following URL: https://tools.ietf.org/html/rfcl918, IANA-Reserved IPv4 Prefix for Shared Address Space IPv4 addresses, as specified in RFC 6598 published by the IETF in April 2012 and accessible via the following URL: https://tools.ietf.org / html / rfc6598, IPv6 addresses of LLA (“Link Local Address”) or ULA (“Unique Local Address”) type.
  • LLA Link Local Address
  • ULA Unique Local Address
  • the source and destination addresses must be of the same type or family of addresses, for example IPv4 or IPv6, but that the list may contain candidate communications involving addresses of different types, for example candidate communications between two IPv4 type addresses and candidate communications between two IPv6 type addresses.
  • the presence of at least one stateful function is detected, on at least one path making it possible to reach the terminal T1 via the communication network RC on an IP address of said terminal equipment, called the second IP address.
  • this step is repeated for all the paths listed in the ACAL list.
  • the candidate communications of the PCL list are used.
  • a first message is sent in the communication network from at least a first IP resource of said terminal equipment to a second IP resource of said terminal equipment, comprising the second IP address and a port number.
  • the terminal T1 decides on the presence of at least one stateful function on the path taken by this communication to connect the terminal T1 to the network RC via the second IP resource as a function of data received on this second IP resource in response to the transmission of the first message. This step is advantageously repeated for all the candidate communications involving the second IP address of the terminal T1.
  • an action for managing a communication of the terminal equipment T1 is triggered on the path making it possible to reach via said communication network said terminal equipment on said second IP address, as a function of said detection.
  • the management actions of step 23 include selecting a path for establishing a communication with a remote terminal as a function of the result obtained in 22. Examples of management actions will be detailed in the remainder of the description.
  • step 21 of obtaining a PCL list of candidate communications from the paths of the ACAL list.
  • This step therefore aims to create the PCL list from the ACAL list.
  • addresses in the ACAL list are not all of the same type, for example if the list includes elements of different types, for example IPv4 addresses and IPv6 addresses, then a sublist is created by address type: ACAL (v4) and ACAL (v6).
  • the ACAL list of paths available at the terminal T1 to access the network RC can include IP addresses or prefixes, but also network interface names (eg ethl, wlanO), network names, etc. etc. In what follows we will therefore refer to the elements of the ACAL list.
  • the PCL list comprises candidate communications CC between two elements of the ACAL list. It is created taking into account the following constraints:
  • Each entry in the PCL is made up of two items from the ACAL;
  • the second element of a PCL entry is called “Destination”.
  • a port number of the terminal T1, called the destination port, is associated with it;
  • Each item in the ACAL list must appear in at least one PCL entry as "Destination";
  • Two ACAL elements can only belong to one and only one entry in the list
  • An ACAL list item may appear in multiple PCL entries as "Source";
  • the PCL list is ordered
  • FIGS. 3A and 3B illustrate two examples of construction of the PCL list from the ACAL list comprising the elements Nil, N12, Nli. These two examples satisfy the constraints listed above.
  • step 22 of detecting the presence of a state function according to a first embodiment of the invention is now detailed.
  • a communication to be established is selected at 220 from among the candidate communications of the PCL list. During this selection, care is taken not to choose a source IP resource that has just been used as the source or destination of a previous communication, so as to prevent an entry corresponding to this resource from being still maintained as valid in a table of a stateful function present on the tested path.
  • the selected communication is established in 221 by forcing the transmission in the communication network of a request to establish a communication between the source address, the source port number, and the destination address and the port number destination, so that the request is not processed locally at the terminal T1.
  • the source port number chosen for this candidate communication is different from those already used to test the candidate communications listed above. This condition is necessary to detect the presence of NAT functions such as EIF / EIM ("Endpoint Independent Filtering / Mapping") or firewalls.
  • a communication from a new @Tli address can be established with the @ T11 address even in the presence of a NAT if a communication from this @Tli address has been established previously (and maintained by the NAT function) to another @ T2 address.
  • the NAT function supports the “EIF / EIM” mode.
  • the terminal Tll establishes a communication with a remote terminal Tli
  • the NAT function allocates to this communication an external address and an external port number (212.25.26.25:1234) and rewrites the internal source address and internal port number of the packet issued by Tll (192.168.0.2:7856) to Tli.
  • the NAT function keeps in memory an entry in its tables to associate the internal and external information of this communication. This entry does not contain information about Tli. Therefore, any incoming call to (212.25.26.25:1234) will be routed to Tll in rewriting the destination address and port number (192.168.0.2:7856) according to the instructions in the above table. In other words, the NAT function does not check the source address and port number to process an incoming packet.
  • ADM / ADF filtering for “Address Dependent Filtering”
  • APDM / APDF filtering for “Address Port Dependent Filtering”, in English
  • FIG. 7 the NAT function configured in ADM / ADF mode (FIG. 6) must keep in memory the destination address of an outgoing packet, in addition to the source information. Thus, only the packets received with a source address present in an entry in the NAT function table will be routed to an internal terminal.
  • the NAT function allocates an external address and an external port number (11.11.11.11:1234) and rewrites the internal source address and number internal port of the packet sent by Tll (192.168.0.2:7856) to Tli. Then, the NAT function keeps in memory an entry in its tables to associate the internal and external information as well as the destination address characteristic of this communication (internal source: 192.168.0.2:7856, external source: 11.11.11.11:1234, destination : 35.26.25.25). The NAT function rejects all incoming communications to 1.1.1.1:1234 if the source address of a communication is not equal to 35.26.25.25.
  • the example of Figure 7 is similar to that of Figure 6 except that the NAT function records, in addition to the information maintained in the state tables of the example of Figure 6, the port number destination (4545) for outgoing communication sent from Tll (192.168.0.2:7856).
  • the NAT function rejects all incoming communications to 1.1.1.1:1234 which do not have a source address and a source port number equal to 35.26.25.25:4545.
  • decisions to update the statuses of the paths taken by the candidate communications tested can be taken immediately after a single establishment attempt or alternatively after several attempts.
  • steps 220 to 223 is then repeated as long as there are candidate communications to be tested.
  • a second option only part of the communications is established in accordance with a policy local to the terminal T1.
  • a policy local to the terminal T1 An advantage of a selective approach is that it is less expensive in computing resources and potentially better suited to particular contexts, according to which for example the choice of a path is indexed by the nature of the traffic which will pass through the communication. For example, Internet traffic goes through NAT while voice traffic is routed over a path without NAT.
  • the candidate communications are selected at 220 according to their order of appearance in the PCL list and established sequentially so as to avoid the registration of entries by a NAT function on the path that it is desired to test.
  • several candidate communications can be established simultaneously provided that no IP resource of the terminal appears as both source and destination in candidate communications of the PCL list.
  • step 221 of sending a request to set up a selected candidate communication As previously mentioned, because the source and destination IP addresses belong to the same terminal T1, it is necessary to force the routing of the data packet comprising said request through an output interface so that it is not processed locally by the terminal.
  • the request for establishing the communication comprises a parameter MP_BUND (@ T1D) for masking the interface corresponding to the destination IP address of the candidate @ T1D communication of the terminal Tl.
  • MP_BLIND lanterface Alias / Address
  • This MP_BLIND lanterface Alias / Address parameter is used to act as if the Tl terminal only had a single IP address or a single output interface (interface identifier "Interface Alias" or the “Address” interface).
  • This new parameter proposed by the invention when it is invoked to trigger the sending of a packet in the network to a given interface, has the effect of applying a filter to all the other interfaces of the terminal, which has the effect that only information relating to the unfiltered interface is retained.
  • the request to establish a communication between the addresses ⁇ @ T1S, @ T1D ⁇ invoked with the MP_BLIND parameter has the consequence of sending the packet comprising this request to the default router associated with the source IP address @ T1S.
  • terminal T1 maintains a global routing table (table 1) which includes two routing tables associated respectively with each of its “eth0” and “ethl” interfaces.
  • This communication is intended to be processed locally because the destination address is that of the “ethl” interface.
  • the terminal In order to force the sending of the data packet comprising the request for establishing a communication via the RC communication network to the destination IP address @ T1D corresponding to the “ethl” interface, the terminal therefore emulates a behavior mono-interface using the MP_BLIND (ethl) parameter.
  • the invoked routing table (Table 2) is shown below.
  • the packet is then transmitted to the routing equipment RI as illustrated by FIG. 8A.
  • the sending of the request for establishing a communication between the source @ T1S and destination @ T1D IP addresses is forced in 221 by using a source routing technique.
  • a source routing technique known to those skilled in the art, can be implemented in different ways, such as for example the extension of routing by segment SR (for “Segment Routing”), the IPv4 option entitled “ Loose Source and Record Route or any other similar source routing function.
  • the option based on source routing consists of associating additional information with each of the entries in the list of candidate communications PCL to indicate, for each candidate communication, the default router associated with its source IP address @ T1S.
  • the decision to route the data packet comprising the request to set up the selected call is based on the content of the SR option. So the terminal sends the call establishment request to the default router as identified in the corresponding entry in the PCL table. On receipt of the packet, said default router removes the SR option and proceeds to transmit the data packet to the next hop in the communication network.
  • the packet is thus routed step by step or rejected when no route has been found.
  • the terminal T1 seeks to establish in 221 the candidate communications CC listed in its PCL table: ⁇ @ T11, PS11, @ T12, PD12 ⁇ , ⁇ @ T12, PS12, @Tli, PDli ⁇ and ⁇ @Tli, PSli, @ T11, PD11 ⁇ .
  • all these communications are established without difficulty.
  • the ACAL table is therefore updated to set the STATUS parameter of each path associated with a tested destination IP address to the value “OKON”.
  • the terminal T1 seeks to establish the following candidate communications on its access paths to the network: ⁇ @ T11, PS11, @ T12, PD12 ⁇ , ⁇ @ T12, PS12, @Tli, PDli ⁇ and ⁇ @Tli, PSli, @ T11, PD11 ⁇ .
  • all these communications are established successfully with the exception of the candidate communication ⁇ @ T12, PS12, @Tli, PDli ⁇ , because a NAT function is present on the corresponding path.
  • the ACAL table is then updated to update the STATUS parameter of the IP addresses of the access paths to the network of the terminal T1. It sets to the value “OKON” the status of all the IP addresses available in the ACAL list at except for the @Tli address for which the STATUS parameter is kept at "OKOFF".
  • the terminal is connected to the communication network by means of access equipment of the CPE (“Customer Premises Equipment”) type.
  • CPE Customer Premises Equipment
  • This is for example a residential gateway.
  • the method which has just been described can advantageously be implemented by this CPE equipment.
  • this proxy equipment P implements a “Proxy QUIC” function responsible for executing operations on the QUIC communications sent by the or intended for the terminal T1. No constraint is imposed by the. invention as to the operations performed by such a proxy function. This embodiment of the invention is applicable regardless of the location of the “Proxy QUIC” function in the communication network.
  • the “QUIC Proxy” can typically be configured on the terminal using, for example, the DHCP protocol, the PCO option (for “PDP Configuration Options”), etc.
  • the terminal can select one or more instance (s) of this function, or even use all the instances to establish communications in the network.
  • the terminal T1 builds the PCL list of candidate communications at 21 from the ACAL list according to the LIST step described above.
  • the PCL list thus constructed for the terminal T1 is ⁇ @ T11, PS11, @ T12, PD12 ⁇ , ..., ⁇ @Tln, PSln, @ T11, PD11 ⁇ .
  • the terminal T1 attempts to establish a QUIC communication for each of the elements of the PCL list, but this time via at least one “Proxy QUIC” function.
  • the terminal T1 sends to the proxy P a request for the establishment of a communication QUIC comprising the destination IP address @Tli. To do this, it encapsulates this establishment request (formatted according to a QUIC frame) in an IP packet whose destination address is that of the proxy P. On receipt of the packet by the proxy P, the latter extracts the QUIC frame. Then, it tries to route the call establishment request to the IP address @Tli. If it has a route to reach the @Tli address, it sends the packet on that route. If no route has been found, the proxy P responds to the terminal with an ICMP message to indicate that this IP address is not reachable. If the proxy P receives the call establishment request, it retransmits it to the terminal by encapsulating it in an IP packet.
  • this establishment request formatted according to a QUIC frame
  • Steps 222 to 224 described above remain unchanged.
  • step 22 of detecting the presence of a state function according to a second embodiment of the invention is now detailed.
  • a PCL list of candidate communications to be established on the network paths available at the level of the terminal equipment T1 was constructed.
  • the terminal selects at least one candidate communication CC from the PCL list. Note that it can select several or even all candidate communications from the PCL list.
  • this communication is established between an IP resource comprising the @ T11 address allocated by the access network Nil to the terminal T1 and an IP resource comprising the @ T2 address of the terminal T2.
  • the terminal T1 sends to the terminal T2, via the communication CE12, a message, called a mirror frame (for “Mirror”, in English).
  • This frame is intended to command the terminal T2 to send a response message according to the conditions specified in the fields of the mirror frame.
  • this is a new QUIC frame structure proposed by the invention.
  • This frame includes:
  • this field comprises the destination IP addresses of the candidate communications selected at 220 ′;
  • the remote terminal T2 will have to randomly generate a port number to be associated with each destination IP address;
  • an additional security key (or "token” or “Token”) to be included in the response message to be transmitted to the address or addresses of destination indicated.
  • FIG. 15 An example of a mirror frame is illustrated in figure 15.
  • the terminal T2 connected to the terminal T1 via the communication CE12 implements a method of processing a communication which comprises the following steps, illustrated by FIG. 14.
  • the terminal T2 receives at 300 the mirror frame transmitted by Tl via the CEI communication. In 301, it extracts from this frame the destination IP addresses that it contains, possibly associated with destination port numbers, as well as the security key. It is recalled that if the mirror frame does not contain a destination port number, the terminal T2 generates as many as there are destination addresses extracted, for example at random. In 302, the terminal T2 sends to each pair (destination IP address, destination port number) of the terminal T1 specified in the mirror frame, a TV frame called an empty frame because it does not transport application data, comprising only the key of security. Note that the terminal T2 does not need to establish a new QUIC communication with Tl. Indeed, as mentioned previously, a QUIC communication is independent of source and destination IP resources, but relies on a security association.
  • the “mirror” frame would give rise to new communications, which the terminal T1 should listen to and associate with the presence detection test in progress. .
  • the terminal T1 checks that it does understand the security key, then, if necessary, triggers the update in 223 ′ of the status ST of the corresponding CC candidate communication from its PCL list by setting it to the value “OKON”. Indeed, the fact of having received the TV frame on the path associated with the destination IP address of the terminal T1 proves that there is no state function on the path followed by the TV frame.
  • the terminal T1 triggers at 223 ′ a positioning of the status of the path associated with the value OKOFF.
  • the terminal T1 updates the status of the corresponding paths of the ACAL list, as previously described in relation to FIG. 4 .
  • a terminal T1 which uses a single communication CE12 established with a remote terminal T2 to control its different available addresses @ T11, @ T12, ... @ Tli, with i non-zero integer.
  • the terminal T1 sends a mirror frame listing the addresses @ T11, T12, ..., @Tli as destination IP addresses and a security key CS.
  • the remote terminal T2 sends an acknowledgment to T1 and then proceeds to send QUIC frames of the TV frame type comprising only the security key CS, to each of the IP addresses @ T11, @ T12, etc.
  • Tl On receipt of a data packet comprising such a frame TV, the latter checks whether the packet contains the security key CS entered in the mirror frame . If so, T1 updates its ACAL table to indicate that all the addresses have a STATUS parameter equal to “OKON”.
  • FIG. 17 illustrates the case where the data packets comprising the TV frames sent by T2 to the address @ T12 and @Tli are not received by T1 despite the prior acknowledgment of T2, due to the presence of stateful functions on the road.
  • T1 updates the statuses of the records in its PCL list, then those of its ACAL list to set the STATUS parameter associated with the @ T12 and @Tli addresses to "OKOFF", and the associated one at @ T11 at
  • the terminal T1 detects a new path. It is for example a VPN tunnel (“Virtual Private Network”, in English), established from a physical interface of the terminal T1 for which it already has a network path.
  • VPN tunnel Virtual Private Network
  • This detection triggers the implementation of the step MULT for discovering stateful functions on this path according to one of the embodiments which have just been described.
  • This new path is associated with an @ Tli + l address.
  • the terminal T1 requests the terminal T2 with which it is already connected by sending it a mirror frame comprising the address @ Tli + 1 and a security key CS via a communication already established with it.
  • a destination port number different from that used for the communication already established is indicated in the mirror frame.
  • the terminal updates the STATUS parameter of the path associated with the @ Tli + l address according to the result of the presence detection procedure.
  • the terminal T1 updates the statuses of the elements of the PCL then ACAL lists as previously described.
  • the terminal can implement the MULT2 embodiment or “Proxy” mode to force the sending of a message to its own IP address and to a port number different from that used to contact the proxy. :
  • the terminal T1 implements the MULT3 embodiment or “MIRROR” mode. In this case, it sends a "mirror" frame to a terminal T2 with which it is already in communication and having several IP addresses. This frame comprises a security key, the IP address of the terminal T1 and a destination port number different from that used by the terminal T1 to send the “mirror” frame as described in relation to FIGS. 15 to 17.
  • the remote terminal T2 Upon receipt of the message, the remote terminal T2 sends a response message or TV frame to the terminal address and the destination port number indicated in the mirror frame.
  • the latter checks whether the packet contains the security key CS entered in the mirror frame. If so, T1 concludes that there is no state function on the path and updates the STATUS status of this path by setting it to “OKON”.
  • the embodiment MULT1 is applicable to a single interface terminal, there is a risk that the data packets sent in the network RC by the terminal T1 are filtered on their return by the access network. Indeed, these packets sent with an address of this access network, once relayed by the intermediate nodes imposed by the routing at the source, will probably be treated as an attempt to spoof the IP address of the terminal and will therefore be blocked. .
  • the management method implements an optional step 225 of determining a KA_TIMER parameter representative of a lifetime of an input instantiated by the function to states present on the way. It is assumed that the method comprises a preliminary step (not shown) of extracting the elements of the ACAL list associated with an OKOFF status and a test step to verify whether at least one path has been extracted.
  • the terminal T1 chooses another address from the ACAL list, for example @ T11, whose status is on the contrary equal to “OKON”.
  • the terminal T1 then transmits data via the established communication, at a succession of temporal instants, two consecutive instants of said succession of instants being separated by a temporal interval, initially set at T0 and doubled at each new transmission of data, both that communication is not lost or cut off.
  • communication is lost when the parameter KA_TIMER reaches the value KA_TIMER_LOSS equal to 960s.
  • this evaluated lifetime is used to more effectively manage the communications from the terminal T1 to the communications network RC.
  • it is used to configure the “keepalive” mechanism and the frequency of the messages sent to maintain the entry of a communication in a state function table.
  • the invention is not limited to this example of an implementation of the evaluation of the lifespan, even if it offers a good compromise between the performance of a lifespan mechanism and the risk of cutting. of communication.
  • FIGS. 19A, 19B and 20 A detailed description will now be made in relation to FIGS. 19A, 19B and 20 of an embodiment of step 23 of triggering an action for managing at least one communication involving a network path of the terminal T1.
  • the terminal T1 can advantageously use the information stored in the ACAL list to select the one on which it is more efficient to establish an outgoing communication. For example, the terminal T1 can select the path which does not involve a stateful function or alternatively, a path which comprises a stateful function associated with the highest possible KA_TIMER lifetime. Indeed, the lifetime of an input maintained by a stateful function directly impacts the frequency of sending messages for keeping a “keepalive” mechanism alive and therefore the energy consumption of the terminal.
  • the terminal T1 To establish a QUIC communication with a remote terminal T3, the terminal T1 includes in a communication message, such as for example the request for establishment of the communication or any other message, a new control frame called KEEPALIVE_CONTROL of a mechanism for keeping an input maintained by a stateful function alive. This frame is used to transmit to the terminal T3 information for the configuration of the mechanism for keeping an entry maintained by a state function intended to be activated on one or more paths connecting the terminal T1 to the network.
  • a communication message such as for example the request for establishment of the communication or any other message.
  • KEEPALIVE_CONTROL a new control frame called KEEPALIVE_CONTROL of a mechanism for keeping an input maintained by a stateful function alive.
  • This frame is used to transmit to the terminal T3 information for the configuration of the mechanism for keeping an entry maintained by a state function intended to be activated on one or more paths connecting the terminal T1 to the network.
  • FIG. 19A Examples of the format of such a message are illustrated by Figures 19A and 19B.
  • a simple TCS format intended to be used by a terminal which has a single network interface and in particular a single network path for accessing the communication network RC. It can also be used to characterize a single source address used by the terminal T1 for sending a QUIC data packet.
  • FIG. 19B presents a second TCM format of a control message of a keep alive mechanism intended for a multi-interface terminal, that is to say provided with several paths for accessing the RC network.
  • the frame of this control message comprises a field representative of an element of the IP address, prefix or IP address identifier type, a STATUS status field and a KA_TIMER lifetime field.
  • the values of the STATUS and KA_TIMER parameters are extracted from the ACAL table of the Tl terminal.
  • the KA_TIMER field is optional. Note that if this field is absent for an element with a STATUS equal to “OKON”, this means that the procedure for keeping the inputs of a state function alive can be safely disabled.
  • One or more KEEPALIVE_CONTROL control frames can be sent to the same remote terminal. For example, a control frame is sent per available path at the terminal T1 or else a single control frame includes all the information relating to all of the available paths.
  • the remote terminal T3 on receipt of the frame by the remote terminal T3, the latter extracts the information it contains and saves them in a table called ACAL_PEER. It will be understood that this ACAL_PEER table is an at least partial copy of that maintained by Tl.
  • the remote terminal T3 advantageously uses the information in this table to decide on which path to establish a communication with Tl.
  • the remote terminal T3 must in turn determine the value of the KA_TIMER parameter representative of a lifetime of an input instantiated by the stateful function present on the path between the IP address @ T11 of Tl and its own paths in the access networks N31, N32, ..., N3j with j non-zero integer, as previously described in relation to FIG. 15. Then, it transmits them to the terminals with which it wishes to communicate via the communication network, such as for example the terminal Tl.
  • the terminal T1 can also decide to add one or more new paths to a communication established with the terminal T3 as a function of the relative values of the parameters STATUS and KA_TIMER obtained for a new path compared to those of the paths already used. For example, a terminal can decide to add a new path to the communication even if it does not receive data from the remote terminal T3 via this path.
  • KA_TIMER Lical
  • PEER KA_TIMER
  • the terminals must choose the smaller value between the two.
  • each terminal sends KEEPALIVE_CONTROL control frames to the other.
  • each terminal has its own ACAL table and that of the remote ACAL terminal (Peer).
  • the T3 terminal decides to add a new path via the IP address @ T3i of (N3 and the IP address @ T11 of Nil) to the communication.
  • the terminal T1 decides to add the path @Tli of Nli and @ T31 of N31 to the communication.
  • the two terminals Due to the fact that for the @ T11 address of Nil and the @ T31 address of N31, the status is set to "OKON" with no associated KA_TIMER lifetime value, the two terminals know that no stateful function has been detected on these paths and decide not to activate the “keepalive” mechanism for keeping the inputs of a stateful function alive for the path (Nil, N31).
  • values of KA_TIMER being entered, they activate the optimization for the other paths according to the instructions described in their ACAL tables. In particular, they configure an optimal transmission frequency of "keepalive" messages according to the KA_TIMER lifetime entered.
  • the two terminals can each implement the invention which has just been described.
  • the terminals can send new KEEPALIVE_CONTROL control frames whenever necessary, as for example in the event of modification of network parameters, such as an attachment to a new access network, obtaining a new IP address, etc.
  • the hardware structure of a device 100 for managing at least one communication of terminal equipment in a communication network said terminal equipment being able to access said communication network via at least two paths, one said path being associated to an IP resource, comprising at least an IP address and a port number.
  • the device 100 comprises a module for detecting a presence, on at least one path making it possible to reach via said communication network said terminal equipment on an IP address of said terminal equipment called second IP address of at least one.
  • stateful function configured to maintain in a table a state associated with a communication on said path for a determined lifetime, comprising the transmission in the communication network of a first message from at least a first IP resource of said terminal equipment, said first IP resource comprising a first IP address and a first port number to a second IP resource of said terminal equipment, comprising said second IP address and a second port number, and the decision of the presence of at least one stateful function on said at least one path as a function of data received by the second IP resource in response to the transmission of the first message, and a trigger module the execution of an action for managing a communication of the terminal equipment on said at least one path making it possible to reach via said communication network said terminal equipment on said second IP address, as a function of said detection.
  • the device 100 comprises a module for obtaining a list of paths connecting the terminal to the network via an IP address of this terminal, called the second IP address, and a module for obtaining a list of candidate communications between a first resource comprising a first IP address and a first port number and a second IP resource comprising the second IP address and a second port number.
  • the device 100 also comprises a module for determining the lifetime associated with a state of a communication established on said path by said at least one state function detected on the path.
  • the device 100 further comprises a module for updating a status representative of the presence or the absence of a state function on said path as a function of the decision, where appropriate of the lifetime. associated with a state of the communication by the state function detected and the module for triggering a management action is configured to trigger said action according to the status and / or the associated lifetime.
  • module can correspond just as well to a software component as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subroutines or otherwise. more general to any element of a program capable of implementing a function or a set of functions.
  • such a communication management device 100 comprises a random access memory 103 (for example a RAM memory), a processing unit 102 equipped for example with a processor, and controlled by a computer program Pgl, representative the module for detecting the presence of a stateful function on said at least one path and the module for triggering at least one management action on said at least one path, and optionally modules for obtaining the list of paths , obtaining the list of candidate communications, updating a status and determining a lifetime, stored in a read only memory 101 (for example a ROM memory or a hard disk).
  • a read only memory 101 for example a ROM memory or a hard disk.
  • the code instructions of the computer program are for example loaded into the random access memory 103 before being executed by the processor of the processing unit 102.
  • the random access memory 103 notably contains the path table ACAL. , the list of candidate communications PCL and stores for each path the associated KA_TIMER status and, if applicable, lifetime parameters.
  • the processor of the processing unit 102 controls the obtaining of the list of paths, the detection of the presence of stateful functions on the listed paths and the triggering of a communication management action on the listed paths, in accordance with the logic diagram of FIG. 2.
  • it also stores the ACAL-PEER path tables transmitted by other terminals.
  • FIG. 21 only illustrates one particular way, among several possible, of implementing the device for managing a communication 100, so that it performs the steps of the method for managing a communication of a terminal equipment item as detailed below. above, in relation to FIG. 2 in its various embodiments.
  • these steps can be carried out either on a reprogrammable computing machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated computing machine (for example a set of logic gates such as an FPGA or ASIC, or any other hardware module).
  • a reprogrammable computing machine a PC computer, a DSP processor or a microcontroller
  • a program comprising a sequence of instructions
  • a dedicated computing machine for example a set of logic gates such as an FPGA or ASIC, or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) can be stored in a removable storage medium (such as for example a floppy disk, CD-ROM or DVD-ROM) or not, this storage medium being partially or totally readable by a computer or a processor.
  • a removable storage medium such as for example a floppy disk, CD-ROM or DVD-ROM
  • a device for managing a communication 100 integrated into terminal equipment Tl 10 such as for example a mobile telephone of the smart phone type (for “smartphone”, in English ), a PC-type computer (for “Personal Computer” in English) or a tablet, but it can also, as described in relation to FIG. 12, be embedded in any type of CPE access equipment to a computer.
  • communication network such as a home automation gateway, provided that it has access to a wide area network, such as for example the Internet network.
  • a device 200 for processing a communication established between a first terminal equipment item and a second terminal equipment item via a communication network comprising at least one reception module, from a first IP resource of a first terminal equipment, a message comprising at least one command to send a response to at least a second IP resource of the first terminal equipment, distinct from the first , and inserting security information in the response, a module for extracting said at least one second IP resource and said security information and a transmission module intended for said at least one second address d 'a response or TV frame comprising said security information.
  • the device 200 further comprises a module for storing an ACAL_PEER path table received from the first terminal equipment item.
  • module can correspond just as well to a software component as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more programs or subroutines of a computer or computer. more generally to any element of a program capable of implementing a function or a set of functions.
  • such device equipment 200 comprises a random access memory 203 (for example a RAM memory), a processing unit 202 equipped for example with a processor, and controlled by a computer program Pg2, representative of the reception modules, extraction and transmission, stored in a read only memory 201 (for example a ROM memory or a hard disk).
  • a random access memory 203 for example a RAM memory
  • a processing unit 202 equipped for example with a processor
  • a computer program Pg2 representative of the reception modules, extraction and transmission
  • a read only memory 201 for example a ROM memory or a hard disk.
  • the code instructions of the computer program are for example loaded into the random access memory 203 before being executed by the processor of the processing unit 32.
  • the random access memory 203 notably contains the second IP resources and the security information extracted from the control message received from the first terminal equipment. It can also include the ACAL_PEER path table or tables transmitted by the first terminated device and possibly other terminals.
  • the processor of the processing unit 202 controls the reception of the message, the extraction of at least a second IP resource from the first terminal equipment and of security information included in said message, the transmission of a response comprising the security information intended for said at least one second IP resource of the first terminal equipment, in accordance with the flowchart of FIG. 14.
  • Fig. 22 only illustrates one particular way, among several possible, of implementing the processing device 200, so that it carries out the steps of the method of processing a communication detailed above, in relation to FIG. 14. Indeed, these steps can be performed indifferently on a reprogrammable computing machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated computing machine (for example a set of logic gates such as a FPGA or ASIC, or any other hardware module).
  • a reprogrammable computing machine a PC computer, a DSP processor or a microcontroller
  • a program comprising a sequence of instructions
  • a dedicated computing machine for example a set of logic gates such as a FPGA or ASIC, or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) can be stored in a removable storage medium (such as whether for example a floppy disk, a CD-ROM or a DVD-ROM) or not, this storage medium being partially or totally readable by a computer or a processor.
  • Tl such as for example a mobile telephone of the smart telephone type (for “smartphone”, in English), a PC-type computer (for “Personal computer” in English) or a tablet, but it can also, as described in relation to FIG. 12, be embedded in any equipment CPE type access to a communication network, such as a residential gateway, provided that it has access to a network.
  • the invention which has just been described proposes to dynamically detect the presence of stateful functions in a communication network on access paths from a terminal to this network. This presence detection is used to manage the communications accordingly and thus improve their quality while optimizing the energy resources put into play in particular by the terminal equipment.
  • the invention allows in particular:

Landscapes

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

Abstract

L'invention concerne un procédé de gestion d'au moins une communication selon un protocole de transport d'un équipement terminal dans un réseau de communication, ledit équipement terminal étant apte à accéder audit réseau de communication via au moins une ressource IP, chaque ressource IP comprenant une adresse IP et un numéro de port, comprenant : - la détection (22) d'une présence, sur au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur une adresse IP dudit équipement terminal dite deuxième adresse IP d'au moins une fonction à états configurée pour maintenir dans une table un état associé à une communication sur ledit chemin pendant une durée de vie déterminée, comprenant l'émission dans le réseau de communication d'un premier message depuis au moins une première ressource IP dudit équipement terminal, ladite première ressource IP comprenant une première adresse IP et un premier numéro de port vers une deuxième ressource IP dudit équipement terminal, comprenant ladite deuxième adresse IP et un deuxième numéro de port, et la décision de présence d'au moins une fonction à états sur ledit au moins un chemin en fonction de données reçues par la deuxième ressource IP en réponse à l'émission du premier message; et - le déclenchement (23) d'une action de gestion d'une communication de l'équipement terminal sur ledit au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur ladite deuxième adresse IP, en fonction de ladite détection.

Description

DESCRIPTION
TITRE : Procédé de gestion d'au moins une communication d'un équipement terminal dans un réseau de communication, procédés de traitement d'une communication établie avec un équipement terminal dans un réseau de communication, dispositifs, équipement terminal, équipement proxy et programmes d'ordinateur correspondants
Domaine de l'invention
Le domaine de l'invention est celui d'un réseau de communication et plus particulièrement de la gestion des communications d'un équipement terminal dans un tel réseau.
L’invention trouve notamment une application dans les réseaux de communication mettant en oeuvre des services IP à valeur ajoutée.
Art antérieur et ses inconvénients
Le protocole de communication, appelé QUIC, a été conçu pour réduire les temps de latence observés lors de communications reposant sur le protocole de transport TCP (pour « Transport Control Protocol », en anglais) et notamment le temps d'établissement d'une communication entre un premier équipement terminal, dit client ou terminal émetteur ou encore simplement terminal, et un deuxième équipement terminal, dit serveur ou terminal récepteur, via le réseau de communication. C'est pour cette raison que le protocole QUIC s'appuie sur le protocole de transport UDP (pour « User Datagram Protocol », en anglais). En effet, le protocole de transport UDP, contrairement au protocole TCP, n'utilise pas de mécanisme de signalisation de type poignée de main en trois étapes (pour « 3-way handshake », en anglais), afin que les terminaux puissent notamment adapter la fréquence de transmission des données en fonction des conditions de bande passante du réseau par exemple. Le protocole QUIC permet en particulier de transmettre, sous certaines conditions, des données utiles dès l'envoi du premier paquet d'une communication, sans que le client QUIC doive attendre la réponse de son correspondant. Les temps de latence et de signalisation entre les clients sont ainsi réduits.
Afin de supporter tout changement d'adresse IP sans avoir à clôturer une communication QUIC en cours, le protocole de transport QUIC ne s'appuie pas sur les adresses transport, et plus particulièrement sur le quadruplet {adresse IP source, numéro de port source, adresse IP destination, numéro de port destination} mais sur un identifiant de connexion appelé CID (pour « Connection Identifier ») La spécification QUIC définit deux types de CID : Destination CID et Source CID.
Actuellement, le protocole QUIC supporte un mécanisme de migration de connexions (pour « Connection migration », en anglais) qui permet de maintenir une communication QUIC en cas de modification d'une des adresses (ou numéros de port) des participants (incluant les changements liés à l'utilisation d'adresses allouées par des équipements intermédiaires de traduction d'adresse ou NAT (pour « Network Address Translation », en anglais). La réception d'un message au titre d'une communication en cours présentant une nouvelle adresse source est une indication de migration de connexion. Ainsi, une migration de connexion consiste à passer d'un quadruplet {adresse source, numéro de port source, adresse destination, numéro de port destination} à un autre.
Cependant, la présence de fonctions à états telles que les fonctions NAT, pare-feu (ou « firewall », en anglais) ou proxy, sur un chemin du réseau utilisé par la communication QUIC constitue une source de problèmes de nature à compromettre la qualité de la communication. En effet, de façon connue, de telles fonctions à états sont généralement hébergées par des équipements intermédiaires, et maintiennent une table comprenant des entrées associant en particulier une adresse source interne et une adresse source externe pour un paquet de données sortant. Elles utilisent cette table pour filtrer les paquets entrants en rejetant ceux qui ne correspondent pas à une entrée valide de la table. Une entrée est généralement maintenue pendant une durée, dite durée de vie prédéterminée, au-delà de laquelle, en l'absence de nouveau paquet de données sortant ou de message de contrôle adéquat pour étendre la durée de vie, elle est invalidée et supprimée de la table. Cette durée de vie peut être courte, de l'ordre de la seconde.
Pour pallier cet inconvénient, les protocoles de communication, QUIC inclus, utilisent un mécanisme de « maintien en vie » (« keepalive », en anglais) d'une communication qui permet, en particulier, de vérifier que le lien sur lequel la communication est établie est toujours actif ou pour éviter que ce lien ne soit rompu. Dans le cas où la communication est établie sur un lien qui comporte un équipement intermédiaire de type NAT par exemple, un tel mécanisme consiste pour un équipement terminal, à envoyer à fréquence régulière un message de signalisation à l'équipement terminal distant, de sorte que les entrées des tables maintenues par ledit équipement intermédiaire ne soient pas supprimées d'une manière inopinée, au risque de rompre la communication entre les terminaux alors que l'échange des données n'est pas encore terminé. Par exemple, le protocole IPsec utilise un message appelé « NAT-Keepalive » dont la fréquence d'envoi par défaut est 20 secondes.
Aujourd'hui, ce mécanisme « keepalive », caractéristique de quelques protocoles de communication dont le protocole QUIC, est appliqué indifféremment par un équipement terminal à tous les chemins dont dispose cet équipement terminal pour accéder au réseau de communications, qu'une fonction à états soit présente ou non sur le chemin.
Or, ce mécanisme est coûteux en ressources, aussi bien pour le réseau qu'il surcharge que pour l'équipement terminal, dont il sollicite les ressources de calcul, voire augmente la consommation d'énergie dans le cas d'un équipement terminal fonctionnant sur batterie, tel qu'un terminal mobile.
A cet égard, la désactivation de ce mécanisme « keepalive » permet de multiplier par 5 ou 6 la durée de fonctionnement d'un équipement terminal sur batterie, tel qu'un terminal mobile par exemple. On notera aussi que la réduction de la fréquence d'envoi de messages « keepalive » contribue significativement à augmenter la durée de vie de la batterie de l'équipement terminal. En effet, l'équipement terminal embarque potentiellement plusieurs applications, chacune émettant ses propres messages « keepalive ». Le gain potentiel est d'autant plus important que l'envoi des messages « keepalive » requis par application embarquée dans l'équipement terminal est plus réduit.
Il existe donc un besoin d’une technique permettant d'éviter d'activer inutilement un mécanisme de maintien en vie ou d'optimiser son utilisation (par exemple en optimisant la fréquence d'envoi des messages relatifs à l'activation du mécanisme de maintien en vie), notamment lorsque ce mécanisme est utilisé pour maintenir les entrées caractéristiques d'une communication établie sur un chemin comportant au moins un équipement intermédiaire, dans une table prévue à cet effet et gérée par cet équipement intermédiaire.
Exposé de l’invention
L’invention répond à ce besoin en proposant un procédé de gestion d'au moins une communication établie sur un protocole de transport d'un équipement terminal dans un réseau de communication, ledit équipement terminal étant apte à accéder audit réseau de communication via au moins une ressource IP, chaque ressource IP comprenant une adresse IP et un numéro de port, comprenant :
la détection d'une présence, sur au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur une adresse IP dudit équipement terminal dite deuxième adresse IP d'au moins une fonction à états configurée pour maintenir dans une table un état associé à une communication sur ledit chemin pendant une durée de vie prédéterminée, comprenant l'émission dans le réseau de communication d'un premier message depuis au moins une première ressource IP dudit équipement terminal, ladite première ressource IP comprenant une première adresse IP et un premier numéro de port vers une deuxième ressource IP dudit équipement terminal, comprenant ladite deuxième adresse IP et un deuxième numéro de port, et la décision de la présence d'au moins une fonction à états sur ledit au moins un chemin en fonction de données reçues par la deuxième ressource IP en réponse à l'émission du premier message; et
le déclenchement d'une action de gestion d'une communication de l'équipement terminal sur ledit au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur ladite deuxième adresse IP, en fonction de ladite détection.
L'invention concerne la gestion des communications d'un équipement terminal dans un réseau de communication comprenant des équipements intermédiaires qui embarquent des fonctions à état, tels que des NAT ou des pare-feux. Ces fonctions à états ne laissent passer les paquets de données échangés par les équipements terminaux via la communication que pour ceux qui correspondent à une entrée valide de leur table d'états, une telle validité n'étant garantie que pendant une durée déterminée. Il en résulte que la gestion des communications d'un équipement terminal établies sur un tel réseau peut être compliquée. Pour améliorer la situation, l'invention s'appuie sur une approche tout à fait nouvelle et inventive, qui consiste à découvrir la présence de fonctions à états sur les chemins reliant entre elles les différentes ressources dont l'équipement terminal dispose pour accéder au réseau de communications et sur la prise en compte du résultat de cette découverte pour décider des actions de gestion des communications à déclencher. Un principe de l'invention est d'émettre un message depuis au moins une première ressource IP de l'équipement terminal vers une deuxième ressource IP de cet équipement terminal, et de décider de la présence d'une fonction à états sur le chemin reliant la première et la deuxième ressources en fonction de données reçues par l'équipement terminal sur sa deuxième ressource IP, suite à l'émission du message. Autrement dit, l'invention propose de découvrir la présence d'éventuelles fonctions à états en s'appuyant sur les ressources IP locales de l'équipement terminal. La détection d'une fonction à états sur l'un des chemins permettant de joindre la deuxième adresse IP de l'équipement terminal est prise en compte pour la gestion d'une communication impliquant cette deuxième adresse IP de l'équipement terminal.
L'invention s'applique aussi lorsque l'équipement terminal ne dispose que d'une seule adresse IP pour accéder au réseau (les première et deuxième ressources IP sont alors caractérisées par des adresses IP identiques mais des numéros de port différents).
L'invention est adaptée à tout type de protocole de transport, en particulier le protocole QUIC. Selon un aspect de l'invention, la présence d'au moins une fonction à états sur le chemin est décidée lorsque les données reçues comprennent un message d'erreur ou lorsqu'aucune donnée n'est reçue par la deuxième ressource IP en réponse à l'émission du premier message par au moins unedite première ressource IP.
Selon un autre aspect de l'invention, le premier message comprend une requête d'établissement d'une communication entre ladite au moins une première ressource IP et la deuxième ressource IP de l'équipement terminal et une décision d'absence de fonction à états sur le chemin reliant ladite au moins une première ressource IP à la deuxième ressource IP via ledit réseau est prise lorsque les données reçues par la deuxième ressource IP de l'équipement terminal comprennent le premier message.
Un principe de l'invention est d'exploiter les différentes ressources d'accès au réseau dont dispose l'équipement terminal pour découvrir les fonctions à états présentes sur les chemins reliant ces ressources. Pour pouvoir détecter la présence d'une fonction à états sur un chemin associé à une deuxième adresse IP de l'équipement terminal, on établit par exemple de nouvelles communications depuis des ressources comprenant des adresses IP de cet équipement terminal vers une ressource comprenant cette deuxième adresse IP. Ces nouvelles communications ne correspondent à aucune entrée valide dans les tables maintenues par d'éventuelles fonctions à états présentes sur le chemin des messages échangés.
Selon encore un autre aspect, l'étape de détection comprend le masquage d'informations de routage associées à ladite deuxième ressource IP et contenues dans ladite requête d'établissement de ladite communication, préalablement à son émission.
Un avantage est d'émuler un équipement terminal ne disposant que d'une seule interface. Ainsi la deuxième ressource IP n'est pas reconnue comme une adresse locale de l'équipement terminal émetteur et la requête de communication est envoyée via l'interface de sortie de l'équipement terminal.
Alternativement, l'étape de détection comprend, préalablement à l'émission de la requête d'établissement de la communication, l'enregistrement d'une information d'identification d'au moins un équipement de routage du réseau de communication associé à ladite au moins une première ressource IP.
Une autre option pour forcer l'émission de la requête de communication dans le réseau est le routage à la source, c'est-à-dire la désignation explicite d'un équipement routeur du réseau de communication en charge d'acheminer les paquets de données émis par le premier équipement terminal sur le chemin correspondant à la première ressource IP.
Selon un autre aspect de l'invention, une communication étant établie entre ladite au moins une première ressource IP de l'équipement terminal et une ressource IP d'un deuxième équipement terminal, ledit premier message est émis via ladite communication à destination de ladite ressource IP du deuxième équipement terminal, ledit premier message comprend au moins une commande d'émission d'une réponse à destination de la deuxième ressource IP et une commande d'insertion d'une information de sécurité dans ladite au moins une réponse et une décision d'absence de fonction à états sur le chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur la deuxième ressource IP est prise lorsque les données reçues sur ladite deuxième ressource IP de l'équipement terminal (Tl) comprennent ladite réponse. Un avantage de ce mode de réalisation est qu'il exploite une communication déjà établie par l'équipement terminal depuis l'un de ses accès au réseau, pour tester ses autres accès réseau. Selon encore un autre aspect de l'invention, lorsque la présence d'au moins une fonction à états a été détectée sur ledit au moins un chemin, le procédé comprend la détermination d'une période temporelle d'émission d'un message de maintien en vie d'un état d'une communication établie sur ledit au moins un chemin par ladite au moins une fonction à états, le stockage de la période déterminée et la prise en compte de la période déterminée dans la décision d'une action de gestion sur une communication via ledit chemin.
Un avantage de connaître cette période est de permettre d'optimiser la gestion des communications. On pourra par exemple choisir la communication sur le chemin dont la fonction à états a la période la plus élevée et activer le mécanisme de maintien en vie en configurant un envoi de messages selon ladite période, pour limiter la consommation d'énergie de l'équipement terminal.
Selon encore un autre aspect de l'invention, ladite détermination comprend :
l'établissement d'une communication sur ledit chemin associée à la deuxième adresse IP, en provenance d'une ressource IP comprenant une adresse IP de l'équipement terminal, distincte de la deuxième, associée à un chemin permettant de joindre ledit équipement terminal via ledit réseau, pour lequel aucune présence de fonction à états n'a été détectée ;
l'émission de données via la communication établie, à une succession d'instants temporels, deux instants consécutifs de ladite succession d'instants étant séparés par un intervalle temporel, ledit intervalle ayant une valeur courante initialisée à zéro et doublée à chaque nouvelle émission de données, tant que la communication n'est pas perdue ; et
la détermination d'un paramètre représentatif de ladite période temporelle d'émission inférieure à ladite valeur courante.
Par exemple la valeur du paramètre choisie est égale à la moitié de la valeur courante de l'intervalle temporel. Un avantage de cette détermination est qu'elle permet d'obtenir d'une manière simple une fréquence optimale d'émission de messages de maintien en vie d'une fonction à états qui préserve les ressources énergétiques.
Selon un autre aspect de l'invention, le procédé comprend la mise à jour d'un statut représentatif d'une configuration d'un mécanisme de maintien en vie d'une fonction à états, ledit statut étant associé audit au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur l'adresse IP de la deuxième ressource IP de l'équipement terminal en fonction de ladite au moins une décision prise pour ledit au moins un chemin.
Par exemple, le statut est positionné à une valeur « optimisé » lorsqu'aucune fonction à états n'a été détectée sur le chemin, puisqu'il n'est pas nécessaire dans ce cas d'activer le mécanisme de maintien en vie des tables, ou suite à la détermination d'une durée de vie associée à la fonction à états détectée. Il est au contraire positionné à une valeur « non optimisé » sinon, notamment lorsqu'une fonction à états a été détectée, pour indiquer que le mécanisme de maintien en vie des tables des fonctions à états doit être activé et qu'il faut optimiser sa configuration. Un avantage d'associer un tel statut à une ressource IP de l'équipement terminal est de faciliter la gestion des communications via le réseau et notamment de permettre à l'équipement terminal de mettre en place des communications plus économes en ressources.
Selon encore un autre aspect de l'invention, l'action de gestion déclenchée comprend l'établissement d'une communication via ledit chemin de l'équipement terminal sans activer de mécanisme de maintien en vie d'un état associé à la communication lorsqu'il n'a pas été détecté de fonction à états sur ledit chemin et l'établissement de la communication via ledit chemin en activant un mécanisme de maintien en vie dudit état associé à la communication lorsqu'une fonction à états a été détectée sur ledit chemin. Ainsi, avec l'invention, on peut activer le mécanisme de maintien en vie d'un état associé à une communication seulement lorsque c'est nécessaire, c'est-à-dire lorsqu'une fonction à états a été détectée sur un chemin impliqué dans la communication, ce qui permet d'économiser les ressources des terminaux et du réseau.
Selon un autre aspect de l'invention, lors de l'établissement d'une communication avec un autre équipement terminal depuis l'adresse IP de la deuxième ressource IP de l'équipement terminal, l'action de gestion déclenchée comprend l'émission dans la requête d'établissement de ladite communication ou au cours de ladite communication du statut dudit au moins un chemin associé à ladite adresse IP et/ou de la période temporelle déterminée.
Ainsi, selon l'invention, un équipement terminal comprend sa propre table de chemins (typiquement identifiés par des adresses IP locales de l'équipement terminal) et une copie de celle des autres équipements terminaux avec lesquels il communique (typiquement identifiés par des adresses IP de l'équipement terminal distant). On comprend que les statuts et durées de vie associées aux chemins sur lesquels la communication est établie peuvent être différents. Leur connaissance réciproque permet aux terminaux de négocier entre eux le meilleur choix de chemin et de durée de vie à appliquer à un mécanisme de maintien en vie des états maintenus par les fonctions à états éventuellement présentes sur le chemin de la communication. Ce faisant, l'optimisation est plus efficace car elle est mise en oeuvre par tous les participants à une communication.
L'invention concerne également un produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé de gestion d'au moins une communication tel que décrit précédemment, lorsqu'il est exécuté par un processeur.
L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de gestion selon l'invention tel que décrit ci-dessus.
Un tel support d’enregistrement peut être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple une clé USB ou un disque dur.
D’autre part, un tel support d’enregistrement 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, de sorte que le programme d'ordinateur qu'il contient est exécutable à distance. Le programme selon l’invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.
Alternativement, le support d’enregistrement 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 du procédé de gestion précité.
L’invention concerne également un dispositif de gestion d'au moins une communication d'un équipement terminal dans un réseau de communication, ledit équipement terminal étant apte à accéder audit réseau de communication via au moins une ressource IP, caractérisé en ce qu'il est configuré pour :
détecter une présence, sur au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur une adresse IP dudit équipement terminal dite deuxième adresse IP d'au moins une fonction à états configurée pour maintenir dans une table un état associé à une communication sur ledit chemin pendant une durée de vie déterminée, comprenant l'émission dans le réseau de communication d'un premier message depuis au moins une première ressource IP dudit équipement terminal, ladite première ressource IP comprenant une première adresse IP et un premier numéro de port vers une deuxième ressource IP dudit équipement terminal, comprenant ladite deuxième adresse IP et un deuxième numéro de port, et la décision de présence d'au moins une fonction à états sur ledit au moins un chemin en fonction de données reçues par la deuxième ressource IP en réponse à l'émission du premier message; et déclencher une action de gestion d'une communication de l'équipement terminal sur ledit au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur ladite deuxième adresse IP, en fonction de ladite détection.
Plus généralement, un tel dispositif est apte à mettre en oeuvre un procédé de gestion d'au moins une communication tel que décrit précédemment. Avantageusement, ledit dispositif est intégré dans un équipement terminal apte à accéder à un réseau de communication depuis au moins une ressource IP, comprenant une adresse IP et un numéro de port.
Le dispositif peut aussi être intégré dans équipement proxy d'un réseau de communication, apte à relayer les données émises par un équipement terminal connecté audit réseau.
L'équipement terminal, le dispositif de gestion d'au moins une communication et le programme d’ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé de gestion selon la présente invention.
Corrélativement, l'invention concerne aussi un procédé de traitement d'une communication établie sur un protocole de transport entre un premier équipement terminal et un deuxième équipement terminal dans un réseau de communication via au moins une ressource IP du premier équipement terminal, chaque ressource IP comprenant une adresse IP et un numéro de port, comprenant :
la réception, en provenance de ladite première ressource IP d'un message comprenant l'adresse IP, dite première adresse IP et le numéro de port, dit premier numéro de port, de ladite première ressource IP ledit message comprenant une commande d'émission d'une réponse à destination d'au moins une deuxième ressource IP du premier équipement terminal, distincte de la première et comprenant une deuxième adresse IP et un deuxième numéro de port, et une commande d'insertion d'une information de sécurité dans la réponse ;
l'extraction de ladite au moins une deuxième ressource IP et de ladite information de sécurité de la dite commande ;
l'émission à destination de ladite au moins une deuxième adresse IP et dudit deuxième numéro de port d'au moins une réponse comprenant ladite information de sécurité.
Cette réponse du deuxième équipement terminal au message émis par le premier équipement terminal est exploitée par le procédé de gestion d'au moins une communication mis en oeuvre par ledit premier équipement terminal pour détecter la présence d'une fonction à états sur le chemin associé à la deuxième adresse IP. Avantageusement, un message d'acquittement est transmis au premier équipement terminal. Ledit premier équipement terminal reçoit ainsi la confirmation que le deuxième équipement terminal a bien reçu sa commande. De ce fait, s'il ne reçoit pas la réponse comprenant l'information de sécurité, le premier équipement terminal pourra en déduire la présence d'une fonction à états sur le chemin testé.
Corrélativement, l'invention concerne encore un procédé de traitement d'une communication sur un protocole de transport entre un premier équipement terminal et un deuxième équipement terminal dans un réseau de communication via au moins une ressource IP du premier équipement terminal, chaque ressource IP comprenant une adresse IP et un numéro de port, caractérisé en ce qu'il comprend :
la réception sur une ressource IP du deuxième équipement terminal, dite ressource IP destination, d'un message relatif à une communication établie ou à établir en provenance d'une ressource IP du premier équipement terminal, dite ressource IP source, ledit message comprenant un statut représentatif d'une configuration d'un mécanisme de maintien en vie d'une entrée d'une table maintenue par une fonction à états, ladite entrée associant un état à une communication sur un chemin permettant de joindre via ledit réseau de communication ledit premier équipement terminal sur l'adresse IP de la ressource IP source pendant une durée de vie prédéterminée, ledit statut étant associé à ladite adresse IP, et une période temporelle représentative d'une fréquence d'émission d'un message de maintien en vie d'un état de la communication ;
l'ajustement dudit statut et de ladite période en fonction de valeurs de statut et de période stockées en mémoire en association avec ladite adresse IP destination ;
l'émission d'une réponse comprenant les valeurs ajustées.
Ainsi, avec l'invention, les deux équipements terminaux négocient l'activation/désactivation du mécanisme « keepalive » et la fréquence optimale d'émission des messages de maintien en vie des états.
L'invention concerne également un produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé de traitement d'une communication tel que décrit précédemment, lorsqu'il est exécuté par un processeur.
L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de traitement selon l'invention tel que décrit ci-dessus.
Un tel support d’enregistrement peut être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple une clé USB ou un disque dur.
D’autre part, un tel support d’enregistrement 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, de sorte que le programme d'ordinateur qu'il contient est exécutable à distance. Le programme selon l’invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.
Alternativement, le support d’enregistrement 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 du procédé de gestion précité. L'invention concerne également un dispositif de traitement d'une communication entre un premier équipement terminal et un deuxième équipement terminal via un réseau de communication sur un protocole de transport, caractérisé en ce qu'il est configuré pour mettre en oeuvre un procédé de traitement d'une communication précité.
Avantageusement, ledit dispositif est intégré dans un équipement terminal apte à accéder à un réseau de communication depuis au moins une ressource IP, comprenant une adresse IP et un numéro de port. Il peut aussi être intégré dans l'équipement proxy précité.
L'équipement terminal, le dispositif de traitement d'au moins une communication et le programme d’ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé de traitement selon la présente invention.
L'invention concerne enfin un équipement nœud d'un réseau de communication apte à recevoir sur au moins une ressource IP comprenant une adresse IP et un numéro de port, des données d'une communication entre une ressource IP, dite ressource IP source, d'un premier équipement terminal et une ressource IP d'un deuxième équipement terminal, dite ressource IP destination, et à les retransmettre depuis ladite au moins une ressource IP. Un tel équipement est configuré pour :
détecter une présence, sur au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement nœud sur une ressource IP dudit équipement terminal dite deuxième ressource IP, d'au moins une fonction à états configurée pour maintenir dans une table un état associé à une communication sur ledit chemin pendant une durée de vie déterminée, comprenant l'émission dans le réseau de communication d'un premier message depuis au moins une première ressource IP dudit équipement nœud vers ladite deuxième adresse IP dudit équipement terminal et la décision de présence d'au moins une fonction à états sur ledit au moins un chemin en fonction de données reçues par la deuxième ressource IP en réponse à l'émission du premier message ;
déclencher une action de gestion d'une communication de l'équipement terminal sur ledit réseau de communication via ledit chemin en fonction de ladite détection.
Ainsi, l'invention est mise en œuvre de façon récursive par les différents équipements nœuds mis en jeu sur le chemin testé. Liste des figures
D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
[fig. 1] : cette figure représente de façon schématique un exemple d'équipement terminal disposant de plusieurs chemins pour se connecter à un réseau de communication;
[fig. 2] : cette figure représente sous forme de logigramme les différentes étapes du procédé de gestion d'au moins une communication d'un équipement terminal dans un réseau de communication selon un mode de réalisation de l'invention;
[fig. 3A] : cette figure représente de façon schématique un premier exemple de construction d'une liste de communications candidates entre deux adresses distinctes d'un même équipement terminal;
[fig. 3B] : cette figure représente de façon schématique un deuxième exemple de construction d'une liste de communications candidates entre deux adresses distinctes d'un même équipement terminal;
[fig. 4] : cette figure détaille sous forme de logigramme les différentes sous-étapes de l'étape de découverte d'au moins une fonction à états sur un chemin de l'équipement terminal selon un premier mode de réalisation du procédé de gestion d'au moins une communication selon l'invention;
[fig. 5] : cette figure représente de façon schématique un premier exemple de fonction à états présente sur un chemin de l'équipement terminal dans le réseau de communication;
[fig. 6] : cette figure représente de façon schématique un deuxième exemple de fonction à états présente sur un chemin de l'équipement terminal dans le réseau de communication;
[fig. 7] : cette figure représente de façon schématique un troisième exemple de fonction à états présente sur un chemin de l'équipement terminal dans le réseau de communication ;
[fig. 8A] : cette figure représente de façon schématique une première option de l'invention pour forcer l'envoi d'une requête de communication destinée à une adresse de l'équipement terminal émetteur dans le réseau de communication;
[fig. 8B] : cette figure illustre de façon schématique la réception de la requête de communication à l'adresse de l'équipement terminal émetteur selon cette première option;
[fig. 9] : cette figure représente de façon schématique une deuxième option de l'invention pour forcer l'envoi d'une requête de communication destinée à une adresse de l'équipement terminal émetteur dans le réseau de communication; [fig. 10] : cette figure représente de façon schématique les communications directes établies par un équipement terminal entre deux de ses propres interfaces selon un premier exemple de réalisation de l'invention ;
[fig. 11] : cette figure représente de façon schématique les communications directes établies par un équipement terminal entre deux de ses propres interfaces selon un deuxième exemple de réalisation de l'invention ;
[fig. 12] : cette figure représente de façon schématique les communications directes établies par un équipement terminal entre deux de ses propres interfaces selon un troisième exemple de réalisation de l'invention, lorsque l'équipement terminal est connecté au réseau via un équipement d'accès ;
[fig. 13] : cette figure représente un exemple de mise en oeuvre de l'invention lorsque l'équipement terminal a été configuré avec un équipement proxy situé dans le réseau de communication;
[fig. 14] : cette figure détaille sous forme de logigramme les différentes sous-étapes de l'étape de découverte d'au moins une fonction à états sur un chemin de l'équipement terminal selon un deuxième mode de réalisation du procédé de gestion d'au moins une communication selon l'invention;
[fig. 15] : cette figure représente de façon schématique un exemple de structure d'un message de commande, dit miroir, émis par un équipement terminal à destination d'un deuxième équipement terminal via une communication déjà établie selon un mode de réalisation de l'invention ;
[fig. 16] : cette figure représente de façon schématique un premier exemple de mise en oeuvre d'une détection de présence de fonctions à états sur un chemin d'un premier équipement terminal en utilisant une communication déjà établie avec un deuxième équipement terminal selon le deuxième mode de réalisation de l'invention ;
[fig. 17] : cette figure représente de façon schématique un deuxième exemple de mise en oeuvre d'une détection de présence de fonctions à états sur un chemin d'un premier équipement terminal en utilisant une communication déjà établie avec un deuxième équipement terminal selon le deuxième mode de réalisation de l'invention ;
[fig. 18] : cette figure représente de façon schématique la détermination d'une durée de vie d'une entrée d'une fonction à états détectée sur un chemin d'un équipement terminal selon un troisième mode de réalisation de l'invention ;
[fig. 19A] : cette figure représente de façon schématique un premier exemple de structure d'un message de contrôle d'une durée de vie d'une fonction à états détectée sur un chemin d'un équipement terminal, selon le troisième mode de réalisation de l'invention ; [fig. 19B] : cette figure représente de façon schématique un deuxième exemple de structure d'un message de contrôle d'une durée de vie d'une fonction à états détectée sur un chemin d'un équipement terminal, selon le troisième mode de réalisation de l'invention ;
[fig. 20] : cette figure représente de façon schématique un exemple d'émission d'un message de contrôle par un équipement terminal à destination d'un deuxième équipement terminal selon ce troisième mode de réalisation de l'invention ;
[fig. 21] : cette figure représente un schéma synoptique d'un dispositif de gestion d'au moins une communication d'un équipement terminal dans un réseau de communication selon l'invention ; et
[fig. 22] : cette figure représente un schéma synoptique d'un dispositif de traitement d'une communication d'un équipement terminal dans un réseau de communication selon l'invention.
Description détaillée de modes de réalisation de l'invention
Principe général
Le principe général de l'invention repose sur la découverte des fonctions à états présentes sur un ou plusieurs chemins permettant de joindre via un réseau de communication une interface d'un équipement terminal et sur la décision de déclencher une action de gestion d'une communication avec un autre équipement terminal sur un de ces chemins en fonction de ladite découverte. Par exemple, une action possible est l'établissement d'une communication en choisissant un chemin ne présentant pas de fonction à états intermédiaire et sans activer de mécanisme de maintien en vie d'une entrée d'une table maintenue par une telle fonction à états. L'invention permet ainsi de gérer plus efficacement les communications d'un équipement terminal via un réseau de communication et d'optimiser les ressources énergétiques mises en jeu par ces communications. L'invention s'applique à tout type d'équipements terminaux : un équipement terminal mono interface ou un équipement terminal multi-interfaces et multi-usages capable d'établir des communications sur des chemins multiples tout en préservant la continuité du ou des service(s) correspondant(s) lorsque l'équipement terminal est en situation de mobilité.
Dans la suite de la description, on désigne par équipement terminal (ou plus simplement parfois « terminal ») toute entité capable d'établir ou d'accepter l'établissement d'une communication reposant sur l'utilisation d'un ou plusieurs protocoles de transport, tels que TCP, UDP, ou QUIC. Il peut s'agir d'une entité physique, une entité virtuelle, ou d'une application logicielle embarquée dans l'équipement terminal.
Par « protocole QUIC », ou de manière abrégée « QUIC », on entend tout protocole conforme à une version de la spécification du protocole QUIC ou de projet de spécification, tel que le projet de spécification de l'IETF intitulé « QUIC : A UDP-Based Multiplexed and Secure Transport », ou la spécification du protocole « Quick UDP Internet Connections », dit protocole « QUIC », y compris les versions existantes de ces spécifications ou projets de spécifications et leurs évolutions. Plus généralement, QUIC dénote ici tout protocole de transport encapsulé sur un autre protocole de transport UDP ou UDP-lite (de l'anglais « Lightweight User Datagram Protocol ») mais dont les primitives et la charge utile sont chiffrées.
L'invention s'applique à tout type d'équipement terminal, fixe ou mobile, comprenant une ou plusieurs interfaces de communication avec un réseau de communication. Ces interfaces peuvent être filaires, comme par exemple une interface de type ADSL ou fibre, ou non filaires, comme par exemple une interface de type WLAN, BlueTooth, Zigbee, ou autre.
On désigne génériquement par réseau de communication un réseau de communication de type Internet auquel peut accéder l'équipement terminal par un ou plusieurs réseaux d'accès à ce réseau.
L'équipement terminal qui initialise l'établissement d'une communication est généralement désigné par terminal émetteur ou client, tandis que celui à qui est destinée la requête d'établissement est appelé terminal distant ou serveur. Un même terminal peut donc agir à la fois comme client et serveur.
On suppose qu'un ou plusieurs chemins d'un terminal peuvent être utilisés pour établir une communication et qu'une communication peut être établie via un ou des chemins multiples.
Des fonctions à états, par exemple de type traduction d'adresse réseau ou NAT ou pare-feu ( « firewall », en anglais) peuvent être présentes sur tout ou partie des chemins disponibles qu'un équipement terminal peut utiliser pour accéder au réseau, aussi bien dans le réseau d'accès du terminal émetteur, que dans celui du terminal distant, voire des deux. Les fonctions NAT peuvent être de différentes natures, telles que par exemple NAT44, NAT64, DS-Lite, NPTv6, L2NAT, NAT 66, etc. Plusieurs fonctions NAT peuvent être présentes sur un chemin donné, comme par exemple dans le cas d'un déploiement dit « double NAT ».
Un chemin réseau peut impliquer à la fois des fonctions NAT et des pare-feux, sans hypothèse restrictive quant au nombre de fonctions présentes ou à l'ordre dans lequel elles agissent.
On désigne par fonction à états entrante une fonction à états localisée dans le réseau d'accès auquel un terminal destinataire d'une communication est connecté. Une fonction à états sortante dénote une fonction à états localisée au contraire dans le réseau d'accès auquel l'équipement terminal émetteur de la requête d'établissement d'une communication est connecté. Ainsi, une fonction à états peut agir en tant que fonction à états entrante ou fonction à états sortante selon la direction du trafic.
Un ou plusieurs adresses ou préfixes peuvent être alloués à un équipement terminal par un réseau d'accès. On désigne par ressource IP un couple comprenant une adresse IP et un numéro de port.
Dans la suite de la description, on s'attache à décrire plus en détails le cas de communications établies avec le protocole QUIC et en particulier des structures de messages de signalisation adaptées au protocole QUIC, mais l'invention ne se limite pas à cet exemple et concerne plus largement tout autre protocole de transport utilisé par un équipement terminal émetteur pour établir une communication avec un équipement terminal distant via un réseau de communication, comme par exemple le protocole TLS (pour « Transport Layer Security », en anglais). Dans les exemples décrits ci-après, on considère en particulier le cas d'une fonction à états de type NAT, mais l'invention s'applique plus généralement à tout type de fonction à états. En relation avec la figure 1, on présente un équipement terminal Tl disposant de plusieurs chemins pour accéder, via des interfaces qui permettent de connecter le terminal Tl à différents réseaux d'accès à un réseau de communication RC, tel que le réseau Internet : un premier chemin Cl associé à une adresse IP @T11 de l'équipement terminal Tl via un réseau d'accès Nil au réseau RC, un deuxième chemin C2 associé à une adresse @T12 de l'équipement terminal Tl via un réseau d'accès N12, un ieme chemin Ci associé à une adresse @Tli de l'équipement terminal Tl via un réseau d'accès Nli, avec i entier non nul.
La figure 2 illustre les principales étapes mises en oeuvre par un procédé de gestion d'au moins une communication de l'équipement terminal dans le réseau de communication RC.
Au cours d'une étape 20, on vérifie, par exemple au démarrage du terminal Tl, s'il dispose de plusieurs chemins réseau Cli pour accéder au réseau RC et on obtient une liste ACAL (pour « Address Candidate List », en anglais) des adresses associées à ces chemins. Préférentiellement, une telle liste ACAL comprend pour une adresse IP @Tli du terminal Tl, une entrée associant au moins une valeur de statut STATUS à l'adresse @Tli. Par défaut, ce paramètre est positionné à OKOFF, ce qui signifie que pour cette adresse, aucune optimisation de gestion d'une volumétrie des messages émis par un mécanisme de maintien en vie (keepalive ) des fonctions à états n'est mise en oeuvre.
En 21, on construit à partir de la liste ACAL une liste des communications candidates CC, dite liste PCL (pour « Path Candidate List », en anglais), entre deux ressources distinctes de l'équipement terminal Tl, c'est-à-dire entre un premier couple (première adresse IP, premier numéro de port) et un deuxième couple (deuxième adresse IP, deuxième numéro de port). On comprend que ces communications candidates sont destinées à connecter deux ressources distinctes du même équipement terminal Tl. Optionnellement, la liste PCL peut exclure les adresses IPv4 privées telles que décrites dans le document RFC 1918, publié par l'IETF en février 1996 et accessible via l'URL suivante : https://tools.ietf.org/html/rfcl918, les adresses IPv4 de type « IANA-Reserved IPv4 Prefix for Shared Address Space », telles que spécifiées dans le document RFC 6598 publié par l'IETF en avril 2012 et accessible via l'URL suivante : https://tools.ietf.org/html/rfc6598, les adresses IPv6 de type LLA ( « Link Local Address », en anglais) ou ULA ( « Unique Local Address », en anglais). On notera que l'allocation exclusive de telles adresses à un équipement terminal est une indication qu'un mécanisme de traduction d'adresse est mis en oeuvre dans le réseau de communication pour permettre une connectivité globale.
On notera aussi que pour un élément, c'est-à-dire une même communication candidate de la liste PCL, les adresses source et destination doivent être d'un même type ou famille d'adresses, par exemple IPv4 ou IPv6, mais que la liste peut contenir des communications candidates impliquant des adresses de différents types, par exemple des communications candidates entre deux adresses de type IPv4 et des communications candidates entres deux adresses de type IPv6.
En 22, on détecte la présence d'au moins une fonction à états, sur au moins un chemin permettant de joindre le terminal Tl via le réseau de communication RC sur une adresse IP dudit équipement terminal, dite deuxième adresse IP. Avantageusement, on répète cette étape pour tous les chemins listés dans la liste ACAL.
Pour réaliser cette détection, on utilise les communications candidates de la liste PCL.
On considère par exemple les communications candidates impliquant la deuxième adresse IP. On émet dans le réseau de communication un premier message depuis au moins une première ressource IP dudit équipement terminal vers une deuxième ressource IP dudit équipement terminal, comprenant la deuxième adresse IP et un numéro de port. Le terminal Tl décide ensuite de la présence d'au moins une fonction à états sur le chemin emprunté par cette communication pour relier le terminal Tl au réseau RC via la deuxième ressource IP en fonction de données reçues sur cette deuxième ressource IP en réponse à l'émission du premier message. Avantageusement on répète cette étape pour toutes les communications candidates impliquant la deuxième adresse IP du terminal Tl.
On comprend que la détection de présence d'une fonction à états pour une des communications candidates suffit pour conclure à la présence d'une fonction à états sur le chemin reliant le terminal Tl au réseau RC via la deuxième adresse IP.
En 23, on déclenche une action de gestion d'une communication de l'équipement terminal Tl sur le chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur ladite deuxième adresse IP, en fonction de ladite détection.
Par exemple, les actions de gestion de l'étape 23 comprennent la sélection d'un chemin pour établir une communication avec un terminal distant en fonction du résultat obtenu en 22. Des exemples d'actions de gestion seront détaillés dans la suite de la description.
On détaille maintenant l'étape 21, appelée LIST PCL, d'obtention d'une liste PCL de communications candidates à partir des chemins de la liste ACAL.
Etape LIST PCL
Cette étape a donc pour objectif de créer la liste PCL à partir de la liste ACAL.
Si les adresses de la liste ACAL ne sont pas toutes du même type, par exemple si la liste comprend des éléments de types différents, par exemple des adresses IPv4 et des adresses IPv6, alors une sous-liste est créée par type d'adresses : ACAL(v4) et ACAL(v6).
On notera que la liste ACAL des chemins disponibles au niveau du terminal Tl pour accéder au réseau RC peut comprendre des adresses ou des préfixes IP, mais aussi des noms d'interface réseau (par ex. ethl, wlanO), des noms de réseau, etc. Dans la suite on fera donc référence aux éléments de la liste ACAL.
Selon l'invention, la liste PCL comprend des communications candidates CC entre deux éléments de la liste ACAL. Elle est créée en prenant en compte les contraintes suivantes :
Chaque entrée de la liste PCL est composée de deux éléments de la liste ACAL ;
Le premier élément d'une entrée PCL est appelé « Source ». Un numéro de port du terminal Tl, dit port source lui est associé ;
Le deuxième élément d'une entrée PCL est appelé « Destination ». Un numéro de port du terminal Tl, dit port destination, lui est associé ;
Chaque élément de la liste ACAL doit apparaître au moins dans une entrée PCL comme « Destination » ;
Deux éléments ACAL ne peuvent appartenir qu'à une et seulement une entrée de la liste
PCL ;
Un élément de la liste ACAL peut apparaître dans plusieurs entrées PCL comme « Source » ;
Certains éléments de la liste ACAL peuvent ne pas apparaître dans aucune entrée PCL comme « Source » ;
La liste PCL est ordonnée ;
Une entrée avec une source SRC1, ne doit pas précéder une entrée avec une destination SRC1. En effet, une telle configuration aurait pour effet de créer une entrée dans une éventuelle fonction à états intermédiaire pour l'élément SRC1. Lors du test d'une communication avec SRC1 comme destination, cette fonction à états pourrait laisser passer le paquet de données servant à réaliser le test et ainsi, masquer la présence de cette fonction à états sur le chemin associé à
SRC1. Les figures 3A et 3B illustrent deux exemples de construction de la liste PCL à partir de la liste ACAL comprenant les éléments Nil, N12, Nli. Ces deux exemples satisfont les contraintes listées ci-dessus.
L'exemple de la figure 3A génère la liste PCL suivante :
{Nil, N12}, {N12, N 13}, {N13, N 14}, ..., {Nli-1, Nli}, {Nli, Nil}.
L'exemple de la figure 3B génère la liste PCL suivante :
{Nil, N12}, {Nil, N 13}, {Nil, N 14}, ..., {Nli, Nli-2}, {Nli, Nli-1}, {Nli, Nil}.
En relation avec la figure 4, on détaille maintenant l'étape 22 de détection d'une présence d'une fonction à états selon un premier mode de réalisation de l'invention.
Mode de réalisation MULT1 ou mode « autonome »
Comme illustré par la figure 4, on sélectionne en 220 une communication à établir parmi les communications candidates de la liste PCL. Lors de cette sélection, on veille à ne pas choisir une ressource IP source qui vient d'être utilisée comme source ou destination d'une précédente communication, de façon à éviter qu'une entrée correspondant à cette ressource soit encore maintenue comme valide dans une table d'une fonction à états présente sur le chemin testé.
On établit en 221 la communication sélectionnée en forçant l'émission dans le réseau de communication d'une requête d'établissement d'une communication entre l'adresse source, le numéro de port source, et l'adresse destination et le numéro de port destination, de sorte que la requête ne soit pas traitée localement au niveau du terminal Tl. Avantageusement, le numéro de port source choisi pour cette communication candidate est différent de ceux déjà utilisés pour tester les communications candidates précédemment listées. Cette condition est nécessaire pour détecter la présence de fonctions NAT de type EIF/EIM (« Endpoint Independent Filtering/Mapping », en anglais) ou de pare-feux.
En effet, comme illustré par la figure 5, une commuication depuis une nouvelle adresse @Tli peut être établie avec l'adresse @T11 même en présence d'un NAT si une communication depuis cette adresse @Tli a été établie antérieurement (et maintenue par la fonction NAT) vers une autre adresse @T2. En effet, en référence à la figure 5, on suppose que la fonction NAT supporte le mode « EIF/EIM ». Lorsque le terminal Tll établit une communication avec un terminal distant Tli, la fonction NAT alloue à cette communication une adresse externe et un numéro de port externe (212.25.26.25:1234) et réécrit l'adresse source interne et numéro de port interne du paquet émis par Tll (192.168.0.2:7856) à destination de Tli. Ensuite, la fonction NAT garde en mémoire une entrée dans ses tables pour associer les informations internes et externes de cette communication. Cette entrée ne contient pas les informations relatives à Tli. De ce fait, n'importe quelle communication entrante à destination de (212.25.26.25:1234) sera acheminée vers Tll en réécrivant l'adresse et numéro de port destination (192.168.0.2:7856) selon les consignes de la table précitée. En d'autres termes, la fonction NAT ne vérifie pas l'adresse et numéro de port source pour traiter un paquet entrant.
On note que d'autres types de filtrage sont plus restrictifs et peuvent être détectés plus facilement. Il s'agit par exemple du filtrage ADM/ADF (pour « Address Dépendent Filtering », en anglais), illustré par la figure 6, ou le filtrage APDM/APDF (pour « Address Port Dépendent Filtering », en anglais), illustré par la figure 7. En effet, contrairement au mode EIM/EIF, la fonction NAT configurée dans un mode ADM/ADF (figure 6) doit garder en mémoire l'adresse destination d'un paquet sortant, en plus des informations source. Ainsi, seuls les paquets reçus avec une adresse source présente dans une entrée de la table de la fonction NAT seront acheminés vers un terminal interne. Par exemple, si Tll établit une communication avec un terminal distant Tli (35.26.25.25:4545), la fonction NAT alloue une adresse externe et un numéro de port externe (11.11.11.11:1234) et réécrit l'adresse source interne et numéro de port interne du paquet émis par Tll (192.168.0.2:7856) à destination de Tli. Ensuite, la fonction NAT garde en mémoire une entrée dans ses tables pour associer les informations internes et externes ainsi que l'adresse destination caractéristiques de cette communication (source interne : 192.168.0.2:7856, source externe : 11.11.11.11:1234, destination : 35.26.25.25). La fonction NAT rejette toutes les communications entrantes vers 1.1.1.1:1234 si l'adresse source d'une communication n'est pas égale à 35.26.25.25.
L'exemple de la figure 7 est similaire à celui de la figure 6 à l'exception du fait que la fonction NAT enregistre, en plus des informations maintenues dans les tables à états de l'exemple de la figure 6, le numéro de port destination (4545) pour la communication sortante émise depuis Tll (192.168.0.2:7856). La fonction NAT rejette toutes les communications entrantes à destination de 1.1.1.1:1234 qui ne présentent pas une adresse source et un numéro de port source égaux à 35.26.25.25:4545.
En 222, on vérifie si la requête d'établissement d'une communication émise depuis l'adresse source et le numéro de port source a été reçue par la ressource IP destination du terminal Tl. Dans l'affirmative, on déclare en 223 que la communication candidate (@T11, PS, @Tli, PD) emprunte un chemin qui ne comprend pas de fonction à états et on met à jour un statut PATH- STATUS de la communication candidate à la valeur OK.
Dans la négative, on décide que le chemin (@T11, PS, @Tli, PD) est inutilisable en l'absence d'une communication sortante et on positionne le statut PATH_STATUS associé à NOP.
Enfin, si un message d'erreur a été reçu, par exemple de type ICMP avec une indication de type destination ou protocole injoignable (pour « unreachable destination or protocol », en anglais), le chemin emprunté par la communication candidate sélectionnée est déclarée inutilisable et le statut PATH-STATUS de la communication est positionné à la valeur NOP.
On notera que les décisions de mise à jour des statuts des chemins empruntés par les communications candidates testées peuvent être prises immédiatement après une unique tentative d'établissement ou alternativement après plusieurs tentatives.
L'enchaînement d'étapes 220 à 223 est ensuite répété tant qu'il reste des communications candidates à tester.
Selon une première option toutes les communications candidates sont testées. Un avantage d'une approche systématique est de permettre au terminal d'apprécier la viabilité de l'intégralité des chemins disponibles (et de décider d'une politique d'acheminement de trafic en conséquence).
Selon une deuxième option, seule une partie des communications est établie conformément à une politique locale au terminal Tl. Un avantage d'une approche sélective est qu'elle est moins coûteuse en ressources de calcul et potentiellement mieux adaptée à des contextes particuliers, selon lesquels par exemple le choix d'un chemin est indexé par la nature du trafic qui transitera par la communication. Par exemple, le trafic Internet transite via un NAT tandis que le trafic voix est acheminé sur un chemin sans NAT.
Avantageusement, les communications candidates sont sélectionnées en 220 selon leur ordre d'apparition dans la liste PCL et établies séquentiellement de sorte à éviter l'enregistrement d'entrées par une fonction NAT sur le chemin que l'on souhaite tester. Toutefois, on notera que plusieurs communications candidates peuvent être établies simultanément pourvu qu'aucune ressource IP du terminal n'apparaisse à la fois comme source et destination dans des communications candidates de la liste PCL.
En revanche, si la liste PCL est construite comme suit : [(@T11,@T12), (@T12,@T13), ..., (@Tli- l,@Tli), ..., (@Tli,@Tll)], alors les communications candidates seront nécessairement établies séquentiellement.
En 224, on met à jour le statut des adresses IP associées aux chemins listés dans la liste ACAL de la façon suivante :
si toutes les communications candidates testées à destination d'une adresse IP @Tlk, k entier compris entre 1 et i, ont leur statut positionné à OK, on décide que le chemin associé à l'adresse @Tlk du terminal Tl ne comprend pas de fonction à états et on met à jour le statut de cette adresse IP à une valeur « optimisé » ou « OKON » (pour « Optimized Keepalive On », en anglais), ce qui signifie que pour ce chemin, la procédure d'optimisation du mécanisme de maintien en vie des entrées maintenues par les fonctions à états est activée ;
sinon, si au moins une communication candidate testée à destination d'une ressource comprenant l'adresse IP @Tlk a son statut positionné à NOP, alors on décide que le chemin associé à l'adresse IP @Tlk du terminal Tl comprend une fonction à états intermédiaire et on met à jour le statut de cette ressource STATUS à une valeur « non optimisé » ou « OKOFF » pour signifier que l'optimisation du mécanisme de maintien en vie des entrées maintenues par les fonctions à états n'est pas activée sur ce chemin et qu'il faudra déterminer une fréquence d'émission des messages « keepalive » pour optimiser le mécanisme. Après cette étape de traitement supplémentaire, on pourra modifier le statut et le positionner à « OKON » en indiquant la fréquence optimisée.
On détaille maintenant l'étape 221 d'émission d'une requête d'établissement d'une communication candidate sélectionnée. Comme précédemment évoqué, du fait que les adresses IP source et destination appartiennent au même terminal Tl, il est nécessaire de forcer l'acheminement du paquet de données comprenant ladite requête à travers une interface de sortie afin qu'il ne soit pas traité localement par le terminal.
Pour ce faire, deux options sont envisagées :
Option MULT1.1 : Filtre MP-BUND
Selon une première variante illustrée par les figures 8A et 8B, la requête d'établissement de la communication comprend un paramètre MP_BUND(@T1D) de masquage de l'interface correspondant à l'adresse IP de destination de la communication candidate @T1D du terminal Tl. Ce paramètre MP_BLIND(lnterface Alias/Address)permet de faire comme si le terminal Tl ne disposait que d'une seule adresse IP ou d'une seule interface de sortie (identifiant d'interface « Interface Alias» ou l'adresse de l'interface « Address »).
Ce nouveau paramètre proposé par l'invention, quand il est invoqué pour déclencher l'envoi d'un paquet dans le réseau vers une interface donnée, a pour effet d'appliquer un filtre à toutes les autres interfaces du terminal ce qui a pour effet que seules les informations relatives à l'interface non filtrée soient retenues.
Ce faisant, la requête d'établissement d'une communication entre les adresses {@T1S, @T1D} invoquée avec le paramètre MP_BLIND a pour conséquence d'envoyer le paquet comprenant cette requête vers le routeur par défaut associé à l'adresse IP source @T1S.
Ainsi le terminal Tl maintient une table de routage globale (table 1) qui inclut deux tables de routage associées respectivement à chacune de ses interfaces « ethO » et « ethl ».
fl;~# ip rule show
0: from ail lookup local
32764: from 1.2.3.2 lookup 2
32765: from 10.20.30.2 lookup 1
32766: from ail lookup main
32767: from ail lookup default
tl:~# ip route 1.2.3.0/24 dev ethO proto kernel scope link src 1.2.3.2
10.20.30.0/24 dev ethl proto kernel scope link src 10.20.30.2
default via 1.2.3.1 dev ethO
Table 1
Supposons par exemple que le terminal veuille établir une communication entre les adresses IP source et destination {@T1S=1.2.3.2, @T1D=10.20.30.2}. Cette communication a vocation à être traitée localement car l'adresse de destination est celle de l'interface « ethl ».
Afin de forcer l'envoi du paquet de données comprenant la requête d'établissement d'une communcation via le réseau de communication RC vers l'adresse IP de destination @T1D correspondant à l'interface « ethl », le terminal émule donc un comportement mono-interface en utilisant le paramètre MP_BLIND(ethl). La table de routage invoquée (table 2 ) est indiquée ci- dessous. Le paquet est alors transmis à l'équipement de routage RI comme illustré par la figure 8A.
fl;~# ip route show table 2
1.2.3.0/24 dev ethO scope link
default via 1.2.3.1 dev ethO
Table 2
Si aucune fonction à états n'est présente sur le chemin reliant le terminal Tl au réseau RC via l'interface « ethl », le paquet de données sera reçu par le terminal Tl via l'équipement de routage R2, comme illustré par la figure 8B.
Option MULT1.2 : Routage à la source
Selon une deuxième variante illustrée par la figure 9, on force en 221 l'envoi de la requête d'établissement d'une communication entre les adresses IP source @T1S et destination @T1D en utilisant une technique de routage à la source. Une telle technique, connue de l'homme de métier, peut être mise en oeuvre de différentes manières, telles que par exemple l'extension de routage par segment SR (pour « Segment Routing », en anglais), l'option IPv4 intitulée « routage non strict à la source et enregistrement de route » ou LSRR (pour « Loose Source and Record Route », en anglais) ou toute autre fonction de routage à la source similaire.
L'option reposant sur le routage à la source consiste à associer une information supplémentaire à chacune des entrées de la liste des communications candidates PCL pour indiquer, pour chaque communication candidate, le routeur par défaut associé à son adresse IP source @T1S. Par exemple, la liste PCL mise à jour par le terminal Tl est : {@T11, PS11 @T12, PD12, default_router=Rll}, ..., {@Tln, PSln, @T11, PD11, default_router=Rln}.
Dans la suite, on suppose par exemple que l'option SR est utilisée.
Avec cette option, la décision d'acheminement du paquet de données comprenant la requête d'établissement de la communication sélectionnée repose sur le contenu de l'option SR. Ainsi, le terminal envoie la demande d'établissement de communication au routeur par défaut tel qu'identifié dans l'entrée correspondante de la table PCL. A réception du paquet, ledit routeur par défaut retire l'option SR et procède à la transmission du paquet de données vers le prochain saut dans le réseau de communication.
Le paquet est ainsi acheminé de proche en proche ou rejeté lorsqu'aucune route n'a été trouvée.
En relation avec la figure 10, le terminal Tl cherche à établir en 221 les communications candidates CC listées dans sa table PCL : {@T11, PS11, @T12, PD12}, {@T12, PS12, @Tli, PDli} et {@Tli, PSli, @T11, PD11}. Dans l'exemple de la figure 10, toutes ces communications sont établies sans difficulté. La table ACAL est donc mise à jour pour positionner à la valeur « OKON » le paramètre STATUS de chaque chemin associé à une adresse IP destination testée.
En relation avec la figure 11, le terminal Tl cherche à établir les communications candidates suivantes sur ses chemins d'accès au réseau : {@T11, PS11, @T12, PD12}, {@T12, PS12, @Tli, PDli} et {@Tli, PSli, @T11, PD11}. Dans l'exemple de la figure 11, toutes ces communications sont établies avec succès à l'exception de la communication candidate {@T12, PS12, @Tli, PDli}, car une fonction NAT est présente sur le chemin correspondant. La table ACAL est alors mise à jour pour mettre à jour le paramètre STATUS des adresses IP des chemins d'accès au réseau du terminal Tl. Il positionne à la valeur « OKON » le statut de toutes les adresses IP disponibles dans la liste ACAL à l'exception de l'adresse @Tli pour laquelle le paramètre STATUS est maintenu à « OKOFF ».
En relation avec la figure 12, le terminal est connecté au réseau de communication par l'intermédiaire d'un équipement d'accès de type CPE (« Customer Premises Equipment », en anglais). Il s'agit par exemple d'une passerelle résidentielle. Dans ce cas, le procédé qui vient d'être décrit peut avantageusement être mis en oeuvre par cet équipement CPE.
En relation avec la figure 13, on décrit maintenant une variante de réalisation du mode de réalisation du procédé qui vient d'être présenté en relation avec la figure 4, selon laquelle le terminal Tl a été configuré pour se connecter au réseau via un équipement proxy P localisé dans le réseau de communication RC.
Mode de réalisation MULT2 ou mode « Proxy »
Selon l'exemple du protocole QUIC, cet équipement proxy P met en oeuvre une fonction «Proxy QUIC » responsable de l'exécution des opérations sur les communications QUIC émises par le ou destinées au terminal Tl. Aucune contrainte n'est imposée par l'invention quant aux opérations effectuées par une telle fonction Proxy. Ce mode de réalisation de l'invention est applicable quelle que soit la localisation de la fonction « Proxy QUIC » dans le réseau de communication.
Le « Proxy QUIC » peut être typiquement configuré sur le terminal en utilisant par exemple le protocole DHCP, l'option PCO (pour « PDP Configuration Options », en anglais), etc.
Les requêtes d'établissement de communication selon le protocole QUIC émises par le terminal Tl sont interceptées par ce « Proxy QUIC » P qui les relaie ensuite vers leurs destinations. O suppose à titre d'exemple qu'un schéma d'encapsulation IP-in-IP ou GRE (pour « Generic Routing Encapsulation », en anglais), tel que décrit dans le document RFC 2784 publié par l'IETF en mars 2000, est utilisé entre le terminal et la fonction « Proxy QUIC ».
Si plusieurs fonctions « Proxy QUIC » sont présentes dans le réseau, le terminal peut sélectionner une ou plusieurs instance(s) de cette fonction, voire utiliser toutes les instances pour établir des communications dans le réseau.
Selon l'invention, le terminal Tl construit en 21 la liste PCL des communications candidates à partir de la liste ACAL selon l'étape LIST précédemment décrite. Par exemple, la liste PCL ainsi construite pour le terminal Tl est {@T11, PS11, @T12, PD12}, ..., {@Tln, PSln, @T11, PD11}. Ensuite, en 221, comme déjà décrit en relation avec la figure 4, le terminal Tl tente d'établir une communication QUIC pour chacun des éléments de la liste PCL, mais cette fois via au moins une fonction « Proxy QUIC ».
Par exemple, comme illustré par l'exemple de la figure 13, le terminal Tl émet vers le proxy P une demande d'établissement d'une communication QUIC comprenant l'adresse IP de destination @Tli. Pour ce faire, il encapsule cette demande d'établissement (formatée selon une trame QUIC) dans un paquet IP dont l'adresse destination est celle du proxy P. A réception du paquet par le proxy P, ce dernier extrait la trame QUIC. Ensuite, il tente d'acheminer la demande d'établissement de communication vers l'adresse IP @Tli. S'il dispose d'une route pour joindre l'adresse @Tli, il envoie le paquet sur cette route. Si aucune route n'a été trouvée, le proxy P répond au terminal avec un message ICMP pour indiquer que cette adresse IP n'est pas joignable. Si le proxy P reçoit la demande d'établissement de communication, il la retransmet au terminal en l'encapsulant dans un paquet IP.
Les étapes 222 à 224 précédemment décrites restent inchangées.
En relation avec la figure 14, on détaille maintenant l'étape 22 de détection de présence d'une fonction à états selon un deuxième mode de réalisation de l'invention.
Mode de réalisation MULT3 ou mode « assisté »
On rappelle qu'en 21 une liste PCL des communications candidates à établir sur les chemins réseau disponibles au niveau de l'équipement terminal Tl a été construite. Au cours d'une étape 220', le terminal sélectionne au moins une communication candidate CC de la liste PCL. On note qu'il peut sélectionner plusieurs voire toutes les communications candidates de la liste PCL.
En 220b', il obtient les informations relatives à une communication CE12 qu'il a déjà établie via un de ses chemins réseau avec un deuxième équipement terminal T2 dans le réseau de communication RC. Par exemple, cette communication est établie entre une ressource IP comprenant l'adresse @T11 allouée par le réseau d'accès Nil au terminal Tl et une ressource IP comprenant l'adresse @T2 du terminal T2.
En 22 , le terminal Tl émet à destination du terminal T2, via la communication CE12, un message, dit trame miroir (pour « Mirror », en anglais). Cette trame est destinée à commander au terminal T2 l'émission d'un message de réponse selon les conditions spécifiées dans les champs de la trame miroir. Dans le cas du protocole QUIC, il s'agit d'une nouvelle structure de trame QUIC proposée par l'invention.
Cette trame comprend :
au moins une adresse IP de destination du terminal Tl à laquelle le terminal T2 doit envoyer des données. Avantageusement, ce champ comprend les adresses IP destination des communications candidates sélectionnées en 220' ;
au moins un numéro de port destination par adresse IP de destination. On note que si la trame ne contient pas de numéro de port, le terminal distant T2 devra générer aléatoirement un numéro de port à associer à chaque adresse IP de destination ;
une clé de sécurité (ou « jeton », soit « Token », en anglais) supplémentaire à inclure dans le message de réponse à transmettre à l'adresse ou aux adresses de destination indiquée(s).
Un exemple de trame miroir est illustré par la figure 15.
Selon l'invention, le terminal T2 connecté au terminal Tl via la communication CE12 met en oeuvre un procédé de traitement d'une communication qui comprend les étapes suivantes, illustrées par la figure 14 .
Il reçoit en 300 la trame miroir émise par Tl via la communication CEI. En 301, il extrait de cette trame les adresses IP destination qu'elle contient, éventuellement associées à des numéros de port de destination, ainsi que la clé de sécurité. On rappelle que si la trame miroir ne contient pas de numéro de port destination, le terminal T2 en génère autant que d'adresses de destination extraites, par exemple de façon aléatoire. En 302, le terminal T2 émet à destination de chaque couple (adresse IP destination, numéro de port destination) du terminal Tl spécifié dans la trame miroir, une trame TV dite trame vide car elle ne transporte pas de données applicatives, comprenant uniquement la clé de sécurité. On note que le terminal T2 n'a pas besoin d'établir une nouvelle communication QUIC avec Tl. En effet, comme évoqué précédemment, une communication QUIC est indépendante des ressources IP source et destination, mais repose sur une association de sécurité.
On notera qu'avec un autre protocole de transport, qui serait dépendent des ressources IP source et destination, la trame « miroir » donnerait lieu à de nouvelles communications, que le terminal Tl devrait écouter et associer avec le test de détection de présence en cours.
En 222', à réception d'une telle trame TV sur une de ses adresses, le terminal Tl vérifie qu'elle comprend bien la clé de sécurité, puis, le cas échéant, déclenche la mise à jour en 223' du statut ST de la communication candidate CC correspondante de sa liste PCL en le positionnant à la valeur « OKON ». En effet, le fait d'avoir reçu la trame TV sur le chemin associé à l'adresse IP destination du terminal Tl prouve qu'il n'y a pas de fonction à états sur le chemin suivi par la trame TV.
Au contraire, pour toutes les adresses IP de destination associées aux trames miroir qui ne sont pas reçues à l'issue d'un délai prédéterminé, le terminal Tl déclenche en 223' un positionnement du statut du chemin associé à la valeur OKOFF.
En 224', une fois que toutes les adresses de destination correspondant aux communications candidates CC de la liste PCL ont été testées, le terminal Tl met à jour le statut des chemins correspondants de la liste ACAL, comme précédemment décrit en relation avec la figure 4.
En relation avec les Figures 16 et 17, on considère l'exemple d'un terminal Tl qui utilise une seule communication CE12 établie avec un terminal distant T2 pour contrôler ses différentes adresses disponibles @T11, @T12, ...@Tli, avec i entier non nul. Concrètement, une fois la communication CE12 établie avec le terminal distant T2, le terminal Tl envoie une trame miroir listant les adresses @T11, T12, ..., @Tli comme adresses IP de destination et une clé de sécurité CS. A réception de la trame, le terminal distant T2 envoie un acquittement à Tl et procède ensuite à l'envoi de trames QUIC de type trame TV comprenant uniquement la clé de sécurité CS, vers chacune des adresses IP @T11, @T12, etc.
Dans l'exemple de la figure 16, toutes ces trames sont reçues avec succès par Tl. A réception d'un paquet de données comprenant une telle trame TV, ce dernier vérifie si le paquet contient la clé de sécurité CS renseignée dans la trame miroir. Dans l'affirmative, Tl met à jour sa table ACAL pour indiquer que toutes les adresses ont un paramètre STATUS égal à « OKON ».
La figure 17 illustre le cas où les paquets de données comprenant les trames TV envoyées par T2 vers l'adresse @T12 et @Tli ne sont pas reçus par Tl malgré l'acquittement préalable de T2, en raison de la présence de fonctions à états sur le chemin. A l'issue d'un délai prédéterminé, Tl met à jour les statuts des enregistrements de sa liste PCL, puis ceux de sa liste ACAL pour positionner le paramètre STATUS associé aux adresses @T12 et @Tli à « OKOFF », et celui associé à @T11 à
« OKON ». On considère maintenant le cas où le terminal Tl détecte un nouveau chemin. Il s'agit par exemple d'un tunnel VPN (« Virtual Private Network », en anglais), établi à partir d'une interface physique du terminal Tl pour laquelle il dispose déjà d'un chemin réseau.
Cette détection déclenche la mise en oeuvre de l'étape MULT de découverte de fonctions à états sur ce chemin selon l'un des modes de réalisation qui viennent d'être décrits. Ce nouveau chemin est associé à une adresse @Tli+l.
Par exemple, le terminal Tl sollicite le terminal T2 avec lequel il est déjà connecté en lui envoyant une trame miroir comprenant l'adresse @Tli+l et une clé de sécurité CS via une communication déjà établie avec lui. Un numéro de port destination différent de celui utilisé pour la communication déjà établie est indiqué dans la trame miroir. A l'issue de cette étape, le terminal met à jour le paramètre STATUS du chemin associé à l'adresse @Tli+l en fonction du résultat de la procédure de détection de présence.
Ensuite, en fonction des réponses reçues, le terminal Tl met à jour les statuts des éléments des listes PCL puis ACAL comme précédemment décrit.
Il peut enfin déclencher en 23 (CONNECT) des actions de gestion de communication sur les chemins de la liste ACAL, en prenant en compte la valeur du paramètre STATUS affectée à ces chemins.
Mode de réalisation SOLO pour un terminal mono-interface
On considère maintenant le cas d'un terminal Tl ne disposant que d'une seule interface d'accès au réseau de communication RC et donc qu'un seul chemin associé à une seule adresse IP. Le procédé selon l'invention s'applique aussi à ce terminal selon un des modes de réalisation précédemment décrits.
Par exemple, le terminal peut mettre en oeuvre le mode de réalisation MULT2 ou mode « Proxy » pour forcer l'envoi d'un message à destination de sa propre adresse IP et d'un numéro de port différent de celui utilisé pour contacter le proxy :
Si aucune réponse n'est reçue, alors il conclut à la présence d'une fonction à états sur le chemin.
Si au contraire une réponse est reçue, alors il conclut à l'absence de fonction à états sur le chemin.
En outre, il établit qu'aucune fonction de traduction d'adresse n'est présente sur le chemin lorsque que le message envoyé par le proxy en réponse à la commande du terminal a été acheminé avec succès et qu'il n'a pas subi de modification d'adresse IP/numéro de port destination. Il établit aussi qu'aucune fonction de filtrage n'est présente sur le chemin à partir du constat du fait que le paquet de réponse reçu a été envoyé depuis une adresse différente de celle utilisée pour contacter le proxy.
De façon alternative, le terminal Tl met en oeuvre le mode de réalisation MULT3 ou mode « MIRROR ». Dans ce cas, il envoie une trame « miroir » à un terminal T2 avec lequel il est déjà en communication et disposant de plusieurs adresses IP. Cette trame comprend une clé de sécurité, l'adresse IP du terminal Tl et un numéro de port destination différent de celui utilisé par le terminal Tl pour émettre la trame « miroir » comme décrit en relation avec les figures 15 à 17. Dès réception du message, le terminal distant T2 envoie un message de réponse ou trame TV vers l'adresse du terminal et le numéro de port destination indiqué dans la trame miroir. A réception du paquet de données comprenant une telle trame TV, ce dernier vérifie si le paquet contient la clé de sécurité CS renseignée dans la trame miroir. Dans l'affirmative, Tl conclut à l'absence de fonction à états sur le chemin et met à jour le statut STATUS de ce chemin en le positionnant à « OKON ».
On notera que si en théorie le mode de réalisation MULT1 est applicable à un terminal mono interface, il existe un risque que les paquets de données émis dans le réseau RC par le terminal Tl soient filtrés à leur retour par le réseau d'accès. En effet, ces paquets émis avec une adresse de ce réseau d'accès, une fois relayés par les noeuds intermédiaires imposés par le routage à la source, seront probablement traités comme une tentative d'usurpation d'adresse IP du terminal et seront donc bloqués.
La réception de tels paquets constitue d'ailleurs une indication que le réseau n'est pas protégé contre les attaques d'usurpation d'adresse IP (pour « spoofing », en anglais).
En relation avec les figures 4 et 18, on décrit maintenant le procédé de gestion d'au moins une communication selon un troisième mode de réalisation de l'invention et on considère plus particulièrement le cas où le terminal Tl a détecté la présence d'au moins une fonction à états sur le chemin associé à l'adresse @Tli. Il a donc positionné en 224 le statut de ce chemin à la valeur « OKOFF ».
Comme illustré par la figure 4, le procédé de gestion selon ce troisième mode de réalisation de l'invention met en oeuvre une étape optionnelle 225 de détermination d'un paramètre KA_TIMER représentatif d'une durée de vie d'une entrée instanciée par la fonction à états présente sur le chemin. On suppose que le procédé comprend une étape préalable (non représentée) d'extraction des éléments de la liste ACAL associés à un statut OKOFF et une étape de test pour vérifier si au moins un chemin a été extrait.
A titre d'exemple, on considère le cas de la figure 11, pour lequel seule l'adresse @Tli est associée au statut « OKOFF » et donc extraite.
Ensuite, comme illustré par la figure 18, le terminal Tl choisit une autre adresse de la liste ACAL, par exemple @T11, dont le statut est au contraire égal à « OKON ».
Il établit une communication depuis l'adresse extraite @Tli vers l'autre adresse @T11 et initialise le paramètre KA_TIMER à une valeur TO prédéterminée, par exemple de 15 secondes, comme recommandé dans le document intitulé « UDP Usage Guidelines », RFC 8085, publié par l'IETF en mars 2017.
Le terminal Tl émet ensuite des données via la communication établie, à une succession d'instants temporels, deux instants consécutifs de ladite succession d'instants étant séparés par un intervalle temporel, initialement fixé à T0 et doublé à chaque nouvelle émission de données, tant que la communication n'est pas perdue ou coupée. Dans l'exemple de la figure 18, la communication est perdue lorsque le paramètre KA_TIMER atteint la valeur KA_TIMER_LOSS égale à 960s.
A partir de la valeur obtenue pour KA_TIMER-LOSS, on dérive la durée de vie d'une entrée instanciée par la fonction à états présente sur le chemin. Par exemple, cette durée de vie est évaluée à la moitié de la valeur de l'intervalle temporel qui a induit la perte, c'est-à-dire KA_TIMER_LOSS/2 = 480s.
Avantageusement, cette durée de vie évaluée est mise à profit pour gérer plus efficacement les communications du terminal Tl au réseau de communication RC. En particulier elle est utilisée pour configurer le mécanisme « keepalive » et la fréquence des messages émis pour maintenir l'entrée d'une communication dans une table de fonction à états.
Bien sûr, l'invention n'est pas limitée à cet exemple d'implémentation de l'évaluation de la durée de vie, même s'il offre un bon compromis entre performances d'un mécanisme de maintien en vie et de risque de coupure de la communication.
On détaille maintenant en relation avec les figures 19A, 19B et 20 un exemple de réalisation de l'étape 23 de déclenchement d'une action de gestion d'au moins une communication impliquant un chemin réseau du terminal Tl.
Etape CONNECT (23) On suppose maintenant que la table ACAL du terminal Tl a été mise à jour et qu'en particulier, elle renseigne la valeur du paramètre STATUS de chaque adresse associée à chaque chemin disponible au niveau du terminal Tl pour accéder au réseau de communication RC. Avantageusement, elle comprend aussi la valeur de durée de vie KA_TIMER d'une fonction à états présente sur le chemin, le cas échéant.
S'il dispose de plusieurs chemins, le terminal Tl peut avantageusement exploiter les informations stockées dans la liste ACAL pour sélectionner celui sur lequel il est plus efficace d'établir une communication sortante. Par exemple, le terminal Tl peut sélectionner le chemin qui n'implique pas de fonction à états ou de façon alternative, un chemin qui comprend une fonction à états associée à une durée de vie KA_TIMER la plus élevée possible. En effet, la durée de vie d'une entrée maintenue par une fonction à états impacte directement la fréquence d'émission des messages de maintien en vie d'un mécanisme « keepalive » et donc la consommation énergétique du terminal.
Pour établir une communication QUIC avec un terminal distant T3, le terminal Tl inclut dans un message de la communication, tel que par exemple la requête d'établissement de la communication ou tout autre message, une nouvelle trame de contrôle appelée KEEPALIVE_CONTROL d'un mécanisme de maintien en vie d'une entrée maintenue par une fonction à états. Cette trame sert à transmettre au terminal T3 des informations pour la configuration du mécanisme de maintien en vie d'une entrée maintenue par une fonction à états destiné à être activée sur un ou plusieurs chemins reliant le terminal Tl au réseau.
Des exemples de format d'un tel message sont illustrés par les figures 19A et 19B. En relation avec la figure 19, on considère un format simple TCS destiné à être utilisé par un terminal qui dispose d'une interface réseau unique et en particulier d'un unique chemin réseau pour accéder au réseau de communication RC. Il peut aussi être utilisé pour caractériser une unique adresse source utilisée par le terminal Tl pour l'envoi d'un paquet de données QUIC.
La figure 19B présente un deuxième format TCM de message de contrôle d'un mécanisme de maintien en vie destiné à un terminal multi-interfaces, c'est-à-dire doté de plusieurs chemins pour accéder au réseau RC. La trame de ce message de contrôle comprend un champ représentatif d'un élément de type adresse IP, préfixe ou identifiant d'adresse IP, un champ de statut STATUS et un champ de durée de vie KA_TIMER. Les valeurs des paramètres STATUS et KA_TIMER sont extraites de la table ACAL du terminal Tl. Le champ KA_TIMER est optionnel. On notera que si ce champ est absent pour un élément ayant un STATUS égal à « OKON », cela signifie que la procédure de maintien en vie des entrées d'une fonction à états peut être désactivée en toute sécurité. Une ou plusieurs trames de contrôle KEEPALIVE_CONTROL peuvent être envoyées vers un même terminal distant. Par exemple, une trame de contrôle est envoyée par chemin disponible au niveau du terminal Tl ou bien une seule trame de contrôle inclut toutes les informations relatives à l'ensemble des chemins disponibles.
Comme illustré par la figure 20, à réception de la trame par le terminal distant T3, celui-ci extrait les informations qu'elle contient et les sauvegarde dans une table appelée ACAL_PEER. On comprend que cette table ACAL_PEER est une copie au moins partielle de celle maintenue par Tl. Le terminal distant T3 exploite avantageusement les informations de cette table pour décider sur quel chemin établir une communication avec Tl.
Dans l'exemple de la figure 20, on suppose que pour le chemin associé à l'adresse IP @T11, le statut reçu par T3 est positionné à « OKON », mais qu'aucune valeur de durée de vie KA-TIMER n'a été positionnée dans la trame KEEPALIVE_CONTROL. L'absence de valeur de durée de vie lorsque le statut est positionné à OKON est une indication qu'il n'y a pas de fonction à états sur le chemin. Ainsi, T3 sait qu'il peut envoyer des messages vers cette adresse de Tl sans l'avoir testée au préalable.
Le terminal distant T3 doit à son tour déterminer la valeur du paramètre KA_TIMER représentatif d'une durée de vie d'une entrée instanciée par la fonction à états présente sur le chemin entre l'adresse IP @T11 de Tl et ses propres chemins dans les réseaux d'accès N31, N32, ..., N3j avec j entier non nul, comme précédemment décrit en relation avec la figure 15. Ensuite, il les transmet aux terminaux avec lesquels il souhaite communiquer via le réseau de communication, comme par exemple le terminal Tl.
Le terminal Tl peut aussi décider d'ajouter un ou plusieurs nouveaux chemins à une communication établie avec le terminal T3 en fonction des valeurs relatives des paramètres STATUS et KA_TIMER obtenues pour un nouveau chemin par rapport à celles des chemins déjà utilisés. Par exemple, un terminal peut décider d'ajouter un nouveau chemin à la communication même s'il ne reçoit pas de données du terminal distant T3 via ce chemin.
On comprend que pour une communication établie entre Tl et T3, un chemin utilisé pour cette communication peut être associé à deux valeurs distinctes du paramètre KA_TIMER :
KA_TIMER (Local) et KA_TIMER(PEER). Dans ce cas, les terminaux doivent choisir la plus petite valeur entre les deux. Dans l'exemple de la figure 20, chaque terminal envoie à l'autre des trames de contrôle KEEPALIVE_CONTROL. Ainsi, chaque terminal dispose de sa propre table ACAL et celle du terminal distant ACAL(Peer).
On suppose par exemple que la première communication a été établie entre Tl et T3 via l'adresse IP @T11 de Nil et l'adresse @T31 de N31. En consultant la table ACAL(Peer), le terminal T3 décide d'ajouter un nouveau chemin via l'adresse IP @T3i de (N3 et l'adresse IP @T11 de Nil) à la communication. En outre, le terminal Tl décide d'ajouter le chemin @Tli de Nli et @T31 de N31 à la communication. Du fait que pour l'adresse @T11 de Nil et l'adresse @T31 de N31 le statut est positionné à « OKON » sans valeur de durée de vie KA_TIMER associée, les deux terminaux savent qu'aucune fonction à états n'a été détectée sur ces chemins et décident de ne pas activer le mécanisme « keepalive » de maintien en vie des entrées d'une fonction à états pour le chemin (Nil, N31). En revanche, pour les autres chemins utilisés par la communication, des valeurs de KA_TIMER étant renseignées, ils activent l'optimisation pour les autres chemins selon les consignes décrites dans leurs tables ACAL. Notamment, ils configurent une fréquence d'émission optimale des messages « keepalive » en fonction de la durée de vie KA_TIMER renseignée.
Ainsi, les deux terminaux peuvent chacun mettre en oeuvre l'invention qui vient d'être décrite.
Les terminaux peuvent envoyer de nouvelles trames de contrôle KEEPALIVE_CONTROL à chaque fois que nécessaire, comme par exemple en cas de modification de paramètres réseau, telle qu'un attachement à un nouveau réseau d'accès, l'obtention d'une nouvelle adresse IP, etc.
On présente maintenant, en relation avec la fig. 21, la structure matérielle d'un dispositif 100 de gestion d'au moins une communication d'un équipement terminal dans un réseau de communication, ledit équipement terminal étant apte à accéder audit réseau de communication via au moins deux chemins, undit chemin étant associé à une ressource IP, comprenant au moins une adresse IP et un numéro de port. Selon l'invention, le dispositif 100 comprend un module de détection d'une présence, sur au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur une adresse IP dudit équipement terminal dite deuxième adresse IP d'au moins une fonction à états configurée pour maintenir dans une table un état associé à une communication sur ledit chemin pendant une durée de vie déterminée, comprenant l'émission dans le réseau de communication d'un premier message depuis au moins une première ressource IP dudit équipement terminal, ladite première ressource IP comprenant une première adresse IP et un premier numéro de port vers une deuxième ressource IP dudit équipement terminal, comprenant ladite deuxième adresse IP et un deuxième numéro de port, et la décision de présence d'au moins une fonction à états sur ledit au moins un chemin en fonction de données reçues par la deuxième ressource IP en réponse à l'émission du premier message, et un module de déclenchement d'une action de gestion d'une communication de l'équipement terminal sur ledit au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur ladite deuxième adresse IP, en fonction de ladite détection. Avantageusement, le dispositif 100 comprend un module d'obtention d'une liste des chemins reliant le terminal au réseau via une adresse IP de ce terminal, dit deuxième adresse IP, et un module d'obtention d'une liste des communications candidates entre une première ressource comprenant une première adresse IP et un premier numéro de port et une deuxième ressource IP comprenant la deuxième adresse IP et un deuxième numéro de port.
Avantageusement, le dispositif 100 comprend aussi un module de détermination de la durée de vie associée à un état d'une communication établie sur ledit chemin par ladite au moins une fonction à états détectée sur le chemin.
Avantageusement, le dispositif 100 comprend en outre un module de mise à jour d'un statut représentatif de la présence ou de l'absence d'une fonction à états sur ledit chemin en fonction de la décision, le cas échéant de la durée de vie associé à un état de la communication par la fonction à états détectée et le module de déclenchement d'une action de gestion est configurée pour déclencher ladite action en fonction du statut et/ou de la durée de vie associée.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions.
Plus généralement, un tel dispositif de gestion d'une communication 100 comprend une mémoire vive 103 (par exemple une mémoire RAM), une unité de traitement 102 équipée par exemple d’un processeur, et pilotée par un programme d’ordinateur Pgl, représentatif du module de détection d'une présence de fonction à états sur ledit au moins un chemin et du module de déclenchement d'au moins une action de gestion sur ledit au moins un chemin, et optionnellement des modules d'obtention de la liste des chemins, d'obtention de la liste des communications candidates, de mise à jour d'un statut et de détermination d'une durée de vie , stocké dans une mémoire morte 101 (par exemple une mémoire ROM ou un disque dur). A l’initialisation, les instructions de code du programme d’ordinateur sont par exemple chargées dans la mémoire vive 103 avant d’être exécutées par le processeur de l’unité de traitement 102. La mémoire vive 103 contient notamment la table de chemins ACAL, la liste des communications candidates PCL et stocke pour chaque chemin les paramètres de statut et, le cas échéant, de durée de vie KA_TIMER associés. Le processeur de l'unité de traitement 102 pilote l'obtention de la liste de chemins, la détection de présence de fonctions à états sur les chemins listés et le déclenchement d'action de gestion de communication sur les chemins listés, conformément au logigramme de la figure 2. Avantageusement, elle stocke aussi les tables de chemin ACAL-PEER transmises par d'autres terminaux. La figure 21 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif de gestion d'une communication 100, afin qu'il effectue les étapes du procédé de gestion d'une communication d'un équipement terminal tel que détaillé ci-dessus, en relation avec la figure 2 dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le dispositif 100 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif de gestion d'une communication 100 intégré à un équipement terminal Tl 10, tel que par exemple un téléphone mobile de type téléphone intelligent (pour « smartphone », en anglais), un ordinateur de type PC (pour « Personal Computer », en anglais) ou une tablette, mais il peut aussi, comme décrit en relation avec la figure 12 être embarqué dans n'importe quel équipement d'accès de type CPE à un réseau de communication, tel qu'une passerelle domotique, pourvu qu'il dispose d'un accès à un réseau étendu, tel que par exemple le réseau Internet.
On présente enfin, en relation avec la figure 22, la structure matérielle d'un dispositif 200 de traitement d'une communication établie entre un premier équipement terminal et un deuxième équipement terminal via un réseau de communication, comprenant au moins un module de réception, en provenance d'une première ressource IP d'un premier équipement terminal, d'un message comprenant au moins une commande d'émission d'une réponse à destination d'au moins une deuxième ressource IP du premier équipement terminal, distincte de la première, et d'insertion d'une information de sécurité dans la réponse, un module d'extraction de ladite au moins une deuxième ressource IP et de ladite information de sécurité et un module d'émission à destination de ladite au moins une deuxième adresse d'une réponse ou trame TV comprenant ladite information de sécurité.
Avantageusement, le dispositif 200 comprend en outre un module de stockage d'une table de chemins ACAL_PEER reçue du premier équipement terminal.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions.
Plus généralement, un tel équipement dispositif 200 comprend une mémoire vive 203 (par exemple une mémoire RAM), une unité de traitement 202 équipée par exemple d’un processeur, et pilotée par un programme d’ordinateur Pg2, représentatif des modules de réception, d'extraction et d'émission, stocké dans une mémoire morte 201 (par exemple une mémoire ROM ou un disque dur). A l’initialisation, les instructions de code du programme d’ordinateur sont par exemple chargées dans la mémoire vive 203 avant d’être exécutées par le processeur de l’unité de traitement 32. La mémoire vive 203 contient notamment les deuxièmes ressources IP et l'information de sécurité extraites du message de commande reçu du premier équipement terminal. Elle peut comprendre aussi la ou les tables de chemins ACAL_PEER transmises par le premier équipement termina et éventuellement d'autres terminaux. Le processeur de l'unité de traitement 202 pilote la réception du message, l'extraction d'au moins une deuxième ressource IP du premier équipement terminal et d'une information de sécurité comprises dans ledit message, l'émission d'un message de réponse comprenant l'information de sécurité à destination de ladite au moins une deuxième ressource IP du premier équipement terminal, conformément au logigramme de la figure 14.
La fig. 22 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif de traitement 200, afin qu'il effectue les étapes du procédé de traitement d'une communication détaillé ci-dessus, en relation avec la figure 14. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le dispositif de traitement d'une communication 200 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif de traitement d'une communication 200 intégré à un équipement terminal T2, Tl, tel que par exemple un téléphone mobile de type téléphone intelligent (pour « smartphone », en anglais), un ordinateur de type PC (pour « Personal computer », en anglais) ou une tablette, mais il peut aussi, comme décrit en relation avec la figure 12 être embarqué dans n'importe quel équipement d'accès de type CPE à un réseau de communication, tel qu'une passerelle résidentielle, pourvu qu'il dispose d'un accès à un réseau .
L'invention qui vient d'être décrite propose de détecter dynamiquement la présence de fonctions à états dans un réseau de communication sur des chemins d'accès d'un terminal à ce réseau. Cette détection de présence est exploitée pour gérer les communications en conséquence et ainsi améliorer leur qualité tout en optimisant les ressources énergétiques mises en jeu notamment par les équipements terminaux.
L'invention permet notamment :
d'optimiser la consommation des batteries des terminaux mobiles ;
- d'optimiser la sélection des chemins/adresses pour l'établissement de communications ; d'optimiser l'acheminement du trafic dans le réseau ;
de faciliter l'établissement de nouvelles communications depuis une adresse d'un terminal distant même si aucune donnée n'a encore été reçue depuis cette adresse ;
d'éviter les problèmes d'établissement de communications liés à la présence de fonctions avec état, telles que les fonctions NAT ou pare-feu ;
d'optimiser la valeur de la fréquence d'émission des messages « keepalive » par communication, en tenant compte de la présence éventuelle de fonctions à états sur un chemin emprunté par la communication.

Claims

REVENDICATIONS
1. Procédé de gestion d'au moins une communication selon un protocole de transport d'un équipement terminal dans un réseau de communication, ledit équipement terminal étant apte à accéder audit réseau de communication via au moins une ressource IP, chaque ressource IP comprenant une adresse IP et un numéro de port, caractérisé en ce qu'il comprend :
la détection (22) d'une présence, sur au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur une adresse IP dudit équipement terminal dite deuxième adresse IP d'au moins une fonction à états configurée pour maintenir dans une table un état associé à une communication sur ledit chemin pendant une durée de vie prédéterminée, comprenant l'émission dans le réseau de communication d'un premier message depuis au moins une première ressource IP dudit équipement terminal, ladite première ressource IP comprenant une première adresse IP et un premier numéro de port vers une deuxième ressource IP dudit équipement terminal, comprenant ladite deuxième adresse IP et un deuxième numéro de port, et la décision de présence d'au moins une fonction à états sur ledit au moins un chemin en fonction de données reçues par la deuxième ressource IP en réponse à l'émission du premier message; et
le déclenchement (23) d'une action de gestion d'une communication de l'équipement terminal sur ledit au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur ladite deuxième adresse IP, en fonction de ladite détection.
2. Procédé de gestion d'une communication selon la revendication 1, caractérisé en ce qu'une présence d'au moins une fonction à états sur le chemin est décidée, lorsque les données reçues comprennent un message d'erreur ou lorsqu'aucune donnée n'est reçue par la deuxième ressource IP en réponse à l'émission du premier message par au moins une dite première ressource IP.
3. Procédé de gestion d'une communication selon l'une des revendications 1 à 2, caractérisé en ce que le premier message comprend une requête d'établissement d'une communication entre ladite au moins une première ressource IP et la deuxième ressource IP de l'équipement terminal et en ce qu'une décision d'absence de fonction à états sur le chemin reliant ladite au moins une première ressource IP à la deuxième ressource IP via ledit réseau est prise lorsque les données reçues par la deuxième ressource IP de l'équipement terminal comprennent le premier message.
4. Procédé de gestion d'une communication selon la revendication 3, caractérisé en ce qu'il comprend le masquage d'informations de routage associées à ladite deuxième ressource IP et contenues dans ladite requête d'établissement de ladite communication, préalablement à son émission.
5. Procédé de gestion d'une communication selon la revendication 3, caractérisé en ce qu'il comprend, préalablement à l'émission de la requête d'établissement de la communication, l'enregistrement d'une information d'identification d'au moins un équipement de routage du réseau de communication associé à ladite au moins une première ressource IP.
6. Procédé de gestion d'au moins une communication selon l'une des revendications 1 à 2, caractérisé en ce qu'une communication (CE12) étant établie entre ladite au moins une première ressource IP de l'équipement terminal (Tl) et une ressource IP d'un deuxième équipement terminal (T2), ledit premier message est émis via ladite communication à destination de ladite ressource IP du deuxième équipement terminal (T2), ledit premier message comprend au moins une commande d'émission d'une réponse à destination de la deuxième ressource IP et une commande d'insertion d'une information de sécurité dans ladite au moins une réponse et en ce qu'une décision d'absence de fonction à états sur le chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur la deuxième ressource IP est prise lorsque les données reçues sur ladite deuxième ressource IP de l'équipement terminal (Tl) comprennent ladite réponse.
7. Procédé de gestion d'une communication selon l'une des revendications 1 à 6, caractérisé en ce que, lorsque la présence d'au moins une fonction à états a été détectée sur ledit au moins un chemin, le procédé comprend la détermination d'une période temporelle d'émission d'un message de maintien en vie d'un état d'une communication établie sur ledit au moins un chemin par ladite au moins une fonction à états, le stockage de la période déterminée et la prise en compte de la période déterminée dans la décision d'une action de gestion sur une communication via ledit chemin.
8. Procédé de gestion d'une communication selon la revendication 7, caractérisé en ce que ladite détermination comprend :
l'établissement d'une communication sur ledit chemin associée à la deuxième adresse IP, en provenance d'une ressource IP comprenant une adresse IP de l'équipement terminal, distincte de la deuxième, associée à un chemin permettant de joindre ledit équipement terminal via ledit réseau, pour lequel aucune présence de fonction à états n'a été détectée;
l'émission de données via la communication établie, à une succession d'instants temporels, deux instants consécutifs de ladite succession d'instants étant séparés par un intervalle temporel, ledit intervalle ayant une valeur courante initialisée à zéro et doublée à chaque nouvelle émission de données, tant que la communication n'est pas perdue ; et la mise à jour d'un paramètre représentatif de ladite période, en lui affectant une valeur égale à la moitié de la valeur courante de l'intervalle temporel ;
9. Procédé de gestion d'une communication selon l'une des revendications 1 à 8, caractérisé en ce que le procédé comprend la mise à jour d'un statut représentatif d'une configuration d'un mécanisme de maintien en vie d'une fonction à états, ledit statut étant associé audit au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur la deuxième adresse IP de l'équipement terminal en fonction de ladite au moins une décision prise pour ledit au moins un chemin.
10. Procédé de gestion d'une communication selon l'une quelconque des revendications précédentes, caractérisé en ce que l'action de gestion déclenchée comprend l'établissement d'une communication via ledit chemin de l'équipement terminal sans activer de mécanisme de maintien en vie d'un état associé à la communication lorsqu'il n'a pas été détecté de fonction à états sur ledit chemin et l'établissement de la communication via ledit chemin en activant un mécanisme de maintien en vie dudit état associé à la communication lorsqu'une fonction à états a été détectée sur ledit chemin.
11. Procédé de gestion d'une communication selon l'une des revendications 7 à 10, caractérisé en ce que, lors de l'établissement d'une communication avec un autre équipement terminal depuis l'adresse IP de la deuxième ressource IP de l'équipement terminal, l'action de gestion déclenchée comprend l'émission dans la requête d'établissement de ladite communication ou au cours de ladite communication du statut dudit au moins un chemin associé à ladite adresse IP et/ou de la période temporelle déterminée.
12. Dispositif (100) de gestion d'au moins une communication d'un équipement terminal dans un réseau de communication, ledit équipement terminal étant apte à accéder audit réseau de communication via au moins une ressource IP, caractérisé en ce qu'il est configuré pour :
détecter une présence, sur au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur une adresse IP dudit équipement terminal dite deuxième adresse IP d'au moins une fonction à états configurée pour maintenir dans une table un état associé à une communication sur ledit chemin pendant une durée de vie prédéterminée, comprenant l'émission dans le réseau de communication d'un premier message depuis au moins une première ressource IP dudit équipement terminal, ladite première ressource IP comprenant une première adresse IP et un premier numéro de port vers une deuxième ressource IP dudit équipement terminal, comprenant ladite deuxième adresse IP et un deuxième numéro de port, et la décision de présence d'au moins une fonction à états sur ledit au moins un chemin en fonction de données reçues par la deuxième ressource IP en réponse à l'émission du premier message; et
déclencher une action de gestion d'une communication de l'équipement terminal sur ledit au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement terminal sur ladite deuxième adresse IP, en fonction de ladite détection.
13. Procédé de traitement d'une communication établie selon un protocole de transport entre un premier équipement terminal et un deuxième équipement terminal dans un réseau de communication via au moins une ressource IP du premier équipement terminal, chaque ressource IP comprenant une adresse IP et un numéro de port, caractérisé en ce qu'il comprend :
la réception (300), en provenance de ladite première ressource IP d'un message comprenant l'adresse IP, dite première adresse IP et le numéro de port, dit premier numéro de port, de ladite première ressource IP ledit message comprenant une commande d'émission d'une réponse à destination d'au moins une deuxième ressource IP du premier équipement terminal, distincte de la première et comprenant une deuxième adresse IP et un deuxième numéro de port, et une commande d'insertion d'une information de sécurité dans la réponse ;
l'extraction (301) de ladite au moins une deuxième ressource IP et de ladite information de sécurité de la dite commande ;
l'émission (303) à destination de ladite au moins une deuxième adresse IP et dudit deuxième numéro de port d'au moins une réponse (TV) comprenant ladite information de sécurité.
14. Procédé de traitement d'une communication établie sur un protocole de transport entre un premier équipement terminal et un deuxième équipement terminal dans un réseau de communication via au moins une ressource IP du premier équipement terminal, chaque ressource IP comprenant une adresse IP et un numéro de port, caractérisé en ce qu'il comprend
la réception sur une ressource IP du deuxième équipement terminal, dite ressource IP destination, d'un message relatif à une communication établie ou à établir en provenance d'une ressource IP du premier équipement terminal (Tl), dite ressource IP source, ledit message comprenant un statut représentatif d'une configuration d'un mécanisme de maintien en vie d'une entrée d'une table maintenue par une fonction à états, ladite entrée associant un état à une communication sur un chemin permettant de joindre via ledit réseau de communication ledit premier équipement terminal sur l'adresse IP de la ressource IP source pendant une durée de vie prédéterminée, ledit statut étant associé à ladite adresse IP, et une période temporelle représentative d'une fréquence d'émission d'un message de maintien en vie d'un état de la communication ; l'ajustement dudit statut et de ladite période en fonction de valeurs de statut et de période stockées en mémoire en association avec ladite adresse IP destination; et l'émission d'une réponse comprenant les valeurs ajustées.
15. Dispositif (200) de traitement d'une communication entre un premier équipement terminal et un deuxième équipement terminal via un réseau de communication établie sur un protocole de transport, ledit dispositif étant caractérisé en ce qu'il est configuré pour mettre en oeuvre procédé de traitement d'une communication selon la revendication 13 et/ou la revendication 14.
16. Equipement terminal (Tl, 10) apte à accéder à un réseau de communication depuis au moins une ressource IP, comprenant une adresse IP et un numéro de port, caractérisé en ce qu'il comprend un dispositif de gestion d'au moins une communication depuis ladite ressource selon la revendication 12.
17. Equipement terminal (T2, 11, Tl, 10) selon la revendication 16, caractérisé en ce qu'il comprend en outre un dispositif de traitement d'une communication selon la revendication 15.
18. Equipement proxy (P) d'un réseau de communication, apte à connecter un équipement terminal audit réseau, caractérisé en ce qu'il comprend un dispositif de gestion d'au moins une communication selon la revendication 12.
19. Equipement nœud d'un réseau de communication apte à recevoir sur au moins une ressource IP comprenant une adresse IP et un numéro de port, des données d'une communication entre une ressource IP, dite ressource IP source, d'un premier équipement terminal et une ressource IP d'un deuxième équipement terminal, dite ressource IP destination, et à les retransmettre depuis ladite au moins une ressource IP, caractérisé en ce qu'il est configuré pour :
détecter une présence, sur au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement nœud sur une ressource IP dudit équipement terminal dite deuxième ressource IP, d'au moins une fonction à états configurée pour maintenir dans une table un état associé à une communication sur ledit chemin pendant une durée de vie déterminée, comprenant l'émission dans le réseau de communication d'un premier message depuis au moins une première ressource IP dudit équipement nœud vers ladite deuxième adresse IP dudit équipement terminal et la décision de présence d'au moins une fonction à états sur ledit au moins un chemin en fonction de données reçues par la deuxième ressource IP en réponse à l'émission du premier message ; et
déclencher une action de gestion d'une communication de l'équipement terminal sur ledit réseau de communication via ledit chemin en fonction de ladite détection.
20. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d'un procédé selon l'une quelconque des revendications 1 à 11 et 13 à 14 lorsqu'il est exécuté par un processeur.
EP20747035.2A 2019-06-28 2020-06-24 Procede de gestion d'au moins une communication d'un equipement terminal dans un reseau de communication, procedes de traitement d'une communication etablie avec un equipement terminal dans un reseau de communication, dispositifs, equipement terminal, equipement proxy et programmes d'ordinateur correspondants Pending EP3991358A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1907105A FR3096530A1 (fr) 2019-06-28 2019-06-28 Procédé de gestion d’au moins une communication d’un équipement terminal dans un réseau de communication, procédés de traitement, dispositifs, équipement terminal, équipement proxy et programmes d’ordinateur correspondants
PCT/FR2020/051103 WO2020260826A1 (fr) 2019-06-28 2020-06-24 Procede de gestion d'au moins une communication d'un equipement terminal dans un reseau de communication, procedes de traitement d'une communication etablie avec un equipement terminal dans un reseau de communication, dispositifs, equipement terminal, equipement proxy et programmes d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP3991358A1 true EP3991358A1 (fr) 2022-05-04

Family

ID=68733166

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20747035.2A Pending EP3991358A1 (fr) 2019-06-28 2020-06-24 Procede de gestion d'au moins une communication d'un equipement terminal dans un reseau de communication, procedes de traitement d'une communication etablie avec un equipement terminal dans un reseau de communication, dispositifs, equipement terminal, equipement proxy et programmes d'ordinateur correspondants

Country Status (5)

Country Link
US (1) US11979276B2 (fr)
EP (1) EP3991358A1 (fr)
CN (1) CN114303346B (fr)
FR (1) FR3096530A1 (fr)
WO (1) WO2020260826A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115102924B (zh) * 2022-06-25 2023-09-19 平安银行股份有限公司 集群地址切换方法、装置、计算机设备及存储介质
US12328256B2 (en) * 2022-08-10 2025-06-10 Palo Alto Networks, Inc. Supporting overlapping network addresses universally
CN119182751B (zh) * 2024-08-30 2025-11-07 新华三技术有限公司 Sdwan中的数据通信方法、装置、系统及电子设备

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020078198A1 (en) * 2000-02-25 2002-06-20 Buchbinder John E. Personal server technology with firewall detection and penetration
CN101120550A (zh) * 2005-01-07 2008-02-06 松下电器产业株式会社 通信系统、资源管理设备和方法以及通信管理设备和方法
ATE426283T1 (de) * 2005-12-15 2009-04-15 Nokia Corp Verfahren, apparat und computerprogrammprodukt zur beibehaltung von abbildungszuordnungen
FR3019421A1 (fr) * 2014-03-31 2015-10-02 Orange Procede de communication par chemins multiples entre deux terminaux
US10104167B2 (en) * 2015-09-28 2018-10-16 Verizon Patent And Licensing Inc. Networking functions in a micro-services architecture
US20190052711A1 (en) * 2017-08-10 2019-02-14 Morega Systems Inc. System and method for peer-to-peer connectivity
US10476800B2 (en) * 2017-10-16 2019-11-12 Verizon Digital Media Services Inc. Systems and methods for load balancing virtual connection traffic
US10602551B2 (en) * 2018-06-27 2020-03-24 Charter Communications Operating, Llc Methods and apparatus for testing alternative wireless connections and selecting a wireless connection
US10791485B2 (en) * 2018-10-16 2020-09-29 Cisco Technology, Inc. Systems and methods for quick user datagram protocol internet connection (QUIC) with multipath

Also Published As

Publication number Publication date
US11979276B2 (en) 2024-05-07
WO2020260826A1 (fr) 2020-12-30
FR3096530A1 (fr) 2020-11-27
CN114303346A (zh) 2022-04-08
US20220239556A1 (en) 2022-07-28
CN114303346B (zh) 2025-01-14

Similar Documents

Publication Publication Date Title
EP3739843B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
EP2494747B1 (fr) PROCÉDÉS ET DISPOSITIFS DE ROUTAGE DE PAQUETS DE DONNÉES ENTRE RÉSEAUX IPv4 ET IPv6
EP3476095A1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
EP3284224B1 (fr) Procédé d'émulation dune connexion à chemins multiples
EP3987752B1 (fr) Procede et dispositif d'obtention d'une adresse ip
EP3172887A1 (fr) Procédé de communication tcp via des chemins multiples entre deux terminaux
WO2020260826A1 (fr) Procede de gestion d'au moins une communication d'un equipement terminal dans un reseau de communication, procedes de traitement d'une communication etablie avec un equipement terminal dans un reseau de communication, dispositifs, equipement terminal, equipement proxy et programmes d'ordinateur correspondants
EP2997717A1 (fr) Procede et dispositif de selection d'interface de communication
EP4142265B1 (fr) Procede de communication tcp via des chemins multiples entre deux terminaux
EP3373558B1 (fr) Procédé de communication pour assurer le maintien d'une session applicative entre un terminal et un serveur d'application
EP3526956B1 (fr) Procédé de négociation d'une qualité de service offerte par une passerelle à des terminaux
EP2579545B1 (fr) Méthode d'attribution d'une adresse réseau publique à un équipement disposant d'une adresse réseau privée
WO2019211548A1 (fr) Procédé d'envoi d'une information et de réception d'une information pour la gestion de réputation d'une ressource ip
EP4037289A1 (fr) Procede de determination si une adresse ip est attribuee a un terminal dans un reseau de communication
WO2025078594A1 (fr) Procédés de sélection de tranches réseau adaptées à un service, de gestion d'au moins une tranche réseau et de communication, et entités configurées pour mettre en œuvre ces procédés
FR3143150A1 (fr) Procédé de gestion d’un ensemble d’adresses IP, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés.
EP2053833A1 (fr) Procédé de traduction d'entête de paquets de données
WO2007060364A1 (fr) Procede pour selectionner dans un routeur une route parmi au moins deux routes relatives a une meme adresse reseau de destination

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: 20211223

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

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

17Q First examination report despatched

Effective date: 20231130