As Garner 1588v2 Summary 0908

8/19/2019 As Garner 1588v2 Summary 0908

1/89

eo rey . arner Consultant

September 24, 2008


2/89

Outline - 1

• c now e gment

• Purpose of IEEE 1588• Status and history of IEEE 1588

• New features for Version 2

• Overview of IEEE 1588 V2• Application service interface

• Some basic PTP concepts and entities

• S nchronization basics

• Delay request-response mechanism

• Peer dela mechanism

• End-to-end transparent clocks9/24/2008

2


3/89

Outline - 2

• Peer-to-peer transparent clocks

• Time format

• Architectural choices• Best master selection

•

• General optional features

• Compatibility requirements•

• Security

• ranspor o cumu a ve requency o seinformation

9/24/2008

3


4/89

Outline - 3

• s tutor a s an up ate vers on o re erence5

9/24/2008

4


5/89

Acknowledgment

• e aut or wou e to ac now e ge anthank John Eidson for having provided

– ,slides used here were taken or adapted.

9/24/2008

5


6/89

Purpose of IEEE 1588

• IEEE 1588 is a rotocol desi ned to s nchronize real-time clocks in the nodes of a distributed system that communicateusing a network

–respective application areas)

NETWORK

9/24/2008

6


7/89

Status and History of-

• ers on pu s e as t . –on November 8, 2002

• ers on approve as s an aron May 21, 2004

• uin late 2003

–

• Version 2 PAR approved March 20, 2005• ers on ec n ca wor comp e e e ruary ,

2007

• ,closed August 8, 2007

9/24/2008

7


8/89

Status and History of

•

-

and coordination with IEEE Registration

Authorit Committee RAC occurred durin August – December, 2007

• Version 2 recirculation ballot occurred January

14 – 24, 2008• P1588 committee voted on January 31, 2008

to send version to IEEE RevCom

• Version 2 approved by RevCom on March 26,an y tan ar s oar on arc

27, 2008

• ers on pu s e as –2008 on July 24, 2008 (reference 1)

9/24/2008

8


9/89

Status and History of

•

-

– Current: industrial automation, T&M, military, power

eneration and distribution – New: consumer electronics, telecommunications

• Products V1 V2 mainl under develo ment :

microprocessors, GPS-linked clocks, boundaryclocks, NIC cards, protocol stacks, RFinstrumentation, aircraft flight monitoring

instruments• e erence n: . . , . ,

IEEE 1646-2004, LXI Consortium, ODVA

• .reference 8 for details)9/24/2008

9


10/89

New Features for Version 2-

• app ngs to v , t ernet rectmapping), DeviceNetTM, PROFINET, ControlNetTM

• orma mec an sms or message ex ens ons(using TLV)

•• Synchronization accuracies better than 1 ns

• p ons or re un ancy an au o erance

• New management capabilities and options• Higher sampling rates compared to V1; asymmetry

corrections

9/24/2008

10


11/89

New Features for Version 2-

• pt ona un cast messag ng n a t on tomulticast)

• pro es

• Conformance specifications

• Configuration options• Security (experimental specification only)

– Covered very briefly in this tutorial; see

reference 6 for more information• eans o accumu a e cumu a ve requency

scale factor offset relative to grandmaster

9/24/2008

11


12/89

Overview of IEEE 1588-

1 Scope and purpose 8 Data sets

2 Standards references 9 PTP rotocol for ordinar and boundary clocks

3 Definitions 10 PTP protocol for

4 Notation Convention 11 Clock offset, path delay,

residence time, andasymmetry corrections

5 Data types 12 Synchronization ands ntonization

6 Description of PTP protocol (Informative)

13 Message formats

9/24/2008

12


13/89


15 Management A Using the PTP protocol

16 General o tional B Timescales and e ochs features

17 State configuration C Examples of residence

corrections

18 Compatibility (V1/V2 D Transport over UDP/IPv4and V2/futureversions)

19 Conformance and PTP E Trans ort over UDP/IPv6

profilesF Transport over IEEE

9/24/2008

13.


14/89


G Transport over

DeviceNet

L Transport of cumulative

frequency scale factoroffset (experimental)

H Transport over M Bibliography

I Transport over IEC61158 Type 10

K Security protocolex erimental

9/24/2008

14


15/89

Application Service

• s s outs e t e scope oand V2), and also outside the scope of this

– However, it cannot be ignored

, ,synchronization) of the respective applicationsthat use the PTP clock must be met

