Contenido

Introducción

Antecedentes

Importancia de la sincronización de fase/frecuencia

Sincronización del reloj de red

Sincronización de frecuencia

Sincronización de fase

Sincronización horaria

SyncE

Principio básico de SyncE

Canal de mensajería de sincronización Ethernet

SyncE con LAG

PTPv2/1588v2

Principio básico de funcionamiento del PTP

Trabajo de PTP

Dominios PTP

Patrón de intercambio de mensajes

Diversos tipos de paquetes

Tipos de dispositivos PTP

Establecer la jerarquía del reloj maestro

Perfiles

8275.1

8275.2

Algoritmo Servo

Ejemplo de configuración para 8275.1/8275.2 en NCS 540 (Cisco IOS XR)

Solución de problemas de PTP

Ejemplos de Capturas de Paquetes de Mensajes de Sincronización, Anuncio, Retraso_Req y Retraso_Resp

Información Relacionada

Introducción

Este documento describe el trabajo de Precision Time Protocol (PTP) y Synchronous Ethernet (SyncE) con configuraciones de ejemplo, ejemplos y comandos de resolución de problemas para dispositivos Cisco IOS® XR en perfiles de telecomunicaciones 8275.1 y 8275.2.

Antecedentes

Un reloj para nosotros es un reloj de pared o reloj de pulsera, pero para los dispositivos de red, es una señal periódica de 0 y 1 alternativos que se utiliza para probar los bits de datos. Al igual que una mano en segundos en el reloj tiene un movimiento angular para representar un segundo, un par de 0 y 1 representa T (período de tiempo [T=1/frecuencia]). Para generar este reloj, los dispositivos de red utilizan un oscilador de cristal que tiene un error de ±100 ppm (partes por millón). por ejemplo, un reloj con una frecuencia de 250 MHz y 100 ppm tendrá un rango de frecuencia de 249,975 MHz a 250,025 MHz.) para generar la señal del reloj. Por lo tanto, idealmente, el reloj no es completamente periódico sino suficiente para el requisito de muestrear las señales de datos de las interfaces.

Las redes de telecomunicaciones (3G/4G/5G) utilizan un reloj de muy alta calidad (estrato) y todas las estaciones base (nodos B/eNodeB, etc.) deben sincronizarse con este reloj con el menor error/retraso (aproximadamente 1 µs) posible.

- Una opción es instalar un GPS en todas las estaciones de base, lo que es bastante costoso y menos seguro ya que el GPS funciona en sistemas satelitales.

- La segunda opción es utilizar el equipo de red (NE) existente para transferir la información del reloj junto con la señal de datos. Esta opción es muy rentable, ya que los NE ya están transfiriendo los datos y el uso de NE para la transferencia de señales de reloj hará que sea más barato y seguro. Sin embargo, es posible que la calidad del reloj no sea tan buena como la opción anterior del GPS y que varíe en el perfil/protocolo utilizado en los NE, así como en la congestión en la red.

Importancia de la sincronización de fase/frecuencia

Una señal de mensaje (por ejemplo, una señal de voz) modulada con una onda de alta frecuencia (señal portadora) en el extremo del transmisor debe ser demodulada en el extremo del receptor con la misma señal portadora utilizada en el extremo del transmisor. Si se produce algún cambio/desplazamiento en la frecuencia o fase de la onda portadora en el receptor, la señal del mensaje se dañará. Sin embargo, siempre se espera un pequeño desplazamiento entre la onda del portador Rx y la onda del portador Tx.

Una analogía es utilizar una caja segura para enviar un mensaje y bloquearlo con una clave. Si alguien desea leer el mensaje en la caja segura, se debe utilizar la misma clave para desbloquear la caja en el extremo del receptor. Si la clave de réplica tiene alguna distorsión/desfiguración, el mensaje no se puede leer.

Las compensaciones aceptables para varios servicios de telecomunicaciones son:

Sincronización del reloj de red

La sincronización es la alineación de los relojes con la misma hora/fase y frecuencia.

La sincronización para la temporización se puede categorizar en sincronización de frecuencia (logrando = / = donde = también se llama a la misma velocidad), sincronización de fase (al mismo tiempo) y sincronización de hora (hora del día).

Sincronización de frecuencia

Todos los NEs deben coincidir la frecuencia de su reloj con un reloj fuente (derivado de un MasterClock).

La sincronización de frecuencia para NE se puede lograr con SyncE o PTPv2, que se discutirá más en esta sección.

SyncE trabaja en derivar la frecuencia de los paquetes de datos recibidos en la interfaz (funciona en la capa física) junto con los paquetes ESMC recibidos (un paquete por segundo aproximadamente) en la interfaz que describe la calidad del reloj. Por lo tanto, no agrega paquetes de control y no se ve afectado por la congestión del tráfico, que es el mejor aspecto de SyncE.

El PTP se ejecuta en los paquetes, por lo que habrá un flujo de paquetes de control y los paquetes se verán afectados por la congestión, lo que aumenta la demora.

Sincronización de fase

La sincronización de fase consiste en la alineación de estas señales de reloj. Podemos ver que las señales sincronizadas de frecuencia anteriores aún no están alineadas, por lo que tienen un desplazamiento de fase.

PTPv2 se utiliza para transportar la información de fase a través de la red.

Sincronización horaria

La sincronización horaria, también llamada Hora del día, simplemente tiene la misma hora en todos los NE. Es decir, t 1=t 2.

NTP y PTP se utilizan para transferir información de hora en la red. Si bien NTP proporciona una precisión de milisegundos, el PTP puede proporcionar una precisión de hasta submicrosegundos.

La sincronización horaria y la sincronización de fase se utilizan a menudo de forma sinónima en las redes, ya que el PTP utilizado para la sincronización de fase alcanzará la sincronización horaria.

NTP no formará parte de nuestra discusión ahora.

SyncE

Principio básico de SyncE

SyncE funciona sobre el principio básico de extraer la frecuencia del reloj de los datos recibidos en un puerto.

Aquí se ilustra un ejemplo sencillo. La señal de datos se procesa con el oscilador local y los datos de salida se envían desde el puerto Tx. Puede observar que la frecuencia del reloj está presente en la señal de datos transmitida en el puerto. SyncE funciona sobre el principio de procesamiento inverso de la señal recibida en el puerto Rx y de obtención de la información de frecuencia del reloj transmitido.

SyncE es una recomendación de ITU-T sobre cómo ofrecer una frecuencia en una red. Según la recomendación, la frecuencia se recuperará del bitstream en la capa física, como se señaló anteriormente. El reloj que se distribuirá en la cadena se denomina reloj de referencia principal (PRC) y todos los relojes de la red se rastrearán hasta ese reloj. Para obtener un reloj rastreable, todos los nodos en una cadena entre el MasterClock y el dispositivo final deben implementarse con un reloj de equipos Ethernet síncrono (CEE) según las recomendaciones de SyncE. El rendimiento del reloj recuperado no dependerá de la carga de la red, ya que no se sincroniza con ningún paquete específico.

El NE MasterClock toma las referencias de temporización de entrada externas que vienen del reloj de red (SSU o BITS). Estas referencias se utilizan luego como entrada al reloj CEE, normalmente ubicado en la tarjeta de sincronización central del NE. La referencia de temporización de salida CEE se utiliza luego para muestrear datos y enviar el tráfico en el puerto Tx de activación SyncE.

En el NE de reloj esclavo, el reloj se recupera dentro de la recuperación de datos del reloj del transceiver (CDR). En algunos casos en los que el reloj RX no está disponible en el transceptor, podría ser necesario el uso de un CDR externo para recuperar el reloj. A continuación, el reloj se envía a través de la placa de interconexiones para alcanzar la tarjeta de sincronización central del reloj esclavo. A continuación, esta referencia temporal se convierte en referencia a la CEE (también denominada referencia de cronometría de línea). Como se muestra en la Norma SlaveClock, una CEE puede aceptar referencias de línea y externas, así como la entrada de un oscilador local de ±4,6 ppm (utilizado en situaciones en las que no hay línea o referencias externas disponibles). A partir de este punto, el NE de reloj esclavo se convierte en el NE de reloj maestro para el siguiente NE descendente, y la sincronización se transporta de nodo a nodo, donde cada nodo participa en la recuperación y distribución.

