Timing in

Packet
Networks

Stefano RUffini – 9 June 2014

Contents
Giulio Bottari

› Background
› Frequency sync via packets
› Two-Way Time Transfer
› NTP/PTP Details
› Impairments, Packet-based Metrics for frequency and time

– Note: Special thanks to Christian Farrow (Chronos) and Kishan Shenoi (Qulsar)

PAcket Timing | 2014-05-12 | Page 2

Historical Background
Giulio Bottari

› Packet Switching network does not require sync itself

› CBR (Constant Bit Rate) services carried over ATM one of the first examples when sync aspects
discussed in relationship with packet technologies
– Definition of methodologies to recover the CBR sync rate have been defined to allow the transport of these
services over ATM (eg. 2 Mbit/s):
› Network Synchronous
› Adaptive
› Differential
› The migration of the transport network to packet networks (in particular IP), led to a generalization
of these methods,
– Need to support timing requirements of the connected networks (e.g. Mobile applications)
– Circuit Emulation detailed performance analysis
– Frequency sync distribution via dedicated protocols (NTP, PTP)
– Standardized performance objectives over reference networks (ITU-T Recc. G.8261)
› Recent increase interest to also deliver time/phase sync reference
– Packet-based technologies required
PAcket Timing | 2014-05-12 | Page 3
Circuit Emulation sync solutions: Giulio Bottari

PRC available at the Edges of thE

packet network

Differential

Network Synchronous

From ITU-T Recc. G.8261

PAcket Timing | 2014-05-12 | Page 4
Circuit Emulation: Giulio Bottari

Adaptive MEthods

From ITU-T Recc. G.8261

› No PRC traceable reference available at the edge of the packet

network !
› Frequency sync recovered based on arrival time of the packets ...
PAcket Timing | 2014-05-12 | Page 5
Packet-Based Methods

PRC
Reference

Time Stamp Time Stamp

Packet Switched
Master Processing
Network

Recovered
Time Stamp
Reference
Timing Signal

From ITU-T Recc. G.8261

› Timing information carried by dedicated timing packets:

– Network Time Protocol (NTP)
– Precision Time Protocol (PTP)
PAcket Timing | 2014-05-12 | Page 6
Adaptive Clock Operation

E1/T1 Interworking CESoP Interworking E1/T1

Bit Stream Function Function Bit Stream CBR
Packet/Cell Stream
CBR Equipment
Equipment Packet(Cell)
Service
Clock

Playout Buffer
Buffer Fill Level
Service
› Service clock adjusts based on buffer fill level/ Filter
VCO
/NCO Clock
packet arrival rate
› PDV influences wander at the network output 7

PAcket Timing | 2014-05-12 | Page 7

 From clocks to “packet Clocks”
› “Packet clocks” can be described in a similar way …
› CES Packets do have a regular rhythm
› Extension to using dedicated protocols: NTP, PTP
– NTP/PTP Packets may not arrive regularly, but timestamps within the packets
themselves mean time information can be extracted
– Timing information contained in the arrival/departure time of the packets
– Timestamps carried by the packets can be used to support this operation
– Two-way or one-way protocols
– Timing recovery process based on filtering the PDV
› Time and frequency can be distributed from point A to point B
Packets
(header, payload and footer) time

F Payload 4 H F Payload 3 H F Payload 2 H F Payload 1 H

PAcket Timing | 2014-05-12 | Page 8 Significant instants

Packet-based Equipment
Clock
PEC-S
Local reference
Time scale
comparator
Packet timing Packet Low pass filter Oscillator Output clock
signal selection

Local time
scale

G.8263-Y.1363(12)_FA.1

› Concept of «Packet Selection»:

– Pre-processing of packets before use in a traditional clock to handle PDV

PAcket Timing | 2014-05-12 | Page 9

Two-ways time transfer

› Delivery of Time synchronization requires also the knowledge of «transit delay»

from A to B
t2
tn t1
Dt
Dt ?
A B

› Two-ways transfer protocols (round trip delay)

– Assumption for symmetric channel
PAcket Timing | 2014-05-12 | Page 10
 How NTP Works
› T1 Originate Timestamp
– Time request sent by client
› T2 Receive Timestamp
– Time request received by server Client Server
› T3 Transmit Timestamp
– Time reply sent by server T1 09:00:000
› T4 Destination Timestamp
– Time reply received by client T2 09:00:005
› Round Trip Delay=(T4-T1)-(T3-T2)
– Round Trip Delay =25-10=15
› Clock Offset= [(T2-T1)-(T4-T3)]/2 T3
– Clock Offset =[5-10]/2= -2.5 09:00:015
(Clients actual time when reply received was therefore
09:00:0225) T4 09:00:025

› Key Assumptions:
– One way delay is half Round Trip (symmetry!) Time Time
– Drift of client and server clocks are small and close to same
value Corrected time
– Time is traceable 09:00:0225