• The quality of the clock delivered to the

a lication de ends on both the ualit of thePTP clock and the application serviceinterface

• See reference 7 for more information on thistopic 9/24/2008

15


16/89

Some Basic PTP Concepts-

• oma n: og ca group ng o c oc sthat synchronize to each other using the PTP

,synchronized to PTP clocks in another domain

–

• PTP clock types (will cover in more detail later)

– TM – (reference 1) for exact wording of definitions

9/24/2008

16


17/89

Some Basic PTP-

• c oc types cont. – Ordinary clock (OC): has a single PTP port in a domain

.serve as a source of time, i.e., be a master, or maysynchronize to another clock, i.e., be a slave. It may

.

– Boundary clock (BC): has multiple PTP ports in adomain and maintains the timescale used in the domain.

, . ., ,may synchronize to another clock, i.e., be a slave. It

may provide time to an application.• oun ary c oc a s a s ave as a s ng e s ave

port, and transfers timing from that port to the masterports

9/24/2008

17


18/89

Some Basic PTP-

• c oc types cont.

– Transparent clock (TC): A device that measures

the device and provides this information to clocksreceivin this PTP event messa e

• Peer-to-peer transparent clock (P2P TC): A transparentclock that, in addition to providing PTP event transit time

,delay of the link connected to the port receiving the PTP

event message. In the presence of peer-to-peer,clocks and the master clock are performed using thepeer delay measurement mechanism.

9/24/2008

18


19/89

Some Basic PTP-

• c oc types cont.• End-to-end transparent clock (E2E TC): A device

message to transit the device and provides thisinformation to clocks receiving this PTP event

. .,

propagation delay of the link connected to the portreceiving the PTP event message. It does not use the

supports use of the delay request-response

mechanism

9/24/2008

19


20/89

Some Basic PTP

•

-

egress from a node (clock) and ingress to a

node – Sync

– Delay_Req

– Pdelay_Req

– Pdelay_Resp

– Follow_Up

– Delay_Resp

– Pdelay_Resp_Follow_Up

– Announce

– Management – Signaling

9/24/2008

20


21/89

Some Basic PTP-

• commun cat on pat : e s gna ng patportion of a particular network enabling direct

clocks

–

clocks – Cannot mix end-to-end and peer-to-peer

transparent clocks on the same communication

