FR3096530A1 - 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 - Google Patents

Abstract

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 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. fig. 2

Description

Description Titre de l'invention : Procédé de gestion d'au moins une commu- nication d'un équipement terminal dans un réseau de commu- nication, procédés de traitement, dispositifs, équipement terminal, équipement proxy et programmes d'ordinateur correspondants Domaine de l'invention

[0001] Le domaine de l'invention est celui d'un réseau de communication et plus particu- lièrement de la gestion des communications d'un équipement terminal dans un tel réseau.

[0002] 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

[0003] 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 handshakc », 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.

[0004] Afin de supporter tout changement d'adresse IP sans avoir à clôturer une commu- nication 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.

[0005] Actuellement, le protocole QUIC supporte un mécanisme de migration de connexions (pour « Connection migration », en anglais) qui permet de maintenir une 2 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 « Nctwork Addrcss 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.

[0006] Cependant, la présence de fonctions à états telles que les fonctions NAT, parc-feu (ou « fircwall », 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.

[0007] 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.

[0008] 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.

3 100091 Or, ce mécanisme est coûteux en ressources, aussi bien pour le réseau qu'il surcharge que pour l'équipement tenninal, dont il sollicite les ressources de calcul, voire augmente la consommation d'énergie clans le cas d'un équipement terminal fonctionnant sur batterie, tel qu'un terminal mobile.

[0010] A cet égard, la désactivation de cc mécanisme « keepalive » permet de multiplier par 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 « keepal ive » 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 « keepal ive » requis par application embarquée dans l'équipement terminal est plus réduit.

[0011] 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

[0012] 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 IF, en fonction de ladite détection.

[0013] 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.

[0014] 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).

[0015] L'invention est adaptée à tout type de protocole de transport, en particulier le protocole QUIC.

[0016] 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.

[0017] 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 5 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.

[0018] 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.

[0019] 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.

[0020] Un avantage est d'étnuler 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.

[0021] 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.

[0022] 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.

[0023] 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 6 sur ladite deuxième ressource IP de l'équipement terminal (Ti) comprennent ladite réponse.

[0024] Un avantage de cc 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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 7 ressource IP de l'équipement terminal en fonction de ladite au moins une décision prise pour ledit au moins un chemin.

[0030] 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 cocas 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.

[0031] 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. 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 commu- nication, ce qui permet d'économiser les ressources des terminaux et du réseau.

[0032] Selon un autre aspect de l'invention, lors de l'établissement d'une communication avec un autre équipement temainal 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.

[0033] 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 temainal 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 à 8 une communication.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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é.

[0039] L'invention concerne également un dispositif de gestion d'au moins une commu- nication 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 9 - 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.

[0040] 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.

[0041] 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.

[0042] Le dispositif peut aussi être intégré dans équipement proxy d'un réseau de commu- nication, apte à relayer les données émises par un équipement terminal connecté audit réseau.

[0043] 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.

[0044] Corrélativement, l'invention concerne aussi un procédé de traitement d'une commu- nication é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é.

[0045] 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é.

[0046] Corrélativement, l'invention concerne encore un procédé de traitement d'une com- munication 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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 11 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.

[0052] 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é.

[0053] 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 configure pour mettre en oeuvre un procédé de traitement d'une communication précité.

[0054] 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é.

[0055] 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.

[0056] L'invention concerne enfin un équipement noeud 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 noeud 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 noeud 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.

[0057] Ainsi, l'invention est mise en oeuvre de façon récursive par les différents équipements noeuds mis en jeu sur le chemin testé.

12 Liste des figures 100581 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 : 100591 Ifie.11 : 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;

