[0001] La présente invention se rapporte à un procédé de gestion du routage de données dans un système de communication de données, ainsi qu’à dispositifs et logiciels pour la mise en œuvre de ce procédé. Elle s’applique notamment à la mesure du temps de propagation d’une information de routage dans un système de communication de données.

[0002] Le protocole de routage « Border Gateway Protocol » (BGP) est un protocole de routage entre systèmes autonomes conçu pour être mis en œuvre dans des réseaux de type TCP/IP. Le protocole BGP est spécifié dans le document « Request For Comments » initialement n° 1771 puis mis à jour sous le n°4271, intitulé « A Border Gateway Protocol 4 (BGP-4) », édité par l’organisation « Internet Engineering Task Force » (IETF).

[0003] Une des fonctions du protocole BGP est de permettre l’échange entre deux systèmes autonomes d’information d’accessibilité de réseau. L’information échangée comprend de l’information sur la liste des systèmes autonomes que l’information d’accessibilité traverse, ce qui permet de construire un graphe de connectivité entre les deux systèmes autonomes, et de supprimer de ce graphe les éventuelles boucles de routage et de mettre en œuvre des politiques de décision au niveau des systèmes autonomes.

[0004] La mise en œuvre de politiques de décision en utilisant le protocole BGP s’effectue par un mécanisme d’annonces envoyées par un nœud dit « annonceur » (en anglais, « BGP speaker ») à ses nœuds correspondants dans des systèmes autonomes voisins des routes que le nœud annonceur utilise. Ce mécanisme repose sur le principe du routage par sauts (en anglais, « hop-by-hop ») actuellement utilisé dans le réseau Internet.

[0005] Le protocole BGP est un protocole de routage très largement utilisé aujourd’hui dans les réseaux de l’Internet. Sa mise en œuvre au sein des réseaux opérateurs permet notamment d’échanger des informations de routage et d’accessibilité entre les réseaux des opérateurs, qui constituent des systèmes autonomes du point de vue du protocole BGP. Par exemple, le protocole BGP peut être utilisé pour annoncer des préfixes Internet (typiquement des routes IPv4 codées sur 4 octets, ou des routes IPv6 codées sur 16 octets) ou des préfixes de réseau privé virtuel (en anglais « Virtual Private Network », ou VPN), comme par exemple des routes VPN-IPv4 codées sur 12 octets, ou des routes VPN-IPv6 codées sur 24 octets.

[0006] Cependant, l’utilisation de protocoles de routage tels que le protocole BGP dans des réseaux à forte densité de nœuds nécessite d’avoir des outils de mesure de performance afin d’optimiser les choix de mise en œuvre de ces protocoles, notamment sur les réseaux opérés par des opérateurs télécoms. [0007] Un objet de la présente invention est de remédier au moins partiellement aux inconvénients précités.

[0008] Selon un premier aspect, il est proposé un procédé de mesure du temps de propagation d’une information relative au routage de données dans un système de communication de données comprenant un réseau de communication de données comprenant une pluralité de nœuds routeurs opérant selon un protocole de routage pour le routage de paquets de données entre des nœuds du réseau de communication de données, le procédé comprenant, à un nœud routeur dit nœud générateur : générer des données d’horodatage d’émission de l’information relative au routage de données ; insérer les données d’horodatage d’émission dans un champ d’un message du protocole de routage porteur de l’information relative au routage de données, le champ étant destiné à recevoir des données relatives au routage de données ; et envoyer le message à un autre nœud routeur dit nœud récepteur.

[0009] Selon un autre aspect, il est proposé un procédé de mesure du temps de propagation d’une information relative au routage de données dans un système de communication de données comprenant un réseau de communication de données comprenant une pluralité de nœuds routeurs opérant selon un protocole de routage pour le routage de paquets de données entre des nœuds du réseau de communication de données, le procédé comprenant, à un nœud routeur, dit nœud récepteur : recevoir un message du protocole de routage porteur de l’information relative au routage de données en provenance d’un autre nœud routeur ; extraire d’un champ du message reçu des données d’horodatage, le champ étant destiné à recevoir des données relatives au routage de données; générer des données d’horodatage courant ; et déterminer une estimation du temps de propagation de l’information relative au routage de données entre le noeud générateur et le noeud récepteur, sur la base des données d’horodatage du message et des données d’horodatage courant.

[0010] Les procédés proposés traitent entre autres d’une problématique qui a été identifiée par les inventeurs, selon laquelle la vitesse pour annoncer la création, la modification ou le retrait d’un préfixe IP ou VPN est un critère qui devient prépondérant dans le choix des équipements opérationnels qui activent le protocole de routage BGP.

[0011] Pour mesurer le temps de propagation d’un préfixe VPN dans un routeur ou dans un réseau (comprenant un ensemble de routeurs), il serait envisageable d’utiliser un générateur de préfixes IP ou VPN et un analyseur de trafic. En synchronisant ces deux équipements/outils, un outil pourrait être développé pour identifier/associer les préfixes qui ont été générés avec les informations qui ont été collectées pour pouvoir en déduire le temps de propagation des préfixes.

[0012] Cette possibilité serait complexe à mettre en œuvre. De plus, outre la complexité de mise en œuvre, il resterait des approximations quant au moment exact de l’émission d’un préfixe, et donc des incertitudes sur les résultats obtenus. [0013] Les procédés proposés permettent avantageusement d’ estimer le temps de propagation d’une information relative au routage de données, comme par exemple un préfixe de routage de données, en minimisant les approximations quant au moment exact de l’émission de l’information, par l’insertion de données d’horodatage d’émission d’une information relative au routage de données dans un champ d’un message de protocole de routage utilisé, comme par exemple le protocole BGP, puis par l’envoi du message.

[0014] Le nœud routeur de destination du message peut alors, sur réception d’un message de protocole de routage correspondant au message envoyé, extraire d’un champ du message reçu les données d’horodatage d’émission, et estimer le temps de propagation de l’information relative au routage de données sur la base des données d’horodatage reçues et de données d’horodatage courant.

[0015] Dès lors, que ce soit au niveau du routeur générant les données d’horodatage d’émission d’information relative au routage de données ou au niveau du routeur recevant ces données d’horodatage et les traitant pour estimer un temps de propagation de l’information relative au routage de données, un ou plusieurs messages de protocole de routage sont utilisés sans que les procédés proposés nécessitent des changements ou des développements supplémentaires du protocole de routage utilisé.