Canal de mensajería de sincronización Ethernet

El canal de mensajería de sincronización Ethernet (ESMC) es un protocolo lento Ethernet definido por ITU-T (es decir, los mensajes se envían a la dirección de destino de Ethernet de multidifusión 01-80-C2-00-00-02 y utilizan Ether Type 88-09) para evitar que los mensajes se filtren de un enlace sincronizado a otro enlace.

Lleva la información del mensaje de estado de sincronización (SSM), que es el nivel de calidad (QL) del reloj transmisor. Por ejemplo: Si el dispositivo ascendente está sincronizado con un reloj PRC, el valor de QL recibido es QL-PRC y el valor de SSM correspondiente es 0010.

Las PDU de información de ESMC se envían periódicamente a una velocidad de una PDU por segundo. La falta de recepción de una PDU ESMC en un período de cinco segundos da como resultado el SSF=true (QL=QL-FAILED). El valor predeterminado (inicial) para el QL es DNU (SSM=1111) y sólo debe cambiar cuando se recibe un TLV de QL válido.

Debemos tener en cuenta que si un dispositivo tiene doble conexión y la fuente de señal para ambos dispositivos ascendentes es PRC, entonces el QL recibido en el dispositivo desde ambos links es QL-PRC. Por lo tanto, necesitamos priorizar los links en consecuencia para elegir el dispositivo ascendente adecuado con respecto a saltos, links, etc.

La sincronización MasterClock-SlaveClock en varios NE con varias entradas de sincronización posibles para la protección de la sincronización podría conducir a bucles de sincronización entre NE. Para evitar loops de sincronización, un NE debe insertar un valor SSM de DNU en la dirección del NE, que se utiliza como la fuente de sincronización real para el reloj NE.

SyncE con LAG

SyncE funciona en la capa física y los paquetes ESMC también son transportados por el protocolo lento Ethernet. El LAG es otra función que utiliza protocolos lentos y el LAG funciona sobre el ESMC. Por lo tanto, se requiere el procesamiento de los mensajes ESMC en cada link habilitado para Ethernet síncrono en el grupo LAG.

También es importante señalar que el uso de enlaces paralelos, como el caso del Grupo de Expertos, debe considerarse cuidadosamente debido a la posibilidad de crear loops de sincronización.

Lo ideal es que sea suficiente ejecutarlo en el link de un solo miembro del paquete, pero de lo contrario, se deja a los operadores para configurar varios puertos sincrónicos habilitados para Ethernet.

PTPv2/1588v2

El IEEE 1588 lo define el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) en 2002 como el Protocolo de sincronización del reloj de precisión (PTP) para sistemas de medición y control en red. Se denomina protocolo de tiempo de precisión (PTP) para abreviar.

IEEE 1588v1 se aplica a la automatización industrial y a los campos de pruebas y mediciones. Con el desarrollo de las redes IP y la popularización de las redes 3G, ha aumentado la demanda de sincronización horaria en las redes de telecomunicaciones. Para satisfacer esta necesidad, IEEE redactó IEEE 1588v2 basado en IEEE 1588v1 en junio de 2006, revisó IEEE 1588v2 en 2007 y publicó IEEE 1588v2 a finales de 2008.

1588v2 es un protocolo de sincronización horaria que permite una sincronización horaria muy precisa entre los dispositivos. También se utiliza para implementar la sincronización de frecuencia entre los dispositivos.

Este mecanismo de sincronización basado en paquetes combina la frecuencia y la sincronización de fase en niveles de submicrosegundos, con capacidades de distribución ToD a través del mecanismo eficiente de intercambio de paquetes

La principal debilidad del PTP también se debe a su naturaleza de paquete, ya que los paquetes de sincronización utilizados por el PTP se reenvían en la red entre el MasterClock y los hosts, que están sujetos a todos los eventos de red como el retraso de trama (latencia), la variación de retraso de trama (fluctuación de paquetes) y la pérdida de trama. Incluso con la mejor práctica de aplicar alta prioridad a los flujos de sincronización, estos paquetes de sincronización aún experimentarán congestión y posibles problemas de ruteo y reenvío como inestabilidad de ruta y fuera de secuencia.

Principio básico de funcionamiento del PTP

Enviamos el tiempo (hh:mm:ss) en un paquete y utilizamos el tiempo de ida y vuelta del flujo de paquetes para encontrar el retraso en la transmisión de un paquete y corregir el tiempo del reloj ajustándolo con la mitad del retraso del viaje de ida y vuelta.

Trabajo de PTP

PTP utiliza una arquitectura jerárquica de MasterClock-SlaveClock para la distribución del reloj.

Especifica cómo se sincronizan los relojes en tiempo real del sistema entre sí. Estos relojes se organizan en una jerarquía de sincronización MasterClock-SlaveClock con el reloj en la parte superior de la jerarquía que determina el MasterClock el tiempo de referencia para todo el sistema. La sincronización se logra mediante el intercambio de mensajes de temporización PTP, con SlaveClocks usando la información de temporización para ajustar sus relojes a la hora de su MasterClock en la jerarquía.

El PTP se diseñó suponiendo un modelo de comunicación multicast. PTP también soporta un modelo de comunicación unicast siempre y cuando se preserve el comportamiento del protocolo. PTP asume que los mensajes de anuncio son enviados periódicamente por un puerto y entregados a todos los demás puertos de los relojes ordinarios o de límite dentro de un trayecto de comunicación. Si la ruta de comunicación consta de más de dos puertos, se supone que los mensajes de anuncio se envían en multidifusión o que la información de anuncio se replica en todos los puertos de la ruta de comunicación mediante mensajes de unidifusión. Los puertos PTP detectan otros puertos dentro de una trayectoria de comunicación a través de la recepción de mensajes de anuncio multidifusión.

El protocolo se ejecuta dentro de un ámbito lógico denominado dominio. Todos los mensajes PTP, conjuntos de datos, máquinas de estado y todas las demás entidades PTP siempre están asociados a un ID de dominio determinado

El protocolo define el evento y los mensajes PTP generales. Los mensajes de eventos son mensajes cronometrados, es decir, una marca de hora precisa (hora registrada en el dispositivo en el punto de entrada/salida, pero no es necesario que el mensaje transporta la hora t) se genera tanto en la transmisión como en la recepción. Los mensajes generales no requieren marcas de tiempo precisas.

Dominios PTP

Un dominio consiste en una agrupación lógica de relojes que se comunican entre sí mediante el protocolo PTP.

Los dominios PTP se utilizan para dividir una red dentro de una entidad administrativa. Los mensajes PTP y los conjuntos de datos están asociados con un dominio y, por lo tanto, el protocolo PTP es independiente para diferentes dominios.

Patrón de intercambio de mensajes

1. El MasterClock envía un mensaje de sincronización al SlaveClock y toma nota de la hora en la que se envió.

2. SlaveClock recibe el mensaje Sync y toma nota de la hora de recepción.

3. El MasterClock transmite a SlaveClock la marca de hora:

- Inserta la marca de tiempo en el mensaje de sincronización. Esto requiere algún tipo de procesamiento de hardware para lograr la mayor precisión y precisión.

- Inserta la marca de tiempo en un mensaje de seguimiento.

4. SlaveClock envía un mensaje Delay_Req al MasterClock y toma nota de la hora en la que se envió.

5. MasterClock recibe el mensaje Delay_Req y toma nota de la hora de recepción.

6. El MasterClock transmite al SlaveClock la marca de hora insertándola en un mensaje Delay_Resp.

La exactitud del tiempo PTP se degrada por la asimetría en las trayectorias tomadas por los mensajes de eventos. Específicamente, el error de desplazamiento de tiempo es 1/2 de la asimetría.