[0060] [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;

[0061] [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;

[0062] [fig.313] : 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;

[0063] [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;

[0064] [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;

[0065] [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;

[0066] [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 ;

[0067] [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;

[0068] [fig.8B] : cette figure illustre de façon schématique la réception de la requête de com- munication à l'adresse de l'équipement terminal émetteur selon cette première option;

[0069] [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;

[0070] [fig.10] : cette figure représente de façon schématique les communications directes 13 établies par un équipement terminal entre deux de ses propres interfaces selon un premier exemple de réalisation de l'invention ;

[0071] [fig.1 1] : 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 ;

[0072] [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 ;

[0073] [fig.13] : cette figure représente un exemple de mise en oeuvre de l'invention lorsque l'équipement terminal a été configure avec un équipement proxy situé dans le réseau de communication;

[0074] [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;

[0075] [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 ;

[0076] [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 ;

[0077] [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 ;

[0078] [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 ;

[0079] [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 ;

[0080] [fig.1913] : 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 14 l' invention ;

[0081] [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 ;

[0082] [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

[0083] [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.

[0084] Description détaillée de modes de réalisation de l'invention

[0085] Principe général

[0086] 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.

[0087] 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é.

[0088] 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.

[0089] 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 dc transport UDP ou UDP-lite (de l'anglais « Lightweight User Datagram Protocol ») niais dont les primitives et la charge utile sont chiffrées.

[0090] 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, BlucTooth, Zigbec, ou autre.

[0091] On désigne génériquement par réseau de communication un réseau de commu- nication de type Internet auquel peut accéder l'équipement terminal par un ou plusieurs réseaux d'accès à cc réseau.

[0092] 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.

[0093] 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.

[0094] 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 ».

[0095] 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.

[0096] 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.

[0097] Un ou plusieurs adresses ou préfixes peuvent être alloués à un équipement terminal 16 par un réseau d'accès.

[0098] On désigne par ressource IP un couple comprenant une adresse IP et un numéro de port.

[0099] Dans la suite dc la description, on s'attache à décrire plus en détails le cas de commu- nications é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, niais l'invention s'applique plus généralement à tout type de fonction à états.

[0100] 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 Ti à 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 @Tl 1 de l'équipement terminal Tl via un réseau d'accès N11 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 ième chemin Ci associé à une adresse @Tl i de l'équipement terminal Ti via un réseau d'accès NI i, avec i entier non nul.

[0101] 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.

[0102] Au cours d'une étape 20, on vérifie, par exemple au démarrage du terminal Ti, 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 Ti, une entrée associant au moins une valeur de statut STATUS à l'adresse @T li.

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.

[0103] 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 Ti, 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. 17

[0104] 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/rfc1918, 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 ruRL suivante : https://tools.ietf.org/html/rfc6598, les adresses IPv6 de type LLA ( « Link Local Addrcss », en anglais) ou ULA ( « Unique Local Addrcss », 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.

[0105] 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.

[0106] En 22, on détecte la présence d'au moins une fonction à états, sur au moins un chemin permettant de joindre le terminal Ti 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.

[0107] Pour réaliser cette détection, on utilise les communications candidates de la liste PCL.

[0108] 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.

[0109] On comprend que la détection de présence d'une fonction à états pour une des com- munications 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 W.

[0110] 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 18 détection.

[0111] 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.

[0112] 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.

[0113] Etapc LIST PCL

[0114] Cette étape a donc pour objectif de créer la liste PCL à partir de la liste ACAL.

[0115] 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).

[0116] On notera que la liste ACAL des chemins disponibles au niveau du terminal Ti 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, wlan0), des noms de réseau, etc.

Dans la suite on fera donc référence aux éléments de la liste ACAL.

[0117] 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 Ti, 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 SRCI, ne doit pas précéder une entrée avec une destination SRCI.

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 SRCI.

Lors du test d'une communication avec SRCI comme destination, cette fonction à états pourrait 19 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.

[0118] Les figures 3A et 3B illustrent deux exemples de construction de la liste PCL à partir de la liste ACAL comprenant les éléments N11, N12, ..., Nli.

Ces deux exemples satisfont les contraintes listées ci-dessus.

[0119] L'exemple de la figure 3A génère la liste PCL suivante : {N11, N12}, {N12, N13}, {N13, N14}, ..., {Nli-1, Nil}, {Nli,N111.

[0120] L'exemple de la figure 3B génère la liste PCL suivante : {N11, N12}, {N11, N13}, {N11, N14}, ..., {Nli,Nli-2}, {Nli,Nli-1}, {N1 i, N11}.

[0121] 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.

[0122] Mode de réalisation MULT1 ou mode « autonome »

[0123] 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 IF 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é.

[0124] 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 TI.

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.

[0125] En effet, comme illustré par la figure 5, une commuication depuis une nouvelle adresse @Tli peut être établie avec l'adresse erril même en présence d'un NAT si une communication depuis cette adresse @TB 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 T11 établit une communication avec un terminal distant TU, 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 T11 (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 à Ti i.

De cc fait, n'importe quelle communication entrante à destination de (212.25.26.25:1234) sera acheminée vers T11 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.

[0126] 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 « Addrcss Dependent Filtering », en anglais), illustré par la figure 6, ou le filtrage APDM/APDF (pour « Addrcss Port Dependent 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 T11 é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 T11 (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.

[0127] 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 T11 (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.

[0128] 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 Ti.

Dans l'affirmative, on déclare en 223 que la communication candidate (@T ii, 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.

[0129] Dans la négative, on décide que le chemin (@TI1, PS, @Tli, PD) est inutilisable en l'absence d'une communication sortante et on positionne le statut PATH_STATUS associé à NOP. 21

[0130] Enfin, si un message d'erreur a été reçu, par exemple de type ICMP avec une in- dication 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.

[0131] 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.

[0132] L'enchaînement d'étapes 220 à 223 est ensuite répété tant qu'il reste des commu- nications candidates à tester.

[0133] 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).

[0134] Selon une deuxième option, seule une partie des communications est établie conformément à une politique locale au terminal Ti.

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.

[0135] 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.

[0136] En revanche, si la liste PCL est construite comme suit : R@T11,@T12), (@T12,@T13), (@Tii-1,@T li), ( @TH, @Tl 1)], alors les communications candidates seront nécessairement établies séquentiellement.

[0137] 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 @T ik 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 « Optirnized 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 @Tl k a son statut positionné à NOP, alors on décide que le chemin associé à l'adresse IP @Tl k 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.

[0138] 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.

[0139] Pour ce faire, deux options sont envisagées : Option MULT1.1 : Filtre MP-BLIND

[0140] 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 BLIND(@T1D) de masquage de l'interface correspondant à l'adresse IP de destination de la communication candidate eTID du terminal T 1 .

[0141] Ce paramètre MP_BLIND(Interface 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 »).

[0142] 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.

[0143] Ce faisant, la requête d'établissement d'une communication entre les adresses @TIS, @TID} invoquée avec le paramètre MP_BUND a pour conséquence d'envoyer le paquet comprenant cette requête vers le routeur par défaut associé à l'adresse IP source @T1S.

[0144] 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 « eth0 » et ethl ».

[0145] t1:-# ip rule show

[0146] 0: front ail lookup local

[0147] 32764: front 1.2.3.2 lookup 2 23

[0148] 32765: from 10.20.30.2 lookup I

[0149] 32766: from ail hzokup main

[0150] 32767: from ail hzokup default

[0151] t1:--# ip route

[0152] 1.2.3.0/24 dey eth0 prolo kerne' scope link sise- 1.2.3.2

[0153] 1(120.3(10/24 dey ethl prolo kertzel scope link src 1(120.3(12

[0154] default via 1.2.3.1 dey eth0

[0155] Table 1

[0156] Supposons par exemple que le terminal veuille établir une communication entre les adresses IP source et destination { @Tl S=1.2.3.2, @Tl D=10.20.30.2}.

Cette communication a vocation à être traitée localement car l'adresse de destination est celle de l'interface « ethl ».

[0157] 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(eth1).

La table de routage invoquée (table 2 ) est indiquée ci-dessous.

Le paquet est alors transmis à l'équipement de routage R1 comme illustré par la figure 8A.

[0158] d ip route show table 2

[0159] 1.2.3.0/24 dey eth0 scope link

[0160] default via 1.2.3.1 dev eth0

[0161] Table 2

[0162] Si aucune fonction à états n'est présente sur le chemin reliant le terminal Ti au réseau RC via l'interface « ethl », le paquet de données sera reçu par le terminal Ti via l'équipement de routage R2, comme illustré par la figure 8B.

[0163] Option MULT1.2 : Routage à la source

[0164] 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.

[0165] L'option reposant sur le routage à la source consiste à associer une information sup- plé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 @TIS.

Par exemple, la liste PCL mise à jour par le terminal Tl est : 24 { @Tl 1, PS11 @T12, PD12, default router=R11}, @Tl n, PS1 n, @Tl 1, PD11, default router,R1n1.

[0166] Dans la suite, on suppose par exemple que l'option SR est utilisée.

[0167] 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.

[0168] Le paquet est ainsi acheminé de proche en proche ou rejeté lorsqu'aucune route n'a été trouvée.

[0169] En relation avec la figure 10, le terminal T1 cherche à établir en 221 les commu- nications candidates CC listées dans sa table PCL : @Ill, PS11, @T12, PD121, @T12, PS12, @T1i, PD1i1 et { @T'IL PS1i, @Tl 1, PD111.

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.

[0170] En relation avec la figure 11, le terminal T1 cherche à établir les communications candidates suivantes sur ses chemins d'accès au réseau : @Tl 1, PS11, @T12, PD121, @T12, PS12, eTli, PD1i1 et { @Tli, PS @T11, PDI1}.

Dans l'exemple de la figure 11, toutes ces communications sont établies avec succès à l'exception de la communication candidate @T12, PS12, @TH, PD lit 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 Ti.

Il positionne à la valeur « OKON » le statut de toutes les adresses IP disponibles dans la liste ACAL à l'exception de l'adresse eTli pour laquelle le paramètre STATUS est maintenu à « OKOFF ».

[0171] 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.

[0172] 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 Ti a été configuré pour se connecter au réseau via un équipement proxy P localisé dans le réseau de communication RC.

[0173] Mode de réalisation MULT2 ou mode « Proxy »

[0174] 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.

[0175] 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.

[0176] Le « Proxy QUIC » peut être typiquement configure sur le terminal en utilisant par exemple le protocole DHCP, l'option PCO (pour « PDP Configuration Options », en anglais), etc.

[0177] 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. 0 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 ».

[0178] 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.

[0179] 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, @TI2, PD12}, {@TIn, PS1n, @TII, PD11}.

[0180] Ensuite, en 221, comme déjà démit en relation avec la figure 4, le terminal T1 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 ».

[0181] 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 @T Ii.

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 @T li, 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.

[0182] Si le proxy P reçoit la demande d'établissement de communication, il la retransmet au terminal en l'encapsulant dans un paquet IP.

[0183] Les étapes 222 à 224 précédemment décrites restent inchangées. 26

[0184] 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.

[0185] Mode de réalisation MULT3 ou mode « assisté »

[0186] 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.

[0187] 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.

[0188] En 22011', 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 @Tl 1 allouée par le réseau d'accès N11 au terminal Ti et une ressource IP comprenant l'adresse @T2 du terminal T2.

[0189] En 221', le terminal T1 é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.

[0190] Cette trame comprend : - au moins une adresse IP de destination du terminal Ti à 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).

[0191] Un exemple de trame miroir est illustré par la figure 15.

[0192] 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 .

[0193] 11 reçoit en 300 la trame miroir émise par Tl via la communication CE1.

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, 27 numéro de port destination) du terminal T1 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é.

[0194] 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 Ti devrait écouter et associer avec le test de détection de présence en cours.

[0195] 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.

[0196] 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.

[0197] En 224', une fois que toutes les adresses de destination correspondant aux commu- nications 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.

[0198] 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 @Til, @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 erril, 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.

[0199] 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 ».

[0200] La figure 17 illustre le cas où les paquets de données comprenant les trames TV 28 envoyées par T2 vers l'adresse @T12 et @Tl i 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é, Ti 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 @Tl i à « OKOFF », et celui associé à @T11 à « OKON ».

[0201] On considère maintenant le cas où le terminal Ti détecte un nouveau chemin.

Il s'agit par exemple d'un tunnel VPN (« Vit-tuai Privait? Newark », en anglais), établi à partir d'une interface physique du terminal Ti pour laquelle il dispose déjà d'un chemin réseau.

[0202] 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 @Tl i+1.

[0203] Par exemple, le terminal Ti sollicite le terminal T2 avec lequel il est déjà connecté en lui envoyant une trame miroir comprenant l'adresse @Tl i+1 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 @Tl i+1 en fonction du résultat de la procédure de détection de présence.

[0204] Ensuite, en fonction des réponses reçues, le terminal Ti met à jour les statuts des éléments des listes PCL puis ACAL comme précédemment décrit.

[0205] 11 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.

[0206] Mode de réalisation SOLO pour un terminal mono-interface

[0207] 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.

[0208] 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 :

[0209] Si aucune réponse n'est reçue, alors il conclut à la présence d'une fonction à états sur le chemin.

[0210] Si au contraire une réponse est reçue, alors il conclut à l'absence de fonction à états sur le chemin.

[0211] En outre, il établit qu'aucune fonction de traduction d'adresse n'est présente sur le 29 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.

[0212] 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.

[0213] De façon alternative, le terminal Ti 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 Ti 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, Ti conclut à l'absence de fonction à états sur le chemin et met à jour le statut STATUS de ce chemin en le positionnant à « OKON ».

[0214] 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 Ti 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.

[0215] 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).

[0216] 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 @TH.

Il a donc positionné en 224 le statut de ce chemin à la valeur « OKOFF ».

[0217] Comme illustré par la figure 4, le procédé de gestion selon ce troisième mode de réa- lisation 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

[0218] 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.

[0219] A titre d'exemple, on considère le cas de la figure 11, pour lequel seule l'adresse @Tl i est associée au statut « OKOFF » et donc extraite.

[0220] Ensuite, comme illustré par la figure 18, le terminal T1 choisit une autre adresse de la liste ACAL, par exemple @Tl 1, dont le statut est au contraire égal à « OKON ».

[0221] Il établit une communication depuis l'adresse extraite @Tl i vers l'autre adresse @Tl 1 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 Guidelincs », RFC 8085, publié par l'IETF en mars 2017.

[0222] Le terminal Ti é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é à TO 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.

[0223] 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.

[0224] Avantageusement, cette durée de vie évaluée est mise à profit pour gérer plus effi- cacement 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.

[0225] 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.

[0226] 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 Ti.

[0227] Etape CONNECT (23)

[0228] 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.

[0229] S'il dispose de plusieurs chemins le terminal Ti peut avantageusement exploiter les informations stockées dans la liste ACAL pour sélectionner celui sur lequel il est plus efficace (l'établir une communication sortante.

Par exemple, le terminal Ti peut sé- 31 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 impact° 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.

[0230] Pour établir une communication QUIC avec un terminal distant T3, le terminal T1 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 KEEPALTVE 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.

[0231] 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 T1 pour l'envoi d'un paquet de données QUIC.

[0232] 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é.

[0233] 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.

[0234] 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.

[0235] Le terminal distant T3 exploite avantageusement les informations de cette table pour 31 décider sur quel chemin établir une communication avec Tl .

[0236] Dans l'exemple de la figure 20, on suppose que pour le chemin associé à l'adresse IP @T1 1, 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.

[0237] 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 @Tl 1 de Ti 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 Ti.

[0238] Le terminal Ti 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.

[0239] 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).

[0240] On suppose par exemple que la première communication a été établie entre Ti et T3 via l'adresse IP @TI1 de NI1 et l'adresse @T3I 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 @T II de N11) à la communication.

En outre, le terminal Ti décide d'ajouter le chemin @Tli de NU et @T3I de N31 à la communication.

Du fait que pour l'adresse @TI1 de N11 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 (N11, N31).

En revanche, pour les autres chemins utilisés par la 33 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.

[0241] Ainsi, les deux terminaux peuvent chacun mettre en oeuvre l'invention qui vient d'être décrite.

[0242] 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.

[0243] 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.

[0244] 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.

[0245] Avantageusement, le dispositif 100 comprend aussi un module de détermination de la 34 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.

[0246] 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.

[0247] 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.

[0248] 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.

[0249] 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).

[0250] Dans le cas où le dispositif 100 est réalisé avec une machine de calcul repro- grammable, 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.

[0251] 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 Ti 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.

[0252] 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é.

[0253] Avantageusement, le dispositif 200 comprend en outre un module de stockage d'une table de chemins ACAL_PEER reçue du premier équipement terminal.

[0254] 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.

[0255] 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 finitialisation, les instructions 36 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.

[0256] 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 rnicrocontrô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).

[0257] 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.

[0258] 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, Ti, 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.

[0259] 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.

[0260] L'invention permet notamment : 37 - 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 « kcepalive » par communication, en tenant compte de la présence éventuelle de fonctions à états sur un chemin emprunté par la communication.

38 [Revendication 1] [Revendication 2] [Revendication 3]

Claims (1)

1. REVENDICATIONSProcé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 dc 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 teiminal, 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 teiminal, comprenant ladite deuxième adresse IP et un deuxième numéro de poil, 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. 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. 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 (l'absence de fonction à états sur le chemin reliant ladite au moins une première ressource IP à la deuxième 39 [Revendication 4] [Revendication 5] [Revendication 6] [Revendication 7] [Revendication 8] 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. 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. 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. 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 (T I) comprennent ladite réponse. 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 Procédé de gestion d'une communication selon la revendication 7, ca- 40 [Revendication 9] [Revendication 10] [Revendication 11] racté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 dc 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 ; 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 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. Procédé de gestion d'une communication selon l'une des revendications 7 à 19, 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 41 [Revendication 12] [Revendication 13] temporelle déterminée. 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 cc qu'il est configure 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. 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 ; 42 [Revendication 14] [Revendication 15] [Revendication 16] - l'extraction (301) de ladite au moins une deuxième ressource IP et dc ladite information dc 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é. 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 cc 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. 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. Equipement terminal (TI, 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 43 [Revendication 17] [Revendication 18] [Revendication 19] [Revendication 20] revendication 12. Equipement terminal (T2, 1 1 , Ti, 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. 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. Equipement noeud 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 configure pour : - détecter une présence, sur au moins un chemin permettant de joindre via ledit réseau de communication ledit équipement noeud 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 noeud 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. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 11 et 13 à 14 lorsqu'il est exécuté par un processeur.