[0016] Ainsi, avantageusement, les procédés proposés ne requièrent pas une mise en œuvre complexe, notamment en ce qu’ils ne nécessitent pas de modifier le protocole de routage utilisé. Ils tirent parti de ce protocole de routage en utilisant un champ d’un message du protocole de routage pour y insérer des données d’horodatage. Les éventuels traitements du message par un ou plusieurs nœuds routeurs intermédiaires ne sont donc pas impactés par les procédés proposés, qui sont donc avantageusement transparents pour ce(s) nœud(s) intermédiaire(s).

[0017] Les procédés proposés permettent ainsi avantageusement de mesurer précisément, sans complexité de mise en œuvre, le temps de propagation d’une information relative au routage selon un protocole de routage dans un routeur ou dans un réseau.

[0018] Les caractéristiques exposées dans les paragraphes suivants peuvent, optionnellement, être mises en œuvre. Elles peuvent être mises en œuvre indépendamment les unes des autres ou en combinaison les unes avec les autres :

[0019] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : extraire du message reçu une information relative à un routeur à l'origine de l’information relative au routage de données, dit nœud générateur.

[0020] Dans un ou plusieurs modes de réalisation, les données d’horodatage sont insérées dans le message en tant que préfixe d’adresse Internet Protocol, IP, ou préfixe de réseau privé virtuel, VPN. [0021] Dans un ou plusieurs modes de réalisation, le protocole de routage est le protocole « Border Gateway Protocol », BGP. BGP définit différents types de paquets (OPEN, NOTIFICATION, UPDATE, KEEPALIVE, ...) ; seul le paquet BGP-UPDATE est responsable de l’annonce et du retrait d’informations de routage. Dans un ou plusieurs modes de réalisation, les données d’horodatage d’émission sont insérées dans la partie « attribut », la partie « withdrawn » ou la partie « NLRI » du message BGP-UPDATE. Dans un ou plusieurs modes de réalisation, les données d’horodatage d’émission sont insérées dans la partie « attribut » (en utilisant un attribut prédéfini), la partie « withdrawn » (en tant que préfixe Internet ou VPN), ou la partie « NLRI » (en tant que préfixe Internet ou VPN) du message BGP-UPDATE.

[0022] Dans un ou plusieurs modes de réalisation, le message du protocole de routage est du type BGP-WITHDRAW.

[0023] Dans un ou plusieurs modes de réalisation, le protocole de routage est le protocole de routage interne « Intermediate System to Intermediate System », IS-IS (RFC 1142), ou le protocole de routage interne IP « Open Shortest Path First », OSPF (RFC 2328 puis RFC 5340).

[0024] Selon un autre aspect, il est proposé un dispositif comprenant un processeur et une unité radio-fréquence couplée de manière opérationnelle au processeur, le dispositif étant configuré pour la mise en œuvre d’un procédé selon l’un des modes de réalisation proposés dans la présente description.

[0025] Un autre aspect concerne un programme d’ordinateur, chargeable dans une mémoire associée à un processeur, et comprenant des portions de code pour la mise en œuvre d’un procédé tel que proposé dans la présente description lors de l’exécution dudit programme par le processeur.

[0026] Un autre aspect concerne un ensemble de données représentant, par exemple par voie de compression ou d’encodage, un programme d’ordinateur tel que proposé dans la présente description.

[0027] Un autre aspect concerne un support de stockage non-transitoire d’un programme exécutable par ordinateur, comprenant un ensemble de données représentant un ou plusieurs programmes, lesdits un ou plusieurs programmes comprenant des instructions pour, lors de l’exécution desdits un ou plusieurs programmes par un ordinateur comprenant un processeur couplé de manière opérationnelle à une mémoire et à une interface entrées/sorties de communication de données, conduire l’ordinateur à gérer un nœud de communication de données selon un procédé de gestion d’un nœud de communication de données selon l’un des modes de réalisation proposés dans la présente description.

Brève description des dessins

[0028] D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels :

Fig. 1 [0029] [Fig. 1] est un schéma illustrant un exemple de système pour la mise en œuvre d’un ou plusieurs modes de réalisation du procédé proposé ;

Fig. 2

[0030] [Fig. 2] est un schéma illustrant un exemple d’architecture d’un nœud routeur pour la mise en œuvre d’un ou plusieurs modes de réalisation du procédé proposé ;

Fig. 3a

[0031] [Fig. 3a] est un schéma illustrant un procédé proposé selon un ou plusieurs modes de réalisation ;

Fig. 3b

[0032] [Fig. 3b] est un schéma illustrant un procédé proposé selon un ou plusieurs modes de réalisation ;

Fig. 4

[0033] [Fig. 4] est un schéma illustrant un exemple de mesures du temps de propagation dans un routeur réflecteur de route dans un ou plusieurs modes de réalisation du procédé proposé;

Description des modes de réalisation

[0034] Dans la description détaillée ci-après de modes de réalisation de l'invention, de nombreux détails spécifiques sont présentés pour apporter une compréhension plus complète. Néanmoins, l'homme du métier peut se rendre compte que des modes de réalisation peuvent être mis en pratique sans ces détails spécifiques. Dans d'autres cas, des caractéristiques bien connues ne sont pas décrites en détail pour éviter de compliquer inutilement la présente description.

[0035] La présente description fait référence à des fonctions, moteurs, unités, modules, plateformes, et illustrations de diagrammes des méthodes et dispositifs selon un ou plusieurs modes de réalisation. Chacun des fonctions, moteurs, modules, plateformes, unités et diagrammes décrits peut être mis en œuvre sous forme matérielle, logicielle (y compris sous forme de logiciel embarqué («firmware»), ou de «middleware»), microcode, ou toute combinaison de ces derniers. Dans le cas d’une mise en œuvre sous forme logicielle, les fonctions, moteurs, unités, modules et/ou illustrations de diagrammes peuvent être mis en œuvre par des instructions de programme d’ordinateur ou du code logiciel, qui peut être stocké ou transmis sur un support lisible par ordinateur, incluant un support non transitoire, ou un support chargé en mémoire d’un ordinateur générique, spécifique, ou de tout autre appareil ou dispositif programmable de traitement de données pour produire une machine, de telle sorte que les instructions de programme d’ordinateur ou le code logiciel exécuté(es) sur l’ordinateur ou l’appareil ou dispositif programmable de traitement de données, constituent des moyens de mise en œuvre de ces fonctions. [0036] Les modes de réalisation d’un support lisible par ordinateur incluent, de manière non exhaustive, des supports de stockage informatique et des supports de communication, y compris tout support facilitant le transfert d’un programme d’ordinateur d’un endroit vers un autre. Par «support(s) de stockage informatique», on entend tout support physique pouvant être accédé par ordinateur. Les exemples de support de stockage informatique incluent, de manière non limitative, les disques ou composants de mémoire flash ou tous autres dispositifs à mémoire flash (par exemple des clés USB, des clés de mémoire, des sticks mémoire, des disques-clés), des CD-ROM ou autres dispositifs de stockage optique de données, des DVD, des dispositifs de stockage de données à disque magnétique ou autres dispositifs de stockage magnétique de données, des composants de mémoire de données, des mémoires RAM, ROM, EEPROM, des cartes mémoires («smart cards»), des mémoires de type SSD («Solid State Drive»), et toute autre forme de support utilisable pour transporter ou stocker ou mémoriser des données ou structures de données qui peuvent être lues par un processeur d’ordinateur.

