En el pasado post analizamos el protocolo NTP para sincronización de tiempo. Hoy revisaremos el protocolo PTP (Precisión Time Protocol) está recogido en la norma IEEE 1588v2 y surgió como necesidad para aquellas aplicaciones que necesitan una precisión superior a la que nos permite el protocolo NTP. En PTP pasamos a precisiones por debajo de los microsegundos mientras en NTP podemos tener precisiones del rango de milisegundos.
El protocolo PTP se basa en una arquitectura maestro/esclavo donde ambos nodos intercambian paquetes específicos para sincronizarse entre ellos. A través de estos paquetes el sincronismo se distribuye a través de todos los nodos de la red.
BMC (Best Master Clock)
En PTP definimos dominios. Un dominio es un grupo de nodos que se sincronizan a partir de la mejor fuente de reloj disponible. El algoritmo que permite determinar cuál es esta mejor fuente de reloj se denomima BMCA (Best Master Clock Algorithm). Todos los relojes del dominio intercambian paquetes Announce entre ellos y a través de la información intercambiada deciden cuál es el mejor reloj (GMC o Grand Master Clock). La elección del GMC se basa en múltiples aspectos tales como la fuente interna de reloj, la precisión del propio nodo o la variabilidad con el tiempo de dicha referencia. Normalmente el GMC suele ser un nodo que extrae la referencia de tiempo de una señal GPS o un oscilador de gran precisión (OCXO o incluso Rubidio). En un dominio sólo puede haber un único GMC. En caso de caída o pérdida de sincronismo de este nodo, otro nodo asumirá el papel de nuevo GMC.
Tipos de relojes
En función de cómo se distribuye el reloj por los diferentes nodos de la red, éstos nodos pueden asumir los siguientes roles:
- Ordinary clock (OC): es un nodo con un único puerto PTP que funciona en modo slave. Es un nodo terminal de red que recibe la sincronización a través de este puerto slave.
- Boundary clock (BC): es uno nodo que tiene múltiples puertos PTP. A través del protocolo BMC (Best Master Clock) cada puerto identifica su mejor reloj. Si el mejor reloj es un nodo externo, dicho puerto se configurará como slave sincronizándose a partir del puerto master del nodo externo conectado. Si por el contrario el propio puerto es el mejor reloj, éste se configurará como master permitiendo la sincronización de los slaves conectados a dicho puerto. Los boundary clock actúan como elementos intermedios en la red y permiten la interconexión y sincronismo entre diferentes dominios PTP.
- Transparent clock (TC): estos nodos no participan del mecanismo BMC y por tanto no actúan propiamente como master o slave. Simplemente intentan dejar pasar los paquetes PTP de la forma más transparente posible. Hay dos tipos:
- End-to-End transparent clock (E2E): cuando un paquete PTP traspasa el nodo, se le añade a la salida el tiempo de tránsito del paquete dentro del nodo
- Peer-to-Peer transparent clock (P2P): en este caso, además del tiempo de tránsito le añadimos también el retardo del nodo anterior. De esta forma tenemos realmente el offset total de tiempo del paquete PTP desde el anterior nodo a la salida del P2P.
En la siguiente figura vemos de forma gráfico una red PTP con los diferentes tipos de relojes.
Sincronización Master / Slave
Una vez seleccionado el GMC, su reloj debe distribuirse por todos los nodos de la red a través de los paquetes PTP. La distribución se produce siempre en el sentido de master a slave y se basa en 4 tipos de mensajes.
A través de estos 4 tipos de mensajes, el puerto slave debe sincronizarse con el puerto master ajustando dos parámetros que marcan la diferencia original entre ambos relojes y que son:
- delay: es el retardo producido en la tránsito del paquete por la red desde el puerto master al puerto slave o viceversa. PTP asume retardos simétricos, es decir, que el retardo en ambos sentidos de la comunicación es el mismo
- offset: es la diferencia original en la referencia de tiempo entre ambos nodos debida a diferencias en frecuencias y precisiones internas en los nodos
Sincronismo en uno o dos pasos (one way / two-way)
Si nos fijamos en el intercambio de paquetes anterior vemos que sólo necesitamos los paquetes Sync y Delay_Req para tener los tiempos t1,t2,t3 y t4 y calcular el delay y el offset. Sin embargo, no todo es tan sencillo como veremos a continuación. t1 es la marca de tiempo en que el master envía el paquete Sync al slave. Sin embargo el paquete sufre un proceso interno en el nodo y un posible encolamiento antes de abandonar el master de forma que dicho tiempo no refleja fielmente el momento en que dicho paquete abandona efectivamente el equipo. Para minimizar este efecto PTP define un mecanismo en dos pasos (two-way) donde el master envía un segundo paquete Follow_up donde se incluye la marca de tiempo t1 una vez que ha transcurrido cierto tiempo y hemos podido verificar exactamente en qué momento enviamos el paquete Sync obviando el tiempo interno de proceso.
De igual forma, cuando el master recibe el paquete Delay_Req debe notificar al slave de cuándo lo ha recibido exactamente (t4) a través del mensaje Delay-Resp. No olvidemos que es el nodo slave el que tiene que ajustar su reloj y por tanto quien necesita conocer con precisión los valores de t1,t2,t3 y t4 para calcular el offset y el delay.
PTP es un protocolo que permite gran precisión ya que para su implementación en los nodos necesita de un hardware Ethernet específico capaz de marcar los paquetes a nivel físico con una marca de tiempo precisa. Este mecanismo unido al anterior de Follow_up nos permite compensar cualquier retardo por procesamiento o encolamiento de los paquetes PTP dentro de cada nodo. Por ello siempre debemos recordar que PTP necesita que todos los nodos a través de los cuales transmitan los paquetes de sincronismo sean PTP compliant y puedan actuar como BC, OC o TC remarcando los paquetes y compensando adecuadamente los retardos de propagación en la red.
Perfiles PTP
El protocolo PTP define una multitud de parámetros para su funcionamiento. Con el ánimo de agrupar estos parámetros y asignar posibles valores y valores por defecto a algunos de ellos se crearon los perfiles PTP.
Default Profile
Este perfil debe estar habilitado en cualquier equipo PTP. Recoge los parámetros básicos de funcionamiento de cualquier dispositivos PTP incluyendo frecuencias y retardos para los diferentes tipos de paquetes y los mecanismos de medida de retardo tanto E2E como P2P.
Telecom Profile
Este perfil se usa para el transporte de reloj entre redes de telecomunicación a través de redes de transporte Ethernet. Está recogido en la norma G.8265.1 y usa únicamente transporte unicast y medidas de retardo E2E. Asimismo asume la presencia únicamente de ordindary clocks.
Industrial Profile
Este perfil se usa para sincronización de nodos en redes industriales. Está estandarizado por IEC 62439-3 y fue también adoptado por IEC/IEEE 61850-9-3 como mecanismo de sincronismo en redes de comunicaciones en subestaciones eléctricas según IEC 61850.
Este prefil persigue una precisión igual o mejor que 1 μs después de atravesar 15 transparent clocks y asume que todos los elementos de la red (switches, routers y conversores de medio) soportan PTP
Nuestras soluciones PTP
A través de nuestro partner Digital Instruments disponemos de una familia de servidores PTP tanto en formato 19» como carril DIN. Estos equipos pueden funcionar como Grand Master Clock ya que disponen de un receptor GPS y un oscilador OCXO de gran precisión para mantener la referencia de tiempo en ausencia de señal GPS.
Incorporan los perfiles Default, Telecom e Industrial y uno configurable de forma manual.
Puedes ampliar información en nuestra página de servidores NTP y PTP
(1 votos, promedio: 5,00 de 5)
Cargando...