path (except in a restricted class of topologies,. .,

9/24/2008

21


22/89

Synchronization Basics

• ep : r or o sync ron z ng, organ ze e c oc sinto a master-slave hierarchy (based on observing

Announce messages)

– Announce messages carry information used to

establish the master-slave hierarchy; they are notused for synchronization

using the delay request-response or peer delay

mechanism, by exchanging messages with itsmaster (and possibly with an upstream peer-to-peer transparent clock, if one is present)

9/24/2008

22

S h i ti B i D l


23/89

Synchronization Basics – Delay-

• n t a y, cons er t e case w ere notransparent clocks are present

• Each slave synchronizes to its master usingSync, possibly Follow_Up, Delay_Req, and

e ay_ esp messages exc ange e weenmaster and its slave

Grandmaster Clock

This clock

Slave to the

Grandmaster ClockSlave to its Master

9/24/2008

23

base for the system Slave

S h i ti B i D l


24/89


Master

time

Slave

time

t1

t

by slavet-ms

Sync

t

t3

t-sm

Follow_Up

Delay_Req t1, t2, t3

t1, t2

t4

Delay_Resp

t1, t

2, t

3, t

4

9/24/2008

24Grandmaster- M S- BC - M S- OC

S h i ti B i D l


25/89


• n er e assump on a e n s symme r c(i.e., propagation time from master to slave =

Offset = (Slave time) – (Master time) = [(t2 – t1) – (t4 – t3)]/2 = [(t-ms) – (t-sm)]/2

• Can rewrite the offset as

2 – 1 4 – 3

• If the link is not symmetric

–

2 – 1 – - –

the master-to-slave and slave-to- master propagationtimes

– e o se s n error y e erence e ween e ac uamaster-to-slave and mean propagation times9/24/2008

25

S h i ti B i D l


26/89


• s n , e e ay reques -responsemechanism works on multipoint communication

– Multicast Sync and Follow_Up messages (option for unicast)

– Delay_Req from each slave sent to master; may be unicast

– Separate Delay_Resp messages from master to each slave;may be unicast

• One-ste clock: the S nc e ress time stam iscarried in the Sync message, and Follow_Up is

not sent• Two-step clock: the Sync egress time stamp is

carried in the Follow_Up message. This option is

achieve sufficient time stamp accuracy and placethe time stamp in the message as it is transmitted. 9/24/2008

26



27/89

Synchronization Basics –

•

-

,transparent clocks are present

•Sync, possibly Follow_Up, Pdelay_Req,

_ ,

Pdelay_Resp_Follow_Up messagesexchan ed between master and its slave

Grandmaster Clock

This clock

Slave to the

Grandmaster ClockSlave to its Master

9/24/2008

27

determines the time

base for the system

and Master to its

Slave



28/89


Master

time

Slave

time

t

Timestamps known

by slave

t2

t-ms

Follow_Upt2

t1, t

2

t4

t3t-sm Pdelay_Req t3

Pdelay_Respt5

t6Pdelay_Resp_Follow_Up

t6

t3, t

4,t5, t

6

9/24/2008

28Grandmaster- M S- BC - M S- OC



29/89

Synchronization Basics – -

• n er e assump on a e n s symme r c(i.e., propagation time from master to slave =

Offset = t2 – t1 – (propagation time) = (t-ms) – (propagation time)

• If the link is not symmetric

–

4 – 3 6 – 5

the master-to-slave and slave-to- master propagationtimes

–master-to-slave and mean propagation times

9/24/2008

29



30/89


• e peer e ay mec an sm s m te to po nt-to-point links between two ordinary clocks,

, - -transparent clocks

–

for the clock that receives Pdelay_Req to keeptrack of which clock it receives the messagerom, an respon separa e y o eac c oc

• The mechanism is symmetric, i.e., it operatesy

9/24/2008

30



31/89


• ne-step c oc : e ync t mestamp scarried in the Sync message, and Follow_Up

. _carries the turnaround time, t5 – t4, andPdela Res Follow U is not sent. _ _ _

9/24/2008

31



32/89


• wo-step c oc : e ync t mestamp scarried in the Follow_Up message.

• er

• (a) the turnaround time, t5 – t4, is carried in _ _ _ ,

• (b) t5 is carried in Pdelay_Resp_Follow_Upand t is carried in Pdela Res . _

• This option is useful in cases where it is not

possible both to achieve sufficient time stampaccuracy an p ace e me s amp n emessage as it is transmitted.

9/24/2008

32

End-to-End Transparent


33/89

End-to-End Transparent-

• ne a erna ve o p ac ng an or a everynode in a 1588 network is to use E2E TCs

-hierarchy, i.e., it does not synchronize to thegrandmaster (GM)

– Instead, an E2E TC forwards Sync and correspondingFollow_Up messages on all ports not blocked by any

. .,protocol (RSTP) operating in an IEEE 802 bridged LAN)

• The E2E TC time stamps the Sync message onngress an egress, an compu es e me a en orthe message to traverse the node (termed theresidence time)

9/24/2008

33



34/89

End to End Transparent-

9/24/2008

34



35/89


• e res ence t me s accumu ate n a e othe Sync (one-step clock) or Follow_Up (two-

Message at ingress Message at egress

Preamble

PTP message

payloadNetwork

protocol

headersCorrection field

Preamble

PTP message

payloadNetwork

protocol

headersCorrection field

++

- +Ingress timestamp Egress timestamp

9/24/2008

35



36/89


• ac s ave uses e cumu a ve res ence me n ecomputation of propagation time from the master

– , ,Follow_Up, and Delay_Resp messages are subtracted in thenumerator

– e o se s g ven y 2 m nus 1 m nus propaga on me

minus Sync correction field minus Follow_Up correction field

• The residence time measurement does not re uirethat the E2E TC be time-synchronized to the master

– This is because the residence time is a time interval• However, the residence time measurement will be in

error if the rate of the E2E TC differs from the GM

– The resulting synchronization error is equal to the fractionalfrequency offset multiplied by the residence time 9/24/2008

36



37/89


• If this error is unacceptably large, the E2ETC clock may optionally be syntonized,.e., sync ron ze n requency, o e

– This may be done by using the egress time. .,

fields in the successive Sync and Follow_Upmessages, and the ingress time stamps ofthese Sync messages, to measure elapsedtime of the master and corresponding elapsed

– These two elapsed times may be used toobtain an estimate of the fre uenc offset of

the TC relative to the master 9/24/2008

37



38/89


• oes not spec y ow t einformation contained in the egress time

Sync and Follow_Up messages, and in thein ress time stam s of those S nc messa es

is to be used to accomplish the Syntonization – This is consistent with the fact that IEEE 1588

(V1 and V2) does not specify how thecomputed offset is used to synchronize OCs

9/24/2008

38



39/89

p-

– e a e spec ca ons o w e er o syn on ze,and how, is the subject of PTP profiles and

• Syntonization may be done in hardware,e.g., by physically adjusting the TC oscillator

frequency, or in software, e.g., by using themeasured frequency offset in the residence

9/24/2008

39

Peer-to-Peer Transparent


40/89

p-

• e measures res ence t me o aSync and Delay_Req message through the TC

– owever, propaga on me e ween e mas erand slave is measured using the delay request-res onse mechanism

– If the master changes, propagation time from theslave to the new master must be measured

– This results in a longer transient during the

network reconfiguration• The P2P TC, in addition to measuring the

residence time of the Sync message, measures, ,

using the peer delay mechanism9/24/2008

40



41/89

p-

• e e ay measurement s ma e on every nin both directions, including links that are

. .,rapid spanning tree protocol)

–

immediately available on links newly used aftera change of GM or network reconfiguration

• The cumulative residence plus propagation

time is accumulated in a field of the Syncone-s ep c oc or o ow_ p wo-s ep c ocmessages

9/24/2008

41



42/89

p-

Peer-to-peer

Transparent Clock

9/24/2008

42



43/89

p-

• e o se e ween e s ave an mas er s g ven y

Offset = t2 – t1 – (Sync correction field) – (Follow_Up correction

• As with E2E TCs, P2P TCs may optionally be

–

syn on ze o e mas er n ar ware or n so ware

• If the P2P TCs are not syntonized to the GM, there will

the sum of two terms:

– turnaround time (Pdelay_Resp egress time minus Pdelay_Reqingress time) multiplied by the fractional frequency offsetbetween the adjacent clocks that exchange Pdelay messages

– _

to the master, multiplied by the measured propagation time9/24/2008

43

Peer-to-Peer


44/89

-

• t e s are not synton ze , t e rstterm may be computed by measuring the

using the egress and ingress time stamps ofthe successive Pdela Res messa es _

received by the sender of Pdelay_Req – The resulting propagation time will still be in

error by an amount equal to the second term inthis case

• or many app ca ons, s error .e.,relative propagation delay error) may besufficientl small e. . 10-4 or smaller since

the free-run frequency accuracy of PTPclocks is specified as ±100 ppm (10-4 )) 9/24/2008

44

Time Format


45/89

Time Format

struct Timestamp

UInteger48 seconds;

UInteger32 nanoseconds;

Integer64 correctionField; /* nanoseconds × 216 */

9/24/2008

45

Architectural choices - 1


46/89


• a ows or a var e y o arc ec ures,each based on choices of clock(s) and delay

• As stated earlier – P2P TCs use the peer delay mechanism

– E2E TCs use the delay request-response mechanism – OCs can use either mechanism within a domain (but a vendor

is not re uired to im lement both mechanisms

– BCs can use either mechanism on any port within a domain(but a vendor is not required to implement both mechanisms on

all orts

– The two delay mechanisms do not mix

– P2P and E2E TCs cannot be mixed on the same, , . .,

chains where each E2E TC has only 2 ports and no collocatedOC

9/24/2008

46



47/89

Architectural choices 2

• erarc ca topo ogy examp e gure ta enfrom reference 1)

– ses s an s

– The cyclic path (indicated by the dashed line) is

appears to not be present to PTP

Boundary Clock-1 Cyclic path

Boundary Clock-3Boundary Clock-2Ordinary Clock-1 Ordinary Clock-2

9/24/2008

47Ordinary Clock-6Ordinary Clock-4Ordinary Clock-3 Ordinary Clock-5



48/89


• near opo ogy examp e gure a en rom re erence – Uses BC, OCs, and E2E TCs, arranged in linear chains

– - separately between each OC and BC-1

Boundary Clock-1

A Grandmaster clock

End-to-endTransparent

- -

Ordinary Clock-1

Ordinary Clock-1-1

BCyclic path

End-to-endTransparent

- -

Ordinary Clock-2-1

End-to-end

TransparentOrdinary Clock-1-2

End-to-end

Transparent Ordinary Clock-2-2

C

Clock-1-2 Clock-2-2

.

.

.

.

.

.

9/24/2008

48End-to-endTransparent

Clock-1-n

Ordinary Clock-1-n T

End-to-end

Transparent

Clock-2-n

Ordinary Clock-2-n

S



49/89


• u p y connec e opo ogy examp e gure a enfrom reference 1)

– , – Propagation time measured on each link using peer delay

mechanismGrandmaster clock

Peer-to-peer

Transparent

Clock-1-1

Ordinary Clock-1-1

Peer-to-peer

Transparent

Clock-2-1

A

Peer-to-peer

Transparent

Clock-m-1

B ...

Peer-to-peer

Transparent

Clock-1-2

Ordinary Clock-1-2 D

Peer-to-peer

Transparent

Clock-2-2

Peer-to-peer

Transparent

Clock-m-2

E ...

F

.

.

.

.

.

.

.

.

.

9/24/2008

49

Peer-to-peer

TransparentClock-1-n

Ordinary Clock-1-n

Peer-to-peer

TransparentClock-2-n

Peer-to-peer

TransparentClock-m-n...



50/89


• Bridging disparate technologies using BC

(figure taken from reference 1)

– Links A use UDP/IPv4, links B use DeviceNet

– BC-2 bridges the two technologies

Ordinary

Clock-1

M

Ordinary

Clock-2

S

S

1

3 MBoundaryClock-1

M 2

M

1

3 MBoundaryClock-2

S 2OrdinaryClock-3

S OrdinaryClock-4

S

A

A A

B

B

4

M

4

M

A B

9/24/2008

50

Ordinary

Clock-5

Ordinary

Clock-6

Best Master Selection - 1


51/89

Best Master Selection 1

• uses a e au t est aster ocalgorithm (BMCA) that is similar to the V1 BMCA

• a n erences

– In V2, best master selection information is sent, ,

synchronization-related information• This enables a much smaller S nc messa e

with higher Sync message rates using less

bandwidth (important for some applications) – V1 stratum is renamed clock class (to distinguish

from use of ‘stratum’ in telecom); many more of the. .,

reserved)9/24/2008

