FR2968154A1

FR2968154A1 - Procede de transmission de paquets de synchronisation de type ieee 1588v2 sur ethernet en mode lien par lien, via des equipements de reseau ayant une horloge transparente, et dispositif d'aide associe

Info

Publication number: FR2968154A1
Application number: FR1059838A
Authority: FR
Inventors: Pallec Michel Le; Dinh Thai Bui
Original assignee: Alcatel Lucent SAS
Current assignee: Alcatel Lucent SAS
Priority date: 2010-11-29
Filing date: 2010-11-29
Publication date: 2012-06-01
Anticipated expiration: 2030-11-29
Also published as: EP2458757A1; EP2458757B1; FR2968154B1

Abstract

Un procédé est dédié à la transmission de paquets de synchronisation entre des horloges maître (HM) et esclave (HE) d'un réseau à commutation de paquets supportant un protocole Ethernet au niveau de leurs interfaces, associés chacun à un module de mesure (MM) servant de support à un protocole de marquage temporel de type IEEE 1588V2, et reliés l'un à l'autre via un chemin de réseau défini par un protocole de routage ou à commutation de labels, afin de transmettre des paquets de synchronisation sur le réseau. Ce procédé comprend les étapes suivantes: i) insérer dans un paquet de synchronisation devant être transmis de l'une des horloges maître (HM) et esclave (HE), alors dite source, vers l'autre horloge maître (HM) ou esclave (HE), alors dite destinatrice, des informations représentatives d'une partie au moins du chemin de réseau défini par rapport au protocole de routage ou à commutation de labels, et ii) encapsuler sur Ethernet le paquet de synchronisation ayant fait l'objet d'une insertion, puis transmettre ce paquet encapsulé dans un mode lien par lien vers l'horloge destinatrice.

Description

