Subject: [TICTOC] RE: [ntpwg] Documents, slides, etc. from WG meeting

From: "Laurent Montini (lmontini)" <[email-masked]>
Date: Wed, 31 Oct 2007 19:21:26 +0100

Hi,

I do foresee other issues to be considered with TC, related to message
flows, message processing and state in equipments.

1- When using TC one can either use one-step or two-step mode.
One-step mode would require the TC equipment to detect PTP event
messages (e.g. SYNC message) at ingress and TS (timestamp) it (TSa).
At egress, the same eqpt would have to TS the same message again, (TSb)
calculate the internal delay (Residence Time =RT = TSb-TSa) and write
this value into the PTP payload (Correction Field: CF). TC would have to
compute RT and add RT value to any other value existing into the CF.
This demands important HW function and complex design for a large
equipment with distributed architecture.

2- With two-step mode the difference is visible at TC egress.
The TC equipment would have, at ingress, to detect PTP event messages
(as frame or packet) and TS it (same as one-step above).
At egress, the eqpt would have to TS the same message again.
However the Residence Time calculation would be done after (at least
independently of) the transmission of the event message. The RT value
would be added to the Correction Field which would be sent with a
Follow-Up (FU) general message (case of SYNC message). This solves some
design issues.

However, the process (1- or 2-step) must be done for every event
messages of every PTP session (slave-master), whatever mcast or ucast
transmission.
As I'm considering ucast, this means processing every event messages of
every master-slave pairs.

3- Considering the two-step mode (and SYNC event message only for now),
the eqpt will switch the SYNC event message then process the FU messages
for every PTP sessions.
If going thru multiple serialized TCs, the event messages will be
switched multiple times and the FU messages processed same number of
times.
It may then happen that a FU message of an event message n could arrive
after the event message n+1 or n+d due to the sum of processing delay.
That is there may be a misordering due to unequal transmission delays
into TC.
This delay will depend on (non exhaustive list):
- the transmission mode
- number of PTP sessions
- rate of the event messages
- CPU power or load of each TC
- TC node design...
The slave may rearrange using the Seq ID. This implies further
processing (not sure this is expected by IEEE1588v2 slave).

4- Last potential issue of TC is the following.
TC functions (TS and RT calculation) shall be performed for event
messages SYNC and Delay_Req in order to get a delay correction for both
directions.
The sum of residence times must be known by the slave for delay
correction computation (master does not care).
For SYNC messages, the flow is in the "right" direction. That is the RT
calculations are done by TC on the from master to slave direction. The
FU will provide the master-to-slave CF value to the slave i.e. following
the flow direction.
However for Delay_Req, the flow is slave to master. 
The CF value is thus the sum of the RT for TCs from slave to master.
In order the slave to get the slave-to-master CF value, the TCs have two
options.
If one-step mode, the RT is added in HW in the CF of the Delay_Req. (cf.
1-).
If two-step mode, the TCs will not use a FU general message (which would
be sent to master). 
Actually, every TC will hold its RT value and keep state of the RT value
for every slave-master pair session.
The TC will then wait for the Delay_Resp general message sent back to
slave by the master (for the same master-slave session) and modify the
Correction Field of the Delay_Resp message.
This requires the TC to keep state of RT values for every master-slave
session.

This can be balanced, considering the rate of Delay_Req/Resp is lower
than SYNC message rate. 
Moreover using a physical (e.g. SyncE) instead of packet-based frequency
distribution for syntonization could reduce the SYNC message rate. 

An alternative approach to avoid state in TC, would be every TC to
transmit its RT directly to slave (without waiting for the Delay_Resp
back).
If there is n times TC on the path to master, the slave should receive n
time messages for every Delay_Req.
This replaces state by message generation.

Last note about servo cascading effect.
AFAIK TC has been designed to overcome clock degration due to cascading
BC with cheap servo clock on a long chain (10's of 1588 switches).
Considering telecom network and nodes (restricting the scope to operator
management domain and thus limited number of nodes), nodes may own a
better servo clock than industrial equipment. Number of nodes between
master and slaves may also be lower than in industrial environment. 
Control loop performance may be sorted out the same way SDH or SyncE
timing chain is specified.

.lm 

> -----Original Message-----
> From: ntpwg-bounces+lmontini=[email-masked] 
> [mailto:ntpwg-bounces+lmontini=[email-masked]] On 
> Behalf Of Martin Burnicki
> Sent: dimanche 28 octobre 2007 22:50
> To: David L. Mills
> Cc: NTP Working Group
> Subject: Re: [ntpwg] Documents, slides, etc. from WG meeting
> 
> Dave,
> 
> David L. Mills wrote:
> > Guys,
> >
> > The 1588 provisions for switches and routers is called a 
> boundary clock.
> > It requires intricate management of various fixed latencies and 
> > queueing delays. 1588 NICs known to me use the Intel 
> chipset which has 
> > an onboard ARM processor very definitely provisioned by 
> firmware. As 
> > for modifying NTP to simulate the 1588 two-step protocol, a 
> > description on how to do this is in the architecture 
> briefing on the NTP project page.
> 
> The boundary clock is just _one_ possible way to eliminate 
> the latency of intermediate nodes between the grandmaster and 
> the final client. 
> 
> In the NTP world this is comparable to an NTP server running 
> on a company's firewall or router, which gets its time from 
> the outside world and serves it to the internal network.
> 
> Since each boundary clock includes a control loop, a number 
> of cascaded boundary clocks results in cascaded control 
> loops, maybe with unknown characteristics, which may let the 
> overall control loop between the final client and the 
> grandmaster become instable.
> 
> So another approach is the transparent clock, which just adds 
> to every packet how much the packet has been delayed when it 
> has traversed an intermediate node. So even if there are 
> several intermediate nodes, there's only on big control loop 
> which includes the grandmaster and the final client, which 
> can possibly easier be made stable than a number of cascaded loops.
> 
> For existing NTP installations the similar configuration is 
> when clients behind a firewall directly send queries to a 
> server in the outer world, and the queries and replies just 
> go through the firewall, though of course a firewall or 
> router would not try to compensate any latency it adds to the 
> NTP packets.
> 
> The advantages and disadvantages of boundary clocks and 
> transparent clocks for this purpose have been discussed on 
> several PTP plug fests and meetings.
> 
> Martin
> _______________________________________________
> ntpwg mailing list
> [email-masked]
> https://lists.ntp.org/mailman/listinfo/ntpwg
> 

_______________________________________________
TICTOC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tictoc