La asimetría no es detectable por PTP. Sin embargo, si se conoce, el PTP corrige la asimetría. La asimetría se puede introducir en la capa física, por ejemplo, a través de la asimetría de medios de transmisión, por puentes y routers, y en sistemas grandes por las trayectorias hacia adelante e inversas atravesadas por mensajes de eventos que toman diferentes rutas a través de la red. Se deben configurar sistemas y seleccionar componentes para minimizar estos efectos guiados por la precisión de tiempo requerida. En sistemas de subred única con distancias de unos pocos metros, la asimetría no suele ser un problema para las precisiones de tiempo por encima de unos pocos 10 segundos de ns.

Diversos tipos de paquetes

El conjunto de mensajes de eventos consta de:

1. Sincronización: se utiliza para la sincronización del tiempo entre MasterClock y SlaveClock. En dos pasos, los mensajes de sincronización no llevan tiempo, pero la hora se marca con la marca de tiempo en el MasterClock y se transmitirá en el mensaje de seguimiento. En Un paso, el mensaje de sincronización llevará tiempo. Los dispositivos/hardware antiguos no podían admitir la medición y el transporte del punto de tiempo de salida cuando se enviaba un mensaje a través de un puerto, por lo que dos pasos se debían a la limitación del hardware. Hoy en día, el hardware puede registrar el punto de tiempo de salida y enviarlo dentro del mensaje Sync. Un paso es compatible con dos.

2. Delay_Req - Un mensaje Delay_Req es una solicitud del nodo de recepción/RelojEsclavo para devolver la hora en la que se recibió el mensaje Delay_Req, usando un mensaje Delay_Resp. Se utilizará para calcular el tiempo de tránsito entre SlaveClock y MasterClock. Este mensaje está marcado con el tiempo en el Reloj esclavo.

3. Pdelay_Req: un puerto PTP transmite un mensaje Pdelay_Req a otro puerto PTP como parte de la medición del tiempo de propagación de puerto a puerto para determinar el retraso en el link entre ellos. El reloj transparente P2P lo utiliza para calcular el retraso del link por salto.

4. Pdelay_Resp: un puerto PTP transmite un mensaje Pdelay_Resp en respuesta a la recepción de un mensaje Pdelay_Req.

El conjunto de mensajes generales consta de:

- Anuncio: este mensaje lo utiliza el algoritmo Best MasterClock (BMCA) para generar la topología MasterClock-SlaveClock. Se utiliza para elegir el mejor MasterClock y mantenerlo en su lugar.

- Follow_Up - Este tipo de mensaje se utiliza en el modo de dos pasos. Lleva el tiempo. (Sincronizar el tiempo de salida en el nodo MasterClock) en su mensaje.

- Delay_Resp - Se utiliza para calcular el tiempo de tránsito de MasterClock a SlaveClock. Lleva la hora (hora de salida del mensaje Delay_Resp) en el mensaje.

- Pdelay_Resp_Follow_Up - Esto es similar al mensaje de seguimiento pero lo genera un reloj transparente P2P.

- Gestión: No es parte de nuestra discusión.

- Señalización: para la comunicación entre los relojes con cualquier otro fin. Por ejemplo, los mensajes de señalización se pueden utilizar para la negociación de la velocidad de los mensajes de unidifusión entre un MasterClock y sus SlaveClocks.

Los mensajes Sync, Delay_Req, Follow_Up y Delay_Resp se utilizan para generar y comunicar la información de temporización necesaria para sincronizar los relojes ordinarios y los de límite mediante el mecanismo de respuesta de solicitud de demora.

Los mensajes Pdelay_Req, Pdelay_Resp y Pdelay_Resp_Follow_Up se utilizan para medir el retraso del link entre dos puertos de reloj que implementan el mecanismo de retraso del par. El retraso del link se utiliza para corregir la información de temporización en los mensajes Sync y Follow_Up en sistemas compuestos de relojes transparentes peer-to-peer.

Los relojes normales y de límite que implementan el mecanismo de demora de peer pueden sincronizarse usando los retrasos de link medidos y la información en los mensajes Sync y Follow_Up. El mensaje de anuncio se utiliza para establecer la jerarquía de sincronización. Los mensajes de administración se utilizan para consultar y actualizar los conjuntos de datos PTP mantenidos por los relojes. Estos mensajes también se utilizan para personalizar un sistema PTP y para la inicialización y la administración de fallas. Los mensajes de administración se utilizan entre los nodos de administración y los relojes (no formarán parte de nuestro debate).

Los mensajes de señalización se utilizan para la comunicación entre los relojes para todos los demás fines. Por ejemplo, los mensajes de señalización se pueden utilizar para la negociación de la velocidad de los mensajes de unidifusión entre un MasterClock y sus SlaveClocks.

Tipos de dispositivos PTP

Hay cinco tipos básicos de dispositivos PTP, a saber:

1. Reloj normal - Sólo puede ser un Grand MasterClock (GM) o sólo un SlaveClock.

2. Reloj límite: puede ser SlaveClock y GM

3. Reloj transparente de extremo a extremo - El reloj transparente de extremo a extremo reenvía todos los mensajes como un puente, router o repetidor normal. Sin embargo, para los mensajes de eventos PTP, el puente de tiempo de residencia, que se muestra en la figura siguiente, mide el tiempo de residencia (el tiempo que tarda el mensaje en atravesar el reloj transparente) de los mensajes de eventos PTP. Estos tiempos de residencia se acumulan en un campo especial, el campo de corrección, del mensaje de evento PTP o el mensaje de seguimiento asociado. Esta corrección se basa en la diferencia en la marca de tiempo generada cuando el mensaje del evento entra y deja el reloj transparente.

4. Reloj transparente de peer a peer - Agrega el tiempo de residencia así como el tiempo de demora de tránsito de link a los mensajes ptp mediante el mecanismo de demora de peer (genera sus propios paquetes delay-req-resp para calcular el retraso del link de peer).

5. Nodo de administración (no forma parte de nuestra conversación).

Establecer la jerarquía del reloj maestro

Dentro de un dominio, cada puerto de un reloj normal y de límite ejecuta una copia independiente de la máquina de estado del protocolo. Para "eventos de decisión de estado", cada puerto examina el contenido de todos los mensajes de anuncio recibidos en el puerto. Utilizando el mejor algoritmo MasterClock, se analizan el contenido del mensaje de anuncio y el contenido de los conjuntos de datos asociados con el reloj normal o de límite para determinar el estado de cada puerto del reloj.

Máquina de estado PTP

Cada puerto de un reloj ordinario y de límite mantiene una copia separada de la máquina de estado PTP. Esta máquina de estado define los estados permitidos del puerto y las reglas de transición entre estados. Los principales "eventos de decisión de estado" que determinan la jerarquía de MasterClock-SlaveClock son la recepción de un mensaje de anuncio y el final de un intervalo de anuncio (el intervalo entre mensajes de anuncio). Los estados del puerto que determinan la jerarquía de MasterClock-SlaveClock son los siguientes:

- INIT - El puerto aún no está listo para participar en PTP.

- ESCUCHA - Primer estado cuando un puerto está listo para participar en PTP: el puerto escucha PTP MasterClocks durante un período de tiempo (configurable)

- PRE-MasterClock - El puerto está a punto de entrar en el estado MasterClock.

- MasterClock - El puerto proporciona marcas de tiempo para cualquier reloj SlaveClock/límite de escucha.

- UNCALIBRATED - El puerto recibe marcas de tiempo de un MasterClock, pero el reloj del router todavía no está sincronizado con ese MasterClock

- SLAVE - El puerto recibe las marcas de tiempo de un MasterClock y el reloj del router está sincronizado con ese MasterClock

- PASSIVE - El puerto es consciente de un reloj mejor que el que anunciaría si estuviera en estado MasterClock, pero no está ahorrando ese reloj

Mejor Algoritmo MasterClock

