Nociones básicas de PTP y SyncE con la configuración de Cisco IOS XR

Introducción

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

Antecedentes

Un reloj para nosotros es un reloj de pared o un reloj de pulsera, pero para los dispositivos de red, es una señal periódica de 0 y 1 alternativos que se utiliza para muestrear los bits de datos. Al igual que una mano de 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 ±100 ppm (partes por millón. por ejemplo, un reloj con la frecuencia de 250 MHz y 100 ppm tendrá un rango de frecuencia de 249,975 MHz a 250,025 MHz.) en la generación de la señal de reloj. Así que, idealmente, el reloj no es completamente periódico pero es suficiente para el requisito de muestrear las señales de datos fuera de las interfaces.

Las redes de telecomunicaciones (3G/4G/5G) utilizan un reloj de muy alta calidad (estrato) y todas las estaciones base (NodeB/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 base, lo cual es bastante costoso y menos seguro ya que el GPS funciona en sistemas satelitales.
• La segunda opción consiste en 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 la señal de reloj hará que sea más barato y más seguro. Sin embargo, es posible que la calidad del reloj no sea tan buena en comparación con la opción de GPS anterior y variará en el perfil/protocolo utilizado en NEs, 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 desmodularse en el extremo del receptor con la misma señal portadora utilizada en el extremo del transmisor. Si ocurre 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 portadora Rx y la onda portadora Tx.

Una analogía es utilizar una caja de seguridad para enviar un mensaje y bloquearlo con una llave. Si alguien desea leer el mensaje en el cuadro de seguridad, se debe utilizar la misma clave para desbloquear el cuadro en el extremo del receptor. Si la clave de réplica tiene distorsiones o desfiguraciones, el mensaje no se puede leer.

Las compensaciones aceptables para diversos servicios de telecomunicaciones son:

Sincronización del reloj de red

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

La sincronización para la temporización se puede categorizar en sincronización de frecuencia (lograr = / = donde = también se llama como 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 NE deberán hacer coincidir la frecuencia de su reloj con la de un reloj de origen (derivado de un MasterClock).

La sincronización de frecuencia para NE se puede lograr con SyncE o PTPv2, que se tratará más adelante 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 ningún paquete de control y no se ve afectado por la congestión de tráfico, que es el mejor aspecto de SyncE.

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

Sincronización de fase

La sincronización de fase se trata de 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 denominada Hora del día, simplemente tiene la misma hora en todos los NE. Es decir, t₁=t_2^.

NTP y PTP se utilizan para transferir información de tiempo en la red. Mientras que NTP proporciona precisión en milisegundos, PTP puede proporcionar precisión de hasta sub-microsegundos.

La sincronización de la hora y la sincronización de fase se utilizan a menudo de forma sinónima en la red, ya que el PTP utilizado para la sincronización de fase logrará la sincronización de la hora.

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

SyncE

Principio básico de SyncE

SyncE funciona según el principio básico de extraer la frecuencia de reloj de los datos recibidos en un puerto.

Aquí se muestra 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 según el principio de procesamiento inverso de la señal recibida en el puerto Rx y obtener la información de frecuencia del reloj transmitido.

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

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

En el SlaveClock NE, el reloj se recupera dentro del transceiver clock data recovery (CDR). En algunos casos en los que el reloj RX no está disponible en el transceptor, puede 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 de SlaveClock. Esta referencia de temporización se convierte en una referencia a la CEE (también conocida como referencia de temporización de línea). Como se muestra en el SlaveClock NE, un EEC puede aceptar referencias de línea y externas, así como la entrada de un oscilador local ±4.6 ppm (utilizado en situaciones donde no hay línea o referencias externas disponibles). A partir de este momento, el NE de SlaveClock se convierte en el NE de MasterClock 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 mensajes 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 Ethernet de multidifusión 01-80-C2-00-00-02 y utilizan Ether Type 88-09) para evitar que los mensajes se filtren desde un enlace sincronizado a otro enlace.

Transporta 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 de ESMC dentro de un período de cinco segundos resulta en SSF=true (QL=QL-FAILED). El valor predeterminado (inicial) para QL es DNU (SSM=1111) y solo debe cambiar cuando se reciba un TLV de QL válido.

Debemos tener en cuenta que si un dispositivo es de doble conexión y el origen de la 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 correcto con respecto a los saltos, links, etc.

La sincronización MasterClock-SlaveClock en varios NEs con múltiples entradas de sincronización posibles para la protección de la sincronización podría conducir a bucles de sincronización entre NEs. 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 de ESMC también son transportados por el protocolo lento Ethernet. LAG es otra función que utiliza protocolos lentos y LAG opera por encima de ESMC. Por lo tanto, se requiere el procesamiento de los mensajes de ESMC en cada link síncrono habilitado para Ethernet en el grupo LAG.

También es importante tener en cuenta que el uso de links paralelos, como el caso de LAG, debe ser considerado cuidadosamente debido al potencial para la creación de loops de sincronización.

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

PTPv2/1588v2

El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) definió IEEE 1588 en 2002 como 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.