PROCÉDÉ DE TRANSMISSION DE PAQUETS DE SYNCHRONISATION DE TYPE IEEE 1588V2 SUR ETHERNET EN MODE LIEN PAR LIEN, VIA DES ÉQUIPEMENTS DE RÉSEAU AYANT UNE HORLOGE TRANSPARENTE, ET DISPOSITIF D'AIDE ASSOCIÉ Domaine technique L'invention concerne les réseaux à commutation de paquets qui comportent des équipements (ou noeuds) supportant un protocole Ethernet (IEEE 802.3) au niveau de leurs interfaces (couche 2 du modèle OSI), associés chacun à un module de mesure servant de support à un protocole de marquage temporel de type IEEE 1588V2 (ou PTPV2), et reliés l'un à l'autre via un chemin de réseau défini par un protocole de routage ou à commutation de labels afin de transmettre des paquets de synchronisation 15 destinés à permettre la synchronisation d'horloges maître et esclave. On entend ici par "réseau à commutation de paquets" (ou "Packet-Switched Network") un réseau de communication dans lequel les messages numériques sont transmis sous forme de paquets de données d'une adresse source vers une adresse destinataire par des opérations de commutation ou 20 de routage. On notera que le medium de communication peut être filaire ou non filaire. Par ailleurs, on entend ici par "équipement ou noeud)" tout équipement (ou élément) de réseau représentant un point de commutation ou de routage (ou d'aiguillage). Il pourra donc s'agir, par exemple, d'un 25 commutateur de labels (ou d'étiquettes) ou d'un routeur. De plus, on entend ici par "horloge maître" un élément capable de transmettre, recevoir et traiter des messages/paquets horodatés de synchronisation selon le protocole de marquage temporel (ou à étiquette temporelle - en anglais "timestamp protocol") IEEE 1588V2. Cet élément 30 maintient la référence de fréquence ou de temps qui doit être distribuée à une ou plusieurs horloges esclaves. Un tel élément peut être, par exemple, une horloge maître IEEE 1588V2. Une horloge maître peut être intégrée dans, ou co-localisée avec, un élément ou équipement de réseau (comme par exemple un commutateur ou un routeur), mais cela n'est pas obligatoire. Enfin, on entend ici par "horloge esclave" un élément capable de transmettre, recevoir et traiter des messages/paquets horodatés afin d'asservir une horloge locale sur la référence de fréquence ou de temps qui est distribuée depuis l'horloge maître au moyen du protocole à étiquette temporelle. Cette horloge locale est notamment destinée à fournir une référence de fréquence ou de temps aux applications qui sont reliées à l'horloge esclave. Un tel élément peu être, par exemple, intégré dans, ou colocalisé avec, une station de base (dans le cas d'un réseau non filaire), mais cela n'est pas obligatoire. Etat de l'art Lorsque l'on veut synchroniser une horloge esclave (ou "slave dock" en anglais) sur une horloge maître (ou "master dock" en anglais une référence temporelle ou fréquentielle doit être distribuée de l'horloge maître à l'horloge esclave à travers les noeuds d'un réseau à commutation de paquets et au moyen de messages/paquets de synchronisation. A titre d'exemple non limitatif, les messages de synchronisation 20 peuvent être des messages du protocole IEEE 1588V2 (ou PTPV2 pour "Precision Time Protocol release 2") dans au moins un sens de communication, par exemple de l'horloge maître vers l'horloge esclave (messages de type "SYNC", par exemple) ou bien de l'horloge esclave vers l'horloge maître (messages de type "DELAY_REQ", par exemple). Ces 25 messages de synchronisation contiennent des informations d'horodatage (également appelées marquages temporels) qui permettent une synchronisation temporelle de l'horloge esclave sur l'horloge maître, à partir de laquelle peut être dérivée une synchronisation fréquentielle (ou syntonisation). Il est rappelé que la fréquence peut être dérivée du temps 30 mais que la réciproque n'est pas vérifiée. Résumé de l'invention, Comme le sait l'homme de l'art, pour synchroniser une horloge esclave sur une horloge maître, il faut au moins connaître le temps ou délai) de transmission aller (respectivement retour) des paquets des messages de synchronisation (ci-après appelés paquets de synchronisation) entre les horloges maître et esclave. Certains protocoles de marquage temporel, comme par exemple IEEE I588V2, permettent de déterminer ce temps de transmission avec une certaine précision, grâce aux marquages temporels (ou horodatages) qui sont effectués par des modules de mesure qui sont appelés "horloges transparentes" (ou "transparent clocks") et qui sont associées aux noeuds traversés. Il est rappelé qu'une horloge transparente est un module de mesure chargé de déterminer le temps de transit local (dans le noeud associé) des paquets de synchronisation d'un flux (par soustraction entre l'horodatage de départ local et l'horodatage d'arrivée local) et de cumuler ce temps de transit 15 local déterminé à la valeur en cours d'un champ dit de correction (ou "correction field") qui est situé dans l'entête du paquet de synchronisation considéré (ou bien dans celui du message de type "Follow-Up" associé). Avant qu'une telle opération de cumul puisse être effectuée dans un paquet de synchronisation par une horloge transparente, il faut que le paquet 20 de synchronisation de type PTPV2 ait été détecté localement parmi l'ensemble des paquets de données. Or, étant donné que dans un réseau on peut avoir déployé plusieurs technologies différentes et/ou plusieurs protocoles réseau différents (comme par exemple MPLS ("MultiProtocol Label Switching" MPLS-TP ou Ethernet sur PVV ("Pseudo-vire'")), chaque horloge 25 transparente doit être capable de détecter localement autant d'identifiants PTPV2 qu'il y a de technologies et/ou de protocoles réseau déployés. En outre, la détection (ou localisation) du champ de correction d'un paquet PTPV2 peut s'avérer difficile (ou complexe) dans le cas d'un empilement de couches protocolaires important supportant les paquets de synchronisation. A 30 titre d'exemple, lorsque les paquets de synchronisation sont transportés par une technologie pseudo-filaire Ethernet (définie par la règle RFC 4448), la pile de couches protocolaires peut être de type IEEEI588V2 sur UDP sur IP sur Ethernet sur PW "Pseudo-wire") sur MPLS "MultiProtocol Label Switching")

sur une couche de transport. De plus, la complexité d'un empilement de couches protocolaires peut avoir un impact sur la technique d'horodatage utilisée, et plus précisément sur la corrélation entre l'horodatage d'un paquet PTPV2 et l'heure à laquelle il est réellement transmis sur un lien, tan sur le plan de l'implémentation matérielle (ou "hardware") que sur le plan des imprécisions temporelles possibles. Par ailleurs, chaque opération de cumul effectuée sur un paquet PTPV2 en transit par l'horloge transparente d'un noeud implique une écriture dans le champ de correction de ce paquet PTPV2. Cette action intrusive induit une violation du principe d'isolation des couches réseaux et peut potentiellement conduire à des problèmes de sécurité et/ou d'intégrité de l'information transmise. En outre, la mise à jour du champ de correction est une opération qui est d'autant plus complexe que l'empilement de couches protocolaires est important. De plus, la mise à jour du champ de correction 15 d'un paquet PTPV2 impose également un nouveau calcul de valeur de champ(s) "cheksum" de ce paquet PTPV2. Or, la probabilité que ce nouveau calcul échoue est d'autant plus grande que l'empilement de couches protocolaires est important. Par conséquent, si l'on veut que les opérations de cumul se déroulent correctement quel que soit l'empilement de couches 20 protocolaires considéré, on doit implanter dans chaque noeud concerné par l'horodatage une horloge transparente spécifiquement adaptée à la technologie et/ou au protocole réseau utilisé(e)(s), et donc on doit prévoir autant de types d'horloge transparente qu'il y a de technologies et/ou de protocoles réseau. 25 Afin d'améliorer la situation il est possible d'utiliser des horloges de frontière (ou "boundary docks") à la place des horloges transparentes, et de gérer la distribution du temps selon un mode dit "lien-à-lien" (ou "Iink-to-link" en anglais). Hélas, cette solution ne peut pas être mise en oeuvre systématiquement, par exemple en raison d'une limitation induite par un effet 30 de cascade. En effet, on peut démontrer que chaque horloge de frontière introduit une erreur de phase, et donc la mise en cascade de plusieurs horloges de frontière sur un chemin de réseau induit une accumulation d'erreurs de phase qui devient rapidement problématique notamment lorsque veut obtenir des précisions de synchronisation temporelle de l'ordre de la microseconde, comme c'est par exemple le cas dans les réseaux mobiles de dernière génération. En outre, les horloges de frontières présentent généralement une complexité d'implémentation qui est supérieure à celle des horloges transparentes. L'invention a donc pour but d'améliorer la situation, en permettant d'utiliser des modules de mesure (ou horloges transparentes) d'un unique type, quel que soit l'empilement de couches protocolaires considéré, grâce à une transmission en mode lien par lien sur Ethernet en considérant le support offert par les horloges transparentes. Selon un premier aspect, l'invention propose un procédé, dédié à la transmission de paquets de synchronisation entre des horloges maître et esclave d'un réseau à commutation de paquets qui comporte au moins deux équipements supportant un protocole Ethernet (IEEE 802.3) au niveau de leurs interfaces (couche 2 du modèle OSI), associés chacun à un module de mesure servant de support à un protocole de marquage temporel de type IEEE 1588V2 (ou PTPV2), et reliés l'un à l'autre via un chemin de réseau défini par un protocole de routage ou à commutation de labels afin de transmettre des paquets de synchronisation sur le réseau. 20 Ce procédé comprend plus précisément les étapes suivantes: i) insérer dans un paquet de synchronisation devant être transmis de l'une des horloges maître et esclave, alors dite source, vers l'autre horloge maître ou esclave, alors dite destinatrice, des informations qui sont représentatives d'une partie au moins du chemin de réseau défini par 25 rapport au protocole de routage ou à commutation de labels (comme par exemple le protocole 1P ou MPLS), et ii) encapsuler sur Ethernet (IEEE 802.3) le paquet de synchronisation ayant fait l'objet d'une insertion, puis transmettre ce paquet de synchronisation encapsu é dans un mode lien par lien vers l'horloge destinatrice. 30 Le procédé peut comporter d'autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment : - on peut prévoir une étape (iii) dans laquelle, lorsqu'un équipement du chemin de réseau reçoit le paquet de synchronisation encapsulé, on détermine dans une table de correspondance de cet équipement une adresse d'un port de sortie Ethernet qui correspond aux informations de chemin de réseau insérées et devant être utilisé par cet équipement pour poursuivre la transmission de ce paquet de synchronisation reçu; les informations insérées peuvent comprendre au moins les adresses de communication des horloges maître et esclave, définies par rapport au protocole de routage ou à commutation de labels, les informations insérées peuvent également comprendre au moins l'adresse de communication, définie par rapport au protocole de routage ou à commutation de labels, de l'équipement qui est le destinataire suivant du paquet de synchronisation sur le chemin de réseau; > dans une première variante, les informations insérées peuvent également comprendre l'adresse de communication, définie par rapport au protocole de routage ou à commutation de labels, de chaque équipement situé sur le chemin de réseau; A dans une seconde variante, les informations insérées peuvent également comprendre au moins un paramètre qui définit le prochain saut devant être effectué sur le chemin de réseau par le paquet de synchronisation; 20 on peut insérer les informations dans au moins un champ préexistant choisi ou bien dans un champ additionnel de type dit "Type Length Value" (ou TLV) d'un entête du paquet de synchronisation. Selon un deuxième aspect, l'invention propose un dispositif destiné à aider à transmettre des paquets de synchronisation entre des horloges maître