El mejor algoritmo MasterClock compara los datos que describen dos relojes para determinar qué datos describen el mejor reloj. Este algoritmo se utiliza para determinar cuál de los relojes descritos en varios mensajes de anuncio recibidos por un puerto de reloj local es el mejor reloj. También se utiliza para determinar si un reloj descubierto recientemente (un reloj maestroClock extranjero) es mejor que el reloj local en sí. Los datos que describen un MasterClock externo se incluyen en los campos grandMasterClock de un mensaje de anuncio.

El algoritmo de comparación de conjuntos de datos se basa en comparaciones de atributos en pares con la siguiente precedencia:

1. priority1 - Designación configurable por el usuario de que un reloj pertenece a un conjunto ordenado de relojes desde los que se selecciona MasterClock

2. clockClass: atributo que define la trazabilidad TAI de un reloj

3. clockAccuracy - Atributo que define la exactitud de un reloj

4. offsetScaledLogVariance: atributo que define la estabilidad de un reloj

5. priority2: designación configurable por el usuario que permite realizar pedidos más finos entre relojes equivalentes

6. clockIdentity: un desempate basado en identificadores únicos

Además de este orden de precedencia, la "distancia" medida por el número de relojes de límite entre el reloj local y el reloj maestro externo se utiliza cuando dos mensajes de anuncio reflejan el mismo reloj maestro externo. La distancia se indica en el campo stepRemoved de los mensajes de anuncio. Esta condición puede ocurrir en sistemas PTP con trayectos cíclicos no eliminados por un protocolo fuera de PTP. El algoritmo de comparación de conjuntos de datos selecciona uno de los dos relojes como "mejor" o "topológicamente mejor".

Perfiles

El propósito de un perfil PTP es permitir a las organizaciones especificar selecciones específicas de valores de atributos y características opcionales de PTP que, al utilizar el mismo protocolo de transporte, interactúan y logran un rendimiento que cumpla los requisitos de una aplicación en particular.

Un perfil PTP debe definir:

- Mejores opciones del algoritmo MasterClock

- Opciones de administración de la configuración

- Mecanismos de retardo de trayecto (peer-delay o delay request-response)

- El rango y los valores predeterminados de todos los atributos configurables PTP y los miembros del conjunto de datos

- Mecanismos de transporte requeridos, permitidos o prohibidos

- Los tipos de nodo requeridos, permitidos o prohibidos

- Las opciones requeridas, permitidas o prohibidas

Varios perfiles definidos para la conexión de redes de paquetes con PTP son los siguientes:

Los perfiles 8265.x se utilizan para lograr la sincronización de frecuencia con PTP.

8275.x se utiliza para la sincronización de hora del día/Fase mediante PTP.  Actualmente, NCS5xx/55xx es compatible con 8265.1, 8275.1, 8275.2 y 8273.2.

8265.1 se utilizaba anteriormente para la sincronización de reloj 3G/4G, mientras que 8275.x se utiliza ahora para 5G debido al aumento de la demanda de precisión con las redes 5G.

8275.1

Este anexo contiene el perfil de telecomunicaciones PTP para la distribución de fase/hora con soporte de sincronización completo de la red.

Modelo de sincronización:

El perfil G.8275.1 adopta el modelo de sincronización salto a salto. Cada dispositivo de red en el trayecto del reloj de Servidor a Cliente sincroniza su reloj local con los dispositivos ascendentes y proporciona sincronización con el dispositivo descendente

Tipos de nodo:

En este perfil, los tipos de nodo permitidos son relojes normales, relojes de límite y relojes transparentes de extremo a extremo.

En este perfil, los tipos de nodo prohibidos son relojes transparentes de igual a igual.

Dominios:

Se pueden utilizar ID de dominio de 24 a 43. El ID de dominio predeterminado es 24

Modo de reloj:

Se permiten los relojes de un paso y de dos. Un reloj debe ser capaz de recibir y manejar mensajes transmitidos desde los relojes de un paso y de dos. No se necesita un reloj para admitir los modos de un paso y dos para transmitir mensajes.

Mecanismos de transporte requeridos, permitidos o prohibidos

En este perfil, los mecanismos de transporte permitidos son:

- IEEE 802.3/Ethernet y

- OTN

Se debe apoyar al menos uno de los dos mecanismos de transporte. Para el transporte a través de IEEE 802.3/Ethernet, se requiere que se admita la dirección multicast no reenviable 01-80-C2-00-00-0E y la dirección multicast reenviable 01-1B-19-00-00-00 para cumplir con este perfil

Mensajes de unidifusión/multidifusión:

Todos los mensajes se envían multidifusión mediante una de las dos direcciones de multidifusión (01-80-C2-00-00-0E/01-1B-19-00-00-00). El modo de unidifusión no está permitido en esta versión del perfil.

Mejores opciones del algoritmo MasterClock:

Este perfil utiliza la BMCA alternativa.

Los siguientes parámetros de reloj se comparan (en orden) de cada nodo disponible para seleccionar el mejor MasterClock:

Tabla 1. Jerarquía BMCA del perfil de Telcom

Parámetro

Descripción

Prioridad 1

NO se utiliza en perfiles de telecomunicaciones

Clase de reloj

Medida de la trazabilidad del reloj.

Si la frecuencia/hora del reloj maestro se puede rastrear a una referencia GNSS (A, B mejor que C)

Precisión del reloj

¿Cuál es la precisión de la salida del reloj del MM con respecto a la referencia principal?

Por ejemplo: tiempo exacto a 25 ns.

Varianza del registro escalado de desplazamiento (OSLV)

Medida de la precisión del reloj. Cuánto varía el resultado del reloj cuando no se sincroniza con otro origen.

Prioridad 2

Prioridad definida por el usuario en el nodo MasterClock si todos los parámetros anteriores coinciden

Prioridad de puerto local

Prioridad por puerto definida por el usuario en DUT

Identidad del reloj GM

ID del reloj de GrandMasterClock utilizado como desempate

Pasos eliminados

Ruta más corta elegida si se puede alcanzar grandMasterClock a través de varios puertos (A mejor que B)

Opción de medición de retraso de trayecto (solicitud de retraso/respuesta de demora):

El mecanismo de respuesta de demora/solicitud de retraso se utiliza en este perfil. El mecanismo de demora de peer no se debe utilizar en este perfil, se debe utilizar el método delay_req—response.

Este perfil de telecomunicaciones PTP define una BMCA alternativa que permite utilizar dos enfoques principales para configurar la topología de la red de sincronización de fase/hora:

Establecimiento automático de topología:

Al configurar los atributos localPriority definidos en esta Recomendación a su valor predeterminado, la topología PTP es establecida automáticamente por la BMCA alternativa basada en los mensajes de anuncio intercambiados por los relojes PTP. Después de esta operación se crea un árbol de sincronización con las rutas más cortas a los T-GM. En este modo, durante los eventos de falla y la reconfiguración de topología, la BMCA alternativa se ejecutará de nuevo y dará como resultado un nuevo árbol de sincronización. Esta operación BMCA alternativa garantiza que no se creará ningún loop de temporización sin necesidad de intervención manual o análisis previo de la red. El tiempo de convergencia a la nueva topología PTP depende del tamaño de la red y de la configuración específica de los parámetros PTP.

Planificación de red manual: El uso de los atributos localPriority definidos en esta Recomendación con valores diferentes a los predeterminados permite crear manualmente la topología de red de sincronización, de forma similar a como las redes Synchronous Digital Hierarchy (SDH) se suelen utilizar en función del mensaje de estado de sincronización (SSM). Esta opción permite el control total de las acciones durante los eventos de falla y la reconfiguración de la topología, en función de las prioridades locales configuradas del sistema. Sin embargo, se requiere una planificación de red cuidadosa antes de la implementación para evitar loops de sincronización.

Consideraciones sobre el uso de la prioridad 2:

El atributo PTP priority2 se puede configurar en este perfil. En algunas circunstancias especiales, el uso del atributo priority2 puede simplificar la administración de la red. Esta sección describe dos casos prácticos: otros casos posibles se estudiarán más a fondo.

- Caso 1.

Los operadores pueden configurar el atributo PTP priority2 para que todos los Telecom Boundary Clock (T-BC) se puedan rastrear a un Telecom Grand MasterClock (T-GM) o se puedan rastrear a dos T-GM diferentes al mismo tiempo.

Por ejemplo, en esta imagen, si todos los demás atributos PTP de los dos T-GM son iguales y los dos T-GM se configuran con el mismo valor priority2, cada T-BC seleccionará el T-GM con la trayectoria más corta. Si los dos T-GM se configuran con valores de prioridad2 diferentes, todos los T-BC se sincronizarán con el T-GM con el valor de prioridad2 más pequeño.

- Caso 2.

Los operadores pueden configurar el atributo PTP priority2 para evitar que los T-BC de una red ascendente se sincronicen con los T-BC de una red descendente cuando el T-GM falla.

Por ejemplo, en la figura, si todos los demás atributos PTP de todos los T-BC son iguales, y el atributo PTP priority2 de todos los T-BC se configura con el mismo valor, entonces cuando el T-GM está en la falla, los T-BC en la red ascendente pueden sincronizarse con los T-BC en la red descendente, dependiendo de los valores clockIdentity de todos los T-BC. Si los T-BC de la red ascendente se configuran con un valor de prioridad 2 menor que los T-BC de la red descendente, entonces, cuando el T-GM está en falla, los T-BC de la red descendente se sincronizarán con los T-BC de la red ascendente.

Operaciones sobre la agregación de enlaces:

Cuando se conectan dos dispositivos que integran relojes PTP que cumplen con este perfil mediante una agregación de enlaces (LAG), se debe acceder directamente a cada enlace físico para transmitir mensajes PTP, omitiendo el LAG. Este método evita posibles asimetrías que pueden estar presentes cuando las trayectorias hacia adelante y hacia atrás se entregan a través de diferentes links que pertenecen al LAG.

Consideraciones sobre la Elección de la Dirección de Destino de Multidifusión PTP Ethernet:

Este perfil PTP admite tanto la dirección multicast no reenviable 01-80-C2-00-00-0E como la dirección multicast reenviable 01-1B-19-00-00-00 cuando se utiliza la asignación PTP.

La dirección de multidifusión Ethernet que se utilizará depende de la política del operador; a continuación se exponen otras consideraciones.

La función de puente de Capa 2 asociada con el puerto PTP de un T-BC o T-TC no debe reenviar ninguna trama con la dirección MAC de destino 01-1B-19-00-00-00; esto podría hacerse aprovisionando correctamente esta dirección multicast en la base de datos de filtrado.

- Opción 1 - Uso de la dirección multicast no reenviable 01-80-C2-00-00-0E.

Algunos operadores de red consideran que los mensajes PTP nunca deben reenviarse a través de un equipo de red que no reconoce PTP.

El uso de la dirección multicast no reenviable 01-80-C2-00-00-0E garantiza esta propiedad la mayor parte del tiempo (existen excepciones para algunos equipos Ethernet más antiguos).

Por lo tanto, en el caso de configuración incorrecta del equipo de red (por ejemplo, si las funciones PTP no están habilitadas en el equipo de red que reconoce PTP), el uso de esta dirección multicast evita la distribución incorrecta de la sincronización, ya que los mensajes PTP serán bloqueados por el equipo de red que no reconoce PTP.

- Opción 2: Uso de la dirección de multidifusión reenviable 01-1B-19-00-00-00.

Algunos operadores de red consideran que el uso de una dirección multicast reenviable es más flexible y que es preferible reenviar los mensajes PTP para mantener el link de sincronización en funcionamiento en caso de que algún equipo esté mal configurado como nodos no PTP, aunque existen riesgos potenciales de degradación del rendimiento. El sistema de administración de redes (NMS) detectará fácilmente el error de configuración y enviará alarmas.

Sin embargo, es posible bloquear los mensajes PTP aprovisionando correctamente esta dirección multicast en la base de datos de filtrado de cada equipo Ethernet.

8275.2

Esta Recomendación define otro perfil PTP para permitir la distribución de fase y hora con soporte de temporización parcial (PTS) desde la red (es decir, no es necesario que cada dispositivo ejecute ptp en la red). La diferencia principal entre 8275.2 y 8275.1 es que se ejecuta en unidifusión IPv4 y no todos los nodos de la red necesitan ejecutar PTP.

Mecanismos de transporte:

En este perfil, el mecanismo de transporte requerido es UDP/IPv4.

Mensajes de unidifusión:

Todos los mensajes se envían en unidifusión.

En este perfil de telecomunicaciones, la negociación de unidifusión se habilita de forma predeterminada.

SlaveClock iniciará la sesión siguiendo el procedimiento de negociación de mensajes de unidifusión.

Dominios:

Se pueden utilizar ID de dominio de 44 a 63. El ID de dominio predeterminado es 44.

Mejores opciones del algoritmo MasterClock:

Este perfil utiliza la BMCA alternativa.

Propiedades Opción de medición de demora de trayecto (solicitud de retraso/respuesta de demora), Establecimiento automático de topología y Consideraciones sobre el uso de prioridad2 son iguales que el perfil de telecomunicaciones 8275.1

Consideraciones de PTP sobre el Transporte IP en Topologías de Anillo:

Al utilizar la mensajería PTP sobre una capa de transporte IP, hay algunos aspectos del protocolo de Capa 3 que deben tenerse en cuenta. La capa PTP envía mensajes a la capa IP con una dirección IP de destino. A continuación, la capa IP asegura que el mensaje se envíe al destino siempre y cuando haya alguna trayectoria a través de la red de transporte IP desde el nodo de origen a la dirección de destino. La capa IP incluye protocolos de ruteo dinámicos que pueden adaptar la trayectoria a través de la red según los links disponibles entre los routers IP. Puede ocurrir que la trayectoria tomada por la capa de transporte IP no sea la trayectoria 'esperada' por el planificador de sincronización. La aplicación de algunas restricciones en la capa de transporte IP para controlar las trayectorias subóptimas para los mensajes PTP puede ser beneficiosa. Este probablemente sea el caso en las topologías de anillo.

Tomando como ejemplo la topología mostrada en la figura siguiente, SlaveClock se configura para solicitar el servicio de unidifusión desde BC3 y BC4. Después de recibir los mensajes de anuncio de BC3 y BC4, SlaveClock ejecutará la BMCA y seleccionará BC4 como su reloj principal basándose en el hecho de que los pasos - el valor eliminado de BC4 es 1, comparado con un valor eliminado por pasos de 3 para BC3. El Reloj esclavo solicitaba entonces los mensajes de sincronización desde BC4.

Si se interrumpe la conexión entre BC4 y R6 (consulte la figura siguiente), no se alcanza BC4 a través de la ruta esperada. Sin embargo, todavía se puede alcanzar porque los protocolos de ruteo conservarán la conexión ruteando los paquetes IP alrededor del anillo. BC4 se conserva como el reloj primario porque BMCA todavía lo considera mejor.

Lo más probable es que la operación deseada sea que SlaveClock cambie a BC3 para obtener un mejor rendimiento.

Hay algunas técnicas que se pueden emplear para asegurarse de que en el escenario de falla identificado anteriormente, SlaveClock seleccione BC3 como su reloj principal. Se basan en el bloqueo de los mensajes IP PTP de BC4 al SlaveClock si esos mensajes transitan en el sentido de las agujas del reloj alrededor del anillo. La solución se basa en el bloqueo sólo de los mensajes PTP y no en el mensaje de otros protocolos que podrían utilizar las mismas direcciones IP.

Opción 1. Direcciones IP únicas y rutas estáticas:

En algunos modelos de implementación, podría ser posible asignar direcciones IP únicas para el uso de PTP solamente. Esto permite el uso de rutas estáticas para controlar la dirección de los flujos PTP entre los nodos. BC4 se configuraría de tal manera que la única ruta que se utilizará para alcanzar 11.x.x.141 (SlaveClock) sería el link entre BC4 y R6. Además, R6 podría configurarse de manera que la única ruta que se debe utilizar para alcanzar 11.y.y.104(BC4) sería el link entre R6 y BC4. Si el link entre R6 y BC4 falla, entonces no hay ninguna ruta disponible para obtener los paquetes IP entre 11.x.x.141 y 11.y.y.104, por lo que SlaveClock no recibirá Anuncios de BC4 y BMCA seleccionará BC3 como reloj principal. Consulte esta imagen.

Opción 2. Filtros IP

Todos los routers admiten cierto nivel de filtrado IP. Los filtros se pueden utilizar para proteger el plano de control del router de los mensajes no deseados. Se pueden utilizar en este caso para controlar la aceptación de los mensajes PTP en un subconjunto de las interfaces de ruteo.

En este caso, R6 se configuraría para proteger SlaveClock de los mensajes PTP que toman la ruta incorrecta. En la interfaz en R6 orientada hacia BC3, se podría aplicar un filtro para permitir solamente mensajes al puerto UDP 319 o 320 si la dirección de origen coincide con la del proceso PTP en BC3. Cualquier mensaje procedente de BC4 que se reciba en esa interfaz se descartará. Consulte esta imagen.

Opción 3. Procesamiento BC de todos los mensajes PTP

Un BC podría terminar todos los mensajes PTP recibidos en cualquiera de sus puertos para cualquier dominio utilizado por el BC. A continuación, los mensajes PTP podrían eliminarse o reenviarse en función de las decisiones del propio proceso PTP. Las opciones podrían ser descartar el mensaje si la dirección de destino del mensaje PTP no era una dirección propiedad del BC o entregarlo al motor de reenvío para enviarlo al destino. Este último caso podría utilizarse si el mensaje PTP es para un dominio diferente al BC. También en este último caso, el elemento de red que contiene el BC también podría actualizar el campo de corrección de cualquier mensaje de evento reenviado para compensar la extracción y procesamiento de mensajes PTP, es decir, soportar la función de reloj transparente para estos mensajes. La extracción de mensajes del plano IP se puede lograr si el router soporta el ruteo basado en políticas de los paquetes IP.

Este ejemplo se muestra en esta imagen.

Opción 4. Uso del Mecanismo de Tiempo de Vida (TTL) desde el Transporte IP:

Un nodo PTP podría enviar paquetes PTP con el encabezado IP/Transporte que lleve un campo TTL configurado al número mínimo de saltos de ruteo requeridos para alcanzar el puerto PTP del peer con el que tiene un contrato PTP. En una red típica que no reconoce PTP y que tiene routers no conscientes entre MasterClock y SlaveClock, si el número de routers PTP que no reconocen es mayor que el valor TTL del mensaje PTP, el mensaje PTP será descartado por uno de los routers que no reconoce PTP. Esto se puede utilizar para limitar el número de saltos IP que atraviesan los paquetes PTP entre los routers adyacentes y evitar la comunicación a través de trayectos largos no deseados.

Este comportamiento puede ser por puerto PTP o por reloj PTP, y es específico de la implementación. Se supone que en tal topología de anillo, el ruteo IP se ocupará de asegurar que una trayectoria más corta al PTP MasterClock se considere como una mejor ruta que la trayectoria más larga alrededor del anillo.

Por ejemplo, si un SlaveClock tiene un MasterClock conectado directamente que también puede alcanzarse a través de una trayectoria más larga, puede utilizar el valor TTL de 1 para asegurarse de que los paquetes PTP alcancen el MasterClock solamente a través de la trayectoria directamente conectada en lugar de la trayectoria más larga alrededor del anillo.

Algoritmo Servo

Descripción de los modos:

- Modo de ejecución libre:

El reloj PTP nunca se ha sincronizado con un origen de tiempo y no está en proceso de sincronizarse con un origen de tiempo.

- Modo de adquisición:

El reloj PTP está en proceso de sincronizarse con un origen de tiempo. La duración y funcionalidad de este modo son específicas de la implementación. Este modo no es necesario en la implementación.

- Modo Freq/Phase Locked:

Bloqueo de fase: el reloj PTP se sincroniza de fase con un origen de tiempo y tiene cierta precisión aceptable interna.

Bloqueo de frecuencia: el reloj se sincroniza con frecuencia con una fuente de tiempo y se encuentra dentro de cierta precisión aceptable interna.

Como se relaciona con el estado del puerto PTP definido en [IEEE 1588], un reloj se encuentra en modo bloqueado si hay un puerto PTP en estado SLAVE.

- Modo de retención:

El reloj PTP ya no está sincronizado con una fuente de tiempo y está utilizando la información obtenida mientras estaba sincronizado anteriormente u otras fuentes de información aún disponibles, para mantener el rendimiento dentro de las especificaciones deseadas o no puede mantener el rendimiento dentro de las especificaciones deseadas. El nodo puede depender únicamente de sus propias instalaciones para la retención o puede utilizar algo parecido a una entrada de frecuencia de la red para lograr una retención de tiempo o fase.

Ejemplo de configuración para 8275.1/8275.2 en NCS 540 (Cisco IOS XR)

El router permite seleccionar fuentes independientes para frecuencia y hora del día (ToD). La selección de frecuencia puede estar entre cualquier fuente de frecuencia disponible para el router, como BITS, GPS, SyncE o IEEE 1588 PTP. La selección de ToD se encuentra entre la fuente seleccionada para frecuencia y PTP, si está disponible (la selección de ToD es de GPS, DTI o PTP). Esto se conoce como modo híbrido, donde se utiliza una fuente de frecuencia física (BITS o SyncE) para proporcionar sincronización de frecuencia, mientras que PTP se utiliza para proporcionar sincronización ToD.

SyncE (para transferencia de frecuencia) y ptp (transferencia de fase/hora del día) se pueden utilizar juntos en la red mientras se implementa 8275.1 para lograr una mayor precisión (se llaman modo híbrido y es el único modo compatible para NCS a partir de la versión 7.3.x)

El atributo de prioridad local no se transmite en los mensajes de anuncio. Este atributo se utiliza como desempate en el algoritmo de comparación de conjuntos de datos, en el caso de que todos los demás atributos anteriores de los conjuntos de datos que se comparan sean iguales

8275.1:

Reloj límite

Configuración

Explicación

ptp

ptp

Reloj

dominio 24

profile g.8275.1 clock-type T-BC

El perfil 8275.1 se está utilizando con la función de reloj para ser un reloj de límite de telecomunicaciones T-BC

!

perfil T-BC-MasterClock

Defina una función para el puerto ptp.

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

Se está utilizando una dirección de multidifusión no reenviable (opcional)

transport ethernet

se está utilizando el transporte Ethernet

estado de puerto sólo MasterClock

el estado de puerto que se utilizará es sólo MasterClock

sync frequency 16

Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo

frecuencia de anuncio 8

Los paquetes anunciados se enviarán con una frecuencia de paquetes por segundo

frecuencia de solicitud de retraso 16

Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo

!

perfil T-BC-SLAVE

Defina una función para el puerto ptp.

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

Se está utilizando una dirección de multidifusión no reenviable (opcional)

transport ethernet

se está utilizando el transporte Ethernet

estado de puerto SlaveClock solamente

el estado del puerto que se utilizará es sólo SlaveClock

sync frequency 16

Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo

frecuencia de anuncio 8

Los paquetes anunciados se enviarán con una frecuencia de paquetes por segundo

frecuencia de solicitud de retraso 16

Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo

!

!

interface TenGigE0/0/0/18

Interfaz MasterClock. Puerto conectado al reloj esclavo descendente

ptp

ptp habilitado para este puerto

perfil T-BC-MasterClock

Se llama a la función definida por el usuario en este puerto ptp

