Notions de base sur PTP et SyncE avec la configuration Cisco IOS XR

Introduction

Ce document décrit le fonctionnement des protocoles PTP (Precision Time Protocol) et SyncE (Synchronous Ethernet) avec des exemples de configuration, des exemples et des commandes de dépannage pour les périphériques Cisco IOS® XR dans les profils de télécommunications 8275.1 et 8275.2.

Informations générales

Pour nous, une horloge est une horloge murale ou une montre-bracelet, mais pour les périphériques réseau, il s’agit d’un signal périodique de 0 et de 1 alternés qui est utilisé pour échantillonner les bits de données. Tout comme une aiguille de secondes dans l'horloge a un mouvement angulaire pour représenter une seconde, une paire de 0 et 1 représente T (période [T=1/fréquence]). Pour générer cette horloge, les équipements de réseau utilisent un oscillateur à quartz qui présente une erreur de ±100 ppm (parties par million. par exemple, une horloge avec une fréquence de 250 MHz et 100 ppm aura une plage de fréquences de 249,975 MHz à 250,025 MHz.) pour générer le signal d'horloge. Ainsi, idéalement, l'horloge n'est pas complètement périodique mais est suffisante pour la nécessité d'échantillonner les signaux de données à partir des interfaces.

Les réseaux de télécommunications (3G/4G/5G) utilisent une horloge de très haute qualité (strate) et toutes les stations de base (NodeB/eNodeB, etc.) doivent être synchronisées avec cette horloge avec le moins d'erreurs/de retards possible (environ 1 µ).

• Une option consiste à installer un GPS à toutes les stations de base, ce qui est assez coûteux et moins sûr car le GPS fonctionne sur les systèmes satellites.
• La deuxième option consiste à utiliser l'équipement réseau existant (NE) pour transférer les informations d'horloge avec le signal de données. Cette option est très rentable, car les données sont déjà transférées par les réseaux nationaux et l'utilisation de réseaux nationaux pour le transfert des signaux d'horloge les rendra moins coûteux et plus sûrs. Cependant, la qualité de l'horloge peut ne pas être aussi bonne que celle de l'option GPS précédente et varie en fonction du profil/protocole utilisé dans les réseaux d'extrémité et de l'encombrement du réseau.

Importance de la synchronisation phase/fréquence

Un signal de message (par exemple, un signal vocal) modulé avec une onde haute fréquence (signal porteur) à l'extrémité de l'émetteur doit être démodulé à l'extrémité du récepteur avec le même signal porteur utilisé à l'extrémité de l'émetteur. Si un changement/décalage de fréquence ou de phase de l'onde porteuse se produit au niveau du récepteur, le signal du message est altéré. Cependant, un léger décalage est toujours attendu entre l'onde porteuse Rx et l'onde porteuse Tx.

Une analogie consiste à utiliser un coffre-fort pour envoyer un message et le verrouiller avec une clé. Si quelqu'un veut lire le message dans le coffre-fort, la même clé doit être utilisée pour déverrouiller le coffre à l'extrémité du récepteur. Si la clé de réplica présente des distorsions/défigurations, le message ne peut pas être lu.

Les compensations acceptables pour divers services de télécommunications sont les suivantes :

Synchronisation de l'horloge réseau

La synchronisation est l'alignement des horloges sur la même heure/phase et la même fréquence.

La synchronisation pour l'horloge peut être catégorisée en synchronisation de fréquence (atteignant = / = où = également appelé comme même débit), synchronisation de phase (en même temps) et synchronisation de l'heure (heure du jour).

Synchronisation de fréquence

Tous les NE doivent faire correspondre la fréquence de leur horloge à une horloge source (dérivée d’une horloge principale).

La synchronisation de fréquence pour NE peut être réalisée avec SyncE ou PTPv2, ce qui sera traité plus en détail dans cette section.

SyncE travaille à dériver la fréquence des paquets de données reçus sur l'interface (fonctionne sur la couche physique) avec les paquets ESMC reçus (un paquet par seconde environ) sur l'interface qui décrit la qualité de l'horloge. Ainsi, il n'ajoute aucun paquet de contrôle et n'est pas affecté par l'encombrement du trafic, qui est le meilleur aspect de SyncE.

Le protocole PTP s’exécute sur les paquets, de sorte qu’il y aura un flux de paquets de contrôle et que les paquets seront affectés par l’encombrement, ce qui augmente le délai.

Synchronisation de phase

La synchronisation de phase concerne l'alignement de ces signaux d'horloge. On voit que les signaux synchronisés en fréquence ci-dessus ne sont pas encore alignés, donc ils ont un déphasage.

PTPv2 est utilisé pour transporter les informations de phase sur le réseau.

Synchronisation temporelle

La synchronisation de l'heure, également appelée heure du jour, a simplement la même heure dans tous les NE. Autrement dit, t₁=t_2^.

Les protocoles NTP et PTP sont utilisés pour transférer des informations de temps sur le réseau. Alors que le protocole NTP fournit une précision à la milliseconde, le protocole PTP peut fournir une précision inférieure à la microseconde.

La synchronisation temporelle et la synchronisation de phase sont souvent utilisées comme synonymes dans les réseaux, car le protocole PTP utilisé pour la synchronisation de phase permet d’obtenir une synchronisation temporelle.

NTP ne fera pas partie de notre discussion maintenant.

SyncE

Principe de base de SyncE

SyncE fonctionne sur le principe de base d'extraction de la fréquence d'horloge à partir des données reçues sur un port.

Un exemple simple est illustré ici. Le signal de données est traité avec l'oscillateur local et les données de sortie sont envoyées à partir du port Tx. Vous pouvez observer que la fréquence d'horloge est présente dans le signal de données transmis sur le port. SyncE fonctionne sur le principe du traitement inverse du signal reçu sur le port Rx et de l'obtention des informations de fréquence de l'horloge transmise.

SyncE est une recommandation de l'UIT-T sur la manière de fournir une fréquence dans un réseau. Selon la recommandation, la fréquence sera récupérée à partir du train de bits dans la couche physique comme indiqué précédemment. L’horloge qui sera distribuée dans la chaîne est appelée horloge de référence primaire (PRC) et toutes les horloges du réseau doivent pouvoir être retracées jusqu’à cette horloge. Pour obtenir une horloge traçable, tous les noeuds d'une chaîne entre l'horloge principale et le périphérique final doivent être mis en oeuvre avec une horloge d'équipement Ethernet (EEC) synchrone conformément aux recommandations SyncE. Les performances de l'horloge récupérée ne dépendent pas de la charge réseau, car elle ne se synchronise pas avec un paquet spécifique.

Le NE MasterClock prend les références de synchronisation d'entrée externes qui proviennent de l'horloge réseau (SSU ou BITS). Ces références sont ensuite utilisées comme entrée de l'horloge EEC, typiquement située sur la carte de temporisation centrale du NE. La référence de synchronisation de sortie EEC est ensuite utilisée pour échantillonner les données et envoyer le trafic sur le port Tx d'activation SyncE.

Au niveau du NE SlaveClock, l'horloge est récupérée dans le CDR (Transceiver Clock Data Recovery). Dans certains cas, lorsque l'horloge RX n'est pas disponible à l'émetteur-récepteur, l'utilisation d'un CDR externe peut être nécessaire pour récupérer l'horloge. L'horloge est ensuite envoyée par le fond de panier pour atteindre la carte de synchronisation centrale de SlaveClock. Cette référence de synchronisation devient alors une référence à la CEE (également appelée référence de synchronisation de ligne). Comme l'illustre le NE SlaveClock, un EEC peut accepter des références de ligne et externes, ainsi que l'entrée d'un oscillateur local ±4,6 ppm (utilisé dans les situations où aucune référence de ligne ou externe n'est disponible). A partir de ce point, l'NE SlaveClock devient alors l'NE MasterClock pour le NE aval suivant, et la synchronisation est transportée noeud à noeud, où chaque noeud participe à la récupération et à la distribution.

Canal de messagerie de synchronisation Ethernet

Le canal de messagerie de synchronisation Ethernet (ESMC) est un protocole Ethernet lent défini par l'UIT-T (c'est-à-dire que les messages sont envoyés à l'adresse de destination Ethernet de multidiffusion 01-80-C2-00-00-02 et utilisent le type d'Ether 88-09) pour empêcher les messages de passer d'une liaison synchronisée à une autre liaison.

Il transporte les informations SSM (Synchronization Status Message) qui correspondent au niveau de qualité (QL) de l'horloge de transmission. Par exemple : si le périphérique en amont est synchronisé avec une horloge PRC, la valeur QL reçue est QL-PRC et la valeur SSM correspondante est 0010.

Les unités de données de protocole d’informations ESMC sont envoyées périodiquement à raison d’une unité de données de protocole par seconde. L’absence de réception d’une unité de données de protocole ESMC dans un délai de cinq secondes entraîne la définition de SSF=true (QL=QL-FAILED). La valeur par défaut (initiale) de QL est DNU (SSM=1111) et ne doit être modifiée que lorsqu'un TLV QL valide est reçu.

Nous devons noter que si un périphérique est à double résidence et que la source de signal pour les deux périphériques en amont est PRC, alors la QL reçue sur le périphérique à partir des deux liaisons est QL-PRC. Par conséquent, nous devons hiérarchiser les liaisons en conséquence pour choisir le périphérique en amont approprié en ce qui concerne les sauts, les liaisons, etc.