25 et esclave d'un réseau à commutation de paquets qui comporte au moins deux équipements (ou noeuds) supportant un protocole Ethernet (IEEE 802.3) au niveau de leurs interfaces (couche 2 du modèle OSI), associés chacun à un module de mesure servant de support à un protocole de marquage temporel de type IEEE 1588V2, et reliés l'un à l'autre via un chemin

30 de réseau défini par un protocole de routage ou à commutation de labels, afin de transmettre des paquets de synchronisation sur le réseau. Ce dispositif est agencé, lorsqu'un paquet de synchronisation doit être transmis de l'une des horloges maître et esclave, alors dite source, vers l'autre horloge maître ou esclave, alors dite destinatrice, pour contrôler l'insertion dans ce paquet de synchronisation d'informations qui sont représentatives d'une partie au moins du chemin de réseau défini par rapport au protocole de routage ou à commutation de labels, puis pour contrôler l'encapsulation sur Ethernet du paquet de synchronisation ayant fait l'objet d'une insertion en vue de sa transmission dans un mode lien par lien vers l'horloge destinatrice. Par ailleurs, ce dispositif peut être également agencé, en cas de réception d'un paquet de synchronisation encapsulé par un équipement qui es situé sur le chemin de réseau, pour déterminer dans une table de correspondance de cet équipement l'adresse d'un port de sortie Ethernet qui correspond aux informations insérées dans ce paquet de synchronisation encapsulé, de sorte que cet équipement utilise ce port de sortie Ethernet déterminé pour poursuivre la transmission du paquet de synchronisation reçu. 15 De plus, ce dispositif peut être également agencé pour contrôler l'insertion des informations dans au moins un champ préexistant choisi ou bien dans un champ additionne de type TLV d'un entête du paquet de synchronisation. Selon un troisième aspect, l'invention propose un module de mesure 20 servant de support à un protocole de marquage temporel de type 1EEE 1588V2, propre à faire partie d'un équipement, appartenant à un réseau à commutation de paquets, supportant un protocole Ethernet (IEEE 802.3) au niveau de ses interfaces, et comprenant un dispositif d'aide du type de celui présenté ci-avant. 25 Brève description des dessins D'autres caractéristiques et avantages de l'invention apparaîtront à examen de la description détaillée ci-après, et du dessin annexé, sur lequel l'unique figure illustre de façon très schématique et fonctionnelle des noeuds 30 et des horloges maître et esclave, d'un réseau à commutation de paquets supportant un protocole Ethernet), connectés entre eux et dans certains desquels est implanté un module de mesure comportant un dispositif d'aide selon l'invention.

