IEC 61588:2004

INTERNATIONAL IEC
STANDARD 61588
First edition
2004-09
™
IEEE 1588
Precision clock synchronization protocol
for networked measurement
and control systems
Reference number
IEC 61588(E):2004
IEEE Std. 1588(E):2002
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the
60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.

Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,
edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the
base publication incorporating amendment 1 and the base publication incorporating
amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
) enables you to
The on-line catalogue on the IEC web site (www.iec.ch/searchpub
search by a variety of criteria including text searches, technical committees
and date of publication. On-line information is also available on recently issued
publications, withdrawn and replaced publications, as well as corrigenda.
• IEC Just Published
This summary of recently issued publications (www.iec.ch/online_news/ justpub)
is also available by email. Please contact the Customer Service Centre (see
below) for further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:

Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
INTERNATIONAL IEC
STANDARD 61588
First edition
2004-09
™
IEEE 1588
Precision clock synchronization protocol
for networked measurement
and control systems
Copyright © IEEE 2004 ⎯ All rights reserved
IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics Engineers, Inc.
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
The Institute of Electrical and Electronics Engineers, Inc, 3 Park Avenue, New York, NY 10016-5997, USA
Telephone: +1 732 562 3800 Telefax: +1 732 562 1571 E-mail: stds-info@ieee.org Web: www.standards.ieee.org
Commission Electrotechnique Internationale
International Electrotechnical Commission
Международная Электротехническая Комиссия

– 2 –
IEEE 1588-2002(E)
CONTENTS
Foreword. 4

IEEE introduction. 7

1. Overview. 8

1.1 Scope. 9

1.2 Purpose. 9

2. References. 9
3. Definitions.10
4. Conventions .12
4.1 Descriptive syntax.12
4.2 Word usage .12
4.3 Behavioral specification notation .13
5. Datatypes in a PTP system.15
5.1 Primitive datatypes.15
5.2 Derived datatypes.16
6. PTP Clock synchronization model. 17
6.1 Overview. 17
6.2 PTP systems. 21
7. PTP protocol specification. 33
7.1 Protocol model of a clock . 33
7.2 Protocol model of a subdomain of PTP clocks. 35
7.3 State behavior of clocks. 38
7.4 Clock data set. 42
7.5 Messaging and internal event behavior of clocks. 54
7.6 Best master clock algorithm. 71

7.7 Clock variance computation . 83
7.8 Local clock synchronization . 86
7.9 Values for system and clock constants. . 89
7.10 Physical requirements for PTP implementations. 91
7.11 PTP timing and event ordering constraints. 91
7.12 Management message semantics . 95
8. PTP inter-clock message formats. 95
8.1 Inter-clock messages.102
8.2 PTP message header specification.102
8.3 Sync and Delay_Req messages.105
8.4 Follow_Up messages . 109
8.5 Delay_Resp messages. 110
8.6 Management messages. 111
Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.
vi Copyright © 2002 IEEE. All rights reserved.

– 3 –
IEEE 1588-2002(E)
9. Conformance. 120

9.1 Conformance objective . 120

9.2 PTP node conformance requirements . 121

9.3 PTP system conformance requirements. 121

Annex A (informative) Using the PTP protocol. 122

Annex B (informative) Time scales and epochs in PTP . 128

Annex C (normative) subdomain_name to subdomain_address mapping algorithm . 133
Annex D (normative) Ethernet implementation of PTP . 134
Annex E (informative) Bibliography. 151
Annex F (informative) List of Participants . 152

Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.
– 4 –
IEEE 1588-2002(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
___________
PRECISION CLOCK SYNCHRONIZATION PROTOCOL

FOR NETWORKED MEASUREMENT AND CONTROL SYSTEMS

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization
comprising all national electrotechnical committees (IEC National Committees). The object of IEC is to
promote international co-operation on all questions concerning standardization in the electrical and
electronic fields. To this end and in addition to other activities, IEC publishes International Standards,
Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter
referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC National
Committee interested in the subject dealt with may participate in this preparatory work. International,
governmental and non-governmental organizations liaising with the IEC also participate in this preparation.
IEC collaborates closely with the International Organization for Standardization (ISO) in accordance with
conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has
representation from all interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly
indicated in the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC/IEEE 61588 has been processed through subcommittee 65C:
Digital communications, of IEC technical committee 65: Industrial-process measurement
and control.
The text of this standard is based on the following documents:

IEEE Std FDIS Report on voting
1588 (2002) 65C/333/FDIS 65C/340/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
The committee has decided that the contents of this publication will remain unchanged until
2007.
Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

– 5 –
IEEE 1588-2002(E)
IEC/IEEE Dual Logo International Standards

This Dual Logo International Standard is the result of an agreement between the IEC and the Institute of
Electrical and Electronics Engineers, Inc. (IEEE). The original IEEE Standard was submitted to the IEC for

consideration under the agreement, and the resulting IEC/IEEE Dual Logo International Standard has been

published in accordance with the ISO/IEC Directives.

IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating

Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards
through a consensus development process, approved by the American National Standards Institute, which

brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers

are not necessarily members of the Institute and serve without compensation. While the IEEE administers the
process and establishes rules to promote fairness in the consensus development process, the IEEE does not
independently evaluate, test, or verify the accuracy of any of the information contained in its standards.
Use of an IEC/IEEE Dual Logo International Standard is wholly voluntary. The IEC and IEEE disclaim liability for
any personal injury, property or other damage, of any nature whatsoever, whether special, indirect,
consequential, or compensatory, directly or indirectly resulting from the publication, use of, or reliance upon
this, or any other IEC or IEEE Standard document.
The IEC and IEEE do not warrant or represent the accuracy or content of the material contained herein, and
expressly disclaim any express or implied warranty, including any implied warranty of merchantability or fitness
for a specific purpose, or that the use of the material contained herein is free from patent infringement.
IEC/IEEE Dual Logo International Standards documents are supplied “AS IS”.
The existence of an IEC/IEEE Dual Logo International Standard does not imply that there are no other ways to
produce, test, measure, purchase, market, or provide other goods and services related to the scope of the
IEC/IEEE Dual Logo International Standard. Furthermore, the viewpoint expressed at the time a standard is
approved and issued is subject to change brought about through developments in the state of the art and
comments received from users of the standard.
Every IEEE Standard is subjected to review at least every five years for revision or reaffirmation. When a
document is more than five years old and has not been reaffirmed, it is reasonable to conclude that its contents,
although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to
determine that they have the latest edition of any IEEE Standard.
In publishing and making this document available, the IEC and IEEE are not suggesting or rendering
professional or other services for, or on behalf of, any person or entity. Neither the IEC nor IEEE is undertaking
to perform any duty owed by any other person or entity to another. Any person utilizing this, and any other
IEC/IEEE Dual Logo International Standards or IEEE Standards document, should rely upon the advice of a
competent professional in determining the exercise of reasonable care in any given circumstances.
Interpretations – Occasionally questions may arise regarding the meaning of portions of standards as they relate
to specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will
initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of concerned
interests, it is important to ensure that any interpretation has also received the concurrence of a balance of
interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are
not able to provide an instant response to interpretation requests except in those cases where the matter has
previously received formal consideration.
Comments for revision of IEC/IEEE Dual Logo International Standards are welcome from any interested party,
regardless of membership affiliation with the IEC or IEEE. Suggestions for changes in documents should be in
the form of a proposed change of text, together with appropriate supporting comments. Comments on standards
and requests for interpretations should be addressed to:
Secretary, IEEE-SA Standards Board, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA and/or

General Secretary, IEC, 3, rue de Varembé, PO Box 131, 1211 Geneva 20, Switzerland.
Authorization to photocopy portions of any individual standard for internal or personal use is granted by the
Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright
Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center,
Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy
portions of any individual standard for educational classroom use can also be obtained through the Copyright
Clearance Center.
NOTE – Attention is called to the possibility that implementation of this standard may require use of subject
matter covered by patent rights. By publication of this standard, no position is taken with respect to the
existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for
identifying patents for which a license may be required by an IEEE standard or for conducting inquiries into the
legal validity or scope of those patents that are brought to its attention.

Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

– 6 –
IEEE 1588-2002(E)
™
IEEE Std 1588 -2002
Precision Clock Synchronization Protocol
for Networked Measurement
and Control Systems
Sponsor
TC9—Technical Committee on Sensor Technology
of the
IEEE Instrumentation and Measurement Society
Approved 12 September 2002
IEEE-SA Standards Board
Abstract: A protocol to synchronize independent clocks running on separate nodes of a distributed
measurement and control system to a high degree of accuracy and precision is specified. The pro-
tocol is independent of the networking technology, and the system topology is self-configuring.
Keywords: clocks, distributed system, master clock, measurement and control systems, real-time
clock, synchronized clocks
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
All rights reserved. Published 8 November 2002. Printed in the United States of America.
Print: ISBN 0-7381-3369-8 SH95023
PDF: ISBN 0-7381-3370-1 SS95023
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
written permission of the publisher.
Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

– 7 –
IEEE 1588-2002(E)
IEEE Introduction
The objective of this standard is to specify a protocol to synchronize independent clocks running on separate

nodes of a distributed measurement and control system to a high degree of accuracy and precision. The

clocks communicate with each other over a communication network. In its basic form, this protocol is

intended to be administration free. The protocol generates a master slave relationship among the clocks in

the system. Within a given subnet of a network, there will be a single master clock. All clocks ultimately

derive their time from a clock known as the grandmaster clock. The communication path between any clock

and its grandmaster clock is part of a minimum spanning tree.
Patent notice
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken with respect to the existence or
validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying pat-
ents for which a license may be required by an IEEE standard or for conducting inquiries into the legal valid-
ity or scope of those patents that are brought to its attention. A patent holder has filed a statement of
assurance that it will grant licenses under these rights without compensation or under reasonable rates and

nondiscriminatory, reasonable terms and conditions to all applicants desiring to obtain such licenses. The

IEEE makes no representation as to the reasonableness of rates and/or terms and conditions of the license
agreements offered by patent holders. Further information may be obtained from the IEEE Standards
Department.
Information on the patent declaration can be found on the IEC website under the Technical work heading
(see Patent declarations).
Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

– 8 –
IEEE 1588-2002(E)
PRECISION CLOCK SYNCHRONIZATION PROTOCOL

FOR NETWORKED MEASUREMENT
AND CONTROL SYSTEMS
1. Overview
This standard is divided into nine clauses. They are as follows:
Clause Purpose
1 Provides the scope and benefits of this standard
2 Lists references to other standards that are referenced by this standard
3 Provides definitions that are either not found in other standards or have been modified for use with this
standard
4 Provides conventions for the notation used in this standard
5 Defines the datatypes used in this standard
6 Provides an overview of the protocol specified by the standard
7 Defines the precision time protocol (PTP)
8 Defines the format of messages passed between participating clocks
9 Defines requirements for conformance
Annexes are provided as follows:
Annex Purpose
A Using the PTP
B Defines time scales and epochs in PTP
C Defines subdomain_name to address mappings
D Defines the Ethernet implementation of PTP
E Bibliography
Annexes defining communication-medium-specific implementation details for additional network imple-
mentations are expected to be provided in future revisions of this standard.
Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

– 9 –
IEC 6    1588:2004(E)
IEEE
IEEE 1588-2002(E)
Std 1588-2002 IEEE STANDARD FOR A PRECISION CLOCK SYNCHRONIZATION

1.1 Scope
This standard defines a protocol enabling precise synchronization of clocks in measurement and control sys-

tems implemented with technologies such as network communication, local computing, and distributed

objects. The protocol will be applicable to systems communicating by local area networks supporting multi-

cast messaging including, but not limited to, Ethernet. The protocol will enable heterogeneous systems that

include clocks of various inherent precision, resolution, and stability to synchronize. The protocol will sup-
port systemwide synchronization accuracy in the submicrosecond range with minimal network and local
clock computing resources. The default behavior of the protocol will allow simple systems to be installed
and operated without requiring the administrative attention of users.
1.2 Purpose
Measurement and control applications are increasingly using distributed system technologies such as net-
work communication, local computing, and distributed objects. Many of these applications will be enhanced
by having an accurate systemwide sense of time achieved by having local clocks in each sensor, actuator, or
other system device. Without a standardized protocol for synchronizing these clocks, it is unlikely that the
benefits will be realized in the multivendor system component market. Existing protocols for clock synchro-
nization are not optimum for these applications. For example, Network Time Protocol (NTP) targets large
distributed computing systems with millisecond synchronization requirements. The protocol proposed in
this standard specifically addresses the needs of measurement and control systems:
— Spatially localized
— Microsecond to submicrosecond accuracy
— Administration free
— Accessible for both high-end devices and low-cost, low-end devices
2. References
This standard shall be used in conjunction with the standards listed in this clause. When the following stan-
dards are superseded by an approved revision, the revision shall apply.
™
IEEE Std 802.3 -2002, Information technology—Telecommunications and information exchange between
systems—Local and metropolitan area networks—Specific requirements—Part 3: Carrier sense multiple
access with collision detection (CSMA/CD) access method and physical layer specifications.
ISO 8601:2000, Data elements and interchange formats—Information interchange—Representation of dates

and times.
ISO/IEC 8859-1:1998, Information technology—8-bit single-byte coded graphic character sets—Part 1:
Latin alphabet No. 1
IEEE Publications are available from the Institute of Electrical and Electronics Engineers. 445 Hoes Lane, P.O. Box 1331, Piscataway,
NJ 08855-1331, USA and .
ISO publications are available from the International Organization for Standardization, vices/ISOstore/store.html>.
2 Copyright © 2002 IEEE. All rights reserved.
Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

– 10 –
IEEE
IEEE 1588-2002(E)
PROTOCOL FOR NETWORKED MEASUREMENT AND CONTROL SYSTEMS Std 1588-2002

3. Definitions
This clause defines terms that have specific meanings in the context of the PTP.

3.1 boundary clock: A clock with more than a single PTP port, with each PTP port providing access to a

separate PTP communication path.

3.2 clock: A node that is capable of providing a measurement of the passage of time since a defined epoch.

In this standard, the term clock is interpreted to mean either an ordinary clock or a PTP port of a boundary
clock unless otherwise stated or obvious from the context.
3.3 clock timestamp point: A point in the network protocol stack of a clock at which timestamps are gener-
ated for Sync and Delay_Req messages sent or received by the clock. This point is defined for both the
inbound and outbound paths in the protocol stack.
3.4 direct communication: A communication of PTP information between two PTP clocks with no inter-
vening boundary clock.
3.5 epoch: The reference time defining the origin of a time scale.
3.6 event: An abstraction of the mechanism by which signals or conditions are generated and represented.
3.7 external synchronization: The process of bringing two clocks into a synchronized state by means other
than the use of the PTP. See also: synchronized clocks.
3.8 grandmaster clock: Within a PTP subdomain, a PTP clock that is the ultimate source of time for clock
synchronization using the PTP protocol.
3.9 interface definition language (IDL): A programming-language-independent method of specifying
operation syntax [B1].
3.10 master clock: In the context of a single PTP communication path, a clock that when viewed from the
path appears to be the source of time to which all other clocks synchronize.
3.11 message timestamp point: A distinguished feature of Sync and Delay_Req messages serving as a ref-
erence point in these messages. A timestamp is defined by the instant a message timestamp point passes the
clock timestamp point in a protocol stack.
3.12 network: A communication mechanism for passing PTP messages among multiple clocks.

3.13 node: A device that can issue or receive PTP communications on a network.
3.14 ordinary clock: A PTP clock with a single PTP port.
3.15 ordinary communication: A communication of non-PTP information between two nodes.
3.16 port number: An index identifying a specific PTP port on a PTP clock.
3.17 preferred master clock set: A set of clocks that will be favored over those not so designated in the
selection of the grandmaster clock within a subdomain.
The numbers in brackets correspond to those of the bibliography in Annex E.
Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

– 11 –
IEEE
IEEE 1588-2002(E)
Std 1588-2002 IEEE STANDARD FOR A PRECISION CLOCK SYNCHRONIZATION

3.18 precision time protocol (PTP): The protocol defined by this standard. As an adjective, it indicates that

the modified noun is specified in or interpreted in the context of this standard.

3.19 PTP clock: A clock that participates in the PTP protocol.

3.20 PTP communication: Information used in the operation of the PTP protocol, transmitted in a PTP
message over a PTP communication path.

3.21 PTP communication path: A segment of a network enabling direct communication between two PTP

clocks.
3.22 PTP domain: A collection of one or more PTP subdomains.
3.23 PTP message: One of the five designated messages types defined in this standard: Sync, Delay_Req,
Follow-up, Delay_Resp, and Management.
3.24 PTP multicast communication: A PTP message sent from any PTP port and received and processed
by all PTP ports on the same PTP communication path. PTP multicast communications are not automati-
cally forwarded to other PTP communication paths by routers or other similar network components.
3.25 PTP node: A node that issues any message that will be received by a second node resulting in any
change in state in the second node that influences any aspect of the PTP protocol.
3.26 PTP port: The logical access point to a PTP clock for PTP communications on a single PTP communi-
cation path.
3.27 PTP subdomain: A logical grouping of PTP clocks that synchronize to each other using the PTP pro-
tocol but that are not necessarily synchronized to PTP clocks in another PTP subdomain.
NOTE—It should be emphasized that this grouping is logical. Clocks sharing a PTP communication path may or may
not be in the same PTP subdomain, and clocks in the same PTP subdomain may or may not share a PTP communication
path.
3.28 state transition diagram: A graphical means of expressing the allowed states of an object and the
allowed transitions from one state to another (see 4.3).
3.29 subnet: A subset of a network. If a network contains devices whose function is to pass messages and
these devices do not pass PTP non-management messages, then the network can be partitioned into regions
in such a way that:
— No two nodes in a region communicate via one of these devices, and
— All communication between regions is via one or more of these devices.
Each such region is a subnet. If a network does not contain any such devices, it is a subnet.
3.30 synchronized clocks: Two clocks are synchronized to a specified uncertainty if they have the same
epoch, and measurements of any time interval by both clocks differ by no more than the specified uncer-
tainty. The timestamps generated by two synchronized clocks for the same event will differ by no more than
the specified uncertainty.
3.31 timeout: A mechanism for terminating requested activity, at least from the requester’s perspective, that
does not complete within the time specified.
4 Copyright © 2002 IEEE. All rights reserved.
Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

– 12 –
IEEE
IEEE 1588-2002(E)
PROTOCOL FOR NETWORKED MEASUREMENT AND CONTROL SYSTEMS Std 1588-2002

3.32 universally unique identifier (UUID): An identifier that has a unique value within some defined uni-

verse. For purposes of this standard, the universe consists of all possible PTP artifacts having a UUID unless

otherwise stated.
4. Conventions
The specifications of this clause shall apply to all artifacts defined in this standard.

4.1 Descriptive syntax
The syntax conventions specified in the following subclauses are used in this standard.
4.1.1 Lexical form syntax
A lexical form refers to:
— A name
— A datatype
The conventions illustrated in the following list regarding lexical forms shall be used:
— Type names: e.g., TimeRepresentation (no word separation, initial letter of each word capitalized)
— Enumeration members and global constants: e.g., PTP_SYNC_MESSAGE (underscore word sepa-
ration, all letters capitalized)
— Fields of structures or messages: e.g., seconds, specialElement (no word separation, initial word not
capitalized, initial letter capitalization on subsequent words)
— Data set members and all other variables: new_master (underscore word separation, no letters capi-
talized)
— : text enclosed in angle brackets, < >, is used where the standard needs
to refer to something whose syntax or lexical form is dependent on the local implementation and
language.
When a lexical form appears in text, as opposed to in a signature, a type, or a format definition, the form is to
be interpreted as singular, plural, or possessive as appropriate to the context of the text.
4.2 Word usage
4.2.1 Shall
The word shall, equivalent to is required to, is used to indicate mandatory requirements, strictly to be fol-
lowed in order to conform to the standard and from which no deviation is permitted.
4.2.2 Recommended
The word recommended is used to indicate flexibility of choice with a strong preference alternative.
4.2.3 Must
The use of the word must is deprecated and shall not be used when stating mandatory requirements. The
word must is only used to describe unavoidable situations.
Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

– 13 –
IEEE
IEEE 1588-2002(E)
Std 1588-2002 IEEE STANDARD FOR A PRECISION CLOCK SYNCHRONIZATION

4.2.4 Should
The word should, equivalent to is recommended that, is used to indicate:

— Among several possibilities, one is recommended as particularly suitable, without mentioning or

excluding others.
— A certain course of action is preferred but not required.

— In the negative form, a certain course of action is deprecated but not prohibited.

4.2.5 May
The word may, equivalent to is permitted, is used to indicate a course of action permissible within the limits
of the standard.
4.2.6 Can
The word can, equivalent to is able to, is used to indicate possibility and capability, whether material or
physical.
4.3 Behavioral specification notation
State transition diagrams are used to specify behavioral characteristics as illustrated in Figure 1. Each state
transition diagram is composed of the following components:
— Named boxes, representing states
— Directed arrows, indicating transitions from one state to the next
Each transition is labeled with:
— The enabling event or predicate label for a transition
— The transition action label for a transition

6 Copyright © 2002 IEEE. All rights reserved.
Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

– 14 –
IEC 6    1  5 88 :2004(E)

IEEE
IEEE 1588-2002(E)
PROTOCOL FOR NETWORKED MEASUREMENT AND CONTROL SYSTEMS Std 1588-2002

(i)
State 1
State 1 or
State 2
event_1 OR event_2
result_1
event_3
result_2
State 2
result_3
(d)
ptp_meal
Figure 1—Mealy state transition diagram
The notation used describes state transition diagrams using the Mealy style, where actions are associated
with the transition from one state to another.
Events—for example, event_1, event_2, and event_3—identify the inputs to the state machine. They can be
operation requests and responses, or internal occurrences such as timer expirations.
Predicates—for example, event_1 OR event_2—identify enabling conditions for transitions. The first predi-
cate encountered, evaluating from left to right, that is TRUE selects the transition to execute and therefore
the next state.
Transition actions—for example, result_1—are the actions that are executed before transitioning to the next
state.
The next state identifies the state for the state machine after the selected transition action completes. As the
transition to the next state occurs, the value of the current state changes.
A bold line for a state box indicates that the box represents multiple states. Any transition shown that begins

and terminates in such a state box indicates that there has been no change in state.
Transitions—for example, the transition resulting in result_3—that have no indicated enabling conditions,
occur via unspecified mechanisms. Unless otherwise stated, in PTP these mechanisms are implementa-
tion-specific and outside the scope of the standard.
A transition into a state machine—for example, (i)—is indicated by a transition arrow that has no source
state. A transition out of a state machine—for example, (d)—is indicated by a transition arrow with no desti-
nation state.
Example: As a result of either event_1 or event_2 becoming TRUE, State 1 is replaced with the value of the
next state. In this example, the next state is State 2, which is specified as the name of the state box that is the
target of the transition arrow. Before the transition, result_1 occurs. event_3 can occur in either State 1 or
State 2. The state is unchanged but an action, result_2, occurs as the result of event_3.
Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

– 15 –
IEEE
IEEE 1588-2002(E)
Std 1588-2002 IEEE STANDARD FOR A PRECISION CLOCK SYNCHRONIZATION

5. Datatypes in a PTP system
For every datatype defined in a PTP system there shall be a default value designated. Quantities declared as

having a type shall be instantiated with the default value unless otherwise specified.

The datatypes specified for the various PTP variables and message fields define logical properties, such as

rollover for integers, necessary for correct operation of the protocol or interpretation of PTP message con-

tent.
The definition of data of types defined in this standard shall be correctly represented in the local system after
such data has been communicated over the network. In any PTP implementation, these datatypes shall be
mapped to implementation language-dependent primitives.
Implementations are free to use any internal representation preserving these characteristics provided that the
internal representation shall not change the semantics of any quantity visible via PTP communications.
The mapping of datatypes into their on-the-wire format is network specific. For each network used in a PTP
system, an annex to this standard shall be required that includes this mapping. Unless otherwise specified in
this standard, the mapping in the network specific annexes shall be used for all PTP communications.
The following normative definitions are used in this clause.
Definition Meaning
IDL: typedef An implementation of PTP Array of the datatype:
[ ];
IDL:
typedef Where is a primitive or previously defined PTP datatype, shall
; mean that is a synonym for
5.1 Primitive datatypes
The datatypes defined in Table 1 shall be defined in all PTP systems. All other datatypes shall be derived
from these primitive types.
Table 1—Primitive PTP datatypes
Datatype Default value Definition

Boolean FALSE TRUE or FALSE
Integer8 0 8-bit signed integer
UInteger8 0 8-bit unsigned integer
Integer16 0 16-bit signed integer
UInteger16 0 16-bit unsigned integer
Integer32 0 32-bit signed integer
UInteger32 0 32-bit unsigned integer
Integer64 0 64-bit signed integer
UInteger64 0 64-bit unsigned integer
Octet All bits set to 0 8-bit field not interpreted as a number
8 Copyright © 2002 IEEE. All rights reserved.
Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

– 16 –
IEEE
IEEE 1588-2002(E)
PROTOCOL FOR NETWORKED MEASUREMENT AND CONTROL SYSTEMS Std 1588-2002

5.2 Derived datatypes
The datatypes in this clause are based on the primitive datatypes. Only the primitive or derived datatypes

defined in this standard are allowed as part of a PTP message.

5.2.1 Specification of arrays of primitive types

All arrays defined by this standard shall be of fixed length. Any of the following array types may be used
provided the length is specified. Unless otherwise specified in this standard or network specific annexes, all
arrays shall be marshaled into an on-the-wire format with the member having the lowest numerical index
first.
IDL: typedef Boolean BooleanArray[];
IDL: typedef Integer8 Integer8Array[];
IDL: typedef UInteger8 UInteger8Array[];
IDL: typedef Integer16 Integer16Array[];
IDL: typedef UInteger16 UInteger16Array[];
IDL: typedef Integer32 Integer32Array[];
IDL: typedef UInteger32 UInteger32Array[];
IDL: typedef Integer64 Integer64Array[];
IDL: typedef UInteger64 UInteger64Array[];
IDL: typedef Octet OctetArray[];
5.2.2 Time type specifications
The TimeRepresentation type shall be used to specify both:
— Timestamps (Time with respect to an epoch)
— Time increments
IDL: struct TimeRepresentation

{
UInteger32 seconds;
Integer32 nanoseconds;
};
The range of the absolute value of the nanoseconds member shall be restricted to:
0 ≤ nanoseconds< 10
The sign of the nanoseconds member shall be interpreted as the sign of the entire representation.
A negative timestamp shall indicate time prior to the epoch.
Published by IEC under licence from IEEE. © 2004 IEEE. All rights reserved.

– 17 –
IEEE
IEEE 1588-2002(E)
Std 1588-2002 IEEE STANDARD FOR A PRECISION CLOCK SYNCHRONIZATION

A negative increment shall result for example from subtracting a timestamp A from a timestamp B, where A

is an instant later in time than B.

Example: A timestamp whose seconds mem
...