P1588

Submitter Email: doug.arnold2@gmail.com

Type of Project: Modify Existing Approved PAR
PAR Request Date: 03-Aug-2016
PAR Approval Date: 22-Sep-2016
PAR Expiration Date: 31-Dec-2017
Status: Modification to a Previously Approved PAR for the Revision of a Standard
Root PAR: P1588 Approved on: 14-Jun-2013
Root Project: 1588-2008

1.1 Project Number: P1588

1.2 Type of Document: Standard
1.3 Life Cycle: Full Use

2.1 Title: Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems

3.1 Working Group: Precise Networked Clock Synchronization Working Group (IM/ST/1588_WG)
Contact Information for Working Group Chair
Name: John Eidson
Email Address: john-eidson@stanfordalumni.org
Phone: 650-494-7204
Contact Information for Working Group Vice-Chair
Name: Hans Weibel
Email Address: hans.weibel@zhaw.ch
Phone: +41 58 934 7552

3.2 Sponsoring Society and Committee: IEEE Instrumentation and Measurement Society/TC9 - Sensor Technology (IM/ST)
Contact Information for Sponsor Chair
Name: Kang Lee
Email Address: kang.lee@ieee.org
Phone: 301-975-6604
Contact Information for Standards Representative
None

4.1 Type of Ballot: Individual

4.2 Expected Date of submission of draft to the IEEE-SA for Initial Sponsor Ballot: 01/2017
4.3 Projected Completion Date for Submittal to RevCom
Note: Usual minimum time between initial sponsor ballot and submission to Revcom is 6 months.: 10/2017

5.1 Approximate number of people expected to be actively involved in the development of this project: 30
5.2 Scope: This standard defines a network protocol enabling accurate Changes in scope: This standard defines a network protocol enabling
and precise synchronization of the real-time clocks of devices in accurate and precise synchronization of the real-time clocks of devices
networked distributed systems. The protocol is applicable to systems in networked distributed systems. The protocol is applicable to systems
where devices communicate via networks, including Ethernet. The where devices communicate via networks, including Ethernet. The
standard allows multicast communication, unicast communication or standard allows multicast communication, unicast communication or
both. The standard specifies requirements for mapping the protocol to both. The standard specifies requirements for mapping the protocol to
specific network implementations and defines such mappings, specific network implementations and defines such mappings,
including User Datagram Protocol (UDP)/Internet Protocol (IP including User Datagram Protocol (UDP)/Internet Protocol (IP
versions 4 and 6), and layer-2 IEEE 802.3 Ethernet. versions 4 and 6), and layer-2 IEEE 802.3 Ethernet. The protocol
enables heterogeneous systems that include clocks of various inherent
The protocol enables heterogeneous systems that include clocks of precision, resolution, and stability to synchronize to a grandmaster
various inherent precision, resolution, and stability to synchronize to a clock. The protocol supports synchronization in the sub-microsecond
grandmaster clock. The protocol supports synchronization in the range with minimal network bandwidth and local clock computing
sub-microsecond range with minimal network bandwidth and local resources. The protocol enhances support for synchronization to better
clock computing resources. The protocol enhances support for than 1 nanosecond. The protocol specifies how corrections for path
synchronization to better than 1 nanosecond. The protocol specifies asymmetry are made, if the asymmetry values are known. The
how corrections for path asymmetry are made, if the asymmetry values grandmaster can be synchronized to a source of time external to the