PAcket Timing | 2014-05-12 | Page 11

 NTP Network Architecture
GPS
Satellite

Stratum 1
Time Server

Stratum 2
Router Router

Server Server

Stratum 3
Router

Server Server Server

Computer Computer Computer Computer Computer Computer Computer

PAcket Timing | 2014-05-12 | Page 14

 IEEE 1588-2008 PTPv2 Overview
› The Grandmaster “reference clock” sends a series of time-stamped messages to slaves.
› Slaves process the round-trip delay & synchronize to the Grandmaster.
› Frequency can be recovered from an accurate time of day reference (but L1 can also be used … )
› Best Master Clock Algorithm to define the hierarchy
› Accuracy is possible by means of:
– Proper packet rate (up to 128 per second)
– Hardware time-stamping (eliminate software processing delays)
– Timing support in the network

Embedded
Slave Packet Slave clocks can be
either stand-alone or
1588
embedded in network
Grandmaster 1588 Packets External equipment
(Server) Slave

PAcket Timing | 2014-05-12 | Page 15

Timing Support

Timing packets are terminated and regenerated by N

Timing packet Timing packet
S
N
...
...
M S
N Slave
Master
e.g. IEEE1588 Boundary Clock, NTP Stratum Clock

Latency is calculated by NE and the information is added in the timing packet

Timing packet
Timing packet
L S
S L
... ...
M S
Master N
Slave
e.g. IEEE1588 Transparent Clock
PAcket Timing | 2014-05-12 | Page 16
 PTP Time Transfer Technique
Master Clock Slave Clock Data At Round Trip Delay
Slave Clock RTD = (t2 - t1) + (t4 - t3)

Offset:
(slave clock error and one-way path delay)
OffsetSYNC = t2 – t1
Switch/Router Layer

t1 Leap second offset

OffsetDELAY_REQ = t4 – t3

t2 t2 (& t1 for 1-step)

We assume path symmetry, therefore
t1,t2 One-Way Path Delay = RTD ÷ 2

t3 t1, t2, t3 Slave Clock Error = (t2 - t1) - (RTD ÷ 2)

t4 Notes:
1. One-way delay cannot be calculated exactly, but there is
a bounded error.
t1, t2, t3, t4
2. The protocol transfers TAI (Atomic Time).
UTC time is TAI + leap second offset from the announce
message.
Time

Time

The process is repeated up to 128 times per second.

19
(Announce rate is lower than Sync rate)
PAcket Timing | 2014-05-12 | Page 19
“The Telecom Profile” (G.8265.n/G.8275.n)

› A profile is a subset of required options, prohibited options, and the ranges and defaults of
configurable attributes
– e.g. for Telecom: Update rate, unicast/multicast, etc.

› PTP profiles are created to allow organizations to specify selections of attribute values and
optional features of PTP that, when using the same transport protocol, inter-works and achieve a
performance that meets the requirements of a particular application

› Other (non-Telecom) profiles:

– IEEE C37 238 Power Distribution Industry
– 802.11AS AV bridging (AV over domestic LAN)

21
PAcket Timing | 2014-05-12 | Page 21
Impairments in Packet
networks
› Typical Impairments in the packet networks
– Packet delay variations [PDV], depending on
› Network dimension
› Traffic load
› QoS
– Path dependent aspects
› Physical path asymmetry (particularly relevant for time synchronization)
› Path rerouting
– Interactions between the packet streams

PAcket Timing | 2014-05-12 | Page 22

Packet delay variation (PDV)
› Queuing
› Equipment Configuration
› Priority/ QoS

Ingress Classification Forwarding Switch Shaping/ Egress

Interface Engines Engines Fabric Policing Interface
Engines

Potential Queuing points/ delays

Potential configuration dependent delay

points

PAcket Timing | 2014-05-12 | Page 23

Packet delay variation (PDV),
Cont.
› Head of line blocking • A packet arrives in the HPQ, just
when a packet from the LPQ has
High priority queue begun transmission
Egress link speed = G • The packet from HPQ is blocked till
Mbits/s the LPQ packet is transmitted
Low priority queue • With more complex prioritization
scheme the delay due to head of
line blocking could vary
significantly
MTU size M byte
Strict priority queue

D 
pp
M 
  s Ex. : at 100 Mbit/s, 1000 byte packet = 8 x 1000 /
max
 G  100 x 106 = 80s

PAcket Timing | 2014-05-12 | Page 24

Packet delay variation (PDV),
Cont.
Equipment implementation specifics
e.g. the Delay variation through a single piece of equipment, with packet
sizes

1024byte

576 byte
256 byte

64 byte

PAcket Timing | 2014-05-12 | Page 25

Path dependent
impairments

› Asymmetry
– Static Difference in paths between the forward and reverse paths. E.g
difference in lengths of fiber
– Forward and reverse paths pass through different node
› Rerouting
– Leads change in path delays and can “confuse” the algorithms.