El estándar 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, revisado IEEE 1588v2 en 2007, y publicado IEEE 1588v2 a finales de 2008.

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

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

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

Principio de funcionamiento básico de 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 MasterClock-SlaveClock para la distribución del reloj.

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

PTP se diseñó asumiendo un modelo de comunicación multidifusión. PTP también admite un modelo de comunicación de unidifusión, siempre que se mantenga el comportamiento del protocolo. PTP asume que los mensajes de Anuncio son enviados periódicamente por un puerto y entregados a todos los otros puertos de los relojes ordinarios o de límites dentro de una trayectoria 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 ruta 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, equipos de estado y todas las demás entidades PTP siempre se asocian a un ID de dominio determinado

El protocolo define el evento y los mensajes PTP generales. Los mensajes de eventos son mensajes temporizados, es decir, se genera una marca de tiempo precisa (hora registrada en el dispositivo en el punto de entrada/salida, pero no es necesario que el mensaje lleve el tiempo t) 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 conjuntos de datos y mensajes PTP están asociados a 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 anota la hora a la que se envió.
2. El SlaveClock recibe el mensaje Sync y anota la hora de recepción.
3. El MasterClock transmite al SlaveClock la marca de tiempo mediante:
   • Incrustar la marca de tiempo en el mensaje de sincronización. Esto requiere algún tipo de procesamiento de hardware para lograr la máxima precisión.
   • Incrustar la marca de tiempo en un mensaje de seguimiento.
4. El SlaveClock envía un mensaje Delay_Req al MasterClock y anota la hora a la que fue enviado.
5. MasterClock recibe el mensaje Delay_Req y anota la hora de recepción.
6. El MasterClock transmite al SlaveClock la marca de tiempo integrándola en un mensaje Delay_Resp.

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

PTP no detecta la asimetría. Sin embargo, si se conoce, 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 los medios de transmisión, por puentes y routers, y en sistemas grandes por las trayectorias de reenvío e inversas que atraviesan los mensajes de eventos que toman diferentes rutas a través de la red. Los sistemas deben configurarse y los componentes deben seleccionarse para minimizar estos efectos guiados por la precisión de sincronización requerida. En sistemas de subred única con distancias de unos pocos metros, la asimetría no suele ser una preocupación para las precisiones de tiempo por encima de unos pocos 10 s de ns.

Varios tipos de paquetes

El conjunto de mensajes de eventos consta de:

1. Sync: se utiliza para la sincronización de la hora entre MasterClock y SlaveClock. En Dos pasos, los mensajes de sincronización no llevan tiempo, pero éste se marcará en el MasterClock y se transportará en el mensaje Seguimiento. En un solo paso, el mensaje de sincronización llevará tiempo. Los dispositivos/hardware antiguos no eran compatibles con 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 los 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 de sincronización. Un paso es compatible con dos pasos hacia atrás.

   

2. Delay_Req: Un mensaje de Delay_Req es una solicitud del nodo de recepción/reloj esclavo para devolver la hora a la que se recibió el mensaje de Delay_Req, utilizando un mensaje de Delay_Resp. Se utilizará para calcular el tiempo de tránsito entre SlaveClock y MasterClock. Este mensaje tiene una marca de tiempo en el SlaveClock.
3. Pdelay_Req - Un mensaje Pdelay_Req es transmitido por un puerto PTP a otro puerto PTP como parte de la medición del tiempo de propagación puerto a puerto para determinar el retraso en el link entre ellos. El reloj transparente P2P lo utiliza para calcular la demora de link por salto.
4. Pdelay_Resp - Un mensaje Pdelay_Resp es transmitido por un puerto PTP en respuesta a la recepción de un mensaje Pdelay_Req.

El conjunto de mensajes generales consta de:

