Recommandations de conception PTP pour les réseaux R-PHY
Contenu
Introduction
Ce document décrit le protocole PTP (Precision Time Protocol) utilisé dans les réseaux câblés avec les réseaux cBR-8 et Remote PHY (R-PHY). L'objectif est de donner une compréhension globale du protocole et de la façon de le configurer dans les déploiements cBR-8 et RPHY.
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- R-PHY.
- CCAP (Converged Cable Access Platform) cBR-8.
Components Used
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- cBR-8 exécute la version 16.6.1 ou ultérieure.
- Périphérique Cisco 1x2 Remote PHY (RPD).
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Fond
Afin d'accorder aux modems les tranches de temps (mini-lots) à transmettre sur un canal en amont, le CCAP mappe les affectations de mini-lot en amont au moyen de messages MAP (bandwidth allocation map). Ces messages MAP sont envoyés en aval et reçus par tous les modems.
Les modems examinent ces messages pour déterminer quels mini-lots sont attribués à quels modems et lesquels sont destinés à des activités basées sur le conflit. Un modem ne transmet le trafic que sur un mini-lot qui lui est attribué (ou sur un logement de contention si vous effectuez une demande de bande passante ou une autre activité de maintenance de station).
Les messages MAP du CCAP allouent environ 2 millisecondes (ms) de temps. Le protocole LLD (Low Latency DOCSIS) offre des options pour réduire cette valeur en dessous de 2 ms.
Il est important que le CCAP et chaque modem aient le même concept de temps, afin d'éviter les chevauchements.
Le CCAP doit s'assurer qu'il n'affecte pas un créneau horaire à un modem trop rapidement à la suite d'une demande, pour éviter que le modem n'ait pas le temps de recevoir le message MAP et de le traiter, et qu'il manque la possibilité d'utiliser ce mini-lot.
Pour éviter cette situation, le CCAP utilise un compteur d'avance MAP, où il ne planifie pas le trafic d'un modem avant un point ultérieur au compteur d'avance MAP.
L'élément de synchronisation de DOCSIS nécessaire pour la planification en amont est toujours présent dans R-PHY. Afin de relier les RPD au CCAP, un CIN (Converged Interconnect Network) est utilisé, basé sur IP, et peut être dédié à l'accès par câble ou partagé par d'autres applications.
Le coeur CCAP gère la planification et la génération en amont des messages MAP. Toutefois, les signaux en aval et en amont sont maintenant émis et terminés physiquement sur la DRE, de sorte que la DRE doit avoir le même concept de temps que le noyau du PAIC.
La spécification de l'interface de temporisation DOCSIS distante (R-DTI) est la spécification de CableLabs qui détaille comment cette synchronisation a lieu. Pour les réseaux Ethernet, le protocole PTP est utilisé pour atteindre ce délai.
Dans la mise en oeuvre actuelle de Cisco, le cBR-8 et le RPD agissent comme un périphérique esclave à une horloge maître PTP.
Protocole PTP (Precision Time Protocol)
Introduction
PTP permet à une horloge esclave de déterminer son décalage horaire à partir d'une horloge maître (différence d'heure entre les horloges), ainsi que le délai de propagation dans le réseau de transport entre les deux horloges.
Les périphériques maître et esclave échangent des messages qui incluent des horodatages avant que l'esclave n'exécute un algorithme pour déterminer ces valeurs.
Les formules de ce calcul supposent une connexion symétrique entre les deux horloges.
Les connexions non symétriques telles que Ethernet Passive Optical Network (EPON) sont répertoriées dans la spécification R-DTI pour utilisation comme CIN, mais dépendent d'une méthode de synchronisation différente, actuellement non prise en charge par Cisco.
La DRE doit atteindre l'horloge principale via le CIN. Le routeur cBR-8 peut accéder à l'horloge principale via des interfaces WAN (Wide Area Network) sur la carte d'interface physique (PIC) du superviseur ou via des interfaces DPIC (Digital PIC) sur la carte de ligne par câble (l'option DPIC a été ajoutée dans la version 16.8.1). Il est recommandé que la DRE ne passe pas par le cBR-8 pour accéder à l'horloge principale.
Le RPD et le cBR-8 ne peuvent fonctionner que comme des horloges esclaves dans le logiciel actuel, bien que la feuille de route du cBR-8 ajoute la prise en charge de cette horloge principale et limite.
Cela signifie que les problèmes de stabilité de l'horloge PTP affectent tous les modems d'un châssis, même ceux des cartes de ligne CCAP intégré (I-CCAP), lorsque vous utilisez un mélange de cartes dans un châssis.
Protocol
PTP est défini sous la norme IEEE 1588-2008.
Les spécifications complètes sont disponibles ici : 1588-2008 - Norme IEEE pour un protocole de synchronisation d'horloge de précision pour les systèmes de mesure et de contrôle en réseau.
Le protocole PTP permet de distribuer le temps et la fréquence via un réseau :
- Heure (synchronisation) : synchronise le temps entre les périphériques d’un réseau.
- Fréquence (syntonisation) : synchronise la fréquence.
Le protocole PTP utilise la multidiffusion ou la monodiffusion et les ports UDP 319 (pour les événements) et UDP 320 (pour les messages généraux)
Sur la mise en oeuvre du CMTS, le protocole PTP utilise la monodiffusion IPv4.
Le protocole crée une relation maître-esclave entre une horloge maître et les périphériques clients via le réseau. La façon dont PTP choisit une horloge à distribuer dans un réseau consiste à utiliser un algorithme appelé Best Master Clock Algorithm (BCMA).
L’algorithme détermine la meilleure horloge d’un réseau avec les propriétés suivantes :
- Identificateur (numéro, construit à partir de l'adresse MAC du périphérique, ressemble généralement au format EUI-64 (xxxx:xxFF:FExx:xxxx).
- Qualité.
- clockPrécision : Détermine la précision de l'horloge.Plus la valeur est faible, mieux c'est (plus la précision est grande).
Value (hex) Specification
00-1F Reserved
20 The time is accurate to within 25 ns
21 The time is accurate to within 100 ns
22 The time is accurate to within 250 ns
23 The time is accurate to within 1 µs
24 The time is accurate to within 2.5 µs
25 The time is accurate to within 10 µs
26 The time is accurate to within 25 µs
27 The time is accurate to within 100 µs
28 The time is accurate to within 250 µs
29 The time is accurate to within 1 ms
2A The time is accurate to within 2.5 ms
2B The time is accurate to within 10 ms
2C The time is accurate to within 25 ms
2D The time is accurate to within 100 ms
2E The time is accurate to within 250 ms
2F The time is accurate to within 1 s
30 The time is accurate to within 10 s
31 The time is accurate to >10 s
32–7F Reserved
80–FD For use by alternate PTP profiles
FE Unknown
FF Reserved
-
clockClass : Reflète la traçabilité de l'heure et de la fréquence distribuées par l'horloge GrandMaster.
Les classes d'horloge sont définies par les spécifications IEEE 1588-2008 en tant que telles :
clockClass (décimal)
0 Reserved to enable compatibility with future versions.
1–5 Reserved.
6 Shall designate a clock that is synchronized to a primary reference time source. The timescale distributed shall be PTP. A clockClass 6 clock shall not be a slave to another clock in the domain.
7 Shall designate a clock that has previously been designated as clockClass 6 but that has lost the ability to synchronize to a primary reference time source and is in holdover mode and within holdover specifications. The timescale distributed shall be PTP. A clockClass 7 clock shall not be a slave to another clock in the domain.
8 Reserved.
9–10 Reserved to enable compatibility with future versions.
11–12 Reserved.
13 Shall designate a clock that is synchronized to an application-specific source of time. The timescale distributed shall be ARB. A clockClass 13 clock shall not be a slave to another clock in the domain.
14 Shall designate a clock that has previously been designated as clockClass 13 but that has lost the ability to synchronize to an application-specific source of time and is in holdover mode and within holdover specifications. The timescale distributed shall be ARB. A clockClass 14 clock shall not be a slave to another clock in the domain.
15–51 Reserved.
52 Degradation alternative A for a clock of clockClass 7 that is not within holdover specification. A clock of clockClass 52 shall not be a slave to another clock in the domain.
53–57 Reserved.
58 Degradation alternative A for a clock of clockClass 14 that is not within holdover specification. A clock of clockClass 58 shall not be a slave to another clock in the domain.
59–67 Reserved.
68–122 For use by alternate PTP profiles.
123–127 Reserved.
128–132 Reserved.
133–170 For use by alternate PTP profiles.
171–186 Reserved.
187 Degradation alternative B for a clock of clockClass 7 that is not within holdover specification. A clock of clockClass 187 may be a slave to another clock in the domain.
188–192 Reserved.
193 Degradation alternative B for a clock of clockClass 14 that is not within holdover specification. A clock of clockClass 193 may be a slave to another clock in the domain.
194–215 Reserved.
216–232 For use by alternate PTP profiles.
233–247 Reserved.
248 Default. This clockClass shall be used if none of the other clockClass definitions apply.
249–250 Reserved.
251 Reserved for version 1 compatibility; see Clause 18.
252–254 Reserved.
255 Shall be the clockClass of a slave-only clock; see 9.2.2.
- Priorité : valeur attribuée par l'administrateur (entre 0 et 255)
- Variance - La stabilité estimée de l'horloge
Processus D'Échange D'Horodatage Master Et Slave
- Le maître envoie un message Sync à l'esclave et prend note de l'heure (t1) à laquelle il a été envoyé.
- L'esclave reçoit le message Sync et note l'heure de réception (t2).
- Le maître transmet à l'esclave l'horodatage t1 ; il incorpore l'horodatage t1 dans un message de suivi.
- L'esclave envoie un message Delay_Req au maître et note l'heure (t3) à laquelle il a été envoyé.
- Le maître reçoit le message Delay_Req et note l'heure de réception (t4).
- Le maître transmet à l'esclave l'horodatage t4 ; il l'intègre dans un message Delay_Resp.
Ce processus est répété plusieurs fois par seconde (généralement 16 à 32 fois par seconde) afin d'assurer une adaptation rapide en cas de petits décalages.
Horloge GrandMaster
Le GrandMaster communique avec les esclaves qui ont établi des sessions avec le grand maître afin d'échanger les informations de synchronisation (Time) et de synchronisation avec ces esclaves. en théorie, un GrandMaster doit être connecté à un PRTC (Prime Reference Time clock), tel un GPS via une antenne GPS, de cette façon, si un GrandMaster tombe en panne et un autre GrandMaster prend le relais, puisque tous deux utilisent la même référence temporelle, les esclaves continuent à utiliser la même référence temporelle. Si vous n'utilisez pas de code PRTC, la défaillance d'une horloge GrandMaster entraîne la modification de la référence temporelle par les esclaves, ce qui entraîne, dans les scénarios CMTS, la mise hors ligne des modems.
Horloge esclave
L'esclave initie la connexion à l'horloge GrandMaster. L'esclave et le maître échangent leurs paramètres de configuration et d'horloge afin de commencer la négociation. Dans ce cas, cBR-8 et RPD sont tous deux esclaves d'un PTP GrandMaster externe.
Horloge de limite
L’horloge de frontière synchronise deux segments de réseau ensemble. Agit comme esclave à une horloge Grand Master (GM) sur le segment 1, puis agit comme horloge GM sur le segment 2. Les horloges non limitrophes sont appelées horloges ordinaires.
Classes d'horloge
Les classes d'horloge sont l'une des valeurs utilisées lors de la négociation pour déterminer quelle horloge, dans un réseau avec plusieurs horloges, est la plus précise.
Les classes d'horloge sont définies par la norme IEEE 1588-2008.
États de l'horloge
- FREERUN : N'est connecté à aucun GM distant, utilise un oscillateur local.
- ATTENTE : Perte de connexion à un GM distant, tentative de récupération et tentative de maintien de l'horloge précédente. Pendant l'état HOLDOVER, l'horloge peut commencer à dériver, et si elle dérive en dehors des spécifications, elle revient au mode FREERUN.
- ACQUISITION : Début de la négociation avec GM et échange de messages avec le GM pour déterminer le délai induit par le réseau et tenter de se synchroniser avec l'horloge GM.
- FREQ_LOCKED : Le périphérique esclave est verrouillé sur le maître par rapport à la fréquence, mais n'est pas aligné sur la phase.
- PHASE_ALIGNÉ : Verrouillé au maître par rapport à la fréquence et à la phase.
Machine d'état pour RPD :
Domaines PTP
Le domaine PTP est un nombre qui identifie un groupe de périphériques qui communiquent ensemble. Les périphériques esclaves et maîtres doivent se trouver dans le même domaine PTP pour pouvoir se synchroniser. Le domaine 0 est le domaine par défaut et les domaines 1-2-3 sont réservés par spécification. Les autres numéros de domaine peuvent être compris entre 4 et 255,
Notez que certaines variantes PTP telles que G.8275.2 nécessitent que le domaine PTP se trouve dans la plage 44-63. Par conséquent, si vous n'utilisez pas cette variante, évitez d'utiliser cette plage de domaines PTP, car cela peut confondre l'utilisateur et le périphérique.
Profils PTP
Les profils PTP ont été introduits dans la norme IEEE 1588-2008 et comprennent un ensemble d'options de configuration pouvant être sélectionnées pour répondre aux exigences de différentes applications. Il est possible de définir des profils distincts afin d'adapter PTP à différents scénarios.
Exemples de profils PTP courants :
- Profil Telecom-2008 : Profil générique utilisé avant les spécifications G.8265.1. Ce profil utilise les numéros de domaine 0-4. Ce profil est pris en charge sur cBR-8 et RPD, cependant, G.8275.2 est fortement recommandé par rapport à celui-ci, car il est plus résistant aux défaillances.
- G.8265.1 : Profil de télécommunications de protocole de temps de précision pour la synchronisation de fréquence
Ce profil est destiné aux applications qui nécessitent une synchronisation de fréquence uniquement sur les réseaux de télécommunications. Il ne couvre pas l'alignement des phases et/ou l'heure de la journée.
Le cas d'utilisation concerne les maîtres et les esclaves PTP dans les réseaux où les noeuds intermédiaires ne prennent pas en charge PTP.
- G.8275.1 : profil de télécommunications de protocole de temps de précision pour la synchronisation phase/temps avec prise en charge de la synchronisation complète à partir du réseau
Ce profil est utilisé dans les systèmes qui nécessitent une synchronisation précise de l'heure et de la phase dans les réseaux de télécommunications (par exemple, réseau cellulaire 4G ou réseau RPD) où une synchronisation de phase et/ou d'heure est requise.
Avec ce profil, chaque périphérique réseau participe au protocole PTP. Une horloge de limite est utilisée à chaque noeud de la chaîne entre le maître de réseau PTP et l'esclave PTP, ce qui réduit l'accumulation d'erreurs temporelles sur le réseau.
- G.8275.2 : Profil de télécommunications de protocole de temps de précision pour la synchronisation temps/phase avec prise en charge de la synchronisation partielle à partir du réseau
Ce profil est basé sur la prise en charge de la synchronisation partielle du réseau, ce qui signifie que les noeuds du domaine PTP n'ont pas besoin d'être directement connectés.
Comme le G.8275.1, il est utilisé dans les systèmes qui nécessitent une synchronisation précise du temps et de la phase, mais permet d'exécuter la synchronisation de la phase et du temps sur les réseaux existants. Il utilise des horloges de limite si nécessaire pour régler le signal temporel sur l’ensemble du réseau.
Pour plus d'informations sur les plates-formes G.8275.1 et G.8275.2 pour ASR900, cliquez ici : Guide de configuration de synchronisation et de synchronisation, Cisco IOS XE Everest 16.5.1 (gamme Cisco ASR 900)
Définition des messages de base
- Sync, Follow_up, Delay_req, Delay_resp sont des messages utilisés par les horloges de frontière et ordinaires pour communiquer des informations d'heure aux esclaves sur le réseau.
- Les messages d'annonce sont échangés à la fois par les esclaves et par le maître pour identifier la meilleure horloge du réseau à l'aide de l'algorithme Best Master Clock (reportez-vous aux images 26, 27 et 28 des spécifications IEEE pour le mécanisme détaillé).
- Les messages de signalisation sont utilisés pour les informations non critiques.
Conditions requises
Ces exigences doivent être satisfaites pour un déploiement correct de PTP dans un cBR-8 et R-PHY dans un réseau de production :
- Utilisez le profil PTP G.8275.2, qui garantit que le protocole PTP fonctionne correctement même si certains éléments réseau du chemin ne prennent pas en charge le protocole PTP
- Pas de chemins ECMP (Equal-Cost Multi-Path), d'équilibrage de charge ou d'asymétrie : PTP suppose toujours que le délai entre le maître et l'esclave et vice versa est égal, et dans les 500 microsecondes (μs)
- Configurez les intervalles de délai et de synchronisation avec les valeurs -4 ou -5 (voir le chapitre Configuration pour plus de détails). Les valeurs supérieures à -4 (-3, ...) peuvent ne pas offrir une précision suffisante pour détecter les petits changements de décalage. Les valeurs inférieures à -5 (-6,...) ont un impact plus important sur l'utilisation du réseau, mais pas un gain de précision de signification.
- Assurez-vous que les paquets PTP pour les RPD ne passent pas par le cBR-8
- Garantir une gigue minimale dans le réseau IP (1 ms max.). La QoS PTP appropriée doit être appliquée à tous les routeurs : cBR-8 et RPD envoient tous les paquets PTP marqués avec le DSCP (Differentiated Services Code Point) 46 (express forwarding - EF). Assurez-vous que l'horloge PTP Grand Master marque également les paquets avec la même valeur DSCP.
- L'horloge PTP Grand Master doit être synchronisée avec le GPS et le rapport clock-class 6, pour une utilisation sur un réseau de production. Les configurations de travaux pratiques peuvent fonctionner avec un maître PTP autonome (clock class 58).
- L'horloge PTP Grand Master doit avoir une précision d'horloge de 100 nanosecondes.
- Si deux horloges PTP Grand Master sont utilisées, vous devez utiliser le GPS pour synchroniser l'heure entre elles. Les deux grands maîtres PTP doivent avoir leurs horloges dans un délai de 500 microsecondes (μs)
Configuration
Cette section décrit comment configurer une horloge maître PTP sur un routeur Cisco ASR900, les horloges esclaves sur cBR-8 pour cBR-8 lui-même et RPD, et une horloge frontière sur ASR900.
Horloge maître PTP sur ASR900
Il existe une implémentation de base logicielle du protocole PTP, sous Linux, appelée ptpd. Cependant, étant donné qu'il est basé sur un logiciel, il n'offre pas assez de précision pour que le cBR-8 et le RPD fonctionnent avec lui, par conséquent, les modems ne pourront pas se connecter et la synchronisation PTP ne se produira pas non plus. En outre, l'implémentation de linux PTPd nécessite un horodatage matériel par la carte réseau afin d'augmenter la précision. Cela signifie que lorsque vous utilisez une machine virtuelle ou une carte réseau qui ne prend pas en charge l'horodatage matériel, PTPd peut même ne pas démarrer sous Linux.
Selon le modèle de l'ASR900 utilisé, il peut ou non avoir une antenne GPS. Si l'ASR900 n'a pas d'antenne GPS, vous n'avez pas de PRTC, mais vous pouvez toujours exécuter l'ASR900 en tant que Grand-Maître avec un PRTC local (oscillateur interne). Cela signifie que si cet ASR900 échoue et qu'un autre ASR900 prend le relais, le cBR-8 et le RPD perdent la référence temporelle en raison du fait que les deux horloges ne sont pas synchronisées.
Étape 1. Configurer L'Oscillateur Interne Local
network-clock source quality-level QL-PRC tx
network-clock synchronization automatic
network-clock synchronization mode QL-enabled
network-clock synchronization squelch-threshold QL-PRC
network-clock quality-level tx QL-PRC ptp domain 0
network-clock input-source 1 External R0 10m
Étape 2. Configurer PTP en tant que maître sur l'ASR900
ptp clock ordinary domain 0 <<< DOMAIN 0 or DOMAIN 44 for G.8275.2
clock-port MASTER master [profile g8275.2] <<< EITHER DEFAULT OR G.8275.2 PROFILE
sync interval -4
sync one-step
transport ipv4 unicast interface Lo1588 negotiation <<< IPV4 UNICAST MODE, SOURCING PACKETS FROM LO1588 interface
interface Loopback1588
ip address 15.88.15.88 255.255.255.255
end
Si vous choisissez d'utiliser le profil G.8275.2 dans votre environnement au lieu du profil par défaut, vous devez le spécifier dans la configuration du port d'horloge (pour la configuration du profil G.8275.2 sur le cBR-8, reportez-vous à la section : Profil G.8275.2).
Notez que même si IOS-XE permet de configurer le profil G.8265.1, cela n'est pas pris en charge dans l'environnement DOCSIS avec cBR-8 et RPD.
Pour obtenir de plus amples informations sur le profil G.8275.2 de l'ASR900, consultez le guide suivant : Guide de configuration de synchronisation et de synchronisation, Cisco IOS XE Everest 16.5.1 (gamme Cisco ASR 900)
Vérification
Cette section fournit des informations que vous pouvez utiliser afin de vérifier que votre configuration fonctionne correctement.
ASR900#show ptp clock running
PTP Ordinary Clock [Domain 0]
State Ports Pkts sent Pkts rcvd Redundancy Mode
FREQ_LOCKED 1 86307034 36108234 Hot standby
PORT SUMMARY
PTP Master
Name Tx Mode Role Transport State Sessions Port Addr
MASTER unicast master Lo1588 Master 1 -
ASR900#show ptp clock dataset parent
CLOCK [Ordinary Clock, domain 0]
Parent Clock Identity: 0x34:6F:90:FF:FE:C1:66:3F
Parent Port Number: 0
Parent Stats: No
Observed Parent Offset (log variance): 0
Observed Parent Clock Phase Change Rate: 0
Grandmaster Clock:
Identity: 0x34:6F:90:FF:FE:C1:66:3F
Priority1: 128
Priority2: 128
Clock Quality:
Class: 58
Accuracy: Within 1s
Offset (log variance): 52592
ASR900#show platform software ptpd stat stream 0
LOCK STATUS : FREERUN
SYNC Packet Stats
Time elapsed since last packet: 0.0
Configured Interval : 0, Acting Interval 0
Tx packets : 5577, Rx Packets : 0
Last Seq Number : 5577, Error Packets : 0
Delay Req Packet Stats
Time elapsed since last packet: 0.0
Configured Interval : 0, Acting Interval : 0
Tx packets : 0, Rx Packets : 5353
Last Seq Number : 0, Error Packets : 0
Delay Response Packet Stats
Time elapsed since last packet: 0.0
Configured Interval : 0, Acting Interval : 0
Tx packets : 5353, Rx Packets : 0
Last Seq Number : 0, Error Packets : 0
Announce Packet Stats
Time elapsed since last packet: 0.0
Configured Interval : 0, Acting Interval : 0
Tx packets : 1904, Rx Packets : 0
Last Seq Number 1904 Error Packets 0
Signalling Packet Stats
Time elapsed since last packet: 0.0
Configured Interval : 0, Acting Interval : 0
Tx packets : 1, Rx Packets : 1
Last Seq Number : 1, Error Packets : 0
Current Data Set
Offset from master : +0.0
Mean Path Delay : +0.0
Forward Path Delay : +0.0
Reverse Path Delay : +0.0
Steps Removed 0
General Stats about this stream
Packet rate : 0, Packet Delta (ns) : 0
Clock Stream handle : 0, Index : 0
Oper State : 0, Sub oper State : 6
Log mean sync Interval : 0, log mean delay req int : 0
Horloge esclave sur cBR-8
Le cBR-8 agit comme le noyau du CCAP de la DPR, de sorte qu'il est responsable de la configuration PTP de lui-même et des DPR associées.
Le cBR-8 utilise des profils pour obtenir ces informations PTP aux RPD, et plusieurs options pour le PTP sont configurables :
- Le type de suivi de servo pour le cBR-8 doit être défini sur R-DTI pour accélérer la synchronisation d'horloge.
- Le cBR-8 utilise une adresse de bouclage définie par l'utilisateur comme source de ses paquets PTP. Assurez-vous qu'il existe un routage approprié pour l'horloge principale pour atteindre l'interface de bouclage. Si vous ne parvenez pas à envoyer une requête ping à l'horloge maître avec un paquet provenant de l'adresse de bouclage, le protocole PTP n'est pas opérationnel.
- Le profil G.8275.2 Telecom est recommandé car il prend en charge les protocoles IPv4 et IPv6, et les périphériques de commutation intermédiaires du CIN n'ont pas besoin d'être compatibles PTP.
- Le numéro de domaine PTP est choisi par l'utilisateur mais doit être identique pour le cBR-8 et le RPD.
Les paquets PTP sont marqués avec une QoS plus élevée par la RPD et le cBR-8 pour la priorité sur le CIN. La valeur DSCP 46/EF est utilisée par défaut sur les deux.
ptp clock ordinary domain 0
servo tracking-type R-DTI
clock-port TOMASTER slave
announce interval -3
announce timeout 10
delay-req interval -4 <<< RECOMMENDED VALUE
sync interval -4 <<< RECOMMENDED VALUE
transport ipv4 unicast interface Lo1588 negotiation <<< IPV4 UNICAST PACKETS SOURCED FROM THE LO1588 interface
clock source 15.88.15.88 <<< THIS IS YOUR PTP MASTER
clock source 15.88.2.8 1 <<< THIS IS THE ALTERNATE MASTER FOR PTP REDUNDANCY (OPTIONAL)
Dans cet exemple, le port d'horloge est configuré pour utiliser le profil PTP par défaut. Pour la configuration du profil G.8275.2, reportez-vous à la section : Profil G.8275.2.
Avec la configuration de redondance PTP, si le maître devient inaccessible, les commutateurs cBR-8 sont dirigés vers l'autre source et dès que le maître est à nouveau disponible, le cBR-8 revient à la source principale.
Vérification
Vérifiez avec cette commande que l'état est PHASE_ALIGNED et que les paquets envoyés et reçus sont plus nombreux :
cBR-8#show ptp clock running domain 0
PTP Ordinary Clock [Domain 0]
State Ports Pkts sent Pkts rcvd Redundancy Mode
PHASE_ALIGNED 1 462249 1104590 Hot standby
PORT SUMMARY
PTP Master
Name Tx Mode Role Transport State Sessions Port Addr
TOMASTER unicast slave Lo1588 Slave 1 15.88.15.88
SESSION INFORMATION
TOMASTER [Lo1588] [Sessions 1]
Peer addr Pkts in Pkts out In Errs Out Errs
15.88.15.88 1104590 462249 0 0
Restrictions
- Pour le moment, cBR-8 ne prend pas en charge PTP sur MPLS, donc si les paquets PTP sont étiquetés MPLS, l'horloge ne se synchronise pas. Il existe une demande d'amélioration pour que cette fonctionnalité soit prise en charge et vous pouvez suivre les mises à jour éventuelles à l'adresse suivante : CSCvj02809.
- En tant que profil PTP, vous pouvez soit utiliser le profil par défaut (comme jusqu'à présent), soit spécifier le profil G.8275.2 (recommandé) comme décrit dans la section suivante. Notez que même si IOS-XE permet de configurer le profil G.8265.1, cela n'est pas pris en charge dans l'environnement DOCSIS avec cBR-8 et RPD.
Profil G.8275.2
Vous pouvez configurer le profil G.8275.2 sur l'esclave cBR-8 avec une source GM de cette manière :
ptp clock ordinary domain 44 servo tracking-type R-DTI clock-port TOMASTER slave profile g8275.2 <<<<<<<<<< announce interval -3
announce timeout 10
delay-req interval -4
sync interval -4 transport ipv4 unicast interface Lo1588 negotiation clock source 15.88.15.88
Comme mentionné précédemment dans cet article, la limite PTP n'est pas encore prise en charge sur le cBR-8. Cependant, si vous voulez configurer le profil G.8275.2 sur l'esclave cBR-8 avec deux sources GM, vous devez utiliser la définition de domaine frontière de cette manière :
ptp clock boundary domain 44 servo tracking-type R-DTI clock-port slave1 profile g8275.2 <...> transport ipv4 unicast interface Lo1588 negotiation clock source 15.88.15.88 <<< THIS IS YOUR PTP MASTER clock-port slave2 profile g8275.2 <...> transport ipv4 unicast interface Lo1588 negotiation clock source 15.88.2.8 <<< THIS IS THE ALTERNATE MASTER FOR PTP REDUNDANCY
Horloge esclave sur RPD
Malgré cette configuration RPD, elle doit être saisie sur le cBR-8 lui-même, puisque le cBR-8 provisionne le périphérique Remote Phy.
ptp r-dti 1
[profile G.8275.2] <-- ONLY IF SPECIFIED IN THE cBR-8 PTP CONFIGURATION
ptp-domain 0
clock-port 1
clock source ip 15.88.15.88 <-- THIS IS YOUR PTP MASTER
clock source ip 15.88.2.8 alternate <-- THIS IS THE ALTERNATE MASTER FOR PTP REDUNDANCY (OPTIONAL)
sync interval -4
announce interval -3
Value Log calculation Value in seconds
-5 2^-5 1/32s
-4 2^-4 1/16s
-3 2^-3 1/8s
-2 2^-2 1/4s
-1 2ˆ-1 1/2s
0 2^0 1s
1 2^1 2s
2 2^2 4s
3 2^3 8s
4 2^4 16s
5 2^5 32s
Vérification
Ces commandes émises à partir de la console RPD peuvent être utilisées pour vérifier l'état PTP, qui doit être dans PHASE_LOCK et SUB_SYNC, et les compteurs de réponse de synchronisation, de demande de délai et de délai qui doivent augmenter :
# ssh 10.6.17.9 -l admin
R-PHY>ena
R-PHY#show ptp clock 0 state
apr state : PHASE_LOCK <<<
clock state : SUB_SYNC <<<
current tod : 1506419132 Tue Sep 26 09:45:32 2017
active stream : 0
==stream 0 :
port id : 0
master ip : 15.88.15.88
stream state : PHASE_LOCK <<< Stream state must be PHASE_LOCK
Master offset : 1212 <<< Master offset (in ns) must be as close to 0 as possible
Path delay : -81553
Forward delay : -80341 <<< Forward delay and reverse delay must be within 500us of each other
Reverse delay : -77791 <<< Forward delay and reverse delay must be within 500us of each other
Freq offset : -86279
1Hz offset : -615
R-PHY#show ptp clock 0 statistics <output omitted> streamId msgType rx rxProcessed lost tx 0 SYNC 8585001 8584995 0 0 <<<<<< 0 DELAY REQUEST 0 0 0 8585000 <<<<<< 0 P-DELAY REQUEST 0 0 0 0 0 P-DELAY RESPONSE 0 0 0 0 0 FOLLOW UP 0 0 0 0 0 DELAY RESPONSE 8584998 8584998 5 0 <<<<<< 0 P-DELAY FOLLOWUP 0 0 0 0 0 ANNOUNCE 536571 536571 0 0 0 SIGNALING 5593 5593 0 5591 0 MANAGEMENT 0 0 0 0 TOTAL 17712163 17712157 5 8590591
Horloge de limite sur ASR900
Supposez que vous voulez configurer une horloge de limite comme maître secondaire pour cBR-8 et RPD, au cas où l'horloge maître échoue ou devient inaccessible. Cette horloge frontière utilise une source maître différente à des fins de redondance (dans cet exemple, 15.88.200.8). La configuration de l'horloge maître dans ce scénario n'est pas différente de celle décrite précédemment. Elle est donc omise dans cette section.
ptp clock boundary domain 0 clock-port TO-MASTER slave sync interval -5 transport ipv4 unicast interface Lo2008 negotiation clock source 15.88.200.8 <<< THE PTP MASTER (Different from PTP master described above) clock source 15.88.20.8 1 <<< AN ALTERNATE MASTER USED FOR REDUNDANCY (OPTIONAL) clock-port TO-SLAVE master transport ipv4 unicast interface Lo1588 negotiation interface Loopback1588 ip address 15.88.2.9 255.255.255.255 end
Surveillance avec SNMP
Afin de surveiller le nombre de sessions ptp sur l'ASR900 et cBR-8 avec SNMP, vous pouvez utiliser :
Objet - cPtpClockPortNumOfAssociatedPorts
OID - 1.3.6.1.4.1.9.9.760.1.2.7.1.10
Dépannage
Cette section fournit des renseignements qui vous permettront de régler les problèmes de configuration.
Dépannage du maître PTP (ASR900)
Sur le maître, la chose la plus importante est de s'assurer que PTP a une source d'horloge réseau pour la synchronisation, soit une antenne GPS (préférée), soit un oscillateur local.
Afin de vous assurer que la source network-clock fonctionne comme prévu, vous pouvez utiliser la commande :
ASR900#show network-clocks synchronization
Symbols: En - Enable, Dis - Disable, Adis - Admin Disable
NA - Not Applicable
* - Synchronization source selected
# - Synchronization source force selected
& - Synchronization source manually switched
Automatic selection process : Enable
Equipment Clock : 2048 (EEC-Option1)
Clock Mode : QL-Enable
ESMC : Enabled
SSM Option : 1
T0 : Internal
Hold-off (global) : 300 ms
Wait-to-restore (global) : 300 sec
Tsm Delay : 180 ms
Revertive : No
Nominated Interfaces
Interface SigType Mode/QL Prio QL_IN ESMC Tx ESMC Rx
*Internal NA NA/Dis 251 QL-SEC NA NA <<<<<
External R0 10M NA/Dis 1 QL-FAILED NA NA
Gi0/2/5 NA Sync/En 1 QL-FAILED QL-PRC -
Dépannage de l'esclave PTP (cBR-8)
Sur le cBR-8 en tant qu'esclave, il est important de noter que le prend uniquement en charge les interfaces DPIC SUP pour se connecter au maître PTP (à partir de maintenant), donc n'utilisez pas l'interface Gig0 ou les interfaces PIC RPHY, car PTP pourrait ne pas fonctionner par ces interfaces.
Au cours de la négociation PTP initiale, le cBR-8 peut prendre jusqu'à 35 minutes pour régler et aligner son horloge sur l'horloge du maître PTP. Pendant ce temps, l'horloge est affichée en état ACQUISITION sur cBR-8 :
cBR-8#show ptp clock running
PTP Ordinary Clock [Domain 0]
State Ports Pkts sent Pkts rcvd Redundancy Mode
ACQUIRING 1 687 1995 Hot standby
PORT SUMMARY
PTP Master
Name Tx Mode Role Transport State Sessions Port Addr
TOMASTER unicast slave Lo1588 Uncalibrated 1 15.88.15.88
Si l'état ACQUIRING reste là pendant plus de 35 minutes, cela peut indiquer que l'horloge principale PTP n'est pas très précise et dérive d'avant en arrière, ce qui empêche le cBR de pouvoir ACQUIRE correctement. Ceci peut être vu avec un serveur Linux avec PTPd par exemple.
L'horloge PTP sur le cBR-8 et le RPD doit être synchronisée avec le maître avant de résoudre les problèmes DOCSIS. Plusieurs commandes peuvent afficher cet état ainsi que le nombre de paquets. Vous voulez voir l'incrément de paquets pour la synchronisation, la demande de délai et la réponse de délai dans ce résultat :
cBR-8#show platform software ptpd stat stream 0 LOCK STATUS : PHASE LOCKED <<<<<<< must be PHASE LOCKED SYNC Packet Stats Time elapsed since last packet: 0.0 Configured Interval : -5, Acting Interval -5 Tx packets : 0, Rx Packets : 24074045 <<<<<<< Rx Packets must increase Last Seq Number : 42454, Error Packets : 0 <<<<<<< Last Seq Number must increase Delay Req Packet Stats Time elapsed since last packet: 0.0 Configured Interval : 0, Acting Interval : -5 Tx packets : 24077289, Rx Packets : 0 <<<<<<< Tx Packets must increase Last Seq Number : 0, Error Packets : 0 Delay Response Packet Stats Time elapsed since last packet: 0.0 Configured Interval : -5, Acting Interval : -5 Tx packets : 0, Rx Packets : 23983049 <<<<<<< Rx Packets must increase Last Seq Number : 31420, Error Packets : 0 <<<<<<< Last Seq Number must increase Announce Packet Stats Time elapsed since last packet: 0.0 Configured Interval : -3, Acting Interval : -3 Tx packets : 0, Rx Packets : 6030915 <<<<<<< Rx Packets must increase Last Seq Number 44276 Error Packets 0 <<<<<<< Last Seq Number must increase Signalling Packet Stats Time elapsed since last packet: 0.0 Configured Interval : 0, Acting Interval : 0 Tx packets : 9944, Rx Packets : 9521 <<<<<<< Tx Packets and Rx Packets must increase Last Seq Number : 0, Error Packets : 0 <output omitted>
Le numéro de flux peut être vérifié sous la commande déjà introduite show ptp clock running domain 0, sous la section SESSION INFORMATION. La première session est le flux 0, la seconde le flux 1, etc.
Si certains compteurs n’augmentent pas, il est possible d’avoir un problème de réseau et il est recommandé de vérifier la perte de paquets.
DTI et PTP
Afin de configurer PTP sur le cBR-8, le DTI de l'horloge de câble doit être DÉSACTIVÉ, sinon le message suivant s'affiche :
%[PTP]: NetSync source already configured. PTP slave configuration not allowed.
Enfin, la carte de ligne I-CMTS éventuellement insérée dans le même châssis repose sur la synchronisation PTP. Par conséquent, une panne potentielle sur l'horloge GM PTP peut également affecter les modems situés derrière une carte de ligne I-CMTS.
Délais d'horloge et décalage
Afin de vérifier le décalage de l'horloge maître, et quels sont les retards sur le chemin de transfert vers le chemin maître et le chemin inverse, vous pouvez utiliser cette commande introduite précédemment, et filtrer par la section Jeu de données actuel.
Le décalage du maître doit être aussi proche de 0 que possible et le délai du chemin de transfert doit être aussi égal que possible au délai du chemin inverse.
Voici un exemple avec de bonnes valeurs, comparées aux mauvaises valeurs capturées lors d'une situation problématique :
----------------- GOOD -----------------
cBR-8#show platform software ptpd stat stream 0 | s Current Data Set
Current Data Set
Offset from master : -0.000000313
Mean Path Delay : +0.000025042
Forward Path Delay : +0.000024729
Reverse Path Delay : +0.000024660
--------------- NOT GOOD ---------------
cBR-8#show platform software ptpd stat stream 0 | s Current Data Set Current Data Set Offset from master : +0.002812485 Mean Path Delay : +0.000022503 Forward Path Delay : +0.002834302 Reverse Path Delay : -0.002789295
Les valeurs sont exprimées en secondes (d'où le chiffre le moins significatif, le chiffre le plus à droite, est de nanoseconde), et le décalage du masque est calculé comme le délai moyen du chemin, moins le retard du chemin avancé.
Le délai moyen du chemin est calculé comme la moyenne entre l'avant et l'arrière : (retard de chemin de transfert + retard de chemin inverse) / 2.
Dans le monde idéal, le décalage de master serait égal à 0, car le retard de chemin avant serait égal au retard de chemin inverse, ce qui les rend tous deux égaux au retard de chemin moyen.
En fonction de l'asymétrie entre le chemin d'accès avancé et le chemin inverse, vous pouvez avoir un décalage négatif du maître (si le délai du chemin inverse est supérieur au délai du chemin d'accès avancé) ou un décalage positif (si le délai du chemin inverse est inférieur au délai du chemin d'accès avancé).
Si la valeur de décalage est trop importante, ou si vous observez des valeurs très fluctuantes, il est possible que ce soit un problème de gigue, ou une horloge principale inexacte.
Plus la gigue est élevée, plus le RPD ou cBR-8 est long à passer en état PHASE_ALIGNED, et plus il faut de temps pour se remettre d'une situation HOLDOVER.
Les configurations de plusieurs chemins influencent fortement la gigue (en raison du fait que certains paquets utilisent le chemin A et que certains paquets utilisent le chemin B avec des délais différents, ce que voit le cBR-8 et le RPD comme gigue). Par conséquent, il est nécessaire que le trafic PTP utilise un seul chemin (non équilibré en charge sur plusieurs liaisons).
Dépannage de l'esclave PTP (RPD)
Sur RPD, toutes les commandes intéressantes sont sous le parapluie show ptp :
R-PHY#show ptp clock 0 state
apr state : PHASE_LOCK
clock state : SUB_SYNC
current tod : 1506426304 Tue Sep 26 11:45:04 2017
active stream : 0
==stream 0 :
port id : 0
master ip : 15.88.15.88
stream state : PHASE_LOCK
Master offset : 6010
Path delay : -78442
Forward delay : -72432
Reverse delay : -81353
Freq offset : -86206
1Hz offset : -830
R-PHY#show ptp clock 0 statistics
AprState 6 :
2@0-00:14:54.347 3@0-00:14:15.945 2@0-00:06:24.766
1@0-00:06:15.128 0@0-00:03:59.982 4@0-00:03:40.782
ClockState 5 :
5@0-00:06:49.252 4@0-00:06:46.863 3@0-00:06:43.016
2@0-00:06:25.017 1@0-00:06:24.728
BstPktStrm 3 :
0@0-00:14:45.560 4294967295@0-00:14:07.272 0@0-00:06:15.160
StepTime 1 :
406874666@0-00:05:46.080
AdjustTime 99 :
427@0-02:05:11.705 -414@0-02:04:10.705 -396@0-02:03:09.705
145@0-02:02:08.705 -157@0-02:00:06.705 327@0-01:58:04.705
-195@0-01:57:03.705 -46@0-01:56:02.705 744@0-01:55:01.705
streamId msgType rx rxProcessed lost tx
0 SYNC 246417 246417 4294770689 0
0 DELAY REQUEST 0 0 0 118272
0 P-DELAY REQUEST 0 0 0 0
0 P-DELAY RESPONSE 0 0 0 0
0 FOLLOW UP 0 0 0 0
0 DELAY RESPONSE 117165 117165 4294902867 0
0 P-DELAY FOLLOWUP 0 0 0 0
0 ANNOUNCE 82185 82184 4294901761 0
0 SIGNALING 78 78 0 78
0 MANAGEMENT 0 0 0 0
TOTAL 445845 445844 12884575317 118350
R-PHY#show ptp clock 0 config
Domain/Mode : 0/OC_SLAVE
Priority 1/2/local : 128/255/128
Profile : 001b19000100-000000 E2E
Total Ports/Streams : 1 /1
--PTP Port 1, Enet Port 1 ----
Port local Address :10.6.17.9
Unicast Duration :300 Sync Interval : -5
Announce Interval : -3 Timeout : 11
Delay-Req Intreval : -4 Pdelay-req : -4
Priority local :128 COS: 6 DSCP: 47
==Stream 0 : Port 1 Master IP: 15.88.15.88
Informations connexes
- Protocole Precision Time - Wikipedia
- 1588-2008 - Norme IEEE pour un protocole de synchronisation d'horloge de précision pour les systèmes de mesure et de contrôle en réseau
- G.8265.1 : profil de télécommunications de protocole de temps de précision pour la synchronisation de fréquence
- G.8275.1 : profil de télécommunications de protocole de temps de précision pour la synchronisation phase/temps avec prise en charge de la synchronisation complète à partir du réseau
- G.8275.2 : profil de télécommunications de protocole de temps de précision pour la synchronisation temps/phase avec prise en charge partielle de la synchronisation à partir du réseau
- Guide de configuration de synchronisation et de synchronisation, Cisco IOS XE Everest 16.5.1 (gamme Cisco ASR 900)
- Guide de configuration du logiciel de périphérique Cisco Remote PHY pour Cisco 1x2 RPD Software 1.1
- Dépannage des problèmes de performances du débit DOCSIS RPD
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)