El protocolo PTP (Precision Time Protocol) está diseñado para ofrecer una sincronización horaria más precisa que otros protocolos, para aplicaciones críticas.
Mientras que NTP ofrece una precisión del orden del milisegundo, PTP apunta al microsegundo. Para lograr esta precisión, se emplean mecanismos que dependen de la capacidad de la red para transportar los mensajes de sincronización sin introducir retardos imprevisibles. Sin embargo, los equipos de red —switches y routers— introducen precisamente este tipo de retardos. El reloj transparente (Transparent Clock) es el mecanismo que contempla la norma IEEE 1588 para resolver este problema.
¿Por qué un switch degrada la precisión de PTP?
Para comprender la utilidad del reloj transparente, primero hay que entender cómo funciona la sincronización PTP. Un cliente PTP intercambia mensajes con sellado de tiempo con un servidor de referencia denominado Grandmaster. A partir de los sellos de tiempo de estos mensajes, calcula el retardo de propagación en la red y deduce la desviación entre su reloj y el del Grandmaster. Este cálculo se basa en una hipótesis: que el retardo de propagación sea estable en el tiempo.
El problema surge cuando hay un switch Ethernet en el trayecto entre el Grandmaster y el cliente. Cada mensaje de sincronización es tratado por el switch como cualquier otro paquete de red: se recibe en un puerto de entrada, se coloca en una cola de espera y, después, se reenvía por el puerto de salida. El tiempo que pasa en esta cola de espera depende de la carga de tráfico. Cuando la red está saturada, el procesamiento del paquete puede retrasarse y tardar varios microsegundos adicionales, sin que esto se mida.
Esta variación del retardo de tránsito, denominada PDV (Packet Delay Variation), falseará el cálculo del retardo de propagación realizado por el cliente PTP. Y lo que es peor, el error puede amplificarse si hay varios switches entre el Grandmaster y el cliente.
En algunos casos, la precisión de PTP se degradará hasta acercarse a la obtenida con NTP. En otras palabras, sin un mecanismo de compensación, desplegar PTP en una red estándar no aporta gran cosa.
¿Como funciona un reloj transparente?
Elreloj transparente es un mécanismo correctivo de PTP definido en la versión 2 de la norma IEEE 1588, publicada en 2008. Se utiliza para gestionar los equipos de red situados entre el Grandmaster y los clientes que se sincronizan. La idea es compensar la variación del retardo al atravesar los equipos de red midiendo dicha variación. Esta medición se comunica al cliente para que pueda tenerla en cuenta al sincronizarse.
En realidad, el principio es muy sencillo.
Cuando un mensaje PTP llega al puerto de entrada del switch, el equipo registra el instante exacto de llegada. Cuando ese mismo mensaje sale por el puerto de salida, registra el instante de salida. La diferencia entre ambos corresponde al tiempo que el mensaje ha permanecido en el equipo, es decir, el retardo variable que se busca compensar. El reloj transparente registra esta duración en un campo específico del mensaje PTP, denominado campo de corrección.
El mecanismo es acumulativo. Si el mensaje atraviesa varios relojes transparentes sucesivos, cada uno de ellos añade al campo de corrección el tiempo que tarda en atravesarlo. Así, cuando el cliente recibe el mensaje, dispone de la suma de todos los retardos introducidos por los equipos intermedios. Basta con restar este valor de su cálculo de retardo para obtener una medición precisa.
Se habla de reloj transparente porque, gracias al campo de corrección, los equipos de red se vuelven invisibles para la sincronización.
En cierto modo, el nombre de reloj transparente no es del todo acertado. De hecho, no se sincroniza por sí mismo con el Grandmaster, sino que se limita a medir un retardo y a anotar los mensajes.
Una sincronización horaria fiable para sus entornos críticos
Asegure una sincronización horaria precisa y coherente en todos sus dispositivos, sin ningún desfase.
Dos variantes: End-to-End y Peer-to-Peer
La norma PTP establece dos métodos para medir el retardo entre dos equipos: el método End-to-End y el método Peer-to-Peer. El reloj transparente gestiona los dos métodos.
El reloj transparente End-to-End (E2E) es es más habitual. Mide únicamente el tiempo de tránsito por el switch o el router y lo registra en el campo de corrección. El cálculo del retardo total entre el Grandmaster y el cliente sigue recayendo íntegramente en el cliente, que continúa intercambiando mensajes de medición de retardo con el Grandmaster, como en una red PTP clásica. Este reloj, que constituye una función de un tipo de equipo, es transparente y «pasivo» porque no modifica el funcionamiento de la sincronización, lo que facilita su despliegue.
El reloj transparente Peer-to-Peer (P2P) va más allá, pero requiere equipos más avanzados. De hecho, además del tiempo que tarda en atravesar el equipo, el reloj transparente P2P también mide el retardo de propagación en el cable que lo conecta con el equipo anterior. Para ello, intercambia mensajes de medición específicos con los equipos vecinos, en modo P2P.
Por lo tanto, el campo de corrección tiene en cuenta tanto el tiempo que tarda en atravesar el equipo como el tiempo de transmisión de la información entre los equipos. La ventaja de este enfoque es que, cuando el cliente recibe un mensaje, ya ni siquiera necesita ponerse en contacto con el Grandmaster para conocer la demora, ya que el campo de corrección contiene toda la información. Por lo tanto, el resultado es potencialmente más preciso.
¿Transparent Clock o Boundary Clock?
Esa es la cuestión que todo el mundo se plantea a la hora de diseñar una arquitectura PTP. Ambos mecanismos abordan el mismo problema, pero cada uno con una solución diferente.
El reloj transparente deja pasar los mensajes PTP y los anota. Por su parte, el Boundary Clock interrumpe la cadena PTP. En primer lugar, se sincroniza con el Grandmaster como cualquier otro cliente y, a continuación, redistribuye la hora a los equipos posteriores como si fuera el Grandmaster. De este modo, divide la red PTP en segmentos independientes
El Boundary Clock ofrece una ventaja importante para las redes de gran tamaño. Con los relojes transparentes, cada cliente intercambia sus mensajes de sincronización directamente con el Grandmaster. Cuando aumenta el número de clientes, el Grandmaster se convierte en un punto de congestión y puede provocar un fallo en el sistema de sincronización. Con el Boundary Clock, cada conmutador PTP se encarga de un subconjunto de clientes, lo que permite distribuir la carga. El algoritmo BMCA (Best Master Clock Algorithm) garantiza la selección automática del mejor servidor de referencia en caso de fallo.
Por su parte, el reloj transparente presenta la ventaja de no introducir ningún reloj adicional en la cadena de sincronización. El «Boundary Clock» es un reloj en toda regla: se sincroniza con el «Grandmaster», pero, como cualquier reloj, tiene su propia deriva.
El reloj transparente evita esta deriva. Para una red de tamaño moderado, suele ser el enfoque más adecuado. En la práctica, ambos enfoques no son excluyentes. Por ejemplo, se pueden utilizar «Boundary Clocks» en los puntos estructurales de la red y relojes transparentes en los switches de acceso.
Qué hay que saber para un despliegue correcto
Una red PTP solo alcanza su precisión teórica si todos los equipos situados en el trayecto entre el Grandmaster y los clientes son compatibles con PTP. Esto significa que cada switch debe funcionar como reloj transparente o como Boundary Clock. Un switch que tratara los mensajes PTP como tráfico ordinario introduciría una variación de retardo. Por tanto, basta con un solo equipo no compatible para degradar la precisión del conjunto del sistema.
El segundo punto se refiere a la calidad del sellado de tiempo en el switch. Para que la medición del retardo de tránsito sea fiable, el sellado de tiempo debe realizarse a nivel de hardware. Un sellado de tiempo realizado a nivel de software introduce por sí mismo variación, lo que reduce la ventaja del reloj transparente. Por tanto, al elegir un switch para un despliegue PTP, es importante comprobar que el sellado de tiempo esté integrado en el hardware.
Por último, el reloj transparente resuelve el problema de la variación del retardo en los equipos, pero no el de la asimetría de red. La asimetría consiste en que el retardo de un mensaje de ida no sea el mismo que el de un mensaje de vuelta, por ejemplo, porque los trayectos físicos son distintos. Este problema se aborda en la fase de diseño de la red, no a nivel del protocolo de sincronización.