• Anuncio: este mensaje lo utiliza el Mejor algoritmo MasterClock (BMCA) para generar la topología MasterClock-SlaveClock. Se utiliza para elegir el mejor MasterClock y mantenerlo en su lugar.
• Seguimiento: este tipo de mensaje se utiliza en el modo de dos pasos. Lleva el tiempo. (Hora de salida de sincronización en el nodo MasterClock) en su mensaje.
• Delay_Resp - Se utiliza para calcular el tiempo de tránsito de MasterClock a SlaveClock. Transporta el tiempo (hora de salida del mensaje Delay_Resp) en el mensaje.
• Pdelay_Resp_Follow_Up - Esto es similar al mensaje Follow_Up pero es generado por un reloj P2P transparente.
• Gestión: no forma parte de nuestra discusión.
• Señalización: para la comunicación entre relojes para cualquier otro propósito. Por ejemplo, los mensajes de señalización se pueden utilizar para la negociación de la velocidad de 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 sincronización necesaria para sincronizar los relojes normales y de límite mediante el mecanismo de solicitud-respuesta de retraso.

Los mensajes Pdelay_Req, Pdelay_Resp y Pdelay_Resp_Follow_Up se utilizan para medir la demora de link entre dos puertos de reloj que implementan el mecanismo de demora de peer. El retraso de link se utiliza para corregir la información de sincronización en los mensajes Sync y Follow_Up en sistemas compuestos por relojes transparentes de igual a igual.

Los relojes ordinarios y de límite que implementan el mecanismo de retraso de par pueden sincronizarse usando los retrasos de link medidos y la información en los mensajes Sync y Follow_Up. El mensaje 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 gestión se utilizan entre nodos de gestión y relojes (no formarán parte de nuestra conversación).

Los mensajes de señalización se utilizan para la comunicación entre 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 mensajes de unidifusión entre un MasterClock y sus SlaveClocks.

Tipos de dispositivos PTP

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

1. Reloj ordinario - Solo puede ser un Grand MasterClock (GM) o solo un SlaveClock.
2. Reloj de límite - Puede ser tanto SlaveClock como 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 sale del reloj transparente.

   

   

   

4. Peer-to-peer transparent clock - Agrega el tiempo de residencia y 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 la demora de link de peer).

   

   

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

Establecer la jerarquía de MasterClock−SlaveClock

Dentro de un dominio, cada puerto de un reloj de frontera y ordinario ejecuta una copia independiente de la máquina de estado de protocolo. Para los "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 analiza el contenido del mensaje Announce y los contenidos de los conjuntos de datos asociados con el reloj ordinario o de frontera para determinar el estado de cada puerto del reloj.

Máquina de estado PTP

Cada puerto de un reloj de frontera y ordinario mantiene una copia independiente de la máquina de estado PTP. Esta máquina de estados 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 de 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 los MasterClocks de PTP 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 esclavo/reloj de frontera de escucha.
• UNCALIBRATED - El puerto recibe las marcas de tiempo de un MasterClock, pero el reloj del router aún no está sincronizado con ese MasterClock
• SLAVE - El puerto recibe las marcas de tiempo de un MasterClock, y el reloj del router se sincroniza con ese MasterClock
• PASIVO - El puerto es consciente de un reloj mejor que el que anunciaría si estuviera en el estado MasterClock, pero no está ahorrando ese reloj

Mejor algoritmo MasterClock

El mejor algoritmo MasterClock compara 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 recién descubierto (un MasterClock externo) es mejor que el propio reloj local. 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 por pares con la siguiente prioridad:

1. priority1 - Designación configurable por el usuario de que un reloj pertenece a un conjunto ordenado de relojes del que se selecciona un MasterClock
2. clockClass: atributo que define la trazabilidad TAI de un reloj
3. clockAccuracy - Un atributo que define la precisión de un reloj
4. offsetScaledLogVariance: atributo que define la estabilidad de un reloj
5. priority2 - Una designación configurable por el usuario que proporciona un orden más preciso entre relojes por lo demás 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 MasterClock externo se utiliza cuando dos mensajes de Anuncio reflejan el mismo MasterClock externo. La distancia se indica en el campo stepsRemoved (Pasos eliminados) de los mensajes de anuncio. Esta condición puede ocurrir en sistemas PTP con trayectorias cíclicas no removidas por un protocolo fuera de PTP. El algoritmo de comparación de conjuntos de datos selecciona sin ambigüedades uno de los dos relojes como "mejor" o "topológicamente mejor".

Perfiles

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