51



52/89

• a n erences con .

– V1 clock identifier is replaced by clock accuracy, which

technology

• An information-only attribute, time source, that indicatese na ure o e source o me, s a e

– Variance is replaced by (offset) scaled log variance,but is essentiall the same

– V1 notion of a clock being preferred for GM is replaced

by 2 priority fields, each of which has 256 levels• Priority1 takes precedence over all other attributes

• Priority2 is considered after class, clock accuracy, andscaled lo variance

9/24/2008

52



53/89

• a n erences cont.

– Whereas V1 would partition the network into

of low enough stratum was present, V2 will notartition the network

• instead, all clocks of higher class willsynchronize to a single GM, and otherpo en a s o ow enoug c ass c ass128 or lower) will free-run but not

9/24/2008

53



54/89

Clock attributes considered in the order iven

1. priority1(256 levels)

.3. accuracy (clockAccuracy)

.

(offsetScaledLogVariance).

6. identifier (IEEE EUI-64) (clockIdentity)

o es: var ance s equa o an var ancemultiplied by τ2/3, where τ is the sampling

.

EUI-48 using IEEE mapping rules9/24/2008

54



55/89

(decimal)0 Reserved to enable compatibility with future versions.

- eserve

6 Shall designate a clock that is synchronized to a primary reference time source. The timescale distributed shall be