La synchronisation MasterClock-SlaveClock sur plusieurs NE avec plusieurs entrées de synchronisation possibles pour la protection de la synchronisation pourrait conduire à des boucles de synchronisation entre NE. Afin d'éviter les boucles de synchronisation, un NE doit insérer une valeur SSM de DNU dans la direction du NE, qui est utilisée comme source de synchronisation réelle pour l'horloge NE.

SyncE avec LAG

SyncE fonctionne sur la couche physique et les paquets ESMC sont également transportés par le protocole Ethernet lent. LAG est une autre fonction qui utilise des protocoles lents et LAG fonctionne au-dessus d'ESMC. Le traitement des messages ESMC est donc nécessaire sur chaque liaison Ethernet synchrone du groupe LAG.

Il est également important de noter que l'utilisation de liaisons parallèles, comme dans le cas du LAG, doit être soigneusement envisagée en raison du potentiel de création de boucles de synchronisation.

 Idéalement, il suffit de l'exécuter sur la liaison à un seul membre du bundle, mais sinon, il revient aux opérateurs de configurer plusieurs ports Ethernet synchrones.

PTPv2/1588v2

IEEE 1588 est défini par l'Institute of Electrical and Electronics Engineers (IEEE) en 2002 comme protocole PTP (Precision Clock Synchronization Protocol) pour les systèmes de mesure et de contrôle en réseau. Il est appelé protocole PTP (Precision Time Protocol) pour abréger.

IEEE 1588v1 s'applique à l'automatisation industrielle et aux domaines des tests et des mesures. Avec le développement des réseaux IP et la popularisation des réseaux 3G, la demande de synchronisation temporelle sur les réseaux de télécommunications a augmenté. Pour répondre à ce besoin, l'IEEE a rédigé la norme IEEE 1588v2 sur la base de la norme IEEE 1588v1 en juin 2006, révisé la norme IEEE 1588v2 en 2007 et publié la norme IEEE 1588v2 à la fin de 2008.

1588v2 est un protocole de synchronisation temporelle qui permet une synchronisation temporelle extrêmement précise entre les périphériques. Il est également utilisé pour mettre en oeuvre la synchronisation de fréquence entre les périphériques.

Ce mécanisme de synchronisation par paquets combine la synchronisation de fréquence et de phase à des niveaux inférieurs à la microseconde, avec des capacités de distribution ToD via le mécanisme efficace d'échanges de paquets

La principale faiblesse de PTP est également due à sa nature de paquet, car les paquets de synchronisation utilisés par PTP sont transférés dans le réseau entre MasterClock et les hôtes, qui sont soumis à tous les événements du réseau tels que le retard de trame (latence), la variation du retard de trame (gigue de paquet) et la perte de trame. Même avec la meilleure pratique d'application d'une priorité élevée aux flux de synchronisation, ces paquets de synchronisation continueront à connaître un encombrement et d'éventuels problèmes de routage et de transfert, tels que les sauts de séquence et les sauts de route.

Principe de fonctionnement de base de la PTP

Nous envoyons l'heure (hh:mm:ss) dans un paquet et nous utilisons le temps de transmission aller-retour du flux de paquets pour trouver le délai de transmission d'un paquet et corriger le temps d'horloge en ajustant avec la moitié du délai de transmission aller-retour.

Fonctionnement de PTP

PTP utilise une architecture MasterClock-SlaveClock hiérarchique pour la distribution des horloges.

Elle spécifie comment les horloges en temps réel du système se synchronisent entre elles. Ces horloges sont organisées en une hiérarchie de synchronisation MasterClock−SlaveClock, l'horloge en haut de la hiérarchie déterminant l'heure de référence pour l'ensemble du système. La synchronisation est réalisée par l'échange de messages de synchronisation PTP, les SlaveClocks utilisant les informations de synchronisation pour ajuster leurs horloges à l'heure de leur MasterClock dans la hiérarchie.

Le protocole PTP a été conçu sur la base d’un modèle de communication multidiffusion. PTP prend également en charge un modèle de communication monodiffusion tant que le comportement du protocole est préservé. Le protocole PTP suppose que les messages d’annonce sont envoyés périodiquement par un port et remis à tous les autres ports des horloges ordinaires ou limites d’un chemin de communication. Si le chemin de communication comporte plus de deux ports, l'hypothèse est que les messages d'annonce sont envoyés en multidiffusion ou que les informations d'annonce sont répliquées sur tous les ports du chemin de communication à l'aide de messages de monodiffusion. Les ports PTP détectent d'autres ports dans un chemin de communication par la réception de messages d'annonce de multidiffusion.

Le protocole s'exécute dans une étendue logique appelée domaine. Tous les messages PTP, ensembles de données, machines d'état et toutes les autres entités PTP sont toujours associés à un ID de domaine particulier

Le protocole définit l'événement et les messages PTP généraux. Les messages d'événement sont des messages chronométrés, c'est-à-dire qu'un horodatage précis (temps enregistré sur le périphérique au point d'entrée/sortie, mais il n'est pas nécessaire que le message transporte le temps t) est généré à la fois lors de la transmission et de la réception. Les messages généraux ne nécessitent pas d'horodatages précis.

Domaines PTP

Un domaine consiste en un regroupement logique d’horloges communiquant entre elles à l’aide du protocole PTP.

Les domaines PTP sont utilisés pour partitionner un réseau au sein d’une entité administrative. Les messages et ensembles de données PTP sont associés à un domaine et, par conséquent, le protocole PTP est indépendant pour différents domaines.

Modèle d'échange de messages

1. Le MasterClock envoie un message Sync au SlaveClock et note l'heure à laquelle il a été envoyé.
2. SlaveClock reçoit le message Sync et note l'heure de réception.
3. MasterClock transmet l'horodatage à SlaveClock en :
   • Incorporation de l'horodatage dans le message de synchronisation. Cela nécessite une sorte de traitement matériel pour une précision et une précision maximales.
   • Incorporation de l'horodatage dans un message de suivi.
4. SlaveClock envoie un message Delay_Req à MasterClock et note l'heure à laquelle il a été envoyé.
5. MasterClock reçoit le message Delay_Req et note l'heure de réception.
6. L'horloge maître transmet l'horodatage à l'horloge esclave en l'incorporant dans un message Delay_Resp.

La précision du temps PTP est dégradée par l'asymétrie dans les chemins empruntés par les messages d'événement. En effet, l'erreur de décalage temporel est égale à 1/2 de l'asymétrie.

L'asymétrie n'est pas détectable par PTP. Cependant, si elle est connue, PTP corrige l'asymétrie. L'asymétrie peut être introduite dans la couche physique, par exemple, par l'intermédiaire de l'asymétrie des supports de transmission, par des ponts et des routeurs, et dans les grands systèmes par les chemins d'aller et de retour traversés par des messages d'événement empruntant différentes routes à travers le réseau. Les systèmes doivent être configurés et les composants sélectionnés pour minimiser ces effets doivent être guidés par la précision de synchronisation requise. Dans les systèmes à sous-réseau unique avec des distances de quelques mètres, l'asymétrie n'est généralement pas un problème pour les précisions de temps supérieures à quelques dizaines de ns.

Différents types de paquets

L'ensemble des messages d'événement comprend :

1. Sync : utilisée pour la synchronisation de l'heure entre MasterClock et SlaveClock. En deux étapes, les messages Sync ne transportent pas de temps, mais l'heure est horodatée à l'horloge principale et est transportée dans le message Follow_Up. En une seule étape, le message de synchronisation transporte le temps. Les anciens périphériques/matériels ne pouvaient pas prendre en charge la mesure et le transport du point temporel de sortie lorsqu'un message était transmis par un port. Par conséquent, la configuration en deux étapes était limitée par le matériel. De nos jours, le matériel peut enregistrer le point temporel de sortie et l'envoyer dans le message de synchronisation. Un pas est rétrocompatible avec deux pas.

   

2. Delay_Req : un message Delay_Req est une demande du noeud de réception/SlaveClock pour renvoyer l'heure à laquelle le message Delay_Req a été reçu, à l'aide d'un message Delay_Resp. Il sera utilisé pour calculer le temps de transit entre SlaveClock et MasterClock. Ce message est horodaté à l'horloge esclave.
3. Pdelay_Req - Un message Pdelay_Req est transmis par un port PTP à un autre port PTP dans le cadre de la mesure du temps de propagation de port à port pour déterminer le délai sur la liaison entre eux. Il est utilisé par l'horloge transparente P2P pour calculer le délai de liaison par saut.
4. Pdelay_Resp - Un message Pdelay_Resp est transmis par un port PTP en réponse à la réception d'un message Pdelay_Req.

L'ensemble des messages généraux se compose des éléments suivants :