prioridad local 120

atributo localPriority utilizado como desempate en el algoritmo de comparación de conjuntos de datos, en el caso de que todos los demás atributos anteriores de los conjuntos de datos que se comparan sean iguales

!

!

interface TenGigE0/0/0/19

Interfaz SlaveClock. Puerto conectado a MasterClock ascendente

ptp

ptp habilitado para este puerto

perfil T-BC-SLAVE

Se llama a la función definida por el usuario en este puerto ptp

local-priority 130

!

!

SyncE

sincronización de frecuencia

Habilitación global

Quality ITU-T Option 1

QL del reloj recibido es según la opción itu-t 1

cambios en la selección de registro

!

interface TenGigE0/0/0/19

Interfaz SlaveClock. Puerto conectado a MasterClock ascendente

sincronización de frecuencia

Habilitar syncE en la interfaz

entrada de selección

Interfaz en estado SlaveClock para SyncE

prioridad 15

de importancia local.

gestionar la selección del reloj cambiando la prioridad de las fuentes del reloj

wait-to-restore 0

La cantidad de tiempo que el router espera antes de incluir una fuente de reloj de Ethernet síncrona recientemente activa en la selección de reloj. El valor predeterminado es de 300 segundos

!

interface TenGigE0/0/0/18

Interfaz MasterClock. Puerto conectado al reloj esclavo descendente

sincronización de frecuencia

Habilitar syncE en la interfaz

wait-to-restore 0

La cantidad de tiempo que el router espera antes de incluir una fuente de reloj de Ethernet síncrona recientemente activa en la selección de reloj. El valor predeterminado es de 300 segundos

GrandMasterClock

Configuración

Explicación

ptp

ptp

Habilitación de PTP globalmente

reloj

dominio 24

profile g.8275.1 clock-type T-GM

El perfil 8275.1 se está utilizando con la función de reloj para ser T-GM telecom grand MasterClock

!

perfil T-MasterClock

Defina una función para el puerto ptp.

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

Se está utilizando una dirección de multidifusión no reenviable (opcional)

transport ethernet

se está utilizando el transporte Ethernet

estado de puerto sólo MasterClock

el estado de puerto que se utilizará es sólo MasterClock

sync frequency 16

Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo

frecuencia de anuncio 8

Los paquetes anunciados se enviarán con una frecuencia de paquetes por segundo

frecuencia de solicitud de retraso 16

Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo

!

!

interface TenGigE0/0/0/18

Interfaz MasterClock. Puerto conectado al reloj esclavo descendente

ptp

ptp habilitado para este puerto

perfil T-MasterClock

Se llama a la función definida por el usuario en este puerto ptp

prioridad local 120

atributo localPriority utilizado como desempate en el algoritmo de comparación de conjuntos de datos, en el caso de que todos los demás atributos anteriores de los conjuntos de datos que se comparan sean iguales

!

!

!

SyncE

sincronización de frecuencia

Habilitación global

Quality ITU-T Option 1

Para configurar las opciones de nivel de calidad ITU-T (QL). La opción 1 de ITU-T también es la predeterminada

cambios en la selección de registro

enable logging

!

interface TenGigE0/0/0/18

Interfaz MasterClock. Puerto conectado al reloj esclavo descendente

sincronización de frecuencia

Habilitar syncE en la interfaz

wait-to-restore 0

La cantidad de tiempo que el router espera antes de incluir una fuente de reloj de Ethernet síncrona recientemente activa en la selección de reloj. El valor predeterminado es de 300 segundos

Reloj esclavo

Configuración

Explicación

ptp

ptp

Habilitación de PTP globalmente

reloj

dominio 24

profile g.8275.1 clock-type T-TSC

El perfil 8275.1 se está utilizando con la función de reloj para ser T-TSC telecom SlaveClock

!

profile T-SLAVE

Defina una función para el puerto ptp.

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

Se está utilizando una dirección de multidifusión no reenviable (opcional)

transport ethernet

se está utilizando el transporte Ethernet

estado de puerto SlaveClock solamente

el estado del puerto que se utilizará es sólo SlaveClock

sync frequency 16

Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo

frecuencia de anuncio 8

Los paquetes anunciados se enviarán con una frecuencia de paquetes por segundo

frecuencia de solicitud de retraso 16

Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo

!

!

interface TenGigE0/0/0/19

Interfaz SlaveClock. Puerto conectado a MasterClock ascendente

ptp

ptp habilitado para este puerto

profile T-SLAVE

Se llama a la función definida por el usuario en este puerto ptp

prioridad local 120

atributo localPriority utilizado como desempate en el algoritmo de comparación de conjuntos de datos, en el caso de que todos los demás atributos anteriores de los conjuntos de datos que se comparan sean iguales

!

!

!

SyncE

sincronización de frecuencia

Habilitación global

Quality ITU-T Option 1

Para configurar las opciones de nivel de calidad ITU-T (QL). La opción 1 de ITU-T también es la predeterminada

cambios en la selección de registro

enable logging

!

interface TenGigE0/0/0/19

Interfaz SlaveClock. Puerto conectado a MasterClock ascendente

sincronización de frecuencia

Habilitar syncE en la interfaz

entrada de selección

Interfaz en estado SlaveClock para SyncE

prioridad 15

de importancia local.

gestionar la selección del reloj cambiando la prioridad de las fuentes del reloj

wait-to-restore 0

La cantidad de tiempo que el router espera antes de incluir una fuente de reloj de Ethernet síncrona recientemente activa en la selección de reloj. El valor predeterminado es de 300 segundos

!

8275.2:

Reloj límite

Configuración

Explicación

ptp

ptp

reloj

dominio 44

profile g.8275.2 clock-type T-BC

El perfil 8275.2 se está utilizando con la función de reloj para ser un reloj de límite de telecomunicaciones T-BC

!

perfil T-BC-MasterClock

Defina una función para el puerto ptp.

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

Se está utilizando una dirección de multidifusión no reenviable (opcional)

transport ipv4

se está utilizando el transporte Ethernet

estado de puerto sólo MasterClock

el estado de puerto que se utilizará es sólo MasterClock

sync frequency 16

Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo

frecuencia de anuncio 8

Los paquetes anunciados se enviarán con una frecuencia de paquetes por segundo

frecuencia de solicitud de retraso 16

Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo

!

perfil T-BC-SLAVE

Defina una función para el puerto ptp.

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

Se está utilizando una dirección de multidifusión no reenviable (opcional)

transport ipv4

se está utilizando el transporte Ethernet

estado de puerto SlaveClock solamente

el estado del puerto que se utilizará es sólo SlaveClock

sync frequency 16

Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo

frecuencia de anuncio 8

Los paquetes anunciados se enviarán con una frecuencia de paquetes por segundo

frecuencia de solicitud de retraso 16

Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo

!

!

interface TenGigE0/0/0/18

Interfaz MasterClock. Puerto conectado al reloj esclavo descendente

ptp

ptp habilitado para este puerto

perfil T-BC-MasterClock

Se llama a la función definida por el usuario en este puerto ptp

prioridad local 120

atributo localPriority utilizado como desempate en el algoritmo de comparación de conjuntos de datos, en el caso de que todos los demás atributos anteriores de los conjuntos de datos que se comparan sean iguales

!

!

interface TenGigE0/0/0/19

Interfaz SlaveClock. Puerto conectado a MasterClock ascendente

ip address 10.0.0.1 255.255.255.252

ptp

ptp habilitado para este puerto

perfil T-BC-SLAVE

Se llama a la función definida por el usuario en este puerto ptp

local-priority 130

MasterClock ipv4 10.0.0.2 255.255.255.252

Mencione explícitamente la ip de MasterClock

!

GrandMasterClock

Configuración

Explicación

ptp

ptp

Habilitación de PTP globalmente

reloj

dominio 44

profile g.8275.2 clock-type T-GM

El perfil 8275.1 se está utilizando con la función de reloj para ser T-GM telecom grand MasterClock

!

perfil T-MasterClock

