PTP

1. SINCRONIZACIÓN ETHERNET CON IEEE 1588

El Precision Time Protocol (PTP), incluido en el estándar IEEE 1588, fue diseñado originalmente
para proporcionar la sincronización para la automatización industrial crítica. Con la versión
2008 de este estándar (IEEE 1588v2), el PTP supera los efectos de la latencia y la fluctuación de
las cadenas de los conmutadores Ethernet, proporcionando una precisión en el rango de
nanosegundos que se requería para las redes de telecomunicaciones de alta velocidad y alta
calidad.

Legacy: Sincronización de IP con NTP

El Network Time Protocol (NTP), es uno de los protocolos más antiguos todavía en uso y goza
de gran popularidad en muchas instalaciones. Hay dos sabores disponibles:

• NTP simple o la versión completa.

• NTP simple (SNTP) que es un subconjunto

La última versión de NTP (NTPv4) generalmente puede mantener el tiempo dentro de 1 a 20

ms utilizando las soluciones tradicionales basadas en interrupciones de software en la Internet
pública. Puede lograr precisiones de microsegundos, o mejor, en LAN en condiciones ideales.
Podría decirse que NTP ha sido la solución de sincronización más popular porque se
desempeña bien en redes LAN y WAN y, al mismo tiempo, es económico y requiere muy poco
hardware.

El NTP debería poder brindar una precisión de 1 a 2 ms en una LAN y de 1 a 20 ms en una

WAN, está lejos de ser una garantía de toda la red en gran parte debido a los retrasos variables
agregados por los conmutadores y enrutadores.

Detalles del protocolo PTP

PTP requiere un reloj maestro central y relojes esclavos PTP de bajo costo en sitios remotos.
Los dispositivos de red maestros y esclavos se mantienen sincronizados mediante la
transmisión de las marcas de tiempo enviadas dentro de los mensajes PTP.

Según la cantidad de puertos que tenga un reloj de red, el estándar IEEE 1588 lo denomina
reloj ordinario (dispositivo de puerto único) o reloj de límite (dispositivo multipuerto). La
versión estándar IEEE 1588v2 también define el concepto de relojes transparentes que
mejoran la precisión de temporización cuando el protocolo se ejecuta en rutas de red que
contienen conmutadores intermedios (consulte la Tabla 1).

La ejecución de PTP tiene dos fases: 1.

Establecimiento de la Jerarquía Maestro-Esclavo. Los relojes ordinarios y de límite deciden qué

puerto tiene la función de maestro o esclavo en cada enlace con la ayuda del algoritmo del
Mejor reloj maestro (BMC). Los datos del extremo remoto de una ruta son proporcionados por
el mensaje Anunciar.

2. Sincronización de reloj. Los relojes de esclavos pueden tener compensaciones positivas o

negativas en comparación con sus amos y la latencia de amos a esclavos también se
desconoce. Los dispositivos PTP inician un procedimiento para calcular las latencias y las
compensaciones. Estos parámetros se utilizarán para ajustar la temporización en dispositivos
esclavos.

Una vez que se han establecido las jerarquías maestra y esclava, al observar la información de
la propiedad del reloj contenida en los mensajes Anunciar enviados por los dispositivos PTP, se
inicia el proceso de sincronización (consulte la Figura 2).

Antes de que se haya logrado la sincronización entre el reloj maestro y el esclavo, puede existir
un desplazamiento entre ambos relojes. Este desplazamiento se calcula con la ayuda del
mensaje de sincronización que se envía periódicamente (generalmente una vez cada unos
pocos segundos) por el maestro para actualizar la información del desplazamiento en el
esclavo. Los mensajes de sincronización pueden llevar una marca de tiempo precisa que
indique la hora de salida del propio mensaje, pero esto requiere un costoso hardware de
sellado de tiempo que puede no estar disponible. Para mejorar el protocolo, los mensajes de
seguimiento llevan marcas de tiempo para un mensaje de sincronización anterior que permite
un procedimiento de sellado de tiempo más relajado y un hardware más barato. El
procedimiento de sincronización se basa en multidifusión para permitir una transmisión y
procesamiento de mensajes más eficiente.

