Pág. 1

IEEE 1588?

¿Qué es 1588? Su nombre completo es Precision Timing Protocol (PTP) y su origen proviene de sistemas industriales originalmente construidos para solucionar el problema de distribuir un reloj de sincronismo, a través de una red industrial, dentro de un paquete Ethernet como medio. En este modelo hay un reloj maestro cuyo tiempo es distribuido a través de la red hacia los dispositivos denominados esclavos, los cuales usan el reloj maestro para sincronizarse y mantener la escala de tiempo. ¿Por qué es tan importante el registro de la información del tiempo o del reloj ? Existen varias razones, tales como la coordinación de todas las máquinas de una línea de montaje robotizada. Por ejemplo, si uno quisiera un controlador robótico para poner el para-golpes de un auto, sería deseable que el chasis estuviera en ese lugar cuando la máquina comenzara a poner el para-golpes. Este es un ejemplo burdo, pero a medida que las máquinas se vuelven más precisas es necesaria también una mayor precisión en los tiempos. No se trata solamente de horas y minutos del día, sino de sincronizar también la frecuencia de los relojes internos entre las máquinas y, adicionalmente, la coordinación de las relaciones de las fases entre las frecuencias. Para que TOD (Time of Day), frecuencias y fases fueran factibles de ser transmitidos a través de Ethernet, se tuvieron que enfrentar muchos desafíos. Uno de ellos es la naturaleza de las redes de paquetes y cómo se comportan. Estos comportamientos ha sido muy estudiados desde su aparición décadas atrás. Las redes de paquetes tienen retrasos inherentes dentro de ellas a medida que cada nodo o elemento de la red recibe un paquete y lo retransmite. Muchas veces los nodos no procesan un paquete en el mismo tiempo, cada vez que lo hacen. Esto es particularmente comprobable cuando hay otro tráfico presente además del tráfico de temporización. Además, las redes paquetes no son muy distintas de otras redes en el sentido de que pueden tener fallas y, por lo tanto, necesitan de algún mecanismo de redundancia. Finalmente, cuando se discute en general acerca de redes de paquetes, existen varios tipos: Ethernet, TCP/IP, UDP, MPLS, etc. Éstas también son un desafío para los arquitectos de redes, quienes quieren

obtener maneras de sincronizar sus infraestructuras existentes, pero sin tener que modificar todos sus componentes para lograrlo. Entonces ¿qué es IEEE 1588v2? Los podemos separar en varios componentes. En primer lugar se encuentran los sellos ToD que son tan pequeños como sea necesario para aplicaciones de nanosegundos de resolución. Lo segundo es cómo detectar retardos en varias secciones del camino de la red de manera de permitir las compensaciones necesarias, y que puedan ser acordadas entre los nodos de la red. En tercer lugar está la redundancia para un reloj esclavo en caso de fallar la recepción de registros de tiempo del reloj maestro, donde pueda encontrar un maestro alternativo. Al final de todo se encuentran los métodos de encapsulamiento y los mecanismos para las especificidades de cada red, tales como Ethernet, MPLS, etc. En una red de paquetes, los retardos y las variaciones de éstos son factores que afectan la precisión y fases del reloj. Para enfrentar este problema, IEEE propone dos métodos. Uno es el concepto de Ordinary/Boundary Clock, donde un nodo actúa como esclavo de un reloj maestro, ajusta su reloj recuperado y luego retransmite el reloj recuperado como maestro. Esto tiene varios beneficios, en el sentido de que el reloj es ajustado antes de ser reenviado. Otra posible solución se llama Modo de Reloj Transparente, donde un nodo simplemente deja pasar la trama del protocolo, pero realiza ajustes menores en la manera en que el nodo procesa la trama antes de dejarla pasar. Hay dos métodos para esta solución. Uno es llamado one-step, donde la trama 1588 es ajustada antes de ser reenviado. El otro es llamado two-step, donde la trama 1588 es simplemente dejada pasar, pero el nodo determina los retardos de procesamiento y manda una trama de ajuste al siguiente nodo para que éste pueda hacer las correcciones necesarios a sus relojes y paquetes reenviados.