Un perfil PTP debe definir:

• Mejores opciones de algoritmo MasterClock
• Opciones de administración de configuración
• Mecanismos de retraso de ruta (peer-delay o delay request-response)
• El rango y los valores predeterminados de todos los atributos configurables de PTP y miembros del conjunto de datos
• Los mecanismos de transporte requeridos, permitidos o prohibidos
• Los tipos de nodo requeridos, permitidos o prohibidos
• Las opciones requeridas, permitidas o prohibidas

Los diversos perfiles definidos para las 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. NCS5xx/55xx admite actualmente 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 de PTP para la distribución de fase/tiempo con soporte de sincronización completa 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 la ruta del reloj del servidor al cliente sincroniza su reloj local con los dispositivos ascendentes y proporciona sincronización con los dispositivos descendentes

Tipos de nodos:

En este perfil, los tipos de nodo permitidos son los relojes normales, los relojes de límite y los 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 relojes de un paso y de dos pasos. Un reloj debe ser capaz de recibir y manejar mensajes transmitidos desde relojes de un paso y de dos pasos. No se necesita un reloj para admitir los modos de un paso y dos pasos 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

Debe prestarse apoyo a al menos uno de los dos mecanismos de transporte. Para el transporte a través de IEEE 802.3/Ethernet, es necesario que se admitan tanto la dirección de multidifusión no reenviable 01-80-C2-00-00-0E como la dirección de multidifusión reenviable 01-1B-19-00-00-00 para cumplir con este perfil

Mensajes de unidifusión/multidifusión:

Todos los mensajes se envían de forma 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 de algoritmo MasterClock:

Este perfil utiliza el BMCA alternativo.

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

Tabla 1. Jerarquía de 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 hasta una referencia GNSS (A, B mejor que C)
Precisión del reloj	¿Qué tan precisa es la salida del reloj del GM para referencia primaria? p. ej.: tiempo con una precisión de 25 ns.
Desviación de registro escalada (OSLV)	Medida de la precisión del reloj. Cuánto varía la salida del reloj cuando no está sincronizada con otra fuente.
Prioridad 2	Prioridad definida por el usuario en el nodo MasterClock si coinciden todos los parámetros anteriores
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 ruta (solicitud de retraso/respuesta de retraso):

En este perfil se utiliza el mecanismo de solicitud/respuesta de retraso. En este perfil no se debe utilizar el mecanismo de retraso del par; se debe utilizar el método delay_req-response.

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

Establecimiento automático de topología:

Al configurar los atributos localPriority definidos en esta recomendación con su valor predeterminado, la topología PTP se establece automáticamente mediante la BMCA alternativa en función de 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 fallo y la reconfiguración de la topología, se volverá a ejecutar el BMCA alternativo y se generará un nuevo árbol de sincronización. Esta operación BMCA alternativa garantiza que no se creará ningún bucle de sincronización sin necesidad de intervención manual o análisis previo de la red. El tiempo de convergencia a la nueva topología de PTP depende del tamaño de la red y de la configuración específica de los parámetros de PTP.

Planificación de red manual: el uso de los atributos locales Priority definidos en esta recomendación con valores diferentes a los valores predeterminados permite crear manualmente la topología de red de sincronización, de forma similar a como las redes de jerarquía digital síncrona (SDH) suelen funcionar en función del mensaje de estado de sincronización (SSM). Esta opción permite un control total de las acciones durante los eventos de fallo y la reconfiguración de la topología, en función de las prioridades locales configuradas del sistema. Sin embargo, se requiere una cuidadosa planificación de la red antes de la implementación para evitar bucles de sincronización.

Consideraciones sobre el uso de Priority2:

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. En esta sección se describen dos casos prácticos; otros posibles casos se estudiarán más a fondo.

• Caso 1.

Los operadores pueden configurar el atributo de prioridad PTP2 para hacer que todos los relojes de límite de telecomunicaciones (T-BC) sean trazables a un Grand MasterClock de telecomunicaciones (T-GM) o 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 están configurados con el mismo valor priority2, cada T-BC seleccionará el T-GM con la trayectoria más corta. Si los dos T-GMs están configurados con diferentes valores priority2, todos los T-BCs se sincronizarán con el T-GM con el valor priority2 más pequeño.

• Caso 2.

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