Le dessin annexé pourra non seulement servir à compléter l'invention, mais aussi contribuer à sa définition, e cas échéant. Description détaillée L'invention a pour objet de permettre la transmission de paquets de synchronisation entre des horloges maître HM et esclave HE d'un réseau à commutation de paquets comportant au moins deux équipements Ei dont les interfaces sont de type Ethernet (standard IEEE 802.3), qui sont associés chacun à un module de mesure (ou horloge transparente MM servant de support à un protocole de marquage temporel de type 1EEE 1588V2 (ou PTPV2) et qui sont reliés l'un à 'autre via un chemin de réseau défini par un protocole de routage ou à commutation de labels ou protocole réseau) afin de transmettre des paquets de synchronisation sur le réseau. Dans ce qui suit, on considère, à titre d'exemple illustratif, que 15 l'horloge esclave HE est intégrée dans une station de base SB d'un réseau de type LTE CLong Term Evolution") supportant un protocole Ethernet. Mais, l'invention n'est pas imitée à ce type de scénario. On notera que l'invention concerne n'importe quel type de réseau à commutation de paquets, filaire ou non filaire, et comprenant des 20 équipements (ou noeuds) Ei qui sont situés entre des horloges maître HM et esclave HE devant être synchronisées l'une par rapport à l'autre, et dans lesquels les paquets entrants et sortants font l'objet d'un horodatage (ou marquage temporel - "time stamping") destiné à signaler leurs horaires d'arrivée et de départ par rapport à une horloge locale. 25 Dans l'exemple non limitatif illustré sur l'unique figure, le réseau à commutation de paquets comprend cinq équipements (ou noeuds) Ei (i = 1 à 5) comportant chacun un module de mesure (ou horloge transparente) MM propre à traiter des messages/paquets de synchronisation générés par l'horloge maître HM et/ou l'horloge esclave HE. Par ailleurs, les horloges 30 maître HM et esclave HE sont chargées de générer et traiter les messages/paquets de synchronisation en vue de leur synchronisation. Ces équipements (ou noeuds) Ei sont par exemple des routeurs IP, des routeurs MPLS (ou "label switch routers"), ou des commutateurs à commutation de labels (ou d'étiquettes P S-TP ("MultiProtocol Label Switching-Transport Profile"). On notera que dans l'exemple non limitatif illustré sur l'unique figure le chemin de réseau, qui relie les horloges maître HM et esclave HE, passe par trois des équipements (ou noeuds) Ei (et plus précisément E1, E2 et E3). Par ailleurs, l'horloge maître HM est connectée par une liaison Ethernet au premier équipement El, et la station de base SB (qui comprend l'horloge esclave HE) est connectée au troisieme équipement E3. Ce chemin de réseau es destiné à permettre la transmission de paquets entre l'horloge maître HM et l'horloge esclave H ici via les équipements El à E3, et notamment de paquets de synchronisation qui définissent des messages de synchronisation destinés à l'horloge maître HM ou à 'horloge esclave HE. Les messages de synchronisation sont transmis selon le protocole de marquage temporel IEEE 1588V2 (ou PTPV2). Par conséquent, les messages de synchronisation qui sont transmis de 'horloge maître HM vers l'horloge esclave HE peuvent être de type "SYNC", es messages de synchronisation qui sont transmis de 'horloge esclave HE vers l'horloge maître HM peuvent être de type "DELAY_REQ". Mais, l'invention n'est pas 2o limitée à ces types de message. Chaque module de mesure MM équipant 'un des équipements Ei constitue une horloge transparente (ou "transparent clock") chargée de déterminer le temps de transit local (dans l'équipement Ei associé) des paquets de synchronisation d'un flux (par soustraction entre l'horodatage de 25 départ local et l'horodatage d'arrivée local) et de cumuler ce temps de transit local déterminé à la valeur en cours d'un champ dit de correction (ou "correction field") qui est situé dans l'entête du paquet de synchronisation considéré (ou bien dans celui du message de type "Follow-Up" associé), Selon un aspect, l'invention propose de mettre en oeuvre un procédé 3o dédié à la transmission de messages/paquets de synchronisation entre des horloges maître HM et esclave HE d'un réseau du type de celui présenté ci-avant. Ce procédé comprend au moins deux étapes (i) et (il). 2968154 Io Une première étape (i), du procédé, consiste à insérer dans un paquet de synchronisation qui doit être transmis de l'une des horloges maître HM et esclave HE, alors dite source, vers l'autre horloge maître HM ou esclave HE, alors dite destinatrice, des informations qui sont représentatives d'une partie au moins du chemin de réseau défini par rapport à un protocole de routage ou à commutation de labels ou protocole réseau), qui est utilisé par le réseau. On entend ici par "protocole de routage ou à commutation de labels" un protocole réseau qui est utilisé par le réseau et qui appartient à une couche qui est située au dessus de la couche 2 à laquelle appartient le protocole de transport Ethernet. Dans ce qui suit, on considère, à titre d'exemple illustratif, que le protocole de routage ou à commutation de labels est le protocole de routage IP (ou "Intemet Protocol"). Mais, 'invention n'est pas limitée à ce type de protocole réseau. Ainsi, elle concerne également, et par exemple, les protocoles MPLS MultiProtoco Label Switching"), MPLSTP ("MPLS-Transport Profile' et Ethernet sur PW "Pseudo-vire" - pseudofilaire). Compte tenu du choix précité de protocole de routage (IP), les informations qui sont insérées dans un paquet PTPV2 sont des adresses de 20 communication IP qui définissent au moins partiellement le chemin de réseau. Par exemple, on peut insérer au moins les adresses de communication des horloges maître HM et esclave HE définies par rapport au protocole de routage ici IP). En complément, on peut également insérer au moins l'adresse de 25 communication (définie par rapport au protocole de routage {ici IP}) de l'équipement Ei (par exemple El ou E2 ou encore E3) qui est le destinataire suivant du paquet de synchronisation considéré sur le chemin de réseau. Dans une première variante, on peut également insérer l'adresse de communication (définie par rapport au protocole de routage (ici IP)) de 30 chaque équipement Ei (ici El à E3) qui est situé sur le chemin de réseau. En d'autres termes, les informations insérées définissent ici explicitement l'intégralité du chemin de réseau. Dans une seconde variante, on peut également insérer au moins un Il paramètre qui définit le prochain saut qui doit être effectué sur le chemin de réseau par le paquet de synchronisation considéré. Cette variante est plus particulièrement adaptée au cas où le protocole de routage ou à commutation de labels est de type MPLS ou MPLS-T D'une manière générale, les informations d'adressage, qui sont insérées dans chaque paquet PTPV2, sont destinées à permettre une gestion de type lien par lien (ou "link-by-link") au niveau de chaque équipement Ei appartenant à un chemin de réseau reliant une horloge maître HM à une horloge esclave HE. Par conséquent, l'invention permet d'effectuer une distribution de temps reposant sur une gestion des paquets PTPV2 de type lien-à-lien et utilisant des horloges transparentes HT de type bout-en-bout (ou "end-to-end") ou de type pair à pair ou "peer to peer transparent clocks" en anglais). On notera que les informations peuvent être insérées en différents 15 endroit de l'entête d'un paquet PTPV2, et notamment dans au moins un champ préexistant choisi (comme par exemple "sourcePortldentity" et/ou erved"), ou bien dans un champ additionnel de type dit "Type Length Value" (ou TLV - Type Longueur Valeur). Une deuxième étape (ii), du procédé, consiste à encapsuler sur 2o Ethernet le paquet de synchronisation qui a fait l'objet d'une insertion, puis à transmettre ce paquet de synchronisation encapsulé dans un mode lien par lien vers l'horloge destinatrice HM ou HE. En d'autres termes, on contraint l'encapsulation des paquets PTPV2 sur Ethernet, exclusivement, de sorte que la détection des paquets PTPV2 ne soit effectuée que par des horloges 25 transparentes HT conçues sur la base du "profil" PTPV2 sur Ethernet, quel que soit le domaine considéré. Par conséquent, on n'a plus besoin que d'un seul et unique type d'horloge transparente HT configuré pour le seul profil PTPV2 sur Ethernet. Par exemple, lorsque le paquet PTPV2 fait partie d'un message de type SYNC, la détection peut se faire sur une valeur de champ 3o Ethertype, telle que déjà définie par e standard, c'est-à-dire égale à 88F7 en hexadécimale. Le chemin de transmission des données est donc ici un chemin défini au niveaulP, alors que le chemin de synchronisation est choisi hors de bande ou "out-of-band") et sur Ethernet avec une caractéristique de type lien-à-lien allant de 'horloge maître HM à l'horloge esclave HE. Cela évite d'avoir à transmettre des messages de signalisation étant donné qu'il n'y a pas de connexion à établir.

