FR3131673A1 - Protocole de surveillance de trafic de communication - Google Patents
Protocole de surveillance de trafic de communication Download PDFInfo
- Publication number
- FR3131673A1 FR3131673A1 FR2205287A FR2205287A FR3131673A1 FR 3131673 A1 FR3131673 A1 FR 3131673A1 FR 2205287 A FR2205287 A FR 2205287A FR 2205287 A FR2205287 A FR 2205287A FR 3131673 A1 FR3131673 A1 FR 3131673A1
- Authority
- FR
- France
- Prior art keywords
- flag
- probe
- packets
- communication tunnel
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000004891 communication Methods 0.000 title claims abstract description 325
- 238000012544 monitoring process Methods 0.000 title claims description 18
- 239000000523 sample Substances 0.000 claims abstract description 399
- 238000002347 injection Methods 0.000 claims abstract description 6
- 239000007924 injection Substances 0.000 claims abstract description 6
- 238000005259 measurement Methods 0.000 claims description 91
- 238000005070 sampling Methods 0.000 claims description 47
- 230000004044 response Effects 0.000 claims description 46
- 238000004364 calculation method Methods 0.000 claims description 41
- 238000011144 upstream manufacturing Methods 0.000 claims description 25
- 238000000034 method Methods 0.000 claims description 15
- 238000001514 detection method Methods 0.000 claims description 6
- 230000005540 biological transmission Effects 0.000 description 14
- HRULVFRXEOZUMJ-UHFFFAOYSA-K potassium;disodium;2-(4-chloro-2-methylphenoxy)propanoate;methyl-dioxido-oxo-$l^{5}-arsane Chemical compound [Na+].[Na+].[K+].C[As]([O-])([O-])=O.[O-]C(=O)C(C)OC1=CC=C(Cl)C=C1C HRULVFRXEOZUMJ-UHFFFAOYSA-K 0.000 description 14
- 238000004422 calculation algorithm Methods 0.000 description 11
- 238000005538 encapsulation Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 7
- 238000001914 filtration Methods 0.000 description 6
- 230000006399 behavior Effects 0.000 description 5
- 238000011156 evaluation Methods 0.000 description 5
- 238000007726 management method Methods 0.000 description 5
- 238000013519 translation Methods 0.000 description 5
- 238000000207 volumetry Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 230000000295 complement effect Effects 0.000 description 3
- WBMKMLWMIQUJDP-STHHAXOLSA-N (4R,4aS,7aR,12bS)-4a,9-dihydroxy-3-prop-2-ynyl-2,4,5,6,7a,13-hexahydro-1H-4,12-methanobenzofuro[3,2-e]isoquinolin-7-one hydrochloride Chemical compound Cl.Oc1ccc2C[C@H]3N(CC#C)CC[C@@]45[C@@H](Oc1c24)C(=O)CC[C@@]35O WBMKMLWMIQUJDP-STHHAXOLSA-N 0.000 description 2
- 101000957815 Culex pipiens Alpha-glucosidase Proteins 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000007689 inspection Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 102100027241 Adenylyl cyclase-associated protein 1 Human genes 0.000 description 1
- 108010077333 CAP1-6D Proteins 0.000 description 1
- 101100048435 Caenorhabditis elegans unc-18 gene Proteins 0.000 description 1
- 101100001773 Oryza sativa subsp. japonica AOC gene Proteins 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 108010031970 prostasin Proteins 0.000 description 1
- 230000004043 responsiveness Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/12—Network monitoring probes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
- H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
- H04J3/0658—Clock or time synchronisation among packet nodes
- H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Cardiology (AREA)
- General Health & Medical Sciences (AREA)
- Environmental & Geological Engineering (AREA)
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Une première sonde réseau est associée à un premier routeur et à un premier point de terminaison du premier routeur, et une deuxième sonde réseau est associée à un deuxième routeur et à un deuxième point de terminaison du deuxième routeur. La première sonde réseau injecte de façon périodique des paquets fanions en parallèle du trafic d’un tunnel de communication entre les premier et second points de terminaison, chaque paquet fanion incluant une information d’horodatage exprimant une référence temporelle d’injection dudit paquet fanion. Des informations relatives à une variation de cadencement de trafic dans le tunnel de communication sont collectées, la variation de cadencement étant mesurée grâce à une différence entre les informations d’horodatage contenues dans les paquets fanions et des informations d’horodatage d’instant de capture des paquets fanions par la deuxième sonde réseau. D’éventuelles situations de congestion subies par le tunnel de communication sont évaluées en fonction des informations collectées. Figure à publier avec l’abrégé : Fig. 6
Description
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).
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é dans un système de communication comportant une pluralité de routeurs, une première sonde réseau étant associée à un premier routeur de ladite pluralité de routeurs et à un premier point de terminaison du premier routeur, une deuxième sonde réseau étant associée à un deuxième routeur de ladite pluralité de routeurs et à un deuxième point de terminaison du premier routeur, le procédé comportant les étapes suivantes dans le cadre d’un surveillance d’un trafic dans un tunnel de communication entre le premier point de terminaison et le deuxième point de terminaison : injecter de façon périodique, par la première sonde, des paquets fanions en parallèle du trafic du tunnel de communication, chaque paquet fanion incluant une information d’horodatage exprimant une référence temporelle d’injection dudit paquet fanion ; collecter des informations relatives à une variation de cadencement de trafic dans le tunnel de communication, la variation de cadencement étant mesurée grâce à une différence entre les informations d’horodatage contenues dans les paquets fanions et des informations d’horodatage d’instant de capture desdits paquets fanions par la deuxième sonde ; évaluer d’éventuelles situations de congestion subies par le tunnel de communication en fonction desdites informations collectées. Ainsi, la différence du cadencement en réception des paquets fanions par rapport à leur cadencement en émission permet d’estimer la variation de cadencement dans le tunnel de communication qui prend le même chemin que les paquets fanions, et ainsi d’évaluer finement les situations de congestion pouvant survenir.
Dans un mode de réalisation particulier, le procédé comprend l’étape suivante : calculer une éventuelle perte de volume de données dans le tunnel de communication, par comparaison entre un comptage de volume de données en sortie du tunnel de communication entre des paquets fanions successifs, détectées par la deuxième sonde, et un comptage de volume de données en entrée du tunnel de communication entre des paquets fanions successifs, détectées par la première sonde.
Dans un mode de réalisation particulier, les paquets fanions sont des paquets de type UDP émis sur un port dédié auxdits paquets fanions. Ainsi, les paquets fanions peuvent être aisément capturés par les sondes réseau.
Dans un mode de réalisation particulier, les paquets fanions sont injectés pour chaque type de service parmi une pluralité de types de service transportés par le tunnel de communication. Ainsi, les situations de congestion peuvent être évaluées pour chaque type de service, donc plus finement.
Dans un mode de réalisation particulier, les paquets fanions sont injectés dans un plan utilisateur en amont du premier point de terminaison par rapport au tunnel de communication.
Dans un mode de réalisation particulier, pour collecter les informations relatives à une variation de cadencement de flux de données dans le tunnel de communication, au moins la deuxième sonde réseau comporte au moins une table de mesures pour stocker un historique d’échantillonnages de paquets fanions capturés en sortie du tunnel de communication, chaque entrée de la table de mesures correspondant à un échantillon comportant : un champ d’information d’horodatage telle que contenue dans le paquet fanion correspondant à l’échantillon en question ; un champ d’information d’horodatage marquant l’instant auquel le paquet fanion correspondant à l’échantillon en question a été capturé ; un champ de numéro de séquence tel que contenu dans le paquet fanion correspondant à l’échantillon en question ; et un champ de comptage de données transitant dans le tunnel de communication entre le paquet fanion correspondant à l’échantillon en question et le paquet fanion correspondant à l’échantillon suivant dans la table de mesures. Ainsi, l’historique d’échantillonnages est aisément construit par la deuxième sonde pour permettre l’évaluation des situations de congestion.
Dans un mode de réalisation particulier, la première sonde transmet à la deuxième sonde une requête requérant de transmettre en réponse des informations dérivées par calculs d’un historique d’échantillonnages des paquets fanions reçus par la deuxième sonde, la requête impliquant un intervalle de numéros de séquence à considérer, les calculs étant destinés à évaluer les éventuelles situations de congestion et incluant : une latence minimum de transit des paquets fanions dudit intervalle de numéros de séquence ; une latence maximum de transit des paquets fanions dudit intervalle de numéros de séquence ; une latence moyenne de transit des paquets fanions dudit intervalle de numéros de séquence ; une gigue minimum subie par les paquets fanions dudit intervalle de numéros de séquence ; une gigue maximum subie par les paquets fanions dudit intervalle de numéros de séquence ; une gigue moyenne subie dudit intervalle de numéros de séquence ; une volumétrie de transit de données dans le tunnel de communication sur ledit intervalle de numéros de séquence. Ainsi, la consommation en bande passante pour transmettre par la deuxième sonde à la première sonde des informations permettant d’évaluer les situations de congestion est réduite.
Dans un mode de réalisation particulier, la première sonde transmet à la deuxième sonde une requête requérant de transmettre en réponse tout ou partie de l’historique d’échantillonnages des paquets fanions reçus par la deuxième sonde, la première sonde réalisant alors des calculs destinés à évaluer les éventuelles situations de congestion et incluant : une latence minimum de transit des paquets fanions dudit intervalle de numéros de séquence ; une latence maximum de transit des paquets fanions dudit intervalle de numéros de séquence ; une latence moyenne de transit des paquets fanions dudit intervalle de numéros de séquence ; une gigue minimum subie par les paquets fanions dudit intervalle de numéros de séquence ; une gigue maximum subie par les paquets fanions dudit intervalle de numéros de séquence ; une gigue moyenne subie dudit intervalle de numéros de séquence ; une volumétrie de transit de données dans le tunnel de communication sur ledit intervalle de numéros de séquence.
Dans un mode de réalisation particulier, la première sonde réseau comporte au moins une autre table de mesures pour stocker un historique d’échantillonnages de paquets fanions capturés en entrée du tunnel de communication, chaque entrée de cette autre table de mesures correspondant à un échantillon comportant : un champ d’information d’horodatage telle que contenue dans le paquet fanion correspondant à l’échantillon en question ; un champ d’information d’horodatage marquant l’instant auquel le paquet fanion correspondant à l’échantillon en question a été capturé ; un champ de numéro de séquence tel que contenu dans le paquet fanion correspondant à l’échantillon en question ; et un champ de comptage de données transitant dans le tunnel de communication entre le paquet fanion correspondant à l’échantillon en question et le paquet fanion correspondant à l’échantillon suivant dans la table de mesures. Ainsi, l’historique d’échantillonnages est aisément construit par la première sonde pour permettre l’évaluation des situations de congestion.
Dans un mode de réalisation particulier, la première sonde réseau calcule une information supplémentaire de latence et une information supplémentaire de gigue, qui sont liées à la qualité de service du premier routeur, en comparant les informations d’horodatage contenues dans les paquets fanions injectés et les informations d’horodatage de capture des paquets fanions capturés par ladite première sonde réseau. Ainsi, l’implication du routeur en question dans les situations de congestion peut être aisément évaluée.
Dans un mode de réalisation particulier, la première sonde estime en outre une éventuelle perte de volume de données qui est liée à la qualité de service du premier routeur, à partir de détection de pertes de paquets fanions injectés par la première sonde. Ainsi, l’évaluation de l’implication du routeur en question dans les situations de congestion est complétée.
Il est aussi proposé un système de communication comportant des sondes réseau et une pluralité de routeurs, une première sonde réseau étant associée à un premier routeur de ladite pluralité de routeurs et à un premier point de terminaison du premier routeur, une deuxième sonde réseau étant associée à un deuxième routeur de ladite pluralité de routeurs et à un deuxième point de terminaison du premier routeur, le système de communication comportant de la circuiterie électronique configurée pour effectuer les étapes suivantes dans le cadre d’un surveillance d’un trafic dans un tunnel de communication entre le premier point de terminaison et le deuxième point de terminaison : injecter de façon périodique, par la première sonde, des paquets fanions en parallèle du trafic du tunnel de communication, chaque paquet fanion incluant une information d’horodatage exprimant une référence temporelle d’injection dudit paquet fanion ; collecter des informations relatives à une variation de cadencement de trafic dans le tunnel de communication, la variation de cadencement étant mesurée grâce à une différence entre les informations d’horodatage contenues dans les paquets fanions et des informations d’horodatage d’instant de capture desdits paquets fanions par la deuxième sonde ; évaluer d’éventuelles situations de congestion subies par le tunnel de communication en fonction desdites informations collectées.
La description suivante d’au moins un mode de réalisation est établie en relation avec les dessins joints, parmi lesquels :
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 au protocole mGRE (« Multipoint 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 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, et de capter le volume de paquets transmis dans les tunnels de communication et les paquets fanions y afférents.
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 par exemple d’obtenir une copie de tout paquet de données de type GRE, mGRE 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 sous-module de capture de trafic sortant du tunnel de communication, le tunnel de communication étant bidirectionnel. 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 en parallèle du 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. Les paquets fanions ne sont donc pas encapsulés dans le protocole du tunnel de communication, mais suivent le même chemin. En effet, si le protocole du tunnel de communication emploie un chiffrement des données, les paquets fanions ne pourraient alors pas être détectés en réception. 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é, mais sans que les paquets fanions ne transitent par le tunnel de communication en question. Le plan utilisateur 140 est le chemin de données dans le routeur 110 auquel ladite sonde réseau est associée et par lequel transitent les paquets issus du réseau de communication 100b qui sont transmis dans le tunnel de communication en question par le point de terminaison 120 local. En variante, lorsque le tunnel de communication n’emploie pas de chiffrement, les paquets fanions peuvent faire partie du trafic transitant dans le tunnel de communication et être vus par le point de terminaison 120 local comme étant issus du réseau de communication 100b en amont du point de terminaison 120 local par rapport au tunnel de communication supervisé. Dans une autre variante où le trafic dans le tunnel de communication peut être chiffré, l’injecteur 150 injecte les paquets fanions entre le point de terminaison 120 en entrée du tunnel de communication et le point de capture local de la sonde réseau considérée. Dans tous les cas de figure évoqués ci-dessus, 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.
Il convient de noter qu’une partie du contenu des paquets fanions, non nécessaire à leur routage, peut être chiffrée entre les sondes réseau impliquées. Cependant, le chiffrement appliqué est maîtrisé par les sondes réseau en question et est indépendant du chiffrement utilisé par le tunnel de communication auquel les paquets fanions en question sont associés.
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 (« Differentiated Services Code Point » en anglais) des paquets du tunnel de communication.
Chaque paquet fanion inclut une information d’horodatage (« timestamp » en anglais) exprimant une référence temporelle d’injection dudit paquet fanion, ainsi qu’un identifiant de séquence (Seq).
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 de 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’autre 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.
Dans un mode de réalisation particulier, 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 terminaison 120 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.
En variante de réalisation, les sondes réseau ont des adresses indépendantes des adresses des points de terminaison 120 de tunnel de communication. Eventuellement, les injecteurs 150 ont des adresses qui leur sont propres. A la découverte d’un tunnel de communication, la sonde réseau en question notifie son plan d’adressage à la sonde réseau distante. Pour ce faire, un message est envoyé sur un port dédié (par exemple, un port UDP dédié) aux messages inter-sondes, avec un identifiant de message dédié. Le message en question indique quels points de terminaison 120 sont concernés par le tunnel de communication découvert. La sonde distante étant configurée pour recevoir (écouter) les messages reçus sur ce port dédié, cette sonde distante peut reconnaître le tunnel de communication (le point de terminaison 120) qui la concerne, et le plan d’adressage utilisé de l’autre côté du tunnel de communication lui devient connu. Cette sonde distante peut à son tour transmettre son propre plan d’adressage de la même manière. Dans un mode de réalisation particulier, les paquets fanions incluent une information indiquant quels points de terminaison 120 sont concernés par le tunnel de communication auquel sont associés lesdits paquets fanions, ainsi que le plan d’adressage évoqué ci-dessus.
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 plus prioritaire que les paquets qui sont encapsulés dans les tunnels de communication supervisés (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, la variation de cadencement étant mesurée grâce à une variation de différence entre les informations d’horodatage contenues dans les paquets fanions et des informations d’horodatage d’instant de capture desdits paquets fanions. 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 180 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 résultats de 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.
A noter que l’orchestrateur 180 peut aussi comprendre de manière analogue de la circuiterie électronique agencée et configurée pour implémenter les étapes et comportements décrits ici en relation avec ledit orchestrateur 180.
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, mGRE 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, dans un mode de réalisation particulier, 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.
Ainsi, la sonde réseau peut effectuer 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é.
Comme déjà évoqué, d’autres approches de partage de plan d’adressage peuvent être implémentées.
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.
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 la fréquence d’émission des 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, mGRE 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, dans un mode de réalisation particulier, 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.
Comme déjà évoqué, d’autres approches de partage de plan d’adressage peuvent être implémentées.
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 150 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. Le même raisonnement peut être appliqué en entrée du tunnel de communication, dès que la sonde réseau en amont du tunnel de communication a récupéré un historique horodaté de mesures effectuées par la sonde réseau distante en réception des paquets fanions.
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 de mesures 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 de mesures ainsi créée.
Par exemple, chaque table de mesures est adaptée pour inclure 256 échantillons. Lorsque la table de mesures en question 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 de mesures.
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 de mesures qui correspond 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 (i.e., sonde réseau en amont du tunnel de communication en question pour le sens de communication considéré), 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 de mesures ;
- 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 de mesures ;
- 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 (i.e., sonde réseau en aval du tunnel de communication en question pour le sens de communication considéré), 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 de mesures ;
- 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 de mesures, 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 de mesures ;
- 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).
Dans un autre mode de réalisation particulier, les entrées de table ont le même format quel que soit le rôle, amont ou aval, de la sonde en question, à savoir :
- 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 de mesures ;
- 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 de mesures, a été capturé (que ce soit en amont ou en aval du tunnel de communication, selon le sens de communication auquel s’applique la table de mesures en question) ;
- 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 de mesures ;
- 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).
Un exemple de structure de table de mesures, pour un tunnel de communication considéré et préférentiellement un type de service (e.g., DSCP) considéré dans ledit tunnel de communication, est schématiquement illustré sur la .
L’exemple de la s’applique autant en amont ou en aval du tunnel de communication. La structure de table de mesures illustrée sur la comporte six colonnes, référencées de 801 à 806.
Pour chaque échantillon, la colonne 801 contient une valeur d’index Idx d’échantillon dans la table de mesures. Ici, les valeurs d’index Idx sont présentées dans la colonne 801 par valeurs croissantes, de 0 à 255. Les valeurs d’index Idx sont représentatives de l’ordre dans lequel les paquets fanions traités dans ladite table de mesures ont été capturés (de manière rotative, c’est-à-dire que lorsque l’entrée de valeur d’index Idx égale à 255 est remplie, l’entrée suivante à manipuler est celle de valeur d’index Idx égale à 0).
Pour chaque échantillon, la colonne 802 contient un numéro de séquence Seq tel que contenu dans le paquet fanion qui a entraîné la création, dans la table de mesure, de l’entrée correspondant à la valeur d’index Idx en question.
Pour chaque échantillon, la colonne 803 contient une information d’horodatage FTS telle que contenue dans le paquet fanion qui a entraîné la création, dans la table de mesure, de l’entrée correspondant à la valeur d’index Idx en question.
Pour chaque échantillon, la colonne 804 contient une information d’horodatage CTS marquant l’instant auquel le paquet fanion, qui a entraîné la création de l’entrée dans la table de mesures, de l’entrée correspondant à la valeur d’index Idx en question a été capturé.
Pour chaque échantillon, la colonne 805 contient une information QoP de quantité de paquets 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). L’information QoP indique la quantité de paquets capturés entre le paquet fanion, qui a entraîné la création dans la table de mesures, de l’entrée correspondant à la valeur d’index Idx en question et le prochain fanion qui a entraîné la création dans la table de mesures, de l’entrée correspondant à la valeur d’index Idx suivante, pour le sens de communication considéré (pour le type de service auquel le paquet fanion correspond, si applicable).
Pour chaque échantillon, la colonne 806 contient une information QoB de quantité d’octets 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). L’information QoB indique la quantité d’octets capturés entre le paquet fanion, qui a entraîné la création dans la table de mesures, de l’entrée correspondant à la valeur d’index Idx en question et le prochain fanion qui a entraîné la création dans la table de mesures, de l’entrée correspondant à la valeur d’index Idx suivante, pour le sens de communication considéré (pour le type de service auquel le paquet fanion correspond, si applicable).
Dans la , un échantillon est stocké sur chaque ligne de la table de mesures.
Une ligne 811 stocke un échantillon, à la valeur d’index Idx égale à 0, dont :
- le numéro de séquence Seq est égal à 38 ;
- l’information d’horodatage contenue dans le paquet fanion correspondant a une valeur X0 qui est égale à X, où X est un instant de référence ;
- l’information d’horodatage de capture du paquet fanion correspondant a une valeur X’0 qui est égale à X0+L0, où L0 est une durée de latence de capture par rapport à l’instant X0 où le paquet fanion en question a été émis.
Une ligne 812 stocke un échantillon, à la valeur d’index Idx égale à 1, dont :
- le numéro de séquence Seq est égal à 39 ;
- l’information d’horodatage contenue dans le paquet fanion correspondant a une valeur X1 qui est égale à X+TS, où TS est une valeur prédéfinie fixe de période de cadencement des paquets fanions ;
- l’information d’horodatage de capture du paquet fanion correspondant a une valeur X’1 qui est égale à X1+L1, où L1 est une durée de latence de capture par rapport à l’instant X1 où le paquet fanion en question a été émis.
Une ligne 814 stocke un échantillon, à la valeur d’index Idx égale à 255, dont :
- le numéro de séquence Seq est égal à 293 ;
- l’information d’horodatage contenue dans le paquet fanion correspondant a une valeur X255 qui est égale à X+255*TS ;
- l’information d’horodatage de capture du paquet fanion correspondant a une valeur X’255 qui est égale à X255+L255, où L255 est une durée de latence de capture par rapport à l’instant X255 où le paquet fanion en question a été émis.
Lors des opérations de comptage, les colonnes 805 et 806 sont mises à jour pour indiquer respectivement les quantités de paquets capturés et les quantités d’octets capturés entre des paquets fanions capturés successivement. Ainsi, après remplissage : la ligne 811 contient dans la colonne 805 une mesure de comptage de paquets QoP0, et dans la colonne 806 une mesure de comptage d’octets QoB0 ; la ligne 812 contient dans la colonne 805 une mesure de comptage de paquets QoP1, et dans la colonne 806 une mesure de comptage d’octets QoB1 ; et la ligne 814 contient dans la colonne 805 une mesure de comptage de paquets QoP255, et dans la colonne 806 une mesure de comptage d’octets QoB255.
L’exemple de table de mesures de la contient d’autres lignes 813 contenant d’autres échantillons, entre la ligne 812 et la ligne 814, qui ne sont pas plus amplement détaillées dans cet exemple.
A noter que, comme il se peut que des paquets fanions soient perdus, il est possible que deux échantillons successifs dans la table de mesures aient des numéros de séquence qui ne se suivent pas. Cette situation survient plus particulièrement en aval du tunnel de communication, lorsqu’une congestion sur le chemin emprunté par le tunnel de communication a entraîné des pertes de paquets.
De retour à la , 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ée 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 préférentiellement 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.
Les historiques des échantillonnages de part et d’autre du tunnel de communication permettent 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, ou des informations qui en sont dérivées par calculs, de part et d’autre du tunnel de communication, afin d’évaluer d’éventuelles situations de congestion.
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 des données d’historique d’échantillonnages ou des informations qui en sont dérivées par calculs. 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, ou lesdites informations qui en sont dérivées par calculs, doit être fourni en réponse. Préférentiellement, la requête MeasReq 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 en mémoire l’historique d’échantillonnages le plus proche de l’historique d’échantillonnages demandé et le transmet, ou des informations qui en sont dérivées par calculs, dans la réponse MeasResp. La réponse MeasResp inclut une information indiquant quel intervalle d’historique d’échantillonnages est réellement retourné, ou respectivement quel intervalle d’historique d’échantillonnages a été réellement utilisé pour dériver les informations retournées.
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 MeasResp 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 MeasResp inclut l’historique d’échantillonnages concernant l’intervalle de numéros de séquence de paquets fanions allant de 3 à 6.
La illustre schématiquement un organigramme de collaboration de sondes réseau P1 901 et P2 902 pour évaluer une situation de congestion dans un tunnel de communication, dans un premier mode de réalisation.
Dans une étape 910, la sonde réseau P1 901, en amont du tunnel de communication, envoie une requête MeasReq à la sonde P2 902, en aval du tunnel de communication. La requête MeasReq est de type MeasReq1, et comporte préférentiellement une indication d’au moins un type de service (e.g., DSCP), ainsi qu’un champ indiquant un intervalle de numéros de séquence de paquets fanions, pour lesquels des résultats de calculs de latence, gigue et volumétrie doivent être fournis en réponse. Les calculs sont réalisés par la sonde P2 902 au vu de l’historique d’échantillonnages stocké par la sonde P2 902 vis-à-vis dudit ou desdits types de service précisés dans la requête MeasReq dans le tunnel de communication considéré. Si ce n’est implicite dans le protocole inter-sondes, la requête MeasReq indique quel tunnel de communication est concerné, et quel sens de communication est aussi concerné (par exemple, en indiquant une adresse de point de terminaison 120 source et de point de terminaison 120 destination).
Dans un mode de réalisation particulier, l’intervalle de numéros de séquence est notifié dans la requête MeasReq uniquement par un numéro de séquence de borne inférieure de l’intervalle en question, étant implicitement entendu que la borne supérieure de l’intervalle en question se termine au dernier paquet fanion reçu par la sonde P2 902.
Préférentiellement, la sonde réseau P1 901 mémorise le numéro de séquence Seq du dernier paquet fanion localement capturé et la volumétrie actuelle telle que vue par la sonde réseau P1 901 au moment de l’envoi de la requête MeasReq. Cela permet par la suite, à la sonde réseau P1 901, d’estimer la perte de volume de données dans le cas où tous les paquets fanions seraient perdus sur l’intervalle de numéros de séquence de paquets fanions sur lequel s’applique la requête MeasReq.
Dans une étape 911, la sonde réseau P2 902 reçoit la requête MeasReq émise par la sonde P1 901.
Dans une étape 912, la sonde réseau P2 902 recherche l’intervalle de numéros de séquence sur lequel porte la requête MeasReq, d’après les indications contenues dans ladite requête MeasReq. Si à cause de pertes de paquets, l’historique d’échantillonnages disponible en mémoire de la sonde réseau P2 902 ne correspond pas à l’historique d’échantillonnages demandé par la sonde réseau P1 901, alors la sonde réseau P2 902 retrouve en mémoire l’historique d’échantillonnages le plus proche de l’historique d’échantillonnages demandé par la sonde réseau P1 901.
Dans une étape 913, la sonde réseau P2 902 sélectionne la ou les tables de mesures appropriées d’après le ou les types de service (e.g., DSCP) concernés, et récupère (« retrieve » en anglais) les échantillons (mesures) qui correspondent à l’intervalle de numéros de séquence recherché et qui sont contenus dans cette ou ces tables de mesures. Cette récupération d’échantillons délimite une zone de calculs parmi l’historique d’échantillonnages stocké par la sonde réseau P2 902.
Dans une étape 914, la sonde réseau P2 902 effectue des calculs de latence, gigue et volumétrie, pour chaque type de service requis. En se référant à la , la sonde réseau P2 902 utilise la différence entre la colonne 804 et la colonne 803. Préférentiellement, la sonde réseau P2 902 calcule :
- la latence minimum de transit des paquets fanions de l’intervalle de numéros de séquence considéré ;
- la latence maximum de transit des paquets fanions de l’intervalle de numéros de séquence considéré ;
- la latence moyenne de transit des paquets fanions de l’intervalle de numéros de séquence considéré ;
- la gigue minimum subie par les paquets fanions de l’intervalle de numéros de séquence considéré ;
- la gigue maximum subie par les paquets fanions de l’intervalle de numéros de séquence considéré ;
- la gigue moyenne subie par les paquets fanions de l’intervalle de numéros de séquence considéré ;
- la volumétrie de transit de données (quantité de paquets, d’octets…) dans le tunnel de communication sur l’intervalle de numéros de séquence considéré.
La sonde réseau P2 902 prépare alors une réponse MeasResp. La réponse MeasResp est de type MeasResp1, adapté pour fournir les informations demandées par la requête MeasReq de type MeasReq1.
La sonde réseau P2 902 ajoute dans la réponse MeasResp les informations récupérées suivantes, pour chaque type de service requis :
- l’intervalle de numéros de séquence réellement considéré ;
- la volumétrie actuelle (c’est-à-dire, au moment où la requête MeasReq est reçue) du dernier paquet fanion reçu et le numéro de séquence Seq dudit dernier paquet fanion reçu.
Alors, dans une étape 915, la sonde réseau P2 902 envoie la réponse MeasResp, de type MeasResp1, ainsi préparée. La réponse MeasResp est envoyée à la sonde réseau P1 901 en réponse à la requête MeasReq reçue à l’étape 911.
Dans une étape 916, la sonde réseau P1 901 reçoit la réponse MeasResp émise par la sonde P2 902.
Dans une étape 917, la sonde réseau P1 901 calcule une éventuelle perte de volume de données (de paquets, d’octets…) sur l’intervalle de numéros de séquence réellement considéré par la sonde réseau P2 902 pour effectuer ses calculs et construire la réponse MeasResp. La perte de volume de données correspond à la différence entre la volumétrie calculée par la sonde réseau P1 901 vis-à-vis de son propre historique d’échantillonnages, sur l’intervalle de numéros de séquence réellement considéré par la sonde réseau P2 902, et la volumétrie transmise par la sonde réseau P2 902 dans la réponse MeasResp.
Lorsque les numéros de séquence constituant les bornes de l’intervalle de numéros de séquence de l’historique retourné dans la réponse MeasResp sont les mêmes, une perte totale des paquets fanions entre deux mesures successives est survenue. Dans ce cas, les valeurs de latence et gigue transmises par la sonde réseau P2 902 ne sont pas prises en compte par la sonde réseau P1 901. La sonde réseau P1 901 calcule alors une valeur approximée de la perte de volume de données. En effet, lorsqu’un paquet fanion a été perdu, la volumétrie est cumulée en réception sur l’échantillon du dernier paquet fanion reçu (c’est-à-dire que, en considérant que le paquet fanion de numéro séquence S2 a été perdu, la volumétrie en réception associée au numéro séquence S1 = S2-1 cumule la volumétrie des paquets non-perdus en chemin qui ont été transmis entre le paquet fanion de numéro séquence S1 et le paquet fanion de numéro séquence S3=S2+1 au lieu de simplement la volumétrie des paquets non-perdus en chemin qui ont été transmis entre le paquet fanion de numéro séquence S1 et le paquet fanion de numéro séquence S2). Ainsi, en considérant deux réponses MeasResp successives, la sonde réseau P1 901 peut estimer la perte de volume de données en déterminant la différence d’informations de « volumétrie actuelle » telles qu’indiquées dans lesdites deux réponses MeasResp successives, et en la comparant avec la différence d’informations de « volumétrie actuelle » telles que mémorisées à l’envoi des requêtes MeasReq correspondantes.
Dans une étape 918, la sonde réseau P1 901 mémorise des informations permettant de savoir où en est la surveillance du tunnel de communication vis-à-vis des historiques d’échantillonnages, pour le ou les types de service (e.g., DSCP) considérés. Typiquement, la sonde réseau P1 901 mémorise le numéro de séquence Seq du dernier paquet fanion reçu et la volumétrie actuelle, tels qu’indiqués par la sonde réseau P2 902 dans la réponse MeasResp.
Dans une étape 919, grâce aux informations de latence et de gigue transmises par la sonde réseau P2 902 et au calcul d’éventuelle perte de volume de données à l’étape 917, la sonde réseau P1 901 évalue si une éventuelle situation de congestion est rencontrée par le tunnel de communication, que ce soit en termes de latence, de gigue, ou de pertes de paquet lors du transit dans le tunnel de communication. Grâce à cette évaluation de situation de congestion, la sonde réseau P1 901 peut 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. En variante, la sonde réseau P1 901 remonte à l’orchestrateur 180 des informations relatives aux calculs, de sorte à permettre à l’orchestrateur 180 d’ajuster la gestion d’admission de services.
Faire effectuer les calculs de latence, gigue et volumétrie en réception permet que le message MeasResp soit de petite taille comparativement à l’envoi des mesures brutes. Ainsi, le protocole inter-sondes a un coût réduit sur la consommation de bande passante.
Cependant, plutôt que les calculs de latence, gigue et volumétrie en réception soient effectués par la sonde réseau aval, ces calculs peuvent être réalisés par la sonde amont. La sonde amont doit alors récupérer tout ou partie de l’historique d’échantillonnages de la sonde aval. Cette approche est particulièrement avantageuse lorsque l’injecteur 150 est placé en amont du point de terminaison 120 local et que le routeur local implique par lui-même une latence de transit non négligeable par rapport à la latence de transit du tunnel de communication supervisé. Cette situation est présentée ci-après en relation avec la .
La illustre schématiquement un organigramme de collaboration de sondes réseau P3 1001 et P4 1002 pour évaluer une situation de congestion dans un tunnel de communication, dans un deuxième mode de réalisation. Dans ce deuxième mode de réalisation, l’ensemble des calculs sont réalisés par la sonde amont, la sonde aval transmettant simplement tout ou partie du contenu de sa ou ses tables de mesures.
Dans une étape 1010, la sonde réseau P3 1001, en amont du tunnel de communication, envoie une requête MeasReq à la sonde P4 1002, en aval du tunnel de communication. La requête MeasReq est de type MeasReq2, et comporte préférentiellement une indication d’au moins un type de service (e.g., DSCP) pour lesquels l’historique d’échantillonnages doit être fourni en réponse. Si ce n’est implicite dans le protocole inter-sondes (par exemple, l’ensemble de la ou des tables de mesures concernées), la requête MeasReq contient un champ indiquant un intervalle de numéros de séquence de paquets fanions, pour lequel l’historique d’échantillonnages doit être fourni en réponse. Si ce n’est implicite dans le protocole inter-sondes, la requête MeasReq indique quel tunnel de communication est concerné, et quel sens de communication est aussi concerné (par exemple, en indiquant une adresse de point de terminaison 120 source et de point de terminaison 120 destination).
Préférentiellement, la sonde réseau P3 1001 mémorise le numéro de séquence Seq du dernier paquet fanion localement capturé et la volumétrie actuelle telle que vue par la sonde réseau P3 1001 au moment de l’envoi de la requête MeasReq. Cela permet par la suite, à la sonde réseau P3 1001, d’estimer la perte de volume de données dans le cas où tous les paquets fanions seraient perdus sur l’intervalle de numéros de séquence de paquets fanions sur lequel s’applique la requête MeasReq.
Dans une étape 1011, la sonde réseau P4 1002 reçoit la requête MeasReq émise par la sonde P3 1001.
Dans une étape optionnelle 1012, la sonde réseau P4 1002 recherche l’intervalle de numéros de séquence sur lequel porte la requête MeasReq. L’étape 1012 est optionnelle en ce que le protocole inter-sondes peut impliquer que la requête MeasReq concerne l’ensemble de l’historique d’échantillonnages disponible auprès de la sonde réseau P4 1002. Sinon, la sonde réseau P4 1002 recherche l’intervalle de numéros de séquence d’après les indications contenues dans ladite requête MeasReq. Si à cause de pertes de paquets, l’historique d’échantillonnages disponible en mémoire de la sonde réseau P4 1002 ne correspond pas à l’historique d’échantillonnages demandé par la sonde réseau P3 1001, alors la sonde réseau P4 1002 retrouve en mémoire l’historique d’échantillonnages le plus proche de l’historique d’échantillonnages demandé par la sonde réseau P3 1001.
Dans une étape 1013, la sonde réseau P4 1002 sélectionne la ou les tables de mesures appropriées d’après le ou les types de service (e.g., DSCP) concernés, et récupère (« retrieve » en anglais) les échantillons (mesures) qui correspondent à l’intervalle de numéros de séquence souhaité et qui sont contenus dans cette ou ces tables de mesures.
La sonde réseau P4 1002 prépare alors une réponse MeasResp. La réponse MeasResp est de type MeasResp2, adapté pour fournir les informations demandées par la requête MeasReq de type MeasReq2. La réponse MeasResp inclut les échantillons (mesures) récupérés à l’étape 1013.
La sonde réseau P4 1002 inclut préférentiellement dans la réponse MeasResp les informations récupérées suivantes, pour chaque type de service requis :
- l’intervalle de numéros de séquence réellement considéré ;
- la volumétrie actuelle (c’est-à-dire, au moment où la requête MeasReq est reçue) du dernier paquet fanion reçu et le numéro de séquence Seq dudit dernier paquet fanion reçu.
Dans une étape 1014, la sonde réseau P4 1002 envoie la réponse MeasResp, de type MeasResp2, ainsi préparée. La réponse MeasResp est envoyée à la sonde réseau P3 1001 en réponse à la requête MeasReq reçue à l’étape 1011.
Dans une étape 1015, la sonde réseau P3 1001 reçoit la réponse MeasResp émise par la sonde P4 1002. La sonde réseau P3 1001 connaît ainsi la liste des paquets fanions effectivement capturés par la sonde réseau P4 1002 (et donc par déduction, ceux qui ont été perdus en chemin).
Dans une étape 1016, la sonde réseau P3 1001 effectue des calculs de latence, gigue et volumétrie, pour chaque type de service requis, grâce à l’historique d’échantillonnages reçu dans la réponse MeasResp. En se basant sur les mêmes données, la sonde réseau P3 1001 peut effectuer les mêmes calculs que la sonde réseau P2 902 dans l’étape 914. Ainsi, préférentiellement, la sonde réseau P3 1001 calcule :
- la latence minimum de transit des paquets fanions de l’intervalle de numéros de séquence considéré ;
- la latence maximum de transit des paquets fanions de l’intervalle de numéros de séquence considéré ;
- la latence moyenne de transit des paquets fanions de l’intervalle de numéros de séquence considéré ;
- la gigue minimum subie par les paquets fanions de l’intervalle de numéros de séquence considéré ;
- la gigue maximum subie par les paquets fanions de l’intervalle de numéros de séquence considéré ;
- la gigue moyenne subie par les paquets fanions de l’intervalle de numéros de séquence considéré ;
- la volumétrie de transit de données (quantité de paquets, d’octets…) dans le tunnel de communication sur l’intervalle de numéros de séquence considéré.
La sonde réseau P3 1001 calcule en outre une éventuelle perte de volume de données (de paquets, d’octets…) sur l’intervalle de numéros de séquence réellement considéré (à cause des pertes éventuelles de paquets fanions). La perte de volume de données correspond à la différence entre la volumétrie calculée par la sonde réseau P3 1001 vis-à-vis de son propre historique d’échantillonnages, sur l’intervalle de numéros de séquence réellement considéré, et la volumétrie calculée par la sonde réseau P3 1001 vis-à-vis de l’historique d’échantillonnages reçu dans la réponse MeasResp.
Lorsque les numéros de séquence constituant les bornes de l’intervalle de numéros de séquence de l’historique retourné dans la réponse MeasResp sont les mêmes, une perte totale des paquets fanions entre deux mesures successives est survenue. Dans ce cas, les valeurs de latence et gigue ne sont pas calculées par la sonde réseau P3 1001. La sonde réseau P3 1001 calcule alors une valeur approximée de la perte de volume de données, comme déjà expliqué ci-dessus en relation avec la . Ainsi, en considérant deux réponses MeasResp successives, la sonde réseau P3 1001 peut estimer la perte de volume de données en déterminant la différence d’informations de « volumétrie actuelle » telles qu’indiquées dans lesdites deux réponses MeasResp successives, et en la comparant avec la différence d’informations de « volumétrie actuelle » telles que mémorisées à l’envoi des requêtes MeasReq correspondantes.
Dans une étape 1017, la sonde réseau P3 1001 mémorise des informations permettant de savoir où en est la surveillance du tunnel de communication vis-à-vis des historiques d’échantillonnages, pour le ou les types de service (e.g., DSCP) considérés. Typiquement, la sonde réseau P3 1001 mémorise le numéro de séquence Seq du dernier paquet fanion reçu et la volumétrie actuelle, tels que fournis par la sonde réseau P4 1002 dans la réponse MeasResp.
Dans une étape 1018, grâce aux calculs de latence, de gigue et d’éventuelle perte de volume de données à l’étape 1016, la sonde réseau P3 1001 évalue si une éventuelle situation de congestion est rencontrée par le tunnel de communication, que ce soit en termes de latence, de gigue, ou de pertes de paquet lors du transit dans le tunnel de communication. Grâce à cette évaluation de situation de congestion, la sonde réseau P3 1001 peut 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. En variante, la sonde réseau P3 1001 remonte à l’orchestrateur 180 des informations relatives aux calculs, de sorte à permettre à l’orchestrateur 180 d’ajuster la gestion d’admission de services.
Il convient de noter que l’algorithme de la peut être inversé, c’est-à-dire que la sonde aval obtient l’historique d’échantillonnages de la sonde amont et effectue l’ensemble des calculs.
Dans un mode de réalisation particulier applicable aux algorithmes des Figs. 9 et 10, la sonde réseau P3 1001 calcule une information supplémentaire de latence et une information supplémentaire de gigue, qui sont liées à la qualité de service QoS (« Quality of Service » en anglais) du routeur local lui-même, en comparant les informations d’horodatage contenues dans les paquets fanions émis et les informations d’horodatage de capture des paquets fanions capturés par ladite sonde réseau P3 1001. La latence dans le tunnel de communication est alors ajustée en retranchant la latence induite par le routeur au calcul de latence effectué sur la base des échantillons reçus de la sonde réseau P4 1002. De même, la gigue dans le tunnel de communication est alors ajustée en retranchant la gigue induite par le routeur au calcul de gigue effectué sur la base des échantillons reçus de la sonde réseau P4 1002. Selon un mode de réalisation complémentaire, la sonde réseau P3 1001 estime en outre une éventuelle perte de volume de données liée au routeur local lui-même. Etant donné que la sonde réseau P3 1001 ne connaît pas le volume de données effectivement issu du réseau de communication 100b en amont du point de terminaison 120 100b, la sonde réseau P3 1001 effectue une estimation d’éventuelle perte de volume des données issues du réseau de communication 100b en se basant sur les éventuelles pertes subies par ses propres paquets fanions (i.e., ceux injectés par l’injecteur 150 local et qui doivent être normalement détectés par le point de capture local de la sonde réseau amont).
Dans un mode de réalisation particulier applicable aux algorithmes des Figs. 9 et 10, lorsque les tunnels de communication sont implémentés grâce au protocole GRE ou au protocole mGRE, les paquets fanions peuvent être injectés et capturés par type de service (e.g., DSCP) et en outre par flux (e.g., flux IP LAN). Les informations de flux par paquet fanion sont alors prises en compte par les sondes réseau et les calculs de volumétrie et d’éventuelle perte de volume de données sont réalisés par flux et par type de service, au lieu d’être réalisés par type de service uniquement.
Un mode de réalisation particulier hybride par rapport aux algorithmes des Figs. 9 et 10 peut aussi être implémenté. Le calcul de volumétrie est alors réalisé par la sonde réseau aval, et les calculs de latence et de gigue sont réalisés par la sonde réseau amont. Pour ce faire, la réponse MeasResp est de type MeasResp3. La réponse MeasResp inclut alors les informations de numéro de séquence Seq et d’horodatages, mais pas les informations de volume de données. En relation avec la , les données contenues dans les colonnes 805 et 806 sont omises. La réponse MeasResp inclut aussi le résultat de calcul de volumétrie effectué par la sonde réseau aval. La réponse MeasResp peut toutefois aussi inclure la volumétrie actuelle (c’est-à-dire, au moment où la requête MeasReq est reçue) du dernier paquet fanion reçu et le numéro de séquence Seq dudit dernier paquet fanion reçu. Cela permet de trouver un compromis de consommation de bande passante par le protocole inter-sondes, tout en conservant la justesse des résultats de calculs de latence et de gigue.
Claims (12)
- Procédé implémenté dans un système de communication comportant une pluralité de routeurs (110), une première sonde réseau étant associée à un premier routeur (110) de ladite pluralité de routeurs (110) et à un premier point de terminaison (120) du premier routeur (110), une deuxième sonde réseau étant associée à un deuxième routeur (110) de ladite pluralité de routeurs (110) et à un deuxième point de terminaison (120) du premier routeur (110), le procédé comportant les étapes suivantes dans le cadre d’un surveillance d’un trafic dans un tunnel de communication entre le premier point de terminaison (120) et le deuxième point de terminaison (120) :
- injecter de façon périodique, par la première sonde, des paquets fanions en parallèle du trafic du tunnel de communication, chaque paquet fanion incluant une information d’horodatage exprimant une référence temporelle d’injection dudit paquet fanion ;
- collecter des informations relatives à une variation de cadencement de trafic dans le tunnel de communication, la variation de cadencement étant mesurée grâce à une différence entre les informations d’horodatage contenues dans les paquets fanions et des informations d’horodatage d’instant de capture desdits paquets fanions par la deuxième sonde ;
- évaluer d’éventuelles situations de congestion subies par le tunnel de communication en fonction desdites informations collectées. - Procédé selon la revendication 1, comprenant l’étape suivante :
- calculer une éventuelle perte de volume de données dans le tunnel de communication, par comparaison entre un comptage de volume de données en sortie du tunnel de communication entre des paquets fanions successifs, détectées par la deuxième sonde, et un comptage de volume de données en entrée du tunnel de communication entre des paquets fanions successifs, détectées par la première sonde. - Procédé selon la revendication 1 ou 2, dans lequel les paquets fanions sont des paquets de type UDP émis sur un port dédié auxdits paquets fanions.
- Procédé selon l’une quelconque des revendications 1 à 3, dans lequel les paquets fanions sont injectés pour chaque type de service parmi une pluralité de types de service transportés par le tunnel de communication.
- Procédé selon l’une quelconque des revendications 1 à 4, dans lequel les paquets fanions sont injectés dans un plan utilisateur en amont du premier point de terminaison par rapport au tunnel de communication.
- Procédé selon l’une quelconque des revendications 1 à 5, dans lequel, pour collecter les informations relatives à une variation de cadencement de flux de données dans le tunnel de communication, au moins la deuxième sonde réseau comporte au moins une table de mesures pour stocker un historique d’échantillonnages de paquets fanions capturés en sortie du tunnel de communication, chaque entrée de la table de mesures correspondant à un échantillon comportant :
- un champ d’information d’horodatage telle que contenue dans le paquet fanion correspondant à l’échantillon en question ;
- un champ d’information d’horodatage marquant l’instant auquel le paquet fanion correspondant à l’échantillon en question a été capturé ;
- un champ de numéro de séquence tel que contenu dans le paquet fanion correspondant à l’échantillon en question ; et
- un champ de comptage de données transitant dans le tunnel de communication entre le paquet fanion correspondant à l’échantillon en question et le paquet fanion correspondant à l’échantillon suivant dans la table de mesures. - Procédé selon la revendication 6, dans lequel la première sonde transmet à la deuxième sonde une requête requérant de transmettre en réponse des informations dérivées par calculs d’un historique d’échantillonnages des paquets fanions reçus par la deuxième sonde, la requête impliquant un intervalle de numéros de séquence à considérer, les calculs étant destinés à évaluer les éventuelles situations de congestion et incluant :
- une latence minimum de transit des paquets fanions dudit intervalle de numéros de séquence ;
- une latence maximum de transit des paquets fanions dudit intervalle de numéros de séquence ;
- une latence moyenne de transit des paquets fanions dudit intervalle de numéros de séquence ;
- une gigue minimum subie par les paquets fanions dudit intervalle de numéros de séquence ;
- une gigue maximum subie par les paquets fanions dudit intervalle de numéros de séquence ;
- une gigue moyenne subie dudit intervalle de numéros de séquence ;
- une volumétrie de transit de données dans le tunnel de communication sur ledit intervalle de numéros de séquence. - Procédé selon la revendication 6, dans lequel la première sonde transmet à la deuxième sonde une requête requérant de transmettre en réponse tout ou partie de l’historique d’échantillonnages des paquets fanions reçus par la deuxième sonde, la première sonde réalisant alors des calculs destinés à évaluer les éventuelles situations de congestion et incluant :
- une latence minimum de transit des paquets fanions dudit intervalle de numéros de séquence ;
- une latence maximum de transit des paquets fanions dudit intervalle de numéros de séquence ;
- une latence moyenne de transit des paquets fanions dudit intervalle de numéros de séquence ;
- une gigue minimum subie par les paquets fanions dudit intervalle de numéros de séquence ;
- une gigue maximum subie par les paquets fanions dudit intervalle de numéros de séquence ;
- une gigue moyenne subie dudit intervalle de numéros de séquence ;
- une volumétrie de transit de données dans le tunnel de communication sur ledit intervalle de numéros de séquence. - Procédé selon l’une quelconque des revendications 1 à 8, dans lequel la première sonde réseau comporte au moins une autre table de mesures pour stocker un historique d’échantillonnages de paquets fanions capturés en entrée du tunnel de communication, chaque entrée de cette autre table de mesures correspondant à un échantillon comportant :
- un champ d’information d’horodatage telle que contenue dans le paquet fanion correspondant à l’échantillon en question ;
- un champ d’information d’horodatage marquant l’instant auquel le paquet fanion correspondant à l’échantillon en question a été capturé ;
- un champ de numéro de séquence tel que contenu dans le paquet fanion correspondant à l’échantillon en question ; et
- un champ de comptage de données transitant dans le tunnel de communication entre le paquet fanion correspondant à l’échantillon en question et le paquet fanion correspondant à l’échantillon suivant dans la table de mesures. - Procédé selon la revendication 9, dans lequel la première sonde réseau calcule une information supplémentaire de latence et une information supplémentaire de gigue, qui sont liées à la qualité de service du premier routeur, en comparant les informations d’horodatage contenues dans les paquets fanions injectés et les informations d’horodatage de capture des paquets fanions capturés par ladite première sonde réseau.
- Procédé selon la revendication 10, dans lequel la première sonde estime en outre une éventuelle perte de volume de données qui est liée à la qualité de service du premier routeur, à partir de détection de pertes de paquets fanions injectés par la première sonde.
- Système de communication comportant des sondes réseau et une pluralité de routeurs (110), une première sonde réseau étant associée à un premier routeur (110) de ladite pluralité de routeurs (110) et à un premier point de terminaison (120) du premier routeur (110), une deuxième sonde réseau étant associée à un deuxième routeur (110) de ladite pluralité de routeurs (110) et à un deuxième point de terminaison (120) du premier routeur (110), le système de communication comportant de la circuiterie électronique configurée pour effectuer les étapes suivantes dans le cadre d’un surveillance d’un trafic dans un tunnel de communication entre le premier point de terminaison (120) et le deuxième point de terminaison (120) :
- injecter de façon périodique, par la première sonde, des paquets fanions en parallèle du trafic du tunnel de communication, chaque paquet fanion incluant une information d’horodatage exprimant une référence temporelle d’injection dudit paquet fanion ;
- collecter des informations relatives à une variation de cadencement de trafic dans le tunnel de communication, la variation de cadencement étant mesurée grâce à une différence entre les informations d’horodatage contenues dans les paquets fanions et des informations d’horodatage d’instant de capture desdits paquets fanions par la deuxième sonde ;
- évaluer d’éventuelles situations de congestion subies par le tunnel de communication en fonction desdites informations collectées.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP22216832.0A EP4207638A1 (fr) | 2021-12-31 | 2022-12-27 | Protocole de surveillance de trafic de communication |
| US18/090,201 US20230216772A1 (en) | 2021-12-31 | 2022-12-28 | Protocol for monitoring communication traffic |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2114713 | 2021-12-31 | ||
| FR2114713A FR3131670A1 (fr) | 2021-12-31 | 2021-12-31 | Protocole d’evaluation de congestion |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3131673A1 true FR3131673A1 (fr) | 2023-07-07 |
Family
ID=83438390
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2114713A Pending FR3131670A1 (fr) | 2021-12-31 | 2021-12-31 | Protocole d’evaluation de congestion |
| FR2205287A Pending FR3131673A1 (fr) | 2021-12-31 | 2022-06-01 | Protocole de surveillance de trafic de communication |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2114713A Pending FR3131670A1 (fr) | 2021-12-31 | 2021-12-31 | Protocole d’evaluation de congestion |
Country Status (1)
| Country | Link |
|---|---|
| FR (2) | FR3131670A1 (fr) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2296318A1 (fr) * | 2009-09-11 | 2011-03-16 | Symmetricom, Inc. | Procédé et appareil pour la surveillance de réseaux de paquets |
-
2021
- 2021-12-31 FR FR2114713A patent/FR3131670A1/fr active Pending
-
2022
- 2022-06-01 FR FR2205287A patent/FR3131673A1/fr active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2296318A1 (fr) * | 2009-09-11 | 2011-03-16 | Symmetricom, Inc. | Procédé et appareil pour la surveillance de réseaux de paquets |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3131670A1 (fr) | 2023-07-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1743454A1 (fr) | Mesure de performance dans un reseau de transmission de paquets | |
| EP1743452A1 (fr) | Mesure de performance dans un reseau de transmission de paquets | |
| FR2790348A1 (fr) | Systeme et procede de mesure des durees de transfert et des taux de pertes dans des reseaux de telecommunication haut-debit | |
| FR2922391A1 (fr) | Procede et dispositif de transmission de donnees | |
| EP1453242A2 (fr) | Sonde de mesure de paramètres de qualité de service pour un réseau de télécommunication | |
| FR2998748A1 (fr) | Dispositif et procede de retransmission de donnees dans un commutateur reseau | |
| EP3216189B1 (fr) | Délégation d'intermédiation sur un échange de données chiffrées | |
| FR3131673A1 (fr) | Protocole de surveillance de trafic de communication | |
| EP4207638A1 (fr) | Protocole de surveillance de trafic de communication | |
| EP2396086B1 (fr) | Procédé de communication | |
| Niccolini et al. | Design and implementation of a one way delay passive measurement system | |
| EP2757486A1 (fr) | Interface de réseau sur puce dotée d'un système adaptatif de déclenchement d'envoi de données | |
| WO2020221779A1 (fr) | Procedes et dispositifs de mesure de reputation dans un reseau de communication | |
| FR3131156A1 (fr) | Mise en communication automatique de sondes reseau | |
| EP1424832A1 (fr) | Dispositif de mesures de bout en bout d'informations de reseau | |
| EP3262871B1 (fr) | Sélection de réseau d'accès pour un terminal multi-accès, basée sur un signal phéromonal | |
| WO2005112345A1 (fr) | Mesure de performance dans un reseau de transmission de paquets | |
| Low et al. | Enhanced bandwidth estimation design based on probe-rate model for multimedia network | |
| WO2023078995A2 (fr) | Procédé de vérification de la fiabilité d'une première valeur d'un paramètre de contrôle de flux relatif à une connexion destinée à être établie entre un premier équipement de communication et un deuxième équipement de communication reliés par un chemin comprenant au moins un nœud intermédiaire au moyen d'une valeur d'un paramètre de performance intermédiaire déterminée par le nœud intermédiaire | |
| FR3020537A1 (fr) | Moyens d’evaluation de performances, dans un reseau de donnees | |
| EP2273727A1 (fr) | Procede d'obtention d'une information representative d'une disponibilité d'un réseau de communication, dispositif et programme d'ordinateur correspondant | |
| WO2014135794A1 (fr) | Procede de controle de congestion pour reseaux de telecommunications | |
| WO2020193902A1 (fr) | Procédé de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications, produit programme d'ordinateur et dispositif correspondants | |
| FR3129049A1 (fr) | Procédé de gestion d’une retransmission de données échangées sur un chemin établi entre un premier équipement de communication et un deuxième équipement de communication au moyen d’une valeur d’un paramètre de performance intermédiaire déterminée par un nœud intermédiaire appartenant audit chemin | |
| FR3127351A1 (fr) | Procédé de prédiction de la qualité de service d'un réseau de communication, produit programme d'ordinateur et dispositif électronique de prédiction associés |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20230707 |