PTP. A clockClass 6 clock shall not be a slave to another clock in the domain.

7 Shall designate a clock that has previously been designated as clockClass 6 but that has lost the ability to

synchronize to a primary reference time source and is in holdover mode and within holdover specifications. The

timescale distributed shall be PTP. A clockClass 7 clock shall not be a slave to another clock in the domain.

8 Reserved

9-10 Reserved to enable compatibility with future versions.

11-12 Reserved

13 Shall designate a clock that is synchronized to an application specific source of time. The timescale distributed

shall be ARB. A clockClass 13 clock shall not be a slave to another clock in the domain.

14 Shall designate a clock that has previously been designated as clockClass 13 but that has lost the ability to

synchronize to an application specific source of time and is in holdover mode and within holdover specifications.

The timescale distributed shall be ARB. A clockClass 14 clock shall not be a slave to another clock in the domain.

15-51 Reserved

9/24/2008

55

52 Degradation alternative A for a clock of clockClass 7 that is not within holdover specification. A clock of

clockClass 52 shall not be a slave to another clock in the domain.

53-57 Reserved



56/89

(decimal)58 Degradation alternative A for a clock of clockClass 14 that is not within holdover specification. A clock of

clockClass 58 shall not be a slave to another clock in the domain.

- eserve

68-122 For use by alternate PTP profiles