Por ejemplo, en la figura 1, 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á fallando, los T-BC de la red ascendente pueden sincronizarse con los T-BC de la red descendente, dependiendo de los valores clockIdentity de todos los T-BC. Si los T-BCs en la red ascendente se configuran con un valor de prioridad2 menor que los T-BCs en la red descendente, cuando el T-GM está en falla, los T-BCs en la red descendente se sincronizarán con los T-BCs en la red ascendente.

Operaciones sobre agregación de enlaces:

Cuando dos dispositivos que incorporan relojes PTP que cumplen con este perfil se conectan a través de una agregación de enlaces (LAG), se debe acceder a cada enlace físico directamente para transmitir mensajes PTP, omitiendo el LAG. Este método evita posibles asimetrías que pueden estar presentes cuando las trayectorias de reenvío e inversión 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 Ethernet PTP:

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

La dirección de multidifusión Ethernet que se va a utilizar depende de la política del operador; a continuación se proporcionan más consideraciones.

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

• Opción 1: uso de la dirección de multidifusión 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 reconozca PTP.

El uso de la dirección de multidifusión 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 una 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 de multidifusión reenviable es más flexible y que es preferible reenviar los mensajes PTP para mantener el link de sincronización en ejecución 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 suministrando 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 la fase y el tiempo con el Soporte de sincronización parcial (PTS) desde la red (es decir, no es necesario que cada dispositivo ejecute ptp en la red). La principal diferencia 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 necesario es UDP/IPv4.

Mensajes unidifusión:

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

En este perfil de telecomunicaciones, la negociación de unidifusión está habilitada de forma predeterminada.

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

Dominios:

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

Mejores opciones de algoritmo MasterClock:

Este perfil utiliza el BMCA alternativo.

Las propiedades lPath delay option (delay request/delay response), Automatic topology establishment y Considerations on the use of priority2 son las mismas que el perfil de telecomunicaciones 8275.1

Consideraciones sobre el transporte de PTP a través de IP en las 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 garantiza que el mensaje se envía al destino siempre que haya alguna ruta a través de la red de transporte IP desde el nodo de origen hasta la dirección de destino. La capa IP incluye protocolos de routing dinámicos que pueden adaptar la ruta a través de la red en función de los enlaces disponibles entre los routers IP. Puede ocurrir que la ruta tomada por la capa de transporte IP no sea la ruta 'esperada' por el planificador de sincronización. La aplicación de algunas restricciones en la capa de transporte IP para controlar los trayectos subóptimos para los mensajes PTP puede ser beneficiosa. Es probable que este sea el caso en las topologías de anillo.

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

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

Lo más probable es que la operación deseada sea que el SlaveClock debería cambiar a BC3 para un mejor rendimiento.

Hay algunas técnicas que se pueden emplear para asegurar que en el escenario de falla identificado arriba, el SlaveClock seleccionará BC3 como su reloj primario. Se basan en el bloqueo de los mensajes IP PTP de BC4 a SlaveClock si esos mensajes están transitando en el sentido de las agujas del reloj alrededor del anillo. La solución se basa en bloquear sólo los mensajes PTP y no 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, puede ser posible asignar direcciones IP únicas para el uso de PTP solo. Esto luego permite el uso de rutas estáticas para controlar la dirección de los flujos PTP entre los nodos. BC4 se configuraría de modo que la única ruta que se puede utilizar para alcanzar 11.x.x.141 (SlaveClock) sería el link entre BC4 y R6. Además, R6 podría configurarse de tal manera que la única ruta que se puede usar para alcanzar 11.y.y.104(BC4) sea 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 de modo que el SlaveClock no recibirá Anuncios de BC4 y el BMCA seleccionará BC3 como el reloj principal. Consulte esta imagen.

Opción 2. Filtros IP

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

En este caso, R6 se configuraría para proteger el SlaveClock de mensajes PTP que toman la ruta incorrecta. En la interfaz en R6 orientada a BC3, se puede 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 originado en BC4 que se reciba en esa interfaz será descartado. Consulte esta imagen.

