Brevet FR3131670A1 — publié le 20230707

Il est proposé un procédé implémenté par des sondes réseau dans un système de communication comportant une pluralité de routeurs, chaque sonde réseau étant associée à un routeur de ladite pluralité de routeurs et à un point de terminaison dudit routeur. Il est aussi proposé un produit programme d’ordinateur comportant des instructions pour implémenter ce procédé, lorsque lesdites instructions sont exécutées par un processeur. Il est aussi proposé un support de stockage d’informations stockant un tel programme d’ordinateur comportant des instructions pour implémenter ce procédé lorsque lesdites instructions sont lues depuis le support de stockage d’informations et exécutées par un processeur. Il est aussi proposé un système de communication comportant de telles sondes réseau. PROTOCOLE D’EVALUATION DE CONGESTION La présente invention concerne le domaine des sondes réseau permettant de surveiller (« monitor » en anglais) du trafic passant par un tunnel de communication, et détecter et d’évaluer ainsi des états de congestion de réseaux de communication, par exemple de type WAN (« Wide Area Network » en anglais). ETAT DE LA TECHNIQUE ANTERIEURE Les réseaux de communication servent à offrir une grande diversité de services, comme l’échange de communication voix, typiquement des services dits de VoIP (« Voice over IP » en anglais), l’échange de communication audiovisuelle, la diffusion de programmes multimédia, ou encore l’accès à des données, typiquement l’accès à des services Web. Ces services ont des besoins différents en termes de latence de transmission dans les réseaux de communication, et ont des priorités différentes. Les liens de communication sur lesquels reposent les réseaux de communication sont basés sur des technologies de transmission physique qui peuvent être très diverses. Chacune de ces technologies conduit à des propriétés différentes de canal de transmission utilisé en termes de capacités, c’est-à-dire en bande passante disponible, taux d’erreur, ou variabilité de cette bande passante disponible. De manière à gérer de manière adéquate l’admission de services en tenant compte de ces propriétés différentes de canal de transmission ou de manière à construire un modèle prédictif du canal de transmission, des sondes réseau sont utilisées pour analyser le trafic transitant dans ces réseaux de communication, et notamment dans des tunnels de communication établis entre des routeurs de ces réseaux de communication. Une difficulté réside dans l’évaluation fine des états de congestion de ces réseaux de communication. Il est alors souhaitable de pallier au moins cet inconvénient de l’état de la technique antérieure, et ce, de manière simple, efficace et peu coûteuse. A cet effet, il est proposé un procédé implémenté par des sondes réseau dans un système de communication comportant une pluralité de routeurs, chaque sonde réseau étant associée à un routeur de ladite pluralité de routeurs et à un point de terminaison dudit routeur. Il est aussi proposé un produit programme d’ordinateur comportant des instructions pour implémenter ce procédé, lorsque lesdites instructions sont exécutées par un processeur. Il est aussi proposé un support de stockage d’informations stockant un tel programme d’ordinateur comportant des instructions pour implémenter ce procédé lorsque lesdites instructions sont lues depuis le support de stockage d’informations et exécutées par un processeur. Il est aussi proposé un système de communication comportant de telles sondes réseau. La description suivante d’au moins un mode de réalisation est établie en relation avec les dessins joints, parmi lesquels : illustre schématiquement un système de communication ; illustre schématiquement un agencement de sonde réseau ; illustre schématiquement un agencement complémentaire de sonde réseau ; illustre schématiquement une mise en relation de sondes réseau avec un orchestrateur ; illustre schématiquement un exemple d’architecture matérielle permettant l’implémentation des sondes réseau du système de communication ; illustre schématiquement un organigramme de mise en place de sonde réseau pour la surveillance d’un tunnel de communication en amont dudit tunnel de communication ; illustre schématiquement un organigramme de mise en place de sonde réseau pour la surveillance d’un tunnel de communication en aval dudit tunnel de communication ; illustre schématiquement une variation de cadencement de flux de données dans un tunnel de communication ; et illustre schématiquement un organigramme de création et de mise à jour d’une ou plusieurs tables de mesures stockant des informations représentatives de la variation de cadencement de flux de données de la . EXPOSE DETAILLE DE MODES DE REALISATION La illustre schématiquement un système de communication. Le système de communication comporte une pluralité de routeurs 110. Trois routeurs R1 à R3 sont représentés, à titre illustratif, sur la . Les routeurs 110 sont interconnectés par au moins un réseau de communication 100a sur lequel lesdits routeurs 110 établissent des tunnels de communication. Ainsi, les routeurs 110 comportent au moins un point de terminaison (« end-point » en anglais) 120 de tunnel de communication. Chaque point de terminaison 120 peut concerner un ou plusieurs tunnels de communication. Chaque réseau de communication 100a peut être de nature variée, qu’elle soit filaire comme par exemple des liens Ethernet, ou de la fibre optique, ou radio comme par exemple des liens satellites. Deux réseaux de communications 100a WAN1 et WAN2, de type réseaux étendus WAN (« Wide Area Network » en anglais), sont représentés, à titre illustratif, sur la . Les tunnels de communication sont par exemple implémentés grâce au protocole GRE (« Generic Routing Encapsulation » en anglais) ou à la famille de standards IPSec (« Internet Protocol Security » en anglais). D’autres protocoles de mise en tunnel peuvent être utilisés en variante. Préférentiellement, les tunnels de communications sont sécurisés par chiffrement, de sorte que les données encapsulées dans le protocole d’encapsulation du tunnel de communication ne soient pas déchiffrables par un dispositif qui serait situé entre les deux points de terminaison 120 du tunnel de communication. Par exemple, les tunnels de communication sont utilisés pour mettre en relation d’autres réseaux de communication 100b par le biais desdits routeurs 110. Comme illustré sur la , les routeurs 110 et les tunnels de communication permettent d’interconnecter des réseaux locaux LAN (« Local Area Network » en anglais), comme des réseaux WLAN (« Wireless Local Area Network » en anglais), par exemple de la famille de standard IEEE 802.11. Dans un mode de réalisation particulier, le système de communication permet ainsi de mettre en relation sécurisée des terminaux présents sur des réseaux locaux LAN1, LAN2, LAN3 100b (appelés réseaux rouges) au travers du réseau étendu WAN1 100a (appelé réseau noir). Ainsi, de manière illustrative sur la , un premier tunnel de communication est établi sur le réseau WAN1 entre un point de terminaison E1 du routeur R1 et un point de terminaison E3 du routeur R2, et un deuxième tunnel de communication est établi sur le réseau WAN1 entre le point de terminaison E1 et un point de terminaison E4 du routeur R3. Un troisième tunnel de communication est établi sur le réseau WAN1 entre le point de terminaison E3 du routeur R2 et le point de terminaison E4 du routeur R3. Un quatrième tunnel de communication est établi sur le réseau WAN2 entre un point de terminaison E2 du routeur R1 et un point de terminaison 120 d’un autre routeur non représenté. Le système de communication est équipé de sondes réseau (« network probe » en anglais). Les sondes réseau sont agencées et configurées pour effectuer des mesures de débit de données entrant dans les tunnels de communication et de données sortant des tunnels de communication, c’est-à-dire au niveau des points de terminaison 120 des tunnels de communication, de manière à pouvoir détecter et évaluer des situations de congestion dans le ou les réseaux de communication 100a. Les mesures de débit sont des mesures, sur des périodes temporelles délimitées par des paquets fanions (« flag packets » en anglais), de volumes de données encapsulées dans le protocole des tunnels de communication. Les sondes réseau peuvent être incluses dans les routeurs 110 ou y être connectées, dès lors que lesdites sondes réseau ont accès au plan de données des routeurs 110 afin de capter les paquets transmis dans les tunnels de communication, de pouvoir mettre en place un protocole de communication inter-sondes et de pouvoir injecter des paquets fanions afin de cadencer les mesures de débit de données dans les tunnels de communication. Le protocole de communication inter-sondes permet aux sondes réseau des points de terminaison 120 d’un même tunnel de communication de s’envoyer des informations relatives auxdites mesures afin d’évaluer des états de congestion sur le ou les réseaux de communication 100a. L’agencement présenté ci-dessus permet d’assurer que le protocole de communications inter-sondes emprunte le même chemin que les paquets du tunnel de communication supervisé par les sondes réseau en question. Une dite sonde réseau est ainsi associée à chaque point de terminaison 120 des tunnels de communication à surveiller en termes de débit de données encapsulées. A noter que des tunnels de communication peuvent exister dans le système de communication alors qu’aucune sonde réseau n’est mise en place à leurs points de terminaison 120. Dans un mode de réalisation particulier, les sondes réseau sont agencées comme schématiquement illustrées sur la . La présente ainsi une architecture modulaire de sonde réseau comportant un gestionnaire de sonde réseau 160, un injecteur 150, un module applicatif 165, et un module de capture 155. Le module de capture 155 inclut un module de filtrage permettant de récupérer, via un module d’interface du routeur auquel ladite sonde réseau est associée, des paquets de données relatifs à des tunnels de communication. Ainsi, le module de filtrage permet d’obtenir une copie de tout paquet de données de type GRE ou IPSec destiné ou émanant du point de terminaison 120 auquel ladite sonde réseau est associée. De plus, le module de filtrage permet d’obtenir une copie de tout paquet fanion (tel que décrit ci-après) inclus dans le trafic du tunnel de communication supervisé par la sonde réseau en question. Le module de capture 155 inclut préférentiellement deux sous modules : un sous-module de capture du trafic entrant dans le tunnel de communication et un module de trafic sortant du tunnel de communication. On peut ainsi voir le module de capture 155 comme deux points de capture spécialisés par point de terminaison 120. L’injecteur 150 est adapté et configuré pour injecter des paquets fanions dans le trafic du tunnel de communication supervisé (trafic sortant), c’est-à-dire lorsque la sonde réseau en question est associée au point de terminaison 120 en entrée du tunnel de communication. La sonde réseau est configurée et adaptée de sorte que l’injecteur réseau 150 injecte les paquets fanions dans un plan utilisateur (« user plane » en anglais) 140 en amont du point de terminaison 120 par rapport au tunnel de communication supervisé. Le plan utilisateur 140 est le chemin de données dans le routeur 110 auquel ladite réseau est associée par lequel transitent les paquets issus des réseaux de communication 100b qui sont transmis dans le tunnel de communication en question par le point de terminaison 120 local. Ainsi, du point de vue du point de terminaison 120 en question, les paquets fanions sont vus comme faisant partie du trafic issu du réseau de communication 100b en amont du point de terminaison 120 local par rapport au tunnel de communication supervisé. Cela implique que les paquets fanions sont perceptibles et détectables par le point de capture local de la sonde réseau considérée. L’injecteur 150 est configuré pour générer et émettre les paquets fanions de façon périodique, selon une période de durée définie par le gestionnaire de sonde réseau 160 ou par pré-configuration. La cadence des paquets fanions injectés peut être modifiée ou ajustée par le gestionnaire de sonde réseau 160 dans le temps. Dans un mode de réalisation particulier, les paquets fanions sont des paquets UDP (« User Datagram Protocol » en anglais) émis sur un port dédié auxdits paquets fanions. Préférentiellement, de tels paquets fanions sont injectés pour chaque type de service transporté par le tunnel de communication supervisé. Par exemple, des paquets fanions sont injectés par l’injecteur 150 pour chaque valeur de champ DSCP des paquets du tunnel de communication. Lorsqu’un tunnel de communication transporte du trafic correspondant à plusieurs types de services (e.g., plusieurs valeurs de DSCP dans les paquets transportés), l’injecteur 150 injecte les paquets fanions de manière synchrone pour les différents types de services. En d’autres termes, l’injecteur 150 injecte les paquets fanions des différents types de services substantiellement au même instant (au temps de traitement près). Chaque paquet fanion inclut une information d’horodatage (« timestamp » en anglais) ainsi qu’un identifiant de séquence (seqID). Par exemple, chaque paquet fanion comporte un entête de routage (e.g., de type IP) comportant un champ d’adresse source indiquant l’adresse de la sonde réseau locale, un champ d’adresse destination indiquant l’adresse de la sonde réseau distante, et un champ de type de service (e.g., de type DSCP) indiquant le type de service dans lequel s’inscrit le paquet fanion en question. L’entête de routage a par exemple une taille de 20 à 40 octets. Dans cet exemple, chaque paquet fanion comporte ensuite un entête de transport (e.g., de type UDP) indiquant un port de destination, et éventuellement un port source, dédié aux paquets fanions (et connu de toutes les sondes réseau du système de communication). L’entête de transport a par exemple une taille de 8 octets. Toujours dans cet exemple, chaque paquet fanion comporte ensuite un champ de type de paquet, par exemple ayant une taille de 1 octet et de valeur égale à 0. Toujours dans cet exemple, chaque paquet fanion comporte ensuite un champ d’identifiant de séquence qui indique un numéro d’ordre (cyclique) dudit paquet fanion dans une succession de transmission de dits paquets fanions par l’injecteur 150, ainsi qu’un champ d’horodatage ayant une taille 8 octets exprimant une référence temporelle d’émission dudit paquet fanion par l’injecteur 150 avec une précision à la milliseconde. Les paquets fanions ainsi construits permettent un filtrage aisé en réception par la sonde réseau de l’ordre côté du tunnel de communication supervisé. Le gestionnaire de sonde réseau 160 est configuré et agencé pour stocker des métriques liées à des mesures effectuées grâce au module de capture 155, coordonner la mise en place et le déroulement de communications inter-sondes pour un tunnel de communication donné, et consolider les métriques stockées afin d’alimenter le module applicatif 165 en informations de surveillance de tunnel de communication. Le gestionnaire de sonde réseau 160 implémente un protocole de communication inter-sondes, permettant ainsi à ladite sonde réseau de communiquer avec une ou plusieurs autres dites sondes réseau dans le cadre de la supervision d’un ou plusieurs dits tunnels de communication respectifs. Un port UDP dédié au protocole de communication inter-sondes est préférentiellement utilisé pour ce faire. Un tel protocole inter-sondes permet notamment un partage d’informations de mesures effectuées par lesdites sondes réseau ou des informations de calculs qui en découlent. Chaque sonde réseau a une adresse, pour communiquer dans le ou les réseaux de communication 100a, qui est prédéfinie par rapport à l’adresse du point de terminaison 120 de tunnel de communication à laquelle ladite sonde réseau est associée. Cela permet de mettre automatiquement en communication les sondes réseau concernées lorsqu’un nouveau tunnel de communication est détecté (e.g., établi). Cela permet aussi de configurer automatiquement le filtrage des paquets fanions transmis par l’injecteur 150, par la sonde réseau distante associée au point de terminaison 120 de l’autre côté du tunnel de communication surveillé. Plus précisément, l’adresse de la sonde réseau est déterminée en appliquant une fonction de translation bijective par rapport à l’adresse du point de terminaison 120 auquel ladite sonde réseau est associée. Dans un mode de réalisation particulier, l’adresse de ladite sonde réseau est obtenue en appliquant une règle de conversion (« mapping » en anglais) prédéfinie à partir de l’adresse du point de terminaison 120 auquel ladite sonde réseau est associée. Dans un mode de réalisation particulier, l’adresse de ladite sonde réseau est obtenue en appliquant un décalage (« offset » en anglais) prédéfini (positif ou négatif) par rapport à l’adresse du point de terminaison 120 auquel ladite sonde réseau est associée. Dans un mode de réalisation particulier, l’adresse de ladite sonde réseau est obtenue en ajoutant un ( i.e. , une unité) à l’adresse du point de terminaison120 auquel ladite sonde réseau est associée. Le même mécanisme s’applique pour la définition des adresses des autres sondes réseau du système de communication. Ainsi, l’adresse d’une sonde réseau distante (i.e., de l’autre côté d’un tunnel de communication supervisé) est déterminée en appliquant la fonction de translation bijective par rapport à l’adresse du point de terminaison 120 auquel ladite sonde réseau distante est associée. Les messages échangés dans le cadre du protocole inter-sondes sont préférentiellement d’un type de trafic de plus haute priorité. Par exemple, les messages échangés dans le cadre du protocole inter-sondes ont une valeur de champ DSCP (« Differentiated Services Code Point » en anglais) plus prioritaire que les paquets qui sont encapsulés dans les tunnels de communication supervisées (i.e., plus prioritaire que les paquets communications entre les réseaux de communication 100b). Dans un mode de réalisation particulier, les messages échangés dans le cadre du protocole inter-sondes ont une valeur de champ DSCP qui correspond à une priorité maximale possible. Cela permet de limiter l’impact des situations de congestions sur le transit desdits messages échangés dans le cadre du protocole inter-sondes et ainsi permettre une meilleure réactivité, au besoin, aux situations de congestion. Le module applicatif 165 est en charge de collecter des informations relatives à une variation de cadencement de flux de données dans le tunnel de communication supervisé par ladite sonde réseau. Le module applicatif 165 peut effectuer des calculs sur lesdites mesures afin de détecter et d’évaluer des situations de congestion, en prenant en compte des mesures aussi effectuées par un module applicatif équivalent dans une sonde réseau distante en charge de superviser le tunnel de communication à son autre point de terminaison. Par exemple, le module applicatif 165 peut être en charge d’instruire le routeur local pour modifier des profils de transmission de données dans le ou les réseaux de communication 100a de sorte à prendre en compte, préférentiellement améliorer (e.g., gestion d’admission de services), les situations de congestion qui seraient révélées par les mesures effectuées ou des calculs qui en découlent. En variante, le module applicatif 165 est en charge de remonter à un orchestrateur des informations relatives aux mesures effectuées ou aux calculs qui en découlent. La illustre schématiquement un agencement complémentaire de sonde réseau. Dans le schéma de la , le gestionnaire de sonde réseau 160 comporte un gestionnaire de plan de contrôle (« control plane » en anglais) pour chaque tunnel de communication impliquant le routeur 110 auquel est associée la sonde réseau considérée, c’est-à-dire pour chaque injecteur 150 local et chaque module de capture 155 local. Chaque gestionnaire de plan de contrôle gère et configure les opérations d’un injecteur 150 et d’un module de capture 155 qui lui sont associés. Ledit gestionnaire de plan de contrôle implémente le protocole de communication inter-sondes pour la supervision du tunnel de communication pour lequel ledit injecteur 150 et ledit module de capture 155 opèrent. Ledit gestionnaire de plan de contrôle effectue, ou coordonne, les opérations de mesure de trafic via ledit tunnel de communication, ainsi que les calculs qui en découlent éventuellement. Sur la , la sonde réseau considérée est associée à un routeur en extrémité de deux tunnels de communication. Ces tunnels de communication peuvent avoir un même point de terminaison 120 dans le routeur 110 en question, ou deux points de terminaison 120 distincts. Deux injecteurs INJ1 150a et INJ2 150b, et deux modules de capture CAP1 155a et CAP 2 155b respectifs, sont ainsi représentés sur la . Le gestionnaire de sonde réseau 160 comporte alors deux gestionnaires de plan de contrôle respectifs CPM1 170a et CPM2 170b. Dans le schéma de la , le gestionnaire de sonde réseau 160 comporte en outre une mémoire 175, par exemple sous forme d’une base de données DB (« Database » en anglais). La mémoire en question peut en variante être externe au gestionnaire de sonde réseau 160, voire à la sonde réseau elle-même, et le gestionnaire de sonde réseau 160 est connecté à ladite mémoire et a accès en lecture, écriture, et effacement à ladite mémoire. La mémoire 175 est notamment utilisée par le gestionnaire de sonde réseau 160 pour stocker des informations de captures effectuées par chaque module de capture 155 local, des mesures qui en découlent, des métriques liées à ces mesures, et éventuellement des résultats de calculs effectués sur lesdites métriques. D’autres architectures modulaires que celle présentée ci-dessus en relation avec les Figs. 1B et 1C peuvent être conçues sans départir des principes et comportement décrits ici, notamment en répartissant autrement les fonctions réalisées par les modules exposés ci-dessus. Dans un mode de réalisation particulier tel qu’illustré sur la , les sondes réseau sont en communication avec un orchestrateur 180, plus particulièrement par le biais de leurs modules applicatifs 165. Les mesures effectuées par les sondes réseau ou des calculs qui en découlent peuvent ainsi être partagés avec l’orchestrateur 180, afin notamment de détecter et d’évaluer des situations de congestion sur le ou les réseaux de communication 100a et ainsi d’adapter des admissions de service en conséquence. Ainsi, le système de communication est particulièrement adapté aux infrastructures de type SD-WAN (« Software-Defined Wide Area Network » en anglais). Dans un mode de réalisation particulier, l’orchestrateur 150 définit et impose (« enforce » en anglais) une politique d’admission de services dans le ou les réseaux de communication 100a qui tient compte des capacités effectives de communication dans ledit ou lesdits réseaux de communication 100a et qui prend donc en compte les situations de congestion révélées par les sondes réseau. En variante, les mesures effectuées par les sondes réseau ou des calculs qui en découlent sont partagés avec l’orchestrateur 180, afin de permettre à l’orchestrateur 180, ou à tout autre dispositif ou système informatique centralisé, d’établir un modèle prédictif de congestion du ou des réseaux de communication 100a. La illustre schématiquement un exemple d’architecture matérielle de sonde réseau, et permettant notamment d’implémenter l’architecture modulaire des Figs. 1B et 1C. La sonde réseau comprend alors, reliés par un bus de communication 310 : un processeur ou CPU (pour « Central Processing Unit » en anglais) 301, ou une grappe de tels processeurs, comme par exemple des GPU (« Graphics Processing Units » en anglais) ; une mémoire vive RAM (pour « Random Access Memory » en anglais) 302 ; une mémoire morte ROM (pour « Read Only Memory » en anglais) 303, ou une mémoire réinscriptible de type EEPROM (« Electrically Erasable Programmable ROM » en anglais), par exemple de type Flash ; un dispositif de stockage de données, tel qu’un disque dur HDD (pour « Hard Disk Drive » en anglais) 304, ou un lecteur de support de stockage, tel qu’un lecteur de cartes SD (pour « Secure Digital » en anglais) ; un ensemble d’interfaces d’entrées et/ou sorties, telles que des interfaces de communication 305, permettant notamment à la sonde réseau de capter des paquets à destination du routeur auquel la sonde réseau est associée, ou en transit via le routeur auquel la sonde réseau est associée, d’injecter et de capter des paquets fanions comme décrit plus en détails ci-après, ainsi que de communiquer avec d’autres sondes réseau du système de communication ou avec l’orchestrateur 180. Le processeur 301 est capable d’exécuter des instructions chargées dans la RAM 302 à partir de la ROM 303, d’une mémoire externe (non représentée), d’un support de stockage, tel qu’une carte SD ou le disque dur HDD, ou d’un réseau de communication. Lorsque la sonde réseau est mise sous tension, le processeur 301 est capable de lire de la RAM 302 des instructions et de les exécuter. Ces instructions forment un programme d’ordinateur causant l’implémentation, par le processeur 301, des étapes, comportements et algorithmes décrits ici. Tout ou partie des étapes, comportements et algorithmes décrit ici peut ainsi être implémenté sous forme logicielle par exécution d’un ensemble d’instructions par une machine programmable, telle qu’un DSP (« Digital Signal Processor » en anglais) ou un processeur, ou être implémenté sous forme matérielle par une machine ou un composant (« chip » en anglais) dédié ou un ensemble de composants dédié (« chipset » en anglais), tel qu’un FPGA (pour « Field-Programmable Gate Array » en anglais) ou un ASIC (pour « Application-Specific Integrated Circuit » en anglais). Il en découle que l’architecture modulaire des Figs. 1B et 1C peut être implémentée sous forme logicielle par exécution d’un ensemble d’instructions par une machine programmable, ou être implémenté sous forme matérielle par une machine ou un composant dédié ou un ensemble de composants dédiés. D’une manière générale, chaque sonde réseau comprend de la circuiterie électronique agencée et configurée pour implémenter les étapes, comportements et algorithmes décrits ici, et notamment l’architecture modulaire des Figs. 1B et 1C. La illustre schématiquement un organigramme de mise en place de sonde réseau pour la surveillance d’un tunnel de communication en amont dudit tunnel de communication. Dans une étape 401, la sonde réseau en question détecte un nouveau tunnel de communication dont un point de terminaison est le point de terminaison 120 auquel est associée ladite sonde réseau. La détection d’un nouveau tunnel de communication est préférentiellement réalisée par détection de la transmission d’un paquet d’encapsulation de tunnel, par exemple de type GRE ou IPSec, correspondant à un tunnel de communication qui n’avait pas été précédemment détecté. Un nouveau tunnel de communication est ainsi détecté lorsque l’adresse source et l’adresse destination forment un couple de points de terminaison 120 encore inconnu de ladite sonde réseau (sachant que ladite sonde réseau est associée au point de terminaison 120 d’entrée dans le tunnel de communication, pour le sens de communication considéré). Dans une étape 402, la sonde réseau déduit l’adresse d’une sonde réseau distante, avec laquelle ladite sonde réseau doit collaborer pour la surveillance du trafic du tunnel de communication en question. Pour ce faire, ladite sonde réseau récupère l’adresse du point de terminaison distant, c’est-à-dire celui qui est de l’autre côté du tunnel de communication qui a été nouvellement détecté à l’étape 401. L’adresse source correspond au point de terminaison 120 auquel est associée ladite sonde réseau, donc l’adresse du point de terminaison distant est l’adresse destination. A noter qu’aucune inspection profonde de paquet DPI (« Deep Packet Inspection » en anglais) n’est requise. Ladite sonde réseau déduit alors l’adresse de la sonde réseau distante, avec laquelle ladite sonde réseau doit collaborer pour surveiller le tunnel de communication en question, en appliquant la fonction de translation bijective, comme déjà expliqué ci-avant. Cette déduction d’adresse permet d’établir les communications inter-sondes et la configuration de l’injecteur 150 local. A noter que la sonde réseau effectue une instanciation automatique de communications inter-sonde entre ladite sonde réseau, qui supervise donc un premier point de terminaison 120 du tunnel de communication en question, et la sonde réseau distante, qui supervise le second point de terminaison 120 de ce tunnel de communication. L’instanciation automatique des communications inter-sondes est réalisable grâce à la prédéfinition des adresses des sondes réseau par rapport aux adresses de leurs points de terminaison respectifs. Préférentiellement, chaque sonde réseau ouvre un connecteur réseau (« socket » en anglais) avec l’adresse du point de terminaison 120 qui lui est associé, à laquelle la fonction de translation bijective est appliquée, et avec un port UDP dédié. Cela permet à chaque sonde réseau de recevoir des messages UDP qui sont adressés, par tout autre sonde réseau du système de communication, à destination de cette adresse et de ce port UDP dédié. Ainsi, lorsqu’un tunnel de communication est mis en place entre deux points de terminaison 120, chacune des sondes réseau surveillant une des extrémités dudit tunnel de communication détecte le transit d’un paquet dudit tunnel de communication. Grâce à la prédéfinition des adresses des sondes réseau par rapport à celles des points de terminaison 120 auxquels lesdites sondes réseau sont associées, la mise en communication desdites sondes réseau peut s’établir automatiquement de sorte à surveiller conjointement le trafic (sans inspection profonde de paquet). Dans une étape 403, la sonde réseau instancie un injecteur de paquets de cadencement dans le tunnel de communication, c’est-à-dire un injecteur de paquets fanions. En appliquant le même algorithme, la sonde réseau distante instancie aussi un injecteur de paquets de cadencement dans le tunnel de communication, ce qui permet de créer une horloge de référence dans les deux sens de communication entre les sondes réseau via le tunnel de communication. Dans une étape 404, la sonde réseau effectue des captures et des mesures de débit de données pour le tunnel de communication en question. Les mesures de débit de données sont réalisées par comptage de volume de données transmises entre des paquets fanions successifs, détectés dans le trafic sortant du tunnel de communication. Les mesures de débit de données peuvent être réalisées par type de service dans le tunnel de communication, par exemple en s’appuyant sur une information de type de service (e.g. champ DSCP) incluse dans les paquets d’encapsulation du tunnel de communication. Dans une étape 405, la sonde réseau effectue une surveillance du trafic de données dans le tunnel de communication en question, à partir des mesures effectuées à l’étape 404. Le principe de la surveillance du tunnel de communication consiste à comparer les mesures de débit de données entrant dans le tunnel de communication (au niveau d’un point de terminaison) et celles du débit de données sortant du tunnel de communication (au niveau de l’autre point de terminaison). Une information représentative des mesures de débit effectuées par une sonde réseau est transmise à l’autre sonde réseau de l’autre côté du tunnel de communication (potentiellement dans les deux sens), et une différence entre ces débits au-delà d’une marge prédéterminée met en évidence une congestion. Les paquets fanions servent de référence d’horloge pour déterminer des variations de cadencement entre l’entrée et la sortie du tunnel de communication, comme schématiquement illustré sur la . Une boucle est alors réalisée entre les étapes 405 et 404, de sorte à surveiller le trafic dans le tunnel de communication en question, par cycles temporels définis par les paquets fanions. La illustre schématiquement un organigramme de mise en place de sonde réseau pour la surveillance d’un tunnel de communication en aval d’un tunnel de communication. Dans une étape 501, la sonde réseau en question détecte un nouveau tunnel de communication dont un point de terminaison est le point de terminaison 120 auquel est associée ladite sonde réseau. La détection d’un nouveau tunnel de communication est préférentiellement réalisée par détection de la réception d’un paquet d’encapsulation de tunnel, par exemple de type GRE ou IPSec, correspondant à un tunnel de communication qui n’avait pas été précédemment détecté. Un nouveau tunnel de communication est ainsi détecté lorsque l’adresse source et l’adresse destination forment un couple de points de terminaison 120 encore inconnu de ladite sonde réseau (sachant que ladite sonde réseau est associée au point de terminaison 120 de sortie du tunnel de communication, pour le sens de communication considéré). Dans une étape 502, la sonde réseau déduit l’adresse d’une sonde réseau distante, avec laquelle ladite sonde réseau doit collaborer pour la surveillance du trafic du tunnel de communication en question. Pour ce faire, ladite sonde réseau récupère l’adresse du point de terminaison distant, c’est-à-dire celui qui est de l’autre côté du tunnel de communication qui a été nouvellement détecté à l’étape 501. L’adresse destination correspond au point de terminaison 120 auquel est associée ladite sonde réseau, donc l’adresse du point de terminaison distant est l’adresse source. A noter qu’aucune inspection profonde de paquet n’est requise. Ladite sonde réseau déduit alors l’adresse de la sonde réseau distante, avec laquelle ladite sonde réseau doit collaborer pour surveiller le tunnel de communication en question, en appliquant la fonction de translation bijective, comme déjà expliqué ci-avant. L’étape 502 est l’équivalente de l’étape 402, de l’autre côté du tunnel de communication, afin de permettre d’établir les communications inter-sondes. Dans une étape 503, la sonde réseau effectue des captures et des mesures de débit de données pour le tunnel de communication en question. Les mesures de débit de données sont réalisées par comptage de volume de données reçues entre des paquets fanions successifs, détectés dans le trafic sortant du tunnel de communication. Les mesures de débit de données peuvent être réalisées par type de service dans le tunnel de communication, par exemple en s’appuyant sur une information de type de service (e.g. champ DSCP) incluse dans les paquets d’encapsulation du tunnel de communication. Dans une étape 504, la sonde réseau effectue une surveillance du trafic de données dans le tunnel de communication en question, à partir des mesures effectuées à l’étape 503. Comme déjà indiqué, les paquets fanions servent de référence d’horloge pour déterminer des variations de cadencement entre l’entrée et la sortie du tunnel de communication, comme schématiquement illustré sur la . Une boucle est alors réalisée entre les étapes 504 et 503, de sorte à surveiller le trafic dans le tunnel de communication en question, par cycles temporels définis par les paquets fanions. La illustre schématiquement une variation de cadencement de flux de données dans un tunnel de communication T. En entrée du tunnel de communication, les données sont transmises (par exemple pour un type de service donné) selon un débit DR-tx. L’injecteur de la sonde réseau en entrée du tunnel de communication transmet, à période constante, des paquets fanions 1 à 7 dans le flux de données entrant dans le tunnel de communication. Les paquets fanions 1 à 7 sont donc transmis par le point de terminaison 120 en entrée du tunnel de communication à des instants respectifs t1 à t7 séparés par une période fixe configurée Ts. La période Ts peut être définie en fonction d’une bande passante et d’une latence attendue (e.g., théorique) dans le réseau de communication 100a via lequel est établi le tunnel de communication T. En sortie du tunnel de communication, les données sont reçues (par exemple pour un type de service donné) selon un débit DR-rx qui diffère typiquement du débit DR-tx en entrée du tunnel de communication T. Les paquets fanions 1 et 3 à 7 sont donc reçus par le point de terminaison 120 en sortie du tunnel de communication à des instants respectifs t’1 et t’3 à t’7 qui ne sont pas séparés par la période fixe Ts, et sur la , le paquet 2 a été perdu en route. Le flux de données a donc subi une variation de cadencement dans le tunnel de communication T supervisé. Grâce à l’information d’horodatage contenue dans les paquets fanions, la sonde réseau en sortie du tunnel de communication est en mesure de déterminer le cadencement en entrée du tunnel de communication. En déterminant un horodatage des paquets fanions reçus en sortie du tunnel de communication (récupération d’une information représentative de l’instant de réception), la sonde réseau en sortie du tunnel de communication est en mesure de déterminer le cadencement en sortie du tunnel de communication. En comparant le cadencement en entrée du tunnel de communication et le cadencement en sortie du tunnel de communication, la variation de cadencement dans le tunnel de communication T supervisé peut être déterminée. La illustre schématiquement un organigramme de création et de mise à jour d’une ou plusieurs tables de mesures stockant des informations représentatives de la variation de cadencement de flux de données telle que schématiquement illustrée sur la . L’organigramme de la est implémenté par chaque sonde réseau, et plus particulièrement par chaque gestionnaire de plan de contrôle (e.g., CPM1 170a) dans l’architecture modulaire schématiquement illustrée sur la . Dans une étape 701, la sonde réseau obtient un paquet de données du tunnel de communication, résultant du filtrage réalisé par le module de capture 165 sur l’ensemble des paquets de données transitant (émission / réception) via le point de terminaison 120 auquel ladite sonde réseau est associée. Dans une étape 702, la sonde réseau détermine si le paquet de données concerne le point de terminaison 120 auquel ladite sonde réseau est associée. Si tel n’est pas le cas, il est mis fin à l’algorithme dans une étape 708 ; sinon, une étape 703 est effectuée. Dans le cas d’un rôle de sonde réseau amont par rapport au tunnel de communication, l’adresse source pointe sur le point de terminaison 120 auquel ladite sonde réseau est associée. Dans le cas d’un rôle de sonde réseau aval par rapport au tunnel de communication, l’adresse destination pointe sur le point de terminaison 120 auquel ladite sonde réseau est associée. Dans l’étape 703, la sonde réseau détermine si le paquet de données filtré est issu d’un tunnel de communication déjà connu de ladite sonde réseau. Préférentiellement, les mesures étant effectuées par type de service, la sonde réseau détermine auquel cas, en outre, si le type de service est déjà connu pour le tunnel de communication. Le tunnel de communication est déjà connu si l’adresse source et l’adresse destination du paquet filtré forment un couple de points de terminaison 120 identifiés en mémoire de la sonde réseau. Si les conditions ci-dessus sont vérifiées, une étape 705 est effectuée ; sinon, une étape 704 est effectuée. Dans l’étape 704, la sonde réseau crée une table pour le tunnel de communication nouvellement détecté et/ou une table pour le type de service nouvellement détecté. La sonde réseau initialise chaque table ainsi créée. Par exemple, la table est adaptée pour inclure 256 échantillons. Lorsque la table devient pleine, la sonde réseau écrase l’échantillon le plus ancien lorsque ladite sonde réseau doit stocker un nouvel échantillon dans ladite table. Dit autrement, la sonde réseau instancie en mémoire (dans une base de données, par exemple) un descripteur, pour le tunnel de communication nouvellement détecté et/ou le type de service nouvellement détecté, permettant de stocker ultérieurement des captures et des métriques relatives à des mesures de trafic de données dudit tunnel de communication. Puis, l’étape 705 est effectuée. Dans l’étape 705, la sonde réseau détermine si le paquet de données filtré est un paquet fanion. Si tel est le cas, une étape 706 est effectuée ; sinon, une étape 707 est effectuée. Dans l’étape 706, la sonde réseau crée une nouvelle entrée dans la table correspondant au tunnel de communication, et éventuellement au type de service auquel le paquet fanion correspond. Chaque entrée de table correspond à un échantillon. Dans un mode de réalisation particulier, lorsque la sonde réseau a un rôle de sonde amont, chaque entrée de table inclut : - un champ d’information d’horodatage telle que contenue dans le paquet fanion qui a entraîné la création de l’entrée dans la table ; - un champ de numéro de séquence tel que contenu dans le paquet fanion qui a entraîné la création de l’entrée dans la table ; - un champ de comptage de données transitant dans le tunnel de communication, pour le sens de communication considéré (pour le type de service auquel le paquet fanion correspond, si applicable). Et lorsque la sonde réseau a un rôle de sonde aval, chaque entrée de table inclut : - un champ d’information d’horodatage telle que contenue dans le paquet fanion qui a entraîné la création de l’entrée dans la table ; - un champ d’information d’horodatage marquant l’instant auquel le paquet fanion, qui a entraîné la création de l’entrée dans la table, a été reçu (horodatage de capture) ; - un champ de numéro de séquence tel que contenu dans le paquet fanion qui a entraîné la création de l’entrée dans la table ; - un champ de comptage de données transitant dans le tunnel de communication, pour le sens de communication considéré (pour le type de service auquel le paquet fanion correspond, si applicable). Puis, l’étape 708 est effectuée, où il est mis fin à l’algorithme. Dans l’étape 707, la sonde réseau effectue un comptage des paquets transitant dans le tunnel de communication, pour le sens de communication considéré. Le paquet filtré reçu est pris en compte dans l’échantillon en cours dans la table correspondante. Par exemple, un nombre de paquets reçus à la suite du paquet fanion qui a entraîné la création de l’entrée correspondante dans la table est incrémenté d’une unité. De plus, une quantité de données reçues à la suite du paquet fanion qui a entraîné la création de l’entrée correspondante dans la table est incrémenté de la taille du paquet filtré. Il convient de noter qu’en procédant ainsi les paquets fanions ne sont pas pris en compte dans le comptage. Il est aussi possible de prendre en compte les paquets fanions dans le comptage ; dans ce cas, l’étape 706 est suivie de l’étape 707 et non de l’étape 708. Le même mécanisme de comptage est ainsi appliqué en amont et en aval du tunnel de communication considéré. Puis, l’étape 708 est effectuée, où il est mis fin à l’algorithme. En procédant ainsi un historique des échantillonnages réalisés par la sonde réseau est stocké en mémoire. La comparaison des historiques des échantillonnages de part et d’autre du tunnel de communication permet de détecter et d’évaluer les situations de congestion, que ce soit en termes de latence, de gigue (« jitter » en anglais) ou de pertes de paquet lors du transit dans le tunnel de communication. Le protocole inter-sondes permet aux sondes réseau supervisant un même tunnel de communication, ou l’orchestrateur 180, de collecter ces historiques des échantillonnages de part et d’autre du tunnel de communication, afin d’en effectuer la comparaison. Dans un mode de réalisation particulier, une des sondes réseau (typiquement la sonde réseau en amont du tunnel de communication, dans un sens de communication considéré) demande à l’autre sonde réseau de l’autre côté du tunnel de communication de lui transmettre en réponse son historique d’échantillonnage. Une requête MeasReq est transmise pour ce faire dans le cadre du protocole inter-sondes. Préférentiellement, la requête comporte un champ indiquant un intervalle de numéros de séquence de paquets fanions pour lequel l’historique doit être fourni en réponse. Préférentiellement, la requête comporte elle-même un numéro de séquence qui lui est propre, qui est repris dans une réponse MeasResp fournissant l’historique d’échantillonnages demandé, afin de faciliter l’association requête - réponse. Lorsqu’une sonde réseau reçoit de son homologue de l’autre côté du tunnel une requête MeasReq, ladite sonde réseau détermine quel intervalle d’historique d’échantillonnages est concerné par la demande. La sonde réseau retrouve alors en mémoire l’historique d’échantillonnages demandé. Si à cause de pertes de paquets (e.g. perte du paquet fanion 2 dans la ), l’historique d’échantillonnages disponible en mémoire de ladite sonde ne correspond pas à l’historique d’échantillonnages demandé, alors la sonde réseau retrouve alors en mémoire l’historique d’échantillonnages le plus proche de l’historique d’échantillonnages demandé et le transmet dans la réponse MeasResp. La réponse MeasResp inclut une information indiquant quel intervalle d’historique d’échantillonnages est réellement retourné. Par exemple, en s’appuyant sur la , une requête MeasReq demande l’historique d’échantillonnages concernant l’intervalle de numéros de séquence de paquets fanions allant de 2 à 6. Etant donné que le paquet fanion 2 a été perdu en route, la réponse MeasReq inclut l’historique d’échantillonnages concernant l’intervalle de numéros de séquence de paquets fanions allant de 1 à 6. En variante, la réponse MeasReq inclut l’historique d’échantillonnages concernant l’intervalle de numéros de séquence de paquets fanions allant de 3 à 6. -