Sin embargo, el mecanismo de sincronización no tiene en cuenta el tiempo de propagación de

los mensajes de sincronización a través de la red. Por esta razón, el esclavo solicita una
medición de latencia con un mensaje Delay_Req. Los maestros responden a un mensaje
Delay_Req con Delay_Resp. Las marcas de tiempo que obtiene el esclavo del mecanismo de
Demora de solicitud de respuesta se utilizan para corregir la sincronización con una estimación
de tiempo más precisa.

El desafío más difícil de PTP es la operación a través de cadenas de switches Ethernet. La

mayoría de los conmutadores almacenan paquetes en la memoria local mientras se busca la
tabla de direcciones MAC y se calcula el campo de redundancia cíclica (CRC) del paquete antes
de enviarlo a los puertos apropiados. Este proceso introduce variaciones en el tiempo de
latencia del reenvío de paquetes y daña la precisión del protocolo PTP. La versión 1 del
protocolo PTP resuelve este problema implementando relojes de límites dentro de los
conmutadores. La versión 2 usa el concepto más avanzado de Peer-to-Peer Transparent Clock
para tratar el mismo problema.

Los relojes transparentes no participan en la jerarquía maestro-esclavo, pero procesan los

mensajes PTP agregando campos de corrección especiales dentro del mensaje con sus propias
estimaciones de los tiempos de residencia del paquete en el dispositivo y los retrasos de
propagación de los interlocutores remotos (que también pueden ser pares). -Peer Relojes
Transparentes). Las rutas de red en las que se emplean relojes transparentes punto a punto no
necesitan el mecanismo de solicitud / respuesta de retraso. Este mecanismo es reemplazado
por un mecanismo de corrección de ruta de igual a igual basado en los mensajes Pdelay_Req y
Pdelay_Resp y Pdelay_Resp_Follow_Up.

Protocolo de encapsulación

Los mensajes PTP pueden transmitirse a través de una gran familia de protocolos, incluidos
IPv4, IPv6, IEEE 802.3 Ethernet, DeviceNET, ControlNET e IEC 61158 Tipo 10. Las
encapsulaciones más importantes son las variaciones de IP y Ethernet (consulte la Figura 3).

Pruebas de sincronización PTP

El protocolo PTP fue desarrollado para permitir la sincronización de alta precisión en el tiempo
para servicios y protocolos de calidad Ethernet, en particular para video, las nuevas redes
móviles como LTE y datos empresariales críticos. Entonces, es saludable verificar la
sincronización periódicamente para asegurar un bajo nivel de error, a fin de mantener una
buena QoS.

Los probadores ALBEDO Ether.Sync y Ether.Genius son dispositivos que facilitan a los usuarios
verificar la conectividad, la calidad y la sincronización de las redes controladas por medio de
1588v2 PTP. Con la funcionalidad PTP, los expertos ahora pueden emular 1588v2 relojes
esclavos / maestros, y garantizar la calidad del servicio de la red al generar mensajes PTP y
medir la estabilidad de la variación de retardo de paquetes (PDV) en el tiempo, que es un
parámetro clave para mantener la calidad.

Estudio de caso I: configurar una red de sincronización PTP

El protocolo PTP requiere el establecimiento de la sincronización de tiempo entre los nodos

maestro y esclavo durante el intercambio. Este proceso ocurre constantemente para mantener
la precisión de la sincronización. Si no se establece la conectividad de los mensajes PTP, no es
posible lograr la sincronización y se deshabilita la compatibilidad con los servicios
sincronizados. Con ALBEDO Ether.Sync o Ether.Genius, los usuarios pueden emular los
mensajes PTP para verificar cómo funciona la administración de protocolo del extremo lejano
(consulte la Figura 4).

Estudio de caso II: verificar la sincronización de tiempo precisa

La precisión de la sincronización requiere un intercambio permanente de mensajes entre los

relojes maestro y esclavo. Sin embargo, las perturbaciones de la red pueden afectar la latencia
de los mensajes PTP porque tienen que pasar por las mismas colas que los paquetes de datos.
Por lo tanto, una red con alta utilización puede afectar el retraso de los mensajes PTP de
extremo a extremo y, en consecuencia, la sincronización podría degradarse.