Opción 3. BC Processing of All PTP Messages

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 se pueden descartar o reenviar en función de las decisiones dentro del propio proceso PTP. Las opciones podrían ser borrar el mensaje si la dirección de destino del mensaje PTP no era una dirección propiedad del BC o entregarla al motor de reenvío para enviarla al destino. Este último caso podría utilizarse si el mensaje PTP es para un dominio diferente del 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 el procesamiento de mensajes PTP, es decir, soportar la función de reloj transparente para estos mensajes. La extracción de mensajes desde el plano IP se puede realizar si el router admite el ruteo basado en políticas de 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 puede enviar paquetes PTP con el encabezado IP/Transport que lleva un campo TTL configurado al número mínimo de saltos de ruteo necesarios para alcanzar el puerto PTP par con el que tiene un contrato PTP. En una red típica sin reconocimiento de PTP que tiene routers sin reconocimiento entre MasterClock y SlaveClock, si el número de routers sin reconocimiento de PTP es mayor que el valor TTL del mensaje PTP, uno de los routers sin reconocimiento de PTP descartará el mensaje 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 más 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 una topología de anillo de este tipo, el ruteo IP se encargará de garantizar que una trayectoria más corta al MasterClock PTP se considere como una mejor ruta que la trayectoria más larga alrededor del anillo.

Por ejemplo, si un esclavoReloj tiene un MasterClock conectado directamente que también se puede alcanzar a través de una trayectoria más larga, puede utilizar el valor TTL de 1 para asegurarse de que los paquetes PTP alcanzan el MasterClock sólo a través de la trayectoria conectada directamente 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 una fuente de hora y no está en proceso de sincronización con una fuente de hora.

• Modo de adquisición:

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

• Modo Freq/Phase Locked:

Phase Lock (Bloqueo de fase): el reloj PTP está sincronizado con una fuente de tiempo y tiene una precisión interna aceptable.

Bloqueo de frecuencia (Frequency Lock): el reloj está sincronizado con una fuente de tiempo y se encuentra dentro de una precisión interna aceptable.

En lo que respecta al estado del puerto PTP definido en [IEEE 1588], un reloj se encuentra en modo bloqueado si hay un puerto PTP en estado ESCLAVO.

• Modo de mantenimiento:

El reloj PTP ya no está sincronizado con una fuente de tiempo y utiliza la información obtenida mientras estaba sincronizado anteriormente u otras fuentes de información seguían disponibles para mantener el rendimiento dentro de la especificación deseada o no pueden mantener el rendimiento dentro de la especificación deseada. Es posible que el nodo dependa únicamente de sus propias instalaciones para retenerlo o que utilice algo así como una entrada de frecuencia de la red para lograr una retención de tiempo o fase.

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

El router permite seleccionar fuentes independientes para la frecuencia y la hora del día (ToD). La selección de frecuencia puede realizarse entre cualquier fuente de frecuencia disponible para el router, como BITS, GPS, SyncE o IEEE 1588 PTP. La selección ToD se encuentra entre la fuente seleccionada para la frecuencia y PTP, si está disponible (la selección ToD se realiza desde GPS, DTI o PTP). Esto se conoce como modo híbrido, donde una fuente de frecuencia física (BITS o SyncE) se utiliza 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 denomina modo híbrido y es el único modo compatible con 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 separador 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 van a comparar sean iguales

8275.1:

	Reloj delimitador
	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 que sea un reloj T-BC de límite de telecomunicaciones
	!
	profile T-BC-MasterClock	Defina un rol 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)
	Ethernet de transporte	se está utilizando el transporte Ethernet
	port state MasterClock-only	El estado del puerto que se utilizará es sólo MasterClock
	frecuencia de sincronización 16	Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo
	frecuencia de anuncio 8	Los paquetes de anuncios se enviarán con una frecuencia de paquetes por segundo
	delay-request frequency 16	Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo
	!
	profile T-BC-SLAVE	Defina un rol 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)
	Ethernet de transporte	se está utilizando el transporte Ethernet
	port state SlaveClock-only	El estado del puerto que se utilizará es sólo SlaveClock
	frecuencia de sincronización 16	Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo
	frecuencia de anuncio 8	Los paquetes de anuncios se enviarán con una frecuencia de paquetes por segundo
	delay-request frequency 16	Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo
	!
	!
	interface TenGigE0/0/0/18	Interfaz MasterClock. Puerto conectado a SlaveClock descendente
	ptp	ptp habilitado para este puerto
	profile T-BC-MasterClock	Se llama a la función definida por el usuario en este puerto ptp
	local-priority 120	el atributo localPriority se utiliza como separador 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
	profile 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 de ti
	Quality ITU-T Option 1	El QL del reloj recibido es según la opción 1 de itu-t
	cambios de selección de registro
	!
	interface TenGigE0/0/0/19	Interfaz SlaveClock. Puerto conectado a MasterClock ascendente
	sincronización de frecuencia	Activar syncE en la interfaz
	entrada de selección	Interfaz en estado SlaveClock para SyncE
	prioridad 15	localmente significativo. gestionar la selección de reloj cambiando la prioridad de las fuentes de reloj
	wait-to-restore 0	La cantidad de tiempo que el router espera antes de incluir un origen de reloj de Ethernet síncrono recientemente activo en la selección del reloj. El valor predeterminado es de 300 segundos
	!
	interface TenGigE0/0/0/18	Interfaz MasterClock. Puerto conectado a SlaveClock descendente
	sincronización de frecuencia	Activar syncE en la interfaz
	wait-to-restore 0	La cantidad de tiempo que el router espera antes de incluir un origen de reloj de Ethernet síncrono recientemente activo en la selección del reloj. El valor predeterminado es de 300 segundos
	GrandMasterClock
	Configuración	Explicación