On notera que le contrôle de l'insertion d'informations d'adressage (ou de chemin de réseau) dans chaque paquet de synchronisation, e le contrôle de l'encapsulation sur Ethernet de chaque paquet de synchronisation ayant fait l'objet d'une insertion peuvent être assurés par un dispositif d'aide D associé à un équipement Ei ou à une horloge maître HM ou esclave HE.

On entend ici par "associé" aussi bien le fait de faire paille intégrante d'un équipement Ei ou d'une horloge maître HM ou esclave HE, que le fait d'être couplé directement ou indirectement à un équipement Ei ou à une horloge maître HM ou esclave HE. Par conséquent, un dispositif d'aide D peut être réalisé sous la forme de modules logiciels (ou informatiques) ou bien d'une combinaison de circuits électroniques et de modules logiciels. Comme illustré non limitativement, un dispositif d'aide D, selon l'invention, peut éventuellement faire partie d'un module de mesure (ou horloge transparente) MM. C'est notamment le cas, ici, dans les équipements Ei. Mais cela n'est pas obligatoire. En effet, un dispositif d'aide D peu être externe à un module de mesure MM tout en étant préférentiellement couplé à ce dernier (MM). Le procédé selon l'invention peut également comporter une troisième étape (iii). Cette dernière consiste, lorsqu'un paquet de synchronisation (ici PTPV2) à été reçu par un équipement Ei du chemin de réseau, à déterminer dans une table de correspondance de cet équipement Ei l'adresse d'un port de sortie Ethernet qu'il comprend et qui correspond aux informations insérées, afin que ce port de sortie Ethernet soit utilisé par l'équipement Ei pour poursuivre la transmission du paquet de synchronisation reçu. Comme illustré sur l'unique figure, cette table de correspondance est stockée dans des moyens de stockage MS de l'équipement Ei considéré. Ici, chaque table de correspondance comprend des données d'adressage qui établissent une correspondance entre des adresses de communication IP et des adresses de ports de sortie Ethernet d'un équipement EL En d'autres termes chaque table de correspondance établit un lien entre le plan de routage/transfert (table de routage IP ou table d'étiquettes) et la couche de transport Ethernet, de manière à permettre un interfonctionnement entre les paquets PTPV2 (transportés par le protocole Ethernet) et le protocole de routage ou â commutation de labels (ici le protocole de routage IP} pour l'adressage de type bout-en-bout. On notera que les moyens de stockage MS peuvent être de tout type connu de l'homme de l'art. Il pourra donc s'agir, par exemple, d'une mémoire, éventuellement de type logiciel.

On notera également que la détermination dans une table de correspondance de chaque adresse de port de sortie Ethernet correspondant aux informations insérées dans un paquet de synchronisation encapsulé, peut être également assurée par le dispositif d'aide D. Le traitement d'un paquet PTPV2 par un dispositif d'aide D d'un équipement Ei peut donc se dérouler comme suit. Chaque fois qu'un paquet arrive sur un port d'entrée d'un équipement Ei, le dispositif d'aide D détermine si il comporte (ici) un champ Ethertype dont la valeur est égale à 88F7 en hexadécimale. Si tel est le cas, le dispositif d'aide D lit le contenu du champ dédié aux informations d'adressage insérées (par exemple un champ TLV).

Puis, le dispositif d'aide D recherche dans la table de correspondance locale l'adresse de communication du port de sortie Ethernet (adresse MAC Ethernet) qui correspond aux informations lues dans le champ TLV et qui dessert le chemin de réseau. Enfin, le dispositif d'aide D ordonne à son équipement Ei de transmettre le paquet PTPV2 reçu via le port de sortie Ethernet dont il vient de déterminer l'adresse. On notera que dans certains cas, il est possible de procéder au remplacement, dans chaque équipement Ei, de l'adresse de communication source, qui est contenue dans le paquet PTPV2 reçu et qui est définie par rapport au protocole de routage ou à commutation de labels (ici le protocole de routage IP), par l'adresse de communication source de cet équipement Ei, également définie par rapport au protocole de routage ou à commutation de labels (ici le protocole de routage IP). Ce remplacement est effectué par le dispositif d'aide D dans un paquet PTPV2 avant qu'il n'ordonne à son équipement de retransmettre ce paquet PTPV2. On notera également que le traitement d'un paquet PTPV2 parvenu dans un équipement Ei comporte également l'opération de mise à jour du champ de correction par le module de mesure MM consécutive à la détermination par ce dernier du temps de transit local, ainsi qu'éventuellement un nouveau calcul par le module de mesure MM de valeur de champ(s) "checksum" du paquet considéré. D'une manière générale, chaque paquet de synchronisation peu subir toutes les opérations habituelles des modules de mesure ou horloges transparentes) MM.

10 L'invention ne se limite pas aux modes de réalisation de procédé de transmission, de dispositif d'aide et de module de mesure décrits ci-avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ci-après.

Claims

REVENDICATIONS1. Procédé de transmission de paquets de synchronisation entre des horloges maître (HM) et esclave (HE) d'un réseau à commutation de paquets comportant au moins deux équipements (El) supportant un protocole Ethernet au niveau de leurs interfaces, associés chacun à un module de mesure (MM) servant de support à un protocole de marquage temporel de type IEEE 1588V2, et reliés l'un à l'autre via un chemin de réseau défini par un protocole de routage ou à commutation de labels, afin de transmettre des paquets de synchronisation sur ledit réseau, ledit procédé comprenant les étapes suivantes: i) insérer dans un paquet de synchronisation devant être transmis de l'une desdites horloges maître (HM) et esclave HE), alors dite source, vers autre desdites horloges maître (HM) et esclave (1-1E), alors dite destinatrice, des informations représentatives d'une partie au moins dudit chemin de réseau défini par rapport audit protocole de routage ou à commutation de labels, et ii) encapsuler sur Ethernet ledit paquet de synchronisation ayant fait l'objet d'une insertion, puis transmettre ledit paquet de synchronisation encapsulé 20 dans un mode lien par lien vers ladite horloge destinatrice.
2. Procédé selon la revendication 1, dans lequel on prévoit une étape (iii) dans laquelle, à réception dudit paquet de synchronisation encapsulé dans un équipement (El) situé sur ledit chemin de réseau, on détermine dans une table de correspondance dudit équipement (Ei une adresse d'un poil de sortie Ethernet correspondant auxdites informations de chemin de réseau insérées et devant être utilisé pour poursuivre la transmission dudit paquet de synchronisation reçu.
3. Procédé selon l'une des revendications 1 et 2, dans lequel lesdites informations insérées comprennent au moins les adresses de communication 30 desdites horloges maître (HM) et esclave (HE) définies par rapport audit protocole de routage ou à commutation de labels,
4. Procédé selon la revendication 3, dans lequel lesdites informations insérées comprennent également au moins l'adresse de communication,définie par rapport audit protocole de routage ou à commutation de labels, de l'équipement (El) qui est le destinataire suivant dudit paquet de synchronisation sur ledit chemin de réseau.
5. Procédé selon la revendication dans lequel lesdites informations insérées comprennent également l'adresse de communication, définie par rapport audit protocole de routage ou à commutation de labels, de chaque équipement (Ei) situé sur ledit chemin de réseau.
6. Procédé selon la revendication 3, dans lequel lesdites informations insérées comprennent également au moins un paramètre définissant un prochain saut devant être effectué sur ledit chemin de réseau par ledit paquet de synchronisation.
7. Procédé selon l'une des revendications 1 à 6, dans lequel on insère lesdites informations dans au moins un champ préexistant choisi d'un entête du paquet de synchronisation.
8. Procédé selon l'une des revendications 1 à 6, dans lequel on insère lesdites informations dans un champ additionnel de type dit "Type Length Value" d'un entête du paquet de synchronisation.
9. Dispositif (D) d'aide à la transmission de paquets de synchronisation entre des horloges maître (HM) et esclave (HE) d'un réseau à commutation 20 de paquets comportant au moins deux équipements (Ei) supportant un protocole Etherne au niveau de leurs interfaces, associés chacun à un module de mesure (MM) servant de support à un protocole de marquage temporel de type IEEE 1588V2, e reliés l'un à l'autre via un chemin de réseau défini par un protocole de routage ou à commutation de labels, afin de 25 transmettre des paquets de synchronisation sur ledit réseau, ledit dispositif (D) étant agencé, lorsqu'un paquet de synchronisation doit être transmis de l'une desdites horloges maître (HM) et esclave (HE), alors dite source, vers l'autre desdites horloges maître (HM) et esclave (HE), alors dite destinatrice, pour contrôler l'insertion dans ce paquet de synchronisation d'informations représentatives d'une partie au moins dudit chemin de réseau défini par rapport audit protocole de routage ou à commutation de labels, puis pour contrôler l'encapsulation sur Ethernet dudit paquet de synchronisation ayant fait l'objet d'une insertion en vue de sa transmission dans un mode lien parlien vers ladite horloge destinatrice.
10. Dispositif selon la revendication 9, agencé, en cas de réception d'un paquet de synchronisation encapsulé par un équipement (El) situé sur ledit chemin de réseau, pour déterminer dans une table de correspondance dudit équipement (El) une adresse d'un port de sortie Ethernet correspondant auxdites informations insérées dans ledit paquet de synchronisation encapsulé, de sorte que ledit équipement (El) utilise ce port de sortie Ethernet déterminé pour poursuivre la transmission dudit paquet de synchronisation reçu.
11. Dispositif selon l'une des revendications 9 et 10, agencé pour contrôler l'insertion desdites informations dans au moins un champ préexistant choisi d'un entête du paquet de synchronisation.
12. Dispositif selon l'une des revendications 9 et 10, agencé pour contrôler l'insertion desdites informations dans un champ additionnel de type 15 dit "Type Length Value" d'un entête du paquet de synchronisation.
13. Module de mesure (MM), propre à servir de support à un protocole de marquage temporel de type IEEE 1588V2 et à faire partie d'un équipement (El) supportant un protocole Ethernet sur ses interfaces et appartenant à un réseau à commutation de paquets, et comprenant un dispositif d'aide (D 20 d'aide selon l'une des revendications 9 à 12.