123-127 Reserved

128-132 Reserved


171-186 Reserved

187 Degradation alternative B for a clock of clockClass 7 that is not within holdover specification. A clock of

clockClass 187 may be a slave to another clock in the domain.188-192 Reserved

193 Degradation alternative B for a clock of clockClass 14 that is not within holdover specification. A clock of

clockClass 193 may be a slave to another clock in the domain.

194-215 reserved

9/24/2008




57/89

clockClass

decimal

Specification

233-247 Reserved

248 Default. This clockClass shall be used if none of the other clockClass definitions apply.

- eserve

251 Reserved for version 1 compatibility, see Clause 18.

252-254 Reserved

255 Shall be the clockClass of a slave-only clock, see 9.2.2.

9/24/2008

57



58/89

Value hex S ecification

oc accuracy

00-1F reserved

20 The time is accurate to within 25 ns

21 The time is accurate to within 100 ns

22 The time is accurate to within 250 ns23 The time is accurate to within 1 us

24 The time is accurate to within 2.5 us

25 The time is accurate to within 10 us




29 The time is accurate to within 1 ms

2A The time is accurate to within 2.5 ms

2C The time is accurate to within 25 ms

2D The time is accurate to within 100 ms

2E The time is accurate to within 250 ms

2F The time is accurate to within 1 s

30 The time is accurate to within 10 s

31 The time is accurate to >10 s

32-7F reserved

80-FD For use by alternate PTP profiles

9/24/2008

58

FE Unknown

FF reserved



59/89

- used in BMCA)

Value (hex) Time source Description

10 ATOMIC_CLOCK Any device, or device directly connected to such a device, that is based on atomic

resonance for frequency and that has been calibrated against international

standards for frequency and, if the PTP timescale is used, time

20 GPS Any device synchronized to a satellite systems that distributes time and frequency

tied to international standards

30 TERRESTRIAL_RADIO Any device synchronized via any of the radio distribution systems that distribute

time and frequency tied to international standards

40 PTP Any device synchronized to a PTP-based source of time external to the domain

ny ev ce sync ron ze v a or mp e e wor me ro oco o

servers that distribute time and frequency tied to international standards

60 HAND_SET Used for any device whose time has been set by means of a human interface

based on observation of an international standards source of time to within the

claimed clock accuracy

A0 INTERNAL_OSCILLATOR Any device whose frequency is not based on atomic resonance nor calibrated

against international standards for frequency, and whose time is based on a free-

running oscillator with epoch determined in an arbitrary or unknown manner

F0-FE For use b alternate PTP

9/24/2008

59

profiles

FF Reserved



60/89

‘ event’ (referred to as a STATE_CHANGE_EVENT in V1)

9/24/2008

60


61/89

Compare dataset A to B

GM Identity of A

=GM Identity of B

No

XYes

Compare

GM priority1 values of A and B

A B

Compare

GM class values of A A B

Dataset comparison algorithm - 1

and B

Compare

GM accuracy valuesof A and B

A B

A = B

Compare

GM offsetScaledLogVariance

values of A and B

A B

A = B

A = B

CompareGM priority2 values of

A and B

A B

A = B

9/24/2008

61

Return A better than B

ReturnB better than A

CompareGM identity values of

A and B

A B

62/89

X

Compare Steps

Removed of

A and B

A + 1 B + 1Return

A better than BReturn

B better than A

Dataset comparison

algorithm - 2Compare Steps

Removed of

A within 1 of B

Compare Identities

of Receiver of B and

Compare Identities

of Receiver of A and

Receiver < Sender

A > B

Receiver < Sender

A Sender Receiver > Sender

Return

A better by

topology than B

Return

B better by

topology than A

Identities of

Senders of

A and B

A B

A B

Compare

Port Numbers of

Receivers of

A and B

Receiver = Sender Receiver = Sender

9/24/2008

62

A = B

error-2 error-1error-1


63/89

• n a t on, a ows a pro eto specify an alternate BMCA