• Announce (Annonce) : ce message est utilisé par le meilleur algorithme MasterClock (BMCA) pour générer la topologie MasterClock-SlaveClock. Il est utilisé pour sélectionner le meilleur MasterClock et le maintenir en place.
• Follow_Up : ce type de message est utilisé en mode à deux étapes. Il porte le temps. (Heure de sortie de synchronisation sur le noeud MasterClock) dans son message.
• Delay_Resp - Il est utilisé pour calculer le temps de transit de MasterClock à SlaveClock. Il transporte l'heure (heure de sortie du message Delay_Resp) dans le message.
• Pdelay_Resp_Follow_Up : ce message est similaire au message Follow_Up, mais il est généré par une horloge P2P transparente.
• Gestion : Ne fait pas partie de notre discussion.
• Signalisation : pour la communication entre les horloges à toutes autres fins. Par exemple, les messages de signalisation peuvent être utilisés pour la négociation du taux de messages de monodiffusion entre un MasterClock et ses SlaveClocks.

Les messages Sync, Delay_Req, Follow_Up et Delay_Resp sont utilisés pour générer et communiquer les informations de synchronisation nécessaires à la synchronisation des horloges ordinaires et limites à l'aide du mécanisme de demande-réponse de délai.

Les messages Pdelay_Req, Pdelay_Resp et Pdelay_Resp_Follow_Up sont utilisés pour mesurer le délai de liaison entre deux ports d'horloge mettant en oeuvre le mécanisme de délai d'homologue. Le délai de liaison est utilisé pour corriger les informations de synchronisation dans les messages Sync et Follow_Up dans les systèmes composés d'horloges transparentes d'égal à égal.

Les horloges ordinaires et limites qui implémentent le mécanisme de délai d'homologue peuvent se synchroniser à l'aide des délais de liaison mesurés et des informations contenues dans les messages Sync et Follow_Up. Le message Announce permet d'établir la hiérarchie de synchronisation. Les messages de gestion sont utilisés pour interroger et mettre à jour les ensembles de données PTP gérés par des horloges. Ces messages sont également utilisés pour personnaliser un système PTP et pour l'initialisation et la gestion des pannes. Les messages de gestion sont utilisés entre les noeuds de gestion et les horloges (ne feront pas partie de notre discussion).

Les messages de signalisation sont utilisés pour la communication entre les horloges à toutes autres fins. Par exemple, les messages de signalisation peuvent être utilisés pour la négociation du taux de messages de monodiffusion entre un MasterClock et ses SlaveClocks.

Types de périphériques PTP

Il existe cinq types de périphériques PTP de base, comme suit :