ptp	ptp	Habilitación global de ptp
	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
	!
	profile T-MasterClock	Defina un rol 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)
	Ethernet de transporte	se está utilizando el transporte Ethernet
	port state MasterClock-only	El estado del puerto que se utilizará es sólo MasterClock
	frecuencia de sincronización 16	Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo
	frecuencia de anuncio 8	Los paquetes de anuncios se enviarán con una frecuencia de paquetes por segundo
	delay-request frequency 16	Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo
	!
	!
	interface TenGigE0/0/0/18	Interfaz MasterClock. Puerto conectado a SlaveClock descendente
	ptp	ptp habilitado para este puerto
	profile T-MasterClock	Se llama a la función definida por el usuario en este puerto ptp
	local-priority 120	el atributo localPriority se utiliza como separador 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 de ti
	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 de selección de registro	enable logging
	!
	interface TenGigE0/0/0/18	Interfaz MasterClock. Puerto conectado a SlaveClock descendente
	sincronización de frecuencia	Activar syncE en la interfaz
	wait-to-restore 0	La cantidad de tiempo que el router espera antes de incluir un origen de reloj de Ethernet síncrono recientemente activo en la selección del reloj. El valor predeterminado es de 300 segundos
	RelojEsclavo
	Configuración	Explicación
ptp	ptp	Habilitación global de ptp
	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 un rol 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)
	Ethernet de transporte	se está utilizando el transporte Ethernet
	port state SlaveClock-only	El estado del puerto que se utilizará es sólo SlaveClock
	frecuencia de sincronización 16	Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo
	frecuencia de anuncio 8	Los paquetes de anuncios se enviarán con una frecuencia de paquetes por segundo
	delay-request frequency 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
	local-priority 120	el atributo localPriority se utiliza como separador 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 de ti
	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 de selección de registro	enable logging
	!
	interface TenGigE0/0/0/19	Interfaz SlaveClock. Puerto conectado a MasterClock ascendente
	sincronización de frecuencia	Activar syncE en la interfaz
	entrada de selección	Interfaz en estado SlaveClock para SyncE
	prioridad 15	localmente significativo. gestionar la selección de reloj cambiando la prioridad de las fuentes de reloj
	wait-to-restore 0	La cantidad de tiempo que el router espera antes de incluir un origen de reloj de Ethernet síncrono recientemente activo en la selección del reloj. El valor predeterminado es de 300 segundos
	!

8275.2:

	Reloj delimitador
	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 que sea un reloj T-BC de límite de telecomunicaciones
	!
	profile T-BC-MasterClock	Defina un rol 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
	port state MasterClock-only	El estado del puerto que se utilizará es sólo MasterClock
	frecuencia de sincronización 16	Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo
	frecuencia de anuncio 8	Los paquetes de anuncios se enviarán con una frecuencia de paquetes por segundo
	delay-request frequency 16	Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo
	!
	profile T-BC-SLAVE	Defina un rol 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
	port state SlaveClock-only	El estado del puerto que se utilizará es sólo SlaveClock
	frecuencia de sincronización 16	Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo
	frecuencia de anuncio 8	Los paquetes de anuncios se enviarán con una frecuencia de paquetes por segundo
	delay-request frequency 16	Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo
	!
	!
	interface TenGigE0/0/0/18	Interfaz MasterClock. Puerto conectado a SlaveClock descendente
	ptp	ptp habilitado para este puerto
	profile T-BC-MasterClock	Se llama a la función definida por el usuario en este puerto ptp
	local-priority 120	el atributo localPriority se utiliza como separador 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
	profile 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 dirección ip de MasterClock
	!
	GrandMasterClock
	Configuración	Explicación