– ere are requ remen s on any a erna eregarding updating of states and data sets (seereference 1 for details

• IEEE 1588 V2 uses the same BC and OCstate machines as V1, with some correctionsthat were identified since V1 was published

• IEEE 1588 V2 does not specify detailed statemachines for TCs

• Many aspects of TC behavior can be specifiedn a pro e

9/24/2008

63

PTP Profiles and-


64/89

• urpose o pro es – Allow specific selections of attribute values and optional

,transport protocol, interworking and desired performancelevels will be ensured

•

meet the requirements of a particulara lication

• Recommended that a PTP profile define

– BMCA option – Configuration and node management options

– Path delay measurement option (peer delay or delay-

9/24/2008

64

PTP Profiles and-


65/89

• ecommen e t at a pro e e ne cont.

– Range and default values of all configurable

– Transport mechanisms required, permitted, or

– Node types required, permitted, or prohibited – O tions re uired ermitted or rohibited

– Procedure used to verify conformance

9/24/2008

65

PTP Profiles and-


66/89

• n a t on, spec es ow aprofile can extend the standard (i.e.,

, ,specifications):

–

– Optional BMCA –

– Use of a unicast messaging model provided the

behavior of the PTP protocol is preserved• Profiles are created by standards

organizations, industry trade associations,

companies, or other “appropriate”organizations9/24/2008

66

PTP Profiles and-


67/89

• wo e au pro es are prov e n nnex oIEEE 1588

-• Peer-to-Peer Default PTP Profile

9/24/2008

67

PTP Profiles and-


68/89

• on ormance s spec e n erms o no es .e.,the standard does not talk about “network-level

”• Conformance is to

– IEEE 1588 standard

– PTP profile (i.e., a node claiming conformance shallconform to at least one PTP profile)

• o es con orm o a norma ve sec ons o1588 except those that are optional

– ,the clause that specifies the option (i.e., the option mustbe implemented in its entirety as specified)

9/24/2008

68

PTP Profiles and-


69/89

• no e s a con orm to e t er t e nnex t atdefines the transport protocol that it uses or, if

,specification published by the respectivestandards or anization that has urisdiction

over that transport protocol

9/24/2008

69

General Optional Features - 1


70/89

• n cast negot at on su c ause .

– Provides for negotiated unicast sessions of

• Sync, Announce, and Delay_Resp

– Subclause 16.1 defines TLVs that enable aclock to request unicast transmission, grant arequested unicast transmission made byanother clock, and cancel a unicast

9/24/2008

70



71/89

• at trace su c ause .

– Provides a mechanism for recording the

PTP message

•

detect rogue frames – Path trace is enabled or disabled via

management message

– A TLV appended to Announce messagecon a ns e pa race s

– Current path trace list may be retrieved from a

9/24/2008

71



72/89

• ternate t mesca es su c ause .

– One or more alternate timescales may be

– ALTERNATE_TIME_OFFSET_INDICATOR TLV is,

contains current information for the alternatetimescale

• currentOffset

• jumpSeconds

• displayName

– Alternate timescale is enabled disabled and

configured in GM via management messages9/24/2008

72

State Configuration-


73/89

• ause conta ns opt ons t at may e useto more explicitly control (i.e., more explicitly

– how a PTP system recovers from failure of a

– Which clocks in the network are acceptablemasters

• How these options are used with the default

BMCA or an alternate BMCA is up to thesystem integrator

9/24/2008

73



74/89

• ran master c uster ta e su c ause .

– Allows two or more OCs or BCs to be

– Provides for more rapid evaluation of the

– Each clock in the cluster maintains a mastercluster table

• Priority1 values of clocks in the clustershould be less than those of all other clocksn e oma n

– Each clock in the cluster periodically requests

listed in the grandmaster cluster table9/24/2008

74



75/89

• ternate master su c ause .

– Allows alternate masters that are not currently

– An alternate master is configured to send

– Slave may use the information contained inthese messages to acquire knowledge of thecharacteristics of the transmission pathbetween itself and each alternate master

• ows or as er sw c over o an a erna emaster when the current best master fails

–

management message9/24/2008

75



76/89

• n cast scovery su c ause .

– Allows PTP to be used over a network that

– Slave port is configured with addresses of,

Announce, Sync, and Delay_Resp messagesfrom these potential masters

– Configure via management TLVs

9/24/2008

76



77/89

• ccepta e master ta e su c ause .

– Allows configuration of a slave port to accept

master table

–

clocks can be in the master-slave hierarchyand, in a limiting case, can force a specificmas er-s ave erarc y

– Configured via management TLVs

9/24/2008

77



78/89

• ere s a un amenta con ct etween aself-configuring system (default BMCA defined

• The system integrator must exercise extreme

– Unintended behavior may result when usingthese o tions with the default BMCA

9/24/2008

78

Compatibility-


79/89

• ause e nes requ rements orcompatibility between

– an u ure vers ons – IEEE 1588 V1 and V2

• messages con a n a

versionPTP field –

– V2 versionPTP is port-specific (i.e., applies to

the ort that sends the messa e because in V2 the ports of a node may support V1 and/orV2

9/24/2008

79

Compatibility-


80/89

• ompat ty etween an uture vers ons

– If a V2 node receives a message with a versionPTP

,• Disregard the message if it is not defined in V2

V2, but disregard any TLV extensions that arenot defined in V2

• Disregard the message if any inconsistencies aredetected

9/24/2008

80

Compatibility-


81/89

• ompa y e ween an

– Recommended that V1 and V2 devices communicate via

a BC – Communication between V1 and V2 devices via a TC is

outside the scope of IEEE 1588

• ause con a ns e a e spec ca ons a

describe how V1 entities and attributes are- , ,

interworking

– Domains

– clock attributes

– messageType

–

– Timestamp representation9/24/2008

81

Transport Specific Field


82/89

•transportSpecific field, that functions as asubt e of the res ective Ethert e

• At present, 2 values are defined for the case oftransport of PTP directly over IEEE802.3/Ethernet

– DEFAULT (value = 0 (hex)): All PTP layer 2erne ransm ss ons no covere y ano er

enumeration value

– _reserved for use in connection with the standardbeing developed by the IEEE 802.1 AVB TaskGroup as P802.1AS

• See reference 8 for more detail on P802.1AS9/24/200882

Security - 1


83/89

• nnex escr es an exper menta secur typrotocol

– e pro oco as een rev ewe y secur yexperts

–

experience must be gained in its use• Provides rou source authentication

message integrity, and replay protection forPTP messages

• Does not provide nonrepudiation

• Does not support data confidentiality

(encryption)9/24/2008

83

Security - 2


84/89

• ompose o two as c mec an sms

– Integrity protection mechanism, which uses a

received message was transmitted by anauthenticated source, was not modified in transit,and is fresh (i.e., is not a replay). Replay

protection is implemented using counters.

– c a enge-response mec an sm, w c s useto affirm the authenticity of new sources and to

9/24/2008

84

Security - 3


85/89

• ecur ty protoco uses symmetr c messageauthentication code functions

– oc s s are secre eys• Flag in PTP message common header

TLV is present

present must also be security-enabled

•

9/24/2008

85

Transport of Cumulative


86/89

• Annex L describes an experimental TLV that maybe used to transport cumulative frequency offsetinformation

– The quantity transported is a scale factor that depends onboth the cumulative frequency offset and the frequencychange needed to drive the phase error to zero

• This information can be useful in some phase andfrequency compensation algorithms (e.g., see

o e ograp y nnex

• The TLV may be appended to either Sync or

o ow_ p messages – Recommended it be appended to Follow_Up messages

– , _

same length to avoid asymmetry effects (and all nodes mustsupport the extension)9/24/2008

86

Questions


87/89

9/24/2008

87

References - 1


88/89

. – , an ar or aPrecision Clock Synchronization Protocol for

,IEEE Instrumentation and Measurement Society,July 24, 2008.

2. John C. Eidson, IEEE 1588 Version 2 , Agilent

Laboratories, Measurement Research Lab,, .

3. John C. Eidson, IEEE-1588 Standard for a

Networked Measurement and Control Systems – A Tutorial , Agilent Technologies, October 10,

.

9/24/2008

88

References - 2


89/89

. . , ,LXI Beijing meeting, June, 2007.

5. Geoffre M. Garner, IEEE 1588 Version 2 , ISPCSVienna ‘07, Tutorial 1, October 1, 2007.

6. Ron Cohen, Security and IEEE 1588 , Tutorial 2,ISPCS Vienna 07.

7. John Eidson, Geoffrey M. Garner, John Mackay,,

Timing via IEEE 1588 Application Interfaces,

ISPCS Vienna 07.8. Michael D. Johas Teener, Geoffrey M. Garner,

Benjamin Hur, and Dawey (Weida) Huang,verv ew an m ng er ormance o

802.1AS, ISPCS Ann Arbor ‘08.9/24/2008

89

As Garner 1588v2 Summary 0908

Documents

Transcript of As Garner 1588v2 Summary 0908