PAcket Timing | 2014-05-12 | Page 26

Key Aspects of Performance
› Packet Delay Variation (PDV) is a major contributor to “clock noise”
– Related to number of hops, congestion, line-bit-rate, queuing priority, etc. Time-stamp-error
can be viewed as part of PDV
› Clock recovery involves low-pass-filter action on PDV
– Oscillator characteristics determine degree of filtering capability (i.e. tolerance to PDV)
› Higher performance oscillators allow for longer time-constants (narrower bandwidth == stronger
filtering)
› Lower performance (less expensive) oscillators may be used (may require algorithmic
performance improvements)
› Performance improvements can be achieved by
– Higher packet rate
– Controlling PDV in network (e.g. network engineering, QoS)
– Timing support from network (e.g. boundary clocks in PTP)
– Packet selection and/or nonlinear processing

PAcket Timing | 2014-05-12 | Page 30

Notion of “Best Packets”
› The impact of PDV can be mitigated by means of a suitable classification and selection of
packets
› The “minimum delay” approach is presented as an example. Depending on the network
characteristics other approaches may be more suitable
› The assumption that the path is constant over the interval of observation implies a PDV with a
distribution function with a slowly changing floor (i.e. minimum delay that a packet can
experience)
› In many cases it has been observed that a reasonable fraction (e.g. x%) of the total number of
packets will traverse the network at or near this floor
› Using only these packets in the timing recovery mechanism would allow to significantly reduce
the impact of the PDV on the quality of the recovered reference timing signal

PAcket Timing | 2014-05-12 | Page 31

Sync Metrics in Packet
Networks
› The Network Element clock output metrics (computed from TIE measurements)
can be the same (MTIE/MRTIE/TDEV)
– Clock output requirements are determined by existing (or modified) masks
– Some distinctions are required in case of packet clock integrated in the
Base Station (no standardized output MTIE/TDEV by 3GPP)
› Specific Metrics have been defined to better characterize the behavior of packet
networks (PDV) delivering the timing reference
– E.g. metrics that associate PDV with Frequency Offset or phase variation
– Tolerance masks/Network limits are used by network operators and clock
manufacturers
– Packet selection methods can be justified

PAcket Timing | 2014-05-12 | Page 32

Peak-to-peak jitter not sufficient

phase

pdf

TDEV and
minTDEV

Peak-to-peak jitter = 11.5ms Peak-to-peak jitter = 10ms

PAcket Timing | 2014-05-12 | Page 34
 Floor Packet Percentage

Family of metrics based on counting amount of packets, observed for any window
interval of t seconds within a fixed cluster range starting at the observed floor delay
and having a size δ

Floor Packet Percent (FPP) defined in terms of percentage of packets

meeting these criteria
PAcket Timing | 2014-05-12 | Page 37
Time Synchronization via PTP:
Asymmetry related impairments
› The basic principle is to distribute Time sync reference by means of
two-way time stamps exchange
M S
t1
Time Offset= t2 – t1 – Mean path delay
Mean path delay = ((t2 – t1) + (t4 – t3)) /2 t2

t3
t4

› As for NTP, also in case of PTP Symmetric paths are required:

– Basic assumption: t2 – t1 = t4 – t3
– Any asymmetry will contribute with half of that to the error in the time offset
calculation (e.g. 3 s asymmetry would exceed the target requirement of 1.5
s)
PAcket Timing | 2014-05-12 | Page 38
Asymmetry due to the
transport technologies
› Different paths in Packet networks
– Traffic Engineering rules in order to define always the same path for the forward
and reverse directions
› Different Fiber Lengths in the forward and reverse direction
– Additional problem: DCF (Dispersion Compensated Fiber)
› Different Wavelengths used on the forward and reverse direction
› Asymmetries added by specific access and transport technologies
– GPON
– VDSL2
– Microwave
– OTN
PAcket Timing | 2014-05-12 | Page 39
 Combined PTP-SyncE
• SyncE as “frequency assistance” to 1588

PRC

UTC
PTP 1588 Packet Stream PTP 1588
1588 SyncE Node SyncE Node
GM Stream SyncE Physical Layer Stream Client

PSN PRC freq

• Gives immediate “frequency lock” to 1588 client

• SyncE & 1588 functionality may be in the same node/element
• SyncE might be used for “Time sync holdover”
PAcket Timing | 2014-05-12 | Page 40
References
Giulio Bottari

› Packet Timing in ITU-T: ITU-T G.826x series, G.827x series,

› ITU-T general definitions: G.810, G.8260
› NTP: IETF RFC 5905/6/7/8
› PTP: IEEE 1588-2008
› CES: RFC 5087, RFC 5086, RFC4533, ITU-T Y.1413, ITU-T Y.1453, MEF3,
MEF 8

PAcket Timing | 2014-05-12 | Page 41

PAcket Timing | 2014-05-12 | Page 42