Para controlar estos efectos se requiere medir la fluctuación de fase de los paquetes PTP
intercambiados entre los relojes maestro y esclavo. Con ALBEDO Ether.Sync o Ether.Genius, los
usuarios pueden verificar fácilmente la entrega correcta de los mensajes PTP midiendo la
estabilidad de PDV a lo largo del tiempo (consulte la Figura 5).

Estudio de caso III: Generación de deficiencias en los mensajes PTP

ALBEDO Net.Storm genera esas protuberancias típicas de IP y Carrier Ethernet para probar
mensajes PTP, dispositivos y protocolos que deben ser tolerantes con el paquete de retardo,
fluctuación de fase, pérdida, duplicación, reordenación, error y variaciones de ancho de banda.

Con Net.Storm facilita la verificación de la sincronización IEEE 1588v2 mediante la emulación

real de las condiciones de tráfico real de las redes IP que se utilizan para transportar mensajes
PTP. Por lo tanto, permite a los ingenieros modelar y modificar paquetes PTP vivos arbitrarios.

Net.Storm que puede configurar y administrar hasta 16 flujos de tráfico independientes, luego
uno de estos flujos puede programarse para filtrar mensajes PTP utilizando, por ejemplo, el
puerto PTP que se está utilizando. Luego, se puede aplicar un retardo de paquete o fluctuación
de fase específicos al tráfico PTP para observar las consecuencias en la sincronización maestro
/ esclavo.

Para configurar cualquier filtro en los mensajes PTP es importante conocer la siguiente
información>

• PTP de mensajes de encapsulación IP / UDP Puertos: 319 (evento) y 320 (general)

• Direcciones IP de multidifusión: 224.0.0.107 (mensajes de retardo entre pares), 224.0.1.129

(todos los demás mensajes).

• Ethernet Encapsulation Ethertype: 0x88F7 Direcciones MAC de multidifusión: 01-80-C2-00-

00-0E (mensajes de retardo entre iguales), 01-1B-19-00-00-00 (todos los demás mensajes)

Los usuarios de Net.Storm podrían utilizar el entorno de prueba emulado que se asemeja al
perfil de tráfico real como se observa en la red real (consulte la Figura 6).

Estudio de caso IV: Análisis de paquetes de mensajes PTP

Durante la instalación de una red IEEE 1588v2, pueden ocurrir problemas de conectividad de
mensajes PTP entre las unidades maestra y esclava. Por ejemplo, el hecho de no establecer la
conectividad de mensajes PTP hace imposible la sincronización y deshabilita el soporte para los
servicios. Al solucionar problemas de estos enlaces, ALBEDO Ether.Sync se puede usar en el
modo Terminar para capturar mensajes PTP en los puertos de prueba de transmisión y
recepción hasta 1 Gbit / s. En este modo, ALBEDO Ether.Sync genera, recibe y captura
simultáneamente mensajes PTP en el circuito bajo prueba. Los usuarios pueden identificar
rápidamente problemas de protocolo de capa superior que pueden estar asociados con
mensajes PTP y / o aprovisionamiento.
Estudio de caso V: Probar la calidad del enlace / sincronización precisa

El protocolo PTP está diseñado para funcionar en condiciones de red, incluidas las redes
altamente ocupadas. Cuando existe una gran cantidad de conflictos, el enrutamiento y la
conmutación de los mensajes PTP podrían verse afectados, lo que podría causar efectos
negativos potenciales, como la variación del retardo de paquetes en los mensajes PTP en
última instancia, afectará a la sincronización, ya que depende de la recepción constante de los
mensajes cronometrados. Tanto ALBEDO Ether.Sync como ALBEDO Ether.Genius pueden
emular el tráfico del plano de datos (hasta ocho flujos) mientras que los mensajes PTP se
transmiten simultáneamente. En estas condiciones, los ingenieros de campo pueden verificar
si la red PTP nueva o la existente pueden funcionar correctamente en diferentes escenarios de
carga (consulte la Figura 7).