Defina una función para el puerto ptp.

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

Se está utilizando una dirección de multidifusión no reenviable (opcional)

transport ipv4

se está utilizando el transporte Ethernet

estado de puerto sólo MasterClock

el estado de puerto que se utilizará es sólo MasterClock

sync frequency 16

Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo

frecuencia de anuncio 8

Los paquetes anunciados se enviarán con una frecuencia de paquetes por segundo

frecuencia de solicitud de retraso 16

Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo

!

!

interface TenGigE0/0/0/18

Interfaz MasterClock. Puerto conectado al reloj esclavo descendente

ptp

ptp habilitado para este puerto

perfil T-MasterClock

Se llama a la función definida por el usuario en este puerto ptp

prioridad local 120

atributo localPriority utilizado como desempate en el algoritmo de comparación de conjuntos de datos, en el caso de que todos los demás atributos anteriores de los conjuntos de datos que se comparan sean iguales

!

!

!

Reloj esclavo

Configuración

Explicación

ptp

ptp

Habilitación de PTP globalmente

reloj

dominio 44

profile g.8275.2 clock-type T-TSC

El perfil 8275.1 se está utilizando con la función de reloj para ser T-TSC telecom SlaveClock

!

profile T-SLAVE

Defina una función para el puerto ptp.

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

Se está utilizando una dirección de multidifusión no reenviable (opcional)

transport ipv4

se está utilizando el transporte Ethernet

estado de puerto SlaveClock solamente

el estado del puerto que se utilizará es sólo SlaveClock

sync frequency 16

Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo

frecuencia de anuncio 8

Los paquetes anunciados se enviarán con una frecuencia de paquetes por segundo

frecuencia de solicitud de retraso 16

Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo

!

!

interface TenGigE0/0/0/19

Interfaz SlaveClock. Puerto conectado a MasterClock ascendente

ip address 10.0.0.1 255.255.255.252

ptp

ptp habilitado para este puerto

profile T-SLAVE

Se llama a la función definida por el usuario en este puerto ptp

prioridad local 120

atributo localPriority utilizado como desempate en el algoritmo de comparación de conjuntos de datos, en el caso de que todos los demás atributos anteriores de los conjuntos de datos que se comparan sean iguales

MasterClock ipv4 10.0.0.2 255.255.255.252

mencionar explícitamente la ip de MasterClock

!

!

!

En caso de que no reciba paquetes ESMC en la interfaz o si SyncE no está configurado en el extremo del puerto, pero aún así desea habilitar syncE. Para ello, puede definir estáticamente el valor de QL en la interfaz e inhabilitar SSM.

SyncE

sincronización de frecuencia

Quality ITU-T Option 1

cambios en la selección de registro

!

interface TenGigE0/0/0/19

sincronización de frecuencia

ssm disable

Quality receive exactos itu-t option 1 PRC

entrada de selección

prioridad 15

wait-to-restore 0

!

Para utilizar el modo híbrido con 8275.2, utilice la ‘frecuencia de capa física’ en la interfaz. Esto habilita SyncE para la frecuencia y ptp para la fase.

Para habilitar el modo híbrido con 8275.2, la ‘frecuencia de capa física’ se debe configurar en ptp global.

ptp

reloj

dominio 44

profile g.8275.2 clock-type T-BC

!

perfil 82752

transport ipv4

sync frequency 16

frecuencia de anuncio 8

frecuencia de solicitud de retraso 16

!

physical-layer-frequency

registro

eventos servo

!

!

Topología de ejemplo 8275.1:

Dispositivo 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

!

!

Dispositivo 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

!

!

Topología de ejemplo 8275.2:

Dispositivo 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

!

!

Dispositivo 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

!

!

Solución de problemas de PTP

Algunos comandos show y describen sus salidas.

1. El estado de Servo al final del algoritmo servo debe ser Phase_Locked. Puede ver el para el flujo de estado del servo. Si el modo Servo es Híbrido, el flujo SyncE también debe atenderse, ya que el bloqueo de Fase ocurre solamente después de Freq_Lock. Si el dispositivo PTP en ejecución es un MasterClock normal, es posible que el resultado anterior no sea válido ya que el algoritmo Servo no se ejecutará y no tendrá que sincronizar la fase/frecuencia de otro origen de MasterClock.

El estado del dispositivo no pasa a LOCK a menos que el desplazamiento se encuentre dentro de un rango aceptable. Compruebe también "Offset from MasterClock".

Estado del dispositivo:

FREE-RUN/HOLDOVER: no está bloqueado a ninguna fuente de reloj.

FREQ_LOCKED: Frecuencia sincronizada con MasterClock

PHASE_LOCKED: Tanto la frecuencia como la fase se sincronizan con MasterClock

Modo Servo:

Híbrido: Utilice SyncE para la sincronización de frecuencia. El PTP se utiliza solamente para la sincronización de fase.

Predeterminado: Utilizar PTP para sincronizar tanto la frecuencia como la fase

Diferencia de tiempo observada por el algoritmo servo b/w SlaveClock y MasterClock.

Contadores para marcas de tiempo extraídas de paquetes PTP. Debería seguir aumentando.

Las últimas marcas de tiempo T1/T2/T3/T4 (sec.nanosec) extraídas de los paquetes PTP. Debe estar cerca entre sí y aumentar uniformemente.

T1/T4: Enviado por MasterClock, T2/T3: Calculado en SlaveClock

Desplazamiento Calculado en función de las marcas de tiempo PTP.

Ajustes gruesos (setTime, stepTime) y finos (adjustFreq) realizados por un servo para alinearse con el MasterClock.

3. show ptp interfaces brief muestra el estado del puerto de salida. Debe ser el estado MasterClock/SlaveClock.

4. Las caídas de paquetes por ptp deben ser significativamente bajas.

5. Verifique la razón de la caída del paquete:

6. Los paquetes no alcanzan PTP.

¿Los paquetes alcanzan la 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>

Verifique las caídas en 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> muestra el flujo de paquetes. Asegúrese de que se sigue a syncàDelay_ReqàDelay_Resp (y a Follow_Up si es un reloj de 2 pasos).

8. Compruebe el indicador (S) de la interfaz seleccionada.

9. Verifique el QL recibido. En la interfaz seleccionada, el QLsnd será DNU para evitar loops. Para modificar su preferencia de interfaz, puede cambiar el atributo priority que es 100 de forma predeterminada.

10. Asegúrese de que la "salida impulsada por" es la interfaz SyncE elegida.

11. show ptp external-MasterClocks brief es la lista de dispositivos ptp que participan en el BMCA para convertirse en MasterClocks. Marque los indicadores correspondientes para ver el reloj maestro seleccionado. Puede ver mensajes de anuncio recibidos de esos puertos a través de show ptp packet-counters <interface-id>. El dispositivo con los mejores atributos ganará la BMCA. Si varios puertos tienen los mismos atributos, la prioridad local será el último desempate. Sin embargo, el establecimiento automático de topología también es posible con ptp sin utilizar la prioridad local.

12. Ptp no selecciona el MasterClock (BMCA) deseado.

Verifique el reloj anunciado por el nodo remoto:

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

Lista de máster seleccionados y calificados:

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

Verifique el reloj anunciado en el MasterClock:

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 que no se sincroniza con el 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. Verifique si el PTP ha fallado debido a la pérdida de paquetes:

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. Verifique el resultado de show ptp configuration-errors para ver si hay errores de configuración.

Ejemplos de Capturas de Paquetes de Mensajes de Sincronización, Anuncio, Retraso_Req y Retraso_Resp

La captura del mensaje de anuncio (8275.1) muestra las características del reloj transmitido:

La captura del mensaje Sync muestra la generación de la marca de tiempo (un paso).

Información Relacionada

- https://www.itu.int/rec/T-REC-G.8275.1/en

- https://www.itu.int/rec/T-REC-G.8275.2/en

- Estándar IEEE para 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

- Soporte Técnico y Documentación - Cisco Systems