1
are known. The grandmaster can be synchronized to a source of time system, if time traceable to international standards or other source of
external to the system, if time traceable to international standards ortime is required. The protocol provides information for devices to
other source of time is required. The protocol provides information forcompute Coordinated Universal Time (UTC) from the protocol
devices to compute Coordinated Universal Time (UTC) from the distributed time, if the grandmaster is traceable to international
protocol distributed time, if the grandmaster is traceable to standards and is able to access pending leap second changes. Options
international standards and is able to access pending leap second are also provided to allow end devices to compute other time scales
changes. Options are also provided to allow end devices to compute from the protocol distributed time scale. The protocol defines timing
other time scales from the protocol distributed time scale. domains in which system timing is consistentand independent of
timing in other such domains. The protocol establishes the timing
The protocol defines timing domains in which system timing is topology. The default behavior of the protocol allows simple systems
consistent. The protocol establishes the timing topology. The default to be installed and operated without requiring the administrative
behavior of the protocol allows simple systems to be installed and attention of users to determine the system timing topology. The
operated without requiring the administrative attention of users to standard defines all needed data types, message formats, required
determine the system timing topology. computations, internal states, the behavior of devices with respect to
transmitting, receiving, and processing protocol communications. The
The standard defines all needed data types, message formats, required standard provides for the management of protocol artifacts in devices,
computations, internal states, the behavior of devices with respect to including a Simple Network Management Protocol (SNMP)-compliant
transmitting, receiving, and processing protocol communications. The management information base (MIB). The standard defines formal
standard provides for the management of protocol artifacts in devices. mechanisms for message extensions and the requirements for profiles
The standard defines formal mechanisms for message extensions and that allow customization for specific application domains. The
the requirements for profiles that allow customization for specific standard defines conformance requirements. Optional specifications
application domains. are provided for protocol security. This standard documents conditions
under which this standard is backward compatible with IEEE
The standard defines conformance requirements. Optional 1588-2008.
specifications are provided for protocol security. This standard
documents conditions under which this standard is backward
compatible with IEEE 1588-2008.

5.3 Is the completion of this standard dependent upon the completion of another standard: No
5.4 Purpose: This document will not include a purpose clause.
5.5 Need for the Project: The project is needed for the following reasons:
There is a need for correcting known technical and editorial errors in the IEEE 1588-2008 standard, including message path and timestamp
point issues and layer violation. It needs to clarify the layering, interfaces, and protocol of the standard, including the behavior of systems that
deploy different protocol options. It needs to improve the protocol's security and management capabilities, accuracy, robustness, and flexibility.
It also needs to incorporate the interpretations of IEEE 1588-2008 posted on the IEEE-SA web site.

5.6 Stakeholders for the Standard: Test and measurement, Industrial Automation, Power Generation and Utility, Telecommunications,
Semiconductor, Military/Aerospace, Audio/Video, Finance
Automotive, Medical, Basic Research

Intellectual Property
6.1.a. Is the Sponsor aware of any copyright permissions needed for this project?: No
6.1.b. Is the Sponsor aware of possible registration activity related to this project?: Yes
If yes please explain: There were known registration activities in IEEE 1588-2008. They will be carried to the revision.

7.1 Are there other standards or projects with a similar scope?: Yes
If Yes please explain: IETF's Networked Time Protocol (NTP) version 4, a time distribution protocol at milliseconds-level accuracy targeted
at business applications, while IEEE 1588 is of sub-microsecond-level accuracy suitable for technical applications, such as measurement,
control, and communication.
There are also profiles of IEEE 1588, such as the proposed IEEE 802.1AS and C37-238. They are not independent standards, but depending on
IEEE 1588 specification.

and answer the following

Sponsor Organization: Internet Engineering Task Force (IETF)
Project/Standard Number: RFC 5905
Project/Standard Date: 30-Jun-2010

2
 Project/Standard Title: Network Time Protocol version 4
7.2 Joint Development
Is it the intent to develop this document jointly with another organization?: No

8.1 Additional Explanatory Notes: See Section 5.5 Need for the Project for detailed explanation.
7.1: IEEE 802.1AS-2011, Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications
in Bridged Local Area Networks
C37.238-2011 - IEEE Standard Profile for Use of IEEE
1588 Precision Time Protocol in Power System Applications.
The PAR is being modified for the following reasons:
1.
The name of the contact at the ITU-T (interested standards body) has been updated
2.
Specific reference to an SNMP compatible MIB is removed since the revision will not contain a MIB
3.
Reference to "independent timing domains" is removed since the revision will include limited ways for domains to share information