1. Horloge ordinaire - Ne peut être qu'une HorlogeGrandMaître (GM) ou seulement une HorlogeEsclave.
2. Horloge frontière - Peut être à la fois SlaveClock et GM
3. Horloge transparente de bout en bout : l'horloge transparente de bout en bout transmet tous les messages comme un pont, un routeur ou un répéteur normal. Cependant, pour les messages d'événement PTP, le pont temporel de résidence, illustré dans la figure ci-dessous, mesure le temps de résidence (temps nécessaire au message pour traverser l'horloge transparente) des messages d'événement PTP. Ces temps de séjour sont cumulés dans un champ spécial, le champ de correction, du message d'événement PTP ou du message de suivi associé. Cette correction est basée sur la différence d'horodatage générée lorsque le message d'événement entre et sort de l'horloge transparente.

   

   

   

4. Horloge transparente peer to peer - Ajoute le temps de résidence ainsi que le temps de retard de transit de la liaison aux messages ptp à l'aide du mécanisme de retard de l'homologue (génère ses propres paquets delay-req-resp pour calculer le délai de liaison de l'homologue).

   

   

5. Noeud de gestion (ne fait pas partie de notre discussion).

Établir la hiérarchie MasterClock−SlaveClock

Dans un domaine, chaque port d'une horloge ordinaire et limite exécute une copie indépendante de la machine d'état de protocole. Pour les « événements de décision d'état », chaque port examine le contenu de tous les messages d'annonce reçus sur le port. A l'aide du meilleur algorithme MasterClock, le contenu du message Announce et le contenu des ensembles de données associés à l'horloge ordinaire ou limite sont analysés afin de déterminer l'état de chaque port de l'horloge.

Machine d'état PTP

Chaque port d'une horloge ordinaire et limite conserve une copie séparée de la machine d'état PTP. Cet automate fini définit les états autorisés du port et les règles de transition entre les états. Les principaux « événements de décision d'état » déterminant la hiérarchie MasterClock−SlaveClock sont la réception d'un message d'annonce et la fin d'un Intervalle d'annonce (l'intervalle entre les messages d'annonce). Les états de port qui déterminent la hiérarchie MasterClock−SlaveClock sont les suivants :

• INIT - Le port n'est pas encore prêt à participer au protocole PTP.
• ÉCOUTE : premier état lorsqu'un port est prêt à participer au protocole PTP : le port écoute les horloges principales PTP pendant une période (configurable)
• PRE-MasterClock : le port est sur le point de passer à l'état MasterClock.
• MasterClock : le port fournit des horodatages pour toutes les horloges SlaveClock/de limite d'écoute.
• UNCALIBRATED - Le port reçoit des horodatages d'une horloge principale, mais l'horloge du routeur n'est pas encore synchronisée avec cette horloge principale
• ESCLAVE : le port reçoit des horodatages d'une horloge maître et l'horloge du routeur est synchronisée avec cette horloge maître
• PASSIVE - Le port est conscient d'une meilleure horloge que celle qu'il annoncerait s'il était à l'état MasterClock, mais n'est pas asservi à cette horloge

Meilleur algorithme MasterClock

Le meilleur algorithme MasterClock compare les données décrivant deux horloges pour déterminer quelles données décrivent la meilleure horloge. Cet algorithme est utilisé pour déterminer laquelle des horloges décrites dans plusieurs messages d'annonce reçus par un port d'horloge local est la meilleure horloge. Il est également utilisé pour déterminer si une horloge nouvellement découverte (une horloge maître étrangère) est meilleure que l'horloge locale elle-même. Les données décrivant un MasterClock étranger sont contenues dans les champs grandMasterClock d'un message Announce.

L'algorithme de comparaison d'ensembles de données est basé sur des comparaisons par paires d'attributs avec la priorité suivante :

1. priority1 : désignation configurable par l'utilisateur indiquant qu'une horloge appartient à un ensemble ordonné d'horloges parmi lesquelles une horloge principale est sélectionnée
2. clockClass : attribut définissant la traçabilité TAI d'une horloge
3. clockAccuracy : attribut définissant la précision d'une horloge
4. offsetScaledLogVariance - Attribut définissant la stabilité d'une horloge
5. priority2 - Désignation configurable par l'utilisateur qui permet un classement plus fin parmi les horloges équivalentes
6. clockIdentity - Un tie-breaker basé sur des identifiants uniques

En plus de cet ordre de priorité, la « distance » mesurée par le nombre d'horloges limites entre l'horloge locale et l'horloge maître étrangère est utilisée lorsque deux messages Announce reflètent la même horloge maître étrangère. La distance est indiquée dans le champ ÉtapesSupprimées des messages d'annonce. Cette condition peut se produire dans les systèmes PTP avec des chemins cycliques qui ne sont pas supprimés par un protocole en dehors de PTP. L'algorithme de comparaison d'ensembles de données sélectionne sans ambiguïté l'une des deux horloges comme « meilleure » ou « meilleure topologiquement ».

Profils

L'objectif d'un profil PTP est de permettre aux organisations de spécifier des sélections spécifiques de valeurs d'attribut et de fonctions optionnelles de PTP qui, lorsqu'elles utilisent le même protocole de transport, interagissent et atteignent des performances qui répondent aux exigences d'une application particulière.

Un profil PTP doit définir :

• Meilleures options d'algorithme MasterClock
• Options de gestion de configuration
• Mécanismes de délai de chemin (peer-delay ou delay request-response)
• La plage et les valeurs par défaut de tous les attributs configurables PTP et des membres du jeu de données
• Mécanismes de transport requis, autorisés ou interdits
• Les types de noeuds requis, autorisés ou interdits
• Les options requises, autorisées ou interdites

Les différents profils définis pour la mise en réseau de paquets avec PTP sont les suivants :

Les profils 8265.x sont utilisés pour réaliser la synchronisation de fréquence avec PTP.

8275.x est utilisé pour la synchronisation de l'heure/de la phase à l'aide du protocole PTP. NCS5xx/55xx prend actuellement en charge 8265.1, 8275.1, 8275.2 et 8273.2.

La norme 8265.1 était auparavant utilisée pour la synchronisation d'horloge 3G/4G, tandis que la norme 8275.x est désormais utilisée pour la 5G en raison de la demande croissante de précision pour les réseaux 5G.

8275.1

Cette annexe contient le profil de télécommunications PTP pour la distribution phase/temps avec prise en charge complète de la synchronisation à partir du réseau.

Modèle de synchronisation :

Le profil G.8275.1 adopte le modèle de synchronisation saut par saut. Chaque périphérique réseau sur le chemin de l'horloge du serveur au client synchronise son horloge locale avec les périphériques en amont et assure la synchronisation avec le périphérique en aval

Types de noeuds :

Dans ce profil, les types de noeud autorisés sont les horloges ordinaires, les horloges de limite et les horloges transparentes de bout en bout.

Dans ce profil, les types de noeuds interdits sont des horloges transparentes peer to peer.

Domaines :

Les ID de domaine compris entre 24 et 43 peuvent être utilisés. L'ID de domaine par défaut est 24

Mode horloge :

Les horloges à un pas et à deux pas sont autorisées. Une horloge doit être capable de recevoir et de gérer les messages transmis par des horloges à une et à deux étapes. Une horloge n'est pas nécessaire pour prendre en charge les modes à une et à deux étapes pour la transmission des messages.

Mécanismes de transport requis, autorisés ou interdits

Dans ce profil, les mécanismes de transport autorisés sont les suivants :

• IEEE 802.3/Ethernet et
• OTN

Au moins un des deux mécanismes de transport doit être pris en charge. Pour le transport sur IEEE 802.3/Ethernet, l'adresse de multidiffusion non transférable, 01-80-C2-00-00-0E, et l'adresse de multidiffusion transférable, 01-1B-19-00-00-00, doivent être prises en charge pour la conformité avec ce profil

Messages de monodiffusion/multidiffusion :

Tous les messages sont envoyés en multidiffusion, en utilisant l'une des deux adresses de multidiffusion (01-80-C2-00-00-0E/01-1B-19-00-00-00). Le mode monodiffusion n'est pas autorisé dans cette version du profil.

Meilleures options d'algorithme MasterClock :

Ce profil utilise le BMCA secondaire.

Les paramètres d'horloge suivants sont comparés (dans l'ordre) à partir de chaque noeud disponible pour sélectionner le meilleur MasterClock :

Tableau 1 . Hiérarchie BMCA du profil Telcom

Paramètre	Description
Priorité 1	NON utilisé dans les profils télécom
Clock-class	Mesure de la traçabilité des horloges. Si la fréquence/l'heure de l'horloge principale est traçable à une référence GNSS (A, B meilleur que C)
Précision d'horloge	Quelle est la précision de la sortie de l'horloge du GM par rapport à la référence principale ? par exemple : temps précis à 25 ns près.
Variation OSLV (Offset Scaled Log Variation)	Mesure de la précision d'horloge. La quantité de signal d'horloge varie lorsqu'il n'est pas synchronisé avec une autre source.
Priorité 2	Priorité définie par l'utilisateur sur le noeud MasterClock si tous les paramètres ci-dessus correspondent
Priorité du port local	Priorité par port définie par l'utilisateur sur DUT
identité d'horloge génétiquement modifiée	ID d'horloge de GrandMasterClock utilisé en tant que brise-temps
Étapes supprimées	Chemin le plus court choisi si grandMasterClock est accessible via plusieurs ports (A meilleur que B)

Option de mesure de délai de chemin (demande de délai/réponse de délai) :

Le mécanisme de demande/réponse de délai est utilisé dans ce profil. Le mécanisme peer-delay ne doit pas être utilisé dans ce profil, la méthode delay_req—response doit être utilisée.

Ce profil de télécommunications PTP définit un BMCA alternatif qui permet d'utiliser deux approches principales pour configurer la topologie du réseau de synchronisation de phase/temps :

Établissement automatique de la topologie :

Lors de la configuration des attributs localPriority définis dans la présente recommandation à leur valeur par défaut, la topologie PTP est établie automatiquement par le BMCA secondaire en fonction des messages d'annonce échangés par les horloges PTP. Une arborescence de synchronisation avec les chemins les plus courts vers les T-GM est créée après cette opération. Dans ce mode, lors des événements de défaillance et de la reconfiguration de la topologie, le BMCA secondaire est exécuté à nouveau et génère une nouvelle arborescence de synchronisation. Cette opération BMCA alternative garantit qu'aucune boucle de synchronisation ne sera créée sans intervention manuelle ou analyse préalable du réseau. Le temps de convergence vers la nouvelle topologie PTP dépend de la taille du réseau et de la configuration spécifique des paramètres PTP.

Planification manuelle du réseau : l'utilisation des attributs localPriority définis dans cette recommandation avec des valeurs différentes de leur valeur par défaut permet de construire manuellement la topologie du réseau de synchronisation, de la même manière que les réseaux SDH (Synchronous Digital Hierarchy) sont généralement exploités sur la base du message d'état de synchronisation (SSM). Cette option permet un contrôle total des actions lors des événements de panne et de la reconfiguration de la topologie, en fonction des priorités locales configurées du système. Cependant, une planification réseau minutieuse est requise avant le déploiement afin d'éviter les boucles de synchronisation.

Considérations sur l'utilisation de la priorité2 :

L'attribut PTP priority2 est configurable dans ce profil. Dans certaines circonstances particulières, l'utilisation de l'attribut priority2 peut simplifier la gestion du réseau. Cette section décrit deux cas d'utilisation; d'autres cas possibles sont à étudier plus en détail.

• Cas 1 .

Les opérateurs peuvent configurer l'attribut PTP priority2 pour que toutes les horloges limites de télécommunications (T-BC) soient traçables vers une horloge principale de télécommunications (T-GM) ou traçables vers deux horloges T-GM différentes en même temps.

Par exemple, dans cette image, si tous les autres attributs PTP des deux T-GM sont identiques et que les deux T-GM sont configurés avec la même valeur priority2, chaque T-BC sélectionnera le T-GM ayant le chemin le plus court. Si les deux T-GM sont configurés avec des valeurs de priorité2 différentes, tous les T-BC se synchroniseront sur le T-GM avec la valeur de priorité2 la plus petite.

• Cas 2 .

Les opérateurs peuvent configurer l'attribut PTP priority2 pour empêcher les T-BC d'un réseau en amont de se synchroniser avec les T-BC d'un réseau en aval lorsque le T-GM est en panne.

Par exemple, dans la figure, si tous les autres attributs PTP de tous les T-BC sont identiques et que l'attribut PTP priority2 de tous les T-BC est configuré avec la même valeur, alors quand le T-GM est en panne, les T-BC du réseau en amont peuvent se synchroniser avec les T-BC du réseau en aval, en fonction des valeurs clockIdentity de tous les T-BC. Si les T-BC du réseau en amont sont configurés avec une valeur de priorité2 inférieure à celle des T-BC du réseau en aval, lorsque le T-GM est en panne, les T-BC du réseau en aval se synchronisent avec les T-BC du réseau en amont.

Opérations sur agrégation de liaisons :

Lorsque deux périphériques intégrant des horloges PTP conformes à ce profil sont connectés via un LAG (Link Aggregation), chaque liaison physique doit être accessible directement pour transmettre des messages PTP, en contournant le LAG. Cette méthode évite les asymétries potentielles qui peuvent être présentes lorsque les chemins aller et retour sont fournis sur différentes liaisons appartenant au LAG.

Considérations sur le choix de l'adresse de destination de multidiffusion Ethernet PTP :

Ce profil PTP prend en charge l'adresse de multidiffusion non transférable 01-80-C2-00-00-0E et l'adresse de multidiffusion transférable 01-1B-19-00-00-00 lorsque le mappage PTP est utilisé.

L'adresse de multidiffusion Ethernet à utiliser dépend de la politique de l'opérateur ; d'autres considérations sont fournies ci-après.

La fonction de pontage de couche 2 associée au port PTP d'un T-BC ou T-TC ne doit pas transférer de trame avec l'adresse MAC de destination 01-1B-19-00-00-00 ; cela peut être fait en fournissant correctement cette adresse de multidiffusion dans la base de données de filtrage.

• Option 1 : utilisation de l'adresse de multidiffusion non transférable 01-80-C2-00-00-0E.

Certains opérateurs réseau considèrent que les messages PTP ne doivent jamais être transférés via un équipement réseau non sensible au protocole PTP.

L'utilisation de l'adresse de multidiffusion non transférable 01-80-C2-00-00-0E garantit cette propriété la plupart du temps (des exceptions existent pour certains équipements Ethernet plus anciens).

Par conséquent, dans le cas d'une mauvaise configuration de l'équipement réseau (par exemple, si les fonctions PTP ne sont pas activées dans l'équipement réseau sensible au protocole PTP), l'utilisation de cette adresse de multidiffusion empêche une distribution incorrecte de la synchronisation, puisque les messages PTP seront bloqués par l'équipement réseau non sensible au protocole PTP.

• Option 2 : utilisation de l'adresse de multidiffusion transférable 01-1B-19-00-00-00.

Certains opérateurs réseau considèrent que l’utilisation d’une adresse de multidiffusion transférable est plus flexible et qu’il est préférable de transférer les messages PTP pour maintenir la liaison de synchronisation en fonctionnement au cas où certains équipements ne seraient pas configurés correctement en tant que noeuds non PTP, bien qu’il existe des risques potentiels de dégradation des performances. Le système de gestion du réseau (NMS) détecte facilement l'erreur de configuration et envoie des alarmes.

Cependant, il est possible de bloquer les messages PTP en provisionnant correctement cette adresse de multidiffusion dans la base de données de filtrage de chaque équipement Ethernet.

8275.2

Cette recommandation définit un autre profil PTP pour permettre la distribution de la phase et du temps avec la prise en charge de la temporisation partielle (PTS) à partir du réseau (c'est-à-dire, pas besoin pour chaque périphérique d'exécuter ptp dans le réseau). La principale différence entre la norme 8275.2 et la norme 8275.1 réside dans le fait qu'elle s'exécute sur la monodiffusion IPv4 et que tous les noeuds du réseau n'ont pas besoin d'exécuter le protocole PTP.

Mécanismes de transport :

Dans ce profil, le mécanisme de transport requis est UDP/IPv4.

Messages de monodiffusion :

Tous les messages sont envoyés en monodiffusion.

Dans ce profil de télécommunications, la négociation de monodiffusion est activée par défaut.

SlaveClock démarre la session en suivant la procédure de négociation de message de monodiffusion.

Domaines :

Les ID de domaine de 44 à 63 peuvent être utilisés. L'ID de domaine par défaut est 44.

Meilleures options d'algorithme MasterClock :

Ce profil utilise le BMCA secondaire.

Propriétés Option de mesure du délai de lPath (demande/réponse de délai), établissement automatique de la topologie et Considérations sur l’utilisation de la priorité2 sont identiques au profil de télécommunications 8275.1

Considérations relatives au transport PTP sur IP dans les topologies en anneau :

Lorsque vous utilisez la messagerie PTP sur une couche de transport IP, certains aspects du protocole de couche 3 doivent être pris en compte. La couche PTP transmet les messages à la couche IP avec une adresse IP de destination. La couche IP s’assure ensuite que le message est remis à la destination tant qu’il existe un chemin à travers le réseau de transport IP entre le noeud source et l’adresse de destination. La couche IP comprend des protocoles de routage dynamique qui peuvent adapter le chemin à travers le réseau en fonction des liaisons disponibles entre les routeurs IP. Il peut arriver que le chemin emprunté par la couche transport IP ne soit pas le chemin « attendu » par le planificateur de synchronisation. L’application de certaines restrictions dans la couche transport IP pour contrôler les chemins sous-optimaux pour les messages PTP peut être bénéfique. Cela est probablement le cas dans les topologies en anneau.

En prenant comme exemple la topologie illustrée dans la figure ci-dessous, SlaveClock est configuré pour demander un service de monodiffusion à BC3 et BC4. Après avoir reçu les messages Announce de BC3 et BC4, SlaveClock exécute le BMCA et sélectionne BC4 comme son horloge parent en fonction du fait que les étapes - la valeur supprimée de BC4 est 1, par rapport à une valeur 3 pour BC3. SlaveClock demande alors des messages de synchronisation à BC4.

Si la connexion entre BC4 et R6 est interrompue (voir la figure ci-dessous), BC4 n'est pas atteint par le chemin attendu. Cependant, elle est toujours accessible, car les protocoles de routage conservent la connexion en routant les paquets IP autour de l'anneau. BC4 est conservée comme horloge parente car elle est toujours considérée comme meilleure par le BMCA.

Il est très probable que l'opération souhaitée soit que SlaveClock bascule vers BC3 pour de meilleures performances.

Il existe quelques techniques qui peuvent être employées pour s'assurer que dans le scénario de défaillance identifié ci-dessus, SlaveClock sélectionnera BC3 comme son horloge parent. Ils sont basés sur le blocage des messages IP PTP de BC4 vers SlaveClock si ces messages transitent dans le sens des aiguilles d'une montre autour de l'anneau. La solution est basée sur le blocage des messages PTP uniquement et non du message d’autres protocoles qui pourraient utiliser les mêmes adresses IP.

Option 1. Adresses IP uniques et routes statiques :

Dans certains modèles de déploiement, il peut être possible d'allouer des adresses IP uniques pour l'utilisation du protocole PTP seul. Cela permet ensuite l'utilisation de routes statiques pour contrôler la direction des flux PTP entre les noeuds. BC4 serait configuré de telle sorte que le seul chemin à utiliser pour atteindre 11.x.x.141 (SlaveClock) serait la liaison entre BC4 et R6. En outre, R6 pourrait être configuré de telle sorte que le seul chemin à utiliser pour atteindre 11.y.y.104(BC4) serait la liaison entre R6 et BC4. Si la liaison entre R6 et BC4 échoue, alors il n'y a pas de route disponible pour obtenir les paquets IP entre 11.x.x.141 et 11.y.y.104 donc SlaveClock ne recevra pas Annonces de BC4 et le BMCA sélectionnera BC3 comme horloge parent. Reportez-vous à cette image.

Option 2. Filtres IP

Tous les routeurs prennent en charge un certain niveau de filtrage IP. Des filtres peuvent être utilisés pour protéger le plan de contrôle du routeur contre les messages indésirables. Ils peuvent être utilisés dans ce cas pour contrôler l'acceptation des messages PTP sur un sous-ensemble des interfaces de routage.

Dans ce cas, R6 serait configuré pour protéger SlaveClock des messages PTP empruntant la mauvaise route. Sur l'interface sur R6 faisant face à BC3, un filtre pourrait être appliqué pour autoriser uniquement les messages vers le port UDP 319 ou 320 si l'adresse source correspond à celle du processus PTP sur BC3. Tous les messages provenant de BC4 qui sont reçus sur cette interface seraient abandonnés. Reportez-vous à cette image.

Option 3. Traitement BC de tous les messages PTP

Un BC peut mettre fin à tous les messages PTP reçus dans n'importe lequel de ses ports pour n'importe quel domaine utilisé par le BC. Ensuite, les messages PTP peuvent être abandonnés ou transférés en fonction des décisions prises au sein du processus PTP lui-même. Vous pouvez choisir de supprimer le message si l’adresse de destination du message PTP n’est pas une adresse appartenant au BC ou de le remettre au moteur de transfert pour qu’il soit envoyé à la destination. Ce dernier cas peut être utilisé si le message PTP concerne un domaine différent de celui du BC. Dans ce dernier cas également, l'élément de réseau contenant le BC peut également mettre à jour le champ de correction de tout message d'événement transmis pour compenser l'extraction et le traitement du message PTP, c'est-à-dire prendre en charge la fonction d'horloge transparente de ces messages. L'extraction des messages du plan IP peut être effectuée si le routeur prend en charge le routage de paquets IP basé sur des politiques.

Cet exemple est illustré dans cette image.

Option 4. Utilisation du mécanisme TTL (Time to Live) à partir du transport IP :

Un noeud PTP peut envoyer des paquets PTP avec l'en-tête IP/Transport portant un champ TTL défini sur le nombre minimum de sauts de routage requis pour atteindre le port PTP homologue avec lequel il a un contrat PTP. Dans un réseau PTP-unaware typique ayant des routeurs inconscients entre MasterClock et SlaveClock, si le nombre de routeurs PTP inconscients est supérieur à la valeur TTL du message PTP, le message PTP sera abandonné par l'un des routeurs PTP-unaware. Ceci peut être utilisé pour limiter le nombre de sauts IP traversés par des paquets PTP entre des routeurs adjacents et éviter la communication par des chemins plus longs indésirables.

Ce comportement peut être par port PTP, ou par horloge PTP, et est spécifique à l'implémentation. On suppose que dans une telle topologie en anneau, le routage IP veillera à ce qu'un chemin plus court vers l'horloge principale PTP soit considéré comme une meilleure route que le chemin plus long autour de l'anneau.

Par exemple, si un SlaveClock a un MasterClock directement connecté qui peut également être accessible via un chemin plus long, il peut utiliser la valeur TTL de 1 pour s'assurer que les paquets PTP atteignent le MasterClock uniquement via le chemin directement connecté plutôt que le chemin plus long autour de l'anneau.

Algorithme d'asservissement

Description des modes :

• Mode d'exécution libre :

L'horloge PTP n'a jamais été synchronisée avec une source de temps et n'est pas en cours de synchronisation avec une source de temps.

• Mode acquisition :

L'horloge PTP est en cours de synchronisation avec une source temporelle. La durée et les fonctionnalités de ce mode sont spécifiques à l'implémentation. Ce mode n'est pas requis dans l'implémentation.

• Mode Fréquence/Phase verrouillée :

Verrouillage de phase : l'horloge PTP est synchronisée en phase avec une source temporelle et présente une précision interne acceptable.

Verrouillage de fréquence : l'horloge est synchronisée en fréquence avec une source de temps et se trouve dans une précision interne acceptable.

En ce qui concerne l'état du port PTP défini dans [IEEE 1588], une horloge est en mode Verrouillé si un port PTP est en état ESCLAVE.

• Mode de maintien :

L'horloge PTP n'est plus synchronisée avec une source temporelle et utilise les informations obtenues alors qu'elle était synchronisée précédemment ou que d'autres sources d'informations étaient encore disponibles, pour maintenir les performances dans la spécification souhaitée ou sont incapables de maintenir les performances dans la spécification souhaitée. Le noeud peut compter uniquement sur ses propres installations pour le maintien ou peut utiliser quelque chose comme une entrée de fréquence du réseau pour obtenir un maintien de temps et/ou de phase.

Exemple de configuration pour 8275.1/8275.2 sur NCS 540 (Cisco IOS XR)

Le routeur permet de sélectionner des sources distinctes pour la fréquence et l'heure du jour (ToD). La sélection de fréquence peut être effectuée entre n'importe quelle source de fréquence disponible pour le routeur, telle que BITS, GPS, SyncE ou IEEE 1588 PTP. La sélection ToD se fait entre la source sélectionnée pour la fréquence et PTP, si disponible (sélection ToD à partir de GPS, DTI ou PTP). Il s'agit du mode hybride, dans lequel une source de fréquence physique (BITS ou SyncE) est utilisée pour fournir la synchronisation de fréquence, tandis que le mode PTP est utilisé pour fournir la synchronisation ToD.

SyncE (pour le transfert de fréquence) et ptp (transfert de phase/heure du jour) peuvent être utilisés ensemble sur le réseau tout en déployant 8275.1 pour obtenir de meilleures précisions (appelé mode hybride et seul mode pris en charge par NCS depuis la version 7.3.x)

L'attribut de priorité locale n'est pas transmis dans les messages d'annonce. Cet attribut est utilisé en tant qu'élément de rupture dans l'algorithme de comparaison d'ensembles de données, dans le cas où tous les autres attributs précédents des ensembles de données comparés sont égaux

8275.1:

	Horloge De Délimitation
	Configuration	Explication
ptp	ptp
	Horloge
	domaine 24
	profile g.8275.1 clock-type T-BC	Le profil 8275.1 est utilisé avec le rôle d'horloge pour être l'horloge frontière de télécommunications T-BC
	!
	profile T-BC-MasterClock	Définissez un rôle pour le port ptp.
	adresse-cible de multidiffusion ethernet 01-80-C2-00-00-0E	Une adresse de multidiffusion non transférable est utilisée (facultatif)
	transport ethernet	le transport ethernet est utilisé
	état du port MasterClock-only	L'état du port à utiliser est MasterClock uniquement
	fréquence de synchronisation 16	Les paquets de synchronisation sont envoyés avec une fréquence de paquets par seconde
	fréquence d'annonce 8	Les paquets d'annonce seront envoyés avec une fréquence de paquets par seconde
	delay-request frequency 16	Les paquets Delay_Req seront envoyés avec une fréquence de paquets par seconde
	!
	profile T-BC-SLAVE	Définissez un rôle pour le port ptp.
	adresse-cible de multidiffusion ethernet 01-80-C2-00-00-0E	Une adresse de multidiffusion non transférable est utilisée (facultatif)
	transport ethernet	le transport ethernet est utilisé
	état du port SlaveClock-only	l'état du port à utiliser est SlaveClock uniquement
	fréquence de synchronisation 16	Les paquets de synchronisation sont envoyés avec une fréquence de paquets par seconde
	fréquence d'annonce 8	Les paquets d'annonce seront envoyés avec une fréquence de paquets par seconde
	delay-request frequency 16	Les paquets Delay_Req seront envoyés avec une fréquence de paquets par seconde
	!
	!
	interface TenGigE0/0/0/18	Interface MasterClock. Port connecté à SlaveClock en aval
	ptp	ptp activé pour ce port
	profile T-BC-MasterClock	Le rôle défini par l'utilisateur est appelé sous ce port ptp
	local-priority 120	Attribut localPriority utilisé comme séparateur dans l'algorithme de comparaison d'ensembles de données, dans le cas où tous les autres attributs précédents des ensembles de données comparés sont égaux
	!
	!
	interface TenGigE0/0/0/19	Interface SlaveClock. Port connecté à l'horloge principale en amont
	ptp	ptp activé pour ce port
	profile T-BC-SLAVE	Le rôle défini par l'utilisateur est appelé sous ce port ptp
	local-priority 130
	!
	!
SyncE	synchronisation de fréquence	Favoriser l'informatique mondiale
	option 1 de l'UIT-T de qualité	QL de l'horloge reçue est conforme à l'option 1 de l'UIT-T
	consigner les modifications de sélection
	!
	interface TenGigE0/0/0/19	Interface SlaveClock. Port connecté à l'horloge principale en amont
	synchronisation de fréquence	Activer syncE sur l'interface
	entrée de sélection	Interface à l'état SlaveClock pour SyncE
	priority (priorité) 15	significatif localement. gérer la sélection de l'horloge en modifiant la priorité des sources d'horloge
	attente de restauration 0	La durée d'attente du routeur avant d'inclure une source d'horloge Ethernet synchrone nouvellement active dans la sélection d'horloge. La valeur par défaut est de 300 secondes
	!
	interface TenGigE0/0/0/18	Interface MasterClock. Port connecté à SlaveClock en aval
	synchronisation de fréquence	Activer syncE sur l'interface
	attente de restauration 0	La durée d'attente du routeur avant d'inclure une source d'horloge Ethernet synchrone nouvellement active dans la sélection d'horloge. La valeur par défaut est de 300 secondes
	HorlogeGrandMaître
	Configuration	Explication
ptp	ptp	Activation globale de ptp
	horloge
	domaine 24
	profile g.8275.1 clock-type T-GM	Le profil 8275.1 est utilisé avec le rôle d'horloge pour être T-GM telecom grand MasterClock
	!
	profile T-MasterClock	Définissez un rôle pour le port ptp.
	adresse-cible de multidiffusion ethernet 01-80-C2-00-00-0E	Une adresse de multidiffusion non transférable est utilisée (facultatif)
	transport ethernet	le transport ethernet est utilisé
	état du port MasterClock-only	L'état du port à utiliser est MasterClock uniquement
	fréquence de synchronisation 16	Les paquets de synchronisation sont envoyés avec une fréquence de paquets par seconde
	fréquence d'annonce 8	Les paquets d'annonce seront envoyés avec une fréquence de paquets par seconde
	delay-request frequency 16	Les paquets Delay_Req seront envoyés avec une fréquence de paquets par seconde
	!
	!
	interface TenGigE0/0/0/18	Interface MasterClock. Port connecté à SlaveClock en aval
	ptp	ptp activé pour ce port
	profile T-MasterClock	Le rôle défini par l'utilisateur est appelé sous ce port ptp
	local-priority 120	Attribut localPriority utilisé comme séparateur dans l'algorithme de comparaison d'ensembles de données, dans le cas où tous les autres attributs précédents des ensembles de données comparés sont égaux
	!
	!
	!
SyncE	synchronisation de fréquence	Favoriser l'informatique mondiale
	option 1 de l'UIT-T de qualité	Pour configurer les options de niveau de qualité (QL) de l'UIT-T. L'option 1 de l'UIT-T est également la valeur par défaut
	consigner les modifications de sélection	activer la journalisation
	!
	interface TenGigE0/0/0/18	Interface MasterClock. Port connecté à SlaveClock en aval
	synchronisation de fréquence	Activer syncE sur l'interface
	attente de restauration 0	La durée d'attente du routeur avant d'inclure une source d'horloge Ethernet synchrone nouvellement active dans la sélection d'horloge. La valeur par défaut est de 300 secondes
	HorlogeEsclave
	Configuration	Explication
ptp	ptp	Activation globale de ptp
	horloge
	domaine 24
	profile g.8275.1 clock-type T-TSC	Le profil 8275.1 est utilisé avec le rôle d'horloge T-TSC telecom SlaveClock
	!
	profile T-SLAVE	Définissez un rôle pour le port ptp.
	adresse-cible de multidiffusion ethernet 01-80-C2-00-00-0E	Une adresse de multidiffusion non transférable est utilisée (facultatif)
	transport ethernet	le transport ethernet est utilisé
	état du port SlaveClock-only	l'état du port à utiliser est SlaveClock uniquement
	fréquence de synchronisation 16	Les paquets de synchronisation sont envoyés avec une fréquence de paquets par seconde
	fréquence d'annonce 8	Les paquets d'annonce seront envoyés avec une fréquence de paquets par seconde
	delay-request frequency 16	Les paquets Delay_Req seront envoyés avec une fréquence de paquets par seconde
	!
	!
	interface TenGigE0/0/0/19	Interface SlaveClock. Port connecté à l'horloge principale en amont
	ptp	ptp activé pour ce port
	profile T-SLAVE	Le rôle défini par l'utilisateur est appelé sous ce port ptp
	local-priority 120	Attribut localPriority utilisé comme séparateur dans l'algorithme de comparaison d'ensembles de données, dans le cas où tous les autres attributs précédents des ensembles de données comparés sont égaux
	!
	!
	!
SyncE	synchronisation de fréquence	Favoriser l'informatique mondiale
	option 1 de l'UIT-T de qualité	Pour configurer les options de niveau de qualité (QL) de l'UIT-T. L'option 1 de l'UIT-T est également la valeur par défaut
	consigner les modifications de sélection	activer la journalisation
	!
	interface TenGigE0/0/0/19	Interface SlaveClock. Port connecté à l'horloge principale en amont
	synchronisation de fréquence	Activer syncE sur l'interface
	entrée de sélection	Interface à l'état SlaveClock pour SyncE
	priority (priorité) 15	significatif localement. gérer la sélection de l'horloge en modifiant la priorité des sources d'horloge
	attente de restauration 0	La durée d'attente du routeur avant d'inclure une source d'horloge Ethernet synchrone nouvellement active dans la sélection d'horloge. La valeur par défaut est de 300 secondes
	!

8275.2:

	Horloge De Délimitation
	Configuration	Explication
ptp	ptp
	horloge
	domaine 44
	profile g.8275.2 clock-type T-BC	Le profil 8275.2 est utilisé avec le rôle d'horloge pour être l'horloge frontière de télécommunications T-BC
	!
	profile T-BC-MasterClock	Définissez un rôle pour le port ptp.
	adresse-cible de multidiffusion ethernet 01-80-C2-00-00-0E	Une adresse de multidiffusion non transférable est utilisée (facultatif)
	transport ipv4	le transport ethernet est utilisé
	état du port MasterClock-only	L'état du port à utiliser est MasterClock uniquement
	fréquence de synchronisation 16	Les paquets de synchronisation sont envoyés avec une fréquence de paquets par seconde
	fréquence d'annonce 8	Les paquets d'annonce seront envoyés avec une fréquence de paquets par seconde
	delay-request frequency 16	Les paquets Delay_Req seront envoyés avec une fréquence de paquets par seconde
	!
	profile T-BC-SLAVE	Définissez un rôle pour le port ptp.
	adresse-cible de multidiffusion ethernet 01-80-C2-00-00-0E	Une adresse de multidiffusion non transférable est utilisée (facultatif)
	transport ipv4	le transport ethernet est utilisé
	état du port SlaveClock-only	l'état du port à utiliser est SlaveClock uniquement
	fréquence de synchronisation 16	Les paquets de synchronisation sont envoyés avec une fréquence de paquets par seconde
	fréquence d'annonce 8	Les paquets d'annonce seront envoyés avec une fréquence de paquets par seconde
	delay-request frequency 16	Les paquets Delay_Req seront envoyés avec une fréquence de paquets par seconde
	!
	!
	interface TenGigE0/0/0/18	Interface MasterClock. Port connecté à SlaveClock en aval
	ptp	ptp activé pour ce port
	profile T-BC-MasterClock	Le rôle défini par l'utilisateur est appelé sous ce port ptp
	local-priority 120	Attribut localPriority utilisé comme séparateur dans l'algorithme de comparaison d'ensembles de données, dans le cas où tous les autres attributs précédents des ensembles de données comparés sont égaux
	!
	!
	interface TenGigE0/0/0/19	Interface SlaveClock. Port connecté à l'horloge principale en amont
	adresse ip 10.0.0.1 255.255.255.252
	ptp	ptp activé pour ce port
	profile T-BC-SLAVE	Le rôle défini par l'utilisateur est appelé sous ce port ptp
	local-priority 130
	MasterClock ipv4 10.0.0.2 255.255.255.252	Mentionnez explicitement l'adresse IP MasterClock
	!
	HorlogeGrandMaître
	Configuration	Explication
ptp	ptp	Activation globale de ptp
	horloge
	domaine 44
	profile g.8275.2 clock-type T-GM	Le profil 8275.1 est utilisé avec le rôle d'horloge pour être T-GM telecom grand MasterClock
	!
	profile T-MasterClock	Définissez un rôle pour le port ptp.
	adresse-cible de multidiffusion ethernet 01-80-C2-00-00-0E	Une adresse de multidiffusion non transférable est utilisée (facultatif)
	transport ipv4	le transport ethernet est utilisé
	état du port MasterClock-only	L'état du port à utiliser est MasterClock uniquement
	fréquence de synchronisation 16	Les paquets de synchronisation sont envoyés avec une fréquence de paquets par seconde
	fréquence d'annonce 8	Les paquets d'annonce seront envoyés avec une fréquence de paquets par seconde
	delay-request frequency 16	Les paquets Delay_Req seront envoyés avec une fréquence de paquets par seconde
	!
	!
	interface TenGigE0/0/0/18	Interface MasterClock. Port connecté à SlaveClock en aval
	ptp	ptp activé pour ce port
	profile T-MasterClock	Le rôle défini par l'utilisateur est appelé sous ce port ptp
	local-priority 120	Attribut localPriority utilisé comme séparateur dans l'algorithme de comparaison d'ensembles de données, dans le cas où tous les autres attributs précédents des ensembles de données comparés sont égaux
	!
	!
	!
	HorlogeEsclave
	Configuration	Explication
ptp	ptp	Activation globale de ptp
	horloge
	domaine 44
	profile g.8275.2 clock-type T-TSC	Le profil 8275.1 est utilisé avec le rôle d'horloge T-TSC telecom SlaveClock
	!
	profile T-SLAVE	Définissez un rôle pour le port ptp.
	adresse-cible de multidiffusion ethernet 01-80-C2-00-00-0E	Une adresse de multidiffusion non transférable est utilisée (facultatif)
	transport ipv4	le transport ethernet est utilisé
	état du port SlaveClock-only	l'état du port à utiliser est SlaveClock uniquement
	fréquence de synchronisation 16	Les paquets de synchronisation sont envoyés avec une fréquence de paquets par seconde
	fréquence d'annonce 8	Les paquets d'annonce seront envoyés avec une fréquence de paquets par seconde
	delay-request frequency 16	Les paquets Delay_Req seront envoyés avec une fréquence de paquets par seconde
	!
	!
	interface TenGigE0/0/0/19	Interface SlaveClock. Port connecté à l'horloge principale en amont
	adresse ip 10.0.0.1 255.255.255.252
	ptp	ptp activé pour ce port
	profile T-SLAVE	Le rôle défini par l'utilisateur est appelé sous ce port ptp
	local-priority 120	Attribut localPriority utilisé comme séparateur dans l'algorithme de comparaison d'ensembles de données, dans le cas où tous les autres attributs précédents des ensembles de données comparés sont égaux
	MasterClock ipv4 10.0.0.2 255.255.255.252	mentionner explicitement l'adresse IP MasterClock
	!
	!
	!

Si vous ne recevez pas de paquets ESMC sur l'interface ou si SyncE n'est pas configuré à l'extrémité du port, mais que vous souhaitez quand même activer syncE. Vous pouvez le faire en définissant de manière statique la valeur QL sur l'interface et en désactivant SSM.

SyncE	synchronisation de fréquence
	option 1 de l'UIT-T de qualité
	consigner les modifications de sélection
	!
	interface TenGigE0/0/0/19
	synchronisation de fréquence
	ssm disable
	qualité recevoir exact itu-t option 1 PRC
	entrée de sélection
	priority (priorité) 15
	attente de restauration 0
	!

Afin d'utiliser le mode hybride avec 8275.2, utilisez « physical-layer-frequency » sous l'interface. Cela active SyncE pour la fréquence et ptp pour la phase.

Pour activer le mode hybride avec 8275.2, la « fréquence de couche physique » doit être configurée sous global ptp.

ptp

horloge

domaine 44

profile g.8275.2 clock-type T-BC

!

profile 82752

transport ipv4

fréquence de synchronisation 16

fréquence d'annonce 8

delay-request frequency 16

!

fréquence de couche physique

journal de bord

événements d'asservissement

!

!

Exemple de topologie 8275.1 :

Périphérique A :

ptp

 clock

  domain 24

  profile g.8275.1 clock-type T-BC

 !

 profile T-BC-SLAVE

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ethernet

  port state SlaveClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

 profile T-BC-MasterClock

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ethernet

  port state MasterClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

!

frequency synchronization

 quality itu-t option 1

 log selection changes

!

interface TenGigE0/0/0/23

 description ***to PTP GM***

 ptp

  profile T-BC-SLAVE

 !

 frequency synchronization

  selection input

  priority 10

  wait-to-restore 0

!

!



interface TenGigE0/0/0/19

ptp

  profile T-BC-MasterClock

 !

 frequency synchronization

  wait-to-restore 0

 !

!

Périphérique B :

ptp

 clock

  domain 24

  profile g.8275.1 clock-type T-BC

 !

 profile T-BC-SLAVE

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ethernet

  port state SlaveClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

 profile T-BC-MasterClock

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ethernet

  port state MasterClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

!

interface TenGigE0/0/0/23

 ptp

  profile T-BC-MasterClock

 !

!

interface TenGigE0/0/0/19

 ptp

  profile T-BC-SLAVE

 !

 frequency synchronization

  selection input

 !

!

Exemple de topologie 8275.2 :

Périphérique A :

ptp

 clock

  domain 44

  profile g.8275.2 clock-type T-BC

 !

 profile T-BC-SLAVE

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ipv4

  port state SlaveClock-only

  sync frequency 16

  clock operation one-step

  announce frequency 8

  delay-request frequency 16

 !

 profile T-BC-MasterClock

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ipv4

  port state MasterClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

!

frequency synchronization

 quality itu-t option 1

 log selection changes

!

interface TenGigE0/0/0/23

 description ***to PTP GM***

 ptp

  profile T-BC-SLAVE

 !

 frequency synchronization

  selection input

  priority 10

  wait-to-restore 0

!

!

interface TenGigE0/0/0/19

ip address 10.0.0.1 255.255.255.252

 ptp

  profile T-BC-MasterClock

  MasterClock ipv4 10.0.0.2 255.255.255.252

 !

 frequency synchronization

  wait-to-restore 0

 !

!

Périphérique B :

ptp

 clock

  domain 44

  profile g.8275.2 clock-type T-BC

 !

 profile T-BC-SLAVE

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ipv4

  port state SlaveClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

 profile T-BC-MasterClock

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ipv4

  port state MasterClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

!

interface TenGigE0/0/0/19

  mtu 9216

 ptp

  profile T-BC-SLAVE

 !

 frequency synchronization

  selection input

 !

!

Dépannage du protocole PTP

Certaines commandes show et décrivent leurs résultats.

1. L'état d'asservissement à la fin de l'algorithme d'asservissement doit être Phase_Locked. Vous pouvez voir le pour le flux d'état d'asservissement. Si le mode d'asservissement est Hybride, le flux SyncE doit également être pris en charge car le verrouillage de phase se produit uniquement après Freq_Lock. Si le périphérique PTP en cours d'exécution est un MasterClock ordinaire, le résultat ci-dessus peut ne pas être valide car l'algorithme Servo ne fonctionnera pas et il n'a pas besoin d'obtenir la synchronisation phase/fréquence d'une autre source MasterClock.

L'état du périphérique ne passe pas à LOCK (VERROUILLAGE) à moins que le décalage ne soit dans une plage acceptable. Cochez également la case « Offset from MasterClock ».

État du périphérique :

FREE-RUN/HOLDOVER : non verrouillé sur une source d'horloge. 
FREQ_LOCKED : Fréquence synchronisée avec MasterClock

PHASE_LOCKED : Fréquence et phase synchronisées sur l'horloge principale

Mode servo :

Hybride : utilisez SyncE pour la synchronisation de fréquence. Le protocole PTP est utilisé uniquement pour la synchronisation de phase.

Par défaut : utilisez PTP pour synchroniser la fréquence et la phase

Différence de temps observée par l'algorithme d'asservissement b/w SlaveClock et MasterClock.

Compteurs d’horodatages extraits des paquets PTP. Devrait continuer à augmenter.

Derniers horodatages T1/T2/T3/T4 (sec.nanosec) extraits des paquets PTP. Doit être proche l'un de l'autre et augmenter uniformément.

T1/T4 : envoyé par l'horloge principale, T2/T3 : calculé à l'horloge esclave

Décalage Calculé sur la base des horodatages PTP.

Réglages grossiers (setTime, stepTime) et fins (adjustFreq) effectués par un servo pour s'aligner sur le MasterClock.

3. show ptp interfaces brief indique l’état du port de sortie. Il doit s'agir de l'état MasterClock/SlaveClock.

4. Les abandons de paquets par ptp doivent être significativement faibles.

5. Vérifiez la raison de l’abandon du paquet :

6. Les paquets n’atteignent pas PTP.

Les paquets atteignent-ils NPU ?

NCS (DNX) platforms: show controllers npu stats traps-all instance all location 0/0/CPU0  | inc 1588

RxTrap1588                                    0    71   0x47        32040   7148566              0

ASR9000 platform: show controller np counters <np> location 0/0/cpu0 | inc PTP

Check for PTP_ETHERNET / PTP_IPV4 counters

Packet drops at NPU (not specific to PTP)

NCS (DNX) platforms: show controllers fia diagshell <np> "diag counters g" location 0/0/cpu0

Shows Rx/TX path statistics along with any drops happening in the NPU 

ASR9000 platform: show drops all location <LC>

Vérifier les abandons au SPP :

show spp node-counters location 0/0/cpu0    

# Check for any drop-counters incrementing

NCS (DNX) platforms: show spp trace platform common error last 20 location 0/0/cpu0

Dec 10 02:29:38.322 spp/fretta/err 0/0/CPU0 t2902 FRETTA SPP classify RX: 
Failed in dpa_punt_mapper; ssp: 0x1e, inlif: 0x2000, rif: 0x11; 
trap_code:FLP_IEEE_1588_PREFIX punt_reason:PTP-PKT pkt_type:L2_LOCALSWITCH rc: 
'ixdb' detected the 'fatal' condition 'Not found in database': No such file or directory

ASR9000 platforms:

SPP punt path is simpler in ASR9000 with no risk of a lookup failure.

Drops not expected during packet classification.

7. show ptp packet-counters <interface-id> indique le flux de paquets. Assurez-vous que le paramètre syncàDelay_RequestDelay_Resp est suivi (et Follow_Up s'il s'agit d'une horloge à 2 pas).

8. Vérifiez l'indicateur (S) de l'interface sélectionnée.

9. Vérifiez la liste de contrôle d'accès reçue. Sur l'interface sélectionnée, le QLsnd sera DNU afin d'empêcher les boucles. Pour modifier votre préférence d'interface, vous pouvez modifier l'attribut priority qui est 100 par défaut.

10. Assurez-vous que l'option « Output Driven by » correspond à l'interface SyncE sélectionnée.

11. Le résultat show ptp foreign-MasterClocks brief est la liste des périphériques ptp participant au BMCA pour devenir des horloges maîtres. Cochez les indicateurs correspondants pour afficher l'horloge maître sélectionnée. Vous pouvez voir les messages d'annonce reçus de ces ports via show ptp packet-counters <interface-id>. Le périphérique doté des meilleurs attributs remportera le BMCA. Si plusieurs ports ont les mêmes attributs, la priorité locale sera le dernier point de rupture. Cependant, l'établissement automatique de la topologie est également possible avec ptp sans utiliser la priorité locale.

12. Ptp ne sélectionne pas l'horloge principale (BMCA) souhaitée.

Vérifier l’horloge annoncée par le noeud distant :

show ptp foreign-MasterClocks 

Interface TenGigE0/9/0/2 (PTP port number 1)

  IPv4, Address X.X.X.X, Unicast

    Configured priority: None (128)

    Configured clock class: None

    Configured delay asymmetry: None

    Announce granted:   every 16 seconds,  1000 seconds

    Sync granted:       every 16 seconds,  1000 seconds

    Delay-resp granted: 64 per-second,     1000 seconds

    Qualified for 4 hours, 50 minutes, 6 seconds

    Clock ID: 1

    Received clock properties:

      Domain: 44, Priority1: 128, Priority2: 128, Class: 6

      Accuracy: 0x21, Offset scaled log variance: 0x4e5d

      Steps-removed: 1, Time source: Atomic, Timescale: PTP

      Frequency-traceable, Time-traceable

      Current UTC offset: 38 seconds (valid)

    Parent properties:

      Clock ID: 1

      Port number: 1

Liste des horloges maîtres qualifiées et sélectionnées :

show ptp foreign-MasterClocks brief 

M=Multicast,X=Mixed-mode,Q=Qualified,D=QL-DNU,

GM=GrandMasterClock,LA=PTSF_lossAnnounce,LS=PTSF_lossSync

Interface         Transport Address                   Cfg-Pri  Pri1   State

----------------------------------------------------------------------------

Te0/0/0/12        Ethernet  008a.9691.3830            None     128    M,Q,GM

Vérifiez l'horloge annoncée à l'horloge principale :

show ptp advertised-clock

Clock ID: 8a96fffe9138d8

Clock properties:

  Domain: 24, Priority1: 128, Priority2: 128, Class: 6

  Accuracy: 0xfe, Offset scaled log variance: 0xffff

  Time Source: Internal (configured, overrides Internal)

  Timescale: PTP (configured, overrides PTP)

  No frequency or time traceability

  Current UTC offset: 0 seconds

13. Ptp ne se synchronise pas avec MasterClock :

•Intended PTP MasterClock selected.

•PTP session established

•But not able to synchronize with the MasterClock

show ptp interface brief

Intf                    Port              Port            Line

Name              Number       State          Encap       State         Mechanism

--------------------------------------------------------------------------------

Te0/0/0/12        1            Uncalibrated Ethernet   up            1-step DRRM


OR occasional PTP flap in the field

Jul 31 09:29:43.114 UTC: ptp_ctrlr[1086]: %PLATFORM-PTP-6-SERVO_EVENTS : PTP Servo state transition from state PHASE_LOCKED to state HOLDOVER 

Jul 31 09:30:23.116 UTC: ptp_ctrlr[1086]: %PLATFORM-PTP-6-SERVO_EVENTS : PTP Servo state transition from state HOLDOVER to state FREQ_LOCKED 

ul 31 09:35:28.134 UTC: ptp_ctrlr[1086]: %PLATFORM-PTP-6-SERVO_EVENTS : PTP Servo state transition from state FREQ_LOCKED to state PHASE_LOCKED

14. Vérifier si le protocole PTP est défaillant en raison d’une perte de paquets :

show ptp trace last 100 location 0/rp0/cpu0

Aug  1 02:35:01.616 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Removed clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0) from BMC list

Aug  1 02:35:01.616 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Updated checkpoint record for clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0): Checkpoint ID 0x40002f60

Aug  1 02:35:01.616 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Inserted clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0) into BMC list at position 0

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Comms] Received BMC message from node 0/0/CPU0. Comms is active

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Removed clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0) from BMC list

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] GrandMasterClock removed, local clock better than foreign MasterClock(s)

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Leap Seconds] GrandMasterClock lost

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Platform] Stopping servo

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] BMC servo stopped, BMC servo not synced

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [Comms] Started grandMasterClock message damping timer

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Platform] Sending SlaveClock update to platform. No grandMasterClock available

Aug  1 02:35:46.059 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Received clock update from the platform. Clock active, not using PTP for frequency, using PTP for time. Current local clock is not a primary ref, sync state is 'Sync' and QL is 'Opt-I/PRC'

15. Vérifiez le résultat de show ptp configuration-errors pour toute erreur de configuration.

Exemples de captures de paquets des messages Sync, Announce, Delay_Req et Delay_Resp

La capture du message d'annonce (8275.1) montre les caractéristiques de l'horloge transmise :

La capture du message Sync affiche la génération de l'horodatage (une étape).

Informations connexes

• https://www.itu.int/rec/T-REC-G.8275.1/en
• https://www.itu.int/rec/T-REC-G.8275.2/en
• Norme IEEE pour 1588v2
• https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/sysman/configuration/guide/b-sysman-cg-53xasr9k/b-sysman-cg-53xasr9k_chapter_01100.html
• Assistance et documentation techniques - Cisco Systems