[0037] En outre, diverses formes de support lisible par ordinateur peuvent transmettre ou porter des instructions vers un ordinateur, telles qu’un routeur, une passerelle, un serveur, ou tout équipement de transmission de données, qu’il s’agisse de transmission filaire (par câble coaxial, fibre optique, fils téléphoniques, câble DSL, ou câble Ethernet), sans-fil (par infrarouge, radio, cellulaire, microondes), ou des équipements de transmission virtualisés (routeur virtuel, passerelle virtuelle, extrémité de tunnel virtuel, pare-feu virtuel). Les instructions peuvent, selon les modes de réalisation, comprendre du code de tout langage de programmation informatique ou élément de programme informatique, tel que, sans limitation, les langages assembleur, C, C++, Visual Basic, HyperText Markup Language (HTML), Extensible Markup Language (XML), HyperText Transfer Protocol (HTTP), Hypertext Preprocessor (PHP), SQL, MySQL, Java, JavaScript, JavaScript Object Notation (JSON), Python, et bash scripting.

[0038] De plus, les termes «notamment», «par exemple», «exemple», «typiquement» sont utilisés dans la présente description pour désigner des exemples ou illustrations de modes de réalisation non limitatifs, qui ne correspondent pas nécessairement à des modes de réalisation préférés ou avantageux par rapport à d’autres aspects ou modes de réalisation possibles.

[0039] Par «serveur» ou «plateforme», on entend dans la présente description tout point de service (virtualisé ou non) ou dispositif opérant des traitements de données, une ou plusieurs bases de données, et/ou des fonctions de communication de données. Par exemple, et de manière non limitative, le terme «serveur» ou le terme «plateforme» peut faire référence à un processeur physique couplé de manière opérationnelle avec des fonctions de communication, de base de données et de stockage de données associées, ou faire référence à un réseau, un groupe, un ensemble ou un complexe de processeurs et des équipements de stockage de données et de mise en réseau associés, ainsi qu’un système d’exploitation et un ou plusieurs système(s) de base de données et des logiciels applicatifs en support des services et fonctions fournies par le serveur. Un dispositif informatique peut être configuré pour envoyer et recevoir des signaux, par réseau(x) de transmission sans-fil et/ou filaire, ou peut être configuré pour des traitements et/ou du stockage de données ou de signaux, et peut donc fonctionner en tant que serveur. Ainsi, des équipements configurés pour opérer en tant que serveur peuvent inclure, à titre d’exemples non limitatifs, des serveurs dédiés montés sur rack, des ordinateurs de bureau, des ordinateurs portables, des passerelles de service (parfois appelées «box» ou «passerelle résidentielle»), des décodeurs multimédia (parfois appelés «set-top boxes»), des équipements intégrés combinant diverses fonctionnalités, telles que deux ou plus des fonctionnalités mentionnées ci-dessus. Les serveurs peuvent fortement varier dans leur configuration ou leurs capacités, mais un serveur inclura généralement une ou plusieurs unité(s) centrale(s) de traitement et une mémoire. Un serveur peut aussi inclure un ou plusieurs équipement(s) de mémoire de masse, une ou plusieurs alimentation(s) électrique(s), une ou plusieurs interface(s) réseau sans-fil et/ou filaire(s), une ou plusieurs interface(s) d’entrée/sortie, un ou plusieurs système(s) d’exploitation, tel(s) que Windows Server, Mac OS X, Unix, Linux, FreeBSD, or un équivalent.