Pág. 2

Adicionalmente se encuentra el protocolo entre el maestro y el esclavo para calcular una estimación de cuán largo es el retardo que existe entre ambos a través de la red. Esto se llama protocolo Edge to Edge. El protocolo opera de una manera bastante simple, envía una trama al maestro, el cual lo devuelve lo más rápidamente posible, el esclavo registra el tiempo desde el envío hasta la recepción, también llamado round trip time. Normalmente, si uno divide este tiempo por dos obtiene la cantidad de retardo presente a lo largo del enlace. Otro protocolo llamado Peer to Peer realizó un intercambio Ethernet similar al del Edge to Edge pero entre estaciones contiguas. Esto permite estimar el retardo entre solamente dos estaciones dentro del enlace. Todo lo descripto arriba puede sonar complicado, pero es bastante simple en concepto. Si todos los retardos pueden ser detectados y contabilizados entre un maestro y un esclavo, entonces el esclavo puede tener el mismo tiempo y fase que el maestro. Existe un método desarrollado para asegurarse que el mejor reloj maestro se encuentra disponible. Se llama Best Master Clock Algorithm (BMCA). Ahí es donde los maestros deciden dentro de una red cual es el 'mejor'. Históricamente esto tiene algunas consecuencias negativas y algunas de ellas fueron resueltas en el ITU-T G.8265 Telecom Profile, donde son los esclavos quienes seleccionan de cuál maestro prefieren recibir la información. Todos estos detalles son importantes ya que todos ayudan a mejorar la precisión de la temporización, pero esto es una red de paquetes, y lo importante es la recepción confiable de paquetes con poca o ninguna variación de retardo entre el maestro y el esclavo. Aunque es más común la preocupación por el retardo (también conocido como latencia) esto puede ser usualmente compensado con protocolos y métodos de medición de retardo. El problema real son las variaciones entre los retardos o variancia. Supongamos por ejemplo que un cartero pasa siempre a las 9:00am en punto a entregar el correo. Si el cartero pasara algunos días a las 8:45 y otros a las 9:15 todavía se podría decir que pasa, en promedio, a las 9:00am. Sin embargo uno no podría estar seguro de que la hora es exactamente las 9:00 cuando pase la próxima vez. No es el retardo sino la variancia lo que importa. La variancia en redes de paquete es inevitable, pero la cuestión es cómo minimizarla. Existen dos enfoques comunes. El primero consiste en

priorizar paquetes 1588 por sobre cualquier otro tráfico que se encuentre en el mismo camino físico o lógico. De esta manera éstos siempre llegan por los mismos caminos y con los mismos retardos por cada paquete enviado. El otro mecanismo consiste en un algoritmo para que el reloj esclavo suavice las variaciones que recibe y aparecer con lo que percibe como el tiempo que considere correcto. Este algoritmo es comúnmente denominado 'servo' y usualmente toma miles de muestras a lo largo de varias horas y descarta aquellas que se encuentran fuera de una desviación promedio, y luego ajusta los relojes en función de esto. Notese que todos los nodos que almacenan y reenvían una trama 1588 introducen una cierta cantidad de variancia, en algunas implementaciones mayores que en otras. Normalmente, 10 o más nodos en un camino de red entre el maestro y el esclavo son problemáticos para la precisión de reloj, simplemente porque las variancias se acumulan para cada nodo. Por más pequeñas que sean, su sumatoria puede causar la variación suficiente para reducir la precisión al punto de que varias aplicaciones no puedan utilizarse. Clientes que quieran utilizar 1588 deben conocer el camino de su red y deben mantener menos de 10 nodos entre cada maestro y sus esclavos. Cada nodo debe, por lo menos si no es un Ordinary/Boundary Clock o Transparent Clock, priorizar el tráfico 1588. Finalmente, cada nodo debe tener un mecanismo servo de calidad y utilizar protocolos de detección y compensación de retardo. Traducción al español realizada en Argentina del documento original de Transition Networks Inc. “IEEE-1588”. Julio 2012.