IEEE 1588 Spanish

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 2

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 travs de una red industrial,
dentro de un paquete Ethernet como medio. En
este modelo hay un reloj maestro cuyo tiempo es
distribuido a travs 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
informacin del tiempo o del reloj ? Existen varias
razones, tales como la coordinacin de todas las
mquinas de una lnea de montaje robotizada.
Por ejemplo, si uno quisiera un controlador
robtico para poner el para-golpes de un auto,
sera deseable que el chasis estuviera en ese
lugar cuando la mquina comenzara a poner el
para-golpes. Este es un ejemplo burdo, pero a
medida que las mquinas se vuelven ms
precisas es necesaria tambin una mayor
precisin en los tiempos. No se trata solamente
de horas y minutos del da, sino de sincronizar
tambin la frecuencia de los relojes internos entre
las mquinas y, adicionalmente, la coordinacin
de las relaciones de las fases entre las
frecuencias.
Para que TOD (Time of Day), frecuencias y fases
fueran factibles de ser transmitidos a travs de
Ethernet, se tuvieron que enfrentar muchos
desafos. Uno de ellos es la naturaleza de las
redes de paquetes y cmo se comportan. Estos
comportamientos ha sido muy estudiados desde
su aparicin dcadas atrs. 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
trfico presente adems del trfico de
temporizacin. Adems, las redes paquetes no
son muy distintas de otras redes en el sentido de
que pueden tener fallas y, por lo tanto, necesitan
de algn mecanismo de redundancia. Finalmente,
cuando se discute en general acerca de redes de
paquetes, existen varios tipos: Ethernet, TCP/IP,
UDP, MPLS, etc. stas tambin son un desafo
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
pequeos como sea necesario para aplicaciones
de nanosegundos de resolucin. Lo segundo es
cmo 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 recepcin de registros de tiempo
del reloj maestro, donde pueda encontrar un
maestro alternativo. Al final de todo se encuentran
los mtodos 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
precisin y fases del reloj. Para enfrentar este
problema, IEEE propone dos mtodos.
Uno es el concepto de Ordinary/Boundary
Clock, donde un nodo acta 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 solucin 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 mtodos
para esta solucin. 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.

Pg. 1

Adicionalmente se encuentra el protocolo entre el


maestro y el esclavo para calcular una estimacin
de cun largo es el retardo que existe entre
ambos a travs de la red. Esto se llama protocolo
Edge to Edge. El protocolo opera de una manera
bastante simple, enva una trama al maestro, el
cual lo devuelve lo ms rpidamente posible, el
esclavo registra el tiempo desde el envo hasta la
recepcin, tambin 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 mtodo 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'.
Histricamente 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 cul maestro
prefieren recibir la informacin.
Todos estos detalles son importantes ya que
todos ayudan a mejorar la precisin de la
temporizacin, pero esto es una red de paquetes,
y lo importante es la recepcin confiable de
paquetes con poca o ninguna variacin de retardo
entre el maestro y el esclavo. Aunque es ms
comn la preocupacin por el retardo (tambin
conocido como latencia) esto puede ser
usualmente compensado con protocolos y
mtodos de medicin 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 das a las
8:45 y otros a las 9:15 todava se podra decir que
pasa, en promedio, a las 9:00am. Sin embargo
uno no podra estar seguro de que la hora es
exactamente las 9:00 cuando pase la prxima
vez. No es el retardo sino la variancia lo que
importa.
La variancia en redes de paquete es inevitable,
pero la cuestin es cmo minimizarla. Existen dos
enfoques comunes. El primero consiste en

priorizar paquetes 1588 por sobre cualquier otro


trfico que se encuentre en el mismo camino
fsico o lgico. 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
comnmente denominado 'servo' y usualmente
toma miles de muestras a lo largo de varias horas
y descarta aquellas que se encuentran fuera de
una desviacin promedio, y luego ajusta los
relojes en funcin de esto.
Notese que todos los nodos que almacenan y
reenvan una trama 1588 introducen una cierta
cantidad
de
variancia,
en
algunas
implementaciones mayores que en otras.
Normalmente, 10 o ms nodos en un camino de
red entre el maestro y el esclavo son
problemticos para la precisin de reloj,
simplemente porque las variancias se acumulan
para cada nodo. Por ms pequeas que sean, su
sumatoria puede causar la variacin suficiente
para reducir la precisin 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 trfico 1588. Finalmente, cada nodo
debe tener un mecanismo servo de calidad y
utilizar protocolos de deteccin y compensacin
de retardo.
Traduccin al espaol realizada en Argentina del documento
original de Transition Networks Inc. IEEE-1588. Julio 2012.

Pg. 2

También podría gustarte