[0040] Les termes «réseau» et «réseau de communication» tels qu’utilisés dans la présente description font référence à une ou plusieurs liaisons de données qui peuvent coupler ou connecter des équipements, éventuellement virtualisés, de manière à permettre le transport de données électroniques entre des systèmes informatiques et/ou des modules et/ou d’autres dispositifs ou équipements électroniques, tel qu’entre un serveur et un dispositif client ou d’autres types de dispositifs, y compris entre dispositifs sans fil couplés ou connectés par un réseau sans fil, par exemple. Un réseau peut aussi inclure une mémoire de masse pour stocker des données, tel qu’un NAS (en anglais «network attached storage», un SAN (en anglais «storage area network»), ou toute autre forme de support lisible par un ordinateur ou par une machine, par exemple. Un réseau peut comprendre, en tout ou partie, le réseau Internet, un ou plusieurs réseaux locaux (en anglais «local area networks», ou LANs), un ou plusieurs réseaux de type WAN (en anglais «wide area networks»), des connexions de type filaire, des connexions de type sans fil, de type cellulaire, ou toute combinaison de ces différents réseaux. De manière similaire, des sous-réseaux peuvent utiliser différentes architectures ou être conformes ou compatibles avec différents protocoles, et inter-opérer avec des réseaux de plus grande taille. Différents types d’équipements peuvent être utilisés pour rendre interopérables différentes architectures ou différents protocoles. Par exemple, un routeur peut être utilisé pour fournir une liaison de communication ou une liaison de données entre deux LANs qui seraient autrement séparés et indépendants.

[0041] Les termes «couplé de manière opérationnelle», «couplé», «monté», «connecté» et leurs variantes et formes diverses utilisés dans la présente description font référence à des couplages, connexions, montages, qui peuvent être directs ou indirects, et comprennent notamment des connexions entre équipements électroniques ou entre des portions de tels équipements qui permettent des opérations et fonctionnements tels que décrits dans la présente description. De plus, les termes «connectés» et «couplés» ne sont pas limités à des connections ou des couplages physiques ou mécaniques. Par exemple, un couplage de manière opérationnelle peut inclure une ou plusieurs connexion(s) filaire(s) et/ou une ou plusieurs connexion(s) sans-fil entre deux équipements ou plus qui permettent des liaisons de communication simplex et/ou duplex entre les équipements ou des portions des équipements. Selon un autre exemple, un couplage opérationnel ou une connexion peut inclure un couplage par liaison filaire et/ou sans-fil pour permettre des communications de données entre un serveur du système proposé et un autre équipement du système.

[0042] Les termes «application» ou «programme applicatif» (AP) et leurs variantes («app», «webapp», etc.) tels qu’utilisés dans la présente description correspondent à tout outil qui fonctionne et est opéré au moyen d’un ordinateur, pour fournir ou exécuter une ou plusieurs fonction(s) ou tâche(s) pour un utilisateur ou un autre programme applicatif. Pour interagir avec un programme applicatif, et le contrôler, une interface utilisateur peut être fournie sur l’équipement sur lequel le programme applicatif est mis en œuvre. Par exemple, une interface graphique (en anglais, «graphical user interface» ou GUI) peut être générée et affichée sur un écran de l’équipement utilisateur, ou une interface utilisateur audio peut être restituée à l’utilisateur en utilisant un haut-parleur, un casque ou une sortie audio.

[0043] Par « protocole BGP », on entend un protocole de routage conforme à la spécification RFC 1771 puis RFC 4271 et/ou à toute autre spécification antérieure et/ou correspondante, telle que publiée par l’IETF ou par tout autre organisme ou groupe de normalisation, et/ou à leurs évolutions.

[0044] Bien que décrit dans le cadre de modes de réalisation utilisant le protocole BGP, l’homme du métier comprendra que les procédés, systèmes, logiciels et équipements proposés ne sont pas limités à un protocole de routage particulier, et que ceux-ci pourraient être mis en œuvre avec d’autres protocoles de routage, tels que, par exemple, le protocole IS-IS (RFC 1142) ou le protocole OSPF (RFC 2328 puis RFC 5340).

[0045] La figure 1 est un diagramme illustrant un ou plusieurs modes de réalisation dans lesquels un système (1) de communication de données comprenant une pluralité de N routeurs RTR1, RTR2, RTR3 (10a, 10b, 10c) interconnectés (N=3 dans l’exemple illustré), formant un réseau (2), configurés pour la mise en œuvre d’un protocole de routage, comme par exemple le protocole BGP. Les trois routeurs RTR1 (10a), RTR2 (10b) et RTR3 (10c) illustrés sur la figure peuvent donc être des routeurs activant le protocole BGP et donc aptes à échanger des messages du protocole BGP et à mettre en œuvre les fonctionnalités définies pour le protocole BGP. Les routeurs RTR1 (10a), RTR2 (10b) et RTR3 (10c) peuvent être connectés à des équipements (l ia, 11b, 11c, l ld, l ie, l lf, 11g) qui n’activent pas le protocole BGP, comme par exemple des set-top boxes, des boxes, des switches, des ordinateurs, des équipements utilisateurs (tablettes, etc.). [0046] En particulier, chacun des routeurs du réseau (1) peut être configuré pour fonctionner en mode « annonceur BGP » (en anglais, « BGP speaker ») tel que défini par la RFC 1771 puis la RFC 4271. Dans ce mode, lorsqu’un routeur (par exemple le routeur RTR1 ( 10a), sur la figure 1 ) reçoit une route externe pour l’acheminement de données et est sélectionné comme meilleur chemin pour ces données, il doit annoncer cette information aux autres routeurs du réseau (par exemple les routeurs RTR2 et RTR3 du réseau (1) sur la figure 1).

[0047] Pour ce faire, dans les cas où le réseau (1) est configuré selon une architecture de réseau maillé, le routeur annonceur RTR1 doit annoncer son information à chacun des autres routeurs, RTR2 et RTR3 dans l’exemple de la figure 1, ce qui amène à utiliser des ressources de communication entre chaque paire de routeurs RTR1-RTR2 et RTR1-RTR3.

[0048] Afin d’éviter un volume important de trafic de signalisation BGP dans le cas où le réseau (1) comprend un grand nombre de routeurs, le réseau peut utiliser une ou plusieurs des fonctions de réflexion de route (en anglais, « route reflection ») décrites dans le document RFC 4456 édité par l’IETF, intitulé « BGP Route Reflection - An Alternative to Full Mesh IBGP ».

[0049] La fonction de réflecteur de route permet typiquement d’éviter l’interconnexion d’un grand nombre de routeurs selon une architecture de réseau maillé (en anglais, « mesh network ») dans laquelle les routeurs sont par exemple interconnectés deux à deux. Le nœud RR permet ainsi d’éviter les problèmes d’échelle qui se présentent lorsqu’un grand nombre de routeurs doivent tous recevoir une information de routage externe. La réflexion de route permet ainsi d’éviter la mise en œuvre d’une architecture de type réseau maillé, par la mise en œuvre au sein d’un des routeurs du réseau (1) d’une fonction de réflecteur de route (en anglais, « Route reflector », ou « RR ») telle que définie dans la RFC 4456.

[0050] L’architecture du réseau peut alors prévoir que l’un des nœuds routeur du réseau fonctionnera en mode nœud RR, auquel cas le nœud RR sera configuré pour échanger des données avec chacun des autres nœuds routeur du réseau. Dans la pratique, le nombre de routeurs connectés à un nœud RR pourra atteindre plusieurs centaines, ce qui montre l’avantage qu’il peut y avoir à utiliser un nœud RR.

[0051] Dans un ou plusieurs modes de réalisation, le nœud RR peut être configuré pour mettre en œuvre une ou plusieurs des fonctions spécifiées dans le document RFC 4456. Ainsi, comme illustré sur la figure 1, un réseau comprenant une pluralité de routeurs (RTR1, 10a ; RTR2, 10b, RTR3, 10c) peut utiliser un nœud RR (RTR2, 10b) afin de mettre en œuvre la distribution des informations de routage externes à tous les routeurs du réseau par le biais du nœud RR (RTR2, 10b). Lorsqu’un routeur a une information de routage à partager avec les autres routeurs du réseau, il peut envoyer cette information au nœud RR qui se charge de la redistribution aux autres routeurs. [0052] Le nœud routeur RR RTR2 (10b) peut ainsi fournir une interface entre tous les routeurs RTR1 (10a), RTR3 (10c) du réseau (2), ces routeurs n’ayant qu’à établir une session de communication de données avec le nœud routeur RR RTR2 (10b). Dans l’exemple de la figure 1, chaque routeur RTR1 (10a), RTR3 (10c) autre que le nœud routeur RR RTR2 (10b) peut avoir établi au préalable une session de communication de données avec le nœud routeur RR RTR2 ( 10b) pour l’échange de messages du protocole de routage avec ce nœud routeur RR RTR2 (10b).

[0053] En fonction du mode de réalisation, la fonction RR pourra être mise en oeuvre, en tout ou partie, au sein d’un des nœuds routeurs du réseau, et/ou en tout ou partie au sein d’un autre type de nœud du réseau.

[0054] Par exemple, dans un ou plusieurs modes de réalisation, le réseau (2) formé par les nœuds routeurs pourra être de tout type de réseau de communication de données, comme par exemple un réseau de paquets de données (en anglais, « Packet Data Network », ou PDN), et comprendre un ou plusieurs réseaux de transmission de données de type réseau IP (de l’anglais « Internet Protocol »), et utiliser des liens de communication basés sur les protocoles TCP, IP, et/ou tous types de protocole utilisables pour la communication de données dans un réseau de communication de données. En outre, en fonction du mode de réalisation, le réseau (2) pourra utiliser un ou plusieurs protocoles de routage, tels que par exemple le protocole BGP, le protocole ISIS, et/ou le protocole OSPF.

[0055] En référence à la figure 2, dans un ou plusieurs modes de réalisation, chaque nœud routeur (10) du réseau (par exemple chacun des nœuds routeur RTR1 (10a), RTR2 (10b), RTR3 (10c) de la figure 1) pourra comprendre une unité de communication de données (20), un contrôleur (21), une unité de routage (22), et une unité de mesure de temps de propagation (23). Selon le mode de réalisation, l’unité de communication de données (20), l’unité de routage (22), et l’unité de mesure de temps de propagation (23) pourront être couplées de manière opérationnelle au contrôleur (21) par un bus de communication (24), ou par tout lien de communication, comprenant éventuellement un ou plusieurs connecteurs matériels. Dans l’architecture du nœud routeur (10) illustré sur la figure 2, l’ensemble des unité de communication de données (20), contrôleur (21), unité de routage (22), unité de mesure de temps de propagation (23), unité fonctionnelle (24) et bus de communication (24) forme un nœud routeur selon un ou plusieurs modes de réalisation, qui peut par ailleurs inclure d’autres composants, unités, fonctions, non représentés sur la figure.

[0056] Le contrôleur (21) peut comprendre un ou plusieurs processeurs, comme microprocesseur, un microcontrolleur ou un autre processeur matériel, une mémoire associée (par exemple, une mémoire vive (RAM), une mémoire cache, une mémoire flash, etc.), et être apte à être configuré pour piloter l’unité de communication de données (20), l’unité de routage (22), l’unité de mesure de temps de propagation (23), afin de commander l’utilisation du nœud routeur ( 10) selon un ou plusieurs modes de réalisation du procédé proposé, par exemple en exécutant un programme d’ordinateur comprenant des portions de code pour la mise en œuvre d’un procédé de mesure du temps de propagation d’une information relative au routage de données tel que proposé dans la présente description. En fonction du mode de réalisation, une mémoire associée du contrôleur (21), externe ou interne au contrôleur (21), contient des instructions qui, lorsqu'elles sont exécutées par le contrôleur (21), amènent ce contrôleur (21) à effectuer ou contrôler les parties unité de communication de données (20), unité de routage (22), et/ou unité de mesure de temps de propagation (23) des exemples de mise en œuvre du procédé proposé décrits dans la présente description. Le contrôleur (21) peut être un composant implémentant un processeur ou une unité de calcul pour la mesure du temps de propagation d’une information relative au routage de données selon le procédé proposé et le contrôle de l’unité de mesure de temps de propagation (23) du dispositif (10), comme par exemple un microcontrôleur.

[0057] L’unité de mesure de temps de propagation (23) peut être mise en œuvre, selon le mode de réalisation choisi, sous la forme d’un ou plusieurs logiciels, ou d’une combinaison d’un ou plusieurs matériels et d’un ou plusieurs logiciels, configurés pour la mise en œuvre de modes de réalisation du procédé de gestion décrit dans la présente description. En particulier, le nœud routeur ( 10) peut être configuré par l’intermédiaire de l’unité de mesure de temps de propagation (23) pour fonctionner selon une pluralité de modes opératoires, parmi lesquels se trouvent un mode opératoire dit « nœud générateur » et un mode opératoire dit « nœud récepteur », et pour fonctionner en mode nœud générateur et/ou en mode nœud récepteur selon un ou plusieurs modes de réalisation décrits dans la présente description.

[0058] La partie logicielle de l’unité de mesure de temps de propagation (23) peut constituer ou faire partie d’un logiciel de pilotage du nœud routeur (10). Dans la suite, on désignera par « logiciel de pilotage » (en anglais, « driver ») un ensemble d’un ou plusieurs logiciels configurés pour la mise en œuvre d’un procédé de mesure du temps de propagation d’une information relative au routage de données tel que proposé dans la présente description. En fonction de l’architecture du nœud routeur, le logiciel de pilotage est configuré pour être exécutable sur un processeur du nœud routeur, et/ou sur un processeur d’un équipement informatique auquel une partie du nœud routeur est connectée.

[0059] L’unité de communication de données (20) peut être mise en œuvre, selon le mode de réalisation choisi, sous la forme d’une combinaison d’un ou plusieurs matériels et d’un ou plusieurs logiciels, et comprendre un ou plusieurs matériels de communication filaire, radiofréquence et/ou optique, et un logiciel de pilotage d’unité de communication, par exemple exécutable par le contrôleur (21) ou, dans une autre architecture du nœud de communication, exécutable par un processeur de l’unité de communication de données (20), et chargé dans une mémoire accessible par un processeur configuré pour exécuter le logiciel de pilotage d’unité de communication. Dans un ou plusieurs modes de réalisation, l’unité de communication de données (20) peut comprendre une interface de communication de données. [0060] L’unité de routage (22) peut être mise en œuvre, selon le mode de réalisation choisi, sous la forme d’une combinaison d’un ou plusieurs matériels et d’un ou plusieurs logiciels, et comprendre une ou plusieurs unités de gestion de protocole de routage, par exemple exécutable par le contrôleur (21) ou, dans une autre architecture du nœud routeur, exécutable par un processeur de l’unité de routage (22), et chargé dans une mémoire accessible par un processeur configuré pour exécuter le logiciel de pilotage d’unité de routage. Par exemple, l’unité de routage (22) pourra être configurée pour mettre en œuvre une ou plusieurs des fonctionnalités d’un protocole de routage, tel que le protocole BGP, le protocole ISIS, et/ou le protocole OSPF.

[0061] Le dispositif nœud routeur (10) peut être mis en œuvre sous forme logicielle, auquel cas il prend la forme d’un programme exécutable par un processeur, ou sous forme matérielle (ou « hardware »), comme un circuit intégré spécifique application (ASIC), un système sur puce (SOC), ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA (Field Programmable Gâte Array). Les SOC (System On Chip) ou système sur puce sont des systèmes embarqués qui intègrent tous les composants d’un système électronique dans une puce unique. Un ASIC (Application-specific Integrated Circuit) est un circuit électronique spécialisé qui regroupe des fonctionnalités sur mesure pour une application donnée. Les ASIC sont généralement configurés lors de leur fabrication et ne peuvent être que simulés par l’utilisateur. Les circuits logiques programmables de type FPGA (Field- Programmable Gâte Array) sont des circuits électroniques reconfigurables par l’utilisateur.

[0062] Le dispositif nœud routeur (10) peut également utiliser des architectures hybrides, comme par exemple des architectures basées sur un CPU+FPGA, un GPU (Graphics Processing Unit) ou un MPPA (Multi-Purpose Processor Array).

[0063] En fonction du mode de réalisation, différentes architectures du dispositif nœud routeur ( 10) peuvent être adoptées, tant pour la partie matérielle du dispositif, que pour la partie logicielle du dispositif, le cas échéant.

[0064] L’homme du métier comprendra que le procédé proposé n’est pas limité à une architecture particulière du nœud routeur (10), de l’unité de communication de données (20), du contrôleur (21), de l’unité de routage (22), de l’unité de mesure de temps de propagation (23) et du bus de communication (25), ou du couplage entre ces éléments illustrant à titre d’exemple un mode de réalisation sur la figure 2.

[0065] On décrit ci-après des procédés de mesure du temps de propagation d’une information de routage de données dans un système de communication de données tel que celui illustré sur les figures 1 et 2, dans un ou plusieurs modes de réalisation.

[0066] En référence aux figures 3a et 3b, dans un ou plusieurs modes de réalisation, l’un au moins des nœuds de communication (RTR2, 10b) du système (1) peut être configuré pour fonctionner en mode routeur RR, et un autre nœud routeur du système (1) (RTR1, 10a) peut être configuré pour générer (40) des données d’horodatage d’émission d’une information relative au routage de données, et insérer (41) les données d’horodatage d’émission dans un champ d’un message du protocole de routage BGP, le champ étant destiné à recevoir des données relatives au routage de données.

[0067] Le nœud routeur RTR1 ( 10a) peut alors envoyer (42) le message au nœud routeur RR RTR2 pour annoncer aux autres routeurs du réseau (2) l’information relative au routage de données portée par le message. Par exemple, dans le cas d’une utilisation du protocole de routage BGP, le message de protocole utilisé pour la mise en œuvre du procédé proposé peut être, en fonction du mode de réalisation, du type « UPDATE » ou du type « WITHDRAWN ». Le nœud routeur RTR1 envoie ainsi des données d’horodatage sous forme d’une information de routage dans le cadre de l’annonce de l’information de routage aux autres routeurs du réseau auxquels l’information de routage doit être annoncée selon le protocole de routage utilisé.

[0068] Sur réception du message en provenance du nœud routeur RTR1 (10a), le nœud routeur RR RTR2 (10b) effectue les traitements nécessaires pour transmettre l’information de routage contenue dans le message aux autres nœuds routeurs du réseau (2), et en particulier le nœud routeur RTR3 (10c).

[0069] Dans un ou plusieurs modes de réalisation, le nœud RTR3 (10c) peut être configuré pour, sur réception (50) d’un message du protocole de routage en provenance d’un autre nœud routeur, par exemple le nœud routeur RR RTR2 (10b) dans l’exemple de réseau illustré sur la figure 1, extraire (51) d’un champ du message reçu des données d’horodatage, le champ étant destiné à recevoir des données relatives au routage de données. En référence à la figure 1, les données d’horodatage peuvent correspondre à celles insérées par le nœud routeur RTR1 (10a) dans un champ du message de protocole de routage envoyé au nœud routeur RR RTR2 (10b). Le nœud routeur RTR3 (10c) pourra donc être configuré comme nœud récepteur pour effectuer des mesures de temps de traitement et de propagation d’un message du protocole de routage émis par un autre nœud routeur, configuré pour fonctionner comme nœud émetteur de messages de test, par un routeur ou un réseau de routeurs objet du test. En particulier, le nœud routeur récepteur pourra être configuré (par exemple préconfiguré) pour identifier, parmi les messages reçus ou parmi les différents types de messages reçus, ceux utilisés par le nœud routeur émetteur pour y insérer une information d’horodatage d’émission. De la même manière, le nœud routeur émetteur pourra être configuré (par exemple préconfiguré) pour insérer une information d’horodatage dans un message de protocole prédéfini ou d’un type prédéfini (par exemple un ou plusieurs messages de type UPDATE et/ou WITHDRAW pour le protocole de routage BGP), selon une configuration de test correspondante à celle utilisée pour configurer le nœud routeur récepteur.

[0070] Dans un ou plusieurs modes de réalisation, le nœud RTR3 (10c) peut en outre être configuré pour extraire du message reçu une information relative à un routeur à l'origine de ladite information relative au routage de données, soit dans l’exemple de la figure 1 extraire du message reçu une information permettant d’identifier le nœud routeur RTR1 (10a) à l’origine du message reçu (et donc des données d’horodatage qu’il contient).

[0071] Dans un ou plusieurs modes de réalisation, le nœud routeur RTR3 (10c) peut en outre être configuré pour générer (52) des données d’horodatage courant, puis déterminer (53) une estimation du temps de propagation de l’information de routage entre le routeur à l’origine du message et le routeur de destination du message (c’est-à-dire le nœud routeur RTR3 (10c) lui-même), sur la base d’une différence entre les données d’horodatage extraites du message et les données d’horodatage courant.

[0072] En référence à la figure 1, le nœud routeur de destination du message, RTR3 (10c) peut être configuré pour, sur réception du message en provenance du nœud routeur RTR1 (10a) via le nœud routeur RR RTR2 (10b), estimer un temps de propagation du message, ce temps de propagation comprenant la propagation du message depuis le routeur d’origine du message, RTR1 (10a) jusqu’au routeur de destination, RTR3 (10c) et le traitement du message par le nœud intermédiaire RTR2 (10b). Le nœud routeur de destination RTR3 (10c) peut ainsi avantageusement mesurer le temps cumulé nécessaire au nœud routeur RR RTR2 (10b), pour traiter le message, une fois reçu en provenance du nœud routeur d’origine RTR1 (10a) et pour le retransmettre à l’ensemble des autres nœuds routeurs du réseau (2).

[0073] Dans le cadre d’une mise en œuvre utilisant le protocole BGP, les messages BGP de type UPDATE ou de type WITHDRAWN pourront être utilisés dans un ou plusieurs modes de réalisation.

[0074] Dans un ou plusieurs modes de réalisation, les données d’horodatage pourront être de format nombre flotant sur 32 bits, avec la partie entière représentant le nombre de secondes écoulées depuis le 01/01/1970 et la partie décimale représentant le nombre de microsecondes à ajouter au nombre de secondes.

[0075] Le protocole BGP définit des messages BGP de type UPDATE pour entre autres effectuer l’annonce et/ou le retrait d’une information relative au routage, telle qu’une information d’accessibilité, comme par exemple un préfixe. Les messages BGP de type UPDATE comprennent quatre parties distinctes, dont un en-tête (en anglais, « header »), une partie « attribut de chemin » (en anglais, « Paths Attributes »), une partie « retrait » (en anglais, « Withdrawn ») et une partie « NLRI » (de l’anglais « Network Layer Reachability Information ») La partie « attribut de chemin » peut être utilisée pour indiquer la liste des propriétés associées à l’information relative au routage (par exemple au préfixe). La partie « retrait » peut être utilisée pour indiquer une information d’accessibilité, comme un ensemble de préfixes à retirer. La partie « NLRI » peut être utilisée pour indiquer des préfixes à créer/modifier et auxquels on associe le ou les attributs indiqués dans la partie « atribut ».

[0076] Différents types d’attribut peuvent être renseignés dans la partie « attribut », parmi lesquels le type d’atribut obligatoire « ORIGIN » pour définir l’origine de l’information de routage, le type d’attribut obligatoire « AS-PATH » pour définir une suite de segments de routes de systèmes autonomes, le type d’attribut obligatoire « NEXT HOP » pour définir l’adresse IP d’un routeur de frontière, le type d’attribut optionnel « MULTI EXIT DISC » pour définir différents points de sortie d’un système autonome, le type d’attribut discrétionnaire « LOCAL PREF » pour informer les routeurs d’un système autonome du degré de préférence d’un routeur annonceur pour une route annoncée, le type d’attribut discrétionnaire « ATOMIC AGGREGATE » ou le type d’attribut optionnel « AGGREGATOR ».

[0077] On pourra se reporter à la spécification RFC 4271 , par exemple dans l’édition de mars 1995, pour une description détaillée du message BGP UPDATE et des champs de ce message.

[0078] Dans un ou plusieurs modes de réalisation, une information de type horodatage peut être insérée, sous forme de données d’horodatage, dans un message de protocole BGP, par exemple dans un message de type UPDATE.

[0079] Dans un ou plusieurs modes de réalisation, les données d’horodatage peuvent être insérées dans un champ de message BGP UPDATE destiné à recevoir des données représentant une information relative au routage de données, comme par exemple des données de préfixe (par exemple préfixe d’adresse IP ou préfixe VPN).

[0080] Dans un ou plusieurs modes de réalisation, les données d’horodatage peuvent être insérées dans un champ de message UPDATE correspondant à la partie « attribut ». Par exemple, les données d’horodatage peuvent être insérées en tant qu’attribut avec un type d’attribut déjà existant, comme par exemple le type optionnel « LOCAL PREF ». Ainsi, on peut utiliser un type d’attribut ayant un format compatible avec celui des données d’horodatage à transmettre pour transmettre ces données dans un message BGP UPDATE. Les données d’horodatage sont alors transmises dans un message UPDATE comme attribut de type « LOCAL PREF ».

[0081] Dans un ou plusieurs modes de réalisation, les données d’horodatage peuvent être insérées dans un champ de message UPDATE correspondant à la partie « retrait ». Par exemple, les données d’horodatage peuvent être insérées en tant que préfixe Internet ou VPN. Ainsi, le champ « retrait » étant utilisé pour indiquer une liste de préfixes d’adresse IP pour les routes qui sont retirées du service, on peut transmettre des données d’horodatage ayant un format compatible avec celui d’un ou de plusieurs préfixes d’adresse IP en insérant ces données comme étant un ou plusieurs préfixes d’adresse IP dans un message BGP UPDATE. Les données d’horodatage sont alors transmises dans le champ « retrait » d’un message UPDATE comme préfixe(s) d’adresse IP.

[0082] Dans un ou plusieurs modes de réalisation, les données d’horodatage peuvent être insérées dans un champ de message UPDATE correspondant à la partie « NLRI ». Par exemple, les données d’horodatage peuvent être insérées en tant que préfixe Internet ou VPN. Ainsi, le champ « NLRI » étant utilisé pour indiquer une liste de préfixes d’adresse IP, on peut transmettre des données d’horodatage ayant un format compatible avec celui d’un ou de plusieurs préfixes d’adresse IP en insérant ces données comme étant un ou plusieurs préfixes d’adresse IP dans un message BGP UPDATE. Les données d’horodatage sont alors transmises dans le champ « NLRI » d’un message UPDATE comme préfixe(s) d’adresse IP.

[0083] Ainsi, dans un ou plusieurs modes de réalisation, un routeur BGP dit routeur « générateur » ou routeur « d’origine », génère un message BGP de type UPDATE, et insère des données d’horodatage d’émission dans le message BGP UPDATE en tant qu’ attribut dans la partie « attribut », en tant que préfixe d’adresse IP ou préfixe VPN dans la partie « retrait », et/ou en tant que préfixe d’adresse IP ou préfixe VPN dans la partie « NLRI ». Le routeur BGP générateur envoie ensuite le message BGP UPDATE au routeur (par exemple un routeur RR) ou au réseau dont on souhaite mesurer le temps de propagation (comprenant le temps de traitement).

[0084] Ledit routeur ou réseau effectue les traitements nécessaires pour prendre en compte des informations contenues dans le message BGP UPDATE envoyé par le routeur « générateur », et propager ce message à ses voisins après avoir effectué les traitements requis.

[0085] Un des routeurs recevant le message en provenance dudit routeur ou réseau, dit routeur « récepteur » ou routeur « de destination », est configuré pour extraire du message reçu les données d’horodatage. Par exemple, en fonction du mode de réalisation, si le routeur générateur est configuré pour insérer des données d’horodatage d’émission dans un message BGP UPDATE en tant qu’ attribut dans la partie « attribut », en tant que préfixe d’adresse IP ou préfixe VPN dans la partie « retrait », et/ou en tant que préfixe d’adresse IP ou préfixe VPN dans la partie « NLRI », le routeur récepteur sera, de manière correspondante, configuré pour extraire ces données d’horodatage d’un message BGP UPDATE reçu, comme attribut de la partie « attribut », comme préfixe d’adresse IP ou préfixe VPN de la partie « retrait », et/ou comme préfixe d’adresse IP ou préfixe VPN de la partie « NLRI », respectivement.

[0086] Le routeur récepteur peut ensuite comparer les données d’horodatage reçues avec son propre horodatage, pour en déduire le temps de propagation (y compris le temps de traitement) nécessaire audit routeur ou réseau.

[0087] La figure 4 illustre un exemple de mesures du temps de propagation dans un routeur RR dans un ou plusieurs modes de réalisation.

[0088] Ces mesures sont les résultats de tests effectués en exécutant des routines de test sur un routeur générateur de test BGP préconfiguré avec 5 millions de routes BGP à travers 330 sessions de communication de données avec un routeur RR.

[0089] Dans un premier test, le routeur générateur de test exécute une routine en boucle infinie, chaque instance de boucle comprenant (1) l’exécution de dix instances d’une boucle de génération et d’émission d’un message BGP UPDATE contenant des données d’horodatage dans le champ « Route Distinguisher » (qui un élément d’une route VPN-IPv4 ou VPN-IPv6)du message BGP UPDATE, avec un intervalle prédéterminé (par exemple 0,5 s) entre chaque instance, (2) un temps d’attente prédéterminé (par exemple 10 s), (3) l’exécution de dix autres instances de boucle de génération et d’émission d’un message BGP UPDATE contenant des données d’horodatage dans le champ « Route Distinguisher » (qui un élément d’une route VPN-IPv4 ou VPN-IPv6) du message BGP UPDATE, avec un intervalle prédéterminé (par exemple 0,5 s) entre chaque instance, et (4) un temps d’attente prédéterminé (par exemple 10 s).

[0090] Le routeur générateur de test BGP envoie donc quasiment en permanence à un routeur RR dont on cherche à mesurer le temps de traitement et propagation 10 messages UPDATE qui contiennent des modifications de route et des données d’horodatage. Le routeur RR traite chacun de ces messages, et les annonce à un routeur récepteur de test BGP. Le routeur récepteur de test BGP est configuré pour recevoir les messages BGP UPDATE en provenance du routeur RR, extraire de chaque message BGP UPDATE reçu des données d’horodatage depuis le champ « Route Distinguisher » du message, et déterminer une mesure du temps de traitement et propagation au routeur RR à partir de son propre horodatage et des données d’horodatage reçues.

[0091] Les résultats de ce premier test correspondent au nuage de points inférieur de la figure 4, avec une droite de tendance d’équation : y = 0.1041 — 4544.5.

[0092] Dans un deuxième test, le routeur générateur de test exécute une routine en boucle infinie, chaque instance de boucle comprenant (1) l’exécution de dix instances d’une boucle de génération et d’émission d’un message BGP WITHDRAW contenant des données d’horodatage dans le champ « Route Distinguisher » du message BGP WITHDRAW, avec un intervalle prédéterminé (par exemple 0,5 s) entre chaque instance, (2) un temps d’attente prédéterminé (par exemple 10 s), (3) l’exécution de dix autres instances de boucle de génération et d’émission d’un message BGP WITHDRAW contenant des données d’horodatage dans le champ « Route Distinguisher » du message BGP WITHDRAW, avec un intervalle prédéterminé (par exemple 0,5 s) entre chaque instance, et (4) un temps d’attente prédéterminé (par exemple 10 s).

[0093] Le routeur générateur de test BGP envoie donc quasiment en permanence à un routeur RR dont on cherche à mesurer le temps de traitement et propagation 10 messages WITHDRAW qui contiennent des modifications de route et des données d’horodatage. Le routeur RR traite chacun de ces messages, et les annonce à un routeur récepteur de test BGP. Le routeur récepteur de test BGP est configuré pour recevoir les messages BGP WITHDRAW en provenance du routeur RR, extraire de chaque message BGP WITHDRAW reçu des données d’horodatage depuis le champ « Route Distinguisher » du message, et déterminer une mesure du temps de traitement et propagation nécessaire au routeur RR pour le retrait d’une route à partir de son propre horodatage et des données d’horodatage reçues. [0094] Les résultats de ce premier test correspondent au nuage de points inférieur de la figure 4, avec une droite de tendance d’équation y = 0.1213 — 5292.9.

[0095] Le procédé proposé fournit une solution de mesure de temps de propagation dans un routeur ou dans un réseau utilisant un protocole de routage qui est avantageusement simple de mise en œuvre, notamment en ce qu’elle ne nécessite pas de développements supplémentaires sur le protocole de routage. Le procédé proposé peut ainsi être mise en œuvre par logiciel, de manière indépendante, c’est- à-dire sans dépendre d’une mise en œuvre particulière du protocole de routage ou d’un équipement propriétaire sur lequel il est mis en œuvre.

[0096] Le procédé proposé implique en outre avantageusement un faible coût de calculs, de sorte qu’il peut être mis en œuvre en parallèle à d’autres tests pour voir l’impact de ces autres tests sur le temps de propagation mesuré par le procédé proposé.

Application industrielle

[0097] En fonction du mode de réalisation choisi, certains actes, actions, évènements ou fonctions de chacune des méthodes décrites dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans certains modes de réalisation, certains actes, actions ou évènements sont effectués ou se produisent concurremment et non pas successivement.

[0098] Bien que décrits à travers un certain nombre d’exemples de réalisation détaillés, le procédé de pilotage proposé et le dispositif pour la mise en œuvre d’un mode de réalisation du procédé comprennent différentes variantes, modifications et perfectionnements qui apparaîtront de façon évidente à l’homme de l’art, étant entendu que ces différentes variantes, modifications et perfectionnements font partie de la portée de l’invention, telle que définie par les revendications qui suivent. De plus, différents aspects et caractéristiques décrits ci-dessus peuvent être mis en œuvre ensemble, ou séparément, ou bien substitués les uns aux autres, et l’ensemble des différentes combinaisons et sous-combinaisons des aspects et caractéristiques font partie de la portée de l’invention. En outre, il se peut que certains systèmes et équipements décrits ci-dessus n’incorporent pas la totalité des modules et fonctions décrits pour les modes de réalisation préférés.