ptp	ptp	Habilitación global de ptp
	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
	!
	profile T-MasterClock	Defina un rol 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
	port state MasterClock-only	El estado del puerto que se utilizará es sólo MasterClock
	frecuencia de sincronización 16	Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo
	frecuencia de anuncio 8	Los paquetes de anuncios se enviarán con una frecuencia de paquetes por segundo
	delay-request frequency 16	Los paquetes Delay_Req se enviarán con una frecuencia de paquetes por segundo
	!
	!
	interface TenGigE0/0/0/18	Interfaz MasterClock. Puerto conectado a SlaveClock descendente
	ptp	ptp habilitado para este puerto
	profile T-MasterClock	Se llama a la función definida por el usuario en este puerto ptp
	local-priority 120	el atributo localPriority se utiliza como separador 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
	!
	!
	!
	RelojEsclavo
	Configuración	Explicación
ptp	ptp	Habilitación global de ptp
	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 un rol 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
	port state SlaveClock-only	El estado del puerto que se utilizará es sólo SlaveClock
	frecuencia de sincronización 16	Los paquetes de sincronización se enviarán con una frecuencia de paquetes por segundo
	frecuencia de anuncio 8	Los paquetes de anuncios se enviarán con una frecuencia de paquetes por segundo
	delay-request frequency 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
	local-priority 120	el atributo localPriority se utiliza como separador 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 de ESMC en la interfaz o si SyncE no está configurado en el extremo del puerto, pero aún así desea habilitar syncE. Puede hacerlo definiendo estáticamente el valor de QL en la interfaz y desactivando SSM.

SyncE	sincronización de frecuencia
	Quality ITU-T Option 1
	cambios de selección de registro
	!
	interface TenGigE0/0/0/19
	sincronización de frecuencia
	ssm disable
	quality receive exact 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 ‘physical-layer-frequency’ bajo la interfaz. Esto habilita SyncE para frecuencia y ptp para fase.

Para habilitar el modo híbrido con 8275.2, se debe configurar ‘physical-layer-frequency’ bajo global ptp.

ptp

reloj

dominio 44

profile g.8275.2 clock-type T-BC

!

profile 82752

transport ipv4

frecuencia de sincronización 16

frecuencia de anuncio 8

delay-request frequency 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

 !

!

Solucionar problemas de PTP

Algunos comandos show y describen sus resultados.

1. El estado del servo al final del algoritmo del 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 se debe tener en cuenta, ya que el bloqueo de fase sólo se produce después de Freq_Lock. Si el dispositivo de ejecución PTP es un MasterClock ordinario, el resultado anterior puede no ser válido ya que el algoritmo Servo no se ejecutará y no tiene que obtener la fase/frecuencia sincronizada desde otra fuente MasterClock.

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

Estado del dispositivo:

FREE-RUN/HOLDOVER: No está bloqueado para ninguna fuente de reloj. 
FREQ_LOCKED: Frecuencia sincronizada con MasterClock

PHASE_LOCKED: frecuencia y fase sincronizadas con MasterClock

Modo servo:

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

Predeterminado: utilice PTP para sincronizar frecuencia y fase

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

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

Últimas marcas de tiempo T1/T2/T3/T4 (sec.nanosec) extraídas de paquetes PTP. Debe estar cerca el uno del otro y aumentar uniformemente.

T1/T4: enviado por MasterClock, T2/T3: calculado en SlaveClock

Desplazamiento Se calcula según las marcas de tiempo de 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 pérdidas de paquetes por ptp deben ser significativamente bajas.

5. Verifique el motivo de la caída del paquete:

6. Los paquetes no llegan a 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>

Comprobar 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 syncàDelay_RequestDelay_Resp (y Follow_Up si es un reloj de 2 pasos).

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

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

10. Asegúrese de que "Output Driven by" es la interfaz SyncE seleccionada.

11. show ptp foreign-MasterClocks brief output es la lista de dispositivos ptp que participan en el BMCA para convertirse en MasterClocks. Marque las marcas correspondientes para ver el MasterClock seleccionado. Puede ver los 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 la topología también es posible con ptp sin utilizar la prioridad local.

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

Compruebe 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 MasterClocks calificados y seleccionados:

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

Compruebe 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 no 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 PTP falló 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 la salida de show ptp configuration-errors para ver si hay errores de configuración.

Capturas de paquetes de ejemplo de mensajes Sync, Announce, Delay_Req y Delay_Resp

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

La captura del mensaje de sincronización 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